Monday, January 17, 2011

Mobiwan installation in NS2

For Mobile IPv6 support there are two options for the use it on NS2.
1) Use NS2.1b6 version for the NS2. The Mobiwan package and procedure is available:-

     http://www.inrialpes.fr/planete/mobiwan/

 User Guide:- http://www.inrialpes.fr/planete/mobiwan/Documents/mobiwan-report-0501.pdf

As the NS2.1b6 is much more older and not that supportable so Please try to avoid it.(by authors consideration)


2) Use NS2.33 version for the MIPv6.
  Steps:-

     a) Install NS2.33.
     b) Download Patch from :- http://www.nicta.com.au/people/mehanio/nsmisc/ns-233-mobiwan-1.patch.
     c) After installation keep the patch file "ns-233-mobiwan-1.path" in ns-2.33 folder in ns-allinone-2.33 directory.
     d) Install the patch by running "patch -p1 < ns-233-mobiwan-1" from the ns-2.33 directory.  
     e) re run "./configure ; make clean ; make" in ns-2.33 directory


steps d) and e) should be done on terminal.

This patch is only work on the Ns2.33 

Mobiwan

Mobiwan is use for the support of Mobile IPv6. Mobiwan should be installed in NS2 so that it will support any MIPv6 simulation. Mobile IPv4 is easy to generate on any NS2 simulator, but in case of MIPv6 simulation it is not possible.

There is still some work going on NS3 for MIPv6. Still there is no proper answer get from the developers of NS3 for MIPv6.

Thursday, December 30, 2010

Wireless Trace format : Default


All trace data will be recorded into a specified trace file in a certain format. The default trace format is as show below,


s 75.509208000 _0_ MAC  --- 6 cbr 100 [0.01 1 0] [energy 999.310079] ---
---- [0:0 10:0 32 1] [6] 0 0

r 75.552208667 _1_ MAC  --- 6 cbr 100 [0.01 1 0] [energy 999.411071] ----
--- [0:0 10:0 32 1] [6] 0 0

s 81.997210667 _0_ MAC  --- 7 cbr 100 [0.07 1 0] [energy 999.274915] ----
--- [0:0 10:0 32 1] [7] 0 0

s 82.051212000 _0_ MAC  --- 7 cbr 100 [0.01 1 0] [energy 999.273208] ----
--- [0:0 10:0 32 1] [7] 0 0

r 82.094212667 _1_ MAC  --- 7 cbr 100 [0.01 1 0] [energy 999.372559] -----
-- [0:0 10:0 32 1] [7] 0 0

s 83.502206667 _0_ MAC  --- 8 cbr 100 [0.07 1 0] [energy 999.251147] ----
--- [0:0 10:0 32 1] [8] 0 0

s 83.556208000 _0_ MAC  --- 8 cbr 100 [0.01 1 0] [energy 999.249441] ----
--- [0:0 10:0 32 1] [8] 0 0

r 83.599208667 _1_ MAC  --- 8 cbr 100 [0.01 1 0] [energy 999.366944] ----
--- [0:0 10:0 32 1] [8] 0 0

s 85.112206667 _0_ MAC  --- 9 cbr 100 [0.07 1 0] [energy 999.225868] ----
--- [0:0 10:0 32 1] [9] 0 0

s 85.166208000 _0_ MAC  --- 9 cbr 100 [0.01 1 0] [energy 999.224162] ----
--- [0:0 10:0 32 1] [9] 0 0

r 85.209208667 _1_ MAC  --- 9 cbr 100 [0.01 1 0] [energy 999.361227] ----
--- [0:0 10:0 32 1] [9] 0 0

The fields of trace format are explaining as follows.
  1. The first field represents the event type, whose value can be s (send), r (receive), d (drop) or f (forward).
  2. The second field the time this event happens.
  3. The third field records the id of the node, on which this event takes place.
  4. The fourth field shows the layer where this event happens. Its possible value may be one of the following four: AGT (agent), RTR (router), IFQ (interface queue), and MAC (mac).
  5. The fifth field is normally a short broken line, which is reserved for special events. For example, when collision occurs, the broken line is replaced with COL.
  6. The sixth field is the global sequence number for this packet, which is the integer number used to identify this packet in the whole network and distinguish it from others. Sequence number is only available for data packets and not allocated for control packets, like RTS/CTS/ACK and SYNC packets in S-MAC (using a zero instead).
  7. The seventh field is the packet type. The actual value is determined by the application or MAC layer, which creates this packet. For example, cbr represents that it is a data packet generated by a CBR traffic source.
  8. The eighth field is the packet size in bytes.
  9. The ninth field including three numbers in brackets concerns MAC layer information. Originally, there will be four numbers in the brackets. But S-MAC revises this format. The first number is the duration field of this packet. In Figure 4.6, the duration field of this RTS packet is 0.11 s, which is the remaining time reserved for the coming transmission. The second number stands for the MAC address of the receiver of this packet, and the third number for the sender.
  10. The tenth field including energy remained for the node at that time.
  11. The eleventh field gives source IP, Destination IP, TTL.
  12. This field gives unique packet ID.

New Wireless Trace Format

s -t 1.001836354 -Hs 4 -Hd 5 -Ni 4 -Nx 180.00 -Ny 50.00 -Nz 0.00 –Ne 999.985575 -Nl MAC -Nw --- -Ma 50 -Md 5 -Ms 4 -Mt 0 -Is 4.0 -Id 5.0 -It cbr -Il 272 -If 0 -Ii 2 -Iv 32 -Pn cbr -Pi 0 -Pf 0 -Po 0
r -t 1.002924421 -Hs 5 -Hd 5 -Ni 5 -Nx 200.00 -Ny 50.00 -Nz 0.00 –Ne 999.985544 -Nl MAC -Nw --- -Ma 50 -Md 5 -Ms 4 -Mt 0 -Is 4.0 -Id 5.0 -It cbr -Il 220 -If 0 -Ii 2 -Iv 32 -Pn cbr -Pi 0 -Pf 1 -Po 0
s -t 2.000863796 -Hs 4 -Hd 5 -Ni 4 -Nx 180.00 -Ny 50.00 -Nz 0.00 –Ne 999.973880 -Nl MAC -Nw --- -Ma 50 -Md 5 -Ms 4 -Mt 0 -Is 4.0 -Id 5.0 -It cbr -Il 272 -If 0 -Ii 7 -Iv 32 -Pn cbr -Pi 1 -Pf 0 -Po 0
r -t 2.001951863 -Hs 5 -Hd 5 -Ni 5 -Nx 200.00 -Ny 50.00 -Nz 0.00 –Ne 999.971156 -Nl MAC -Nw --- -Ma 50 -Md 5 -Ms 4 -Mt 0 -Is 4.0 -Id 5.0 -It cbr -Il 220 -If 0 -Ii 7 -Iv 32 -Pn cbr -Pi 1 -Pf 1 -Po 0

The new trace format as seen above can be can be divided into the following fields:
Event type
In the traces above, the first field (as in the older trace format) describes the type of event taking place at the node and can be one of the four types:
s send
r receive
d drop
f forward
General tag
The second field starting with "-t" may stand for time or global setting
-t time
-t * (global setting)
Node property tags
This field denotes the node properties like node-id, the level at which tracing is being done like agent, router or MAC. The tags start with a leading "-N" and are listed as below:
-Ni: node id
-Nx: node’s x-coordinate
-Ny: node’s y-coordinate
-Nz: node’s z-coordinate
-Ne: node energy level
-Nl: trace level, such as AGT, RTR, MAC
-Nw: reason for the event.
The different reasons for dropping a packet are given below:
"END" DROP_END_OF_SIMULATION
"COL" DROP_MAC_COLLISION
"DUP" DROP_MAC_DUPLICATE
"ERR" DROP_MAC_PACKET_ERROR
"RET" DROP_MAC_RETRY_COUNT_EXCEEDED
"STA" DROP_MAC_INVALID_STATE
"BSY" DROP_MAC_BUSY
"NRTE" DROP_RTR_NO_ROUTE i.e no route is available.
"LOOP" DROP_RTR_ROUTE_LOOP i.e there is a routing loop
"TTL" DROP_RTR_TTL i.e TTL has reached zero.
"TOUT" DROP_RTR_QTIMEOUT i.e packet has expired.
"CBK" DROP_RTR_MAC_CALLBACK
"IFQ" DROP_IFQ_QFULL i.e no buffer space in IFQ.
"ARP" DROP_IFQ_ARP_FULL i.e dropped by ARP
"OUT" DROP_OUTSIDE_SUBNET i.e dropped by base stations on receiving           routing updates from nodes outside its domain.
Packet information at IP level
The tags for this field start with a leading "-I" and are listed along with their explanations as following:
-Is: source address.source port number
-Id: dest address.dest port number
-It: packet type
-Il: packet size
-If: flow id
-Ii: unique id
-Iv: ttl value
Next hop info
This field provides next hop info and the tag starts with a leading "-H".
-Hs: id for this node
-Hd: id for next hop towards the destination.
Packet info at MAC level
This field gives MAC layer information and starts with a leading "-M" as shown below:
-Ma: duration
-Md: dst’s ethernet address
-Ms: src’s ethernet address
-Mt: ethernet type
Packet info at "Application level"
The packet information at application level consists of the type of application like ARP,
TCP, the type of adhoc routing protocol like DSDV, DSR, AODV etc being traced. This field consists of a leading "-P"and list of tags for different application is listed as below:
-P arp Address Resolution Protocol.
Details for ARP is given by the following tags:
-Po: ARP Request/Reply
-Pm: src mac address
-Ps: src address
-Pa: dst mac address
-Pd: dst address
-P dsr
This denotes the adhoc routing protocol called Dynamic source routing. Information on DSR is represented by the following tags:
-Pn: how many nodes traversed
-Pq: routing request flag
-Pi: route request sequence number
-Pp: routing reply flag
-Pl: reply length
-Pe: src of srcrouting->dst of the source routing
-Pw: error report flag ?
-Pm: number of errors
-Pc: report to whom
-Pb: link error from linka->linkb
-P cbr Constant bit rate.
Information about the CBR application is represented by the following tags:
-Pi: sequence number
-Pf: how many times this pkt was forwarded
-Po: optimal number of forwards
-P tcp: Information about TCP flow is given by the following subtags:
-Ps: seq number
-Pa: ack number
-Pf: how many times this pkt was forwarded
-Po: optimal number of forwards

Wednesday, December 29, 2010

NS-2 Trace format


1.     Type Identifier:-
"+": a packet enque event
"-": a packet deque event
"r": a packet reception event
"d": a packet drop
"c": a packet collision at the MAC level

2.     Time:- Time at which the above event occurred.

3.     Source and Destination Node: - It shows the ID of the nodes between which the event has occurred.

4.      Packet Name:- Type of packet

5.     Packet Size: - Size of the packet in bytes.

6.     Flags: - A 7-digit flag string is defined. Each flag digit is set to “-” if the corresponding flag is disabled. Otherwise, it will be set as follows. The first is set to “E” if an ECN (Explicit Congestion Notification) echo is enabled. The second is set to “P” if the priority in the IP header is enabled. The fourth is set to “A” if the corresponding TCP takes an action on congestion (e.g., closes the congestion window). The fifth is set to “E” if the congestion has occurred. The sixth is set to “F” if the TCP fast start is used. Finally, the seventh is set to “N”, when the transport layer protocol is capable of using Explicit Congestion Notification (ECN).

7.     Flow ID: Flow ID specified in the field fid_ of an IP packet header.

8.     Source Address and Destination Address: The source and destination addresses of a packet specified in an IP packet header. For a flat addressing scheme, the format of these two fields is “a.b”, where “a” is the address and “b” is the port.

9.     Sequence Number: The sequence number specified in packet header. Specified by a transport layer protocol.

10  Packet Unique ID: A unique ID stored in a common packet header.

Changing environment variables in ns-2

The installation procedure given in the previous post allows you to run the ns2 codes only by placing these codes in the /ns-2.34/bin folder. By editing the environment variables it is possible to simulate the tcl codes present anywhere in the filesystem.


1.     First enter the ns-2.34-allinone folder
$ cd ns-2.34-allinone

2.     We have to edit bashrc file
$ gedit ~/.bashrc

3.    Add the following lines to this file. Change /home/programmer according to where your ns-2 has been installed.


# LD_LIBRARY_PATH

OTCL_LIB=/home/programmer/ns-allinone-2.33/otcl-1.13

NS2_LIB=/home/programmer/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/programmer/ns-allinone-2.33/tcl8.4.18/library

USR_LIB=/usr/lib

export TCL_LIBRARY=$TCL_LIB:$USR_LIB


# PATH

XGRAPH=/home/programmer/ns-allinone-2.33/bin:/home/programmer/ns-allinone-2.33/tcl8.4.18/unix:/home/programmer/ns-allinone-2.33/tk8.4.18/unix:/home/programmer/ns-allinone-2.33/xgraph-12.1/

NS=/home/programmer/ns-allinone-2.33/ns-2.33/

NAM=/home/programmer/ns-allinone-2.33/nam-1.13/

export PATH=$PATH:$XGRAPH:$NS:$NAM

4.     To let this change take effect, type the following command
$source ~/.bashrc


To run your tcl script use the following command
$ns filename.tcl

Tuesday, December 28, 2010

The WiMAX Forum System Level Simulator NS-2 MAC+PHY Add-On for WiMAX (IEEE 802.16)

New Features in Release 2.6

1. The cdma_codes (0-255) are distributed among codes for bandwidth request, initial ranging, handover and CQICH. These cdma-code ranges can be set at “ns-wimax.tcl”.
2. To send the bandwidth request (BWR), MSS scheduler makes use of transmission opportunity and cdma_ranging code to verify the opportunity to transmit for each MSS.
3. This version supports a variable part of DL_MAP by taking number of burst allocation in both uplink and downlink.
4. Number of DL_PREAMBLE can variably set to either 1 or 3 symbol-columns.
5. The best effort fair scheduling for downlink allocation is written up with the decrease in complexity.
6. With OFDMA PHY, the end of downlink map entity is removed. The end of UL_MAP will be removed in the next patch. Note that although there is a presence of the end of
UL_MAP entity, there is no packet transmission during this region.
7. The downlink subframe is utilized; we take the space right after the MAP for data allocation.
8. Channel Index random allocation scheme update based on CDMA Ranging mechanism.
9. Effective SINR realignment to dB scale.
10. Support ARQ in Handover scenario
11. New transmission power and interference power calculation logic.