Dynamic Link Network Emulation: A Model-based Design

Erick Petersen

1,2

, Jorge L

opez

, Natalia Kushik

, Claude Poletti

and Djamal Zeghlache

Airbus Defence and Space, Issy-Les-Moulineaux, France

ecom SudParis, Institut Polytechnique de Paris, Palaiseau, France

{erick petersen, natalia.kushik, djamal.zeghlache}@telecom-sudparis.eu

Keywords:

Model-based Design, Dynamic Link Networks, Emulator, Trafﬁc 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 ﬁnal deployment. To achieve this goal, different existing

technologies are carefully combined to emulate link dynamicity, automatic trafﬁc generation, and overall

network device emulation. The emulator takes as an input a formal model of the network to emulate and

conﬁgures 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 ﬂexibility

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 ﬁnal 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 ﬁdelity (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 difﬁculties in creating various

network topologies, generating different trafﬁc sce-

narios, and testing the implementations under speciﬁc

conditions (network load or weather conditions that

may affect the radio-physical links in speciﬁc 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 speciﬁc

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 simpliﬁcation. 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 ﬁnal 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

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-

ﬁc 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 trafﬁc or the mod-

iﬁcation 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 trafﬁc

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-

ﬂow, from the installation to the conﬁguration 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 conﬁgured

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 brieﬂy 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-

ciﬁc 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 trafﬁc

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 conﬁgu-

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 ﬁdelity 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-

deﬁned 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 conﬁgure 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 ﬂexible 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 veriﬁ-

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

Trafﬁc

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

, . . . , p

), where V is a set of

nodes, E ⊆ V ×V is a set of directed edges, and p

is a

link parameter function p

: 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

maps an edge to a

non-empty set of integer values, i.e., p

: E → 2

where 2

denotes the power-set of N. An example

dynamic network is depicted in Fig. 1, and its model

N = (V, E, p

(e), p

(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)}

(e) = b((s, d)) =

(

{4, 5, 6}, if d = 2

{2, 3, 4}, otherwise

(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

b(e) = {4, 5, 6}, d(e) = {1, 2}

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 artiﬁcial 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 efﬁcient

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

APP

Bin/Lib/Runtime

OS + Kernel

Hardware

App

(a) Virtual Machine.

Hardware Infraestructure

Operating System + Kernel

Container Engine

App

Bin/Lib/Runtime

App

Bin/Lib/Runtime

App

Container

(b) Container.

Hardware Infraestructure

Operating System + Kernel

Hypervisor

Bin/Lib/Runtime

APP

Container 2

APP

App

Bin/Lib/Runtime

Kernel

APP

App

Bin/Lib/Runtime

Kernel

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 ﬂexibility of VMs and

the performance of containers, it requires applications

to be written speciﬁcally 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 efﬁciently, 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, ﬂexible and

conﬁgurable 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 veriﬁcation 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 speciﬁcations.

The Input/Output Processing Module fulﬁlls

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 (speciﬁcation) in terms

of ﬁrst order logic formulas veriﬁed throughout the

emulation by a satisﬁability modulo theories solver.

Indeed, the network topology can be veriﬁed 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 ﬁle 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

Containers

Virtual

Machines

Debugg

Emulator Manager

Input/Output

I/O Processing

Module

Topology

Validation

Traffic

Parser

Figure 3: Emulation Platform Architecture.

dynamic trafﬁc 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 ﬁrst step, it takes the input speciﬁcation 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

speciﬁcation). 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, ﬁle 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 ﬂexibility 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 Trafﬁc 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 ﬁrst step, packets are queued or dropped

depending on the size of the ﬁrst 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 speciﬁc time (propagation delay of the link)

in the second queue and then ﬁnally injected into the

network stack. This module uses the Linux Advanced

trafﬁc control tc, to control and set these properties

by using ﬁltering 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 trafﬁc and thus

use the same technique.

The Trafﬁc Generation Module is in charge of

converting the dynamic description of the trafﬁc (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 trafﬁc 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 trafﬁc. Addition-

ally, multiple instances of the same or different traf-

ﬁc 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 difﬁcult 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 difﬁculties 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 efﬁcient 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., trafﬁc 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 trafﬁc, 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 trafﬁc is not

predictable in advance, i.e., we do not deal with a

seasonal behavior of the network trafﬁc. Thus, dy-

namic bandwidth assignations of the emulation sys-

tem are required. That is, the passing trafﬁc modiﬁes

the conﬁguration of the emulation and consequently

the resulting modiﬁcations will have an effect on the

trafﬁc 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 conﬁgured 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

80 100 120

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

80 100 120 140

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 trafﬁc conﬁgurations

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 ﬂexible and can emulate any existing soft-

ware; additionally, it can dynamically change the link

parameter values. Although the emulator is very ﬂex-

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 efﬁciently (faster than the emula-

tion) obtain static network snapshots with certain de-

sired properties; this should allow the emulator to pro-

vide interesting states/conﬁgurations 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-deﬁned 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-deﬁned 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: Conﬁning 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 deﬁned 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-

deﬁned 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 openﬂow 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

reconﬁgurable 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