MAODV在ns2.30下的仿真及性能分析将MAODV在ns2.30下进行了b...b

MAODV在ns2.30下的仿真及性能分析
将MAODV在ns2.30下进行了仿真，并将单播和组播的性能进行了比较分析。

仿真中使用的参数设置如下：
仿真中首先根据以上场景文件和数据流文件生成了trace文件，但在分析trace文件的过程中，我们发现了两个问题：
一、从运行节点加入组播组的MAODV协议生成的trace文件中看到，一个节点会重复多次接收同一个数据包。

分析原因为，MAODV中，数据包在组播树中是广播的，而各节点又没有数据包接收的重复性检测机制。

例如，有三个节点A、B、C分别在相互的通信范围内，当节点A接收到一个数据包时，将其广播转发，节点B、C都可以接收到，但由于数据包要在树中广播，节点B、C又将此数据包广播出去，并被节点A接收到，而节点A没有进行包的重复性检测，因此又将此数据包接收并再次广播，直到数据包的ttl值为0。

这样造成了数据包
在组播树中的震荡，降低了路由协议的效率，增加了网络负担。

我们将对此问题进一步分析，并对MAODV进行改进，增加数据包的重复性检测机制。

二、运行节点加入组播组的MAODV协议，当加入组播组的节点个数为10时，发现从730号以后的数据包（目的节点个数为10时，源节点共发送的数据包个数为1740）都直接在源节点的路由层和MAC层被丢弃了，其它节点都没有进行接收。

用gdb跟踪730号以后的某个数据包流向，发现源节点在应用层产生这个数据包后，将其传递给了本节点的路由层，进行路由查询，且路由表中存在有效的路由，于是直接将数据包转发出去了，但在调用了forward函数的Schedule函数后，其它节点却没有进行接收。

而源节点又继续产生了下一个数据包，并重复上述过程。

因此，当目的节点个数为10时，组播的分组投递率很低。

目的节点为其它个数时没有出现这个情况，因此投递率都较高。

参考了别人的分析文件，发现他们针对组播，也只对各节点第一次接收到的数据包进行了统计，而没有统计以后接收到的重复包。

因此，我们也先按照这个思路编写了awk分析文件，对单播和组播的分组投递率、分组端到端的平均时延以及路由协议的效率（目的节点正确接收到的数据包的个数/ 路由层共发送及转发的控制包的个数）进行了比较。

仿真结果如下：
图1 分组投递率的比较
图2 分组端到端的平均时延比较
图3 路由协议效率的比较
从仿真结果来看，maodv在进行组播数据传输时的分组投递率除目的节点个数为10时，其余都在94%以上，而分组端到端的平均时延则保持在0.02s左右，相对单播数据传输，性能有很大的提高，特别是时延的性能。

从图3可以看到，maodv进行组播数据传输时的路由效率低于单播数据传输，这是因为我们在统计目的节点正确接收到的数据包时，只统计了各节点第一次收到的数据包的个数，而没有统计后来重复接收到的同一个数据包，因此得到的结果较差。

另外，由于数据包在树中不停的震荡广播，也增加了网络的负担。

从仿真结果可以看到，单播数据传输时网络的性能很差：分组投递率很低，且随着目的节点个数的增加而逐渐降低；分组端到端的平均时延随着目的节点个数的增加而急剧上升，且数值很大。

分析原因有两个：1、单播时，源节点要根据目的节点的个数将一个数据包复制多份分别发送至每一个目的节点，随着目的节点个数的增加，数据源数目也不断增加，极大地增加了网络拥塞，增加了分组传输中的碰撞，降低了分组投递率，增加了传输时延。

2、单播数据传输时，我们设置的数据流文件与实际情况不太一致：实际中应该是源节点将每一个数据包复制多份，分别寻找路由发送给各目的节点。

而仿真中，由于在tcl文件中是直接对数据流进行操作，而不能具体对每一个数据分组操作，因此，我们在发送组播数据时，使源节点只发送了一个cbr流，将其发送给各目的节点；而单播时，源节点产生多个cbr流，每个cbr流分别连接一个目的节点。

这样与实际中每个目的节点应该收到的总的数据包总个数是一致的，但我们在启动数据流时，同时启动了所有的cbr流，就造成了分组传输中的严重碰撞，使投递率与时延性能都很差。

在以后的仿真中数据流的启动应该间隔一定的时间。

总之，当源节点要将同一数据发送至多个接收者时，采用组播方式能充分地利用无线传输的广播特性，创建和维护一棵包含所有参与通讯的节点的组播树，这样，源节点只需发送一份数据即可传送至所有的接收者，提高了路由协议的性能。