其实早就听说TeX了，ChinaTeX的光盘也早就有了，但是一打开.tex源文件——晕过几次就放弃了。
不过这都是过去了。
专业外语必须交一篇专业论文的翻译，又一次打开MS Word，开始写标题，又一阵恶心涌上心头，想起最近给别人翻译另一篇英文资料时的情形，光是统一字体和格式就费了不少劲，也许是我不懂得如何使用VB宏命令？？我决心用半天时间学一下TeX，买了本书《LaTeX入门与提高》（基于天元系统的）--陈志杰，然后开始翻书。虽然不是很厚的一本书，但是我很快陷入了语言的细节，我很快发现我只是在不自觉地往脑子里塞TeX的宏命令而已。看完第二章“准备工作”，我回到了目录，今天全部看这些没有必要了，我只不过写个article，而且没有多么复杂的数学公式……接下来顺利多了，我只看觉得有用的部分，很快知道了TeX的工作原理和编写格式和常用写法，然后——完工！
总结下来，看这样的工具性的东西，就是实用主义。当然先要从网上狂google一顿，从专业网站或者爱好者的个人网页上取得最直观的印象和最中肯的评价，然后确定自己想要的目标，接下来，选择最简单的方案，使用最简单的工具，学习最简短的pdf，最后是一个安静的环境，一般不需要半天，这种临时性学习就可以应付各种情况了。今天是成功案例一。
（希望明天有时间把note贴上）
练习
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% @author: chenjunwen Dec,14th,2005
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%
%% LaTeX + CJK 模板，只针对 A4 纸的中文Paper。
% 文章模板：A4 纸，小五字，单列（可根据要求改双列 twocolumn）
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
/documentclass[a4paper,11pt,onecolumn,twoside]{article}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% packages
% 这部分声明需要用到的包
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
/usepackage{CJK} % CJK 中文支持
/usepackage{fancyhdr}
/usepackage{amsmath,amsfonts,amssymb,graphicx} % EPS 图片支持
/usepackage{subfigure} % 使用子图形
/usepackage{indentfirst} % 中文段落首行缩进
/usepackage{bm} % 公式中的粗体字符（用命令/boldsymbol）
/usepackage{multicol} % 正文双栏
/usepackage{indentfirst} % 中文首段缩进
/usepackage{picins} % 图片嵌入段落宏包 比如照片
/usepackage{abstract} % 2栏文档，一栏摘要及关键字宏包
%/usepackage{latexsysm,bm}% 嵌入数学符号
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% lengths
% 下面的命令重定义页面边距，使其符合中文刊物习惯。
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
/addtolength{/topmargin}{-54pt}
/setlength{/oddsidemargin}{-0.9cm} % 3.17cm - 1 inch
/setlength{/evensidemargin}{/oddsidemargin}
/setlength{/textwidth}{17.00cm}
/setlength{/textheight}{24.00cm} % 24.62
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% 定义标题格式，包括title，author，affiliation，email等。
% 在任何用到中文的地方，用/begin{CJK} ... /end{CJK}将其括起来。
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
/renewcommand{/baselinestretch}{1.1} %定义行间距
/parindent 22pt %重新定义缩进长度
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% 标题，作者，通信地址定义
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
/begin{CJK}{GBK}{song}
/title{
/huge{模拟与仿真//评价移动点对点网络路由协议}}
/author{Furqan Haq and Thomas Kunz//[2pt]
/normalsize
（卡林顿大学系统与计算机工程系，加拿大,~渥太华市） //[2pt]
/email{ haq/_{}furqan@hotmail.com, tkunz@sce.carleton.ca} //
/begin{flushright}//
翻译：juzi/email{Junwen.Chen@gmail.com}/end{flushright}}
/date{} % 这一行用来去掉默认的日期显示
/end{CJK}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% 正文两栏环境不允许float环境，比如 figure, table。所以重新定义
% figure，使之可以浮动到你想要的位置。table也同样，把figure改为
% table就可以。
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
/newenvironment{figurehere}
{/def/@captype{figure}}
{}
/makeatother
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% 文章正文
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
/begin{document}
/begin{CJK*}{GBK}{song}
/CJKcaption{GB}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% 自定义命令
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% 此行使文献引用以上标形式显示
/newcommand{/supercite}[1]{/textsuperscript{/cite{#1}}}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% 显示title，并设页码为空（按杂志社要求）
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
/maketitle
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% 文章编号(左上角)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
/begin{minipage}[c]{10cm}
/vspace{-35.5cm} 文章编号~~~~1005$-$0388(2004)05$-$0505$-$04
/end{minipage}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% 正文由此开始－－－－－－－－－－－－－－－－－－－－－－－－－
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% 恢复正文页边距
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
/setlength{/oddsidemargin}{-.5cm} % 3.17cm - 1 inch
/setlength{/evensidemargin}{/oddsidemargin}
/setlength{/textwidth}{17.00cm} /CJKfamily{song}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% 分栏开始
/begin{multicols}{2}
/CJKfamily{hei}
/section{摘要}
/CJKfamily{kai}为了使模拟研究有实际意义，使模拟的结果尽可能地接近试验台的结果意义重大。
本文将比较基于NS2和GloMoSim的仿真试验台结果和模拟结果，路由协议为OLSR，
采用NRL移动网络仿真器（MNE）来进行动态拓扑控制和处理，
由五台基于膝上电脑，装有IEEE~
802.11b无线网卡的Linux系统在试验台实现。在低通信量时，试验台结果能跟模拟结果吻合；
在高通信量时，试验台结果不仅在性质和数量的方面不同于模拟结果，而且在某些情形下两个
模拟器的结果几乎不具有可比性。
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
/CJKfamily{hei}
/section{引言}
/CJKfamily{kai}网络工程师通常使用模拟工具来调试和测试网络协议和硬件设备的
可靠性和服务质量QoS。这使模拟器成为部署无线网络重要的一步。当然，模拟器只有在模拟结果
尽可能的吻合实验结果时才是有用的。随着商用无线装置如IEEE~
802.11和蓝牙技术的发展，传统的有线网络正在向无线网络过渡。在一个无线区域中，
可移动的点对点网络，凭借其灵活性，动态性，自我恢复性，自我维护性而
变得越来越流行。/par
尽管在移动无线网络领域已经有了很多的技术成果和前沿研究，人们仍然对无线网络模拟器
获得的结果的可靠性持有怀疑。
/CJKfamily{hei}
/section{相关研究}
/CJKfamily{kai}这里有一些讨论模拟结果精确性和无线网络模拟器模拟结果结果差异的论文。/par
分布式系统实验室的Ecole Polytechnique Fé dé rale de Lausanne
发表了一篇有影响的论文，比较了OPNET，NS2和GloMoSim的模拟结果。
他采用IEEE~802.11~MAC协议实现和一种非常简单的浸透算法来模拟
一个具有50个移动节点的无线点对点网络。根据论文，
采用不同的模拟器会使结果有着极大的不同，在某些情况下结果
甚至是没有可比性的。论文还提到，现在还缺少能够展示无线网络模拟器正确性的
现实试验/supercite{DYA}。论文极大的激发了我们使用各种可用的工具来做模拟并
跟试验台结果比较的兴趣。/par
Kunz比较了MANET模拟结果跟试验台结果，他使用的是一种多播路由协议BCAST。
根据他的发现，在一个静态的环境里，二者的结果都差不多，移动模拟器会有
一个可以忽略的超前时间。然而，在移动环境中，他在仿真环境中使用的测量尺寸
不管在性质上还是在数量上和仿真试验台的结果都有着很大出入。
根据报告，像MNE这样的工具可以帮助调试和测试真实试验台中的的协议，
但是我们并不清楚这些工具是否适合用来对协议进行性能评估/supercite{Kunz}。/par
基于上述两项研究项目的发现，我们计划实现更为详细和细致的模拟和仿真试验。
为了确保结果的可靠性，我们采用了不同的通信量模型和高度动态的网络拓扑结构。/par
项目的主要目标是找出模拟和仿真过程中哪个环节导致了结果的显著差异，从而制定出
是否/如何仿真的指导性原则，找到一种研究协议性能的合适途径。
/CJKfamily{hei}
/section{OLSR协议}
/CJKfamily{kai}最优链路状态路由协议（OLSR）（RFC~
3626）是一种前向路由协议，它使用链路状态模式，以一种优化的方式来传播拓扑信息。
多跳点（multi-hop）的无线网络使用优化的OLSR消息流来保证带宽。“优化是
通过一种叫做多点中继的技术获得的，多点中继（MPR）的思想是通过
将控制信息限制到选中的节点来最小化消息流的过载”/supercite{NWG}。
/CJKfamily{hei}
/section{MNE}
/CJKfamily{kai}MNE是为基于Linux的、具备IPTABLES网络过滤功能的分布式环境而设计的。
当数据包经过时，数据包过滤器检查每个包的头部，根据用户定义的规则决定
数据包是应该接收来进行进一步的处理，还是应该丢弃。数据包过滤通常用于网络安全、控制和监控。
MNE利用IPTABLES的这些控制特性来阻塞来自某个特定节点的数据包。这种阻塞将
作用在整个无线链接范围，在MNE中，来自被认可范围之外的所有节点的数据包将会
被IPTABLES过滤组件阻塞。/supercite{WJJ}/par
控制模块为节点的本地信息的发送提供一条反馈信道。本地更新信息通过广播信道
（这也被认为是反馈信道或者可控网络）不断地发送到网络中的所有节点。
有线和无线接口都可以用来发送本地更新信息，但是在同一物理信道上
发送这两种信息（动态拓扑信息和用户信息）会造成拥塞。在我们的实验中，
有线接口用来广播本地更新信息来避免无线信道上的拥塞。/par
MNE支持多种不同的节点行为仿真，包括队列，随机行为，ns2，静止，共线和循环。
在MNE中，NS2行为文件可以直接使用。MNE的MOVE模块以纵坐标和横坐标的形式
提供本地信息，这种信息将以通过上述的控制网络发送到所有节点。/par
网络中的每一个节点在反馈信道上以无线网卡的MAC地址来广播自己的本地信息。
动态模块利用这种信息来计算节点之间的距离并进行过滤。MAC地址将用来
阻塞来自某个特殊节点的数据包。/par
/begin{center}
Sorry,I can't insert figures here.:(
/end{center}/par
/begin{center}
Sorry,I can't insert figures here.:(
/end{center}/par
上图显示t=0,/ 180,/ 300和400时的节点方位。在情形一中，t=0时，节点
/begin{math}/ n_0/ /end{ math}和/begin{math}/ n_1/ /end{math}在
各自的直接联络范围之内，/begin{math}n_{4}/
/end{math}和/begin{math}/ n_{3}/ /end{math}也
能发送和接收数据包，而/begin{math}/ n_{2}/ /end{math}在范围之外。
紧接着t=0，所有节点开始移动，当t=180s时，他们的位置如情形二所示。
在情形二中，节点/begin{math}/ n_{1}/
/end{math}不能和/begin{math}/ n_{4}/ /end{math}直接联络，而必须通过一个中间节点；反之亦然。
这样就建立一个2-hop的通信网。在这个情形中，任何节点（/begin{math}n_{0},/
n_{2},/
n_{3}/end{math}）都可以选作MPR来中继所有的数据包。情形三和四是为模拟多跳通信设计的。
/CJKfamily{hei}
/section{模拟模型}
/CJKfamily{kai}NS2/supercite{ISI}是一个针对Linux的离散事件模拟器之一，
它可以定义各种不同的情形。NS2依赖于一些外部组件，如Tcl，otcl和TclCL。
仿真通过TCL程序来定义，而拓扑结构由ns命令来定义。NS2能用来模拟无线和有线网络。
NS2包括一个IEEE~
802.11模块，一个实现了点对点Ad-Hoc路由协议的协议栈，
这使得它成为移动和点对点网络的理想模拟器。/par
GloMoSim是一个可扩展的模拟环境，适用于无线和有线网络系统，由UCLA的
并行计算实验室设计/supercite{UCLA}。GloMoSim能用来模拟为数众多的
无线网络协议。它的协议栈包括信道、无线电、MAC、网络层、传输层以及更高层的模型。/par
许多研究组织已经为这两个模拟器开发出公开的、可用的OLSR模型。我们将这些模型
集成到NS2和GloMoSim中，并且确保对所有的协议参数（如HELLO消息的周期）使用常量。/par
我们的模型中使用了五个移动节点。MAC层和LLC层在NS2中实现，采用GloMoSim
IEEE~
802.11协议。接口队列是一个100个数据包大小的在尾部删除的队列，还使用了一个
具有单元增益的全向天线，一个用于无线电发射的双射线的背反射模型。/par
/CJKfamily{hei}
/section{通信量模型}
/CJKfamily{kai}网络使用CBR代理来产生通信量。下表显示了所有实验中
使用的数据包的大小和每秒钟发送的数据包的个数。/par
%
% for graphics
%
/begin{center}
Sorry,I can't insert figures here.:(
/end{center}/par
每一个节点的CBR连接到其它所有的节点，从而组成一个网状网络。所有的链路都是双向的。
传输层使用用户数据报协议（UDP）来最小化建立连接所用的开销。/par
/CJKfamily{hei}
/section{实验台实现}
/CJKfamily{kai}我们使用NRL
MNE来实现动态拓扑的控制和处理。以太网接口用来广播本地更新信息，避免无线信道的拥塞。
实验中还使用了高级网络协议设计（PROTEAN）研究小组的OLSR（RFC~
3626）的实现方式。/par
Multi-Generator（MGEN
第4版）（NRL的一个开放源代码的软件）在实验中用来生成无线信道上的通信量，
并获取数据包传送的统计信息。MGEN使用UDP/IP通信量来测试和测量IP网络性能。
为确保结果的可靠性，我们仔细的选择网络设置，使它尽可能的和模拟模型中
的网络模拟器中的设置接近。/par
/CJKfamily{hei}
/section{性能比较}
/CJKfamily{kai}我们总共进行了3次模拟和测试实验。
/begin{center}
$*$低带宽（1 packet/s 128 bytes）//
$*$中带宽（10 packet/s 128 bytes）//
$*$高带宽（10 packet/s 512 bytes）//
/end{center}
在这次实验中我们关注于数据包的转发率，比较各个情形下仿真试验台节点的
接收数据包的数目和NS2和GloMoSim模拟结果。由于膝上电脑不能精确地同步，
我们没有测量数据包的延时。由于网络拓扑结构保持不变，所有协议参数
都设置成相同的值，网络中传播的控制消息的数目就具有了可比性。/par
/begin{center}
Sorry,I can't insert figures here.:(
/end{center}/par
在第一个情形中，由网络中各个节点的CBR代理分配的累计的信道带宽是20
Kb/s（ 不包括OLSR的带宽开销），可用的最大带宽是2
Mb/s。情形一的模拟结果和仿真试验台结果非常接近。
试验台节点和模拟模型中的节点的接收数据包的数目之差的平均比不到5/%。/par
%
% for graphics g1.eps, g2.eps
%
/begin{center}
Sorry,I can't insert figures here.:(
/end{center}/par
图1和2
显示了节点0和4各自的接收到的数据包数目。这种趋势表现在所有其它的节点，
而且模拟结果和仿真试验台结果在性质上和数量上都能吻合。/par
在情形二（中带宽），CBR通信代理使用的累计带宽为200
Kb/s加上路由协议需要的带宽。
当我们以因子10增加每秒发送的数据包的数目时，模拟结果跟仿真试验台结果
在数量上有了分歧。模拟结果和仿真试验台结果的差别的百分比同样也按因子10增长，
不同于情形一中的结果。因此试验台节点接收到的数据包比模拟模型中的少10倍。
不同模拟器的结果一致，而且差别少于2/%。图3显示了情形二中节点0的数据包转发率。
其它节点的结果也相似。/par
%
% for g3.eps
%
/begin{center}
Sorry,I can't insert figures here.:(
/end{center}/par
分析过情形一和二后，我们决定将数据包的大小从128 bytes增加到512
bytes。
我们想看看，当我们增加通信量负载时，试验台结果和模拟结果之间的不一致
是否存在某种套路。当以4倍于数据包大小的因子增加时，网络中的每个节点的累积带宽达到了800
Kbytes/s。
我们希望看到试验台和模拟结果的在数量上的其它变化，但是结果却出乎意料。
情形三的试验台结果在数量上和性质上跟模拟结果都有很大差别。NS2和GloMoSim的更多结果
是没有可比性的。尽管分配到节点的带宽远远少于允许的最大带宽（2
Mb/s），可是结果还是非常的不一致。/par
%
% for graphics g4.eps
%
/begin{center}
Sorry,I can't insert figures here.:(
/end{center}/par
图4－6显示了试验台和模拟实验第三轮获得的结果。GloMoSim节点收到的数据包
始终比NS2和仿真试验台节点的要多。在某些情形下，NS2比MNE收到的数据包要多；
在另外一些情形下恰好相反。/par
/CJKfamily{hei}
/section{结论}
/CJKfamily{kai}基于动态拓扑结构和该实验中用到的通信量模型，采用模拟工具NS2和GloMo
Sim得到的性能在高通信量率下，性质和具体值上都有差别。结果变量随着网络负载的增加
而持续增加。尽管在低通信量时（1 packet/s 128
bytes），仿真结果十分接近试验台结果。/par
基于实验结果，在评估MANET路由协议性能时应当谨慎使用无线网络模拟工具。
在高带宽下，无线网络模拟器结果可能不能正确地评价路由协议。然而，低带宽下
实际结果可能和模拟器结果一致。因此实验中使用的试验台是一个仿真试验台（采用MNE实现），
仿真试验台结果可能和实际试验台结果有所不同。在仿真环境中，无线节点的布置相互接近，
从而物理上会共享无线信道。在某些模拟情形下，节点超出了各自的范围而能够并行访问物理信道，
我们的仿真实验中不包括这种情形。相对于GloMoSim，NS2的结果更接近试验台结果，
特别是在高速带宽下。总的来说，使用GloMoSim来评价路由协议的性能时，跟NS2和仿真试验台的
结果相比，数据包转发率总是偏高，差别有时候甚至超过了100/%。
/CJKfamily{hei}
/section{下一步的工作}
/CJKfamily{kai}在实验中，我们仅注意数据包的转发率，没有考虑数据包延时，
这是因为点对点方式（Ad--Hoc）使得要时钟同步很难。有人提出了一些时钟同步算法，
如Kunz和Carlos提出了一种时钟采样的相互网络同步算法，适用于无线网络和Ad--Hoc网络
/supercite{CT}。在以后的工作中，我们将实现时钟同步算法来比较数据包的延时（
在NS2，GloMoSim和试验台中）。/par
本次试验中采用的试验台是一个仿真试验台，当前我们正着手校园内一个实际的Multi--hop无线试验台，
我们计划将来对它进行性能研究。这些结果然后可以用来跟仿真试验台和模拟器结果比较，
并采用多种通信量模型。现实试验台的不足之处在于，要探索大量不同的动态拓扑结构很难，
所以我们想决定哪一种工具（NS2，GloMoSim，还是仿真器）能够更精确的预测实际实验台结果。
最后，我们在实验中使用了OLSR路由协议，以后在试验台中将采用AODV或者DSR协议，
并比较实验结果。FTP，TELNET，VoIP等其它通信模型也将要进行测试。/par
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% 参考文献
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
/small
/begin{thebibliography}{99}
/setlength{/parskip}{0pt} %段落之间的竖直距离
/bibitem{DYA}D. Cavin, Y. Sasson, A. Schiper,“关于MANET模拟器的精确性”, Distributed Systems Laboratory Ecole
Polytechnique Fédérale de Lausanne, in Workshop on Principles of
Mobile Computing 2002, Toulouse, France.
/bibitem{Kunz} Thomas Kunz, “实现与模拟：MANET多播协议的评估”,in Proceedings of the Global
Mobile Congress 2004, Shanghai, China, pages 129-134, October 2004,
Delson Group 2004.
/bibitem{NWG}Network Working Group, The Internet Engineering
Task Force, 最优链路状态路由协议, January 2005,
http://www.ietf.org/rfc/rfc3626.txt?number=3626.
/bibitem{WJJ}W. Chao, J. Macker, J. Weston,“移动网络模拟器”,Communication Systems Branch Information Technology
Division Navel Research Labaratories, Washington, DC, USA, January
24, 2003.
/bibitem{ISI}Information Sciences Institute USA Viterbi School of
Engineering,“网络模拟器-NS2”,September 2004
http://www.isi.edu/nsnam/ns/.
/bibitem{UCLA}UCLA Parallel computing laboratory, University of
California ,“关于GloMoSim”,September 2004
http://pcl.cs.ucla.edu/projects/glomosi.
/bibitem{CT}Carlos H. Rentel and Thomas Kunz,“针对和点对点网络的时钟采样互同步网络算法”,Proceedings of the IEEE Wireless Communications and
Networking Conference 2005, New Orleans, USA, March 2005.
/end{thebibliography}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% 分栏结束
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
/end{multicols}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% 文章结束
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
/clearpage
/end{CJK*}
/end{document}
Simulation vs. Emulation:Evaluating Mobile Ad Hoc Network Routing Protocols
Furqan Haq and Thomas KunzSystems and Computer EngineeringCarleton UniversityOttawa, Ont., Canada K1S 5Bhaq_furqan@hotmail.com, tkunz@sce.carleton.ca
Abstract
In order for simulation studies to be useful, it is very important that the simulation results match as closely as possible with the testbed results. This paper compares emulated testbed results with simulation results from NS2 and GloMoSim. OLSR was used as a routing protocol and NRL Mobile Network Emulator (MNE) for dynamic topology control and manipulation. Five linux based laptops, equipped with IEEE 802.11b wireless network cards were used for testbed implementation. At low traffic rates, testbed results matched closely with the simulation results, at higher traffic rates, testbed results not only differed from the simulation results both qualitatively and quantitatively but the simulation results from both the simulators were barely comparable in some scenarios.
Introduction
Network engineers use simulation tools to debug and test the reliability and QoS of network protocols as well as hardware equipment. This makes simulation a very important step towards the deployment of wireless communication networks. A simulation is only useful if the simulation results match as closely as possible with the testbed results.
With the popularity of commercial wireless devices such as IEEE 802.11 and Bluetooth, a transition is taking place from traditional wired networks to wireless networks. In the wireless domain, Mobile Ad-hoc networks are getting more and more popular due to their flexible, dynamic, self-healing and self-configuring nature.
In spite all the technological achievements and cutting edge research occurring in the field of mobile wireless networks, there are growing concerns regarding the reliability of results generated by wireless network simulators.
Related Work
There are very few papers discussing the accuracy of simulation results and the variation of the results among different wireless network simulators.
An interesting paper published by Distributed Systems Laboratory, Ecole Polytechnique Fédérale de Lausanne, compares the simulation results of OPNET, NS2 and GloMoSim. IEEE 802.11 MAC implementations and a very simple flooding algorithm were used to simulate wireless ad-hoc networks using 50 mobile nodes. According to the paper, there was huge diversion between results from different simulators and in some cases results were barely comparable. The paper also mentioned that there is a scarcity of real experiments that demonstrate the correctnes of wireless network simulators [1]. This paper gave us our primary motivation to perform simulations using various simulation tools available and compare the simulation results with the testbed results.
Kunz compared MANET simulation results with testbed results using the BCAST protocol, a multicast routing protocol. According to his findings, in a stationary environment, all results were close to each other, and a mobile emulator introduces negligible additional overhead. However, in mobile scenarios, his measurements in the emulated environment differed both qualitatively and quantitatively from the simulation results. According to the report, tools like MNE (Mobile Network Emulator) can help in testing and debugging protocols for real testbed but it is not clear if these tools are suitable for the performance evaluation of the protocol [2].
Based on the findings of the two above research projects, a need for detailed and carefully planed simulation and emulation experiments was realized. To ensure the reliability of the results, it was decided to use different traffic models and a highly dynamic network topology.
The primary goal of the project was to find out where simulation and emulation yield drastically different results and come up with guidelines for how/whether to use simulation as an appropriate tool for performance
studies of protocol.
OLSR Protocol
The Optimized Link State Routing protocol (RFC 3626) is a proactive routing protocol, which uses a link-state scheme in an optimized manner to diffuse topology information. OLSR message flooding is optimized to run in a multi-hop wireless network to preserve bandwidth. “Optimization is acquired through a technique called MultiPoint Relaying. The idea of MultiPoint Relaying (MPR) is to minimize the overhead of flooding messages by restricting the control messages to selected nodes.” [3]
MNE
MNE is designed to work under linux-based distribution environments with IPTABLES network filtering capabilities installed. A packet filter looks at the header of packets as they pass through and based on user-defined rules decides whether the packet should be accepted for further processing or should be dropped. Packet filtering is used for security, control and watchfulness. MNE takes advantage of these control features of IPTABLES to block packets from a particular node. The blocking is done based on the wireless link range. In MNE, packets from the nodes that are deemed out of range are blocked with the IPTABLES MAC Filtering component [4].
The control module provides a communication back channel for transmitting the node’s location information. The location update information is constantly transferred to all the nodes in the network using a broadcast channel (also known as back channel or controlled network). Either the wired or the wireless interface can be used to transmit location updates; however transmitting both traffics (dynamic topology information and user traffic) on the same physical channel causes congestion. In our work, the wired interface was used to broadcast location update to avoid congestion on the wireless channel.
MNE supports several different ways of emulating node motion, which includes file, random, ns2, static, line and circle. In MNE, NS2 motion files can be used directly. The MOVE module of MNE provides location information represented in terms of longitude and latitude and this information is then transmitted to all the nodes through the controlled network described above.
Each node in the network broadcasts its location information with the MAC address of the wireless network card over the back channel. The DYNAMICS module uses this information for calculating the distance between the nodes and performing filtering. The MAC address is used to block packets from a particular node.
Dynamic Network Topology
Dynamic network topology scenarios were carefully selected to simulate 1 hop, 2 hop and multi-hop connections in different scenarios. An area of 600x600 meters was selected as the basis for our dynamic topology. During the simulation of 400 seconds, the nodes acquired four different topologies.
-
(a)
- Scenario 1 (b) Scenario 2 (c)
- Scenario 3 (d) Scenario 4 Figure 1: Network Topologies
The above figure shows the orientation of nodes at time t = 0, 180, 300 and 400 seconds. In first scenario at time t = 0, nodes n0 and n1 are within each other’s direct communication range, n4 and n3 can also send and receive packets but n2 is out of range. Shortly after t = 0 sec, all the nodes start moving and at t = 180 sec they acquire positions shown in scenario 2. In scenario 2 node n1 cannot communicate with n4 directly and has to go through an intermediate node and vice versa, hence establishing a 2-hop communication network. In this scenario any node (n0, n2, n3) can be chosen as a MPR to relay all the packets. Scenario 3 and 4 were designed to simulate multi hop communication.
Simulation Model
NS2 [5] is a discrete event simulator for, among others, linux that can be used to define different scenarios. NS2 depends on several external components such as Tcl, otcl and TclCL. A simulation is defined by a TCL program and a topology is defined using ns commands. NS2 can be used to simulate wired or wireless network. NS2 includes a model for IEEE 802.11 and the protocol stack includes implementations for ad-hoc routing protocols which makes it an ideal simulator for mobile ad hoc networks.
GloMoSim is a scalable simulation environment for wireless and wired network systems designed by UCLA’s parallel computing laboratory [6]. GloMoSim can be used to simulate a variety of wireless network protocols. The protocol stack includes models for the channel, radio, MAC, network, transport, and higher layers.
For both simulators, different research groups have developed OLSR models and made them publicly available. We integrated these models into NS2 and GloMoSim and ensured that we used consistent values for all protocol parameters (such as the periodicity of HELLO messages).
Five mobile nodes were used in the simulation model. The MAC and the Logic Link Layer implemented in NS2 and GloMoSim for IEEE 802.11 was used in the simulation. A Drop Tail Queue of size 100 packets was selected as an interface queue. An omni-direction antenna having unity gain was used. A two-ray ground reflection model was used for radio propagation.
Traffic Model
CBR agents were used to generate traffic in the network. The following table shows the packet size and number of packets sent per second for all the experiments.
| Experiment # | Packet Size | Duration |
|---|---|---|
| 1 | 128 bytes | 1 packet/sec |
| 2 | 128 bytes | 10 packets/sec |
| 3 | 512 bytes | 10 packets/sec |
Multi-Generator (MGEN version 4) (an open source software from NRL) was used to generate traffic over the wireless channel to obtain packet delivery statistics. MGEN provides the ability to perform IP network performance tests and measurements using UDP/IP traffic. To ensure the reliability of the results, great care was takes while selecting network settings that will match as closely as possible with the settings defined in the network simulators for the simulation model.
Performance Comparison
In total three simulation and testbed experiments were performed.
- Low bandwidth (1 packet/s of 128 bytes)
- Medium bandwidth (10 packet/s of 128 bytes)
- High bandwidth (10 packet/s of 512 bytes)
In this experiment we focused on the packet delivery ratio and compared the number of packets received by the emulated testbed nodes in all three scenarios with the simulation results from NS2 and GloMoSim. As the clocks on the laptops were not closely synchronized, we did not measure packet latencies. And the number of control messages propagated in the network was comparable in all experiments because the network topology was unchanged and protocol parameters were all set to the same values.
In the first scenario, the accumulated channel bandwidth utilized by the CBR agents of all the nodes in the network nodes was 20Kb/s (excluding the bandwidth consumed by
the OLSR). The maximum bandwidth available was 2Mb/s. Simulation and emulated testbed results of the first scenario were very close to each other. The average percentage difference between the number of packets
Table 1: Traffic Rates received by the testbed nodes and the nodes in the
simulation model was less than 5%. Each node’s CBR was connected to every other nodes receiver agent hence forming a meshed network. All the 450 Node 0 Statistics links were bi-directional. User Datagram Protocol (UDP) 400
was used as Transport Layer protocol to minimise the
Number of Packets Received
overhead of establishing a connection.
350 300 250
Testbed Implementation
200
NRL MNE was used for dynamic topology control and
150
manipulation. The Ethernet wired interface was used to
100
50
broadcast location update to avoid congestion on the
wireless channel. An implementation of OLSR (RFC
3626) from the PROTocol Engineering Advanced Networking (PROTEAN) Research Group was used for
the testbed experiments. Graph 1: Node 0 Statistics (128 bytes packets 1/sec)
Graph 2: Node 4 Statistics (128 bytes packets 1/sec)
Graphs 1 and 2 show the number of packets received by node 0 and 4 respectively. The trend holds for all the other nodes and simulation results matched emulated testbed results both qualitatively and quantitatively.
In the second scenario (medium bandwidth), accumulated bandwidth used by the CBR traffic agents was 200Kb/s plus the bandwidth required by the routing protocol. When we increased the number of packets sent per second by the factor of 10, the simulation results differed quantitatively from the emulated testbed results. The percentage difference between the simulation results and testbed results was also increased by a factor of 10 as compared to the results acquired in the first scenario. Hence testbed nodes received 10 times less packets as compare to nodes in the simulation model. The results among different simulators were pretty consistent and the percentage difference was less than 2 percent. Graph 3 shows the packet delivery ration of node 0 in the second scenario. The results are similar for rest of the nodes.
a pattern in the inconsistency of the results between the testbed and simulation results when we increase the traffic load. By increasing the size of the packet by a factor of 4 the accumulated bandwidth used by the nodes in the network reached 800Kbytes/s. We were hoping to see another quantitative shift in the results between testbed and simulation but the results we acquired were somewhat surprising. Testbed results of the third scenario differed both quantitatively and qualitatively from the simulation results. Furthermore the results from NS2 and GloMoSim were barely comparable in some scenarios. However the bandwidth utilized by the nodes was far less than the maximum allowed bandwidth (2Mb/s). Overall, the results were very inconsistent.
Graph 4: Node 0 Statistics (512 bytes packets 10/sec)
Graph 4: Node 1 Statistics (512 bytes packets 10/sec)
Graph 3: Node 0 Statistics (128 bytes packets 10/sec)
After analyzing the results from the first and second scenario, we decided to increase the size of the packet from 128 bytes to 512 bytes. We wanted to see if there is
Graph 5: Node 2 Statistics (512 bytes packets 10/sec)
Graph 6: Node 3 Statistics (512 bytes packets 10/sec)
Conclusion
Based on the dynamic topology and traffic model used in this experiment, the performance results from the simulation tools NS2 and GloMoSim and the emulated testbed results differ both qualitatively and quantitatively at higher traffic rates. The variation in the results kept on increasing with an increase in the load in network. However at lower traffic rates (1 packet/s 128bytes) simulation results were very close to testbed results.
Based on the results of this experiment, wireless network simulation tools should be used with great care when evaluating performance of MANET routing protocols. At higher bandwidth wireless network simulators results may not evaluate the routing protocols correctly. However, lower bandwidth may result in realistic simulation results. The testbed used in this experiment was an emulated testbed (implements using MNE) therefore; the emulated testbed results may differ from the real testbed results. In the emulated environment, wireless nodes were placed close to each other and therefore physically share the wireless channel. In certain simulation scenarios, where the nodes were out of each others range and were able to access the physical channel concurrently, they were unable to access the channel concurrently in our emulated environment. Between NS2 and GloMoSim, results from NS2 were much closer to the testbed results as compared to the GloMoSim, especially at higher bandwidth. Using GloMoSim to evaluate the routing protocol performance did, in general, result in higher packet delivery ratios, compared to both NS2 and the emulated testbed, sometimes by a factor of more than 100%
Future Work
In this experiment, we only looked at the packet delivery ratio. We did not consider packet latency because in Ad Hoc mode it is difficult to synchronize the clocks. Several algorithms have been proposed to synchronize the clock. Kunz and Carlos proposed a clock-sampling mutual network synchronization algorithm for wireless ad hoc networks [7]. In future work, clock synchronization protocols can be implemented (in NS2, GloMoSim and testbed) to compare the packet latency.
The testbed used in this experiment was an emulated testbed. We are currently working on a real multihop wireless testbed on our campus and plan to perform performance studies on that testbed in the future. These results can then be compared with both the emulated testbed results and the simulator results, varying the traffic model. One disadvantage of a real testbed will be the difficulty in exploring a number of different dynamic topologies, so we would like to determine which tool (NS2, GloMoSim, or emulator) will more accurately predict the actual testbed results. Finally, in this experiment we used OLSR as a routing protocol, future work can compare the testbed results with the simulation results using AODV or DSR protocol. Various traffic models can also be tested such as FTP, TELNET, VoIP.
Reference
[1] D. Cavin, Y. Sasson, A Schiper, “On the Accuracy of MANET Simulators”, Distributed Systems Laboratory Ecole Polytechnique Fédérale de Lausanne, in Workshop on Principles of Mobile Computing 2002, Toulouse, France
[2] Thomas Kunz, "Implementation vs. simulation: Evaluating a MANET multicast protocol", in Proceedings of the Global Mobile Congress 2004, Shanghai, China, pages 129-134, October 2004, Delson Group 2004
[3] Network Working Group, The Internet Engineering Task Force, Optimized Link State Routing Protocol, January 2005, http://www.ietf.org/rfc/rfc3626.txt?number=3626
[4] W. Chao, J. Macker, J. Weston, “Mobile Network Emulator,” Communication Systems Branch Information Technology Division Navel Research Labaratories, Washington, DC, USA, January 24, 2003
[5] Information Sciences Institute USA Viterbi School of Engineering, “The Network Simulator -ns-2,” September 2004
http://www.isi.edu/nsnam/ns/
[6] UCLA Parallel computing laboratory, University of California “About GloMoSim,” September 2004 http://pcl.cs.ucla.edu/projects/glomosim/
[7] Carlos H. Rentel and Thomas Kunz, "A clock-sampling mutual network synchronization algorithm for wireless ad hoc networks", Proceedings of the IEEE Wireless Communications and Networking Conference 2005, New Orleans, USA, March 2005
Simulation vs. Emulation:Evaluating Mobile Ad Hoc Network Routing Protocols
Furqan Haq and Thomas KunzSystems and Computer EngineeringCarleton UniversityOttawa, Ont., Canada K1S 5Bhaq_furqan@hotmail.com, tkunz@sce.carleton.ca
Abstract
In order for simulation studies to be useful, it is very important that the simulation results match as closely as possible with the testbed results. This paper compares emulated testbed results with simulation results from NS2 and GloMoSim. OLSR was used as a routing protocol and NRL Mobile Network Emulator (MNE) for dynamic topology control and manipulation. Five linux based laptops, equipped with IEEE 802.11b wireless network cards were used for testbed implementation. At low traffic rates, testbed results matched closely with the simulation results, at higher traffic rates, testbed results not only differed from the simulation results both qualitatively and quantitatively but the simulation results from both the simulators were barely comparable in some scenarios.
Introduction
Network engineers use simulation tools to debug and test the reliability and QoS of network protocols as well as hardware equipment. This makes simulation a very important step towards the deployment of wireless communication networks. A simulation is only useful if the simulation results match as closely as possible with the testbed results.
With the popularity of commercial wireless devices such as IEEE 802.11 and Bluetooth, a transition is taking place from traditional wired networks to wireless networks. In the wireless domain, Mobile Ad-hoc networks are getting more and more popular due to their flexible, dynamic, self-healing and self-configuring nature.
In spite all the technological achievements and cutting edge research occurring in the field of mobile wireless networks, there are growing concerns regarding the reliability of results generated by wireless network simulators.
Related Work
There are very few papers discussing the accuracy of simulation results and the variation of the results among different wireless network simulators.
An interesting paper published by Distributed Systems Laboratory, Ecole Polytechnique Fédérale de Lausanne, compares the simulation results of OPNET, NS2 and GloMoSim. IEEE 802.11 MAC implementations and a very simple flooding algorithm were used to simulate wireless ad-hoc networks using 50 mobile nodes. According to the paper, there was huge diversion between results from different simulators and in some cases results were barely comparable. The paper also mentioned that there is a scarcity of real experiments that demonstrate the correctnes of wireless network simulators [1]. This paper gave us our primary motivation to perform simulations using various simulation tools available and compare the simulation results with the testbed results.
Kunz compared MANET simulation results with testbed results using the BCAST protocol, a multicast routing protocol. According to his findings, in a stationary environment, all results were close to each other, and a mobile emulator introduces negligible additional overhead. However, in mobile scenarios, his measurements in the emulated environment differed both qualitatively and quantitatively from the simulation results. According to the report, tools like MNE (Mobile Network Emulator) can help in testing and debugging protocols for real testbed but it is not clear if these tools are suitable for the performance evaluation of the protocol [2].
Based on the findings of the two above research projects, a need for detailed and carefully planed simulation and emulation experiments was realized. To ensure the reliability of the results, it was decided to use different traffic models and a highly dynamic network topology.
The primary goal of the project was to find out where simulation and emulation yield drastically different results and come up with guidelines for how/whether to use simulation as an appropriate tool for performance
studies of protocol.
OLSR Protocol
The Optimized Link State Routing protocol (RFC 3626) is a proactive routing protocol, which uses a link-state scheme in an optimized manner to diffuse topology information. OLSR message flooding is optimized to run in a multi-hop wireless network to preserve bandwidth. “Optimization is acquired through a technique called MultiPoint Relaying. The idea of MultiPoint Relaying (MPR) is to minimize the overhead of flooding messages by restricting the control messages to selected nodes.” [3]
MNE
MNE is designed to work under linux-based distribution environments with IPTABLES network filtering capabilities installed. A packet filter looks at the header of packets as they pass through and based on user-defined rules decides whether the packet should be accepted for further processing or should be dropped. Packet filtering is used for security, control and watchfulness. MNE takes advantage of these control features of IPTABLES to block packets from a particular node. The blocking is done based on the wireless link range. In MNE, packets from the nodes that are deemed out of range are blocked with the IPTABLES MAC Filtering component [4].
The control module provides a communication back channel for transmitting the node’s location information. The location update information is constantly transferred to all the nodes in the network using a broadcast channel (also known as back channel or controlled network). Either the wired or the wireless interface can be used to transmit location updates; however transmitting both traffics (dynamic topology information and user traffic) on the same physical channel causes congestion. In our work, the wired interface was used to broadcast location update to avoid congestion on the wireless channel.
MNE supports several different ways of emulating node motion, which includes file, random, ns2, static, line and circle. In MNE, NS2 motion files can be used directly. The MOVE module of MNE provides location information represented in terms of longitude and latitude and this information is then transmitted to all the nodes through the controlled network described above.
Each node in the network broadcasts its location information with the MAC address of the wireless network card over the back channel. The DYNAMICS module uses this information for calculating the distance between the nodes and performing filtering. The MAC address is used to block packets from a particular node.
Dynamic Network Topology
Dynamic network topology scenarios were carefully selected to simulate 1 hop, 2 hop and multi-hop connections in different scenarios. An area of 600x600 meters was selected as the basis for our dynamic topology. During the simulation of 400 seconds, the nodes acquired four different topologies.
-
(a)
- Scenario 1 (b) Scenario 2 (c)
- Scenario 3 (d) Scenario 4 Figure 1: Network Topologies
The above figure shows the orientation of nodes at time t = 0, 180, 300 and 400 seconds. In first scenario at time t = 0, nodes n0 and n1 are within each other’s direct communication range, n4 and n3 can also send and receive packets but n2 is out of range. Shortly after t = 0 sec, all the nodes start moving and at t = 180 sec they acquire positions shown in scenario 2. In scenario 2 node n1 cannot communicate with n4 directly and has to go through an intermediate node and vice versa, hence establishing a 2-hop communication network. In this scenario any node (n0, n2, n3) can be chosen as a MPR to relay all the packets. Scenario 3 and 4 were designed to simulate multi hop communication.
Simulation Model
NS2 [5] is a discrete event simulator for, among others, linux that can be used to define different scenarios. NS2 depends on several external components such as Tcl, otcl and TclCL. A simulation is defined by a TCL program and a topology is defined using ns commands. NS2 can be used to simulate wired or wireless network. NS2 includes a model for IEEE 802.11 and the protocol stack includes implementations for ad-hoc routing protocols which makes it an ideal simulator for mobile ad hoc networks.
GloMoSim is a scalable simulation environment for wireless and wired network systems designed by UCLA’s parallel computing laboratory [6]. GloMoSim can be used to simulate a variety of wireless network protocols. The protocol stack includes models for the channel, radio, MAC, network, transport, and higher layers.
For both simulators, different research groups have developed OLSR models and made them publicly available. We integrated these models into NS2 and GloMoSim and ensured that we used consistent values for all protocol parameters (such as the periodicity of HELLO messages).
Five mobile nodes were used in the simulation model. The MAC and the Logic Link Layer implemented in NS2 and GloMoSim for IEEE 802.11 was used in the simulation. A Drop Tail Queue of size 100 packets was selected as an interface queue. An omni-direction antenna having unity gain was used. A two-ray ground reflection model was used for radio propagation.
Traffic Model
CBR agents were used to generate traffic in the network. The following table shows the packet size and number of packets sent per second for all the experiments.
| Experiment # | Packet Size | Duration |
|---|---|---|
| 1 | 128 bytes | 1 packet/sec |
| 2 | 128 bytes | 10 packets/sec |
| 3 | 512 bytes | 10 packets/sec |
Multi-Generator (MGEN version 4) (an open source software from NRL) was used to generate traffic over the wireless channel to obtain packet delivery statistics. MGEN provides the ability to perform IP network performance tests and measurements using UDP/IP traffic. To ensure the reliability of the results, great care was takes while selecting network settings that will match as closely as possible with the settings defined in the network simulators for the simulation model.
Performance Comparison
In total three simulation and testbed experiments were performed.
- Low bandwidth (1 packet/s of 128 bytes)
- Medium bandwidth (10 packet/s of 128 bytes)
- High bandwidth (10 packet/s of 512 bytes)
In this experiment we focused on the packet delivery ratio and compared the number of packets received by the emulated testbed nodes in all three scenarios with the simulation results from NS2 and GloMoSim. As the clocks on the laptops were not closely synchronized, we did not measure packet latencies. And the number of control messages propagated in the network was comparable in all experiments because the network topology was unchanged and protocol parameters were all set to the same values.
In the first scenario, the accumulated channel bandwidth utilized by the CBR agents of all the nodes in the network nodes was 20Kb/s (excluding the bandwidth consumed by
the OLSR). The maximum bandwidth available was 2Mb/s. Simulation and emulated testbed results of the first scenario were very close to each other. The average percentage difference between the number of packets
Table 1: Traffic Rates received by the testbed nodes and the nodes in the
simulation model was less than 5%. Each node’s CBR was connected to every other nodes receiver agent hence forming a meshed network. All the 450 Node 0 Statistics links were bi-directional. User Datagram Protocol (UDP) 400
was used as Transport Layer protocol to minimise the
Number of Packets Received
overhead of establishing a connection.
350 300 250
Testbed Implementation
200
NRL MNE was used for dynamic topology control and
150
manipulation. The Ethernet wired interface was used to
100
50
broadcast location update to avoid congestion on the
wireless channel. An implementation of OLSR (RFC
3626) from the PROTocol Engineering Advanced Networking (PROTEAN) Research Group was used for
the testbed experiments. Graph 1: Node 0 Statistics (128 bytes packets 1/sec)
Graph 2: Node 4 Statistics (128 bytes packets 1/sec)
Graphs 1 and 2 show the number of packets received by node 0 and 4 respectively. The trend holds for all the other nodes and simulation results matched emulated testbed results both qualitatively and quantitatively.
In the second scenario (medium bandwidth), accumulated bandwidth used by the CBR traffic agents was 200Kb/s plus the bandwidth required by the routing protocol. When we increased the number of packets sent per second by the factor of 10, the simulation results differed quantitatively from the emulated testbed results. The percentage difference between the simulation results and testbed results was also increased by a factor of 10 as compared to the results acquired in the first scenario. Hence testbed nodes received 10 times less packets as compare to nodes in the simulation model. The results among different simulators were pretty consistent and the percentage difference was less than 2 percent. Graph 3 shows the packet delivery ration of node 0 in the second scenario. The results are similar for rest of the nodes.
a pattern in the inconsistency of the results between the testbed and simulation results when we increase the traffic load. By increasing the size of the packet by a factor of 4 the accumulated bandwidth used by the nodes in the network reached 800Kbytes/s. We were hoping to see another quantitative shift in the results between testbed and simulation but the results we acquired were somewhat surprising. Testbed results of the third scenario differed both quantitatively and qualitatively from the simulation results. Furthermore the results from NS2 and GloMoSim were barely comparable in some scenarios. However the bandwidth utilized by the nodes was far less than the maximum allowed bandwidth (2Mb/s). Overall, the results were very inconsistent.
Graph 4: Node 0 Statistics (512 bytes packets 10/sec)
Graph 4: Node 1 Statistics (512 bytes packets 10/sec)
Graph 3: Node 0 Statistics (128 bytes packets 10/sec)
After analyzing the results from the first and second scenario, we decided to increase the size of the packet from 128 bytes to 512 bytes. We wanted to see if there is
Graph 5: Node 2 Statistics (512 bytes packets 10/sec)
Graph 6: Node 3 Statistics (512 bytes packets 10/sec)
Conclusion
Based on the dynamic topology and traffic model used in this experiment, the performance results from the simulation tools NS2 and GloMoSim and the emulated testbed results differ both qualitatively and quantitatively at higher traffic rates. The variation in the results kept on increasing with an increase in the load in network. However at lower traffic rates (1 packet/s 128bytes) simulation results were very close to testbed results.
Based on the results of this experiment, wireless network simulation tools should be used with great care when evaluating performance of MANET routing protocols. At higher bandwidth wireless network simulators results may not evaluate the routing protocols correctly. However, lower bandwidth may result in realistic simulation results. The testbed used in this experiment was an emulated testbed (implements using MNE) therefore; the emulated testbed results may differ from the real testbed results. In the emulated environment, wireless nodes were placed close to each other and therefore physically share the wireless channel. In certain simulation scenarios, where the nodes were out of each others range and were able to access the physical channel concurrently, they were unable to access the channel concurrently in our emulated environment. Between NS2 and GloMoSim, results from NS2 were much closer to the testbed results as compared to the GloMoSim, especially at higher bandwidth. Using GloMoSim to evaluate the routing protocol performance did, in general, result in higher packet delivery ratios, compared to both NS2 and the emulated testbed, sometimes by a factor of more than 100%
Future Work
In this experiment, we only looked at the packet delivery ratio. We did not consider packet latency because in Ad Hoc mode it is difficult to synchronize the clocks. Several algorithms have been proposed to synchronize the clock. Kunz and Carlos proposed a clock-sampling mutual network synchronization algorithm for wireless ad hoc networks [7]. In future work, clock synchronization protocols can be implemented (in NS2, GloMoSim and testbed) to compare the packet latency.
The testbed used in this experiment was an emulated testbed. We are currently working on a real multihop wireless testbed on our campus and plan to perform performance studies on that testbed in the future. These results can then be compared with both the emulated testbed results and the simulator results, varying the traffic model. One disadvantage of a real testbed will be the difficulty in exploring a number of different dynamic topologies, so we would like to determine which tool (NS2, GloMoSim, or emulator) will more accurately predict the actual testbed results. Finally, in this experiment we used OLSR as a routing protocol, future work can compare the testbed results with the simulation results using AODV or DSR protocol. Various traffic models can also be tested such as FTP, TELNET, VoIP.
Reference
[1] D. Cavin, Y. Sasson, A Schiper, “On the Accuracy of MANET Simulators”, Distributed Systems Laboratory Ecole Polytechnique Fédérale de Lausanne, in Workshop on Principles of Mobile Computing 2002, Toulouse, France
[2] Thomas Kunz, "Implementation vs. simulation: Evaluating a MANET multicast protocol", in Proceedings of the Global Mobile Congress 2004, Shanghai, China, pages 129-134, October 2004, Delson Group 2004
[3] Network Working Group, The Internet Engineering Task Force, Optimized Link State Routing Protocol, January 2005, http://www.ietf.org/rfc/rfc3626.txt?number=3626
[4] W. Chao, J. Macker, J. Weston, “Mobile Network Emulator,” Communication Systems Branch Information Technology Division Navel Research Labaratories, Washington, DC, USA, January 24, 2003
[5] Information Sciences Institute USA Viterbi School of Engineering, “The Network Simulator -ns-2,” September 2004
http://www.isi.edu/nsnam/ns/
[6] UCLA Parallel computing laboratory, University of California “About GloMoSim,” September 2004 http://pcl.cs.ucla.edu/projects/glomosim/
[7] Carlos H. Rentel and Thomas Kunz, "A clock-sampling mutual network synchronization algorithm for wireless ad hoc networks", Proceedings of the IEEE Wireless Communications and Networking Conference 2005, New Orleans, USA, March 2005
Simulation vs. Emulation:Evaluating Mobile Ad Hoc Network Routing Protocols
Furqan Haq and Thomas KunzSystems and Computer EngineeringCarleton UniversityOttawa, Ont., Canada K1S 5Bhaq_furqan@hotmail.com, tkunz@sce.carleton.ca
Abstract
In order for simulation studies to be useful, it is very important that the simulation results match as closely as possible with the testbed results. This paper compares emulated testbed results with simulation results from NS2 and GloMoSim. OLSR was used as a routing protocol and NRL Mobile Network Emulator (MNE) for dynamic topology control and manipulation. Five linux based laptops, equipped with IEEE 802.11b wireless network cards were used for testbed implementation. At low traffic rates, testbed results matched closely with the simulation results, at higher traffic rates, testbed results not only differed from the simulation results both qualitatively and quantitatively but the simulation results from both the simulators were barely comparable in some scenarios.
Introduction
Network engineers use simulation tools to debug and test the reliability and QoS of network protocols as well as hardware equipment. This makes simulation a very important step towards the deployment of wireless communication networks. A simulation is only useful if the simulation results match as closely as possible with the testbed results.
With the popularity of commercial wireless devices such as IEEE 802.11 and Bluetooth, a transition is taking place from traditional wired networks to wireless networks. In the wireless domain, Mobile Ad-hoc networks are getting more and more popular due to their flexible, dynamic, self-healing and self-configuring nature.
In spite all the technological achievements and cutting edge research occurring in the field of mobile wireless networks, there are growing concerns regarding the reliability of results generated by wireless network simulators.
Related Work
There are very few papers discussing the accuracy of simulation results and the variation of the results among different wireless network simulators.
An interesting paper published by Distributed Systems Laboratory, Ecole Polytechnique Fédérale de Lausanne, compares the simulation results of OPNET, NS2 and GloMoSim. IEEE 802.11 MAC implementations and a very simple flooding algorithm were used to simulate wireless ad-hoc networks using 50 mobile nodes. According to the paper, there was huge diversion between results from different simulators and in some cases results were barely comparable. The paper also mentioned that there is a scarcity of real experiments that demonstrate the correctnes of wireless network simulators [1]. This paper gave us our primary motivation to perform simulations using various simulation tools available and compare the simulation results with the testbed results.
Kunz compared MANET simulation results with testbed results using the BCAST protocol, a multicast routing protocol. According to his findings, in a stationary environment, all results were close to each other, and a mobile emulator introduces negligible additional overhead. However, in mobile scenarios, his measurements in the emulated environment differed both qualitatively and quantitatively from the simulation results. According to the report, tools like MNE (Mobile Network Emulator) can help in testing and debugging protocols for real testbed but it is not clear if these tools are suitable for the performance evaluation of the protocol [2].
Based on the findings of the two above research projects, a need for detailed and carefully planed simulation and emulation experiments was realized. To ensure the reliability of the results, it was decided to use different traffic models and a highly dynamic network topology.
The primary goal of the project was to find out where simulation and emulation yield drastically different results and come up with guidelines for how/whether to use simulation as an appropriate tool for performance
studies of protocol.
OLSR Protocol
The Optimized Link State Routing protocol (RFC 3626) is a proactive routing protocol, which uses a link-state scheme in an optimized manner to diffuse topology information. OLSR message flooding is optimized to run in a multi-hop wireless network to preserve bandwidth. “Optimization is acquired through a technique called MultiPoint Relaying. The idea of MultiPoint Relaying (MPR) is to minimize the overhead of flooding messages by restricting the control messages to selected nodes.” [3]
MNE
MNE is designed to work under linux-based distribution environments with IPTABLES network filtering capabilities installed. A packet filter looks at the header of packets as they pass through and based on user-defined rules decides whether the packet should be accepted for further processing or should be dropped. Packet filtering is used for security, control and watchfulness. MNE takes advantage of these control features of IPTABLES to block packets from a particular node. The blocking is done based on the wireless link range. In MNE, packets from the nodes that are deemed out of range are blocked with the IPTABLES MAC Filtering component [4].
The control module provides a communication back channel for transmitting the node’s location information. The location update information is constantly transferred to all the nodes in the network using a broadcast channel (also known as back channel or controlled network). Either the wired or the wireless interface can be used to transmit location updates; however transmitting both traffics (dynamic topology information and user traffic) on the same physical channel causes congestion. In our work, the wired interface was used to broadcast location update to avoid congestion on the wireless channel.
MNE supports several different ways of emulating node motion, which includes file, random, ns2, static, line and circle. In MNE, NS2 motion files can be used directly. The MOVE module of MNE provides location information represented in terms of longitude and latitude and this information is then transmitted to all the nodes through the controlled network described above.
Each node in the network broadcasts its location information with the MAC address of the wireless network card over the back channel. The DYNAMICS module uses this information for calculating the distance between the nodes and performing filtering. The MAC address is used to block packets from a particular node.
Dynamic Network Topology
Dynamic network topology scenarios were carefully selected to simulate 1 hop, 2 hop and multi-hop connections in different scenarios. An area of 600x600 meters was selected as the basis for our dynamic topology. During the simulation of 400 seconds, the nodes acquired four different topologies.
-
(a)
- Scenario 1 (b) Scenario 2 (c)
- Scenario 3 (d) Scenario 4 Figure 1: Network Topologies
The above figure shows the orientation of nodes at time t = 0, 180, 300 and 400 seconds. In first scenario at time t = 0, nodes n0 and n1 are within each other’s direct communication range, n4 and n3 can also send and receive packets but n2 is out of range. Shortly after t = 0 sec, all the nodes start moving and at t = 180 sec they acquire positions shown in scenario 2. In scenario 2 node n1 cannot communicate with n4 directly and has to go through an intermediate node and vice versa, hence establishing a 2-hop communication network. In this scenario any node (n0, n2, n3) can be chosen as a MPR to relay all the packets. Scenario 3 and 4 were designed to simulate multi hop communication.
Simulation Model
NS2 [5] is a discrete event simulator for, among others, linux that can be used to define different scenarios. NS2 depends on several external components such as Tcl, otcl and TclCL. A simulation is defined by a TCL program and a topology is defined using ns commands. NS2 can be used to simulate wired or wireless network. NS2 includes a model for IEEE 802.11 and the protocol stack includes implementations for ad-hoc routing protocols which makes it an ideal simulator for mobile ad hoc networks.
GloMoSim is a scalable simulation environment for wireless and wired network systems designed by UCLA’s parallel computing laboratory [6]. GloMoSim can be used to simulate a variety of wireless network protocols. The protocol stack includes models for the channel, radio, MAC, network, transport, and higher layers.
For both simulators, different research groups have developed OLSR models and made them publicly available. We integrated these models into NS2 and GloMoSim and ensured that we used consistent values for all protocol parameters (such as the periodicity of HELLO messages).
Five mobile nodes were used in the simulation model. The MAC and the Logic Link Layer implemented in NS2 and GloMoSim for IEEE 802.11 was used in the simulation. A Drop Tail Queue of size 100 packets was selected as an interface queue. An omni-direction antenna having unity gain was used. A two-ray ground reflection model was used for radio propagation.
Traffic Model
CBR agents were used to generate traffic in the network. The following table shows the packet size and number of packets sent per second for all the experiments.
| Experiment # | Packet Size | Duration |
|---|---|---|
| 1 | 128 bytes | 1 packet/sec |
| 2 | 128 bytes | 10 packets/sec |
| 3 | 512 bytes | 10 packets/sec |
Multi-Generator (MGEN version 4) (an open source software from NRL) was used to generate traffic over the wireless channel to obtain packet delivery statistics. MGEN provides the ability to perform IP network performance tests and measurements using UDP/IP traffic. To ensure the reliability of the results, great care was takes while selecting network settings that will match as closely as possible with the settings defined in the network simulators for the simulation model.
Performance Comparison
In total three simulation and testbed experiments were performed.
- Low bandwidth (1 packet/s of 128 bytes)
- Medium bandwidth (10 packet/s of 128 bytes)
- High bandwidth (10 packet/s of 512 bytes)
In this experiment we focused on the packet delivery ratio and compared the number of packets received by the emulated testbed nodes in all three scenarios with the simulation results from NS2 and GloMoSim. As the clocks on the laptops were not closely synchronized, we did not measure packet latencies. And the number of control messages propagated in the network was comparable in all experiments because the network topology was unchanged and protocol parameters were all set to the same values.
In the first scenario, the accumulated channel bandwidth utilized by the CBR agents of all the nodes in the network nodes was 20Kb/s (excluding the bandwidth consumed by
the OLSR). The maximum bandwidth available was 2Mb/s. Simulation and emulated testbed results of the first scenario were very close to each other. The average percentage difference between the number of packets
Table 1: Traffic Rates received by the testbed nodes and the nodes in the
simulation model was less than 5%. Each node’s CBR was connected to every other nodes receiver agent hence forming a meshed network. All the 450 Node 0 Statistics links were bi-directional. User Datagram Protocol (UDP) 400
was used as Transport Layer protocol to minimise the
Number of Packets Received
overhead of establishing a connection.
350 300 250
Testbed Implementation
200
NRL MNE was used for dynamic topology control and
150
manipulation. The Ethernet wired interface was used to
100
50
broadcast location update to avoid congestion on the
wireless channel. An implementation of OLSR (RFC
3626) from the PROTocol Engineering Advanced Networking (PROTEAN) Research Group was used for
the testbed experiments. Graph 1: Node 0 Statistics (128 bytes packets 1/sec)
Graph 2: Node 4 Statistics (128 bytes packets 1/sec)
Graphs 1 and 2 show the number of packets received by node 0 and 4 respectively. The trend holds for all the other nodes and simulation results matched emulated testbed results both qualitatively and quantitatively.
In the second scenario (medium bandwidth), accumulated bandwidth used by the CBR traffic agents was 200Kb/s plus the bandwidth required by the routing protocol. When we increased the number of packets sent per second by the factor of 10, the simulation results differed quantitatively from the emulated testbed results. The percentage difference between the simulation results and testbed results was also increased by a factor of 10 as compared to the results acquired in the first scenario. Hence testbed nodes received 10 times less packets as compare to nodes in the simulation model. The results among different simulators were pretty consistent and the percentage difference was less than 2 percent. Graph 3 shows the packet delivery ration of node 0 in the second scenario. The results are similar for rest of the nodes.
a pattern in the inconsistency of the results between the testbed and simulation results when we increase the traffic load. By increasing the size of the packet by a factor of 4 the accumulated bandwidth used by the nodes in the network reached 800Kbytes/s. We were hoping to see another quantitative shift in the results between testbed and simulation but the results we acquired were somewhat surprising. Testbed results of the third scenario differed both quantitatively and qualitatively from the simulation results. Furthermore the results from NS2 and GloMoSim were barely comparable in some scenarios. However the bandwidth utilized by the nodes was far less than the maximum allowed bandwidth (2Mb/s). Overall, the results were very inconsistent.
Graph 4: Node 0 Statistics (512 bytes packets 10/sec)
Graph 4: Node 1 Statistics (512 bytes packets 10/sec)
Graph 3: Node 0 Statistics (128 bytes packets 10/sec)
After analyzing the results from the first and second scenario, we decided to increase the size of the packet from 128 bytes to 512 bytes. We wanted to see if there is
Graph 5: Node 2 Statistics (512 bytes packets 10/sec)
Graph 6: Node 3 Statistics (512 bytes packets 10/sec)
Conclusion
Based on the dynamic topology and traffic model used in this experiment, the performance results from the simulation tools NS2 and GloMoSim and the emulated testbed results differ both qualitatively and quantitatively at higher traffic rates. The variation in the results kept on increasing with an increase in the load in network. However at lower traffic rates (1 packet/s 128bytes) simulation results were very close to testbed results.
Based on the results of this experiment, wireless network simulation tools should be used with great care when evaluating performance of MANET routing protocols. At higher bandwidth wireless network simulators results may not evaluate the routing protocols correctly. However, lower bandwidth may result in realistic simulation results. The testbed used in this experiment was an emulated testbed (implements using MNE) therefore; the emulated testbed results may differ from the real testbed results. In the emulated environment, wireless nodes were placed close to each other and therefore physically share the wireless channel. In certain simulation scenarios, where the nodes were out of each others range and were able to access the physical channel concurrently, they were unable to access the channel concurrently in our emulated environment. Between NS2 and GloMoSim, results from NS2 were much closer to the testbed results as compared to the GloMoSim, especially at higher bandwidth. Using GloMoSim to evaluate the routing protocol performance did, in general, result in higher packet delivery ratios, compared to both NS2 and the emulated testbed, sometimes by a factor of more than 100%
Future Work
In this experiment, we only looked at the packet delivery ratio. We did not consider packet latency because in Ad Hoc mode it is difficult to synchronize the clocks. Several algorithms have been proposed to synchronize the clock. Kunz and Carlos proposed a clock-sampling mutual network synchronization algorithm for wireless ad hoc networks [7]. In future work, clock synchronization protocols can be implemented (in NS2, GloMoSim and testbed) to compare the packet latency.
The testbed used in this experiment was an emulated testbed. We are currently working on a real multihop wireless testbed on our campus and plan to perform performance studies on that testbed in the future. These results can then be compared with both the emulated testbed results and the simulator results, varying the traffic model. One disadvantage of a real testbed will be the difficulty in exploring a number of different dynamic topologies, so we would like to determine which tool (NS2, GloMoSim, or emulator) will more accurately predict the actual testbed results. Finally, in this experiment we used OLSR as a routing protocol, future work can compare the testbed results with the simulation results using AODV or DSR protocol. Various traffic models can also be tested such as FTP, TELNET, VoIP.
Reference
[1] D. Cavin, Y. Sasson, A Schiper, “On the Accuracy of MANET Simulators”, Distributed Systems Laboratory Ecole Polytechnique Fédérale de Lausanne, in Workshop on Principles of Mobile Computing 2002, Toulouse, France
[2] Thomas Kunz, "Implementation vs. simulation: Evaluating a MANET multicast protocol", in Proceedings of the Global Mobile Congress 2004, Shanghai, China, pages 129-134, October 2004, Delson Group 2004
[3] Network Working Group, The Internet Engineering Task Force, Optimized Link State Routing Protocol, January 2005, http://www.ietf.org/rfc/rfc3626.txt?number=3626
[4] W. Chao, J. Macker, J. Weston, “Mobile Network Emulator,” Communication Systems Branch Information Technology Division Navel Research Labaratories, Washington, DC, USA, January 24, 2003
[5] Information Sciences Institute USA Viterbi School of Engineering, “The Network Simulator -ns-2,” September 2004
http://www.isi.edu/nsnam/ns/
[6] UCLA Parallel computing laboratory, University of California “About GloMoSim,” September 2004 http://pcl.cs.ucla.edu/projects/glomosim/
[7] Carlos H. Rentel and Thomas Kunz, "A clock-sampling mutual network synchronization algorithm for wireless ad hoc networks", Proceedings of the IEEE Wireless Communications and Networking Conference 2005, New Orleans, USA, March 2005
扫一扫
8652
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
