Porting IEEE 802.15.4 Model from INET framework to MiXiM

Transcription

Computer and Communication Systems
Lehrstuhl für Technische Informatik
Alexandra Jäger
Porting IEEE 802.15.4 Model from INET
framework to MiXiM framework
Bachelor Thesis
16. Mai 2013
Please cite as:
Alexandra Jäger, “Porting IEEE 802.15.4 Model from INET framework to MiXiM framework,” Bachelor
Thesis (Bachelorarbeit), University of Innsbruck, Institute of Computer Science, May 2013.
University of Innsbruck
Institute of Computer Science
Technikerstr. 21a · 6020 Innsbruck · Austria
http://ccs.uibk.ac.at/
Porting IEEE 802.15.4 Model from INET
framework to MiXiM framework
Bachelor Thesis
vorgelegt von
Alexandra Jäger
geb. am 15. Dezember 1990
in Bludenz
angefertigt am
Lehrstuhl für Technische Informatik
Institut für Informatik
Leopold-Franzens-Universität Innsbruck
Betreuer:
Abgabe der Arbeit:
Noorsalwati Nordin
Christoph Sommer
16. Mai 2013
Erklärung
Ich versichere, dass ich die Arbeit ohne fremde Hilfe und ohne Benutzung anderer
als der angegebenen Quellen angefertigt habe und dass die Arbeit in gleicher
oder ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen hat und
von dieser als Teil einer Prüfungsleistung angenommen wurde.
Alle Ausführungen, die wörtlich oder sinngemäß übernommen wurden, sind als
solche gekennzeichnet.
Declaration
I declare that the work is entirely my own and was produced with no assistance
from third parties.
I certify that the work has not been submitted in the same or any similar form for
assessment to any other examining body and all references, direct and indirect,
are indicated as such and have been cited accordingly.
(Alexandra Jäger)
Innsbruck, 16. Mai 2013
Abstract
A significant accomplishment in advancing the importance of Wireless Sensor
Networks (WSN) in industrial applications has been the introduction of the
IEEE 802.15.4 standard, since it provides guidelines after which to model the
functionality of devices operating in Low-Rate Wireless Personal Area Networks
(LR-WPAN). To study the standard, a simulation model using the simulation
framework OMNeT++ and the INET framework has been implemented. Since
the standard only defines the physical and MAC layer, it is important to model
these layers as exactly as possible, but the INET framework offers only limited
support for the lower layers of wireless protocols. Therefore this thesis describes
the process of replacing the INET framework with the MiXiM framework, which
offers a detailed model of the physical layer and channel. The first step has been
to analyze the exact differences of the frameworks, then to replace functions
where possible and reimplement them where not, always using as much of
MiXiM’s functionality as possible. This was followed by the verification of the
ported model, comparing it with the original version. The results show that
the migration has been successful. This makes it possible to conduct new, more
complex simulations especially to study the physical layer in more detail.
thesis.tex
2013-05-16
iii
21:12:09
Kurzfassung
Eine beachtliche Leistung zur Förderung der Bedeutung von WSN in industriellen
Anwendungen war die Einführung des IEEE 802.15.4-Standards, da er Richtlinien
einführt, nach denen die Funktionalität von Geräten für LR-WPAN modelliert
werden kann. Um den Standard untersuchen zu können wurde ein Simulationsmodell mit dem Simulations-Framework OMNeT++ und dem INET-Framework
implementiert. Da der Standard nur die physikalische and die MAC Schicht spezifiziert ist es wichtig, diese so genau wie möglich zu modellieren. Das INET Framework bietet aber nur eingeschränkte Unterstützung für den unteren Schichten
von kabellosen Protokollen. Deshalb beschreibt diese Arbeit den Prozess der
Ablösung des INET-Frameworks durch das MiXiM Framework, welches ein detaillierteres Modell der physikalischen Schicht und des physikalischen Kanals bietet.
Der erste Schritt bestand darin, die genauen Unterschiede der Frameworks zu
analysieren, dann Funktionen soweit möglich zu ersetzen und die fehlenden
Funktionen eigenhändig zu implementieren, immer mit dem Ziel, soviel von
MiXiMs Funktionalität wie möglich zu nutzen. Darauf folgte die Überprüfung
des portierten Modells durch Vergleichen von Simulationsresultaten mit der originalen Version. Die Ergebnisse zeigen, dass die Portierung erfolgreich war. Dies
ermöglicht es, neue und komplexere Simulationen durchführen, um vor allem
die physikalische Schicht genauer zu untersuchen.
thesis.tex
2013-05-16
iv
21:12:09
Contents
Abstract
iii
Kurzfassung
iv
1 Introduction
1
2 Fundamentals
3
2.1 IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.2 OMNeT++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.3 INET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.4 MiXiM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5 Existing IEEE 802.15.4 model . . . . . . . . . . . . . . . . . . . . . . 13
3 Porting the Model
15
3.1 Theoretical Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 System Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.1 PHY Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.2 MAC Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.3 Higher layers and Utility files . . . . . . . . . . . . . . . . . . 23
4 Analysis
24
4.1 Simulation Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1.1 3 Node scenario . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.2 21 Node scenario . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2 Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2.1 Verification of the migration to OMNeT++ 4.2.2 . . . . . . 29
4.2.2 Verification of the migration to MiXiM . . . . . . . . . . . . . 29
5 Conclusion
39
Bibliography
45
thesis.tex
2013-05-16
v
21:12:09
Chapter 1
Introduction
Wireless Local Area Networks (WLAN) are only one large-scale example for
how networks influence and enrich our everyday life [1]. Especially industrial
environments start to depend more and more on wireless technology, in particular
Wireless Sensor Networks (WSN), for monitoring and controlling their systems
[2]. An important step in establishing the use of WSN in industrial environments
has been the introduction of the IEEE 802.15.4 standard. The protocol is intended
for Low-Rate Wireless Personal Area Networks (LR-WPAN), defining its objectives
to be low latency, energy efficiency and low device cost [3], which are all qualities
that the industry demands [4]. The standard focuses on the physical and MAC
layer, leaving the definition of upper layers open for protocols building upon the
standard. An example for such a protocol is ZigBee, which defines the network
and application layer as well as security measures [5].
To study the IEEE 802.15.4 standard further, Feng Chen and Falko Dressler have
developed a simulation model using the popular simulation platform OMNeT++
[6]. OMNeT++ has been chosen for a number of reasons. Although network
simulators like JiST and ns-3 surpass OMNeT++ in terms of simulation time, they
lack graphical support [7]. OMNeT++, however, offers a powerful Eclipse-based
IDE, complete with a graphical interface for debugging and running simulations
as well as acceptable simulation time. Various useful frameworks exist to enhance
OMNeT++’s functionality and offer support for specific protocols, two of the
most important being INET and MiXiM. According to [8], using a simulation
instead of conducting a real-world experiment has many advantages. Firstly, it is
an inexpensive way to be able to test various device types, a variable number
of devices and parameter combinations. In this case, basically all that is needed
is a computer and OMNeT++, which is free for academic use. Secondly, in real
life it is almost impossible to generate the exact same conditions for multiple
experiments, whereas in a simulation it is fairly easy.
thesis.tex
2013-05-16
1
21:12:09
1 Introduction
2
The goal of my bachelor thesis is to port the already existing IEEE 802.15.4
model, which has been developed on OMNeT++ version 3.x and uses the INET
framework, to OMNeT++ version 4.2.2 and using MiXiM framework instead of
INET. MiXiM has been chosen to replace INET because it offers greater support
for wireless protocols as well as a - for my project - more useful approach to
the physical layer. The effects that occur on the physical channel during the
transmission of packages (e.g.: path loss, shadowing effects) can be simulated
more accurately.
This thesis is structured as follows. As a starting point in my project I began to
familiarize myself with the IEEE 802.15.4 standard, OMNeT++, INET and MiXiM
as well as the existing model. The first step which actually involved working
with the original model was the task of porting it to OMNeT++ version 4.2.2.,
followed by the verification of the migration. For the verification I executed
several simulations and compared them to simulation results gathered using
the original model. Afterwards, I replaced and enhanced all functionality that
was taken from INET by using functions provided by MiXiM, and implemented
missing but necessary functions myself. As a last step I verified the project anew,
once more conducting simulations and comparing the results with data derived
from the original version.
thesis.tex
2013-05-16
21:12:09
Chapter 2
Fundamentals
In this chapter I will give a brief overview of all technology and knowledge employed in my thesis. The first section is an introduction to the IEEE 802.15.4
standard. The next section is about the simulation framework OMNeT++, followed by a summary of both frameworks developed for OMNeT++ that I am
using in my project, INET and MiXiM. The last section consists of an overview of
the existing IEEE 802.15.4 model developed in OMNeT++ by Feng Chen and
Falko Dressler.
2.1
IEEE 802.15.4
The IEEE 802.15.4 standard describes a transmission protocol for low-rate wireless personal area networks (LR-WPANs), defining the physical (PHY) and MAC
layer. Higher layers are not defined in the standard. It was created for devices that
have limited or no battery power, operate in the Personal Operating Space (POS)
of 10m, and are moving, stationary or portable. The main development goals
have been low battery consumption, inexpensive hardware, low complexity and
low data-rate [9].
Two topologies are supported: star topology and peer-to-peer topology. In the
star topology, devices communicate using a single central controller, termed
PAN coordinator, as an intermediary. In peer-to-peer networks every device can
communicate with any other, given that they are within communication range.
Nevertheless, a peer-to-peer network still has a PAN coordinator. Devices of
both topologies have unique 64-bit extended addresses as well as short 16-bit
addresses, which are allocated by the Personal Area Network (PAN) coordinator
on association. Both address types can be used to identify a device in a network.
For every PAN a unique identifier is chosen to allow communication using short
addresses. Typically a PAN coordinator is mains powered, whereas devices rely
thesis.tex 2013-05-16 21:12:09
3
2.1 IEEE 802.15.4
4
on batteries.
An IEEE 802.15.4 networks consists of two different device types: the FullFunction Device (FFD) and the Reduced-Function Device (RFD). Whereas a FFD
can act as a PAN coordinator, a RFD is intended for very simple applications
that do not have the need to transmit large amounts of data. Furthermore, a
RFD can only be associated with one FFD at a time. To form a network, two or
more devices need to use the same channel, and one of them has to act as a PAN
coordinator.
Each LR-WPAN device contains at least one complete physical layer, including a
the Radio Frequency (RF) transceiver. It serves as an interface between the MAC
sublayer and the radio channel, as depicted in figure 2.1. Every PHY offers two
services [9]:
PHY data service Controls transmission and reception of PHY Protocol Data
Units (PPDU). The PHY data service is accessed through the PHY data service access point (PD-SAP).
PHY management service Provides management functions such as activate/deactivate radio transceiver. Also maintains a database of objects associated
with the PHY. The PHY management service is accessed through the PHY
layer management entity - service access point (PLME-SAP).
The MAC sublayer offers two services [9]:
MAC data service Controls transmission and reception of MAC protocol data
units (MPDU) using the PHY data service. The MAC data service is accessed
through the MAC common part sublayer - service access point (MCPS-SAP).
MAC management service Provides management functions such as beacon management, Guaranteed Time Slots (GTS) management or association/disassociation. The MAC management service is accessed through the MAC
sublayer management entity - service access point (MLME-SAP).
Figure 2.1 illustrates how the MAC layer communicates with the other layers.
One of the main features of the standard is the optional use of the superframe
structure. The coordinator defines the superframe format. Bounded by network
beacons, it consists of 16 equal time slots. The beacon transmission starts at the
first slot of the superframe. The duration between two beacons is determined
by the beacon order (BO) parameter. Beacons are used for synchronization,
identification of a PAN and description of the superframe structure. If beacons
are active, the network is in the so-called beacon-enabled mode.
A superframe can have two phases: an active and an inactive portion (see figure
2.2). The length of the active portion is determined by the superframe order (SO)
parameter.
thesis.tex
2013-05-16
21:12:09
2.1 IEEE 802.15.4
5
Upper layers
MLME SAP
MCPS SAP
MAC
PLME SAP
PD SAP
PHY
Physical Medium
Figure 2.1 – LR-WPAN device architecture. Adhering to the ISO-OSI model,
the device is split into layers which only communicate over well defined
interfaces. Source: [9]
Beacon frame
Inactive Period
Active Period
time
Figure 2.2 – Possible superframe structure. A superframe consists of an
active portion (CAP) and an optional inactive portion (CFP), bounded by
beacons. Source: [9]
This enables the coordinator to enter a low power mode during the inactive
portion. The active phase can further be divided into two periods: the Contention
Access Period (CAP) and the Contention-free Period (CFP), see figure 2.3.
A device wishing to communicate in the CAP has to use slotted CSMA-CA to
compete for its time. Backoff periods are synchronized with the start of a beacon
transmission and the PAN coordinator. A device wishing to send data searches for
the boundary of the next backoff period. Then it waits for a random number of
backoff periods. Transmission begins on the boundary of the next backoff period,
if the channel is found to be idle. If the channel is busy, the device waits for
Beacon frame
CAP
CFP
GTS
1
16
Slot index
time
Figure 2.3 – A superframe with no inactive portion but 4 allocated GTS
slots. Source: [9]
thesis.tex
2013-05-16
21:12:09
2.1 IEEE 802.15.4
6
another random number of backoff periods then tries again. The CFP is formed
by GTS, which are allocated by the PAN coordinator for applications requiring a
specific bandwidth or low latency. There can be up to seven GTS, and a GTS is
permitted to fill more than one slot period. Nevertheless, an adequate portion of
the CAP must remain to allow for contention-based traffic.
The use of a superframe structure is optional. In non-beacon-enabled PANs
unslotted CSMA-CA is used for data and MAC command frames.
In the IEEE 802.15.4 standard the concept of primitives is used to describe
the services offered from a layer to its higher- or sublayer [9]. How the service
is provided is not designated by the primitive. By describing the service primitives and its parameters, a service is specified. There are four generic types of
primitives:
Request A service should be initiated.
Indication Indicates an internal event.
Response Completes a process requested by an indication primitive.
Confirm Transmits the result of previous service requests.
The concept is shown in figure 2.4.
2.2
OMNeT++
”OMNeT++ (...) is an extensible, modular, component-based C++ simulation library
and framework which also includes an integrated development and graphical runtime environment.” [10] It was designed to be as generic as possible, therefore
enabling developers and researchers to make use of OMNeT++1 in various domains, such as queueing networks, wireless and ad-hoc network simulations and
1
http://www.omnetpp.org/
Figure 2.4 – Service primitives. This is a very general principle; a request
from one layer to another yields an indication in the recipient, which
typically prompts a response that is sent to the origin of the request using
a confirm primitive. Source: [9]
thesis.tex
2013-05-16
21:12:09
2.2 OMNeT++
7
peer-to-peer networks. Domain specific functionality is added by independently
developed frameworks. It offers a powerful Eclipse-based IDE, a graphical simulation runtime environment and a graphical debugger interface. For executing
simulation batches, a simple command line interface is provided.
Concepts are modeled as model components, termed modules. An active module
is called simple module, and is implemented in C++. Several modules can be
grouped into so called compound modules, with no limitation on the number of
hierarchy levels [10]. Simple modules usually represent protocols like UDP or
single network layers, whereas compound ones represent entities like hosts or
routers. Communication takes place through message passing. Simple modules
typically exchange messages using gates.
It is possible for modules to have parameters. They are mainly used to configure
simple modules and define the model topology. Double, integer, boolean, string
and XML element tree are valid parameter types. Default values, measurement
units and other attributes may be assigned to them. To pass stochastic data to
modules, OMNeT++ has introduced the concept of volatile parameters. Labeled
with the volatile keyword, a parameter will be re-evaluated each time their value
is read. [10]
OMNeT++ developed its own language for describing the component model: the
Network Description (NED) language [10]. Typically, the NED language is used
in the following three scenarios:
Simple module declarations Describes the module’s interface: used gates and
parameters are defined here.
Compound module definitions Describes the module’s external interface: used
gates and parameters are defined here. Furthermore, the module’s submodules and how they communicate with each other is outlined.
Network definitions Describes special compound modules: they can act as selfcontained simulation models.
The NED language makes it possible to add metadata annotations to most language items like connections, submodules or parameters. Typical uses are the
storage of graphical attributes like position or icon of an element or the specification of measurement units.
Various frameworks are available for OMNeT++ to add domain specific functionality. Two are of special interest to for the scope of this thesis:
INET The INET framework is an open-source project and offers models for mainly
wired protocols (TCP, UDP, etc.) [10]. A more detailed description of the
INET framework can be found in section 2.3.
thesis.tex
2013-05-16
21:12:09
2.2 OMNeT++
8
MiXiM MiXiM offers models for wireless networks, mobile and fixed. It was
formed merging several frameworks supporting mobile and wireless simulations. [11] I will discuss MiXiM in more depth in section 2.4.
OMNeT++ uses the make command to build simulation models. A makefile can
be created automatically using OMNeT++ tool opp_makemake. It is possible to
influence the makefile creation by providing a makefrag file. If such a makefrag
file exists and opp_makemake is run, the complete file is textually included in the
makefile.
OMNeT++ created a special simple language to facilitate describing messages
[10]. A sample message description:
message Ieee802154AppPkt
{
string sourceName;
// name of the source node
string destName; // name of the destination node
simtime_t creationTime; // creation time of the packet
}
opp_makemake uses the tool opp_msgc to translate such message files into C++
code, offering standard functions like attribute accessors or a duplicate function.
Special files, termed ini-files, are used to configure simulations. Ini-files specify the
NED file which is used for the network and make it possible to define simulation
options (e.g. a time limit, output file names). Furthermore, it is possible to supply
values for model parameters for which no default value was specified or in case
that the default value is not suitable for the simulation at hand. Multiple named
configurations can be contained in one ini-file, to alleviate running simulations
with different basic networks, options and parameters in the same project. It
is also possible to define parameter studies employing iteration variables using
the syntax $maxNumHops=5..10,20,30. Simulation runs are generated for each
parameter study. If more than one iteration variable is used, a constraint can be
added to filter out unsuitable combinations. Example of an ini-file:
[General]
network = src.wpan.networks.Ieee802154StarNet
sim-time-limit = 1000s
[Config c1]
network = src.wpan.networks.Ieee802154StarNet
**.coreDebug = false
**.numHosts = 21
thesis.tex
2013-05-16
21:12:09
2.2 OMNeT++
9
[Config c2]
network = src.wpan.networks.Ieee802154P2P
**.coreDebug = true
**.numHosts = ${1,2,3,4,5..10}
There are multiple ways to run simulations in OMNeT++. The first one is using
the graphical runtime environment. This is especially useful to understand how
a certain simulation works or to check whether it works correctly. It is possible
to pause the simulation execution, enabling the user to explore the module
output of every object of the simulation at any time [12]. However, using the
graphical environment is not feasible for running simulation batches. Therefore,
OMNeT++ offers the program opp_runall, which makes it possible to specify
the configuration that should be used and the number of runs that should be
executed.
The objective of most simulations is to gather and analyze statistical data. In
OMNeT++, this data is written to result files can have one of three types:
scalar A single number.
vector A timestamped series of values.
statistics Records consisting of various statistical properties like minimum, maximum, mean, variance, etc.
Scarlars and statistics are recorded by collecting values in class variables and
writing them to textual, line-oriented scalar files in the finalization phase using
record calls. Vectors use output vector objects, which are written to vector files.
Using OMNeT++’s integrated result analysis tool, a set of result files can be
specified to make their data browsable. It can be represented in tables, charts
or various other ways [10]. For processing result data on the command line,
OMNeT++ offers the tool scavetool. It is used to filter the simulation data and
produce output files of various data formats like vec, csv, octave or matlab. These
can be used by other programs to plot and analyze the data.
2.3
INET
The INET framework2 is one of the more widely used network simulation packages
built upon OMNeT++. The project is open-source and offers models for various
common wired protocols like UDP, TCP or IPv4 [12]. INET uses the same modeling
concept as OMNeT++: protocols are represented by simple modules, interfaces
2
http://inet.omnetpp.org/
thesis.tex
2013-05-16
21:12:09
2.3 INET
10
are described using the NED-language and the implementation is done using
C++. Compound modules model network devices such as hosts or routers;
communication takes place via message passing.
INET, as it is now, has emerged from combining various functionality into one
comprehensive framework. INET’s predecessor has been the IPSuite, developed
at the University of Karlsruhe3 . After a period of it being unmaintained, Andras
Varga took over the development and rewrote and extended significant parts,
creating the name INET. Support for wireless and mobile protocols has been
derived from the Mobility Framework.
2.4
MiXiM
MiXiM4 (mixed simulator) is an open-source network communication simulation package for OMNeT++. Focusing on wireless and mobile simulations, it
offers extensive support for simulating the physical channel [11] as well as many
common protocols. In my project I will use MiXiM version 2.3.
MiXiM has been created combining and extending several already existing frameworks. Support for mobility and connectivity has been taken from the Mobility
Framework (MF). The models for radio propagation have been integrated from
the Channel Simulator (ChSim). Furthermore, the Mobility Framework, the MAC
Simulator and the Positif framework have provided the protocols that have been
used to build MiXiM’s protocol library. Among other things, MiXiM has added
full 3D support, models for simulating real world objects (e.g. walls, houses) that
influence radio wave propagation and mobility of nodes as well as introduced
more MAC protocols [11]. One of these protocols is the IEEE 802.15.4. However,
only the non-beacon-enabled mode is offered.
Basically MiXiM can be split into two groups: the basic framework and protocol
specific modules [11]. Modules that constitute the basic framework will be used
in almost every simulation. Some of the most important are:
World The world utility module manages global simulation parameters. Examples for such parameters are the dimensions of the space the simulation
takes place in (playground), or whether the playground is to be handled as
a torus.
Object Manager The ObjectManager module is responsible for keeping track of
all the obstacles placed on the playground and offers methods to the rest
of the simulation.
3
4
http://inet.omnetpp.org/doc/INET/neddoc/index.html
http://mixim.sourceforge.net/
thesis.tex
2013-05-16
21:12:09
2.4 MiXiM
11
Connection Manager The ConnectionManager module manages connections
between nodes. For this purpose it saves and periodically updates the
position of all nodes on the playground. Nodes are connected as long
as they are within the maximal interference distance of each other. The
maximal interference distance between two nodes is defined as the distance
in which the first node’s transmission can still interfere with the other node’s
reception of messages. Obstacles between nodes can also influence the
maximal interference distance. Therefore, ConnectionManager can query
object positions from the ObjectManager and use them in its computation.
Nodes in MiXiM have a specific structure. All node functionality is divided
into layers as specified in the IP model [11]. Therefore, a typical node has an
application layer, a network layer, a MAC layer and a physical layer, whereby
the MAC and physical layer are usually grouped into a NIC (Network Interface
Card) module. A special feature of MiXiM is that between each layer two pairs
of OMNeT++ gates are used for communication: the first one for data message
passing, and the second one is used to pass control messages. Moreover, a node
module generally contains up to four modules used to simulate other aspects
than the direct functionality. The three most important are:
Mobility This module is responsible for the movement of the node. This includes
handling a node moving out of the playground’s borders and collision
handling.
ARP This module represents the Address Resolution Protocol (ARP) and is used
to transform network addresses into MAC addresses.
Battery The battery module is responsible for simulating energy consumption
in a node.
MiXiM has introduced the concept of Signals to simulate real signals, transmitted over a physical channel. A signal has three mandatory attributes: transmission
power, bit rate and attenuation. It is created at the sender’s MAC layer, where the
attributes transmission power and bit rate are set. The attenuation attribute is
set at the receivers physical layer, after the defined AnalogueModels have been
applied.
MiXiM’s physical layer module consists of five parts [13]:
AnalogueModel AnalogueModels simulate effects that can attenuate the signal.
It is possible to use multiple AnalogueModels in a simulation. A very basic
one is the RadioStateAnalogueModel, which simulates the effect the state of
the radio has on a signal. If the radio state is anything other than RECEIVE,
the attenuation factor will be 100%, whereas no attenuation is occurring if
the radio state is RECEIVE.
thesis.tex 2013-05-16
21:12:09
2.4 MiXiM
12
ChannelInfo ChannelInfo stores all airframes that are currently being detected
on the channel. As soon as a new reception starts, the airframe is given
to ChannelInfo to be kept in a list of active frames. Once the reception is
complete, the frame’s status will be changed to inactive. It will be removed
as soon as it is not interfering with any other active airframe anymore.
Decider The Decider checks the received data and categorizes it either as data
or noise.
Radio The Radio simulates the transceiver, complete with optional switch times
needed to switch from one state (RECEIVE, TRANSMIT, SLEEP) to another.
The switch times can be set manually. If they are greater than zero, a control
message will be sent to the MAC layer as soon as the switching is finished.
BasePhyLayer The BasePhyLayer interacts with all parts mentioned above to be
able to offer basic physical layer functionality: transmit/receive messages,
detect collisions and calculate bit errors.
In figure 2.5 the physical layer is shown as a class-graph.
Energy consumption functionality has been derived from [14] and behaves
the following way: for every radio state change, the energy spent in the state
before is computed by multiplying the time since the last radio switch with the
last known current and then subtracted from the available capacity. During the
radio state switch the current for the next update of the energy levels is set.
Although the INET framework is the main OMNeT++ framework, for my project
<<interface>>
MacToPhyInterface
BasePhyLayer
send/recv
<<interface>>
DeciderToPhyInterface
1
*
Decider
1
1
1
ChannelInfo
Radio
AnalogueModel
logs
Radio-state
creates
PHY
processes
ConstMapping
*
Mapping
3
bitrate,-TX-power,-RX-power
attenuation
*
1
AirFrame
Signal
signal-function
Figure 2.5 – A class graph of MiXiM’s physical layer. Source: [13]
thesis.tex
2013-05-16
21:12:09
2.4 MiXiM
13
MiXiM is better suited. There are various reasons for that. On the one hand, IEEE
802.15.4 specifies the physical and MAC layer of a wireless protocol. Compared
to INET, MiXiM offers more extensive support for the lower layers of wireless
protocols. An example is the in MiXiM already offered IEEE 802.15.4 MAC layer
implementation of the non-beacon-enabled mode. Furthermore, using MiXiM
it is possible to model the physical layer more detailed. The principle of AnalogueModels together with the Signal class provides a simple, comprehensive and
flexible way to simulate attenuation effects of the physical channel on a physical
signal. A variety of predefined AnalogueModels are already offered. To name a
few, models for LogNormalShadowing, JakesFading and a SimplePathlossModel
are included in MiXiM version 2.3. Last but not least, the possibility to simulate
non-zero radio switch times is another reason for favoring MiXiM over INET.
Using this feature, the radio transceiver can be modeled more extensively.
2.5
Existing IEEE 802.15.4 model
The existing IEEE 802.15.4 model has been developed by Feng Chen and Falko
Dressler, using the OMNeT++ simulation environment and the INET framework.
The two main modules are the PHY and the MAC module, as described in the
standard. This model is the starting point of my thesis.
The PHY module has been created according to the standard, offering capability
to send/receive messages, detect collisions and perform clear channel assessment
(CCA). INET’s class RadioState simulates the radio, offering the radio states RECV,
IDLE, TRANSMIT and SLEEP. Functions to set a new radio state, change the
channel as well as set the bitrate are available. Furthermore, INET’s module
NotificationBoard is used to notify the MAC layer of changes to the radio state
or channel. When a message from the upper layer is received, it is determined
whether it is data to be sent or a primitive containing a request by checking the
message’s kind. In the case of a data message, it is sent to the channel and a
timer starts to indicate when the transmission is over so that a confirm primitive
can be returned to the MAC layer. If it is a primitive, the corresponding task will
be performed and a confirm primitive will be returned to the MAC layer. When
a message is received from the channel, the physical layer checks whether the
signal’s received power is above the sensitivity threshold. If that is the case, the
message is again checked to determine bit errors or collisions. Afterwards the
message is handed to the MAC layer.
The MAC module is the main part of the IEEE 802.15.4 simulation model and
contains all functions necessary to use the beacon-enabled as well as the nonbeacon-enabled mode. In the standard, three data transfer modes are defined [9]:
thesis.tex
2013-05-16
21:12:09
2.5 Existing IEEE 802.15.4 model
14
Direct The PAN coordinator always sends a node’s pending data as soon as it is
able to.
Indirect Either the PAN coordinator includes a list of pending messages in its
beacon and the device notifies the coordinator that it is ready to receive, or
the device itself asks the coordinator whether data is awaiting transmission.
GTS In GTS transmission mode, every node that wants to transmit or receive has
to allocate slots in the CFP using the PAN coordinator. If a transmit GTS
has been allocated, pending data will be sent to the coordinator without
delay. If a receive GTS has been allocated, the radio state will be switched
to RECEIVE and a possible data transmission will be awaited.
In this implementation of the model, only direct and GTS transmissions are
implemented. However, support for duplicate checking, sending and receiving
ACK’s and filtering of frames is offered. Furthermore, slotted (beacon-enabled) as
well as unslotted (non-beacon-enabled) CSMA-CA is implemented. Functions for
beacon transmission and reception are offered as well, although the association
process has been simplified. Some other related functionality, like channel scans
and the disassociation process, has not been modeled. Energy consumption is
monitored by keeping track of the total time the radio spends in each state and
calculating the energy amount at the end of the simulation.
Lastly, a simple traffic generator as well as an application and network layer
implementing a very simple version of the star topology are offered.
thesis.tex
2013-05-16
21:12:09
Chapter 3
Porting the Model
This chapter is dedicated both to the migration of the existing IEEE 802.15.4
model from OMNeT++ version 3.x to version 4.2.2 and from INET to MiXiM
framework. In comparison to the INET framework, MiXiM offers models for
the physical layer and channel that are more suitable for my project. As these
are two of the most important factors in wireless transmissions, it is reasonable
to replace INET with MiXiM to achieve a better approximation of reality. This
chapter is structured as follows. The first part consists of the theoretical approach
I’ve applied to port the project. The second part describes how the system was
ported, including implementation details.
3.1
Theoretical Approach
As a first step I examined the code of the project to identify which classes in the
original project use which INET references, moreover determining what functionality these offer. Using this data I explored the MiXiM framework, searching for
classes and modules that offer similar functionality. This results of this process
are summarized in table 3.1.
Basically all of INET’s functionality is available in MiXiM, with the exception
of a passive queue model and the radio state IDLE. Since MiXiM is currently in
the process of being integrated in INET, some classes and modules are exactly
the same. All other classes I examined closely to determine what differentiates
them from those offered in INET.
thesis.tex
2013-05-16
15
21:12:09
3.1 Theoretical Approach
INET class
RadioState
16
MiXiM equivalent
MiximRadio
NotificationBoard NotificationBoard
NotifierConsts
NotifierConsts
INotifiable
INotifiable
Energy
SimpleBattery
BasicMobility
MobilityBase
IChannelControl
ChannelControl
BaseConnectionManager
ConnectionManager
ChannelAccess
ConnectionManagerAccess
IRadioModel
IReceptionModel
RadioStateAnalogueModel
Airframe_m
MiximAirFrame
ModuleAccess
FindModule<T>
BasicBattery
BaseBattery
Functionality
Stores current radio state as
well as related parameters such
as channel number.
Notifies members that have
subscribed to a module of
changes (e.g.: radio state,
node failure) within the module.
Interface that has to be implemented to be able to subscribe
to another module.
Stores the node’s current energy level and offers means to
simulate energy consumption.
Base class for all mobility modules, offers random placement.
Controls the channel, keeps
track of neighbors as well as
the interference distance of a
node.
Basic physical layer class, offers functions for ChannelControl and ConnectionManager.
Offers functions to calculate
the received power of a transmission.
Basic message class for airframes.
Finds a pointer to the module
with a given name and type,
then returns it.
Basic class for any battery module.
Table 3.1 – INET functions in the original model, their MiXiM equivalents
and their purpose.
thesis.tex
2013-05-16
21:12:09
3.2 System Migration
3.2
17
System Migration
The very first task was to port the existing model from OMNeT++ version 3.x to
version 4.2.2. OMNeT++ facilitates this by offering several automatic migration
scripts that can be run on the existing simulation model. Migratened, migrateini,
migratemsg and migratecpp change all NED, ini, msg and C++ files to be conform to the 4.x format. Because not everything can be migrated automatically,
some manual post-processing is necessary. Due to the change in the project file
structure to a package system not unlike the one employed in Java, all NED files
in subdirectories now need package declarations and imports. Using the IDE this
can be done automatically.
Besides replacing INET functions with MiXiM functionality, my goal for the actual
migration of the model was to make as much use of MiXiM as was feasible.
Inheritance plays an important role in the new model. Therefore, the ported
project is a lot tighter knit with MiXiM than the old model was with INET. The
description of the system migration is split into PHY, MAC and higher layers.
3.2.1
PHY Layer
The PHY layer implementation, MiximIeee802154Phy, inherits from MiXiM’s
PhyLayerBattery. PhyLayerBattery itself inherits from PhyLayer, which again
inherits from BasePhyLayer. Most of MiXiM’s physical layer functionality resides
in BasePhyLayer. For this project, BasePhyLayer’s most important functions are
getRadioState(), setRadioState() and handleAirFrame(), which replace the functions get/set radio state as well as handleLowerMsgStart/End in the original
model.
Set/getRadioState() are functions of the MacToPhyInterface, and therefore also
available to the MAC layer using a pointer to the PHY layer module. Basically,
the respective request is forwarded to the PHY layer’s radio, which is of type MiximRadio. MiximRadio simulates the radio as a state machine, offering the states
RX (RECEIVE), TX (TRANSMIT), SLEEP and SWITCHING. The main differences
to INET’s RadioState state machine is the additional state SWITCHING and the
missing state IDLE. In MiXiM, the state will be set to SWITCHING and stay in it
until the actual switching is over. This is needed to model non-zero radio switch
times, which are also observable in reality. INET did not take this into account,
and the original module only assumed a delay when switching to state RECEIVE.
Furthermore, MiximRadio informs the RadioStateAnalogueModel of the changed
state. This is necessary to compute the correct attenuation factor for incoming
airframes.
HandleAirFrame() is responsible for handling the complete airframe reception
thesis.tex
2013-05-16
21:12:09
18
process, from the first received bit until the frame can be removed from the list of
current airframes kept in ChannelInfo. Typically an airframe passes through this
function three times. At the first time the function handleAirFrameStartReceive is
called. All specified AnalogueModels are applied to the Signal object contained
in the airframe to determine the attenuation. If a Decider exists, the frame is then
handed to the function handleAirFrameReceiving, where the specified decider
processes the signal to determine whether the remaining signal is strong enough
that the airframe can be received. At last, the function handleAirFrameEndReceive
is called to signal the reception is over and to remove the frame from the list of
current airframes in ChannelInfo, as well as clean up the AnalogueModels.
BasePhyLayer’s handleUpperMessage() provides the same functionality as the
function handleUpperMsg() in the original module. First of all the current radio
state is checked. If the radio is not in state TX, an error message will be generated.
Secondly, if there is already a message being sent, again an error message will
be generated. Lastly, if everything is cleared and the message is ready to be
transmitted, a timer is set to indicate when the transmission is over and the
message is sent to the channel. Based on this, the original module’s function is
replaced by BasePhyLayer’s handleUpperMessage().
PhyLayerBattery extends setRadioState() by adding means to simulate power
consumption caused by different radio states. Different currents can be specified
for the states RX, TX, SWITCHING and SLEEP. No additional code to simulate
energy consumption needs to be added, as PhyLayerBattery takes care of that.
Furthermore, it checks the host’s state before receiving or sending messages. If
the state is not active (e.g. empty battery), the messages are dropped.
MiximIeee802154Phy makes use of the NotificationBoard module contained in
MiXiM version 2.3. A change notification is fired in initialize() as soon as radio
channel and state are set, to inform the MAC layer of the initial values.
In the following part of the chapter I will explain some implementation details.
To be able to handle non-zero radio switch times, it was necessary to modify the
primitive handler function handle_PLME_SET_TRX_STATE_request. In the original
implementation the radio state was switched instantaneously. Therefore, a
corresponding confirm primitive could be sent to the MAC layer without delay. The
only exception was when switching to state RECEIVE. There, a timer was set to fire
as soon as the switching was over, and handleSelfMsg then forwarded the primitive
to the MAC layer. In the new implementation it is possible to use zero switch times
as well as non-zero switch times. This was achieved by temporarily storing the
returned value from function setRadioState(), which is defined as the time needed
for switching the radio. If the returned value is equal zero, a confirm primitive is
sent to the MAC layer without delay. Is it non-zero, we make use of MiXiM’s own
radio switching timer, set in BasePhyLayer’s setRadioState() function. When the
thesis.tex
2013-05-16
21:12:09
19
timer is fired, it is caught in MiximIeee802154Phy’s handleSelfMsg() function
and the corresponding primitive is then returned to the MAC layer. A diagram
showing a schematic view of the function handle_PLME_SET_TRX_STATE_request
can be found in figure 3.1.
In the original project, two parameters are representing the current radio state. On
the one hand there is the actual radio state, stored in the RadioState class. On the
other hand, there is the variable phyRadioState in the physical layer. This variable
is of type PHYenum, an enumeration used to represent various more detailed states
of the radio. See table 3.2 for a list of all possible parameters and their meanings.
If the function handle_PLME_SET_TRX_STATE_request receives a request with
the PHYenum state phy_TX_ON or phy_RX_ON and all prerequisites have been
satisfied, phyRadioState will be set to match the one demanded. However, the
real radio state will not be changed just then, but when the transmission or
reception starts, independently of the handle_PLME_SET_TRX_STATE_request. In
my opinion there is no point in delaying the actual radio switch like that. It could
even lead to errors. Therefore, in the ported model all radio switches take place
inside the handle_PLME_SET_TRX_STATE_request function.
3.2.2
MAC Layer
The original MAC layer implementation, Ieee802154Mac, is vastly different from
anything MiXiM has to offer. Although MiXiM provides an IEEE 802.15.4 MAC
layer module, only the non-beacon enabled mode has been implemented. Considering that the beacon-enabled mode is a lot more complex and the used CSMA-CA
mode is different, most of the original code has simply been taken and modified
to fit the MiXiM structure.
The MAC layer implementation, MiximIeee802154Mac, inherits from MiXiM’s
CSMA802154. CSMA802154 itself inherits from csma, which again inherits from
BaseMacLayer. This is done to make use of basic MAC functionality in MiXiM
as well as of some IEEE 802.15.4 parameters available in MiXiM’s csma module
that are necessary for both, beacon-enabled and non-beacon enabled mode.
As mentioned earlier, MiXiM does not offer any queue modules or classes. However, the csma class implements a list of MAC packet pointers called macQueue
and uses it as a makeshift queue. In the original model, an interface queue
has been put between the network layer and the MAC layer, to cache packets
coming from the upper layer before the MAC layer is ready to handle them. Using
macQueue of class csma, I rebuilt the interface queue functionality as a part of
the MAC layer.
Further, MiXiM contains a simple class to normalize network layer and MAC
layer addresses: the LAddress class. A network layer address corresponds to a
thesis.tex
2013-05-16
21:12:09
20
callptophandle_PLME_SET_TRX_STATE_requestFPHYenumpsetStatek
yes
return
radiopalreadypinpthepprocesspofp
switchingptopthepdesiredpstate?
no
yes
radiopalreadypswitchingptop
anotherpstate?
stoppcurrentpswitch
no
ispradiopalreadypinpdesiredpstate?
no
yes
tmpStatep=pphyRadioState
setStatep=pphy_RX_ONporpphy_TRX_OFFp
andpappacketpispcurrentlypbeingptransmitted?
no
yes
tmpStatep=pphy_BUSY_TX
newStatep=psetState
setStatep=pphy_TX_ONporpphy_TRX_OFFp
andpappacketpispcurrentlypbeingpreceived?
no
forcepallp
receptionpandp
transmissionp
off
return
yes
setStatep=pphy_FORCE_TRX_OFF?
tmpStatep=pphy_BUSY_RX
delayp=psetRadioStateFSLEEPk
no
newStatep=psetState
ptmpStatep=pphy_SUCCESS
yes
tmpStatep=pphy_SUCCESS
setStatep=pphy_RX_ON
setStatep=pphy_TX_ON
delayp=psetRadioStateFRXk
phyRadioStatep=pphy_TRX_OFF
setStatep=pphy_TRX_OFF
delayp=psetRadioStateFTXk
yes
delayp>pB
no
phyRadioStatep=psetStatep
else
delayp=psetRadioStateFSLEEPk
newState_turnaroundp=psetState
waitpforptheptimerptopbepfiredpandp
changepradiopstatepandpphyRadioState
inphandleSelfMsgpfunction
returnpprimitivepwithpcorrespondingpstatus
returnpconfirmpprimitive
withpstatusptmpStateptopMAC
return
Figure 3.1 – This figure shows a flow chart-like scheme of the modified
function handle_PLME_SET_TRX_STATE_request available in the ported
model.
thesis.tex
2013-05-16
21:12:09
State
phy_BUSY
phy_BUSY_RX
21
Meaning
The PHY is currently busy
with some task
receiving a message
phy_BUSY_TX
transmitting a message
phy_FORCE_TRX_OFF
Force the radio to switch to
state SLEEP, regardless of
ongoing transmissions or
receptions
The PHY is currently idle
phy_IDLE
phy_INVALID_PARAMETER
phy_RX_ON
The PHY has received an
invalid parameter
The PHY shall switch to
state RECEIVE
The PHY is in state RECEIVE
phy_SUCCESS
The physical layer operation was successful
Set radio state to SLEEP
phy_TRX_OFF
phy_TX_ON
The PHY shall switch to
state TRANSMIT
The PHY is in state TRANSMIT
phy_UNSUPPORTED_ATTRIBUTE
An unsupported value has
been passed to the PHY
Usage
Not used
PHY to MAC: PLME_SET_TRX_STATE_confirm, this result is returned if the radio should switch to
TRANSMIT or SLEEP during a message reception
PHY to MAC: PLME_SET_TRX_STATE_confirm, this result is returned if the radio should switch to
RECEIVE or SLEEP during a message
transmission
MAC to PHY: PLME_SET_TRX_STATE_request, force radio off
Used in PHY to denote that no radio
switch is pending / for CCA to confirm an idle channel
PHY to MAC: PLME_SET_confirm,
new channel is an invalid parameter
MAC to PHY: PLME_SET_TRX_STATE_request, denotes that the
channel should switch to state RECEIVE
PHY to MAC: PLME_SET_TRX_STATE_confirm, switching to RECEIVE was successful
From PHY to MAC, to denote a request was successful
MAC to PHY: PLME_SET_TRX_STATE_request, switch to state
SLEEP
MAC to PHY: PLME_SET_TRX_STATE_request, denotes that the
channel should switch to state
TRANSMIT
PHY to MAC: PLME_SET_TRX_STATE_confirm,
switching
to
TRANSMIT was successful
Not used
Table 3.2 – PHYenum attributes as defined in the file Ieee802154Enum.h
in the original model. These states are used in PHY to describe the current
radio state in more detail and to return information about the radio state
to the MAC layer.
thesis.tex
2013-05-16
21:12:09
22
L3Type address and is of type long. Similarly, a MAC layer address conforms to a
L2Type address and is again of type long. For both address types, a broadcast
and a NULL address are already specified in LAddress. In the original model,
a string parameter has been used to determine a node’s address. As MiXiM’s
approach is more realistic and supported throughout the whole framework, I
converted all addresses to instances of class LAddress. A special case is the Address LAddress::L2Type(-2): it is used by the network layer to tell the MAC layer
to send a message to its PAN coordinator.
In the following part of the chapter I will explain some implementation specific
details. To be able to use CSMA-CA it is necessary to conduct a CCA to determine
whether the channel is idle or busy. In the original model a CCA was executed
as follows: switch radio state to RECEIVE, send a primitive to the physical layer
telling it to sense the channel and then return the result - either idle or busy - to
the MAC layer. However, MiXiM offers a useful function for determining the state
of the channel more easily. Using BasePhyLayer’s getChannelState() function it
is possible to get the current state of the channel compressed in a ChannelState
object. Using the isIdle() function on the ChannelState object yields a boolean
indicating whether the channel is idle or not. In my model, the radio state is still
switched to RECEIVE first of all, but instead of sending a primitive to the physical
layer MiXiM’s getChannelState().IsIdle() function is used to get the result.
The IEEE 802.15.4 standard specifies various MAC frames of a specific format.
The most important are: Beacon frame, the Data frame and the ACK frame. To
ensure compatability with all handleMessage-related MiXiM functions I changed
the message specification to inherit from MacPkt, MiXiM’s basic MAC packet.
MacPkt’s structure is simple: it offers two LAddress::L2Type attributes, one for
the destination address and one for the source address. Furthermore, an attribute
for the sequence number is included. Using this basic message facilitates the
migration from string destination addresses to MiXiM’s LAddress class addresses.
In the original model the transmission of a message can be simplified to the
following process: use PLME_SET_TRX_STATE_request to set the radio to state
RECEIVE, wait for the confirmation message and then send the packet to the
physical layer which in turn sends the message to the channel. This is true for all
frames but the Beacon frame. Contrary to all other transmissions, the process for
sending the beacon does not wait for the confirmation of the changed radio state
but is sent to the physical layer instantaneously. This works fine if the radio switch
times to TRANSMIT are zero, but fails otherwise. Since I was planning to make
it possible to use realistic radio switch times in the ported model I had to solve
this differently. For this, I introduced the MAC parameter maxRadioSwitchTime.
It is set in the initialization phase and is given a value that is slightly bigger
than the biggest declared radio switch time. For the beacon transmission, the
thesis.tex
2013-05-16
21:12:09
23
parameter is used to give the physical layer enough time to switch to TRANSMIT
by using OMNeT++’s function sendDelayed(), which sends a message to the
specified gate delayed by, in this case, maxRadioSwitchTime. Furthermore,
maxRadioSwitchTime is also used in the startBcnRxTimer() function, which
starts a timer to set the radio state to RECEIVE before the next beacon arrives. In
this function, the wait time is shortened by maxRadioSwitchTime to ensure that
the radio had enough time to switch states. Last but not least, the parameter is
also used in GTS to compute the duration of a GTS spot including possible radio
switch times.
3.2.3
Higher layers and Utility files
As application layer I chose MiXiM’s SensorApplLayer, which offers almost everything that is needed: a function for exponentially generating and sending
messages to the network layer and functionality for keeping track of useful statistics like latency times. The module MiximIeee802154StarApp inherits from it
and only changes the functionality for sending messages so that it can be chosen
whether a node generates packets or not.
The network layer, MiximIeee802154StarRouting, inherits basic functionality from
BaseNetwLayer. It overrides the functions handleUpperMsg and handleLowerMsg
to realize routing in a star network. This means that every packet has to be sent
to its coordinator first before it can be sent to its destination. Furthermore, if
the PAN coordinator receives a packet that was not addressed to it, it has to be
forwarded to its real destination.
Some files have been taken from the original model and have been barely modified
at all. These files are:
MiximIeee802154Const Defines IEEE 802.15.4 constants
MiximIeee802154Def Offers some parameter typedefs
MiximIeee802154Enum Offers all for IEEE 802.15.4 needed enumerations
MiximIeee802154Field Defines IEEE 802.15.4 message fields
MiximIeee802154MacPhyPrimitives This message file describes the structure
of a MAC to PHY primitive
MiximIeee802154Link Used to check for duplicate message receptions
thesis.tex
2013-05-16
21:12:09
Chapter 4
Analysis
In this chapter I will verify my migration to the new OMNeT++ version as well
as to MiXiM framework. All simulation setups have been taken from [4]. In this
paper, the original authors of the existing IEEE 802.15.4 model, Feng Chen and
Falko Dressler, present simulation results that have been gathered using their
IEEE 802.15.4 model. This chapter is structured as follows. In the first part I will
explain the basic simulation setup: common parameters, used measures and the
stop condition. Furthermore the simulation scenarios, a 3 node and a 21 node
scenario, will be described. The second part consists of a short explanation on
how I will verify my results followed by the actual verification.
4.1
Simulation Setup
According to [4], star topology is more robust and has better latency when
compared to mesh networks. Furthermore, because of its adjustable duty cycle,
the beacon-enabled mode is more energy efficient compared to the non-beacon
enabled mode [4]. Since these are qualities that are demanded by the industry, an
IEEE 802.15.4 star network using the beacon-enabled mode has been employed
by [4] to conduct the simulations. Commonly used parameters of the original
model and the new simulation model using MiXiM are shown in table 4.1 and
4.2.
Missing parameters correspond either to the default values as declared in the
IEEE 802.15.4 standard [9] or are dependent on the simulation scenario and will
be explained in the corresponding section.
In [4] four performance measures are specified, one energy related and three
end-to-end measures:
5
http://mixim.sourceforge.net/doc/MiXiM/doc/neddoc/index.html?p=org.mixim.modules.nic.Nic802154_TI_CC2420.html
thesis.tex
2013-05-16
24
21:12:09
4.1 Simulation Setup
25
Parameters for Battery module
Radio power in SEND
17 mA
Radio power in RECEIVE 9.6 mA
Radio power in SLEEP
0.06 mA
Radio power in IDLE
1.38 mA
Parameters for PHY module
Channel number, bitrate
11, 250 kb/s
Transmitter power
1 mW
Transmission range
172 m
Carrier sense sensitivity
-85 dBm
Parameters for MAC and IFQ module
Synchronization mode
Beacon-enabled
Topology type
Star
IFQ size (buffer)
1
Parameters for Traffic module
Traffic type
Exponential
Payload size
1 byte
Table 4.1 – Common module parameters used in original IEEE 802.15.4
simulation model. Source: [4]
Mean energy consumption per per payload byte The mean energy consumption in µAh/s. It is computed by summing up the whole network’s energy
consumption for transmitting data packets and dividing it by the number
of payload bytes received at the sink.
Mean end-to-end packet loss rate The mean packet loss rate in % of the whole
network. This is computed by taking the sum of all lost packets, either
dropped at the MAC queue due to overflow or failed packet transmissions
due to too many retries, and dividing it by all packets that have been
generated in source nodes.
Mean end-to-end delay The mean time between a packet’s generation and its
reception at the sink node. Measured in s.
Mean end-to-end goodput The ratio of payload bytes received at the sink to
the total simulation time. Measured in bytes/s.
In accordance to [4], every simulation scenario is repeated five times with different random number generator seeds to guarantee independent runs. Since the
necessary simulation time for every simulation is dependent on the parameter
combination and varies greatly, the number of data packets received at the sink
has been taken as stop condition. At least 5000 packets must have been received
at the sink to stop a run. The results plotted on the graphs correspond to the
thesis.tex
2013-05-16
21:12:09
26
Parameters for Battery module
Radio power in SEND
Radio power in RECEIVE
Radio power in SLEEP
Parameters for PHY module
Channel number, bitrate
Transmitter power
Transmission range
Carrier sense sensitivity
Time switching from radio state SLEEP to TRANSMIT
Time switching from radio state SLEEP to RECEIVE
Time switching from radio state TRANSMIT to RECEIVE
Time switching from radio state RECEIVE to TRANSMIT
Time switching from radio state TRANSMIT to SLEEP
Time switching from radio state RECEIVE to SLEEP
Parameters for MAC module
Synchronization mode
Topology type
MAC queue size
Parameters for Traffic module
Traffic type
Payload size
17 mA
9.6 mA
0.06 mA
11, 250 kb/s
1 mW
172 m
-85 dBm
0.001792 s
0.001792 s
0.000192 s
0.000192 s
0.0 s
0.0 s
Beacon-enabled
Star
1
Exponential
1 byte
Table 4.2 – Common module parameters used in the new simulation model
using MiXiM framework, based on [4]. Contrary to the original model’s
parameters, MiXiM’s radio has no radio state IDLE and therefore does not
need to define the consumed energy while being in this state. However,
since MiXiM supports the use of radio switch times, these have been declared
in the PHY module. The values have been taken from MiXiM’s Nic802154_TI_CC2420.ned. 5
mean values derived from the above mentioned runs and have been plotted
depicting the confidence interval if the results have not been constant.
4.1.1
3 Node scenario
The 3 node scenario is the first of two simulation scenarios that I will discuss. It
conforms to the one described in [4]. The network consist of three nodes arranged
in a row, the PAN coordinator between the other two nodes. Its topology is shown
in figure 4.1. The distance between the two outer nodes is chosen so that they
are outside of each others interference distance. By choosing the value of SO to
be BO-1, a constant duty cycle of 50% can be achieved.
The device on the left side, the source, possesses an exponential traffic source
that generates and sends packets in a certain interval to the device on the right
side, the sink. Four intervals have been chosen for this scenario: 0.01s, 0.1s, 1s
thesis.tex
2013-05-16
21:12:09
27
Figure 4.1 – The topology of the 3 node simulation scenario. The three
nodes are placed in a row with the PAN coordinator in the middle.
and 10s. These values correspond to the interDepartureTime parameter in the
ini-file of the original version and to the trafficParam in the ported version. For
each of these intervals, various combinations of BO and SO have been chosen.
Because the underlying network is of the star topology type, packets have to be
routed over the PAN coordinator to be able to reach their goal. As data transfer
mode the direct one with acknowledgments has been chosen.
4.1.2
21 Node scenario
The 21 node scenario, which correlates to the first 21 node scenario in [4], is
the second simulation scenario that I will discuss. The network consists of 21
nodes, arranged symmetrically around the PAN coordinator so that every node is
placed 30 meters apart from all its neighbors (diagonal neighbors not included).
The topology is shown in figure 4.2. A schematic view has been chosen rather
than the actual output of OMNeT++’s graphical simulation environment because
the node placement can be observed better this way. Since the transmission
range of every node equals 172m (see tables 4.1 and 4.2) this means that all
nodes are within each others interference distance. All nodes other than the PAN
coordinator are equipped with exponential traffic sources, transmitting packets
at various intervals to the PAN coordinator. These intervals are: 0.01s, 0.017s,
0.032s, 0.056s, 0.1s, 0.178s, 0.316s, 0.562s, 1s, 1.778s, 3.162s, 5.623s, 10s,
17.783s, 31.623s, 56.234s and 100s. As in the 3 node scenario, these values
correspond to the interDepartureTime parameter in the ini-file of the original
version and to the trafficParam in the ported version. Contrary to the 3 node
scenario however the BO and SO combinations are chosen such that SO is always
thesis.tex
2013-05-16
21:12:09
28
device
30m
30m
30m
30m PAN
Coord
playground 300x300
Figure 4.2 – A schematic view of the 21 node topology. 20 nodes are
arranged symmetrically around the PAN coordinator, each 30 meters apart
from its neighbors.
0 and BO iterates through the values 1,3,5 and 7. This leads to a constant active
time (about 0.015s) and variable inactive times. As data transfer mode the direct
one with acknowledgments has been chosen. According to [4], the 21 node
scenario models a typical situation of industrial control applications.
4.2
Verification
My first approach to verify my simulation data has been to compare them to the
results attained in [4], since the simulation setup and all scenarios have been
derived from this paper. However, during the conduction of my own simulations
and comparing the outcomes to the original results I noticed some unexplainable
differences. Furthermore, while exploring the original model available to me, I
perceived a few deviations compared with the one described in the paper. For
example, [4] declares that all data transfer modes (direct, indirect and GTS) have
been implemented, whereas in the original IEEE 802.15.4 model available to me
the indirect transfer mode has not been modeled. Taking these facts into account,
I concluded that the project I ported has not been the exact same one that has
been used to conduct the experiments described in [4]. Therefore, to attain data
to which I can compare my results to, I used the original model, programmed
in OMNeT++ version 3.x, and simulated the same scenarios as those used in
the ported model. In figure 4.3 the difference in simulation results between the
thesis.tex
2013-05-16
21:12:09
4.2 Verification
29
paper and the original version is shown based on the goodput graph. To facilitate
detecting these differences when comparing the results the axes dimensions of
every plot have been chosen to be as close to those in the paper as possible.
4.2.1
Verification of the migration to OMNeT++ 4.2.2
At first I verified the migration of the original model to OMNeT++ version 4.2.2.
The procedure of the migration is described in section 3.2. As explained in section
4.2, I will compare the new graphs with the ones I obtained by conducting the
same simulations using the original model. Only the 3 node scenario will be
considered, since it is sufficient to be able to prove that the migration was
successful. The resulting graphs and their equivalent of the original model are
shown in figures 4.4, 4.5, 4.6 and 4.7.
I will start with examining the graphs depicting the mean energy consumption (see
figure 4.4). It is easy to assert that the graphs are basically identical. The next pair
of graphs (figure 4.5) show the mean end-to-end packet loss rate in the original
model as well as in the migrated one. Again, the graphs are essentially equal. The
same behavior can be observed in the last two graph pairs, depicting the mean
end-to-end delay (figure 4.6) and the mean end-to-end goodput (figure 4.7). The
explanation is simple: when porting from OMNeT++ version 3.x to 4.2.2, the
functionality of the IEE 802.15.4 model remains unchanged since OMNeT++
only provides the basic framework. All changed framework functionality that
influences my project is restored by using the provided migration scripts.
4.2.2
Verification of the migration to MiXiM
I verified the migrated model using MiXiM framework in two steps. Firstly, I will
consider the data obtained by using the 3 node scenario described in section 4.1.1.
Secondly, a more complex scenario using 21 nodes as described in section 4.1.2
has been simulated to test the migrated implementation in a more demanding
environment. In the verification’s second step, I will use the 21 node scenario
and compare the data of the original model to that of the migrated model. The
results will be presented in this chapter.
3 Node scenario - The graphs in figures 4.8 to 4.11 compare the original model’s
3 node scenario simulation results to the ones obtained by using the ported model.
Since there are some light discrepancies, the confidence intervals of the data
have been printed also. The probability used for these intervals is 95%.
In figure 4.8 the graphs depicting the mean energy consumption per payload byte
are shown. It is easy to observe that the energy consumption in the new model
is higher than in the original one. This behavior can be explained by considering
thesis.tex
2013-05-16
21:12:09
4.2 Verification
30
(a) The mean goodput graph of the 3 node scenario, taken from the
paper. Source: [4]
10000
Mean end−to−end goodput (bytes/s)
●
1000
0.01s
0.1s
1s
10s
100
●
●
●
●
●
(3,2)
(5,4)
(7,6)
(9,8)
●
●
10
1
0.1
0.01
(1,0)
(11,10) (13,12)
Combination of BO and SO (BO,SO)
(b) The mean goodput graph plotted with the results gathered from
simulating the 3 node scenario anew using the original IEEE 802.15.4
model.
Figure 4.3 – Comparison between the simulation paper’s goodput graph
(4.3a) and the new graph created by simulating the 3 node scenario using
the original model (4.3b). The results of the simulation paper (see [4]) are
about 50 times bigger than the ones I obtained using the original model.
Therefore I conclude that the model I ported is not the same as the one
used in the paper. As a result I will verify the ported model using my own
simulations with the original model. For a general description of the 3 node
scenario and a more detailed exploration of the results see section 4.1.1.
thesis.tex
2013-05-16
21:12:09
4.2 Verification
31
100
10
1
0.1
0.01
●
●
0.001
●
●
●
●
●
●
0.01s
0.1s
1s
10s
0.0001
Mean energy consumption per byte (µAh/byte)
100
●
10
0.01s
0.1s
1s
10s
1
0.1
0.01
●
●
●
●
●
(1,0)
(3,2)
(5,4)
(7,6)
(9,8)
●
●
0.001
0.0001
(1,0)
(3,2)
(5,4)
(7,6)
(9,8)
(11,10) (13,12)
(11,10) (13,12)
(a) Mean energy consumption per payload byte in the (b) Mean energy consumption per payload byte in the
original model using OMNeT++ version 3.x.
ported model using OMNeT++ version 4.2.2.
Figure 4.4 – Comparison of the mean energy consumption graphs in both the
original model (4.4a) and the ported model using OMNeT++ version 4.2.2 (4.4b).
The graphs are identical.
1.0
1.0
Mean end−to−end packet lossrate
0.8
0.01s
0.1s
1s
10s
●
0.9
0.7
●
0.6
●
●
●
●
●
0.5
●
0.4
0.3
0.2
0.1
●
0.9
0.8
0.01s
0.1s
1s
10s
0.7
●
0.6
●
●
●
(5,4)
(7,6)
(9,8)
●
●
0.5
●
0.4
0.3
0.2
0.1
0.0
0.0
(1,0)
(3,2)
(5,4)
(7,6)
(9,8)
(11,10) (13,12)
(1,0)
(3,2)
(11,10) (13,12)
(a) Mean end-to-end packet loss rate in the original (b) Mean end-to-end packet loss rate in the ported
model using OMNeT++ version 3.x.
model using OMNeT++ version 4.2.2.
Figure 4.5 – Comparison of the mean end-to-end packet loss rate graphs in both the
It is simple to observe that the graphs are essentially equal.
thesis.tex
2013-05-16
21:12:09
4.2 Verification
32
100
100
10
0.01s
0.1s
1s
10s
●
Mean end−to−end delay (s)
●
1
0.1
10
0.01s
0.1s
1s
10s
1
0.1
●
●
●
●
●
●
●
●
●
●
●
●
●
(1,0)
(3,2)
(5,4)
(7,6)
(9,8)
●
0.01
(1,0)
(3,2)
(5,4)
(7,6)
(9,8)
0.01
(11,10) (13,12)
(11,10) (13,12)
Combinations of BO and SO (BO,SO)
(a) Mean end-to-end delay in the original model using (b) Mean end-to-end delay in the ported model using
OMNeT++ version 3.x.
OMNeT++ version 4.2.2.
Figure 4.6 – Comparison of the mean end-to-end delay graphs in both the original
model (4.6a) and the ported model using OMNeT++ version 4.2.2 (4.6b). It is
simple to observe that the graphs show basically the same results.
10000
10000
1000
0.01s
0.1s
1s
10s
●
100
●
●
●
●
●
●
●
10
1
0.1
0.01
●
1000
0.01s
0.1s
1s
10s
100
●
●
●
●
●
(3,2)
(5,4)
(7,6)
(9,8)
●
●
10
1
0.1
0.01
(1,0)
(3,2)
(5,4)
(7,6)
(9,8)
(11,10) (13,12)
(1,0)
(11,10) (13,12)
(a) Mean end-to-end goodput in the original model us- (b) Mean end-to-end goodput in the ported model using
ing OMNeT++ version 3.x.
OMNeT++ version 4.2.2.
Figure 4.7 – Comparison of the mean end-to-end goodput graphs in both the
The graphs are essentially identical.
thesis.tex
2013-05-16
21:12:09
4.2 Verification
33
that MiXiM does not implement the radio state IDLE. The functionality to model
the battery is actually quite similar in both projects (see sections 2.3 and 2.4).
Every radio state has an energy expenditure assigned to it. The overall energy
consumption is then computed by multiplying the time spent in a radio state
with its energy consumption. In the MiXiM model the radio state stays in either
TRANSMIT or RECEIVE after the actual transaction has been completed, whereas
in the original one it switches to idle. The radio state IDLE has a low energy
expenditure assigned to it (see 4.1), only 1.38 mA. The states TRANSMIT and
RECEIVE, however, are consuming more energy (see 4.2). Since the time spent
in IDLE in the original model is being spent either in TRANSMIT or RECEIVE in
the MiXiM model, the overall energy consumption is higher.
In figure 4.9 the graphs depicting the mean end-to-end packet loss rate are
shown. Packet loss occurs if upper packets are dropped by the IFQueue module (in
the original model) or the MAC queue (in the ported model) and if the maximum
number of retries is exceeded [4]. By comparing the graphs, it is possible to
determine that they are essentially equal. The explanation is simple: although
the mechanism had to be changed to accommodate the missing interface queue
module, the queueing functionality is still untouched. Further, the ported model
did not change the mechanism for dealing with lost acknowledgments and packet
retries. The packet loss related functionality is therefore essentially unchanged.
100
10
1
0.1
0.01
●
●
0.001
●
●
●
●
●
●
0.01s
0.1s
1s
10s
0.0001
100
10
1
0.1
●
●
●
●
●
(3,2)
(5,4)
(7,6)
(9,8)
●
●
0.01
●
0.001
0.01s
0.1s
1s
10s
0.0001
(1,0)
(3,2)
(5,4)
(7,6)
(9,8)
(11,10) (13,12)
(1,0)
(11,10) (13,12)
model using INET framework.
MiXiM model.
Figure 4.8 – Comparison of the mean energy consumption graphs in both the
original model (4.8a) and the ported model using MiXiM (4.8b). It is shown that the
energy consumption of the MiXiM model is higher. This is caused by spending more
time in the energy expensive states TRANSMIT and RECEIVE than the original model,
which switches to the inexpensive state IDLE after having completed a transmission
or reception.
thesis.tex
2013-05-16
21:12:09
4.2 Verification
34
1.0
1.0
0.8
0.01s
0.1s
1s
10s
●
0.9
0.7
●
0.6
●
●
●
●
●
0.5
●
0.4
0.3
0.2
0.1
●
0.9
0.8
0.01s
0.1s
1s
10s
0.7
●
0.6
0.5
●
●
●
(5,4)
(7,6)
(9,8)
●
●
●
0.4
0.3
0.2
0.1
0.0
0.0
(1,0)
(3,2)
(5,4)
(7,6)
(9,8)
(11,10) (13,12)
(1,0)
(3,2)
(11,10) (13,12)
(a) Mean end-to-end packet loss rate of the model using (b) Mean end-to-end packet loss rate of the model using
INET framework.
MiXiM framework.
Figure 4.9 – Comparison of the mean end-to-end packet loss graphs in both the
original model (4.9a) and the ported model using MiXiM (4.9b). It is trivial to
observe that the graphs are basically identical. This can be explained by comparing
the packet loss related functionality in both the original model and the ported one.
Since this functionality is essentially unchanged, it is reasonable for the packet loss
rate to be equal.
Figure 4.10 shows the graphs depicting the mean end-to-end delay. The
graphs are essentially identical. Generally, the time needed to transmit one
packet from source to sink increases because of the added non-zero radio switch
times. However, these times are quite small (see 4.2). Almost no retransmission
of data is necessary, due to absence of another node generating traffic, keeping
the number of necessary radio switches at its minimum. Therefore the additional
delay is too small to be observable in these graphs.
In figure 4.11 the graphs depicting the mean end-to-end goodput are shown.
Conforming to the verification results before, the graphs are almost identical.
As with the graphs depicting the mean end-to-end delay, the additional delay
caused by the radio switch times is unobservable.
Since the comparison of simulation data between the original model and the
ported one did not yield any significant differences, the first part of the verification
has been completed successfully.
21 Node scenario with fixed SO - The graphs in figures 4.12 to 4.15 compare
the original model’s 21 node scenario with fixed SO simulation results to the ones
obtained by using the ported model. Since there are some light discrepancies,
the confidence intervals of the data have been printed also. The probability used
for these intervals is again 95%.
The first two graphs show the mean energy consumption in both the original
(figure 4.12a) as well as the ported version (figure 4.12b). It is trivial to observe
thesis.tex
2013-05-16
21:12:09
4.2 Verification
35
100
100
10
0.01s
0.1s
1s
10s
●
●
1
0.1
10
0.01s
0.1s
1s
10s
1
0.1
●
●
●
●
●
●
(1,0)
(3,2)
(5,4)
(7,6)
(9,8)
●
0.01
●
●
●
●
●
(1,0)
(3,2)
(5,4)
(7,6)
(9,8)
●
●
0.01
(11,10) (13,12)
(11,10) (13,12)
(a) Mean end-to-end delay in the model using INET (b) Mean end-to-end delay in the model using MiXiM
framework.
framework.
Figure 4.10 – Comparison of the mean end-to-end delay graphs of both the original
model (4.10a) and the MiXiM model (4.10b). The graphs show the same results.
Although the MiXiM model has slightly bigger transmission times due to its non-zero
radio switch times, the additional delay is too small to be observable in these graphs.
10000
10000
1000
0.01s
0.1s
1s
10s
●
100
●
●
●
●
●
●
●
10
1
0.1
0.01
●
1000
0.01s
0.1s
1s
10s
100
●
●
●
●
●
●
●
10
1
0.1
0.01
(1,0)
(3,2)
(5,4)
(7,6)
(9,8)
(11,10) (13,12)
(1,0)
(3,2)
(5,4)
(7,6)
(9,8)
(11,10) (13,12)
(a) Mean end-to-end goodput in the model using INET (b) Mean end-to-end goodput in the ported model using
framework.
MiXiM framework.
Figure 4.11 – Comparison of the mean end-to-end goodput graphs of both the
original model (4.11a) and the MiXiM model (4.11b). The graphs are basically equal
due to the very small radio switch times.
thesis.tex
2013-05-16
21:12:09
4.2 Verification
36
that the MiXiM model has a higher energy consumption than the original one. As
already explained in the comparison of the simulation results gathered from the
3 node scenario, this behavior originates from the missing radio state IDLE in the
ported model. The greater drop of the curves can be attributed to unproportionally
higher energy consumption in states TRANSMIT and RECEIVE compared to state
IDLE combined with the greater number of nodes compared to the 3 node scenario.
There is one value that deviates from the norm in the curve of BO=7. This can be
attributed to the additional delay caused by non-zero radio switch times and the
long inactive period caused by BO=7, prolonging the necessary simulation time.
This effect is also visible in the goodput graph in figure 4.15b. The next pair
of graphs describe the mean end-to-end packet loss rate in the original (figure
4.13a) as well as the ported model (figure 4.13b). Comparing these two graphs,
it is simple to observe that they are essentially equal. The reason for this is the
unchanged packet loss related functionality as described in the verification of
the ported model using the 3 node scenario packet loss rate graph.
In the next two graphs the mean end-to-end delay is depicted in the original
model (figure 4.14a) as well as the ported one (figure 4.14b). The comparison
between them yields the observation that the delays in the ported model are
smaller in the beginning and their drop is less steep, but the curves end at the
same values as in the original model. This behavior is caused by the faster CCA
mechanism as described in section 3.2.2. Since it is likely to detect something
1000
10
●
●
●
1
●
●
●
●
0.01
●
●
●
●
●
●
0.1
●
100
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
0.1
●
SO=0 BO=1
SO=0 BO=3
SO=0 BO=5
SO=0 BO=7
10
●
●
●
1
SO=0 BO=1
SO=0 BO=3
SO=0 BO=5
SO=0 BO=7
100
●
0.1
1000
on the channel in a network consisting of 20 constantly transmitting nodes,
1
10
100
0.01
Mean interarrival time (s)
0.1
1
10
100
original model using INET framework.
ported model using MiXiM framework.
Figure 4.12 – Comparison of the mean energy consumption graphs of both the
original model (4.12a) and the MiXiM model (4.12b). The energy consumption of
the ported model is higher. This can be attributed to the missing radio state IDLE
and the higher energy consumption in states TRANSMIT and RECEIVE.
thesis.tex
2013-05-16
21:12:09
1
37
1
4.2 Verification
●
●
●
●
●
0.8
0.6
●
0.4
0.6
0.4
●
SO=0 BO=1
SO=0 BO=3
SO=0 BO=5
SO=0 BO=7
0.2
0.8
●
●
0.2
Mean End−to−end packets lossrate
●
SO=0 BO=1
SO=0 BO=3
SO=0 BO=5
SO=0 BO=7
Mean End−to−end packets lossrate
●
●
●
●
0.01
●
0.1
●
●
●
●
1
●
●
●
●
10
●
●
0
0
●
100
0.01
●
0.1
●
●
●
●
1
●
●
●
●
10
●
100
(a) Mean end-to-end packet loss rate in the original (b) Mean end-to-end packet loss rate in the migrated
model using INET framework.
model using MiXiM framework.
Figure 4.13 – Comparison of the mean end-to-end plr graphs of both the original
model (4.13a) and the MiXiM model (4.13b). The graphs are equal. This behavior
stems from the unchanged packet loss related functionality of the ported model.
the probability for having to perform multiple CCAs to send one packet is high.
Therefore, the delays in the model with the faster CCA mechanism decrease
significantly.
In the last pair of graphs the mean end-to-end goodput of both the ported
(figure 4.15b) as well as the original one (figure 4.15a) is shown. It is easy
100
1
●
●
●
SO=0 BO=1
SO=0 BO=3
SO=0 BO=5
SO=0 BO=7
●
●
10
●
1
●
●
0.1
SO=0 BO=1
SO=0 BO=3
SO=0 BO=5
SO=0 BO=7
10
●
0.1
100
to observe that only the values before the respective peak of each curve in the
●
●
●
●
●
●
0.01
0.1
●
●
●
●
1
●
●
10
●
●
●
0.01
0.01
●
100
●
0.01
0.1
●
●
●
●
●
1
●
●
●
10
●
●
100
(a) Mean end-to-end delay in the original model using (b) Mean end-to-end delay in the ported model using
INET framework.
MiXiM.
Figure 4.14 – Comparison of the mean end-to-end delay graphs of both the original
model (4.14a) and the MiXiM model (4.14b). The ported model displays smaller
staring delays and a less steep drop. This is caused by the faster CCA mechanism.
thesis.tex
2013-05-16
21:12:09
4.2 Verification
38
ported model differs from those in the original model. This is can be explained
with the bigger simulation time caused by the non-zero radio switch times. The
effect is only seen in the areas before the peak because of the higher number of
collisions due to heavy traffic resulting in a higher number of retransmissions [4]
prolonging the necessary simulation time. There is one value that deviates from
the norm in the curve of BO=7, as the necessary simulation time gets especially
long due to the heavy traffic load, the non-zero radio switch times and the long
inactive period. This effect can also be seen in the energy graph in figure 4.12b.
Concluding the verification, there are differences in energy consumption, endto-end delays and goodput results between the original model and the ported
one. However, these originate from MiXiM’s own functionality or the way the
migration has been done and can be explained in every case. Therefore, since no
significant abberations have been found, the model is considered to be ported
100
●
●
●
●
●
●
10
●
SO=0 BO=1
SO=0 BO=3
SO=0 BO=5
SO=0 BO=7
●
●
●
●
1
●
●
●
●
●
●
●
●
●
●
●
SO=0 BO=1
SO=0 BO=3
SO=0 BO=5
SO=0 BO=7
●
●
●
●
●
●
●
0.01
0.1
●
0.01
●
●
●
10
●
1
●
0.1
●
100
successfully.
0.01
0.1
1
10
100
0.01
0.1
1
10
100
(a) Mean end-to-end goodput in the original model us- (b) Mean end-to-end goodput in the ported model using
ing INET framework.
MiXiM framework.
Figure 4.15 – Comparison of the mean end-to-end goodput graphs of both the
original model (4.15a) and the MiXiM model (4.15b). The ported model displays
the same behavior as the original model after its peak has been reached. Before, the
starting values are smaller and the climb is steeper. This can be attributed to the
increased simulation time needed to simulate non-zero radio switch times.
thesis.tex
2013-05-16
21:12:09
Chapter 5
Conclusion
In this paper the migration of the original IEEE 802.15.4 model implemented by
Feng Chen and Falko Dressler using the OMNeT++ simulation framework and
the INET framework to a more up-to-date version of OMNeT++ and the MiXiM
framework has been described. Since the standard only defines the physical
and MAC layer it is important to model these layers are as exact as possible,
but the INET framework provides only limited support for the lower layers of
wireless protocols. Therefore the MiXiM framework has been chosen to replace
INET, since it offers more detailed models of the physical layer and channel. A
theoretical analysis of the differences between these frameworks was followed
by the actual migration, using as much from MiXiM’s functionality as sensible.
The ported model has been verified by conducting simulations, gathering the
results and plotting them in graphs. By comparing theses graphs with the results
of simulations carried out by the original model, the model has been verified.
The verification has shown that there are differences between the ported and the
original model, which stem from MiXiM’s enhanced functionality, for example
in the area of non-zero radio state switch time. The biggest difference can be
identified in the energy consumption, caused by the reduction from four radio
states to three, omitting the state IDLE.
Using the ported model, more complex simulations concentrating on the physical
and MAC layer will be conducted to further study the IEEE 802.15.4 standard.
Furthermore, as some functionality defined in the standard is not yet implemented,
the model will be extended to offer full IEEE 802.15.4 support. These two factors
will help to construct a more complete picture of the standard’s behavior and
thus make it even more attractive for industry applications.
thesis.tex
2013-05-16
39
21:12:09
List of Acronyms
WSN
Wireless Sensor Networks
NED
Network Description
LR-WPAN
Low-Rate Wireless Personal Area Networks
WLAN
Wireless Local Area Networks
POS
Personal Operating Space
FFD
Full-Function Device
RFD
Reduced-Function Device
PAN
Personal Area Network
RF
Radio Frequency
PPDU
PHY Protocol Data Units
PD-SAP
PHY data - service access point
PLME-SAP
PHY layer management entity - service access point
MPDU
MAC protocol data units
MLME-SAP
MAC sublayer management entity - service access point
MCPS-SAP
MAC common part sublayer - service access point
CAP
Contention Access Period
CFP
Contention-free Period
GTS
Guaranteed Time Slots
SO
superframe order
BO
beacon order
CCA
clear channel assessment
thesis.tex
2013-05-16
40
21:12:09
List of Figures
2.1 LR-WPAN device architecture. Adhering to the ISO-OSI model,
the device is split into layers which only communicate over well
defined interfaces. Source: [9] . . . . . . . . . . . . . . . . . . . . . .
5
2.2 Possible superframe structure. A superframe consists of an active
portion (CAP) and an optional inactive portion (CFP), bounded
by beacons. Source: [9] . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.3 A superframe with no inactive portion but 4 allocated GTS slots.
Source: [9] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.4 Service primitives. This is a very general principle; a request from
one layer to another yields an indication in the recipient, which
typically prompts a response that is sent to the origin of the request
using a confirm primitive. Source: [9] . . . . . . . . . . . . . . . . .
6
2.5 A class graph of MiXiM’s physical layer. Source: [13] . . . . . . . . 12
3.1 This figure shows a flow chart-like scheme of the modified function
handle_PLME_SET_TRX_STATE_request available in the ported
model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1 The topology of the 3 node simulation scenario. The three nodes
are placed in a row with the PAN coordinator in the middle. . . . . 27
4.2 A schematic view of the 21 node topology. 20 nodes are arranged
symmetrically around the PAN coordinator, each 30 meters apart
from its neighbors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
thesis.tex
2013-05-16
41
21:12:09
List of Figures
42
4.3 Comparison between the simulation paper’s goodput graph (4.3a)
and the new graph created by simulating the 3 node scenario
using the original model (4.3b). The results of the simulation
paper (see [4]) are about 50 times bigger than the ones I obtained
using the original model. Therefore I conclude that the model I
ported is not the same as the one used in the paper. As a result I
will verify the ported model using my own simulations with the
original model. For a general description of the 3 node scenario
and a more detailed exploration of the results see section 4.1.1. . 30
4.4 Comparison of the mean energy consumption graphs in both the original model
(4.4a) and the ported model using OMNeT++ version 4.2.2 (4.4b). The graphs
are identical. .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.5 Comparison of the mean end-to-end packet loss rate graphs in both the original
model (4.5a) and the ported model using OMNeT++ version 4.2.2 (4.5b). It is
simple to observe that the graphs are essentially equal.
. . . . . . . . . . . . . . 31
4.6 Comparison of the mean end-to-end delay graphs in both the original model (4.6a)
and the ported model using OMNeT++ version 4.2.2 (4.6b). It is simple to observe
that the graphs show basically the same results.
. . . . . . . . . . . . . . . . . 32
4.7 Comparison of the mean end-to-end goodput graphs in both the original model
(4.7a) and the ported model using OMNeT++ version 4.2.2 (4.7b). The graphs
are essentially identical.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.8 Comparison of the mean energy consumption graphs in both the original model
(4.8a) and the ported model using MiXiM (4.8b). It is shown that the energy
consumption of the MiXiM model is higher. This is caused by spending more time
in the energy expensive states TRANSMIT and RECEIVE than the original model,
which switches to the inexpensive state IDLE after having completed a transmission
or reception.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.9 Comparison of the mean end-to-end packet loss graphs in both the original model
(4.9a) and the ported model using MiXiM (4.9b). It is trivial to observe that the
graphs are basically identical. This can be explained by comparing the packet loss
related functionality in both the original model and the ported one. Since this
functionality is essentially unchanged, it is reasonable for the packet loss rate to
be equal.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.10 Comparison of the mean end-to-end delay graphs of both the original model (4.10a)
and the MiXiM model (4.10b). The graphs show the same results. Although the
MiXiM model has slightly bigger transmission times due to its non-zero radio switch
times, the additional delay is too small to be observable in these graphs.
. . . . . 35
4.11 Comparison of the mean end-to-end goodput graphs of both the original model
(4.11a) and the MiXiM model (4.11b). The graphs are basically equal due to the
very small radio switch times.
thesis.tex
. . . . . . . . . . . . . . . . . . . . . . . . . . 35
2013-05-16
21:12:09
List of Figures
43
4.12 Comparison of the mean energy consumption graphs of both the original model
(4.12a) and the MiXiM model (4.12b). The energy consumption of the ported
model is higher. This can be attributed to the missing radio state IDLE and the
higher energy consumption in states TRANSMIT and RECEIVE. .
. . . . . . . . . 36
4.13 Comparison of the mean end-to-end plr graphs of both the original model (4.13a)
and the MiXiM model (4.13b). The graphs are equal. This behavior stems from
the unchanged packet loss related functionality of the ported model.
. . . . . . . 37
4.14 Comparison of the mean end-to-end delay graphs of both the original model (4.14a)
and the MiXiM model (4.14b). The ported model displays smaller staring delays
and a less steep drop. This is caused by the faster CCA mechanism. .
. . . . . . . 37
4.15 Comparison of the mean end-to-end goodput graphs of both the original model
(4.15a) and the MiXiM model (4.15b). The ported model displays the same
behavior as the original model after its peak has been reached. Before, the starting
values are smaller and the climb is steeper. This can be attributed to the increased
simulation time needed to simulate non-zero radio switch times.
thesis.tex
2013-05-16
21:12:09
. . . . . . . . . 38
List of Tables
3.1 INET functions in the original model, their MiXiM equivalents and
their purpose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 PHYenum attributes as defined in the file Ieee802154Enum.h in
the original model. These states are used in PHY to describe the
current radio state in more detail and to return information about
the radio state to the MAC layer. . . . . . . . . . . . . . . . . . . . . . 21
4.1 Common module parameters used in original IEEE 802.15.4 simulation model. Source: [4] . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2 Common module parameters used in the new simulation model
using MiXiM framework, based on [4]. Contrary to the original
model’s parameters, MiXiM’s radio has no radio state IDLE and
therefore does not need to define the consumed energy while being
in this state. However, since MiXiM supports the use of radio switch
times, these have been declared in the PHY module. The values
have been taken from MiXiM’s Nic802154_TI_CC2420.ned. 6 . . . 26
thesis.tex
2013-05-16
44
21:12:09
Bibliography
[1] K. Shuaib, M. Boulmalf, F. Sallabi, and A. Lakas, “Co-existence of Zigbee and
WLAN, a performance study,” in Wireless Telecommunications Symposium,
2006. WTS’06.
IEEE, 2006, pp. 1–6.
[2] A. Willig, K. Matheus, and A. Wolisz, “Wireless technology in industrial
networks,” Proceedings of the IEEE, vol. 93, no. 6, pp. 1130–1151, 2005.
[3] J. T. Adams, “An introduction to IEEE STD 802.15.4,” in Aerospace Conference, 2006 IEEE.
IEEE, 2006, pp. 8–pp.
[4] F. Chen, N. Wang, R. German, and F. Dressler, “Simulation study of IEEE
802.15.4 LR-WPAN for industrial applications,” Wireless Communications
and Mobile Computing, vol. 10, pp. 609–621, May 2010 2010.
[5] P. Baronti, P. Pillai, V. W. Chook, S. Chessa, A. Gotta, and Y. F. Hu, “Wireless
sensor networks: A survey on the state of the art and the 802.15.4 and
Zigbee standards,” Computer communications, vol. 30, no. 7, pp. 1655–1695,
2007.
[6] F. Chen and F. Dressler, “A simulation model of IEEE 802.15.4 in OMNeT++,”
6. GI/ITG KuVS Fachgespräch Drahtlose Sensornetze, Poster Session, p. 35,
2007.
[7] E. Weingartner, H. Vom Lehn, and K. Wehrle, “A performance comparison
of recent network simulators,” in Communications, 2009. ICC’09. IEEE
International Conference on.
IEEE, 2009, pp. 1–5.
[8] S. Bajaj, L. Breslau, D. Estrin, K. Fall, S. Floyd, P. Haldar, M. Handley,
A. Helmy, J. Heidemann, P. Huang et al., “Improving simulation for network
research,” 1999.
[9] IEEE, IEEE Standard for Local and metropolitan area networks - Part 15.4:
Low-Rate Wireless Personal Area Networks (LR-WPANs), LAN/MAN Standards
Committee, Jun. 2011.
thesis.bbl
2013-05-16
45
21:12:09
Bibliography
46
[10] K. Wehrle, M. Güneş, and J. Gross, Modeling and Tools for Network Simulation.
Springer, 2010, ch. 3.
[11] A. Köpke, M. Swigulski, K. Wessel, D. Willkomm, P. T. Klein Haneveld, T. E. V.
Parker, O. W. Visser, H. S. Lichte, and S. Valentin, “Simulating wireless and
mobile networks in OMNeT++ the MiXiM vision,” in Proceedings of the 1st
international conference on Simulation tools and techniques for communications, networks and systems & workshop.
ICST (Institute for Computer
Sciences, Social-Informatics and Telecommunications Engineering), 2008.
[12] A. Varga and R. Hornig, “An overview of the OMNeT++ simulation environment.” in Proceedings of the 1st international conference on Simulation
tools and techniques for communications, networks and systems & workshop.
ICST (Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering), 2008.
[13] K. Wessel, M. Swigulski, A. Köpke, and D. Willkomm, “MiXiM - the Physical
Layer An Architecture Overview,” in Proceedings of the 2. International Workshop on OMNeT++.
Technische Universität Berlin, Telecommunication
Networks Group, 2009.
[14] L. M. Feeney and D. Willkomm, “Energy framework: an extensible framework for simulating battery consumption in wireless networks,” in Proceedings of the 3rd International ICST Conference on Simulation Tools and
Techniques. ICST (Institute for Computer Sciences, Social-Informatics and
Telecommunications Engineering), 2010, p. 20.
thesis.tex
2013-05-16
21:12:09

Porting IEEE 802.15.4 Model from INET framework to MiXiM

Transcription

Similar documents

MiXiM - CCS Labs

Graphical Methods for Describing Data 6` 57

OMNET++ AND MIXIM FRAMEWORK - Create-Net

iSIM iSIM

LA FAVORITA

Power devices - Crosslight Software

Get the look

SIMPro3 Backhoe Loader

VISUAL SIMULATION As viewed from Orono Fairgrounds South

When Colette Foisy-Doll arrived in Qatar last year