OMNeT++下Veins的veins_inet仿真超18节点无包交换问题求助

该问题是veins_inet示例扩大车辆规模时的典型配置缺陷，按以下优先级排查修复即可：

• 优先排查IPv4地址池耗尽问题
  veins_inet基于INET协议栈实现数据包路由，示例默认配置中Ipv4NetworkConfigurator为车载子网分配的是10.0.0.0/28网段，该网段仅能提供14个有效单播地址，叠加RSU、广播地址、网络地址预留，总可分配节点数刚好在17~18个区间耗尽。后续入场的车辆无法拿到有效IPv4地址，网络层会直接丢弃所有上层生成的报文，也不会转发任何入站报文，表现为全场景无数据包交互。
  修复配置：在omnetpp.ini中添加/修改如下参数，调整后可支持65000+节点同时在线，覆盖千级车辆测试需求：

  *.configurator.networkAddress = "10.0.0.0"
  *.configurator.netmask = "255.255.0.0"
  

• 其次排查ConnectionManager邻接表容量限制
  Veins 5.0~5.2版本中，ConnectionManager模块的maxNumNeighbors参数默认值为20，当场景内节点数超过该阈值后，模块会停止计算新增节点的信号邻接关系，物理层无法感知其他节点的信号，自然不会触发收发流程。
  修复配置：在omnetpp.ini中显式调大该阈值：

  *.connectionManager.maxNumNeighbors = 2000
  

• 最后排查MAC层队列溢出问题
  示例默认配置的802.11p MAC层发送队列长度仅为10，节点数升高后信道竞争加剧，队列占满后默认会直接丢弃所有新增报文且不向上层反馈。可通过Qtenv启动仿真，在节点数达到18时随机点开一个车辆节点的nic.mac1609_4模块，查看txQueueLength统计量是否打满、droppedPacketsQueueFull计数是否持续上涨。
  修复配置：调大队列长度并适配竞争窗口参数：

  *.nic.mac1609_4.txQueueLimit = 100
  *.nic.mac1609_4.cwMin = 15
  *.nic.mac1609_4.cwMax = 1023
  

• 有效性验证
  修改配置后先启动30节点规模的短仿真，随机选取节点查看两个统计量：一是应用层sentPackets、receivedPackets是否随仿真时间正常增长；二是IPv4模块的droppedPacketsNoRoute计数是否为0，确认地址分配、邻接计算均正常后再跑全量1000节点场景。

内容的提问来源于stack exchange，提问作者R_S