I am running Leach protocol simulations in Castalia Omnet++ with the following simulation parameters:
sim-time-limit = 100s
SN.field_x = 70
SN.field_y = 70
SN.numNodes = 10
SN.deployment = "[1..9]->uniform"
SN.node[*].Communication.RoutingProtocolName = "LeachRouting"
SN.node[*].Communication.Routing.netBufferSize = 1000
SN.node[0].Communication.Routing.isSink = true
SN.node[*].Communication.Routing.slotLength = 0.2
SN.node[*].Communication.Routing.roundLength = 20s
SN.node[*].Communication.Routing.percentage = 0.05
SN.node[*].Communication.Routing.powersConfig = xmldoc("powersConfig.xml")
SN.node[*].ApplicationName = "ThroughputTest"
SN.node[*].Application.packet_rate = 1
SN.node[*].Application.constantDataPayload = 200
After running simulations, I checked the Castalia trace file and found the following errors:
SN.node[1].Communication.Radio Failed packet (WC_SIGNAL_START) from
node 6, radio not in RX state
SN.node[1].Communication.Radio Failed packet (WC_SIGNAL_END) from node
6, NO interference
Are these errors occurs due to simulation parameters or is there any other reason?
The messages you see are not errors per se. It could be normal behaviour. The messages just tell you that when a packet from node 6 arrived at node 1, node 1 did not have its radio in RX mode (listening) so it could not receive the packet.
This is a problem only when you lose most of your info-carrying packets, or you do not have a way to recover from such losses. You do not provide information whether this is the case or not.
The MAC plays a crucial role in this. The MAC puts the radio in RX or TX or Sleep mode. In the list of simulation parameters, the MAC is absent. If we assume that you use the default value, then this is bypassMAC that does not put the Radio to Sleep mode. Only way to have this message appear is for node 1 to TX at the same time it receives the packet from node 6.
These are normal messages, not errors. You can check Radio.cc to know why these messages are generated and adjust your code.
Related
I am new to Omnet and Inet.
I am modifying the network TsnLinearNetwork which is part of the Inet Library and looks like the following:
Client <-------> Switch <-------> Server
The client sends a continuous packet stream which the switch forwards to the server.
I am trying to set up a Periodic Gate which changes its state, so that the packets won't get forwarded, if the gate is closed.
The 1st second the gate should be closed and the 2nd second it should be open.
As a result the gate status changes which I configured in the omnetpp.ini file.
In contrast to that, the packets are forwarded even on a closed gate state.
I played around with the omnet.ini parameters without any success.
I am expecting that the packets are discarded when the periodic gate state is closed.
Like the documentation points out:
PeriodicGate
This module allows or forbids packets to pass through depending on whether the gate is open or closed. The gate is open and closed according to the list of change times periodically.
So here my questions:
Why are the packets forwarded even on a closed gate state?
How can I achieve that behaviour?
omnetpp.ini
[General]
[simpleStart03]
network = simpleStart
sim-time-limit = 2s
*.client.numApps = 1
*.client.app[*].typename = "UdpSourceApp"
*.client.app[0].display-name = "random traffic"
*.client.app[*].io.destAddress = "server"
*.client.app[0].io.destPort = 1000
*.client.app[0].source.packetLength = 1000B
*.client.app[0].source.productionInterval = 500us
*.client.hasOutgoingStreams = true
*.client.bridging.streamIdentifier.identifier.mapping = [{stream: "random traffic"}]
*.client.bridging.streamCoder.encoder.mapping = [{stream: "random traffic", pcp: 0}]
*.server.numApps = 1
*.server.app[*].typename = "UdpSinkApp"
*.server.app[0].io.localPort = 1000
*.switch.bridging.streamCoder.decoder.mapping = [{pcp: 0, stream: "random traffic"}]
*.switch.hasIngressTrafficFiltering = true
*.switch.bridging.streamFilter.ingress.numGates = 1
*.switch.bridging.streamFilter.ingress.numMeters = 1
*.switch.bridging.streamFilter.ingress.numStreams = 1
*.switch.bridging.streamFilter.ingress.classifier.mapping = {"random traffic": 0}
*.switch.bridging.streamFilter.ingress.meter[0].display-name = "random traffic"
*.switch.bridging.streamFilter.ingress.meter[*].typename = "SingleRateTwoColorMeter"
*.switch.bridging.streamFilter.ingress.meter[0].committedInformationRate = 40Mbps
*.switch.bridging.streamFilter.ingress.meter[0].committedBurstSize = 10kB
*.switch.bridging.streamFilter.ingress.gate[*].typename = "PeriodicGate"
*.switch.bridging.streamFilter.ingress.gate[0].display-name = "random traffic"
*.switch.bridging.streamFilter.ingress.gate[0].initiallyOpen = false
*.switch.bridging.streamFilter.ingress.gate[0].durations = [1s,1s]
*.switch.bridging.streamFilter.ingress.gate[*].initiallyOpen = false
omnetpp.ned
import inet.networks.tsn.TsnLinearNetwork;
network simpleStart extends TsnLinearNetwork
{
}
omnet Version: 6.0.1
Inet Version: inet4.4
This issue was stated as a bug
https://github.com/inet-framework/inet/issues/830
The bug is that the classifier doesn't check that the selected gate index can be pushed with the packet or not. In case the selected branch has back pressure then the default branch should be selected. If the default branch also has back pressure then an error should be raised.
This Commit fixes the issue and this commit changes the order of the submodules.
Suppose in a wireless network with 25 nodes, we have a scenario where some of each node sends messages to some other nodes according to a routing protocol such as AODV.
We simulate this network. After finishing the simulation, how to obtain the number of correct messages on the network layer by the Omnet++ result collection? Two metrics are defined, sentPacketCount and receivedPacketCount.
By correct messages, I mean messages received by a node whose destination address field is the address of the same node. If retransmission occurs, it should be counted once for the receiver side for receivedPacketCount, in fact, received Packet Count will be increased when the packet is received in destination node. Every packet is sent, sentPacketCount will be increased.
If a node has more than an application, all the messages generated by all applications of the same node must be counted.
A part of omnetpp.ini file is for a node:
*.hostA.numApps = 2
*.hostA.app[0].typename = "UdpBasicApp"
*.hostA.app[0].destAddresses = "hostB"
*.hostA.app[0].destPort = 5000
*.hostA.app[0].messageLength = 1000B
*.hostA.app[0].sendInterval = exponential(12ms)
*.hostA.app[0].packetName = "UDPData"
*.hostA.app[0].typename = "TcpBasicApp"
*.hostA.app[0].destAddresses = "hostC"
*.hostA.app[0].destPort = 5001
*.hostA.app[0].messageLength = 1024B
*.hostA.app[0].sendInterval = exponential(45ms)
*.hostA.app[0].packetName = "TCPData"
For TcpBasicApp or any other TCP app, the count of packets is meaningless. Tcp apps have streams, not packets. Even if you send out 1000 bytes in one write operation to a TCP socket, the other end may get it using 3 read operation, or 20... TCP also guarantees the delivery of the packets, so number of successfully sent packets = number of successfully received packets. So byte count statistics also do not matter.
Number of sent/received packets/bytes makes sense for UDP traffic. In UDP there is a concept of packets and there is no guaranteed delivery. Luckily UdpBasicApp gathers these statistics by default. Take a look at the packetReceived and packetSent statistic. It gathers both packet count and total byte count.
You may need to turn on scalar recording on all apps:
**.app[*].*.scalar-recording = true
I am using omnet++-5.4.1, veins-4.7.1 and sumo-0.25.0 to simulate vehicle frame transmission.
About the behavior of the EDCA in the mac layer in WAVE, in my understanding the waiting time to send can be obtained by the following calculation.
waiting time = AIFS[AC] + backoff
AIFS[AC] = SIFS + AIFSN[AC] * slotlength
However, in the startContent function of Mac 1609_4.cc, it is written as follows
if (idleTime > possibleNextEvent) {
DBG_MAC << "Could have already send if we had it earlier" << std::endl;
//we could have already sent. round up to next boundary
simtime_t base = idleSince + DIFS;
possibleNextEvent = simTime() - simtime_t().setRaw((simTime() - base).raw() % SLOTLENGTH_11P.raw()) + SLOTLENGTH_11P;
}
Even during simulation, transmission is performed without waiting for the time calculated just after the transmission request has occurred.
As described above, it is considered that the operation of the original EDCA (CSMA / CA) has not been performed and the busyness of the channel is not sensed.
I do not understand enough about this Mac layer? Please let me know if I missed some information.
Thank you.
I want to get the number of collisions in Veins. I am using Instant Veins 4.7.1 and I just modified the scenario to get a high density of vehicles without a RSU. The application only send beacons (BasicSafetyMessages) with an interval and transmission power as follows:
*.**.nic.mac1609_4.txPower = 50mW
*.node[*].appl.sendBeacons = true
*.node[*].appl.beaconInterval = 0.1s
I modified the next part of Mac1609_4.cc:
else if (msg->getKind() == Decider80211p::BITERROR || msg->getKind() == Decider80211p::COLLISION) {
statsSNIRLostPackets++;
DBG_MAC << "A packet was not received due to biterrors" << std::endl;
if (msg->getKind() == Decider80211p::COLLISION)
statsCollisions++;
else if (msg->getKind() == Decider80211p::BITERROR)
statsBitErrors++;
}
but all lost packets I get are due to biterrors and none due to collisions. Is there a default configuration of Veins that is not allowing me to get collisions?
Veins allows to collect statistics about collisions natively. However, it is disabled by default, since it increases simulation time. To enable it, just add the following line to your omnetpp.ini:
*.**.nic.phy80211p.collectCollisionStatistics = true
This enables collision statistics in Decider80211p on all nodes in your scenario which then record ncollisions.
I added extra event like accident in TraCiMobility.cc including the accident message but I can only see the data exchange between nodes for the accident message and can not see the data exchange between nodes with the new "icyroad" event.
When using only "icy road", I can see the data exchange between the nodes. Where should I add/edit in Veins so that I can see data exchange when both or more events are active?
The .ini is as follows:
*.node[*].veinsmobilityType = "org.car2x.veins.modules.mobility.traci.TraCIMobility"
*.node[*].mobilityType = "TraCIMobility"
*.node[*].mobilityType.debug = true
*.node[*].veinsmobilityType.debug = true
*.node[*].veinsmobility.x = 0
*.node[*].veinsmobility.y = 0
*.node[*].veinsmobility.z = 1.895
*.node[4].veinsmobility.accidentCount = 1
*.node[4].veinsmobility.accidentStart = 45s
*.node[4].veinsmobility.accidentDuration = 30s #30s
*.node[3].veinsmobility.icyroadCount = 1
*.node[3].veinsmobility.icyStart = 15s
*.node[3].veinsmobility.icyDuration = 30s
The sample simulation that is included in Veins 4a2 uses an application layer that only relays the first message it receives. You will need to change this to a more full-featured application layer to make this work with more than one event type.