05.01.2013 Views

Emulation Experimentation Using the Extendable Mobile Ad-hoc ...

Emulation Experimentation Using the Extendable Mobile Ad-hoc ...

Emulation Experimentation Using the Extendable Mobile Ad-hoc ...

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

EMANE was developed using cross platform tool<br />

kits to support Linux, OS X and MS Windows experiment<br />

testbed environments 2 .<br />

The remainder of this paper is organized as follows:<br />

Section 2 describes <strong>the</strong> modular EMANE software<br />

architecture and component types. Section 3<br />

describes <strong>the</strong> rationale for realistic wireless models<br />

and identifies existing wireless models, as well<br />

as models under development within EMANE. Section<br />

4 lists some of <strong>the</strong> current programs utilizing<br />

EMANE. Section 5 provides a near term road map<br />

for EMANE and planned future work.<br />

2 Architecture<br />

EMANE implements a highly flexible modular architecture<br />

capable of accommodating a wide range<br />

of experiment testbeds. The flexibility of EMANE<br />

centers around its ability to centralize or distribute<br />

some or all of an experiment’s emulation processing<br />

across any number of testbed nodes. XML inputs<br />

to <strong>the</strong> emulator control <strong>the</strong> types of processing<br />

deployments and <strong>the</strong>ir respective locations, as<br />

well as <strong>the</strong> types of emulation modules to instantiate.<br />

The modularity of EMANE comes from a<br />

set of well defined component APIs that allow independent<br />

development of emulation module plugins,<br />

while retaining <strong>the</strong> ability to deploy and control<br />

<strong>the</strong>se components in a consistent generic manner.<br />

There are three main types of EMANE components:<br />

Network <strong>Emulation</strong> Modules, <strong>Emulation</strong><br />

Boundaries and <strong>Emulation</strong> Event Components.<br />

All EMANE components are implemented as<br />

Dynamic-Link Libraries and referred to as plugins.<br />

All plugins, regardless of type, implement a set of<br />

common interfaces to allow generic creation, configuration,<br />

and control. In addition, plugins implement<br />

a set of specialized interfaces which vary<br />

based on <strong>the</strong>ir respective type. EMANE uses a layered<br />

XML approach to instantiate any number of<br />

plugins and configure each plugin with any number<br />

of input parameters. The XML configuration<br />

is designed to minimize <strong>the</strong> amount of redundant<br />

information necessary to create an EMANE deployment.<br />

This is done by building a hierarchical series<br />

of emulation element groups. Each level in <strong>the</strong> hierarchy<br />

encapsulates <strong>the</strong> previous level(s) while still<br />

allowing tailoring of parameters from <strong>the</strong> level(s)<br />

below.<br />

2 EMANE is developed using The ADAPTIVE Communication<br />

Environment (ACE TM )[1] and The XML C parser<br />

and toolkit of Gnome (libxml2)[2].<br />

2<br />

2.1 Network <strong>Emulation</strong> Modules<br />

A Network <strong>Emulation</strong> Module (NEM) is a logical<br />

component that encapsulates all <strong>the</strong> functionality<br />

necessary to emulate a particular type of network<br />

technology. Each NEM is composed of two types<br />

of plugins: a Medium Access Control (MAC) Layer<br />

plugin and a Physical (PHY) Layer plugin. Instantiated<br />

NEM component layers are configured and<br />

<strong>the</strong>n connected to <strong>the</strong> layer immediately above and<br />

below. NEM layers communicate with each o<strong>the</strong>r<br />

using a generic message passing interface. Each<br />

layer is capable of communicating cross-layer control<br />

messages and Over-The-Air (OTA) messages<br />

with <strong>the</strong>ir neighboring layers (See Figure 1). Examples<br />

of cross-layer messages include: per packet<br />

RSSI, carrier sense, and transmission control messages.<br />

Each layer has <strong>the</strong> capability to generate<br />

OTA messages for communication with respective<br />

layer counterparts contained in different NEMs.<br />

Layers may also append and strip layer specific<br />

headers to OTA messages.<br />

Figure 1: NEM Stack with Boundary and OTA connections<br />

(Left). NEM Stack showing physical and<br />

logical communication paths (Right).<br />

NEMs are created and managed by a NEM Platform<br />

Server. NEMs managed by <strong>the</strong> same NEM<br />

Platform Server are referred to as being part of <strong>the</strong><br />

same platform (See Figure 2). The determination<br />

as to how many NEM platforms are required to support<br />

a given emulation experiment is a function of<br />

<strong>the</strong> number of NEMs, <strong>the</strong> complexity of <strong>the</strong> emulation<br />

modules, and <strong>the</strong> processing and memory<br />

resources available. Inter-NEM communication is<br />

manged by <strong>the</strong> NEM Platform Server. NEMs belonging<br />

to <strong>the</strong> same platform use in memory message<br />

passing. NEMs belonging to different platforms<br />

communicate using a multicast channel.<br />

The EMANE infrastructure delivers all OTA mes-

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!