Saturday 26 December 2015

Mobile Adhoc network in NS3 / (MANET Implementation in NS3)

Mobile Adhoc network in NS3 / (MANET Implementation in NS3)

INTRODUCTION

•  MANETs are typically
–  wireless
–  mobile
–  little or no reliance on infrastructure
–  communication among peers
–  limited network resources

MANET Routing Protocols in ns-3

•  AODV:  ad-hoc on demand distance vector
•  DSDV:  destination-sequenced distance vector
•  DSR:  dynamic source routing 
•  OLSR:  optimised link state routing

Ad Hoc Routing Examples

OLSR in ns-3

OlsrHelper olsr;
Ipv4StaticRoutingHelper
staticRouting;
Ipv4ListRoutingHelper list;
list.Add (staticRouting,0);
list.Add (olsr,10);
InternetStackHelper internet;
internet.SetRoutingHelper (list);
internet.Install (nodes);

AODV in ns-3

AodvHelper aodv;
InternetStackHelper stack;
stack.SetRoutingHelper (aodv);
stack.Install (nodes);
Ipv4AddressHelper address;
address.SetBase ("10.0.0.0","255.0.0.0");
address.Assign (devices);


Implementation in NS3:


#include "ns3/core-module.h"
#include "ns3/network-module.h"
#include "ns3/mobility-module.h"
#include "ns3/config-store-module.h"
#include "ns3/wifi-module.h"
#include "ns3/internet-module.h"
#include "ns3/aodv-module.h"
#include "ns3/olsr-module.h"
#include "ns3/dsdv-module.h"
#include "ns3/ipv4-static-routing-helper.h"
#include "ns3/ipv4-list-routing-helper.h"
#include "ns3/applications-module.h"
#include "ns3/netanim-module.h"
#include "ns3/constant-velocity-mobility-model.h"
#include "ns3/flow-monitor-module.h"
#include <iostream>
#include <fstream>
#include <vector>
#include <string>


NS_LOG_COMPONENT_DEFINE ("scenario");

using namespace ns3;

Ptr<ConstantVelocityMobilityModel> cvmm;
double position_interval = 1.0;
std::string tracebase = "scratch/scenario";

// two callbacks
void printPosition()
{
  Vector thePos = cvmm->GetPosition();
  Simulator::Schedule(Seconds(position_interval), &printPosition);
  std::cout << "position: " << thePos << std::endl;
}

void stopMover()
{
  cvmm -> SetVelocity(Vector(0,0,0));
}

int main (int argc, char *argv[])
{
  // Dsss options: DsssRate1Mbps, DsssRate2Mbps, DsssRate5_5Mbps, DsssRate11Mbps
  // also ErpOfdmRate to 54 Mbps and OfdmRate to 150Mbps w 40MHz band-width
  std::string phyMode = "DsssRate1Mbps";               
  //phyMode = "DsssRate11Mbps";

  int bottomrow = 20;            // number of bottom-row nodes
  int spacing = 200;            // between bottom-row nodes
  int mheight = 150;            // height of mover above bottom row
  int brheight = 50;            // height of bottom row

  int X = (5-1)*spacing+1;              // X and Y are the dimensions of the field
  //int Y = 300; a
  int packetsize = 500;
  double factor = 1.0;  // allows slowing down rate and extending runtime; same total # of packets
  int endtime = (int)100*factor;
  double speed = (X-1.0)/endtime;      
  double bitrate = 80*1000.0/factor;  // bits/sec
  uint32_t interval = 1000*packetsize*8/bitrate*1000;    // in microsec, computed from packetsize and bitrate
  uint32_t packetcount = 1000000*endtime/ interval;
  std::cout << "interval = " << interval <<", rate=" << bitrate << ", packetcount=" << packetcount << std::endl;

  CommandLine cmd;              // no options, actually
  cmd.Parse (argc, argv);

  // disable fragmentation for frames below 2200 bytes
  Config::SetDefault ("ns3::WifiRemoteStationManager::FragmentationThreshold", StringValue ("2200"));
  // turn off RTS/CTS for frames below 2200 bytes
  Config::SetDefault ("ns3::WifiRemoteStationManager::RtsCtsThreshold", StringValue ("2200"));
  // Set non-unicast data rate to be the same as that of unicast
  Config::SetDefault ("ns3::WifiRemoteStationManager::NonUnicastMode", StringValue (phyMode));

  // Create nodes
  NodeContainer fixedpos;
  fixedpos.Create(bottomrow);
  Ptr<Node> lowerleft = fixedpos.Get(0);

  // The below set of helpers will help us to put together the desired Wi-Fi behavior
  WifiHelper wifi;
  wifi.SetStandard (WIFI_PHY_STANDARD_80211b);
  wifi.SetRemoteStationManager ("ns3::AarfWifiManager"); // Use AARF rate control
  // to view AARF rate changes, set in the shell NS_LOG=AarfWifiManager=level_debug

  // The PHY layer here is "yans"
  YansWifiPhyHelper wifiPhyHelper =  YansWifiPhyHelper::Default ();
  // for .pcap tracing
  // wifiPhyHelper.SetPcapDataLinkType (YansWifiPhyHelper::DLT_IEEE802_11_RADIO);

  YansWifiChannelHelper wifiChannelHelper;              // *not* ::Default() !
  wifiChannelHelper.SetPropagationDelay ("ns3::ConstantSpeedPropagationDelayModel"); // pld: default?
  // the following has an absolute cutoff at distance > 250
  wifiChannelHelper.AddPropagationLoss ("ns3::RangePropagationLossModel", "MaxRange", DoubleValue(250));
  Ptr<YansWifiChannel> pchan = wifiChannelHelper.Create ();
  wifiPhyHelper.SetChannel (pchan);

  // Add a non-QoS upper-MAC layer "AdhocWifiMac", and set rate control
  NqosWifiMacHelper wifiMacHelper = NqosWifiMacHelper::Default ();
  wifiMacHelper.SetType ("ns3::AdhocWifiMac");
  NetDeviceContainer devices = wifi.Install (wifiPhyHelper, wifiMacHelper, fixedpos);
  devices.Add (wifi.Install (wifiPhyHelper, wifiMacHelper, mover));

  // set positions.
  MobilityHelper sessile;               // for fixed nodes
  Ptr<ListPositionAllocator> positionAlloc = CreateObject<ListPositionAllocator> ();
  int Xpos = 0;
  for (int i=0; i<5; i++) {
        positionAlloc->Add(Vector(Xpos, brheight, 0.0));
        Xpos += spacing;
  }


  sessile.SetPositionAllocator (positionAlloc);
  sessile.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
  sessile.Install (fixedpos);

  // ConstantVelocityMobilityModel is a subclass of MobilityModel
  Vector pos (0, mheight+brheight, 0);
  Vector vel (speed, 0, 0);
  MobilityHelper mobile;
  mobile.SetMobilityModel("ns3::ConstantVelocityMobilityModel");        // no Attributes
  mobile.Install(mover);
  cvmm = mover->GetObject<ConstantVelocityMobilityModel> ();
  cvmm->SetPosition(pos);
  cvmm->SetVelocity(vel);
 
  AodvHelper aodv;
  OlsrHelper olsr;
  DsdvHelper dsdv;
  Ipv4ListRoutingHelper listrouting;
  //listrouting.Add(olsr, 10);                          // generates less traffic
  listrouting.Add(aodv, 10);                            // fastest to find new routes

  InternetStackHelper internet;
  internet.SetRoutingHelper(listrouting);
  internet.Install (fixedpos);
  internet.Install (mover);

  Ipv4AddressHelper ipv4;
  NS_LOG_INFO ("Assign IP Addresses.");
  ipv4.SetBase ("10.1.1.0", "255.255.255.0");           // there is only one subnet
  Ipv4InterfaceContainer i = ipv4.Assign (devices);
 
  uint16_t port = 80;

  // create a receiving application (UdpServer) on node mover


  Address sinkaddr(InetSocketAddress (Ipv4Address::GetAny(), port));
  Config::SetDefault("ns3::UdpServer::Port", UintegerValue(port));
//-----sample
  Ptr<UdpServer> UdpRecvApp = CreateObject<UdpServer>();
  UdpRecvApp->SetStartTime(Seconds(0.0));
  UdpRecvApp->SetStopTime(Seconds(endtime));
  mover->AddApplication(UdpRecvApp);
// mover definition needed

  // Tracing
  //wifiPhyHelper.EnablePcap (tracebase, devices);

  AsciiTraceHelper ascii;
  wifiPhyHelper.EnableAsciiAll (ascii.CreateFileStream (tracebase + ".tr"));

  // create animation file, to be run with 'netanim'
  AnimationInterface anim (tracebase + ".xml");
  anim.SetMobilityPollInterval(Seconds(0.1));

  // uncomment the next line to verify that node 'mover' is actually moving
  //Simulator::Schedule(Seconds(position_interval), &printPosition);

  Simulator::Schedule(Seconds(endtime), &stopMover);
anim.UpdateNodeDescription (fixedpos.Get(0), "AP");

  FlowMonitorHelper flowmon;
  Ptr<FlowMonitor> monitor = flowmon.InstallAll();
  Simulator::Stop(Seconds (endtime+60));
  Simulator::Run ();
monitor->CheckForLostPackets ();
static double throughput =0;
static double Total_tx =0;
static double Total_rx =0;
static double delay =0;
  Ptr<Ipv4FlowClassifier> classifier = DynamicCast<Ipv4FlowClassifier> (flowmon.GetClassifier ());
  std::map<FlowId, FlowMonitor::FlowStats> stats = monitor->GetFlowStats ();
  for (std::map<FlowId, FlowMonitor::FlowStats>::const_iterator i = stats.begin (); i != stats.end (); ++i)
    {
      Ipv4FlowClassifier::FiveTuple t = classifier->FindFlow (i->first);
      if ((1))
      {
       
// QOS Measurement
     }
  Simulator::Destroy ();


      }
  return 0;
}

 OUTPUT :

 








Video:

 

Mail to nsallinone@gmail.com to get the implementation

 

 

Sunday 13 December 2015

Multimedia Data Aggregation implementation in NS2

Privacy and Quality Preserving Multimedia Data Aggregation for Participatory Sensing Systems


Introduction:


                     Abstract—With the popularity of mobile wireless devices equipped with various kinds of sensing abilities, a new service paradigm named participatory sensing has emerged to provide users with brand new life experience. However, the wide application of participatory sensing has its own challenges, among which privacy and multimedia data quality preservations are two critical problems. Unfortunately, none of the existing work has fully solved the problem of privacy and quality preserving participatory sensing with multimedia data. In this paper, we propose SLICER, which is the first k-anonymous privacy preserving scheme for participatory sensing with multimedia data. SLICER integrates a data coding technique and message transfer strategies, to achieve strong protection of participants’ privacy, while maintaining high data quality. Specifically, we study two kinds of data transfer strategies, namely transfer on meet up (TMU) and minimal cost transfer (MCT). For MCT, we propose two different but complimentary algorithms, including an approximation algorithm and a heuristic algorithm, subject to different strengths of the requirement. Furthermore, we have implemented SLICER and evaluated its performance using publicly released taxi traces. Our evaluation results show that SLICER achieves high data quality, with low computation and communication overhead.


Implementation screen shots:










CONCLUSION AND FUTURE WORK

In this paper, we have presented a coding-based privacy preserving scheme, namely SLICER, which is a k-anony-mous privacy preserving scheme for participatory sensing with multimedia data. SLICER integrates the technique of erasure coding and well designed slice transfer strategies, to achieve strong protection of participants’ private information as well as high data quality and loss tolerance, with low computation and communication overhead. We have studied two kinds of data transfer strategies, including TMU and MCT. While TMU is a simple and straightforward 
strategy, MCT contains two complimentary algorithms, including an approximation algorithm and a heuristic algorithm, designed for satisfying different levels of delivery guarantee. We also implement SLICER and evaluate its performance using publicly released taxi traces. Our evaluation 
results confirm that SLICER achieves high data quality,strong robustness, with low computation and communication overhead.

MULTI PATH TCP - MPTCP in NS3

MULTI PATH  (MPTCP) in NS3

Introduction

MultiPath TCP (MPTCP) is an effort towards enabling the simultaneous use of several IP-addresses/interfaces by a modification of TCP that presents a regular TCP interface to applications, while in fact spreading data across several subflows. Benefits of this include better resource utilization, better throughput and smoother reaction to failures

Advantages:

The redundancy offered by Multipath TCP enables inverse multiplexing of resources, and thus increases TCP throughput to the sum of all available link-level channels instead of using a single one as required by plain TCP. Multipath TCP is backwards compatible with plain TCP.

Multipath TCP is particularly useful in the context of wireless networks - using both Wi-Fi and a mobile network is a typical use case. In addition to the gains in throughput from inverse multiplexing, links may be added or dropped as the user moves in or out of coverage without disrupting the end-to-end TCP connection. The problem of link handover is thus solved by abstraction in the transport layer, without any special mechanisms at the network or link level. Handover functionality can then be implemented at the endpoints without requiring special functionality in the subnetworks - in accordance to the Internet's end-to-end principle.

Multipath TCP also brings performance benefits in datacenter environments. In contrast to Ethernet channel bonding using 802.3ad link aggregation, Multipath TCP can balance a single TCP connection across multiple interfaces.

Results:







MPTCP Concept :



 To a non-MPTCP-aware application, MPTCP will behave the same as normal TCP. Extended APIs could provide additional control to MPTCP-aware applications. An application begins by opening a TCP socket in the normal way. MPTCP signaling and operation are handled by the MPTCP implementation.

An MPTCP connection begins similarly to a regular TCP connection. This is illustrated in Figure 2 where an MPTCP connection is established between addresses A1 and B1 on Hosts A and B, respectively.

 If extra paths are available, additional TCP sessions (termed MPTCP "subflows") are created on these paths, and are combined with the existing session, which continues to appear as a single connection to the applications at both ends. The creation of the additional TCP session is illustrated between Address A2 on Host A and Address B1 on Host B.

 MPTCP identifies multiple paths by the presence of multiple addresses at hosts. Combinations of these multiple addresses equate to the additional paths. In the example, other potential paths that could be set up are A1<->B2 and A2<->B2. Although this additional session is shown as being initiated from A2, it could equally have been initiated from B1. o The discovery and setup of additional subflows will be achieved through a path management method; this document describes a mechanism by which a host can initiate new subflows by using its own additional addresses, or by signaling its available addresses to the other host.

 MPTCP adds connection-level sequence numbers to allow the reassembly of segments arriving on multiple subflows with differing network delays.

 Subflows are terminated as regular TCP connections, with a four- way FIN handshake. The MPTCP connection is terminated by a connection-level FIN.