An Architecture for a Distributed Universal Location Service - CiteSeerX

2 downloads 451 Views 44KB Size Report
wireless communication system has to know in which cell a mobile phone currently is, to be able to forward a call to it. Fleet management systems have to know ...
An Architecture for a Distributed Universal Location Service Alexander Leonhardi, Uwe Kubach Institute of Parallel and Distributed High-Performance Systems (IPVR) Breitwiesenstr. 20-22 70565 Stuttgart, Germany EMail: [email protected]

Abstract |

Location information about mobile users or other mobile objects is a valuable input for many applications in mobile computing and wireless communications. As this information is used by an increasing number of applications it is not practical for them to gather the location information themselves, as most systems do now. These applications could be developed much easier if they were based on a universal location service which manages the location information. This location service has to be independent from the applications it is used by and the sources it gathers location sightings from. In this paper we propose an architecture for such a distributed universal location service in the Internet. To increase the availability of the location information, the service is designed to store different copies of the location information of an object with varying accuracy on different servers, depending on the requirements of the applications accessing it. I. I NTRODUCTION An important aspect of many applications in mobile computing or wireless communications is the knowledge about the current position of their users. For example, a wireless communication system has to know in which cell a mobile phone currently is, to be able to forward a call to it. Fleet management systems have to know the current position of all trucks that are managed by them. In mobile computing, location-aware applications provide and collect information or perform certain tasks according to the current position of their users. Today, location-aware applications or systems have to contain a special component for gathering the location information. If the application is to be used outdoors and only the position of a single user is of interest, it can get this information from a local sensor for the Global Positioning System (GPS) [1] which in case of Differential GPS has an accuracy of a few meters or less but is not available indoors. An application for indoor use has to set up its own positioning infrastructure, e.g. using an Active Badge system [2]. If the application is interested in the position of more than one user there has to be a component that gathers the positioning information from the different sensors. To facilitate the implementation of location-aware applications and to use resources more efficiently, a universal location service with a standardized interface and functionality has been proposed, which collects and manages location information independently from a special application or sensor

system [3]. In this paper we propose an architecture for a distributed universal location service based on Internet technology. As this location service is intended to be available world-wide, a potentially very high number of objects, position updates and queries has to be expected. Therefore, an important issue in the design of the location service is its scalability. The proposed architecture will allow location information to be replicated on different servers with varying levels of accuracy. Copies with a high accuracy can be placed near the current position of the corresponding mobile object to allow frequent updates, while copies with less accuracy are placed nearer to the applications, to improve accessibility. Another important issue is the privacy of the location information, as it will be of great concern for its users. In the remainder of this paper we give an overview of the idea and the architecture of the location service. First, Section II describes related work and Section III the basic functionality and elements of a location service. Section IV presents the general idea of our architecture, while Section V describes the main components of the service and their functionality. II. R ELATED W ORK Research on the development of a location service has been carried out mainly for location management in wireless communications [4] and for location-aware applications in mobile computing [3]. The former concentrates on the functionality necessary for locating a certain mobile phone, has a limited accuracy corresponding to the cells of the wireless network and assumes a single administrative control. Location services for mobile computing have been mostly developed for special sensor-systems (e.g. [5]) and/or applications (e.g. [6]). Leonhardt [3] discusses a general location service, defining a location model and considering security aspects, but does only present some basic ideas for a global architecture. III. BASIC F UNCTIONALITY

AND

E LEMENTS

This section describes some elements and aspects that are characteristic of the functionality of a location service and that are the basis for the design of our architecture. A. System Model The system model defines the basic elements of the location service and their relations. Objects, of which the lo-

cation service stores information about their current position, are called tracked objects. These are either users or any other type of (mobile) object, e.g. a car or an electronic book, which is equipped with or suited to have its position detected by a sensor system. One basic type of sensor system, called a positioning system, is attached to an object and determines its own position. A typical example of a positioning system is a GPS sensor. A tracking system, e.g. an Active Badge system, monitors a certain area and determines the position of the objects in it. According to the type of the positioning information, sensor systems can be classified into cellular systems (e.g. an Active Badge system), which determine that a tracked object is currently anywhere in a certain cell, and non-cellular systems like GPS, which determine the exact position of a mobile object with a certain precision. A distributed location service consists of a number of location servers, which manage the location information of the tracked objects. The location information is received from the sensor systems. To provide the functionality of the location service, the location servers cooperate by communicating over a fixed or wireless network. Mobile clients, which can be tracked objects themselves, or stationary clients query the location servers to get information about the position of the objects they are interested in using wireless communication in the first case, or a fixed network in the second one. B. Requirements for a Universal Location Service The following requirements are important for the design of a universal location service. They are different from those of related topics, like location management for wireless communications, where the resolution of the location information is limited by the size of its cells.

 





Scalability: Because of the global scope and the possibly high resolution of the location information, the service must be able to handle a large number of objects and therefore its components must scale well. Accuracy of Location Information: The location service must be able to handle the different accuracies of location information which depend on the type of sensor systems. While in some areas or for some applications a low resolution of the location information may be sufficient, the location service must be able to maintain location information with a high accuracy which can be obtained by current or future sensor systems. Flexibility/Adaptivity: As some areas will contain more objects or require a higher accuracy of the location information than others, an installation of the location service should be able to reflect this. This will also depend on the time of day, date or be subject to long term changes. The necessary reconfigurations could be done manually by assigning more location servers to special areas and by adding more sensor systems. Ideally, the location service should reconfigure automatically to changes, as much as possible. Security and Privacy: A very sensible issue when providing information about the current location of people is the security and privacy of the location information. Therefore, the service needs to provide a detailed access



control which allows a user to specify who is allowed to retrieve information about his current position and to which extend (see [3]). Fault Tolerance: As with any distributed service fault tolerance is an important design goal. The service should still be available, at least partially, if single servers or connections are down.

C. Location Model To describe the position of a mobile object, we use a simple location model which is based on geographical coordinates from the WGS84 system used by GPS [7]. Symbolic coordinates, e.g. the name of a room, will have to be mapped to the geographical coordinates of the physical location they represent (see [3]). In our location model, a position is described by the data-type Pos, that contains a single geographical coordinate. The data-type Area represents a geographical region, e.g. a circle or a polygon. Mask is an area which is not bound to any location. It specifies the outline of an arbitrary region. Each sensor system returns the positioning information as instances of the data-type

Sighting = (ObjectId  Pos  Area  (CELLULARjNONCELLULAR)  TimeStamp); where the tracked object is described by a unique identifier (ObjectId). The precision of the positioning information is given by the area in the third attribute and the type of precision in the fourth attribute. For a cellular system (CELLULAR) this is the area of the cell the tracked object is in. The position given by the second attribute is just the center of this area. For a non-cellular system (NONCELLULAR) the position of the tracked object is in the area given by the third parameter with a certain probability that is defined by an additional parameter (not shown here). In case of GPS the precision is given by an area with the probability of 95%. Other ways of describing the precision of a sighting may be necessary for different types of sensor systems. The last attribute gives the time this information was obtained. D. Interface In this subsection the functionality that the location service offers to its clients is defined by its basic interface. Many applications running on a mobile device are just interested in the location of their user, e.g. a car navigation system or a location-aware Internet browser, and rely on a local sensor system. More complex applications are aware of the position of many or all of their users (or objects). An example is the Forget-me-not system described in [8], which as an aid for human memory, automatically maintains a log of the user’s actions, annotated with the people that were present at this time. The interface of a universal location service that supports the second kind of applications is based on the two following basic queries: A location-of-object query returns the current position of a certain object; an objects-at-location query returns all objects that are currently in a certain area. Other more complex types of queries can be based on these two queries (see below). As applications in mobile computing often have to

react to changes in their environment, the location service should support the registration for specific events and send a notification whenever they occur. In particular, the interface of the location service supports the following concrete queries and events, where the data-type ObjectSelector is used to further limit the results of a request to objects of a certain type or with certain attributes. For each query, the desired accuracy (Accuracy) of the positioning information can be specified. Supported queries are:

 



locationOfObject: ObjectId  Accuracy ! Sighting Returns the current position of the object with the given identifier and accuracy (if possible) as an object of the type Sighting (see Subsection C). objectsAtLocation: Area  ObjectSelector  Accuracy ! Sighting Returns a list of the sightings for all objects which are currently located in the given area and have the specified attributes. If there is no object with the appropriate attributes in this area an empty list is returned.

nearestObject: Pos  ObjectSelector  Accuracy ! ObjectId  Sighting Returns the object with the desired attributes which is nearest to the given position. If no appropriate object can be found, the result of the query is null.

An event consists of two phases: First, the client sends a definition of the situation it is interested in to the location service. The location service then sends a notification either once or whenever a corresponding situation occurs.



 



onEnters: Area  ObjectSelector  Accuracy ! EventId notifyEnters: EventId  ObjectId Notifies the client when an object with the given attributes has entered the requested area. onLeaves: Area  ObjectSelector  Accuracy ! EventId notifyLeaves: EventId  ObjectId Similar to onEnters for objects leaving an area.

onMeeting: ObjectId  Mask  ObjectSelector  Accuracy ! EventId notifyMeeting: EventId  Sighting  Notifies the client whenever objects with the given attributes come within a certain distance of a given mobile or non-mobile object.

onGroupMeeting: Mask  ObjectSelector  Accuracy ! EventId notifyGroupMeeting: EventId  Sighting  Checks if a group of objects with the given attributes meets either in a certain area or with a maximum distance between any two objects of the group. If this happens, the area is returned together with a list of objects and their positions. IV. S TORING L OCATION I NFORMATION

As already mentioned, the location information about the tracked objects, which is obtained from the sensor systems, can be stored on one or more location servers with varying degrees of accuracy. Each of the sensor systems is

attached to one certain location server. This server maintains a primary copy of the location information for the tracked object or objects with the maximum accuracy of the sensor system. Secondary copies of this location information can be created on other servers and are updated automatically. These copies do not need to be strictly consistent. Instead, the required consistency is defined by an update policy for this copy or by the more general update policies of the servers which are involved. An update policy can e.g. specify a time interval for the updates or a desired accuracy for the secondary copy and can e.g. reflect the special function of a server and the security concerns of an object. Secondary copies are usually less accurate than primary copies but can also be used to combine the location information from more than one sensor system. They do not need to be updated from primary copies but can be also created from other secondary copies. The security policies for a copy determine who and to what extend one is allowed to query the information of this copy. For example it is possible to allow only a certain group of users to access the maximum accuracy of the copy, while all other users get the location information with a reduced accuracy. To find the location servers with copies of location information for a certain object or for objects in a certain area and with a given accuracy, the object or location register can be queried (see below). The location service combines different types of location servers. An area location server is e.g. responsible for all the objects in a certain area and is informed about the changes in the location of these objects with a given accuracy. The accuracy of the location information on a server is limited by the maximum number of position updates it can receive, which depends on the size of the area or rather on the number and mobility of the tracked objects in it. The location information can also be replicated with less accuracy on another server responsible for a larger area, thus creating hierarchical structures, like they are used in recent location management systems for wireless networks. A special kind of location server is used on a mobile device which is equipped with a positioning sensor like GPS. This local location server only stores the location information for this device. If an application is just interested in the position of its user, this server can be used without needing to communicate with other location servers. Also, the local location server is still available if the network connection is down. If there are no security concerns, the location information could by replicated on another location server, which is responsible for the area the device is currently in, to support more complex location-aware applications. V. A RCHITECTURE

OF THE U NIVERSAL S ERVICE

L OCATION

In this section the main components of our architecture for a universal location service, as shown in Figure 1, are described. A. Clients Clients of the location service are location-aware applications, which run either on a mobile or stationary computer and query the location servers about the position of certain tracked objects using the interface described above. On a

client programs

sensor systems

results, notifications

object sightings

queries, events

location service API

D. Location Register location server

lookups

updates

location register

The object register is updated by the location servers when a hand-over between two area location servers is performed or when a secondary copy is created or removed. The object register can easily be distributed across different register servers, each being responsible for a certain set of objects. Which register server has to be contacted for a certain object is stored together with its identifier. As in the Domain Name System (DNS) of the Internet the registers servers should be replicated to guarantee a certain level of fault tolerance.

lookups

updates

object register

Fig. 1: Components of the location service mobile device there will be in many cases a local positioning sensor and therefore also a local location server. Otherwise, a location server can be found through the registers (see below).

The location register is used for objects-at-location queries to find a location server that stores the location information for the tracked objects in a certain area. Given a description of the requested area and the required accuracy it returns a list of all adequate location servers. The location register is updated when an area location server becomes responsible for a certain area or when this area changes. Local location servers do not update this register. The location register is distributed hierarchically similar to the routers for geographic addressing and routing (see [9]) and each register server is again responsible for a fixed area. A query is forwarded down this tree to a child server, if the requested area is inside the area of the current register server and there is a child server whose area includes it. If the area overlaps, includes or lies outside the area of the current register server it is forwarded to its parent. Else the current register server answers the query. Again, fault tolerance of the location register can be achieved by replication register servers.

B. Location Servers and Sensor Systems VI. C ONCLUSION Whenever a sensor system determines a change in the current location of a tracked object, it sends this information to the location server it is associated to. The location server stores this information as a primary copy. If there are sightings from different sensor systems for the same tracked object, they have to be integrated by the location server. When a secondary copy of this information has been created, the server checks the consistency and update policies of this copy and sends an update message, whenever necessary. In case a new tracked object is detected, which e.g. has entered the area this location server is responsible for, a hand-over of the copy of location information is performed with the location server this information has formerly been stored at. Each location server can be queried about location information for any object or location. If it cannot answer the query itself, it consults the object or location register, respectively and forwards the query to the indicated location servers. The results of the register look-ups are then cached for subsequent queries. If a location server is not available because of failure or a high load, the client can use the registers to search for another server with a copy of the location information with maybe a higher or lower accuracy. C. Object Register For a location-of-object query the object register is consulted to find an appropriate location server, which stores a copy of the location information for the tracked object with the given identifier and which has the required accuracy. It returns a list of all location servers with adequate copies.

AND

F UTURE W ORK

In this paper an architecture of a distributed universal location service for applications in mobile computing and wireless communications has been presented. It can be used by location-aware applications as a general resource, thus expanding the scope of existing applications and making the development of new ones much easier. The service can store several copies of the location information for an object with different accuracies. These copies can be used to improve the scalability of the service by making more local copies available for applications that do not require a high accuracy. These copies can also reflect security considerations by limiting copies with a high accuracy to trusted servers while allowing copies with lower accuracy on any server. The location service is currently being implemented as part of the Nexus project [10], whose goal is the development of a generic platform for location-aware applications. We expect to have a first prototype of the location service this summer. Based on this prototype we will test different schemes for distributing secondary copies in the location service. Basic aspects of distributing location information are discussed in [11]. We will also define and compare different updating and security policies. Eventually, the service should be able to adapt to different environments and usage characteristics by dynamically creating and destroying secondary copies and by adjusting update policies. VII. R EFERENCES [1] B. Hofmann-Wellenhof, H. Lichtenegger, and J. Collins, Global Positioning System: Theory and

Practice. Springer–Verlag TELOS, 1997. [2] R. Want, A. Hopper, V. Falcao, and J. Gibbons, “The active badge location system,” ACM Transactions on Information Systems, vol. 10, no. 1, pp. 91–102, 1992. [3] U. Leonhardt, Supporting Location-Awareness in Open Distributed Systems. PhD thesis, Imperial College of Science, Technology and Medicine, University of London, 1998. [4] J. Jannink, D. Lam, N. Shivakumar, J. Widom, and D. Cox, “Efficient and flexible location management techniques for wireless communication systems,” in Proceedings of the Second ACM International Conference on Mobile Computing and Networking (MobiCom ’96), pp. 38–49, ACM Press, 1996. [5] A. Harter and A. Hopper, “A distributed location system for the active office,” IEEE-Network, vol. 8, no. 1, 1994. [6] O. Wolfson, A. P. Sistla, S. Chamberlain, and Y. Yesha, “Updating and querying databases that track mobile units,” Distributed and Parallel Databases Journal, vol. 7, no. 3, pp. 1–31, 1999. [7] “DoD World Geodetic System 1984, its definition and relationship with local geodetic systems,” Tech. Rep. 8350.2, Third Edition, National Imagery and Mapping Agency, 1997. [8] M. Lamming and M. Flynn, “Forget-me-not: Intimate computing in support of human memory,” in Proceedings of FRIEND21 ’94 International Symposium on Next Generation Human Interface, (Meguro Gajoen, Japan), pp. 125–127, 1994. [9] J. Navas and T. Imielinski, “Geocast - geographic addressing and routing,” in Proceedings of the Third Annual International Conference on Mobile Computing and Networking (MobiCom ’97), (Budapest, Hungary), pp. 66–76, ACM Press, 1997. [10] F. Hohl, U. Kubach, A. Leonhardi, M. Schwehm, and K. Rothermel, “Nexus - an open global infrastrucure for spatial-aware applications,” in Proceedings of The Fifth Annual International Conference on Mobile Computing and Networking (MobiCom ’99) (to appear), ACM Press, 1999. [11] U. Kubach, A. Leonhardi, K. Rothermel, and M. Schwehm, “Analysis of Distribution Schemes for the Management of Location Information,” Tech. Rep. TR-1999-01, Faculty of Computer Science, University of Stuttgart, 1999.