此次的工作主要是在NS2原有模块的基础上添加多接口，实现多信道数据传输。
大部分的修改是基于”Adding Multiple Interface Support in NS-2”(Ramon Agiiero Calvo), 但还是对其中的一些代码做了部分修改。本次的修改说采用的版本是NS2.33。（曾经在很多个版本上进行过实验，但是效果都不好，或者是结果出不来）
一 代码的添加及修改（所有具体的修改和添加见上述文档）
1 、TCL代码的修改
ns-lib.tcl(listing 3.1, 3.2, 3.3, 3.4, 3.5, 3.6):
在该文件中添加了change-numifs, add-channel, get-numifs及添加ifNum变量。其中change-numifs是改变接口的数量；add-channel是增加一个接口到节点，如果需要多个接口需要循环使用该语句；get-numifs是获取脚本中的说设定的接口的数目；ifNum变量的添加是为了在脚本中设置接口的数量。
对于该文件的修改部分是在node-config及create-wireless-node这两个程序中。在node-config中添加了numifs_变量及做了初始化信道的工作。在create-wireless-node中，仍然是numifs_变量的添加，及其增加接口的修改。
ns-mobilenode.tcl(listing 3.7, 3.8, 3.9, 3.10, 3.11)：
在这个文件里没有新的程序需要添加，只需做一些修改。第一个修改的是add-target，在这段代码中前面添加的get-numifs被用到来确定我们应用了多接口的扩展并获取所设定的接口数。接着这个程序中的路由代理命令if-queue也被修改来适应多接口。
第二个被修改的add-target-rtagent，这个程序也用到了get-numifs来获取接口的数量，然后利用这个变量来连接路由代理和链路层。在add-target和add-target-rtagent中都定义了一个新的变量numIfsSimulator来保证模拟器单信道时也正常工作。
第三个需要修改的是add-interface, 因为原来的该程序中只给每个节点创建了1个ARP，而我们需要的是给每个接口创建一个ARP。因此将原有的arptable_该为了数组arptable_($i)。
最后的修改是为了节点的创建和重设。因此修改是在init和reset部分。
2、C++代码的修改
mobile.[h.cc](listing 4.1, 4.2, 4.3):
在头文件中，修改了两个数组指针nextX_[MAX_CHANNELS], prevX_[MAX_CHANNELS]来管理过个信道。然后由于运行过程中的错误，对方法变量getLoc做了修改，在头文件中将它定义为一个普通变量，然后在.cc中进行重新定义命令。
channel.cc(listing 4.4, 4.5):
由于前面定义的两个数组指针需要在这个文件中运用，所以这该文件中也应做相应的修改，将所有nextX_, prevX_改为nextX_[this->index()], prevX_[this->index()]。当一个包被发送的时候，第一步需要做的就是评估哪个节点和源节点离的最近，并且已经与将被用到的信道连接上。然后包能够被发送到目的节点的所有接口。但是这样做意义不大，因为包仅仅只能被连接到对应信道上的接口接收。所以我们不得不添加一种新的过程来检测发送方和接收方的接口所使用的信道是同一个。该代码中添加了一句“if(rifq->channel() == this)”。
mac-802_11.cc(listing 4.6):
这一部分的修改是为了选择接收信息的接口。“hdr->iface() == addr();”被添加到该文件中。
3、路由协议代码的修改
路由协议的修改主要是为了应用多接口的扩展，这一部分的修改主要是以AODV为蓝本来修改，也可以说是在AODV协议的基础上扩展多接口。该协议的修改主要是为了验证多接口是否工作，或者有什么优势。对AODV文件夹中的：aodv.h, aodv.cc, aodv_rtable.h, aodv_rtable.cc进行了部分修改。
aodv.h(listing 5.6, 5.7, 5.8):
首先是在aodv类声明中定义了一个新的常量MAX_IF，这个常量在后面声明指针的时候被用到，这些指针的作用是管理target list和interface queue list。
还需要增加一些新的成员nIfaces, targetlist[MAX_IF], ifqueuelist[MAX_IF].
另外每个路由表必须与一个指针相结合，这样路由代理就能够选择包从哪个接口被转发，因此需要修改rt_update被被调用的方式。
aodv.cc(listing 5.9~5.17):
对AODV部件做一些改变，对nIface进行初始化。
还有就是在sendRequest, sendError, sendHello这几个程序中所做的一些修改，让其应用多接口的扩展。
修改sendReply, forward方法，这些都包含一些单播及广播机制。在这两个程序中，我们改变了路由表说提供的Iface指针。但是在Ramon的原始的文档中在forward这段程序中所提到的Iface指针在编译的过程中会报错，因为没有对其进行定义，所以在和Ramon教授交流了之后将其在forward中的Iface改为rt->rt_interface，然后编译通过。
为了正确的管理路由表，在任何时候路由表加入一个节点，我们必须包含与这个节点相对应的接口的信息。因此我们必须对相应的recvRequest和recvReply方法做一定的修改。需要注意的是我们还需要修改路由表维护过程，因为我们不得不将接口作为一个变量包含到rt_update方法中。
最后我们还必须修改re_update方法，以适应前面的修改。
这是根据文档所做的修改，但是在文档中aodv.cc部分缺少了对路由代理类中的command方法的修改，在一部分可见Listing 5.2。在与作者联系后，作者也发现了这个纰漏，然后更新了网上的该文档。这一部分对应于ns-mobilenode.tcl中所改的add-target, add-target-rtagent程序中的“$agent if-queue $i [$self set ifq_($i)]”，“$agent target $i $sndT”和“$agent target $i [$self [$self set ll_($i)]”。
Aodv_rtable.[h,cc](listing 5.18, 5.19):
正如前面介绍过的路由表的维护方法必须根据多接口的扩展做相应的改变，唯一需要做的修改添加一个路由表入口的接口部分（aodv_rt_entry）。
为了保证正确的运行，我们还需要在通信构造函数中初始化这个成员为255。
二 脚本的编写
在脚本编写的过程中就需要体现前面所做的修改。在模拟变量初始化的过程中需要定义接口的数目。在创建无线信道的过程中，这时的信道就需要用一个数组来代替了，因为这个需要创建多个信道。对god的初始化也相应发生一定的变化。在node-config中必须在最后添加接口在前面的定义：-ifNum $val(ni)。需要特别注意的是创建节点，在创建节点时我们可以创建具有相同接口的节点，也能够创建不同接口的节点，并且在分配信道的时候需要注意。
为了充分展示多信道的优势，也为了方便测试，我们的脚本场景如下：创建3个节点，3个节点位置固定，并保证之间的距离是0节点只能通过1节点中继才能与2节点通信，0节点和2节点有1个接口，1节点有2个接口。创建两个信道，0节点和1节点利用0信道传送数据，1节点和2节点用1信道传送数据。采用的是UDP连接cbr流，数据包大小512byte,发送间隔0.005秒。
作为对比另一个脚本也是3个节点，但是三个节点都是使用原始接口和信道，也就是单接口单信道，其他场景设置与上述脚本相同。
三 仿真分析
通过仿真得到nam动画文件如图所示：
该实验通过分析节点吞吐量，收包率，及延时来比较多接口与单接口的性能。
计算吞吐量的原理，只要统计出一定时间内网络（或某节点）成功发送（或接收）的数据量，除以这个时间就得到吞吐量。由于我们所设场景比较简单，所以我们可以直接用2节点成功接收的数据量除以我们仿真所用的总时间来分析吞吐量。这里test_3.tcl所采用的是多接口，test_ma3.tcl所采用的是单接口。
由上图分析可知：对于多接口场景，所接收的数据包的个数为32834，吞吐量为698kbps。对于单接口场景，所接收的数据包的个数为16328，吞吐量为347kbps。很明显可以看出两信道的吞吐量大约是单信道的2倍。
(1)接下来分析的是多信道的投递率：接收数据包的数目/发送数据包的数目。所做的分析见下图。
从图可得到，对于场景一：发送数据包数目为39801，接收数据包数目为32834，投递率为0.8250；对于场景二：发送数据包数目为：39801，接收数据包数目为16328，投递率为0.4102. 明显的，多信道投递率是单信道的2倍。
(2)端到端延时的计算思想如下：首先提取trace文件中定义的相互通信的节点对，将pi号相同的记录中的时间域相减，即得该通信节点对发送数据包的延时，取所有通信对发送延迟的平均可得网络的平均延时。实验对比如图所示。
上图中，红色小点代表的是多接口多信道在传输数据过程中的时延，绿色小点代表单接口单信道的时延。从图可一明显看出多接口时延大概是单接口时延的1/2。
从上面的分析可以得到的结论：多接口扩展在单接口的基础对网络的性能有比较明显的提高。
