We have a network topology. There is a base station, 36 LCN and 1500 sensor nodes. While simulating, I want to turn off / disconnect randomly selected the sensor nodes.I mean ,I dont want to sense any value from this nodes.To do this I used:
cModuleType *moduleType = cModuleType::get("SensorNode");
cModule *snIO = modtype->createScheduleInit("snIO", this);
snIO->gate("inout")->disconnect();
sensor numbers are set in the network.ned file
(" Error in module (SensorNode) Network.sn[20] (id=22) at event #5, t=0: NED module type "SensorNode" not found (fully qualified type name expected)").So how can I solve this problem ?
Related
Hello dear OmNetpp and INET community,
I try to create a UDP sender module that adds a DSCP value to each packet.
Something like this:
module udpAppTag extends UdpApp like IApp
{
parameters:
tagger.typename = "PacketTagger";
}
I read the information from the INET document PacketTagger that there is a dscp parameter in the module.
In addition, I also read some example of setting tagger from showcase Frame Preemption.
something like this:
*.host1.app[0].tagger.vlanId = 1
*.host1.app[1].tagger.vlanId = 0
However, what I plan to do is not on the application level, but on the packet level.
So, how do I assign a different DSCP value to each packet?
For example, if my total simulation time is 1s, at 0.2s, I send the first UDP packet with dscp=1, and at 0.7s, the second with dscp=3.
Should I import a XML file from the .ini file? If there is a sample code, that would be appreciated.
Thank you very much.
I am quite new to OMNET++ and I am currently working on a VANET simulation.
I am using the VeinsInCar module to simulate cars and the network being used is WLAN. I would like to change the coverage distance of the node. I tried using the following code but it is not working:
*.node*.wlan[0].radio.transmitter.communicationRange = 500m
Component in Ned file:
node[0]: VeinsInetCar {
#display("p=72,200;r=10");
}
Could you please help ?
Awaiting for a response.
Regards,
Azhar
The simulation configuration I want is for the vehicle and the RSU to communicate with each other through IEEE 802.11p and LTE through one eNB(eNodeB).
Refer to the veins_hetvnet repository and the paper Simulating cellular communications in vehicular networks: making SimuLTE interoperable with Veins to configure the .ned of each node and write the source code.
The error seems to occur in the code below among omnetpp.ini codes.
# car
**.car[*].masterId = 1
**.car[*].macCellId = 1
# RSU
**.fRSU[*].masterId = 1
**.fRSU[*].macCellId = 1
# Cell (eNodeB)
**.Cell.macCellId = 1
**.Cell.macNodeId = 1
**.dynamicCellAssociation = true
When I run the simulation, the following error occurs.
check_and_cast(): Cannot cast (LteMacEnbRealistic*)MyScenario.Cell.lteNic.mac to type 'LteMacEnbRealisticD2D*' -- in module (LteMacUeRealisticD2D) MyScenario.fRSU[0].lteNic.mac (id=184), during network initialization ..
The paper stated that it was the difference between automatic and manual coupling, but I don't know if that is true.
How can I modify the D2D communication with one eNB?
I'm working on Veins | OMNeT++ | SUMO.
Is it possible to select the starting position of our cars and the destination?
I only see spawn of vehicules at the exact same position and don't know how to adapt them. I've already read some topics explaining that we have cars that are created automatically by the TraCI module, but how can we control it?
Cars are initially created by SuMO and then inserted in Veins by the TraCIScenarioManager. In the demo example from Veins, multiple vehicles are driving from the same origin to the same destination:
194 Cars leaving the Computer Science Building and campus of the University of Erlangen-Nuremberg
In order to have different traffic, you have to adjust the network description files of SuMO - in particular the *.rou.xml. See the SuMO wiki for how to configure vehicles and routes.
I think you can following method in TraCICommandInterface.h.
bool addVehicle(std::string vehicleId, std::string vehicleTypeId, std::string routeId, simtime_t emitTime_st = -DEPART_NOW, double emitPosition = -DEPART_POS_BASE, double emitSpeed = -DEPART_SPEED_MAX, int8_t emitLane = -DEPART_LANE_BEST_FREE);
I am using veins4.6 with sumo 0.30 and omnet++5.1.1 in ubuntu 14.04. I have created a custom network with a cross(one intersection with 4 roads) and ran the simulation with 200 vehicles. I did not observe this behaviour for 4vehicles. I have seen it with 50 vehicles too. I need to get the count of total lost packets for my masters project. So I was looking at statistics and found that RXTXLostPackets is not zero. As far as I understood from documentation it should be zero if allowTxDuringRx=false. Default is false(PhyLayer80211p.ned). As I did not change any code yet, I was confused if that is expected behaviour.
What I have done so far.
from Mac1609_4::handleLowerControl, statsTXRXLostPackets is updated when Decider80211p responds with RECWHILESEND.
In Decider80211p::processSignalEnd, if value of whileSending is true RECWHILESEND is sent to mac layer as control message.
In Decider80211p::processSignalEnd, if(frame->getWasTransmitting() || phy11p->getRadioState() == Radio::TX) , this frame was considered as received while sending and sets the value for whileSending as true.
The wasTransmitting varilable is set to true in Decider80211p::switchToTx and Decider80211p::processNewSignal functions.
currentFrame->setWasTransmitting(true);
currentFrame->setBitError(true);
in Decider80211p::processNewSignal:
if (phy11p->getRadioState() == Radio::TX ) {
frame->setBitError(true); --> tried disabling both these values and the RXTXLostPackets was zero.
frame->setWasTransmitting(true);
DBG_D11P << "AirFrame: " << frame->getId() << " (" << recvPower << ") received, while already sending. Setting BitErrors to true" << std::endl;
}
There is one thread with similar issue with the fix of adding this line in processSignalEnd function. But looks like veins4.6 does not use curSyncFrame anymore.
Veins - Unexpected behavior with lost packets in certain vehicles
if (!frame->getWasTransmitting()){
curSyncFrame = 0;
}
I could not clearly understand the issue. The code and configuration files I have used are here. https://github.com/Rajeswar59/veins_learning.
Can anyone please take a look and help me with this. Thanks in advance.
edit: I went through the logs. This is what I could understand as of now.
https://drive.google.com/open?id=0BzjDW8PQhkSmSEUtZ2lpcld4ZXc --> some portion of logs are here.
---> order of sending
#13332 0.247987176594 node[30] --> node[48] id=22266
#13375 0.247987796864 node[18] --> node[20] id=22447
#13384 0.247987864534 node[20] --> node[30] id=22573
From logs I have concentrated on node 18. Two nodes that transmitted before 30 are 32 and 4. These 2 messages are received successfully by all 3 nodes. When a message arrives decider tries to set channel state as busy in processnewsignal and set idle after processing packet. This calls mac1609_4.cc channelBusy and channelIdle functions respectively. So the channelIdle variable is set accordingly. Also if channel is to be set busy it will stop contention and calculate currentBackoff if any packet is waiting to be transmitted. If channel is being set idle at the end of reception, startContent is called. Based on this only the lastIdle variable is set which is used to calculate nextMacEvent. So when the last successful message was received all the nodes which have a packet to send decide nextMacEvent and it is sent as self message in Mac1609_4.cc. on receiving the nextMacEvent self message we will start transmitting without checking if any other node has started transmission. We can not identify that probably because we are setting channel busy when we receive messages after some propagation delay. So between last successful transmission and nextMacEvent other nodes also take decision to transmit without checking current channel state. That's why the node has some receive events while sending. As far as my understanding goes before transmission we should sense current state of channel and retry backoff accordingly. We do not check this at the nextMacEvent. It looks like a collision behaviour but should we not check the current state of channel when backoff counter reaches zero and retry. Please correct me if I am wrong anywhere.
Thanks for your patience.
Any help or advice??
My Learnings(probably last update):
After Some digging, these are my learnings if it helps some one. The basic CSMA mechanism says before attempting for transmission, the node has to sense the channel, initiate transmission if the channel is sensed idle for AIFS time, or go in to back off if channel is busy. In veins the channel busy status is stored in idleChannel variable whose status is checked in Mac1609_4:channelBusySelf() function before initiating transmission (nextMacEvent in Mac1609_4::handleSelfMsg). The idleChannel is updated in Mac1609_4::channelBusy and Mac1609_4::channelIdle functions when a message reception starts and when message reception ends respectively. So when a previously transmitting node sends a packet, all the recieving nodes will receive the packet with varying delay i.e., starts receiving at different times and update their channelIdle variable. After that they calculate best time to transmit and starts transmission. It does check if channel is idle or not but as the channelIdle status is updated at next reception and because of transmission delay it takes some time between transmission start at sender and reception start at receiver side, both the transmitting nodes cant see other transmission. As far as I understand this is called a collision when more than two nodes start transmission at the same time. So the BitError statistic is set and statsTXRXLostPackets is also set. So while calculating totalLostPackets we can take only one of these two values.