# IoT Middleware Platforms for Smart Energy Systems: An Empirical Expert Survey
## 2 Background
### IoT Platform Definition and Architecture  
In the community, there is an ongoing discussion about the fundamental building blocks, layers and concepts in architecture of the IoT [26]. For instance, [PERSON] et al. [42] and [PERSON] et al. [3] identify the three most relevant layers in IoT architecture as: users or applications; IoT platform; and devices and infrastructure. [PERSON] et al. [43] and [PERSON] [44] define them as: perception, network and service. [PERSON] [45] presents the IoT as four layers: smart device/sensor, gateways and networks, management service and application. According to the International Telecommunication Union, each IoT architecture should be divided into five layers: sensing, accessing, networking, middleware and application [46]. Another five-layer model, proposed by [PERSON] et al. [47] consists of business, application, middleware, network and perception layers. Figure 1 illustrates the three architectures (three-layer, four-layer and five-layer architectures), their layers and their services. More advanced models, such as cloud and fog-based architectures [48] or the communication-centric IoT reference model [49], and various six- or seven-layer models, can also be found in the literature. In this paper, we use a five-layer approach, derived from the model in [47]. It proposes a simple separation of layers based on their functionalities and can be described as follows:  
1. _Business Layer_: It offers a management and control of the IoT platform functions, including data analysis, (e.g., using Apache Spark [50] in case of dealing with big data) to help in the process of the decision-making by the responsible people. 2. _User/Application Layer_: It is responsible for delivering and presenting the application-specific service to the end user. It defines a wide range of applications where the IoT platforms can be used, such as smart services applications. 3. _Middleware Layer_: The concept of linking billions of individual devices and getting them to communicate with each other means that IoT systems are already inherently characterized by a high degree of heterogeneity [3]. The large number of different communication protocols, interfaces and platforms lead to heterogeneous IoT networks, which complicate the interaction. The task of middleware here is to function as a mediator between the devices by integrating the received data from the physical environment to the IoT-connected devices, networks and servers. This integration process also includes all the necessary operations, such as storing, analyzing and processing the data, allowing the connectivity between different and complex programs, which were not originally designed to provide this feature. Various protocols are used to provide the communication and services to the application in this layer. These protocols correspond to the application layer protocols in OSI model [51], such as: * The Hypertext Transfer Protocol (HTTP) [52]: This has been the foundation for data communication for the World Wide Web (i.e., Internet) since 1990 [53]. HTTP is a Transmission Control Protocol (TCP)/Internet Protocol (IP)-based, application-level protocol for distributed, collaborative hypermedia information systems. It is used to deliver data (HTML files, image files, query results, etc.) on the Internet, supporting both request/response and client/server interaction modes. * The Constrained Application Protocol (CoAP) [54]: An upgraded version of HTTP, designed for the resource constrained applications such as IoT, wireless sensor networks (WSNs) and machine to machine (M2M) communication. One reason for the CoAP's reduced complexity is the use of User Diagram Protocol (UDP) instead of TCP in HTTP, with acknowledgment messages in order to introduce a reliable communication based on a request/response interaction. * Message Queuing Telemetry Transport (MQTT) [55]: A protocol that enables a publish/subscribe messaging communication mode in a lightweight way. It is useful for connections with remote locations, where the bandwidth is limited.