An Architecture for Location Dependent Query Processing Ayse Y. Seydim, Margaret H. Dunham Department of Computer Science and Engineering Southern Methodist University Dallas, TX 75275-0122 yasemin(mhd)@engr.smu.edu
Abstract As the mobility of people increases, anytime, anywhere computing has become a must. With the advances in wireless communications, the geographical position of the mobile user can be estimated accurately enough to be used to access data dependent on it. Location awareness then enables new kinds of services specific to localized information. While this provides great flexibility for the end user, it creates many challenges for the content providers and wireless operators. We propose an architecture, Location Dependent Services Manager (LDSM), between the mobile user and the service/content providers to service Location Dependent applications which access Location Dependent Data. The proposed middleware does location translation which we call Location Leveling, to adjust the location granularities and to solve the location mismatch problem. Quality of query results and the complicated queries involving more than one service provider is also supported in this middleware. In this paper, we give an overview of the proposed architecture, examine the query processing issues and discuss the future work plans.
1. Introduction With the advances in wireless communication and hardware technology, more and more people have begun using wireless devices not only to communicate with each other but also to access the information they need, from anywhere, at anytime and while on the move. Moreover, location has become a very important constraint in many applications. Users need to access applications and data which are related to their geographical position, seeking information about unfamiliar places or local lifestyle data [6] which
This material is based upon work supported by the National Science Foundation under Grant No. IIS-9979458 This material is based upon work supported by the National Science Foundation under Grant No. IIS-9979453
Vijay Kumar Computer Science Telecommunications University of Missouri-Kansas City Kansas City, MO 64110
[email protected]
are determined by the related location. Data kept for local events, local yellow pages, and weather information are examples of such Location Dependent Data (LDD) [14]. The rapid growth of the volume and diversity of data makes it very difficult for users to discover and know the correct sources of LDD in which they are interested. As a general information server, the Internet requires users to have apriori knowledge about these services. Thus, Location Dependent Services (LDS) are being developed as applications that can produce the desired LDD results. Local directory services, hotel and restaurant reservation, emergency services, location based advertising and tourist guides are examples of LDS applications. Location is provided by a Location Service (LCS) or a GPS-based solution. LDS applications seek specific information related to an implicitly or explicitly known location. “Find the closest hotel within 5 miles.” is an example of a Location Dependent Query (LDQ). In these applications, location determines the values of other attributes or objects. Unlike an LDQ, a Location Aware Query has the explicit specification of location in some granularity [15]. Content providers (service providers) must support all of these queries even if the associated databases do not contain specific location information. Whether the query issuer is moving or not, there are two basic types of location based applications. First are the ones that provide data related to the objects which are not moving. In the example above, “hotel” is not moving. Supporting these queries requires that the data be able to be accessed by location. Second type of applications involve queries about objects which are themselves moving. “Find all cars within 50 feet of my car.” is a query of this kind. They basically need location of the mobile object to use in further processing. These types of applications, which are also called moving-object database (MOD) applications [17], will become more crucial in the years ahead as “smart” cars are developed. We concentrate on the first type of applications as LDS applications and propose a flexible and functional software architecture serve for both types of ap-
plications. The proposed architecture is not a replica of the commonly deployed middleware approach, rather it maps many wireless operators to many content providers thereby providing service to any kind of mobile/stationary users. In this paper, we give a background for the LDS architectural model designed to support LDD and LDQs in the next section. We present our view of a general LDS framework in Section 3. The proposed middleware which services between wireless operator and end user services is presented in Section 4. Related previous work is summarized in Section 5 and summary and our future work plan are discussed in the last section.
2. Background Currently, wireless operators and providers work to offer users some basic LDS applications. Content/service providers are responsible for the selection or processing of data asked. To support the LDS applications, neither the wireless operator nor the content provider is suited to provide all the functionality required. The content provider extracts the information needed to answer users’ queries. This includes all types of queries, not just LDQs. To support the LDQs, the user’s query must be bound to a particular location (that for which he wishes to have the query answered), and the query must be processed by the content provider to find the appropriate LDD to answer the query. Keep in mind that legacy type databases currently used by content providers may not have location information or may have a different granularity of information than that to which the query is bound. This creates a problem when designing an architecture to support it LDS applications. Any LDS design must at least bind location to query, determine content provider(s) for processing and translate bound query location to data location. Three architectural approaches can be considered to support LDS applications. In Content Side oriented approach, all LDS support functions are provided by the content provider with the support of a Location Service (LCS) module. The content provider is responsible for binding the mobile user’s query to a location and then for processing the query. Location is assumed to be the current position of the mobile user. If the granularity provided by the is not compatible with the granularity of the stored data, then the content provider may need to customize its database accordingly. Ericsson’s Mobile Positioning System (MPS) is an example of this type of architecture [4]. In Wireless Side oriented approach, support for LDS applications is moved to the wireless operator side. Wireless operator provides all the functionality to the mobile user in a well defined and limited way. The mobile user does not know anything about the content provider, all he sees is the menu provided by his wireless operator. A middleware ap-
proach assumes that a special software agent sits between the wireless operator and the content provider. The software agent performs all LDS functions, with the help of software, independent of both the wireless operator and the content provider. Currently, SignalSoft Corporation [16], and Mobilaris [11] support this type of architecture. Wireless providers include these middleware not only for LDS applications but also for billing, provisioning, etc.. An architecture should be flexible enough to support multiple content providers, wireless operators and complicated LDQ requests. It may not be known apriori which content provider is to receive and process the query. Indeed the content provider choice may itself be location based and the same query could be sent to two different providers. Users should be able to use any LDS from any service provider, not only the ones presented by default from the wireless network. Besides being independent of the underlying cellular technology, the middleware approach provides a more flexible and transparent framework for LDS applications. Different location identification software or can be used in the architecture to locate the mobile user. LDQs of the future will need to have the query bound to locations other than the current position of the MU. In addition, very complex location binding can be supported. Some types of queries may be repeatedly requested. Some queries may be fragmented and sent to different content providers. These subquery results could then be merged together and returned to the user. The architecture could also use intelligence for caching results for frequent disconnection cases, or use access patterns for prefetching data and for efficient use of resources. We thus feel that the middleware option is a good choice to support future location dependent queries in the mobile computing environment. We propose a Location Dependent Services Manager (LDSM), a
between the mobile user and the applications, to provide this flexibility and functionality. We envision that the middleware will support potentially many service providers and wireless networks. Quality of results according to this matching, support for complex queries and possible result merging have to be provided. Caching and prefetching will enrich the functionality of LDSM. We present our architectural view which encompasses the LDSM next.
3. Location Dependent Services Framework In the widely accepted mobile computing model, the wireless interface of the Base Station or Mobile Support Station supports the wireless communication via cellular networks, satellites, or wireless LAN technology [2], [12]. For mobile computing applications, if needed, the location of the mobile user may be estimated by an in collaboration with the location management provided by the
wireless operator. We include the box in traditional mobile computing architecture and assume the location of the user is either provided by the network or by the device (GPS). We also assume the primary copy of LDD resides on some fixed node in the network but a cached copy of it may exist on the mobile device. A detailed view of LDS framework is given in Figure 1. It includes the Mobile Unit, Wireless Network, LDSM and the Fixed Network Partner Services. Mobile devices may access an enterprise network or Internet, and the connection to fixed networks is through a wireless operator’s network. LDS applications are implemented by the service providers or they are the software adapted for legacy/existing applications. We refer to any end user services which support LDQs as Fixed Network Partner Services. The Wireless Network provides the wireless interface and the operator has the responsibility of supplying the location of the Mobile Unit to authorized parties by the help of an . In the LDS framework, we envision that Mobile Units have two types of software components: an LDS Interface to provide the basic interface for LDS applications, and User Service Agents - (USAs). The mobile user prepares the query, sends it to wireless network, sets user preferences (such as caching, prefetching, and complex query filtering), and views the results with the help of these two interfaces. The LDS Interface is a general interface for LDS applications which does the query communication between the user and the LDSM. Queries may originate from the USAs or may be the basic queries provided by the interface itself. In the interface, basic facilities are provided to sign on with an LDSM service, to state user preferences for LDSM services, to view results of previously requested queries (perhaps interrupted by disconnect). User Service Agents - USAs are the mobile user interfaces for the corresponding Fixed Network LDS applications. These interfaces may be pre-installed or may be obtained by subscribing to a service or a group of services. A mobile browser can also be considered as a USA which provides an interface for Internet applications. The middleware can be passed without any processing in this case. Each application or a group of applications has to register related properties and arguments to the LDSM to start the service. In this way, a service provider informs LDSM about the application needs, such as the location granularity type needed for the queries, whether the location is defined in the database schema or if data partitioning is used in implementation. These should be specified in order for the queries sent by the mobile user to be transformed to an appropriate form to get the answers from the service. The legacy systems should be able to process LDQs by registering with the LDSM.
4. Location Dependent Services Manager 4.1. Location Related Services There are two basic location related services provided by the LDSM. Using the support of , it binds the query to a location and determines the location granularity at which to process the query at a content provider. The latter requires that the LDSM determine the corresponding content provider(s). It may also require that the query predicate be modified accordingly. For example, a “closest” request may be translated to “within 5 miles”. When a query is sent to LDS framework with user preferences, it is important to distinguish the location constraint in the query. For this purpose, the query needs to be analyzed to see if it includes an explicit location specification, an implicit indication to the user’s current location or no location at all. “Find the movie theaters in Richardson.”, “Find the closest movie theaters.”, “Find the lead actor’s name in the movie ’Meet the Parents’?” are examples of each type respectively. It is necessary to identify the location constraint and bind the location to the query. In the examples corresponding locations are “Richardson”, “my current location”, and none. When the current location of the user is required for the query, the mobile user id is sent to to obtain the location. location is then used to determine the location for which the query should be processed. This location data is then bound to the query with the obtained granularity. The new query with the lat/long granularity will be, “Find the movie theaters closest to (x,y).”, while the meaning of “closest” may be defined as “within a 5 mile radius circle”. While the identification of location within the query is important, the granularity of the location is also important. The location granularity in the query may be quite different from that at which the data is stored by the service provider. Definition 1 If the location granularity specified (implicitly or explicitly) in an LDQ and the location granularity of the data stored by the application are not the same, there is a Location Granularity Mismatch. The LDSM addresses the Location Granularity Mismatch problem by mapping the location to the stored location. The manner in which this is to be performed is not always straightforward. In addition, different translation techniques could yield different query results. Suppose we could obtain two different location granularities to our query “Find the closest movie theaters.”, such as lat/long and cell id. The lat/long binding associates the query with a specific point whereas the cell id associates it with an entire cell as defined by the wireless operator. The query will look for all movie theaters within a 5 mile radius circle of the specific point when lat/long location granularity is used.
FIXED NETWORK PARTNER SERVICES (Service Providers & Legacy Applications)
MOBILE NETWORK SERVICES (Portals & Interfaces) E911
TOURIST GUIDE
LOCAL INFO
MU DB BS Fixed Host
LOCATION MU DEPENDENT
WIRELESS OPERATOR NETWORK
ENTERPRISE NETWORK
SERVICES Fixed Host
MANAGER (LDSM)
Fixed Host
BS
MU
DB MU
LOCATION SERVICE
WEB GATEWAY SERVER
(LCS)
INTERNET MU: MOBILE UNIT BS : BASE STATION WIRELESS LINK WIRED LINK
Figure 1. Location Dependent Services Framework While with the second granularity, the query will search for a larger area - 5 miles around the cell. The differences between these two interpretations for the query are shown in Figure 2. The mobile user may think the application is finding the movie theaters in the area indicated by part (a) of the figure, whereas he may get the results in the area shown in part (b) of the figure.
5 mile
X
!! "" !! "" !! "" !! "" !! "" !! "" !! "" !! "" !! "" !! "" !! "" !! "" !! "" !! "" !! "" !! ""
x
(a) Zones
(b) Lat/Long Binding and Zones
## ## $$ ## $$ ## $$ ## $$ ## $$ ## ## ## $$ ## $$ ## $$ ## $$ ## $$ ## x
(c) Cell Id Binding and Zones
Figure 3. Query results with zone granularity binding
5 mile
X
(a) Lat/Long Binding (b) Cell Id Binding
Figure 2. Query meaning with different location granularity bindings
The result of the query is also effected by the location granularity used for storing data by the service provider. If the database is stored in zone granularity, like city, zipcode, etc., the query results will change according to the query binding performed. Figure 3 (a) shows three zones to be searched. When the query is processed, all relevant data in any region intersecting the query will be returned as the result. If the location is bound to the query as lat/long pair, the two white zones in Figure 3 (b) will be returned as the result. On the other hand, if cell id binding is used, all three zones will be returned as a result as shown in Figure 3 (c). The results of the query thus depend on the binding granularity used at both the query level and that used by the service provider. To solve this Location Granularity Mismatch problem, the location obtained can be changed to the same granularity which the application uses. Translation from one location granularity to another requires dealing with hierarchies which describe the relationships between different lo-
cations. Location hierarchies can be used to match each query to the suitable level of granularity which the LDS application needs to process the query. Location Translation has been a term previously used to describe this process [16]. Here the possible set of location granularities at both the query and content provider sides is limited and known apriori. The translations are well defined and either hard coded or described by a precise mapping function. This approach is used by SignalSoft Corp.’s “local.info” translations, which include cell id to lat/long, lat/long to zones, zones to URL, etc. [16]. An automated process, called % '&()& +* % , is used in GIS systems which translates the implicit references (such as addresses) to explicit geographic references (such as lat/long) [5]. Geographic references then allow to locate features on the earth’s surface for analysis which is too specific for LDS applications. Definition 2 Location Leveling is the process of changing the query location granularity to the appropriate location granularity(ies) needed by the application. The term Location Leveling implies a much more complicated and general process than a simple hardcoded translation. LDSM performs this matching process dynamically by using a metadata database which includes user preferences, hierarchies describing the relationships between different location granularities, and the indication of various
translation standards (geocoding). It is also possible that one query could be matched to different service provider location granularities. Location hierarchy definitions depend on the location modeling and the structure of the granularities used by the LDS applications. We envision applications could define their location hierarchies or use a default model. Location hierarchies are kept in the metadata database. The Metadata database stores application identifiers, the granularity of location to be provided for the application, the hierarchy of locations modeled, if the application database is partitioned or not and so on. After the query is bound to the location constraints, the new query built is sent to the related service provider. To properly route queries to service providers, the LDSM needs the metadata database to store the requirements of LDS applications as well as describing the support provided by various service providers. This metadata is used to determine appropriate routing of the query. The exact structure of this metadata has yet to be determined, but it must as a minimum include the way each content provider implements location dependency, and the structure and distribution of LDD. For LDS application providers, a Metadata Manager is necessary to describe their application requirements and the location granularity definitions.
hand has to be considered. Location Leveler and Query Builder (2): The query is checked whether the bound location is sufficient for the service. The metadata database, the location graphs are examined for the data granularity. When the LDS provider for this query has stored the hotels by their zipcodes, there is a Location Granularity Mismatch. By using the location graphs, the Location Leveler translates the query to a range query, or a set of queries which will include the zipcodes that contain the Cell Id 3. The new location granularities are bound to the query and sent to Query Fragmenter. Figure 5 shows a sample location graph which could be used for this location leveling process. When we used this tree, the new query will be “ Find the hotels with 75205 , zipcode , 75206.”.
4.2. Proposed Model
Query Fragmenter and Sender (3): When the query involves more than one database and one LDS application provider, it has to be fragmented and sent to the corresponding site for processing. After the second binding, execution plan of the query can be determined. After the fragmentation of the query, LDSM communication interface sends the queries to the related data sources and service providers. If one fragment’s execution depends on other’s successful ending, then LDSM has to keep the query processing records. Assume the “Hotel” database is a centralized database, then the query sent to the service provider as it is. Result Analyzer and Query Filter (4): When the query results are ready, they are sent to the LDSM. The LDSM then combines the individual results and according to the QoS constraints, it may ignore some of the results. Suppose the service provider sends additional restaurant information which are close to each hotel within that zipcode range. If the user does not want any unnecessary information, he may indicate it in his preferences so LDSM will ignore these additional data. On the other hand, the quality of the results are also important. If the user has gas to only drive 5 miles, by using the zipcode zoning, he may end up running out of gas while finding a hotel which has a distance more than 5 miles. This is the same problem we presented in Figure 3. The recall for the results is large but the precision is not sufficient in this case. The results may need to be modified using some filtering mechanisms to ignore the obvious
The Location Dependent Services Manager (LDSM) is shown Figure 4. We describe the functionality of the LDSM using the following example query: “Find the closest hotels.”. The area to be searched may be a circle, the user being at the center. This area could be a half circle or rectangle in the direction of the movement of the mobile user. As it is seen, this query uses only one relation and location constraint is implicitly specified. Suppose the area to be searched is a circle, user being at the center, and the relation is “Hotel”. The processing of this query by the five basic components of LDSM is as follows: Semantic Analyzer and Query Binder (1): The request sent by the user is semantically analyzed, checked to determine whether the user’s current location is needed or not and query predicates are identified. The spatial operator “closest” is replaces with a predicate “within 5 miles”. The query implies the current position of the user, so the mobile user id is sent to . If a location value is also provided as a GPS value. The location is bound to the query by replacing the location variables with actual location values in the predicates. Suppose the location of the mobile user is determined by the cell id, then the query is bound to this data. Let the Cell Id = 3, then the query becomes “Find the hotels which are within 5 miles of Cell Id = 3.”. Of course, the location determined is not accurate to define a 5 mile radius search plan, but the best quality of the information at
Dallas-Fortworth Metroplex
Dallas County
Zipcode=75205 Zipcode=75206
CellId = 3 CellId = 4
Richardson
Zipcode=75082
Zipcode=75083
CellId = 21 CellId = 22
Figure 5. A sample location graph
LOCATION DEPENDENT SERVICES MANAGER (L D S M)
RESULT ANALYZER
MERGE & CHANGE
& QUERY
FORMAT 5
4
LOCATION LEVELER &QUERY BUILDER 2
SEMANTIC ANALYZER &QUERY BINDER 1
LOCATION SERVICE (LCS)
COMMUNICATION INTERFACE
NETWORK
FILTER
COMMUNICATION INTERFACE
MOBILE
LOCATION DEPENDENT SERVICE PROVIDERS
QUERY FRAGMENTER & SENDER
metadata
3
METADATA MANAGER
Figure 4. Location Dependent Services Manager architecture unnecessary results. Merge and Change Format (5): The query results may be merged and the location constraints included in the results are ignored. If the Mobile Unit is a PDA and needs the result in a tiny HTML format, then the format can be changed. Since there is no fragmentation in this query, only one group of results are expected. Notice that the LDQ query goes through several stages prior to being processes: Find the closest hotels Find the hotels within 5 miles Find the hotels within 5 miles radius of Cell Id = 3. Find the hotels with 75205 , zipcode , 75206.
-
With query fragmenting and use of multiple granularities and/or service providers even more query stages result. As can be seen this functionality is much greater than a simple location translation.
5. Related Previous Work Querying location dependent information in mobile environment has been seen as an important research area and most of the work to date has studied data management issues of mobile objects and their location information [7], [12] and [13]. Representation and indexing of moving objects have been studied by [17] and their work after [18]. These works mostly treat LDS applications as moving object database (MOD) applications. On the other hand, [6] and [2] view LDQs as asking values of data which changes depending on a location. [3] defines LDD as spatial replicas depending on a data region it is included. The query processing approaches based on physical organization of data and location binding to queries are discussed also in [9]. When we look to architectural views to support LDS applications, we don’t see the flexibility and functionality
we propose in LDSM. [1] proposed a Web-based environment for mobile LDS applications, but the LDS architecture is built on geographical routing to regional Web servers and needs apriori URL specification for each service. [10] presents a platform for location-aware mobile applications based on directory access protocols. He includes an as Location Information Server in the architecture which allows applications query location information and to be notified by the location based triggers. The architecture is specific for Internet/Intranet environments and does not have a general view of query binding and support for complicated queries. [8] proposes a scalable LDS framework with a hierarchical, semi-symbolic location model and uses URL-like specifications for finding services dependent on the location of the user. In industry, content providers and location providers have implemented different parts of the LDS framework, most of them include moving object applications as they have the location management functions. Content providers work with the wireless operators and provide their services to the subscribers. A middleware approach for LDS applications is offered by SignalSoft Corp. [16] and it is more suitable to embed to the wireless operator networks. Services are well defined and there is no support for complicated queries. In LDS applications the location is assumed to be the user’s current geographical position. Mobilaris [11] offers a Service Platform for LDS by using Ericsson’s Mobile Positioning System [4] and GPS as Location Service. Authentication/encryption, compression, billing, statistics, administration, user management are performed in the platform together with servicing to (yellow pages, traffic information, asset tracking, etc.) end-user services. The middleware is specifically designed for wireless operator needs. Wireless and Internet Infrastructure Software Environment (WIISE) architecture by Xmarc Inc. [20], aims to develop and deploy customized location applications to mobile devices and independent from the location determining tech-
nology like LDSM. In fact their environment imposes spatial applications to LDS in wireless environment and there is no support to legacy systems. In the “Visions for Wireless World” report [19], a future architecture for location dependent applications and services is envisioned to have location transparency, location tolerance, mobility awareness, flexibility and disconnection support. The access to the services and resources have to be transparent to user without any configuration. The similar vision holds for LDSM and our approach to LDQ processing is a database management view within a LDS framework. In our proposed model, LDSM shows functionality and flexibility because it offers the usage of complicated queries, execution of LDQ with legacy systems, using quality of service metrics in LDQ processing, detailed location leveling algorithms. LDSM allows alternatives for wireless providers and service providers to users.
6. Summary and Future Work Plan In this paper, we proposed a model for managing the LDS applications of different types and different requirements. LDSM provides a standard framework for these applications which is flexible, independent, and facilitates adaptability. The difference of location granularity estimated from the and the location specified in the query is proposed to be solved by the location leveling algorithms in the architecture. LDSM allows the content providers to define their needs for processing the location related requests. Implementation of an LDSM prototype is currently underway. This work at least includes : precise definition of location leveling algorithms, defining the structure of the ./0 ./ database including location graphs, precise definition of LDSM interface requirements, and identification of metrics to measure the performance of the LDS implementation.
References [1] A. Acharya, B. R. Badrinath, T. Imielinski, and J. C. Navas. A www-based location dependent information service for mobile clients. Technical report, Rutgers University, July 1995. [2] M. H. Dunham and A. Helal. Mobile computing and databases: Anything new? SIGMOD Record, 24(4):5–9, December 1995. [3] M. H. Dunham and V. Kumar. Location dependent data and its management in mobile databases. In R. Wagner, editor, Ninth International Workshop on Database and Expert System Applications, DEXA’98, pages 414–419, Vienna, Austria, August 1998. IEEE Computer Society. [4] Ericsson. Ericsson Mobile Positioning System-MPS. web page, http://www.ericsson.se/wireless/products/, 2000.
[5] ESRI. About GIS : How GIS works. ESRI, web page, http://www.esri.com/library/gis/abtgis/giswrk.html, 2000. [6] G. H. Forman and J. Zahorjan. The challenges of mobile computing. Computer, pages 38–47, April 1994. [7] T. Imielinski and B. R. Badrinath. Data management for mobile computing. SIGMOD Record, 22(1):34–39, March 1993. [8] R. Jose and N. Davies. Scalable and flexible location-based services for ubiquitous information access. In Handheld and Ubiquitous Computing, HUC ’99, volume 1707 of Lecture Notes in Computer Science, pages 52–66. Springer, 1999. [9] V. Kumar and M. H. Dunham. Defining location data dependency, transaction mobility and commitment. Technical Report 98-CSE-01, Southern Methodist University, Dallas, TX, 1998. [10] H. Maass. Location-aware mobile applications based on directory services. ACM Baltzer Journal on Mobile Networks and Applications (MONET), 3:157–173, 1998. [11] Mobilaris. Mobilaris AB - location services. web page, http://www.mobilaris.se, 2000. [12] E. Pitoura and B. Bhargava. Building information systems for mobile environments. In Third International Conference on Information and Knowledge Management, CIKM’94, pages 371–378, Gathesburg, MD, USA, November 1994. ACM. [13] E. Pitoura and G. Samaras. Locating objects in mobile computing. IEEE Transactions on Knowledge and Data Engineering, 2000. accepted, to appear.. [14] Q. Ren and M. H. Dunham. Using semantic caching to manage location dependent data in mobile computing. In Sixth Annual International Conference on Mobile Computing and Networking, MobiCom 2000, pages 210–221, Boston, MA, USA, August 2000. ACM SIGMOBILE. [15] A. Y. Seydim, M. H. Dunham, and V. Kumar. Location dependent query processing. In S. Banerjee, P. Chrysanthis, and E. Pitoura, editors, Second ACM International Workshop on Data Engineering for Mobile and Wireless Access, MobiDE’01, pages 47–53, Santa Barbara, California, USA, May 2001. [16] SignalSoft Corp. SignalSoft Corporation - Wireless Location Services. web page, http://www.signalsoftcorp.com, 2000. [17] A. P. Sistla, O. Wolfson, S. Chamberlain, and S. Dao. Modeling and querying moving objects. In IEEE Thirteenth International Conference on Data Engineering (ICDE’97), pages 422–432, Birmingham, U.K., April 1997. IEEE Computer Society. [18] O. Wolfson, B. Xu, S. Chamberlain, and L. Jiang. Moving objects databases: Issues and solutions. In International Conference on Scientific and Statistical Database Management, (SSDBM’98), pages 111–122, Capri, Italy, July 1998. [19] I.-W. P. WSI, Wireless Strategic Initiative. The book of visions 2000 - visions of the wireless world. Technical report, Wireless Strategic Initiative, November 2000. [20] Xmarc, Inc. Xmarc Inc., WIISE - Wireless and Internet Infrastructure Software Environment Architecture. web page, http://www.xmarc.com, 2000.
