# Difficulties and Challenges of Anomaly Detection in Smart Cities: A Laboratory Analysis
## 3 Simulation Environment  
To design the simulation environment created to perform our tests, we have replicated in the lab a standard area of a smart city. To this end, we have emulated certain characteristics that make the smart city a very complex scenario, especially regarding WSN security. The main features of this simulation environment are:  
* It is highly heterogeneous, which means it includes:
* Different protocols (i.e., ZigBee, 6 LoWPAN, WiFi). * Different hardware (i.e., Z1, Waspmotes). * Different sensor configurations (i.e., battery or grid powered, nodes with different computational limits, low/high transmit power). * Different network topologies (i.e., star, mesh). * Different routing path to the smart city servers (i.e., direct routing to the city servers, indirect routing through a third party server). * Different types of sensors (i.e., electrical measurements, environmental). * It has different components physically sharing an area. Regarding security, this is relevant because an attack affecting an area can affect several nodes from different networks. * It has different WSNs sharing the radioelectric space. Here, an attack affecting a particular frequency band can disrupt communication in several networks. * It has different WSNs sharing a single gateway. An attack aiming at the gateway can cause packet loss of distant nodes from different networks. Figure 1 shows a technical representation of the simulation environment and Table 1 describes in more detail the most relevant characteristics of the included networks. As the figure shows, the WSNs  
send data (i.e., sensor readings and network status data) from the sensors to the gateway. The gateway, in turn, re-sends the data through the Internet to a server in the lab, where the data are stored in a data warehouse. On a large scale, this server would be the equivalent to the central servers of the smart city. It is worth noting that the sensor networks are configured either in a star topology or in a mesh topology, which are the most common topologies in smart cities. The networks configured in a star topology use, on the one hand, a point-to-point TCP socket connection over WiFi between each sensor node and the gateway in the RPI network. On the other hand, in the Libelium network, the ZigBee protocol coordinates an adequate transmission between all the nodes and the gateway [45]. In both cases, the gateway network address has been manually configured in the sensor nodes. The network configured in a mesh topology, i.e., the Zolertia network, uses 6 LoWPAN to enable multihop capabilities, implementing UDP in the transport layer and IPv6 in the network layer with RPL (Routing Protocol for Low power and Lossy Networks) [46]. In order to force sensors nodes to communicate using multiple hops in a reduced scenario, such as the laboratory, the transmission power of the nodes in this network has been set particularly low. In order to add more realism to the executed simulations, the sending patterns of the nodes and the content of the sensor readings have been set up cloning the behavior of real sensors from the smart city of Barcelona (excluding the SCK, which reads actual environmental data from the lab). Nodes have also been configured to send network status data gathered by the sensors. Moreover, in order to collect a larger volume of data, simulation speed has been triplicated. This means that one week of simulation data corresponds to three weeks of actual city data.