=Paper=
{{Paper
|id=Vol-1762/Herle
|storemode=property
|title=Bridging GeoMQTT and REST
|pdfUrl=https://ceur-ws.org/Vol-1762/Herle.pdf
|volume=Vol-1762
|authors=Stefan Herle,Ralf Becker,Jörg Blankenbach
}}
==Bridging GeoMQTT and REST==
https://ceur-ws.org/Vol-1762/Herle.pdf
Bridging GeoMQTT and REST
Stefan Herle, Ralf Becker & Jörg Blankenbach
Chair for Computing in Civil Engineering & Geo Information Systems
RWTH Aachen University
Aachen, Germany
herle@gia.rwth-aachen.de
Abstract— Wireless geo sensor networks (WGSN) use (OGC) Sensor Web Enablement (SWE) initiative [3].
different ways to publish their measured data in the Sensor Web However, there have been some unsolved issues with
to make time series of this data accessible by means of the World transferring the data from the WGSNs to the Sensor Web
Wide Web (WWW). In earlier papers, we proposed the use of servers since WGSNs are often not able to handle HTTP
GeoMQTT, a spatiotemporal extension to the widely known and requests. The authors of [4] suggest an intermediary layer, the
used “Internet-of-Things” (IoT) protocol Message Queue and so-called Sensor Bus, to bypass this gap. We took this idea
Telemetry Transport (MQTT). In this paper, we propose a and implemented it using an extension of the lightweight
GeoMQTT – Representational State Transfer (REST) bridge to Message Queue and Telemetry Transport (MQTT) protocol,
enable users to easily interact with GeoMQTT by using standard
which we call GeoMQTT [5]. A short introduction to MQTT
HTTP methods. We demonstrate that using such a bridge is
and GeoMQTT is given in the next two sections.
especially useful for debugging events issued by sensors nodes
using GeoMQTT as a communication protocol. GeoMQTT, like MQTT, is a machine-to-machine (M2M)
protocol and, therefore, is tailored to requirements of
Keywords— Sensor Web; IoT; GeoMQTT; REST; machines. Users, on the other hand, need simpler methods to
spatiotemporal pub/sub interact with machines. The standards of the Sensor Web are
one way to achieve this, but it only holds for sensor data.
I. INTRODUCTION Having a more general access point to the GeoMQTT bus
would be a huge benefit, especially for developers. Therefore,
Monitoring environmental phenomena and events in we propose an architecture built upon the Representational
geoscience has changed dramatically over the last decade State Transfer (REST) principle, which bridges GeoMQTT
since new technological trends improve the capabilities of and REST. It is presented in section 4 and 5 of this paper.
sensors and sensor platforms. According to [1], there have Last, we give a conclusion and an outlook for future
been three major drivers for this development. First, improvements.
ubiquitous communication networks have evolved to facilitate
access and measuring in remote and inaccessible areas without
wires. Furthermore, the miniaturization of computing II. MESSAGE QUEUE AND TELEMETRY TRANSPORT
platforms and, hence, the optimization of power consumption (MQTT)
enables sensor platforms to run over a significant extended The MQTT protocol is a very lightweight protocol often
period of time. Lastly, the sensors and sensor materials used in the Internet of Things and Service (IoTS). It is
themselves have improved to size-reduced and micro-scale especially suitable for constrained devices as well as low-
sensors. bandwidth, high-latency and unreliable networks. The
Wireless geo sensor networks (WGSN) are one protocol implements the so-called publish/subscribe
manifestation of these technological trends. Being still in an interaction scheme, which is an event-based communication
early adoption phase, they shift traditional centralized sensor model between publishers that produce certain information
platforms into lightweight, portable and intelligent systems on and subscribers that register to these information. The term
a microscale. Distributed sensors and sensor nodes in such event is used for the act of publishing information whilst
networks are able to monitor an extensive geographical area notification denotes the act of delivery to the consumer [6]. A
with minimal efforts and costs but deliver point-based data in broker distributes the events according to the interests of
near real-time. subscribers.
On the other hand, WGSNs should not be an isolated MQTT uses a topic-based publish/subscribe scheme [7] for
system. The captured sensor data should be accessible by addressing. Events or publish messages are tagged with a topic
means of existing methods of the World Wide Web and name, which is an arbitrary string. It can be hierarchically
preferably in a standardized way. This paradigm is called the structured with the topic level separator, a forward slash. For
“Sensor Web”. Its goal is to hide “the underlying layers from instance, a temperature sensor node tags an MQTT message
the applications built on top of it” [2]. Standards for accessing with the topic name room/237/temperature and publishes the
sensor data over Hyper Text Transport Protocol (HTTP) have room temperature in the payload of the message. Subscribers
already been developed by the Open Geospatial Consortium are able to express their interests in events with a topic filter,
which is also an arbitrary string and has a similar shape like between 2016-03-28T11:15:00Z and 2016-03-28T13:45:00Z.
the topic name. In addition, a single-level wildcard “+” or a In addition to the ISO standard, we add support for cron
multi-level wildcard “#” can be used to register to a set of expressions to specify the start timestamp of a period. The
topics. For example, if a subscriber is interested in the syntax adheres to the cron expression defined in the Quartz
temperature measurements of all rooms, he could use the Job Scheduler [10]. The spatial filter is used to filter the
single-level wildcard in the topic filter room/+/temperature. events with respect to the tagged geometry in the GeoPublish
For all rooms and all possible observation properties, he could message. Similar to the GeoPublish message, the geometry is
use the multi-level wildcard with the topic filter room/#. specified using common description languages such as WKT
or GeoJSON. The evaluation of the spatial filter in the broker
The MQTT Version 3.1.1 offers some core features, such currently uses a simple “covers” relation. To enhance the
as a Quality of Service (QoS) mechanism, to guarantee the spatial filter, there are plans that will enable subscribers to
delivery of a message or the Last Will and Testament (LWT) specify the Spatial Reference System (SRS) using an EPSG
mechanism to notify clients about an “ungracefully” code as well as their preferred spatial relation.
disconnected client. These features are especially useful in
unreliable networks. Conflicts may occur between GeoMQTT and MQTT
messages. For instance, a client is subscribed to an MQTT
MQTT is based on TCP/IP, but with the extension MQTT topic filter and a GeoPublish message is issued whose topic
for Sensor Networks (MQTT-SN), it also supports name matches the filter. Since the subscription only contains a
connectionless communication protocols like UDP or ZigBee topic filter, but has neither a temporal nor a spatial filter, it
[8]. As the name suggests, the extension is especially useful in raises the question whether to forward the message or not. We
wireless sensor networks (WSN) since it is optimized for tiny implemented a conflict handling strategy, which is also
battery-operated Sensor/Actuator devices and considers compatible to MQTT clients that do not support the extension
constraints of WSNs such as high link failure or short message [4]. For example, in the conflict mentioned, the temporal and
payload. MQTT-SN adds two new components to an MQTT spatial information in the GeoPublish message are ignored. If
network: the MQTT-SN client and a gateway, which acts like the topic filter of the MQTT subscription matches the topic
a translator between the two protocols. name, the message is converted into an MQTT publish
message discarding the additional information.
III. GEOMQTT Since we deal with WGSNs that use ZigBee, we also
We extended MQTT with new message types to support implemented a GeoMQTT-SN version to bridge the sensor
spatiotemporal tagging and filtering of events [5]. Therefore, nodes with the GeoMQTT broker. We added different
the extension is called GeoMQTT. It is still a message types, which are translated to GeoMQTT messages in
publish/subscribe interaction scheme although not solely the gateway of the WSN. As shown in Figure 1, we use the
topic-based, but also timestamp and geometry-based. The GeoMQTT-SN protocol in the project EarlyDike to monitor
topic mechanism, however, is inherited from ordinary MQTT dikes with sensors. Like MQTT, it is also useful in WGSN
as described in Section 2. environments due to its lightweight nature, but adds support
for the definition of sampling time and sampling
The introduced GeoPublish message, which can be used location/geometry in the header of the GeoPublish message.
by producers to generate a spatiotemporal event, is tagged
with a timestamp and geometry in addition to the topic name.
The format of the timestamp can either be expressed in IV. BRIDGING GEOMQTT AND REST
ISO8061 syntax or in UNIX time, which is the number of By adding a REST interface to GeoMQTT, two different
seconds that have elapsed since January 1, 1970 (midnight semantic models of communication are bridged, the
UTC/GMT). The geometry can be specified in different publish/subscribe interaction scheme of MQTT and the
common description languages for geometries such as Well- request/response pattern of HTTP. According to [11, 12], it is
known Text (WKT) or GeoJSON. Like the MQTT publish useful to couple the REST-oriented web architecture and the
message, a GeoPublish message also consists of a payload, real-time properties of MQTT to close the gap between
which can be arbitrary. machines and developers in the IoTS. They implement a so-
The geo subscription mechanism uses a temporal filter called QEST broker to expose MQTT topics as REST
and/or a spatial filter in addition to the topic filter inherited resources and vice versa. For instance, the REST resource
from the ordinary MQTT subscription. The broker forwards /topics/room/237/temperature corresponds to the topic
the published events only if the subscription meets all room/237/temperature. By requesting the resource with an
specified filters. HTTP GET, the response consists of the latest published value
issued with the topic. Similarly, an HTTP PUT request at
The syntax of the temporal filter adheres to the ISO8601 /topics/room/237/temperature publishes the value of the
intervals and repeating intervals standard defined in [9]. For request body with the corresponding topic.
instance, a time interval can be specified with 2016-03-
28T11:15:00Z/PT2H30M, which subscribes to events issued
Fig. 1. GeoMQTT-SN architecture and layer stack
We follow a similar approach in the implementation of our In GeoMQTT, the topic is handled similarly to the MQTT
REST bridge. Unlike [11], we do not integrate the REST case (resource /geopublish/temperature is mapped to topic
interface directly in our GeoMQTT broker, but use an temperature). The HTTP GET request has four optional
observer client, which subscribes to all messages/events. parameters: from, to, geometry and size like before. from and
Additionally, we use the bridge as a message logger. It does to are used to specify a time interval whilst geometry expects a
not solely store the latest value on a specific topic, but all geometry in WKT format. All OGC Simple Feature Access
messages that are received. The REST-GeoMQTT bridge is geometries are supported and extended by a BBOX and
shown in Figure 2. BUFFER format. If not specified, the temporal filter and
geometry filter are set to wildcards. The bridge queries the
MongoDB database with the temporal, geometry and topic
filters and returns a GeoJSON FeatureCollection of the logged
published messages. Hereby, the geometry filter is evaluated
with a “within” relation in respect to the geometries of the
GeoPublish messages stored in the database. The HTTP PUT
request for the GeoMQTT endpoint expects two required
parameters in addition to the corresponding wildcard-free
topic name as the resource: the time parameter as an ISO8601
timestamp and the geometry parameter in WKT syntax.
Similar to the MQTT case, the request body and the
Fig. 2. GeoMQTT - REST bridge parameters form a GeoPublish message, which is sent to the
GeoMQTT broker.
In addition, we implemented HTTP DELETE for the two
endpoints to manage the database. It deletes the matching
As mentioned above, the observer & logger client entities in the database and returns them as a JSON/GeoJSON
subscribes to all MQTT and GeoMQTT messages at the document. The request parameters are the same as for the
broker. It logs the publish and GeoPublish messages received HTTP GET requests except for the size parameter.
in separate collections in a MongoDB database. The bridge
As mentioned previously, since HTTP uses a
has two different REST endpoints: one for MQTT and one for
request/response mechanism, it cannot fully support a
GeoMQTT.
publish/subscribe mechanism. WebSockets could be one
For MQTT, the REST resources are mapped to topics possible solution to solve this issue [13]. In fact, we already
according to the approach in [7] (for instance, the resource implemented a GeoMQTT client with WebSockets. But [11]
/publish/room/237/temperature is mapped to the topic argues that WebSockets do not implement the concept of URI
room/237/temperature). In an HTTP GET request, it is also after opening the communication and, therefore, do not
possible to use the single-level wildcard “+” or the URL- support the pure REST approach (resource-topic mapping).
encoded multi-level wildcard “#” of topic filters. The bridge They enhanced the implementation by a Long-Polling
queries the MongoDB database for logged publish messages approach for retrieving real-time updates in the browser
and responses with a list of messages in JSON format. Setting without using WebSockets. So far, we have not implemented
the optional URL parameter size to 1 allows the users to this solution, but it might be of interest in the future.
retrieve only the latest published message that matches the
topic filter. Accordingly, with the HTTP PUT request of a
resource, the request body is published to the corresponding
topic name to the GeoMQTT broker. Wildcards are not
allowed in the resource since they are prohibited in topic
names in MQTT publish messages.
V. APPLICATION VI. CONCLUSION AND FUTURE WORK
1
The REST bridge is used in the EarlyDike project to log Bridging the publish/subscribe protocol GeoMQTT and a
and easily obtain events published by sensor nodes, which are HTTP based REST interface is beneficial to provide an easy
deployed at dike lines to monitor the structure of sea dikes. access point to the GeoMQTT bus without any further
We set up a Web map application to request the events and software. By using simple HTTP methods such as GET and
plot them in a map. Since the response of the service is a PUT, it is convenient especially for developers to retrieve
FeatureCollection of events in GeoJSON format, it is quite events or publish messages to the GeoMQTT broker. Since we
easy to plot the events, for example, in a Leaflet 2 map also added logging capabilities to the bridge, users are able to
container (see Figure 3). The corresponding REST request for retrieve, not only the latest event issued, but also a history of
the requested data in the application in Figure 3 is the events.
following.
REST, however, is based on HTTP requests/responses.
Therefore, it lacks in retrieving real-time data through push
notifications like in the publish/subscribe interaction scheme
of GeoMQTT. One solution to solve this issue is the use of
http://localhost:8080/rest/geopublish/node/+/temperature? WebSockets. This would require additional libraries and does
geometry=LINESTRING(8.589248657226562 not support the concept of URI. As mentioned previously, a
54.517893120052946,8.590707778930664, …) Long-Polling RESTful approach could be used to tackle this
issue in the future.
In combination with the Sensor Bus concept for closing the
The REST endpoint here is /rest/geopublish. The requested gap between WGSNs and high-level SWE services, the
resource corresponds to all stored messages that match the GeoMQTT-REST bridge is a powerful tool. It enables
topic filter node/+/temperature, where the "+" wildcard is developers of such architectures to log and retrieve events
used to replace the sensor node id and, therefore, retrieve all which are issued from the sensor nodes, but also send
measured temperatures of every available sensor node. messages to the bus. However, the bridge does not replace the
Additionally, the stored messages are filtered by the specified services for storing sensor data in the Sensor Web, such as the
geometry, a LINESTRING which represents the southwestern Sensor Observation Service (SOS). Due to the semi-structured
first order dike line of the German North Sea island Pellworm nature of the underlying document database MongoDB, it can
(compare the purplish polyline in the map in Figure 3). The be used for logging the raw events of a GeoMQTT system or
temporal filter is not specified and thus set to a wildcard. for debugging purposes.
The bridge and application do not represent a substitution
for SWE data storage services such as the Sensor Observation
Service (SOS). We use it mainly for fast debugging of our
sensor networks or to send configuration messages to the
sensor nodes.
Fig. 3: Web map application to request GeoMQTT events using the REST
bridge
1
https://www.earlydike.de/
2
http://leafletjs.com/
REFERENCES [7] MQTT Version 3.1.1, OASIS Standard, 2014.
[8] A. Stanford-Clark and H. L. Truong “MQTT for Sensor Networks
[1] S. Nittel, “A Survey of Geosensor Networks: Advances in Dynamic (MQTT-SN) Protocol Specification Version 1.2,” IBM Zurich Res. Lab.,
Environmental Monitoring,” Sensors, vol. 9, no. 7, pp. 5664-5678, July Zurich, Nov. 2012.
2009.
[9] Representations of dates and times, ISO 8601:2004, 2004.
[2] A. Broering et al., “New Generation Sensor Web Enablement,” Sensors,
vol. 11, no. 3, pp. 2652-2699, March 2011. [10] Terracotta Inc. (2016). Quartz CronTrigger Tutorial [Online].
Available: http://www.quartz-scheduler.org/documentation/quartz-
[3] M. Grothe and J. Kooijman, Sensor Web Enablement. Delft, NL:NCG, 2.x/tutorials/crontrigger.html
2008.
[11] M. Collina, G. E. Corazza and A. Vanelli-Coralli “Introducing the QEST
[4] A. Broering, T. Foerster, S. Jirka and C. Priess, “Sensor Bus: An broker: scaling the IoT by bridging MQTT and REST,” in IEEE 23rd
Intermediary Layer for Linking Geosensors and the Sensor Web,” Proc. International Symposium on Personal Indoor and Mobile Radio
COM.Geo 2010, 1st Int. Conf. on Computing for Geospatial Research Communications (PIMRC), Sydney, Australia, 2012, pp. 36-41.
and Applications, Washington DC, 2010, p.1-8.
[12] M. Koster (2013, Oct. 4) M2M Protocol Interoperability Using the
[5] S. Herle and J. Blankenbach, “GeoPipes using GeoMQTT” in Smart Object API. Data Models for the Internet of Things. Available:
Geospatial Data in a Changing World. Selected papers of the 19th http://iot-datamodels.blogspot.de/2013/10/m2m-protocol-
AGILE Conference on Geographic Information Science, T. Sarjakoski, interoperability-using.html
M. Santos and T. Sarjakoski, Ed. Springer International Publishing
Switzerland, 2016, pp. 383-398. [13] The WebSocket Protocol, IETF Standard RFC 6455, 2011.
[6] P. Eugster, A. Felber, R. Guerraoui and A.-M. Kermarrec “The many
faces of publish/subscribe,” ACM Computing Surveys, vol. 35, no. 2, pp.
114–131, June 2003.