A system for coarse-grained location-based synchronisation

This paper describes a system for supporting coarse-grained location-based synchronisation. This type of synchronisation may occur when people need only some awareness about the location of others within the specific context of an on-going activity. We have identified a number of reference scenarios for this type of synchronisation and we have implemented and deployed a prototype to evaluate the type of support provided. The results of the evaluation suggest a good acceptance of the overall concept, indicating that this might be a valuable approach for many of the indicated scenarios, possibly replacing or complementing existing synchronisation practices.

💡 Research Summary

The paper introduces a novel approach to support “coarse‑grained location‑based synchronisation”, a type of coordination where participants only need to know whether others have entered a predefined geographic area during a shared activity, rather than receiving continuous precise location updates. The authors argue that many everyday coordination tasks—such as families splitting up in a shopping centre, flash‑mob participants checking attendance, co‑workers sharing a car ride, or household members monitoring task completion—can be satisfied with this minimal, binary location information.

To ground the concept, the authors first review related work. Existing location‑sharing services such as Google Latitude and Locaccino provide continuous, fine‑grained tracking but raise significant privacy concerns and often deliver more information than required for simple synchronisation. Ambient display systems like the Whereabouts Clock and HomeNote demonstrate the value of situated awareness but are either fixed to a single location or focus on person‑to‑place communication rather than person‑to‑person coordination. The gap identified is a lack of tools that integrate location‑based cues directly into the scheduling workflow.

The paper then presents four reference scenarios that illustrate the need for coarse‑grained synchronisation: (1) a group that separates within a mall and reconvenes later, (2) a flash‑mob or dinner party where participants need to know who has already arrived, (3) a car‑pool where a rider wants to know when the driver is nearby, and (4) family members who wish to be reassured that chores have been completed. From these scenarios the authors derive functional requirements: activities must be bound to a temporal window and a geographic scope, support multiple participants, allow users to enable or disable synchronisation per activity, and respect context‑dependent privacy policies (e.g., identity disclosure).

The proposed system architecture consists of three main components:

1. Mobile Synchronisation Application – a smartphone app that lets users create, edit, and join activities. The app can be used on‑site, offline with pre‑entered coordinates, or with coordinates added later. It monitors GPS and, upon entering the activity’s geofence, notifies the server. Users can select privacy settings per activity, influencing what information is shared in notifications.

2. Shared Calendar System – an existing calendar service (e.g., Google Calendar) serves as an entry point for activity creation and participant invitation. Calendar events are extended with optional latitude/longitude fields and the system’s service email address, allowing the synchronisation server to discover new activities automatically.

3. Synchronisation Server – the central mediator that pulls activity metadata from the calendar, tracks participant acceptance, and manages notification distribution. When an activity’s start time is reached, the server begins accepting location events from mobile clients. Upon a user’s arrival in the defined region, the server generates a notification for all participants, respecting the activity’s privacy policy (e.g., showing the user’s name or an anonymous token). Different activity types can trigger different notification frequencies and contents.

Operationally, a user creates an activity via the app or calendar, invites participants, and receives acceptance responses. The server records who has accepted. When the activity starts, the server opens a “listening window” for geofence events. As participants cross the boundary, the server pushes arrival notifications to the remaining participants. This design limits location data collection to the minimal necessary moment, reducing bandwidth usage and privacy exposure.

The prototype was evaluated with six participants who simulated realistic social situations corresponding to the reference scenarios. Qualitative feedback indicated high acceptance: participants found the concept intuitive, appreciated the reduced information overload, and felt that privacy controls were adequate. They also reported that the system complemented existing calendar tools by providing real‑time situational awareness without requiring constant messaging. Limitations noted include the small sample size, lack of quantitative metrics on GPS accuracy, battery consumption, and network latency, and the need for more extensive usability testing.

In conclusion, the paper defines and validates the concept of coarse‑grained location‑based synchronisation, demonstrating that integrating simple geofence‑triggered notifications into calendar‑driven workflows can effectively support a range of everyday coordination tasks. The authors suggest future work on scaling the system to larger user bases, exploring richer privacy models (e.g., differential privacy), incorporating peer‑to‑peer fallback mechanisms for offline scenarios, and optimizing energy consumption for continuous geofence monitoring.