Dockemu: Extension of a Scalable Network Simulation Framework

based on Docker and NS3 to Cover IoT Scenarios

Ant

on Rom

an Portabales

and Mart

ın L

opez Nores

Quobis Networks, O Porri

no, Spain

Department of Telematics Engineering, Universidade de Vigo, Vigo, Spain

Keywords:

ns-3 Network Simulation Docker Real-time Containers.

Abstract:

The purpose of this project was to extend an existing open-source simulation framework called Dockemu in

order to make it suitable to perform IoT simulations. The work covered some improvements with goes from

the support of more network technologies to the use of setup and deployment tools used by modern devops

professionals. The paper explains the architecture, the newly-added features and the speciﬁc advantages it

offers for research works in IoT network simulations.

1 INTRODUCTION

The Dockemu project was initially described by

Marco Antonio To, Marcos Cano and Preng Biba in

(To et al., 2015). It proposes a simulation approach

where the nodes can run any client/server Linux soft-

ware which is executed in a Linux container and the

network is simulated used using the open source net-

work simulator ns-3

The Dockemu implementation used to add the ex-

tensions described in this work was published by J.A.

Alvarez Aldana in Github

. The main features of

Dockemu simulation framework are as follows:

• It allows to use real software in the simulated

nodes, removing the extra effort needed to create

ad-hoc simulation software and ensuring more ac-

curate results.

• It is based on open-source projects and the project

itself is open-source, so it can be used and ex-

tended by anyone at no cost and with total ac-

cess to the code which is considered to be more

effective and cost-efﬁcient for research works.

(G Gupta et al., 2013).

• It has a very quick set-up time through a com-

pletely automated procedure, minimizing the time

the researcher needs to invest in tasks not directly

related with the experiments at hands.

• The tools available for the exchange of Docker

https://www.nsnam.org/

https://github.com/chepeftw/NS3DockerEmulator

containers make it very easy to replicate experi-

ments, thus facilitating the validation and analysis

of the results included in any publication.

Owing to these facts, Dockemu fosters greater re-

alism, reproducibility and representativeness in net-

work simulations. It supports the most relevant net-

work technologies, and more are expected to be added

in the future.

The goal of the extension described in this pa-

per is to enable simulations of different IoT scenar-

ios that can not be covered with the current version

of Dockemu. Those scenarios include more complex

topologies, including different types of application

(e.g. client-server) in the same simulation, and uses

of network technologies typically found in IoT net-

works, namely LTE and 6lowpan over IEEE 802.15.4.

This work describes the extensions and the rationale

behind the additions of new features needed to con-

duct experiments that aim to benchmark IoT proto-

cols and measure the impact of the modiﬁcation of

different network and protocol-speciﬁc parameters.

The key technologies used to implement Dockemu

are Linux containers and ns-3.

Both Linux containers are ns-3 are brieﬂy de-

scribed in Section 2. Then a short state-of-the-art sec-

tion discusses the existing alternatives to perform IoT

simulations. In Section 4 we cover the new features

All the changes implemented in Dockemu will be re-

leased under GPLv3 license, including the experiments re-

ported in the paper. This tries to follow good practices

(Patrick Vandewalle and Vetterli, 2009) in terms of re-

search impact and reproducibility.

Portabales, A. and Nores, M.

Dockemu: Extension of a Scalable Network Simulation Framework based on Docker and NS3 to Cover IoT Scenarios.

DOI: 10.5220/0006913601750182

In Proceedings of 8th International Conference on Simulation and Modeling Methodologies, Technologies and Applications (SIMULTECH 2018), pages 175-182

ISBN: 978-989-758-323-0

175

added to the existing Dockemu framework and in Sec-

tion 5 we describe the main implementation details.

The paper ends in Section 6 with conclusions and fu-

ture lines to further enhance Dockemu.

2 TECHNOLOGY BACKGROUND

Container-based virtualization and application con-

tainerization is an Operating System (OS) level vir-

tualization method for deploying and executing dis-

tributed applications without launching a different

VM for each application. The application executed

in the containers uses the same lower layers of the OS

like the rest of applications, but in an isolated run-

time environment. Linux containers take advantage

of namespace and cgroups resource isolation features

provided by the Linux kernel.

Docker takes advantage of the aforementioned

features to provide a complete framework to create

and execute Linux containers. Docker enables the ex-

ecution of a huge number of isolated containers in a

single server. This is the main reason why we consid-

ered containers to be the best approach to run the real

software to be tested in our simulations, since IoT sce-

narios normally require a big number of network end-

points. Using Virtual Machines would require much

more resources, by far (Sharma et al., 2016). The

overhead of virtual machines is even more noticeable

in IoT, since applications in this realm have to run in

constrained devices, so they are expected to be light

in terms of CPU and RAM usage.

Apart from the low use of resources of contain-

ers, the use of Docker also facilitates the creation of

images which contain all the required software to be

tested. These can be created from scratch, or derived

from existing container images used during the devel-

opment phase of the project to be automatically tested

by CI (Continuous Integration) systems or by the de-

veloper herself. Currently, there are Docker images

available to be used as development environments

for the most common IoT operating systems, such as

Contiki OS

and FreeRTOS

. The same Docker con-

tainer which is used to develop and test IoT applica-

tions can be directly connected to Dockemu.

The other key technology of Dockemu, ns-3, is a

discrete event simulator (DES) designed for the sim-

ulation of data networks of different technologies and

topologies. It is targeted primarily for research and

educational use and open-source software, licensed

under the GNU GPLv2 license, therefore publicly

https://github.com/contiki-ng/contiki-ng/wiki/Docker

https://github.com/megakilo/FreeRTOS-Sim

available for research, development and use. There

are other open-source network simulators, but ns-3

has been considered one of the best in terms of per-

formance of use of CPU and RAM (ur Rehman Khan

et al., 2013). A key feature of ns-3 is a real-time

scheduler for simulation events which locks the sim-

ulation clock with the hardware clock. This real-time

feature and the ability to generate real network pack-

ets which its respective checksums enable the inte-

gration of ns-3 with real network stacks which and

emit/consume packets.

Furthermore, ns-3 enjoys a great diversity of mod-

ules to simulate different parts of data networks.

Many modules allow to simulate different network

technologies implementing realistic models. There

are also modules not related with the networking it-

self but with other characteristics of the simulation

such as the mobility model, which allows to simu-

late mobile nodes deployed in a speciﬁc area. One of

these modules is the Tap NetDevice

, which enables

the connection of a OS-level tap interface with a node

of the ns-3 simulation.

In section 5 we will see how both the real-time

feature and Tap bridge module are key characteristics

of ns-3 used by Dockemu to be able to run simula-

tions.

3 STATE OF THE ART

Simulation of IoT networks has been widely dis-

cussed by the research community which has de-

scribed a number of requirements every simulation

and experimentation platform should meet in order to

provide realistic and valuable results. (Gluhak et al.,

2011) gathers a comprehensive list of those require-

ments:

• Scale: IoT simulations would normally involve a

very big number of nodes;

• Heterogeneity: different network technologies,

topologies, type of devices and applications must

be supported;

• Repeatability: experiments must be easily re-

peatable with the same results;

• Federation: testing platforms should be able to

federate to each other in order to simulate bigger

systems.

• Concurrency: several experiments should be

able to be performed at the same time;

https://www.nsnam.org/doxygen/grouptap-bridge.html

SIMULTECH 2018 - 8th International Conference on Simulation and Modeling Methodologies, Technologies and Applications

176

• Mobility: the platform must be able to simulate

mobile nodes as this is going to be normal behav-

ior of many IoT devices;

• User Involvement and Impact: experiments

which involves humans should be able to evalu-

ate its social impact and acceptance.

Though those requirements were initially considered

for experimentation testbeds many of them can be ap-

plied directly or adapted to pure of hybrid

IoT simu-

lations.

Regarding the simulation technologies to be used,

DESs have been identiﬁed as valid tools in order to

simulate the network, but in order to take advantage

of multi-CPU and distributed networks (D’Angelo

et al., 2016) it is necessary to implement Parallel

and Distributed Simulation (PADS)

. The authors

of (D’Angelo et al., 2016) also proposed the use of

multilevel simulations, where some parts of the sys-

tem are simulated in more detail and other parts are

simulated at a higher level in order to save computa-

tional resources.

There are several proprietary simulators, such as

SimpleIoTSimulator

, that claim to be able to simu-

late thousands of sensors implementing different IoT

protocols. No technical details about the simulation

techniques used are disclosed. Rather, the sensors are

pre-built and the code is proprietary, so it is not re-

ally usable in typical research environments. Another

commercial alternative is Netsim

, a generic network

emulator that can emulate a network of different tech-

nologies and connect real applications to it, however

it does not handle the setup of the complete scenario.

It allows to modify its source code to implement cus-

tomized protocols to licensed users.

ns-3 has been already use in other simulation

frameworks such as Cupcarbon

. This is a open-

source IoT and smart city simulator that allows to

simulate a network of sensors deployed in a city with

geographic models

. It is largely focused on smart

cities and sensor networks, and it does not support the

simulation of customized applications.

Node-RED

is an open-source ﬂow-based pro-

gramming tool which is part of the JS Foundation

Flow-based programming is a way of describing the

We use the term hybrid to refer to simulations where some

of the elements is not simulated but a real element, like the

client/server software in Dockemu.

ns-3 supports distributed simulations as explained in 6.1.

http://www.smplsft.com/SimpleIoTSimulator.html

https://www.tetcos.com/

http://www.cupcarbon.com/

https://github.com/bounceur/CupCarbon

https://nodered.org/

https://js.foundation/

behavior of an application as a network of black

boxes. Each black box has a well-deﬁned purpose

and exchanges data with other connected boxes. This

high-level, functional style of speciﬁcations allows

the system behavior to emerge from simpliﬁed model,

but it does not deal with neither implementation nor

low-level networking models.

Finally, the most extreme approach in terms of

simulation is to use a very large scale open testbed

with thousands of real wireless sensors. This is the ap-

proach followed by FIT/IoT-Lab

which consists of

thousands of real IoT wireless sensors spread across

six different sites in France. The IoT-LAB is open to

research experiments under request.

4 NEW FEATURES ADDED TO

SUPPORT IOT SIMULATIONS

This section gathers all the new features and technolo-

gies we have added to the Dockemu framework within

the scope of this work in order to improve its suitabil-

ity for advanced IoT simulations and be able to simu-

late a wider range of scenarios.

4.1 LTE and 6lowpan Over 802.15.4

IoT emulation requires to support a huge number of

nodes as there would be in a real environment and

also network topologies using adapted technologies

as LTE and 6lowpan over 802.15.4. We included sup-

port for both in Dockemu by leveraging the LENA,

lr-wpan and 6lowpan modules of ns-3. The initial ver-

sion Dockemu only supported CSMA (model equiv-

alent to Ethernet in terms of simulation) and WiFi

(802.11), which are not particularly relevant to em-

ulate IoT scenarios.

Both LTE and 6lowpan over 802.15.4 topologies

support mobility, so scenarios where the nodes are not

static are supported taking advantage of ns-3 mobil-

ity model library

. This feature could be especially

interesting to simulate connected car scenarios. The

type of simulations covered by both technologies is

different. LTE can cover wide areas, leveraging the

operator infrastructure and relatively expensive de-

vices with SIM card and LTE wireless module which

can send and receive high bandwidth trafﬁc. In turn,

6lowpan over 802.15.4 is used in small areas to re-

ceive and send information to low power constrained

devices. Actually a combination of two modules –

which is still not possible in Dockemu– would make

https://www.iot-lab.info/

https://www.nsnam.org/docs/models/html/mobility.html

Dockemu: Extension of a Scalable Network Simulation Framework based on Docker and NS3 to Cover IoT Scenarios

177

sense to cover even more realistic scenarios where

a PAN coordinator receives data from remote sen-

sor connected to small devices and this information

is sent to a cloud service using LTE.

4.2 Different Types of Nodes

The initial version of Dockemu only considered a sin-

gle type of node. We have added the capacity to de-

ﬁne different types of nodes (e.g. scenarios where one

node is a server and the rest of nodes act as clients).

This allows, for example, to simulate for IoT proto-

cols such as COAP(Bormann and Shelby, 2016) and

MQTT

where the nodes can play different roles.

Scenarios where there is more than one server can

even be easily supported, too. In order to create the

different type of nodes the Docker container must be

created with the right software or conﬁguration.

4.3 Ansible as Scenario Deployment

Tool

The initial setup as well as the scenario setup is a

complex process which involves several software el-

ements and conﬁguration ﬁles. Ansible –deployment

and orchestration software supported by Red Hat– has

become an important tool for devops engineers (Ebert

et al., 2016) to deploy services since its release in

2012 and it is being used to automate the setup of

complex architectures such as NFV-based platforms.

The fact that it is a de facto standard tool, together

with the ease to add new features using existing and

well-tested modules, makes it a suitable choice to

manage the orchestration of the Dockemu framework.

It also allows to replicate the simulation environment

in different Linux distributions so it makes the project

more portable. These are the reason why we decided

to adopt Ansible in Dockemu as the deployment and

scenario setup tool.

5 IMPLEMENTATION

5.1 Conﬁguration File

In order to control the parameters of the simulation we

had to extend the parameters included in the reference

conﬁguration ﬁle. The conﬁguration ﬁle is written in

YAML format, which makes it easy to understand and

modify.

http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/csprd02/mqtt-

v3.1.1-csprd02.html

Listing 1: Dockemu reference conﬁguration ﬁle.

#DOCKEMU c o n f i g f i l e

g e n e r a l :

w a f p a t h = / home / u s e r / ns − 3.22

l o g g i n g = t r u e

v e r b o s e = f a l s e

l o g f i l e = l o g s / . l o g

c o n t a i n e r L o g s =/ v a r / l o g s / c o n t a i n e r s

r unningTim e =300

t e m p l a t e E t h e r n e t = ns3 / t a p − e t h e r n e t

t e m p l a t e W i F i = n s 3 / tap − w i f i

temp l a t eLTE = ns3 / t a p − l t e

t e m p l a t e 6 l o w p a n = n s3 / ta p −6lowpan

m o b i l i t y :

m o b i l i t y p a t t e r n =1

node s :

n u m b e r C l i e n t C o n t a i n e r s : 5

n u m b e r S e r v e r C o n t a i n e r s : 1

c l i e n t D o c k e r f i l e : n s 3 / d o c k e r / c D o c k e r f i l e

s e r v e r D o c k e r f i l e : ns3 / d o c k e r / s D o c k e r f i l e

n e t w o r k i n g :

t o p o l o g y : e t h e r n e t

ipv4 N e t work : 1 0 . 6 . 6 . 0 / 2 4

ipv6 N e t work : 2 0 0 1 : DB8 : : / 3 2

Once the conﬁguration ﬁle has been provisioned

with the right values it is necessary to execute the

Dockemu from a terminal command, passing the con-

ﬁguration ﬁle as a parameter:

$ sudo dockemu -c <conf file>

It is required to execute with sudo, since it is nec-

essary to create new bridge and tap interfaces. It is

also possible to set all the commands using the CLI

and passing all the settings deﬁned in the conﬁgura-

tion ﬁle directly as parameters to the command.

5.2 Steps to Setup the Simulation

In order to set up the environment and prepare all the

elements needed by each simulation, Dockemu car-

ries out the following tasks:

1. Build the container images for client and server

from the Dockerﬁles speciﬁed in the conﬁgura-

tion. These Dockerﬁles must be edited by the

authors/testers of the software to be tested in the

simulation.

2. It sets the right ns-3 simulation ﬁle and does the

required modiﬁcation in the C++ ﬁle if required

according to the conﬁguration settings.

3. It starts one container running per client and

server nodes deﬁned in the conﬁguration ﬁle.

4. It creates all the tap and bridge interfaces required

to link each container with the ns-3 simulation.

5. It assigns the IP addresses to be used during the

simulation to each node.

SIMULTECH 2018 - 8th International Conference on Simulation and Modeling Methodologies, Technologies and Applications

178

6. Once the steps below are completed the simula-

tion starts for the duration speciﬁed in the conﬁg-

uration ﬁle.

5.3 Networking Setup

The networking setup requires the creation of as many

bridges and tap interfaces as containers are in the sim-

ulation. The number of containers corresponds with

the number of nodes desired in the simulation, and it

may change from one simulation to another; so, the

creation/deletion of bridge and tap interfaces most be

done on demand. The number and type of nodes is

passed as a parameter. As shown in Figure 1 the vir-

tual interfaces and the corresponding tap interfaces

are connected using a bridge interface and the tap

bridge object within the ns-3 topology is associated

in turn to its corresponding bridge.

Dockemu takes advantage of the Network names-

pace feature of the Linux Kernel (Pino, 2018) to as-

sign IPv4 and IPv6 IP addresses to each container.

Figure 1: Connectivity between containers and ns-3 ghost

nodes for Ethernet (CSMA) and WiFi.

5.3.1 IPv6 Support

In order to support IPv6, an IPv6 address has been

added to the Network Space interface created for each

container. This way each container will use directly

this IP so the application can be tested with a real IPv6

like in a real network. The connection with ns-3 hap-

pens at Data Link layer so it is not necessary to handle

it in the OS interfaces. Special attention needs to be

put on the routing conﬁguration of ns-3 as it has some

differences respect to IPv4 routing.

5.4 LTE Support

The only ns-3 networking technologies that support

tap bridge are WiFi and CSMA, so a LTE network

can not be directly connected to the container through

network interfaces. In order to connect the container

with the ns-3 simulation, we have followed the ap-

proach described and validated in (Hasan et al., 2017).

A CSMA link with a huge bandwidth and very low

latency is used to connect the tap interface and the

UE node in the simulation as depicted in Figure 2.

Each container is connected through a bridge with the

tap interface installed in a ghost host, connected in

turn using the high-bandwidth and very low latency

CSMA link. As the CSMA effect is minimized in

terms of simulation, it will not add a measurable delay

nor will lose any packets. This approach can be fol-

lowed to simulate more network technologies which

can not be connected directly to tap bridge interfaces.

Our implementation allows to connect each con-

tainer to a UE node, so it simulates the execution of

the application in a device with LTE interface. In

our initial version all the devices are connected to the

same enbNode, but nothing prevents from using sev-

eral enbNodes in the future, since this is supported by

ns-3 LENA module (it has been designed to support

from tens to hundreds of eNBs and from hundreds to

thousands of UEs, so it is suitable for almost any IoT

simulation). The current implementation also allows

to create a different role for a server application which

may exist or not.

The diagram 2 depicts the general architecture of

the system.

5.5 LR-WPAN and 6lowpan Support

Low-rate wireless personal area networks (LR-

WPANs) are widely used in IoT deployments as they

focus on low-cost, low-speed ubiquitous communi-

cation between constrained devices with low-power

requirements. IEEE 802.15.4 is a technical standard

which deﬁnes the physical and MAC (Medium Ac-

cess Control) layers of LR-WPANs. Other higher-

level layers and interoperability sublayers are not de-

ﬁned in the standard. Speciﬁcations, such as 6LoW-

PAN, SNAP, Thread and ZigBee deﬁne the layers not

covered by IEEE 802.15.4 to implement usable LR-

WPANs.

Dockemu: Extension of a Scalable Network Simulation Framework based on Docker and NS3 to Cover IoT Scenarios

179

Figure 2: Block diagram of ns-3 conﬁguration to simulate

LTE network with N UE and a server nodes.

ns-3 has a 6lowpan module, which was used

jointly with the lr-wpan module (which implements

part of the 802.15.4 standard) in order to simulate a

LR-WPAN network. Figure 3 depicts the architecture

we use to simulate this type of network. It is pretty

similar to the architecture used to simulate the LTE

scenario: the ns-3 tap-bridge is connected to a ghost

node which is connected using an Ethernet

. In this

architecture the Node container must send the trafﬁc

in IPv6 directly. This IPv6 trafﬁc is sent through a

very low latency and high bandwidth link to the node

which sends the trafﬁc to the LR-WPAN network, af-

ter passing through a 6lowpan layer to adapt the pack-

ets to the 127-byte maximum size deﬁned by 802.15.4

standard. In order to associate all the nodes to the

same network, a fake PAN association is forced in

the conﬁguration. In a real network this association

would be automatically set up by one of the nodes of

the network playing the role of PAN coordinator.

5.6 Docker Setup

In order to execute the software of server and client

nodes, Dockemu uses Docker containers. This way

The name of the module used to simulate wired Ethernet

networks in ns-3 is called CSMA.

Figure 3: Block diagram of NS3 conﬁguration to simulate

LTE network with N UE and a server nodes.

a relatively high number of nodes can be simulated

at low computational cost (especially considering that

the software is expected to have been designed to be

executed in constrained devices). For the sake of sim-

plicity and to cover the most common simulation sce-

narios, the current version allows to deploy one node

with the role of server and a conﬁgurable number of

nodes with the role of client. With this setup we can

cover a wide range of IoT simulation scenarios.

It is necessary to build the Docker images which

will be instantiated as containers at the beginning of

the simulation. In order to create the build, it is neces-

sary to write one Dockerﬁle for the server and another

one for the clients. The creation of this Dockerﬁle

does not differ from a regular ﬁle for other types of

containers. It must leave the service running as if it

would be in a real device of server. Therefore the sim-

ulation will also validate the implementation of the

IoT software.

5.7 Software Deployment Automation

Several solutions to automate the deployment of soft-

ware such Puppet, Chef and Ansible have appeared

in the last years. They are intensively used in de-

vops tasks. The initial version of Dockemu was im-

plemented using different Bash scripts to set up the

environment (creation of tap and Bridge interfaces

SIMULTECH 2018 - 8th International Conference on Simulation and Modeling Methodologies, Technologies and Applications

180

and edition of the C++ ns-3 simulation script) and a

Python main script which controls the execution of

the simulation.

We have used Ansible to carry out all the envi-

ronmental tasks and the logic was left in the Python

script. Using Ansible instead of Bash scripts has a

number of advantages:

• the simulation can be easily deployed in any

server, different from the OS where the main

script is being executed;

• it is idempotent, and therefore more efﬁcient since

it only performs actions when needed reducing

setup time;

• it is declarative (not procedural), which added to

its smooth learning curve makes the playbook ﬁles

easier to read and modify;

• it will be possible to take advantage of new mod-

ules and features added to Ansible.

Once the simulation has ﬁnished, Ansible it is

also used to gather all the trafﬁc exchanged by all the

nodes collected in PCAP ﬁles (except the LR-WPAN

trafﬁc, which is collected in text ﬁles) and also the

logs generated by the client and server applications

executed in the Docker containers.

6 CONCLUSIONS

Dockemu provides a realistic and easy to setup sim-

ulation framework which meets the requirements of

a wide range of IoT simulations. It enables the use

of real client/server IoT software without any modiﬁ-

cation by just creating a Docker container following

Dockemu guidelines to be included as a node in the

simulation.

The fact of using ns-3 to simulate the network

means a great advantage since it allows to use all the

exiting and future ns-3 modules to increase the num-

ber of simulation scenarios covered.

Dockemu can simulate different network tech-

nologies (WiFi, Ethernet, LTE and 802.15.4) and can

be used with different purposes:

• validate IoT software over realistic network con-

ditions;

• check the impact of modiﬁcation in the applica-

tions or at any level of the network stack;

• carry out performance test of IoT software under

speciﬁc network conditions.

Playbook is the name given by Ansible framework to the

scripts where all the instruction needed to carry out a task

are written.

6.1 Future Lines

We have identiﬁed several work lines to improve and

complete Dockemu simulation in the future. These

tasks can be divided in three main groups:

1. Improvement of Existing Framework: this

group of tasks goes from improving and complet-

ing the documentation for the framework in or-

der to be used by others to including more conﬁg-

uration parameters for the simulation of the net-

work. This conﬁguration parameters will give the

researcher more control about what is happening

on the wireless interfaces and enable the execu-

tion of more speciﬁc experiments.

2. Addition of More Complex Network Topolo-

gies and Support of More Network Technolo-

gies: the network topologies offered are pretty

static. The framework could be easily enriched

with more topologies and network technologies in

order to cover more scenarios.

3. Support of Parallel and Distributed Simula-

tion Mode: ns-3 supports parallel and distributed

modes for simulation. These modes can handle

a higher number of nodes which is essential to

cover IoT scenarios with more elements in or-

der to cover real-world scenarios. To support dis-

tributed simulation in ns-3, the standard Message

Passing Interface (MPI) is used. There is an exist-

ing module

which already supports it and which

makes use of the OpenMPI Linux library

REFERENCES

Bormann, C. and Shelby, Z. (2016). Block-Wise Transfers

in the Constrained Application Protocol (CoAP). RFC

7959 (Proposed Standard).

D’Angelo, G., Ferretti, S., and Ghini, V. (2016). Simulation

of the internet of things. CoRR, abs/1605.04876.

Ebert, C., Gallardo, G., Hernantes, J., and Serrano, N.

(2016). Devops. IEEE Software, 33(3):94–100.

G Gupta, S., Ghonge, M., D P M Thakare, P., and Jawand-

hiya, P. (2013). Open-source network simulation tools

an overview. 2.

Gluhak, A., Krco, S., Nati, M., Pﬁsterer, D., Mitton, N.,

and Razaﬁndralambo, T. (2011). A survey on facili-

ties for experimental internet of things research. IEEE

Communications Magazine, 49(11):58–67.

Hasan, A. B., Kiong, T., Paw, J. K., Musa, A. B., and Mo-

hamed, H. (2017). Real-time video streaming over

ns3-based emulated lte networks. volume 4. Interna-

tional Journal of Electronics, Computer and Commu-

nications Technologies.

https://www.nsnam.org/docs/models/html/distributed.html

https://www.open-mpi.org/

Dockemu: Extension of a Scalable Network Simulation Framework based on Docker and NS3 to Cover IoT Scenarios

181

Patrick Vandewalle, J. K. and Vetterli, M. (2009). Repro-

ducible research in signal processing. IEEE SIGNAL

PROCESSING MAGAZINE, pages 37,47.

Pino, D. (2016 (accessed April 22, 2018)). Network names-

paces. https://blogs.igalia.com/dpino/2016/04/10/

network-namespaces/.

Sharma, P., Chaufournier, L., Shenoy, P., and Tay, Y. C.

(2016). Containers and virtual machines at scale: A

comparative study. In Proceedings of the 17th In-

ternational Middleware Conference, Middleware ’16,

pages 1:1–1:13, New York, NY, USA. ACM.

To, M. A., Cano, M., and Biba, P. (2015). DOCKEMU – a

network emulation tool. In 2015 IEEE 29th Interna-

tional Conference on Advanced Information Network-

ing and Applications Workshops. IEEE.

ur Rehman Khan, A., Bilal, S. M., and Othman, M. (2013).

A performance comparison of network simulators for

wireless networks. CoRR, abs/1307.4129.

SIMULTECH 2018 - 8th International Conference on Simulation and Modeling Methodologies, Technologies and Applications

182