Software Demonstrations

	1. Future Combat System
	2. Routing Algorithms
		DVMRP
		CBT
	3. Task Management Project
	4. Comparison of Fair Queueing Algorithmns

Future Combat System Demo

1. Overview
The communication network in the Future Combat System has three layers:
• Ground units: including troopers and vehicles.
• UAVs.
• Satellites.
  

  

2. Implementations
1. The simulation of FCS scenario is challenging because the scenario is heterogeneous in terms of
• Physical layer characteristics.
• MAC through transport layer protocols.
• Mobility and terrain models.
• Network connectivity models.
• Real vs. virtual environments.
2. J-Sim implemented:
• Detailed implementation of most, if not all, physical, MAC, network classes for FCS simulation scenarios.
• Network emulation, i.e., transporting real-life images captured by WebCam to PDA through the JavaSim virtual network environment.
• Collaboration with SAIC on UAV placement in JavaSim.
• JavaSim 3D toolkit for displaying 3D terrain and UAV/tank/soldier movement.
3. UAV placement algorithm:
Based on tank movement and path loss information, continuously optimize altitude and flight path to maintain network connectivity and recover from disconnection in the case of network partition, in a realistic military scenario, We incorporate the UAV algorithm in J-Sim, and conduct fast-than-real-time simulation so as to provide UAV placement recommendation.
4. The J-Sim 3-D Terrain Visualizer:
• Implemented as a component in J-Sim, based on Java3D technology.
• Reads altitude data from GLOBE (the Global Land One-km Base Elevation) database by National Geophysical Data Center.
• Displays the movement of all vehicles, soldiers, UAVs, etc.
• Can zoom in/out, translate, and rotate.
• Can provide real-time node statistics (e.g., #packets received by a node) by clicking on the node.
  
3. Demo Download

Download: MPEG-4(compressed, about 4M) or AVI (Non-compressed, about 150M).
Please use Microsoft Windows Media Player to watch the demo.

Routing Algorithms

DVMRP

This is a simple demonstration on how DVMRP works on a multicast group, where the sender keeps sending data. The red lines and nodes reflect the forwarding cache content of the multicast group in each node. What you see is basically a cycle of three steps: broadcast, prune and timeout. The multicast group contains a sender at node 0 and multiple receivers at node 15, 23, 24, 25 and 26. This is a 43-second avi file (122KB).

Click here to view.

CBT

This is a simple demonstration on how CBT works on a multicast group, where members join and leave simultaneously. The red lines and nodes reflect the forwarding cache content of the multicast group in each node. The aqua lines represents forwarding of a join-request or a quit-notification. The multicast group contains node 2, 7, 10, 20, 23, 24 and the core is node 14. this is a 41-second avi file (94KB)

Click here to view.

Task Management Project Demo

In one of the DARPA/ITO funded research projects, we address the following research issues:

We have characterized load sharing with three component policies: the transfer policy, the location policy, and the information policy, and carefully tailor each policy to reduce the probabilities of (1) transferring an overflow task to an ``incapable workstation''; (2) multiple workstations sending their overflow tasks to the same workstation; (3) excessive task transfers; (4) excessive communication overheads. We have also implemented the load sharing scheme as a portable software layer in the Sun Solaris environment. To facilitate monitoring of the task management system, we have implemented a Java monitor. More details on the Java monitor can be found here.

This demo is a series of AVI movies captured directly from the display by HyperCam and consists of demos for two sets of experiments.

• In the first set of experiments, we show the capability of the software layer to redistribute the workload. Specifically, we show how each workstation distributes overflow jobs in a decentralized manner to the other workstations. Because of the priority lists used in the location policy, the overflow jobs are shown to be evenly distributed among capable workstations.
  
• In the second set of experiments, we show the capability of the software layer to support fault tolerance. Llama will submit a remote job to gorrila (which will then crash). For demonstrative purposes, the only function this job performs is to write consecutive integers to llama's screen, starting from 0. After the job is executed for some time, we manually turn off gorrila. This emulates the scenario in which gorrila crashes. The operation of writing to llama's screen stops at this point. Since all the processes running on each participating workstation are periodically checkpointed and sent back to their home workstations, the most recent checkpoint file of this job has been sent back to llama, and will be restarted on vulture, the first runnable workstation in llama's priority list.

Click here to view.

[back to top]

Comparison of Fair Queueing Algorithms

This demo compares four scheduling algorithms: VirtualClock (VC), WF2Q+ (an approximate of WF2Q), Self Clock Fair Queueing (SCFQ) and Start Time Fair Queueing (SFQ). The network topology is shown in the following graph. Four connections are set up with parameters shown in the following table. The movie shows the scheduling on link 2 at node 4, at which packets of all four connections encounter and contend for bandwidth. Performances observed are average queueing delay and average backlog. The average queueing delay is obtained by running average. When each packet is transmitted, the queueing delay it experiences is used to update the running average by the formula d = d * 0.9 + new_d * 0.1, where d is the running average and new_d is the queueing delay just obtained. The average backlog is the time average of backlog in each connection queue. This is a 42-second avi file (605KB).

Click here to view.

[back to top]

Contact Ning Li with questions or comments on this page.