Deploying Public WLANs

By Jim Geier

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.

Refer to my previous tutorial on defining requirements for details on common

requirements types. 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. 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.