Supervisor: Kaisa Sere
Download 298.62 Kb.
|
- Navigate this page:
- 7.3 Results
7.2 Simulation SettingsFor the simulation we choose the largest possible area, so that the network, with a high probability, never becomes partitioned. We say that the network is partitioned if at least one node is disconnected so that it could not even in theory find a route to every destination. We did not want the network to be partitioned in order to receive the true characteristics of the protocol. A partial network would incur worse results since the nodes could never reach all other destinations. Therefore, in order to choose the suitable area for 25 nodes with the radio range of 100 meters. We ran the simulator 20 times and noted the initial position of the nodes. Every time a result yielded partitioned networks we would decrease the size and try again. We stopped when all twenty runs yielded only single connected networks. 
Fig. 7 27: 25 nodes in a 400x400 square meter area. In figure 7-1 one can see one of 20 runs, which show that at this size it is quite likely for the network to be partitioned. Figure 7-2 shows another partitioned network even though it is reduced to 350x350 square meters
Fig. 7 29: 25 nodes in a 300x300 square meter area. In the simulator nodes select a position randomly and start moving in a random direction. The direction may be parallel to the x- or y-axis, or diagonally at a specified speed. The VMAC was programmed in such a way that a conflict-free MAC protocol has to be assumed, for instance CDMA with perfectly distributed codes so that nodes can transmit at will. This is different from contention-based MAC protocols that use RTS-CTS handshakes. In contention-based protocols nodes cannot transmit at will, before the handshake is made. Since nodes can transmit when they want as long as they want, this is why we do not have to take the sizes of the messages nor the transmission data rate into account. In contention-based protocols simulators the time that it takes to transmit a message has to be estimated (packet size/data rate) and other nodes must not transmit during this time. Congestion was not monitored specifically in the simulator, but the amount of lost messages is proportional to the amount of congestion. Also, we did not set an artificial receive buffer size for the nodes (processes), but instead, since real UDP sockets was used, we let the receive buffer of the sockets model available storage space for packets to be handled. In Linux the sockets receive buffer can be set with a command called “setsockopt” and the default buffer size is 42080 bytes which was used in the simulator. When the first RQM fails, that is, a time-out period has elapsed, a second RQM will sent to try to find the destination. If the second attempt also fails, an error is reported that the destination is unreachable and the simulator will count this as a lost data message because it was never sent. Currently no route aging is used, which might contribute to higher delay values. In route aging one has to be careful not to delete functioning routes. More research has to be completed before a suitable route-aging scheme can be implemented. While it remains unseen how TRP scales, it was shown that the simulator itself does not. The overhead from communicating with UDP between 25-50 processes, not only at the network layer but also at the VMAC layer made the simulator sluggish when simulating more than 25 nodes. It was also noted that when running the simulator on a more effective computer, the delivery rate improved. The same happened when we scheduled more processor time for the simulator program (by using the nice command). This was the reason for the relatively slow message rate, as more messages require more of the hardware of the computer. The rate at which data messages are sent is 1msg/second during a period of 30 seconds in real-time. The results were obtained by running the simulator 10 times and then calculating the average value of the runs. The graphs also show the standard deviation of the runs. 7.3 ResultsThe initial results of the simulator are promising. Figure 7-4 show how the delivery rate of data messages behave, as the speed of the nodes are increased from 0 to 10 meters per second. The delivery rate decreases evenly until 5 m/s is reached, this seems to be a point that is reflected in the other results as well. 
Fig. 7 30: Delivery rate of data messages. 
Fig. 7 31: RQM rate. The graph in figure 7-5 shows that very few RQMs are sent even at high speeds. The average time for nodes to find routes to destinations is presented in figure 7-6. This graph seems to be more independent than the others, although a varying increase in delay occurs. 
Fig. 7 32: Route discovery delay. 
Fig. 7 33: Relayed control messages. Figure 7-7 shows an interesting statistic of relayed control messages. In this statistic every relayed control message is counted as a new message. So, for instance, if a RQM is sent and the sender has two neighbors and the neighbors also have two neighbors then a total amount of 6 control messages will be counted. In the same way, if a ”destination unreachable” message is sent from a node to another through a route that contains 5 links then the message will count as 5 messages not 1. This will enable us to see how RQMs for example “reproduce” when multicast to appropriate neighbors. Download 298.62 Kb. Share with your friends:
|
