PaperlayerView exact revision on arXiv

Source-linked AI summary

A Spatially-Aware Publish-Subscribe Middleware for IoT Applications

Philipp Ungrund, Kurt Rothermel, Sukanya Bhowmik

arXiv:2608.25728v1cs.DC

TL;DR

Spatially aware communication in CPS and IoT lacks suitable middleware and standardized support, while existing location-based approaches are limited in their spatial filtering. The paper presents spaPS, which extends topic-based pub/sub with geometric neighborhoods and broker-side spatial filtering using MQTT 5-compatible mechanisms. Evaluations on synthetic and real-world data report efficient behavior and practical feasibility for existing pub/sub deployments.

  • Problem

    CPS and IoT lack suitable middleware and standardized mechanisms for spatial awareness, while existing location-based pub/sub commonly supports only containment and publisher-location filtering.

  • Method

    spaPS extends topic-based pub/sub with spatial neighborhoods, a geometric world model, and broker-integrated filtering based on physical state owners.

  • Results

    Evaluations on synthetic and real-world data show highly efficient behavior and practical feasibility for incorporating spaPS into existing pub/sub solutions.

  • Takeaways & Limitations

    spaPS supports spatially constrained IoT communication while preserving MQTT standard compliance and leaving existing client implementations virtually unchanged.

Abstract

from arXiv · show

Spatial and proximity awareness are critical enablers for efficient communication in Cyber-Physical Systems (CPS) and the Internet of Things (IoT). However, the lack of suitable middleware support and standardized mechanisms for spatial awareness significantly limits the pervasiveness of location-dependent applications. In this paper, we present a novel approach that extends topic-based publish-subscribe, a dominant messaging model in this domain, with integrated spatial filtering and routing capabilities. Our approach leverages a highly flexible geometric method for describing spatial filters, enabling expressive and efficient spatial subscriptions. A geometric world model operates together with an enhanced topic-based broker to realize spatially constrained message dissemination. Importantly, this functionality is achieved using the MQTT5 protocol without violating the standard or requiring any modifications to existing client implementations. Experimental results based on both synthetic and real-world data demonstrate strong system efficiency, minimal computational overhead at the broker, and the practical feasibility of deploying the approach on existing IoT devices.

I. INTRODUCTION

spaPS extends topic-based publish-subscribe with spatially aware subscriptions for CPS, addressing limitations of geofencing and publisher-location filtering. It uses expressive neighborhoods, a geometric model, and MQTT 5-compatible broker-side functionality.

  • Approach: Neighborhoods express spatial relationships that identify the physical entities whose state data subscribers want to receive.The approach is motivated by dependencies such as intersections receiving traffic-flow data from adjacent road segments.
  • Research gap: Existing location-based pub/sub systems mainly support containment geofencing and associate messages with publisher locations, constraining publisher placement.These systems require state owners to be physically co-located with publishers.
  • Approach: spaPS incorporates physical entities into pub/sub so digital counterparts can publish and consume state data using both topics and spatial neighborhoods.Each message identifies the topic and the physical state owner, while subscriptions specify topics and groups of relevant physical entities.
  • Implementation: Broker-side extensions keep client implementations virtually unchanged, preserving MQTT’s lightweight character for resource-limited IoT devices.The prototype enhances ActiveMQ Artemis, and the implementation is intended as a drop-in replacement.
  • Contributions: The architecture integrates spatial filtering into classic topic-based pub/sub while adhering to the MQTT standard.The stated contribution includes an expressive neighborhood scheme and an MQTT-compliant spatial-filtering architecture.
  • Evaluation: Evaluations on synthetic and real-world data demonstrate the practical feasibility and efficiency of the middleware.The paper describes extensive evaluations of spaPS as evidence for these properties.

II. RELATED WORK

Related systems provide scalable or location-based pub/sub, but commonly use simple containment geofencing and publisher locations. spaPS instead combines a richer spatial world model with broker-integrated filtering and routing.

  • Scalable pub/sub: Prior pub/sub research emphasizes high throughput, low latency, parallel filtering, or network-layer performance rather than integrated spatial awareness.The related systems cited include multi-server and line-rate filtering approaches.
  • Location-based pub/sub: Location-based pub/sub systems use geofences and publisher locations to filter messages, limiting spatial reasoning to containment.This also forces publishers to be co-located with the physical entities whose state they transmit.
  • Location-based pub/sub: spaPS decouples physical entities from digital publishers and consumers, allowing the latter to be placed anywhere in the IoT infrastructure, including mobile devices.Its richer world model addresses the publisher-placement constraint described for geofencing systems.
  • MQTT-based systems: Some MQTT-conforming location systems perform location filtering in a dedicated client, causing each publication to traverse the broker twice.The related-work discussion identifies this design as less efficient and disadvantageous for scalability.
  • Service discovery: The proposed neighborhood concept is tailored to pub/sub communication and differs from spatial extensions designed for proximity-based service discovery.The paper distinguishes the communication purpose and extension mechanisms of the two approaches.
  • Spatial data: spaPS uses a geometric model supported by widely available geospatial sources such as GIS datasets, NASA EarthData, USGS resources, and OpenStreetMap.The supplied passage introduces these data sources as available bases for the model.

2) Geometric World Model:

The Geometric World Model represents relevant physical entities, their geometry, categories, and standardized spatial relationships. It supports spatial analysis but assumes modeled entities are quasi-static.

  • Entity representation: The World Model represents both material objects, such as buildings and road segments, and immaterial objects, such as traffic zones and national borders.These entities form the geometric representation used by spaPS.
  • Entity representation: Each modeled physical entity has a unique identifier, geometry, and category.Geometry captures position, orientation, size, and shape; categories group entities by purpose or type.
  • Entity representation: Categories can be organized hierarchically, enabling groups such as road/major/motorway to include motorway segments.The hierarchy parallels the organization of topics.
  • Spatial relations: Spatial relationships in the model follow OGC Simple Feature Access and include topological and metric relations.The model uses standardized relations, with the final relation in the referenced table identified as metric and the others as topological.
  • Spatial relations: OGC spatial-analysis routines provide Boolean tests that return true or false for whether two geometries satisfy a relationship.The passage states that major database-management-system vendors support these routines.
  • Scope boundary: The world model is quasi-static: changes create new model versions, and modeled mobile physical entities such as vehicles and people are unsupported.Publishers and subscribers may still be mobile; support for mobile physical entities is left for future research.

IV. SPECIFYING NEIGHBORHOODS

spaPS neighborhoods specify groups of physical entities through references, categories, and spatial conditions, with optional logical composition and chained multi-stage resolution.

  • Expressive specification: Spatial conditions can combine multiple relations with AND, OR, and NOT, while category and reference sets increase expressiveness.Examples include selecting primary roads within a zone, border motorways, or major roads across multiple zones.
  • Single-stage neighborhoods: A neighborhood descriptor contains non-empty references, categories, and one or more logically connected spatial relations.The Select function returns category-matching entities spatially related to at least one reference, excluding the references themselves.
  • Multi-stage neighborhoods: Multi-stage neighborhoods chain stage descriptors so later stages select entities using neighbors from any subset of preceding stages as references.Each stage can apply its own categories and spatial conditions to the constructed reference set.
  • Example neighborhoods: Two-stage resolution can first select border motorway segments and then select adjacent parking spaces using those segments as references.This models a practical dependency chain from a zone to road segments to parking facilities.
  • Stage filtering: A stage filter lets subscribers include only selected stages in the final neighborhood rather than all stage results.The parking-management example retains only facilities selected in the final stage.

A. System Architecture

spaPS combines an enhanced topic-based broker with a spatial database that resolves neighborhood subscriptions into physical-entity filters for message routing.

  • Architecture: The architecture consists of a spatial broker, a spatial database containing the geometric world model, and clients acting as publishers or subscribers.The broker queries the database for neighborhood resolution.
  • Subscription processing: A neighborhood subscription combines a topic with a neighborhood, and resolution maps the subscription to relevant physical-entity identifiers called spatial filters.Publications carrying a physical-entity identifier are termed spatial publishes.
  • Broker components: The broker maintains topic and spatial filter mappings, per-subscription message queues, and managers that coordinate subscription and publication processing.The publication manager uses these mappings and queues to route filtered publications.
  • Subscription processing: A subscription creates a queue, updates topic mapping, resolves its neighborhood through the spatial DBMS, and adds the resulting identifiers to the spatial filter mapping.The stored procedure returns the resolved physical-entity identifiers for the subscription.
  • Neighborhood resolution: Neighborhood resolution processes each stage by merging preceding-stage neighbors, selecting current-stage neighbors, and inserting results into a temporary table.The database stores physical entities, category memberships, category-layer geometry, and intermediate neighborhood results.

2) Spatial Filter Mapping:

spaPS supports either database-resident or in-memory mappings from subscriptions to physical entities, trading update and lookup characteristics between the two variants.

  • Mapping variants: The spatial filter mapping associates unique subscription identifiers with sets of physical-entity identifiers and can reside in the DBMS or broker memory.The two variants differ in where and how this mapping is stored.
  • Database mapping: O(log(F ∗S)) is the asymptotic complexity for adding a spatial filter in the database variant.F is the number of spatial filters, and S is the average number of physical entities per filter; both mapping columns use B-tree indexes.
  • In-memory mapping: O(S) is the time complexity for adding a subscription to the in-memory mapping.This mapping uses physical-entity identifiers as hash-map keys and subscription-identifier hash sets as values.

C. Publication Filtering & Routing

spaPS filters publications first by topic and then by the physical entity whose state they carry, routing matches to subscription queues.

  • Filtering pipeline: Incoming publications are first filtered against topic subscriptions, producing the subset Subtfiltered.This preserves the traditional topic-based publish-subscribe filtering step.
  • Filtering pipeline: The topic-filtered subset is then filtered spatially by looking up the publication’s physical-entity identifier in the spatial filter mapping.This lookup identifies the subscriptions whose neighborhoods include the publication’s state owner.
  • Routing: Matched subscriptions are selected for routing, and each publication is added to its corresponding subscription message queue for delivery.The queue manager provides the eventual delivery path to subscribers.
  • Complexity: The in-database spatial lookup has O(log(F ∗S)) complexity, whereas the main-memory lookup has O(1) complexity.The main-memory design therefore favors publication filtering over filter addition.

VI. IMPLEMENTATION

spaPS is implemented as four cooperating components: a spatial database, an enhanced topic-based broker, a message codec, and a spatial client.

  • The spatial database stores the geometric world model, resolves neighborhoods, and can store an in-database mapping of resolution results.
  • The enhanced topic-based broker applies spatial filtering using mappings constructed through the spatial database in response to neighborhood subscriptions.
  • The message codec supports topic-based communication while encoding neighborhood descriptors in subscriptions and physical entity identifiers in publications.
  • The spatial client is built on Eclipse Paho MQTT, while ActiveMQ Artemis and PostGIS provide the broker and spatial database implementations.

VII. EVALUATION RESULTS

The evaluation compares in-database and main-memory spatial filter mappings using synthetic and real-world data. Both modes provide low filtering latency, while main memory generally performs better because it avoids database communication overhead.

  • The experiments compare in-database and main-memory mapping modes using synthetic mappings and Berlin OpenStreetMap data.Synthetic data controls matching and client-distribution variables, while real-world experiments use preprocessed Berlin data.
  • Main-memory mapping performs better than in-database mapping as publish rate increases because it avoids communication overhead between Artemis and PostGIS.
  • spaPS maintains low-microsecond filtering latencies and high publish rates, especially with main-memory mapping, across the large-scale experiments.
  • Both mappings show slowly increasing filtering time in the lower microseconds as subscription count rises at 100 000 messages/s.
  • Main-memory mapping has a constant filter-addition time, whereas in-database mapping increases logarithmically under subscription churn.

3) Impact of Spatial Filter Size:

Evaluation across synthetic and real-world settings examines how spatial filter size and neighborhood resolution affect filtering and subscription addition. Filtering remains nearly constant over the tested sizes, while addition behavior differs by mapping and resolution stage.

  • 3) Impact of Spatial Filter Size:: Both mapping modes exhibit constant filtering time in the low µs across the tested spatial filter sizes.The in-database mode is about 70 µs slower and slightly more variable under the chosen parameters.
  • 3) Impact of Spatial Filter Size:: In-database filter addition increases logarithmically with spatial filter size, while main-memory addition increases more linearly.
  • C. Performance under Real-World Data: The real-world evaluation uses 1 000 one-stage neighborhood subscriptions, 592 publishers, and an overall publish rate of 50 000 messages/s.
  • C. Performance under Real-World Data: After an initial warm-up of around 200 ms, both real-world mapping modes settle around constant filtering time, with main memory performing better.
  • C. Performance under Real-World Data: Single-stage neighborhood resolution is faster than multi-stage resolution, while neighborhood scope has only a small effect on subscription addition time.
  • The evaluation results show highly efficient spaPS behavior on both synthetic and real-world data and practical feasibility for existing publish-subscribe solutions.

APPENDIX A IMPLEMENTATION DETAILS

The implementation uses established MQTT5-compatible components and encodes spatial information through standardized user properties. It focuses on QoS 0 and requires clients to support MQTT5 user-property handling.

  • The prototype combines enhanced ActiveMQ Artemis, PostGIS, MQTT5, and Eclipse Paho MQTT client implementations.
  • MQTT5 user properties carry application-specific spatial information without modifying the standardized protocol.
  • The implementation focuses on QoS 0 delivery semantics and does not study client-authentication implications.
  • Neighborhood subscriptions encode an identifier and JSON neighborhood descriptor, while unsubscribe packets carry the neighborhood subscription identifier.
  • Publications carry physical entity identifiers from clients, and brokers add matching spatial filter identifiers when forwarding filtered publications.
  • MQTT5-compliant client libraries are sufficient when they support reading and writing user properties.
Loading 2608.25728v1…