6. Simulation Settings and Results
6.1 Simulation Settings and Modifications
To run our applications such as the trunk daemon and the mobile node daemon on NCTUns2.0, some settings and modifications should be done. On NCTUns2.0, modified kernel uses Source-Destination-Pair IP address scheme to route packets from applications. But by using the fully-integrated GUI environment, a user need not know the concept and need not use the source-destination-pair address scheme at all.
However, when users try to use RAW socket, and install firewall rules to divert packets from IP queue, their application should be modified to work well under the Source-Destination-Pair IP address scheme of NCTUns2.0. So, due to the Source-Destination-Pair IP address scheme on NCTUns2.0, we do some modifications in our trunk daemon and mobile node daemon.
We focus on some issues such as system performance when number of RNs increases and mobility support in MANET when doing the simulation experiments.
Therefore, we used our modified traffic generators to take place the modified apache server in our scheme. Then, we can evaluate our scheme by one TCP connection or a CBR UDP packet stream. We also can evaluate the performance of our routing scheme which is hard to be evaluated in the real world.
6.2 Simulations Results
6.2.1 Calibration Tests for the GPRS package on NCTUns2.0
In those calibration tests, we want to evaluate the GPRS system performs on NCTUns2.0 without using our scheme.
In Figure 6.2.1-1, there is a topology of common GPRS network on NCTUns2.0.
Node 1 is the Base Station, and the Base station connects to a host (Node 5) in the Internet. Node 7 is a cellular phone. Node 6 is the mobile computer equipped with a GPRS network card and an 802.11b wireless card.
Figure 6.2.1-1: simple topology of GPRS network
Figure 6.2.1-2 shows the protocol stack of a GPRS Base Station. Each RLC module has its own transmission queue with a limited number of slots. A packet is allowed to enter an RLC module if the transmission queue in that RLC module has enough slots to store that packet. Otherwise, the packet will be put back into the GPRS FIFO module until the RLC module has enough space for storing this incoming packet.
Figure 6.2.1-2: the protocol stacks of base station
We present the GPRS TCP throughput in Figure 6.2.1-3 (Figure A-3) without using our scheme. The pink line represents the current queue size of GPRS FIFO, and the blue line represents the TCP throughput.
The GPRS FIFO is overflow between 36 seconds to 55 seconds, so GPRS base station would drop some data packets during that period. This condition would trigger the congestion control of a TCP connection, so the TCP throughput drops to zero between 61 seconds to 78 seconds. The size of current GPRS FIFO decreases after 58 seconds, therefore slow start of the TCP connection can progress. After a while, the GPRS TCP throughput climbs up again.
We present the GPRS UDP throughput in Figure 6.2.1-4 (Figure A-4) without using our scheme. We pump a CBR UDP packet stream about 3.75 Kbytes/sec on PS.
Although the GPRS FIFO is overflow after 25 seconds, the UDP throughput keeps steady at 3.74 Kbytes/sec. It is because the UDP throughput wouldn’t decrease even when there are some packet losses on GPRS network.
GPRS TCP Throughput
Kbytes/sec & Current Queue Size
TCP Throughput GFIFO Current Queue Size
Figure 6.2.1-3: GPRS TCP Throughput
GPRS UDP Throughput
UDP Throughput GFIFO Current Queue Size
Figure 6.2.1-4: GPRS UDP Throughput
6.2.2 Evaluation Experiments with a Simple Wireless Physical Layer Module
We measured the web download throughput of our scheme on NCTUns2.0 using a simple wireless physical layer module (PHY) when different numbers of static RNs are forwarding packets to DN. By using Simple wireless PHY on NCTUns2.0, a receiver would not suffer any packet loss within the transmission range of a sender.
In each of the simulation experiment suites below, we measured the download throughput under different file sizes. For each file size, we repeated the experiment 10 times and report their average and standard deviation.
6.2.2.1 TCP
First, we measure the TCP throughput of our scheme on NCTUns2.0.
6.2.2.1.1 Single Hop Count
In those experiments below, every RN is just one hop away from DN, so data packets can be sent to DN directly from each RN in MANET (Figure 6.2.2.1.1-1).
Node 7 is a DN, and the red circle represents its transmission range. So, every RN is within the transmission range of DN.
Figure 6.2.2.1.1-1: simulation topology 1
In the first experiment suite, no RN provides additional GPRS channel bandwidth to help the DN download its requested file. Thus, the packets carrying the file’s content are transmitted on the DN’s own GRPS channel. Figure 6.2.2.1.1-2 shows that the average throughput without applying out scheme is about 3.7 KB/sec.
For each average throughput data point, the point above it is the average plus the standard deviation and the point below it is the average minus the standard deviation.
In this experiment suite, TCP triggered Fast Retransmission about 38 times.
GPRS TCP Throughput
0
1020 50 100 200 300 400 500 600
02 46 108 1214 1618
Kbytes
Kbytes/sec
GPRS TCP throughput +stddev -stddev
Figure 6.2.2.1.1-2: GPRS TCP Throughput
In the second experiment suite, one RN is used and its channel and the DN’s channel are used to download the file in parallel. Figure 6.2.2.1.1-3 shows that the average throughput is about 7.335 KB/sec. The throughput speedup is 1.98 (7.335 / 3.7). In this experiment suite, TCP triggered Fast Retransmission about 0~7 times, so TCP is well protected in our data transfer protocol.
In the third experiment suite, two RNs are used and in total three GPRS channels are used to download the file in parallel. Figure 6.2.2.1.1-4 shows that the average throughput is about 10.83 KB/sec. The throughput speedup is 2.92 (10.83/3.7).
In the fourth experiment suite, three RNs are used and in total four GPRS channels are used to download the file in parallel. Figure 6.2.2.1.1-5 shows that the average throughput is about 11.825 KB/sec. The throughput speedup is 3.19 (11.825/3.7).
One Rel ay Node - One Hop
0 1020
50 100 200 300 400 500 600
02 46 108 1214 1618
kbyt es
kbytes/sec
One Relay Throughput +stddev -stddev
Figure 6.2.2.1.1-3: GPRS TCP Throughput – One Relay
Two Rel ay Nodes-One Hop
0 1020
50
100 200 300 400 500 600
0
Two Relay Node Throughput +stddev -stddev
Figure 6.2.2.1.1-4: GPRS TCP Throughput – Two Relay
Thr ee Rel ay Nodes - One Hop
0 10
20 50
100 200 300 400 500 600
0
Three Relay Node Throughput +stddev -stddev
Figure 6.2.2.1.1-5: GPRS TCP Throughput – Three Relay
In the fifth experiment suite, four RNs are used and in total five GPRS channels are used to download the file in parallel. Figure 6.2.2.1.1-6 shows that the average throughput is about 13.614 KB/sec. The throughput speedup is 3.68 (13.614/3.7).
Four Rel ay Nodes - One Hop
0 1020
50
100 200 300 400 500 600
0
Four Relay Node Throughput +stddev -stddev
Figure 6.2.2.1.1-6: GPRS TCP Throughput – Four Relay
In the second to fifth experiments above, each TCP connection triggered Fast Retransmission about 0~7 times, so TCP is well protected in the experiments above.
However, the current GPRS FIFO queue size mentioned in section 6.2.1 is less than Max GPRS FIFO size all the time. So, there is no packet loss in GPRS Base Station.
This is because we queue each packet in GPRS FIFO queue when the block queue of RLC module layer in GPRS Base Station is full.
In Figure 6.2.2.1.1-7, there are three TCP traffic flows belonged to three different experiments of the fifth experiment suit. The throughput of TCP swings between 20 Kbytes/sec to 10 Kbytes/sec, because DN should reorder data packets which it received and data packets from each RN.
TCP Traf f i c Fl ow- Four Rel ay
Figure 6.2.2.1.1-7: TCP Traffic Flow – Four Relay
In the sixth experiment suite, five RNs are used and in total six GPRS channels are used to download the file in parallel. Figure 6.2.2.1.1-8 shows that the average throughput is about 14.13 KB/sec. The throughput speedup is 3.81 (14.13/3.7).
Fi ve Rel ayNodes -One Hop
0
Five Relay Node Throughput +stddev -stddev
Figure 6.2.2.1.1-8: GPRS TCP Throughput – Five Relay
In Figure 6.2.2.1.1-9, there are three TCP traffic flows belonged to three different experiments of the sixth experiment suit. The throughput of TCP swings between 25
Kbytes/sec to 10 Kbytes/sec before 43 seconds. The TCP throughput of this experiment suit drops to zero and rises up again several times. This is because there are some packet losses in GPRS network, so a DN would enqueue data packets until all data packet in its reordering queue are in order. We observe that GPRS Base Station dropped some data packets after 43 seconds because the GPRS FIFO queue mentioned in section 6.2.1 is overflow. The maximum size of the GPRS FIFO queue is fixed, so the GPRS FIFO queue would be overflow more frequently when we pump more UDP packets into GPRS network per second.
TCP Traf f i c Fl ow- Fi ve Rel ay
Figure 6.2.2.1.1-9: TCP Traffic Flow – Five Relay
In the seventh experiment suite, six RNs are used and in total seven GPRS channels are used to download the file in parallel. Figure 6.2.2.1.1-10 shows that the average throughput is about 13.12 KB/sec. The throughput speedup is 3.54 (13.12/3.7) even lower than the previous experiment suite using less RNs.
In Figure 6.2.2.1.1-11, the TCP throughput of this experiment suit drops to zero and then rises up again more frequency than the previous experiment suite. The reason is that a DN waste more time to reorder data packets because there are more
packet losses than the previous experiment suite.
Six Relay Node Throughput +stddev -stddev
Figure 6.2.2.1.1-10: GPRS TCP Throughput – Six Relay
TCP Traf f i c Fl ow - Si x Rel ay
Figure 6.2.2.1.1-11: TCP Traffic Flow – Six Relay
In 6.2.2.1.1-12, we conclude the experiment results in section 6.2.2.1.1.
TCP Throughput - One Hop
No RN One RN Two RNs Three RNs Four RNs Five RNs Six RNs
Figure 6.2.2.1.1-12: TCP throughput – One Hop
6.2.2.1.2 Multiple Hop Counts
In those experiments below, some RNs are multiple hops away from DN, so data packets would be forwarded by other RNs in the MANET (Figure 6.2.2.1.2-1).
Node 7 is a DN, and the red circle represents its transmission range. So, only Node 6, 8, and 12 are within the transmission range of DN.
Figure 6.2.2.1.2-1: simulation topology 2
Figure 6.2.2.1.2-2 presents the experiment results of section 6.2.2.1.2.
The experiment results in Figure 6.2.2.1.2-2 are similar to those results in Figure 6.2.2.1.1-12. The throughput results show that the number of hop counts of routing paths in the ad hoc network does not affect the TCP throughputs experienced by end users because the underlying ad hoc network provides much more bandwidths than GPRS channels.
200 300 400 500 600
0
Figure 6.2.2.1.2-2: TCP throughput – Multiple Hops
6.2.2.2 UDP
We measure the UDP throughput of our scheme on NCTUns2.0, so we can evaluate our scheme without the affection of TCP congestion control. We used a CBR UDP packet stream in each experiment suit of this section.
6.2.2.2.1 Single Hop Count
In those experiments below, every RN is just one hop away from DN, so data packets can be sent to DN directly from each RN in MANET (Figure 6.2.2.1.1-1).
In the first experiment suite, no RN provides additional GPRS channel bandwidth to help the DN download its requested file. Thus, the packets carrying the file’s content are transmitted on the DN’s own GRPS channel. We pumped a CBR UDP packet stream about 3.75 KB/sec on PS.
Figure 6.2.2.2.1-1 shows that the average throughput without applying out scheme is about 3.74 KB/sec.
GPRS Udp t hroughput
0
1020 50 100 200 300 400 500 600
0
GPRS UDP Throughput +stddev -stddev
Figure 6.2.2.2.1-1: GPRS UDP throughput
In the second experiment suite, one RN is used and its channel and the DN’s channel are used to download the file in parallel. We pumped a CBR UDP packet stream about 7.5 KB/sec on PS. Figure 6.2.2.2.1-2 shows that the average throughput is about 7.45 KB/sec. The throughput speedup is 1.99 (7.45 / 3.74).
One Rel ay Node -One Hop
Figure 6.2.2.2.1-2: GPRS UDP throughput – One Relay
In the third experiment suite, two RNs are used and in total three GPRS channels are used to download the file in parallel. We pumped a CBR UDP packet stream about 11.25 KB/sec. Figure 6.2.2.2.1-3 shows that the average throughput is about 11.21 KB/sec. The throughput speedup is 2.99 (11.21/3.74).
Two Rel ay Nodes - One Hop
UDP Throughput +stddev -stddev
Figure 6.2.2.2.1-3: GPRS UDP throughput – Two Relay
In the fourth experiment suite, three RNs are used and in total four GPRS
channels are used to download the file in parallel. We pumped a CBR UDP packet stream about 15 KB/sec on PS. Figure 6.2.2.2.1-4 shows that the average throughput is about 14.08 KB/sec. The throughput speedup is 3.76 (14.08/3.74).
Three Rel ay Nodes - One Hop
0
Figure 6.2.2.2.1-4: GPRS UDP throughput –Three Relay
In the fifth experiment suite, four RNs are used and in total five GPRS channels are used to download the file in parallel. We use a traffic generator program to generate a CBR UDP packet stream, the sending rate of which is about 18.75 KB/sec on a PS. Figure 6.2.2.2.1-5 shows that the average throughput is about 18.4 KB/sec.
The throughput speedup is 4.91 (18.4/3.74).
Four Rel ay Nodes - One Hop
0 1020
50
100 200 300 400 500 600
0
Figure 6.2.2.2.1-5: GPRS UDP throughput – Four Relay
In Figure 6.2.2.2.1-6, there are two CBR UDP traffic flows belonged to two different experiments of the fifth experiment suit. The throughput of TCP swings between 20 Kbytes/sec to 16 K.
UDP Traf f i c Fl ow - Four Rel ay
Figure 6.2.2.2.1-6: UDP Traffic Flow – Four Relay
In the sixth experiment suite, five RNs are used and in total six GPRS channels are used to download the file in parallel. We pumped a CBR UDP packet stream about
22.5 KB/sec on PS. The performance when using five RNs is even worse than the performance when using four RNs when the download file size exceeds 200 KB.
In Figure 6.2.2.2.1-8, there are two CBR UDP traffic flows belonged to two different experiments of the sixth experiment suit. The UDP throughput of this experiment suit drops to zero and rises up again several times. This is also because there are some packet losses in GPRS network, so a DN would enqueue data packets until all data packet in its reordering queue are in order. In our data transfer protocol, a DN would reorder data packets by the sequence number that is given by our scheme.
Fi ve Rel ay Nodes - One Hop
Figure 6.2.2.2.1-7: GPRS UDP throughput – Five Relay
UDP Tr af f i c Fl ow - Fi ve Rel ay
Figure 6.2.2.2.1-8: UDP Traffic Flow – Five Relay
In the seventh experiment suite, six RNs are used and in total seven GPRS channels are used to download the file in parallel. We pumped a CBR UDP packet stream about 26.25 KB/sec on PS.
Si x Rel ay Nodes - One Hop
Figure 6.2.2.2.1-9: GPRS UDP throughput – Six Relay
In Figure 6.2.2.2.1-10, there are two CBR UDP traffic flows belonged to two different experiments of the seventh experiment suit.
UDP Tr af f i c Fl ow - Si x Rel ay
Figure 6.2.2.2.1-10: UDP Traffic Flow – Six Relay
In Figure 6.2.2.2.1-11, we conclude the experiment results in section 6.2.2.2.1.
When the GPRS FIFO queue mentioned in section 6.2.1 is overflow, the throughput of our scheme would decrease as showed in sixth and seventh experiment suits.
UDP Throughput - One Hop
0 1020
50
100 200 300 400 500 600
0
No RN One RN Two RNs Three RNs Four RNs Five RNs Six RNs
Figure 6.2.2.2.1-11: UDP throughput – One Hop
6.2.2.2.2 Multiple Hop Counts
In those experiments below, some RNs are multiple hops away from DN, so data packets would be forwarded by other RNs in the MANET (Figure 6.2.2.1.2-1).
Figure 6.2.2.2.2-1 presents the experiment results of section 6.2.2.2.2.
The experiment results in Figure 6.2.2.2.2-1 are similar to those results in Figure 6.2.2.2.1-11.
UDP Throughput - Mul t i pl e Hops
0 1020
50
100 200 300 400 500 600
0
No RN One RN Two RNs Three RNs Four RNs Five RNs Six RNs
Figure 6.2.2.2.2-1: UDP throughput – Multiple Hops
6.2.3 Evaluation Experiments with an Advanced Wireless Physical Layer Module
We measured the web download throughput of our scheme on NCTUns2.0 using an advanced wireless physical layer module (PHY) when different numbers of static RNs are forwarding packets to DN. By using advanced wireless PHY on NCTUns2.0, our experiments would suffer the real world like propagation loss and BER.
In each of the simulation experiment suites below, we measured the download throughput under different file sizes. For each file size, we repeated the experiment 10 times and report their average and standard deviation.
6.2.3.1 TCP
First, we measure the TCP throughput of our scheme on NCTUns2.0 with advanced wireless PHY.
6.2.3.1.1 Single Hop Count
In those experiments below, every RN is just one hop away from DN, and we place each RN very close to DN (Figure 6.2.3.1.1-1).
Figure 6.2.3.1.1-1: simulation topology 3
The transmission radius of AWPHY is about 225 meters. In Figure 6.2.3.1.1-1, the distance between each RN and a DN is about 100 meters, so there are few packet losses in this experiment.
TCP Throughput (AWPHY) - One Hop
No RN One RN Two RNs Three RNs Four RNs Five RNs Six RNs
Figure 6.2.3.1.1-2: TCP throughput (AWPHY) – One Hop
In Figure 6.2.3.1.1-2, the experiment results when using advanced wireless PHY are similar to the experiment results in section 6.2.2.1.1 when using simple wireless PHY.
6.2.3.1.2 Multiple Hop Counts
In those experiments below, some RNs are multiple hops away from DN, and we place each mobile node from neighboring nodes within its transmission range as far as possible (Figure 6.2.3.1.2-1).
Figure 6.2.3.1.2-1: simulation topology 4
In Figure 6.2.3.1.2-2, we would suffer some packet losses when data packets are forwarded to DN by other RNs in MANET. This phenomenon might increase the number of out-of-order packets. Therefore, the performance on a multiple hop network case could not be as good as expected.
TCP Throughput (AWPHY) - Mul t i pl e Hops
0 1020
50 100
200 300
400 500 600
0 2 4 6 8 10 12 14 16 18
Kbyt es
Kb yt es /s ec
No RN One RN Two RNs Three RNS
Four RNs Five RNs Six RNs
Figure 6.2.3.1.2-2: TCP throughput (AWPHY) – Multiple Hops
6.2.3.2 UDP
We measure the UDP throughput of our scheme on NCTUns2.0 with advanced wireless PHY, so we can evaluate our scheme without the affection of TCP congestion control.
6.2.3.2.1 Single Hop Count
In those experiments below, every RN is just one hop away from DN, and we place each RN very close to DN (Figure 6.2.3.1.1-1).
In Figure 6.2.3.2.1, the experiment results when using advanced wireless phy are similar to the experiment results in section 6.2.2.2.1 when using simple wireless phy.
UDP Throughput (AWPHY) - One Hop
0 1020
50
100 200 300 400 500 600
0
No RN One RN Two RNs Three RNs Four RNs Five RNs Six RNs
Figure 6.2.3.2.1: UDP throughput (AWPHY) – One Hop
6.2.3.2.2 Multiple Hop Counts
In those experiments below, some RNs are multiple hops away from DN, and we place each mobile node from neighboring nodes within its transmission range as far as possible (Figure 6.2.3.1.2-1). In Figure 6.2.3.2.2, the performance on a multiple hop network case could not be as good as expected like section 6.2.3.1.2.
UDP Throughput (AWPHY) - Mul ti pl e Hops
0
No RN One RN Two RNs Three RNs Four RNs Five RNs Six RNs
Figure 6.2.3.2.2: UDP throughput (AWPHY) – Multiple Hops
6.3 Routing Experiments
Our scheme can support the mobility in MANET. We evaluated our routing scheme in section 6.3.
6.3.1 Basic Routing Experiment
In this basic routing experiment (Figure 6.3.1-1), node 7 is a DN and node 8 moved out and in the DN’s transmission range. Node 9 and node 10 is out of the DN’s transmission range, so node 8 forwarded data packets to the DN for them at the beginning. During total 73 seconds simulation time, node 8 moved out the DN’s transmission range in 31 seconds and moved in the DN’s transmission range again in 59 seconds. So, there was only one RN relaying for the DN between 31 seconds to 59
In this basic routing experiment (Figure 6.3.1-1), node 7 is a DN and node 8 moved out and in the DN’s transmission range. Node 9 and node 10 is out of the DN’s transmission range, so node 8 forwarded data packets to the DN for them at the beginning. During total 73 seconds simulation time, node 8 moved out the DN’s transmission range in 31 seconds and moved in the DN’s transmission range again in 59 seconds. So, there was only one RN relaying for the DN between 31 seconds to 59