Opportunistic Connectivity Management Simulator
Introduction
Many researchers are trying to build communication systems and applications
to leverage the potentials of ubiquitous mobile computers and smartphones.
The best approach to achieve this goal is implementing the
intended system and evaluating it on real devices. However, it is always
helpful to evaluate algorithms and systems with simulators before
deployments, especially when implementation and deployment is as difficult
as it is on cell phones.
The Opportunistic Connectivity Management Simulator (OCMS) is an extensible
platform that I developed to simulate the behavior of a mobile device at a
system level with respect to different opportunistic connectivity
management algorithms.
The rest of this chapter is laid out as follows:
OCMS design is presented in Section 3.
Section 4 serves as a guide to using OCMS to evaluate and analyze
connectivity management algorithms.
Section 5 provides details about the implementation
of OCMS and how to extend it.
The simulator source can be downloaded from here
and the compiled JAR file can be downloaded from here.
Design Overview
OCMS is a single-thread discrete event simulator to evaluate the
performance of different interface management strategies using traces from
real-world user measurements.
A high level overview of
the architecture of OCMS is presented in Figure 1. This
section provides details of the design of each of the components in this
figure.
Figure 1:
Design of the Opportunistic Connectivity Management Simulator
|
|
The Opportunistic Connectivity Management Simulator consists of the
following components: the configuration subsystem, the event queue, network
interfaces, schedulers, and the logging subsystem. Further details about
each component follow:
An OCMS simulation starts by specifying the simulation
configuration in a text file. This file is read by a configuration object,
and its information is passed to the main simulator object and other
components of the simulator. Further details of the configuration file are
discussed in Section 4.
Event Queue
The heart of OCMS is an event queue. The components that are involved in a
simulation communicate through this queue. The event queue finds the
event with the lowest time and dispatches it to the destination. The
semantics of an event is determined by the communication protocol between
its sender and its receiver.
Network Interfaces
Figure 2:
Internal structure of a network interface in OCMS
|
|
In OCMS, a mobile device can have an arbitrary number of network interfaces (NICs).
As depicted in Figure 2 Each NIC has a Medium. A medium
is a mapping from time to connectivity opportunities that can be provided
in a file of real-world measurement traces, or generated based on a
distribution function. Each NIC also has a number of profiles that
keep track of different aspects of the NIC behavior, such as energy
consumption.
Schedulers
The intelligence of a mobile device is implemented in its scheduler (or
schedulers). An OCMS simulation can have one or more scheduler objects.
Each scheduler object interacts with one or more network interfaces through
the event queue. Upon each query, the scheduler sends a command message to
the sender of the query.
Different components of the simulation log their activities to a global
Logger, which then filters them based on the desired log level and
writes them in a log file. Each log entry has the following format:
log_level: sim_time log_source log_message
Using OCMS
This section serves as a guide to using OCMS. If the desired network
interface and scheduler are already implemented in OCMS, using them to run
a simulation is as simple as writing a configuration file, otherwise the
user can first implement the intended functionality and algorithm within the
framework of OCMS.
Simulation Configuration File
The name of the simulation configuration file is passed as the only
argument to the simulator executable. The configuration is a simple regular
language. Each line of the configuration file consists of a key =
value pair. The order of the pairs does affect the simulation, but
for better readability the file is divided into the following sections:
Figure 3:
Example of the simulation section of the OCMS configuration file
 |
This section of the configuration file contains all the general simulation
parameters. An example is provided in Figure 3.
This example specifies the start and end time of the simulation, the
desired log level and the log file to be used. The file to be used as the
source for traces and the time step of the samples. Simple filtering of
specific symbols or
based on frequency of the symbols can be specified in this section too; the
simulator can filter symbols with very low frequency (i.e. random) from the
dataset.
This section of the configuration file specifies the number of interfaces and
different parameters of each interface. Each interface in OCMS has a name
that will appear in the log messages generated by that interface, and is
used to set its parameters in the configuration file. Each interface type
has different configuration parameters, but all interface types
require a medium that should get a dataset object.
Figure 4:
Example of the interfaces section of the OCMS configuration file
 |
Figure 5:
Example of the scheduler section of the OCMS configuration file
 |
The schedulers to be used in the simulation are specified in this section
of the configuration file. Each scheduler may have specific parameters.
Figure 5 is an example of this section of the configuration
file.
OCMS Implementation
OCMS is implemented in Java, This section walks through the general
structure of the implementation. However, interested readers are encouraged
to find further implementation details in the OCMS Java API.
An event is an object of class Event, that consists of a time-stamp, a
source, a destination, type and a details array. The event queue,
the single object of the EventQueue class, keeps all the events in
a priority queue. In a tight loop it finds the next event with the lowest
time and calls the handleEvent of its destination along with a
reference to itself.
Any class that wishes to communicate through the event queue should
implement the EventConsumer interface. In its handleEvent method, it
can send replies to the sender of the event, through enqueueing a new event
(or events) in the event queue.
To keep the implementation of other components of OCMS independent of the
asynchronous communication nature of an event queue, I use wrapper classes
to enable network interfaces and schedulers to talk to the event queue.
Each network interface class implements the NIC Java interface. A network
interface, which is essentially a deterministic state machine, updates a
number of Profiles every time it transitions to a new state. The
current implementation of the WiFi network interface, for example, has
three profiles: energy profile, transmission profile, and receive profile.
Scheduler classes implement the Scheduler interface. A Scheduler
object has a `query' method, that returns a NIC command whenever it is
called. The command is one of the possible states of the network interface.
The network interface tries to transition to that state and returns the
result in the next query to the scheduler, until the end of simulation.
For example, if a network interface is in DISCONNECTED state, and the
scheduler sends a NIC.CONNECTED command to a NIC object, the interface
object tries to transition to the connected. If it succeeds, it will return
NIC.CONNECTED, otherwise returns NIC.DISCONNECTED to the scheduler.
Experiment is a general interface implemented by most components of
OCMS that manage traces, most importantly the DataSet class. A
DataSet object provides mechanisms for reading and manipulating time
stamped
samples from field experiments. A Medium object includes a DataSet object
and provides an interface for network interfaces to access the dataset.
OCMS log messages are generated by calling static methods of the
Log class. Only classes, that implement the Logger interface, can
use this logging facility. There is one static method for each log level
and one other static method for standard output, therefore no other Java
mechanism for output generation should be used.
Opportunistic Connectivity Management Simulator
This document was generated using the
LaTeX2HTML translator Version 2002-2-1 (1.71)
Copyright © 1993, 1994, 1995, 1996,
Nikos Drakos,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999,
Ross Moore,
Mathematics Department, Macquarie University, Sydney.
The command line arguments were:
latex2html -dir ./ocms -split 0 design.tex
The translation was initiated by Hossein on 2008-07-26
