SenseMyCity: Crowdsourcing an Urban Sensor

I. INTRODUCTION

• Smartphones can support personal sensing and aggregated data collection across groups and geographic areas, making large-scale urban datasets tractable.Examples include cartographic and environmental data such as street steepness, traffic delay, noise, and pollution.Source: §I · p. 1
• Large-scale mobile data gathering must balance limited phone resources and availability with transmission costs, privacy, and user control.Users may bear monetary costs for data connections, and should control when sensitive data is gathered, who can access it, and why.Source: §I · p. 1
• SenseMyCity extends prior netbook-based work with a mature, configurable smartphone framework for collecting sensor data and securely transmitting it to backend servers.Configuration can adapt resource use and sampling rates to a usage scenario, including lowering sampling when battery falls below a set level.Source: §I · p. 1
• The framework's contributions include a modular Android application, resource-consumption studies, and example projects using gathered data.The paper frames these studies in terms of energy, storage, and the cost-of-knowledge of sensing tasks.Source: §I · p. 1

A. User Requirements

• Participant requirements include low interaction, non-intrusive operation, clear disclosure, configurable energy and connectivity use, and control over personal data.Users should be able to access, download, or delete their data; identification should not be directly reversible or accessible to researchers.Source: A. User Requirements · p. 2

B. Researcher Goals

• Researchers require a system compatible with widely used, economical devices that supports new sensors, preserves data accuracy, scales under demand, and estimates bandwidth and storage needs.The goals include compatibility with load balancing mechanisms.Source: B. Researcher Goals · p. 2

II. SENSEMYCITY CROWDSENSOR

• SenseMyCity structures its design around system architecture and data structures, a communication protocol, a mobile application, and backend servers.Source: §II · p. 2

A. System Architecture

• The three-tier architecture separates gathering units, main servers, and secondary servers, with distinct functions for each block.Gathering units synchronize, encapsulate, and transmit sensor data; main servers receive and store it; secondary servers provide application-level services.Source: A. System Architecture · p. 2
• Separating storage from analysis and visualization protects write-focused storage from computationally expensive queries and experiments.Secondary servers can be rolled back without losing raw data, and may hold either a full replica or a specialized subset.Source: A. System Architecture · pp. 2–3

1) Data Structure:

• The database structure can change as sensors and requirements evolve, while shared data-type conventions support compatibility across projects.Session information includes identifiers and keys; gathered data are timestamped and linked to a session identifier.Source: 1) Data Structure · p. 3
• High-frequency sensors can be stored as arrays, while asynchronous or higher-precision readings can use millisecond timestamps.Auxiliary tables can store shared, non-personal data such as WiFi address-to-network mappings to reduce repetitive storage.Source: 1) Data Structure · p. 3

B. Reliable and Secure Data Gathering

• The protocol combines encryption, compression, feedback, and access control to provide confidentiality, integrity, reliability, and authentication.The implementation uses 4096-bit RSA to exchange random 128-bit AES session keys.Source: B. Reliable and Secure Data Gathering · p. 3
• The stateless server supports real-time or on-demand transmission over different network connections, but does not authenticate users when storing data.The authors note that this can permit uploads under fake user IDs, though an attacker cannot access another user's existing data.Source: B. Reliable and Secure Data Gathering · p. 3
• A two-way handshake authenticates each sensing session and exchanges a symmetric key before the data-transmission phase.The handshake packet includes session time, key, version, and optional identifiers; the server returns a session identifier.Source: B. Reliable and Secure Data Gathering · pp. 3–4
• Sequence-numbered feedback permits sending later packets before earlier acknowledgements arrive, which can increase throughput on high-latency connections.Feedback reports rows successfully written to the database, making local deletion safe after positive confirmation.Source: B. Reliable and Secure Data Gathering · p. 4

• SenseMyCity uses Android smartphones’ embedded sensors as a testbed for urban data gathering.Source: C. Mobile Data Gathering Application · p. 4
• The app targets a wide range of Android phones with almost no configuration or interaction, emphasizing stability and efficiency across differing hardware resources.Source: C. Mobile Data Gathering Application · p. 4

1) Interface:

• The app gathers in the background while showing a status notification, and lets users start, pause, stop, configure, or synchronize sessions through its interface.A home-screen widget provides session controls without opening the app.Source: 1) Interface · p. 4
• The app lets users choose sensors, sampling rates, real-time or manual synchronization, and allowed network types, while researchers can fix or limit settings before deployment.Defaults collect GPS, accelerometer, and WiFi data.Source: 1) Interface · p. 4
• The main service initializes configured sensor threads and managers, runs resources in separate threads, and flushes local data when a session ends.The architecture figure depicts processing modules and information flow.Source: 2) Architecture (Fig. 3) · p. 4, Figure 3 · p. 5
• Each sensor thread timestamps incoming data, while a memory manager buffers it to reduce SQLite transactions and supports optional real-time synchronization.Local SQLite storage was the main performance bottleneck in tests, sometimes delaying a single operation by a few seconds.Source: 2) Architecture (Fig. 3) · p. 5
• The Internet Manager authenticates and uploads data using the communication protocol; session keys are randomly generated when a session starts.The server RSA key is embedded in the app and can be changed through an application update.Source: 2) Architecture (Fig. 3) · p. 5

3) Data Synchronization:

• The app captures the device timestamp in milliseconds immediately after each sensor reading to reduce timing delay and jitter; offline GPS data can help compare and correct its clock.Source: 3) Data Synchronization · p. 5

• The backend uses a tiered architecture with a main server and a secondary server.The back-end implementation is depicted in Fig. 4.Source: D. Back-office Implementation · p. 5, Figure 4 · p. 5
• Separate workers handle authentication, packet processing, and database operations; data packets are discarded when keys are unavailable or decryption or decompression fails.The gathering unit receives a response only after database storage is confirmed, supporting reliable storage of session and sensor data.Source: D. Back-office Implementation · p. 5
• The system uses relational storage for multiple-index bulk writes and complex reads, with PostgreSQL as the default for its GIS extension and replication support.The server can also use MySQL and is configurable for other storage engines.Source: D. Back-office Implementation · pp. 5–6
• The database separates session information, gathered sensor data, and auxiliary data; user records are restricted to authentication mechanisms and the database administrator.Auxiliary data avoids transmitting or storing redundant information, saving bandwidth and storage.Source: D. Back-office Implementation · p. 6, Figure 5 · p. 6
• Accelerometer, gyroscope, and magnetometer tables share the same structure, supporting consistency across gathered-data tables.Source: D. Back-office Implementation · p. 6

• An OpenID login with a Google account lets users view their recorded sessions and associated data through a GIS service.Other services and algorithms add information such as fuel-consumption calculations from OBD data and WiFi signal-strength maps.Source: 2) Front End · p. 6
• A separate webpage lets users access, download, and delete all of their data.Source: 2) Front End · p. 6

A. Saving the user’s battery

• The study tested at least five runs per configuration on two phones during three-hour data-gathering sessions, measuring battery use and estimated time to depletion.The phones were a 2010 Samsung I5500 and a 2012 LG Nexus 4.Source: A. Saving the user’s battery · p. 6
• Table I shows a clear improvement between the phones in energy consumption for the accelerometer, gyroscope, and magnetometer, even after accounting for differences in battery capacity.The comparison refers to estimated wattage from Fig. 7.Source: A. Saving the user’s battery · p. 6
• Fig. 6 presents common sensor setups by average watts per hour and corresponding battery consumption, supporting estimates of battery requirements for sensing scenarios.The analysis also reports estimated battery autonomy.Source: A. Saving the user’s battery · pp. 6–7, Figure 6 · p. 7
• Accelerometer use stayed constant across 5–50 Hz on the Samsung, while Nexus 4 consumption rose with sampling rates from 5–200 Hz.The paper describes the Nexus 4 sensor as more efficient overall.Source: A. Saving the user’s battery · p. 7, Figure 7 · p. 7
• A 60-second GPS sampling rate reduced energy use by 35% (-35 mWh) compared with 1-second sampling; GPS energy use did not scale linearly with sampling rate.The paper attributes the nonlinearity to the several seconds needed to obtain a GPS fix after waking from standby.Source: A. Saving the user’s battery · p. 7, Figure 8 · p. 7
• WiFi energy use also did not scale proportionally with sampling rate; at 60 seconds, it fell by 69% (-54 mWh) versus 1 second, while collecting from every internal sensor lasted 6–10 hours in tested models.The paper estimates that one hour of daily travel would leave 15% less battery for sensing those trips.Source: A. Saving the user’s battery · p. 7, Figure 9 · p. 7

B. Minimizing the user’s storage and communication costs

• Default sensing stores about 150 bytes per second, or 540 KB per hour, including identifiers and timestamps.The configuration samples GPS at 1 Hz, scans WiFi every 2–3 seconds, and uses typical Android rates of 4–15 Hz for motion sensors.Source: B. Minimizing the user’s storage and… · p. 7
• An intensive configuration with maximum sampling, many WiFi networks, and external OBD data requires about 4 KB per second, or 13 MB per hour.The accelerometer, gyroscope, and magnetometer account for more than 90% of storage use.Source: B. Minimizing the user’s storage and… · p. 7
• For a one-hour session, 700 KB in SQLite became a roughly 1,100 KB JSON string, then 120 KB transmitted after compression and encryption—83% compression from SQLite storage.The protocol serializes data as JSON, compresses it with zlib, encrypts it, and transmits it to the server.Source: B. Minimizing the user’s storage and… · pp. 7–8

C. Meeting the privacy expectations of the user

• Privacy measures include securing communications, using third-party OpenID authentication, storing only an inaccessible hashed email for authentication, and giving users ownership and session deletion.The authors say the architecture conforms with suggested EU Data Protection Guidelines and provides mechanisms for services built on it to do likewise.Source: C. Meeting the privacy expectations of… · p. 8

IV. EXPERIMENTAL RESULTS

• 115 volunteers contributed around 150 million data rows across 3,500 trips and more than 6,200 sensing hours.The collected data included GPS, accelerometer, OBD vehicle, and WiFi measurements.Source: §IV · p. 8
• Cardiac data from public bus drivers was used to estimate stress and create a stress map.The app gathered cardiac information from external biomonitoring devices.Source: §IV · p. 8, Figure 10 · p. 8
• Synchronized OBD and GPS data trained a model to estimate instantaneous fuel consumption from GPS-derived speed, acceleration, and road gradient.The resulting city map clustered fuel-consumption data from Porto.Source: §IV · p. 8, Figure 11 · p. 8
• A WiFi connectivity project estimated access-point locations and predicted travel-path access-point sequences to reduce handshakes while maximizing availability and path coverage.Source: §IV · p. 8
• Universities used SenseMyCity to collect real-world, student-related datasets for machine-learning courses and projects, with data export in a standard format.Source: §IV · p. 8

V. RELATED WORK

• Participatory systems depend on user reports and can miss secondary or unnoticed environmental events, while opportunistic sensing gathers raw data with little user interaction.Opportunistic data typically requires more offline processing to filter and infer information.Source: §V · p. 9
• Unlike scenario-specific sensing systems, SenseMyCity was designed to be configurable for varied projects and a larger range of sensors.The related-work discussion notes that other opportunistic platforms focus on narrower sensor sets and scenarios.Source: §V · p. 9
• Crowdsensing data may be noisy, biased, or generated by misbehaving nodes, and privacy-sensitive location collection remains difficult to manage.The paper says reliability issues should be handled during data processing and notes that location privacy depends on data use and sharing.Source: §V · p. 9

VI. CONCLUSIONS

• The application can be configured for sensor selection, sampling rates, real-time transmission, and allowed connection types, and can run in the background with minimal user interaction.Source: §VI · p. 9
• The platform supports distinct sensing projects and can be extended to new sensors rather than being limited to one scenario.Source: §VI · p. 9
• Benchmarking across smartphone models and configurations estimates battery consumption and storage requirements, helping researchers estimate and minimize cost-of-knowledge.Source: §VI · p. 9