## 2 State of the Art
### Overview of IoT Simulators
#### 2.1.3 MAMotH  
While the majority of related work thus far focused on simulation, in [15], [PERSON], [PERSON], [PERSON] and [PERSON] instead aimed to emulate massive scale Internet of Things scenarios. The reason for their focus on emulation instead of simulation is justified by the lack of simplification, which simulation scenarios resort to, and the fact that the correct timing ensured by network simulators may leave problems of message timing uncovered. First, they did a survey of 15 different Internet of Things simulators and emulators NS2 [16], NS3 [17], PDNS [18], GTNetS [19], J-Sim [20], Jist [21], COOJA [22], TOSSIM [23], DSSimulator [24], GIOoSIM [25], OMNeT++ [26], SensorSIM [27], SENSE [28], EMULAB [29] and ATEMU [30]. According to the authors, the survey showed that, at that time, current solutions were mostly appropriate for small- and medium-scale emulation of Internet of Things scenarios but not feasible for large-scale testing with millions of nodes. Again, the scalability seemed to be the main problem for the evaluated simulators and emulators. As a solution, they proposed MAMMotH (A massive-scale emulation platform for internet of things), a large-scale IoT emulator. Their goal was to emulate tens of thousands of nodes in a single VM, with a future goal of up to 20 million nodes. In addition, it was aimed to achieve nearly linear scalability with this emulator approach. The architecture of this approach presumed three scenarios: mobile devices connected by GPRS in a star topology to a base station, a wireless sensor network connected by GPRS to a base station, and a number of constrained devices connected to proxies, which in turn are connected to a backend.  
To achieve link emulation, the authors figured out that traffic between nodes on either a proxy or a base station had to fit either GPRS or 802.15.4 profile. To simulate TCP or UDP traffic, the planned to reuse models from NS2 coupled with a _netfilter_-type traffic scheduler. Gateway emulation should be achieved by either using EMULAB or using a Linux Virtual Machine with OpenWRT ([[https://openwrt.org/](https://openwrt.org/)]([https://openwrt.org/](https://openwrt.org/))). Lastly, node emulation was achieved by using existing software, that supports the Constrained Application Protocol (CoAP) ([[http://tools.ietf.org/html/draft-ietf-core-coap](http://tools.ietf.org/html/draft-ietf-core-coap)]([http://tools.ietf.org/html/draft-ietf-core-coap](http://tools.ietf.org/html/draft-ietf-core-coap))). They used a proprietary Java-based node emulator together with libcoap ([[http://sourceforge.net/projects/libcoap/](http://sourceforge.net/projects/libcoap/)]([http://sourceforge.net/projects/libcoap/](http://sourceforge.net/projects/libcoap/))), which had to be modified to use instances of threads to circumvent the kernel limit for number of processes. This way, they realized 10,000 nodes per VM and were only limited by the maximum number of threads allowed per kernel and free UDP ports. As a possible drawback of their proposed approach for MAMMotH, the authors stated the huge amount of data which the emulator would produce.