Indoor and outdoor location based services for portable ... - IEEE Xplore

Indoor and outdoor location based services for portable wireless devices Cristiano di Flora*, Massimo Ficco**, Stefano Russo*,** and Vincenzo Vecchio** *

Dipartimento di Informatica e Sistemistica, Università degli Studi di Napoli Federico II Via Claudio 21, 80125 Napoli - Italy [diflora,[email protected]] **

CINI-Consorzio Interuniversitario Nazionale per l’Informatica1 - ITEM Laboratory Via Diocleziano 328, 80124 Napoli - Italy [[email protected], [email protected]] Abstract

Designing and developing location-aware portable software applications is challenging, since most location-estimation methods i) require non-standard features either in the mobile terminal or in the network infrastructure, and ii) they are specifically designed for either indoor or outdoor. Moreover, installing and tuning systems that rely on such location methods may be quite a complex operation. In this paper we propose a software architecture that makes a combined use of indoor and outdoor locationsensing technologies. On top of the architecture there is a generic API, aimed at supporting the development of hybrid (indoor/outdoor) applications at a high level of abstraction, independent of the location technology. The API is meant to support applications for which the exact position of a mobile terminal is not a primary requirement, but it suffices to identify the terminal position in a known set of zones (e.g., rooms indoor, or pre-defined outdoor areas). The software architecture is designed: i) to ensure compliance with emerging positioning standards and commercial devices, in order to leverage the interoperability with third-party developed services, and ii) to be based on low-cost and easily deployable and tunable indoor positioning infrastructures. An implementation of the architecture is described, based on Bluetooth and GPS technologies, so as to outline the major implementation issues.

1. Introduction and related work In the last years a great deal of research has been conducted on developing methods and technologies for automatic location-sensing of people or devices [1]. Proposed solutions differ in the problem they aim to solve or applications they aim to support. As

mentioned in [1], current location-sensing methods can be classified according to several factors, such as power requirements, the physical phenomena used for determining location, the form factor of the sensing apparatus, the required infrastructure, and resolution in terms of time and space accuracy. Moreover, most methods require non-standard features either in the mobile terminal or in the positioning infrastructure [2]. As nowadays several technologies coexist into modern mobile user terminals, we envisage the need for a high level software application programming interface (API) for technology-independent location sensing [3]. Several organizations have proposed location APIs to leverage the interoperability of positioning systems: among them, the Open Mobile Alliance (OMA) and the Java Community Process (JCP). The OMA Location Working Group continuing the work originated in the former Location Interoperability Forum (LIF) [4], defined a location services solution, which allows users and applications to obtain location information from the wireless networks independently of the positioning method. JCP has finalized a Java Specification Request (JSR) in order to cope with location-awareness (JSR179) [5]. The JSR-179 defines a J2ME optional package to enable location-aware applications for mobile devices. This package provides functionality for obtaining information about location and orientation of the mobile device and for accessing a Landmark database stored on the device. Within the JSR-179 specifications, Location objects represent a location in terms of the following parameters: coordinates, time stamp, accuracy, speed, and information about the positioning method used for the location, plus an optional textual address. Location objects are named Landmarks. This specification allows several positioning strategies to be used, including satellite based methods like GPS, and short-range positioning methods like Bluetooth Local Positioning.

1

This work has been partially supported by the Italian Ministry for Education, University and research (MIUR) in the framework of the FIRB Project “Wide-scalE, Broadband, MIddleware for Network Distributed Services” (WEBMINDS), and by Regione Campania in the framework of “Centro Regionale di Competenza ICT”.

Proceedings of the 25th IEEE International Conference on Distributed Computing Systems Workshops (ICDCSW’05) 1545-0678/05 $20.00 © 2005 IEEE

Table 1. The topology map Zones ZOA12

Coordinates X12 , Y12 , Z12

Description Conference room, on the second floor in Computer Science Department

ZOA13 ZOE44

X13 - Y13 - Z13 X’44 < x < X’’44 Y’44 < y < Y’’44 Z’44 < z < Z’’44 X’45 < x < X’’45 Y’45 < y < Y’’45 Z’45 < z < Z’’45 ...

Student laboratory, on the second floor in Computer Science Department At the start of Diocleziano Street

ZOE45

…

There are several methods to determine a mobile user’s location. Triangulation techniques [6,7] measure either the distance between known points or the relative angle with respect to known referring poles. In other works [8,9,10], location is calculated as a function of the proximity to a known set of points. These works rely on specific location sensing methods, like GPS [7], RADAR [6], DOLPHIN [9], and they use sensors and communication technologies such as Bluetooth, IEEE 802.11, RFID tags, ultrasonic badges and ad-hoc solutions. In this work we propose a portable software architecture for indoor-outdoor location sensing, which is based on a proximity method. The original contribution of this work is two-fold. First, the deployment costs of the proposed system (in terms of the cost of the location-sensing hardware required and the time to set it up) are significantly smaller than those of most of the mentioned techniques. Indeed, our technique uses off-the-shelf Bluetooth and GPS devices as location-sensors. Moreover, the zoning approach in turn reduces the efforts required to configure and tune the system. Second, this work proposes an alternative approach for JSR-179 applications to manage different location-sensing components. Indeed, while the Location API for Java delegates the management of different location sources to end-applications, we propose a mechanism for automating the management of multiple locationsensors in an application-transparent manner. A major concern when designing systems to locate users’ portable devices is privacy. Although privacy issues are not addressed by the JSR-179 specifications, it will appear that our architecture has been conceived with basic client-side mechanisms that can be used for allowing the (mobile) user to select the trusted infrastructures. However, privacy is not discussed in this paper, and it will be considered in future work.

2. Indoor-outdoor location method The proposed architecture is based on a novel location method, called ZONING. The idea that such a method relies on is to express the position of a mobile device in terms of the physical zone where it is located. The proposed method addresses the mobility of

In the middle of Diocleziano Street

...

personal devices by extending such a location-paradigm to both indoor and outdoor scenarios. In a hybrid indoor/outdoor configuration, the information about device position is provided by means of at least two distinct positioning systems: we exploit GPS devices for outdoor positioning, and Bluetooth adapters for indoor positioning. Each known zone is represented as a Landmark object. A set of attributes is assigned to each Landmark, including a name, a set of coordinates, and a textual description. Table 1 shows an example topology map of an experimental environment. According to the indoor ZONING strategy [8], we assign a symbolic location (the “zone”) to each room of the building. Each zone is described by a set of coordinates and a description. The outdoor zones are represented by a set of coordinates that identifies the border-line of the related area (a garden, a street, a court). Landmarks are stored in a Landmark Data Base, which represents the topology map of the experimental environment. In indoor environments, we model each room by a specific short or mid-range network device (e.g. a Bluetooth device) [8]. We assume that a single sensor is assigned to each room. To determine the room where the mobile device is currently located, we exploit the socalled Received Signal Strength Indicator (RSSI). RSSI is a measure of the received power levels of the sensor signal. The mobile device acquires information about the RSSI from the sensors that reside in the neighboring rooms. The information is used to locate the nearest sensor. By combining this information with the reference topology information (comprised in Table 1) it is possible to detect the room, the floor, and the building in which the mobile device is currently located. Moreover, since personal devices can be used in a mixed indoor and outdoor scenario, the architecture must provide a mechanism to automatically switch between positioning technique. Figure 1 depicts a sample scenario involving a mobile device moving from inside to outside a certain building and vice versa. Each room adjacent to the outdoor world (e.g. the room with the exit door) is marked as “Boundary” room. Therefore, if the device connection gets disrupted within a Boundary room, the system will try to discover GPS signals automatically. Similarly, each entrance of the building is assigned specific GPS


coordinates which are marked as “near building entrance”; in this case the mobile device starts looking up the indoor-network automatically. It is worth noting that, as a mobile switches from indoor to outdoor (and vice versa), it stops looking the indoor devices up, thereby reducing power consumption.

Figure 1. Indoor-Outdoor mode switching Position information is updated periodically based on both time and space. Temporal updates are forced at pre-defined time slots, while space intervals require the mobile device to update position information each time the device moves either i) along a predetermined space or ii) to a different zone.

3. The overall architecture This section provides a more detailed description of the key role and functionality of each component of the proposed software architecture. A typical interaction between the mobile devices and the proposed architecture consists of the following steps. First, the wireless mobile device estimates its location by means of an indoor or outdoor location sensing technology. Second, such information is dispatched to several infrastructure components. Figure 2 shows the proposed architecture. As for the indoor scenario, the mobile device discovers its location and delivers it, enriched by a unique user identifier, to the Location Event Sink. The Location Event Sink is in charge of delivering the received position information to the User Server. As for the outdoor scenario, the device collects the location information and delivers it to the User Server component by means of an outdoor networking technology (e.g. GPRS). The User Server is in charge of updating the information about a device location. The Topology Server is responsible for the management of the Landmark Data Base. It provides two main services: the first is a web service to update the data base upon variations of the reference

topology; the second is used to deliver topology maps to the Application Server and to mobile devices.

Figure 2. The positioning architecture The Application Server represents the context aware end-application; this component exploits the Topology Server to retrieve the maps of the campus and the User Server to retrieve information about users’ location. The client side architecture, as depicted in Figure 3, is composed of three main components, namely the Communication Agent, the Discovery Agent, and the Location Agent. The Discovery Agent is used for the indoor scenario. It is in charge of downloading the topology map of the building in which the mobile device is entering. The user may choose to download updates of the map or use the one previously saved in the device’s memory. The Communication Agent is used to deliver the location information to the User Server. The Location Agent is the component which determines the user position in indoor and outdoor scenario.

Figure 3. The software architecture For the sake of clarity, let us refer to the scenario envisioned in Section 1. As a professor enters the campus (e.g. the area covered by the wireless network) and turns his mobile device on, it detects its physical


position thanks to the neighbouring location sensor. Subsequently, the mobile device provides this information to the Location Event Sink, which is responsible for communicating with the rest of the location architecture. Upon that, the User Server knows the current location of a specific user. The Application Server can thus use this information to display user’s location on the retrieved campus map.

4. Implementation issues

specifications. JBluez relies on the Official Linux Bluetooth protocol stack, namely Bluez [13]. We implemented the RSSI_Provider component as an extension to the JBluez Library. Such a component exploits the hciGetRssi and hciGetLinkQuality Bluez functions to measure the RSSI and the Link Quality respectively. The bridge between the Java RSSI_Provider component and the mentioned C functions has been established by means of the Java Native Interface (JNI).

4.1 The Positioning System The location system is designed to support JSR-179 compliant applications. More specifically, it produces Location Objects as defined in the JSR-179. The system has been implemented by using existing location methods, namely the satellite based GPS, and the Bluetooth Local Positioning [11] short-range method. As Figure 3 shows, the Positioning System comprises the Indoor Location System, the Outdoor Location System, and the Location API, which are briefly described in the following.

4.2 The indoor location system The internal structure of the implemented Bluetooth-based Indoor Location System is depicted in Figure 4. We adopted the Java Specification Request for Bluetooth communication (JSR-82) [14] in Connected Limited Device Configuration (CLDC), since we were interested in supporting J2ME locationaware applications. Such an API allows to manage and control the remote connections. In the indoor scenario, we used two parameters to determine user position. More specifically, we measured the RSSI (Received Signal Strength Indicator) which indicates the power of the received RF signal and the BER (Bit Error Rate) which exploits the Link Quality to estimate the Bluetooth signal. Since the JSR-82 does not allow applications to measure such parameters, we propose to extend the JSR-82 API in order to provide the Location API with local information [12]. For this reason, we propose a solution based on the insertion of a new component, called RSSI_Provider, into the JSR-82 API. This is in charge of producing information about signal strength and link quality. More specifically, it retrieves the RSSI and the Link Quality at run-time by means of the underlying Bluetooth’s Host Configuration Interface (HCI) layer. As for the Bluetooth API, the implemented prototype exploits the JBluez library, which is an open-source implementation of the JSR-82

Figure 4. Structure of the Indoor Location System The implementation of the above described APIs depends on the components installed on a system, for example the specific Bluetooth hardware, the Bluetooth stack, the operating system, and the Java Virtual Machine. Moreover, the JSR-82 extension assumes that both the Bluetooth hardware and the software stack allow to read the RSSI values. Only with these conditions it is possible to implement, by means of the JNI, the described extensions.

4.3 The outdoor location system The Outdoor Location System has been implemented as a specific JSR-179 compliant Location Provider component. Such a component is called GPS Location Provider since it is based on the Global Positioning System (GPS) location-sensing method. Such a component is responsible for the retrieval of current location data and for the provision of Location objects to end applications. However, commercial GPS devices can use several data representation standards (e.g.: NMEA, SIRF) to output position data as a set of formatted strings, called sentences. Hence, the GPS Location Provider is responsible not only for data retrieval but also for parsing the read sentences and for translating them into a set of coordinates. As for location data retrieval, the GPS Location Provider is in charge of connecting to the GPS sensor in order to get the current location data (location coordinates, altitude, date and time). More specifically, the implemented GPS-Location Provider allows


applications to retrieve location-data from Bluetooth enabled GPS devices that support the BT Serial Port Profile (SPP). As for the supported data representation standard, the implemented GPS Location Provider allows to retrieve location information from NMEA0183 compliant devices. Parsing of NMEA sentences relies on the NMEA Java APIs. Upon sentence parsing, the GPS-Location Provider can use the gathered location data to create Location objects and distribute them to JSR-179 Java applications.

4.4 The overall Positioning System According to the proposed zoning approach, each location has a one-to-one relationship with a specific area or room of the campus. Within the JSR-179 specifications, Location objects represent the up-todate location in terms of time-stamped coordinates, accuracy, speed and information about the positioning method used for the location, plus an optional textual address. Thus, it is crucial that our technique be mapped onto JSR-179 semantics. Since the zoning approach focuses mainly on the zone where the mobile device is located, we do not consider accuracy and speed as crucial parameters. We assign a specific set of latitude, longitude, and altitude parameters to each selected zone (a room or an area) of the ITEM laboratories. Figure 5 shows the overall architecture of the Positioning System. We implemented two specific LocationProvider, namely the RSSI LocationProvider and GPS LocationProvider, in order to provide the overlying JSR-179 applications with our combined

indoor-and-outdoor positioning mechanism. In the indoor scenario, the mobile device uses table 2 and 3 to determine its position. Such tables are managed by the following two components: •

•

the SensorLocator, which is in charge of managing the Sensor-Coordinates table; such a table assign each zone to a specific Bluetooth sensor and to its coordinates; the SensorConnector, which manages the SensorNeighbors table (representing the interconnections between rooms). For each zone, it contains information about the bordering network sensors. Table 2. Sensor coordinates table Zones ZOA12 ZOA13 .....

Positioning Sensors 56:F3:75:12:1E:89 67:21:EA:5B:23:45 .....

Coordinates XA12, YA12, ZA12 XA13, YA13, ZA13

Table 3. Sensor neighbors table Zones ZOA12 ZOA13 .....

Neighboring Zone 1 ZOA13 ZOA12 .....

Neighboring Zone 2 ZOD1 ZOB23 .....

Neighboring Zone 3 ZOA12 ZOD3 .....

The LocationEstimator component uses the RSSI_Provider to discover the zone where the mobile device is located. It analyzes the Sensor-Neighbors table by means of the SensorConnector component, and reads the RSSI value for each neighbored sensor. Based on this two pieces of information, it determines the nearest sensor (i.e., the identification of the current room), and subsequently retrieves its coordinates by means of the SensorLocator component, thereby returning such coordinates to the LocationProvider. In the outdoor scenario, the GPS LocationEstimator uses the HCI_Driver to determine the mobile device location by means of the NMEA sentences. In this case no topology tables are needed, since the retrieved information contains valid geographical coordinates.

4.5 Discovery agent

Figure 5. The hybrid positioning system

Triangulation-based approaches can be particularly time-consuming since each topology variation may require to re-configure the entire positioning system. In our solution such a problem is solved by allowing the mobile devices to download the topology map when entering a building. The Bluetooth service-discovery protocol is used to update the topology map on mobile devices. More specifically, the map-update functionality is delivered by a specific component, namely the Topology Server, as a


Bluetooth topology service. The Topology Server publishes details about its services in order to allow mobile devices to find and use them. The interested reader may refer to [15] for further details about service discovery and publishing in Bluetooth piconets. We developed the topology maps as XML files in order to make their management and visualization more flexible and customizable. Each map is downloaded and stored onto the mobile device when it enters a certain environment for the first time. Map downloading can be done according to two different strategies. When the device returns to a previously visited environment, the positioning system can be configured to either upload the map or just leave the previously stored one and search for topology updates.

of the Computer and Systems Engineering Department of the Faculty of Engineering at the University of Naples (Italy). The laboratory is composed of different rooms, including offices, storerooms and open-space computer laboratories, as shown in Figure 6.

4.6 Communication agent The Communication Agent is used to deliver the position information. In the indoor scenario we consider each building covered by the positioning infrastructure. When a mobile device enters a new building, it downloads the topology map and connects to the Location Event Sink. The Location Event Sink is then responsible to send the coordinates received from each mobile device to the User Server. On the other hand, in the outdoor scenario the mobile device sends its coordinates to the User Server by means of an IP connection on GPRS communication.

4.7 The positioning-sensors infrastructure In a triangulation-based approach, the presence of thick walls and strong interference may require sophisticated sensor devices and/or more than three access points to improve accuracy. This will actually increase the cost of the positioning infrastructures. Conversely, our positioning sensor infrastructure uses cheap commercial network sensors (e.g. Bluetooth dongles), in order to reduce costs. However, the main limitation of such sensors is that the number of simultaneous connections that they can hold is quite limited. In order to overcome such a problem our architecture allows several Bluetooth sensors to be placed in the same room; in this case each zone is assigned multiple Bluetooth addresses by means of the Sensor Table.

5. Experimental testbed In order to evaluate the effectiveness of the proposed approach we deployed an experimental testbed into the ITEM laboratory of the CINI Consortium, located at about 1 Km from the campus

Figure 6. CINI-ITEM laboratory As for the client device, we used iPAQ h5450 Personal Digital Assistants with Bluetooth and 802.11 wireless capabilities and an additional external GSM/GPRS adaptor. As for the GPS receiver, we used the Tom Tom Bluetooth 3 Wireless device. The adopted devices run the Linux Familiar 0.7.0 operating system. The sensor infrastructure consisted of ANYCOM Bluetooth dongles and stationary Bluetooth devices (e.g. the ANYCOM Bluetooth printer adapter). Results of the preliminary experiments confirm the ease of configuration and tuning of the proposed indoor infrastructure, and its effectiveness to locate mobile users indoor. In addition, experiments show the effectiveness of the high-level API we designed to support development of location-aware applications in a way independent of the location sensing technology. Work is ongoing for developing more complex software applications and services based on the proposed API.

6. Conclusions and future work This work proposed a method for supporting locationaware services by means of a “zoning” location sensing technique. The method is based on the combined use of indoor and outdoor positioning mechanisms and it relies also on third-party off-the-shelf components. The paper showed that the method allows to significantly reduce re-configuration time upon variations of the environment topology. We defined a mechanism for the positioning system to be simply and quickly updated by dynamic upload of topology maps on mobile devices. Moreover, we also defined a mechanism to switch between indoor and outdoor environments, in order to


make the architecture choose the right positioning system to use on behalf of applications. The overall architecture has also been implemented, and a high level software application programming interface for technology-independent location sensing has been developed. Such an API has been tested on Bluetooth and GPS technology, and is compliant with the JSR-179 specifications. In order to read the RSSI on multiple platforms and multi devices (e.g.: general cellular phones), we also had to extend the JSR-82 API by implementing the additional RSSI_Provider component. As for the indoor location-sensing infrastructure, the adopted approach also lays the groundwork for the development of strategies for leveraging the robustness and the scalability by assigning multiple Bluetooth sensors to the same room. Privacy concerns were out of the scope of the paper. However, it is worth pointing out that in the proposed architecture location is calculated on the client-side and the position information is locally kept on mobile devices for personal use. This enables the design of client-side mechanisms for specifying trusted services and infrastructures. We used the prototype at the ITEM laboratory building as a proof-of-concept implementation of the proposed technique. We are currently working to provide a more thorough and comprehensive evaluation of the proposed architecture, and to compare it with other state-of-the-art solutions.

7. References [1] J. Hightower and G. Borriello. Location Systems for Ubiquitous Computing. IEEE Computer, 34(8):57–66, August 2001. [2] T. Roos, P. Myllymaki and H. Tirri, A statistical modeling approach to location estimation, IEEE transactions on Mobile Computing, 1(1): 59 - 69, Jan.-Mar. 2002.

[7] M. H. S. Capkun and J. Hubaux, GPS-free positioning in mobile adhoc networks, in Hawaii International Conference on System Sciences, HICSS-34, January 3-6 2001. [8] F. Cornevilli, D. Cotroneo, M. Ficco, S. Russo and V. Vecchio. Implementing Positioning Services Over an Ubiquitous Infrastructure. Proc. of 2nd IEEE Workshop on Software Technologies for Embedded and Ubiquitous Computing Systems (WSTFEUS ’04). IEEE CS Press (2004). [9] Y. Fukuju, M. Minami, H. Morikawa and T. Aoyama. DOLPHIN: An Autonomous Indoor Positioning System in Ubiquitous Computing Environment. Proc. of the IEEE Workshop on Software for Future Embedded Systems (WSTFES’03), pp. 53–56, Hakodate, Japan, May 2003. [10] S. Hsi, R. Semper, W. Brunette, A. Rea and G. Borriello, eXspot: A Wireless RFID Transceiver for Recording and Extending Museum Visits. Ubicomp 2004. [11] A. Kotanen, M. Hannikainen, H. Lappakoski and T.D. Hamalainen, Experiments on Local Positioning with Bluetooth. In Proceedings of the International Conference on Information Technology, Computers and Communication (ITCC03). [12] C. di Flora, M. Ficco and S. Russo, Indoor Positioning for Location-aware applications on Java-based Mobile Devices. Proc. of 2nd Workshop on Java Technologies for Real-Time and Embedded Systems (JTRES 2004), On the Move to Meaningful Internet Systems 2004, Springer-Verlag LNCS, vol. 3292, pp. 383-393, 2004. [13] Bluez: Official Linux Bluetooth protocol http://bluez.sourceforge.net/

stack:

[14] JCP - The Java Community Process Program, JSR-82: Java APIs for Bluetooth, http://jcp.org/en/jsr/detail?id=82

[15] Bluetooth SIG, Specification of the Bluetooth System - Core and Profiles V1.1, 2001 http://www.bluetooth.org.

[3] C.A. Patterson, R.R. Muntz and C.M. Pancake. Challenges in Location-Aware Computing. IEEE Pervasive Computing, 2(2):80–89, June 2003. [4] Location Inter-operability Forum. Mobile Location Protocol LIF TS 101 Specification, Version 3.0.0, June 2002. [5] Java Community Process. Location API for J2ME Specification 1.0 Final Release. September 2003. [6] P. Bahl and V.N. Padmanabham. RADAR: An InBuilding RF-based User Location and tracking System. Proc. of IEEE Infocom 2000, Vol.2:775–784, Tel-Aviv, Israel, March 2000.
