Deploying Public WLANs

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

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
, 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
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
radio channels
and other 802.11
(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
for use in pubic WLANs. Vendors such as Cisco and Proxim also
offer some effective access control mechanisms resident within their access

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
  • 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
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.

News Around the Web