Jiang Li, Ph.D. Department of Systems and Computer Science An Interim Report on the OppWireless...

Jiang Li, Ph.D.Department of Systems and Computer Science

An Interim Report on the OppWireless Project

Dr. Jiang LiHoward University


Organization of the Report• Project overview

– Pigeon Networks• Goals of the project• Building the emulation framework

– Focusing on a small network– Design of modules– Implementation of the modules – An emulation skeleton for realizing node connectivity

• Time line of Milestones: Current Status


Project Overview• To experiment with opportunistic mobile wireless

networks (O-MWNet) on ORBIT using its GENI interface– Based on our research project known as Pigeon

Networks, which is a special type of opportunistic mobile wireless networks.

– Focuses on performance evaluation (e.g. delay, throughput, and loss ratio).

– Uncover the strengths and limitations of using the GENI interface.

• Team– PI: Jiang Li– Postdoc (part-time): Sankardas Roy


Pigeon Networks• Uses special purpose vehicles called “Pigeons” to

convey messages between host nodes. • A “Pigeon” is different from a “message ferry” due to

the Pigeon’s dedication to a particular host (owner).• A “Pigeon” P only serves its owner, which is denoted as

its “Home Host” (H).• Other nodes are denoted as “Foreign Hosts” (F) of this

pigeon, P.• P can carry the messages from H to a Foreign Host, and

can also carry messages back to H.• However, a pigeon will not carry messages from one

Foreign Host to another Foreign Host.


Goals of the Project

• Goal 1: To build an emulation framework for O-MWNet experiments– Subgoal: To provide an emulation test bed to

students of computer networking courses so that they could do a realistic project within limited time.

• Goal 2: To evaluate the efficacy of the GENI interface of the ORBIT test bed.


Goal 1: An Emulation Framework

• To build an emulation framework for O-MWNet experiments– Written in C, based on Internet sockets

• Development is the same as in real networks• Easily portable to many testbeds e.g. ORBIT

– Simple• Does not rely on any other simulation/emulation

packages

– Modular design


Subgoal: An Academic Benefit• This goal is mostly achieved as a side effect of achieving

Goal 1 thanks to the design of the emulation framework being modular.

• The emulation framework should be easily deployed for students in computer networking coursers to do a realistic class project.

• This framework should allow students to plug in their own version of algorithm for one or multiple modules of their interest• This will allow them to focus on their point of interest.• As an example, students could focus on scheduling, message

queue, node discovery or mobility module. One can also plug in a new communication protocol above the transport layer.


Goal 2: The Main Goal

• To evaluate the efficacy of the GENI interface of the ORBIT test bed– Port the source code of the emulation to ORBIT.– Use the GENI interface (i.e. OMF) of ORBIT for

resource management of the experiments. – Uncover the strengths and limitations of the GENI

interface via extensive experiments.


Building the Emulation Framework

– Focusing on a small Pigeon Network (as preliminary work)

– Design of modules– Implementation of the modules– An emulation skeleton for realizing node

connectivity


Focusing on a small Pigeon Network

Home Host (H)

Foreign Host (F)

Pigeon (P)

• For the time being, we assume that the network only has one pigeon, one stationary home host and one stationary foreign host.

• Pigeon P traverses back and forth between the Home Host (H) and the Foreign Host (F).


Nodes’ Activities

• Either of H and F generates messages in course of time, whose generation time is modeled by a statistical distribution e.g. the uniform distribution or the Poisson distribution.

• Each message needs to be delivered to the other node than the node where it was generated, i.e. H’s messages need to reach F and vice versa. The pigeon node P acts as the message carrier.


Nodes’ Activities (Cont’d)• Each node possesses a wireless communication system

and can connect to another node within its communication range while we assume that all nodes’ communication radii are same, say c. However, the distance dHF between H and F is way longer than their communication range (i.e. dHF > c) and they cannot communicate directly to each other.

• After messages are generated in a node (H or F), they are stored in a queue, called the message generation queue, at the generating node before being picked up by the pigeon node. Pigeon P, being a mobile node, carries H’s messages to F, and P also carries F’s messages to H.


Modeling the Message Transfer in the Network

Message Generation Queue at H (QHg)

Queue of Messages for F at P (QPF)

Queue of Messages at the sink of H (QHs)

Queue of Messages for H at P (QPH)

Message Generation Queue at F (QFg)

Queue of Messages at the sink of F (QFs)

Message Generation at F

Message Consumption at F

Message Generation at H

Message Consumption at H

Message Pickup by P

Message Pickup by P

Message Delivery by P

Message Delivery by P


Design of Modules

• We aim to build the simulation framework as modular as possible.

• The user can replace any module later with his/her own version without worrying about tweaking other modules.

• We envision each host node N (N=H or F) or the Pigeon node P to possess several modules.


Modules in a Node

• Presence or absence of a module in a node depends on the nature of the node.

• As an example, the message generation module or the message consumption module is only present in a host node N (N=H or F) but not in the Pigeon P.

• Conversely, the mobility module is only present in P but not in N. In addition, only P has a scheduling module.

• However, each node has a module which is responsible for the message delivery and reception.


Modules of a Host Node N• Message Generation Module (MGM): It uses N’s message

generation algorithm GN to generate messages and store the generated messages in the message generation queue QNg.

• Message Transfer Module (MTM): This module in N interacts with the message pickup module (MPM) of P. After P picks up messages from QNg, MTM does the bookkeeping job for QNg.

• Message Reception Module (MRM): This module of N interacts with the message delivery module (MDM) of P. This module receives the messages delivered by the pigeon and stores them in the sink QNs.

• Message Consumption Module (MCM): We assume that MCM consumes messages stored in the sink QNs. This module is responsible to compute the protocol performance statistics such as average message delay or message loss ratio.


Modules of the Pigeon P• Scheduling Module (S): Depending on the current scenario (e.g. number

of the messages waiting at H or F), this module determines when P should make trips to other nodes.

• Node Mobility Module (M): It updates the current location of P and manages the mobility feature.

• Connectivity Module (C): This modules checks P’s current connection status with H and F.

• Message Pick-up Module (MPM): This module picks up the messages from the message generation queue of N (N = H or F) and stores them in the corresponding local queue, QPN.

• Message Delivery Module (MDM): This module delivers the messages from P’s local queue, QPN (N = H or F) to node N. We assume that P always tries to connect to node N and as soon as the connection is established the message is delivered.


Implementation Options for Nodes• We realize each node by a unique system ‘process’. We

allow these processes to communicate with each other via the socket API.

• There were two options available to us in realizing this emulation. • Option 1: to run these processes on a single computer.• Option 2: to run each process on a different machine. • In either case, the processes communicate with each other via

sockets. • We chose the 2nd option (i.e., multiple machines) because

that will allow us to easily migrate our emulation source code to ORBIT. Note that during our experiments on ORBIT, each node will be a separate physical entity.


Implementation of Modules• By definition some of the modules act concurrently, e.g. in

a host N (N= H or F), the message generation module (MGM) and the message transfer module (MTM) or the message reception module (MRM) act simultaneously.

• To manage this concurrency while ensuring the modularity in the system design, we envision each node (which is realized by one unique process) to execute multiple threads.

• There are 4 threads present in the Pigeon P or in a host N (N =H or F) . Host N has a TCP server running on one thread, while P has a TCP client running on one thread. This TCP connection is used for message transfer.


The Functional View of the System: Threads

Host N (N= H or F)

Pigeon (P)

QNg QNs

MTMMGM

MRM

MCM

QPFQPH

SM C

MPM

MDM

TCP

Thread 2 Thread 3

Thread 1

Thread 2

Thread 3

CRM

Thread 4

Thread 1 Thread 4

Each thread realizes one or more modules. Green boxes represent the message queues.


Key Challenges in Thread Implementation

1. To ensure that all en-queue and de-queue operations in each message queue of N or P are atomic. We identify the producer and the consumer thread of each queue.

2. To define the message format and to enable each node to identify the start and end of a message in the transmitted or received bit stream.

3. To implement the interaction among the scheduling module (S), mobility module (M) and the connectivity module (C) of the Pigeon. Also, to decide if we should use a push-based or pull-based interaction.


Emulation of Node Connectivity

• The Pigeon P is a mobile node while the other two host nodes H or F are static. As a result, P’s connectivity to H or F changes with time.

• The challenge is how to emulate P discovering its connectivity to H or F.

• The solution: Use an arbitrator or controller R which can enable or disable P’s connectivity to a host node. P periodically reports its current location to R so R can take the correct action.


An Emulation Skeletonfor realizing node connectivity

• We completed implementing the control node R whose job is to enable or disable pigeon P’s connectivity with host N (N=H or F).

• We realized each of these 4 nodes as a VM (Ubuntu 10.4). We used VMware Workstation 7.1 on Windows which acts as the Host OS.

• We tried two alternative paths to fulfill the aim and both of them seemed to work.


Emulation of Node Connectivity: Path I

• R, P, H, and F are 4 VMs which are on a single LAN. VMware gives us option to choose a bandwidth of this LAN.

• R has a Click module (a modular router software) which acts as a traffic forwarder between P and N (=H or F). Depending on P’s current location R disables or enables the Click module.

• The drawback of Path I is that the connectivity module of P needs to know the presence of Click. In other words, presence of the controller is not transparent to P and it can cause difficulty to migrate our code to ORBIT in future.


Controller R

Pigeon P

Home Host H

CurrentLocation

Foreign Host F

VM 1

VM 4VM 2 VM 3

VM4 (Controller R) has 3 network interfaces r1, r2 and r3. VM4 is set up as a real router. The mobility module M of P updates its current location to R and accordingly R enables or disables interfaces r2 and r3. Note that R is transparent to all other modules of P. Also, R is transparent to all modules in H or F and most modules in P.

r2

r1

r3h1 f1

p1

Host OS

Emulation of Node Connectivity: Path II


Migrating the Source to ORBIT

• We do not need the controller node R in ORBIT because Pigeon P will be able to discover a host node N by itself due to its real mobility.

• Thanks to the fact of each node in our emulation framework being a separate VM, it will be straightforward to migrate the source of P, H and F to ORBIT.

• Each thread-based architecture of the modules of P, H and F remain same.


Time Line of MilestonesMilestones Starts Ends Status

Stage 1: Build an emulationskeleton for node connectivity

June 2, 2010 July 31, 2010 Done

Stage 2: Develop an emulation framework for a Pigeon Network of 3 nodes with a simple scheduling algorithm

Aug. 1, 2010 Sep. 30, 2010 In Progress

Stage 3: Migrate the source to ORBIT and test the GENI interface

Oct. 1, 2010 Nov. 30, 2010

Stage 4: Plug in complex scheduling algorithm to the emulation framework

Dec. 1, 2010 Jan. 31, 2011

Stage 5: Improve the emulation framework for bigger networks

Feb. 1, 2011 Mar. 30, 2011

Stage 6: Migrate the improved emulation framewwork to ORBIT

Apr. 1, 2011 May 31, 2011

Stage 6: Develop demo and final report

June 1, 2011 June 30, 2011


Thank You.

Jiang Li, Ph.D. Department of Systems and Computer Science An Interim Report on the OppWireless...

Documents

Transcript of Jiang Li, Ph.D. Department of Systems and Computer Science An Interim Report on the OppWireless...