Dynamic Link Network Emulation: A Model-based Design
Erick Petersen
1,2
, Jorge L
´
opez
1
, Natalia Kushik
2
, Claude Poletti
1
and Djamal Zeghlache
2
1
Airbus Defence and Space, Issy-Les-Moulineaux, France
2
T
´
el
´
ecom SudParis, Institut Polytechnique de Paris, Palaiseau, France
Keywords:
Model-based Design, Dynamic Link Networks, Emulator, Traffic Generation.
Abstract:
This paper presents the design and architecture of a network emulator whose links’ parameters (such as delay
and bandwidth) vary at different time instances. The emulator can thus be used in order to test and evaluate
novel solutions for such networks, before their final deployment. To achieve this goal, different existing
technologies are carefully combined to emulate link dynamicity, automatic traffic generation, and overall
network device emulation. The emulator takes as an input a formal model of the network to emulate and
configures all required software to execute live software instances of the desired network components, in the
requested topology. We devote our study to the so-called dynamic link networks, with potentially asymmetric
links. Since emulating asymmetric dynamic links is far from trivial (even with the existing state-of-the-art
tools), we provide a detailed design architecture that allows this. As a case study, a satellite network emulation
is presented. Experimental results show the precision of our dynamic assignments and the overall flexibility
of the proposed solution.
1 INTRODUCTION
As the demand for interactive services, multimedia
and network capabilities grows in modern networks,
novel software and/or hardware components should
be incorporated (Deng et al., 2019). As a conse-
quence, the evaluation and validation process of these
newly developed solutions is critical to determine
whether they perform well, are reliable and robust be-
fore their final deployment in a real network (Alsmadi
et al., 2020). However, thorough testing or qualify-
ing (Shan, 2021) the produced software under a wide
variety of network characteristics and conditions is a
challenging task (Gandhi et al., 2021).
Currently, many of these tests are done through
operational, controlled and small-scale networks
(physical testbeds) or alternatively software-based
testbeds. Ideally, if available, such tests are performed
on the original system in order to replicate the condi-
tions in which a service or protocol will be used at the
highest level of fidelity (Horneber and Hergenr
¨
oder,
2014). Unfortunately, while system modeling is not
needed, such testbeds are not always desirable or per-
tinent due to several reasons (Sun and Chai, 2003).
For example, there are difficulties in creating various
network topologies, generating different traffic sce-
narios, and testing the implementations under specific
conditions (network load or weather conditions that
may affect the radio-physical links in specific network
technologies such as wireless or satellite communica-
tions).
A very well-known alternative method is the use
of network simulators (Khan et al., 2012). Through
network simulation, researchers can mimic the ba-
sic functions of network devices and study specific
network-related issues on a single computer or high-
end server. However, the adequacy of simulated sys-
tems is always in question due to the model abstrac-
tion and simplification. At the same time, not simu-
lation but emulation for the related networks can also
be a solution (Lai et al., 2019). Network emulation
provides the necessary mechanisms to reproduce the
behavior of real networks at low infrastructure costs,
compared with physical testbeds while achieving bet-
ter realism than simulations since it allows the inter-
action with interfaces, protocol stacks and operating
systems. Moreover, there is a possibility to perform
continuous testing on the final implementation with-
out having to make any changes in the solution once
deploying it in a real network. However, the emu-
lation of dynamic link networks, i.e., networks whose
link parameters change, complicates the emulation ar-
536
Petersen, E., López, J., Kushik, N., Poletti, C. and Zeghlache, D.
Dynamic Link Network Emulation: A Model-based Design.
DOI: 10.5220/0011091100003176
In Proceedings of the 17th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE 2022), pages 536-543
ISBN: 978-989-758-568-5; ISSN: 2184-4895
Copyright
c
 2022 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved

chitecture. For example, certain radio-frequency links
have different up/down bandwidth capacity (Gandhi
et al., 2021), large delays (due to distant transmitters),
and the links’ capacities may change due to external
interference, propagation conditions (weather), traf-
fic variations (due to the shared medium), or others.
Therefore, it is extremely important to have methods
which allow controlling key parts of the emulation
over time, such as the generation of traffic or the mod-
ification of the link property values (capacity, delay).
These are required in order to build a proper emula-
tion environment of interest which is the main focus
of this work.
To cope with such requirements, we herein pro-
pose a dynamic link network emulation and traffic
generation which combines the functional realism and
scalability of virtualization and link emulation to cre-
ate virtual networks that are fast, customizable and
portable. The main contributions of this paper are: i)
a design and architecture of a dynamic link network
emulator that meets dynamic link emulation needs by
the effective use of software technologies, such as
virtualization (containers and virtual machines) and
Linux kernel capabilities; ii) a dynamic link network
emulator that provides a fast and user friendly work-
flow, from the installation to the configuration of sce-
narios by using a formal model of the network; iii) a
use case illustrating the dynamic link capabilities of
our emulator – we provide an experimental evalua-
tion, varying different network parameters configured
by demand for effectively emulating satellite commu-
nications.
2 RELATED WORK
Several works have been devoted to simulation and
emulation of networks, to perform experiments on
novel or existing protocols and algorithms. Below,
we briefly summarize relevant existing solutions.
Ns-3 (Henderson et al., 2008) is a widely used
network simulator. Ns-3 simulates network devices
by compiling and linking C++ modules; thus it sim-
ulates the behavior of real components in a user-level
executable program. However, real world network de-
vices are extremely complex (functionally speaking)
or cannot be compiled and linked together with Ns-3
to form a single executable program. Therefore, Ns-3
cannot run real-world network devices but only spe-
cific ones developed for it. vEmulab (Stoller et al.,
2008) is a network emulator with a minimum degree
of virtualization, aiming to provide application trans-
parency and to exploit the hierarchy found in real
computer networks. Its architecture uses FreeBSD
jail namespaces (Kamp and Watson, 2000) in low-end
computers to emulate virtual topologies. Similarly,
Mininet (Lantz et al., 2010) enables rapid testbeds by
using several virtualization features, such as virtual
ethernet pairs and processes in Linux container net-
work namespaces. It emulates hosts, switches and
controllers which are simple shell processes that are
given their network namespace and links between
them. However, both still present some limitations in-
cluding the lack of support for dynamic features such
as link emulation, resource management and traffic
generation. EstiNet (Wang et al., 2013) is based on
network simulation/emulation integration for differ-
ent kinds of networks. Unlike previous simulators,
EstiNet allows not only observation but also configu-
ration through a GUI. It also supports wireless chan-
nel modeling. However, since EstiNet is a commer-
cial solution, it cannot be easily extended. Moreover,
its features are limited and depend on the EstiNet de-
velopers. Thus, the performance fidelity and the ex-
pansion to new features are reduced. OpenNet (Chan
et al., 2014) also merges simulation and emulation
network capabilities by connecting Mininet and Ns-
3. However, it inherits the limitations from Ns-3 and
Mininet. Additionally, its main focus is on software-
defined wireless local area networks (SDWLAN).
More recently, the introduction of lightweight vir-
tualization technologies (e.g., containers) has led to
some few container-based emulation tools (Srisawai
and Uthayopas, 2018; Farias et al., 2019). SDN Owl
(Srisawai and Uthayopas, 2018) is a network emu-
lation tool to create simple SDN testbeds using few
computers with Linux OSs. SDN Owl utilizes Ansi-
ble to send a set of scripts to properly configure each
virtual component. However, it fails to provide scal-
ability and isolation, since experiments with different
types of network topologies or resource allocation are
not shown. vSDNEmul (Farias et al., 2019) and Con-
tainerNet (Peuster et al., 2018) are network emula-
tors based on Docker container virtualization allow-
ing autonomous and flexible creation of independent
network elements, resulting in more realistic emula-
tions. However, these emulators can only create SDN
networks. Furthermore, the network descriptions re-
main rather informal and do not facilitate the verifi-
cation of the emulator, in order to guarantee that the
emulator properly replicates the desired network. A
feature comparison is shown in Table 1.
As can be seen and to the best of our knowledge,
we are not aware of any works that meet all the fea-
tures required to properly emulate dynamic link net-
works in order to qualify novel engineered solutions.
This is the main motivation behind this work, which
presents the design and architecture of an emulator
Dynamic Link Network Emulation: A Model-based Design
537

Table 1: Comparison of Software-based Network Testbeds.
Name Open
Source
Language GUI Emulation
Support
Scalability Portability Dynamic
Links
Automatic
Traffic
Generation
Formal
Description
Ns-3(Henderson et al.,
2008)
C++/Python x x +++ x x x
Mininet(Kaur et al.,
2014)
Python + x x x
Containernet(Peuster
et al., 2018)
Python ++ x x x
OMNet++(Varga, 2001) x C++ x +++ x x x
Emulab(Stoller et al.,
2008)
C + x x x
OpenNet(Chan et al.,
2014)
C++ x +++ x x x
vSDNEmul(Farias et al.,
2019)
Python x ++ x x x
EstiNet(Wang et al.,
2013)
x - ++ - -
SDN Owl(Srisawai and
Uthayopas, 2018)
Python x ++ x x x
NetEM(Hemminger
et al., 2005)
- x - x x x
that meets all the requirements. In order to do so, a
model-based engineering approach is well suited, and
thus, utilized.
3 BACKGROUND
Dynamic Link Networks. As introduced in (Pe-
tersen et al., 2020), a static network is a computer net-
work where each link has a set of parameters that do
not change, for example bandwidth (capacity) or de-
lay. Differently from static networks, the parameters
of the links may change in dynamic link networks (in
the scope of our current work, we assume the network
topology does not change); such change can be the
consequence of the physical medium (e.g., in wireless
/ radio frequency networks) or due to logical changes
(e.g., rate limiting the capacity of a given link).
Static networks can be modeled as (directed)
weighted graphs (V, E, p
1
, . . . , p
k
), where V is a set of
nodes, E ⊆ V ×V is a set of directed edges, and p
i
is a
link parameter function p
i
: E → N, for i ∈ {1, . . . , k};
without loss of generality, we assume that the pa-
rameter functions map to non-negative integers (de-
noted by N) or related values can be encoded with
them. Similarly, dynamic link networks can be mod-
eled as such graphs, however, p
i
maps an edge to a
non-empty set of integer values, i.e., p
i
: E → 2
N
\
/
0,
where 2
N
denotes the power-set of N. An example
dynamic network is depicted in Fig. 1, and its model
N = (V, E, p
1
(e), p
2
(e)), where:
V = {1, 2, 3, 4}
E = {(1, 2), (2, 1), (1, 3), (3, 1), (1, 4),
(4, 1), (2, 4), (4, 2), (3, 4), (4, 3)}
p
1
(e) = b((s, d)) =
(
{4, 5, 6}, if d = 2
{2, 3, 4}, otherwise
p
2
(e) = d((s, d)) =
(
{1, 2}, if d = 2
{9, 10}, otherwise
.
Semantically, this model represents a dynamic
link network in which the link’s available bandwidth
can vary according to the function b (for bandwidth),
and the link’s delay can vary according to the function
d (for delay).
1 2
3
4
b(e) = {4, 5, 6}, d(e) = {1, 2}
b(e) = {2, 3, 4}, d(e) = {9, 10}
b(e) = {2, 3, 4}, d(e) = {9, 10}
b(e) = {2, 3, 4}, d(e) = {9, 10}
b(e) = {2, 3, 4}, d(e) = {9, 10}
b(e) = {2, 3, 4}, d(e) = {9, 10}
b(e) = {2, 3, 4}, d(e) = {9, 10}
b(e) = {2, 3, 4}, d(e) = {9, 10}
b(e) = {4, 5, 6}, d(e) = {1, 2}
b(e) = {2, 3, 4}, d(e) = {9, 10}
Figure 1: Example dynamic link network.
Virtualization & Software Technologies Involved.
Nowadays, virtualization technologies (Giallorenzo
ENASE 2022 - 17th International Conference on Evaluation of Novel Approaches to Software Engineering
538

et al., 2021) have been used for the design of virtual
networks and furthermore, to conduct necessary ex-
periments (emulations). The reason is that virtualiza-
tion allows creating controlled environments (virtual
instances) and reproduce their real underlying net-
work architectures, as well as creating artificial condi-
tions, that can be hard to reproduce in real life. Below
we present the virtualization technologies, utilized in
our work, namely Virtual Machines, Containers, and
Unikernels.
Virtual Machines (VMs) are created and man-
aged by a hypervisor (Wulf et al., 2021), which al-
lows to fully emulate different types of devices (e.g.,
routers, cellphones, etc.) with their own complete and
isolated operating system (OS) or CPU architecture.
Containers are isolated environments (user-
spaces instances) for processes; they are created by
utilizing the kernel features of a given operating sys-
tem (Sultan et al., 2019). In contrast to VMs, con-
tainers do not get their own virtualized hardware but
use the hardware of the host system. Therefore, not
having to emulate hardware and boot a complete op-
erating system enables containers to be more efficient
than VMs but dependent on the kernel functions of
the host OS.
Unikernels are single-address-space machine im-
ages constructed by using library operating systems
(Watada et al., 2019). The approach consists of pack-
aging a given application (e.g., a router) with the min-
imal kernel functions and drivers required to run as a
sealed and immutable executable directly on the hard-
ware (or sometimes on a hypervisor).
APP
Hardware Infraestructure
Operating System + Kernel
Hypervisor
Bin/Lib/Runtime
OS + Kernel
Hardware
App
VM
APP
Bin/Lib/Runtime
OS + Kernel
Hardware
App
VM
(a) Virtual Machine.
Hardware Infraestructure
Operating System + Kernel
Container Engine
App
App
App
Bin/Lib/Runtime
App
Bin/Lib/Runtime
App
Container
Container
(b) Container.
Hardware Infraestructure
Operating System + Kernel
Hypervisor
Bin/Lib/Runtime
APP
Container 2
APP
App
Bin/Lib/Runtime
Kernel
VM
APP
App
Bin/Lib/Runtime
Kernel
VM
(c) Unikernel.
Figure 2: Virtualization Architectures: VM (a), Container
(b), Unikernel (c).
In Figure 2, we depict the architectural differences
between the virtualization technologies. Although,
the minimality of unikernels seems to be a promising
emulation solution between the flexibility of VMs and
the performance of containers, it requires applications
to be written specifically for them. Thus, we do not
consider this option in our work. At the same time,
plenty of emulators as introduced above rely just on
one single virtualization technology to emulate homo-
geneous networks. In contrast, we believe that both
virtualization technologies (VMs and containers) can
be used simultaneously (hybrid approach), to emulate
heterogeneous nodes and thus replicate other types of
networks with dynamic capabilities.
4 EMULATOR ARCHITECTURE
Our emulation platform design and architecture is
based on well-known state-of-the-art technologies
presented above, such as virtualization (VMs and con-
tainers) and Linux kernel features (namespaces or
cgroups). When combined efficiently, these technolo-
gies provide excellent capabilities for the emulation
of a diverse set of network topologies alongside the
dynamic links and interconnected network devices.
The emulation platform architecture, shown in Fig-
ure 3, consists of several independent, flexible and
configurable components. We describe each of these
components in detail in the following paragraphs.
The Emulator Manager is the main component
and the central processing unit. It has a single in-
stance per physical machine and it is composed of
several independent modules in charge of the man-
agement, deployment and verification of the emulator
components for a given network description (input for
the emulation). In addition, it is responsible for pro-
viding, within the same physical host, the containers
or VMs required for each emulated device as well as
their own emulated network specifications.
The Input/Output Processing Module fulfills
several tasks. First, since our emulation platform
relies on state-of-the-art virtualization (or container-
based) solutions, it is in charge of creating and main-
taining a network model that later is used by other
modules to implement the necessary infrastructure el-
ements for each emulation. To achieve this, we utilize
a formal network description (specification) in terms
of first order logic formulas verified throughout the
emulation by a satisfiability modulo theories solver.
Indeed, the network topology can be verified using
model checking strategies before its actual implemen-
tation, as well as at run-time, to assure that certain
properties of interest hold for the static network in-
stances (Petersen et al., 2020). The module is also
in charge of parsing and verifying the file to generate
Dynamic Link Network Emulation: A Model-based Design
539

Deployment
Module
MemoryDisksCPU Hardware
CapabilitiesCgroupsNamespaces
Host Operating System
Virtualization
Drivers
NIC
Monitoring
Module
Dynamic link
Module
Traffic
Generator
Module
Network Model
Specifications
Dynamic Traffic
Model
VNF
VNF
VNF
VNF
VNF
VNF
Containers
Virtual
Machines
Debugg
Emulator Manager
Input/Output
I/O Processing
Module
Topology
Validation
Traffic
Parser
Figure 3: Emulation Platform Architecture.
dynamic traffic scenarios between the components of
an emulated network as well as the debugging output
of the platform. An example of a network description
is given in Listing 1 (for the network in Figure 1).
( d e c l a r e − d a t a t y p e s ( )
( ( Edge (mk− edg e ( s r c I n t ) ( d s t I n t ) ) ) ) )
( d e c l a r e − f u n b a nd w i d t h ( Edge ) I n t )
( d e c l a r e − f u n d e l a y ( Edge ) I n t )
; ; Node s t o r a g e o m i t t e d on p u r p o s e
; ; t o r e d u c e t h e sp a c e , s e e ed ge s t o r a g e
( d e c l a r e − c o n s t ed g e s ( Ar r a y I n t Edge ) )
( d e c l a r e − c o n s t e d g e s s i z e I n t )
( a s s e r t (= ( s t o r e e d g es 1 ( mk−e dge 1 2 ) ) e d g e s ) )
; ; Edge s t o r a g e o m i t t e d on p u r p o s e
; ; t o r e d u c e t h e sp a c e , s e e f i r s t and l a s t ed g e
( a s s e r t (= ( s t o r e e d g es 10 ( mk− ed g e 4 2 ) ) e dg e s ) )
( a s s e r t (= e d g e s s i z e 1 0 ) )
( a s s e r t ( f o r a l l ( ( x I n t ) ) (=>
( and (> x 0 ) (<= x e d g e s s i z e ) )
( and
(=> (= ( d s t ( s e l e c t e d g e s x ) ) 2 )
; ; i t e n o t us ed on p u r p o s e
( and
(>= ( b a n d w i d t h ( s e l e c t e dg e s x ) ) 4 )
(<= ( b a n d w i d t h ( s e l e c t e dg e s x ) ) 6 )
(>= ( d e l a y ( s e l e c t e d g e s x ) ) 1 )
(<= ( d e l a y ( s e l e c t e d g e s x ) ) 2 )
)
)
(=> ( n o t ( = ( d s t ( s e l e c t e d g e s x ) ) 2 ) )
( and
(>= ( b a n d w i d t h ( s e l e c t e dg e s x ) ) 2 )
(<= ( b a n d w i d t h ( s e l e c t e dg e s x ) ) 4 )
(>= ( d e l a y ( s e l e c t e d g e s x ) ) 9 )
(<= ( d e l a y ( s e l e c t e d g e s x ) ) 10)
)
) ) ) ) ) ; ; c l o s i n g p a r e n t h e s e s
Listing 1: Example of a Network description (SMT-LIB).
The Deployment Module is in charge of convert-
ing the previously generated network model into run-
ning instances of emulated network devices. In order
to achieve this, the module makes use of the docker
engine for the management and support of contain-
ers and libvirt for different virtualization technolo-
gies such as KVM, VMware, LXC, and virtualbox. At
the first step, it takes the input specification and cre-
ates the required nodes with their corresponding im-
ages and properties. Each emulated node is deployed
by means of a VM or a container attached to its own
namespace and acts according to the software or ser-
vice running inside of it (as requested by the input
specification). For example, if it is desired to run a
virtual switch as a Docker container, the Deployment
Module creates the proper container and executes the
corresponding Virtual Network Function (VNF) via a
docker image (e.g., Open vSwitch). Therefore, each
node has an independent view of the system resources
such as process IDs, user names, file systems and net-
work interfaces while still running on the same hard-
ware. It can also hold several individual (virtual) net-
work interfaces, along with its associated data, in-
cluding ARP caches, routing tables and independent
TCP/IP stack functions.
This gives great flexibility and capabilities to the
emulator, it can execute any real software as in the real
physical systems. At the last step, the module creates
the links between the nodes to complete the emula-
tion topology. The links are emulated with Linux vir-
tual networking devices; TUN/TAP devices are used
to provide packet reception and transmission for user
space processes (applications or services) running in-
side each node. They can be seen as simple Point-
to-Point or Ethernet devices, which, instead of receiv-
ing (and transmitting, correspondingly) packets from
a physical medium, read (and write, correspondingly)
them from a user space process. veth (virtual Ether-
net) devices are used for combining the network fa-
cilities of the Linux kernel to connect different virtual
networking components together. veth are built as
ENASE 2022 - 17th International Conference on Evaluation of Novel Approaches to Software Engineering
540

pairs of connected virtual Ethernet interfaces and can
be thought of as a virtual “patch” cable. Thus, packets
transmitted on one device in the pair are immediately
received on the other device and when either device is
down the link state of the pair is down too.
{ ” name ” : ” t e s t t r a f f i c s c e n a r i o ” ,
” i n i t i a l T i m e ” : 0 ,
” ti m e U n i t I n S e c ” : 1e −3 ,
” b a n d w i d t h U n i t I n B i t s ” : 1 e3 ,
” fl o wS e q u e n ce ” : [ {
” ti m e ” : 400 0 ,
” f l o w s ” : [ {
” f l o w i d ” : 1 ,
” re q u i r e d B a n d w i d t h ” : 2 ,
” p r o t o c o l ” : ” t c p ” ,
” s o u r c e i p ” : ” 1 9 2 . 1 6 8 . 1 . 2 ” ,
” s o u r c e p o r t ” : 4 0 0 0 ,
” d e s t i n a t i o n i p ” : ” 1 9 2 . 1 6 8 . 1 . 3 ” ,
” d e s t i n a t i o n p o r t ” : 4 000
}]
} ,
{
” ti m e ” : 100 0 0 ,
” f l o w s ” : [ {
” f l o w i d ” : 1 ,
” re q u i r e d B a n d w i d t h ” : 4 ,
” p r o t o c o l ” : ” t c p ” ,
” s o u r c e i p ” : ” 1 9 2 . 1 6 8 . 1 . 2 ” ,
” s o u r c e p o r t ” : 8 0 0 0 ,
” d e s t i n a t i o n i p ” : ” 1 9 2 . 1 6 8 . 1 . 3 ” ,
” d e s t i n a t i o n p o r t ” : 8 000
} , {
” f l o w i d ” : 2 ,
” re q u i r e d B a n d w i d t h ” : 3 ,
” p r o t o c o l ” : ” t c p ” ,
” s o u r c e i p ” : ” 1 9 2 . 1 6 8 . 1 . 2 ” ,
” s o u r c e p o r t ” : 8 0 8 0 ,
” d e s t i n a t i o n i p ” : ” 1 9 2 . 1 6 8 . 1 . 3 ” ,
” d e s t i n a t i o n p o r t ” : 8 080
}]
}]
}
Listing 2: Example of a Dynamic Traffic Description.
The Dynamic Link Module is in charge of estab-
lishing and modifying the dynamic properties of the
links (between the nodes) during the emulation’s exe-
cution time. An asymmetric link between two nodes,
as shown in Figure 4, is emulated by a set of nesting
queues; in the simplest case - two queues.
eth0 Queue
ifb0
eth0
ifb0
Link Emulation
Node BNode A
VNF VNF
Delay
Bandwidth
Queue
Delay
Bandwidth
Figure 4: Asymmetric Link emulation model.
At the first step, packets are queued or dropped
depending on the size of the first queue. This queue
is drained at a rate corresponding to the link’s band-
width. Once outside, packets are staged in a delay
line for a specific time (propagation delay of the link)
in the second queue and then finally injected into the
network stack. This module uses the Linux Advanced
traffic control tc, to control and set these properties
by using filtering rules (classes) to map data (at the
data link or the network layer) to queuing disciplines
(qdisc) in an egress network interface. Note that
since tc can be used only on egress, Intermediate
Functional Block devices (IFB) are created to allow
queuing disciplines on the incoming traffic and thus
use the same technique.
The Traffic Generation Module is in charge of
converting the dynamic description of the traffic (see
an example of it in Listing 2), into a timed sequence
of network packets. This sequence is then introduced
into the deployed nodes during the emulation. For
the generation of network packets, the module uses
nmap at each node, particularly nping, allowing to
generate traffic with headers from different protocols.
This is achieved by using virsh commands utilizing
libvirt for VMs or by passing execute commands
through the Docker daemon (for containers). It is im-
portant to keep in mind that nping can be replaced
for any other software to generate traffic. Addition-
ally, multiple instances of the same or different traf-
fic generators can be executed inside each emulated
node.
Finally, the Monitoring Module retrieves and
collects information from the nodes and their links.
This information can be used for example, to verify
that the emulation process is executed correctly. Ad-
ditionally, for our case study, this information is use-
ful to change the bandwidth on demand (in fact this is
known as demand assigned multiple access or DAMA
which further serves as a case study).
5 EVALUATION
Use Case – Satellite Communications. It is cer-
tainly difficult to assess novel software systems in
satellite networks, mainly due to the complex network
dynamics, models and mechanisms that are involved
in such networks. Particularly, the difficulties are re-
lated to the asymmetric bandwidth capacities of satel-
lite links (due to the use of different radio-frequencies
and modulations) and the highly dynamic behaviour
of the mechanisms to make an efficient use of the
scarce and costly transmission resources. Usually,
these mechanisms tend to dynamically allocate band-
Dynamic Link Network Emulation: A Model-based Design
541

width depending on internal factors but, more impor-
tantly external factors (e.g., traffic crossing the net-
work) can also be crucial.
We focus on the DAMA mechanism for dynamic
link bandwidth assignation. As its name suggests, the
idea is to assign physical resources to nodes which
need to transmit traffic, according to their demands.
The physical resources are translated to bandwidth.
In real settings, in order to assign a given bandwidth,
the DAMA module may assign certain time slots and
frequencies to a particular node (station). We abstract
from this physical level and consider that the band-
width to physical resource assignation is done by a
proper translation module. Therefore, we are inter-
ested in the logical view of the algorithm, i.e., only
the bandwidth assignations and no deeper. It is im-
portant to note that in DAMA, nodes have minimal
and maximal bandwidth capacities assigned. Like-
wise, the satellite transponder has a maximal band-
width capacity that it can handle.
We assume that the behaviour of user traffic is not
predictable in advance, i.e., we do not deal with a
seasonal behavior of the network traffic. Thus, dy-
namic bandwidth assignations of the emulation sys-
tem are required. That is, the passing traffic modifies
the configuration of the emulation and consequently
the resulting modifications will have an effect on the
traffic going through the emulator. The goal of the
developed emulator is to reproduce the conditions de-
scribed above.
Experimental Settings & Results. For the link’s
bandwidth assignation we configured it by demand,
that is the link’s bandwidth gets assigned to whatever
the node requires up to a maximal allocation (as in
satellite communications). The results are presented
in Figure 5; as can be seen, the measured bandwidth
(with the bmw-ng utility) varies considerably w.r.t. the
demand.
0 20 40
60
80 100 120
0
10
20
30
Time (s)
Bandwidth (Mbps)
Demand Bandwidth
Observed Bandwidth
Figure 5: Varying emulated bandwidth by demand.
For the link’s delay emulation, we have varied the
desired delay between 5ms and 100ms. The assigna-
tion was made randomly by setting the delay queue
with a normal distribution (using the tc utility). The
results are presented in Figure 6; as can be seen, the
delays have been measured (with nping) and the his-
togram clearly shows a normal distribution, as ex-
pected. It is important to note that the measured delay
can be higher than 100ms since the processing time of
the equipment plays a role in the delay, as in the real
system.
0 20 40
60
80 100 120 140
0
5
10
15
20
Delay (ms)
Frequency
Observed Delay
Figure 6: Emulated delay histogram.
In this section, we have showcased how both link
parameters of interest (bandwidth and delay) can be
dynamically (and automatically) assigned in our em-
ulator; it can properly emulate a complex DAMA
scheme for satellite communications. Moreover, it
is capable of producing distinct traffic configurations
to thoroughly test novel engineered solutions. Addi-
tionally, the emulator’s design allows to easily interact
with real life software components.
6 CONCLUSION
In this paper, we have showcased the design and ar-
chitecture for a dynamic link network emulator. The
emulator is flexible and can emulate any existing soft-
ware; additionally, it can dynamically change the link
parameter values. Although the emulator is very flex-
ible, we note that the emulator cannot handle mo-
bile nodes, i.e., networks whose topology may change
(such as mobile ad-hoc networks).
As for future work, we plan to incorporate more
features into the architecture so that it becomes more
controllable and realistic, for example, we consider
incorporating link state scenarios to qualify the so-
lutions under different conditions (degraded links,
weather conditions, etc.). Additionally, we envision
incorporating mobility patterns in links to emulate
mobile networks. Finally, we plan to investigate var-
ious model-based simulation strategies for dynamic
ENASE 2022 - 17th International Conference on Evaluation of Novel Approaches to Software Engineering
542

link networks, to efficiently (faster than the emula-
tion) obtain static network snapshots with certain de-
sired properties; this should allow the emulator to pro-
vide interesting states/configurations to assess novel
network management solutions.
REFERENCES
Alsmadi, I., Zarrad, A., and Yassine, A. (2020). Mutation
testing to validate networks protocols. In 2020 IEEE
International Systems Conference (SysCon), pages 1–
8, Montreal, QC, Canada. IEEE.
Chan, M.-C., Chen, C., Huang, J.-X., Kuo, T., Yen, L.-H.,
and Tseng, C.-C. (2014). Opennet: A simulator for
software-defined wireless local area network. In 2014
IEEE Wireless Communications and Networking Con-
ference (WCNC), pages 3332–3336. IEEE.
Deng, B., Jiang, C., Yao, H., Guo, S., and Zhao, S. (2019).
The next generation heterogeneous satellite communi-
cation networks: Integration of resource management
and deep reinforcement learning. IEEE Wireless Com-
munications, 27(2):105–111.
Farias, F. N., Junior, A. d. O., da Costa, L. B., Pinheiro,
B. A., and Abel
´
em, A. J. (2019). vsdnemul: A
software-defined network emulator based on container
virtualization. arXiv preprint arXiv:1908.10980.
Gandhi, S., Singh, R. K., et al. (2021). Design and develop-
ment of dynamic satellite link emulator with experi-
mental validation. In 2021 12th International Confer-
ence on Computing Communication and Networking
Technologies (ICCCNT), pages 1–6. IEEE.
Giallorenzo, S., Mauro, J., Poulsen, M. G., and Siroky, F.
(2021). Virtualization costs: benchmarking contain-
ers and virtual machines against bare-metal. SN Com-
puter Science, 2(5):1–20.
Hemminger, S. et al. (2005). Network emulation with
netem. In Linux conf au, pages 18–23.
Henderson, T. R., Lacage, M., Riley, G. F., Dowell, C., and
Kopena, J. (2008). Network simulations with the ns-3
simulator. SIGCOMM demonstration, 14(14):527.
Horneber, J. and Hergenr
¨
oder, A. (2014). A survey on
testbeds and experimentation environments for wire-
less sensor networks. IEEE Communications Surveys
Tutorials, 16(4):1820–1838.
Kamp, P.-H. and Watson, R. N. (2000). Jails: Confining the
omnipotent root. In Proceedings of the 2nd Interna-
tional SANE Conference, volume 43, page 116.
Kaur, K., Singh, J., and Ghumman, N. S. (2014). Mininet as
software defined networking testing platform. In In-
ternational Conference on Communication, Comput-
ing & Systems (ICCCS), pages 139–42.
Khan, A. R., Bilal, S. M., and Othman, M. (2012). A per-
formance comparison of open source network simu-
lators for wireless networks. In 2012 IEEE Interna-
tional Conference on Control System, Computing and
Engineering, pages 34–38, Penang, Malaysia. IEEE.
Lai, J., Tian, J., Jiang, D., Sun, J., and Zhang, K. (2019).
Network emulation as a service (neaas): Towards a
cloud-based network emulation platform. In Song,
H. and Jiang, D., editors, Simulation Tools and Tech-
niques, pages 508–517, Cham. Springer International
Publishing.
Lantz, B., Heller, B., and McKeown, N. (2010). A net-
work in a laptop: rapid prototyping for software-
defined networks. In Proceedings of the 9th ACM SIG-
COMM Workshop on Hot Topics in Networks, pages
1–6. ACM.
Petersen, E., L
´
opez, J., Kushik, N., Poletti, C., and Zegh-
lache, D. (2020). On using smt-solvers for model-
ing and verifying dynamic network emulators: (work
in progress). In 19th IEEE International Symposium
on Network Computing and Applications, NCA 2020,
Cambridge, MA, USA, November 24-27, 2020, pages
1–3. IEEE.
Peuster, M., Kampmeyer, J., and Karl, H. (2018). Con-
tainernet 2.0: A rapid prototyping platform for hybrid
service function chains. In 2018 4th IEEE Conference
on Network Softwarization and Workshops (NetSoft),
pages 335–337. IEEE.
Shan, Q. (2021). Testing methods of computer software.
In 2020 International Conference on Data Processing
Techniques and Applications for Cyber-Physical Sys-
tems, pages 231–237. Springer.
Srisawai, S. and Uthayopas, P. (2018). Rapid building of
software-based sdn testbed using sdn owl. In 2018
22nd International Computer Science and Engineer-
ing Conference (ICSEC), pages 1–4. IEEE.
Stoller, M. H. R. R. L., Duerig, J., Guruprasad, S., Stack,
T., Webb, K., and Lepreau, J. (2008). Large-scale vir-
tualization in the emulab network testbed. In USENIX
Annual Technical Conference, Boston, MA.
Sultan, S., Ahmad, I., and Dimitriou, T. (2019). Container
security: Issues, challenges, and the road ahead. IEEE
Access, 7:52976–52996.
Sun, Z. and Chai, W. K. (2003). Satellite emulator for
ip networking based on linux. In 21st International
Communications Satellite Systems Conference and
Exhibit, page 2393.
Varga, A. (2001). Discrete event simulation system. In
Proc. of the European Simulation Multiconference
(ESM’2001), pages 1–7.
Wang, S.-Y., Chou, C.-L., and Yang, C.-M. (2013). Es-
tinet openflow network simulator and emulator. IEEE
Communications Magazine, 51(9):110–117.
Watada, J., Roy, A., Kadikar, R., Pham, H., and Xu, B.
(2019). Emerging trends, techniques and open is-
sues of containerization: A review. IEEE Access,
7:152443–152472.
Wulf, C., Willig, M., and G
¨
ohringer, D. (2021). A sur-
vey on hypervisor-based virtualization of embedded
reconfigurable systems. In 2021 31st International
Conference on Field-Programmable Logic and Appli-
cations (FPL), pages 249–256.
Dynamic Link Network Emulation: A Model-based Design
543