wireless.html 25.7 KB
Newer Older
1
2
<!--
   EMULAB-COPYRIGHT
3
   Copyright (c) 2004-2007 University of Utah and the Flux Group.
4
5
6
   All rights reserved.
  -->
<center>
7
<h2>Emulab Tutorial - Using Wireless Networking</h2>
8
9
</center>

10
<p>
Kirk Webb's avatar
   
Kirk Webb committed
11
Some Emulab nodes contain 802.11 a/b/g wifi interfaces (Atheros 5212 chipset),
12
and are scattered around at various locations in a large building.  To find out where they
Kirk Webb's avatar
   
Kirk Webb committed
13
are located and what their node IDs are, see the <a
Leigh B. Stoller's avatar
Leigh B. Stoller committed
14
15
16
href=https://www.emulab.net/floormap.php3>wireless floormaps</a> page.
When you click on one of the colored dots, you will be taken to a page
describing the node and what type of interfaces the node has installed
Leigh B. Stoller's avatar
Leigh B. Stoller committed
17
in it.
18
19
20
</p>

<p>
21
22
23
24
25
26
27
28
29
In addition to the nodes deployed throughout the building, we've also
concentrated a subset of them in our machine room.  36 of the pc600s now have
802.11 a/b/g interfaces, also with the Atheros 5212 chipset.  Each has an
external antenna deployed on the backs of the racks containing the pc600s.  To
find out which nodes are where, look at <a
href="https://www.emulab.net/floormap.php3?building=MEB-MRC600">the floormaps
for this sub-cluster</a>.  For connectivity, antenna positions, and related
information, see the <a href="#envinfo">Environmental Information</a>
subsection of this document.
30
</p>
Leigh B. Stoller's avatar
Leigh B. Stoller committed
31

32
<p>
33
Before using a wireless network interface in an experiment,
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
please read the <a href="#WirelessAUP"><b>Wireless Acceptable Use
Policy</b></a> regarding wireless interfaces.
</p>

<p>
This document is broken up into the following sections:
<ol>
<li><a href="#WirelessAUP">Wireless Acceptable Use Policy</a>
<li><a href="#CreateExp">Creating an Experiment with Wireless Nodes</a>
<li><a href="#LinkConfig">Wireless Link Configuration Settings</a>
<li><a href="#DynamicLinkConfig">Dynamically Configuring Wireless Links</a>
<li><a href="#AdvDynLinkConfig">Advanced Dynamic Link Configuration</a>
<li><a href="#ChoosingNodes">Choosing Physical Nodes</a>
<li><a href="#EnvInfo">Environment and Deployment Information</a>
</ol>
</p>

<h3><a name="WirelessAUP">Wireless Acceptable Use Policy</a></h3>
<p>
Jay Lepreau's avatar
Jay Lepreau committed
53
By using our wireless nodes, you agree to be bound by this AUP.
54
</p>
Leigh B. Stoller's avatar
Leigh B. Stoller committed
55
56

<ul>
57
<p><li> <b>Receiving: </b>
Jay Lepreau's avatar
Jay Lepreau committed
58
59
60
61
     You may listen to and monitor anything you like.  If you happen
     to observe "private" information such as plaintext Web passwords,
     you will not exploit that information, and you will take
     care not to let it leak out publicly, e.g., in log files.
62
     </li></p>
Leigh B. Stoller's avatar
Leigh B. Stoller committed
63
     
64
<p><li> <b>Transmitting (1): </b>
Jay Lepreau's avatar
Jay Lepreau committed
65
66
67
68
69
70
     Do not transmit on channels that another experiment on the
     testbed is using, unless it's your own.  You can find out which
     channels are currently in use by looking at the top of the <a
     href=https://www.emulab.net/floormap.php3>wireless floormap</a>.
     <br>Where possible, choose channels that have the least frequency overlap
     with other experiments.  (channel/freq table coming.)
71
     </li></p>
Jay Lepreau's avatar
Jay Lepreau committed
72

73
<p><li> <b>Transmitting (2): </b>
74
75
76
77
78
     Do not flood a wireless network with non-responsive traffic for
     any significant period of time.  The following channels are
     "production networks" used by others at this location, so are
     more restricted. You may not send "large" amounts of traffic on
     them, and may send only low rates of non-responsive traffic.
Leigh B. Stoller's avatar
Leigh B. Stoller committed
79
80
81
82
83
84
     
     <table align=center border=2 cellpadding=0 cellspacing=2>
     <tr><th>Protocol</th><th>Channels</th></tr>
     <tr><td>A</td><td>36, 38, 45, 52, 56, 60, 64</td></tr>
     <tr><td>B/G</td><td>1, 3, 5, 6, 7, 9, 11</td></tr>
     </table>
85
     </li></p>
86

87
<p><li> <b>Question and Exceptions:</b> send to
88
89
     <a href="mailto:testbed-ops@flux.utah.edu">Testbed Ops</a>
     if you're not sure, or want an exception.
90
     </li></p>
Leigh B. Stoller's avatar
Leigh B. Stoller committed
91
92
93

</ul>

94
<h3><a name="CreateExp">Creating an Experiment with Wireless-Capable Nodes</a></h3>
95

96
<p>
97
To use a wireless network in an experiment, you must provide a few Emulab
Leigh B. Stoller's avatar
Leigh B. Stoller committed
98
99
specific NS directives in your NS file, which are illustrated in the
following small example:
100
101
102
103
104

	<code><pre>
	source tb_compat.tcl
	set ns [new Simulator]

105
106
	# Allocate the nodes.  Their "wifi-ness" is determined later,
	# by the type of networks you request to be set up on them.
107
108
109
	set nodew1 [$ns node]
	set nodew2 [$ns node]
	set nodew3 [$ns node]
110
	set node4  [$ns node]
111

112
	# A wireless lan connecting the first three nodes.
Timothy Stack's avatar
Timothy Stack committed
113
	set lan0 [$ns make-lan "$nodew1 $nodew2 $nodew3" 54Mb 0ms]
114

Jay Lepreau's avatar
Jay Lepreau committed
115
	# A regular duplex link from a wireless-capable node to a plain node.
116
	set link0 [$ns duplex-link $nodew1 $node4 100Mb 0ms DropTail]
117

118
	# Choose the wireless lan protocol.
119
	tb-set-lan-protocol $lan0 "80211g"
120

121
122
123
	# Set an access point.  This node becomes the access point;
	# others in the LAN become stations of it.  You can also set other
	# modes for your LAN, such as Adhoc mode.
124
125
126
	tb-set-lan-accesspoint $lan0 $nodew1

	# Choose some other settings.
127
	tb-set-lan-setting $lan0 "channel" 2
128
129
	tb-set-node-lan-setting $lan0 $nodew1 "txpower" "auto"

130
131
	# Select a wireless-capable image (i.e., FC4-WIRELESS)
	# Let the other node default to RHL-STD (currently 9.0).
132
133
134
	tb-set-node-os $nodew1 FC4-WIRELESS
	tb-set-node-os $nodew2 FC4-WIRELESS
	tb-set-node-os $nodew3 FC4-WIRELESS
135
136
137
138

	# Turn on static routing.
	$ns rtproto Static
	$ns run			</code></pre>
139
140
141
142
</p>

<p>
As mentioned above, there are two different node types with wireless
David Johnson's avatar
David Johnson committed
143
interfaces.  The <a href="/shownodetype.php3?type=pc3000w"><tt>pc3000w</tt></a> 
144
nodes are deployed in a wide range around our building.  We have also added a
David Johnson's avatar
David Johnson committed
145
single wireless interface to 36 of the <a href="/shownodetype.php3?type=pc600">
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
<tt>pc600</tt></a>s.  If you wish to include <b>only <tt>pc3000w</tt></b> nodes
in your experiment, for each node, set its hardware type:

       <code><pre>
       set nodew1 [$ns node]
       tb-set-hardware $nodew1 pc3000w
       set nodew2 [$ns node]
       tb-set-hardware $nodew2 pc3000w
       set nodew3 [$ns node]
       tb-set-hardware $nodew3 pc3000w           </code></pre>

If you wish to include <b>only <tt>pc600</tt></b> nodes in your experiment, for
each node, add a "desire" to the node:

       <code><pre>
       set nodew1 [$ns node]
       $nodew1 add-desire pc600wifi 1.0
       set nodew2 [$ns node]
       $nodew2 add-desire pc600wifi 1.0
       set nodew3 [$ns node]
       $nodew3 add-desire pc600wifi 1.0           </code></pre>

These are simply alternative ways of instructing Emulab's resource allocator,
<tt>assign</tt>, to select nodes of specific type or feature when you wish.
</p>

<p>
In this example, we created a simple infrastructure mode LAN with a single
access point.  You can also place LANs in Adhoc mode, for instance.  If you
wish to do this, do not specify an access point with the
<tt>tb-set-lan-accesspoint</tt> command.  Instead, set the mode for the LAN
explicitly:

        <code><pre>
	tb-set-lan-setting $lan0 "mode" "adhoc"
	</code></pre>
</p>

<p>
A few additional points should be noted:
186
187
188
189
<ul>
<li> <tt>lan0</tt> is created with standard <tt>make-lan</tt>
     directive, but with a bandwidth that reflects the typical speed of a
     wireless link (54Mb for 80211a and 80211g, 11Mb for 80211b). Note that
190
191
     you may not use duplex links of wireless interfaces; just LANs.
     We assign each LAN a unique ssid.
192

193
<li> After you create the LAN, choose the <em>protocol</em> for the LAN
194
     with the <tt>tb-set-lan-protocol</tt> directive. Currently, you can
195
196
     set the protocol to one of <tt>80211a, 80211b, or 80211g.</tt>. <b>If you
     fail to set the protocol, the LAN will consist of wired links</b>, most
197
198
199
200
201
     likely with delay nodes inserted!

<li> <tt>link0</tt> is a plain duplex link. You may create plain links
     as long as the nodes have enough wired interfaces. If you try to
     create an experiment that uses more links (wired or wireless) on a
Jay Lepreau's avatar
Jay Lepreau committed
202
     node than are available in Emulab, the experiment will fail to map.
203
204
205
206
     Of the current 54 wifi nodes, the 18 pc3000w wifi nodes 
     (pcwf1-18) contain two wifi cards and one wired experimental interface 
     and the 36 pc600 (all pc600s except pc8,pc11,pc30,pc38) nodes contain one wifi card and four 
     experimental interfaces.
207

208
<li> In the example above, we let Emulab decide what wireless nodes to
209
     use for the LAN. This is not an ideal approach, as Emulab does
210
211
212
213
214
215
     not currently track the connectivity of nodes, and so might pick
     a set of nodes (randomly) that cannot communicate with each
     other.  See the section below on <a href="#ChoosingNodes">choosing
     your nodes</a> for more information on how to overcome this
     problem.

216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
<li> You will want to put your LAN or individual nodes in a specific operating
     mode.  In the example above, we used the <tt>tb-set-lan-accesspoint</tt>
     command to specify that <tt>nodew1</tt> be the access point, and all other
     nodes become stations connected to that node.  Rather than using dedicated
     access points, Emulab's implementation of wireless LANs uses the
     interface's capability to become an access point for a LAN. The node that
     is chosen to be the access point should obviously be within range of all
     of the nodes in the LAN. There is currently no automated mechanism to pick
     the access point for you, but one is planned for the future.  If you wish
     to put your LAN into another operating mode (i.e., Adhoc), you must
     specify this via the <tt>tb-set-lan-setting</tt> command.  In the above
     example, you could add:
     <code><pre>
             tb-set-lan-setting $lan0 "mode" "adhoc"
     </code</pre>
     For more information on wireless modes, see the section of this document
     entitled <a href="#LinkConfig">Wireless Link Configuration Settings</a>.

<li> Wireless LANs allow a number of configuration parameters to be
     specified, either for the LAN as a whole, or for individual members of
     a LAN. There are two Emulab specific directives that you can use;
237
     <tt>tb-set-lan-setting</tt> sets a configuration parameter for the
238
239
     entire LAN. In the example above, we set the channel to be used for
     the LAN to channel five. Per-node settings can be specified with the
240
241
242
243
     <tt>tb-set-node-lan-setting</tt> directive. In the example, we set the
     transmit power for <tt>nodew1</tt> to auto; all other nodes will
     default to an interface specific setting.

244
245
246
247
<li> You must use Fedora Core 4 or RedHat 9.0 to take advantage of wireless
     interfaces. Be sure to set the OSID for all of your wireless nodes to
     <tt>FC4-WIRELESS</tt> or <tt>RHL90-WIRELESS</tt>.  <tt>FC4-WIRELESS</tt>
     contains a 2.6.x kernel and very recent madwifi drivers; 
248
249
250
     <tt>RHL90-WIRELESS</tt> contains a 2.4.x kernel.  <b>We strongly
     suggest</b> you use <tt>FC4-WIRELESS</tt> unless you specifically require
     a 2.4.x Linux kernel.
Kirk Webb's avatar
   
Kirk Webb committed
251

252
</ul>
253
254
255
</p>

<h3><a name="LinkConfig">Wireless Link Configuration Settings</a></h3>
256

257
<p>
258
Numerous interface settings are possible using <tt>tb-set-lan-setting</tt>
259
260
261
262
263
264
265
266
267
268
269
and <tt>tb-set-node-lan-setting</tt>.  These mostly correspond to options
that are available using the <tt>iwconfig</tt>, <tt>iwpriv</tt>, and
<tt>wlanconfig</tt> commands on Fedora Core 4 or Redhat 9.0.  
For <tt>iwconfig</tt>-specific options, the format of the value you provide for
the option must be acceptable to iwconfig.  
At some point in the future we hope to make this more
explicit so that know exactly what options are available each type of card, and
what their legal values are.  For now you will want to be familiar with
<tt>iwconfig</tt> and the <a href="http://www.madwifi.org">madwifi drivers</a>
for Atheros chipsets.  Here is a guide to what you can currently specify:
</p>
270
271

<ul>
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
<li> <tt>mode</tt>: Set the mode for the LAN or interface.  The mode argument
     may be one of <tt>Master</tt>, <tt>Managed</tt>, <tt>Adhoc</tt>, or
     <tt>Monitor</tt>.  <tt>Master</tt> makes the interface become an access
     point (note that you probably do not want to set an entire LAN in
     <tt>Master</tt> mode).  <tt>Managed</tt> makes the LAN or interface become
     a station which connects to an access point, if one exists.
     <tt>Adhoc</tt> puts the interface or LAN into ad-hoc mode.
     <tt>Monitor</tt> puts the interface or LAN into monitor mode, which may be
     useful for network sniffing.  Note that the <tt>Adhoc</tt> and
     <tt>Monitor</tt> values can be given when calling
     <tt>tb-set-lan-setting</tt>, but you probably only want to pass
     <tt>Master</tt> or <tt>Managed</tt> values to
     <tt>tb-set-node-lan-setting</tt>.  In fact, you can more easily set
     nodes to be access points by calling <tt>tb-set-lan-accesspoint</tt>
     for a wireless LAN; in this way, the node you specify will be the access
     point and all others in the LAN will become stations of it.

<li> <tt>freq</tt>: Set the channel for the LAN to either a
     channel number or a frequency.  If you set the value to an integer
     less than 1000, you are setting a channel number; if you set the value to
     an integer greater than 1000, or to a floating point number with a unit
     (i.e., 2.437GHz), you are setting a frequency directly.  
     If you do not set the channel one will be choosen for you, and that's
     probably just as bad as setting it yourself without knowing what other
     people are using!

<li> <tt>rate</tt>: Some interfaces support setting a bit rate
299
300
     different then the default. The default is to tell the interface
     to use "auto" mode (varies the rate according to RF conditions),
301
     but you can specify a specific rate for either the entire LAN or
302
     for just one node. The value should be in bits per second with no
303
304
     units, or a floating point value with a unit (i.e., 11M, 54M). See the 
     <tt>iwconfig</tt> man page for more details on the format of this option. 
305

306
<li> <tt>txpower</tt>: Some interfaces support setting the transmit
307
308
309
310
311
     power to something different then the default. The default is to
     tell the interface to use "auto" mode. See the iwconfig man page
     for more details on the format of this option. Not all interfaces
     support this option. 
     
312
313
<li> <tt>sens</tt>: Some interfaces support setting the <tt>sens</tt> 
     parameter (i.e., sensitivity)
314
315
316
     to something different then the default. The default is to
     tell the interface to use "auto" mode. See the iwconfig man page
     for more details on the format of this option. Not all interfaces
317
318
319
320
321
322
323
324
325
326
327
328
329
     support this option.

<li> <tt>rts</tt>: This parameter can be set to enable RTS/CTS.  From the
     <tt>iwconfig</tt> man page: "This parameter sets the size of the smallest
     packet for which the node sends RTS; a value equal to the maximum packet
     size disables the mechanism."  You can also set the value to "auto" or
     "off"; note that the default is "off" on our hardware.  Setting this
     parameter may not have the intended result on all hardware.

<li> <tt>frag</tt>: Any IP packets larger than the value of this parameter 
     will be split into multiple packets.  The value should be specified in
     bytes.  You can also set it to "auto" or "off".

330
</ul>
Leigh B. Stoller's avatar
Leigh B. Stoller committed
331

332
333
334
335

<h3><a name="DynamicLinkConfig">Dynamically Configuring Wireless Links</a></h3>

<p>
336
337
338
339
After your experiment is swapped in, the above settings (including the
accesspoint) can be changed on the fly, using either the
<tt>link_config</tt> script on <tt>users.emulab.net</tt>, or with the
XMLRPC interface. For example, if you want to change the accesspoint
340
of a LAN, first determine the MAC address (dotted or undotted notation
341
342
343
344
345
346
347
348
349
350
351
352
353
354
is fine) of the interface you want to be the accesspoint, and then use
link_config:

<code><pre>
	link_config myproj myexp lan0 accesspoint=00:09:5B:94:26:AF
</code></pre>

Or you can use the <a href=../xmlrpcapi.php3>XMLRPC interface</a> from
your desktop or from <tt>users</tt>.

<code><pre>
	sshxmlrpc_client.py link_config proj=myproj exp=myexp
		link=lan0 "params={'accesspoint': '00:09:5B:94:26:AF'}"
</code></pre>
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
</p>

<p>
If you want to change your LAN to adhoc mode, you can simply run
<tt>link_config</tt> from <tt>users.emulab.net</tt>:

<code><pre>
        link_config myproj myexp lan0 mode=adhoc
</code></pre>

Or you can use the XMLRPC client on <tt>users.emulab.net</tt>:

<code><pre>
        sshxmlrpc_client.py link_config proj=myproj exp=myexp
                link=lan0 "params={'mode': 'adhoc'}"
</code></pre>
</p>
Leigh B. Stoller's avatar
Leigh B. Stoller committed
372

373
<p>
Leigh B. Stoller's avatar
Leigh B. Stoller committed
374
You may also change the settings for an individual node in a wireless
375
LAN (although in some cases this could make the LAN unusable if you
Leigh B. Stoller's avatar
Leigh B. Stoller committed
376
377
378
379
380
381
382
383
384
385
were to change a setting on just a single node). To do this, use the
<tt>-s</tt> option to link_config or the <tt>src</tt> argument to the
XMLRPC interface:

<code><pre>
	link_config -s nodew1 myproj myexp lan0 txpower=50

	sshxmlrpc_client.py link_config proj=myproj exp=myexp
		src=nodew1 link=lan0 "params={'txpower': 50}"
</code></pre>
386
</p>
387

388
<p>
389
To <em>enable</em> and <em>disable</em> the interface for individual
390
nodes on the LAN:
391
392
393
394
395
396
397
398
399
400
401

<code><pre>
	link_config -s nodew1 myproj myexp lan0 enable=no
	link_config -s nodew1 myproj myexp lan0 enable=yes

	sshxmlrpc_client.py link_config proj=myproj exp=myexp
		src=nodew1 link=lan0 "params={'enable': 'no'}"

Note this currently operates by bringing the interface up/down with
the <tt>ifconfig</tt> command. 
</code></pre>
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
</p>


<h3><a name="AdvDynLinkConfig">Advanced Dynamic Link Configuration</a></h3>

<p>
The goal of this section is to provide extra functionality via
<tt>link_config</tt> so that you can work around issues encountered with the
combination of Linux wireless support and the madwifi drivers.
</p>

<p>
One "problem" that arises for wireless interfaces with
Atheros chipsets due to the combination of the generic Linux wireless tools and
the madwifi drivers, is that to
change modes (i.e., from <tt>Managed</tt> to <tt>Adhoc</tt>), you must actually
remove the <tt>athX</tt> device, change the mode with <tt>wlanconfig</tt>, and
finally re-create the <tt>athX</tt> device.  This effectively removes all
current <tt>iwconfig</tt> settings of the device and resets them to defaults.
Consequently, if you want to keep your settings without having to respecify
them as parameters to the command line, you can pass a flag (set the "remember"
parameter to "1") to <tt>link_config</tt> that will do this for you.  When the
"remember" flag is set, the current state of the device to be reconfigured is
captured via <tt>iwconfig</tt>.  Any parameters you specify along with
"remember" override the current settings.  If the device is currently down and
we cannot obtain current settings via <tt>iwconfig</tt>, the original Emulab
configuration from your NS file is used.
<b>Important Note</b>: Using the "remember" flag can be dangerous.  For
instance, if your device is currently operating in 80211b on channel 4, and you
try to switch it to 80211a <emph>without specifying a new channel in the 5GHz
spectrum</emph>, your kernel may panic (this has been observed on our
<tt>RHL90-WIRELESS</tt> image with the latest 2.4.x kernel and madwifi
drivers).  So, be careful!  
</p>

<p>
In other situations, the Atheros/wireless tools combination will simply not
execute your commands.  For instance, sometimes you cannot switch from one
protocol to another (i.e., <tt>80211g</tt> to <tt>80211b</tt>); <tt>iwpriv</tt>
will fail.  One solution to this problem is to remove the Atheros and wireless
kernel modules, re-insert them, and then run the configuration commands.  If
you find that some of your dynamic configuration commands fail, try setting the
"resetkmod" parameter to "1" when calling <tt>link_config</tt>.  A less drastic
approach that sometimes works is simply using <tt>wlanconfig</tt> to destroy
the <tt>athX</tt> device and re-create it with the new settings.  You can try
this by setting the "resetwlan" parameter to "1" when calling
<tt>link_config</tt>.  <b>Important Note</b>: Removing and re-inserting kernel
modules can have unintended side effects.  For instance, if you have multiple
Atheros interfaces enabled on your node, removing the modules will remove any
other <tt>athX</tt> devices you may have configured (and it might even panic
your kernel).  Unfortunately, at this time, <tt>link_config</tt> cannot work
around this possibility.
</p>


<h3><a name="ChoosingNodes">Choosing Physical Nodes</a></h3>

<p>
460
461
462
463
As mentioned above, Emulab's default mapping of nodes in your virtual
topology, to physical nodes with wireless interfaces, does not
currently take into account physical connectivity (walls, floors,
electrical conduits, etc. all conspire to make it possible that two
Grant Ayers's avatar
typo.    
Grant Ayers committed
464
wireless nodes 50 feet apart from each other will not actually be able to
465
466
467
468
469
communicate with each other). We <b>are</b> planning to add this
capability in the future, but in the meantime it is mostly up to you
to choose nodes that make sense for your topology. You might end up
having to make some trial and error runs, trying to find the right
set of nodes (including setting the accesspoint to different nodes in
470
471
a LAN) before you get a working set.
</p>
472

473
<p>
474
To assist in this chore there are two Emulab specific NS extensions
Leigh B. Stoller's avatar
Leigh B. Stoller committed
475
476
477
478
479
480
481
482
you can use in your NS file. The first approach is to use the
<tt>tb-use-physnaming</tt> extension.

	<code><pre>
	tb-use-physnaming 1
	
	set pc222 [$ns node]
	set pc223 [$ns node]
Jay Lepreau's avatar
Jay Lepreau committed
483
	set pc224 [$ns node] </code></pre>
Leigh B. Stoller's avatar
Leigh B. Stoller committed
484
485
486
487
488

which says that whenever a node is named by an existing physical node
in the testbed, do an implicit fix-node. This saves a little bit of
typing, and in some cases might be easier to manage then the second
approach, which is to use <tt>tb-fix-node</tt> for all (or some) of
489
the nodes in your LAN. Using the
490
491
<a href=https://www.emulab.net/floormap.php3>wireless floormaps</a>
choose which nodes you want, and then in your NS file:
Leigh B. Stoller's avatar
Leigh B. Stoller committed
492

493
494
495
496
497
498
499
	<code><pre>
	set nodew1 [$ns node]
	set nodew2 [$ns node]
	set nodew3 [$ns node]

	tb-fix-node $nodew1 pc222
	tb-fix-node $nodew2 pc223
Jay Lepreau's avatar
Jay Lepreau committed
500
	tb-fix-node $nodew3 pc224 </code></pre>
501
502

Keep in mind that the physical nodes you choose must be free when you
Leigh B. Stoller's avatar
Leigh B. Stoller committed
503
swap in your experiment!
504
505
506
507
508
</p>

<h3<a name="Hardware">Hardware Details</a></h3>

<p>
David Johnson's avatar
David Johnson committed
509
The <a href="/shownodetype.php3?node_type=pc3000w"><tt>pc3000w</tt></a wifi 
510
511
nodes each contain two 
<a href="http://netgear.com/products/details/WAG311.php"> Netgear WAG311 
David Johnson's avatar
David Johnson committed
512
cards</a>, which use the Atheros 5212 802.11a/b/g chipset.  Each <a href="/shownodetype.php3?node_type=pc600"><tt>pc600</tt></a> node
513
514
515
516
517
518
519
contains a single <a href="http://www.dlink.com/products/?sec=0&pid=306">
D-Link DWL-AG530</a>, which also use the Atheros 5212 chipset.  This chipset is
quite flexible since most of the 802.11 MAC layer is handled in software.  
Emulab provides the standard madwifi Atheros driver by default, but there are 
alternatives such as the madwifi stripped driver from the MIT roofnet project
and SoftMAC from the Universtiy of Colorado at Boulder.  Here are some useful
links: 
520
<br>
521
522
523
524
525
526
527
528
529
530
531
<ul>
<li><a href="http://netgear.com/products/details/WAG311.php">
Netgear WAG311 product info</a>
<li><a href="http://www.dlink.com/products/?sec=0&pid=306">
D-Link DWL-AG530</a>
<li><a href="http://madwifi.org">Madwifi Atheros driver</a>
<li><a href="http://pdos.csail.mit.edu/~jbicket/madwifi.stripped/">
Stripped madwifi driver</a> - <i>Primarily for use with
<a href="http://pdos.csail.mit.edu/click/">click</a></i>
</ul>
</p>
532

533
<h3><a name="EnvInfo">Environment and Deployment Information</a></h3>
534

535
<p>
536
537
538
539
Due to the dense nature of the pc600 mini-cluster, we describe some of its
properties and deployment characteristics in detail in this section.  You can
view a map of the deployment 
<a href="https://www.emulab.net/floormap.php3?building=MEB-MRC600">here</a>.
540
</p>
541

542
<p>
543
544
545
546
547
548
549
550
551
The external antennas for each wireless interface in the pc600s are deployed in
a 6 x 6 grid on the back side of the racks housing the pc600s and pc850s.  Each
antenna is currently pointed straight down towards the floor.  The
grid is 300cm x 224cm.  All nodes in the grid are easily able to communicate
with each another; the interesting nature of this grid becomes more evident
when many nodes attempt to send packets at the same time.  Because the nodes
are deployed in our machine room, the environment is hostile, with many other
racks, machines, conduits, and other items, conspiring to provide various types
of signal interference.
552
</p>
553

554
<p>
555
556
557
558
559
560
561
562
563
To give you an idea of what you might expect when many nodes in proximity are
sending packets at the same time, we ran some simple tests.  In this
experiment, all nodes are placed in ad-hoc mode in a single LAN, and send
packets all at once to the broadcast address in their subnet.  Each node sends
1000 1024-byte packets at a rate of 10pps.  We then do this iteratively over
all channels in each of a, b, and g modes.  The results are presented in terms
of the percentage of broadcast packets received at each node.  The Aggregate
Statistics table simply aggregates all statistics gathered from each 802.11
mode across all receivers.
564
</p>
565

566
<p>
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
<center>
<table>
  <tr>
    <td colspan="6"><center>Aggregate Statistics</center></td>
  </tr>
  <tr>
    <td>Mode</td>
    <td>min</td>
    <td>mean</td>
    <td>max</td>
    <td>stddev</td>
    <td>var</td>
  </tr>

  <tr>
    <td>802.11 a</td>
    <td>0.10</td>
    <td>65.21</td>
    <td>99.40</td>
    <td>15.69</td>
    <td>246.27</td>
  </tr>
  <tr>
    <td>802.11 b</td>
    <td>2.10</td>
    <td>25.19</td>
    <td>91.10</td>
    <td>15.01</td>
    <td>225.25</td>
  </tr>
  <tr>
    <td>802.11 g</td>
    <td>0.30</td>
    <td>26.04</td>
    <td>83.10</td>
    <td>15.84</td>
    <td>250.99</td>
  </tr>
</table>
</center>
607
</p>
608

609
<p>
David Johnson's avatar
David Johnson committed
610
611
612
613
Finally, here are some pictures of the pc600 mini-cluster.  On the back of the
racks, you can see the antennas in the 6 x 6, 36-node grid.  Some antennas are
outlined to make them easier to see; however, once you find the corners of the
grid, it becomes easier to spot them all.
614
</p>
615

616
<p>
David Johnson's avatar
David Johnson committed
617
618
619
620
621
622
623
624
625
626
627
628
<center>
<a href="pc600wifi_back.jpg"><img src="pc600wifi_back_thumb.jpg"></a>
&nbsp;
<a href="pc600wifi_back_marked.jpg"><img src="pc600wifi_back_marked_thumb.jpg"></a>
&nbsp;
<a href="pc600wifi_back_detail.jpg"><img src="pc600wifi_back_detail_thumb.jpg"></a>
<br>
<br>
<a href="pc600wifi_front_left.jpg"><img src="pc600wifi_front_left_thumb.jpg"></a>
&nbsp;
<a href="pc600wifi_front_right.jpg"><img src="pc600wifi_front_right_thumb.jpg"></a>
<center>
629
</p>