UnetStack多跳仿真端到端时延计算及相关异常问题咨询

1个DatagramReq对应多个TxFrameReq的原因 #

这是链路层可靠传输机制触发的正常现象，本质就是单个数据包被多次重传：

• DatagramReq是网络层提交给链路层的发送请求，代表上层仅要求发送1个完整IP数据包；TxFrameReq是链路层通知物理层实际执行帧发送的动作事件，每触发一次发帧（不管是首次发送还是重传）就会生成一条对应记录。
• 出现这种多对一的匹配关系，基本都是仿真配置中开启了MAC层ARQ自动重传机制：Node-B第一次向Node-C发送数据帧后，如果在超时窗口内没有收到Node-C返回的ACK确认帧（要么是数据帧因信道干扰、信号冲突、信噪比不足直接丢失，要么是ACK回传过程中丢失），链路层就会重新触发该数据包的发送流程，生成新的TxFrameReq记录，直到收到对端ACK、或者达到最大重传阈值后丢弃数据包为止。
• 你可以直接在trace文件中提取第2、4个数据包的全流程记录，核对第一次TxFrameReq之后Node-B有没有收到对应ACK的RxFrameNtf记录，即可验证该结论。

多次重传场景下的端到端时延正确计算方式 #

端到端时延的统计和中间节点重传次数没有直接关系，不需要纠结中间实际发送了多少次帧，只要锚定两个首尾时间点直接做差即可：

• 起点统一取Node-A应用层第一次生成该数据包、向下层递交发送的时间戳，也就是trace中Node-A侧对应该数据包ID的最早发送事件时间，不要取链路层的发帧时间、某一次重传的时间作为起点，避免漏掉源节点的排队、协议处理时延。
• 终点统一取Node-C收到完整、校验通过的数据包，向上层应用递交的时间戳，不要取收到错误帧、重复冗余帧的时间作为终点，也不要取链路层刚收到帧还未完成校验重组的时间凑数。
• 中间所有重传、排队、冲突退避消耗的时间，本身就是端到端时延的合法组成部分，不需要额外剔除。

超15秒时延的合理性&现有计算方法校验 #

你当前采用的「Node-C侧RxFrameNtf时间减去Node-A侧数据包发送时间」的计算逻辑大方向是正确的，但15秒的时延在你这个场景下明显不符合预期，按以下顺序排查即可：

1. 先核对时间锚点的匹配是否正确
   首先确认做差的两个时间戳是否对应同一个数据包ID：如果包ID匹配错位（比如拿Node-A发送第1个包的时间，匹配Node-C接收第4个包的时间），或者错误取用了Node-A重传队列中缓存包的时间、Node-C收到乱序重复帧的时间，计算结果会完全失真。
2. 如果时间锚点匹配无误，15秒时延说明仿真配置存在错误
   你的场景发包间隔仅为5秒，正常端到端时延应该在毫秒到秒级，超过15秒基本是三类配置问题导致：
   • MAC层队列缓存配置过大：Node-B的MAC层发送队列长度设置不合理，数据包在队列中排队等待时间过长，叠加重传退避时间很容易堆出超高时延；
   • 信道/物理层参数配置错误：比如节点传输功率设置过低、节点间距过大、信道衰落模型/干扰模型参数不符合预期，导致链路误码率极高，单个数据包需要十几次甚至几十次重传才能成功送达，重传的超时退避时间累计后很容易超过10秒；
   • 转发逻辑存在bug：检查Node-B的转发代码是否存在路由环路、重复转发的问题，导致数据包在节点间来回绕转多次才送达目的节点。

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