Deploying Public WLANs – Part 2

Deploying Public WLANs – Part 2

Photo of author
Written By Eric Sandler

Designing the system

A good design involves the application of technologies and products to bring about a system that satisfies requirements. For example, you’ll need to determine the optimum location of access points and find out whether there is any significant RF interference that will impact performance. As we’ve discussed in previous tutorials, perform an RF site survey to assess the situation. After you complete the survey, you’ll have a good idea of the placement of access points, which provides a basis for assigning radio channels and other 802.11 MAC (medium access control) features, such as RTS/CTS (request-to-send / clear-to-send).

For a public WLAN, also focus on the requirements we discussed above. To satisfy open user connectivity, design the system in a way that minimizes changes necessary on end users devices. In other words, ensure that the user interfaces don’t require upgrades to their operating systems, installation of special connectivity software, and other items as a basis for connectivity. For example, all users should need is a laptop or PDA, wireless NIC, and a Web browser.

For authentication, deploy a controller that regulates access to the protected network services you’re providing to users. There are a number of companies, such as Bluesocket, Reefedge, and Nomadix, offering access controllers for use in pubic WLANs. Vendors such as Cisco and Proxim also offer some effective access control mechanisms resident within their access points.Whether or not you should purchase a separate access controller or use a “smart” access point depends on your specific requirements. If there are lots of hotspots with only a few users at each one, then it makes sense to use lower end access points in the facilities and have a separate controller at a central point to serve the multiple hotspots. If you have many users at the hotspot, then an access point with built-in access control features would be your best way because it localizes control and improves performance.

To satisfy roaming requirements, you’ll likely need dedicated access control components, especially if the system spans many locations. By the way, there are no complete standards for roaming in public WLANs. So, choose a single vendor for the access control elements to maximize interoperability. Of course the problem with this, however, is you’ll have a proprietary system that’s difficult (but not impossible) to interface with other WISPs.

The Wireless Ethernet Compatibility Association (WECA) has a committee called WISPr (Wireless ISP — Roaming) defining best practices that should eventually become a standard. The WISPr committee is currently finalizing intellectual property rights (IPR) statements of those companies who’ve contributed elements to the best practices document. It would be in your best interest to choose a roaming solution supported by one or more of the member companies of WISPr in order to maximize interoperability as the standards evolve.

When configuring a public WLAN, here are some specific tips:

  • Turn WEP off. Despite all of the controversy, WEP (wired equivalent privacy) does provide some security, but WEP’s definitely not practical to use in a public WLAN because of key distribution problems. As a result use alternative, dynamic forms of security that are available on typical user devices (e.g., EAP-TLS) to satisfy the open systems requirement of public WLANs.
  • Broadcast SSIDs. The SSID (service set identifier) is an obstacle to public WLAN users because in many cases the user must configure their SSID to match the one that the local public WLAN uses. Windows XP sniffs the SSID (if the access point broadcasts the SSID) and automatically configures the radio NIC without end user intervention. As a result, be sure to enable SSID broadcasting when configuring the access point. To avoid hanging signs up in your facility indicating the SSID and instructing users on how to configure their radio NICs, offer (but do not require) smart client software that performs the SSID sniffing and card configuration for users having older Windows operating systems.
  • Include DHCP services. As users roam to different hotspots, their user device will need an IP (Internet protocol) address that corresponds to the local network. To enable roaming with as few end user actions as necessary, establish dynamic host configuration protocol (DHCP) services to automatically assign IP addresses to visiting users. Most versions of Windows operating systems by default activate DHCP, so users probably won’t have to do anything.

Supporting the users

Operational support is a problem area for companies, and public WLANs are often the most difficult to support. The quandary is that public WLANs include many different types of users, user hardware, operating systems, and NICs–a nightmare for support people. The idea of making the system as open as possible is valuable, but it introduces headaches when supporting the system. As a result, be ready to support the users by clearly identifying how to contact a help desk that will assist a variety of users, most of them computer illiterate.

Users will have trouble with configuring their network connection. For example, they may employ static IP addresses within their company facility, and they will need to switch DHCP on before accessing the public WLAN. Also, users without Windows XP need to set the SSID for their radio NIC to match the one that the public network uses. Even with DHCP on, however, some user devices may not properly renew the IP address, leaving the user without a network connection. Become familiar with these types of problems, and be ready to help users.

Jim Geier provides independent consulting services to companies developing and deploying wireless network solutions. He is the author of the book, Wireless LANs (SAMs, 2001), and regularly instructs workshops on wireless LANs. Join Jim for discussions as he answers questions in the 802.11 Planet Forums.

Leave a Comment