The growth of public WLANs will be very high over the next few years. Companies are deploying these visitor-friendly WLANs in "hotspots" where people congregate, such as airports, convention centers, hotels, and marinas throughout the World. It won't be long until we become reliant on having WLAN access just about everywhere we go.

If you own a facility that has public areas, then consider deploying a WLAN to provide wireless broadband network services to mobile visitors. Candidate hotspots include those where people visit regularly on a temporary basis and need or desire access to network services. In some cases, the addition of a public WLAN will provide a source of revenue as you bill subscribers. Other situations might not generate revenue, but they could increase the use of your establishment.

Getting started on the right foot

If you're serious about deploying a public WLAN, develop a business plan and assess the financial aspects of the endeavor first before spending too much money. Think about whether people will actually utilize your WLAN and how much they are likely to pay. Don't depend too much on the "we shall build it, and they will come" mentality.

As a facility owner, you can deploy your own public WLAN as a "grass roots" operator. Your solution could be as simple as placing an access point within range of the visitors, and pay for an Internet connection through a local ISP (Internet service provider). This works well if the number of users is somewhat limited, such as a privately-owned coffee shop, but you'll need a more elaborate system to support masses of users and multiple locations.

A hotel chain, for example, should focus on defining requirements and properly designing the system to provide access control, roaming, and billing in addition to traditional WLAN elements. For these higher-end solutions, a facility owner generally outsources the project to a system integrator. In this case, the facility owner directly owns the network and the responsibilities in line with a wireless ISP (WISP). This could be the best way to go if you have a very clear business plan, that is, there's not much risk in achieving your revenue goals.

In some cases, companies in the business of deploying public WLANs will install the system free-of-charge and utilize a business plan similar to vending machines. The facility owner receives a small percentage of the profits by having the WLAN within their confines, and the public WLAN vendor banks on having profit left over after collecting the subscription fees from users and paying all costs. If revenue predictions for WLAN subscribers are a bit shaky, then the vending approach will reduce risks for the facility owner. Of course, you'll need to convince a vendor to install the system.

Defining requirements

Requirements define what the system is supposed to do. Spend some time near the beginning of the project to adequately identify and analyze the needs of users, existing systems, potential RF interference, and so on. Public WLANs involve defining requirements similar to private ones, but be prepared for some additional components.

In general, you need to define the types of applications that users will need. For example, you might enable the use of e-mail and Web browsing as a basic service. As options, you could include the use of VPNs and video conferencing.

The following are suggestions for defining requirements that pertain specifically to public WLANs:

Keep the user interface as open as possible. With public WLANs, be sure the solution interfaces with the widest possible number of users. This maximizes the number of subscribers. Most WLAN users today have 802.11b radio NICs, but plan ahead and insist on access points that support both 802.11b/g and 802.11a.

Provide adequate authentication mechanisms. To regulate access to the network, the system needs to include a process that requires users to subscribe and log in. RADIUS is the most common authentication database in use today, but be sure to require authentication elements that provide a level of security consistent with application requirements.
Enable widespread roaming. If you plan to deploy a public WLAN at multiple sites, then you need to accommodate users that will be roaming from site-to-site. Consider interfacing with other WISPs to provide the widest possible roaming capability for your subscribers. In that case, however, you'll need to include a settlement function that mediates the financial transactions. For example, you'll want some of the profits applied to your account if one of your subscribers operates within an area covered by a different WISP. Your WISP partner will want the same in return.

Consider implementing local advertisements. A public WLAN can provide a mechanism to deliver advertisements to subscribers similar to other online services. In fact, you can provide a free subscription to users for basic Internet access, and drive ads to them with hopes that they'll purchase enough from the ads to offset the cost of system. Keep the advertising to a minimum, though, especially when users are paying for services.

Virtual Private Networks (VPNs). In hotspots where business travelers may be present, ensure your public WLAN supports VPN traffic. In many cases, people on the road must use their company's VPN to access corporate resources.

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.

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 is an independent consultant and founder of Wireless-Nets, Ltd (www.wireless-nets.com), a consulting firm assisting municipalities, enterprises, hospitals, airports, and equipment providers with the development and deployment of wireless networks.