End of Studies Project Report: Ecole Nationale Des Sciences de L'informatique Laboratoire Cristal - P Ole RIM

Université de la Manouba
École Nationale des Sciences de l’Informatique

Laboratoire Cristal - Pôle RIM
End of Studies Project Report

Fulfillment of the requirement of the degree of
Computer Science Engineering Diploma
Theme :
Design and Implementation of a Wireless
Communication Networks Simulation Environment
Author :
Safaà Hachana
Supervisors :
Dr. Nicolas Montavont, RSM Dept., ENST-Bretagne (Rennes, France)

nicolas.montavont@enst-bretagne.fr
Mr. Mohamed Kassab, RIM-CRISTAL Lab., ENSI (Manouba, Tunisia) and
RSM Dept., ENST-Bretagne (Rennes, France)
mohamed.kassab@enst-bretagne.fr
Pedagogic advisors :
Pr. Abdelfattah Belghith, RIM-CRISTAL Lab., ENSI (Manouba, Tunisia)

abdelfattah.belghith@ensi.rnu.tn
Dr. Jean-Marie Bonnin, RSM Dept., ENST-Bretagne (Rennes, France)
jm.bonnin@enst-bretagne.fr
Presented on October, 2006

Abstract
Nowadays, the multiple advantages and facilities offered by wireless networks

are favoring their increasing popularity. Thus, wireless networks are widely
motivating researchers to develop new protocols, and optimize existing ones. Of
course, technical challenges do not lack since wireless networks pose considerable
problems.
Generally, newly developed protocols need to be tested, evaluated and read-
justed before becoming operative. In most cases, attempts to predict and ex-
trapolate the network performance in small-scale experimental test beds may
yield incomplete or contradictory outcomes. In a similar manner, application of
analytical methods is not sufficient to predict network performance and elimi-
nate protocol faults.
Accordingly, simulation is now considered as a tool of equal importance and
complementary to the analytical and experimental studies for investigating and
understanding the behaviour of various complex systems, notably wireless and
mobile networks.
Unfortunately, despite of the perceptible growth of wireless communications,
most of the existing simulation tools have been developed in the context of
wired networks, and do not satisfy requirements of wireless networks simulation
scenarios.
The proposed solution is the development of a new wireless networks discrete-
event simulation environment. It is realized in the framework of a collaborative
project in progress. And it is expected to be under openGL licence.
In this end of studies project report, we describe the kernel of simulation
development. Further, we give an example of integration of a standard proto-
col within the simulator protocols library, namely the implementation of the
standard IEEE802.11i.
Key words: discrete-event simulation, wireless communication network, IEEE
802.11i.
Design and Implementation of a Wireless Networks Simulator 0.0
Résumé
De nos jours, les réseaux sans fils marquent une popularité croissante grâce
aux nombreux avantages et apports qu’ils offrent. De ce fait, les chercheurs
en réseaux s’intéressent de plus en plus au monde des réseaux sans fils, en
développant de nouveaux protocoles et en essayant d’optimiser les protocoles
déjà existant. Naturellement, les défis techniques ne manquent pas, vu la com-
plexité considérable que présentent souvent les protocoles sans fil.
Généralement, les nouveaux protocoles doivent passer par une phase de test,
d’évaluation, et d’ajustement itératif avant de devenir opérationnel. Dans la plu-
part des cas, les tentatives de prédire le comportement et la performance d’un
protocole en se contentant d’une plateforme réelle à faible échelle n’aboutissent
pas, dans la mesure où elles peuvent donner des résultats incomplets, voir
même incohérents et contradictoires. L’application des méthodes analytiques
et mathématiques ne suffit pas non plus à éliminer les fautes des protocoles.
En conséquence, la simulation est considérée aujourd’hui comme un outil
d’importance égale et complémentaire aux études expérimentales et analytiques
dans l’analyse et la compréhension des comportements de plusieurs systèmes
complexes, y inclus les réseaux sans fil et mobiles.
Malheureusement, et malgré la submersion des réseaux de communication
sans fil, la grande majorité des outils de simulation disponibles actuellement,
ont été développés dans le contexte des réseaux filaires. De ce fait, ils s’adaptent
mal aux besoins de la simulation des réseaux sans fil.
Nous avons pu constater ce manque imminent de simulateurs spécialisés
dans les réseaux sans fils et les aspects de mobilités au cours de notre recherche
d’un simulateur pour y intégrer des méthodes de pré authentification rapides
dans les réseaux locaux sans fil sécurisés IEEE802.11i avec infrastructure. Ces
méthodes de pré authentification ont été développées dans le cadre d’un mastère
de recherche réalisé au laboratoire CRISTAL pôle RIM à l’ENSI en collaboration
avec le laboratoire ENST-Bretagne. Elles ont été évaluées sur une plateforme
réelle, mais une évaluation plus poussée par des outils de simulation s’est avérée
indispensable.
La solution proposée est le développement d’un nouvel environnement de
simulation à évènements discrets. Les dites méthodes y seront implémentées
ultérieurement en vu de l’évaluation de leur performances et leurs apports.
Etant une tache laborieuse et nécessitant la collaboration de plusieurs personnes
à long terme, le développement du nouveau simulateur s’intitule dans le cadre
d’un projet collaboratif et en progression continue dont le présent projet de fin
d’étude constitue la première étape. Le projet est destiné à être publié sous
licence OpenGL.
Dans ce rapport de projet de fin d’étude, nous exposons notre participation
dans le développement de ce simulateur de réseaux de télécommunication sans
fil. En effet, nous commençons par donner la terminologie de la simulation à
évènements discrets pour fournir au lecteur le bagage technique nécessaire à
fin de lui permettre de mieux assimiler le reste du rapport. Par la suite, nous
présentons une étude comparative entre trois simulateurs qui se trouvent être
des plus utilisés de nos jours. Cette étude permet de montrer les spécificités de
2
chaque simulateur, de ressortir leurs lacunes, et de mettre en évidence leur non

adaptabilité à la simulation des réseaux sans fils.
Dès lors, nous dégageons les différents besoins de la simulation des réseaux
sans fils. Nous décrivons ensuite la solution adoptée pour la conception du noyau
du simulateur, avant de donner un aperçu sur les conditions de réalisation et le
stade d’avancement dans le projet.
En dernière partie, nous donnons un exemple d’intégration d’un protocole
dans la bibliothèque de protocoles du simulateur, afin de mettre en évidence sa
modularité et son extensibilité, mais aussi de donner un aperçu sur l’avenir et
la continuité du projet. Le protocole choisit est le 802.11i, standard de l’IEEE
spécifiant les normes de sécurité dans les réseaux locaux sans fil. Ce protocole
s’est avéré un candidat privilégié car il nous sera d’une grande utilité dans
l’extension du projet.
Mots clé: simulation à évènements discrets, réseaux de communication sans
fil, IEEE 802.11i.
3
Dedication
To my parents: words are not expressive
To Salam : my sister and best friend
To MedAli et Touha: hoping that it will be a source of inspiration for them
End of Studies Project Report

October 2006,École Nationale des Sciences de l’Informatique
1
Greeting
First, I want to thank Dr. Nicolas Montavont for his faith in me and his sug-
gestions. He was really a continual source of learning during all our discussion
and meeting.
I would like to express my deepest gratitude to Mohamed Kassab, my friend
and supervisor for his good suggestions, his support, and his good mood.
I really appreciated the critical comments and beneficial suggestions from
my great Professor Abdelfattah Belghith.
A particular acknowledgement is for all my professors and teachers during
these latter three years during my studies within the ENSI. They were an inex-
haustible source of learning.
I would like to thank Amine Dhraief for his precious help at the starting of
this project, and particularly in NS-2 discovery and study.
I would like to thank all those who works in the ENST-Bretagne for the
cordial reception they reserved to us.
All my thankfulness is for my friends at Rennes. They provided me with a
great comfort with their kindness, favour, generosity and humour. My thoughts
go to Neila, Rayène, Meriem, Anis and all others.
For all my good friends in the ENSI: Sofien, Hamdi, Med, Youssef, Dina,
Zied, Fadi, Walid, Ramsis and all others: I’ll never forget you.
My thoughts go to all those who have been a real help for me, my best
friends: Emeni, Baha, Sana, Amine, Faten, . . .
Finally, my special thank goes to Attoufa and Mabrouk, for their continuous
support, to aunt Fawzia and uncle Rachid, and to all my big family’s members.
I love you.
Safaà Hachana
2
Contents
Introduction 8
I State of the art 11
1 Terminology of discrete-event simulation 12

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2.1 Discrete-event simulation . . . . . . . . . . . . . . . . . . 12
1.3 Components and structure . . . . . . . . . . . . . . . . . . . . . . 13
1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2 Comparative study of three available simulation environments 16

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2 Network simulation tool’s evaluation criteria . . . . . . . . . . . . 17
2.3 NS-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.1 Presentation . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.2 NS-2 monitoring support . . . . . . . . . . . . . . . . . . 19
2.3.3 NS-2 internal architecture . . . . . . . . . . . . . . . . . . 19
2.3.4 Evaluation and summary of NS-2 features . . . . . . . . . 25
2.3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4 OMNeT++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4.1 Presentation . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4.2 OMNeT++ monitoring support . . . . . . . . . . . . . . . 28
2.4.3 OMNeT++ internal architecture . . . . . . . . . . . . . . 29
2.4.4 Evaluation and summary of OMNeT++ features . . . . . 34
3
2.4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.5 SimulX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.5.1 Presentation . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.5.2 SimulX monitoring support . . . . . . . . . . . . . . . . . 36
2.5.3 SimulX internal architecture . . . . . . . . . . . . . . . . 37
2.5.4 Evaluation and summary of SimulX features . . . . . . . 40
2.5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
II Simulator Kernel 42
3 Specification of requirements 43
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2 Functional requirements . . . . . . . . . . . . . . . . . . . . . . . 44
3.3 Non functional requirements . . . . . . . . . . . . . . . . . . . . . 46
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4 Simulator Design 50
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.2 Classes diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.2.1 Simulation kernel classes . . . . . . . . . . . . . . . . . . . 52
4.2.2 Topology devices classes . . . . . . . . . . . . . . . . . . . 57
4.2.3 Protocols and services library . . . . . . . . . . . . . . . . 63
4.3 Sequence diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.3.1 Sending a packet from one node to another node . . . . . 64
4.3.2 Running a timer in a protocol . . . . . . . . . . . . . . . . 65
4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5 Realization of the simulator kernel 67

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.2 Hardware environment . . . . . . . . . . . . . . . . . . . . . . . . 67
5.3 Software environment . . . . . . . . . . . . . . . . . . . . . . . . 68
5.4 Overview of the current state of the simulator . . . . . . . . . . . 69
5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4
III Implementation of IEEE802.11i in the simulator 73
6 IEEE802.11i standard description 75

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.2 The 802.1X authentication framework . . . . . . . . . . . . . . . 76
6.2.1 802.1X entities . . . . . . . . . . . . . . . . . . . . . . . . 76
6.2.2 The notion of port . . . . . . . . . . . . . . . . . . . . . . 77
6.2.3 Protocols used during 802.1X authentication . . . . . . . 77
6.2.4 Upper layer authentication (ULA) . . . . . . . . . . . . . 82
6.3 802.11i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.3.1 RSNA Establishment Procedure . . . . . . . . . . . . . . 83
6.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
7 Conception and integration of the standard into the simulator 87

7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
7.2 IEEE802.1X entities design in the simulator . . . . . . . . . . . . 88
7.3 IEEE 802.11i protocols classes . . . . . . . . . . . . . . . . . . . . 88
7.3.1 eap, eap hdr, eapol and eapol hdr classes . . . . . . . . . 89
7.3.2 radius, radius hdr, eap tls and eap tls hdr classes . . . . 90
7.3.3 The Class pae . . . . . . . . . . . . . . . . . . . . . . . . 90
7.4 Realization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
7.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
8 Conclusion and prospects 93
5
List of Figures
2.1 Scheduler by NS-2 . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.2 Event by NS-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3 Handler by NS-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.4 Classic and Mobile Nodes structures in NS . . . . . . . . . . . . 24
2.5 ARP client by OMNeT++ . . . . . . . . . . . . . . . . . . . . . . 31
2.6 Ethernet interface in ARP client by OMNeT++ . . . . . . . . . 31
2.7 Graphical User Interface of SimulX . . . . . . . . . . . . . . . . . 37
2.8 Nodes classes’hierarchy in SimulX . . . . . . . . . . . . . . . . . 38
3.1 Use case1: Researcher requirements . . . . . . . . . . . . . . . . . 47

3.2 Use case1: Student requirements . . . . . . . . . . . . . . . . . . 48
3.3 Use case1: Developer requirements . . . . . . . . . . . . . . . . . 48
4.1 Overview of the classes diagram . . . . . . . . . . . . . . . . . . . 51

4.2 The class event . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.3 The class message . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.4 The class timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.5 The class scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.6 The class handler . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.7 The class header . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.8 The class equipment . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.9 The class protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.10 The class service . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.11 The class link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.12 The class Simplelink . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.13 The class Multipointlink . . . . . . . . . . . . . . . . . . . . . . . 63
6
4.14 Topology of the first sequence diagram . . . . . . . . . . . . . . . 64

4.15 Sequence diagram1: message exchange . . . . . . . . . . . . . . 65
4.16 Topology of the second sequence diagram . . . . . . . . . . . . . 66
4.17 Sequence diagram2: timer . . . . . . . . . . . . . . . . . . . . . . 66
5.1 Overview of the present state of the simulator . . . . . . . . . . . 70

5.2 A simple equipment structure . . . . . . . . . . . . . . . . . . . . 71
5.3 AP supporting IAPP modelling in the simulator . . . . . . . . . 71
6.1 Authorized and unauthorized port . . . . . . . . . . . . . . . . . 77

6.2 EAP packet format . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.3 EAPOL packet format . . . . . . . . . . . . . . . . . . . . . . . . 79
6.4 Key Descriptor packet format . . . . . . . . . . . . . . . . . . . . 80
6.5 RADIUS packet format . . . . . . . . . . . . . . . . . . . . . . . 81
6.6 RSNA Establishment Procedures . . . . . . . . . . . . . . . . . . 84
7.1 Adopted structure for entities involved in 802.11i authentication

procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
7.2 EAP modeling in the simulator: eap and eap hdr classes . . . . . 89
7.3 EAPOL modeling in the simulator: eapol and eapol hdr classes . 90
7.4 RADIUS modeling in the simulator: radius and radius hdr classes 91
7.5 EAP TLS modeling in the simulator: eap tls and eap tls hdr classes 91
7.6 Port Access Entity modeling in the simulator . . . . . . . . . . . 91
7
Introduction
Nowadays, the trend is toward the use of wireless and mobile networks as re-
quired by some submerging applications and services. Several forms of mobile
computing are becoming more and more popular,such as WLAN802.11 with
infrastructure, Ad-hoc networks, WMAN802.116, etc.
Indeed, the multiple advantages and facilities offered by wireless networks
favor their increasing popularity. For instance, they provide mobility and in-
dependency from location and infrastructures. Moreover, a wireless device can
dynamically move within multiple locations while maintaining moving trans-
parency from application point of view, instead of being hardwired to a single
location (or IP address). Likewise, communication among a set of mobile units
can be established spontaneously, without using any existing network infras-
tructure. So, wireless networks are more resistant and allow fast recovery in
case of disasters.
Thus, identified as one of the most important technologies of the 21st cen-
tury, and considered as a key technology for the future, wireless networks are
widely motivating researchers to develop new protocols, and optimize existing
ones. For example, Mobile-IP is a protocol that have been suggested to handle
message routing via internet in mobility scenarios.
Of course, technical challenges do not lack. As a matter of fact, wireless net-
works pose considerable problems since they may operate in hostile and varying
environment. They also present complications of medium access as wireless
channel is a shared resource. Furthermore, wireless networks may connect to
Internet whereas Internet was not designed to support mobility features. For all
these raisons, protocols designed for this kind of environment are often complex.
Generally, newly developed protocols need to be tested, evaluated and read-
justed before becoming operative. However, in front of their rapid proliferation,
and the reduced time to market, predicting network performance and eliminat-
ing protocol faults have become an extremely difficult task. Moreover, this task
is made harder with regard to the fusion of communication technologies and
their interference leading to the rapid growth of networks.
In most cases, attempts to predict and extrapolate the network performance
in small-scale experimental test beds may yield incomplete or contradictory out-
comes. In a similar manner, application of analytical methods is also not feasible
due to factors such as complex channel access protocols, node mobility, channel
propagation properties, radio characteristics, and multitude of interactions.
Accordingly, simulation is now considered as a tool of equal importance and
complementary to the analytical and experimental studies for investigating and
understanding the behaviour of various complex systems, notably wireless and
mobile networks.
Unfortunately, despite of the perceptible growth of wireless communications,
most of the existing simulation tools have been developed in the context of wired
networks that include LAN, TCP, IP and ATM simulators. Research in wire-
less network simulation has come relatively late. Henceforth, most of famous
network simulators have added modules for simulating wireless topologies. Nev-
8
ertheless, wireless and wired networks differ in fundamental ways such as the
signal interference and attenuation, and also broadcast nature of wireless ra-
dio transmission. In addition, wireless and wired networks have not the same
interests (e.g. Handoff for wireless and mobile communications).
Besides, we had the occasion to experiment this lack of simulators specialized
in, or at least which implement suitably wireless network protocols and espe-
cially WLAN with infrastructure protocols. That is to say, at the beginning
of this project, the aim was the evaluation of fast pre-authentication methods
in IEEE 802.11 LAN with infrastructure, by simulation mean. These methods
were developed within the framework of the research works in the collabora-
tion between the pole RIM of the laboratory CRYSTAL in the ENSI and RSM
department in ENST-Bretagne’s laboratory.
The pre-authentication methods[11] were tested in small-scale actual test
bed[12]. However, their implementation in a simulation tool remains imperative
to establish exact evaluation of their contribution in the improvement of the
standard protocol. Through our quest of a well established available simulation
tool, which provides the necessary protocols library, and that enables a good
extensibility, we realized that such a software is not available among free and
open source simulation tools.
Consequently, we were constrained to modify the purposes of the project.
Henceforth, the aim of the project described in this report is the development
of a new wireless networks simulation environment. The evaluation of the men-
tioned pre-authentication methods is to be completed within the extension of
the project, using the new developed simulator described here.
However, the development of a wireless networks simulation environment is a
laborious task that requires a lot of time and the collaboration of many persons.
This is why; it will be a collaborative project in progress. The work achieved
in the framework of this end of studies project, and described in this document
concerns only the development of the core of simulation and the integration
of IEEE802.11i protocol into the newly developed simulator. We give a brief
overview of the tasks of other collaborators and the continuity of the project.
From this analysis, it arises that a new wireless simulation tool is widely
welcomed. The second part describes the kernel of simulation development
steps. In the second chapter, we fix and determine the objectives of the simulator
we are planning to develop regarding to the previous analysis and the initial
requirements The third chapter explains the basics of our solution’s conception,
and shows in details the class diagram. It concludes with some simple sequence
diagrams that show more clearly how does the tool work. We give a brief glance
at the realization and implementation steps for the core of network simulator
in the following chapter. We conclude the fourth chapter by discussing further
work and next steps of the project.
This makes the transition with the next and last part which describes the
implementation of the IEEE 802.11i security protocol for wireless LAN. This
part is made of two chapters. The first one is consecrated to the IEEE 802.11i
standard protocol description, whereas the second chapter presents the concep-
tion and integration of the protocol into the simulator. This will constitute an
example of exploitation of the core of simulation newly developed.
9
We conclude by exposing the future prospects of the simulator.
10
Part I
State of the art
11
Chapter 1
Terminology of
discrete-event simulation
1.1 Introduction
This section aims at introducing discrete-event simulation concept in order to
provide the reader with basic notions and necessary technical background to
understand in more details next chapters. This introductive part begins with
defining the simulation, before explaining its structural components, function-
ality, and generated data.
1.2 Definition
In general concept, simulation can be defined as ”the process of designing a
model of a real system and conducting experiments with this model for the
purpose either of understanding the behavior of the system or of evaluating
various strategies, within the limits imposed by a set of criteria, for the operation
of the system”[15].
1.2.1 Discrete-event simulation

The difference and the power of discrete-event simulation is the ability to mimic
the dynamics of a real system. So we will admit that it is ”the process of design-
ing a dynamic model of an actual dynamic system”[8] for the same purposes.
Indeed, many models of simulation, in spite of including high-powered opti-
mization models, cannot take in account the dynamic aspect of a real studied
12
system. It is the ability to mimic dynamics that gives discrete-event simulation

its unique way to analyze results. Moreover, since communication networks can
be considered as particularly dynamic systems, discrete-event simulation seems
to be the best way for modeling them.
1.3 Components and structure

There is wide panoply of discrete-event simulation tools. Still, all of them,
regardless of how complex they can be, are build on a basic structure, and
contain the same basic components that we will briefly describe in this section.
Entities :
Entities are requisite components since they are the ones who cause the changes
in the state of the system by generating events, and eventually handling them.
Indeed, if there are no active entities in the system, the simulation will be
stopped. Entities are characterized by attributes, determinant to understand
the behavior of the entity. Referring to communication networks as example of
modeled systems, an entity may be a node, a link or any other entity that is
likely to influence the system state. We may also have a hierarchy of entities
(e.g. node and protocolar layers which constitute part of the node).
Activities :
Entities run the simulation by their activities. In fact, interacting with activities,
entities create events. So activities are process and logic in the simulation. We
can distinguish three major types of activities in simulation: delays, queues and
logic. The delay is when we postpone an entity for a definite period of time.
The period may be a constant or a randomly generated value. For instance, in
network simulation, a node that has to wait for a timer to expire is considered
as a delayed entity. Queues are places were entities wait for unspecified period
of time, which depends on other parameters. As a matter of fact, entity may
be waiting for a resource to be liberated or for given system condition to occur.
In our example, one of the several queues we may need is a queue as buffer for
packets on a level with some protocol layers, and also queues in routers. This
latter kind of queue may be managed with different policies. Logic activities
allow the entity to affect the state of the system through the manipulation of
state variables. For example, treatments made in a protocol layer are logic
activities related to the entity which is the layer it self.
Events :
Events are conditions that occur at a point of time witch causes changes in the
state of the system. The definition of what will be an event is a crucial choice
when modeling a system. An entity interacts with activity to create events. For
instance, when an entity starts a delay, an event is scheduled in the calendar to
occur.
13
Calendar :
It is an overriding component for the discrete-event simulation. The calendar is a
list of events that are scheduled to occur in the future. In every simulation there
is only one calendar of future events and it’s generally ordered by the earliest
scheduled time first. It may have different structure, more or less optimized
structure that influences over simulator performance and execution time. Still,
in all cases, at any given point in time, every event that has already been
scheduled to occur in the future is held on the calendar.
Resources :
As we showed above, entities may be waiting for resources. These latter repre-
sent anything that has a restricted capacity. Common examples in communica-
tion networks include traffic intersections, links, etc In the course of simulation,
we can track the key statistics of each of these resources including utilization
and costs.
Global variables :
A global variable is a variable that is available to the entire model at all times.
It can track just about anything that is of interest to the entire simulation. We
distinguish two kind of global variables: those which help as to configure the
problem as a schedule, and those which collect revenue information as a trace
file can be.
System state and global variables :

The key indicator of a system state in simulation is the current time of simu-
lation. This variable is updated every time an entity takes an event from the
calendar. Thus, we should make difference between the actual time and the
simulation time. Based on this observation, the system state is the set of values
all variable systems take at a given point of simulation’s time.
Random number generator :

Every simulation package has one or more random number generator. A ran-
dom number generator is a software component that generates numbers used in
sampling random distributions, and statistical law generation.
Statistics collectors :
The purpose of a simulation is to get statistics that will be indicators about
the performance of the studied system. Statistic collectors are the part of the
simulation that collects statistics, such as state of resources, or the value of
global variable, or certain performance statistics based on attributes of the en-
tity. There are three different types of statistics we can collect: counts (e.g.
the number of lost packets on a link), time-persistent (e.g. resource utilization),
and tallies (e.g. queue residence time of a packet). Generally, we rely on these
statistics to optimize the modeled system.
14
1.4 Conclusion
Simulation is a powerful tool if understood and properly used. Regardless of
how complex a system may be, it is possible to create a model that will evaluate
it. However, the most complex a system is, the longer it takes to model, run and
evaluate. In the next chapter, we will present and compare three commonly used
network simulation tools of different levels of complexity and different purposes.
15
Chapter 2
Comparative study of three

available simulation
environments
2.1 Introduction
There are numerous network simulation tools on the market today, both com-
mercial and non-commercial ones. This chapter gives a brief overview by picking
three of the most important or most representative ones. Among them, NS and
OMNeT++ deserve the most attention, as they are the most widely accepted
and most mature packages. The third one, ’SimulX’, is a wireless communica-
tion simulator under development, not published yet. In this section, we keep
a glance at the general features of the studied simulators, but we are especially
interested in the simulation core of each of them trying to underline its advan-
tages and drawbacks. The ultimate purpose of this section is to identify the
properties of simulation environment that allows it to be the most appropriate
to study performance and behaviour of new protocols of mobility and wireless
networks.
16
2.2 Network simulation tool’s evaluation crite-

ria
In this section we summarize the most important criteria of evaluation of sim-
ulation tool studied later. First, there are several simulation types, but we are
mainly interested in discrete-event simulation. Second, we focus on flexibility,
modifiability, and extensibility issues as we look for truly open modular soft-
ware design. Such a design allows upgrading new protocols, substituting or
modifying old protocols, and including new devices and modules in the simula-
tor. Moreover, it makes possible to select a desired level of detail. For this issue
components can be easily switched on and off. In other words, since we have
the intention to run studies at different scales of resolution, it could be very
useful in practice to have a simulator offering the possibility to switch off most
of the microscopic details (e.g., the OSI chain inside the nodes). Furthermore,
scalability is a critical issue. In principle all simulators allow to add more nodes
and to increase the computational burden associated to the traffic patterns and
to the other dynamic aspects of the network (mobility, appearing/disappearing
of nodes, broken paths, etc.). However, in practice some simulators scale much
better than others. It depends on memory and CPU resources management
efficiency. Besides, the availability of a suitable documentation is always appre-
ciated. Of course, the documentation must be synchronised with the simulator
version.
Another important criterion of evaluation of network simulator is monitor-
ing support. All simulators have some mechanism for the generation of network
topologies. Among the several possibilities, there are the use of special script
or configuration languages, manually edited numerical files, and graphical inter-
faces. During the execution it can be extremely useful to monitor the network
dynamics on a per-flow, per-node, or, more in general, on the basis of some
aggregation criteria. Monitoring can helped by the availability of graphical in-
terfaces. The results of monitoring can be also dumped on files to generate
traces that can be used for further comparisons or for re-play the simulation for
more careful studies of the generated dynamics.
In some fortunate cases a special tool for the automatic controlled gener-
ation of random topologies is provided with the simulator. Some simulators
do not easily permit the creation of hierarchical topologies, admitting only flat
topologies.
Furthermore, a simulator coming with a rich set of already implemented
and tested modules is preferable to a simulator coming with no implemented
modules. However, according to the sensitivity of the obtained results to the
model characteristics, it is clear that not only the number but also the quality of
the implemented modules is equally important. The OSI modules that are really
interesting for us are primarily those relative to wireless networking protocols,
including mobility models, and radio propagation models such as open space
with ground reflection, shadowing effect, etc. It is also very important to have
a reliable implementation.
In addition, we interest in simulators’ support for generation and manage-
17
ment of traffic profiles. In order to generate data traffic, it is in general nec-

essary to use generators of data according to some specific target distribution
(e.g. Poisson or derived from the observation of real traffic). Good simulators
usually come either with a wide set of such traffic generators. When possible,
it might be interesting to carry out trace-driven simulation, that is, simulations
using as input a time-ordered record of events, it means a trace from a real
system. Actually, these characteristics refer more to emulators than simulators.
On the other side, it is also important to have tools to profile the generated
traffic and to compute the statistics necessary to draw conclusions.
The level of acceptance of the simulator by the scientific community is an-
other factor of selection of simulation tool. It is clear that choosing a simulator
widely in use and accepted by the community allows producing results which
are easier to compare with those present in the literature.
Finally, we interest in the type of software license. There are commercial
and public domain simulation tools. We focus only on free and open source
software.
2.3 NS-2
1
2.3.1 Presentation
The NS network simulator, from U.C. Berkeley/LBNL, is an object-oriented dis-
crete event simulator targeted at networking research and available in the public
domain. Its first version (NS-1) began in 1989 as a variant of the REAL network
simulator and was developed by the Network Research Group at the Lawrence
Berkeley National Laboratory (LBNL), USA. Its development was then part of
the VINT project, supported by DARPA, at LBNL, Xerox PARC, and UCB,
under which NS version 2.0 (NS-2) was released, evolving substantially from the
first version. The aim of the VINT was not to design a new network simulator,
but to unify the effort of all people working in the research field of network
simulation. The result is that NS-2 is widely used in the networking research
community and has found large acceptance as a tool to experiment new ideas,
protocols and distributed algorithms. Currently NS-2 development is still sup-
ported through DARPA. NS has always included substantial contributions from
other researchers, including wireless code for both mobile ad hoc networks and
wireless LANs from the UCB Daedelus and CMU Monarch projects and Sun
Microsystems.
1 The Network Simulator - ns-2 Official web site, http://www.isi.edu/nsnam/ns/
18
2.3.2 NS-2 monitoring support
Input
The user creates a topology through writing an OTcl file, in which he can define
arbitrary network topologies. The topology is composed of routers, links and
shared media by listing the network nodes and edges. OTcl is the object oriented
extension of Tcl (Tool Command Language), which is an interpreted language.
So, it is obvious that the user of NS-2 must master the OTcl language. Another
alternative is possible but seldom used: that is to specify the simulator entry
using some network generators developed for NS-2 (Tiers and GT-ITM).
Output
For collecting output or trace data on a simulation, NS-2 uses both traces and
monitors. Traces are records of each individual packet as it arrives, departs, or
is dropped at a link or queue. Whereas monitors are record counts of various
interesting quantities that can be associated to both packets and flows such as
packet and byte arrivals, departures, etc.
The Network Animator (NAM), is a Tcl/TK based animation tool that can be
used for viewing NS-2 trace files for post-processing, analysis and replay of sim-
ulations (actually NAM can be used with any simulator, as long as data formats
are respected). Still in terms of graphical tools to describe simulation scenarios
and analyze or visualize simulation trace files, NS-2 cannot score positively.
2.3.3 NS-2 internal architecture
Duality C++ - OTcl
NS-2’s code source is split between C++ for its core engine and OTcl, the object
extension to Tcl, for both the core engine and configuration and simulation
scripts. The combination of the two languages is supposed to offer a sort of
compromise between performance and ease of use as the first one (C++) is
compiled whereas the second (OTcl) is an interpreted language. The package
provides a compiled class hierarchy of objects written in C++ and an interpreted
class hierarchy of objects written in OTcl related to the compiled ones. The
user creates new objects through the OTcl interpreter. New objects are closely
mirrored by a corresponding object in the compiled hierarchy. Tcl procedures
are used to provide flexible and powerful control over the simulation (start and
stop events, network failure, statistic gathering and network configuration). The
OTcl interpreter provides commands to create the networks topology of links
and nodes and the agents associated with nodes.
In the next tow paragraphs, we’ll show in more details successively the struc-
ture of the compiled and interpreted class hierarchies.
19
Simulator kernel
2
From the description of the most important C++ classes in the hierarchy of
NS-2, we will reconstitute an obvious view of how the simulation core operates.
Simulator
A simulation script begins by creating an instance of the OTcl class Sim-
ulator. It will be the unique instance of this class during the whole sim-
ulation. The simulation is configured, controlled and operated through
the use of interfaces provided by this class. The class provides procedures
to create and manage the topology, to initialize the packet format and to
choose the scheduler. It stores internally references to each element of the
topology. The user creates the topology using OTcl through the use of
the stand alone class node and link that provide a few simple primitives.
Scheduler
Being an event driven-simulator, NS-2 needs a scheduler (Calendar) for
the events’ management. Scheduler is a C++ class. The scheduler man-
ages a data structure of Events (insert, drop, remove, handle...). It runs by
selecting the earliest event, giving it to its handler, and advancing the sim-
ulation time. After the handler has executed the event to completion (no
partial exec, no pre-emption), the scheduler returns to dispatch the next
event. The scheduler is the only object in the simulation that can advance
the time. There is only one event in execution at any given time. Simul-
taneous events are executed on a first scheduled-first dispatched manner.
That means the tow events are executed successively, but at the same
simulation time. There is only one instance of Scheduler in one instance
of Simulator. So that event’s scheduling is managed in a centralised way
in NS-2. All other objects of the simulation which are likely to generate
events have a reference to the scheduler instance. The choice of the data
structure is quite important for the simulator performance. NS-2 defines
four scheduler types using four different data structures which are: List
(a simple linked list), Calendar[9], Heap, and RealTime (borrowed from
MaRS-2.0 simulator). All schedulers should give the same order of dis-
patching given the same in put. However, only Calendar works correctly.
It is set as the scheduler by default. The calendar queue is a special in-
dexed list that assures an optimistic management of event. It uses a data
structure analogous to a one-year desk calendar, in which events on the
same month/day of multiple years can be recorded in one day.
Event
Defining what will be the considered as an ”event” is a crucial choice
in a discrete-event simulator. In NS-2 ”Event” is a C++ class. Among
the attributes of this class we find a pointer on the next event, a pointer
on an instance of the class ”Handler”, and ”time”. The next event is
used to chain the list of events managed by the scheduler. The handler
is the object that will handle the event when it will be removed from the
scheduler’s list. The time represents the date in time of simulation, in
2 ns Notes and Documentation, http://www.isi.edu/nsnam/ns/doc/index.html
20
Figure 2.1: Scheduler by NS-2
Figure 2.2: Event by NS-2
which the event must be consumed. Many types of events are defined
such as:
– Packet is a C++ class. It’s the fundamental unit of exchange between
objects in simulation and also the most frequently used event.
– AtEvent is a C++ class. It represents a Tcl procedure execution
scheduled to occur at a particular time. The procedure may be de-
fined in an input Tcl script, or in NS core code.
– ChannelDelayEvent: is a C++ class. It is used to schedule the re-
ception of affected mobile nodes (physical layer) of a packet within a
wireless channel.
Handler
Handler is the parent class of all objects that are likely to handle an event
in the simulator. As we showed above, an event has a pointer to the han-
dler to call when it is ready to be consumed. When an event’s scheduled
time arrives, it is passed to handle() method of the handler which must
consume it. There are several kinds of event handlers such as NsObject,
TimerHandler, AtHandler, MacTimer, etc.For instance NsObjects such as
Mac (class that represents the MAC layer), LL, Agent, Classifier, etc, ma-
nipulate event of type ”packet”. Another example of handlers is that of
AtHandler. They are specialized in Atevent handling. The last example
of Handler we will see is TimerHandler. Those objects represent timers
in a network and execute neither Atevent, nor Packets. They only block
21
Figure 2.3: Handler by NS-2
an object for a period of time, and advance time of simulation. Figure 2.3
shows a portion of the class hierarchy that inherits from Handler.
Event scheduling and management
An Event is scheduled in the schedule list, with the following parameters: a

reference to the next object that will handle it, and event’s delay. The scheduler
fills in the event’s ID and time fields. The time at which the event is supposed
happen ”time” is set to ”current time + delay”. Finally the event is inserted
into the list. Simulator removes the earliest event from the list, and dispatches
it. In other terms, it advances the simulation time to time-of-event, and wakes
up the simulation object concerned by handling the event.
Topology
3
The network model represents the interconnection of network elements. It
consists of nodes and links. In the next paragraphs we’ll see how does NS-2
models its network elements.
Classic node structure

The function of a node is to receive a packet, to examine it and map it
to the relevant outgoing interfaces. A node is composed of two important
NsObjects: Classifier and Agent. Each classifier in a node performs a par-
ticular function, looking at a specific portion of the packet and forwarding
it to the next classifier.
3 ns-2.29 Notes and Documentation, http://www.isi.edu/nsnam/ns/doc/index.html
22
Agents are another important type of components of a node: they model

endpoints of the network where packets are constructed, processed or con-
sumed. Users create new sources or sinks from the class Agent. NS cur-
rently supports various TCP agents, UDP, and other general protocols,
including RTP, RTCP, and SRM. Therefore network and transport pro-
tocol behavior are simulated by attaching the appropriate agents to the
interested nodes. Single or multiple traffic generators, including statistical
generators and other typical generators such as FTP and Telnet, can be
attached to any agent of the node.
Link structure Links are modeled either as simplex or duplex links with
a predefined capacity, delay, and queuing discipline. In addition, links
can be torn down or restored at any point in time during the simulation,
simulating link failures. Links are built from a sequence of Connectors
objects. The data structure representing a link is composed of a queue
of connector objects, its head, the type of link, the ttl (time to live),
and an object that processes link drops. Connectors receive a packet,
perform a function, and send the packet to the next connector or to the
drop object. Various kinds of links are supported, e.g. point-to-point,
broadcast, wireless. The queues are considered as part of a link. NS-2
allows the simulation of various queuing and packet scheduling disciplines.
Provided C++ classes include: drop-tail (FIFO) queuing, random early
detection (RED) buffer management, CBQ (priority and round-robin),
weighted fair queuing (WFQ), stochastic fair queuing (SFQ) and deficit
round-robin (DRR). The user has to specify the routing strategy (static,
dynamic) and protocol to be used.
Mobile node structure and wireless networking features At the beginning,
NS-2 was a transport protocol simulator. Simulating wireless and mobile
networks wasn’t in his purposes. Recently, the proliferation of wireless
communication imposed the adaptation of the simulator with changes. NS
has included code for simulating wireless network for both mobile ad hoc
networks and wireless LANs from the UCB Daedelus and CMU Monarch
projects and Sun Microsystems. The class MobileNode extends the basic
capability of the Node object class by adding functionalities of a wireless
and mobile node like ability to move within a given topology, ability to
receive and transmit signals to and from a network interface with an an-
tenna, etc. In addition, a MobileNode is not connected by means of Links
to other nodes or mobile nodes. MobileNode is a split object. The mobility
features, including node movement, periodic position updates, maintain-
ing topology boundary etc. are implemented in C++, while plumbing
of network components within MobileNode itself (like classifiers, MAC,
Channel, etc.) are implemented in OTcl. The network stack for a mobile
node consists of:
1. a link layer
2. an address resolution protocol (ARP) module connected to the link
layer
3. interface priority queue which gives priority to routing protocol pack-
ets and supports running a filter over all packets in the queue
23
Figure 2.4: Classic and Mobile Nodes structures in NS
4. a MAC layer implementing the specifications of the standard IEEE

802.11
5. a Tap Agent which receives, if allowed, all the packets from the MAC
layer before address filtering is done
6. a network interface which serves as a hardware interface used by
the mobile node to access the wireless channel. The network in-
terface is subject to collisions and to the radio propagation model,
which, in turn, receives the packets transmitted by node interfaces
to their wireless channel. The interface stamps each transmitted
packet with meta-data related to the transmitting interface, like the
transmission power, wavelength etc. This meta-data in the packet
header is used in turn by the propagation model in receiving net-
work interface to determine if the packet has minimum power to
be received and/or captured and/or detected (carrier sense) by the
receiving node. The model approximates the DSSS radio interface
(LucentWaveLan direct-sequence spread-spectrum).
The radio propagation model uses a shadowing model, and Two Ray
Ground model. Antennas used by the mobile nodes are assumed to be
omni-directional and with unity gain. Four ad-hoc routing protocols are
currently supported. Concerning the simulation core, there are no great
changes excepting the creation of a new class MoveEvent that inherits
from event. Here we have a schematic representation of the MobileNode
by NS-2. Notice that the NS-2 architecture tends to get closer to the OSI
model. Figure 2.4 is a schematic representation of the MobileNode by
NS-2. Notice that the NS-2 architecture tends to get closer to the OSI
model45 .
4 ns-2.29 Notes and Documentation, http://www.isi.edu/nsnam/ns/doc/index.html

5 NS-2 versus NS-1,http://www.isi.edu/nsnam/ns/ns-1-2.html
24
Model libraries and available models
At the time being, NS-2 has a large number of protocol models, mostly centered
on TCP/IP. It is well-suited for packets switched networks and wireless ad-
hoc networks, and is used mostly for small scale simulations of queuing and
routing algorithms, transport protocols, congestion control, and some multicast
related work. It provides substantial support for simulation of TCP, routing,
and multicast protocols over wired networks. Various types of applications can
be simulated. Among them are FTP, Telnet, and HTTP, which use TCP as
the underlying transport protocol, and applications requiring a constant bit
rate (CBR) traffic pattern, which use the UDP transport protocol. For the
purpose of traffic generation NS-2 provides an exponential on/off distribution
and it allows also generating traffic according to a trace file. Packet losses
are simulated by buffer overflows in routers, which is also the dominant way
packets get lost in the Internet. Other packet losses are related to error models
where the unit could be packet, bit or time based. Supported routing features
include asymmetric routing, multi-path routing, link-state and distance vector
algorithms, multicast routing, and several ad hoc algorithms.
2.3.4 Evaluation and summary of NS-2 features
Extensibility
From the short description of its architecture given above, it is quite clear that
NS-2 is rather complex software. Adding new components and/or modifying
existing ones necessarily involve writing several software modules (in both C++
and OTcl), taking into account several parameters and multi-step data flows.
As a net result, NS-2 is not so easy to use in the perspective of contributing new
models, protocols, and studying different scenarios at different levels of detail.
In fact, implementing a new protocol in NS-2 requires adding C++ code for the
protocol’s functionality, as well as updating key NS-2 OTcl configuration files
in order for NS2 to recognize the new protocol and its default parameters. The
C++ code also describes which parameters and methods are to be made avail-
able for OTcl scripting. Unfortunately, the software architecture of NS-2 is such
that adding new components and/or modifying existing ones is not a straight-
forward process. That is, in terms of ease to implement/test new algorithms or
scenarios, NS-2 scores poorly with respect to other simulators. Moreover, the
simulator has difficulties to stabilize. In deed, between two successive versions
of the simulator, there are always fundamental changes. This makes the task of
adding new protocols absurd to a certain extend. In fact, one can never be sure
that changes he makes will keep compatible with next versions.
Scalability and efficiency
NS-2 does not scale well in term of number of nodes and it is reported to be
in general quite slow from a computational point of view. Because of its large
memory footprint as soon as simulations of a few hundred to a few thousand
25
of nodes are undertaken, and its lack of scalability, NS is used mostly for small
scale simulations
Documentation availability
In addition to the lack of graphical tools that could greatly help code develop-
ment, the provided documentation, unfortunately, does not help from this point
of view. In fact, it is often limited and out of date with the current release
of the simulator. Most problems must be solved by consulting the highly dy-
namic newsgroups and browsing the source code. In general, it is admitted that
the learning curve for NS-2 is steep and debugging is difficult due to the dual
C++/OTcl nature of the simulator.
Reliability of wireless networks implementation in NS
As we are particularly interested in wireless network simulation we tested some

wireless scenarios with NS. We used tutorials and examples given within the
package. We detected some anomalies:
Normally three radio propagation models are proposed. First a shadowing

model takes into account multi-path propagation effects, and represents
the received power in terms of a random variable. Second free-space model
is used for near distances. Finally a Two Ray Ground is used for far
distances. In practice, only Two Ray Ground model works.
Antennas used by the mobile nodes are assumed to be omni-directional
and with unity gain. Nodes are designed to move in a three dimensional
topology. However the third dimension is not used, therefore, the nodes
are assumed to move always on a flat terrain. Moreover, it is allowed to
choose the height of the antenna in the tcl specification file given as input
to the simulator. However this datum is ignored by the simulator, the
height of the antenna is set statically to 1.5 m.
The most serious problem is that wireless network model with infrastruc-
ture does not work at all. Indeed, we run a simple scenario with two
mobile nodes attached to an access point. The first node sends data to
the second one. According to the IEEE 802.11 standard specifications, ex-
changed packets must go by the Access Point which should redirect them
to the destination mobile node, or to the distribution system. Contrary to
expectation, the packets exchanged in the simulation have a different be-
havior. The Access point is totally ignored, and considered as an ordinary
node. In other words, packets sent by the first mobile node are directly
delivered to the destination mobile node as if it was about an ad-hoc
network. The access point receives packets only if it is their destination.
26
Acceptability in the scientific community
NS-2 plays an important role in the network research field community, being a
sort of reference simulator. In fact, it is the most used simulator for studies on
transport protocols. Furthermore, it is becoming popular in the research field
of mobile ad hoc networks too. Therefore, in terms of scientific acceptance NS-2
would be an ideal choice.
2.3.5 Conclusion
NS-2 comes fully equipped with protocols, models, algorithms and accessory
tools, and furthermore it is under GPL license. Being started since 1989, it is
expected that it be a mature package. However, the simulator has difficulties
to stabilize. This is due to the continuous changes in the trends of network
community requirements and the submersion of new technologies. In addition,
being the result of such a long process of development, which has incorporated
contributions from several different sources, the software design of NS-2 is quite
poor with respect to current standards. If it is rather easy to use the simulator,
it is not that easy to learn how to add new components or modify existing ones.
A more troublesome limitation of NS-2 is its large memory footprint and its
lack of scalability as soon as simulations of a few hundred to a few thousand of
nodes are undertaken. This is a major impediment according to the objectives
of researchers. Only small sized, but at the same time fine-grained simulations
can be undertaken.
2.4 OMNeT++
2.4.1 Presentation
The ”Objective Modular Network Testbed in C++” known as OMNeT++6 is
an open-source, free, for academic and non-profit use discrete-event simulation
package. It is component-based, modular and open-architecture tool. It is de-
veloped by Anderas Vagra within its PhD work at University of Budapest. This
tool offers a C++ simulation class library and GUI support (graphical network
editing, animation). The simulator can be used for: traffic modeling of telecom-
munication networks, protocol modeling, modeling queuing networks, modeling
multiprocessors and other distributed hardware systems. It is also used for
validating hardware architectures, evaluating performance aspects of complex
software systems. More in general, OMNeT ++ allows modeling any other sys-
tem which can be mapped to active components that communicate by passing
messages. In some sense, and differently from the other simulators discussed
within this chapter, OMNeT++ is not specifically designed for telecommunica-
tion networks, but it is far more general.
6 OMNeT++ Community Site, http://www.omnetpp.org
27
2.4.2 OMNeT++ monitoring support
In put
Unlike in NS-2, there are no pre defined network entities in OMNeT++. In

fact, OMNeT++ model of a system (e.g., a network) consists of hierarchically
imbricate modules. The notion of module will be explained in details in the in-
ternal architecture OMNeT++ description.The depth of module nesting is not
limited, allowing the user to reflect the logical structure of the actual system in
the model structure. Modules communicate via message passing. Messages can
contain arbitrarily complex data structures defined by the user. Modules can
send messages either directly to their destination or along a predefined path,
through gates and connections, which have assigned properties like bandwidth,
delay, and error rate. Modules can have parameters which are used to customize
module behavior, to create flexible model topologies, and for module communi-
cation, as shared variables. Modules at the lowest level of the module hierarchy
are to be provided by the user, and they contain the algorithms in the model.
Briefly, an OMNeT++ program consists of a collection of modules, their pa-
rameters, their connections, and the behavior of simple modules of them. It is
spread over multiple files in order to enforce separation between topology and
functionality [16].
For each simulation program a NED file is required. The NED language
is used in OMNeT++ versions 2.x and 3.x. NED (NEtwork Description). It
is a human-readable and the expressive textual topology description format of
OMNeT++, provided in order to specify: connections and channels, simple
modules with their parameters and gates, and compound modules with their
parameters, gates, submodules, and the connections between them. Therefore,
a compiler for the NED topology description language is given within the OM-
NeT++ package. NED compiler translates the *.ned file into C++. The same
format (NED) is used by a graphical editor (GNED).
In addition, *.h and *.cc files are required to define the modules classes.
Indeed, to write simple modules, the user is requested to use C++ programming.
OMNeT++ has a consistent object-oriented design. One can freely use concepts
of object-oriented programming (inheritance, polymorphism etc.) to extend the
functionality of the simulator.
Finally, the file omnetpp.ini is default configuration file for a simulation pro-
gram; it contains configuration for the simulator as well as module parameters
and it is read on startup. It consists of several sections: Such as general set-
ting that contains names of output files, seed selection, limit of simulation time
and simulated time, memory usage, and also environment-specific settings. Any
module parameter left unspecified in *.ned file can be set here.
To turn these three components into an executable, OMNeT++ provide a
tool: opp makemake, which creates a makefile for the make tool.
It is obvious that writing an OMNeT++ program is not such a simple task.
In fact, the OMNeT++ user must master the NED format, the C++ language,
and match between the *.ned, *.cc and *.h files. In addition he must have a wide
idea about the simulator classes’ hierarchy. Thus, simulating a simple network
28
scenario becomes a hard and long mission.
Out put
We can asset that it’s the strong part of OMNeT++. User can choose be-
tween two user interfaces selectable as opp makemake parameters, to run an
OMNeT++ program: command-line and graphical interface. Though the com-
mand line interface is rather uncomfortable and used only to run the program
with maximum speed, the graphical user interface is nice and well -planned. The
GUI makes the inside of the model visible to the user including the hierarchy of
modules and their connections. Messages travelling along connections are ani-
mated. It is very useful for simple debugging and can also be used to pedagogic
issues. It offers inspectors for most objects (e.g. double-click on modules shows
submodules and parameters, see figures 2.5 and 2.6 respectively). Moreover, it
allows to single-step from event to event or fast forward the program with dif-
ferent animation speed. Furthermore, it allows the user to start/stop simulation
execution and to intervene by changing variables/objects inside the model. The
GUI library is linked with the debugging/tracing capability into the simulation
executable. This choice enables every user-created object being visible (and
modifiable) in the GUI via inspector windows. Output files are text files in a
format which, after some simple processing, can be read into standard math-
ematical and statistical packages. In this sense, OMNeT++ does not provide
any duplicate of such standard packages. Briefly, the nice graphical interface
offers good potentialities for monitoring and analysis of the simulations. The
following components are given within the OMNeT++ package, and responsible
of output generation:
GUI for simulation execution, links into simulation executable (Tkenv)

Command-line user interface for simulation execution (Cmdenv)
Graphical output vector plotting tool (Plove)
Graphical output scalars visualization tool (Scalars)
2.4.3 OMNeT++ internal architecture
General structure and topology representation
There is no pre established node or equipment model supported by this simu-

lator. As mentioned in the presentation below, OMNeT++ structures a sim-
ulation into modules such that a module has a well specified interface and a
state that can be inspected graphically. Modules implement application-specific
functionality, can be connected by connections or channels, and communicate
by exchanging messages via connections.
The arrival of a message at a module is an event, so modules are respon-
sible of handling and generating events. Moreover, modules can be arranged
hierarchically, and can be created and destroyed dynamically.
29
Actually, modules are C++ objects, using support functions from a simula-
tion library. There are two principle parent classes for modules in OMNeT++
design: cCompoundModule and cSimpleModule.
Compound modules are C++ classes, derived from OMNeT++ base class
cCompoundModule, and simple modules are subclassed from cSimpleModule
[17]. This later is an abstract base class; which’s interface specifies everything
the simulation kernel must know about a module. Modules with user specified
behavior must be simple modules. A compound module is glued together from
a number of simple modules of different types and possibly of other compound
modules. This leads to a hierarchical structure of modules. From outside a
compound module looks like a simple module; it reacts on messages, and send
messages to other modules. However, a compound module does not have any
own behavior; it just combines and connects its constituent modules. There are
also module types in the simulator.
Let’s take an example for illustration: Suppose we want to simulate the
progress of ARP (address resolution protocol). An ARPclient, an ARPserver,
and a router are represented as compound modules, whereas the channel is
a simple module. For instance the ARPclient is made of the following sub
modules:
An Ethernet interface (eth[0]).

Network layer (networkLayer).
A pinger application (pingApp).
UDP model (udp) and TCP model (tcp), while not used in the ARP
process.
An application model (tcpApp[0])
The (routingTable)
(blackboard) is there for future extensions: it will be used in the future as a
storage place for various parameters and state variables different protocol
layers need to share.
Some of those sub modules are simple modules such as TCP and UDP module,
while other are in their turn compound modules. For instance the Ethernet
interface consists on three simple sub modules, namely: ARP-cache module,
encapsulation module, and MAClayer module. Figures 2.5 and 2.6respectively
are bought from an OMNeT++ demonstration and illustrate these compound
and simple modules.Note that a simple or a compound module can have an
arbitrary number of input and output connections.
Simulation kernel
The classes described here are used internally by the simulation kernel. They
are normally of very little interest to the simulation programmer, but for great
interest for us since we intend to design a simulation kernel. However, it is not
30
Figure 2.5: ARP client by OMNeT++
Figure 2.6: Ethernet interface in ARP client by OMNeT++
31
quite different from NS-2 kernel. In fact, the two simulators answer discrete-
event’s requirements. So, we will not tarry on kernel description. The most
pertinent classes associated with simulation execution are:
cSimulation has a single instance. It stores the network and manages

simulation runs.
cScheduler is a base class for schedulers. There are two different schedulers
according to the data structure used for the FES (RealTime scheduler and
Sequential scheduler).
cMessageHeap is used internally by cSimulation as FES (Future Event
Set).
cCoroutine is the engine behind activity of simple modules.
cWatch is the class that rules the simulated time .
Note that these internal classes may change more often than other classes, sim-
ply because they aren’t used in simulation models and thus backwards compat-
ibility is less important. There is another important family of classes in the
simulator, that is Registration classes. They play the role of a central registry
in OMNeT++. Registration objects play an important role at network build
time: they store information about available module, channel, etc types and
can instantiate them. They are also overriding for inspectors in graphical user
interfaces. As example of Registration classes we cite cModuleInterface which
stores the list of gates and parameters declared for a module type and cModule-
Type which can instantiate a module type. Some other classes, closely related
to the above ones are not listed here. Major part of event handling is part of
simulation kernel, especially the FES management. Modules are entities that
generate and handle events. A simple module is invoked from simulation kernel
by the call of handleMessage (cMessage * msg). It is a virtual method in cSim-
pleModule interface, so all derived modules must implement it. In response, the
event handler modifies the module’s state and eventually generate new messages
destined to other modules or even to it self.
OMNeT++ is not specifically designed for telecommunication networks and

even less for wireless telecommunication networks. Until a near past, some
important network-specific models and protocols were missing. This fact, in
spite of some interest that OMNeT++ is widely attracting, dramatically limited
the use of OMNeT++. However, a numerous sides work on the simulator so the
modules library is growing rapidly. Thus, today OMNeT++ has a very large
simulation models that belongs to different projects. Next we list the most
important implemented protocols and their corresponding frameworks:
Implemented TCP/IP networks
32
The INET Framework contains models for IP, TCP, UDP, PPP, Ethernet,
MPLS with LDP and RSVP-TE signaling, and other protocols. Since
summer 2005, the INET Framework also includes some support for mobile
and wireless simulations.
IPv6Suite is developed at CTIE, Monash University, Melbourne. Sup-
ports IPv6 (Mobile IPv6 and Hierarchical Mobile IPv6 models are being
developed), and contains PPP, Ethernet and 802.11 models. Meanwhile,
an effort is underway to add IPv6/MIPv6 support into the INET Frame-
work, using a new IPv6 codebase.
OppBSD (Roland Bless, University Karlsruhe) is basically the FreeBSD
kernel’s networking stack ported into OMNeT++ as a TCP/IP simulation
model. It allows for accurate yet very scalable TCP simulations; suitable
for network emulation as well.
Implemented LAN/MAN frameworks
Ethernet: a detailed Ethernet model is available from CTIE. This model

is also part of the INET framework.
FDDI and Token Ring models are included in the OMNeT++ distribution
as example simulations. The FDDI model is fairly detailed, the Token
Ring model is relatively simple.
Wireless models The most important mobility, ad-hoc and wireless protocols
supported in OMNeT++ are developed within the following projects:
The Mobility Framework (MF) mentioned above supports also simulations

of wireless and mobile net works within OMNeT++. It was created at
TKN, TU Berlin. MF includes 802.11 ad-hoc mode only. This framework
is intended to support wireless and mobile simulations within OMNeT++.
The core framework implements the support for node mobility, dynamic
connection management and a wireless channel model. Additionally the
core framework provides basic modules that can be derived in order to
implement own modules. With this concept a programmer can easily
develop own protocol implementations for the Mobility Framework (MF)
without having to deal with the necessary interface and interoperability
stuff.
An AODV framework was written in Bologna.
The Consensus project (TU Delft and Univ.of Twente, the Netherlands)
released the packages Positif and MAC Simulator, which were used in their
wireless sensor networks and MAC layer publications.
A 802.11 model has also been developed for the IPv6Suite.
Two Hiperlan/2 models have been written. The more detailed and pow-
erful model has been written at TU Berlin but the code has never been
released.
33
SensorSimulator at Louisiana State University
OMNeT++ team is currently developing a library of standard protocols

for the MF (802.11, AODV, etc). Their goal is to have a rich library of such
protocols to enable easy plug-and-play simulations of various kinds of widely
used protocols. In conclusion, all this looks very nice. OMNeT++ seems to
hold a very rich protocol library. Unfortunately, a problem persists. In fact all
these frameworks were developed separately in different projects and sometimes
in a precipitated way. Attempt to integrate all these separated contributions
usually fail because of their incompatibility. This is due in part to the fact that
OMNeT++ is still a young software product (its development started in 1998).
As regards credibility of implementations, we are asked to relay on development
teams. Personally, I did not have the occasion to check by me self if some
protocols works suitably.
2.4.4 Evaluation and summary of OMNeT++ features
Extensibility
Being highly modular and well structured is a big advantage for OMNeT++
when it comes to implementing new protocols to be used in the simulator. The
process of implementing new protocols for wireless as for wired networks in
OMNeT++ is quite straightforward and convenient especially thanks to the
NED language. Extensibility can even be confused with usability since user is
required to define its own modules and classes in C++ language. Furthermore,
OMNeT++ comes with an extensive set of container classes for data structures
(e.g., queues, arrays), data collection classes, probability and statistics classes
(e.g., histograms, exponential distributions) transient detection and result ac-
curacy detection classes. The definition of new custom models and protocols is
quite easy when compared in comparison to the other simulators and to NS-2
in particular.However, unfortunately, the problem of incompatibility between
modules developed by different developers’ sets oneself.
According to the well-planned conception of its kernel of simulation and to the

youth and modernity of its architecture, it is reasonable to expect a good scala-
bility of OMNeT++, even if there are no real data concerning the simulation of
large networks. Concerning the CPU resource management, simple modules ap-
pear to run in parallel during simulation execution, since they are implemented
as co-routines. OMNeT++ also supports parallel simulation [18] through the
use of either MPI or PVM3 communication libraries but we do not interest on
this aspect in the present document.
34
A consistent documentation is delivered with OMNeT++ package. Moreover,

the official web site of the simulator 7 is well structured and up-to-date. Fur-
thermore, some demonstration executables are provided. The source code is
also well commented and structured for a relatively easy readability.
Acceptability in the scientific community
Although OMNeT++ is not a network simulator itself, it is currently gaining

widespread popularity as a network simulation platform in the scientific com-
munity as well as in industrial settings, and building up a large user community.
Moreover Platforms: OMNeT++ runs on Linux, other Unix-like systems and
on Windows (XP, Win2K). Nevertheless, OMNeT++ is relatively a young sim-
ulator, particularly compared by NS-2.
2.4.5 Conclusion
OMNeT++ has been carefully designed from the software point of view, result-
ing in a product which is much better organized, flexible and easy to use than
the other simulators, which are all based on older software products and design
concepts and specially compared with NS-2. The overall design of OMNeT++
is pretty nice and fully based on the driving ideas of object-oriented design.
In this respect, OMNeT++ is probably the best software product among the
available ones. Unfortunately, some important network-specific models and pro-
tocols are missing or incompatible with other modules. This fact, together with
the fact that OMNeT++ is not specially designed for telecommunication net-
work simulation and even less for wireless ones limits the use of OMNeT++ in
spite of some interest that OMNeT++ is widely attracting. Moreover, writing
an OMNeT++ program is not a simple task and might discourage more then
one.
2.5 SimulX
2.5.1 Presentation
SimulX is a wireless network simulator project started in 2003. It is the result of
the contribution of about ten people; all of them are students from Louis PAS-
TEUR University in Strasbourg, and members of Networks and Protocols team
in the LSiiT. The project is not open source yet. Nevertheless, it is expected
to be an open source, free for academic and non-profit use simulation package.
The simulator targets to be used in both research and teaching areas. It offers
a C++ simulation class library and uses GTK/OpenGL for the graphical user
7 OMNeT++ Community Site, http://www.omnetpp.org
35
interface. Unlike other simulators discussed here, this tool is consecrated to

wireless networks and mobility aspects simulation purpose. More specifically,
the most important topics are Mobile IPv6, 802.11 with infrastructure commu-
nication, and optimized level two and three handover mechanisms. Although it
is not finished yet, we interest on this software for many reasons. First it has
near objectives to ours. Moreover, it is quite different from other simulators
discussed here in sense that it focuses on mobility features, and brings some
original ideas notably when it comes to events and mobility management as
we’ll see. Most of all, some members of SimulX team are likely to participate
in the development of the present project and it seems very interesting to take
advantage of their experience.
2.5.2 SimulX monitoring support
Input
Differently from other simulators discussed in this chapter, SimulX provides

a graphical user interface that allows the specification of features of simulation
scenario to completion. The graphical interface guides the user to provide topol-
ogy elements including MNs, AP, routers, etc. All this elements are positioned
on a map. The user can also configure the network by creating LANs, Back-
bones, cells, and attaching equipments to them. Further, the user is asked to
create and schedule flows and movements. The interface offers also the pos-
sibility to load session, which means a previous saved simulation scenario. It
is possible mutually to save one’s session. SimulX presents another interesting
mean: that’s to launch a simulation remotely, via Web interface. Otherwise, it
still possible to bypass the graphical interface, and provide text files as input
to the simulator. That’s an uncomfortable way to act, not recommended for
ordinary users. Finally, the user has to choose between two executions modes:
normal mode and NextEvent mode which tally with two levels of details.
Output
In the one hand, the simulator offers a graphical visualization of the simulated
scenario with an animated map, on which we can see nodes moving, making
handoffs etc. On the other hand, the simulator generates multitude of trace
files, in text format. Following, we find some of the trace files:
move.log: log every movement of nodes

traffic.log: indicate the beginning and the end of each flow, on each
medium
l2handover.log: indicate L2 handover related message and mechanisms
mobileipv6 : indicates MN and CN mechanisms related to Mobile IPv6
We underline that the trace is tunable: the user can choose which files he wants
to obtain to avoid undesirable information and save processing resources. In
36
Figure 2.7: Graphical User Interface of SimulX
fact, this can have a great influence on execution time, and constitutes another
mean of selection of level of details.
2.5.3 SimulX internal architecture
Topology representation
[10] SimulX topology is made of equipments (nodes) and links. All those com-
ponents are located on a map. To create a topology instance, one should first
create the map which limits the spatial frontiers of the simulation. Further, it
becomes possible to create equipments and links.
Equipments:
The simulator defines panoply of pre established equipment’s types which
are the following:
– Router: only router, home agent, GPS server
– AP : Access Point
– MN : Mobile Nodes, Mobile IPv6 compatible, can visit other IPv6
networks
– CN : Correspondent Node, compatible Mobile
37
Figure 2.8: Nodes classes’hierarchy in SimulX
– NN : Normal Node, non compatible Mobile IPv6

Every equipment is modeled as a C++ classes. Figure 2.8 shows node’s
hierarchy in SimulX classes’ diagram. We notice that this hierarchy is
not flexible at all. We can not envisage adding a new equipment type or
modifying an existing one, without adjusting the whole global structure.
Link:
Three types of link are defined:
– WLAN: wireless link that connects MNs and APs

– LAN: ethernet link that connects APs to each other and to routers
– Backbone: a specific link which connects routers only. It introduces
a specific delay to simulate a cross over the Internet. It is possible
to configure each link weight. This link also allows computing and
seeing the shortest path on the map.
The three types of links are modeled as C++ classes two. We stress
that only one instance of each link is created in a simulation instance.All
equipmnets share the same three links. That is to say, the topology should
imply a number of WLAN for example. Although those WLAN are sep-
arated in the space, only one instance of class WLAN is created. Two
38
devices attached to this unique WLAN are connected or not according to

their respective positions on the map.
Mobility management
As mentioned above, the simulated topology is built on a map. The map is a

grid, subdivided into unity squares. Equipments are characterized by coordi-
nates that tally with a square on the map. Whenever the user wants to make
move one equipment, he specifies the departure time, the target position, and
the speed of moving. He can also choose to move it to a random destination. The
simulator computes the shortest trajectory (itinerary) to the destination follow-
ing the squares in range or out of range according to the requirement. Every
time the equipment leaves a square and enters into another one, an event is gen-
erated. This process means guarantees the control of equipments movements.
Nevertheless, it may generate unnecessary events. In fact, when equipment is
moving without exchanging data, we don’t care about its intermediary position.
Event management
SimulX has no calendar, and does not define an event as a substantial entity.
Nevertheless, it keeps a global variable which represents simulation time. To
manage events generated by elements of the topology, the simulator acts in
iterative way. In every iteration, the simulator probes all equipments created
within the simulation instance. If the examined equipment has an event to
consume and which is likely to advance simulation time, he checks NextEvent
value and compares it to its own event delay. If the delay is smaller then
NextEvent is set to the event delay. At the end of an iteration, the simulation
time is up dated (time = time + NextEvent), and the equipment that has the
nearest event is served.
This method guaranties that events are generated and dispatched in the
right rank. In addition, there will be no processing in calendar sort, and no
memory footprint due to excessive number of events. However, it has a major
problem; that is to do more much processing. All equipments are probed in
every iteration, including inactive equipments. This may affect noticeably the
scalability of the simulator.
In spite of being in a primitive stage, SimulX has acquired yet a rich mobility
protocols library. Support for mobile networks is essential but of high-quality
and sufficient to carry out serious studies. Nevertheless, though it has been de-
signed for wireless and wired networks systems, the simulator currently supports
only protocols for purely wireless networks.
Layer 2 protocols
39
– Ethernet: CSMA/CD not respected, messages are sent sequentially

on the medium
– IEEE 802.11b and IEEE 802.11a (DCF, PCF, RTS/CTS, fragmen-
tation, L2 handover, active mode, Power Saving Mode, Rate (Mbps)
selection, etc)
– Some L2 handover optimization mechanisms:
* Selective scanning: Scan first 1 - 6 - 11 channels.
* Periodic Scan: Launch a short scanning at regular intervals.
* Neighbor AP: The current AP sends the lost of its neighbor.
* Double transmitter: The MN has two radio interfaces.
Layer 3 protocols
– IPv6 routing:
* Dijikstra to build the shortest path between routers.
* Router Advertisement: sent by Router, periodical retransmis-
sion.
– Mobile IPv6:
* Mobile Node mobility (BU / BA with Home Agent).
* Reverse Tunneling.
* Route Optimization (BU / BA with CN).
* Security issues (TBD).
– Layer 3 handover optimization mechanisms:
* RFC2461 (Neighbor DiscoveryL2 triggers (RS upon Link Up).
* L2 triggers (RS upon Link Up): Solicit a RA when a new link is
established.
* RA beaconing: RAs are introduced in the beacons.
* Anticipated handover.
* Nearest AP: Usage of GPS information.
* Fast location-based handover: Mobile initiated handover based
on GPS information.
2.5.4 Evaluation and summary of SimulX features
Extensibility
We notice that Simulx do not enforce separation of topology and functionality

at all. The definition of equipments is closely bound to their activities. Thus,
the simulator does not support reusable models. Adding a new functionality,
protocol, or application requires knowledge of the whole structure of the simu-
lator.
40
Unfortunately, we can not expect a good scalability, in regard to event man-

agement process. We recall that, in every iteration, the simulator sounds out
all topology devices created in the simulation instance to determine the next
event to consume. This could be very penalizing in term of processing time and
memory utilization.
Being not published yet, there are not enough data in the current literature to
make a more precise idea about SimulX. Nevertheless, the simulator is men-
tioned in some articles. In addition, we can consult the collaborative web site of
SimulX to have more obvious idea of the simulator evolution8 . The official web
site is under construction 9 . Furthermore, Simulx is referenced in some publi-
cations that used it to evaluate some protocols[13]. On the other hand, we get
in touch with the simulator dvelopers. They provided as with some interesting
informations ans documents such as the code and the classes’diagram [10].
2.5.5 Conclusion
SimulX is an ambitious project. It provides a highly detailed wireless network
protocols’ implementation. However, it is not a mature package. In other terms,
it is young software, and it lacks experience to some extend. Consequently, the
simulator does not score positively in term of extensibility and scalability.
2.6 Conclusion
This chapter discussed the characteristics of simulation environments for com-
munications networks, and, more specifically, for mobile and wireless networks.
Three available network simulators were discussed and compared according to a
number of criteria ranging from the reliability of the provided simulation mod-
els, to the degree of usability of software and graphical interfaces. The aim
of the chapter is to evaluate tease simulation environments in order to identify
their advantages and drawbacks, to bring out the need of a new simulator which
will be more appropriate to run experiments to test and validate the design of
new mobility protocols.
8 Network Simulator SimulX,https://clarinet.u-strasbg.fr/ mon-

tavont/wiki/index.php/Accueil
9 Network Simulator SimulX, development page,https://clarinet.u-strasbg.fr/ mon-
tavont/wiki/index.php/Accueil
41
Part II
Simulator Kernel
42
Chapter 3
Specification of
requirements
3.1 Introduction
Further to the two precedent chapters, we can consider that we acquired now
enough knowledge about some of the most important available simulation envi-
ronment; we evaluated their advantages and their drawbacks, and we isolated
the needs of different kind of users. We also looked further into the properties
of discreet event simulation. Thus we are capable of defining with precision the
needs of our project.
Furthermore, the range of this project exceeds the frame of the present
project of end of study. In fact, it is a project marked by its open, continuous,
and evolutionary character. In other terms, it is only about the development
of the kernel of wireless network simulation environment within the context
of the present document, but we expect that the project will be continued,
and consequently, we must foresee both present and future functionalities since
the beginning, in order to avoid dead-end situations, and for not to commit
irreparable mistakes.
Where from the specification of needs set some more of importance. In fact,
this task has become increasingly recognized as being one of the most vital parts
of the process; given that the failure to properly identify requirements makes it
virtually impossible for the finished piece of software to meet the needs of the
user or be finished on time. Thus, a good set of requirements is needed for any
project, especially computer system projects, to be successful. This is where
many projects fail, in that they do not specify correctly what the system should
do. So we deal in this chapter with three sections: functional requirements, and
non functional requirements.
43
3.2 Functional requirements

Functional requirements are simply what we want the system to do. They
capture the intended behavior we want the system to perform. This behaviour
may be expressed as services, tasks or functions the system is required to achieve
for different kinds of users or actors. The important point to note is that
’what’ is wanted is specified, and not ’how’ it will be delivered. They have
important implications for software architecture, and must be taken into account
when we design the solution. Let’s begin with general features of our tool: We
plan to design a wireless network discret-event simulation environment, for both
research and teaching areas. Thus, we distinguish three kinds of users, with
different needs for each: researcher, student, and developer.
Networks researcher requirements
He specifies the scenario to simulate without need to know the internal

structure of the simulation tool. In relation to the user, the simulator
must be a black box with a specified input and output interfaces.
The input interface allows the user to ”write” a traffic exchange and mo-
bility scenario within wireless telecommunication network topology.
The user must not be constrained to master a script and even less a
programming language for the simple use of the simulator. Such kind
of constraints may discourage people from using the simulation tool.
The ideal is to dispose of two input interfaces: a graphical user interface
and a command line user interface.
The user can choose the suitable input interface according to his statue.
The command line interface is to be used by experts, practised and devel-
opers to test some new features of the simulator for example, and has no
comfort constraints.
The GUI is the principle interface. It must allow the acquisition of the
simulation scenario which may be relatively a complex scenario, with a
deep level of details.
The user creates the topology of the network to simulate by: defining
nodes and their positions, creating links, and establishing wireless and
wired connexions, in addition to attachments to cells and networks.
He can define specific (personalized) type of equipment: by picking pro-
tocols and applications from the model libraries and available models and
attaching them between them selves and to the equipment. The protocol
stack may define the role of the equipment (IEEE 802.11 AP, router, web
server, etc).
This offers panoply of possibilities. For instance, he may create equip-
ment that holds multiple interfaces of different technologies (e.g. 802.11
and 802.16, UMTS, etc), to allow it switching from an interface to another
44
according to the availability of networks. This latter feature, is solicited

with insistence with the proliferation of the IEEE801.21media indepen-
dence standard that will enable handover and interoperability between
heterogeneous network types.
Notice that at the beginning, these libraries will not be very rich and
varied, but we hope that new protocol and service models will be readily
available for the simulation tool in brief delays. Regarding, we should
make the task of adding a new protocol or application as easy as possible.
This allows different levels of details in simulation by substituting some
protocols by an entity that adds simply a statistical delay when needed.
So in equipment, some protocols run in conformity with reality, whereas
others induce a delay. This depends on what we want to simulate exactly.
Some readily available equipment templates must be available.
The user can create multiple similar devices at the same time.
He can define movements and mobility scenarios: target position or ran-

dom destination, speed, and time of departure.
He may also dispose of readily mobility models to apply on his topology.
Handovers are associated to mobility. The simulator must allow testing

some optimized level 2 and level 3 handover techniques.
The user must be able to allocate flows to nodes, depending on applications
that the node holds.
He may precise the time of beginning, the time of end, the data size, etc
or simply apply a mathematical or statistical traffic generation model on
one equipment or on the whole topology.
After the specification of the scenario to simulate, the user runs the sim-
ulation.
Scalability is also necessary, which implies a good memory management.

Researcher has often to test some features on a big number of nodes, which
can not be made with real topology, from where the interest of simulation.
The user may need to resume or restart the same scenario. He must have
the possibility to save the simulation session.
In addition, research area requires precision and reliability of results. The
user may need to define different level of details and so different levels of
precision in a compromise between execution time and precision of results.
Similarly to the in put interface, two out put interfaces are needed:
– Graphical interface to show the scenario running, and may be to

control some execution features, such as speed.
– A text format trace, to analyse simulation results, especially for
pushed simulations.
45
Use cases are a widespread practice for capturing functional requirements. This
is especially true in the object-oriented community where they originated. Thus,
we summarize all functional requirements in three use cases. The first one Fig.
3.1 is about researcher requirements.
Student requirements
The educational aspect imposes methodical steps at the level of the seizure
of the parameters of the scenario to be feigned, as well as at the level of
the clarity of the code source of the simulation tool.
The graphical use interface must ask the user to provide with the right
detail at the opportune time, in such way that he understand what is
needed to specify when simulating this or that network technology.
The code of the simulator and specifically the implementation of protocols
must show a clearly how this protocol proceeds.
Developer requirements
The success or the fail of this project bases on the interest which the developers
carry there. We remind that it is about a free and open source tool, and it
has no chance to be continued unless developers extend it by adding protocols
implementations. Our task is to make this the as easy as possible.
A developer needs modularity of implementation. To add a new protocol,

he must not be constrained to know the structure of the whole simulator,
notably he do not carry about the kernel of the simulator. These grantees
a maximum of extensibility.
A net, precise, targeted and up to date documentation is for big utility.
Simulation model and selection of level of details
3.3 Non functional requirements

Performance constraints
– Scalability: efficient management of memory resource.

– Time taken by a simulation to end: efficient management of CPU
resource.
Development constraints
– For better modularity of components, we should use an object ori-

ented language (C++).
46
47
Figure 3.1: Use case1: Researcher requirements

Figure 3.2: Use case1: Student requirements
Figure 3.3: Use case1: Developer requirements
48
– It would be interesting to export some information from the simulator

and use them with other applications. For instance, the topology
will have to in particular be exportable in a text format that will
be furnished to other graphical tools to be visualized. Similarly,
the measures constituting the track of the execution, an export in a
compatible format with an external graphics application package as
GNUPLOT1 is envisaged, to obtain 2D and 3D graphs.
– Mutually, data could be imported by the software to make a treat-
ment: for example, load a track supplied by another tool as tcpdump.
We can also, export models of mobility generated by other tools such
as CanuMobiSim, in addition to models of traffic generation and then
apply them in simulation scenarios
– The input/output text format must be a standard format, we propose
XML.
– Having a good and synchronized documentation is getting more and
more important to insure the continuity of the project. The better
way is to use an automatic generator of documentation, which gener-
ates documentation basing on commentaries extracted from the code
(e.g. doxygen2 ).
– The graphical user interface should be in Java. In fact, this choice
allows the possibility to run a simulation through web. The client
can specify the parameters of the scenario to simulate and recover
simulation track, without installing the simulator on his proper sta-
tion.
3.4 Conclusion
Specification of requirements has important implications for software architec-
ture. In particular, it is not just the functional requirements of the present
project that must be supported by the architecture. The functional require-
ments of similar and near releases need to be explicitly taken into account too.
Later releases are accommodated through architectural qualities such as exten-
sibility, flexibility, etc. The latter are expressed as non-functional requirements.
The strategy for quickly starting is to produce the core, basic product, and
adding features to variants of the product to be released shortly thereafter.
Already, we can distinguish the global architecture features. The product is
constituted of three big modules, namely: the kernel of simulation, the topol-
ogy entities, and the protocols and applications libraries. In the next chapter,
we will see the detailed solution conception.
1 GNUPLOT official web site, http://www.gnuplot.info/

2 Documentation system generator for C++,Java, etc, http://www.stack.nl/ dim-
itri/doxygen/
49
Chapter 4
Simulator Design
4.1 Introduction
Further to the detailed specification of requirements, we are henceforth capable
of elaborating the complete design of the adopted solution for the environment
of simulation that we plan to develop. We clarify in this chapter the adopted
abstract conceptual structure by beginning with a global sight of the classes
diagram, followed by a detailed description of the different modules and sub
modules of the software. To give a better visibility of the operating mode of
the product, we finish this chapter by unrolling two sequence diagrams showing
the execution of two very simple scenarios, and the communication between the
different modules and objects.
4.2 Classes diagram

As mentioned in the non functional requirements specification, it is about ob-
ject oriented software. Thus, and according to the conceptual model UML, we
developed a classes diagram. Figure 4.1 shows a global sight of the whole classes
diagram.
According to Fig.4.1, we discern three big modules; namely: the kernel of
simulation classes, topology elements classes, and finally classes that consti-
tute protocols and services library . Following, we describe in details classes
structures of each module.
50
Figure 4.1: Overview of the classes diagram
51
Figure 4.2: The class event
4.2.1 Simulation kernel classes

As mentioned in the first chapter, all discrete-event simulation tools, regardless
of how complex they can be, contain the same basic components: that’s the
kernel of simulation. The first module of the program represents our modelling
of these essential components, in other words: the simulation core, the event
driven monitor. It includes the following classes
Class event
The first thing to think about when creating a simulator is the event definition.
Events are conditions that occur at a point of simulated time witch causes
changes in the state of the system. The C++ class event represents the parent
class of all events in the program. Events may be: scheduled (to arrive back
at the same module at a later time), reported (e.g. backoff timer), cancelled,
or sent directly to another handler (fast run). All manipulations on events are
made via methods of handler s and scheduler. Events are generated by entities
interacting with their activities, and exchanged between them via the scheduler.
We inspect the most pertinent attributes and methods of the class and their
function in the following:
uid : every created instance of event has its unique identifier in the whole
simulation instance. This uid allows tracking the event instance and even-
tually canceling or reporting it, even after it has been scheduled.
time: it represents the date of execution (completion) of the event.
ev type: the type of the event refers in fact to a class that inherits from
Event. This attribute is used when cast is needed, it means when a specific
processing is to be made according the type of the event. This attributes
can have only one of the predefined values.
h: it is a reference to the entity in charge to handle (consume) the event
when its date is reached by the simulation time. Of course, the handling
of an event may lead to generation of other events. An instance of event
52
Figure 4.3: The class message
may be handled by many handlers at different times. Every handler that

receives it, does the necessary activities, and then changes some attributes
of the event, often time. The present handler sets h field of the event to the
next handler address, and sends it. This will be frequently done, namely
with events of type Message. Actually, the same message is usually han-
dled successively by entities in the simulation (e.g. the different protocol
layers in a node). In the contrary, when an event needs to be handled
by different entities at the some point of time, we should create different
copies of the event. Thus, every entity will handle its proper copy and
so, we avoid contradictions between changes made by every entity (e.g. a
Message that is propagated in broadcast).
show event: is a virtual function that displays the type, the uid and the
time of the event. This method is to be over loaded by derived classes.
It is obvious that the class event is to be derived in a set of specific types. Next
we have the description of different types of events. Notice that here we are
the defined events until now. Still, we expect the creation of new classes that
inherits from event, to satisfy other future requirements.
The class message :

It is the most frequent unit of exchange between the simulation entities. Message
is the representative class of data unity (packet or frame) exchanged between
nodes. In different terms, we consider a data exchange, or more properly, the end
of reception of data unity as an event. In fact, it is quite understandable in some
sense that Messages generation is the result of topology elements activities, and
is programmed to reach a destination entity at a precise point of time. Besides,
the reception of a Message by an entity, wakes it up, and triggers it to make
new activities. Let’s focus on message components in our conception:
As we show in Fig. 4.3, a message has a size expressed in Bytes. It has also
both source and destination equipment and port fields which tally respectively
53
Figure 4.4: The class timer
with references to source and destination nodes and applications. The message
holds also a direction attribute. This field is likely to take one of two values:
’-1’ which means that the message is in while transmission; whereas a value of
’1’ means that the message is in reception from the node point of view. In fact,
a message may be handled by a sub entity of a node. This sub entity needs
to know whether the local node is sending or receiving the message. Finally,
we notice that a message has another attribute: that is stack hdr or stack of
headers. As its name indicates, this field represents the stack of headers that
encapsulate the virtual data carried by the message. We will linger in header
description next.
The class timer :

Here we deal with another pattern of events. Timers can be simply considered as
delays. Sometimes, an activity needs to be postponed for a definite or randomly
generated period of time. The class timer is defined to satisfy such kind of
requirements. We implemented the class timer for test issues, but it is supposed
to be subclassed to many types of timers, according to the different needs of
implemented protocols (e.g. Backoff timer, TCP retransmission timer).
The class moving :

As it concerns a wireless network and mobility simulator, we must take on ac-
count mobility features as an overriding feature. We create the class moving to
express mobility in simulated scenarios. In this purpose, we have some hypoth-
esis. If a node is moving without sending or receiving any data, we do not care
about its intermediate state. It may only signalize the beginning and the end of
its displacement. In most cases, nodes do not move out of range, and therefore,
they continue receiving packets while their moving. To manage such situations,
the wireless channel takes on account the moving state of nodes that sent a
start moving event and did not send end of moving event yet, when computing
affected nodes, before delivering a message.
Thus, moving events are generated by moving nodes, and consumed in cen-
tralized manner by the wireless channel. Mobility feature will not be tested in
the first stage of development of the kernel. Nevertheless, we expect a good
behaviour with regard to the implementation of wireless channel that foresees
such aspects.
54
Figure 4.5: The class scheduler
The class scheduler
Being an event driven simulator, our program needs an entity to keep in charge
events scheduling and dispatching. scheduler is the class that encapsulates the
calendar and event scheduling. We explain the different attributes and methods
of this class showed in the Fig. 4.5.
The scheduler is the entity that holds the most important global variable in
a simulation: the simulated time represented by simul time field. It is also the
only object that can advance time. Naturally, time never moves back. The other
objects of the simulation may consult the time by calling the scheduler’s method:
get simul time. The calendar is represented by a list of events that are scheduled
to occur in the future sched list. It is ordered by the earliest scheduled time first,
basing on time field of event class. To be more precise, it is not a list of events,
it is rather a list of pointer on event for efficiency and memory saving issues.
Therefore, we can insert any object that inherits from event in this list. As
mentioned in the first chapter, an observed in the second one, the calendar may
take one of different data structures, more or less optimized, which influences
noticeably the simulator performance and execution time. Unfortunately, until
the moment of redaction of this document, the adopted structure is the Standard
Template Library (STL)sequential container List. In fact, the optimization of
the calendar structure is not the main purpose of this project, at this level
of advancement. The pre established STL’s List allowed starting tests on the
general conception of the simulator in the briefest delay.
Nevertheless our choice was taken with regard to the structure efficiency.
List is the most appropriate structure between those proposed by the STL. In
fact, insertion and removal are the most frequent operations dealing with the
calendar. Being doubly-chained, List provides insertion and removal methods
with a complexity of O(1). Alternatively, the most important drawback of the
List is the complexity of direct access to an element, but obviously, we don’t
need this functionality in our program. Thus, we can assert that we made the
most optimized choice between the containers provided by the STL.
Nevertheless, we plan to reconsider the structure of the calendar as soon as
55
possible. We underline that it still possible to modify the calendar structure

internally to scheduler class, without affecting any other class of the program.
Moreover, we plan to make the class scheduler an abstract class, and subclass it
into many schedulers using different structures to stock events. In the following
we focus on how does the scheduler actually run.
First of all, we must keep in mind that there is only one instance of class
scheduler in one simulation instance. Event management is centralized. Every
time an object generates an event, it calls the scheduler’s method schedule. This
function fetches the right position of the event according to its time field, and
inserts it in the sched list. Finally, this function returns the uid of the inserted
event to the entity that asked to schedule it. The uid will be eventually used
to find the event in the sched list if it is needed to cancel or suspend it. The
scheduler runs by selecting the earliest event, advancing the simulation time to
event time, calling the function dispatch before removing the dispatched event
from the sched list, and returning to execute the next event. dispatch is the
function that insures the consumption of the event by its destination object,
namely its handler. There is only one event in execution at any given time.
Simultaneous events are executed on a first scheduled-first dispatched manner.
That means the tow events are executed the one after the other, but at the same
simulation time.
Besides, it is possible to cancel an event with the member function cancel.
For instance, a node may run a retransmission timer with means that it will
schedule an event of type timer. If the acknowledgment is received before the
timer has expired, it is required to cancel the timer, that to say, find the cor-
responding event, and remove it from the calendar. Likewise, it may be useful
to suspend an event, and resume it later (e.g. Backoff timer in IEEE802.11).
suspend member function is defined for such a case. Finally, show all events is
the function that displays all the events scheduled when the function is called.
The class handler
Until now, we dealt with events and with scheduler. Entities in charge of gener-
ating and consuming events are absent from roll-call. For this issue, we define
the abstract class handler. It is the parent class of all entities that are likely to
consume an event. It has only one member function: handle. It takes a refer-
ence to an event in parameter. In fact, all classes that inherit from this class
are supposed to treat events. They can be referred by h attribute of any event,
and so, the scheduler calls the handle function of the appropriate handler when
dispatching the event. In addition, the handler keeps a pointer on the scheduler
instance of the simulation. Thus, each handler can accede to scheduler mem-
bers such as schedule function, to schedule an event, and get simulation time to
consult current time of simulation.
The class header
We saw above that the class message has a stack of headers as attribute. header
is a class representative of headers added by protocols to a data packet. In the
56
Figure 4.6: The class handler
Figure 4.7: The class header
reality, when a message is transmitted, each protocol of the node creates a

protocol data unit (PDU) for transmission that includes headers required by
that protocol and data to be transmitted. This data becomes the service data
unit (SDU) of the next layer below it. The encapsulation process continues all
the way down to layer 2. The inverse process takes place while reception of a
message by a node. Likewise, in our simulator, each time we implement a new
protocol, we create a new class that inherits from header, and that is associated
to this protocol. This header does not copy all the information found in the
real header, but only information that are useful for the simulation progress.
We show below the parent class header structure. type refers to the associated
protocol, and size must take the value of the actual header’s size in Bytes.
4.2.2 Topology devices classes

A network topology can be completely defined by the description of nodes and
links that interconnect them. We model network element with class equipment
that represents all possible devices and class link that makes interconnections
between equipments. We describe the tow classes in the following.
The class equipment
This class inherits from the class handler, and represents all kinds of nodes, in-
cluding mobile nodes, access points, authentication servers, web servers, routers,
etc. In fact, equipment can be modeled as a protocol’s stack, and a set of appli-
cations or services, in addition to an address or identifier. The nature of these
services and these protocols, with regard to their arrangement defines the type
57
Figure 4.8: The class equipment
of the equipment. Thus, the class equipment has tow vectors: a protocols’ vec-
tor and a services’ vector. The member functions add protocol, remove protocol,
add service and remove service allow the management of these vectors. proto-
col and service are two classes in our design. We will deal with them next. All
we need to know at this level is that protocols and services are interconnected,
and can be arranged in different manners.
However, equipment must have at least one protocol of type physical inter-
face unless we can not attach it to a link. This latter functionality is insured by
attachtoSlink, attachtoMlink and attachtoWlink member functions, according
to whereas we want to attach the equipment to a simple link, a multipoint link,
or a wireless channel.
Moreover, equipment is characterized by its unique identifier eq uid that
can be considered as an address while routing. In addition, it has three spatial
coordinates to locate it on the topology’s map, and define which equipments
are in range of which ones. The member function send allows setting off a
service of the equipment at a given simulation point of time, with the necessary
characteristics according the type of service. For this issue, many forms of send
are defined.
58
Figure 4.9: The class protocol
The class protocol
The main concept is to represent each implemented protocol in one class to

guarantee the maximum of modularity, and then extensibility. Moreover, such
a concept allows the creation of ”to measure” equipments, by picking protocol s
from the protocol library and attaching them to the equipment.
For this issue, we defined the class protocol that represents the parent class
of all network protocols. It includes the main common functionalities between
all protocols, namely reception of SDU or PDU from applications and upper or
down layers, encapsulation and decapsulation of messages, forwarding to upper
or down protocol, application or link.
Specific functionalities of each protocol are to be implemented in the sub-
class of protocol that represents the specific protocol (e.g. TCP, MAC802.11,
etc). We can see in Fig.fig:ptcl the structure of the class protocol. A pro-
tocol is characterized by its identifier ptc id. Being unique for each created
instance of protocol in a simulation instance, this identifier might be used as
address in some specific protocols such as IP and MAC. Furthermore, a pro-
tocol has an up target vector that refers to all upper layers, which can be one
or more protocol s, and eventually one or more services. In a similar manner,
we define down target vector. This latter refers to all attached down proto-
cols, and probably a link when it is about a physical layer. add down target,
remove down target, add up target, and remove up target are the functions in
charge to manage these two vectors. When attached to equipment, the protocol
59
keeps also a reference to its equipment (my eq).

The following paragraph summarizes how protocol operates.
Being a handler, a protocol is able to handle events, namely messages and
timer s. Therefore, protocol defines the function handle inherited from the par-
ent class handle. When receiving a message, a protocol checks its direction field
and decides accordingly either to call recv from up or recv from down member
function. recv from up adds the associated header, recognized by its type that
tallies with the protocol type field. Consequently, it increases the size of the
message. After that, it finds the suitable down layer, or link, by calling the
member function find down target. This latter method looks for a protocol of
a specific type in the down target vector, and sets it as the next handler of
the message. Thus, the message is ready to be sent to the lower level. This is
done through the scheduler. The function send schedules the message reception
calling schedule method of the scheduler instance of the simulation. Symmetri-
cally, recv from down removes the corresponding header to the protocol, and so
reduces the size of the received message. Next, it looks for the upper layer or
application by calling find up target function. As mentioned above, the upper
target may be a protocol or a service. We can guess either it is the one or the
other basing on the stack of headers of the received message. In fact, we make
a supposition that is not far from the reality: a message that goes through a
stack of protocols in the sender equipment, must goes through the some stack
of protocols in the opposite sense in the destination equipment. This is quite
important because of the header assigned to the message by each protocol and
that is intended to be interpreted by the same protocol in the destination node.
Thus, we can always rely on the type of the header on the top of the stack
of headers to find for a given message, the appropriate upper protocol in the
up target vector. In the defaulting case, in means when there are no more
headers in the stack hdr of the message, we can deduce that the upper target is
not a protocol but an application (service. In this case, we rely on the destination
port field of the message (portdest) to find the appropriate application. Again,
the protocol sends the message to the up target through the scheduler.
This architecture is conform with the OSI reference model. In fact, if we
look at several ways that protocols at various layers in a networking protocol
stack interact with each other in this model, we notice that one of the most
important concepts in inter-protocol operation is that of encapsulation, called
also packaging. Most data originates within the higher layers of the OSI model
(applicative level). The protocols at these layers pass the data down to lower
layers for transmission, usually in the form of discrete messages. Upon receipt,
each lower-level protocol takes the entire contents of the message received and
encapsulates it into its own message format, adding a header and possibly a
footer that contain important control information. A part from encapsulation,
a protocol has generally other specific functionalities such as fragmentation,
reassembly, and retransmission. These features are often related to a specific
protocol. Consequently, they are not implemented in the parent class protocol,
but are left to be kept in consideration in subclasses of protocol.
60
Figure 4.10: The class service
The class service
We showed above that equipment has a set of protocols, but also a set of services.
service is the class that models applications in a node. services are different from
protocol s in some sense that generate and consume data flows. gen and consume
member functions are defined to provide respectively these two functionalities.
In addition, services have no upper level, and have only one down target,
which must be a protocol. A service is characterized by a unique identifier
srv id. This attribute is the equivalent of a port number used to reach the
service when it is the destination of a message.
The class link
Links are the entities that insure equipment interconnections, and messages
propagation. There are several types of links. For instance, they can be wire
links, or radio channels. However, all links has some common properties. For
this reason, we define a parent class link that gathers common properties of all
links, namely a vector that refers to all attached physical interfaces of equip-
ments (attached interfaces). We remind that a physical interface is an instance
of class phy derived from protocol.
link is a handler. messages are passed from equipment’s physical interfaces
to link trough the scheduler, after the transmission time is added. The link sim-
ply looks for the destination interface within its attached interfaces, by making
the correspondence of eqdest field of the received message and the eq uid of the
equipment that holds the physical interface.
Further, the link schedules the message to be received by the destination
node after propagation delay.
61
Figure 4.11: The class link
Figure 4.12: The class Simplelink
The class Simplelink :

A Simplelink connects two equipments. When he receives a message from one
equipment, he transmits it to the other equipment after inducing a propagation
delay. This delay can be fixed statistically when the link is created, or takes a
random value between a maximum and a minimum given values.
The class Multipointlink Multipointlink models an Ethernet link. When

an attched node transmits a message on this link, the link delivers a copy of
the message to each attached equipment, unless the transmitter. CSMA/CD
mechanism is to be implemented by the subclass of protocol MAC802.3. The
attribute busy is created to help equipments detect either the link is busy or
used by another attached equipment and thus it is necessary for CSMA/CD
process. :
The class Wirelesschannel :
62
Figure 4.13: The class Multipointlink
4.2.3 Protocols and services library

It is admitted that a simulator that provides a rich set of already implemented
and tested protocols and services is preferable to a simulator with no imple-
mented modules. Nevertheless, our software is in an early stage of advancement,
and we can not expect having a rich a big number of protocols and applications
models since the beginning. Indeed, development of a rich protocols and ser-
vices library requires a lot of time especially if we want to guarantee quality.
As a matter of fact, number of implemented protocols is not the only important
criterion since measurements are very sensitive to the quality of implementa-
tion, and to its conformity with reality. Ever since, all we can do at this level
of the project is to make addition of new protocols and applications the more
easy than possible.
However, in the global classes diagram Fig.4.1, we notice the presence of a
set of subclasses of protocol and service classes. As mentioned above, subclasses
of the parent classes’ protocol and service form the models library of our sim-
ulator. Unfortunately, most of them, such as TCP and IP, will not be suitably
implemented from the beginning. They are here only for test issues. On the
other set, some other protocols will be well defined. For instance, protocols
that get in touch with IEEE802.11i is to be properly defined. We will focus
on them on the next part of this document. The OSI modules that are really
interesting for us are primarily those relative to mobility and wireless protocols.
The physical and link layer, if considered in the perspective of the radio emis-
sion/reception are also important. It is also very important to have a reliable
implementation of the MAC layer. At the application level it is enough to have
simple CBR modules for tests on the simulator kernel purposes.
Briefly, the integration of a new protocol in the simulator is a very straight-
forward task, as it is sufficient to derive the class protocol, and to create the
corresponding header which is likewise a subclass of header. In a similar man-
ner, we must subclass the class service to create a new service. In all cases, it
is unnecessary to alter the rest of the software.
63
Figure 4.14: Topology of the first sequence diagram
4.3 Sequence diagrams

In this section, we give a simplified but precise idea about how our program
processes. For this issue, we make use of sequence diagrams. Sequence diagram
is an UML formalism that shows the succession of interactions between objects
in time course, within the activity of the program. We note that there are two
types of exchanged messages between objects: synchronous and asynchronous
messages. When an object sends a synchronous message, it is frozen until the
destination message has completed the requested procedure, or until it receives
another trigger message, whereas an object that sends an asynchronous message
continues its execution. All messages exchanged in sequence diagrams presented
in this document are synchronous messages (repectively Fig.4.15 and Fig.4.17).
We Will deal with two frequent use cases of a network simulator, namely
sending a message from one equipment to another, and running a timer in
protocolar layer. For this issue, and to grantee clarity we isolated these two
process to present them in simple manner.
4.3.1 Sending a packet from one node to another node

In this paragraph, we base on the following scenario: The network topology
consists of two equipments (instances of class equipment) connected with a
simple link (instance of class Simplelink). The two equipments, Eq1 and Eq2,
have each one a minimal configuration: namely one instance of class service
to represent application level, and a protocol. As mentioned in above, every
equipment must have at least one physical interface. Thus the protocol is an
instance on class phy that is a subclass of class protocol, namely phy1 and
phy2. In the applicative level, Eq1 is provided with an instance of the subclass
of service CBR , whereas Eq2 has an instance of class sink. The topology is
described in Fig.4.14.
The scenario sum up in the sending of only one data packet from Eq1 to
Eq2 and is summarized in Fig.4.15. In this scenario we suppose that there are
64
Figure 4.15: Sequence diagram1: message exchange
no interactions with event other than the sending of this packet, so things are
extremely simplified.
4.3.2 Running a timer in a protocol

In this scenario, we suppose that a given protocol needs to run a timer before
relaying a data packet received from the upper protocolar layer. Contrary to
the first scenario, this one needs the definition of a new class. In deed, we define
a new class that we call protocoly. This class inherits from protocol, the parent
class of all protocols. Protocoly has two new metods which are expire(timer
*) and set timer(). It also overload handle(event *) member function inherited
from protocol. handle of protocoly foresee the reception of events of type mes-
65
Figure 4.16: Topology of the second sequence diagram
Figure 4.17: Sequence diagram2: timer
sage, but also events of type timer. Fig.4.16 presents the topology defined to
run unroll the sequence diagram shown in Fig.4.17.
4.4 Conclusion
In this chapter, we detailed the simulator’s object oriented design. For this
purpose, we described the most important classes. And finally, we unrolled two
sequence diagrams demonstrating the interactions between objects via two of
the most frequent use cases of the simulator, namely messages exchanging and
timer setting. Reader may notice that we relied on simplicity in the solution
exposition in this chapter as well as in the solution design.
66
Chapter 5
Realization of the simulator

kernel
5.1 Introduction
Introduction : This chapter has two main purposes. First of all, it aims to give
a glance at the actual work conditions of the project. In different words, we will
deal with the hardware and software environments of development. Moreover,
since it is about a collaborative project in progress, it is interesting to precise
the advancement state of the software until the time of redaction of the present
document.
5.2 Hardware environment

Despite of being a collaborative project, the starting of the development was
entirely realized within the framework of this end of studies project. To be more
precise, the realization of the kernel of simulation can be considered as an indi-
vidual project. It was concretized using the following hardware configuration:
Laptop DELL (LATITUDE D410) :
Processor Speed: 1.86 GHz
RAM: 512 MB
Storage Capacity: 80 GB
Wireless: 802.11a/g
67
5.3 Software environment

In this section we check off all software tools used for the achievement of this
project.
Operating system :
Ubuntu1 : it is a complete Linux-based operating system, freely available with
both community and professional support. We used the version 6.06.
Program language :
The kernel of the simulator is fully programmed in C++. We implemented the
classes diagram referred in Fig. 4.1. We use the GNU 2 Compiler Collection3
(GCC) version 4.1.1, released on May 24th 2006. GCC was used to stand for
the ”GNU C Compiler”, but since the compiler supports several other languages
aside from C, it now stands for the GNU Compiler Collection. GCC includes
front ends for C, C++, Objective-C, Fortran, Java, and Ada, as well as libraries
for these languages (libstdc++, libgcj,...). Nevertheless, hitherto we interest
only on C++.
Text editor :
Emacs4 : it is a class of text editors, possessing an extensive set of features,
that are popular with computer programmers and other technically proficient
computer users. GNU Emacs, a part of the GNU project, is under active de-
velopment and is the most popular version. Weused the version 21.4 of GNU
Emacs.
Memory utilization checker :

Memory represents a crucial resource for simulation tools. Thus, as mentioned
in the second chapter, many of the available simulators do not scale well because
of memory footprint. In deed, with a big topology, we must foresee the genera-
tion of a phenomenon number of events. To front of this situation, we take some
prevention described in the previous chapter. For more surety, we use a software
tool to check memory utilisation. Valgrind5 is an award-winning suite of tools
for debugging and profiling Linux programs. With the tools that come with
Valgrind, we can automatically detect many memory management and thread-
ing bugs, avoiding hours of frustrating bug-hunting, making our programs more
stable. The Valgrind distribution that we use (version 3.2.1) includes four tools.
1 https://launchpad.net/distros/ubuntu
2 GNU: recursive acronym for ”GNU’s Not UNIX”, a project launched in 1984 to develop a
complete UNIX-like operating system which is free software. The widely used variants of the
GNU operating system, which use the kernel often referred to as ”Linux” are more accurately
called GNU/Linux systems.
3 GCC web site, http://gcc.gnu.org/
4 Emacs web site,http://www.gnu.org/software/emacs/
5 Valgrind web site, http://valgrind.org/
68
Among them we have a memory error detector. Furthermore, Valgrind is Open

Source and freely available under the GNU General Public License.
Collaborative work tools
The simulator’s Wiki

Since it is about a collaborative project, we created a collaborative web
site (Wiki ). ”wiki” 6 is a type of website that allows the authorized
visitors themselves to easily add, remove and otherwise edit and change
some available content.. This ease of interaction and operation makes
a wiki an effective tool for collaborative authoring. The word wiki is
a Hawaiian-language word for fast. The word is sometimes interpreted
as the backronym for ”what I know is”, which describes the knowledge
contribution, storage and exchange function.
The wiki of the simulator is lodged under the URL: https://www.labo4g.ren-
nes.enst-bretagne.fr/twiki/bin/view/Simulator/WebHome, and is in free
admission, but requires authorization for modification. It presents many
links. Among them, we find ”Meeting” that reports discussions in meet-
ings between the collaborative team of the simulator. The link heading
”Planning” contains tasks that we plan to do, or yet done. In ”Refer-
ences” we note our references as the title invokes. ”Organization” checks
off the design diagrams. And finally, we can download the source of the
simulator under ”Code”. We find also some utilization indications.
Concurrent Versions System (CVS)7
It is also known as the Concurrent Versioning System, implements a ver-
sion control system: it keeps track of all work and all changes in a set of
files, typically the implementation of a software project, and allows sev-
eral (potentially widely separated) developers to collaborate. CVS has
become inescapable in the free software and open-source worlds. CVS is
released under the GNU General Public License. We used the version
1.11.22 released on June 2006.
5.4 Overview of the current state of the simula-

tor
At the time being, the simulator works as illustrated in Fig. 5.1. Only the com-
mand line interface is available. The specification of the scenario of simulation
is done via the main function. First we must create the scheduler instance of
the simulation. Further, we can create the topology. We create our equipments,
protocols, services and links. Ordering is not important. Ever since, we attach
protocols and services of each equipment. We can create different configurations
including multiple interfaces, bridges, and so on.
6 wikipedia’s definition of Wiki: http://en.wikipedia.org/wiki/Wiki
7 CVS web site, www.nongnu.org/cvs/
69
Figure 5.1: Overview of the present state of the simulator
Until this moment, available protocols are those we can see in the global
classes diagram Fig.4.1. We notice the presence of a set of subclasses of proto-
col and service classes. As mentioned above, subclasses of the parent classes’
protocol and service form the models library of our simulator. Unfortunately,
most of them, such as TCP and IP, are not suitably implemented. They are
here only for test issues. On the other set, some other protocols are well defined.
For instance, protocols that get in touch with IEEE802.11i are properly defined.
We will focus on them on the next part of this document. The OSI modules
that are really interesting for us are primarily those relative to mobility and
wireless protocols. The physical and link layer, if considered in the perspective
of the radio emission/reception are also important. It is also very important to
have a reliable implementation of the MAC layer. At the application level it is
enough to have simple CBR modules for tests on the simulator kernel purposes.
The next step of scenario specification is defining up targets and down targets
of each protocol, and we precising the down target of each service too. Now,
the protocolar stack of every equipment is ready. We attach it to the concerned
equipment.
This process allows the creation of personalized equipments. We can create
simple equipment as in Fig 5.2, or more elaborated equipments like in Fig 5.3.
This latter represents an access point that supports the protocol IAPP 8 Wereas
the simple equipment only generates traffic and introduces a statistical delay.
Further, we interconnect equipments by attaching them to links. Now we can
schedule flows to begin at precise time of simulation. Flows are the activity of
pre created services (or applications) in equipments. Mobility is not functional
8 IAPP: inter access point protocol
70
Figure 5.2: A simple equipment structure
Figure 5.3: AP supporting IAPP modelling in the simulator
71
yet. But it will be possible to schedule mobility scenarios at short notice since
it is under work at the time of redaction of the present document.
We remind that the project remains in progress, and is likely to evolve
rapidly, as far as new protocols and applications are upgraded. Moreover, we
recall that it is a collaborative project of development which means that other
persons are working on it. For instance, at the time being, Nicolas Montavont
is implementing the IEEE Protocol 802.11, in addition to the wireless channel.
Thus we can expect that the simulator will support mobility soon. And so we
foresee a rapid implementation of the graphical interface especially when we
take in count that it will take inspiration from the GUI of SimulX.
5.5 Conclusion
This chapter gave an overview of work conditions but also of the current level
of advancement of the project. All this second part is devoted to the kernel
of simulation description. It underlines in particular the modularity and the
independency of protocols library from the simulation kernel. In the next part
we give an example that illustrates how to add a new protocol to the simulator.
72
Part III
Implementation of
IEEE802.11i in the
simulator
73
Introduction :
Previous chapters explain the parameters taken into account and the purposes
that was determinant in our work of design and realization of the simulation
kernel. The next step is the validation (and debugging) of this architecture
by implementing a protocol from the world of wireless networks standards. To
begin, we elect the IEEE 802.11i standard, protocol dedicated to security in
the local area wireless networks (WLAN IEEE 802.11). This choice is based on
the following reasons. First, it is a standard protocol of the IEEE for wireless
communication networks which is in concordance with our purpose. Second, it
is such a complicated protocol. Its range extends on several layers and levels,
and puts in interaction a set of protocols. Thus, it makes it possible to evaluate
the modularity of our simulation architecture. Finally, we need to implement
this protocol for our near future work: ”implementation and evaluation of fast
re-authentication methods”.
This part is divided into two chapters: in the first one, we describe the
standard IEEE 802.11i in addition to all the protocols that interact with it,
while trying to focus on the aspects which interest us in most for our modeling.
In the second chapter, we present our conception of the protocol in order to
implement it on the simulator. We conclude by an evaluation of this modeling
and its realization.
74
Chapter 6
IEEE802.11i standard
description
6.1 Introduction
As it is widely known today, the security problems of the early 802.11 spec-
ifications resulted in insecure implementations and thus low adoption of the
technology by enterprises. Therefore, in 2000 the IEEE initiated a work group,
”Task Group I” in order to provide enhanced security services and mechanisms
for the IEEE 802.11 medium access control (MAC). The IEEE standards com-
munity completed the revision of the security-related components of 802.11 in
2004 and proposed the IEEE 802.11i standard. This chapter aims to provide a
roadmap for readers seeking a deeper understanding of the security aspects of
802.11 WLAN. The discussion sometimes goes into considerable level of details.
This is needed because we want to be as exact as possible in our modeling of
the protocol.
As it is widely known today, the security problems of the early 802.11 spec-
ifications resulted in insecure implementations and thus low adoption of the
technology by enterprises. Therefore, in 2000 the IEEE initiated a work group,
”Task Group I” in order to provide enhanced security services and mechanisms
for the IEEE 802.11 medium access control (MAC). The IEEE standards com-
munity completed the revision of the security-related components of 802.11 in
2004 and proposed the IEEE 802.11i standard. This chapter aims to provide a
roadmap for readers seeking a deeper understanding of the security aspects of
802.11 WLAN. The discussion sometimes goes into considerable level of details.
This is needed because we want to be as exact as possible in our modeling of
the protocol.
IEEE 802.11i is such a complicated protocol because it makes use of panoply
75
of preexistent protocols in interaction. These protocols are either of IEEE stan-

dardization organism, or other organisms like IETF. In fact, IEEE 802.11i relays
on IEEE 802.1X port-based network access control protocol, which in his turn,
makes use of EAP as general authentication support. On the other hand, 802.11i
does not specify the upper layer authentication (ULA) protocol used, as it is
out of scope of the layer 2. Likewise, 802.1X does not specify the authentication
protocol used to transport messages exchanged between the authenticator and
the authentication server.
In this chapter, we’ll describe briefly all those protocols, and the interactions
between them. Concerning the non specified protocols, we’ll choose the most
used ones by default. In our description, we focus on packet format and sizes,
retransmission policy and timers if supported, and fragmentation if supported.
These are the most important features for simulation. We conclude this chapter
by a scenario6.6 that summarizes the whole authentication procedure.
6.2 The 802.1X authentication framework

802.1X is an IEEE standard which plays a key role in this new IEEE 802.11i
standard by providing authentication as well as a mechanism to distribute en-
cryption key information that IEEE 802.11i uses to provide security to a WLAN.
Both the 802.11i and 802.1x standards work hand-in-glove to make a wireless
network more robust. IEEE 802.1x is a standard for port-based network access
control. It was developed to protect access to the network and its resources until
a device proves its credentials with authentication. This prevents unauthorized
devices and attackers from accessing the network resources.
6.2.1 802.1X entities

The 802.1X framework recognises three primary types of entities or port access
entities (PAE). These are the following:
1. Supplicant: this is the port that wishes to requests access to the services
offered by the authenticator’s system. Typically, the supplicant would be
the client system, such as a laptop.
2. Authenticator: this is the port that enforces authentication before allowing
access to services that are accessible via the port. In the basic WLAN
configuration, the AP would typically be the authenticator.
3. Authentication server: this is the entity that performs the authentication
function necessary to check the credentials of the supplicant, on behalf of
the authenticator. The resulting decision consists of whether or not the
supplicant is authorized to access the authenticator’s services. The most
oft-quoted server is RADIUS, though other types of servers could also be
used.
76
Figure 6.1: Authorized and unauthorized port
From the basic description of the entities above, we can get a basic understand-
ing of the behaviour of each entity. Thus, for example, a laptop (supplicant)
seeking to gain access to LAN behind an 802.11 AP (authenticator) must first
execute an authentication protocol against the AS sitting behind the AP. If the
authentication process succeeds, the AS signals the AP to open the relevant
port on the AP to allow the client access.
6.2.2 The notion of port

An important concept in 802.1X is that of ”port”. It is the basis for the port-
based access control (PBAC) appellation of 802.1X. In a general wired network,
a port is a single point of attachment to the LAN infrastructure. In a wireless
LAN, you can consider a port as an association between the supplicant and
an access point. This port restricts access to the network resources until the
supplicant proves its credentials through authentication. To control access to a
network, the access point uses the concept of ”controlled” and ”uncontrolled”
ports illustrated in Fig. 6.1. Both these ports are logical and virtual, but
they use a single wireless association (link) between the supplicant and the
access point. The uncontrolled port allows only authentication traffic through
it. The controlled port is initially in an ”unauthorized” state that makes the
supplicant unable to access the network until it proves its credentials with the
authentication server. During the authentication phase, the supplicant tries to
establish its credentials to the authentication server using this ”uncontrolled”
port. The access point acts as a passage for the authentication traffic between
the supplicant and authentication server. The authentication server verifies and
validates the authenticity of the supplicant to access the network resources. The
access point grants or rejects access for the supplicant based on the input from
the authentication server. After the supplicant authenticates successfully with
the authentication server, the access point moves the controlled port to the
”authorized” state, allowing the supplicant to access the network.
6.2.3 Protocols used during 802.1X authentication

802.1X authentication involves several protocols.
77
Figure 6.2: EAP packet format
(Extensible Authentication Protocol) is used for the exchange of authenti-

cation information between the supplicant and the authentication server. IEEE
802.1x defines an encapsulation protocol called EAP over LAN (EAPOL) to
carry these EAP packets between the supplicant and the access point over the
wireless Ethernet link. The supplicant and authenticator use EAPOL for all
kinds of communication. The authenticator then repackages these EAP packets
using the RADIUS protocol and forwards them to the authentication server.
The access point and authentication server use EAP over RADIUS for commu-
nication. The access point exchanges EAP authentication packets between the
supplicant and authentication server with proper encapsulation; that is, EAPOL
for the packets that are meant for the supplicant and RADIUS for the packets
that are meant for the authentication server.
Moreover, one important aspect of the 802.1X is that it is an authentication
framework, within which specific authentication protocols need to be specified
by deployment. For instance, as its name suggests, EAP is designed in such
a way that the authentication mechanisms that EAP uses are extensible. The
protocol is flexible enough to allow any type of authentication mechanism over
it.
We deal in the following with protocols used by 802.1X one by one.
EAP
The 802.1X protocol makes use of the Extensible Authentication Protocol (EAP)[3]
as a way of communicating authentication information between the supplicant
and the AS, passing through the authenticator. EAP is a general protocol
that supports multiple authentication mechanisms. It is interesting that in this
mode of usage, EAP essentially becomes a lowest denomination of ”transport”
between the supplicant and the AS. A summary of the EAP packet format is
shown in the Fig. 6.2 shows EAP packet format.
Code field identifies the type of EAP packet. Four types are supported ,
namely Request, Response, Success and Failure. Request packets have a type
field to indicate what is being requested (e.g. identity, MD5-challenge).
Identifier field allows matching of responses with requests. Identifier field and
System Port together uniquely identify an authentication exchange. The Au-
78
Figure 6.3: EAPOL packet format
thenticator PAE determines the value of Identifier used in new EAP-Request/Identity

frames. The Supplicant PAE uses the same Identifier in subsequent EAP-
Response frames responding to that initial request frame. The Authenticator
PAE uses the same Identifier value in any retransmissions of the same request.
Data field is zero or more octets. The format of the Data field is determined
by the Code field.
It is important to realize that the EAP frames, exchanged between the sup-
plicant and the AS, traverse over tow different types of communication me-
dia. Between the supplicant and the authenticator, EAP is layered immediately
above the MAC layer whereas EAP is over the RADIUS protocol (over IP)
between the authenticator and the AS (RADIUS).
EAPOL
[6] 802.1X defines the encapsulation format, known as EAP over LAN or EAPOL,
which allows EAP messages to be carried directly by a LAN MAC service. The
EAPOL encapsulation is used for all communication between the supplicant and
the authenticator. EAPOL PDUs (protocol data unit) are encapsulated into an
IEEE 802 MAC frame. Fig.6.3 shows a summary of EAPOL frame format.
Packet type field’s value determines the type of packet being transmitted.
Five types are defined. For example, EAP-Packet indicates that the frame
carries an EAP packet. EAPOL-Start means that the frame is an EAOL-Start
frame. EAPOL-Key shows that the frame is an EAPOL-Key frame, used to
transmit key information between the Authenticator and the Supplicant.
The value of Packet Body length field defines the length in octets of the
Packet Body field; a value of 0 indicates that there is no Packet Body field
present.
Packet Body field is present or not according to Packet Type value. In a
frame carrying a Packet Type of EAP-Packet, this field contains exactly one
EAP packet as described the previous paragraph. In a frame carrying a Packet
Type of EAPOL-Key, this field contains exactly one Key Descriptor.
Key Descriptor frames are used to exchange encryption keys between the
supplicant and the authenticator. A summary of the Key Descriptor format is
shown in Fig.6.4.
79
Figure 6.4: Key Descriptor packet format
Finally, we notice that EAPOL do not support fragmentation. Consequently,

the maximum size of EAP packet that can be carried within an EAPOL frame
will depend on the maximum MAC frame size supported by the MAC method by
which the frame is transmitted. In our case MAC method used is MAC802.11.
RADIUS
EAP is a general encapsulating format or transport mechanism for authenti-

cation information exchange between supplicant and AS. We still need an au-
thentication protocol to be executed. Though not mandating by the 802.1X
standard, the most common way to communicate the EAP frames to the AS is
through EAP over RADIUS.
The remote dial-in user service is an authentication protocol that has wide
deployment in the dial-up Internet services world. Due mostly to its simple
password-based authentication method and simple transaction structure, RA-
DIUS has become the de facto ”authentication protocol” in the dial-up world
for IP connectivity using the PPP. More recently, interest in RADIUS has also
been extended to the new area of WLAN authentication.
RADIUS follows the client-server model, where a RADIUS client interacts
with a RADIUS server. It runs over UDP for a number of reasons that we’ll
not explain in this document. However the use of UDP implies that the end
point RADIUS entities must deploy their own reliability mechanisms to handle
lost packets. Many RADIUS implementations and deployment cases today just
use retransmission as a reliability mechanism. Within the context of 802.1X au-
thentication framework, RADIUS is the most oft-cited protocol for supporting
WLAN authentication. In this case, the 802.1X supplicant is in fact the RA-
DIUS client communicating with the 802.1X AS which is the RADIUS server.
Exactly one RADIUS packet is encapsulated in the UDP Data field, where
the UDP Destination Port field indicates 1812 (decimal). When a reply is
generated, the source and destination ports are reversed. A summary of the
RADIUS data format is shown in Fig. 6.5.
Code field identifies the type of RADIUS packet. When a packet is received
with an invalid Code field, it is silently discarded. Some of the most used
80
Figure 6.5: RADIUS packet format
RADIUS types are Access-Request, Access-Accept, Access-Reject, Accounting-

Request, Accounting-Response, and Access-Challenge.
Identifier field aids in matching requests and replies. The RADIUS server
can detect a duplicate request if it has the same client source IP address and
source UDP port and Identifier within a short span of time.
Length field indicates the length of the packet including the Code, Identifier,
Length, Authenticator and Attributes fields. Octets outside the range of the
Length field must be treated as padding and ignored on reception. If the packet
is shorter than the Length field indicates, it must be silently discarded. The
minimum length is 20 and maximum length is 4096.
Authenticator field value is used to authenticate the reply from the RADIUS
server. The actual contents of this field are determined by the type of packet
within which it is contained. For instance, when the packet is an access-request
packet, this field functions as a request-authenticator. It consists of 16 octets
of a random number generated by the RADIUS client. This number should be
unpredictable and unique over the lifetime of a secret (the password shared be-
tween the client and the RADIUS server). Authenticator field in access-accept,
access-reject, and access-challenge packets is called the response authenticator.
In this case, the field contains a one-way MD5 hash calculated over the con-
catenation of the following: the identifier, the length, the request authenticator
(from the original access-request packet), and the shared secret (shared between
the RADIUS client and the RADIUS server).
We notice that a RADIUS server must use the source IP address of the
RADIUS UDP packet to decide which shared secret to use. Moreover, the
protocol specifies the mandatory and optional attributes in every type of packet.
Finally we focus in the last field of RADIUS packet. Attributes carry the
specific authentication, authorization, information and configuration details for
the request and reply. The end of the list of Attributes is indicated by the
Length of the RADIUS packet. Some Attributes may be included more than
once. An Attribute’s description may limit which kinds of packet it can be
contained in. This applies only to the packet types mentioned in this document,
namely Access-Request, Access-Accept, Access-Reject and Access-Challenge.
Some attributes are mandatory or optional in every type of RADIUS packet.
To determine which Attributes are allowed in which packet type, we can refer
to the RADIUS Accounting document [4].
RADIUS extensibility and adaptation for 802.1X :

From the perspective of protocol extensibility RADIUS provides an attractive
81
solution as all transactions between the client and the server are based on the
3-tuple attribute-value-length. As such, a given implementation of RADIUS can
introduce its own domain-relevant extensions without affecting other implemen-
tations.
For instance, the IEEE 802.1X RADIUS Usage Guidelines [14] provides sug-
gestions on Remote Authentication Dial In User Service usage by IEEE 802.1X
Authenticators. In a similar manner, the RFC [1] defines some new attributes
like the EAP-Message attribute which is used to encapsulate EAP packets for
transmission from the IEEE 802.1X Authenticator to the Authentication Server,
likewise Message-Authenticator attribute.
In fact, since an authentication exchange occurs between the supplicant and
the AS which is the decision maker, during such an exchange, the authenticator
provides a ”pass-through” or ”relay” function. This means that the authenti-
cator needs to repackage the EAP packets for suitable delivery to the AS. This
repackaging must be done by high level function in the authenticator. Since RA-
DIUS is used for this purpose, we need a mean to encapsulate EAP messages
within RADIUS packets. EAP-Message attribute is defined for this purpose.
The AP places EAP messages received from the authenticating peer into
one or more EAP-Message attributes and forwards them to the RADIUS server
within an Access-Request message. Multiple EAP-Message attributes may be
contained within an Access-Request or Access-Challenge packet. The RADIUS
server can return EAP-Message attributes in Access-Challenge, Access-Accept
and Access-Reject packets. Multiple EAP packets must not be encoded within
EAP-Message attributes contained within a single Access-Challenge, Access-
Accept, Access-Reject or Access-Request packet.
The field value of EAP-Message attribute contains an EAP packet. If mul-
tiple EAP-Message attributes are present in a packet their values should be
concatenated; this allows EAP packets longer than 253 octets to be transported
by RADIUS.
6.2.4 Upper layer authentication (ULA)

EAP is designed in such a way that the authentication mechanisms that EAP
uses are extensible. The protocol is flexible enough to allow any type of authen-
tication mechanism over it. You can use any one of the different authentication
mechanisms, including OTP (One Time Password), MD5 (Message Digest 5),
TLS (Transport Layer Security), TTLS (Tunneled Transport Layer Security),
and PEAP (Protected Extensible Authentication Protocol), to provide authen-
tication. Each mechanism has a separate RFC to describe its usage over EAP.
However, various EAP methods for authentication and authorization deploy
an underlying TLS session to protect end-to-end communication between the
802.1X supplicant and authentication server. In other words, TLS is becoming
the de facto ULA used in 802.1X authentications. Hence, in the rest of this
report, we design the ULA protocolar layer by EAP-TLS[2].
82
6.3 802.11i
IEEE 802.11i [7], is designed to provide enhanced security in the Medium Ac-
cess Control (MAC) layer for 802.11 networks. The 802.11i specification de-
fines two classes of security algorithms; Robust Security Network Association
(RSNA), and Pre-RSNA. Pre-RSNA security consists of Wired Equivalent Pri-
vacy (WEP) and 802.11 entity authentication.
RSNA provides two data confidentiality protocols, called the Temporal Key
Integrity Protocol (TKIP) and the Counter-mode/CBC-MAC Protocol (CCMP),
and the RSNA establishment procedure, including 802.1X authentication and
key management protocols.
6.3.1 RSNA Establishment Procedure

802.11i RSNA establishment procedure consists of 802.1X authentication and
key management protocols. Three entities are involved, called the Supplicant
(the wireless station), the Authenticator (the Access Point), and the Authentica-
tion Server (de facto a RADIUS server). Generally, a successful authentication
means that the supplicant and the authenticator verify each other’s identity
and generate some shared secret for subsequent key derivations. Based on this
shared secret, the key management protocols compute and distribute usable
keys for data communication sessions. The authentication server can be imple-
mented either in a single device with the authenticator, or through a separate
server, assuming the link between the authentication server and the authentica-
tor is physically secure. The complete handshakes of establishing a RSNA are
shown in Fig.6.6[5]. For the purpose of analysis, these steps can be divided into
6 stages as the figure.
Stage 1. Network and Security Capability Discovery :

This stage consists of messages numbered (1) to (3). The AP (Access Point)
either periodically broadcasts its security capabilities, indicated by RSN IE
(Robust Security Network Information Element), in a specific channel through
the Beacon frame; or responds to a station’s Probe Request through a Probe
Response frame. A wireless station may discover available access points and
corresponding security capabilities by either passively monitoring the Beacon
frames or actively probing every channel.
Stage 2. 802.11 Authentication and Association :

This stage consists of messages numbered (4) to (7). The station chooses one
AP from the list of available APs, and tries to authenticate and associate with
that AP. Note that 802.11 Open System Authentication is included only for
backward compatibility, and a station should indicate its security capabilities
in the Association Request. After this stage, the station and the AP are in
authenticated and associated state. However, the authentication achieved so
far is weak, and will be supplemented by further steps. At the end of this stage,
the 802.1X ports remain blocked and no data packets can be exchanged.
83
84
Figure 6.6: RSNA Establishment Procedures

Stage 3. EAP/802.1X/RADIUS Authentication :

This stage consists of messages numbered (8) to (14). The supplicant and the
authentication server execute a mutual authentication protocol (de facto EAP-
TLS), with the authenticator acting as a relay. After this stage, the supplicant
and the authentication server have authenticated each other and generated some
common secret, called the Master Session Key (MSK). The supplicant uses the
MSK to derive a Pairwise Master Key (PMK); The AAA key material on the
server side is securely transferred to the authenticator, indicated by message
(15). This allows the authenticator to derive the same PMK. This stage might
be skipped if the supplicant and the authenticator are configured using a static
Pre- Shared Key (PSK) as the PMK, or when a cached PMK is used during a
Re-association.
The authentication process can be initiated either by the supplicant or the
access point. The supplicant initiates by sending an EAPOL-Start packet. The
access point responds by sending an EAP-Request/Identity packet to the sup-
plicant. The access point can directly initiate the authentication process by
sending an EAP-Request/Identity packet to the supplicant as soon as the port
has become operable with authentication enabled on it.
Stage 4. 4-Way Handshake :

This stage consists of messages numbered (16) to (19). Regardless of whether
the PMK is derived from Stage 3, configured using a PSK, or reused from a
cached PMK, the 4-Way Handshake must be executed for a successful RSNA
establishment. The supplicant and authenticator use this handshake to confirm
the existence of the PMK, verify the selection of the cipher suite, and derive
a fresh Pairwise Transient Key (PTK) for the following data session. Simulta-
neously, the authenticator might also distribute a Group Transient Key (GTK)
in message (18). After this stage, a fresh PTK (and maybe GTK) is shared
between the authenticator and the supplicant; the 802.1X ports are unblocked
for data packets.
Stage 5. Group Key Handshake :

This stage consists of messages numbered (20) and (21). In case of multicast
applications, the authenticator will generate a fresh GTK and distribute this
GTK to the supplicants. These handshakes might not be present if the fresh
GTK has been distributed in Stage 4; this stage may be repeated multiple times
using the same PMK.
Stage 6. Secure Data Communication :

This stage is indicated by (22). Using the PTK (or GTK) and the negotiated
cipher suite from above stages, the supplicant and the authenticator can ex-
change protected data packets using data confidentiality protocols. Through
these handshakes, the supplicant and the authenticator mutually authenticate
each other and establish a secure session for data transmissions.
85
6.4 Conclusion
In this chapter we described the standard IEEE protocol 802.11i. We explained
that it involves a set of protocols from IEEE and other standardisation orga-
nizations such as the IETF. We presented the specifications of each protocol
of them, including packet format, and fragmentation and retransmission policy.
We gone into an advanced level of details because it as required for a faithful
modelling of the protocol into the simulator. In the next chapter, we detail the
conception and the integration of 802.11i into our software.
86
Chapter 7
Conception and integration

of the standard into the
simulator
7.1 Introduction
We asserted in the precedent chapters that the addition of a new protocol in
our simulator requires only two manipulations. First, we may subclass the
class header to create the corresponding header to the new protocol if requisite.
Second, we must subclass the class ”protocol” to create our proper protocol.
Thus, the new protocol can be integrated to any equipment in the topology.
However, the IEEE 802.11i security protocol for IEEE802.11 WLAN makes
use of several protocols from the IEEE and other standardization organization
such as the IETF. It is in reality a set of protocolar layers and not only one layer.
Thus, we are constrained to create a subclass of ”protocol” for each protocol
that interacts within 802.11i.
In addition, 802.11i involves three devices, namely; the supplicant, the au-
thenticator server, and the authenticator. Therefore, we need also to establish
the conception of these three entities.
In this chapter, we give an overview of the three entities structure adopted
to model the supplicant, the authenticator, and the authentication server within
our simulator. Further, we describe in details classes created to simulate each
protocol invocated by the IEEE 802.11i authentication procedure.
87
Figure 7.1: Adopted structure for entities involved in 802.11i authentication

procedure
7.2 IEEE802.1X entities design in the simulator

First of all, we should make the general design of the different entities involved
in IEEE802.11i. The procedure can not take place unless the three entities are
available and provided with the needed protocols with the suitable arrangement.
Fig. 7.1 shows the minimal structure of each entity, which is necessary for
802.11i authentication. We note that these equipments may have other protocols
and services that are not in relationship with 802.11i and that are not presented
in the mentioned Fig.
The presented Fig. suggests upgrading the protocols library of the simula-
tor by creating a set of new protocols, namely EAP, EAPOL, EAP TLS, and
RADIUS. It also proposes creating a Port Access Entity (PAE) for the authen-
ticator and for the supplicant as specified in IEEE802.1X standard protocol.
7.3 IEEE 802.11i protocols classes

According to our simulator philosophy, for every new protocol created we may
create its corresponding header. Protocols are modelled with classes that inherit
from the parent class protocol, and headers are modelled with classes inherit-
88
Figure 7.2: EAP modeling in the simulator: eap and eap hdr classes
ing from header. We focus on classes created to model protocols interacting in

802.11i authentication procedure, and their corresponding headers in the fol-
lowing.
7.3.1 eap, eap hdr, eapol and eapol hdr classes

EAP is the lowest denomination of ”transport” between the supplicant, the
AP and the AS. EAP reacts according to equipment type. However, we define
only one class EAP. Fig.7.2 shows the structure of the class EAP and the class
EAP hdr that represents EAP frame header.
We deal with class EAP attributes and methods one by one:
theAS id : this attributes represents the Authentication Server identifier

by default for a Mobile Station.
bridging: if this attribute is set to 1 the equipment, which must be an AP,
EAP frames received by an interface are sent by the other interface. In
this case, the AP only repackages EAPOL packets in a RADIUS packet
and vice versa.
start auth(int MS id): this function starts the EAP authentication proce-
dure 6.6 with the MS of which the identifier is given as parameter. The
function creates an EAP request identity message and sends it to the cor-
responding MS. It is called by the EAPOL down target after reception of
an EAPOL-start message. Notice that this function is executed only in
EAP layer within an equipment of type AP. The EAP enters in bridging
mode after sending the EAP start msg.In other words, it will no more
interpret EAP messages received, but only repackage them and rely them
between the MS and the AS.
TLS finished(int AP id): The EAP TLS up target layer uses this function
to inform the EAP layer that the TLS exchanges are finished, and so
that the EAP layer can send an EAP-response-identity2. Notice that this
happens only in equipment of type MS.
89
Figure 7.3: EAPOL modeling in the simulator: eapol and eapol hdr classes
recv, recv from down, and recv from up: They are over loadings of the
functions inherited from protocol. recv checks while the EAP layer is in
bridging mode. In this case it calls repackaging function. Otherwise, it
checks the direction of the message. And according to the subtype, and
subsubtype of the EAP hdr of the message, recovered from the EAP hdr,
the function either sends the suitable response, deletes the message silently,
remove EAP header and deliver to up target or notifies the EAP TLS
to start EAP TLS exchanges by calling start auth function of EAP TLS
class.
repackaging(message *m): This method is called by the AP when EAP
layer is in bridging mode. In fact, the AP checks either the packet is re-
ceived from the 802.11 interface or from the DS (distribution system),
and removes accordingly the old header to replace it by the new one
( EAPOL hdr/RADIUS hdr). Moreover, it changes addresses to relay
EAP messages between the MS and the RADIUS. Then it sets the right
handler for the message and sends it.
In a simular manner Fig.7.3 shows EAP over LAN modeling in the simulator.
7.3.2 radius, radius hdr, eap tls and eap tls hdr classes
In this project, RADIUS design is minimal. In other terms, we plan to imple-
ment a version of RADIUS that is operational only in 802.11i authentication
framework. Still, it is possible to extend easily RADIUS in order to adapt it
with other authentication process.
Consequently, the class RADIUS does not define new methods, but only
overload some methods inherited from its parent class protocol as we can see in
Fig. 7.4.
7.3.3 The Class pae

This class acts as the Port Access Entity specified by the IEEE 802.1X stan-
dard.In other words, this entity checks emitted and received flow in both the
90
Figure 7.4: RADIUS modeling in the simulator: radius and radius hdr classes
Figure 7.5: EAP TLS modeling in the simulator: eap tls and eap tls hdr classes
Figure 7.6: Port Access Entity modeling in the simulator
91
mobile station (MS) and the access point (AP). In spite of not being really a
protocolar layer, it is represented as if, because of the similarity of behaviour.
This is why it inherits from protocol class. PAE checks the access to controlled
port. Before authentication, it allows only authentication messages to access
to the uncontrolled port. open port and block port member functions, allow or
block the access to controlled port to traffic coming from a specific node.
Moreover, since it is only an adaptation that we imagined to model the port
access entity defined in IEEE802.1X and not really a protocol, it does not tally
with a specific header, but with the parent class header.
IEEE802.1X defines two different types of PAE: the first one acts in the
Mobile Station that wants to be authenticated, whereas the second type is for
Authenticator. Likewise, we define two classes PAE client and PAE auth. Both
inherit from a root class PAE.
For instance, the mobile station has an attribute myAP id which represents
the identifier of the Access point to which the node is associated at this time,
whereas Access point has a list of authenticated mobile station (MS authenticated ),
as the same AP may be authenticated with several MSs at the same time.
7.4 Realization
We implemented all protocols and headers mentioned in the previous section.
We can find these protocols and headers in two separated files. 802.11i hdr.h,
.cpp contains the definition of the headers that are specific to IEEE 802.11i pro-
tocol and other protocols used by the 802.11i authentication procedure. These
protocols are defined in their turn in an isolated file which is 801.11i ptcl.h,.cpp.
The protocols MAC802.11, Phy802.11a in addition to MAC 802.3 are in
course of implementation by other collaborators.
7.5 Conclusion
In this chapter, we presented in details the protocol 802.11i integration into our
simulator process. First, we explained the adopted design to model equipments
involved in 802.11i authentication procedure, namely, the mobile station, the
Access point, and the authentication server. Further, we gave the detailed
description of classes allowing creating such equipments. We underlined the
extensibility of our software, and we introduced how to upgrade the protocol
library in a simple manner.
92
Chapter 8
Conclusion and prospects
Along this report, we presented the different steps of development of a new

wireless networks simulation environment.
This project begun with an initiation to event discrete simulation, giving a
brief terminology that provides the reader with basic technical background. The
sate of the art includes also an overview of different commonly used simulation
tools. For this purpose, we made a comparative study of three simulators,
namely NS-2, OMNeT++ and SimulX. Of course, we gave first the evaluation
criteria on which we based in the comparison.
Starting from this evaluation, we analysed and detailed the issues raising
from the use of these available simulators. Consequently, we notified that net-
working research community needs a new simulation tool, that would be special-
ized in wireless networks and mobility features, and will provide some specific
functionalities and properties such as extensibility, total modularity, scalability,
easiness of use for pedagogic and research purposes and an elaborated graphical
user interface.
To remedy at these issues, we proposed an approach to develop a new simu-
lation tool. We emphasized that this work would be realized in the framework
of a collaborative and progressive project. In some sense, the work described in
this document consists of the bootstrap of the project. It amounts the kernel of
simulation development, in addition to some network protocols implementation.
Further in this document, we focused on the kernel of simulation achieve-
ment steps. This second part detailed both analysis of requirements, design, and
realization of the simulator kernel. First, in the analysis requirement chapter,
we enumerated the expected functionalities and facilities from a network sim-
ulation tool. Therefore, we release the different functional and non functional
requirements. We illustrated with some use cases diagrams conform to the UML
formalism.
Next, we moved to the kernel of simulation design description. We started
with a general classes diagram overview. Then we described in details the most
93
important classes. We concluded with two sequence diagrams that show in

a simplified way the expected mode of functioning of the kernel, illustrating
interactions between different classes.
After that, we gave a glance at the project realization hardware and software
environment. Since the project remains in progress, we specified the stage of
advancement we reached. As the project is collaborative, we mentioned the tasks
and parts of the project that are currently in development by other collaborators.
All along the second part we insisted on the extreme modularity and ex-
tensibility of our simulator. To prove this, we explained how to add a new
protocol to the protocols library of the simulator with a concrete example. In
deed, we implemented the IEEE standard protocol 802.11i. This was the aim
of the third part of the report. We started with the description of the standard
specifications on the protocol. Further, we explained how we designed it to be
integrated in the simulator.
We tried to be as clear as possible in such way to allow anyone who reads the
report using or extending the new simulation tool, as soon as it will be under
OpenGL licence. This may explain the relative length of the document.
Since it is about a big project that surpasses the framework of this End
of Studies Project, a lot of enhancements are still to be done. We distinguish
immediate enhancements and long term enhancement.
Immediate enhancements are often closely related to the kernel of simula-
tion. They sum up to some local modifications with no effects on other parts
of the software. Among them, we cite the optimization of the calendar data
structure for a better management of CPU resource. We cite also the addition
of new classes that will take care of random variable, distribution and process
generation. Another near future aim is that of developing an elaborated graphi-
cal interface, taking the pattern of SimulX. Of course, making mobility features
functional is also one of our primary priorities.
Concerning the long term perspectives, we can consider that the continuity
and the success of the project depend on the upgrade of new protocols and the
enrichment of the simulator protocol library. However, the addition of some
protocols urges (e.g. IP, TCP, 802.11, 802.3). Indeed, these protocols represent
the background of most simulation scenarios.
Personally, I particularly appreciated working on this project. It was a very
enriching scientific experience as much as it was a good exercise of relatively
big project design. This allowed me to set in practice some of the knowledge
acquired during my course of engineering studies. All the more, it was a unique
occasion to experiment participation in a collaborative project.
Therefore, I plan to continue working on the development of this simulator,
but also to use it to simulate and evaluate new protocols, particularly in the
framework of master thesis.
94
Bibliography
[1] B. Aboba and P. Calhoun. Radius (remote authentication dial in user ser-
vice) support for extensible authentication protocol (eap). Technical Re-
port RFC 3579, Internet Engineering Task Force. Network Working Group,
2003.
[2] B. Aboba and D. Simon. Ppp eap tls authentication protocol. Techni-
cal Report RFC 2716, Internet Engineering Task Force. Network Working
Group, 1999.
[3] L. Blunk and J. Vollbrecht. Ppp extensible authentication protocol (eap).

Technical Report RFC 2284, Internet Engineering Task Force. Network
Working Group, 1998.
[4] A. Rubens C. Rigney, S. Willens and W. Simpson. Remote authentica-
tion dial in user service (radius). Technical Report RFC 2865, Internet
Engineering Task Force. Network Working Group, 2000.
[5] Changhua He and John C Mitchell. Security analysis and improvements
for ieee 802.11i. 2004.
[6] IEEE. IEEE Std 802.1X, 2001; IEEE Standard for Local and metropolitan
area networks, Port Based Network Access Control. 2001.
[7] IEEE. IEEE Std 802.11i 2004; IEEE Standard for Information technology,
Telecommunications and information exchange between systems, Local and
metropolitan area networks, Specific requirements, Part 11: Wireless LAN
Medium Access Control (MAC) and Physical Layer (PHY) specifications,
Amendment 6: Medium Access Control (MAC) Security Enhancements.
2004.
[8] Ricki G. Ingalls. Introduction to simulation. Simulation Conference, 2002.
Proceedings of the Winter, vol.1:7–16, 2002.
[9] Raj Jain. The Art of Computer Systems Performance Analysis. John Wiley
& Sons, 2001.
[10] Romain Kuntz. Implementation du protocole mobile ipv6 dans un sim-
ulateur de reseaux 802.11b. Technical report, Universite Louis Pasteur
Strasbourg & LSiiT, 2003.
95
[11] Jean-Marie Bonnin Mohamed Kassab, Abdelfettah Belghith. Implementa-

tion de methodes d authentification rapides sur un réseau ieee 802.11.
[12] Jean-Marie Bonnin Sahbi Sassi Mohamed Kassab, Abdelfettah Belghith.
Fast pre-authentication based on proactive key distribution for 802.11 in-
frastructure networks.
[13] N. Montavont and T. Noel. Anticipated handover over ieee 802.11 net-
works. In Wireless And Mobile Computing, Networking And Communica-
tions, 2005. (WiMob’2005), IEEE International Conference on, volume 2,
pages 64–71Vol.2, 22-24 Aug. 2005.
[14] A. Smith G. Zorn P. Congdon, B. Aboba and J. Roese. Ieee 802.1x remote
authentication dial in user service (radius) usage guidelines. Technical Re-
port RFC 3580, Internet Engineering Task Force. Network Working Group,
2003.
[15] Robert E. Shannon. Systems Simulation :The Art and Science. Prentice
Hall, 1975.
[16] A. Varga. Using the omnet++ discrete event simulation system in educa-
tion. Education, IEEE Transactions on, 42(4):11pp., 1999.
[17] Dr.-Ing. Andreas Willig. Performance evaluation techniques of simulation
software. Technical report, Telecommunication Networks Group (TKN)
Technical University Berlin, Summer 2005.
[18] Gregory K. Egan Y. Ahmet Sekercioglu, Andras Vagra. Parallel simulation
made easy with omnet++. European Simulation Symposium and Exhibi-
tion, 2003.
96

End of Studies Project Report: Ecole Nationale Des Sciences de L'informatique Laboratoire Cristal - P Ole RIM

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

End of Studies Project Report: Ecole Nationale Des Sciences de L'informatique Laboratoire Cristal - P Ole RIM

Uploaded by

Copyright:

Available Formats

Université de la Manouba

École Nationale des Sciences de l’Informatique

End of Studies Project Report

Dr. Nicolas Montavont, RSM Dept., ENST-Bretagne (Rennes, France)

Pr. Abdelfattah Belghith, RIM-CRISTAL Lab., ENSI (Manouba, Tunisia)

Presented on October, 2006

Nowadays, the multiple advantages and facilities offered by wireless networks

chaque simulateur, de ressortir leurs lacunes, et de mettre en évidence leur non

End of Studies Project Report

I State of the art 11

1 Terminology of discrete-event simulation 12

2 Comparative study of three available simulation environments 16

5 Realization of the simulator kernel 67

III Implementation of IEEE802.11i in the simulator 73

6 IEEE802.11i standard description 75

7 Conception and integration of the standard into the simulator 87

8 Conclusion and prospects 93

2.1 Scheduler by NS-2 . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1 Use case1: Researcher requirements . . . . . . . . . . . . . . . . . 47

4.1 Overview of the classes diagram . . . . . . . . . . . . . . . . . . . 51

4.14 Topology of the first sequence diagram . . . . . . . . . . . . . . . 64

5.1 Overview of the present state of the simulator . . . . . . . . . . . 70

6.1 Authorized and unauthorized port . . . . . . . . . . . . . . . . . 77

7.1 Adopted structure for entities involved in 802.11i authentication

We conclude by exposing the future prospects of the simulator.

State of the art

1.2.1 Discrete-event simulation

system. It is the ability to mimic dynamics that gives discrete-event simulation

1.3 Components and structure

System state and global variables :

Random number generator :

Comparative study of three

2.2 Network simulation tool’s evaluation crite-

ment of traffic profiles. In order to generate data traffic, it is in general nec-

2.3.2 NS-2 monitoring support

2.3.3 NS-2 internal architecture

Duality C++ - OTcl

Figure 2.1: Scheduler by NS-2

Figure 2.2: Event by NS-2

Figure 2.3: Handler by NS-2

Event scheduling and management

An Event is scheduled in the schedule list, with the following parameters: a

 Classic node structure

Agents are another important type of components of a node: they model

Figure 2.4: Classic and Mobile Nodes structures in NS

4. a MAC layer implementing the specifications of the standard IEEE

4 ns-2.29 Notes and Documentation, http://www.isi.edu/nsnam/ns/doc/index.html

Model libraries and available models

2.3.4 Evaluation and summary of NS-2 features

Scalability and efficiency

Reliability of wireless networks implementation in NS

As we are particularly interested in wireless network simulation we tested some

 Normally three radio propagation models are proposed. First a shadowing

Acceptability in the scientific community

2.4.2 OMNeT++ monitoring support

Unlike in NS-2, there are no pre defined network entities in OMNeT++. In

scenario becomes a hard and long mission.

 GUI for simulation execution, links into simulation executable (Tkenv)

2.4.3 OMNeT++ internal architecture

General structure and topology representation

There is no pre established node or equipment model supported by this simu-

 An Ethernet interface (eth[0]).

Classic node structure

Normally three radio propagation models are proposed. First a shadowing

GUI for simulation execution, links into simulation executable (Tkenv)

An Ethernet interface (eth[0]).

cSimulation has a single instance. It stores the network and manages

cWatch is the class that rules the simulated time .

Ethernet: a detailed Ethernet model is available from CTIE. This model

The Mobility Framework (MF) mentioned above supports also simulations

SensorSimulator at Louisiana State University

move.log: log every movement of nodes

He specifies the scenario to simulate without need to know the internal

He can define movements and mobility scenarios: target position or ran-

Handovers are associated to mobility. The simulator must allow testing

Scalability is also necessary, which implies a good memory management.

A developer needs modularity of implementation. To add a new protocol,

Simulation model and selection of level of details