Network Simulator, NS-2 Blog

Adapting BitTorrent to wireless ad hoc networks

2010-04-08T23:21:00.001+09:00

By : Mohamed Karim Sbai, Chadi Barakat, Jaeyoung Choi,

Abstract:

BitTorrent is one of the Internet's most efficient content distribution protocols. It is known to perform very well over the wired Internet where end-to-end performance is almost guaranteed. However, in wireless ad hoc networks, many constraints appear as the scarcity of resources and their shared nature, which make running BitTorrent with its default configuration not lead to best performances. To these constraints it adds the fact that peers are both routers and end-users and that TCP-performance drops seriously with the number of hops. We show in this work that the neighbor selection mechanism in BitTorrent plays an important role in determining the performance of the protocol when deployed over a wireless ad hoc network. It is no longer efficient to choose and treat with peers independently of their location. A first solution is to limit the scope of the neighborhood. In this case, TCP connections are fast but there is no more diversity of pieces in the network: pieces propagate in a unique direction from the seed to distant peers. This prohibits peers from reciprocating data and leads to low sharing ratios and suboptimal utilization of network resources. To recover from these impairments, we propose an enhancement to BitTorrent which aims to minimize the time to download the content and at the same time to enforce cooperation among peers. Our solution considers a restricted neighborhood to reduce routing overhead and to improve throughput, while establishing few connections to remote peers to improve diversity of pieces. With the help of extensive NS-2 simulations, we show that these enhancements to BitTorrent significantly improve the file completion time while fully profiting from the incentives implemented in BitTorrent to enforce fair sharing.

Paper:

Mohamed Karim Sbai, Chadi Barakat, Jaeyoung Choi, Anwar Al Hamra, Thierry Turletti, "Adapting BitTorrent to wireless ad hoc networks" to appear in proceedings of 7th International conference on ad hoc networks and wireless 2008 (AD-HOC NOW), Sophia Antipolis, France, September 2008. download

NS-2 Simulator code and scripts:

Click here to download code.

Mannasim : Wireless Sensor Networks simulation environment

2010-04-08T23:16:00.002+09:00

Mannasim is a Wireless Sensor Networks simulation environment comprised of two solutions:

the Mannasim Framework;
the Script Generator Tool.

The Mannasim Framework is a module for WSN simulation based on theNetwork Simulator (NS-2). Mannasim extends NS-2 introducing new modules for design, development and analysis of different WSN applications.

The Script Generator Tool (SGT) is a front-end for TCL simulation scripts easy creation. SGT comes blunded with Mannasim Framework and it's written in pure Java making it plataform independent.

Download and install Mannasim right now!

Mannasim Objectives

Mannasim goal is to develop a detailed simulation framework, which can accurately model different sensor nodes and applications while providing a versatile testbed for algorithms and protocols.

Numerous challenges make the study of real deployed sensor networks very difficult and financially infeasible. At the current stage of the technology, a practical way to study WSNs is through simulations that can provide a meaningful perspective of the behavior and performance of various algorithms.

How to install ns-2.34 on Ubuntu 9.10 Karmic Koala

2009-11-09T14:36:00.004+09:00

If you are planning to install the latest ns-2.34 on Ubuntu 9.10 Karmic Koala, here are some basic steps

1. Download ns-allinone-2.34.tar from here.

2. Place it in somewhere, e.g. /home/simulator, then extract it.
$ cd /home/simulator
$ tar -xvf ns-allinone-2.34.tar

3. Download & install some packages from repository
$ sudo apt-get install build-essential autoconf automake libxmu-dev

4. Install the ns2
$ cd ns-allinone-2.34
$ ./install

5. You might face problem with the installation of otcl-1.13, the problem can be due to the gcc-4.4.1 / g++-4.4.1 compilers. But please try this :

sudo apt-get install g++-4.3
CC=gcc-4.3 CXX=g++-4.3 ./install

try to edit the Makefile.in too


From :
CC=       @CC@

to :
CC=       gcc-4.3

6. Edit some paths ==a
$ gedit ~/.bashrc

Put these lines on that file. Off course, you might change /home/simulator for it depends on where you extract ns-allinone-2.34.tar.
# LD_LIBRARY_PATH
OTCL_LIB=/home/simulator/ns-allinone-2.34/otcl-1.13
NS2_LIB=/home/simulator/ns-allinone-2.34/lib
X11_LIB=/usr/X11R6/lib
USR_LOCAL_LIB=/usr/local/lib
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$OTCL_LIB:$NS2_LIB:$X11_LIB:$USR_LOCAL_LIB

# TCL_LIBRARY
TCL_LIB=/home/simulator/ns-allinone-2.34/tcl8.4.18/library
USR_LIB=/usr/lib
export TCL_LIBRARY=$TCL_LIB:$USR_LIB

# PATH
XGRAPH=/home/simulator/ns-allinone-2.34/bin:/home/simulator/ns-allinone-2.34/tcl8.4.18/unix:/home/simulator/ns-allinone-2.34/tk8.4.18/unix
NS=/home/simulator/ns-allinone-2.34/ns-2.34/
NAM=/home/simulator/ns-allinone-2.34/nam-1.13/
export PATH=$PATH:$XGRAPH:$NS:$NAM

7. Validate it
$ cd ns-2.34
$ ./validate

7. (Optionally) You can create a symlink, so that ns can be called from everywhere
$ sudo ln -s /home/simulator/ns-allinone-2.34/ns-2.34/ns /usr/bin/ns

8. Try to run it.
$ ns

[via]

Book : Introduction to Network Simulator NS2

2009-04-29T17:02:00.003+09:00

Introduction to Network Simulator NS2 is a primer providing materials for NS2 beginners, whether students, professors, or researchers for understanding the architecture of Network Simulator 2 (NS2) and for incorporating simulation modules into NS2. The authors discuss the simulation architecture and the key components of NS2 including simulation-related objects, network objects, packet-related objects, and helper objects.

The NS2 modules included within are nodes, links, SimpleLink objects, packets, agents, and applications. Further, the book covers three helper modules: timers, random number generators, and error models. Also included are chapters on summary of debugging, variable and packet tracing, result compilation, and examples for extending NS2. Two appendices provide the details of scripting language Tcl, OTcl and AWK, as well object oriented programming used extensively in NS2.

Introduction to Network Simulator NS2 can be used by researchers, professionals or graduate students studying telecommunication networks.

Written for:
Researchers in the industry working in the area of telecommunications networking, professors, and senior undergraduate and graduate students

Trace graph - Network Simulator NS-2 trace files analyser

2008-10-15T20:43:00.000+09:00

Trace graph is a free network trace files analyser developed for network simulator ns-2 trace processing. Trace graph can support any trace format if converted to its own or ns-2 trace format. Trace graph runs under Windows, Linux, UNIX and MAC OS systems. Trace converter processes traces over 80x faster and is available to buy.

Supported ns-2 trace file formats:

wired
satellite
wireless (old and new trace)
new trace
wired-wireless.

Some of the program features (version 2.05):

238 2D graphs
12 3D graphs
delays, jitter, processing times, round trip times, throughput graphs and statistics
whole network, link and node graphs and statistics
all the results can be saved to text files, graphs can also be saved as jpeg and tiff
x, y, z axes information: minimum, mean, maximum, standard deviation, median
any graph saved in text file with 2 or 3 columns can be plotted
script files processing to do the analysis automatically.

Installation

Installation instructions on Linux:
1)Download tracegraph and mglinstaller from the webpage
Check Trace graph download page: http://www.tracegraph.com/download.html
Choose Linux version and download mglinstaller.
2) tar -xvzf tracegraph202.linux.tar.gz
3) gunzip mglinstaller.gz
4) You have to uncompress the file "mglinstaller.gz" and after doing it you will get the file "mglinstaller".
Now, there's no need to use chmod to change the rights and run ./mglinstaller.(or) Just do "sh mglinstaller" and
the script will do the rest for you.
5)set the environment path variable...
setenv LD_LIBRARY_PATH /home/nmahali/trace/tracegraph202/bin/glnx86/
to check whether the variable is set properly u can just type $LD_LIBRARY_PATH Architecture
of the path variable setting:: if new variable then setenv path
if already existing then setenv {$}.

Installation instructions on Windows:
1)Download tracegraph and mglinstaller from the page make sure it is windows version http://www.tracegraph.com/download.html
2)unzip tracegraph202.zip to say, D:\
3)execute mglinstaller.exe, when it asks for directory name, enter D:\tracegraph202
4) add D:\tracegraph202\bin\win32 to your environment PATH
5)how to add to environment PATH??
right click on Mycomputer and select properties
From properties select Advanced tab
Select environment path variables
Select PATH and add your path to it
Thats it tracegraph is now ready!!
This is the procedure i followed while installing tracegraph on both windows and linux (if you dont have matlab installed on your machine.)

Download Trace graph and Trace converter.

Trace graph was presented at ISAT 2003 (Information Systems Architecture and Technology) conference. Click here to read the conference paper.

[via]

How to install Ns-2-AllinOne-2.33 on Ubuntu 8.04

2008-10-13T11:19:00.000+09:00

This is an example of the NS2-AllInOne-2.33 installation for Ubuntu 8.04.

Download the most recent Ns-2-AllinOne-2.33 from Sourceforge.

Suppose that there is "ns-allinone-2.33.tar.gz" in current directory (e.g. "~/" for me is "/home/mm").
All steps are done in Terminal, so open a terminal in Accessories/Terminal.

To extract the file:
tar xvfz ./ns-allinone-2.33.tar.gz

Go into extracted directory:
cd ns-allinone-2.33

Download required packages:
sudo apt-get install build-essential autoconf automake libxmu-dev

Start installation:
./install

Set environment parameter:
gedit ~/.bashrc
Then at the last line, append the following text with changing "/your/path" to the directory that contains "ns-allinone-2.33". (e.g. "/home/mm/" )

# LD_LIBRARY_PATH
OTCL_LIB=/home/mm/ns-allinone-2.33/otcl-1.13
NS2_LIB=/home/mm/ns-allinone-2.33/lib
X11_LIB=/usr/X11R6/lib
USR_LOCAL_LIB=/usr/local/lib
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$OTCL_LIB:$NS2_LIB:$X11_LIB:$USR_LOCAL_LIB

# TCL_LIBRARY
TCL_LIB=/home/mm/ns-allinone-2.33/tcl8.4.18/library
USR_LIB=/usr/lib
export TCL_LIBRARY=$TCL_LIB:$USR_LIB

# PATH
XGRAPH=/home/mm/ns-allinone-2.33/bin:/home/mm/ns-allinone-2.33/tcl8.4.18/unix:/home/mm/ns-allinone-2.33/tk8.4.18/unix
NS=/home/mm/ns-allinone-2.33/ns-2.33/
NAM=/home/mm/ns-allinone-2.33/nam-1.13/
PATH=$PATH:$XGRAPH:$NS:$NAM

[via]

Wireless LAN Power Management Extension for ns-2

2008-09-10T11:10:00.000+09:00

Wireless LAN (IEEE 802.11) power management extension. (Website)
This supports legacy power save functions defined with IEEE 802.11.

Features

Supports legacy power management functions defined with IEEE 802.11.

Supports PS-Mode AP and STA in infrastructure mode.

Supports calculation of power consumption of each nodes.

Based on ns-2.33.

How to use
See sample script at: tcl/ex/powersave.tcl

Access point node can be configured with DTIM period by the following command.

$mac_(ap_node) set DTIMPeriod_ 1
STA node can be configured as PS-Mode by the following command.

$mac_(sta_node) set isPowerSave_ true
To setup the power configuration, use $ns node-config parameters like as:

$ns_ node-config .... \
-txPower 0.660 \
-rxPower 0.395 \
-idlePower 0.035 \
-sleepPower 0.001 \
-initialEnergy 1000
After simulation, you can show the remaining node energy by the following command:

puts [$node_(sta_node) energy]
You can check node behaviors with nam tool.

Authors:

System Platforms Research Laboratories, NEC Corporation.
Makoto Fujinami
Yoshinori Miyamoto
Takuya Murakami

Download files from Project Website.

ns-3.1 Stable Release

2008-07-01T14:34:00.000+09:00

The first ns-3 stable release

This release is immediately available from:
http://www.nsnam.org/releases/ns-3.1.tar.bz2

What is ns-3 ?

ns-3 is a new discrete-event network simulator designed for supporting
network research and education. ns-3 features a solid, well documented
C++ core and models for TCP/IP (IPv4), several link types including
WiFi, and mobility models.

ns-3 is an open source project released under the GNU GPLv2 license
which allows anyone to use ns-3 without having to pay any license fee or
royalties. ns-3 is actively seeking new contributors to extend the range
of supported models and/or to maintain existing models.

Where to get more information about ns-3

All the ns-3 documentation, is accessible from the ns-3 website:
http://www.nsnam.org

Including, tutorials:
http://www.nsnam.org/tutorials.html

Supported platforms

ns-3 is regularly tested on the following platforms:
- linux x86 gcc 4.2, 4.1, and, 3.4.6.
- linux x86_64 gcc 4.1.3, 4.2.1, 3.4.6
- MacOS X ppc and x86
- cygwin gcc 3.4.4 (debug only)

Known issues

ns-3 is known to fail on the following platforms:
- gcc 3.3 and earlier
- optimized builds on gcc 3.4.4 and 3.4.5
- optimized builds on linux x86 gcc 4.0.x

The IPv4 API defined in src/node/ipv4.h is expected to undergo major
changes in preparation of the merge of the IPv6 API and implementation.

Future releases

Our next release, which is expected to happen in 2 to 4 months from now,
will feature the merging of some of our projects currently in
development: python scripting, IPv6, emulation, a statistics framework
and synchronous posix sockets.

An NS2 TCP Evaluation Tool: Installation Guide and Tutorial

2008-01-11T15:50:00.000+09:00

A TCP performance evaluation tool for the network simulator NS2 has been developed. This document describes how to install and use this tool.

Researchers frequently use the network simulator NS2 to evaluate the performance of their protocols in the early stage of design. One particular area of recent intest is the congestion control protocols (a.k.a., TCP alternatives) for high-speed, long-delay networks. There is significant overlap among (but lack of a community-agreed set of) the topologies, traffic, and metrics used by many researchers in the evaluation of TCP alternatives: effort could be saved by starting research from an existing framework. As such, we developed a TCP performance evaluation tool. This tool includes several typical topologies and traffic models; it measures some of the most important metrics commonly used in TCP evaluation; and it can automatically generate simulation statistics and graphs ready for inclusion in latex and html documents. The tool is very easy to use and contains an extendable open-source framework.

This tool can be used not only for high-speed TCP protocols, but for other proposed changes to congestion control mechanisms as well, such as ECN added to SYN/ACK packets, changes to make small transfers more robust, changes in RTO estimation, and proposals to distinguish between loss due to congestion or corruption, etc.

tags : tcp evaluation tool ns2 network simulator

IEEE 802.16 Wireless Mesh Networks in ns-2

2007-11-02T12:12:00.000+09:00

This is a patch to the Network Simulator 2 (ns-2) that allows IEEE 802.16d Wireless Mesh Networks to be simulated. No support to the Point-to-Multipoint mode is included in this patch. Only the Mesh mode.

This is the first public release of the this software. Therefore, it is expected that some problems that have not surfaced while we were using the simulator will happen to you.

The functions for enabling data transmission at the MAC layer are fully implemented. Access to the data sub-frame is negotiated by means of the three-way handshake specified by the standard, while scheduling is implemented according to the Fair End-to-end Bandwidth Access (FEBA) algorithm described in a technical paper presented at IEEE INFOCOM 2006. Access to the control sub-frame is implemented according to the standard distributed election procedure described in a tutorial manner in this paper.

Installation

To install the patch, follow the instructions below:

1. download the ns-allinone-2.31 package from SourceForge
2. unpack the file that you just downloaded in your preferred location (let us assume the location is /usr/local). This will create a directory named /usr/local/ns-allinone-2.31
3. download the latest ns2mesh80216 patch (let us assume that you downloaded the file in /tmp)
4. apply the patch, by executing the following command:
'cd /usr/local/ns-allinone-2.31/ns-2.31 ; \
gzip -dc /tmp/ns2mesh80216-2.31-071030.patch.gz | patch -Np1'
5. compile the all-in-one patched ns-2.31, by executing the following command:
'/usr/local/ns-allinone-2.31/install'

You are now ready to run the Tcl scenario example wimax/tcl/mesh.tcl. You will find many useful pointers on what-to-do-next in the same directory.

The ns2mesh80216 patch includes the following modules:

* ns2measure (more information available here)
* ns2voip (more information available here)

tags : wireless mesh ns-2 network simulator IEEE 802.16

NS-MIRACLE: Multi-InteRfAce Cross-Layer Extension library for the Network Simulator

2007-07-04T17:02:00.000+09:00

Overview

NS-MIRACLE is a set of libraries designed to enhance the functionalities provided by the Network Simulator ns2. It provides an efficient and embedded engine for handling cross-layer messages and, at the same time, enables the co-existance of multiple modules within each layer of the protocol stack. For instance, multiple IP, link layers, MACs or physical layers can be specified and used within the same node. The NS-MIRACLE framework facilitates the implementation and the simulation of modern communication systems in ns2; moreover, due to its modularity, the code will be portable, re-usable and extensible. (Download)

Installation

For step-by-step installation instructions, you can refer to the nsmiracle-dei80211mr tutorial.

Documentation

A detailed documentation of ns-miracle is available. Please note that this documentation was written for a preliminary release of ns-miracle, and is therefore somehow outdated.

You can find the documentation here.

In this release, in addition to MIRACLE library, it is included a set of libraries to simulate wireless system networks, in detail:

Traffic generators
TCP Agents
IP modules
IEEE802.11 (both the one from standard ns distribution and Multirate [2])
MPhy, a general physical layer module in which interference of
in-flight packets is evaluated using a Gaussian Model, and an enhanced
propagation model is provided (fading with Jakes Simulator, shadowing
with Gudmonson model and path loss with Hata model)
UMTS:

Link layer is derived from eurane extension [3]
Physical layer is develpoed exteding Mphy
Link and Wireless Channel
physical mobility models (standard and Gauss Markov mobility model)

tags : network simulator ns2 library ns-miracle physical layer

Greedy Perimeter Stateless Routing (GPSR)

2007-07-03T22:06:00.000+09:00

GPSR: Greedy Perimeter Stateless Routing code for version 2.26 or later (till 2.29 now). Download my implementation tarball
You can obtain its original implementation through GPSR official link which is just for old version of ns2.

Since this implementation is original based on ns2 version 2.26, you need to be careful to deal with it when you use a later vesion. Especially the ns-packet.tcl file, you need to do the change by yourself. The one in my tarball may not be suitable for you to use.
This implementation consists of 2 parts exactly the same as proposed by the original GPSR paper, and is a little bit different from the orginial ns2 implementation (see through the link above).
This implementation is a pure Stateless implementation, where the routing decision of each packet on any node is made purely only on the local information (one-hop neighborhood)
Both GG and RNG planarization methods are provided by this implementation.

In wireless networks comprised of numerous mobile stations, the routing problem of finding paths from a traffic source to a traffic destination through a series of intermediate forwarding nodes is particularly challenging. When nodes move, the topology of the network can change rapidly. Such networks require a responsive routing algorithm that finds valid routes quickly as the topology changes and old routes break. Yet the limited capacity of the network channel demands efficient routing algorithms and protocols, that do not drive the network into a congested state as they learn new routes. The tension between these two goals, responsiveness and bandwidth efficiency, is the essence of the mobile routing problem.

Greedy Perimeter Stateless Routing, GPSR, is a responsive and efficient routing protocol for mobile, wireless networks. Unlike established routing algorithms before it, which use graph-theoretic notions of shortest paths and transitive reachability to find routes, GPSR exploits the correspondence between geographic position and connectivity in a wireless network, by using the positions of nodes to make packet forwarding decisions. GPSR uses greedy forwarding to forward packets to nodes that are always progressively closer to the destination. In regions of the network where such a greedy path does not exist (i.e., the only path requires that one move temporarily farther away from the destination), GPSR recovers by forwarding in perimeter mode, in which a packet traverses successively closer faces of a planar subgraph of the full radio network connectivity graph, until reaching a node closer to the destination, where greedy forwarding resumes.

GPSR will allow the building of networks that cannot scale using prior routing algorithms for wired and wireless networks. Such classes of networks include:

Sensor networks: potentially mobile, potentially great density, vast numbers of nodes, impoverished per-node resources

Rooftop networks: fixed, dense deployment of vast numbers of nodes

Vehicular networks: mobile, non-power-constrained, widely varying density

Ad-hoc networks: mobile, varying density, no fixed infrastructure

tags : GPSR Greedy Perimeter Stateless Routing code ns2 network simulator

How to interprete the NS2 tracefile for wireless simulation

2007-06-03T21:29:00.000+09:00

To find the interpretation of all possible trace format when you do the wireless simulation, you'd better read the code of ns2 in file ns2home/trace/cmu-trace{.h, .cc} Mostly, the format would be as

ACTION: [s|r|D]: s -- sent, r -- received, D -- dropped
WHEN: the time when the action happened
WHERE: the node where the action happened
LAYER: AGT -- application, 
 RTR -- routing, 
 LL  -- link layer (ARP is done here)
 IFQ -- outgoing packet queue (between link and mac layer)
 MAC -- mac, 
 PHY -- physical
flags:
SEQNO: the sequence number of the packet
TYPE: the packet type
  cbr -- CBR data stream packet
  DSR -- DSR routing packet (control packet generated by routing)
  RTS -- RTS packet generated by MAC 802.11
  ARP -- link layer ARP packet
SIZE: the size of packet at current layer, when packet goes down, size increases, goes up size decreases
[a b c d]: a -- the packet duration in mac layer header
  b -- the mac address of destination
  c -- the mac address of source
  d -- the mac type of the packet body
flags:
[......]: [
  source node ip : port_number
  destination node ip (-1 means broadcast) : port_number
  ip header ttl 
  ip of next hop (0 means node 0 or broadcast)
  ]

So we can interpret the below trace

s 76.000000000 _98_ AGT  --- 1812 cbr 32 [0 0 0 0] ------- [98:0 0:0 32 0]

as Application 0 (port number) on node 98 sent a CBR packet whose ID is 1812 and size is 32 bytes, at time 76.0 second, to application 0 on node 0 with TTL is 32 hops. The next hop is not decided yet.

And we can also interpret the below trace

r 0.010176954 _9_ RTR  --- 1 gpsr 29 [0 ffffffff 8 800] ------- [8:255 -1:255 32 0]

in the same way, as The routing agent on node 9 received a GPSR broadcast (mac address 0xff, and ip address is -1, either of them means broadcast) routing packet whose ID is 1 and size is 19 bytes, at time 0.010176954 second, from node 8 (both mac and ip addresses are 8), port 255 (routing agent).

Video Traces for Network Performance Evaluation

2007-05-24T01:47:00.000+09:00

To obtain video trace for network performance evaluation, you can download them at Arizone State University (ASU) website. The traces have been generated from encodings of several videos of typically 60 minutes length each. ASU provide traces for videos encoded with MPEG-4 Part 2, H.261, H.263 and H.264/AVC. For MPEG-4 Part 2 traces for single layer encoded video, temporal scalable, spatial scalable (two-layer) encoded video, as well as fine grain scalable video. For H.264/AVC ASU provide traces for up to high definition resolution video.

Site Link

tags : video trace arizona state university network simulator performance evaluation ns2

Web Traffic Generation in NS-2 with PackMime-HTTP

2007-05-10T02:29:00.000+09:00

Implementation

The ns network simulator has objects called "Applications" that control data transfer in a simulation. These Applications communicate via "Agents" which represent the transport layer of the network. PackMimeHTTP is the ns object that drives the generation of HTTP traffic. Each PackMimeHTTP object controls the operation of two types of Applications, a PackMimeHTTP server Application and a PackMimeHTTP client Application. Each of these Applications is conncted to a TCP Agent (Full-TCP).

Each web server or web client cloud is represented by a single ns node that can produce and consume multiple HTTP connections at a time (Figure 1). For each HTTP connection, PackMimeHTTP creates (or allocates from the inactive pool, as described below) server and client Applications and their associated TCP Agents. After setting up and starting each connection, PackMimeHTTP sets a timer to expire when the next new connection should begin. The time between new connections is governed by the connection rate parameter supplied by the user. New connections are started according to the connection arrival times without regard to the completion of previous requests, but a new request between the same client and server pair (as with HTTP 1.1) begins only after the previous request-response pair has been completed.

PackMimeHTTP handles the re-use of Applications and Agents that have completed their data transfer. There are 5 pools used to maintain Applications and Agents -- one pool for inactive TCP Agents and one pool each for active and inactive client and server Applications. The pools for active Applications ensure that all active Applications are destroyed when the simulation is finished. Active TCP Agents do not need to be placed in a pool beacuse each active Application contains a pointer to its associated TCP Agent. New objects are only created when there are no Agents or Applications available in the inactive pools.

PackMimeHTTP Client Application
Each PackMimeHTTP client controls the HTTP request sizes that are transferred. The client is started when a new TCP connection is started. Each PackMimeHTTP client takes the following steps:

sample the number of requests for this connection from the number-of-requests distribution (if the number of requests is 1, this is an HTTP 1.0 connection)
sample the inter-request times from the inter-request-time distribution, if there will be more than 1 request
sample the HTTP request sizes from the request-size distribution
send the first HTTP request to the server
listen for the HTTP response
when the entire HTTP response has been received, the client sets a timer to expire when the next request should be made
when the timer expires, the next HTTP request is sent, and the above process is repeated until all requests have been completed

PackMimeHTTP Server Application
Each web server controls the response sizes that are transferred. The server is started by when a new TCP connection is started. Each PackMimeHTTP client takes the following steps:

listen for an HTTP request from the associated client
when the entire request arrives, the server samples the server delay time from the server delay distribution
set a timer to expire when the server delay has passed
when the timer expires, the server samples the HTTP response sizes from the HTTP response size distribution
this process is repeated until the requests are exhausted -- the server is told how many requests will be sent in the connection
send a FIN to close the connection

PackMimeHTTP Random Variables
This implementation of PackMimeHTTP provides several ns RandomVariable objects for specifying distributions of PackMimeHTTP connection variables. The implementations were taked from source code provided by Bell Labs and modified to fit into the ns RandomVariable framework. This allows PackMimeHTTP connection variables to be specified by any type of ns RandomVariable, which now include PackMimeHTTP-specific random variables. The PackMimeHTTP-specific random variable syntax for TCL scripts is as follows:

RandomVariable/PackMimeHTTPFlowArrive rate, where rate is the specified PackMimeHTTP connection rate
RandomVariable/PackMimeHTTPFileSize rate type, where type is 0 for HTTP requests and 1 for HTTP responses
RandomVariable/PackMimeHTTPXmit rate type, where type is 0 for client-side transmission delays and 1 for server-side transmission delays

For installation, more info here

tags : Web Traffic Generation network simulator ns2 PackMime-HTTP

Streaming Media System for NS-2

2007-05-06T01:52:00.000+09:00

Goddard Streaming Media System is streaming system (client and server) that be used in the NS simulator. Goddard (named after Robert Goddard, the "Father of Modern Rocketry") is designed based on the behaviors of Real Networks streaming media and Windows Stream media, as observed in measurements studies from work at the Video Tracer project page.

README
INSTALL
source (15 KB tgz, source code and README + INSTALL)

Reference :
Jae Chung, Mark Claypool, and Robert Kinicki. MTP: A Streaming-Friendly Transport Protocol, Technical Report WPI-CS-TR-05-10, Computer Science Department, Worcester Polytechnic Institute, May 2005.
Online at: ftp://ftp.cs.wpi.edu/pub/techreports/pdf/05-10.pdf

tags : real streaming media system network simulator ns2 multimedia video

Hacks : Adding Forward Error Correction (FEC) into NS-2 Sender & Receiver Agents

2007-05-03T16:07:00.000+09:00

This is a hack for NS FEC sender and receiver agents. The sender agent waits for a request from the receiver and then sends the file. Below is a description on integration of these agents into NS. (For more information, please refer to the ping tutorial)

Forward error correction (FEC) is a system of error control for data transmission, whereby the sender adds redundant data to its messages, which allows the receiver to detect and correct errors (within some bound) without the need to ask the sender for additional data. The advantage of forward error correction is that retransmission of data can often be avoided, at the cost of higher bandwidth requirements on average, and is therefore applied in situations where retransmissions are relatively costly or impossible.

Steps :

Get the following files to put in your NS Agent C++ directory:

FEC Agent fec.h fec.cc
FEC Sender Agent fec_snd.h fec_snd.cc
FEC Receiver Agent fec_rcv.h fec_rcv.cc

2. Add fec.o, fec_snd.o, and fec_rcv.o to NS Makefile
In packet.h, add "PT_FEC," to the "enum packet_t" list and add "name_[PT_FEC]= "fec";" to the class p_info p_info() function.
Perform a "make depend". Ignore any warnings.
Add the following to the end of tcl/lib/ns-default.tcl:

Agent/FEC/Snd set packetSize_ 64
Agent/FEC/Snd set rate_ 100Kbps
Agent/FEC/Snd set extraPkts_ 0
Agent/FEC/Snd set debug_ false
Agent/FEC/Rcv set debug_ false

Add the following to the "foreach pair" list in tcl/lib/ns-packet.tcl:

{ FEC off_fec_ }

Run "make"
Try ns on the example TCL script, fec.tcl
You can also try this TCL multicast script, mfec.tcl

Download the source files, here

tags : network simulator ns2 forward error correction fec receiver sender agent hack

The Design and Implementation of WiMAX Module for ns-2 Simulator

2007-05-02T13:24:00.000+09:00

The Network Simulator 2 (ns-2) is a popular and powerful simulation tool for the simulation of packet-switched networks, which provides substantial support for simulation of TCP, routing, and MAC protocols over wired and wireless networks, such as wireless LANs, mobile ad hoc networks (MANETs), and satellite communications, etc, and is widely used in both academia and industry. Although many protocol modules have been implemented in the ns-2, the IEEE 802.16 broadband wireless access networks (BWANs) or WiMAX module has not been contributed yet. Thus, in this paper, we present our detailed design and implementation of the WiMAX module based on the IEEE 802.16 standard with the point-to-multipoint (PMP) mode for the ns-2. The implemented module comprises fundamental functions of the service-specific convergence sublayer (CS), the MAC common part sublayer (CPS), and the PHY layer. A simple call admission control (CAC) mechanism and the scheduler are also included in this module.

Installation

To install the patch, follow the instructions below:

Download the software cygwin and ns-allinone-2.29.3 package.(refer to this website on how to setup cygwin + ns-2)
Download the latest ns-2 WiMAX module source code.
Decompress the ns-2 WiMAX module source code file which including three files : 802_16、common and queue.
Put the 802_16 into c:\cigwin\home\"your_account"\ns-allinone-2.28\ns-2.28\mac.
Move data for common and queue to c:\cigwin\home\"your_account"\ns-allinone-2.28\ns-2.28\common and queue respectively.
Renew your Makefile .
To compile your files by execute "make".

More info

tags : network simulator ns2 wimax 802.11 tcp mac protocol mobile adhoc

NS-2 Emulation Extensions

2007-05-01T09:41:00.000+09:00

The network simulator ns-2 is a widely accepted discrete event network simulator, actively used for wired and wireless network simulations. It has a highy detailed model of the lower layers (Physical and MAC) of wireless IEEE 802.11 networks.

Ns-2 has also an emulation feature, i.e. the ability to introduce the simulator into a live network and to simulate a desired network between real applications in real-time.

Within the scope of this project we developed some methods and extensions to the ns-2 to combine wireless network simulation and network emulation. Now ns-2 can emulate an arbitrary IEEE 802.11 network between real applications. Furthermore, our extensions are generic, i.e. can be applied to any network supported in the ns-2.

NS-2 emulation extensions use two methods for network emulation: Single Host and Distributed Clients. In the first method the simulator and all the applications run on one computer. We use User-Mode-Linux virtual machines and emulate a ns-2 netwok among them. The applications run inside the virtual machines and do not notice that they communicate through a simulated network.

In the Distributed Clients method we run the applications and the simulator on separated machines for better scalability. Here we use TUN/TAP virtual network interfaces and map them to nodes in the ns-2 simulator. The network among these TUN/TAP interfaces is again simulated. The applications interact with it in the same way they would interact with a real network.

More Info.

tags : network simulator ns2 emulation extension physical layer MAC wireless

Extended Network Simulator NS-2 Nam Editor

2007-04-30T01:19:00.000+09:00

The Extended Nam Editor is an editor that allows the graphical creation of ns2 scripts. It extends the basic Nam Editor with the following features:

Integration with existing topology generators
Localization and visualization of set of nodes on large network topologies according to different selection criteria;
Instantiation of agents of any types on all the nodes of a given node set;
Definition of new node types;
Support for simulations of web cache systems.

Topology Generator Interface
The manual generation of complex Network Topology is a tedious and error prone activity.

In order to simulate networks with realistic topologies, it is a common practice to use ad-hoc topology generators, whose output is usually not compatible with the ns2 syntax. Hence, several tools have been developed to translate topology descriptions generated by topology generators in ns-scripts that can be used in the definition of a simulation scenario.

Unfortunately, scripts produced in this way are not compatible with the Nam Editor, hence networks created by common topology generators cannot be modified interactively. Such a limitation is sometimes annoying, in particular when the automatically generated topology needs to be further adapted, e.g. by instantiating agents on particular network nodes.

Nam-Editor provides a graphical interface to:

GT-ITM topology generator;
INET topology generator;

It is now possible to create, visualize and modify topologies created according to the following topology models:

flat-itm;
hierarchical-itm;
transit-stub-itm;
INET;

More info here

tags : network simulator ns2 topology generator gt-itm inet nam editor

ns2measure : An Integrated Framework for Enabling Effective Data Collection and Statistical Analysis with ns2

2007-04-28T01:12:00.000+09:00

The Network Simulator 2 (ns2) is an open source tool for network simulation. When planning for large-scale simulation experiments, an efficient and flexible data collection and a statistically sound output data analysis are important aspects to keep in mind. Unfortunately, ns2 offers little support for data collection, and statistical analysis of the simulation results is most often performed offline, using either home made code or available packages, which are not integrated with ns2.

In this site, you will find two complementary contributions:

the first one consists of a set of C++ modules, that allow a flexible and efficient data collection;
the second one is a software framework, which is fully integrated with ns2, which performs all the operations required to carry out simulation experiments in a statistically sound way.

To learn more about ns2measure, link

Reference :
An Integrated Framework for Enabling Effective Data Collection and Statistical Analysis with ns2
Claudio Cicconetti, Enzo Mingozzi, Giovanni Stea,
Workshop on ns-2: the IP network simulator (WNS2)
Pisa, Italy, October 10, 2006.

tags : ns2measure ns2 network simulator data collection statistical analysis

Peer-to-Peer (P2P) Simplified protocol

2007-04-27T12:35:00.000+09:00

P2PS (Peer-to-Peer Simplified) is a lightweight infrastructure for peer-to-peer service discovery and pipe-based communication. As its names suggests, P2PS aims to provide a simple platform on which to develop peer-to-peer style applications, hiding the complexity of other similar architectures such as JXTA.

The P2PS protocols allow ad-hoc peer networks to be created containing everything from super-computer peers to PDAs. P2PS peers can create and advertise services within the network and discover the services offered by other peers. Services usually have at least one pipe associated, an abstract communication channel used to contact the service. Pipes are only bound to specific transport protocols (e.g. TCP/IP) at connection time and allow peers to communicate over multiple protocols.

The current P2PS reference implementation is written using Java, however as P2PS is based on XML protocols interoperability should exist with other implementations. The Java implementation provides a straightforward API for creating and advertising a peer within a network and for discovering the capabilities of other peers. Pluggable endpoint resolvers allow additional transport protocols to be inserted transparently to the application.

P2PS is an open-source project.

The source code is available from the download section of this website.

tags: network, simulator, ns2, peer, simplified, protocol, p2p, jxta, xml, java

Simulation of BitTorrent Peer-to-Peer (P2P) Networks in ns-2

Simulation of BitTorrent Peer-to-Peer (P2P) Networks in ns-2

2007-04-24T23:41:00.000+09:00

Overview:
Peer-to-peer (P2P) networks can reduce the distribution cost of large media files for the original provider of the data significantly. Thereby, the BitTorrent protocol is widely used in the Internet today. Most research work studies the protocol analytically, by simulations at the flow-level or real world experiments. Thereby, for flow-level simulations the influence of neglecting packet-level characteristics is not yet quantified.

Therefore, we implemented a BitTorrent-like protocol for the network simulator ns-2. We denote it as BitTorrent-like, because we do not intend to implement a specific version of BitTorrent, but aim at assessing the differences between a full simulation of all network layers and simplified simulations on the application-layer. Thus, some functionalities were simplified and others were omitted. In detail, in our simulator no torrent file is used and the downloaded data is not checked for data integrity by hash values. The HTTP tracker protocol is not implemented. That is, all tracker traffic is directly given to the peers rather than being transmitted over the network. We use this simplification because we are predominantly interested in the efficiency of the data transfers between the peers. Each peer runs the original unchoking algorithm. Thereby, anti-snubbing and the endgame-mode are neglected. We omitted the endgame mode in our implementation because it is not clearly specified when a peer switches to the endgame mode. Hence, different implementations realize it differently. Furthermore, anti-snubbing was omitted because it can result in situations where a peer does not contribute its upload bandwidth although it can transfer data to other peers. This can cause inefficiency in the network.

However, we implemented the super-seeding functionality because it improves considerably the performance for the flash crowd scenario. The BitTorrent implementation is modular. That is, the peer and the piece selection algorithms can be replaced by alternatives. Thus, different implementations of BitTorrent-like networks can be compared easily by simulations.

Reference:
K. Eger, T. Hoßfeld, A. Binzenhöfer, G. Kunzmann: "Efficient Simulation of Large-Scale P2P Networks: Packet-level vs. Flow-level Simulations", 2nd Workshop on the Use of P2P, GRID and Agents for the Development of Content Networks (UPGRADE-CN'07), in conjunction with 16th IEEE HPDC (High Performance Distributed Computing), June 25-29, 2007, Monterey Bay California, USA.

Source code:
Patch for ns-allinone-2.29
Sample script for packet-level simulation
Sample script for flow-level simulation

The patch changes the source code of agent.cc, agent.h, node.cc, node.h, tcp-full.cc, tcp-full.h and Makefile.in. Additionally, it adds the folder bittorrent/ with the corresponding files of the BitTorrent implementation. To apply changes run

patch -p1 < bittorrent.patch
in the ns-2.29 folder.
The two sample scripts simulate a flash crowd with initially only one seed and a number of leechers in the network.

Website Extracted from here

Kolja Eger
Hamburg University of Technology (TUHH)
Communication Networks
fon: +49-40-42878-3480
fax: +49-40-42878-2941
e-mail: eger@tuhh.de
web: http://www.tu-harburg.de/et6/staff/eger.html

tags : bittorrent p2p network simulator ns2 source code patch

Tips : How to use two version of NS-2

2007-03-15T13:55:00.000+09:00

If you would like to use two version of NS2, one old version and a another newer version. This is what you can set to call each different version of ns in the terminal/bash. Whenever you want to call the older version of ns, just make changes to the make file :

Example: Makefile.in

- snip -
NS = ns-old
- snip -

run "./configure && make install" again and you are done.

tags: run, two, version, network, simulator, ns2, tips

Tips : How to scale your simulation to more nodes eg. > 500 nodes and increase the simulation speed

2007-02-25T16:11:00.000+09:00

One of the biggest problem for the implementation of the Packet data structure of NS2 is that it does not math the realities. The packet in ns2 simulation keeps all packet headers for any protocols implemented in NS2. For example, a DSR routing packet may keep DSDV, AODV, or even a PING application header. For this reason, till today, a packet used in ns2 simulation, would have a header size around 40~64KB. And NO packet would be deleted to release the memory it holds until the end of the simulation.

So for a typical simulation with 100 nodes in ns2 around 1M packets exchanged (of course, you may reuse the packets already being freed through Packet::free(Packet*). To learn the implementation of it, please check file common/packet{.h,.cc} ), you may hold 10% of it, 100K packets, and you may use a memory at least 100K*64KB -> 6.4GB, which definitely would crash your computer even server computers.

SO what is the best way to scale the simulation and increase the simulation speed. Fortunately there are two ways :

1. Suggested by ns2 manual, putting the below codes in your tcl script
remove-all-packet-headers
add-packet-header DSR ARP LL MAC CBR IP

to simulation a CBR application on UDP with DSR as routing protocol in a wireless ad hoc network (OOPS!, UDP is not a header. This method is effective, but it requires you to understand most packets header you need.

2. Another way is my way, changing the tcl library for the packet headers. You may find the tcl library file for packet headers in ns2/tcl/lib/ns-packet.tcl, you may find a procedure starting as foreach prot . You can comment out all the headers you don't recognize, like all the Routing protocols you dont know, all Routers, all Multicast, all Transport Protocols except you need, all application layer protocols, some of the Wireless, some of the Mobility, Ad-Hoc Networks, Sensor Nets and all the Other. Finally, you may just have all the below left

foreach prot {
# Common:
Common
Flags
IP
# Transport Protocols
TCP
# Wireless
ARP
LL
Mac
# Mobility
AODV
} {
add-packet-header $prot
}

Here is a sample of the skeleton of the script for you to put your code for your own packet header.

Typically, after this way, you may just have a packet size as 256B. So even you have 500 nodes, and 10M packets need to be exchanged during the simulation. You just need 256MB (if 10% packets held) for it, which is lower than any common configuration of current PCs.

tags: network, simulator, ns2, scale, simulation, speed, protocol, node