How to Implement Network Mobile Sink Location in NS2

To implement the mobile sink location using the NS2 (Network Simulator 2), which encompasses simulating the movement of a mobile sink node and make sure that the rest of the network is aware of its place for routing and the data collection. It is specifically vital within the Wireless Sensor Networks (WSNs) in which mobile sinks are used to collect the data from static sensor nodes, performance by minimising energy consumption, and enhancing network lifetime. We provide the implementation process to execute mobile sink location in NS2:

Key Aspects of Mobile Sink Implementation:

  1. Node Mobility: We want to describe a mobility model for the sink node to replicate its movement.
  2. Location Advertisement: The mobile sink must advertise its location or periodically broadcast so as to sensor nodes can update their routes or redirect data.
  3. Routing to Mobile Sink: These routing protocol would be aware of the sink’s mobility and update routes consequently.

Step-by-Step Guide to Implementing Mobile Sink Location in NS2

  1. Define the Mobile Sink in the Network

In the simulation environment NS2, a mobile sink is just a mobile node which moves via the network and also perform as the end for data collection. These sink can move based on the predefined mobility pattern.

Tcl Script Example for Defining a Mobile Sink:

# Create a simulator

set ns [new Simulator]

# Create a mobile sink node

set sink [$ns node]

# Create static sensor nodes

set node1 [$ns node]

set node2 [$ns node]

# Define the mobility model for the mobile sink

$sink setdest 50.0 50.0 1.0  ;# Move the sink to (50, 50) at a speed of 1.0 m/s

$sink setdest 100.0 100.0 1.5  ;# Move the sink to (100, 100) at a speed of 1.5 m/s

Above script moves the mobile sink from one location to another over time. We can be used various mobility models such as Random Waypoint, Random Walk, or custom trajectories.

  1. Set up a Mobility Model for the Mobile Sink

We can be used the NS2’s setdest command to describe a path for the mobile sink, or we may state that the custom mobility model using a C++ extension if we require more difficult movement patterns.

  1. Advertise the Mobile Sink’s Location

For the network to understand in which the sink is placed at any point in time, the sink requires to broadcast its location periodically. The sensor nodes can use this data to bring up-to-date their routes or transfer the data to the new location of the sink.

We can execute this by:

  • Changing the routing protocol to manage mobile sinks like AODV or DSR.
  • Making a location advertisement packet, which the sink broadcasts periodically.

Example Tcl Code for Broadcasting Sink Location:

# Function to broadcast the sink’s location periodically

proc broadcast_sink_location {} {

global sink ns

# Broadcast the current location of the mobile sink

set xpos [$sink set X_]

set ypos [$sink set Y_]

puts “Broadcasting sink location: $xpos $ypos”

# Schedule the next broadcast

$ns at [expr [$ns now] + 5.0] “broadcast_sink_location”

}

# Start broadcasting sink location at the beginning of the simulation

$ns at 1.0 “broadcast_sink_location”

This function transmissions the sink’s location at every 5 seconds and also updates their sensor nodes with the novel position.

  1. Routing to the Mobile Sink

To make certain that the sensor nodes are transfer their information to the mobile sink, we should alter the routing protocol to update the routes while the sink modifies its position.

Modify Routing Protocol (AODV Example):

In a routing protocol such as AODV, we can change the path routes are maintained by:

  • We store the mobile sink’s position in the routing table.
  • Modernising the route while the sink promotes a new location.

The following is a simple idea of what the routing modification may look like in the C++ code for AODV:

void AODV::recvSinkLocationUpdate(Packet *p) {

struct hdr_ip *ih = HDR_IP(p);

struct hdr_sink_location *sl = HDR_SINK_LOCATION(p)

// Update the routing table with the new sink location

rt_entry *rt = rtable.rt_lookup(sl->sink_id);

if (rt == 0) {

rt = rtable.rt_add(sl->sink_id);

}

// Update the routing table entry with the new location

rt->rt_sink_x = sl->sink_x;

rt->rt_sink_y = sl->sink_y;

rt->rt_sink_last_update = CURRENT_TIME;

}

In these case, the custom packet header hdr_sink_location which comprises the mobile sink’s coordinates and ID. The routing table is modernised to reflect the sink’s new location when the sink transmits its position.

  1. Create a Custom Packet for Sink Location Updates

We can describe a custom packet type to take the sink’s location data. These packet will transmit periodically by the sink, and also the sensor nodes will be used it to update their routes.

Example Custom Packet Header Definition:

#define HDR_SINK_LOCATION(p)   hdr_sink_location::access(p)

struct hdr_sink_location {

nsaddr_t sink_id;  // Sink node ID

double sink_x;     // Sink X-coordinate

double sink_y;     // Sink Y-coordinate

static int offset_;

inline static hdr_sink_location* access(const Packet* p) {

return (hdr_sink_location*) p->access(offset_);

}

};

This custom packet will take the mobile sink’s location and we can use by sensor nodes to modernise their routing tables.

  1. Implement Location-Aware Routing (Optional)

To enhance the network, we can execute the location-aware routing that nodes are choose the routes according the distance to the sink or its predicted movement pattern.

  • Greedy Geographic Forwarding: These nodes are send packets to the next hop, which is nearest to the sink’s predicted location.
  • Mobility-Aware Routing: Nodes are expect the sink’s movement and the route packets consequently to prevent the routing failures because of mobility.
  1. Simulation and Performance Metrics

When the mobile sink and routing modifications are executed, then replicate the network and gather the metrics like:

  • Energy Consumption: How much energy is rescued by using a mobile sink against a static sink.
  • Packet Delivery Ratio: The percentage of packets effectively delivered to the sink.
  • Latency: How rapidly data attains the mobile sink.
  • Route Stability: How frequently routes to the sink require to be updated.

We can use the NS2’s trace files to evaluate these metrics and compare various situations like static vs. mobile sink.

  1. Sample Tcl Script for a Mobile Sink in a WSN

# Create a simulator instance

set ns [new Simulator]

# Create mobile sink and sensor nodes

set sink [$ns node]

set node1 [$ns node]

set node2 [$ns node]

# Define movement for the mobile sink

$sink setdest 100.0 100.0 1.0

$sink setdest 200.0 200.0 1.5

# Define traffic from nodes to the mobile sink

set udp1 [new Agent/UDP]

set null1 [new Agent/Null]

$ns attach-agent $node1 $udp1

$ns attach-agent $sink $null1

$ns connect $udp1 $null1

set cbr [new Application/Traffic/CBR]

$cbr attach-agent $udp1

$cbr set packetSize_ 512

$cbr set interval_ 0.1

$ns at 1.0 “$cbr start”

# Broadcast sink location periodically

proc broadcast_sink_location {} {

global sink ns

set xpos [$sink set X_]

set ypos [$sink set Y_]

puts “Sink location: $xpos $ypos”

$ns at [expr [$ns now] + 5.0] “broadcast_sink_location”

}

# Start broadcasting the location

$ns at 1.0 “broadcast_sink_location”

# Run the simulation

$ns run

In conclusion, we completely demonstrated the simple method including some examples to implement and setup the Network Mobile Sink in the simulation environment NS2. We plan to provide more details regarding this topic in various tool.

ns2project.com provide you best customized implementation assistance with Network Mobile Sink Location in NS2guidance and project ideas. Stay in touch with us to receive the best guidance and results. Our researchers will perform the best performance analysis possible, so please share all of your project details with us for the best implementation.