利用NS2(Network Simulation version 2)[1,2]的开源和可扩展特性，研究者通过自行开发和加入新功能对特定类型的多信道协议进行仿真，从而取得了一定的研究成果。这些研究成果包括MITF、TENS、Hyacinth、Ramon 和MMSM等多信道扩展方案。这些方案具有各自的优点，同时在某些方面并不是特别完善，下面将对这些方案的特点及优缺点作简要的概述。63005
MITF方案由巴西里约热内卢大学的科研人员在名为MITF的项目中提出。这个支持多接口的方案在NS－2.28上得到了实现。该方案的目的是实现对多接口的支持，并在此基础上采用AODV 路由协议。然而随着MITF 项目的失败，其中的多接口方案也没有获得广泛认同。但是该方案为之后的多接口多信道仿真研究提供了开阔的思路和较为新颖的想法。
TENS方案由印度Indian Institute of Technology Kanpur提出[3]。这个方案主要对NS2（version 2.1b9a）中的IEEE802.11 协议在MAC 层和物理层的实现进行了改进，同时为该版本的NS2平台引入了多信道仿真的功能。该方案采用多路复用方式通过在物理层的C++实现建立了多信道模型，其中信道的选择是通过在TCL脚本中指定一个信道号参数实现。另外，该方案通过修改TCL 源文件，将完整的物理层复制了多份，从而把多个信道相关组件组合到了一个节点中，这个独特的思路和做法对后来多信道模型的研究具有一定的启发性。但是TENS多信道模型的主要目标在于能够仿真出被IEEE802.11 协议使用的多个信道间的干扰，因此实现机制上与NS2已实现的802.11 协议密切相关，通用性较差。
Hyacinth方案最初由纽约州立大学的研究人员提出并在NS2(version 2.1b9a)上实现[4]。与前面TENS方案针对MAC协议相比，Hyacinth 方案的目标是实现对特定多信道路由协议的仿真，因此对接口扩展时涉及的协议层次更高，修改内容也更广。该方案建立了针对特定路由协议的多信道仿真模型，为多信道路由协议仿真的方式做出了极有意义的贡献，同时这个模型也满足路由协议的静态分配信道策略[5]。美中不足的是该方案中单个节点支持的多接口个数最多为5个，而且其信道配置方式为静态配置，不易于灵活使用。此外其多信道的实现机制严重依赖特定的静态路由协议，所以不能够扩展成为更通用的多信道多接口仿真模型。
Ramon方案由University of Cantabria 的Ramon Aguero Calvo 和Jesus Perez Campo 两位学者提出并在NS2(version 2.29)上实现[6]。这个方案同样也是针对多信道路由协议的仿真。该方案大部分的修改都集中在TCL源码中，采取与Hyacinth 方案相似的思路，以在移动节点的构建阶段复制网络接口中所有组件的方式来实现多个接口，同时将这些接口连接到一个路由代理上。这样可以让路由协议能够直接使用和管理这些接口，从而可以仿真并支持多接口多信道的路由协议论文网。目前由于该方案的灵活配置能力和可扩展的实现机制，使其具有的较好的通用性，很多科研人员采纳了Ramon方案并将其应用在相关项目的研究。
多信道MAC仿真模型（Multi-channel MAC Simulation Model，MMSM）[7]实现在NS-2.29版本。与前面几种方案不同，该方案主要以MAC 层的多信道协议作为仿真对象。为此，MMSM将移动节点模型中与信道直接相关的各个组件（Channel 和NetIF）复制多份，通过修改TCL 和C++源代码将其组合到一个节点中，并使这个节点接受MAC 协议组件的控制。MMSM对相关源码的修改思路类似于Ramon方案，即通过在TCL源码中定义信道数变量和相应接来配置信道，并通过修改create-wireless-node 和add-interface 等函数使其使用循环语句复制和连接组件。两种方案的主要区别在于涉及的协议层次和组件底层不同。与Ramon模型相比，MMSM 多信道模型最大的不同在于它具有唯一的MAC 协议实体，而前者具有多个MAC 实体。MMSM 中唯一的MAC 实体控制了一组NetIF 组件，并且每个NetIF 组件又连接了一个特定信道。因为NetIF 组件是作为移动节点访问信道时的接口，所以其数量就等于所在节点能够访问的最大信道数量。所有的NetIF组件再加上其唯一的MAC、IFQ和LL等部分,共同组成一个多信道的网络接口卡；由于信道的分配算法是在MAC层实现，MAC 层以上协议实体基本不受多信道环境的影响，故无需改动即可正常工作。由此可见，MMSM 模型适用于MAC多信道协议的仿真[8] 。 多接口多信道(MCMI)网络的研究现状:http://www.751com.cn/yanjiu/lunwen_69371.html