802.11s problems

[francesco calabro]

Hi guys,
as I didn't receive any reply I try to make me clearer.
I started with your mesh.cc example in the mesh folder changing the topology of the net (all nodes are all in a single row) and the type of application (see below) and setting always the last node as the source node. I set the throughput at 300kbps.
If the number of the node is >=4 (i mean the source is the third node and the sink is the node0) I'm not able to see any traffic.
Can anyone help me?
I use a ubuntu 10.4 LTS for my test.
Thanks in advance


        int m_nconn = m_xSize * m_ySize;
        int m_source, m_dest, m_dest_port;
        double start_time, stop_time, duration;
// Set the parameters of the onoff application
        Config::SetDefault ("ns3::OnOffApplication::PacketSize", UintegerValue(m_packetSize));
        Config::SetDefault ("ns3::OnOffApplication::DataRate", StringValue (m_txrate));
        ApplicationContainer apps [m_nconn];

                start_time = 1;
                duration = 15;
                stop_time=duration+start_time ;
                m_dest = 0;//rand_nodes.GetInteger (0,m_ySize*m_xSize-1);
                m_dest_port = 80;
                m_source = m_ySize*m_xSize-1;
                std::cout << "\n\t Node "<< m_source << " to " << m_dest;
                std::cout << "\n Start_time: " << start_time << "s";
                std::cout << "\n Stop_time: " << stop_time << "s\n";
// Define UDP traffic for the onoff application
                OnOffHelper onoff ("ns3::UdpSocketFactory", Address (InetSocketAddress(interfaces.GetAddress (m_dest), m_dest_port)));
                onoff.SetAttribute ("OnTime", RandomVariableValue (ConstantVariable (1)));
                onoff.SetAttribute ("OffTime", RandomVariableValue (ConstantVariable (0)));
                apps[0] = onoff.Install (nodes.Get(m_source));
                apps[0].Start (Seconds (start_time));
                apps[0].Stop (Seconds (stop_time));
// Create a packet sink to receive the packets
                PacketSinkHelper sink ("ns3::UdpSocketFactory",InetSocketAddress(interfaces.GetAddress (m_dest), 49001));
                apps[0] = sink.Install (nodes.Get (m_dest));
                apps[0].Start (Seconds (0.1));

[silviocs]

Anyways, did you set m_ySize to 1 and m_xSize to 4 (or the number of
mesh points in the line)?

On Sep 16, 11:13 am, francesco calabro <f.calabro1...@gmail.com>
wrote:

> Hi guys,
> as I didn't receive any reply I try to make me clearer.
> I started with your mesh.cc example in the mesh folder changing the topology
> of the net (all nodes are all in a single row) and the type of application
> (see below) and setting always the last node as the source node. I set the
> throughput at 300kbps.
> If the number of the node is >=4 (i mean the source is the third node and
> the sink is the node0) I'm not able to see any traffic.
> Can anyone help me?
> I use a ubuntu 10.4 LTS for my test.
> Thanks in advance
>

>  *       int m_nconn = m_xSize * m_ySize;

>                 apps[0].Start (Seconds (0.1));*

[silviocs]

Francesco,

By seeing only a fragment of your script is hard to say where is the
problem. Maybe the problem is your mobility model, for example, but in
this fragment I can see only the traffic generation. So, please, try
to post the whole script.

--Silvio

On Sep 16, 11:13 am, francesco calabro <f.calabro1...@gmail.com>
wrote:

> Hi guys,
> as I didn't receive any reply I try to make me clearer.
> I started with your mesh.cc example in the mesh folder changing the topology
> of the net (all nodes are all in a single row) and the type of application
> (see below) and setting always the last node as the source node. I set the
> throughput at 300kbps.
> If the number of the node is >=4 (i mean the source is the third node and
> the sink is the node0) I'm not able to see any traffic.
> Can anyone help me?
> I use a ubuntu 10.4 LTS for my test.
> Thanks in advance
>

>  *       int m_nconn = m_xSize * m_ySize;

>                 apps[0].Start (Seconds (0.1));*

[silviocs]

Anyways, did you set m_ySize to 1 and m_xSize to 4 (or the number of
mesh points in the line)?

On Sep 16, 11:13 am, francesco calabro <f.calabro1...@gmail.com>
wrote:

> Hi guys,
> as I didn't receive any reply I try to make me clearer.
> I started with your mesh.cc example in the mesh folder changing the topology
> of the net (all nodes are all in a single row) and the type of application
> (see below) and setting always the last node as the source node. I set the
> throughput at 300kbps.
> If the number of the node is >=4 (i mean the source is the third node and
> the sink is the node0) I'm not able to see any traffic.
> Can anyone help me?
> I use a ubuntu 10.4 LTS for my test.
> Thanks in advance
>

>  *       int m_nconn = m_xSize * m_ySize;

>                 apps[0].Start (Seconds (0.1));*

[Nuno Namorado]

Any news with this problem?
I came across the same issue. This time using a simple 3x3 grid (like
the one the example), see bellow:
* m_xSize * step
* |<--------->|
* step
* |<--->|
* 6 --- 7 --- 8 _
* | \ | / | ^
* | \ | / | |
* 3 --- 4 --- 5 m_ySize * step |
* | / | \ | |
* | / | \ | |
* 0 --- 1 --- 2 _
* ^ sink node

I use the nodes 1,2,3 and 6 to transmit UDP packets (using
UdpEchoClient and UdpEchoServer) to node 0 (sink). None of the
packets are received at the sink.
Using Proactive or Reactive configurations for HWMP.

Although, if I put all nodes transmitting to sink, then the sink
receives and echoes back the packets.
Has anyone come across this problem?

Thanks in advance,
Nuno

[roman....@googlemail.com]

I have a related problem with mesh.cc

Using the original mesh.cc from two different releases (3.12 and 3-
dev), with no alteration at all, no UDP packets are transmitted from
node 8 (echo client)to node 0 (echo server).

* 0 --- 1 --- 2
* | \ | / |
* | \ | / |

* 3 --- 4 --- 5

* | / | \ |
* | / | \ |

* 6 --- 7 --- 8

So at least on my system the original mesh.cc UDP echo application
does not work.
Flow monitor reports 901/ lost packets.

When I change the topology from 3x3 grid to a 3x1 chain, UDP echo
application does work.
Flow monitor reports 0/ lost packets.

Can anyone confirm this behavior?

I am setting up a virtual testbed, to measure aggregate throughput,
delay, packet loss etc on various sizes of grids, so the chain
topology will not be enough. Does anyone have an idea of what could be
wrong?

You will find mesh.cc in your examples directory (ns-3-dev) or src/
mesh/examples on 3.12 release.

Here is the code from 3.12 release.

--Roman

* Author: Kirill Andreev <and...@iitp.ru>
*
*
* By default this script creates m_xSize * m_ySize square grid
topology with
* IEEE802.11s stack installed at each node with peering management
* and HWMP protocol.
* The side of the square cell is defined by m_step parameter.
* When topology is created, UDP ping is installed to opposite corners
* by diagonals. packet size of the UDP ping and interval between two
* successive packets is configurable.
*
* See also MeshTest::Configure to read more about configurable
* parameters.
*/


#include "ns3/core-module.h"
#include "ns3/internet-module.h"

#include "ns3/network-module.h"
#include "ns3/applications-module.h"
#include "ns3/wifi-module.h"
#include "ns3/mesh-module.h"
#include "ns3/mobility-module.h"
#include "ns3/mesh-helper.h"
#include "ns3/flow-monitor-helper.h"

#include <iostream>
#include <sstream>
#include <fstream>

using namespace ns3;

NS_LOG_COMPONENT_DEFINE ("TestMeshScript");
class MeshTest
{
public:
/// Init test
MeshTest ();
/// Configure test from command line arguments
void Configure (int argc, char ** argv);
/// Run test
int Run ();
private:
int m_xSize;
int m_ySize;
double m_step;
double m_randomStart;
double m_totalTime;
double m_packetInterval;
uint16_t m_packetSize;
uint32_t m_nIfaces;
bool m_chan;
bool m_pcap;
std::string m_stack;
std::string m_root;
/// List of network nodes
NodeContainer nodes;
/// List of all mesh point devices
NetDeviceContainer meshDevices;
//Addresses of interfaces:
Ipv4InterfaceContainer interfaces;
// MeshHelper. Report is not static methods
MeshHelper mesh;
private:
/// Create nodes and setup their mobility
void CreateNodes ();
/// Install internet m_stack on nodes
void InstallInternetStack ();
/// Install applications
void InstallApplication ();
/// Print mesh devices diagnostics
void Report ();
};
MeshTest::MeshTest () :
m_xSize (3),
m_ySize (3),
m_step (100.0),
m_randomStart (0.1),
m_totalTime (100.0),
m_packetInterval (0.1),
m_packetSize (1024),
m_nIfaces (1),
m_chan (true),
m_pcap (false),
m_stack ("ns3::Dot11sStack"),
m_root ("ff:ff:ff:ff:ff:ff")
{
}
void
MeshTest::Configure (int argc, char *argv[])
{
CommandLine cmd;
cmd.AddValue ("x-size", "Number of nodes in a row grid. [6]",
m_xSize);
cmd.AddValue ("y-size", "Number of rows in a grid. [6]", m_ySize);
cmd.AddValue ("step", "Size of edge in our grid, meters. [100 m]",
m_step);
/*
* As soon as starting node means that it sends a beacon,
* simultaneous start is not good.
*/
cmd.AddValue ("start", "Maximum random start delay, seconds. [0.1
s]", m_randomStart);
cmd.AddValue ("time", "Simulation time, seconds [100 s]",
m_totalTime);
cmd.AddValue ("packet-interval", "Interval between packets in UDP
ping, seconds [0.001 s]", m_packetInterval);
cmd.AddValue ("packet-size", "Size of packets in UDP ping",
m_packetSize);
cmd.AddValue ("interfaces", "Number of radio interfaces used by each
mesh point. [1]", m_nIfaces);
cmd.AddValue ("channels", "Use different frequency channels for
different interfaces. [0]", m_chan);
cmd.AddValue ("pcap", "Enable PCAP traces on interfaces. [0]",
m_pcap);
cmd.AddValue ("stack", "Type of protocol stack. ns3::Dot11sStack by
default", m_stack);
cmd.AddValue ("root", "Mac address of root mesh point in HWMP",
m_root);


cmd.Parse (argc, argv);
NS_LOG_DEBUG ("Grid:" << m_xSize << "*" << m_ySize);
NS_LOG_DEBUG ("Simulation time: " << m_totalTime << " s");
}
void
MeshTest::CreateNodes ()
{
/*
* Create m_ySize*m_xSize stations to form a grid topology
*/
nodes.Create (m_ySize*m_xSize);
// Configure YansWifiChannel
YansWifiPhyHelper wifiPhy = YansWifiPhyHelper::Default ();
YansWifiChannelHelper wifiChannel = YansWifiChannelHelper::Default
();
wifiPhy.SetChannel (wifiChannel.Create ());
/*
* Create mesh helper and set stack installer to it
* Stack installer creates all needed protocols and install them to
* mesh point device
*/
mesh = MeshHelper::Default ();
if (!Mac48Address (m_root.c_str ()).IsBroadcast ())
{
mesh.SetStackInstaller (m_stack, "Root", Mac48AddressValue
(Mac48Address (m_root.c_str ())));
}
else
{
//If root is not set, we do not use "Root" attribute, because it
//is specified only for 11s
mesh.SetStackInstaller (m_stack);
}
if (m_chan)
{
mesh.SetSpreadInterfaceChannels (MeshHelper::SPREAD_CHANNELS);
}
else
{
mesh.SetSpreadInterfaceChannels (MeshHelper::ZERO_CHANNEL);
}
mesh.SetMacType ("RandomStart", TimeValue (Seconds
(m_randomStart)));
// Set number of interfaces - default is single-interface mesh point
mesh.SetNumberOfInterfaces (m_nIfaces);
// Install protocols and return container if MeshPointDevices
meshDevices = mesh.Install (wifiPhy, nodes);
// Setup mobility - static grid topology
MobilityHelper mobility;
mobility.SetPositionAllocator ("ns3::GridPositionAllocator",
"MinX", DoubleValue (0.0),
"MinY", DoubleValue (0.0),
"DeltaX", DoubleValue (m_step),
"DeltaY", DoubleValue (m_step),
"GridWidth", UintegerValue (m_xSize),
"LayoutType", StringValue
("RowFirst"));
mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
mobility.Install (nodes);
if (m_pcap)
wifiPhy.EnablePcapAll (std::string ("mp-"));
}
void
MeshTest::InstallInternetStack ()
{
InternetStackHelper internetStack;
internetStack.Install (nodes);
Ipv4AddressHelper address;
address.SetBase ("10.1.1.0", "255.255.255.0");
interfaces = address.Assign (meshDevices);
}
void
MeshTest::InstallApplication ()
{
UdpEchoServerHelper echoServer (9);
ApplicationContainer serverApps = echoServer.Install (nodes.Get
(0));
serverApps.Start (Seconds (0.0));
serverApps.Stop (Seconds (m_totalTime));
UdpEchoClientHelper echoClient (interfaces.GetAddress (0), 9);
echoClient.SetAttribute ("MaxPackets", UintegerValue ((uint32_t)
(m_totalTime*(1/m_packetInterval))));
echoClient.SetAttribute ("Interval", TimeValue (Seconds
(m_packetInterval)));
echoClient.SetAttribute ("PacketSize", UintegerValue
(m_packetSize));
ApplicationContainer clientApps = echoClient.Install (nodes.Get
(m_xSize*m_ySize-1));
clientApps.Start (Seconds (0.0));
clientApps.Stop (Seconds (m_totalTime));
}
int
MeshTest::Run ()
{
CreateNodes ();
InstallInternetStack ();
InstallApplication ();
Simulator::Schedule (Seconds (m_totalTime), &MeshTest::Report,
this);
Simulator::Stop (Seconds (m_totalTime));

//Flow Monitor trial
Ptr<FlowMonitor> monitor;
FlowMonitorHelper flowmon_helper;
monitor = flowmon_helper.InstallAll();




Simulator::Run ();

// Flow Monitor Export trial Serializing Flow Monitor output to
XML.")
monitor->SerializeToXmlFile("mesh_01_FM.xml", false, false);



Simulator::Destroy ();
return 0;
}
void
MeshTest::Report ()
{
unsigned n (0);
for (NetDeviceContainer::Iterator i = meshDevices.Begin (); i !=
meshDevices.End (); ++i, ++n)







{
std::ostringstream os;
os << "mp-report-" << n << ".xml";
std::cerr << "Printing mesh point device #" << n << "
diagnostics to " << os.str () << "\n";
std::ofstream of;
of.open (os.str ().c_str ());
if (!of.is_open ())
{
std::cerr << "Error: Can't open file " << os.str () << "\n";
return;
}
mesh.Report (*i, of);
of.close ();
}



}
int
main (int argc, char *argv[])
{
MeshTest t;
t.Configure (argc, argv);
return t.Run ();

}




On Sep 28, 1:16 am, Nuno Namorado <n.namor...@gmail.com> wrote:
> Any news with this problem?
> I came across the same issue. This time using a simple 3x3 grid (like
> the one the example), see bellow:
>  *  m_xSize * step
>  *  |<--------->|
>  *   step
>  *  |<--->|
>  *  6 --- 7 --- 8                _
>  *  | \   |   / |                ^
>  *  |   \ | /   |                |
>  *  3 --- 4 --- 5 m_ySize * step |
>  *  |   / | \   |                |
>  *  | /   |   \ |                |
>  *  0 --- 1 --- 2                _
>  *  ^ sink node
>

> I use the nodes 1,2,3 and 6 to transmitUDPpackets (using

> UdpEchoClient and UdpEchoServer) to node 0 (sink). None of the
> packets are received at the sink.
> Using Proactive or Reactive configurations for HWMP.
>
> Although, if I put all nodes transmitting to sink, then the sink
> receives and echoes back the packets.
> Has anyone come across this problem?
>
> Thanks in advance,
> Nuno
>
> On Sep 19, 11:47 am, silviocs <silvioc...@gmail.com> wrote:
>
>
>
>
>
>
>
> > Anyways, did you set m_ySize to 1 and m_xSize to 4 (or the number of
> > mesh points in the line)?
>
> > On Sep 16, 11:13 am, francesco calabro <f.calabro1...@gmail.com>
> > wrote:
>
> > > Hi guys,
> > > as I didn't receive any reply I try to make me clearer.

> > > I started with yourmesh.ccexample in the mesh folder changing the topology

> > > // DefineUDPtraffic for the onoff application

[billy Pinheiro]

The same happened with me.

Is not possible send packets between 0 -> 8 and 0 -> 4.

Im using the original mesh.cc.

2011/10/4 roman....@gmail.com <roman....@googlemail.com>

--
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To post to this group, send email to ns-3-...@googlegroups.com.
To unsubscribe from this group, send email to ns-3-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ns-3-users?hl=en.

[street]

Hello Everyone,

I want to measure delay and packet loss in wireless mesh network.
I am currently using NS3 version 3.12. Will any one tell me how can I
measure them.


On Oct 4, 6:15 pm, "roman.sei...@gmail.com"

> * Author: Kirill Andreev <andr...@iitp.ru>

> > Although, if I put all...
>
> read more »

[roman....@googlemail.com]

@street:

It is fairly easy following ns3 flow monitor howto and using code from
examples/wireless/wifi-hidden-terminal.cc

Flow Monitor Howto:
http://telecom.inescn.pt/~gjc/flowmon-presentation.pdf

Please see MeshTest::Run (), of above quoted code, how it is done.

---

@Everyone:
However the issue remains, I can reproduce the same behaviour with TCP
CBR and UDP CBR.

Any suggestion on how this issue can be solved or is it a known bug?


--Roman

> >           std::cerr...
>
> read more »

[billy Pinheiro]

Hello guys,

I made a lot of  experiments with the mesh.cc.

I tried a 2x2 scenery and i'm not enable to send packets between node 0 and node 3.

 0 ------- 100m ---- 1
 |                        |
 |                        |
100m               100m
 |                        |
 |                        |
 2 -------100m -----3


But... if i put another node, at the position x=80m,y=80

 0 ------- 100m ----- 1
 |              |           |
 |             80m      |
100m        |       100m
 |-----80m--4         |
 |                        |
 2 -------100m ------3
 

The traffic between 0 and 3 works!!! Looks like some propagation problem.... 

I dont believe  that just 2 people have found this problem :(

2011/10/5 roman....@gmail.com <roman....@googlemail.com>

>
> read more »

[roman....@googlemail.com]

Hello Everyone,

I have studied the pcap files in wireshark (1.3.2 80211s patched) and
found, that node 3 in below scenario sends out an ARP request in order
to find the IP address of node 0.

Node 3 does so at simulation time 0.999957, 1.999957 and 2.999957
(seconds).
Node 1 and node 2 forward the ARP request at precisely the SAME time
at 1.000000, 2.000000, 3.000000 (seconds).

Node 0 never receives any of the three ARP packets.

This might be a collision problem paired with the fact, that at the
beginning of the simulation ARP tables are empty.

Any suggestions how to solve this?

--R

On Oct 5, 2:31 pm, billy Pinheiro <haquiti...@gmail.com> wrote:
> Hello guys,
>
> I made a lot of  experiments with the mesh.cc.
>
> I tried a 2x2 scenery and i'm not enable to send packets between node 0 and
> node 3.
>

>  *0* ------- 100m ---- *1*
>  |                        |
>  |                        |
> 100m               100m
>  |                        |
>  |                        |
>  *2* -------100m ----*-3*

>
> But... if i put another node, at the position x=80m,y=80
>

> * 0* ------- 100m ----- *1*
>  |              |           |
>  |             80m      |
> 100m        |       100m
>  |-----80m--*4*         |
>  |                        |
> * 2* -------100m -----*-3*

>
> The traffic between 0 and 3 works!!! Looks like some propagation
> problem....
>
> I dont believe  that just 2 people have found this problem :(
>

> 2011/10/5 roman.sei...@gmail.com <roman.sei...@googlemail.com>

> ...
>
> read more »

[Sergio Mtnez]

Hello,

As you say, nodes 1 and 2 will start re-transmitting  the ARP packet at the same time, then the will collide. To avoid that you need to change the position of the nodes to be slightly different, I think that something like 0,90 and 110,0 will be enough. You can also change the PropagationDelayModel from "ConstantVelocityPropagationModel" to "RandomPropagationDelayModel".

2011/10/6 roman....@gmail.com <roman....@googlemail.com>

> ...
>
> read more »

--
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To post to this group, send email to ns-3-...@googlegroups.com.
To unsubscribe from this group, send email to ns-3-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ns-3-users?hl=en.

--
Eng. Sergio Martínez Tornell

Universidad Politécnica de Valencia.

Spain

[roman....@googlemail.com]

Thx Sergio for the advice.

I have done some further experiments.

1. I changed the propagation delay from constant speed to random,
using following code, prior to creating the wifi channel.

<code>
wifiChannel.SetPropagationDelay
("ns3::RandomPropagationDelayModel","Variable",RandomVariableValue
(UniformVariable(0,1)));
</code>

Does anyone have a working propagation delay setup? The rest of the
physical properties are kept default.

But this results in malformed packets and no useful communication at
all.

2. I changed the position of node 2, moved it closer to the center by
10 (y-10, x+10).

This has no effect on the propagation, both node 2 and node 1 receive
the ARP request at exactly 0.999957 and forward it at 1.000000 etc.


--Roman

On Oct 7, 9:11 am, Sergio Mtnez <sertin...@gmail.com> wrote:
> Hello,
>
> As you say, nodes 1 and 2 will start re-transmitting  the ARP packet at the
> same time, then the will collide. To avoid that you need to change the
> position of the nodes to be slightly different, I think that something like
> 0,90 and 110,0 will be enough. You can also change the PropagationDelayModel
> from "ConstantVelocityPropagationModel" to "RandomPropagationDelayModel".
>

> 2011/10/6 roman.sei...@gmail.com <roman.sei...@googlemail.com>

> ...
>
> read more »

[roman....@googlemail.com]

Hi,

The RandomPropagationDelay method seems to generate a delay in
seconds.
Default is between 0 and 1 second.

After some experiments I have found a random delay range of 0-0.000011
seconds (11 micro seconds) to be most useful.
With this setting I have least packet malformation and the hidden
terminal problem seems to be solved on a grid position allocation.
Node 2,4,8 can now transmit to node 0.

I used the following setting:

<code>
wifiChannel.SetPropagationDelay
("ns3::RandomPropagationDelayModel","Variable",RandomVariableValue

(UniformVariable(0,0.000011)));
</code>

However this seems quite random to me, what do you think?

Thanks again,

--Roman

On Oct 7, 3:49 pm, "roman.sei...@gmail.com"

> > > > > It is fairly easy followingns3flow monitor howto and using code from

> > > > > examples/wireless/wifi-hidden-terminal.cc
>
> > > > > Flow Monitor Howto:
> > > > >http://telecom.inescn.pt/~gjc/flowmon-presentation.pdf
>
> > > > > Please see MeshTest::Run (), of above quoted code, how it is done.
>
> > > > > ---
>
> > > > > @Everyone:
> > > > > However the issue remains, I can reproduce the same behaviour with TCP
> > > > > CBR and UDP CBR.
>
> > > > > Any suggestion on how this issue can be solved or is it a known bug?
>
> > > > > --Roman
>
> > > > > On Oct 4, 8:39 pm, street <srtr...@gmail.com> wrote:
> > > > > > Hello Everyone,
>
> > > > > > I want to measure delay and packet loss in wireless mesh network.

> > > > > > I am currently usingNS3version 3.12. Will any one tell me how can I

> > > > > > measure them.
>
> > > > > > On Oct 4, 6:15 pm, "roman.sei...@gmail.com"
>
> > > > > > <roman.sei...@googlemail.com> wrote:
> > > > > > > I have a related problem withmesh.cc
>

> > > > > > > Using the originalmesh.ccfrom two different releases (3.12 and 3-

> > > > > > > dev), with no alteration at all, no UDP packets are transmitted
> > > from
> > > > > > > node 8 (echo client)to node 0 (echo server).
>
> > > > > > >  *  0 --- 1 --- 2
> > > > > > >  *  | \   |   / |
> > > > > > >  *  |   \ | /   |
> > > > > > >  *  3 --- 4 --- 5
> > > > > > >  *  |   / | \   |
> > > > > > >  *  | /   |   \ |
> > > > > > >  *  6 --- 7 --- 8
>

> > > > > > > So at least on my system the originalmesh.ccUDP echo application

> > > > > > > does not work.
> > > > > > > Flow monitor reports 901/ lost packets.
>
> > > > > > > When I change the topology from 3x3 grid to a 3x1 chain, UDP echo
> > > > > > > application does work.
> > > > > > > Flow monitor reports 0/ lost packets.
>
> > > > > > > Can anyone confirm this behavior?
>
> > > > > > > I am setting up a virtual testbed, to measure aggregate throughput,
> > > > > > > delay, packet loss etc on various sizes of grids, so the chain
> > > > > > > topology will not be enough. Does anyone have an idea of what could
> > > be
> > > > > > > wrong?
>

> > > > > > > You will findmesh.ccin your examples directory (ns-3-dev) or src/

> > > > > > >  ...
>
> read more »

[Kirill Andreev]

Hi!

This seems to be a problem of Wifi medium access methods.
This effect is caused by the following reasons:
1. IEEE 802.11 s does not specify any jitters for outgoing data/
management frames.
2. DCF starts to access the medium immediately if there is no activity
in the past.
3. The first frame in the mesh network (as ussialy) is an ARP request,
which is broadcast. And all retranslations of ARP request are broken
due to immediate access to the medium

This is the answer why your simulation works well in a chain topology
but does not work in 3x3 grid.
So, processing delays must be taken into account
Possible solution is to introduce processing delay to net-device
(which is much longer than propagation delay in all real systems).
Each net device may have a queue and packets are dequeued with some
relatively small time-interval between each dequeue event.
Now, there are no processing delays and neighbor stations are
completely synchronized, which (coupled with multiple retranslations)
kills medium access performance in complex topology.

On 11 окт, 07:46, "roman.sei...@gmail.com"

> > > > > > > >   m_stack ("ns3::Dot11sStack"),...
>
> продолжение »

[roman....@googlemail.com]

Hi,

Thank you for the insight.

I have found some new problems, this entry is a bit long, due to
details, sorry for that.
I have dropped the random propagation delay in physical layer, since
this seems to make little sense to me.

Again lets assume the following scenario.

2-----3
| |
| |
0-----1

Node 0 is UDP CBR sink. Packet size is 128kbyte, data rate 10kbit/s
(initially).
Source applications are installed on node 1,2 and 3.

Application start times as follows:
sink: 0.00000
source: 0.50000 (To ensure, that 802.11s peer management is completed
at first.)

I have tried the following now, with mixed results.

---

FIRST: According the discussion between you and Mathieu Lacage ...

http://groups.google.com/group/ns-3-users/browse_thread/thread/8eee8cf883e79981/cb8c8ecd7f30b605?lnk=gst&q=random+delay#cb8c8ecd7f30b605

The Idea according to Mathieu, as far as I understand it, is if the
medium is already in use by some neighboring nodes, the ARP broadcast
by node 3 will less likely be rebroadcasted at the same time by node 2
and node 1. Therefore no collision should occur.

... I have (very rudimentary) changed src/network/helper/application-
container.cc, by adding the following code.

//---------------------------------------------------
void
ApplicationContainer::QueuedStart (Time start)
{
for (Iterator i = Begin (); i != End (); ++i)
int j = 0;
{
++j;
Ptr<Application> app = *i;
app->SetStartTime (start+(MilliSeconds(j * 100)));
}
}
//---------------------------------------------------

This procedure starts every source application with an interval of 0.1
seconds (100 milli seconds).
(Some declarations in application-container.h also necessary.)

Result1:
1. Node 1 starts source application, ARP request successful, UDP
transmission successful -> medium busy at 10kbps by node 1.
2. Node 2 starts source application, ARP request successful, UDP
transmission successful -> medium busy at 10kbps by node 2.
3. Node 3 starts source application, ARP request is rebroadcast-ed by
node 1 and node 2 at precisely the same time -> collision -> UDP
transmission unsuccessful.

I guess the medium was not busy enough. -> I changed the CBR data rate
from 10 kbps to 512 kbps.

Result2:

Node 1 successful transmission of UDP packets to node 0.
Node 2 ARP request not successful, node 0 (sink) never receives any of
the 4 requests, no transmission.
Node 3 ARP request not successful, node 2 or node 3 never receive any
of the requests, no rebroadcast, no transmission.

This seems to be a similar, but slightly different problem.

2
|
|
0=====1

While node 1 uses up a lot of the medium time (====), node 2 seems to
starve (----), meaning it cannot reach node 0.

I assume the following:
Node 2 cannot hear node 1 and vice versa.
Node 0 sends 14byte ACK packets to node 1, to acknowledge the
reception of UDP packets, when it senses an idle medium.
Node 3 can only sense an idle medium, if node 0 is currently not
sending an ACK packet to node 1.
Node 1 can only sense an idle medium, if node 0 is currently not
sending an ACK packet to node 1. (node 4 source application starts
later -> irrelevant).

Node 2 sends the ARP request at the same time as node 1 sends its UDP
packet. -> collision -> hidden terminal problem.

Proof:
node 1 sends a UDP packet of 204 bytes at simulation time 0.620243.
node 2 sends an ARP request of 76 bytes at simulation time 0.620243.

With a previously established UDP connection this would simply result
in packet loss, but with ARP involved this prevents node 2 to
establish a UDP connection in the first place.

Question: How is 802.11s supposed to deal with the hidden terminal
problem in the first place?
In Draft 8.0 from December 2010, I can only find a specification for
beacon collision avoidance with hidden terminals, but nothing for data
packets. Any idea?

---

SECOND: According to Kirill Andreev, a processing delay on nodes could
solve the problem, if randomized and longer than propagation delay.

-> CBR data rate reset to 10kbps, queued application start maintained.

I introduced a queuing delay in src/wifi/model/mac-rx-middle.cc, of
this sort.

void
MacRxMiddle::Receive (Ptr<Packet> packet, const WifiMacHeader *hdr)
{
...
//---------------------------------------------------
WifiMacHeader tmpHdr = *hdr;
m_delayQueue.push_back(std::make_pair(agregate->Copy(), tmpHdr));
Simulator::Schedule (MicroSeconds(m_rng->GetNext(43,53)),
&MacRxMiddle::ForwardUpFromQueue, this);
//---------------------------------------------------
...
}

//---------------------------------------------------
void
MacRxMiddle::ForwardUpFromQueue(void)
{
m_callback (m_delayQueue[0].first, &m_delayQueue[0].second);
m_delayQueue.erase(m_delayQueue.begin() );
}
//---------------------------------------------------

There is some more code, like including random-stream.h, definition of
m_rng and details in mac-rx-middle.h

This workaround is from Hannelore Schi (also active in this group), it
has been kindly provided to me by Michele Segata (thank you). Please
ask Hannelore if you would like to use it.

Notice the random delay of 43-53 microseconds. I have tested various
values, but none below 44 micro seconds will have an effect.

This is due to the fact that the processing delay of a rebroadcast of
an ARP packet originally transmitted by node 3, at both node 1 and
node 2 is 0,000043 (43 microseconds).

The effective pseudo processing delay, by delaying the packet queuing
at mac level is therefore between 0 and 10 microseconds.

Result 1 (10kbps CBR data rate): All nodes successfully establish a
UDP connection. (rejoice!)
Result 2 (512kbps CBR data rate): Only node 1 successful, node 2 ARP
collides with node 1 UDP packet at 0.720243 similar tothe problem in
FIRST.

As for node 3, the ARP packet is sent out at 0.720059, but no obvious
collision happens at and around that time, still neither node 2
receives it, nor node 1.

The random queuing delay of 0-10 micro seconds at mac level seems, for
SOME SITUATIONS and combined with non simultaneous source application
start, to solve the problem of ARP rebroadcast collision.

Thank you everybody for your help with this issue, I am a bit closer
to the solution.

Still I consider this behavior a problem, since I cannot reliably set
up CBR application to conduct comparable experiments on metrics such
as throughput, delay, packet loss etc.

regards,

-R

> > > > > > > > >   double  ...
>
> read more »

[Andrew B.]

Has there been any further updates or solutions to this problem?  The default 3x3 mesh in the mesh.cc example is still not sending any data, and it looks like the tickets are still open, so I'm assuming that this is still relevant.

[roman....@googlemail.com]

No, as far as I know, the problem persists in current ns3 version.

I solve the issue (partially) by delaying packets in mac-rx-middle.cc for 1-10 micro seconds.

regards,

-R

[Ernesto Carrillo]

I am working with the mesh.cc code and, as far as I understand the discussion, there is a sync problem that causes the ARP rebroadcast collision. According with roman...@googlemail.com,  delaying packets in mac-rx-middle.cc for 1-10 micro seconds might alleviate the problem. I would like to know if you could post all the definitions required to run the code that Hannelore Schi  proposed:

void
MacRxMiddle::Receive (Ptr<Packet> packet, const WifiMacHeader *hdr)
{
...
        //--------------------

-------------------------------
        WifiMacHeader tmpHdr = *hdr;
        m_delayQueue.push_back(std::make_pair(agregate->Copy(), tmpHdr));
        Simulator::Schedule (MicroSeconds(m_rng->GetNext(43,53)),
&MacRxMiddle::ForwardUpFromQueue, this);
        //---------------------------------------------------
...
}

//---------------------------------------------------
void
MacRxMiddle::ForwardUpFromQueue(void)
{
        m_callback (m_delayQueue[0].first, &m_delayQueue[0].second);
        m_delayQueue.erase(m_delayQueue.begin() );
}
//---------------------------------------------------

Thanks in advance

Ernesto