## 4 Experiments and Results
### Implementation and Set-Up  
Nowadays, there are many commercial solutions which allow the deployment of IoT devices. For instance, Amazon Web Services IoT Core (AWS IoT Core) [48] and The Things Network [49] offer proprietary platforms which include mechanisms for communications, authentication, and authorization in IoT scenarios. These solutions propose the integration of all these services in a single platform, which limits the interoperability with other systems. Regarding the most used MQTT broker implementations, we can cite HiveMQ [50] and Mosquitto [51]. The first one offers native authentication, authorization, and permissions services, such as X.509 client certificate authentication, username and password authentication and authorization, client ID authentication and authorization, and IP-based authentication and authorization. On the other hand, Mosquitto integrates a username and password authentication scheme, and allows developers to implement third-party authorization plugins, which allow a high degree of customization.  
This prototype implementation has focused on the input and output messages generated by an IoT device, giving that is the most constrained element in the system.  
All the entities defined in Section 3.1 have been developed separately and deployed using Web Servers (cloud AWS servers), Arduino devices, and NodeMCU v1.0 boards [52]. This prototype intends to represent an IoT environment.  
The implementation of each entity is described below:  
* Resource Server Broker: Is composed of two internally connected servers. The MQTT functionalities are provided by a deployed Mosquitto broker. Mosquitto allows the creation and utilization of plug-ins for authorization customization. We have chosen the mosquito_pyavath plug-in which allows the creation of Python scripts to modify the Mosquitto authorization scheme. The HTTP API used to connect the Resource Server with the client, the Protection module used to connect the Resource Server with the Authorization Server, and the topic management interface have been developed in a single server.
* Authorization Server: Is a Web Server written in Python. The implementation includes UMA APIs, a user interface for control and policy definition, and an OAuth API.
* Client: Is a web application that provides a user interface for the configuration of IoT devices and allows communication with the Resource Server HTTP API and the Authorization Server's Authorization API.
* IoT devices: Are deployed in the NodeMCU v1.0 board using a MQTT library for Arduino. This development board is based on Wi-Fi MCU ESP8266.
* Measuring Device: Is composed of an Adafruit INA219 [53] High Side DC Current Sensor Breakout board to measure the energy consumption and an Arduino Uno R3 board with a Arduino Ethernet Shield to collect data.  
The entities described in Section 4.1 have been deployed in the following way:  
* Resource Server Broker and Authorization Server: Both are deployed in a cloud environment. Specifically, we have chosen AWS as the cloud provider. We created two EC2 t2.micro (1 vCPUs, 2.5 GHz, Intel Xeon Family, 1 GiB memory) machines deployed in the EU-West 1 area and configured in the same subnet. The machines run Ubuntu Server 14.04 as the operative system.
* Client: Has been deployed in a local server with Internet access.  
* IoT Device: Has an active Wi-Fi interface and has Internet access.
* Measuring Device: Collects and stores the energy consumption measurements and return this information in a local server.