An Interim Report on the OppWireless Project

1. An Interim Report on the OppWireless Project Dr. Jiang Li Howard University

2. 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

3. 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

4. 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.

5. 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.

6. 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

7. 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.

8. 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.

9. 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

10. Home Host (H) Pigeon (P) Foreign Host (F) Focusing on a small Pigeon Network • 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).

11. 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.

12. 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.

13. Modeling the Message Transfer in the Network Message Consumption at H Message Generation at H Message Generation Queue at H (QHg) Queue of Messages at the sink of H (QHs) Message Pickup by P Message Delivery by P Queue of Messages for H at P (QPH) Queue of Messages for F at P (QPF) Message Pickup by P Message Delivery by P Message Generation Queue at F (QFg) Queue of Messages at the sink of F (QFs) Message Consumption at F Message Generation at F

14. 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.

15. 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.

16. 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.

17. 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.

18. 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.

19. 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.

20. The Functional View of the System: Threads QNg QNs Thread 2 Host N (N= H or F) MTM CRM MCM MGM MRM Thread 4 Thread 1 Thread 3 TCP QPH QPF Pigeon (P) MPM S M C MDM Thread 4 Thread 3 Thread 2 Thread 1 Each thread realizes one or more modules. Green boxes represent the message queues.

21. Key Challenges in Thread Implementation • 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. • 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. • 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.

22. 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.

23. 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.

24. 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.

25. Emulation of Node Connectivity: Path II Pigeon P VM 1 p1 Current Location r1 Home Host H h1 r2 Foreign Host F Controller R r3 f1 Host OS VM 2 VM 4 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.

26. 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.

27. Time Line of Milestones

28. Thank You.