Mobile Networks and Applications 3 (1998) 157–173
`
`157
`
`Location-aware mobile applications based on directory services
`
`Henning Maass
`Philips Research Laboratories, 52066 Aachen, Germany
`
`Location-aware applications are becoming increasingly attractive due to the widespread dissemination of wireless networks and
`the emergence of small and cheap locating technologies. We developed a location information server that simplifies and speeds up
`the development of these applications by offering a set of generic location retrieval and notification services to the application. The
`data model and the access protocols of these services are based on the X.500 directory service and the lightweight directory access
`protocol LDAP since these are becoming the standard attribute-value-pair retrieval mechanisms for Internet and Intranet environments.
`This approach establishes a smooth migration path from conventional to location-aware applications. The paper presents the location
`information server concepts, defines its directory data model and access services, and discusses the implementation options of the loca-
`tion information server.
`
`1. Introduction
`
`With the increasing popularity of mobile communica-
`tions and mobile computing, the demand for location-aware
`and adaptive applications grows. Location-aware applica-
`tions exploit knowledge about the physical location of real-
`world objects such as mobile persons and devices, to adapt
`their functional behaviour and their appearance towards the
`user. The economic deployment of location-aware applica-
`tions will very soon become possible due to the progress
`in miniaturisation and the resulting cost reduction of locat-
`ing technologies such as GPS [5]. Furthermore, the next
`generation wireless multimedia networks will utilise such
`high radio frequencies or even infrared links that the radio
`cells will be limited to the size of a room. This will allow
`to retrieve location information from the wireless network
`mobility management functions without additional costs.
`To enable the fast and efficient development of location-
`aware and adaptive applications, we are developing a so-
`phisticated location information server (LIS) based on di-
`rectory data models and services that is presented in this
`paper1. In addition to earlier work on location-aware appli-
`cations ([11,20,23]) our approach treats location-awareness
`not as an isolated class of applications but conceptually inte-
`grates them into a generalised framework for mobile multi-
`media communication services. Consequently, the location
`information server is integrated part of a software platform
`for mobile multimedia applications2 and interacts with the
`other platform support functions and mobility management
`services. The platform shields the applications from the
`distribution and heterogeneity of the underlying commu-
`nication networks and locating infrastructures and offers a
`set of sophisticated support functions and high-level APIs
`to the application programmers. In multisite corporate net-
`
`1 This paper is a revised and extended version of a conference paper
`presented at MobiCom ’97 [14].
`2 The work this paper is based on is being supported by the German Fed-
`eral Minister of Education, Science, Research and Technology (BMBF)
`as part of the project line ATMmobil.
`
`(cid:211) Baltzer Science Publishers BV
`
`works the platform can be distributed over several mobility
`management domains, allowing the APIs and support func-
`tions to co-operate via directory service based signalling
`protocols as depicted in figure 1.
`The support functions of the mobile application platform
`offer three different location abstraction levels:
`• Location-transparent:
`This abstraction level completely hides the effects of
`mobility to applications and users. Network services
`and resources can be transparently accessed by means
`of a resource and service broker function that maps the
`application’s service type requests on adequate service
`provider instances. Additionally an application-defined
`quality-of-service (QoS) for the underlying network con-
`nections is sustained through a QoS manager func-
`tion. Applications operating on this abstraction level
`are thereby given higher priorities than others in case of
`conflicting resource requirements or wireless network
`congestion.
`• Location-tolerant:
`This abstraction-level allows applications and users to
`tolerate those effects of mobility that can not be hidden
`by the platform. Reasons can be congestion of radio
`cells, degradation of radio link qualities or change of
`terminals in case of user mobility. The trader function
`allows the application to perform a service and service
`type re-negotiation to achieve a graceful service degra-
`dation instead of dumb service termination. A profile
`handler function allows to retrieve user and terminal
`characteristics to perform application adaptation accord-
`ing to the type of terminal currently being used.
`• Location-aware:
`This abstraction-level allows applications and users to
`be aware of their mobility and the absolute and relative
`physical positions of real-world objects. Applications
`can exploit this information for customising their func-
`tionality and users can benefit from this information for
`
`GOOGLE 1009
`Page 1
`
`

`
`158
`
`H. Maass / Location-aware mobile applications based on directory services
`
`Figure 1. Platform for mobile and location-aware multimedia applications.
`
`Figure 2. Location information server in mobile application platform.
`
`navigation purposes. This abstraction level is realised
`by the location information server function that allows
`applications to query location information and to be no-
`tified about the occurrence of predefined location-related
`events.
`
`For remote invocations of the location information server
`– used when application and platform run on different ma-
`chines – the APIs communicate with the platform through a
`suite of mobile application platform access protocols based
`on the widely accepted directory access protocol DAP [10]
`and lightweight directory access protocol LDAP [17]. This
`has the key advantage that the application programmers can
`employ off-the-shelf DAP and LDAP APIs that are widely
`available on numerous platforms [7,18,24]. Therefore no
`proprietary communication protocol stacks have to be de-
`veloped, neither for the application, nor for the location
`information server. Additionally, since many networked
`applications need the directory access protocols anyway,
`the additional effort for the location-aware features of the
`application is minimised and a smooth migration path from
`conventional to location-aware applications is established.
`The location information server acquires information
`about the – absolute or relative – physical location of real-
`world objects in which an application is interested. The
`
`LIS hides from the application which locating technology
`is actually used by presenting it a generic locating model.
`The LIS has map and relationship knowledge to translate
`the low-level position information from the locating in-
`frastructures into location information having a meaningful
`abstraction level for the application. The application can
`query the LIS about current locations of objects (LIS di-
`rectory database) or can request to be notified when certain
`location-related conditions between objects and locations
`are fulfilled (LIS event handler). Other support functions
`of the mobile application platform can internally access the
`LIS functionality too and vice versa, see figure 2.
`
`2. Motivation for X.500-based approach
`
`Usually, the location information server and the location-
`aware applications will run on different machines. The ap-
`plications may, e.g., run on mobile laptops, cordless com-
`munication terminals, and stationary PCs, whereas the LIS
`will usually run on a network server being interfaced to the
`physical locating infrastructure. Therefore the communica-
`tion protocol between server and application must be able
`to bridge the gap between computing platforms of many
`
`GOOGLE 1009
`Page 2
`
`

`
`H. Maass / Location-aware mobile applications based on directory services
`
`159
`
`different types which makes the choice of standardised pro-
`tocols preferable due to their widespread availability.
`The X.500 directory access protocols have recently been
`accepted as a standard means for accessing attribute-value-
`pair information from several types of servers, especially in
`the area of the Inter- and Intranets, the Intelligent Network,
`and modern mobile communication networks:
`• The lightweight directory access protocol LDAP has
`been accepted as de-facto standard Internet directory ac-
`cess protocol [12]. LDAP has helped to promote X.500
`directory services in the Internet since it is based on
`TCP/IP and can be implemented much easier than the
`original OSI transport service-based DAP protocol.
`• Manufacturers of networking technology have begun to
`integrate LDAP into their products. Netscape’s Inter-
`net browser uses LDAP to access directories, in the
`near future all
`their client and server products will
`use LDAP for any attribute-value-pair information ac-
`cess [16]. Even the clients will eventually contain low-
`end LDAP servers to replicate information. Novell an-
`nounced that they would integrate LDAP access into
`their Novell Directory Services NDS.
`• New features are currently being added to the directory
`standards to better cope with dynamic information, e.g.,
`by controlling the lifetime of directory entries and sup-
`porting automatic deletion of entries [25]. This will turn
`directories from the providers of static information they
`are today into information brokers between all kinds of
`servers and applications.
`• Microsoft’s Internet conferencing tool NetMeeting [15]
`uses LDAP to exchange user profile information about
`users wishing to join conferences. It can be expected
`that other Internet applications will follow this approach
`too. Networked applications in the Inter/Intranet envi-
`ronment will therefore most probably have LDAP al-
`ready built-in soon.
`• The directory access protocol DAP has been agreed as
`interface between service control functions (SCF) and
`service data(-base) functions (SDF) in the Intelligent
`Network (IN) standards [2]. These standards are rele-
`vant for applications that want to perform service control
`over telecommunication networks, e.g., PBXs.
`• X.500-compatible services are used to store and access
`mobility management data for public and private mobile
`communication networks, e.g., in the third generation
`mobile networks UMTS [1], in the Japanese Personal
`Handyphone System PHS [21], and in private telecom-
`munication networks [13]. These standards are relevant
`for applications that want to extend the mobility man-
`agement functionality of mobile networks with location-
`aware features.
`
`For these reasons it seemed wise to base the location
`information server protocols on the widely accepted LDAP
`protocol with the option to alternatively use the DAP. The
`
`location information server therefore offers the following
`service model to location-aware applications:
`• All LIS data that shall be made available to the applica-
`tion is represented by the location information server in
`an X.500-conformant directory information tree (DIT).
`• Applications access the location information server
`through the standardised directory access protocols
`LDAP or DAP for local and for remote operations.
`• Application programmers employ standardised and
`widely available APIs for DAP [24] and LDAP [18]
`to communicate with the LIS.
`• Other support functions of the mobile application plat-
`form and remote LIS servers in other parts of the net-
`work can access the LIS functionality through the Di-
`rectory System Protocol DSP or through LDAP.
`• To make use of the LIS, the application and other sup-
`port functions must have knowledge about the directory
`schema of the LIS, and has to know which directory
`services implement the desired locating functionality, in
`which sequence they have to be invoked, and which
`parameters have to be conveyed to the LIS.
`• The LIS has to implement functionality normally offered
`by an X.500 directory system agent (DSA) to implement
`the required parts of the X.500 service model and pro-
`tocols. Additionally it has to interface to the physical
`locating infrastructures and has to process the data re-
`ceived from them to represent it in the DIT.
`
`Whether this service model should be implemented from
`scratch into the location information server or whether ex-
`isting directory servers should be extended with the LIS
`functionality will be discussed in section 8.
`
`3. LIS concepts and requirements
`
`The location information server shall be able to hide
`the actually used locating technology from the application,
`therefore a generic locating model has been defined (see
`also figure 3): The location information server locates ob-
`jects representing either persons or resources inside areas.
`To make objects automatically locatable, they have a tag
`attached to them that identifies and localises its wearer. Re-
`sources serving as a tag can be for example badges, cordless
`phones, PDAs or laptops. The relations between objects
`and tags are maintained in the LIS. A locator forms the
`interface between the locating infrastructure and the LIS.
`The following locating principles can be used for tags:
`• The tag is located relative to areas by means of a sensor
`installed in that area. This information is then collected
`by the locator and published to the LIS. The LIS then
`uses a map to translate sensor identifiers into area iden-
`tifiers.
`• The tag can determine its absolute geographical posi-
`tion and publishes this information through the locator
`
`GOOGLE 1009
`Page 3
`
`

`
`160
`
`H. Maass / Location-aware mobile applications based on directory services
`
`Figure 3. Generic locating model.
`
`to the LIS. By means of a map the LIS translates the
`geographical position into an area-identifier.
`
`For navigation applications the LIS may additionally
`provide graphical map information in human-readable for-
`mat and may calculate shortest paths between areas. Ad-
`ditionally the LIS may find objects that are nearest to a
`specified area and fulfil certain conditions. All entities
`of the locating system have a unique identifier, i.e., tag-
`ID, sensor-ID, object-ID, or area-ID. The network site in
`which a mobile object is located is identified by a mobility
`management domain identifier mmd-ID.
`
`3.1. Locating technologies
`
`This section briefly describes locating technologies that
`can be used to implement the locating infrastructures for
`real-world objects:
`• Dedicated locating infrastructure:
`The tag is a special locatable device. The areas of the lo-
`cating infrastructure are equipped with sensors that can
`detect the presence of the device. This approach can
`for example be realised based on an Active Badge Sys-
`tem [4,22]. The tags are credit card-sized badges that
`communicate with the sensors via infrared light. This
`system is limited to indoor usage and the locating area
`normally equals a room. Another example for infrared-
`based tags are the palm-sized ParcTabs [23]. Radio-
`based tag detection techniques are also available, e.g.,
`in contactless smart cards operating at distances of up
`to one meter.
`• Wireless network infrastucture:
`The tag is the terminal of a wireless communication net-
`work. In this approach, the radio cells of the wireless
`
`communication network serve as sensors and produce
`information where the mobile terminal is located. The
`information can be retrieved from the network’s mobil-
`ity management function. This approach is applicable
`in indoor and outdoor environments and is appealing
`since no additional infrastructure has to be deployed in
`environments where mobile devices are using wireless
`communications anyway.
`• Absolute positioning techniques:
`The tag contains a GPS receiver [5] which is used to
`calculate its absolute position. It then uses a geograph-
`ical map stored either in the tag itself or in the locating
`server to determine the area the object is in. This ap-
`proach is currently limited to outdoor environments but
`GPS relay senders for indoor usage are under develop-
`ment.
`
`3.2. Application requirements on the location information
`server
`
`This section discusses the functionality that an applica-
`tion requires from the locating infrastructure and the loca-
`tion information server. In these examples, an area usually
`corresponds to a locating granularity being obvious to hu-
`mans, e.g., a room or a floor and the locatable objects are
`persons or pieces of equipment.
`
`3.2.1. Location retrieval services
`An application may be interested in the whereabouts of
`objects that carry a tag to automatically determine their
`physical location but it also may be interested in the location
`of static objects or mobile objects having no tag. Therefore,
`the location information server must also be able to handle
`locatable objects without tags by storing their location in-
`
`GOOGLE 1009
`Page 4
`
`

`
`H. Maass / Location-aware mobile applications based on directory services
`
`161
`
`ternally and offering retrieval and location update services.
`Typical location retrieval requirements of location-aware
`applications are for example:
`• In which area is person A (and when was the last sight-
`ing)?
`• How many or which persons are present in area B?
`• Where is equipment C (e.g., an apparatus in a hospital)?
`
`the internal operation of the LIS, for other support func-
`tions of the mobile application platform, and for location-
`aware applications operating on the tag-level, bi-directional
`mapping services between the identifiers of areas, sensors,
`and positions are required. These mappings are determined
`upon installation of the locating infrastructure and are there-
`fore not only required by the LIS and the applications, but
`also by the system administrator.
`
`3.2.2. Location-dependent object and area selection
`services
`Location-aware applications sometimes do not want to
`know the location of a certain object instance but want to
`know which persons or resources of a certain type (e.g.,
`printer, doctor) are present in or nearest to a given area:
`• Which object of type D is present in area B?
`• Which one is the nearest object of type D (relative to
`my own location) and where it is located?
`• Which (nearest) area fulfils certain conditions (e.g.,
`which one is the nearest unoccupied meeting room)?
`
`3.2.3. Event services
`To avoid repeatedly polling the LIS, some location-
`aware applications want to be informed by the location
`information server when an application-defined event oc-
`curs. This functionality is, e.g., needed to start a function
`on a mobile device as soon as it’s wearer enters a certain
`area or to inform a user that a colleague he wants to visit
`is now present in his office. Examples of events are:
`• Inform me when person A enters (or leaves) area B!
`• Inform me when area B is empty!
`• Inform me next time person A meets person B any-
`where!
`
`The event services of the LIS shall consist of two parts:
`They shall consist of a registration part in which an appli-
`cation expresses its interest in a certain event. When the
`specified event finally occurs, the application shall receive
`a notification denoting the occurred event.
`Important for
`applications on mobile terminals is that notifications do not
`become lost in situations where the application is temporar-
`ily disconnected from the LIS.
`
`3.2.4. Map retrieval services
`Location-aware systems often offer a navigation applica-
`tion to help human users in finding other persons, resources
`or areas. For this purpose, the LIS shall offer map infor-
`mation and navigation instructions to its applications:
`• Provide me with a human-readable map of area A!
`• Provide me with the shortest path between area A and B!
`
`3.2.5. Identifier mapping services
`In the above mentioned examples, applications usually
`require information about objects and their actual areas and
`not about tags and their sensors respectively positions. For
`
`3.2.6. Relationship services
`Location-aware applications operating at tag-level in-
`stead of object-level or applications that want to commu-
`nicate with an object through its tag are often interested in
`the relation between objects and tags:
`• Which object is associated with tag A?
`• Which (if any) tag does object B possess?
`Some applications want to change these relations, e.g.,
`when persons change their terminal serving as a tag:
`• Associate tag A with object B!
`How all
`these application requirements are realised by
`means of directory services offered by the LIS to the appli-
`cation is defined in the following chapters. First the data
`model and the required directory schema are defined, then
`the necessary LIS directory service invocations the appli-
`cation has to perform are described.
`
`4. Introduction to X.500 and LDAP
`
`The X.500 set of recommendations [9] standardise a
`distributed directory service as OSI layer seven service
`and protocol. The directory service is offered by the Di-
`rectory System Agent DSA to the Directory User Agent
`DUA, representing an application or human directory user.
`The DSA offers the services listed in table 1 to access
`the directory information via the Directory Access Protocol
`DAP.
`The content of the directory is not held by a single
`DSA but may be distributed over a set of co-operating
`DSAs to enable the establishment of a world-wide global
`directory service. For this purpose, a DSA interacts with
`other DSAs through the Directory System Protocol DSP
`to hide the physical data distribution from the directory
`user.
`
`Table 1
`X.500 DAP directory services.
`
`Read
`Compare
`Search
`List
`Add
`Delete
`Modify
`ModifyRDN
`Abandon
`
`read a single entry from the directory
`compare an attribute value with a given value
`search for one or more entries in the directory
`list the subordinate entries of a directory entry
`add an entry to the directory
`delete an entry from the directory
`modify the content of an entry
`modify the last component of the entry’s name (RDN)
`cancel an outstanding directory access operation
`
`GOOGLE 1009
`Page 5
`
`

`
`162
`
`H. Maass / Location-aware mobile applications based on directory services
`
`Figure 4. X.500 directory model.
`
`Figure 5. X.500 directory information tree.
`
`Two interaction principles have been defined as depicted
`in figure 4:
`• Chaining forwards a user request to a DSA that might
`contain the desired information.
`• Referrals return a handle to the DSA that might contain
`the desired information to the DUA or DSA that is then
`responsible for following the pointer.
`
`The overall directory content, also called Directory Infor-
`mation Base DIB, is held in entries that are arranged into a
`hierarchical Directory Information Tree DIT as illustrated
`in figure 5. Each DSA stores one or more subtrees of the
`DIT. Each entry consists of a collection of attributes that
`may have one or more values. Which attributes must and
`which may be contained in a particular entry is defined by
`the entry’s object class. Typical object classes are coun-
`try, organisation, person, etc. An entry is identified by its
`globally-unique Distinguished Name DN, consisting of the
`concatenation of the Relative Distinguished Names RDN
`of all its superior entries. An RDN is a unique value dis-
`tinguishing an entry from its sister entries inside a subtree.
`The set of defined object classes and the allowed hierar-
`chical relations between their entries is called Directory
`Schema. It controls which information may be contained
`in an X.500 directory.
`Although the X.500 directory service recommendations
`are commonly accepted as standard distributed directory,
`its widespread usage was hampered by the complexity of
`the OSI upper layers and the power but also complexity of
`the X.500 model. Therefore the IETF decided to define a
`Lightweight Directory Access Protocol LDAP [17] with the
`goal to provide “90% of the X.500 functionality at 10% of
`
`Figure 6. LDAP lightweight directory access protocol.
`
`the costs” [7]. This reduction of complexity was achieved
`in the following areas:
`• Transport: LDAP operates directly on top of TCP/IP.
`• Functionality:
`redundant or little-used X.500 features
`were removed, e.g., the X.500 Read and List services
`that can be realised with the Search service.
`• Data representation: LDAP represents data mainly in
`simple strings that are much easier to handle than the
`complex X.500 data structures.
`• Encoding: LDAP uses simplified X.500 encoding rules.
`Initially, LDAP was mainly used as an access protocol
`to X.500 directory servers using LDAP-to-X.500 gateway
`servers, see figure 6.
`Meanwhile, stand-alone LDAP servers have been devel-
`oped [6] which made LDAP becoming one of the standard
`directory services in the Internet, especially in the latest
`conferencing and browser tools [15,16]. Coming versions
`of the LDAP standards will incorporate distribution mech-
`anisms based on the X.500 referral principles, while some
`existing implementations already support this feature [6].
`
`5. X.500 data model of LIS
`
`The location information server maintains an X.500-
`conformant directory information tree that contains entries
`for all the relevant real-world objects such as persons, re-
`sources, tags, and areas. The information exchange be-
`tween the applications and the location information server
`is realised through dedicated attributes in those entries. The
`locating services are mapped on X.500 directory access ser-
`vices that retrieve and manipulate the attributes of those
`entries. In the following, the X.500 object classes used in
`the location information server are defined and examples of
`LIS information trees are presented.
`
`5.1. Directory schema for retrieval operations
`
`All entries of the LIS server are arranged in an infor-
`mation tree that has an entry of object class serverRoot as
`common root, see table 2.
`In the application’s initialisa-
`
`GOOGLE 1009
`Page 6
`
`

`
`H. Maass / Location-aware mobile applications based on directory services
`
`163
`
`tion phase, the distinguished name DN of this serverRoot
`entry is determined and henceforth used as base object for
`the application’s LIS operations. The attribute serverName
`must be set to “LIS” so that the application can distinguish
`the root object of the LIS from root objects of other sup-
`port functions. The serverName value forms the relative
`distinguished name RDN of this entry.
`Below the serverRoot entry, subtrees for the different
`kinds of LIS information are maintained. Each subtree has
`an entry LISdataRoot as root entry which is used as base
`object for the retrieval operations, see table 3 and figure 7.
`The arrangement into separate trees was chosen for conve-
`nience of the application developers, but other arrangements
`are possible too.
`
`Table 2
`Object class definition of serverRoot.
`
`serverRoot::
`OBJECT-CLASS SUBCLASS OF top
`MUST CONTAIN {
`serverName }
`// name of location information server,
`// RDN of this entry
`MAY CONTAIN {
`description }
`
`// plain text description for human users
`
`Table 3
`Object class definition of LISdataRoot.
`
`LISdataRoot::
`OBJECT-CLASS SUBCLASS OF top
`MUST CONTAIN {
`rootName }
`MAY CONTAIN {
`description }
`
`// name of entry according to type of
`// information below it, entry DN
`
`// plain text description for human users
`
`Areas of the locating infrastructure are represented in the
`LIS information tree with entries of object class LISarea,
`see table 4. This entry contains information about present
`(static and mobile) objects and tags, about infrastructure in
`this area (e.g., telephone sets), and it describes configura-
`tion knowledge such as present locating system sensors and
`the geographical position range covered by the area. The
`positionRange attribute has a special matching rule “con-
`tains” associated with it. This matching rule allows to de-
`termine whether a given physical position is contained in
`the positionRange attribute value. It is used by the LIS to
`map a position determined by the LIS locator onto an area
`identifier to be returned to the application. The matching
`rule is not offered by conventional X.500 directories, it is
`a private matching rule extension (being explicitly allowed
`in the X.500 recommendations).
`Static and mobile objects of the location information
`server are modelled with entries of object class LISob-
`ject defined in table 5. This entry contains an attribute
`currentArea that denotes the object’s current location to-
`gether with the attribute currentMmd that identifies its cur-
`
`Table 4
`Object class definition of LISarea.
`
`LISarea::
`OBJECT-CLASS SUBCLASS OF top
`MUST CONTAIN {
`areaID }
`// area identifier is used as RDN of this entry
`MAY CONTAIN {
`presentObject,
`// ids of present objects, read-only, multi-valued
`presentTag,
`// identifiers of detected tags, read-only, multi-value
`installedSensor,
`// configuration knowledge, read-only, single-value
`positionRange,
`// range of co-ordinates that are covered by area
`description }
`// plain text description for human users
`
`Figure 7. LIS directory information tree for retrieval operations.
`
`GOOGLE 1009
`Page 7
`
`

`
`164
`
`H. Maass / Location-aware mobile applications based on directory services
`
`Table 5
`Object class definition of LISobject.
`
`Table 6
`Object class definition of LIStag.
`
`LISobject::
`OBJECT-CLASS SUBCLASS OF top
`MUST CONTAIN {
`objectId,
`currentMmd,
`
`currentArea,
`lastSighting }
`MAY CONTAIN {
`attachedTag,
`description }
`
`// object identifier is used as RDN of this entry
`// identifier of mobility management domain
`// the object is located in
`// identifier of area the object is located in,
`// read-only for mobile object
`// time of last sighting, read-only
`
`// identifier of attached tag, if object is mobile
`// plain text description for human users,
`// e.g., name of person
`
`LIStag::
`OBJECT-CLASS SUBCLASS OF top
`MUST CONTAIN {
`tagId,
`currentMmd,
`
`currentArea,
`lastSighting }
`MAY CONTAIN {
`currentSensor,
`
`currentPosition,
`description }
`
`// tag identifier is used as RDN of this entry
`// identifier of mobility management domain
`// the tag is located in
`// id of area the tag is located in, read-only
`// time of last sighting, read-only
`
`// identifier of sensor that has located this tag,
`// read-only
`// co-ordinates of tag as determined by locator,
`// read-only
`// plain text description for human users,
`// e.g., type of tag technology
`
`rent mobility management domain. For static objects these
`attributes have a read/write value to be updated by the ap-
`plication, for mobile objects currentArea has a read-only
`value that is determined by the locating system.
`In this
`case currentMmd is updated by a roaming service when the
`object enters a new mobility management domain. If the
`entry describes a mobile object it has an attribute attached-
`Tag that contains the identifier of the object’s tag. The
`attributes currentArea and areaId have a special matching
`rule “is-nearest-to” associated with them. When an appli-
`cation presents an area identifier and requests the LIS server
`to perform this match, the LIS server will determine that
`object or area that is physically nearest to the given area
`identifier.
`This non-standard matching rule is completely different
`from other directory matching rules since it does not result
`in a true or false value for a single entry but searches for a
`minimal value (i.e., physical proximity) for all entries that
`fulfil the selection criteria. This new feature significantly
`increases the power of our extended directory service. It
`offers a selection functionality at the server side that previ-
`ously could only be offered with a trader [8].
`The object class LIStag defined in table 6 specifies the
`attributes that are contained in entries describing the prop-
`erties of LIS tags. The read-only attributes currentArea and
`lastSighting contain the tag’s current location and its time
`of last sighting being determined by the locating infrastruc-
`ture. Depending on the locating technology, the entry con-
`tains either a currentSensor attribute or a currentPosition
`attribute, both are read-only too.
`For navigation applications the LIS information tree con-
`tains entries of object class LISmap as defined in table 7
`that contain graphical pictures about maps and paths be-
`tween areas. The attribute coveredArea contains the identi-
`fiers of all areas that are covered by the map picture. The
`attribute graphicalPath contains a graphical picture of the
`shortest path between all areas that an application requests
`to be covered in the retrieval query. For maps covering
`a large number of areas, this path picture should be cal-
`culated on demand by the LIS or an external map server
`in order to reduce the storage amount for all possible path
`combinations.
`
`Table 7
`Object class definition of LISmap.
`
`LISmap::
`OBJECT-CLASS SUBCLASS OF top
`MUST CONTAIN {
`mapId,
`// map identifier used as RDN of this entry
`coveredArea,
`// identifier of