To simulate the Fisheye State Routing (FSR) protocol in NS2 has includes setting up the routing protocol, generating a network topology, and creating traffic for the simulation. FSR is a proactive, link-state routing protocol intended for mobile ad hoc networks (MANETs). It minimizes overhead by interchanging link-state information with diverse frequencies, rely on the distance of the nodes. Nodes closer to a specified node obtain more repeated updates, since distant nodes get fewer updates.
Since NS2 does not contain FSR by default, we can execute or replicate it by following this guide.
Steps to Simulate FSR Protocol Projects Using NS2
- Set up NS2
Make sure that NS2 is installed on the system. We want a patched version of NS2 if FSR isn’t encompassed by default. NS2 extensions or custom implementations of FSR also be available, that can incorporate to NS2.
- Understand FSR Protocol
FSR operates by maintaining a link-state table in every node. But, instead of flooding the complete network frequently, FSR updates the neighbours’ link-state information with diverse granularities:
- Fisheye Scope: Nodes within a close range receive frequent updates, while distant nodes receive updates less frequently.
- This minimizes overhead, especially in large, mobile networks.
- Implement or Use FSR in NS2
If NS2 does not already support FSR, we can attempt to identify or execute a custom version of FSR. We also expand the existing proactive protocols such as OLSR or DSDV to implement FSR’s update frequency characteristics.
- TCL Script for Simulating FSR Protocol in NS2
Here is an instance TCL script that replicates a MANET using the FSR protocol (if implemented or patched) or another proactive protocol by the way of a substitute.
Example TCL Script for FSR Protocol Simulation
# Create a simulator object
set ns [new Simulator]
# Define network parameters
set topo [new Topography]
$topo load_flatgrid 500 500
# Open files for tracing and NAM visualization
set tracefile [open fsr.tr w]
$ns trace-all $tracefile
set namfile [open fsr.nam w]
$ns namtrace-all-wireless $namfile 500 500
# Define the wireless channel with Two-Ray Ground propagation model
set chan_1_ [new Channel/WirelessChannel]
set prop [new Propagation/TwoRayGround]
set netif [new Phy/WirelessPhy]
set mac [new Mac/802_11]
set ll [new LL]
set ifq [new Queue/DropTail/PriQueue]
set antenna [new Antenna/OmniAntenna]
# Define routing protocol as FSR (if implemented or patched)
set adhocRouting FSR
# Node configuration
$ns node-config -adhocRouting $adhocRouting \
-llType $ll \
-macType $mac \
-ifqType $ifq \
-ifqLen 50 \
-antType $antenna \
-propType $prop \
-phyType $netif \
-channel $chan_1_ \
-topoInstance $topo \
-agentTrace ON \
-routerTrace ON \
-macTrace ON
# Create mobile nodes
set num_nodes 10
for {set i 0} {$i < $num_nodes} {incr i} {
set node($i) [$ns node]
}
# Set node positions (you can adjust positions to simulate different topologies)
$node(0) set X_ 100.0
$node(0) set Y_ 100.0
$node(1) set X_ 200.0
$node(1) set Y_ 200.0
$node(2) set X_ 300.0
$node(2) set Y_ 300.0
# Define other node positions as required…
# Mobility model for dynamic scenarios
for {set i 0} {$i < $num_nodes} {incr i} {
$ns at 0.0 “$node($i) setdest 100 200 10”
}
# Create a TCP agent and attach it to node 0
set tcp0 [new Agent/TCP]
$ns attach-agent $node(0) $tcp0
# Create a TCP sink agent and attach it to node 9
set sink0 [new Agent/TCPSink]
$ns attach-agent $node(9) $sink0
# Connect the TCP agent and sink agent
$ns connect $tcp0 $sink0
# Create FTP application over TCP and start generating traffic
set ftp [new Application/FTP]
$ftp attach-agent $tcp0
$ns at 1.0 “$ftp start”
$ns at 10.0 “$ftp stop”
# Define simulation end time
$ns at 15.0 “finish”
# Finish procedure to close files
proc finish {} {
global ns tracefile namfile
$ns flush-trace
close $tracefile
close $namfile
exec nam fsr.nam &
exit 0
}
# Run the simulation
$ns run
- Explanation of the Script
- Simulator Setup: Generates an NS2 simulator instance and describes the trace and NAM files to log the simulation events.
- Node Creation: Set up a number of mobile nodes. Positions of the nodes are defined statically; however we can adapt them according to your requirements.
- Routing Protocol: The script adopts that FSR is available (if implemented or patched), and it set up the simulation to utilize FSR as the routing protocol.
- TCP Traffic Generation: Generates a TCP agent attached to node 0, and node 9 perform as the TCP sink. An FTP application creates traffic over the TCP connection.
- Mobility: we need to utilize the setdest command to move nodes around the simulation area, establishing node mobility.
- Simulation End: The simulation executes for 15 seconds, and at the end, trace files are flushed, and NAM visualization begins.
- Running the Simulation
Save the above script as fsr_simulation.tcl and execute it using NS2 with the following command:
ns fsr_simulation.tcl
- Analysing the Results
- NAM Visualization: Open the .nam file in NAM (Network Animator) to envision the network topology and the movement of packets:
nam fsr.nam
- Trace File Analysis: The .tr file records all events in the simulation. We can measure this file using AWK or Python scripts to extract parameters like:
- Packet delivery ratio
- End-to-end delay
- Routing overhead
- Throughput
- Performance Metrics
For FSR or any proactive routing protocol, typical parametric that contain:
- Packet Delivery Ratio (PDR): The ratio of packets successfully delivered to the destination versus those sent.
- End-to-End Delay: The average delay taken by data packets to reach their destination.
- Routing Overhead: The amount of control packets (routing updates) created by the protocol.
- Throughput: The number of data successfully routed over the network.
- Advanced FSR Implementation
If we need to execute FSR from scratch or adapt existing protocols, follow these steps:
- Modify Routing Tables: Execute source-based routing in which link-state tables are updated using the fisheye approches (more frequent updates for nearby nodes).
- Packet Handling: Make sure that the routing protocol manages link-state advertisements differently for close and far nodes.
- C++ Implementation: Adapt or expand the C++ source files in NS2 to manage FSR-specific operations. The changes would usually include the routing agent and the link-state table updates.
As we demonstrated about the simulation procedures that were utilized to simulate the Fisheye State Routing using ns2 tool and it contains the essential information like step-by step procedure, explanation and extension for the simulation and the example snippets to complete the implementation process. If you need more details then feel free to ask us.
Contact phdprime.com to provide your information, and we assure you of outstanding FSR Protocol Projects, accompanied by support on NS2 simulation. We deliver top-notch technical guidance along with a concise explanation.
