Adapting BitTorrent to wireless ad hoc networks

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

Anwar AlHamra and Thierry Turletti

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

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.

Wireless LAN Power Management Extension for ns-2

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.

IEEE 802.16 Wireless Mesh Networks in ns-2

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

How to interprete the NS2 tracefile for wireless simulation

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