End-to-End delay in inetmanet (IEEE 802.15.4)

[mohammad nekooei]

I am running a test in IEEE 802.15.4 in inetmanet 2.0. However, the average end to end delay dose not show reasonable results. When there are two sensors, the average end to end delay is about 0.5s. But when I  increase the number of nodes in the network, the average end-to-end delay decreases instead of increasing and reaches about 0.2s! Also I set **.mac.BO= 8 and **.mac.SO= 7. Could anybody help me out?

seed-0-mt = 861

sim-time-limit = 1800s

############################################7#################################

#       Network settings                                                     #

##############################################################################

**.constraintAreaMinX = 0m

**.constraintAreaMinY = 0m

**.constraintAreaMinZ = 0m

**.constraintAreaMaxX = 300m

**.constraintAreaMaxY = 300m

**.constraintAreaMaxZ = 0m

##############################################################################

#       Mobility settings                                                    #

##############################################################################

**.sensor[*].mobilityType = "StationaryMobility"

**.mobility.initFromDisplayString = false

**.sensor[0].mobility.initialX = 150m

**.sensor[0].mobility.initialY = 150m

**.sensor[1].mobility.initialX = 65.14m

**.sensor[1].mobility.initialY = 65.14m

#**.sensor[2].mobility.initialX = 170m

#**.sensor[2].mobility.initialY = 33.8m

#**.sensor[3].mobility.initialX = 65.14m

#**.sensor[3].mobility.initialY = 234.86m

#**.sensor[4].mobility.initialX = 33.8m

#**.sensor[4].mobility.initialY = 150m

#**.sensor[5].mobility.initialX = 270m

#**.sensor[5].mobility.initialY = 150m

#**.sensor[6].mobility.initialX = 215.14m

#**.sensor[6].mobility.initialY = 234.86m

#**.sensor[6].mobility.initialX = 215.14m

#**.sensor[6].mobility.initialY = 65.14m

#**.sensor[7].mobility.initialX = 234.86m

#**.sensor[7].mobility.initialY = 234.8m

#**.sensor[8].mobility.initialX = 107m

#**.sensor[8].mobility.initialY = 50m

**.sensor[*].mobility.initialZ = 0m

##############################################################################

#       Parameters for the application-layer (TrafGen)                       #

##############################################################################

**.sensor[0].app.isSink = true

**.sensor[0].app.packetSize = 10B 

**.sensor[0].app.firstPacketTime = exponential(1s) 

**.sensor[0].app.WBANSensorType ="Coordinator"

**.sensor[*].app.trafDest = "sensor[0]" # the default is "BROARDCAST"

**.sensor[1].app.isSink = false # the default is ture, if it is ture then the node doesn't send traffic

**.sensor[1].app.packetSize = 2.5B 

**.sensor[1].app.interDepartureTime = exponential(1s) 

**.sensor[1].app.firstPacketTime = exponential(1s) 

#**.sensor[2].app.isSink = false # the default is ture, if it is ture then the node doesn't send traffic

#**.sensor[2].app.packetSize = 12.5B 

#**.sensor[2].app.interDepartureTime = exponential(1s) 

#**.sensor[2].app.firstPacketTime = exponential(1s) 

#**.sensor[3].app.isSink = false # the default is ture, if it is ture then the node doesn't send traffic

#**.sensor[3].app.packetSize = 102B 

#**.sensor[3].app.interDepartureTime = 0.6528s 

#**.sensor[3].app.firstPacketTime = exponential(1s)

#**.sensor[4].app.isSink = false # the default is ture, if it is ture then the node doesn't send traffic

#**.sensor[4].app.packetSize = 12.5B 

#**.sensor[4].app.interDepartureTime = 1s 

#**.sensor[4].app.firstPacketTime = exponential(1s)

#**.sensor[5].app.isSink = false # the default is ture, if it is ture then the node doesn't send traffic

#**.sensor[5].app.packetSize = 20B

#**.sensor[5].app.interDepartureTime = 1s 

#**.sensor[5].app.firstPacketTime = exponential(1s)

#**.sensor[6].app.isSink = false # the default is ture, if it is ture then the node doesn't send traffic

#**.sensor[6].app.packetSize = 12.5B

#**.sensor[6].app.interDepartureTime = exponential(1s) 

#**.sensor[6].app.firstPacketTime = exponential(1s)

#**.sensor[7].app.isSink = false # the default is ture, if it is ture then the node doesn't send traffic

#**.sensor[7].app.packetSize = 45B

#**.sensor[7].app.interDepartureTime = 1s 

#**.sensor[7].app.firstPacketTime = exponential(1s)

#**.sensor[8].app.isSink = false # the default is ture, if it is ture then the node doesn't send traffic

#**.sensor[8].app.packetSize = 100B

#**.sensor[8].app.interDepartureTime = 1s 

#**.sensor[8].app.firstPacketTime = exponential(1s)

#**.sensor[9].app.isSink = false # the default is ture, if it is ture then the node doesn't send traffic

#**.sensor[9].app.packetSize = 110B

#**.sensor[9].app.interDepartureTime = 1s 

#**.sensor[9].app.firstPacketTime = 1s

#**.sensor[10].app.isSink = false # the default is ture, if it is ture then the node doesn't send traffic

#**.sensor[10].app.packetSize = 62.5B

#**.sensor[10].app.interDepartureTime = 1s 

#**.sensor[10].app.firstPacketTime = 1s

##############################################################################

#       Parameters for the network-layer                 #

##############################################################################

**.sensor[0].net.isPANCoor = true # should be consistent with those in MAC

**.sensor[*].net.isPANCoor = false

##############################################################################

#       Parameters for the network interface and IFqueue               #

##############################################################################

#**.nic.ifqType  = "PriorityQueue"

**.nic.ifqType  = "DropTailQueue"

**.ifq.frameCapacity = 200000 #default is 100

##############################################################################

#       Parameters for MAC layer                           #

##############################################################################

**.sensor[0].**.mac.isPANCoor = true

**.sensor[0].**.mac.WBANSensorType="Coordinator"

**.sensor[*].**.mac.isPANCoor = false

**.mac.panCoorName = "sensor[0]"

**.mac.BO = 8 # range [1,14]

**.mac.SO = 7 #range [0, BO)

**.sensor[*].**.mac.dataTransMode = 1 # 1: direct; 2: indirect; 3: GTS

# GTS settings

**.sensor[*].**.mac.ack4Gts = false

**.sensor[*].**.mac.gtsPayload = 0 # should be consistent with that in trafconfig.xml

**.sensor[*].**.mac.isRecvGTS = false # transmit GTS

##############################################################################

#       Parameters for PHY layer                                   #

##############################################################################

**.phy.channelNumber = 11 # default 2.4G, (range [0, 26])

**.phy.transmitterPower = 1.0mW   #[mW]

**.phy.sensitivity = -85dBm #[dBm]

**.phy.thermalNoise = -110dBm #[dBm]

**.phy.pathLossAlpha = 2

**.phy.snirThreshold = 4dB

##############################################################################

#       Parameters for the channel control                                   #

##############################################################################

# channel physical parameters

*.channelControl.carrierFrequency   = 2.4GHz

*.channelControl.pMax     = 2.0mW

*.channelControl.sat    = -85dBm

*.channelControl.alpha     = 2 

*.channelControl.numChannels    = 27

*.channelControl.propagationModel   = "LogNormalShadowingModel"

##############################################################################

#       Parameters for the display module in the hosts                       #

##############################################################################

 

# display parameters (same as channelControl parameters and mac parameters)

**.disp.carrierFrequency = 2.4GHz

**.disp.pMax = 2.0mW

**.disp.sat = -85dBm #[dBm]

**.disp.alpha = 2

**.disp.numChannels = 27

**.disp.transmitterPower = 1.0mW   #[mW]

**.disp.sensitivity = -85dBm #[dBm]

##############################################################################

#       Parameters for the Energy Model (units: mAh and mA)                  #

##############################################################################

**.phy.usageCpuActive  = 7.6

**.phy.usageCpuSleep  = 0.237 ## 3.3 mA for IDLE mode, 0.237 mA for Standby

**.phy.usage_radio_idle = 1.38mA #[mA]

**.phy.usage_radio_recv = 9.6mA #[mA]

**.phy.usage_radio_sleep = 0.06mA #[mA]

**.battery.nominal = 25

**.battery.capacity = 25

**.battery.voltage = 10

**.battery.resolution = 1s

**.battery.publishDelta = 0.5

**.battery.publishTime = 20s

##############################################################################

#       Output vectors                                                       #

##############################################################################

**.End-to-end delay.vector-recording = true

**.Mean end-to-end delay.vector-recording = true

#**.vector-recording = true

**.queueLength.vector-recording                  = true

##############################################################################

#       Simulation runs                                                      #

##############################################################################

[Michael Kirsche]

That's worth to examine a bit.

Your settings of BO and SO lead to a duty cycle of 50%, meaning 50% wake-up and 50% sleep time. If my memory (excel calculations) serve me right, then the Beacon Interval is around 3.9322 seconds and the Superframe Duration 1.9661 seconds.

You set the packet departure time to "**.sensor[1].app.interDepartureTime = exponential(1s)", meaning that every second or so a new packet will be sent (according to the exponential distribution around 1s). So plus or minus 1800 packets will be sent during your 1800seconds simulation (according to your time limit).

When you look at the vector of collected end-to-end delays for the first scenario (only 2 nodes, which is one source and one sink), you'll see that most of the packets are received at the sink with an E2E-delay between 0.003-0.005 and some packets in between have higher E2E-delays like 1.15 or 1.86 and so on.

Take a look at the time stamps. Usually the longer E2E-delays occur when a packet was being sent in a sleep/inactive period and a (couple of) packets are/were stored in the interface queue (which you set to a high value, so that no packets are dropped there).
So all packets that are generated in the first active period (~1.9 seconds) are immediately sent and all packets in the inactive period (the following ~1.9 seconds until 3.9 seconds or so are stored in the queue and sent afterwards.

So what shapes your end-to-end-delay is the exponential(1s) distribution of the inter-packet-interval and the chosen active and inactive period with your BO and SO values.


Now let's increase the number of nodes.
With multiple senders you will eventually have collisions at the sink of course.


When you take a look at the actual values for the end-to-end-delay at the sink with two senders or three senders now, you'll see that still the range of values differs between 0.003 to 1.88 or so. Packets are still either sent directly if they are created in inside an active period or delayed and stored in the queue if created inside an inactive period.


Now compare the number of packets with a E2E-delay less than 0.006 for example and the number of packets with an E2E-delay above 0.006.
You will see that for scenarios with multiple senders the number of packets with a delay less than 0.006 is getting bigger in relation to the other packets with a higher E2E-delay.

As the mean-end-to-end-delay is calculated = sumE2EDelay / numReceived, you will get a lower mean-E2E-delay if the number of smaller E2E-delays is overall increasing (the ratio between "low" E2E-delays and "high" E2E-delays is shifting towards the lower values).


Why is it like this?
What you actually experience is that the channel bandwith is more than enough to handle the data traffic that is generated by the various sources.


Your mean-end-to-end-delay will decrease (little by little) until you'll reach the channel's capacity and the number of packets to send is actually higher than the time/bandwith available. In your case that will probably happen with much larger numbers of nodes when you keep the inter-packet-interval at exponential(1s) and the BO and SO values like they are.


So whatever you want to achieve/simulate/examine, think twive about your BO / SO (for IEEE 802.15.4) and your traffic generator settings (in general).

[Đức Anh Hồ]

   Hi, I'm sorry but i am interested in this problem, can you explain to me the meaning of the parameters

**.mac.BO                         = 8        # range [1,14]

**.mac.SO                         = 4        #range [0, BO)
 
  

[Đức Anh Hồ]

    Hi, I'm confuse that why each node, you set an unique "sensor[*].app.packetSize" ?

[Alfonso Ariza Quintana]

Beacon Order (BO)

Superframe Order (SO)

 

You can find information about both

http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf

--
You received this message because you are subscribed to the Google Groups "omnetpp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to omnetpp+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Kirsche]

Instead of simply asking about every single detail, why not read the IEEE 802.15.4 standard?
It is publicly available...

Am Donnerstag, 27. November 2014 09:53:20 UTC+1 schrieb Đạt Lê khánh:

I saw your setting "**.sensor[*].**.mac.dataTransMode = 1" that mean "direct". So what is different about "direct, indirect and GTS"? Please give me some infomation about these

Vào 05:40:47 UTC+7 Thứ tư, ngày 26 tháng mười một năm 2014, mohammad nekooei đã viết:

[mohammad nekooei]

Thank you very much Michael it was very helpful.

--
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/2WrFl4EtGL0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to omnetpp+u...@googlegroups.com.