实验一隐终端和暴露终端问题分析
一、实验目的
结合仿真实验分析载波检测无线网络中的隐终端问题和暴露终端问题。
二、实验设定与结果
基本参数配置：仿真时长100s；随机数种子1；仿真区域2000x2000；节点数4。
节点位置配置：本实验用[1] 、[2]、[3] 、[4]共两对节点验证隐终端问题。
节点[1]、[2]距离为200m，节点[3]、[4]距离为200m，节点[2]、[3]距离为370m。
1234
业务流配置：业务类型为恒定比特流CBR。
[1]给[2]发，发包间隔为0.01s，发包大小为512bytes；[3]给[4]发，发包间隔为0.01s，发包大小为512bytes。
实验结果：
Node: 1, Layer: AppCbrClient, (0) Server address: 2
Node: 1, Layer: AppCbrClient, (0) Total number of bytes sent: 5120000
Node: 1, Layer: AppCbrClient, (0) Total number of packets sent: 10000
Node: 2, Layer: AppCbrServer, (0) Client address: 1
Node: 2, Layer: AppCbrServer, (0) Total number of bytes received: 4975616
Node: 2, Layer: AppCbrServer, (0) Total number of packets received: 9718
Node: 3, Layer: AppCbrClient, (0) Server address: 4
Node: 3, Layer: AppCbrClient, (0) Total number of bytes sent: 5120000
Node: 3, Layer: AppCbrClient, (0) Total number of packets sent: 10000
Node: 4, Layer: AppCbrServer, (0) Client address: 3
Node: 4, Layer: AppCbrServer, (0) Total number of bytes received: 5120000
Node: 4, Layer: AppCbrServer, (0) Total number of packets received: 10000
结果分析
通过仿真结果可以看出，节点[2]无法收到数据。
由于节点[3]是节点[1]的一个隐终端，节点[1]无法通过物理载波检测侦听到节点[3]的发送，且节点[3]在节点[2]的传输范围外，节点[3]无法通过虚拟载波检测延迟发送，所以在节点[1]传输数据的过程中，节点[3]完成退避发送时将引起冲突。
三、课后思考
1、RTS/CTS能完全解决隐终端问题吗？如果不能，请说明理由。
答：能。
对于隐发送终端问题，[2]和[3]使用控制报文进行握手（RTS-CTS），听到回应握手信号的[3]知道自己是隐终端，便能延迟发送；对于隐接受终端问题，在多信道的情况下，[3]给[4]回送CTS告诉[4]它是隐终端，现在不能发送报文，以避免[4]收不到[3]的应答而超时重发浪费带宽。
2、如何设计仿真场景来验证暴露终端问题？
答：只需更改业务流配置：业务类型为恒定比特流CBR。
[2]给[1]发，发包间隔为0.01s，发包大小为512bytes；[3]给[4]发，发包间隔为0.01s，发包大小为512bytes。
观察在[2]给[1]发送数据的同时，[3]给[4] 发送数据会不会被影响。
3、如何设计协议使暴露终端场景下的流实现并发？
答：至少要使用两个信道资源，在数据信道上进行RTS-CTS握手，在数据信道上发送数据报文。
在[2]给[1]发送数据报文时，[3]也想向[4]发送数据报文，通过控制信道向[4]发送RTS，[4]也从控制信道向[3]回送CTS，这样[3]就不会因为[2]的数据信号和[4]的回应信号产生碰撞而听不到[4]的回应了。
这样就可以实现并发了。
实验三动态源路由协议路由选择验证
一、实验目的
1、理解DSR路由协议中路由发现过程和路由维护过程。
2、掌握DSR路由协议性能的仿真分析方法。
二、实验设定与结果
基本参数配置：仿真时长100S；随机数种子1；仿真区域2000x2000；节点数5。
节点位置配置：用节点[1]-[5]来验证DSR路由协议的路由发现过程。
[1]和[2]、[2]和[3]、[3]和[4]、[3]和[5]、[4]和[6]、[5]和[6]之间距离为200m。
设置业务流：[1]给[2]发，发包间隔0.01s，发包大小512Bytes。
设置节点移动性：节点[1]为移动节点，仿真过程中绕网格拓扑转一圈。
实验结果：
Time(s): 1.000001000, Node: 1, Route path: 2
┇┇┇┇┇
Time(s): 7.000001000, Node: 1, Route path: 2
Time(s): 8.000001000, Node: 1, Route path: 4-2
┇┇┇┇┇
Time(s): 37.000001000, Node: 1, Route path: 4-2
Time(s): 38.000001000, Node: 1, Route path: 5-4-2
┇┇┇┇┇
Time(s): 67.000001000, Node: 1, Route path: 5-4-2
Time(s): 68.000001000, Node: 1, Route path: 3-2
┇┇┇┇┇
Time(s): 92.000001000, Node: 1, Route path: 3-2
Time(s): 93.000001000, Node: 1, Route path: 2
┇┇┇┇┇
Time(s): 99.000001000, Node: 1, Route path: 2
结果分析：
仿真过程中路由表变化：2，4-2，5-4-2，3-2，2。
当节点[1]在节点[2]的传输范围内时，节点[1]和[2]之间直接通信，不需要中间节点。
随着节点[1]的移动，节点[1]离开节点[2]的传输范围并渐渐远离，最后又逐渐靠近。
在节点[1]离开节点[2]的传输范围，节点[1]和[2]需要通过中间节点来通信，而且节点[1]离节点[2]越远，需要的中间节点越多。
三、课后思考
1、由实验中的网络拓扑能够反映出DSR路由协议的路由维护过程吗？如果能，说明怎么验证？如果不能，请说明理由。
答：能。
因为源节点使用路由维护机制可以检测出因为拓扑变化不能使用的路由，当路由维护指出一条源路由已经中断而不再起作用的时候，为了将随后的数据分组传输到目的节点，源节点能够尽力使用一条偶然获知的到达目的节点的路由，或者重新调用路由寻找机制找到一条新路由。
而该实验中随着源节点[1]的移动，源路由不断中断，比如路由信息从4-2转到5-4-2就是因为源节点[1]到节点[4]的链接已经中断，源节点才通过节点[5]来寻找到一条新路由。
2、为什么仿真过程中路由表变化为5-4-2而不是5-3-2？
答：节点[5]会同时给节点[3]和[4]转发路由请求，但节点[4]路由缓存中可以找到的那条从节点[4]到路由请求目的节点[2]的路由信息（即4-2），节点[4]就直接给发起节点回送路由应答，而不再转发该路由请求。
而节点[3]中没有该缓存。
3、设计一个16网格拓扑的仿真场景来验证动态源路由路由发现的过程。
答：。