Mixim: nodes do not always answer

[a...@cs.nott.ac.uk]

Hello there,

i have got stuck with my simulation and I cannot figure out what is the
problem! I am running a simulation with more than 152 mobile and fixed
nodes by using Mixim in which nodes simply broadcast a message and the
receivers will reply to the sender with "reply_message". I am using
CSMAMacLayer, BaseNetwLayer, BurstApplLayer and BonnMotionMobility. Some
settings SNRThresholdDecider = 0 SimplePathlossModel = 2

baseSim.connectionManager.pMax = 1mW
baseSim.connectionManager.sat = -77dBm
baseSim.connectionManager.alpha = 2
baseSim.connectionManager.carrierFrequency = 2.412e+9Hz

If I run a simulation with just 3 fixed nodes close enough to be able to
communicate then they are all the time in contact. But the same nodes in
the same position in a wider context with more nodes involved in the
scenario sometime it happens the 3 nodes do not reply to the message. Can
the number of nodes involved affect their reply???

Please, let me know if you have any clue!

Thanks,
Adriano

This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

[Andreas Köpke]

How many nodes send messages? Just one?

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

[a...@cs.nott.ac.uk]

25 nodes send a message starting at a certain time (and again every
134seconds) Nodes that receive the message (including the 25 nodes) reply
to the sender.

[Andreas Köpke]

You might want to increase the maxTxAttempts parameter: the MAC simply drops a
message when it can not access the channel after trying it for maxTxAttempts
-- a likely case in your scenario.

[a...@cs.nott.ac.uk]

maxTxAttempts is 50 and it is the same.

Here below some further settings:

################ PhyLayer parameters #####################
baseSim.node[*].nic.phy.usePropagationDelay = false
baseSim.node[*].nic.phy.useThermalNoise = false

baseSim.node[*].nic.phy.timeRXToTX = 0.00021s
baseSim.node[*].nic.phy.timeRXToSleep = 0.000031s

baseSim.node[*].nic.phy.timeTXToRX = 0.00012s
baseSim.node[*].nic.phy.timeTXToSleep = 0.000032s

baseSim.node[*].nic.phy.timeSleepToRX = 0.000102s
baseSim.node[*].nic.phy.timeSleepToTX = 0.000203s

baseSim.node[*].nic.phy.sensitivity = -100dBm

# Max transmission power [mW]
baseSim.node[*].nic.phy.maxTXPower = 100.0mW

baseSim.node[*].nic.phy.initialRadioState = 0

################ MAC layer parameters ####################
#length of the MAC queue
baseSim.node[*].nic.mac.queueLength = 50
# header length
baseSim.node[*].nic.mac.headerLength = 24
#how long is a slot? [s]
baseSim.node[*].nic.mac.slotDuration = 0.04s
#maximum time between a packet and its ack [s]
baseSim.node[*].nic.mac.difs = 0.0005s
#maximum number of transmission attempts
baseSim.node[*].nic.mac.maxTxAttempts = 50

baseSim.node[*].nic.mac.defaultChannel = 0
# bitrate [bits/s]
baseSim.node[*].nic.mac.bitrate = 15360bps
#contention window
baseSim.node[*].nic.mac.contentionWindow = 20
# transmission power [mW]
baseSim.node[*].nic.mac.txPower = 100mW # [mW]

baseSim.node[*].appl.burstSize = 1
###############################################

On Nov 24 2009, Andreas Köpke wrote:

> You might want to increase the maxTxAttempts parameter: the MAC simply
> drops a message when it can not access the channel after trying it for
> maxTxAttempts