3.2.3 Design test case studies
To test and verify the
framework provided by CRCN simulator, demos and debug code test are used
together to test and verify the functionality. Section A compares the methods
used for testing. Section B introduces the test process.
A. Comparisons between the demo method and debug code
method
For the demos, they can
provide direct performance comparisons to users, however, the performance of
demo is hard to analyze for the following reasons.
·
The performance
of demos depends on the algorithm design.
·
The performance
analysis of demos involves analysis of topology, traffic, and interaction with
other layers. Thus, it makes the analysis is complex and not so accurate.
·
For each demo, it
can only adapt to one kind of simulation setting, such as single radio,
multi-channel, or multi-radio, single-channel.
For the debug code test, it
is the most accurate and direct way to test the framework. The only
disadvantage is that it is hard to understand by people other than the
designers and NS-2 users. However, the debug code is not included in the release
code to avoid confusing to users.
B. Test process
(1)
Test the multi-radio provided by design structure figure 2 (a)
Specific topology as follow is
designed to test whether multi-radio is worked under this design structure.
Each node is forced to make the channel selection as shown in figure 1 in the
routing module. Every node has 2 radios, but only node 2 has more chance to use
2 radios at the same time. Then we can check at node 2 whether multi-radio is
used through simulation.
Figure 1. Test topology for multi-radio
From the snapshot of a trace
file about the radio usages in table 1, 2 MACs associated with 2 radios of node
2 are busy at the same time. Thus, the multi-radio functionality is proved.
Users can also write their simple debug code to test the functionality.
Table 1. Radio usages at node
2
|
format<time, node id,
radio index, 0.010000 2 4 busy 0.010000 2 5 busy 0.020000 2 4 busy 0.020000 2 5 idle 0.030000 2 4 idle 0.030000 2 5 idle 0.040000 2 4 idle 0.040000 2 5 idle 0.050000 2 4 busy 0.050000 2 5 idle 0.060000 2 4 idle 0.060000 2 5 idle 0.070000 2 4 busy 0.070000 2 5 busy 0.080000 2 4 idle 0.080000 2 5 idle 0.090000 2 4 idle 0.090000 2 5 idle 0.100000 2 4 idle 0.100000 2 5 idle |
(2)
Test the multi-radio multi-channel provided by design
structure figure 2 (a)
Since the multi-channel provided
through this design is only visible to routing, WCETT is used to test the
multi-channel provided by figure 2(a). However, this implementation is a
simplifier version. With the design structure in figure 2 (a), channel is tied
with each radio, thus, the corresponding radio and channel relationship is
fixed. For example, radio 1 is always on Channel 1; radio 2 is always on
Channel 2.
Figure 2 and figure 3 compare
the performance of wcett when the radios or channel numbers are different. The
performance is not increased significantly, because not all the radios are
being used all the time. Table 2 is the snapshot of a trace file that shows the
radio usage at node 2 when it has 3 radios.
Figure 2. WCETT 2 radios, 2 channels.
Figure 3. WCETT 5 radios, 5 channels
Table 2. Radio usages at node
2
|
format<time, node id,
radio index, 2.700000 2 6 busy 2.700000 2 7 busy 2.700000 2 8 idle 2.710000 2 6 busy 2.710000 2 7 busy 2.710000 2 8 idle 2.720000 2 6 busy 2.720000 2 7 busy 2.720000 2 8 idle 2.730000 2 6 busy 2.730000 2 7 busy 2.730000 2 8 idle |
Users can also write their
simple debug code to test the functionality.
(3)
Test the single radio, multi-channel in figure 2 (b)
Since the multi-channel in
this design structure is only visible to
Macng is used to test single
radio, multi-channel functionality. The operation of MACNG is divided into two
phases. In the first phase, each node sends out strategy packet with preferred
receiving channel. If there is an empty channel available, then it is selected
as the preferred receiving channel. If there is no empty channel, node shares
the channel with the node that is furthest away from it. In the second phase,
node will use the channel selected during the first phase to send and receive
data.
Maccon is designed for
specific topology, since our purpose is just to test multi-channel.
Here is the comparison for
Maccon, when available channels are 2 or 3.
Figure 4 . Test for Macng and the number of available
channel are 2
3 pairs of nodes; topology and traffic file: topo4.tcl
Figure 5.Test for Macng and the number of available
channel are 3
3 pairs of nodes; topology and traffic file: topo4.tcl
However, as we increase the
number of channels to 4 or 5, the throughput is not increased significantly.
The reason is that only 3 pairs of nodes are used.
If we use another simulation
setting, the throughput change for Macng can be seen.
The drop of performance from
30 seconds in figure 6 is due to too many collisions. As Macng is just used to
provide example for the user, collisions introduced in simple-mac still exist.
In comparison, when channel is increased to 10, the throughput is increased.
Thus, multi-channel functionality is correct here since increasing the channel
will increase the throughput, since the same simulation setting is used.
Figure 6. Test for Macng with random topology and
traffic channel number =5
Figure 7. Test for Macng with random topology and
traffic channel number =10
In sum, the functionalities are
tested through the debug code and demos. However, as explained in section A, to
obtain an accurate result, the performance analysis of demos test need to
involve the consideration of topology and traffic pattern, and the design of
the algorithms.
(4)
Test the multi-radio, multi-channel in figure 2 (c)
This structure is a
combination of figure 2
(a) and figure (b),
the supported functionalities in figure 2 (a) and figure (b) are included in
this structure already. But still, some tests are done to make sure this
framework can work. Users need to carefully design
Simulation setting:
Random topology and traffic
Routing: WCETT
2 radios, 3 channels per radios
Since 802_11 is default to channel
0, thus only channel 0 will be used in this case. The Maccon, Macng won’t work
since they are not designed for this structure.
The test result is shown as
follow. This result is to make sure no other framework change is needed. It is
protocol designer’s responsibility to implement their MACs.
Figure 8. Test for the structure in figure 2 (c)