J-Sim Wireless Extension

February 15, 2004

1    Introduction

This tutorial is intended to provide users with an overview of the J-Sim wireless extension. The J-Sim wireless extension includes a set of components which facilitates some basic studies of wireless/mobile network simulation. Figure 1 depicts the schematic of a wireless node in the J-Sim wireless extension architecture.

Figure 1: Schematic of a wireless node in J-Sim.

To simulate a wireless mobile node, there are three categories of additional components to be developed besides those existing modules in J-Sim: 

1. a set of protocols to support wireless and mobile communication (including AODV, ARP, IEEE802.11 and LL). 
2. a set of components simulating the physical characteristics of mobile nodes, which includes the position and movement of the mobile nodes, the energy consumption of each mobile node, as well as the signal strength of each received frame on wireless card. This set of components include WirelessPhy, MobilityModel, RadioPropagationModel and EnergyModel components, where the EnergyModel component resides in the WirelessPhy component and not is shown in the above node architecture graph.
3. a scheme to simulate the shared "channel"  on which each wireless card is working. The Channel and NodePositionTracker classes are defined to simulate such kind of shared medium. The design goal of them is  to lower the simulation overhead and make the simulation scalable especially in the case of scenario involving large number of mobile nodes

We assume the readers of this tutorial are already familiar with the J-Sim's component based architecture, therefore we don't explain why those components are connected via pairs of ports. In the rest of the tutorial, we will explain each component in the three component sets, including what its functionalities and how it interacts with other components.  In the last session o this tutorial, we will give examples about how to construct the simulated scenario step by step.

2    LL, ARP, IEEE802.11 and AODV

2.1    LL

The LL component implements some link layer functions. A LL component contains four ports: an upper port (upPort) which is connected to the down port of PktDispatcher (IP Layer), two down ports (downPort and macPort) which are connected to the wireless interface outgoing queue (implemented with a Queue component) and the Mac_802_11 component respectively, and a macPort which is connected to an ARP component. 

When A LL components receives an InetPacket from the PktDispatcher, it does ARP resolve to find out the MAC address of the next hop node to which the InetPacket should be. After the ARP resolve, each InetPacket  is encapsulated in a LLPacket and put in the interface queue of the underlying wireless interface card. At the meanwhile, if a packet is received from the underlying Mac_802_11 component, the LL component shall dispatch it to ARP if it is an ARP packet, otherwise the LL component shall forward it to PktDispatcher if that packet is an InetPacket. 

2.2    ARP

The ARP component implements Address Resolution Protocol (ARP). It maintains an ARPTable, and each entry in that table records the IP address of a mobile node and the MAC address of the receiving wireless interface card of that mobile node. ARP probes and collects the mapping of MAC address and IP address by sending/receiving ARP request and reply packets to/from the neighboring nodes.

When a unicast InetPacket arrives at a LL component,  the LL component construct an ARPContract.Message object as an ARP resolve packet and sends it to the ARP component. Upon receiving that resolve request, the ARP component looks up its ARPTable to find out corresponding entry. If the corresponding entry can not be found, the ARP component initializes an ARP request and reply procedure to discover the correct mapping of IP address and MAC address. If the entry is found, a LLPacket is constructed and encapsulated in an ARPContract.Message object and sent back the LL component. When the LL component receives that ARPContract.Message, it retrieves the encapsulated LLPacket and puts into the interface queue of the underlying wireless interface card.

There is a special flag "bypassARP" defined in ARP components, which facilitates the bypassing of Address Resolution procedure. When that flag is set to true, the ARP component assumes the MAC address should be of the same value of the corresponding IP address and never sends out ARP request packet. Although in real world, this is never true, using this bypassing mechanism, we can simplify the simulation and make debugging more easier in certain circumstances. 

2.3    IEEE 802.11

IEEE 802.11 currently is the only MAC protocol implemented in J-Sim wireless extension. The protocol is implemented mainly in  the Mac_802_11 component. Outgoing InetPackets and ARP packets are buffered in the Queue component. Whenever Mac_802_11 finishes the transmission of an outgoing packet, it sends an null back to the Queue. According to the ActiveQueue contract, such an null object means asking for a new packet from the buffer. Mac_802_11 components run IEEE 802.11 MAC protocol to determine when an IEEE802.11 mac frame should sent out  through the wireless interface card (WirelessPhy). When a data frame is correctly received and decoded by the wireless interface card (WirelessPhy), that data frame arrives at Mac_802_11 from WirelessPhy. The payload (InetPacket or ARP packet) of the received IEEE802.11 data frame shall be forwarded to the LL component through the llPort of the Mac_802_11 component.  Mac_802_11 sends link failure notification message to the AODV component in case of link failures. 

2.4    IEEE 802.11 Power Saving Mode

 We have implemented the IEEE 802.11 Power Saving Mode in J-Sim following the IEEE 802.11 specification in ad hoc mode (or IBSS). 

2.4.1    Supporting Classes

In addition to modifications to the Mac_802_11 and WirelessPhy class, several supporting classes are implemented to handle power saving.

• TSFTimer: generates a logical timer for time synchronization. If TSFTimer.offset_ is set to 0, all nodes are synchronized since the start of the simulation.
• ATIMEndTimer: indicates the ending of ATIM (ad hoc traffic indication map) window.
• TBTTTimer: generates periodic beacon periods.
• BeaconTimer: starts the transmission of beacon messages inside ATIM window.
• EnergyModel: specifies energy profile of the wireless devices and tracks the energy consumption throughout the simulation

2.4.2    Usage

Enable PSM

By default, PSM is disabled. One can enable power saving mode by adding the following line in script files:

! mac enable_PSM

Conversely, to disable PSM

! mac disable_PSM

Specify beacon interval and ATIM size

The default values of the beacon interval and ATIM window length are 0.01s and 0.008s. To change the settting, one can add the following lines in script files.

! mac setBeaconInterval XXX
! mac setATIMWindow YYY

Specify energy consumption

The default energy consumption for different states (transmitting, receiving, sleep, idle, shut-down) is specified in class EnergyModel. To modify the energy profile, one can add the following lines in script files.

! phy setEnergyModel tx_pwr rx_pwr idle_pwr off_pwr

2.5    AODV

The Ad hoc On Demand Distance Vector (AODV) routing algorithm is a routing protocol designed for ad hoc mobile networks. The AODV component is one of routing protocols implemented in J-sim. The implementation of AODV is based on AODV Draft (version. 11) and AODV class in ns-2. For the details of component structure in J-sim, please refer to Inet tutorial. The extracted class structure related to AODV component is shown below: (please refer to the script file) 

AODV protocol mainly consists of two phases: route discovery and route maintenance. 

Route discovery phase

In the route discovery phase, a source node searches for a route towards its destination by broadcasting a route request (RREQ) packet. Only in two cases a node initiates a RREQ broadcast:

1. On-demand routing: a source find out there is no route available in its routing table. (pktDispatcher send a event to AODV, processed in RouteQueryHandler( ) ).
2. Local repair: an intermediate node receives a link broken event from the MAC layer, i.e. it fails to reach the next hop. At this time, besides sending a route error (RERR) packet back to the source, this intermediate node volunteers to find a route for the source to relay packets stored in its buffer. 

When an intermediate node receives a RREQ packet, it first builds an entry of the reverse route in the routing table. Then it checks whether it has a fresh route entry to the destination. If such a routing entry exists, the node send back the route reply (RREP) packet back to the original source; otherwise, it keeps broadcasting the RREQ packet until the RREQ packet reaches to the destination. 

Route maintenance phase

In the route maintenance phase, when a relay node fails to reach its next hop due to congestion or mobility of nodes, it sends back a route error (RERR) packet back to the source. When a node receives a RERR packet, it removes the entry of this route from its routing table. The link broken event can be either from the underlying MAC layer or from the missing of periodical beacon messages. If the MAC layer such as IEEE 802.11b can provide the detection ability of broken links, the periodical hello message is not required. In the script, to disable the link detection we use:

! aodv enable_link_detection 

AODV Example

The script file shows an example of the usage of AODV package. The networks consist of 6 nodes (n0 ~ n5) placed in a line. The distance between two nodes is 200 m. Since the default transmission range of IEEE 802.11b is about 250 m, a node can only reach it neighboring node(s). 3 TCP connections (n0-n3, n1-n4, and n2-n5) are constructed. Each connection starts at different time to avoid collisions of RREQ broadcasting. The results of the contention window size of three connection in 2000 seconds are shown below:

3    WirelessPhy, MobilityModel, RadioPropagationModel, EnergyModel and Antenna

These four components cooperatively simulate physical characteristics of the wireless interface card of a mobile node. MobilityModel simulates the movement of the mobile node and tracks/records/reports the current node position.  When a MAC frame arrives at a WirelessPhy component from Mac_802_11 component, WirelessPhy inquiries the MobilityModel to get the current (sender) node position. The MAC frame along with the transmission power of this frame, the sender position, the transmission antenna gain are packed into a NodeChannelContract.Message object and sent down the Channel component. When the WirelessPhy of the receiver receives that NodeChannelContract.Message, the encapsulated MAC frame, the transmission power, the transmission antenna gain and the sender position are retrieved from that message. Using these sender-side information plus the receiver-side information like the receiving node position, the receiver antenna gain, after consulting the RadioPropagationModel being adopted, the receiving WirelessPhy is able to determine whether that MAC frame can be decoded, sensed or not. If it can be decoded correctly or it exceeds the carrier sense sensitively threshold, the MAC frame is passed to Mac_802_11. In the later case, a special error flag is set to indicates this is a corrupted frame and should only affects  the carrier sensing mechanism. 

3.1    WirelessPhy 

The WirelessPhy component mainly simulates some features of the physical layer of a wireless card. It simulates/calculates the receiving signal strength of each frame by consulting the installed radio propagation model and determines whether it can be decoded correctly or not.  

3.2    MobilityModel

The MobilityModel component implemented two mobility models: Random Waypoint Mobility Model and Trajectory Based Mobility Model. If a trajectory array is installed, the MobilityModel component automatically simulates the node movement according to the specified trajectory. Between two consecutive trajectory points, it is assumed that the mobile node moves with the fixed velocity. If no trajectory array is installed, Random Waypoint mobility model is used to simulate the movement of mobile nodes.. 

3.3    RadioPropagationModel

The RadioPropagationModel is the base class of all radio propagation models. There are three radio propagation models which have been implemented in J-Sim Extension: Free Space Model, Two-ray Ground Model and Irregular Terrain Model. 

3.3.1    Free Space Model 

In the absence of any reflections or multipath, radio wave propagation can be modeled using the free space propagation model which says:

         P_t * G_t * G_r * (lambda^2)
 P_r = --------------------------------
             (4 * pi * d)^2 * L

where P_t is the transmitted signal power, G_t is the antenna gain of the transmitter, G_t is the antenna gain of the reciver, L is the system loss, lambda is the wavelength and d is the distance between the transmitter and the receiver. Because G_t, G_r, L, P_t, are available at the receiving WirelessPhy component, the free space model only need to calculate the path gain (PG) which is decided by the equation

           (lambda^2)
PG = -----------------
         (4 * pi * d)^2 

3.3.2    Two-ray Ground Model

The Two-ray Ground model considers both the direct path and a ground reflection path, which is more accurate than the free space model. A cross-over distance d_c is used in this model. When the distance between two nodes is smaller than d_c, the free space model result is used. When d is larger than d_c, the equation 

         P_t * G_t * G_r * (h_t^2)*(h_t^2)
 P_r = --------------------------------
             (4 * pi * d)^2 * L

is used to calculate the received signal strength. The cross-over distance is calculated as 

d_c = (4 * pi * h_t * h_r)/lambda

Similarly, the Two-ray Ground model component only need to calculate the path gain 

           (lambda^2)
PG = -----------------
         (4 * pi * d)^2 

when d < d_c and 

                (h_t^2)*(h_t^2)
 PG = ---------------------
               (4 * pi * d)^2 

when d >= d_c.

3.3.3    Irregular Terrain Model

Irregular Terrain Model is based on electromagnetic theory and on statistical analyses of both terrain features and radio measurements, predicts the median
attenuation of a radio signal as a function of distance and the variability of the signal in time and in space [1]. Irregular Terrain Model requires
altitude on each point of the earth which can be obtained from Globe data [2]. In order to match the trace result in our example tcl file, it is important
to download the Globe 1.0 Data from http://www.ngdc.noaa.gov/seg/topo/globe.shtml. When using Irregular Terrain Model, one must use ellipsoidal latitude and longitude coordinates instead of Cartesian coordinates. 

The following lists the input for using Irregular Terrain Model with the corresponding variable in the class IrregularTerrainModel in J-SIM and their default value in the parenthesis.

- globePath: the directory that contains Globe data files. This has to be provided by the user.
- nPoints (20): number of points between source and destination in the terrain profile. 
- polarity (1): polarity of antenna: (0: horizontal polarization, 1: vertical polarization)
- radioClimate (4): climate types 

1  for Equatorial
2  for Continental Subtropical
3  for Maritime Tropical
4  for Desert
5  for Continental Temperate
6  for Maritime Temperate, Over Land
7  for Maritime Temperate, Over Sea

- surfRef (280): minimum monthly mean surface refractivity
- dielectric (15): dielectric constant of ground 
- conductivity (0.005): conductivity of ground
- freq: frequency in MHz (this value is supplied from WirelessPhy.java
People who are not familiar to those parameters can generally use the default values as above
except that globePath must be specified.

The J-SIM command to use Irregular Terrain Model is as follows:    

        mkdir drcl.inet.mac.IrregularTerrainModel propagation

All the parameters can be set through the variable propagation. For example,

! propagation setGlobePath "/home/jhou/hzhang3/disk2/terrain/globedat/"
! propagation setNumPoints 20
! propagation setPolarity 1
! propagation setRadioClimate 4
! propagation setSurfRef 280 
! propagation setDielectric 15.0 
! propagation setConductivity 0.005 

The first parameter has to be set by users. All remaining are optional.

In order to output the trace result of ITM model, .proptrace port has to be connected with a trace file. For example,

$file_ open "fileName"
connect -c n0/propagation/.proptrace@ -to $file_/in@

3.4    EnergyModel

The EnergyModel component resides in the WirelessPhy component and tracks the energy consumption of the mobile node. If a mobile node depletes its energy reserve, the interface card is assumed dead and no more further communication can be done. 

3.5    Antenna

Two different types of antenna, Omni-Directional and Directional antenna respectively are simulated in J-Sim. 

Omni-Directional Antennas

If the omni-directional antenna is used, basically there is nothing to be done. The default configuration is as follows:

• Height = 1.5 meters
• Gain = 1.0dBi

The default setting can be changed by injecting certain objects through the .antenna port of the WirelessPhy component, which is the antenna configuration port. For example, in the script, add the following lines (red lines) shall change the antenna height and gain respectively.

?/p>

mkdir drcl.inet.mac.WirelessPhy phy

inject “set height = 2?phy/.antenna@

inject “set omnigain_dbi = 0.9?phy/.antenna@

?/p>

Directional Antennas

 We support two types of directional antennas: Switched Beam antenna and Adaptive Array antenna. They both are derived from the base class: Antenna.java and bear the names: SwitchedBeamAntenna.java and AdaptiveAntenna.java, respectively. To create either directional antenna, you have to add the following command in the script:

?/p>

mkdir drcl.inet.mac.WirelessPhy phy

inject “create SwitchedBeam Antenna?phy/.antenna@ (or ?“create Adaptive Antenna??)

inject “azimuthpatterns = azimuth_file?phy/.antenna@ (required)

inject “elevationpatterns = elevation_file?phy/.antenna@ (optional, if occur, has to be after the above line)

?/p>

Note: For either directional antenna, the azimuth pattern has to be initialized using the file: azimuth_file. It’s optional to initialize the elevation pattern, but if choose to do, which has to be after the initialization of the azimuth pattern. The azimuth_file may be like example 1 and example 2. You can also still set the height or omnigain_dbi as done for the omnidirectional antenna. 

As for there are no standard protocols for directional antennas, by default we assume omni-directional listening, directional receiving and omni-directional transmitting. The directional will stay in the omni-directional mode when idling, once it detects a signal strong enough, it will lock on that signal using the pattern that detects the strongest signal. After receiving the signal, the directional antenna will unlock itself and switch back to the omni-directional mode.

Finally, a simple script file is provided to test the directional antenna. See aodv_n6_tcp3_multi_hop_directional_antenna.tcl, which uses the azimuth_file: azimuth-switchedbeam (for Switched Beam Antenna, or azimuth-adaptive for Adaptive Array Antenna) and no elevation_file.

4    Channel and NodePositionTracker

In wireless networks, the communication between mobile nodes is conducted over "channels". The wireless interface card of a mobile node usually listen/transmit to one or multiple channels. It is impropriate to define a "wireless link" class and interconnect each pair of mobile nodes with such kind of "wireless link" component. Therefore, a "Channel" component is implemented to simulate the shared wireless channel. In order to control the simulate overhead thus to make the simulator scalable, it is not appropriate to let the "Channel" duplicate and forward every frame transmitting over the wireless medium to all wireless interface cards currently attached (listening) to that channel. Although in real world the transmission activity of any mobile node should be seen as interference to other mobile nodes, we can artificially let only the "near-by" mobile nodes of the sender to sense such interference. Therefore in our implementation, when a frame arrives at "Channel", only the "neighboring" nodes of the sending node shall receive a copy of that frame. 

4.1    Channel

The Channel component simulates a shared channel. A Channel component contains a "nodePort". All mobile nodes' WirelessPhy components should be connected to this port if they are working on this channel. The channel component also contains a vector of Ports, each port is connected to the WirelessPhy component of a specific mobile node if that WirelessPhy is working on this channel. Otherwise that port is just unconnected. When a mobile node transmits a frame, that frame is received by the Channel component from the nodePort. The Channel component queries the NodePositionTracker to get a list of ids of  all "neighboring" nodes, whose wireless interface card should "hear" and process that frame. Then that frame is duplicated and sent "up" to those nodes via the corresponding ports in that port vector.

4.2    NodePositionTracker`

The NodePositionTracker tracks the position of each mobile node and determine the neighboring relation of each node pair. In general, NodePositionTracker artificially divides the whole simulated area into subareas.  We assume all simulated areas are rectangles, thus in each simulation scenario, the area is divided into many small rectangles. The NodePositionTracker periodically receives the position update report from the mobility model component of each node. When the Channel enquiries the neighbors of a sender node (the red dot) in the example, the NodePositionTracker first determines that the sender is currently sitting in subarea (4,2), then it retrieves out all nodes in all adjacent subareas of subarea (3,2) and sends the node ids back to the Channel component, that is, only those green dots in blue area are considered close enough to the red dot to "hear" the transmission activity of that sender. 

After creating the NodePositionTracker in the script, need to call setGrid method to set those parameters about the simulation area, including the maximal and minimal coordinates of the simulation area, the grid size, etc. For example, the following lines in a script

mkdir drcl.inet.mac.NodePositionTracker tracker 
! tracker setGrid 100.0 0.0 100.0 0.0 50.0 50.0

shall create a tracker to simulate a (100M x 100M) square area which grid size (50M x 50M).

5    Constructing  Simulation Scenario

5.1    Example 1:   a two node scenario 

In this example, we create a very simple simulation scenario, which includes only two mobile nodes n0 and n1, to demonstrate the basic steps in setting up a wireless simulation scenario. The nodes n0 and n1 are located at (40, 0) and (0, 40) respectively. A TCP connection from n0 to n1 is set up. The complete script file can be found here.

Step1:  Create a root component 

cd [mkdir -q drcl.comp.Component /example]

Step 2: Create node 0 and its child components explicitly and connecting corresponding ports accordingly. 

# create node 0
set node0 [mkdir drcl.comp.Component n0]
cd n0
mkdir drcl.inet.mac.LL ll
mkdir drcl.inet.mac.ARP arp
mkdir drcl.inet.core.queue.FIFO queue
mkdir drcl.inet.mac.Mac_802_11 mac
mkdir drcl.inet.mac.WirelessPhy phy
mkdir drcl.inet.mac.FreeSpaceModel propagation 
mkdir drcl.inet.mac.MobilityModel mobility
mkdir drcl.inet.protocol.aodv.AODV aodv
set PD [mkdir drcl.inet.core.PktDispatcher pktdispatcher]
set RT [mkdir drcl.inet.core.RT rt ]
set ID [mkdir drcl.inet.core.Identity id ]
$PD bind $RT
$PD bind $ID 

# enable route_back flag at PktDispatcher
! pktdispatcher setRouteBackFlag true

# connect components in node 0
connect phy/.mobility@ -and mobility/.query@
connect phy/.propagation@ -and propagation/.query@
connect mac/down@ -and phy/up@
connect mac/up@ -and queue/output@
connect ll/.mac@ -and mac/.linklayer@
connect ll/down@ -and queue/up@ 
connect ll/.arp@ -and arp/.arp@
connect -c pktdispatcher/0@down -and ll/up@ 
connect -c aodv/down@ -and pktdispatcher/103@up
connect aodv/.service_rt@ -and rt/.service_rt@
connect aodv/.service_id@ -and id/.service_id@
connect aodv/.ucastquery@ -and pktdispatcher/.ucastquery@
connect mac/.linkbroken@ -and aodv/.linkbroken@

Step 3: Configure MAC and IP address of node 0

! arp setAddresses 0 0
! ll setAddresses 0 0
! mac setMacAddress 0
! phy setNid 0
! mobility setNid 0
! id setDefaultID 0

Step 4: Configure the mobility model in node 0.

# ! mobility setTopologyParameters maxX maxY minX minY dX dY dZ
! mobility setTopologyParameters 100.0 100.0 0.0 0.0 50.0 50.0 0.0
# node 0 is located at (40.0. 0.0. 0.0) and is stationary (speed = 0.0)
! mobility setPosition 0.0 40.0 0.0 0.0

Step 5: Configure some parameters and flags

! aodv enable_link_detection

! mac disable_PSM
! arp setBypassARP true

! queue setMode "packet"
! queue setCapacity 40

cd ..

Repeat Step 2 ~ 5 to create and configure node 1

# create node 1
puts "create node 1"
set node1 [mkdir drcl.comp.Component n1]
cd n1

mkdir drcl.inet.mac.LL ll
mkdir drcl.inet.mac.ARP arp
mkdir drcl.inet.core.queue.FIFO queue
mkdir drcl.inet.mac.Mac_802_11 mac
mkdir drcl.inet.mac.WirelessPhy phy
mkdir drcl.inet.mac.FreeSpaceModel propagation 
mkdir drcl.inet.mac.MobilityModel mobility
mkdir drcl.inet.protocol.aodv.AODV aodv
set PD [mkdir drcl.inet.core.PktDispatcher pktdispatcher]
set RT [mkdir drcl.inet.core.RT rt ]
set ID [mkdir drcl.inet.core.Identity id ]
$PD bind $RT
$PD bind $ID 

#enable route_back flag at PktDispatcher
! pktdispatcher setRouteBackFlag true

puts "connect components in node 1"
connect phy/.mobility@ -and mobility/.query@
connect phy/.propagation@ -and propagation/.query@
connect mac/down@ -and phy/up@
connect mac/up@ -and queue/output@
connect ll/.mac@ -and mac/.linklayer@
connect ll/down@ -and queue/up@ 
connect ll/.arp@ -and arp/.arp@
connect -c pktdispatcher/0@down -and ll/up@
connect -c aodv/down@ -and pktdispatcher/103@up
connect aodv/.service_rt@ -and rt/.service_rt@
connect aodv/.service_id@ -and id/.service_id@
connect aodv/.ucastquery@ -and pktdispatcher/.ucastquery@
connect mac/.linkbroken@ -and aodv/.linkbroken@

! aodv enable_link_detection

! arp setAddresses 1 1
! ll setAddresses 1 1
! phy setNid 1
! mac setMacAddress 1
! mobility setNid 1
! id setDefaultID 1

# ! mobility setTopologyParameters maxX maxY minX minY dX dY dZ
! mobility setTopologyParameters 100.0 100.0 0.0 0.0 50.0 50.0 0.0
# node 1 is located at (0.0. 40.0. 0.0) and is stationary (speed = 0.0)
! mobility setPosition 0.0 0.0 40.0 0.0

! mac disable_PSM
! arp setBypassARP true

! aodv enable_link_detection

! queue setMode "packet"
! queue setCapacity 40

cd ..

Step 6  Create the Channel and NodePositionTracker components

mkdir drcl.inet.mac.Channel channel
mkdir drcl.inet.mac.NodePositionTracker tracker 

#! tracker setGrid maxX  minX  maxY  minY  dX  dY
! tracker setGrid 100.0 0.0 100.0 0.0 50.0 50.0

connect channel/.tracker@ -and tracker/.channel@
connect /example/n0/mobility/.report@ -and /example/tracker/.node@
connect /example/n1/mobility/.report@ -and /example/tracker/.node@

# there are two nodes in the scenario, therefore set the capacity to 2
! channel setCapacity 2

connect n0/phy/down@ -to channel/.node@
! channel attachPort 0 [! /example/n0/phy getPort .channel]

connect n1/phy/down@ -to channel/.node@
! channel attachPort 1 [! /example/n1/phy getPort .channel]

Step 7 Create the traffic source and sink

mkdir drcl.inet.transport.TCP n0/tcp
connect -c n0/tcp/down@ -and n0/pktdispatcher/17@up
! n0/tcp setMSS 512; # bytes

mkdir drcl.inet.transport.TCPSink n1/tcpsink
connect -c n1/tcpsink/down@ -and n1/pktdispatcher/17@up

! n0/tcp setPeer 1

set src_ [mkdir drcl.inet.application.BulkSource n0/source]
$src_ setDataUnit 512
connect -c $src_/down@ -and n0/tcp/up@

set sink_ [mkdir drcl.inet.application.BulkSink n1/sink]
connect -c $sink_/down@ -and n1/tcpsink/up@

Step 8  Set up TrafficMonitor and Plotter etc.

puts "Set up TrafficMonitor & Plotter..."
set plot_ [mkdir drcl.comp.tool.Plotter .plot]
set tm_ [mkdir drcl.net.tool.TrafficMonitor .tm]
connect -c n1/pktdispatcher/17@up -to $tm_/in@; # corrected on 2005/08/08
connect -c $tm_/bytecount@ -to $plot_/0@0
connect -c n0/tcp/cwnd@ -to $plot_/0@1
connect -c n1/tcpsink/seqno@ -to $plot_/0@2
connect -c n0/tcp/srtt@ -to $plot_/0@3

connect n0/mac/.mactrace@ -to [! /.term/tcl0/result@] 
connect n1/mac/.mactrace@ -to [! /.term/tcl0/result@] 

Step 9  Start the simulator

puts "simulation begins..." 
set sim [attach_simulator .]

run .
$sim stopAt 100

5.2    Example 2:   a multi-hop scenario (20 nodes + 1 TCP flow)

In this example, we create a multi-hop scenario involving 20 nodes. The 20 nodes are put along a straight line and the distance between any two neightbouring nodes is 80.0 meters. One TCP flow from node 0 to node 19 is set up. The complete simulation script can be found here.

Step 1 Create the Channel and NodePositionTracker components  

cd [mkdir -q drcl.comp.Component /example2]

puts "create channel"

set N 20

mkdir drcl.inet.mac.Channel channel

mkdir drcl.inet.mac.NodePositionTracker tracker 
# maxX minX maxY minY dX dY
! tracker setGrid 2000.0 0.0 2000.0 0.0 300.0 300.0

connect channel/.tracker@ -and tracker/.channel@
! channel setCapacity [expr $N]

Step 1 Create the mobile nodes

for {set i 0} {$i < $N} {incr i} { 
puts "create node $i"
set node$i [mkdir drcl.comp.Component n$i]

cd n$i

mkdir drcl.inet.mac.LL ll
mkdir drcl.inet.mac.ARP arp
mkdir drcl.inet.core.queue.PreemptPriorityQueue queue
mkdir drcl.inet.mac.Mac_802_11 mac
mkdir drcl.inet.mac.WirelessPhy phy
mkdir drcl.inet.mac.FreeSpaceModel propagation 
mkdir drcl.inet.mac.MobilityModel mobility

! queue setLevels 2
! queue setClassifier [java::new drcl.inet.mac.MacPktClassifier]

set PD [mkdir drcl.inet.core.PktDispatcher pktdispatcher]
set RT [mkdir drcl.inet.core.RT rt]
set ID [mkdir drcl.inet.core.Identity id]

$PD bind $RT
$PD bind $ID 

#enable route_back flag at PktDispatcher
! pktdispatcher setRouteBackEnabled true

mkdir drcl.inet.protocol.aodv.AODV aodv
connect -c aodv/down@ -and pktdispatcher/103@up
connect aodv/.service_rt@ -and rt/.service_rt@
connect aodv/.service_id@ -and id/.service_id@
connect aodv/.ucastquery@ -and pktdispatcher/.ucastquery@
connect mac/.linkbroken@ -and aodv/.linkbroken@

# present if using 802.11 power-saving mode
#connect mac/.energy@ -and phy/.energy@ 
#! mac enable_PSM 
! mac disable_PSM 

# since 802.11 provides link broken detection, we set the flag in AODV
! aodv enable_link_detection

# puts "connect components in node $i"

connect phy/.mobility@ -and mobility/.query@
connect phy/.propagation@ -and propagation/.query@

connect mac/down@ -and phy/up@
connect mac/up@ -and queue/output@

connect ll/.mac@ -and mac/.linklayer@
connect ll/down@ -and queue/up@ 
connect ll/.arp@ -and arp/.arp@

connect -c pktdispatcher/0@down -and ll/up@ 

set nid $i

! arp setAddresses $nid $nid
! ll setAddresses $nid $nid
! mac setMacAddress $nid
! phy setNid $nid
! mobility setNid $nid
! id setDefaultID $nid

! queue setMode "packet"
! queue setCapacity 40

# disable ARP 
! arp setBypassARP true

! mac setRTSThreshold 0

connect mobility/.report@ -and /example2/tracker/.node@

connect phy/down@ -to /example2/channel/.node@

! /example2/channel attachPort $i [! phy getPort .channel]

# design a scenario that all nodes are aligned and require multi-hops routing
! mobility setPosition 0.0 [expr 80.0 * $i] 0.0 0.0 


# maxX maxY minX minY dX dY dZ
! mobility setTopologyParameters 2000.0 0.0 2000.0 0.0 300.0 300.0 10.0


! mac disable_MAC_TRACE_ALL
! mac set_MAC_TRACE_ALL_ENABLED false
! mac set_MAC_TRACE_PACKET_ENABLED false
! mac set_MAC_TRACE_CW_ENABLED false
! mac set_MAC_TRACE_EVENT_ENABLED false
! mac set_MAC_TRACE_TIMER_ENABLED false

cd ..

}

Step 2  Set the seeds of  random number generators in Mac_802.11, MobilityModel and AODV components by calling the "setSeed()" of any instance of those classes once respectively. Because those random number generators are declared as static, it doesn't matter whether it is n0, n1 or anyother node in the following three lines. In this example, we call the corresponding methods of the three components on node 0.  

! n0/mac setSeed 111
! n0/mobility setSeed 333
! n0/aodv setSeed 1983

Step 3  Set up a TCP connection from n0 to n19

puts "setup source and sink..."
mkdir drcl.inet.transport.TCP n0/tcp
connect -c n0/tcp/down@ -and n0/pktdispatcher/17@up
! n0/tcp setMSS 512; # bytes
! n0/tcp setPeer 19

set src_ [mkdir drcl.inet.application.BulkSource n0/source]
$src_ setDataUnit 512
connect -c $src_/down@ -and n0/tcp/up@

mkdir drcl.inet.transport.TCPSink n19/tcpsink
connect -c n19/tcpsink/down@ -and n19/pktdispatcher/17@up
set sink_ [mkdir drcl.inet.application.BulkSink n19/sink]
connect -c $sink_/down@ -and n19/tcpsink/up@

Step 4  Set up traffic monitors and plotters

puts "Set up TrafficMonitor & Plotter..."
set plot_ [mkdir drcl.comp.tool.Plotter .plot]
set tm_ [mkdir drcl.net.tool.TrafficMonitor .tm]

connect -c n19/pktdispatcher/17@up -to $tm_/in@; # corrected on 2007/01/09
connect -c $tm_/bytecount@ -to $plot_/0@0
connect -c n0/tcp/cwnd@ -to $plot_/0@1
connect -c n19/tcpsink/seqno@ -to $plot_/0@2

Step 5  Turn on the flag so that frames shall be traced in the Mac_802_11 component on node 0. Connect a file to the trace port so that all exported events are recorded in that file. 

! n0/mac set_MAC_TRACE_PACKET_ENABLED true
set fileName_ example2_traceall.result
puts "Set up file '$fileName_' to store rsults..."
set file_ [mkdir drcl.comp.io.FileComponent .file]
$file_ open $fileName_
connect -c n0/mac/.mactrace@ -to $file_/in@

Step 6  Start the simulator and all active components. To avoid the packet collision at the beginning of the simulation due to all nodes transmit at at the same time, a small random delay is introduced to each node's starting time.

puts "simulation begins..." 
set sim [attach_simulator .]
$sim stop

script {run n1} -at 0.02 -on $sim
script {run n2} -at 0.04 -on $sim
script {run n3} -at 0.06 -on $sim
script {run n4} -at 0.08 -on $sim
script {run n5} -at 0.10 -on $sim
script {run n6} -at 0.12 -on $sim
script {run n7} -at 0.14 -on $sim
script {run n8} -at 0.16 -on $sim
script {run n9} -at 0.18 -on $sim
script {run n10} -at 0.20 -on $sim
script {run n11} -at 0.22 -on $sim
script {run n12} -at 0.24 -on $sim
script {run n13} -at 0.26 -on $sim
script {run n14} -at 0.28 -on $sim
script {run n15} -at 0.30 -on $sim
script {run n16} -at 0.32 -on $sim
script {run n17} -at 0.34 -on $sim
script {run n18} -at 0.36 -on $sim

script {run n19} -at 2.0 -on $sim
script {run n0} -at 5.0 -on $sim
$sim resume
$sim stopAt 500.0 

Reference:

[1]http://elbert.its.bldrdoc.gov/itm.html
[2]http://elbert.its.bldrdoc.gov/globe.html

Written by  Wei-peng Chen, Ye Ge, Chunyu Hu, Honghai Zhang, and Rong Zheng.