Mixim and 802.15.4: why packet loss increase with the number of retransmissions?

[cirom]

Hi,
I am using the example ieee802154Narrow to carry out simulations. I
have built a network very simple with two nodes and I set in
config.xml file as AnalogueModel type LogNormalShadowing.
By starting the simulation but I get the results a bit strange.
In fact, in theory, by increasing the number of retransmissions should
reduce the packet loss and this is not always.
The following block of results does not make sense because the packet
loss increases with the increase of NR.

NR AvgDelay Distance α(mean) σ(devStd) PacketLoss

1 0.416138 60 2.5 50
0.65109

10 24.3285 60 2.5 50
0.686047

The next block of results show that with DevStd up to 30, the
interference is so small that the packet loss is always 0. From 35 to
43, however, the packet loss has a coherent behavior to increase of
NR.

NR AvgDelay Distance α(mean) σ(devStd) PacketLoss

1 0.103648 60 2.5 10
0

1 0.103648 60 2.5 20
0

1 0.109658 70 2.5 30
0

10 0.109658 70 2.5 30 0

1 0.130594 70 2.5 35
0.0170455

5 0.130034 70 2.5 35
0.00297619

10 0.130034 70 2.5 35
0.00297619

1 0.169926 70 2.5 39
0.0785498

5 0.209814 70 2.5 39
0.00292398

10 0.209814 70 2.5 39
0.00292398

1 0.208034 70 2.5 43
0.176119

5 0.469717 70 2.5 43
0.0460123

10 0.730156 70 2.5 43
0.00925926

with devStd=44 packet loss has always a wrong behavior.

NR AvgDelay Distance α(mean) σ(devStd) PacketLoss

1 0.22074 70 2.5 44
0.253918

5 0.545917 70 2.5 44
0.0275229

10 3.03378 70 2.5 44
0.0532915

Why do i get these results? Thanks

[Michael]

which versions of OMNeT++ and MiXiM do you use?

[cirom]

I use Omnet 4.2 and Mixim 2.2.1

The following block of results does not make sense because the packet
loss increases with the increase of NR.

NR AvgDelay Distance á(mean) ó(devStd) PacketLoss

1 0.416138 60 2.5 50 0.65109

10 24.3285 60 2.5 50 0.686047

The next block of results show that with DevStd up to 30, the
interference is so small that the packet loss is always 0. From 35 to
43, however, the packet loss has a coherent behavior to increase of
NR.

NR AvgDelay Distance á(mean) ó(devStd) PacketLoss

1 0.103648 60 2.5 10 0

1 0.103648 60 2.5 20 0

1 0.109658 70 2.5 30 0

10 0.109658 70 2.5 30 0

1 0.130594 70 2.5 35 0.0170455

5 0.130034 70 2.5 35 0.00297619

10 0.130034 70 2.5 35 0.00297619

1 0.169926 70 2.5 39 0.0785498

5 0.209814 70 2.5 39 0.00292398

10 0.209814 70 2.5 39 0.00292398

1 0.208034 70 2.5 43 0.176119

5 0.469717 70 2.5 43 0.0460123

10 0.730156 70 2.5 43 0.00925926

with devStd=44 packet loss has always a wrong behavior.

NR AvgDelay Distance á(mean) ó(devStd) PacketLoss

1 0.22074 70 2.5 44 0.253918

5 0.545917 70 2.5 44 0.0275229

10 3.03378 70 2.5 44 0.0532915

Why do i get these results? Thanks

On 20 Feb, 06:40, Michael <michael.lin...@informatik.tu-chemnitz.de>
wrote:

[Jerome Rousselot]

Hi,

you probably have packet drops at the entrance of the MAC layer. Each
packet spends more time in the MAC layer, and at some point the
arrival rate in the MAC becomes higher than your service time (rho > 1
from a queueing theory viewpoint). Real systems have a finite amount
of memory.

Increase the MAC buffer size to check if this is the problem.

Regards

Jerome

> --
> Sent from the OMNeT++ mailing list. To configure your membership,
> visit http://groups.google.com/group/omnetpp

[cirom]

What is the name of the variable that allows to increase the MAC
buffer size?
Thanks.

On 20 Feb, 15:50, Jerome Rousselot <jeromerousse...@gmail.com> wrote:
> Hi,
>
> you probably have packet drops at the entrance of the MAC layer. Each
> packet spends more time in the MAC layer, and at some point the
> arrival rate in the MAC becomes higher than your service time (rho > 1
> from a queueing theory viewpoint). Real systems have a finite amount
> of memory.
>
> Increase the MAC buffer size to check if this is the problem.
>
> Regards
>
> Jerome
>

[Michael]

The mac for the Ieee802154Narrow example is CSMA802154 (src/modules/
mac/CSMA802154.ned) which extends csma-mac (src/modules/mac/csma.ned),
here is the queue length variable defined:

double queueLength = default(100);

In the omnetpp.ini of Ieee802154Narrow example you find multiple
configurations where this variable is set:

**.mac.queueLength = 100

Hope this helps ;)
Michael

[cirom]

Thank you for reply.

To increase the MAC buffer size does not fix the problem.
The strange thing is that I get the expected behavior only with
standard deviation is between 35dB and 45dB ( which in reality are
values too high).
What other parameter can i go to change to achieve the best results?
And maybe a problem of synchronization between the nodes? It often
happens that the files are dropped before they reach maximum number of
retransmission.

Thank you.

On 21 Feb, 06:58, Michael <michael.lin...@informatik.tu-chemnitz.de>
wrote:

[Laura Marie Feeney]

It should never be the case that a frame is dropped before it reaches
the maximum number of retransmissions, regardless of the buffer size.
Once a frame is the head-of-line frame, it should run to completion
(either success or failure).

What output do you see that makes you think that frames are dropped
without being correctly retransmitted?

Laura

[cirom]

Sorry, you're right I'm wrong. Dropped packets are right.

I have experienced that increasing maximum number of transmissions,
the packet loss(calculated as (1-AckRecieved/TotalPackeSent))
increases too. Becasue for instance: taken the case of simulations
with maximum number of transmission equal to 10, the numer of ack
received is less than the case with maximum numer of transmission
equal to 1. Which could be the bug? I cannot figure it out

Thank you.

[cirom]

Can anyone help me?

[cirom]

Maybe I found the solution to the problem but I would like a
confirmation.
To apply an interference-type Log Normal Shadowing I put in the file
config.xml only model LogNormalShadowing. I do it?
Or I have to put in the file config.xml the two models
LogNormalShadowing and SimplePathlossModel together?

Also what values ​​I set to do a simulation near to reality?

Thank you so much.

[LuisTH]

Hi,

Take a look to the  LogNormalShadowning.cc in src/modules/analogueModel. This model only adds a normally distributed loss (in dB), which is translated into a corresponding gain value.  If you unse only this model then you have to supply a mean and a stdDev. Pay attention to the fact that small means with large stdDev create values of the distribution that are negative. My understanding of this function is that these values end up acting as if they were "amplifying" the received power with respect to the transmitted power.  Otherwise the model should be ok on its own.

Cascading a Pathloss just adds to the mean value of the normally distributed losses of the LogNormalShadowing an extra shift (more dB of loss) depending on the distance between sender and receiver.  Usually you find the combination of PathLoss with zero-mean log-normal shadhowing.

Regards,
Luis.


 

[Mima line]

Hi

could you please tell us how can we calculate packet loss with OMNET,?

thanks in adavance

[Thomas Menzel]

Hi,

probably the simplest would be to use a counter per node for all generated packets and one per node for all received packets. Then you can easiliy caclculate the difference between the sums.

Best
Thomas

[Hana Amira]

Hi Mr Tomas,

Thanks for the reply,

Please, how can I set a counter per node

I thought that these paramers are collected after the simulation as a statistique, could you please help me to do this,I am using the source code of VANET simulation from   https://github.com/nd6688/VANETsV2V-V2I

I am  a new bie with OMENT++, I used to use NS2 where the statistique  are extracted from the trace file with awk or perl scripts

I want to extracte other statistiques from omnet but I don't know how??

Thanks for advance

--
You received this message because you are subscribed to a topic in the Google Groups "omnetpp" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/omnetpp/dabdRf9hCLE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to omnetpp+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.