The Internet of Things (IoT) comprises sensors and actuators that are heterogeneous with different operating (e.g., operating platforms) and hardware (e.g., sensor chip types) characteristics, hosted on diverse IoT devices (e.g., mobile phones, vehicles, clothing, etc.). Such devices are deployed in a variety of application domains, such as smart cities, smart factories, resource management, intelligent transportation and healthcare to name a few (see Fig. below). To support their deployment, major tech industry actors have introduced their own data exchange APIs and protocols, which deal with: (i) the limited hardware (e.g., energy, memory) and network resources (e.g., low bandwidth); and (ii) mobile interactions.

The resulting APIs and protocols are highly heterogeneous. In particular, protocols differ significantly in terms of interaction (see Fig. below) paradigms and data formats. For instance, protocols such as CoAP relying on Client/Server interactions, MQTT and WebSocket based on the Publish/Subscribe and Data Streaming interaction paradigms, respectively, are among the most widely employed ones in IoT applications. Additionally, IoT devices can be mobile which results to an intermittent connected behavior due to networking constraints or voluntary disconnections. To support the deployment of such devices, the publish/subscribe paradigm is often employed, as it decouples mobile devices in both time and space — i.e., devices interact via an intermediate broker entity.

Building an IoT application over a publish/subscribe infrastructure, requires the selection of an appropriate protocol (e.g., MQTT). Such a protocol enables peers to access the broker and push/receive events. Additionally, to create the pub/sub broker overlay, it is essential to select the corresponding message broker implementation (e.g., ActiveMQ, VerneMQ, HiveMQ, etc). Every message broker has different capabilities (see Fig. below) , such as: compatibility with different protocols version by the mean of a bridge functionality, support for clustering (i.e., forming a broker network), provision of performance features(dynamic topics), security mechanisms(Authentification, SSL), etc. Finally, an important design-time decision is the deployment of each broker entity to an appropriate machine. A common tactic of pub/sub developers is to deploy brokers in the cloud.

As we head into the future, the number of IoT devices is certain to increase without bound. However, as this count rises, so will the number of protocols employed by these devices or message brokers used to push/pull data. This in turn introduces newfound diversity and fragmentation in IoT systems, directing a need for solutions such as mediators (i.e. connector wrappers or mediating adapters — e.g., CoAP to MQTT) to enable interoperability. However, these solutions rely on software components that introduce additional overhead, and so the physical placement of these mediators becomes an issue as well. This problem is further worsened by the fact that composed mediators often ignore the associated performance costs of their usage, opting to just solve this interoperability problem. Motivations for finding a better placement of these mediators comes from a use case scenario where time is a critical resource, like in a fire. In these types of scenarios, every seconds counts, and could be the difference between saving a life and losing one.

In the MiMove team, we mainly build IoT scenarios as part of smart city applications and often we have to deal with the aforementioned challenges. For instance an IoT Fire detection system in the forest (see Fig. below), it is well known there could be a large increase in temperature from the normal temperature whenever forest fire occurs. This can be detected, monitored continuously by using temperature/smokes sensors and in accordance with the simple arrangement of transmitters. This concept is quite reliable and cost-effective in detecting of forest fire since simple equipments are arranged in a simple configuration and also GPS is used in the scenario to get the location of the forest fire in order to send drone for pre-rescue activities. Such scenario requires the following services, sensors and devices:

Temperature or smoke sensors: these can be deployed inside a forest in order to monitor the forest conditions and push warning notifications. In the context, we deploy these sensors into a Raspberry Pi and we employ the CoAP protocol to push notifications.

Estimator service: it can be deployed inside a fire department for receiving forest-related notifications. We assume that the estimator service employs the HTTP protocol to receive notifications.

Drone: a PARROT AR DRONE 2.0 located at the fire department – used to inspect the forest-area upon a warning notification. Such a device deploys specific protocols to: i) accept pilot-commands through the UDP protocol and ii) transmit video stream, location and drone speed to an MQTT broker.

Drone handler: a device handling the drone, This device employs the HTTP protocol to receive commands from the estimator service and locate the corresponding drone into the forest.

Media streaming devices: such devices receive video streaming data by the Drone and employs WebSocket protocol.

To facilitate the development of similar scenarios with the above, we aim to introduce zefxis**, a solution for the automated synthesis of mediators that support the interconnection of heterogeneous IoT devices. Since there are multiple protocols and APIs and we do not foreseen a dominant API/protocol in the IoT, we will rely on our previous experience to build software abstractions and metamodels for representing IoT interaction paradigms. The resulting mediators with enable the interconnection between devices employing different protocols (e.g., CoAP to MQTT). With such mediators, will be able the interconnection of not only different heterogeneous devices, but also devices to any message broker since they already support data exchange protocols to receive/push data (e.g., MQTT). This is highly useful, as many IoT applications are built over message brokers by using mainly the MQTT protocol. However, this enforces developers either to use only MQTT as main protocol, or to develop manually protocol wrappers (mediators in our case).  

While providing mediators is very important (especially for exchanging data with brokers), it is very important to provide a solution for their placement. The particular problem we aim to focus lies in where and how mediators should be placed: the cloud, edge or fog, and on which physical device, respectively. In the search for a solution to this where and how problem, we will examine the heuristics offered by a closely related problem, the operator placement problem, and run experiments after reducing these heuristics for our use.

** ‘ζεύξη’ or rather ‘ζεύξις’ in ancient Greek means connection or coupling.