KÜPPER LAYOUT
8/21/06
1:34 PM
Page 114
ADVANCES IN SERVICE PLATFORM TECHNOLOGIES FOR NEXT-GENERATION MOBILE SYSTEMS
TraX: A Device-Centric Middleware Framework for Location-Based Services Axel Küpper, Georg Treu, and Claudia Linnhoff-Popien, University of Munich
ABSTRACT Location-based services turned out not to be the “next big thing” following the success stories of GSM and SMS. The reasons for this are manifold and range from inaccurate cellular positioning technologies to a lack of competition in this field, both being closely related to the fact that positioning is controlled by a network-centric approach where the mobile network operator has the unique selling point for making position data available to third parties. However, things change: small, low-cost GPS receivers, either attachable to mobile devices or even integrated, are enjoying great popularity since their recent inception and are expected to become a standard feature of cell phones in the near future. In conjunction with mobile packet data services, they provide a basis for device-centric LBS platforms, where position data can be obtained directly from the mobile device. In this article the device-centric LBS middleware TraX, which focuses particularly on position management, advanced functions for interrelating the position data of several targets, and privacy protection, is presented. Due to its generic and open design, TraX can be reused for a broad range of different LBSs and thus fosters service diversity and multiprovider environments, both of which are essential for making the next generation of LBSs a success.
INTRODUCTION Location-based services (LBSs) automatically derive the geographic positions of one or several individuals in order to create, compile, select, or filter information and offer it to its users. Typical application areas are restaurant and friend finder services, and mobile gaming and marketing, as well as navigation. LBSs have their primary origins in the E911 mandate in the United States, which was passed in the late 1990s and which obliges mobile network operators (MNOs) to locate emergency callers with a ruled accuracy. As cellular networks were not ready for high accuracy positioning at that time, the E911 man-
114
0163-6804/06/$20.00 © 2006 IEEE
date resulted in enormous efforts to extend cellular networks by advanced positioning technologies. In this context, LBSs represented an important attempt for exploiting the new positioning technologies on a commercial basis and to regain the associated investments. As a result of these developments, standardization authorities and manufacturers created a network-centric solution. MNOs make position data accessible to third actors at a central Gateway Mobile Location Center (GMLC) against a fee, and positioning is controlled inside the cellular networks by system-specific control procedures, see [1] for an overview. Unfortunately, most of today’s LBSs based on this network-centric solution did not prove to be a success due to several reasons. At first, many MNOs, especially those outside the United States, still avoid the high roll-out costs associated with the introduction of advanced positioning technologies. Instead, they offer only Cell-Id positioning, which, however, does not meet the accuracy demands of many LBS applications. Second, most MNOs do not make position data accessible to third parties at all or only against overpriced conditions. As an alternative solution, this article presents the device-centric LBS middleware TraX (tracking and exchange). It offers interfaces to external actors for obtaining position data directly from a mobile device via packet data services like GPRS and UMTS, and hence bypasses the operator’s GMLC. Furthermore, it provides several subservices for processing position data. The remainder of this article is structured as follows: the next section presents a classification scheme for LBSs, which helps to identify the key functions of the proposed middleware. We compare network and device-centric LBS supply chains and identify the actors and their roles participating during the execution of an LBS. Then we provide an overview of TraX and its functional layers. We motivate privacy protection, followed by a short introduction of related mechanisms. The deployment of TraX for different scenarios is demonstrated, followed by the conclusion.
IEEE Communications Magazine • September 2006
KÜPPER LAYOUT
8/21/06
1:34 PM
Page 115
LBS CLASSIFICATION The following list provides different criteria for classifying LBSs with regard to basic functions an LBS middleware has to support: Reactive and proactive LBSs: An LBS is said to be reactive if location-based information is delivered on request to the user. On the other hand, an LBS is proactive if it is triggered on the occurrence of predefined location events (e.g., entering, approaching, or leaving a restaurant or a landmark). Then the user is automatically notified. Self-referencing and cross-referencing LBSs: It can be distinguished whether the user’s own position is processed or that of another target. In self-referencing LBSs, the user and target are identical, while in cross-referencing LBSs, they are different persons. Single-target and multitarget LBSs: In singletarget LBSs, the position of a single target is set into relation with static geographic content, for example, the user is displayed the target’s position on a map. Using multitarget LBSs, the focus is on interrelating the positions of several targets, for example, in order to detect whether several targets remain close by. Central and peer-to-peer LBSs: Central LBSs are provided and managed by a central location or application server. Peer-to-peer services, on the other hand, are self-organizing, which means that position data is exchanged directly between users without the need of intermediary actors. In the following the focus is on central LBSs. Outdoor and indoor LBSs: Outdoor LBSs are available in huge geographical areas and make use of satellite or cellular positioning technologies, while indoor LBSs assist the user inside buildings and are based on local positioning technologies. Figure 1 provides an overview of these classes. Typical first-generation LBSs are reactive, self-referencing, and single-target, and they focus on outdoor applications. Most of them are so-called finder services, which show their users nearby points of interest. Advanced services have been gaining more and more momentum in recent years, and they will determine the appearance of the next LBS generation. Examples are child-finder services, which allow parents to locate their children (reactive, cross-referencing, and single-target), or community services, where members of a community can mutually share their locations on demand (reactive, cross-referencing, and multitarget).
NETWORK VS. DEVICE-CENTRIC LBS SUPPLY CHAINS The execution of an LBS is an interorganizational matter and hence requires the interaction between several actors, each of it adopting one or several roles. As depicted in Fig. 2, an associated supply chain clarifies the flow of position data between the actors. Figure 2a shows the classical, network-centric supply chain. Positioning of the target is controlled inside the cellular network and realized by system-dependent technologies like Cell-Id,
IEEE Communications Magazine • September 2006
Next LBS generation First LBS generation 1 3 2
2 1
User/service interaction:
Reactive (pull)
Proactive (push)
User/target relationship:
Self-referencing
Cross-referencing
Single-target
Multi-target
Infrastructure:
Central
Peer-to-peer
Environment:
Outdoor
Indoor
Plurality:
■ Figure 1. Functional classification of LBSs.
(a) GIS
Content provider Application server
GMLC Target
LBS provider
MNO GSM/UMTS positioning
(b)
User
MLP
GIS
Content provider Application server
Positioning Target enabler Self-positioning of mobile device (e.g., GPS, Gallileo, ...)
LBS provider LBS middleware
(c)
Positioning Target enabler Self-positioning of mobile device (e.g., GPS, Gallileo, ...)
User
GIS Location server Location provider
Content provider Application server LBS provider
User
LBS middleware
■ Figure 2. Supply chains for LBSs: a) classical network-centric; b) direct device-centric; c) intermediary device-centric. enhanced observed time difference (E-OTD), observed time difference of arrival (OTDoA), uplink time difference of arrival (U-TDoA), or by assisted GPS (A-GPS). The derived position data is gathered at the GMLC of the MNO and accessed by an external LBS provider via the
115
KÜPPER LAYOUT
8/21/06
1:34 PM
Page 116
Application layer Traffic telematics
Child tracking
Navigation LBSs
Finder LBSs
Alert LBSs
Community LBSs
Mobile gaming
Mobile marketing
Telematics
...
Service layer
Emergency services
Health care
Pet tracking
Tourist guide
Goods tracking
Safety services
Suppl. services
Finding stolen cars
Toll collecting
Single-target
Multi-target
Reactive services • Location request • Emergency location request • ...
Reactive services • Proximity query • Separation query • Cluster query • ...
Proactive services • Location reporting • Emergency location reporting • ...
Proactive services • Proximity detection • Separation detection • Cluster detection • ...
OpenLS Reactive services • Presentation • Routing • Geocoding • Reverse geocoding • Directory • ...
Position management layer Piggybacking
Polling
PU periodic
PU distance
PU zone
Geographic information system (GIS) and spatial database
...
Positioning layer GPS
A-GPS
E-OTD
WLAN
RFID
...
Target
LBS provider
Location provider
Content provider
■ Figure 3. Architecture of the device-centric middleware.
Mobile Location Protocol (MLP) from the Open Mobile Alliance (OMA), see [2]. The LBS provider makes an LBS accessible to the user. The content provider optionally supports an LBS provider and offers access to a Geographic Information System (GIS), which is needed for creating maps or routing information. TraX is based on self-positioning methods and allows external actors to obtain position data from the target’s device, which significantly affects the supply chain. In the following it is distinguished between a direct and an intermediary device-centric supply chain. The former is depicted in Fig. 2b. The positioning enabler maintains the infrastructure for device-based positioning, for example, GPS or the future Galileo system. The direct supply chain serves well for rudimentary LBSs that do not require the permanent tracking of targets or the spatial interrelation of their positions, that is, for reactive, self-referencing, single-target LBSs. However, for proactive, cross-referencing, or multitarget LBSs these functions would have to be implemented at each LBS provider separately. Therefore, in the intermediary supply chain depicted in Fig. 2c a location provider serves as an intermediate between the target and the LBS provider. It offers a set of standardized services to an LBS provider that cover the functions mentioned before. A target is in a trusted rela-
116
tionship with a location provider of her choice. The advantage of this model is that a target being observed by several LBS providers simultaneously does not need to enter into a trusted relationship with each of them. Instead, her location provider acts as a single access point that manages her position data. At first glance, this approach looks similar to the network-centric solution presented previously. In fact, the MNO could serve as a location provider in order to manage location data on behalf of its subscribers. However, in contrast to the network-centric GMLC, the MNO is not the unique selling point any longer and is in competition with other location providers. Furthermore, the position management and the provisioning of related services is decoupled from system-dependent positioning, and thus allows the integration of nonstandardized and indoor solutions.
MIDDLEWARE ARCHITECTURE Some middleware platforms developed for LBSs primarily focus on the control of positioning and hiding this process from the respective application, for example, the Location API of the Java 2 Micro Edition (J2ME) [3] or the PlaceLab platform [4]. Others deal with the representation of and access to location data and geographic
IEEE Communications Magazine • September 2006
KÜPPER LAYOUT
8/21/06
1:34 PM
Page 117
content, for example, Open GIS Location Services (OpenLS) specified by the Open Geospatial Consortium (OGC), as well as the Nexus [5] and MiddleWhere [6] platforms, to name only a few. TraX differs from these platforms in that it is distributed among all actors of the LBS supply chain and, because of its modularized approach, supports different configurations of it. Furthermore, it provides a reusable and extensible service concept for realizing the different classes of LBSs introduced earlier. The proposed services can be extended by additional ones if there is a demand for new LBS functions in future. Extensibility of TraX also comprises positioning in that new or proprietary technologies can be included. Finally, the middleware integrates proven frameworks, for example the J2ME Location API, the MLP, and OpenLS. Figure 3 shows the proposed middleware as an arrangement of several layers, which are described in the following sections.
POSITIONING LAYER The positioning layer exclusively resides at the mobile device of the target and consists of a positioning set, which incorporates one or several device-based positioning technologies. They allow an autonomous self-positioning in that the device observes transmissions from the surrounding infrastructure (e.g., access points, base stations, or satellites) and calculates its position from that. Various methods for this calculation exist. Using proximity sensing, which in cellular networks corresponds to the Cell-Id method, the target’s position is estimated from the coverage area of the serving base station or access point. Other methods, for example, GPS, E-OTD, or OTDoA, determine the ranges or range differences between the device and a number of satellites or base stations and derive the position by lateration. Finally, fingerprinting is based on observing radio patterns on the spot and comparing the observed pattern with patterns that have been prerecorded at well-defined positions. Also, it can be distinguished between outdoor and indoor (or local) systems, which differ in a number of characteristics like the positioning method used, the coverage area, and the delivered accuracy and format of location data. Outdoor systems are usually based on lateration or proximity sensing, cover huge geographical areas, and show accuracies between 10 m (GPS) and several hundreds of meters (cellular technologies like E-OTD and Cell-Id). Indoor systems, on the other hand, primarily use proximity sensing or fingerprinting, are limited to (parts of) a building, and have a typical accuracy in the range of some meters or even centimeters. Apart from Cell-Id, most outdoor systems deliver geographic location data in terms of coordinates based on a spatial reference system, while most indoor systems provide symbolic location data, for example, the identifier of an access point or the number of a room inside a building, or location data based on a local coordinate system. An overview of the various outdoor and indoor positioning technologies and their special characteristics can be obtained from [1] and [7]. The positioning layer hides this heterogeneity
IEEE Communications Magazine • September 2006
(a) Polling
Application/location server
Positioning daemon
PollingResponse[Quality_requirements, ...]
PollingResponse[Position_data]
(b) Updating Positioning daemon
PositionUpdateRequest[periodic|distance|zone, update_period|update_distance|update_zone, CallBackAddress...]
PositionUpdate[Position_data] PositionUpdate[Position_data] PositionUpdateRemove[] (c) Piggybacking Positioning daemon [web proxy] http://www.location-based-services.org/lat=48_08_43&long=11_35_36/
■ Figure 4. Basic operation for position management. of the various positioning technologies from the upper layers. It receives requests for location data, which may either specify a certain positioning technology or define requirements on position fixes in an abstract manner, for example, the desired accuracy and location data format. From the methods being available, the positioning layer then selects the most suitable one and activates it. Another important task is the mapping between different location data formats if the request specifies a different format than provided by the selected technology. In this case, the positioning implementation has to translate between different formats either by calculation or by a local database that maps symbolic to geographic formats, see [4] for an example. After processing the request, the positioning layer returns either a single report (immediate mode) or continuous location reports (continuous mode) to the requestor. A report contains the determined location and the underlying format, the estimated accuracy, and the positioning technology used. In the continuous mode, the positioning layer is also responsible for executing a positioning handover, which denotes the switching between different positioning methods and which is needed when a selected positioning method suddenly becomes unavailable. A potential candidate for realizing the positioning layer is the abovementioned Location API for J2ME.
POSITION MANAGEMENT LAYER The position management layer is shared between the target and the LBS provider in the direct supply chain and between the target and the location provider in the intermediary approach. Its primary focus is the efficient tracing of a target. As the target is usually attached to the fixed network via mobile packet data services, position data has to pass the air interface. On the one hand, the operations of position management should therefore be dynamically configured in a way that this transfer happens as rare as possible in order to save valuable
117
KÜPPER LAYOUT
8/21/06
1:34 PM
An important prerequisite for the broad acceptance of LBSs is that targets have control about to whom, when, and in which form their position data is made available and how external actors have to deal with it.
Page 118
resources of the air interface and battery consumption at the mobile device. On the other hand, this transfer should be executed as often as required in order to meet the demands of the application. The position management encompasses different operations as depicted in Fig. 4, see also [8]. The operations are executed by a positioning daemon, which is permanently running at the mobile device in order to listen to and process invocations from the application server of an LBS provider, the location server of a location provider, or from a local client application. A simple approach for exchanging position data is polling (Fig. 4a), which is suited for reactive, cross-referencing LBSs. The polling request carries requirements concerning the quality of position data, for example, accuracy and latency, and its format. At the target site, the request is analyzed and passed to the positioning layer, where an appropriate positioning method is selected. After the location has been determined, it is returned to the requesting LBS/location provider in a polling response message. An alternative approach is to configure the mobile device for performing position updates (PUs), see Fig. 4b. The positioning layer at the mobile device continuously delivers position data to the position management layer. An LBS/location provider can subscribe for receiving PUs according to a periodic, distance-based, or zonebased strategy by passing a PU request to the positioning daemon. A periodic strategy periodically updates the position, while in a distancebased strategy an update occurs when the target has covered a certain (line-of-sight) distance with regard to the last reported position. In a zone-based strategy, the LBS/location provider is notified if the target enters or leaves a geographic zone, which is specified as a circle, polygon, or as a symbolic location name (e.g., a cell identifier) in the PU request. The different PU strategies are useful for proactive LBSs and should be dynamically configured by the LBS/location provider. Finally, position data can also be transferred together with application data, which is referred to as piggybacking (Fig. 4c). For this purpose the position daemon acts as a Web proxy that attaches position data to HTTP requests, which is also applied in PlaceLab [4]. Piggybacking might be the preferred approach for reactive, self-referencing LBSs.
SERVICE LAYER The service layer provides a set of subservices, which are offered by location and content providers and which are accessed by LBS providers via well-defined interfaces. The content provider offers services for interrelating a target’s position with geographic content, for which we propose to adopt OpenLS [9]. OpenLS provides the following core services: a presentation service for displaying a target’s position on a map, a directory service for finding nearby points of interest, a (reverse) geocoding service, as well as a routing service. Subservices offered by the location provider are based on the functions of the position management layer and can be subdivided in close
118
correspondence to the LBS classification scheme. Single-target services make position data of a target available to an LBS provider, either in a reactive fashion by using the position request service or in a proactive fashion by using the position reporting service. The former is based on the polling operation of the position management layer, while the latter utilizes the different PU operations. The MLP can be used as a transport protocol for these services. Messages passed between LBS and location provider contain XML elements for identifying the target for which position data is needed and, among other things, for specifying the desired quality of position data. Unfortunately, MLP only enables periodic reporting so far and does not care for distance or zone-based reporting. Multitarget services focus on spatially interrelating position data of several targets and are available in a reactive and proactive version. Without being exhaustive, the focus is here on spatial interrelations like proximity and separation among different targets, spatial clustering, or k-nearest-neighbor determination. Reactive query services perform a check with regard to these interrelations, while proactive detection services automatically trigger an event as soon as such an interrelation occurs.
PRIVACY ASPECTS A target’s position data represents very sensitive, personal information, which runs the risk of being misused either by legitimate actors or by unauthorized parties. Therefore, an important prerequisite for the broad acceptance of LBSs is that targets have control about to whom, when, and in which form their position data is made available and how external actors have to deal with it. This can be achieved by a privacy policy. According to [10], such a policy is an assertion that a certain amount of information may be disclosed to a certain actor under consideration of a certain set of constraints. The specification and enforcement of constraints must be supported by the middleware. At the mobile device the primary focus is on actor constraints, which identify the location and LBS providers that are allowed to access a target’s position data. Optionally, for each actor legitimated in this way the target can additionally determine notification constraints, which prescribe whether or not the target wishes to be notified about positioning attempts, as well as time and location constraints, which restrict positioning to certain times and to predefined locations. Additional constraints are enforced by the location and LBS provider. The focus is here on limiting access to position data to well-defined LBS users as well as on service constraints, which fix the LBSs for which position data may be processed. A two-step approach for defining privacy policies and for making them available is proposed by Geopriv, which is a location exchange protocol (similar to MLP) from the Internet Engineering Task Force (IETF), see [11]. Geopriv attaches simple privacy constraints to location data. Furthermore, additional constraints of a target can be maintained by a dedicated actor,
IEEE Communications Magazine • September 2006
KÜPPER LAYOUT
8/21/06
1:34 PM
Page 119
which is denoted as rule holder and which the recipient of a target’s location data can request on how to process it. Even if a target has properly specified such constraints, there remains the risk that an actor violates them, or, in other words, that an actor may “talk about the target behind its back.” Therefore, another mechanism for privacy protection is anonymization, which focuses on hiding a target’s true identity by the use of pseudonyms. In general, it must be stated that anonymization is an exhausting and complicated matter, because pseudonyms can be easily uncovered by statistical attacks, especially if position data is disclosed at locations frequently visited by a target, for example, at her home or workplace. This is of minor concern for reactive, self-referencing LBSs, where the target explicitly and only occasionally discloses position data, but is a serious risk for proactive, cross-referencing LBSs, where the target implicitly and frequently passes position data to other actors. Several techniques have been proposed in the literature to avoid or at least complicate statistical attacks on position data tagged with pseudonyms. A well-known formal model is kanonymity, which is given if the position of a target cannot be distinguished from that of at least k – 1 others. According to [12], this can be achieved by intentionally degrading the spatial or temporal accuracy of position data in a way that k – 1 other individuals are simultaneously present in an area of some size or at a certain position in a certain time interval. Obviously, this approach is difficult to apply to applications requiring high-accuracy position data. An alternative for complicating statistical attacks is to periodically change the pseudonyms of a target. However, this approach suffers from the risk that an attacker might interlink different pseudonyms together. In [13] it is therefore proposed to restrict the disclosing of position data to so-called application zones, which exclude typical whereabouts of the target, and to allow the change of pseudonyms in mix zones only, but to prevent the disclosure of position data there. These techniques can hardly be realized at the mobile device of the target. Therefore, in the direct supply chain they are applied at the LBS provider, while in the intermediary approach they are realized by the location provider. Unfortunately, the aforementioned anonymization techniques are not an appropriate means for protecting privacy in conjunction with advanced functions like proximity and separation detection. An alternative approach is the usage of pseudonyms in conjunction with distance-preserving coordinate transformations, see [14]. The basic idea is that for proximity and separation checks only relative positions are needed. Hence, the coordinates can be transformed by a distance-preserving function that hides the true positions of targets from the actor performing these checks.
LBS SCENARIOS This section demonstrates the usage of the TraX middleware by means of different scenarios. Imagine that Joe visits the city of Munich
IEEE Communications Magazine • September 2006
Polling/distanceConference based PUs Conference Conference participant participant participant GPS
Positioning
Joe WLAN fingerprint
Proximity detection
Polling/distancebased PUs Zone-based PU Zone-based PU
Loc
Zone-based reporting
Community service
Campus tracking
Positioning Zone-based reporting
Piggybacking
Tourist guide
Restaurant finder
■ Figure 5. Scenarios for middleware deployment. in order to attend a conference. The organizers offer a community service for proximity detection among all participants of the conference (proactive, cross-referencing, multitarget). As Joe gives a presentation on the second conference day, the organizers kindly request Joe to subscribe to a local campus tracking service, which informs the conference chair at that day when Joe enters the building where the conference takes place (proactive, cross-referencing, single-target). In addition, Joe subscribes to a local tourist guide that automatically informs him when approaching to famous monuments (proactive, self-referencing, single-target). Finally, Joe invokes a restaurant finder from time to time in order to search for nearby Italian restaurants (reactive, self-referencing, single-target). The constellation of different services and the participating actors is depicted in Fig. 5. Joe carries a PDA, which is equipped with a GPRS/UMTS unit, and a WLAN unit, as well as a GPS receiver. Thus, the positioning set at this PDA dynamically switches between WLAN fingerprinting at the conference venue and GPS outside. Like the other participants of the conference, Joe subscribes with the location provider Loc. He legitimates it to make position data accessible to the conference organizers, the participants, and the provider of the tourist guide, but to restrict this access to the duration of his visit in Munich and to the day of his presentation, respectively. The community service makes use of the proximity detection subservice of Loc, which in dependence on Joe’s and the other participant’s movement behavior results in a sequence of polling requests and distance-based PUs. For the campus tracking service, Loc applies a zone-based update strategy in which the zone is defined by a polygon matching with the outline of the building where the conference takes place. The tourist guide instructs Loc to be informed when Joe approaches monuments via zonebased PUs. The restaurant finder is the only service without a location provider. It is invoked via a conventional Web browser and Joe’s position is passed to the Web server via piggybacking.
119
KÜPPER LAYOUT
8/21/06
1:34 PM
A special concern is the avoidance of peer pressure, which might occur if persons are exposed to demands for sharing their location data with other persons from their family or business area.
Page 120
PROTOTYPE REALIZATION Large parts of TraX have been realized in a prototype. The special focus was on the position management and the service layer, and hence the positioning layer has been realized with the Location API of J2ME in conjunction with GPS. The positioning daemon is available as a J2ME and Symbian application and has been tested on several mobile devices from different vendors. The positioning daemon and a J2EE location server are interconnected via the GPRS of a public cellular network. The position management layer of the prototype so far supports polling and the PU operations described herein, while piggybacking is to be implemented in a future version. With regard to the service layer, proactive proximity and separation detection have been realized, based on different algorithms adaptively controlling polling as well as distance and zone-based PU operations.
CONCLUSIONS AND FUTURE WORK In this article, an open and device-centric middleware concept for LBSs has been presented as an alternative to the network-centric and systemspecific solutions of cellular networks. It has been designed under consideration of different LBS supply chains and provides means for supporting different classes of LBSs, ranging from the traditional reactive, single-target services to more sophisticated proactive, multitarget, and cross-referencing LBSs. The layered architecture allows us to easily integrate outdoor and indoor positioning technologies, and the position management provides a means for dynamically configuring the exchange of position data between mobile devices and external components in the fixed network in accordance with application requirements. Future work will concentrate on mechanisms for supporting location-based social networks and community services. This includes the development of algorithms for advanced subservices like clustering and k-nearest-neighbor detection as well as new privacy-protection methods. Regarding the latter aspect, a special concern is the avoidance of peer pressure, which might occur if persons are exposed to demands for sharing their location data with other persons from their family or business area. The latest information about TraX can be obtained from the companion Web site [15].
REFERENCES [1] A. Küpper, Location-Based Services: Fundamentals and Operation, New York: Wiley, Sept. 2005. [2] Mobile Alliance LOC MLP, Mobile Location Protocol, http://www.openmobilealliance.org/ [3] Community Process, JSR-179 Expert Group, Location API for Java 2 Micro Edition, 2003.
120
[4] A. LaMarca et al., “Place Lab: Device Positioning Using Radio Beacons in the Wild,” Proc. Int’l. Conf. Pervasive Computing, Munich, Germany, Springer-Verlag, May 2005, LNCS 3468, pp. 116–33. [5] D. Fritsch and S. Volz, “Nexus – the Mobile GIS environment,” Proc. 1st Joint Wksp. Mobile Future and Symp. Trends in Commun., Bratislava, Slovakia, Oct. 2003, pp. 26–28. [6] A. Ranganathan et al., “MiddleWhere: A Middleware for Location-Awareness in Ubiquitous Computing Applications,” Proc. 5th ACM/IFIP/USENIX Int’l. Conf. Middleware, New York, no. 78, pp. 397–416. [7] W. K. Krzysztof and J. Hjelm, Local Positioning Systems: LBS Applications and Services, Boca Raton, FL: CRC Press, May 2006. [8] A. Leonhardi and K. Rothermel, Protocols for Updating Highly Accurate Location Information, Geographic Location in the Internet, Kluwer Academic Publishers, 2002. [9] GeoSpatial Consortium, OpenGIS Location Services (OpenLS): Core Services, http://www.opengis.org/ [10] J. R. Cuellar, Location Information Privacy, Geographic Location in the Internet, Kluwer Academic Publishers, 2002. [11] IETF Geopriv Working Group, http://www.ietf.org/ html.charters/geopriv-charter.html [12] M. Gruteser and D. Grunwald, “Anonymous Usage of Location-based Services Through Spatial and Temporal Cloaking,” Proc. ACM/USENIX Int’l. Conf. Mobile Systems, Applications and Services (MobiSys ’03), San Francisco, CA, 2003. [13] A. R. Beresford and F. Stajano, “Location Privacy in Pervasive Computing,” IEEE Pervasive Computing, vol. 2, no. 1, 2003. [14] P. Ruppel et al., “Anonymous User Tracking for Location-based Community Services,” Proc. Int’l. Wksp. Location and Context-Awareness, LNCS 3987, SpringerVerlag, May 2006. [15] TraX Web site, http://www.mobile.ifi.lmu.de/TraX/
BIOGRAPHIES AXEL KÜPPER (
[email protected]) received his Ph.D. in computer science from Aachen University of Technology in 2001. Currently, he is a research assistant at the Mobile and Distributed Systems Group of Ludwig-Maximilians-University Munich, Germany. In the recent years, he was involved in several projects in the areas of context-aware services and content distribution in broadcast and cellular networks. He is author of the book “Location-based Services: Fundamentals and Operation” (Wiley, 2005) and gives lectures in mobile communications. His special research interests are in the field of location-based services and mobile television. G EORG T REU (
[email protected]) received his M.Sc. degree on informatics from the Technical University of Munich in 2004. Since then he has been working towards a Ph.D. degree as a research fellow in the Mobile and Distributed Systems Group in the Department of Informatics at the Ludwig-Maximilians-University Munich, Germany. His research interests include location-based services (LBSs), in particular, proactive LBSs, location-based community services, and mechanisms for location privacy. CLAUDIA LINNHOFF-POPIEN (
[email protected]) received her Ph.D. degree from the Aachen University of Technology. She is a full professor for Mobile and Distributed Systems at the Ludwig-Maximilians-University Munich, Germany. In addition to her research activities, she gave lectures at the University GH Essen, and was a research visitor at the Department of Computer Science, Washington University of St. Louis, MO. Her research interests include ubiquitous computing, mobility, service discovery, and context awareness. Her research is supported by Siemens, BMW, and several public research-funding organizations.
IEEE Communications Magazine • September 2006
