A System for Locating Mobile Terminals with Tunable Privacy

Journal of Theoretical and Applied Electronic Commerce Research, Aug 2007 by Bessler, Sandford

Each place has a name, center coordinates and a radius. Alternatively, rectangular zones can be defined. Making the continuous location space to a discrete one can lead to the extreme case in which for a certain watcher user, only two states of the target user are available for example: "in the office" and "not in the office" achieving exactly the degree of privacy a person needs for some partners or customers at work. In any case the target user is always in control of the disclosure of every single zone he has defined.

In [17] the authors foresee the formation of a tree of hierarchical location areas starting for example with a region, town, working company, office, room, etc. , and a reasoning process to define the desired accuracy, corresponding to a node in the tree; our approach is simpler: we define a linear list of locations to be disclosed to each user:

The relationship between two zones can be: a) disjoint, b) overlapping or c) contained. Only in cases b) and c) several zones may be returned by a certain coordinate pair: the overlapping case b) is considered as not intended by the user, therefore one of the zones is selected. In case c) a zone is contained in another zone (both being disclosed to an asking watcher), the place with the smallest area is selected. Containment check is very simple especially for rectangular defined zones.

Creating a new zone is a very simple user action: the current user position is stored with a predefined size (radius or rectangle) around the coordinates, and then the user enters a name to identify that location.

Comparing the semantics of location and presence information we see that they are quite different: geographical location expressed in coordinates has practically a continuous value range, whereas rich presence information (standardized by the IETF as RPID [31]) consists of several attributes, each having a discrete number of values. In our model however, through the definition of discrete zones, the location becomes similar to the rich presence attribute "location_type": it has a number of discrete values, the user defined zones. Though, we cannot completely reuse the RPID presence model because of the following reasons: it doesn't trigger a notification when the attribute "location_type" attains a certain value (corresponding to a zone in our model), and it standardizes the values of this attribute instead of leaving them to be freely defined by the user. Therefore, the protocol presented in the next section reuses parts of the SIP presence event package, but defines also new messages.

3 Location service architecture and protocol

In Fig. 1 we summarize the proposed system architecture variations. They all use a SIP overlay network and are therefore independent of the GSM/UMTS network positioning infrastructure. We will use throughout the paper the user roles defined by IETF in their presence work: watcher is the user or application that consumes location information and presentity is the entity that provides it. In Fig. 1 we distinguish between four scenarios: in a) both watcher and presentity are user terminals; in b) the watcher is an application, but the underlying protocol is still SIP; in case c), the location function is mediated by a so called service enabler that serves several terminals and exposes a web service interface such as Parlay X [21] to 3rd party applications, whereas case d) is using a server component to reduce the radio traffic (see section 3.3). The servers in cases c) and d) may provide network-based positioning in case the localized terminal is not equipped with a GPS receiver or cannot temporarily receive GPS information from satellites. The use of a geographical information system (GIS) server as discussed in section 3.1 and 3.2 arises when applications define the zones instead of the presentity