It was great to learn that Amazon IoT uses MQTT as network / transport layer. The more interesting is the move towards REST (which is HTTP) to address semantic issues with IoT systems:
AWS IoT, MQTT and many other network interoperability standards (LWM2M, CoAP, etc.) enable message interchange. However, IoT network interoperability doesn’t enable the systems that are exchanging messages to interpret those messages. To realize the many-to-many system-of-systems vision, IoT applications need to implement standard ways of communicating sensor locations, sensor and data parameters, and sensor instruction sets. This is what the OGC SensorThings API provides.It is understandable from the point of view, that OGC OWS is in general intrinsically interwoven with HTTP semantics and the application of SWE in the IoT context is desirable, well, even crucial.
However, MQTT stems from the constraints of low bandwidth, low energy consumption and unreliable connectivity, and implements a robust, small footprint asynchronous messaging platform. Earlier this we have developed a prototype system, that aims to add SWE semantics into MQTT messaging. We keep the specialisation of MQTT, where for example connections can be resumed which under SSL/TLS security can be a significant power saver. MQTT would also better address the "addressability" of distributed "things" which might be isolated behind IP NAT or run with dynamically assigned addresses, because in MQTT context the "things" would subscribe to SPS management topics and therefore higher order SDI services don't need to direct data queries or task requests to an address but place it on the queue with respective topics.
For an agricultural research project we distributed monitoring stations as a wireless sensor network throughout the catchment to deliver frequent measurements in near-realtime, which mimics OGC SOS.
A dynamic implementation of measurement frequencies, adapted to certain environmental conditions like heavy rainfall events require re-tasking of the nodes, which mimics OGC SPS. Within this paper we provide a framework where a threshold event triggers a reconfiguration task for a phosphorus measurement device, using asynchronous, push-based communication, on an MQTT queue, which links the ground stations with a cloud-based control system. OGC WPS algorithms continuously analyse incoming SOS measurements commits such a request into the wireless sensor network, and updates the measurement frequency of the target nodes to enable nutrient peak flow estimation during storm events.
This on-going work is based on original thoughts on the interlinking of OGC SWE semantics for sensor descriptions and observations (OGC Sensor Observation Service, SOS), sensor configuration and planning (OGC Sensor Planning Service, SPS) with the open Message Queue Telemetry Transport (MQTT) protocol.
MQTT is a simple, yet very performing and robust publish/subscribe message passing system, which can also serve for event brokering as described in the SWE Service Model. Actual addressing and data transmission is done by a topic string and an arbitrary payload. The topic string and the payload need to reflect the necessary standard semantics to be mapped back and forth to allow for a seamless, and preferably lossless bi-directional multi-lateral communication between the WSN as data provider (SOS), web clients as data consumers (SOS) and the management system, which interacts with the WSN in a standardised way, too (SOS and SPS).
