As the world moves towards real-time connected systems, location tracking becomes one of the critical attributes of an IoT project. For example, location-based services play a critical role in tracking a logistic container or finding an available ride nearby (Uber).
Publish/Subscribe messaging is also very popular with IoT systems. The most commonly used protocol is MQTT, where a client could subscribe to a hierarchical topic of interest while the publisher publishes on a specific topic.
Usually, to build location intelligence in IoT apps, the publish-subscribe systems are bridged with a geospatial indexing database to implement location-based services in IoT. The most common approach is to feed the real-time location from sensors into a geospatial database(e.g., Redis Geohash, Tile38, ElasticSearch, ArcGIS, etc.). The location subscriber defines an Area of interest within the indexing system. When an object enters a predefined area of interest, the subscriber is notified via an event-based mechanism asynchronously, also known as Geotrigger. Alternatively, the subscriber could periodically query an area of interest to find available objects.
This approach is complex and challenging to maintain when the system scale increases. An alternative approach is to make the existing MQTT/NATS based publish/subscribe system location-aware, i.e., the topic hierarchy used in the publication and subscription messages are location-based.
E.g. Consider a hypothetical scenario where a sensor could publish its payload to the MQTT topic
/country/state/city/street
A subscriber could subscribe to a topic
/country/state/city/#
to receive live notifications from all objects currently in the city.
The goal would be to use existing standard off-the-shelf publish/subscribe systems such as AWS IoT/MQTT, NATS and build the geospatial indexing only by modifying the topics.
What would be the benefits of such a location-aware publish/subscribe system?
The Pros:
1) The primary benefit is to reduce the need for an external geospatial indexing engine. This drastically reduces the complexity of end to end system, e.g., no bridging is required between the MQTT broker and an external Geospatial database.
2) Scalability of the system is limited by how well the broker can scale, so there are fewer points of failure.
3) The latency of such systems is faster than a geospatial indexing system.
The cons:
1) An add-on function must be added to the client library to generate a hierarchical topic.
2) The accuracy could be slightly lesser due to marginal errors introduced by the underlying geospatial indexing mechanism.
3) The historical location of an object needs external storage (e.g., NATS jetstream)
Building a geospatial MQTT topic hierarchy
Two geospatial indexing systems are worth mentioning here.
S2 is a library for spherical geometry. It supports spatial indexing, including the ability to approximate regions as collections of discrete “S2 cells”. This feature makes it easy to build extensive distributed spatial indexes.
H3 (https://h3geo.org)
H3 is developed and open-sourced by Uber. One of the main differences between S2 and H3 is the choice of cell shape. S2 uses square cells, while H3 uses hexagonal cells. This leads to essential differences in neighbors, subdivisions, and visualization.
A detailed comparison between H3 and S2 can be found here
h3geo.org
Once the geospatial indexing system is chosen, the goal is to generate a hierarchical topic representing the index of the cell containing the current location.
For the publisher topic, this is very easy, as publishers are usually confined to a single-cell area of the indexing system. So the topic could be easily constructed using
/rootcell/childcell_1/childcell_2/.. .
For a subscriber, the thing gets complex, as the shape of the area of interest is usually not confined within a single cell. In this case, a larger parent cell could be chosen, or a collection of multiple cells could be subscribed.
For example, here is a visualization for subscribing H3 index for the City of Zurich, Switzerland with H3 hexagonal indexes with different resolutions. The cells with higher resolutions would be more exact, however the number of topics would be larger as well.
Furthermore, an optimization could be done to compact the neighbor cells to reduce the total number of subscription topic counts. E.g. we have reduced the number of cells required to represent the same area.
Conclusion:
A location-aware publish-subscribe system using a standard off-the-shelf MQTT/NATS broker would generate several benefits for simplification and scalability of the system. There are several use cases that require high scalability and low latency, which such a system could quickly implement.
For more information on implementing an MQTT/NATS-only geospatial messaging system, please reach out to us at [email protected]
