## 4 Architecture and Implementation
### IoT Infrastructure  
The IoT infrastructure supports a population of wireless nodes deployed in a smart city environment, capable of sensing several parameters depending on the maintenance procedures. A backbone city network of any type is used for central data transport. Furthermore, a wireless infrastructure is available to provide the smartphones of the citizens and maintenance workers with network access through several access points (WiFi APs or base stations) scattered throughout the city. Finally, sensing nodes are placed in several infrastructure elements, such as lamp posts, traffic lights or electrical panels. These sensors collect information on parameters such as power consumption or performance metrics. When arranged in local clusters, sensing nodes form local mesh networks in order to communicate directly with each other. In this scheme, at least one of the nodes in each mesh area acts as a border router (BR) to communicate the group with the wired backbone and hence with the central servers and the cloud. Figure 8 summarizes this architecture model. Each node uses 6 LoWPAN and IPv6 protocols to communicate with other devices. This choice is coherent with the fact that sensor nodes may be battery powered and have limited computation resources. Figure 8: Architecture model of the IoT infrastructure. Low power technologies, such as 6 LoWPAN, can be applied to network data transfers while maintaining a high degree of flexibility, scalability and energy efficiency. We chose to use the Contiki operating system [32] for the nodes, as it is specially designed for constrained devices and includes many _de facto_ IoT communication standards  
Sensor measurements are not expected to use more than 80-byte messages, and the transmission frequency of the nodes is expected to be low, so high data rates are not necessary. We therefore used an IEEE802.15.4 [33, 34] wireless radio for mesh area communications. Adjacent areas use different radio channels to avoid interference. Moreover, all areas are supposed to have their own PAN ID, so that they are mutually independent. The network layer employs the 6 LoWPAN protocol [35]. This allows each node to have its own IPv6 address and to be directly accessed from any other node or device implementing the IPv6 protocol. The BRs located in each of the defined mesh zones are responsible for routing information from their respective mesh networks to the backbone and for ensuring adaptation between the 6 LoWPAN protocol and the standard IPv6 protocol. They maintain route tables for their networks and are also in charge of 6 LoWPAN header compression and decompression for messages sent through their interfaces between the 6 LoWPAN network and the backbone. The routing protocol of the 6 LoWPAN network is the RPL [36] distance vector routing protocol. It builds routes to communicate with nodes within the same mesh area. RPL was chosen for its efficient memory usage and low control traffic relative to other options, such as link state routing protocols. In Figure 9, the border router acts as the root node of the destination-oriented directed acyclic graph (DODAG) built by the routing protocol. The objective function used to build the DODAG is the minimum rank with hysteresis objective function (MRHOF), which uses the estimated transmission count (ETX) as the default metric. This metric estimates the number of transmissions until a message reaches its destination and builds the graph accordingly. When possible, redundant paths are established to avoid node isolation. Figure 9: Architecture model of the IoT infrastructure. Detail of mesh area network. The CoAP protocol [37] was chosen for the application layer, using UDP as the transport protocol (Figure 10). This protocol allows the implementation of REST interfaces over constrained networks formed by nodes with limited resources. Thus, each node can be accessed and its resources modified using CRUD (create, read, update and delete) methods.