NS2.35中AODVWCETT实现方案

NS2.35中AODVWCETT实现方案NS2小组/2013.08.310引言AODVWCETT的研究自8月8日起至今已将近一月，只因WCETT需要很多基础工作要做，需要阅读大量源码，进行MIMC的扩展以及解决非保序的问题。尤其是非保序问题，耗时最长，因为非保序度量需要全面修改AODV协议原有的路由建立、维护、更新机制。原有的路由建立机制是每个节点都会更新路由表，中间节点只存储到目的端唯一的一条最优路由。非保序度量是针对若干条完整的路径进行选择，因此中间节点不能更新路由表，中间节点也需要将所有的路由保存下来，返回源端进行比较选择。因此解决非保序问题实现起来比较难，遇到的问题也最多。1WCETT的特殊之处保序性分析：与ETX、ETT不同，WCETT是非保序的，所以中间节点不能更新路由表。因此之前的思路不再适用于WCETT。如图1，如果按照保序性路由的更新方式，中间节点C会在路径BC和AC之间选择一条。由于AC间用了不同信道(信道1和2)，依照WCETT的具体公式，设WCETT(AC)WCETT(BC)，则C节点只会存储AC路径，但是从整条路径来看，很有可能会出现WCETT(AD)WCETT(BD)的情况，但是路径BC已经不在路由表里了，因此保序性的路由更新方式此时已经不再适用。ABCD1211222Source图1非保序特性说明2WCETT实现过程及主要修改的代码下面所述是我们从ETT成功之后到实现WCETT的具体过程。中间经历了MIMC的扩展、WCETT度量不保序的问题。AODVETT20130720AODV+MIMC20130807AODV+ETT+MIMC20130818AODVWCETT(初稿)20130831无线节点创建与工作原理简单的信道分配算法了解NS2无线节点结构接口与信道的OTCL与C++交互修改容器，增加接口字段修改大小探测包，记录信息修改与接口有关的信息获取节点之间的接口或信道信息RREQ与反向路由建立RREP与正向路由建立修改不同类型包的forward函数修改resolve函数，找出最优路径修订路由更新机制AODVWCETT(定稿)20132.1WCETT实现过程由于非保序路由对协议修改较多，在调试过程中也遇到了很多问题。由于篇幅时间有限，这里仅对WCETT实现过程中部分重要问题、耗时较长的问题进行简要概述，并没有阐述MIMC扩展过程中的一些问题，如果对MIMC感兴趣，可以对MIMC扩展相关内容进行查看（参考文档10NS2.35中AODV协议MIMC扩展方案），对节点、网络层次有更清晰的了解，对网络的整体有一进步把握。从1.2的分析可知，由于WCETT非保序的特殊性，在计算WCETT值的时候，需要知道整条链路的信息，进而对不同的链路计算不同的WCETT值，在多个能到达目的端的链路中选择WCETT值最好的，作为最优路径。因此我们采取的设计思路主要为：（1）RREQ包及反向路由表的更新机制在请求包传递过程中，不对经过的节点的WCETT值进行更新，在路由表中记录链路的节点地址、链路信道号、链路ETT值。在目的节点更新整条链路的信息。ABCGSEDF图2网络拓扑以图2所示的网络拓扑为例：1）假设C节点收到第一条路（SC）的请求包C节点首先更新RREQ包数据，请求包中携带S节点的信息。表1C节点收到第一条路（SC）的请求包时更新的RREQ包信息请求包序号请求包携带的信息0S节点所用信道SC链路的ETTC节点的路由表信息，不仅需要记录本节点的路由信息，还需记录之前走过节点的路由信息。表2C节点收到第一条路（SC）的请求包时更新的路由表信息路由表序号路由表记录的信息0S节点地址SC链路的ETTS节点的当前信道1CS链路的ETTC节点的当前信道2）C节点收到第二条路（SAC）的请求包（A节点发来的请求包）此时节点C已经有了一条路SC了，此时需要先查出C节点收到了几条请求包，intrt_index_=rtable.look_rt_index(rq-rq_src);（这个也是关键问题之一）。新开辟一个路由表入口，记录第二条路的信息。表3C节点收到第一条路（SAC）的请求包时更新的RREQ包信息请求包序号请求包携带的信息0S节点所用信道SA链路的ETT1A节点所用信道AC链路的ETT表4C节点收到第一条路（SAC）的请求包时更新的路由表信息路由表序号路由表记录的信息0S节点地址SA链路的ETTS节点的当前信道1A节点的地址AS链路的ETTA节点的当前信道2CA链路的ETTC节点的当前信道这样目的节点D就可以记录多条不同路径的信息，在查询有几条路径之后，返回相应的RREP包。（2）RREP包及正向路由表的更新机制由于在目的节点时，已经知道了所要走的整条链路的信息，所以在返回RREP包，以及更新正向路由表时，所采用的路由建立和维护机制和我们之前涉及的是不相同的。假设有4条链路到达了D节点：SAD、SCGED、SBFD。目的节点D就掌握了4条链路的所有信息，因此在返回RREP包的时候，就不需要像以往的AODV、ETT、ETX协议一样比较更新，只需要沿着反向路由表记录的节点信息，依次转发回到源节点。1）当某节点收到RREP包时，首先查找RREP包中是否携带本节点信息，如果存在本节点信息，更新正向路由信息，继续向源端转发。2）当本节点是源节点时（RREP包的目的节点），查看本节点缓存，发送数据包。上述过程说起来简单，做起来难。在该部分实现的过程中还涉及了许多细小问题影响着仿真结果，如下一跳的处理、多条路径信息的记录、路由的更新机制等。（3）数据包的发送机制——resolve函数对数据包的解析如果仔细阅读会发现，上面的过程中，虽然找到了多条可用路径，但是并没有对WCETT值进行计算，那么WCETT是如何度量的呢？这里通过rt_resolve函数进行处理。当有包到达时，rt_resolve函数就会对包进行解析，区分是协议包还是数据包，如果为数据包，先查看是否有路径，如果没有路径发送request包，如果有路径，对不同路径的WCETT值进行比较，选出最优路径，沿着该条路径发送数据包。2.2需要修改的文件代码需要修改的代码主要有四个主要函数：RREQ、RREP、forward、resolve。RREQ：记录所有的走过的路径，我们采用了一个结构体数组，结构体数组有节点地址、链路信道号、链路ETT值三个字段，其中节点地址是一个含20个元素的数组，为了存储20跳的节点信息(即把整条路径存储下来了)，目的节点依照相应的RREQ中的路径往回发送RREP。发送RREP之前需将源到目的的整条路径信息写到RREP包里RREP：源节点接收到RREP后，将携带的信息写到源节点路由表里。中间节点收到RREP依照反向路由信息向源端转发。forward：三个不同的forward函数实现不同的功能，相应的转发RREQ包、数据包、RREP包。resolve：发数据之前先解析，无路由则发送RREQ，有则挑选WCETT值最小的为最优路径。由于这四个函数与之前的AODV中的大不相同，因此需详细阅读这四个函数才能深入理解WCETT的思想。另外还需修改容器结构，增加链路的信道(接口)信息，修改forward函数，新添calculateWCETT函数等。3WCETT实现过程中遇到的问题下面陈述的问题需要对比源码进行深入思考，对理解AODV协议、拓展编程思路等方面都很有益处。1)如何解决非保序问题？非保序度量建立反向与正向路由的过程？路由表项是否需要修改或添加一些字段？对比一下与保序度量正向路由的建立过程，重大区别在哪里？2)路由表与路由表项的关系？一个节点的路由表有很多路由表项？3)如何记录一个请求包经过的整条链路信息？4)一个节点如何记录经过该节点的多条路由的信息？5)RREQ建立反向路由的过程及其作用？RREP依照反向路由表转发时将正向路由建立起来。6)RREP建立正向路由的过程及其作用？数据包必须依照正向路由表中的信息向下转发。7)forward()函数转发包(RREQ、RREP、数据包)时需要做的修改有哪些？将包格式的公共包头部分填上下一跳和目的地址。8)这些包(RREQ、RREP、数据包、缓存包)必须需要什么信息才能向下转发？依照包格式中的下一跳和目的地址字段信息？这些信息可以从哪里获得？9)如何修改路由生存期？即每条路由的可用时间。不然一旦建立了一条路由，将会一直使用下去。10)非保序路由在何处对WCETT值进行比较？如何对WCETT进行度量？由于遇到的问题较多，因此不在此一一写出解决方案，有兴趣者需边看源码边思考。4MIMC下的仿真验证考虑以下几个问题：1)信道容量(带宽)默认为2M还是5.4Mbps，其他人的仿真一般都用哪个2)观察仿真时间对性能的影响，仿真时间长短是否也要考虑进去3)在链形、格形、随机拓扑场景中验证，在怎样的负载范围内验证其性能