Omnet++/INET Module PeriodicGate forwards Packets even if it is closed - omnet++

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.

Related

Cut-through switching is not working when integrating with Time Aware Shaper (TAS) in INET4.0 showcases

Hello dear researchers:
I am trying to integrate three INET showcases: cut-through switching, Time Aware Shaper, gPTP.
The topology is simplpe as follows: Two senders, one clock, one switch, and one receiver. For simplicity, the gate is always open.
According to the sample code in combine features, I add the following codes to enable the cut-through switching.
#enable cut-through in all network nodes
*.*.hasCutthroughSwitching = true
*.switch.eth[*].typename = "LayeredEthernetInterface"
*.switch.eth[*].phyLayer.typename = "EthernetStreamingPhyLayer"
Currently, the simulation is working. However, the behavior from the animation is still like store and forward. The packets are not transmitted until the whole packets are inside the switch.
If we only enable the first line and comment the other two lines,
*.*.hasCutthroughSwitching = true
#*.switch.eth[*].typename = "LayeredEthernetInterface"
#*.switch.eth[*].phyLayer.typename = "EthernetStreamingPhyLayer"
then there is an error message showing :
Another packet streaming operation is already in progress -- in module (inet::physicallayer::EthernetPhyHeaderInserter) streamisolation.switch.eth[3].phyLayer.phyHeaderInserter (id=493), at t=0.000000226s, event #20
I would like to know how to fix this problem. Thank you.
My *.ini and *.ned files are below.
streamIsolation.ini
[General]
network = tsn_scalability.simulations.streamisolation
description = "stream isolation latency testing"
**.displayGateSchedules = true
**.gateFilter = "**.eth[1].**"#"**"#"**.eth[1].**"
**.gateScheduleVisualizer.height = 20
**.gateScheduleVisualizer.placementHint = "top"
# avoid ARP
#**.hasGlobalArp = true
#####################
# Clock Configuration
# use TSN clock
**.referenceClock = "tsnClock.clock"
*.tsnClock.clock.typename = "IdealClock"
*.tsnDevice.clock.typename = "OscillatorBasedClock"
*.switch.clock.typename = "OscillatorBasedClock"
*.server.clock.typename = "OscillatorBasedClock"
*.tsnClock.clock.oscillator.typename = "IdealOscillator"
*.tsnDevice.clock.oscillator.typename = "ConstantDriftOscillator"
*.switch.clock.oscillator.typename = "ConstantDriftOscillator"
*.server.clock.oscillator.typename = "ConstantDriftOscillator"
*.tsnDevice.clock.oscillator.driftRate = uniform(-100ppm, 100ppm)
*.switch.clock.oscillator.driftRate = uniform(-100ppm, 100ppm)
*.server.clock.oscillator.driftRate = uniform(-100ppm, 100ppm)
####################################
# Time Synchronization Configuration
# enable time synchronization in all network nodes
#*.*.hasTimeSynchronization = true
# time synchronization starts from the master clock
*.tsnClock.gptp.gptpNodeType = "MASTER_NODE"
*.tsnClock.gptp.masterPorts = ["eth0"]
*.switch.hasGptp = true
*.switch.gptp.gptpNodeType = "BRIDGE_NODE"
*.switch.gptp.masterPorts = ["eth1", "eth2"]
*.switch.gptp.syncInterval = 500us
*.switch.gptp.pdelayInterval = 1ms
*.switch.gptp.pdelayInitialOffset = 0ms
# application traffic sources use the local clock of the network node
*.*.app[*].source.clockModule = "^.^.clock"
# periodic gates in all traffic shapers use the local clock of the network node
*.*.eth[*].macLayer.queue.transmissionGate[*].clockModule = "^.^.^.^.clock"
# client application
*.tsnDevice.numApps = 1
*.tsnDevice.app[0].typename = "UdpSourceApp"
*.tsnDevice.app[0].io.destAddress = "server"
*.tsnDevice.app[0].io.destPort = 1000
*.tsnDevice.app[0].display-name = "tactile"
*.tsnDevice1.numApps = 1
*.tsnDevice1.app[0].typename = "UdpSourceApp"
*.tsnDevice1.app[0].io.destAddress = "server"
*.tsnDevice1.app[0].io.destPort = 1001
*.tsnDevice1.app[0].display-name = "besteff"
# server applications
*.server.numApps = 2
*.server.app[*].typename = "UdpSinkApp"
*.server.app[0].io.localPort = 1000
*.server.app[1].io.localPort = 1001
# enable outgoing streams
*.*.hasOutgoingStreams = true
# enable streams
# enable egress traffic shaping
*.switch.hasEgressTrafficShaping = true
# time-aware traffic shaping
*.switch.eth[*].macLayer.queue.numTrafficClasses = 2
*.switch.eth[*].macLayer.queue.queue[0].display-name = "q0"
*.switch.eth[*].macLayer.queue.queue[1].display-name = "q1"
# enable cut-through in all network nodes
*.*.hasCutthroughSwitching = true
*.switch.eth[*].typename = "LayeredEthernetInterface"
*.switch.eth[*].phyLayer.typename = "EthernetStreamingPhyLayer"
# client application
*.tsnDevice.app[0].source.packetLength = 1500B - 50B # 42B = 8B (UDP) + 20B (IP) + 14B (ETH MAC) + 4B (ETH FCS) + 8B (ETH PHY)
*.tsnDevice.app[0].source.productionInterval = 0.1ms
*.tsnDevice.bridging.streamIdentifier.identifier.mapping = [{stream: "tactile", packetFilter: expr(has(udp) && udp.destPort == 1000)}]
*.tsnDevice.bridging.streamCoder.encoder.mapping = [{stream: "tactile", pcp: 6}]
*.tsnDevice1.app[0].source.packetLength = 1500B - 50B # 42B = 8B (UDP) + 20B (IP) + 14B (ETH MAC) + 4B (ETH FCS) + 8B (ETH PHY)
*.tsnDevice1.app[0].source.productionInterval = 0.2ms
*.tsnDevice1.bridging.streamIdentifier.identifier.mapping = [{stream: "besteff", packetFilter: expr(has(udp) && udp.destPort == 1001)}]
*.tsnDevice1.bridging.streamCoder.encoder.mapping = [{stream: "besteff", pcp: 0}]
streamIsolation.ned
//
// This program is free software: you can redistribute it and/or modify
// it under the terms of the GNU Lesser General Public License as published by
// the Free Software Foundation, either version 3 of the License, or
// (at your option) any later version.
//
// This program is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU Lesser General Public License for more details.
//
// You should have received a copy of the GNU Lesser General Public License
// along with this program. If not, see http://www.gnu.org/licenses/.
//
package tsn_scalability.simulations;
import inet.networks.base.TsnNetworkBase;
import inet.node.contract.IEthernetNetworkNode;
import inet.node.ethernet.EthernetLink;
import inet.common.scenario.ScenarioManager;
import inet.networks.base.TsnNetworkBase;
import inet.node.ethernet.EthernetLink;
import inet.node.ethernet.EthernetSwitch;
import inet.node.tsn.TsnClock;
import inet.node.tsn.TsnDevice;
import inet.node.tsn.TsnSwitch;
import inet.node.inet.StandardHost;
//import inet.networklayer.configurator.ipv4.Ipv4NetworkConfigurator;
network streamisolation extends TsnNetworkBase
{
parameters:
*.eth[*].bitrate = default(1000Mbps);
submodules:
tsnClock: TsnClock {
#display("p=550,424");
}
tsnDevice: TsnDevice {
#display("p=350,200");
}
switch: TsnSwitch {
#display("p=550,200");
}
server: TsnDevice {
#display("p=750,200");
}
tsnDevice1: TsnDevice {
#display("p=350,300");
}
connections:
tsnClock.ethg++ <--> EthernetLink <--> switch.ethg++;
tsnDevice1.ethg++ <--> EthernetLink <--> switch.ethg++;
tsnDevice.ethg++ <--> EthernetLink <--> switch.ethg++;
switch.ethg++ <--> EthernetLink <--> server.ethg++;
}
This is a bug in the cut-through mechanism. The EthernetCuthroughSource modeul checks if the cut-through gate is ready to be pushed with a packet that is eligible for cut-through transmission. In your simulation two packets arrive at the switch from two different Ethernet interfaces at the same time. Both are eligible for cut-through transmission, but obviously only the first one should be transmitted using cut-through. For some reason the backpressure doesn't propagate back to the EthernetCuthroughtSource in the other incoming Ethernet interface from the outgoing interface PHY transmitter, so the other packet is also forwarded using cut-through, which is not possible and thus results in the above error.
Could you please create a bug in the github bug tracker, including your example?
This might be enough to activate cut-through switching:
*.*.hasCutthroughSwitching = true
The type of the Ethernet PHY and MAC is set automatically.

Errors in running Leach Protocol in Omnet++(Castalia )

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.

How to get collisions in Veins 4.7.1

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.

How to create a FTP connection and send a file in OMNeT++

I want to create a FTP connection and send a big file via it and see its effect in my network. In order to do that, I wrote the following lines in OMNet++ scenario file. I am not sure whether this is a correct way of creating a FTP connection or not. I set "thinkTime" and "IdleInterval" parameters to zero to send the FTP data immediately and in one session. Since the file size is too big for my current simulation, I think I would have only one session through the whole simulation time. However the throughput of my FTP connection is too low and I am not sure. Can someone help me? All suggestions or FTP examples are welcome.
# FTPclusterMember FTP
**.clusterMember[0].tcpApp[1].typename = "TCPBasicClientApp"
**.clusterMember[0].tcpApp[1].connectAddress = "FTPserver"
**.clusterMember[0].tcpApp[1].connectPort = 21
# Download Scenario requestLength < replyLength
**.clusterMember[0].tcpApp[1].requestLength = 100B
**.clusterMember[0].tcpApp[1].replyLength = 1500MB
**.clusterMember[0].tcpApp[1].thinkTime = 0s
**.clusterMember[0].tcpApp[1].idleInterval = 0s
# FTPserver Settings
**.FTPserver.numTcpApps = 1
**.FTPserver.tcpApp[0].typename = "TCPSinkApp"
**.FTPserver.tcpApp[0].localAddress = "FTPserver"
**.FTPserver.tcpApp[0].localPort = 21
Since FTP uses TCP in transport layer, we can use "TCPBasicClientApp" and "TCPGenericSrvApp" for FTP client and server respectively. For simulating behavior of FTP protocol, we set the port to 21. In addition, for simulation upload and download scenario, you just need to change the size of request length and reply length. As an example, please take a look at codes below;
# FTPclusterMember FTP
**.clusterMember[0].numTcpApps = 1
**.clusterMember[0].tcpApp[0].typename = "TCPBasicClientApp"
**.clusterMember[0].tcpApp[0].connectAddress = "FTPserver"
**.clusterMember[0].tcpApp[0].connectPort = 21
# Download Scenario requestLength < replyLength
# Upload Scenario requestLength > replyLength
**.clusterMember[0].tcpApp[0].requestLength = 1500MB
**.clusterMember[0].tcpApp[0].replyLength = 100B
**.clusterMember[0].tcpApp[0].thinkTime = 0s
**.clusterMember[0].tcpApp[0].idleInterval = 0s
# FTPserver Settings
**.FTPserver.numTcpApps = 1
**.FTPserver.tcpApp[0].typename = "TCPGenericSrvApp"
**.FTPserver.tcpApp[0].localAddress = "FTPserver"
**.FTPserver.tcpApp[0].localPort = 21
As you can see, I set "idleInterval" abd "thinktime" to zero. With these values, you can be sure that you have a constant transmission of FTP packets during your simulation time.

Veins: I added extra accident message but can not see the data exchange between nodes

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.

Resources