Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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-