Location Discovery in Enterprise-based Wireless Networks: Case Studies and Applications

Transcription

1 1783-Her/Telecom 58/3-4 19/03/03 15:34 Page 1 pp Location Discovery in Enterprise-based Wireless Networks: Case Studies and Applications Simon G. M. KOO, Catherine ROSENBERG, Hoi-Ho CHAN, Yat Chung LEE Abstract We have designed and implemented a Web service for location discovery (LODS) and a location-based printing service that uses LODS on a network with wireless LAN connectivity based on IEEE that is typical to campuses and enterprises. The need for location management and location-based services is linked to the mobility of the users. While location discovery is already implemented in cellular telecommunication networks since the system needs to know where are the users to connect them to incoming calls, the need for such a service was not so crucial in data network where in general the mobile user is the client and initiates the connections. We propose several solutions to implement our location discovery service depending on the underlying networking architecture and compare these solutions in terms of several criteria. LODS allows mobile users to find their approximate location within the campus or the enterprise and allows location-based applications to find out the location of a user to suggest the nearest points of interest, e.g., printers, elevators, and vending machines. We also present the case of our location-based remote printing service that was deployed in Purdue wireless network. Key words: SERVICES DE LOCALISATION DANS LES RÉSEAUX D ENTREPRISE SANS FILS: ETUDE DE CAS ET APPLICATIONS Résumé Nous avons conçu et implante un service Web de découverte de localisation (LODS) et un service d imprimante à distance qui utilise LODS dans un réseau d entreprise utilisant la technologie IEEE La mobilité des usagers crée des besoins nouveaux, en particulier le besoin de découvrir les ressources de proximité disponibles et pour cela le système a besoin de connaître la position de l usager. La découverte de la position de l usager n est pas un problème nouveau dans les réseaux cellulaires puisque le réseau a besoin de savoir en tout temps où est l usager pour pouvoir le connecter à des appels entrants. Dans les School of Electrical and Computer Engineering, Purdue University, West Lafayette, IN , USA. {koo,cath,hchan,lee85}@ecn.purdue.edu 1/22 ANN. TÉLÉCOMMUN., 58, n 3-4, 2003

2 1783-Her/Telecom 58/3-4 19/03/03 15:34 Page 2 2 P. BERTIN WLAN STANDARDS AND EVOLUTIONS réseaux locaux sans fils, fondamentalement des réseaux de données, le problème est plus nouveau car en règle générale dans ces réseaux les clients initient les applications et le réseau n a pas à connecter le client à des appels entrants. Nous proposons et comparons plusieurs solutions pour implanter un service de découverte de la position de l usager dépendamment de l architecture du réseau. LODS permet aux usagers mobiles de trouver leur position (de façon approximative) dans leur entreprise ou dans leur campus et il peut être utilisé par des applications de découverte de ressources qui peuvent suggérer à l usager les points d intérêt les plus proches (comme par exemple, des imprimantes, des ascenseurs, ou des distributeurs de boissons) en fonction de sa position. Nous présentons aussi une étude de cas correspondant au service d imprimante à distance que nous avons déployé à l Université de Purdue aux Etats-Unis. Mots clés : Contents I. Introduction II. Related works III. Location Discovery Service and a Network-independent Solution IV. Network-based Solutions V. Application of Lods - Remote printing service VI. Conclusion and Future Work References (17 ref.) I. INTRODUCTION Location management has been an important topic in cellular telecommunications for a long time since the cellular telecommunication network needs to know where the users are to connect them to incoming calls. This is called passive connectivity, which is a requirement in cellular systems to contact or page an idle host. The need for location discovery adds to the complexity of the cellular system, impacts the overall architecture, and increases signaling. However, in a client-server paradigm, like the one used in a wireless LAN, there is no compulsory need for of paging or passive connectivity. A host usually initiates a connection as a client, and, unless the host also wants to be a server, it will not be passively connected. This limits the need for a location discovery mechanism. However such a mechanism would be needed to create value-added applications based on location discovery such as, for example, those mapping the current location of a mobile device to the nearest points of interest such as the nearest printer or vending machine. We have designed a new Web service for Location Discovery (LODS). LODS allows mobile users, using Personal Digital Assistants (PDAs) or laptops, on an IEEE wireless LAN to find their approximate location within the campus or the enterprise and allows location-based applications to find out the location of a user to suggest the nearest points of interest, e.g., printers, elevators, and vending machines. LODS highly enhances the mobility of the hosts within a campus or an enterprise, and, more importantly, this service is easy to deploy and does not require large infrastructure investment. This is especially useful in a campus or an enterprise environment when a mobile user needs to find the closest printer, computing lab, ANN. TÉLÉCOMMUN., 58, n 3-4, /22

3 1783-Her/Telecom 58/3-4 19/03/03 15:34 Page 3 P. BERTIN WLAN STANDARDS AND EVOLUTIONS 3 elevator, cafeteria, etc. Moreover, LODS is accessible directly by common Web browsers so virtually all mobile hosts can use it without purchasing additional hardware (i.e., a GPS receiver) or software. As a Web service, LODS can automatically be accessed by other Web-based applications through a simple API call. With proper database support, LODS can also be used in metropolitan setting with wireless network connectivity, like the wireless coffeehouse. We will discuss in the following sections the reasons why we have not proceeded with a mobile device-based solution in which most of the processing to find out the current position of the device is done in the device itself. Instead we decided to create network-based solutions that take full advantage of the underlying network infrastructure and require no modifications in the mobile device. We designed such solutions for two different wireless network architectures, one using RADIUS (see later) and one using VPN (Virtual Private Networks). We deployed the first solution on the Engineering Computer Network (ECN) at Purdue University. ECN covers three buildings and comprises sixty-plus Access Points (APs). We are in the process of deploying the second solution on the Purdue Air Link (PAL) an based wireless infrastructure that covers the whole campus (it spans over more than eighty buildings and hosts more than 38,000 students) and comprises hundreds of APs. These two based wireless networks have different configurations and characteristics and their case studies illustrate fully the extent of our solutions. FIG. 1. Remote printing scenario. Le scénario d imprimante à distance. LODS provides a service for location-based applications, which facilitates the building of an e-campus or other e-communities. An example will be our current project supported by Hewlett Packard. We have developed a Web-based remote printing service, which allows any 3/22 ANN. TÉLÉCOMMUN., 58, n 3-4, 2003

4 1783-Her/Telecom 58/3-4 19/03/03 15:34 Page 4 4 P. BERTIN WLAN STANDARDS AND EVOLUTIONS laptop or PDA with IEEE wireless access and a Web browser to print HTML, postscript, or PDF documents and all types of images to any network-connected printer without having to download the files and drivers. In the case where the mobile user is away from his office, e.g., in a different building, as shown in Figure 1, the remote-printing service can also call LODS to find the location of the mobile device to suggest the nearest printer(s) to the user. This paper is organized as follows. We will review some of the related works on location services in Section 2. We will describe the idea of LODS and present our general network settings in Section 3. A simple device-based solution, which does not depend on the underlying wireless architecture, will also be presented in that section and we will discuss its pros and cons. We believe that solutions, which are designed to take advantage of the underlying wireless configuration, will utilize the network better, and impose fewer problems on the client end. We will study two common based wireless configurations and present solutions for both settings in Section 4. Applications of LODS will be presented in Section 5, using remote printing as an example. We will conclude the paper and suggest future works in Section 6. II. RELATED WORKS Previous works on mobility ([2], [4], [5], [11], [12], and [13]) mainly considered telecommunication networks settings, which have infrastructure in place to support passive connectivity, paging, and location-based services. These works have focused on passive connectivity for which mobile devices, when idle, still have to listen to some control information, either periodically or using certain policy in case an incoming call arrives. Since in telecommunication network, the architecture and client connectivity are fundamentally different from those in wireless LAN, those schemes do not necessarily work for a wireless LAN setting. Another reason why our designs are different in that we assume that the users in our wireless network actively trigger LODS when they need it, i.e., we deal with active connectivity. Hence we are not trying here to solve the passive connectivity problem in an IEEE based network but to design LODS assuming the mobile device is initiating the request. Similar location-based online service includes go2online.com, which is providing information about nearby restaurants, shopping place, theatre, etc. to their customers via cellular phone or Palm. The key difference is go2online.com requires their customers to input their current location to query their Local Business Registry. Our service does not have such requirement. Users simply logon to the service, and LODS will locate them and suggest the nearest point of interest. Hightower and Borriello [14] surveyed some radio-frequency (RF) and GPS based location systems, which provide active connectivity. These solutions require additional RF components such as proprietary tag hardware and base stations or a GPS module, together with driver software installed on the mobile and, in some cases, the network infrastructure. ActiveCampus project [15] and RADAR [17] on the other hand use signal strength experienced by the mobile to determine a user s position through the process of triangulation. A software module developed specifically for each particular operating system and a wireless modem interface must be installed on the mobile before a user can obtain such information. These ANN. TÉLÉCOMMUN., 58, n 3-4, /22

5 1783-Her/Telecom 58/3-4 19/03/03 15:34 Page 5 P. BERTIN WLAN STANDARDS AND EVOLUTIONS 5 systems provide solutions, which have the advantage of being network independent in that they work on different wireless settings. However, both these systems require the installation of extra modules to the mobile host which imposes extra costs to the users and face the problem of system and hardware dependency. We will present another network-independent solution for active connectivity in based networks and discuss its pros and cons in section 3. From the users point of view, it is more desirable to have a no extra cost, low complexity solution that does not require installation of extra modules. This requirement can only be fulfilled if the solution makes full use of the underlying network architecture. We will present our innovative, configuration-aware solutions to provide a transparent and user-friendly location service for two different wireless settings in section 4 l. III. LOCATION DISCOVERY (LODS) SERVICE AND A NETWORK-INDEPENDENT SOLUTION Before we start the discussion on LODS, we need to describe what we call a typical enterprise-wide or campus-wide wireless-based network. Such network provides full wireless coverage in an enterprise and it allows staff to access the Internet, their account, and their from anywhere within the enterprise through the use of an IEEE b-enabled laptop or PDA. Such networks consist of IEEE access points (AP) that are positioned to provide full coverage and are interconnected through a high-speed intranet. The precise topology of such networks is chosen by the administrator so as to meet his requirements in terms of cost, scalability, security, and openness. We will describe two configurations in the next section. III.1. Location Discovery Service The Location Discovery Service we designed and implemented is a Web service [1] consisting of a location discovery engine and an API for accessing the service. Upon either a direct request from the user or indirectly through the call to a location-based service, the location discovery engine will determine which access point (AP) the user s mobile device is currently connected to, and return the ID of the AP as an estimation of the mobile s position. The entity that requested LODS service can then make use of the returned ID to provide the location-based service through a database mapping the positions of the APs to say, the position of the printers. The number and the positioning of the APs determine the preciseness of the locating process and in our networks, each AP is responsible for a thirty- to fifty-foot radius area, so LODS provides a good estimation of the location of the mobile device considering that our primary objective is to use LODS to suggest closest resources like printers, elevators, etc. to the mobile user. Most APs are designed and configured to be transparent bridges and operate at the link level. In that case, an AP only knows the MAC addresses (and not the IP addresses) of the 5/22 ANN. TÉLÉCOMMUN., 58, n 3-4, 2003

6 1783-Her/Telecom 58/3-4 19/03/03 15:34 Page 6 6 P. BERTIN WLAN STANDARDS AND EVOLUTIONS clients that it is associated with. However, as a Web service, LODS services communicate with clients or other location-based services at the application level using IP addresses and MAC addresses are generally not available. Thus, while we are trying to create an IP-to-AP mapping (i.e., the web service provides the IP address of the device to locate and LODS returns the ID of the associated AP), this mapping cannot be obtained directly. In fact the LODS engine must be able to convert an IP address to the corresponding MAC address, and then find the AP that is associated with this MAC address (see Figure 2). The readers should notice that the IPto-MAC mapping and the MAC-to-IP mapping could require different methods to e obtained. FIG. 2. Relationship between IP address, MAC address and Access Point ID in LODS. Relations entre l adresse IP, l adresse MAC et l identité du Point d Accès dans LODS. III.2. A Network-independent Solution In b, a mobile device needs to establish a relationship with an AP before using the network. This process is called association. In usual settings, a mobile could be under the coverage of multiple APs, and it will perform a scan to the frequency bands and select the AP with the best transmission quality. There are two types of scanning: active scan, where the mobile broadcasts a probe request and all candidate APs (those able to receive the probe) reply with a probe response (Scenario #1 in Figure 3); or passive scan, where the mobile determines the transmission quality with each potential AP from the beacon it received from this APs (Scenario #2 in Figure 3). Since the b modem will know at all time to which AP it is associated with, and since we are only interested in active connectivity where the action is initiated by the mobile device, it seems natural to obtain the information about the current associated AP from the mobile device itself and send the AP s ID to the LODS server. This would require writing a piece of software to place in the device to retrieve this information from the modem. The ANN. TÉLÉCOMMUN., 58, n 3-4, /22

7 1783-Her/Telecom 58/3-4 19/03/03 15:34 Page 7 P. BERTIN WLAN STANDARDS AND EVOLUTIONS 7 FIG. 3. How a mobile device receives AP information. Comment un équipement mobile s associe à un Point d Accès. locating process can be more precise if, instead of just using the AP s ID, the signal strength of all APs the mobile can reach is passed to the LODS server and triangulation is performed ([15] and [17]). This solution has the advantage of making the device responsible to locate itself regardless of the underlying network architecture. However, each user must first install a piece of software which is used to communicate with the modem in order to get the informa- 7/22 ANN. TÉLÉCOMMUN., 58, n 3-4, 2003

8 1783-Her/Telecom 58/3-4 19/03/03 15:34 Page 8 8 P. BERTIN WLAN STANDARDS AND EVOLUTIONS tion about the APs and such software will be operating-system dependent. Also, b modems from different vendors have different ways to store and manipulate the AP information, which means that a different version of the software will be needed for different modems (this could change in the future). This approach could work well in a homogenous environment in which all users use the same model of mobile device, which, for example, are provided by the enterprise [15]. In that case, only one version of the software will be required. This approach also has a good response time and does not create additional signaling overhead for the system. However, for a heterogeneous environment, which is a more realistic case, users have different PDA models and wireless modems. In that case it is not easy to make a version of the software for every user. Because of the heterogeneity of users, a system and software independent solution is worth investigating. In order to provide such solution, we need to make better use of the underlying wireless architecture. IV. NETWORK-BASED SOLUTIONS As we have seen in the previous section, a solution that is not aware of the underlying network configuration faces the problem of not being hardware and system independent. In this section, we will describe solutions we have designed, which rely on the underlying wireless configuration. We will investigate two of the most popular settings for based networks. We will also present and compare different solutions on these settings. In networks, clients are connected to the network via APs. However, the underlying configuration of the wireless network can vary significantly in order to meet different requirements. The two different based wireless configurations considered in this paper are a simple LAN configuration and a scalable virtual LAN (VLAN)/VPN based configuration. IV.1. Network Configurations The simple LAN configuration: this configuration is best used to provide coverage in an enterprise comprising from few floors of a building to few medium-size buildings and consists of tens of APs that are on the same subnet. An example of such a network configuration will be the Engineering Computer Network (ECN) of Purdue University shown in Figure 4, which spans over three buildings and has sixty-plus APs. Users either have a fixed, assigned IP address for their device, or they can obtain one from a DHCP server. In ECN, all users must register the MAC address of their wireless modems before being able to use the wireless infrastructure (this registration has to be done only once). Each AP in ECN will only grant access to a mobile device if the MAC address is on the registration list maintained in a RADIUS server. In order to perform such authentication, the AP will make a request to a RADIUS server to see if the MAC address is allowed to use the service. We will present the RADIUS protocol in section 4.2. Once the access is granted, the mobile device will be assigned a real IP address. When a user moves from the coverage of one AP to another, the ANN. TÉLÉCOMMUN., 58, n 3-4, /22

9 1783-Her/Telecom 58/3-4 19/03/03 15:34 Page 9 P. BERTIN WLAN STANDARDS AND EVOLUTIONS 9 authentication process repeats. In the ECN network, the IP address assigned to a mobile device remains unchanged throughout the whole session, and the assignment is done from a DHCP server located on the Purdue Intranet. The expected number of users in this kind of systems is not very large, ranging from a few hundreds to a couple thousands. This configuration is simple, easy-to-manage, but does not necessarily scale well because of the limited availability of real IP addresses and the fact that the shared medium could become a bottleneck if the traffic load is too large. FIG. 4. Logical configuration of Purdue ECN wireless network. Configuration logique du réseau sans fils ECN de Purdue. The VLAN configuration: the second architecture consists of multiple virtual LAN (VLANs) or virtual private networks (VPNs) under the same administrative domain. It usually comprises thousands of APs, and spans over a much larger geographical area. Purdue Air Link (PAL) network is an example of such a configuration. PAL is a campus-wide wireless network access service provided by ITaP (Information Technology at Purdue) at Purdue University. Upon the completion of the project in May 2003, over eighty buildings in the West Lafayette campus will have wireless connectivity. Currently the system has about 150 APs over twenty-plus buildings. The configuration of PAL is shown in Figure 5. In PAL network, users are assigned private IP addresses through a DHCP server logically located inside the VPN, and 9/22 ANN. TÉLÉCOMMUN., 58, n 3-4, 2003

10 1783-Her/Telecom 58/3-4 19/03/03 15:34 Page P. BERTIN WLAN STANDARDS AND EVOLUTIONS these private IP addresses are valid only in one VLAN area. Once a device leaves a VLAN coverage (say coverage A) to move to another VLAN coverage (say B), it needs to get another private IP address reflecting that it is in VLAN B and the old IP address of the mobile while it was in VLAN A is released to be used by other mobile devices under VLAN A coverage. PAL does not use IP masquerading or other similar techniques to provide Internet access to users. Instead, a VPN box (figure 5) is put at the edge of the VPN to provide a private-to-real IP mapping. All the traffic that run across the VPN and is destined to the Purdue Intranet or the Internet will pass through the VPN box, and all the IP packet headers will be modified by the VPN box to provide real-to-private IP mapping (the reverse for the traffic sent to mobile devices). This configuration scales better than the simple LAN one because there is a much larger range of private IP addresses available (PAL uses class A private IP address). It is also more scalable since adding new VLANs will not increase the local traffic on the existing VLANs. This configuration also allows different entities to manage different VLANs on a department-by-department basis. In general, each VLAN could have its own administrative rules that depend on the department s regulations. Note that users must provide a Purdue account username and password to the system before the VPN box will perform any mapping services for them. The system will check this username/password pair with the user authentication server located in the Purdue Intranet, and once the user is authenticated, the VPN box will perform the privateto-real IP mapping and the reverse mapping throughout the session, even if the user moves from one VLAN to another. These two configurations are significantly different yielding significantly different configuration-aware solutions. One major tradeoff to take into account when designing such solutions is between scalability and complexity. In the simple LAN configuration, since the number of APs and the number of users cannot be too large, scalability is not a big concern, thus we need to focus on a low-complexity solution, which provides fast response times. In the scalable VLAN configuration, even though efficiency is still a major concern, the ability to scale and keep the signaling traffic under control is even more important. We will address the above concerns when we present the respective designs. IV.2. Basic Approaches As the main goal of LODS is to locate a mobile user based on the AP it is associated with, we have developed two approaches to obtain the mobile device to AP mapping: the RADIUS approach and the SNMP approach. We will first discuss these two approaches, which will be the building blocks of our design, and then present our solutions for the two wireless settings described in section 4.1. The RADIUS Approach Remote Authentication Dial-In User Service (RADIUS) is used to provide centralized authentication, authorization, and accounting for dial-up, virtual private network, and, more recently, wireless network access [6]. Authentication is the process of identifying and verifying the credentials of a user. Several methods can be used to authenticate a user, but the most common involves using a combination of user name and password. Once a user is ANN. TÉLÉCOMMUN., 58, n 3-4, /22

11 1783-Her/Telecom 58/3-4 19/03/03 15:34 Page 11 P. BERTIN WLAN STANDARDS AND EVOLUTIONS 11 FIG. 5. PAL Wireless VLAN configuration. Configuration VLAN du réseau sans fils PAL de Purdue. authenticated, authorization to use various network resources and services can be granted. Authorization determines what a user can do, and accounting is the action of recording what a user is doing or has done. RADIUS is a protocol described in IETF RFC A RADIUS client (in our case a wireless access point) sends (using UDP) a RADIUS message containing the user credentials and the connection parameter information to a RADIUS server each time a new device tries to associate with the AP. The RADIUS server authenticates and authorizes the RADIUS client request, and sends back a RADIUS message response to the AP. Each AP will act as a RADIUS client to provide authentication to a user coming under its coverage by sending a message to the RADIUS server that responds by issuing an ACCEPT or DENY response to the AP. The RADIUS client (i.e., the AP) would then act according to the res- 11/22 ANN. TÉLÉCOMMUN., 58, n 3-4, 2003

12 1783-Her/Telecom 58/3-4 19/03/03 15:34 Page P. BERTIN WLAN STANDARDS AND EVOLUTIONS ponse it received. RADIUS is a protocol used between the APs and the RADIUS server. There is a need for an associated protocol between the mobile devices and the APs. One such protocol is the Extensible Authentication Protocol (EAP) [7]. EAP runs directly over the link layer between an AP and a mobile device and therefore it does not require the use of IP addresses. The Authenticator, which is the AP in our case, would request the mobile device, called the Supplicant, to provide identification. Once the supplicant provides the identification credentials, the authenticator ends the authentication phase with either a SUCCESS or a FAILURE response depending on the reply message from the RADIUS server. In general, the authentication mechanism that determines a SUCCESS or a FAI- LURE response does not require the use of RADIUS, and is up to the network administrator s policy to decide the authentication policies. In the ECN current wireless LAN setting, 802.1X [8], which is one of the authentication methods for b is used. Basically it is EAP over IEEE b. After a device has been associated with an AP, the AP would act as the EAP Authenticator and place the device in a blocked state. All non authentication-related traffic coming or going to the device is blocked by the AP. The device acts as the EAP supplicant and supplies identification, here its MAC address to the authenticator. The authenticator would then contact the authentication server, which is the RADIUS server in this case, and check if that MAC address is registered. Currently all users must register the MAC address of their devices in ECN before the devices are allowed to use the wireless service. The authenticator will then issue a SUCCESS or FAILURE response depending on the response from the authentication server. If a SUCCESS response is issued, the AP will drop its filter and allow all traffic between the device and the outside world. Each time a device tries to associate with a new AP, an authentication process starts in which the MAC address of the device is sent through EAP to the AP that sends it to the RADIUS server for authentication. In case the authentication process is successful, the following information is kept in a log file in the RADIUS server: the time at which the authentication request has been made, the ID of the AP that has made the request, and the MAC address of the device that was authenticated. By inspecting the log file of the authentication (RADIUS) server, it is possible to determine to which AP a given device is currently associated with. Using this information, we can determine the approximate location of the device. Figure 6 shows the use of the RADIUS server as a mean to locate a mobile device. Currently most APs are RADIUS-able. The SNMP approach SNMP (Simple Network Management Protocol) is the standard operations and maintenance protocol for the Internet [9]. It can be used to obtain system parameters from a device, and to configure various parameters on a device. Each parameter is called an attribute, and attributes are organized in groups called communities. Currently most APs are SNMP-able. In general APs are configured as transparent bridges and hence they all maintain their bridgelearning table. The bridge s learning table of a given AP contains the mappings of the MAC addresses of the devices, which have recently used that AP, to the corresponding interfaces of that AP. Therefore, if an entry indicates that a particular MAC address is mapped to the wireless interface of a given AP, we can conclude that the device with this MAC address has either been recently connected or is currently connected to that AP. This table is available to the network administrator via SNMP query as long as the APs are SNMP-enabled (a network administrator can decide to disable SNMP on his APs since SNMP has some security flaws). ANN. TÉLÉCOMMUN., 58, n 3-4, /22

13 1783-Her/Telecom 58/3-4 19/03/03 15:34 Page 13 P. BERTIN WLAN STANDARDS AND EVOLUTIONS 13 FIG. 6. The RADIUS approach. L approche basée sur RADIUS. In this approach, a server periodically queries all the APs using SNMP to obtain their bridge learning tables and creates its own log file. One of the shortcomings of this approach is that a bridge table does not refresh until a device has been inactive (possibly because it has moved) from the AP standpoint for about 15 to 20 minutes. By maintaining a log file, which contains information obtained from the periodic queries, we can find the latest AP to which a particular mobile device connected through a query to that log file. The idea is shown in Figure 7. 13/22 ANN. TÉLÉCOMMUN., 58, n 3-4, 2003

14 1783-Her/Telecom 58/3-4 19/03/03 15:34 Page P. BERTIN WLAN STANDARDS AND EVOLUTIONS FIG. 7. The SNMP approach. L approche basée sur SNMP. Comparing the basic approaches For those wireless LANs that use RADIUS for authentication, using the RADIUS approach is overhead free as long as the network administrator allows the RADIUS log file to be used for location discovery. This approach is also device independent. Regardless of what operating system the mobile device is using or what model it is, as long as the device has an IEEE modem card that is registered in the network, this solution will be able to locate it. The response time of the RADIUS approach in our system, i.e., the time it takes for the system to realize that a mobile device is in a new location is about 3 to 5 seconds in our implementation. The delay is mainly due to file updates over NFS (Network File System). For prototype testing, we did not want to interfere with existing services, so we had the RADIUS server running on one machine and the LODS server running on another machine. The LODS server detected changes in the log file on the RADIUS server and updated its copy of the log file accordingly. If both the RADIUS server and the LODS server are put on the same machine, the response time will be much improved. The shortcomings of the RADIUS approach include ANN. TÉLÉCOMMUN., 58, n 3-4, /22

15 1783-Her/Telecom 58/3-4 19/03/03 15:34 Page 15 P. BERTIN WLAN STANDARDS AND EVOLUTIONS 15 the need of a RADIUS server (or other authentication service with output log), the fact that it may not scale that well with the size of the enterprise network, and the fact that all APs must be able to perform authentication (i.e., to be EAP and RADIUS enabled). The SNMP approach does not require the setup of a RADIUS server and it is a generic approach, thus it is more suitable for open access AP systems like Internet café. It would also work in the case of a configuration with a RADIUS server if the network administrator does not want to give access to the RADIUS log file to LODS. In order for this approach to work, the APs have to be SNMP enabled which is not without security risk at the present time. The SNMP approach also is operating system and model independent. The downside of this approach is the heavy signaling generated by the periodic probing of APs. The response time of this approach can vary. In our network setting, the response time varies from 10 to 30 seconds for a probing period set to 10 seconds. The duration between two probes also determines how precise the locating scheme is. Obviously the right trade-off has to be found since the probing period impacts the signaling load as well as the response time (i.e., the speed at which a change of AP can be detected by the system). This approach like the previous one will not scale that well with the size of the enterprise network. IV.3. Network-aware LODS for Simple LAN Wireless Configuration To get a complete solution for LODS, we need to provide a solution to obtain the IP address to MAC address mapping as discussed in section 3.1. When a user or a web application requests service from LODS, the IP address of the mobile device will be extracted from the message header of the query. The Location Server will need to map this IP address to the corresponding MAC address to find out the AP associated with that mobile device. This can be done in several ways. However, in this relatively simple network setting, it is easy to obtain the IP address to MAC address mapping by interrogating the default gateway (i.e., the router represented in Figure 4), which has this information in its ARP table. This is done by having LODS make a SNMP query to the gateway asking for the MAC address corresponding to the IP address given in the query (figure 8). Regarding the MAC address to AP mapping, we have implemented both the RADIUS and the SNMP approaches in the ECN simple LAN wireless configuration. We compared the performance of the two approaches to get the MAC address to AP mapping, together with the devicebased approach mentioned in Section 3. Since each of the above approaches has its pros and cons, and different applicability, it is up to the network administrators to decide which is best suited for their network. Table 1 shows the comparison between the three schemes. Based on our implementation and testing (we have not implemented the device-driven approach due to system dependency), the RADIUS approach provides excellent performance. It requires no signaling in addition to the original RADIUS service. The response time is good, and the implementation is easy. The SNMP approach, on the other hand, generated a high amount of background signaling traffic, and the responsiveness is not always very satisfactory. For the device-driven approach, complexity in implementation is the main issue. Wireless modems from different vendors may need different low-level system calls to obtain the AP information, which makes the implementation of this scheme difficult. The retrieval of AP information can be done relatively easily in Linux. 15/22 ANN. TÉLÉCOMMUN., 58, n 3-4, 2003

16 1783-Her/Telecom 58/3-4 19/03/03 15:34 Page P. BERTIN WLAN STANDARDS AND EVOLUTIONS TABLE I. Comparison between different locating schemes. Comparaison des différentes solutions de localisation. RADIUS SNMP Device-based Network Service(s) RADIUS or other SNMP-enabled AP, required other than authentication server and a log file to maintain NO the location database with log the queries Signaling in addition NO if RADIUS Periodic to LODS requests or service is already SNMP requests NO responses required? in place and updates Software Installation in Mobile Required? Operating System Independent? NO NO YES YES YES NO Scalability AVERAGE POOR GOOD Hardware Model Independent? YES YES NO Ease of implementation Easy Intermediate Difficult (esp. for PDAs) Response Time 3 to 5 seconds 10 to 30 seconds (depending on probing period and AP response time) Immediately after associated with AP FIG. 8. Schematic of LODS for simple LAN Configuration. Schéma de base de LODS pour une configuration simple de réseau local. ANN. TÉLÉCOMMUN., 58, n 3-4, /22

17 1783-Her/Telecom 58/3-4 19/03/03 15:34 Page 17 P. BERTIN WLAN STANDARDS AND EVOLUTIONS 17 IV.4. Network-aware LODS for Scalable VLAN/VPN Configuration Purdue Air Link network runs on a scalable VLAN setting, which is shown in Figure 5, and assigns private IP addresses to users via DHCP. Since the network spans geographically over a large area, and the variety of types of mobile devices and operating systems that users can have is very large, not all the three basic approaches described earlier to obtain a mobile device-to-ap mapping (see Table 1) may work well. The RADIUS and SNMP approaches have a scalability problem while the device-based approach faces the system dependency problem. In order to provide LODS to the Purdue community, we need to develop a scalable and system-independent solution. The RADIUS approach seems to be a good starting point for the solution, since this solution tracks the movement of the users very well and incurs signaling only when the users move. If there is a centralized RADIUS server, LODS can check the log file of the server and easily determine the latest association between the mobile and APs. However, ITaP, the unit who administers PAL, decided not to have a centralized RADIUS and EAP service to check for authenticated MAC addresses. Instead, mobiles with any MAC addresses are allowed to talk to all the APs without blocking, but the user must have a Purdue account and needs to supply login information before getting a real-to-private (and a private-to-real) IP mapping from the VPN box. The authentication process was mentioned in section 4.1. The SNMP approach, though generic, generates too much background signaling traffic for a reasonable probing period. The device-based approach is good in terms of system scalability, but has too many shortcomings (that were discussed earlier) to be considered. Since we need to collect information about the association between the mobile devices and the APs in a scalable way, we decided to introduce extra components to the network. As the RADIUS approach introduces the least overhead in terms of background signaling and application development as shown in the previous section, we developed our solution for the VLAN configuration based on the service RADIUS provides. For the purpose of enhancing scalability, we dedicated a reduced RADIUS server to one or more VLANs, depending on the expected LODS load from the VLANs. A reduced RADIUS server, which we re-named Location Collector, consists of a RADIUS server program, which can be run on a low-end Linux box. It does not need to perform authentication as it is supposed to be. Its only function is to log the access requests to APs made by the mobile users in its coverage and maintain the mappings of MAC addresses to the most current associated APs. This is equivalent to voiding the RADIUS authentication processes by always returning ACCEPT to the AP. It is important that the reliability of the Location Collectors should not affect that of the PAL network, so EAP should be configured to never block a modem even if it fails to get a RADIUS ACCEPT message. With these Location Collectors, RADIUS traffic is limited to each VLAN or group of VLANs and each Location Collector will be responsible for the MAC-to-AP mapping in its region. Now we have the components required to build a scalable LODS system. This scalable LODS works in the following way (Figure 9): When a user or a web application requests service from LODS, the IP address of the mobile initiating the LODS request will be extracted from the message header of the query. The Location Server will, based on the private IP address of the mobile, determine which VLAN the mobile is in, thus which Location Collector to contact (there is a straightforward mapping between a mobile device private IP address and the VLAN it is in). As each Location Collector contains only the MAC-to-AP mappings, LODS needs to figure out the MAC address of the device. This can be done in two ways: First, the default gateway of each VLAN will have the IP-to-MAC mapping of the mobile 17/22 ANN. TÉLÉCOMMUN., 58, n 3-4, 2003

18 1783-Her/Telecom 58/3-4 19/03/03 15:35 Page P. BERTIN WLAN STANDARDS AND EVOLUTIONS since the APs are configured to be transparent bridges, so LODS can make a SNMP query to get the MAC address corresponding to an IP address to the correct gateway. This is the most straightforward way to obtain IP-to-MAC mapping in the sense that there is no overhead except a SNMP query and a SNMP reply messages, which are generated on-demand. Alternatively, it is also possible to make use of the log of the DHCP server. The log file of the DHCP server contains the assignment of IP addresses to MAC addresses, so by studying the log file, the IP-to-MAC mapping can be obtained. For more efficient response to queries, it is recommended that a database should be built which also parses the log file in the background. The database can be implemented in the same machine as the Location Server, so that the query time and traffic will be minimal, and the only signaling traffic introduced will be the one generated when the log file is being updated. One advantage of this scheme over querying the gateway is that with this database, not only the IP-to-MAC mappings are available, but also the MAC-to-IP mappings, which cannot be easily obtained by querying the gateways since we do not know which gateway(s) to query. The advantage of having the MAC-to-IP mappings is that the network is now able to provide based paging services and user tracking services. We will discuss this possibility in section 6 when we suggest future works. FIG. 9. Schematic of LODS for Scalable VLAN Configuration. Schéma de base de LODS pour une configuration VLAN à plus grande échelle. ANN. TÉLÉCOMMUN., 58, n 3-4, /22

19 1783-Her/Telecom 58/3-4 19/03/03 15:35 Page 19 P. BERTIN WLAN STANDARDS AND EVOLUTIONS 19 Once the Location Collector obtained the MAC address of the mobile either from the gateway or the DHCP log, it will return the ID of the AP to which the mobile device is currently associated back to the requesting entity. This design solves the scalability problem in that it takes full advantage of the modular architecture of the VLAN configuration. The downside of this design is that it requires additional hardware (the Linux boxes) for the Location Collectors (i.e., the RADIUS servers). One such server will need to be installed in every group of VLANs. The Cistron RADIUS server [16] is using a free software which has all the features needed. Since each Location Collector will only be responsible for the RADIUS traffic in its own region, the wireless network could expand by introducing more VLANs, and more Location Collectors thereafter, without posing scalability problem to LODS. With network-aware LODS deployed in the PAL network, it is possible for mobile users in the Purdue community to enjoy location service by using any mobile device with a generic browser. It is also possible to build location-based applications on top of this new Web Service. We will present an innovative application of LODS by showing the Remote Printing service which is being deployed on the PAL network in the next section. V. APPLICATION OF LODS REMOTE PRINTING SERVICE Remote printing service is a project that was supported in part by a Hewlett Packard grant. It is a web-based printing service for PDAs and laptops that enable them to print virtually any document that can be accessed through a Web browser (i.e., HTML, PS, PDF, and virtually all types of images) using any printer connected to the network without downloading the document. The advantages of this service are that there is no need to install any printer driver in the mobile device; that files for which there is no viewer installed in the PDA can still be printed from a PDA; and the mobile devices do not need to download, say, a huge postscript file, before printing it. This last advantage reduces the consumption of power and memory in the mobile device and is bandwidth friendly for the wireless LAN. Each mobile user wanting to use the Remote Printing Service is required to connect to a designated proxy server in order to receive this service. This proxy server will look at the URL the user requests, and if it has a PS, PDF, or any image suffix the system supports, it will redirect the request to the Remote Printing page together with the original URL. In that page the mobile user can choose whether to save/view the file or directly print it. If the user chooses to print the file, he has to select which printer to print to, then the Remote Printing Service will download the file directly from the content providing site, convert the file to a printable format, and print it to the desired printer. The whole process from downloading to printing does not involve any signaling or data transfer between the mobile device and the Remote Printing server. If the requested page is an HTML document, the proxy will add a small piece of code which generates a small box with a printing icon on the upper left hand corner of the webpage. Users can have the box removed by clicking the close button on the box. If the user decided to print that page, he would just need to click the printing icon, and the proxy will redirect the request to the Remote Printing page, again with the URL of the page that the user was browsing. The user can then choose which printer to use, and the Remote Printing Ser- 19/22 ANN. TÉLÉCOMMUN., 58, n 3-4, 2003

20 1783-Her/Telecom 58/3-4 19/03/03 15:35 Page P. BERTIN WLAN STANDARDS AND EVOLUTIONS vice will download, convert and print the HTML file in a similar fashion as the one described for printing PS and PDF files. The Remote Printing service works well if the user knows to which printer to print to. However, if the mobile user wants to use the printer, which is the closest to him right now, assuming that he is away from his own building, he may not know where the closest printer is. This means that without a location-based printing service, the user may have to get his document printed by an unnecessarily distant printer, even when a closer one was available. FIG. 10. Remote Printing Service using LODS. Le service d imprimante à distance qui utilise LODS. With LODS, the remote printing service can know approximately where the user is, and suggest printers that are closer to the user. This is illustrated in Figure 10. When Remote Printing is called by the user (directly or indirectly through a redirecting proxy), the service will know the IP address of the device. The Remote Printing Service will then pass the IP address of the device to the network-based LODS service discussed in the previous sections to determine which AP the device is currently using, and the AP s ID will be used to query a Location Database which contains the AP-to-printer mappings and is located in the same machine as the Remote Printing service. A list of closest printers will be returned to the user and the user can choose a printer from the list. We have chosen to maintain a Location Database, which contains all the mappings from the APs to the shared printers in the neighborhood. However, if the naming scheme for APs and shared resources (printers in this case) is carefully chosen, the resources closest to the ANN. TÉLÉCOMMUN., 58, n 3-4, /22

21 1783-Her/Telecom 58/3-4 19/03/03 15:35 Page 21 P. BERTIN WLAN STANDARDS AND EVOLUTIONS 21 mobile user could be obtained more efficiently. From our experience, we recommend system administrators who plan to implement location-based services to use a self-contented naming scheme for Access Points and shared resources. An example would be <Building Name> <Room Number> <Resource Type>. With this method, it is easier to determine the closest resources from an Access Point by using regular expressions to compare the building and room number without actually maintaining a database. VI. CONCLUSION AND FUTURE WORK In conclusion, this paper described different solutions for a new Web service for location discovery which locates mobile users based on the AP they are currently associated to. The service can be used directly by mobile users to know where they are, or through other applications via API calls to provide other location-based services. With network-based LODS, it is possible to provide wireless location services to users with virtually no cost imposed on them. We presented and compared different approaches to locate a user, and also presented network-based solutions based on two different wireless configurations. We also presented in detail an application to LODS, the Remote Printing service, to demonstrate the potential of LODS applications. We are currently working on another project named mypurdue, which is an e-community project aimed at providing a set of sophisticated location-based services to the Purdue community. Another possible extension to LODS will be the ability to track a user. Right now our system can locate a mobile user on the request of the user himself, and it will be interesting if the system can track a user in real-time like what is done in the cellular telecommunication networks. Challenges will be the heavy signaling generated by continuous tracking of a large number of users. Privacy and security will be another issue of concern. This could be used to create a paging service via wireless LAN and that would open the door to many exciting mobile applications. Manuscrit reçu le 26 septembre 2002 Accepté le 15 novembre 2002 Acknowledgement The authors would like to thank Mr. Bill Simmons of Engineering Computer Network (ECN) at Purdue University for his help in deploying LODS in ECN and Mr. Scott Ballew, Mr. Steve Mayo and Mr. Jim Bottum of ITaP at Purdue for their help with the PAL network. The authors would also like to thank Hewlett-Packard for their support through the mobile laboratory grant. 21/22 ANN. TÉLÉCOMMUN., 58, n 3-4, 2003