Download Wireless PCS Project - Winlab

Wireless PCS Project
Dynamic Channel Assignment for WiFi Access
Points (Hardware Team)
14:332:424 Wireless Personal Communication Systems
Rutgers University, School of Engineering
Department of Electrical and Computer Engineering
Group Members (Spring 2004):
Marcel Bautista
Derek Ng
Dynamic Channel Assignment for WiFi
Access Points (Hardware Team)
Objectives of Design Project ............................................................................ - 1 Conclusion......................................................................................................... - 1 Theoretical Considerations............................................................................... - 1 List of Equipment .............................................................................................. - 1 Procedure.......................................................................................................... - 2 Observed Results ............................................................................................. - 2 Flow Chart Logic ............................................................................................... - 4 Testing............................................................................................................... - 5 Summary / Discussion Section: Marcel Bautista ............................................. - 6 Summary / Discussion Section: Derek Ng....................................................... - 8 Original Data Sheets......................................................................................... - 9 Source Code ..................................................................................................... - 9 -
Dynamic Channel Assignment for WiFi Access
Points (Hardware Team)
Objectives of Design Project
The objective of this project is to analyze, design, build and test a method to assign broadcast channels
for optimal network performance. Considerations include:
1. Using current Access Point (AP) functionality
2. Minimizing the requirement of additional hardware
3. Automating the process
4. Realizing a solution that could be implemented within 10 weeks
Conclusion
In this given spring ’04 semester, it was possible for the Hardware Team to write a Perl program that
can communicate to a given access point exchange parameters. In addition, a “Make Do” algorithm
was developed to dynamically assign the best channel for multiple APs to broadcast on in order to
coexist.
Theoretical Considerations
Wireless networks, as the name implies, are comprised of stations that communicate with one another
without the use of wires. IEEE 802.11 is a networking protocol that encapsulates IEEE 802.3 (Ethernet
protocol) frames in order for stations to successfully transfer packets in the wireless network. Random
environmental electromagnetic radiation (i.e. cosmic rays) can interfere with the channel and therefore
hinder network performance. In addition, WiFi devices can also interfere with other WiFi devices. Given
the fact that users can control WiFi devices, it is important for AP channel management to maximize
the performance of such WiFi networks. Channel management implies the separation of APs in
frequency so that all stations have optimal bandwidth.
List of Equipment
For this project, we utilized the following devices:
•
Linksys WRT54G 802.11 b/g AP/router (FW “Nirvana v.2.00.8.4sv”)
•
IBM ThinkPad R32 (P4 1.8 GHz, 256 MB RAM, Cisco PCI Wireless LAN Adapter, Intel
PRO/100 VE Adapter)
•
Perl v.5.8.3 for MSWin32-x86-multi-thread Compiler
•
WildPackets AiroPeek NX Version 2.0
-1-
Procedure
The project would need to be broken into different sections and attended to one at a time.
1. Selecting an AP – In the end, the Linksys WRT54G AP/router was chosen because when
loaded with the properly modified firmware, a user can remotely control the device through
telnet access. In addition, the modified firmware supports many functions and comes with a
documented Application Programmer Interface (API).
2. Selecting the programming language – For a coding language, Perl was chosen due to its
telnet module library allows scripting to interact with telnet commands and client responses.
3. Designing an algorithm – An algorithm was chosen to have a given AP measure the “Channel
Quality” for all possible 11 WiFi channels in the US. “Channel quality” is a term derived from
the API. No qualitative significance has been defined for each possible channel quality value.
And unfortunately, the values are not very precise (ranging from 0 to 3, where 0 corresponds
to AP with its radio turned off). After scanning, the AP would we be assigned to broadcast on
the first channel with the highest returned “Channel Quality” value. For the scenario with
multiple APs, initially, all APs would be turned off. Next, an AP would turn on and run the
algorithm and remain on. One by one, additional APs would turn on, run the algorithm, and
assume the channel the best available remaining channel.
Observed Results
We will point out any peculiarities accord to their previously defined section:
1. Selecting an AP – Few APs support telnet management. The Cisco Aironet 350 series
supports this feature but runs approximately $450. On the contrary, the Linksys WRT54G
AP/router runs $85. For the series of experimental testing and modeling, the Linksys device is
the more economic choice. In order to enable telnet management, users must load an
unsupported firmware release onto the WRT54G. As a note, not all features in the API function
as described. Much time was spent testing and verifying the proper cause-effect relation for all
AP function calls with AP behavior. AiroPeek NX was used to verify such features as (setting
SSID, setting broadcast channel, etc.)
2. Selecting the programming language – Perl code runs similar syntax as C/C++ but is less strict
with its set code structure. Furthermore, for our networking application, C/C++ would require
the analysis and dissection of the telnet application source in order to understand how to
interact with client responses. In the end, using C/C++ would require the writing of a mini-telnet
application. We chose to use telnet to communicate with the device because using Simple
Network Management Protocol (SNMP) would require too much time for us to become familiar
with in order to implement it correctly for our needs.
-2-
3. Designing an algorithm – The algorithm was based on the theory that each AP will need to
make do with what frequency resources it has available. After scanning all channels, it will
have to pick the channel with the highest returned “Channel Quality” value. Not counting a
powered down radio antenna, the algorithm can only work with 3 states. For this project, it will
be assumed that the range is an incremental range where a Channel Quality “1” relates to a
noisy channel and not the best choice for transmission. On the other end of the range, a
Channel Quality “3” means that the channel is best for transmissions
Channel Quality is the preferred metric for two reasons:
•
The AP can generate this value without the use of additional hardware
•
It is an API supported function
The utilization of a different metric that requires additional hardware can increase the cost for
deployment of wireless networks. The cost for deployment increases due to the cost for
additional hardware and the additional real estate required to install it. The additional real
estate may become an issue for metropolitan deployment similar to the cost for deploying
cellular towers. In addition, because “Channel Quality” is an API function, it will not require
rebuilding the wireless driver to include a new measurement function.
An alternative metric would be to use Received Signal Strength Intensity (RSSI) or Signal to
Noise Ratio (SNR). RSSI is an optional IEEE 802.11 1-byte parameter that vendors may
choose to implement to their WiFi devices. A more detailed description can be found in Section
14.2.3.2 of the IEEE 802.11 standard. Although the specification asks for 256 possible
quantized levels, vendors do not always use choose to 256 discrete levels. Symbol uses 32
levels while Cisco uses 101 discrete levels. (Bardwell 4) RSSI would be a better solution than
“Channel Quality” because it can provides a sharper description of the transmission channel
by using more quantized levels. Documentation also exists to convert vendor RSSI values to
exact milliwatt power levels. Unfortunately, RSSI is only computed on the station (STA) side.
At the time of this document, the WRT54G can only function as an AP and therefore cannot
calculate an RSSI value. The WRT54G wireless driver supports the RSSI function, but would
require the AP to be turned into an STA. In the end, to use RSSI as a metric for any algorithm,
one would require the use of an STA to compute the RSSI value. This would require additional
hardware and raise the cost of a solution. SNR would also require the use of additional STA
and would run into the same problem as RSSI.
The algorithm in general has some flaws. The “Channel Quality” metric is only an
instantaneous measurement of the channel and does not accurately reflect its performance.
The measurement does not represent the channel performance over a period of time with
-3-
varying degrees of network traffic, environment noise, and other factors. It has not been
determined how to sample the channel in order to accurately represent the channel. With a
one time scan of each 11 WiFi channels, the process takes slightly over 10 seconds. By
sampling each channel multiple times, the entire process can quickly change to taking minutes
to finish. At some point, time will become a factor to determine whether administrators will use
this algorithm.
This algorithm has yet to be quantified in order to see exactly how the WiFi network will perform after
running the script.
Flow Chart Logic
The following figure depicts the logic of the entire script.
Initiate Script
Terminate Script
No Addresses
Left
Check Access
Point Address
Listing
Has
Addresses
Left
Run “Make Do”
Algorithm
-4-
The following figure depicts the logic of the “Make Do” algorithm.
Run “Make Do”
Algorithm
Initiate Contact
with AP <n>
Set to Channel 3 .
..
Set to Channel 1
& Query for
“Channel Quality”
& Set “Best
Channel Value” to
to Channel 1's
value
Set to Channel 12
..
Check if
Channel 12
has the better
than “Best
Channel
Quality” value
Set to Channel 2
& Query Channel
Status
Set Highest
Channel
Performance to
Channel 2 &
Channel 2
“Channel Quality”
Yes
Check if
Channel 2 has
the better than
“Best Channel
Quality” value
Yes
Set Highest
Channel
Performance to
Channel 2 &
Channel 2
“Channel Quality”
No
Assign AP <n> to
Channel with
“Best Channel
Quality”
No
Terminate
Algorithm
Testing
The hardware team has implemented comm3.pl which functions as follows:
-5-
The script works as follows:
1-
Command: perl DMJNvF.pl -checkall
Purpose: Scans all IPs listed in the ips.txt file for channel quality measurements and spits this
info into Output.txt.
2-
Command: perl DMJNvF.pl -makedoall
Purpose: Dynamically scans all APs and assigns best channel according to Make Do
algorithm.
3-
Command: perl DMJNvF.pl -algo
Purpose: Initiates algorithm group's code for best channel assignment.
4-
Command: perl DMJNvF.pl -cssid
Purpose: Changes the SSID of IP chosen by user.
5-
Command: perl DMJNvF.pl -changec
Purpose: Changes the channel of IP chosen by user.
The script also kicks out a debugger text file log that records all communications between the host
machine and APs.
The script DMJNvF.pl includes the algorithm group’s work into the comm3.pl script.
It should be important to note that for the demo, we originally used a master router running a DHCP
server to assign all child APs with IPs in the reserved 192.168.x.x range. The child APs were also
running their own DHCP servers to assign connected stations with 192.168.x.x IP address. This
careless oversight cost us 2 hours of debugging to remember that stations connected to all child APs
would not be able to route packets to the master router using the 192.168.x.x setup. All packets
destined for the master AP would not route outside the child AP. Subsequently, we chose to use the
Class A 10.0.1.x range.
Summary / Discussion Section: Marcel Bautista
The process of initiating a conversation and issuing commands to the WRT54G was, at first, a highly
improbable task. In the planning stages of this project, Derek and I were faced with choosing between
either the Telnet or SNMP protocol in order to communicate with the AP. Ultimately, we decided on
Telnet since we were both familiar with its usage and also because our knowledge of SNMP was
limited.
Derek and I were given a presentation on how to “flash” an AP with modified firmware. After gaining
this ability, we quickly sought out firmware that would enable Telnet communication to the AP. With the
-6-
official Linksys firmware packaged with the AP, Telnet is not an option. That is why we eventually
settled on Nirvana v2.00.8.4sv which, amongst other functions, gives the option to enable Telnet.
We can now talk to the AP, but what then? The next step was to find out how to issue relevant
commands such as changing channels and finding a channel quality measurement. We were able to
find documentation of the wireless driver online at
http://www.seattlewireless.net/index.cgi/LinksysWrt54g. By manually initiating communication with the
AP through Telnet and issuing learned commands, we were half way to our goal. The next step was to
automate the process.
We chose Perl as the language in which to write our automated script. We did this for several reasons.
1. Perl is portable over many different operating systems including, but not limited to, Linux, Unix,
and Windows.
2. It is open source and available for free.
3. It includes PPM (Perl Package Manager) which allows one to download scripts created by
different authors that increase the functionality of Perl.
4. Perl is very similar to other programming languages so the learning curve was not so steep.
Tutorials on writing in Perl were easily found on the internet. My first step was to learn how to print
statements to the prompt. After meeting this requirement, I picked up file I/O and creating and deleting
new files. The last step was to familiarize myself with the Perl module, Net::Telnet. Net::Telnet is very
useful in that we did not have to write our own script to handle sockets and individual time-outs for
connecting, reading, and writing could be set. After picking up a few key commands such as opening a
host and issuing personalized commands through Net::Telnet, I was able to program a script that would
initiate a conversation with one AP, begin a scan of all channels, and output the results to a file. Just for
testing, I created a dump log which helped me debug the program.
Once completed, I modified the script to be able to scan channels of multiple APs. This took a little bit of
tweaking and was not too difficult. To aid in this process, I created a file from which the script would
read all the IP addresses of each AP. The script worked as expected; it kicked out channel quality
measurements for all 11 channels for each AP to one file.
To test the script, I implemented our “Make Do” algorithm in Perl. At run time, our script would follow the
algorithm for each AP. Once the best channel was found and scanning was complete, said AP would
be set to said channel and the process would repeat for the next AP. We were able to test the script
over 4 APs. It passed with flying colors. The script has the ability to work over more than just 4 APs, but
one drawback is that scanning each AP takes about 10 seconds. With 4 APs, the process draws near
-7-
to one minute. With even more APs, the time increases by multiples of 10 seconds. Our script would do
well in a small, closed environment where the number of APs is not excessive (such as on the order a
hundred).
The largest obstacle in meeting our goal was learning the exact syntax of Perl. All though similar to
C/C++, Perl still takes some time to get used to. Its real power is in pattern matching and extracting
data from other programs, text files, or web pages. When checking the channel quality of a specific
channel, the output has the following syntax:
channel_qa is n
where ‘n’ must be extracted into a scalar value in order to be of any use to the script. This was made
possible through the power of Perl.
In conclusion, after ten weeks of work, I believe that the script we have created is fully functional and
meets the expectations of this project. With one command, we are able to sort through every channel
on every AP, find the best channel, and set each AP to its own personal best channel.
Summary / Discussion Section: Derek Ng
The bulk of this project came in the planning and management for solving the AP channel allocation. It
was essential to understand our allotted time frame in order to ascertain the degree of complexity that
we would use in building a solution. Consequently, it was decided early on that 5 weeks would be
sufficient to theorize and write an alpha solution for managing APs. The following 2 weeks would be
designated to finalizing the working solution. Afterwards, 1 week would be allotted for the full
documentation of the project.
The selection for hardware and programming language were chosen after some preliminary research
into the capabilities of each. The use of the Linksys WRT54G proved to be a cost effective component
for this preliminary attempt at channel management. Perl was chosen as a proper programming
language due to its operating system independence, supporting network library, and free cost.
While doing most of the theoretical research for our chosen solution, it is important to acknowledge its
shortcomings:
1. The solution requires APs to require telnet management. Few products support this feature.
The algorithm could be adapted for SNMP, a more common supported feature if SNMP could
return a quality metric.
-8-
2. We depend on an AP to generate a channel_qa metric. The metric is vague for our project.
With this Linksys, the AP provides only 3 useful states. With few discrete levels, it is not easy
to quantify the exact channel quality.
3. The demo works only a homogenous network. The scripting will only work for the Linksys
WRT54G. It makes specific calls to the wireless driver that not all APs support.
4. The algorithm can only manage APs that are connected to a common infrastructure.
5. The script is currently fixed to only scan the 11 allowed WiFi channels for 802.11b/g in the
United States.
Future development of the solution will possibly rectify these downfalls.
Original Data Sheets
Bardwell, J. (2002). Converting signal strength percentage to dBm values.
http://www.wildpackets.com/elements/whitepapers/Converting_Signal_Strength.pdf
(9 Mar. 2004).
LinksysWrt54g - SeattleWireless.
http://www.seattlewireless.net/index.cgi/LinksysWrt54g (9 Mar 2004).
Source Code
-9-