我在ubuntu 14.04中使用了veins4.6和sumo 0.30以及omnet ++ 5.1.1。我创建了一个带有十字架的自定义网络（一个有4条道路的交叉路口）并运行了200辆车的模拟。我没有观察到4车的这种行为。我也看过50辆车。我需要为我的主人项目获取总丢失数据包的数量。所以我在查看统计数据，发现RXTXLostPackets不为零。据我所知，如果allowTxDuringRx=false，它应为零。默认值为false（PhyLayer80211p.ned）。由于我还没有更改任何代码，如果这是预期的行为，我感到很困惑。
到目前为止我做了什么。
来自Mac1609_4::handleLowerControl的，当Decider80211p以RECWHILESEND响应时，statsTXRXLostPackets会更新。
在Decider80211p::processSignalEnd中，如果whileSending的值为真，则RECWHILESEND作为控制消息发送到mac层。
在Decider80211p :: processSignalEnd，if(frame->getWasTransmitting() || phy11p->getRadioState() == Radio::TX)中，此帧在发送时被视为已接收，并将whileSending的值设置为true。
在Decider80211p::switchToTx和Decider80211p::processNewSignal函数中，wasTransmitting varilable设置为true。
currentFrame->setWasTransmitting(true);
currentFrame->setBitError(true);
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;
}
在processSignalEnd函数中添加此行的修复程序有一个类似问题的线程。但看起来像veins4.6不再使用curSyncFrame了。
Veins - Unexpected behavior with lost packets in certain vehicles
if (!frame->getWasTransmitting()){
curSyncFrame = 0;
}
我无法清楚地理解这个问题。我使用的代码和配置文件在这里。 https://github.com/Rajeswar59/veins_learning。
任何人都可以看看并帮助我。提前致谢。
编辑：我浏览了日志。这就是我现在所能理解的。 https://drive.google.com/open?id=0BzjDW8PQhkSmSEUtZ2lpcld4ZXc - ＆gt;部分日志在这里。
---> 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
从日志中我集中在节点18.在30之前传输的两个节点是32和4.这两个消息由所有3个节点成功接收。当消息到达时，decider尝试在processnewsignal中将信道状态设置为busy，并在处理数据包后设置为idle。这分别调用mac1609_4.cc channelBusy和channelIdle函数。因此相应地设置channelIdle变量。此外，如果要将信道设置为忙，它将停止争用并在任何数据包等待传输时计算currentBackoff。如果在接收结束时将通道设置为空闲，则调用startContent。基于此，仅设置lastIdle变量，用于计算nextMacEvent。因此，当收到最后一条成功消息时，所有具有要发送的数据包的节点都会决定nextMacEvent，并在Mac1609_4.cc中将其作为自身消息发送。在接收到nextMacEvent self消息时，我们将开始发送而不检查是否有任何其他节点已经开始传输。我们无法识别这可能是因为我们在一些传播延迟后收到消息时设置了信道忙。因此，在上次成功传输和nextMacEvent之间，其他节点也会在不检查当前信道状态的情况下决定进行传输。这就是节点在发送时有一些接收事件的原因。据我所知，在传输之前我们应该检测通道的当前状态并相应地重试退避。我们不会在nextMacEvent上检查这个。它看起来像一个碰撞行为，但是当退避计数器达到零并且重试时我们不应该检查通道的当前状态。如果我在任何地方都错了，请纠正我。
感谢您的耐心等待。
任何帮助或建议??
我的学习（可能是上次更新）： 经过一些挖掘，这些是我的学习，如果它有所帮助。基本的CSMA机制在尝试传输之前说，节点必须检测信道，如果信道在AIFS时间被感知空闲则启动传输，或者如果信道忙，则进入后退状态。在静脉中，信道忙状态存储在idleChannel变量中，其状态在启动传输之前在Mac1609_4：channelBusySelf（）函数中被检查（Mac1609_4 :: handleSelfMsg中的nextMacEvent）。当消息接收开始和消息接收分别结束时，idleChannel在Mac1609_4 :: channelBusy和Mac1609_4 :: channelIdle功能中更新。因此，当先前发送节点发送分组时，所有接收节点将以变化的延迟接收分组，即，在不同时间开始接收并更新其channelIdle变量。之后，他们计算传输和开始传输的最佳时间。它确实检查信道是否空闲，但是当下一次接收时更新channelIdle状态，并且由于传输延迟，在发送器的发送开始和接收端的接收开始之间需要一些时间，两个发送节点都看不到其他发送。据我所知，当两个以上的节点同时开始传输时，这称为冲突。因此设置了BitError统计信息，并且还设置了statsTXRXLostPackets。因此，在计算totalLostPackets时，我们只能采用这两个值中的一个。