as a PDF

Open Mobility Platform based on Dynamic Directory Services
Von der Fakultät für Mathematik, Naturwissenschaften und Informatik
der Brandenburgischen Technischen Universität Cottbus
zur Erlangung des akademischen Grades
Doktor der Ingenieurwissenschaften
(Dr.-Ing.)
genehmigte Dissertation
vorgelegt von
Dipl.-Ing.
Henning Maaß
geboren am 05.06.1964 in Bad Oldesloe
Gutachter: Prof. Dr.-Ing. Rolf Kraemer
Gutachter: Prof. Dr.-Ing. Klaus-Rüdiger Fellbaum
Gutachter: Prof. Dr.-Ing. Klaus David
Tag der mündlichen Prüfung: 18.10.2001
Page ii
Acknowledgements
This thesis is the outcome of a long and adventurous effort that consumed considerable
amounts of leisure time over the last years. I would like to thank the many people that
have encouraged and supported me in pursuing my dissertation project.
First, I thank my advisor, Prof. Rolf Kraemer, who is most responsible for helping me in the
creation of this dissertation. His encouragement and belief in my ideas provided invaluable
help over the last years. He gave me the support and motivation that I personally needed
to complete the writing of this thesis. I would also like to thank him for our joint years at
Philips Research where he headed our research department during the time I developed
the fundamental concepts of my thesis. His creativity, enthusiasm, and profound technical
insights created an atmosphere of intellectual inspiration and motivation that allowed me
to work on the fascinating research topics described herein.
I owe a great debt of thanks to Gerard Havermans, Philips Business Communications,
who provided the initial trigger for my interest in research on mobility management. He
made it possible for me to participate in ETSI standardization work on private network mobility and provided invaluable help and motivation to start my dissertation efforts. I would
like to thank Dr. Martin Elixmann for convincing me to start my professional career at Philips Research Laboratories that are a great place to work at. Martin stimulated my interest
in distributed systems and the "upper OSI layers" in general. He encouraged me to start
my dissertation project and provided continuous stimulation and mental support over several years that helped me to get through times of difficulty.
I thank my colleagues and friends at Philips Research Laboratories Aachen for providing
an inspirational working environment. I especially thank Martin Stahl, Oliver Schreyer and
Thomas Falck with whom I had the pleasure to work on mobility-related research projects
over the past eight years. Martin and Oliver built the private network mobility demonstrator
we showed at the Telecom fair in 1995, which incorporated a traditional X.500 directory
service-based database. The insights gained in those days inspired me to aim in my thesis
for a mobility platform based on functionally extended directory services. Furthermore,
parts of that demonstrator are still operational and provide the PBX and DECT communication infrastructure I have used for implementing the Open Mobility Platform prototype.
Thomas was an invaluable source of inspiration in the area of location-aware applications
and is a challenging intellectual sparring partner reinforcing me to strive for technical excellence. He also set up the Active Badge system and realised the proxy server that connects the system with the Open Mobility Platform prototype. I also thank Hans-Dieter Hinz
for his continuos support in keeping the computing infrastructure used for implementing
the LDAP-based Dynamic Directory server alive - in spite of crashing hard disks and Y2K
problems. I thank Dr. Tobias Helbig, for supporting my dissertation efforts on top of my
professional obligations and for providing valuable suggestions for improvement of the
thesis.
Page iii
I had the opportunity to advise several diploma theses and student projects that greatly
contributed to finding the right problem scope for my thesis. I thank Dieter Ahlers, who designed and built in the course of his diploma thesis the first X.500 database system we initially used for private network mobility experiments. I also thank Paul van der Cruijs, Peter
Aarts and Maurice Martin, who have worked on replication mechanisms for X.500 directory servers, which - although they are not used in this thesis - greatly improved my understanding of directory services. Thanks are also due to Prof. Dieter Hammer for being so
kind to supervise X.500-related diploma theses at the Eindhoven Technical University and
for advising me in my dissertation effort in its early stage.
I am greatly indebted to Almuth Pfleging and Marie-Louise Sester, who dared to undergo
the adventure of proofreading this thesis. They significantly improved the way the English
language is used throughout this document. I am very grateful for their precious time they
dedicated to me.
I would like to thank Prof. Klaus David and Prof. Klaus-Rüdiger Fellbaum for their kind willingness to serve as referees for my thesis.
I thank my wife, Astrid, my son, Patrick, and my daughter, Celina, for their patience, love
and support during these long last years.
Finally, I dedicate this thesis to my parents, Brigitte and Dieter Maaß, for giving me my
education culminating in this dissertation and for their unconditional love.
Page iv
Table of Contents
1. Introduction ______________________________________ 1
2. Overview on mobility _______________________________ 5
2.1 Basic mobility concepts __________________________________________5
2.2 Mobility-enabling network infrastructures____________________________7
2.2.1 Terminal mobility infrastructures ______________________________________ 7
2.2.2 User mobility infrastructures ________________________________________ 11
2.3 Mobility management ___________________________________________13
2.3.1 Mobility management in cellular phone networks ________________________ 14
2.3.2 Mobility management in computer networks ____________________________ 15
2.4 Positioning infrastructures _______________________________________17
2.4.1 Global positioning ________________________________________________ 17
2.4.2 Wide-area positioning _____________________________________________ 18
2.4.3 Campus-area positioning __________________________________________ 18
2.5 Summary______________________________________________________20
3. Problem statement ________________________________ 21
3.1 Objectives and scope ___________________________________________21
3.2 Motivation _____________________________________________________22
3.3 Related work on mobility platforms ________________________________25
3.3.1 Mobile Application Support Environment (MASE) ________________________ 25
3.3.2 Mobile Data InterChange Kit (MOBI-DICK) _____________________________ 27
3.3.3 Personal Communication Support System (PCSS) ______________________ 28
3.4 Outline of thesis ________________________________________________30
4. Support techniques enabling mobility ________________ 31
4.1 Mobility management ___________________________________________31
4.1.1
4.1.2
4.1.3
4.1.4
4.1.5
Issues in lifelong personal numbers __________________________________
Issues in location tracking __________________________________________
Mobility management approaches for cordless networks __________________
Mobility management for third-generation mobile networks ________________
Mobility management approaches for user mobility ______________________
32
34
37
38
40
4.2 Mobile applications _____________________________________________41
4.2.1
4.2.2
4.2.3
4.2.4
Support for finding and accessing services _____________________________
Support for disconnected and partially connected operation _______________
Support for migratory applications ___________________________________
Support for adaptive applications ____________________________________
41
45
47
48
Page v
4.3 Location-aware applications ______________________________________51
4.3.1
4.3.2
4.3.3
4.3.4
4.3.5
Support for single locating technologies _______________________________
Locating technology-independent support _____________________________
Support for fine-grained location information ___________________________
Support for navigation _____________________________________________
Other support ___________________________________________________
51
51
53
53
54
4.4 Analysis ______________________________________________________55
4.4.1 Mobility abstraction levels __________________________________________ 55
4.4.2 Opportunities for improving mobility support ____________________________ 57
4.5 Summary______________________________________________________58
5. LDAP/X.500 directory services ______________________ 61
5.1 Introduction ___________________________________________________61
5.2 LDAP/X.500 information model ____________________________________62
5.3 LDAP service model ____________________________________________67
5.4 Proposed LDAP Extensions ______________________________________70
5.5 Summary______________________________________________________73
6. Open Mobility Platform ____________________________ 75
6.1 Functional model _______________________________________________75
6.2 Support services _______________________________________________76
6.3 Information model ______________________________________________79
6.3.1
6.3.2
6.3.3
6.3.4
6.3.5
6.3.6
6.3.7
OMP object class model overview____________________________________ 80
OMP Framework and Subscription Framework _________________________ 83
Positioning Framework ____________________________________________ 86
Positioning Customisation __________________________________________ 90
Addressing Framework ____________________________________________ 98
Service and Terminal Customisation_________________________________ 102
Object placement model __________________________________________ 109
6.4 Realisation of OMP model with X.500 information model _____________111
6.5 Realisation of OMP support services with LDAP services ____________114
6.5.1
6.5.2
6.5.3
6.5.4
6.5.5
6.5.6
6.5.7
6.5.8
Location handling services ________________________________________
Profile handling services __________________________________________
Event handling services __________________________________________
Directory services _______________________________________________
Trading services ________________________________________________
Security services ________________________________________________
Discovery services_______________________________________________
Impact of entry placement on Open Mobility Platform functionality _________
115
120
121
124
124
125
126
127
6.6 Summary_____________________________________________________127
Page vi
7. Dynamic Directory Services _______________________ 131
7.1 Internally derived attributes _____________________________________132
7.1.1
7.1.2
7.1.3
7.1.4
Information model _______________________________________________
Directory data consistency ________________________________________
Operational model _______________________________________________
OMP example __________________________________________________
132
137
139
143
7.2 Externally derived attributes _____________________________________143
7.2.1
7.2.2
7.2.3
7.2.4
7.2.5
Information model _______________________________________________
External access protocols _________________________________________
Directory data consistency ________________________________________
Operational model _______________________________________________
OMP example __________________________________________________
145
147
150
152
153
7.3 Event handling ________________________________________________154
7.3.1
7.3.2
7.3.3
7.3.4
7.3.5
7.3.6
7.3.7
Design options __________________________________________________
Dynamic Directory event handling overview ___________________________
Information model _______________________________________________
Event triggers __________________________________________________
Directory data consistency ________________________________________
Operational model _______________________________________________
OMP example __________________________________________________
155
157
160
175
186
187
192
7.4 New matching rules ____________________________________________195
7.4.1 Spatial matching ________________________________________________ 195
7.4.2 Nearest matching _______________________________________________ 198
7.4.3 Configurable matching ___________________________________________ 203
7.5 Exported attributes ____________________________________________205
7.5.1 Information model _______________________________________________ 205
7.5.2 Operational model _______________________________________________ 207
7.5.3 OMP example __________________________________________________ 207
7.6 Supportive directory extensions _________________________________208
7.6.1
7.6.2
7.6.3
7.6.4
Soft entries ____________________________________________________
Entry templates _________________________________________________
Abstract attributes _______________________________________________
Entry content control _____________________________________________
208
210
212
213
7.7 System schema overview _______________________________________214
7.8 Summary_____________________________________________________215
8. Implementation __________________________________ 217
8.1 Dynamic Directory Services _____________________________________217
8.1.1
8.1.2
8.1.3
8.1.4
Conventional directory server architecture ____________________________
Dynamic Directory server architecture _______________________________
Dynamic Entry layer _____________________________________________
Dynamic Directory server prototype _________________________________
217
219
222
233
Page vii
8.2 Open Mobility Platform _________________________________________234
8.3 Summary_____________________________________________________237
9. Discussion _____________________________________ 239
9.1 Concept discussion ____________________________________________239
9.2 Scaleability evaluation__________________________________________241
9.2.1 Memory limits __________________________________________________ 242
9.2.2 Performance limits_______________________________________________ 244
9.3 Summary_____________________________________________________250
10. Other Dynamic Directory applications _______________ 251
11. Summary and outlook ____________________________ 255
Abbreviations ______________________________________ 261
References ________________________________________ 263
A. Appendix: Summary of UML syntax _________________ 279
B. Appendix: OMP information tree example ____________ 283
C. Appendix: Introduction to Augmented BNF and
LDAP BNF ______________________________________ 285
D. Appendix: Dynamic Directory Schema ______________ 287
E. Appendix: Attribute derivation algorithms ___________ 293
F. Appendix: Scaleability calculations _________________ 295
Page viii
Introduction
Over the past decade, wireless networking technology has introduced fundamental
changes to the way people make use of communication and computer networks. The slogan anytime - anywhere is commonly used to illustrate the fact that virtually any place on
our planet is covered by one or more wireless network infrastructures, enabling people to
communicate with each other whenever and from wherever they want. Network operators
are willing to pay exorbitant amounts of money for an additional radio spectrum to have at
their disposal services that are still more advanced (e.g. mobile video conferencing) and
thereby gaining a competitive edge over other operators. At the same time, the continuing
miniaturisation and increasing functionality of microelectronics has fostered the emergence of powerful portable devices offering sophisticated applications, such as navigation
systems or document processing. Combining such devices with wireless network access
allows people not only to communicate with other humans; it also enables mobile access
to the Internet and the execution of networked applications, e.g. mobile access to corporate databases or m-commerce applications. The latest novelty is the emergence of socalled location-aware services that exploit knowledge of the spatial position of a mobile user
that is obtained from communication networks or from dedicated positioning infrastructures. These applications offer for instance position-dependent information - e.g. informing
about special offers of nearby shops - or navigation services - e.g. telling where to find the
nearest Italian restaurant.
In contrast to wide-area wireless networking coverage, which has become adequately
available, the systematic deployment of indoor and campus-area networking coverage has
only recently become feasible with the progress reached in wireless LAN technology and
standardisation. Studies in the US and in Europe reveal, however, that the mobility of the
professional workforce is restricted to the campus-area environment for more than 50% of
their working time. Additionally, new applications and services may evolve much faster in
these environments than in wide-area networks. This is so because the services do not
have to be deployed on a global scale, specific applications for closed user groups may be
introduced, and because the needs and requirements of local users are better understood.
The aim of this thesis is the development of an Open Mobility Platform (OMP) that supports the development of mobile and location-aware applications in campus-area and
multi-site environments. Mobility management services are special applications that belong to a network and enable mobility of users and terminals. Since these services have
similar functional requirements as mobile and location-aware applications, the Open Mobility Platform should be able to support them, too. The platform shall have a set of mobility support services that offer sophisticated functionality to increase the programmer's productivity and to allow more easily the sharing of a homogeneous model of the real-world
between applications. The platform will shield the application programmer from the complexity and heterogeneity of the underlying network and positioning technologies and shall
support homogeneous management and access control mechanisms.
Page 1
The main architectural approach underlying this work is to base the Open Mobility Platform on a directory service model. Access to and distribution of the mobility platform functionality shall be realised with standards-compliant directory access protocols that allow
the use of existing APIs and protocol stacks in the applications. We first develop an information and functional model of the Open Mobility Platform, which is then realised based
on X.500 and LDAP directory service models. From this we identify the functionality missing in the current directory standards and develop an extended set of directory services
called Dynamic Directory Services (DDS). We propose a layered server architecture that
allows the realisation of the new Dynamic Directory features based on conventional directory server implementations. The Open Mobility Platform may then be realised with a Dynamic Directory server and a directory schema definition that conforms to the Open Mobility Platform information model.
The Open Mobility Platform is open not because it uses standardised access protocols
and services only. Additionally, it is highly adaptable to the needs of a particular application environment. This is necessary since the user requirements will vary considerably between different campus environments and will evolve over time. Also, new technologies
will continue to emerge at an enormous pace. Therefore, the functionality of the Open
Mobility Platform must be easily customisable by network operators and application developers concerning its information model and support functionality. The new Dynamic Directory features are primarily required to support mobility, but we specify them as generic extensions not being limited to the mobility application domain. Several other directoryenabled applications will benefit from the new directory service model. By defining additional Dynamic Directory schemas, application platforms for other application domains
may be easily derived. This extends the relevance of our work from mobility applications to
all flavours of networked applications requiring shared access to dynamic information.
The next chapter introduces the basic concepts of mobility and briefly presents the most
important infrastructure technologies that allow to realise mobility of terminals and users.
Chapter 0 formulates the problem statement underlying this thesis defining its scope and
objectives, and confirms the relevance of our research. Then, it introduces related research done by others on developing mobility platforms. The Open Mobility Platform shall
offer a set of support services to mobile applications; to this end, we study in chapter 0 the
state-of-the-art in mobility support techniques to identify which techniques should be supported by our platform. We summarise the proposed techniques by defining a framework
consisting of four mobility abstraction levels that may be used to categorise the requirements on mobility support and associate them with relevant support techniques. Since our
aim is to realise the Open Mobility Platform based on enhanced directory services, we introduce in chapter 0 the status and proposed extensions of the X.500 and LDAP directory
services standardised by ITU-T and IETF. They form the basis of the Dynamic Directory
Services specifications developed in the remaining parts of the document.
Chapter 0 describes the Open Mobility Platform in detail. First, the functional scope and
the overall functional model are defined; then, the information model is formally specified
by means of the Unified Modelling Language (UML). All object classes and attributes defining the OMP information model are characterised and explained with several application
examples from the mobility domain. After the OMP model is defined, the realisation of the
Page 2
information model and support services based on X.500/LDAP information models and
LDAP services is discussed. This discussion reveals which of the existing X.500 and
LDAP concepts may be applied to realise the Open Mobility Platform and which concepts
have to be additionally provided by the Dynamic Directory Services. A specification of the
Dynamic Directory Services that cover all of the identified new features is presented in
chapter 0. For each new directory capability it discusses major design options and their
applicability. It defines an extended information model containing new object classes and
attributes, defines the interaction of a Dynamic Directory server with its clients, and presents examples that apply the new directory features in the context of the Open Mobility
Platform.
How Dynamic Directory Services may be realised with a layered architecture that extends
existing directory server architectures is presented in chapter 0. Additionally, design issues
and options for realising this architecture as part of the development of a Dynamic Directory server prototype are discussed, and an Open Mobility Platform prototype realised on
that server is introduced. The functionality of the Open Mobility Platform and its scaleability concerning the number of users that may be supported depending on the number of
Dynamic Directory servers are evaluated in chapter 0. Further applications of the Dynamic
Directory Services beyond the scope of mobility support are presented in chapter 0. The
last chapter finally summarises the results of this thesis and provides an outlook for interesting future research issues. A graphical overview on this thesis is shown in Figure 1.
Page 3
Chapter 1
Introduction
Chapter 2
Mobility overview
Chapter 3
Problem statement
Chapter 4
Support techniques
enabling mobility
Chapter 5
LDAP/X.500
directory services
OMP
functional model
OMP
support services
OMP information
model based
on X.500
OMP
information model
OMP support
services
based on LDAP
Chapter 6
Open Mobility Platform
Requirements on
Dynamic Directory
Services
Chapter 7
Dynamic Directory Services
Internally
derived
attributes
Externally
derived
attributes
Event handling
New
matching rules
Exported
attributes
Supportive
extensions
Chapter 8
Implementation
Conventional
directory server
architecture
Dynamic Directory
server architecture
Chapter 9
Discussion
Dynamic Entry
layer
design issues
Dynamic Directory
server prototype
Chapter 10
Other
Dynamic Directory
applications
Figure 1: Document map
Page 4
Open Mobility
Platform
Chapter 11
Summary and
outlook
Overview on mobility
The advent of powerful hardware for portable communication and computing devices coupled with the continuing progress in wireless network technology are the prerequisites for
the introduction of mobility into telecommunication and computer networks. Mobility enables users to change their physical location within a network's coverage area and still access the network and its services and receive incoming connection requests.
This chapter introduces the terminology and basic concepts of mobility required for the
development of an Open Mobility Platform. It provides a brief overview on the networking
and positioning technologies that enable mobility; and it introduces the fundamental issues
of mobility management and their solution in today's computer and telecommunication
networks.
1.1 Basic mobility concepts
Two primary mobility concepts must be distinguished, namely terminal mobility and user
mobility [Jabbari95]. Terminal mobility is based on wireless networks, allowing a terminal to
initiate, receive, and maintain connections to other terminals independent of its current location. The terminal has associated with it a terminal number, just like conventional wired
terminals, that is used to identify the terminal on connection set-up. In contrast to wired
terminals, mobile terminals have no fixed address that may be used for routing connections to it. Therefore, the wireless network must perform location tracking of the mobile
terminal to determine its address dynamically. When a terminal that is engaged in a connection moves and enters the coverage area of another radio cell, a handover into the
new cell is performed transparently to the terminal's user. Another distinction between
mobile and wired terminals is the authentication of the mobile terminal that takes place at
several occasions, at least during incoming and outgoing connection requests. Only terminals having a valid subscription to the wireless network are allowed to connect to it. For
this purpose, terminal subscription parameters, also called terminal profile, must be maintained in the wireless network infrastructure to perform authentication procedures. The
ability of making use of networks other than the one being subscribed to, also called the
home network, is called roaming. It requires exchange of subscription data between networks based on mutual roaming agreements.
User mobility or personal mobility allows users to initiate and receive connections on any
fixed or mobile terminal at any time. A personal number is assigned to the mobile user,
which identifies the user independent of any terminal, and which is used as an identifier to
initiate connections to a mobile user. Ideally, the user keeps the same personal number
for his whole life. The temporary association of a mobile user with one or several terminals
is called registration and may be performed manually by the user or automatically by the
network. The network must keep track of the user's registrations to determine dynamically
Page 5
the terminal to which an incoming connection must be directed. Associated with the personal number is a set of personal subscription parameters, also called user profile, defining the user's communication privileges and preferences, and allowing the provision of
personal services. The user profile is used to authenticate the user at registration time
and to enforce the user's personal privileges and service characteristics independent of
his current terminal, seen by the user as a so-called virtual home environment. Subscription management and roaming are similar to terminal mobility. To simplify the registration
procedure for the user, subscriber identification modules (SIM) or smart cards are often
used to identify the user and perform authentication procedures. User mobility also implies
that charging for usage of different terminals and networks should be integrated into a single personal account.
The realisation of user and terminal mobility enables a further mobility concept, namely
that of mobile applications. Due to terminal mobility, applications themselves become
mobile when running on a portable device. With the emergence of powerful laptops,
handheld PCs and palm-sized PC companions, mobile terminals are no longer specialpurpose portable phone or organiser devices, but run sophisticated applications to an increasing degree. Due to user mobility, users require that their applications are available at
any terminal at which they register and want to enjoy their personal preferences and configuration parameters. Instead of installing all required applications onto every possible
terminal platform, the more favourable approach is to move applications between – fixed
or mobile – terminals in order to follow their users. Mobile applications of this type are also
called migratory applications; they recently found huge attention due to progress made in
the development of interpreted, portable code such as Java. Another concept frequently
found in the context of mobile applications is mobile agents. Several different notions of
mobile agents can be found in the literature. Two main important features of mobile
agents are, first, that agents may have control over the place to which they relocate and,
second, that agents not only move their code but also their current execution state. Mobile
agents may have a user interface to implement migratory applications, but they often are
used to improve locality of reference between co-operating services and to reduce communication traffic over the wireless link.
Mobile applications may be confronted with dramatic variations in the hosting terminal's
capabilities and in the network capabilities being available. The terminals on which migratory applications potentially run, may significantly differ from each other in their capabilities
concerning available processing power, performance of network link, input modalities, and
display capabilities. This leads to the problem that applications that work well on a powerful desktop PC - e.g. web browsers - can often not be used on a small pocket PC. A problem associated with mobile applications running on wireless terminals is that the throughput and service quality of the wireless link is subject to dramatic variations. Reasons for
this may be fading radio links caused by mobility of the terminal, and sharing of available
resources caused by mobile users entering the same radio cell. This leads to situations
where applications suffer from connection degradation so much that their continuation
does not make sense for the user. To answer these problems, the concept of adaptive
applications – meaning to be able to adapt itself to changing environments - was developed [Katz94]. In the context of volatile network characteristics the term network-robust
applications is also used [Caripe98].
Page 6
Another concept found in the mobile application context is service mobility. It characterises the ability of mobile terminals, users, and applications to not only use the services of
their home network, but also those of the currently visited network. Service mobility is often transparent to the mobile user and enforced by the infrastructure to provide services
as locally close as possible to the user's current location. This may be useful for convenience (e.g. for printing), for minimising network traffic (e.g. for video browsing) or simply for
load balancing on the network servers. The process of moving the service provisioning
from one server to another during service execution is called service handover.
A further trend that can be observed with the ongoing introduction of mobility into communication and computer networks is the emergence of location-aware applications. This
names a class of applications that exploits knowledge of the physical location of users and
devices to perform actions. In combination with user mobility, a typical location-aware application is automatic call-forwarding onto wired telephones depending on a mobile user's
current location within a building, avoiding manual registration procedures. In combination
with terminal mobility, a typical application is displaying location-dependent information,
e.g. for showing navigation information or for attaching content to the physical location in
tourist, museum, or exhibition guides. In the first case, the location-aware application itself
is not mobile but it reacts to the location of a mobile user. In the second case, the locationaware application is mobile itself and reacts to its own - more precisely its terminal's or
user's - location. In some approaches, location-awareness is treated as a special case of
situation-awareness [Katz94], context-awareness [Schilit94a], [Brown97], or environmentawareness [Beadle97], where data from additional sensors, e.g. temperature, humidity,
brightness, are taken into account by applications.
1.2 Mobility-enabling network infrastructures
This chapter provides an overview on network infrastructure technologies that enable the
realisation of terminal mobility and user mobility in telecommunication and computer networks.
1.2.1 Terminal mobility infrastructures
This section introduces available infrastructures supporting terminal mobility. It is organised based on the degree of mobility offered to terminals, classified into campus-area and
multi-site mobility, wide-area mobility, and universal mobility.
1.2.1.1 Campus-area and multi-site mobility
Campus-area mobility enables mobile terminals to move inside and between one or several buildings also called campus, while keeping their connectivity to network infrastructure. Some technologies allow the mobile terminal to move around during operation, others require the mobile terminal to be quasi-stationary. Furthermore, with the support of
mobility management services and interconnection networks, terminals are able to roam
Page 7
between campus areas, also referred to as multi-site mobility. The network infrastructures supporting campus mobility may be owned by the campus owner and being installed
and operated within the boundaries of the campus referred to as private or corporate network. However, as they may also be part of a larger network owned and operated by another party with special mobility services offered to the campus users, this is often called a
Virtual Private Network (VPN).
1.2.1.1.1 Wireless LANs
Wireless LANs (WLANs) that are deployed today mainly use 2.4 GHz RF frequency hopping or direct-sequence spread spectrum technology in the unlicensed ISM (Industrial, Scientific, and Medical) bands and are compliant with the IEEE 802.11b standard [ IEEE-802.11].
The gross bit rate offered to wireless terminals is up to 11 Mbps. Higher data rates of up to
54 Mbps and support for isochronous services will be offered by emerging IEEE802.11a
and Hiperlan/2 [ETSI-BRAN00] WLANs operating in the 5 GHz frequency range. Using even
higher radio frequencies increases the bit rates available to the user; additionally the cells
in which the capacity is shared by users become smaller. Frequencies between 17 and 60
GHz are currently being investigated. With directed antennas, the signal beams can be directed even to individual users in a room. However, this prevents the connected device
from moving quickly, since the directed links must follow it by means of an intelligent antenna. Intelligent antennas might be used in the future to connect high-speed workstations
in the office or multimedia consumer equipment at home that are quasi-stationary or link
terminals that are temporarily placed on a table for instance during a meeting.
Indoor wireless LANs using infrared signal transmission have a number of advantages
compared to RF-based technologies. One is low power consumption being important especially for mobile terminals, others include the invulnerability to interferences from electromagnetic and radio sources. Furthermore, the signals cannot escape from the building
or be jammed from outside. Directed IR beams require line-of-sight between receiver and
sender and are used for example in the IrDA technology. The advantages are considerable bit rates achieved with low-priced technology compared to 2.4 GHz LANs, but an important disadvantage is the limited mobility due to line-of-sight and narrow signal beams.
Better suited for mobile terminals are wireless LANs employing diffuse IR beams. Here,
the signal is flooded into a room similar to a light bulb and tolerates direct or reflected signal reception. The disadvantage compared to direct IR is that all users share the bandwidth available in a room. Technology for diffuse IR LANs is still in its infancy with very few
commercial offerings, but has significant potential especially for interference-sensitive environments such as hospitals.
1.2.1.1.2 Cordless PBXs
The DECT (Digital European Cordless Telecommunications) standard [ETSI-DECT99] for cordless voice and data communications has found its widespread use in residential and campus networks in Europe. DECT radios are operating in a reserved but unlicensed band at
1900 MHz and make use of the TDMA/FDMA access scheme supporting 12 two-way
voice channels. The main advantage of DECT technology compared to wireless LANs is
the ability to support voice and data connections over the same infrastructure. Additionally,
Page 8
DECT allows higher signal output power and directive antennas so that larger areas can
be covered with a single base station allowing cost-effective solutions in environments with
low mobile terminal penetration.
ETSI specified multiple DECT data access profiles that will define data services over the
DECT air interface offering bit rates of up to 552 kbps. The DECT standards define only
the access network; they do not specify protocols and mobility management functions of
the network infrastructure. Technologies that combine asynchronous WLAN protocols with
synchronous DECT protocols have been developed to allow simultaneous data and voice
communication over shared infrastructures. Examples are HomeRF [ HomeRF] intended for
home networking and Bluetooth [Bluetooth00] intended for short-range networking.
1.2.1.1.3 Pico-cellular networks
Competition to indoor cordless PBX technology is emerging from digital cellular network
equipment manufacturers. They are introducing pico-cellular systems using miniature
GSM base stations with reduced RF power transmission and simplified operation and
maintenance. These networks offer IP-based telephony and data communication services
while terminals are in the building and seamlessly switch over to cellular GSM networks
when leaving the building. Dialling numbers and services are offered as with traditional
PBX systems within the building and as with traditional cellular phones outside.
1.2.1.2 Wide-area mobility
Wide-area mobility enables a mobile terminal to be mobile at a larger scale than campus
mobility, e.g. in a city or in the country. A difference to campus-area mobility is that mobile
terminals may move with higher speed while staying able to communicate, e.g. inside a
car or a train. A distinguishing characteristic of wide-area wireless networks is that they
work in licensed frequency bands and require heavy investments by the network operator
compared to campus mobility infrastructures.
1.2.1.2.1 Paging systems
Traditional paging services offer wide-area one-way broadcast of messages to receivers
being simple and robust devices with extremely good service coverage, also within buildings, and very low power consumption offering long stand-by times with small batteries.
Paging services are well-suited for reliable messaging and emergency applications. For
use with mobile terminals PC cards for paging networks are attractive due to their low
power consumption; paging receivers have been integrated even into wristwatches. Twoway paging systems offer a return channel to confirm the receipt of a message or to send
small reply messages.
1.2.1.2.2 Digital cellular networks
Digital cellular systems, in the US called PCS (Personal Communications System), have
been widely deployed for wide-area mobile telephony services. These systems are often
referred to as 2nd-generation wireless networks (1st-generation systems were analogue
Page 9
cellular). The main standards that are in place and define the deployed systems are
GSM900/1800 (TDMA/FDMA-based) in Europe, JDC/PDC in Japan, USDC/IS-54 (TDMAbased) in USA, and IS-95 (CDMA-based) in USA. The GSM (Global System for Mobile
Communications) standard is the de-facto global standard being deployed into nearly all
regions of the world. GSM networks were continuously evolving since their initial deployment phase, called phase 1 completed by end of 1994, over a system re-design phase,
called phase 2 completed by end of 1995. The aim of the system re-design was to create
an open technological platform for future incremental evolution. The following phase 2+
[Mouly95] added many new features to the GSM, such as high-speed services and packet
data services [David97]. GSM also offers a Short Message Service (SMS) allowing to send
and receive messages of 160-character length.
Digital cellular networks offer circuit-switched data services with data rates of up to
14.4 kbps. The GSM phase 2+ standards define High-Speed Circuit-Switched Data services
(HSCSD) that combine multiple time slots in one connection and can offer data services
with up to 64 kbps. A further major improvement of GSM performance can be expected
from the GSM EDGE technology [Furuskaer99]. It adds new modulation techniques to the
GSM air interface, allowing bit rates of up to 473 kbps. To cover dense surroundings and
to serve indoor environments, DECT is being used as outdoor wireless access network
[Casademont97], also referred to as city-wide DECT. One large-scale example for this is the
Japanese Personal Handyphone System (PHS) using a digital cordless access network
[Walke97], [Murase98a].
1.2.1.2.3 Packet data networks and services
Mobitex [Salkintzis97] is the de-facto standard for packet data networks offering data rates
of up to 8 kbps. Some US operators have introduced micro-cellular data networks with
smaller coverage areas, typically metropolitan areas. These systems offer substantially increased data rates of up to 128 kbps. To reduce costs of packet data networks, one tries
to share network resources with other cellular networks. In the US, the Cellular Digital
Packet Data (CDPD) technology is based on the analogue AMPS cellular system and uses
the unused AMPS voice channels to provide bit rates of 19.2 kbps. In Europe, GSM networks are being extended with packet data services defined by GSM phase 2+ standards
as General Packet Radio Service (GPRS) [Kalden00]. GPRS offers gross bit rates of up to
178 kbps and has the advantages that no call must be set up and that multiple users
share the same channel. This potentially allows much lower service costs compared to
circuit-switched GSM data services. GPRS will also benefit from the GSM EDGE modulation technology - then called EGPRS - with bit rates of up to 384 kbps.
1.2.1.2.4 Satellite networks
Satellite networks support world-wide mobility since they do not require the presence of a
terrestrial network infrastructure. Communication is achieved through a number of satellites travelling around our planet. Satellite networks have been existing for some time but
they have had few users due to high equipment and service costs and due to the large
size and weight of the satellite phone. The new systems promise to offer handheld phones
and pagers and reasonable service fees. An intrinsic disadvantage of satellite systems is
Page 10
that they usually provide weak building-penetration so that they can be used mainly in
outdoor environments. Depending on the number of available satellites, traditional geosynchronous satellite systems require large dedicated directed antennas making the integration of satellite transceivers into mobile terminals an extremely demanding task. The
new low earth orbit (LEO) satellite systems offer several satellites in the range of a terminal simultaneously and soft handover between satellites. They are using omni-directional
and smaller antennas and thereby enable the deployment of handheld satellite devices.
1.2.1.3 Universal mobility
The third generation of mobile networks promises to offer universal mobility, enabling
communications everywhere in the world, covering indoor and outdoor environments.
They are known as UMTS (Universal Mobile Telecommunications System) and as IMT2000
(International Mobile Telecommunications 2000). The UMTS standards are being developed
by the 3GPP (Third-Generation Partnership Project) [3GPP] combining efforts from several
standardisation bodies. The UMTS Forum [UMTS-Forum99] intends to ensure a commercial
availability of UMTS technology after the year 2002. UMTS will combine a terrestrial component consisting of hierarchically arranged macro-, micro- and pico-cells with a satellite
component in order to achieve global coverage together with an excellent service quality
[daSilva97]. UMTS will offer wide-area coverage with 144 to 384 kbps and limited coverage
spots with 2 Mbps data rates for supporting mobile multimedia services.
1.2.2 User mobility infrastructures
Some of the terminal mobility infrastructures presented above already support limited
forms of user mobility, but they usually allow changing registrations only between terminals of the same mobile network. Infrastructures and services for realising ubiquitous user
mobility are presented in this chapter.
1.2.2.1 Universal Personal Telecommunication (UPT) services
Ubiquitous user mobility, allowing registrations on terminals of any fixed or mobile network,
is the aim of the Universal Personal Telecommunication (UPT) services that have been standardised by ITU-T [F.851]. The UPT service is defined in [F.851] as follows: "In the UPT environment, the fixed association between terminal and user identification is removed. In
order to offer users the capability of establishing and receiving calls on any terminal and at
any location, the identification of UPT users is treated separately from the addressing of
terminals and network access points. UPT user identification is achieved by means of a
UPT number. The UPT user is therefore personally associated with his own UPT number,
which is used as the basis for making and receiving calls. The UPT number is diallable on
a global basis and routable from any fixed or mobile terminal, across multiple networks irrespective of geographical location, limited only by the terminal and network capabilities
and any restrictions imposed by the network operator. The UPT user may be assigned
one or more UPT numbers. UPT also allows the UPT user to participate in a user-defined
set of subscribed services, from amongst which the user defines personal requirements,
to form a UPT service profile."
Page 11
1.2.2.2 The Intelligent Network (IN)
The provision of UPT in telecommunication networks requires the implementation of several new UPT features and the introduction of database functionality for storing the UPT
service profiles and the registration data of the UPT users. Since conventional PSTN and
ISDN network infrastructures were not capable of satisfying these requirements, the Intelligent Network (IN) recommendations were developed by ITU-T [Q.1201] to describe an architectural concept which is intended to be applicable to all telecommunications networks. IN
aims to ease the introduction of new services based on greater call control flexibility and
new data processing capabilities. Service provision and network operations are made independent of specific equipment. In order to arrive quickly at a useful set of recommendations, a phased standardisation approach was taken. Each phase specifies a Capability Set
(CS) being backward compatible to previous sets and introducing an evolutionary extension of the IN capabilities. CS-1 was first approved in 1992/93 [Q.1201], CS-2 was approved in 1997 [Q.1221], and CS-3 is to be published during 2000 [Q.1238].
The IN service model consists of three main elements [Q.1201]: A basic call process should
be available all over the network and is designed to support, with optimal performance,
services that do not require special features. Hooks (also called detection points) are to be
added to the basic call process, forming the links between the individual basic call processes and the IN service logic. The hooks continuously check the basic call process for the
occurrence of conditions on which an interaction session with IN service logic should be
started. The IN service logic is able to control the basic call process, therefore, changing
service logic and modifying network data can implement a new service that uses existing
network capabilities. The states and events of the basic call process are defined with a
Basic Call State Model.
The IN Conceptual Model consists of four planes where each plane represents a different
abstract view of the IN-structured network. These views address service aspects (Service
Plane), global functionality (Global Functional Plane), distributed functionality (Distributed
Functional Plane) and physical aspects (Physical Plane) of an IN. Most attention and practical application was given to the Distributed Functional Plane, which defines the functional
entities that are responsible for realising the IN capabilities, and to the Physical Plane,
which defines new protocols for the exchange of IN-related information between physical
devices. The interaction between the functional entities is realised through the Intelligent
Network Application Protocol (INAP) [ETS300374-1]. As access protocol to the Service Data
Function, the X.500 Directory Access Protocol (DAP) [X.511] was chosen [Turner95], [Chatras95].
Initial support for mobility was introduced into the IN framework with CS-2 [Q.1224]. New interworking relationships between service control functions and between service database
functions allow mobility management procedures for user and terminal mobility, e.g. registration, authentication, encryption, and handover. Additionally, call unrelated user interaction enables features outside the context of a call, such as location registrations or attach
functions of users or terminals. Additional enhancements for wireless access to the IN will
be defined by the CS-3 framework with a Terminal Access State Model for wireless terminals.
Page 12
To allow the fast introduction of new services into digital cellular networks, the IN architectures are being introduced into GSM network infrastructures. In GSM phase 2+ standardisation, IN capabilities are introduced into GSM under the name Customised Applications for
Mobile network Enhanced Logic (CAMEL) [Mouly95], [Geulen97]. CAMEL uses a subset of the
CS-1 INAP protocol to enable the GSM location registers to perform call control in the
GSM switching equipment.
1.2.2.3 Telecommunication Information Networking Architecture (TINA)
In its early phases, IN focused on telephony-based services since the IN concepts started
as an overlay to existing telecommunication networks. Therefore, the TINA-C consortium
specified a Telecommunication Information Networking Architecture (TINA) to define an open
framework for control and management of future telecommunication services and resources. TINA substantially builds upon the (ODP) standards [X.901], and the work of the
Open Management Group (OMG) on the Common Object Request Broker Architecture
(CORBA). TINA defines a service architecture using the concept of sessions between
groups of objects. A session is a temporary association between objects to fulfil a common task or objective. Several kinds of sessions have been defined [ Trigila98]. Access sessions grant users access to the network and support them in initiating service sessions.
Service sessions are the environment that logically contain generic and specific service
logic (in form of objects) to implement the desired application. Communication sessions
establish and maintain the required number of related connections meaningful to the service layer, representing streams between computational objects. They are realised by
connectivity sessions at the network layer, providing a technology-independent view of
network connections that are mapped onto the supporting network technologies. The
TINA session concepts offer a generalised connection graph capability, where end points
and lines between them can be dynamically adjusted throughout the duration of calls
[Chapman95]. It is therefore better suited to the requirements of future multimedia, multiparty services than the original IN basic call models.
1.3 Mobility management
Besides the provisioning of mobility-enabling terminals and communication networks, the
realisation of mobility additionally requires the development of mobility management services [Jabbari95] in the network infrastructure. Mobility management services implement
location handling and profile handling functions to perform tracking of mobile terminals
and users, registering mobile users to terminals, determining the user's or terminal's current address at incoming connection initiation, and storing and exchanging terminal and
user profiles for enforcing privileges and preferences. Location and profile handling technically require the provisioning of data storage functionality to persistently store location
and profile data and making those data accessible throughout the network infrastructure.
This chapter introduces the most prominent mobility management approaches being used
today in telecommunication and computer networks.
Page 13
1.3.1 Mobility management in cellular phone networks
The GSM mobility management mechanisms and protocols are the de-facto standard for
today's cellular networks. They employ databases called Home Location Register (HLR) and
Visitor Location Register (VLR) for handling location and profile data. The interaction between the GSM Mobile Switching Centres (MSCs) and the location registers is defined in the
Mobile Application Part (MAP) of the Signalling System no. 7 (SS7) that is used for transport
of signalling messages between the GSM infrastructure components.
To each terminal a number called Mobile Station ISDN Number (MSISDN) is assigned,
which is dialled by the calling parties. Furthermore, the terminal possesses a globallyunique International Mobile Station Identity (IMSI) for network-internal identification purposes.
For location tracking of terminals, several radio cells are logically combined into a location
area served by an MSC. The current location area of each terminal is stored in the GSM
databases and only updated when the terminal crosses a location area border. On incoming calls, the connection is routed to the MSC associated with the location area. The IMSI
is then used to page the terminal in the cells of the location area. (More precisely, not the
IMSI itself but a Temporary Mobile Station Identity (TMSI) is used for paging to hide a terminal's identity from eavesdroppers). When the terminal acknowledges its presence, the call
is completed as shown in Figure 2.
The HLR is a database that stores the subscription profile and part of the location data for
each GSM terminal. A GSM network may contain more than one HLR, each of them storing a subset of the overall network terminals. Each terminal has exactly one HLR associated with it and its directory number MSISDN contains enough information to unambiguously identify it [Lam97]. Additionally, the IMSI must contain information about a terminal’s
HLR address to allow its access during location update and roaming procedures
[Pandya97]. To each MSC a VLR is coupled containing a partial copy of all visiting terminals' profiles that are kept as long as each terminal stays in the VLR’s location area. The
VLR has several purposes: First, it keeps those parts of the terminal profile which are
time-critical for connection set-up close to the visited MSC so that connection establishment times are decreased. Typically it will contain parameters for frequently-performed
functions, such as authentication. Less often required parameters such as call screening
lists are usually kept in the HLR only. The second purpose of the VLR is to assign a temporary address called Mobile Station Roaming Number (MSRN) for a called terminal, which
is used to route the connection towards the visited MSC. A mobile terminal's HLR stores
the identifier of its current VLR, which is used to query the VLR for the terminal's current
roaming number. The third purpose of the VLR is to locally store more precise location information, called the terminal's current paging area to avoid paging the terminal in the
whole location area.
A simple form of user mobility is supported by GSM through the Subscriber Identity Module
(SIM), allowing a user to register on a terminal by inserting his SIM and performing the required authentication procedures, such as entering PINs. This user mobility is, however,
limited to GSM terminals.
Page 14
visited network of
calling terminal
home network of called terminal
(3)
MSISDN(B)
(5)
HLR(B)
GMSC
MSRN(B)
VLR(A)
(1)
MSISDN(B)
MSC(A)
MSISDN(B)
(2) MSISDN(B)
visited network of
called terminal
(4)
IMSI(B)
(5)
VLR(B)
MSRN(B)
IMSI(B)
MSRN(B) (7)
TMSI(B)
(6) MSRN(B)
PSTN / ISDN network
BSC(A)
MSISDN(B)
MSISDN(A)
MS(A)
(1) VLR(A) confirms that MS(A) is entitled to
requested service
(2) MSC(A) routes call to Gateway MSC of B’s
home network
(3) GMSC requests roaming number from B’s HLR
(4) HLR requests roaming number from visited
network’s current VLR
(5) VLR(B) assigns roaming number for MS(B)
(6) GMSC routes call using roaming number
(7) MSC(B) retrieves IMSI/TMSI of MS(B)
(8) MS(B) is paged using its TMSI
MSC(B)
(8) TMSI(B)
BSC(B)
TMSI(B)
MSISDN(B)
IMSI(B)
TMSI(B)
MS(B)
signalling link
traffic link
Figure 2: GSM mobility management for call set-up, adapted from [Pandya97]
1.3.2 Mobility management in computer networks
Computer networks using the Internet Protocol (IP) assume that a terminal's IP address
uniquely identifies the terminal's point of attachment to the Internet. Therefore, a terminal
must be located on the network indicated by its IP address in order to receive datagrams
destined to it. To enable terminal mobility across IP subnetworks, the Mobile IP protocol
[RFC2002] was defined by the IETF. Each mobile terminal (called mobile node in the IP
community) has a home agent associated with it that is located in the terminal's home subnetwork. An IP address from the subnetwork's address space, called home address, is allocated to the terminal. The home agent has knowledge about the terminal's current location represented by a care-of address. The care-of address belongs to the address space
of the currently visited subnetwork and is temporarily assigned to the mobile terminal by
the foreign agent of the visited network. As soon as a terminal enters a new subnetwork, it
contacts the local foreign agent, which assigns the care-of address and registers it at the
terminal's home agent. While the mobile terminal stays in the foreign subnetwork the
home agent receives all messages sent to the home address. The home agent encapsulates the original messages, adds the care-of address and sends them to the current foreign agent. It de-capsulates and reconstructs the original message and passes it to the
mobile terminal. This process is called tunnelling. Detection of foreign agents by mobile
terminals is done through advertisement messages sent by agents periodically and on request.
Extensions to this basic operation mode have been defined employing caching of location
information at several places in the network. One aim was to improve the routing efficiency
by avoiding the triangle routing via the home agent. After the first packet has been routed
Page 15
as described before, the home agent informs the sender about the terminal's care-ofaddress so that subsequent packets may be sent directly. Several mechanisms that update the cached location information at the sender or at other intermediate routers, are
parts of mobile IP. Another extension is the provision of forwarding pointers at a foreign
agent from which a terminal has left to the new foreign agent. The old foreign agent can
forward packets to the new foreign agent so that no packets are lost during handoffs between subnetworks [LaPorta96]. For the new IP version 6 protocol (IPv6), a more elegant
mobile IP solution is being standardised by the IETF. It makes use of the advanced capabilities of IPv6 for routing and addressing, eliminating the need for the foreign agent [ Perkins00] and eliminating the triangle routing.
Foreign
Agent (B)
care-of address (B)
Home
Agent (B)
home address (B)
mobile host (B)
Foreign
Agent
Internet
fixed host (A)
Figure 3: Mobile IP tunneling, adapted from [LaPorta96]
User mobility in computer networks requires the provision of profile and location handling
services across LAN and WAN environments [Perkins98]. User mobility in LANs allowing a
user to log in at any computer has been supported by several operating systems, such as
Andrew, SUN OS or Windows NT. The common mechanism is built on user profiles being
stored in a dedicated network service or in the network file system that are used upon login to determine the user's privileges and preferences. Part of the profile describes the
desktop environment and application settings that are instantiated at every terminal the
user logs in. The mobility of users is restricted to those computers that are connected to
the server storing the user profiles. To enhance the mobility range to wide-area networks,
the latest version of Windows NT stores the user profiles in a directory service that can be
accessed via LDAP from any computer connected to the Internet [MS-W2000].
Location handling for user mobility in IP networks is supported for example by the Microsoft Site Server [MS-ILS00]. It provides a location tracking and lookup service with which
Internet users can find and locate each other to start interactive conferencing sessions.
The Site Server stores static and dynamic properties of users, such as a unique identifier
and user-friendly names of the user, a user category (business, personal, adult), the IP
address of his current machine, the port number on which communication is to take place,
and application-specific parameters (e.g. the communication applications of the user and
their call status). The information is stored in a directory service and accessed by the users by means of HTTP or LDAP protocols. The Site Server is used by Microsoft's conferencing tool NetMeeting [MS-NM00] to search for users willing to join conferences and to exchange the necessary application parameters.
Page 16
For session-oriented applications in IP networks, the Session Initiation Protocol (SIP)
[RFC2543bis] offers mechanisms to enable user mobility. It defines a set of messages to invite users to participate in a session. The invitation is sent to a SIP server that either acts
as a proxy and forwards the invitation to the mobile user's current location or acts as redirect server and sends the mobile user's current address to the inviting party. SIP does not
specify, however, how the SIP server obtains the user's current location. This is the task of
a location server not defined as part of the SIP specifications.
1.4 Positioning infrastructures
To enable location-aware applications and services, the spatial position of real-world objects must be determined. Several positioning technologies are emerging; the most important ones will be presented in this section. Positioning usually uses one of the following
approaches:
 Mobile-based positioning
In this approach, a mobile sensor receives a set of reference signals from which it can
determine its own position. The resulting position may be absolute, consisting of coordinates, or relative, consisting of an identifier of a detected reference signal.
 Infrastructure-based positioning
This approach uses a fixed infrastructure of multiple locating sensors that can detect
the presence of mobile objects. The available implementations vary in the means how
the mobile object is detected, influencing the coverage area of a sensor and the resulting installation costs and locating resolution. Most systems using this principle provide
the mobile object's location only as a relative value, e.g. the identifier of the sensor having detected the object.
Combinations of these approaches can be found in some positioning systems based on
wireless communication networks, where the locating functionality is distributed over the
mobile device and the network infrastructure. The general advantage of using wireless
communication networks as positioning systems is that no additional infrastructure must
be deployed for locating objects. An approach to define performance benchmark criteria
for location systems was developed in [Tekinay98]. Research and development on locationaware applications [Eckardt96], [Long96], [Foster97], [Kreller98a], [PinPoint99], [Executone00] found
much attention due to progress in positioning technologies for real-world users and things.
1.4.1 Global positioning
The Global Positioning System (GPS) is a US military-operated infrastructure-based positioning system, which sends reference signals from satellites. The signals contain the satellite position and the time of signal transmission, so that the sensor, having received at
least four reference signals, can calculate its own three-dimensional absolute position with
an accuracy of up to 10 meters [Hascher97]. The position is first calculated in a Cartesian
coordinate system (i.e. x,y,z) and is then converted into geodetic coordinates (i.e. latitude,
Page 17
longitude, height) by the GPS transceiver [Dana00]. With the help of additional terrestrial
reference signals, the available location resolution can be further increased. This method
is known as differential GPS. GPS is currently limited to outdoor environments, since satellite signals penetrate buildings very weakly. Research on enhancing indoor and urban
canyon reception of GPS signals by means of processing assistance from external servers
show, however, promising results [SnapTrack]. The Russian Space Forces are operating a
comparable system called GLONASS (Global Navigation Satellite System) [RSF98] providing
similar positioning accuracy. GNSS (Global Navigation Satellite System) is the European
Community's effort to create a navigation system that is in international hands and independent of foreign military powers [ESA98]. It shall become operational after 2010 and will
offer more precise position data than GPS and GLONASS.
1.4.2 Wide-area positioning
The development of wide-area positioning techniques using cellular communication networks is receiving considerable attention since the US Federal Communications Commission adopted rules for locating mobile phones. They mandate that from October 31, 2001,
a wireless phone initiating E911 emergency calls must be located within 125 m of their actual location at least 67 percentage of the time [ Zagami98]. Several positioning techniques
in cellular wireless networks are currently under development for the most widely deployed
network technologies [Reed98], [Caffery98], [TruePosition], [Drane98], [Omnipoint00], [Ericsson-00],
[CellPoint00].
1.4.3 Campus-area positioning
1.4.3.1 RF-based systems
Infrastructure-based campus-area positioning techniques may be based on short-range
RF signals. An example of such technology are contactless smart cards, having the advantage that they may be powered by the sensor infrastructure and do not need own
power supply. Their operating distance from the sensing antenna is, however, restricted to
1.5 m. Short-range wireless LANs can also be used as positioning infrastructure. They can
be operated as mobile-based or as infrastructure-based systems. A dedicated short-range
wireless LAN using limited radio power was used as locating technology in the Piconet
system described in [Bennet97]. The Bluetooth short-range LAN technology [Bluetooth00] can
be used for the same purpose and promises the availability of very low-cost devices.
Additional technologies for indoor-locating systems based on RF reference signals have
recently appeared; PinPoint [PinPoint99a] has developed the 3D-ID Local Positioning System that allows locating assets and persons with an accuracy of 1 meter. A cell controller
sends a 2.44 GHz signal to a battery-operated tag having the size of a fat ID badge. The
badge modulates its ID onto the signal and returns it at 5.78 GHz back to the cell controller. From the time difference the controller calculates the distance to the tag. If the tag was
"seen" by at least three antennas, the position in space is calculated. WiData [ WiData] has
Page 18
developed the Firefly asset tracking system that locates tags at an accuracy of 3 m at a
range of up to 60 m indoors using RF signals in the 2.4-GHz ISM band.
1.4.3.2 IR-based systems
The most popular mobile-based indoor detection method for real-world objects is using infrared signals being periodically sent by the object. This method is used in Olivetti's Active
Badge System, a widely used locating system using battery-powered credit card-sized
badges worn by mobile users or attached to equipment [ Want92], [Harter94]. The sensors
are connected via a dedicated network with a polling box collecting and broadcasting the
sighting information. This system is limited to indoor usage by the infrared links, and the
locating resolution typically equals that of a room. Other examples for infrared-based tags
are Xerox PARC's palm-sized PARCTab [Schilit93], [Want95], [Brown97] and the Smart
Badges [Beadle98]. Executone [Executone00] offers one of the first commercially available infrared-based locating system for hospital applications. It is targeted for locating medical
practitioners, patients, and medical equipment, such as e.g. infusion pumps, beds, wheelchairs, and defibrillators.
The main advantages of infrared are the proven low-cost technology and the fact that the
signal cannot cross walls, leading to very accurate room-positioning results. Disadvantages are high power consumption and coverage-area "holes" when line-of-sight is disturbed. Mobile-based positioning using infrared can be economically achieved in conjunction with infrared-based wireless LANs where the base stations periodically send a location "beacon" that is detected by the mobile object.
1.4.3.3 Other approaches
Ultrasonic signals are being investigated in the Active Bat system [Ward97] to determine not
only fine-grained location at a resolution of about 15 cm, but also the orientation of an object. This infrastructure-based technique was employed in combination with another sensing technique, e.g. infrared, to identify an object to the infrastructure. More recently, the
Cricket ultrasonic positioning system employing a combination of RF and ultrasonic signals has been developed [Priyantha00]. It operates with a mobile-based approach in which a
mobile receiver calculates from the absolute travel time of an ultrasonic pulse the nearest
Cricket beacon and thereby its relative position. Beacons may be placed at a 4 x 4 foot
grid, achieving a positioning granularity in the same order.
Experimental work on using alternative infrastructure-based sensing methods employ for
example weight sensors in the Active Floor for use in buildings [Addlesee97]. Objects whose
weight is known to the system may be tracked as they move from one weight sensor to
another. The main advantage is that the sensed object needs no technical attachment.
However, locating accuracy and practical operation seem to be questionable and the infrastructure costs are extremely high. Another approach is to use image recognition functions along with video cameras to detect the location and possibly their orientation but it
requires extremely expensive infrastructures and is only usable in physically constrained
environments, e.g. a single room.
Page 19
1.5 Summary
This chapter has introduced the basic concepts of mobility and the networking technologies that are the prerequisites for the realisation of terminal and user mobility. It has presented the fundamental issues of mobility management and has discussed how these are
solved today in telecommunication and computer networks. Finally, an overview on positioning technologies that may provide spatial position data to location-aware applications
has been given.
The technologies presented in this chapter may be used by the Open Mobility Platform as
underlying communication and positioning infrastructure. Chapter 1.22.4 will define how
the Open Mobility Platform may be customised for some of the presented positioning
technologies. The HLR/VLR mobility management principles of GSM are a starting point
for the development of mobility management services to be offered by the OMP. In chapter 0, we will discuss additional research work on optimising the HLR/VLR principles; and
in chapter 0, we will specify the mobility management approach used by our Open Mobility
Platform.
The next chapter formulates the problem statement underlying this thesis. It defines the
scope and objectives of our work and motivates the relevance of the aims and the approach we have taken.
Page 20
Problem statement
This chapter formulates the problem statement underlying this thesis. It defines the objectives and the scope of our research and describes the relevance of our objectives and the
approach we have chosen. Related research work on mobility platforms is presented and
compared to our objectives. Finally, the approach we have taken for developing the Open
Mobility Platform and the Dynamic Directory Services is outlined.
1.6 Objectives and scope
The aim of this thesis is to develop an Open Mobility Platform based on functionally enhanced directory services we call Dynamic Directory Services. The Open Mobility Platform
shall offer its users a set of support services that allows the development of mobility management services and mobile and location-aware applications. The scope of the Open
Mobility Platform is campus-area and multi-site mobility because those environments
cover the grater fraction of people's mobility and they allow a much faster introduction of
new applications than publicly operated wide-area environments.
Following are the objectives - and non-objectives - that must be achieved by our research
to reach the aim defined above:
1. The set of support services that should be offered by the Open Mobility Platform to
make it useful for mobility management services, for mobile applications, and for location-aware applications must be identified. The support services shall allow management of and access to all mobility-related control information. Campus-area mobility as
well as multi-site mobility, i.e. roaming of users and terminals between campus-areas,
shall be supported. Connection management - e.g. handover - and handling of communication content is beyond the scope of the support services.
2. An Open Mobility Platform information model must be developed that provides a homogeneous representation of all control information to its users. The information model
shall be open concerning the functionality offered to applications. It must be highly
adaptable to different application environments and network infrastructures by the users
of the platform. This allows fitting the platform to environment-specific and to evolving
user requirements, thereby making it future-suited. The platform shall be open concerning mobility management database architectures to be customised to different network
environments and mobile user communities. A homogeneous management, security,
and access control framework must be supported by the platform across all its support
services.
3. It must be investigated whether the developed OMP information model can be realised
using standards-compliant directory information models and services. For the information models, the ITU-T X.500 recommendations shall form the basis; for the access
Page 21
services, the IETF LDAP standards shall be taken as the reference. We must identify
which parts of the OMP specification can be mapped on existing directory concepts and
which additional functionality is required from our Dynamic Directory Services. Investigating whether the performance of X.500 directory services is appropriate for realising
mobility management is not the aim of our work. Research on that issue has already
been done elsewhere, e.g. in [Hoff98] for wide-area mobility.
4. The identified new features of Dynamic Directory Services must be defined as extensions of the X.500 and LDAP services. The extensions shall be developed as generic
directory features that are not limited to mobility but are useful for any directory-enabled
application. The new Dynamic Directory features shall be accessible via LDAP standards-compliant protocols to allow the use of existing Application Programming Interfaces and protocol stacks for developing OMP applications.
5. To validate the completeness and usability of the proposed OMP information model
and the new directory features, a prototype implementation of the Dynamic Directory
Services and the Open Mobility Platform should be performed. To simplify the prototype
development, a Dynamic Directory server software architecture should be developed
and employed during implementation which allows to introduce the additional Dynamic
Directory functionality into existing directory server implementations.
1.7 Motivation
Why campus-area mobility?
The Open Mobility Platform shall focus on campus-area and multi-site mobility environments, since there the need for demanding mobile applications and services evolves more
quickly than in wide-area environments. This includes campus areas with closed user
groups but increasingly also areas with public user groups such as airports, congress centres, shopping malls, or exhibition places. Another motivation is that most of the time the
professional workforce is mobile in the immediate vivinity of the office and on the campus.
Research indicates that in the US 69% and in Europe 53% of the professional workforce
are mobile in the vicinity of their workplace [Kirby95] as shown in Figure 4. These figures
were found to be representative independent of the various professions, e.g. lawyers,
sales representatives, or architects. Therefore, mobility support for multi-site campus-area
mobility will be important for the grater part of the professional workforce. Additionally, professional and non-professional users will be supported at semi-public places like transport,
shopping, exhibition, and tourist places, leading to an overall significant applicability of the
Open Mobility Platform.
Why combine mobility management services with mobile and location-aware applications?
The Open Mobility Platform shall offer combined support for the development of mobility
management services and mobile and location-aware applications for several reasons.
First, mobility management services can also be seen as applications offered to the mo-
Page 22
bile user. These services strongly determine the functional appearance of a network to the
user with registration features, security procedures, profile handling features, and features
for handling of new communication situations being provided to the user. Different network
operators wish to pursue different privileges and security policies. These services therefore need the same development support as mobile applications since they are subject to
a similar, if not a faster evolution. Second, all application groups need very similar support
functionality, as will be shown in the state-of-the-art analysis. All need access to profile
and location data of mobile users and terminals, and since these data must be consistent
with each other, they are best offered by the same support services. Third, location-aware
applications for campus environments, such as museums, hospitals, or exhibitions are attracting huge interest, so that the platform should include support for this application category. Inside many campus environments, e.g. offices, only a small fraction of users carries
wireless phones today, the support of user mobility and location-aware applications such
as automatic call-forwarding or location-dependent voice paging are especially important.
US
Europe
Out Of Country 1%
Out Of Europe 2%
Out Of Country,
Out Of Metro Area,
In Europe 7%
In Building 55%
In Building 40%
In Country 12%
Out Of Metro Area,
In Country 18%
Out Of Campus,
In Metro Area 18%
Out Of Building,
On Campus 14%
Out Of Campus,
In Metro Area 22 %
Out Of Building,
On Campus 13%
Figure 4: Most mobility takes place in the vicinity of the workplace [Kirby95]
Why customisable functionality?
The aim of the Open Mobility Platform is to offer support functionality that can be used to
build mobility management services and mobile applications with minimal additional effort.
We believe that mobility management and mobile application requirements will be highly
dynamic since mobility has only recently been introduced into campus areas. Users and
network operators will come up with applications and requirements we do not know yet.
Furthermore, network and terminal technology are evolving at a dramatic pace, enabling
applications seemingly impossible today. For mobility management services, the optimal
strategies for location and profile handling of users and terminals are highly dependent on
the network environment and user attitude, as will be discussed in the mobility management analysis. Therefore, the Open Mobility Platform must be able to support various mobility management strategies and database architectures.
Page 23
The support functionality offered by the Open Mobility Platform should be as generic as
possible to serve different network and application environments and be usable in environments where the requirements evolve over time. On the other hand, the support functionality should be focused, meaning that it should offer dedicated functionality that solves
specific problems of the application developers, since otherwise it does not provide added
value to them. Our solution to these contradictory demands is to make the platform customisable by the platform provider, the network operator, or by application developers
themselves. With this approach, the Open Mobility Platform information model and services may be adapted for a particular environment and may evolve with changing requirements.
Why base the Open Mobility Platform on directory services?
The Open Mobility Platform and its clients will usually run on different hosts. Therefore,
access protocols for the OMP support services are required. The X.500 [X.511] and LDAP
[RFC1823] directory services provide a natural approach to answer these requirements.
They provide a generic framework for accessing attribute-value-paired data over networks
by means of a set of well-defined information models, access services, protocols, and
available APIs. This approach has the key advantage that the application and service logic
programmers can employ off-the-shelf Application Programming Interfaces that are widely
available on numerous platforms [XDS94], [RFC2251], [JNDI00]. Therefore, no proprietary
communication protocol stacks have to be developed, neither for the applications, nor for
the platform. Additionally, directory services provide mechanisms for defining data schemas, allowing structuring the data provided by the services. Thereby, an authority defining
the data schema can control the functionality that is offered to applications, while the generic access services remain stable. We can use this as a basis for the development of a
platform customisation approach. Since for multi-site campus mobility the functionality of
the Open Mobility Platform will have to be distributed over multiple network sites, distributed operation and data replication are necessary capabilities for which directory services
provide an elaborated framework. Furthermore, the X.500 directory service standards provide a generic and well-defined framework for realising security and access control [ X.509].
This avoids the necessity of having to develop proprietary new security mechanisms and
access control mechanisms for the Open Mobility Platform.
Another motivation for using a directory-based approach is the fact that X.500 and LDAP
directory services are increasingly used by several parties as a standard means for storing
mission-critical data in communication networks, e.g.:
X.500 directory services are proposed for handling mobility management data for public
and private mobile communication networks, as will be discussed in detail in section
1.10.
The directory access protocol DAP has been agreed as interface between service control
functions and service data (-base) functions in the Intelligent Network, see chapter
1.2.2.2.
Manufacturers of networking technology have begun to integrate LDAP into their products.
Netscape’s Internet browser uses LDAP to access directories, eventually all client and
server products will use LDAP for any attribute-value-pair information access [Netscape96]. Microsoft’s Internet conferencing tool NetMeeting [MS-NM00] uses LDAP to exPage 24
change user profile and location information about users wishing to join conferences, as
described in 1.3.2. The most recent version of Windows NT stores all user profile information in an LDAP-based directory service. It can be expected that other Internet applications will follow this approach, too. Networked applications in the Inter-/Intranet environment will therefore most probably have LDAP integrated soon.
Directory-enabled networks are pushed by several communication equipment manufacturers. The term denotes a design philosophy where network management information
can be accessed from a directory-based information repository, providing an integrated
view on management information from multiple network resources. Another application
is the storage of policy information in the directory that is retrieved from the devices that
enforce the specified policies. This approach is further described in chapter 0.
1.8 Related work on mobility platforms
This section summarises other research work on mobility platforms and discusses the differences in the aims, the scope, and the underlying concepts compared to our work.
1.8.1 Mobile Application Support Environment (MASE)
The European ACTS project OnTheMove has developed a Mobile Application Support Environment (MASE) consisting of a set of so-called manager components that offer their services to the mobile applications via corresponding APIs [Kreller98]. The aim of the platform
is to abstract from underlying heterogeneous network technologies and to allow a smooth
transition from current networks such as DECT and GSM to future UMTS networks. The
overall architecture of MASE is depicted in Figure 5, the grey components were developed
in MASE version one [OnTheMove-D28]; the others were added in a subsequent second development step [OnTheMove-D33]. The MASE platform is distributed over the mobile terminal and a so-called mobility gateway, acting as a central server for platform support functions.
The UMTS adaptation layer provides applications with unified network access to all possible underlying networks, and it handles roaming between different networks and bearer
services. The general support layer provides functionality required for the distribution of
MASE functionality over the mobile terminal and the so-called mobility gateway, acting as
mediator between wired and wireless network infrastructures. It furthermore contains security-related functions and user management functions for accessing and changing userrelated information to enable user mobility.
Page 25
Applications
Mobile API
Mobile
CommuniAgent
Transaction
cation
Manager
Manager
Manager
System
Adaptability
Manager
Accounting
Manager
Location
Manager
Online
Software
Update
General Support Layer
UMTS Adaptation Layer
PSTN
B-ISDN
GSM
...
UMTS
Figure 5: Overall MASE architecture
On top of these layers, the following manager components have been developed and implemented:
 The location manager provides applications with the geographical position - specified in
latitude and longitude coordinates - of a mobile device acquired from GPS devices or
network cell identifiers. The location manager is a process running on the mobile device
and does not maintain a globally accessible location database. The location manager
API supports retrieval services and a single simple event handling function to detect a
change in the current position.
 The communication manager enables messaging and real-time multimedia communication. It supports, among others, disconnected operations by means of an HTTP proxy.
A session management function establishes and disconnects bearer services, handles
transport-independent session connections and notifies applications about the session
connection status. A video gateway supports transcoding of video streams for reducing
bandwidth requirements over the wireless link.
 The system adaptability manager is responsible for providing optimised and personalised services. It takes into account terminal and user profiles describing characteristics
and preferences and determines the current network performance. From this it derives
the optimal content compression and conversion method for a given service request.
The user profiles are stored centrally on the mobility gateway and are replicated onto
the mobile terminal and on an information server running applications in the fixed network infrastructure. The profiles may not be distributed between mobility gateways.
 The accounting manager contains functions for performing secure electronic transactions for electronic commerce applications.
 The agent manager provides an execution environment and a meeting place for mobile
and system agents. The implementation is based on the Siemens’ SWARM system that
was extended with some MASE-specific functions.
Page 26
 The replication and transaction manager provides services for accessing shared data
objects from mobile terminals. It handles replicating and synchronising these data objects.
The follow-up project Move [Wallbaum99] added a number of additional components and
extended the original MASE components to include support for voice-over-IP applications.
The resulting platform is called VE-MASE (Voice-Enabled MASE). Several components
were added to support audio conferencing applications, among which are an audio gateway that provides mixing and transcoding of audio streams and a call manager that performs call and conference control. In contrast to our work, the scope of MASE does not include the provision of mobility management services but relies on mobility management
provided by public cellular networks. No standards-based access protocols and APIs to
the platform support functions are offered, and the MASE functionality is not customisable
by application developers concerning the support functionality and data schemas supported by the mobility gateway.
1.8.2 Mobile Data InterChange Kit (MOBI-DICK)
A mobile computing platform called MOBI-DICK (Mobile Data InterChange Kit) has been developed at Daimler-Benz Research [Diehl96] and Dresden University of Technology
[Schill95], [Böhmak96]. In addition to user and terminal mobility, the system also supports
service mobility. The system architecture models mobile and fixed hosts as stations being
assigned to an administrative area, called domain. A domain is the basic location information about a mobile host. Each domain has associated with it a so-called domain manager,
holding information about the domain and all stations being currently assigned to it. Each
station runs a station manager, maintaining information about the station status and the
available communication systems. In Figure 6, the structure of domain and station manager is depicted.
The station and communication system information is stored in the station manager management information base (SM-MIB). Security management offers authentication and authorisation services, resource management handles the station's resources such as processing and storage, domain management handles interaction with the domain manager
such as registration and deregistration in a domain. A sub-layer handles communication
and disconnection management. The domain manager additionally operates a service directory containing information about all services offered in a domain. Intra-domain management handles communication between the domain manager and stations; inter domain
management supports communication between domain managers. Each application
needs an associated application manager, knowing the service and resource requirements
of the application. The application manager is responsible for the availability of all required
services and performs service trading and service handover procedures when necessary.
The platform was implemented on top of OSF DCE and Windows NT using RPC mechanisms.
Page 27
Print
File Transfer
...
Application Support
SM
Domain
Security
Resource
ManageManageManageApplication
Support
ment
ment
ment
Service
M
Management Services
I
Communication + Disconnection
Management
DM
Inter
Domain
Management
Service
Intra
Domain
Management
Service
Domain
Security
Management
Domain
Resource
Management
Service
Directory
B
M
I
B
Figure 6: Structure of the MOBI-DICK station and domain manager
In MOBI-DICK, distribution of service, location, and profile data between domain managers is restricted to periodically replicating lists of present station identifiers between selected domains. Therefore, it may be doubted that the platform is well-suited for multi-site
mobility requiring more than one domain manager. Whether and how the platform supports location-aware applications with database and event handling services has not been
reported. In contrast to our Open Mobility Platform, the MOBI-DICK support functionality is
hard-coded and not customisable by the users of the platform and does not employ standards-compliant service access protocols and APIs.
1.8.3 Personal Communication Support System (PCSS)
The Personal Communication Support System (PCSS) has been developed [Eckardt97] to
provide advanced personal communications support capabilities (meaning user mobility
only in this case). The first version of the system was based on TMN concepts; later it has
been modified [Eckardt97a] towards a TINA-based architecture. PCSS supports features
such as logical, name-based user addressing, advanced user registration at locations and
dynamic device selection, and intelligent and customised call control, including selective
call forwarding. PCSS provides a platform for developing user services (e.g. registration
and profile management) and communication and information services (e.g. location information services, paging services, intelligent PBX, etc.). This is similar to the scope of
our Open Mobility Platform that supports mobile and location-aware applications and mobility management services.
The main PCSS concept is that a user registers at a location and not at a terminal. At incoming calls, the PCSS call logic first determines whether the user wants to be reached by
the originating party and whether a call-forwarding rule fires. In the latter case, the call is
forwarded to another PCSS user. This first process is called reachability management. If the
call shall reach the user, address resolution starts. The current user location (i.e. the current room) is translated into a terminal being available at the location, and the call is completed at the selected terminal. An interesting aspect of the system is that it may use an
Active Badge locating system to determine dynamically the user’s current location and
thereby terminal without an explicit registration procedure, a feature that is also supported
by our Open Mobility Platform.
Page 28
As technical basis of the PCSS, the TMN-based [M.3010] concept of managed objects
[X.701] being accessed by the standardised management Common Management Information Protocol (CMIP) was chosen. Additionally, X.500 directory services are used to store
static data and provide globally unique names for the managed objects, see Figure 7. Dynamic data, such as a user’s current location is made accessible by managed objects.
The managed objects also offer methods such as evaluating the most appropriate terminal
at a particular location.
PCSS User Services
PCSS-enabled Info & Communication Services
Location/Comm.
Information
Service
User Profile
Management
Service
Paging
Intelligent
PBX
Intelligent
e-mail
User
Registration
(Mgt.) Service
MM
Collaboration
X.500
User
Profiles
Electronic
Location Server
PCSS Applications
Framework
PCSS
Applications
Development
Platform
Mgt.
Platform
DAP
X.500
Infrastructure
Profiles
CMIS/CMIP
(Manager)
DUA
CMIP
X.700
Call Logic
MIB
X.700
X.700
User Reg.
MIB
VAP
MIB
Phone Mail
Server
Media & Format
Converters
Service Gateways
PCSS Support
Components
Figure 7: PCSS application development platform
Unlike the Open Mobility Platform, PCSS is limited to user mobility; terminal mobility as
well as mobile and location-aware applications are not explicitly supported. Although
PCSS makes use of a positioning infrastructure, it does not support the definition of
events by applications, thereby being very limited in its support for location-aware applications. Technically, access to data is hidden by the PCSS application development platform, hiding the underlying X.700 and X.500 objects. The intent was to make these systems “replaceable by other database concepts” [Eckardt97]. This is in contrast to our approach of using a homogeneous directory model for the Open Mobility Platform. We do
not employ directories as replaceable database but base the Open Mobility Platform architecture, information model, and access services and protocols, explicitly on directory concepts. Additionally, much of the PCSS is functionally encapsulated in methods of the
managed objects. The service logic implemented by such methods cannot be modified using the CMIP protocol so that - in contrast to the Open Mobility Platform - no sophisticated
end-user customisation of the platform's functionality is supported.
Page 29
1.9 Outline of thesis
The approach we chose for the development of the Open Mobility Platform and the Dynamic Directory Services reflects the structure of this thesis. The next chapter presents in
detail the state-of-the-art in mobility support techniques to identify which techniques
should be supported by the Open Mobility Platform. A framework consisting of four mobility abstraction levels is defined that may be used to classify application requirements on
mobility support and associate them with relevant support techniques. Chapter 0 introduces the X.500 and LDAP directory services standardised by ITU-T and IETF and presents some of the proposed extensions.
Chapter 0 specifies the Open Mobility Platform in detail. First, the overall functional model
and the functional scope are defined. After that, the information model is formally specified
by means of the Unified Modelling Language (UML). All object classes and attributes defining the OMP information model are characterised and explained with several application
examples from the mobility domain. After the OMP model is defined, the realisation of the
information model and support services based on X.500/LDAP information models and
LDAP services is discussed. This discussion reveals which existing X.500 and LDAP concepts may be used for realising the Open Mobility Platform and which concepts have to be
additionally provided by our Dynamic Directory Services.
A specification of Dynamic Directory Services that realise all of the identified new features
will be presented in chapter 0. It discusses the major design options for new directory capabilities, where appropriate. It defines an extended information model containing new object classes and attributes, defines the interaction of a Dynamic Directory server with its
clients, and presents examples that apply the new directory features in the context of the
Open Mobility Platform. At the end of the chapter, the new functionality is summarised as
UML diagram completing the UML specification of the Open Mobility Platform developed
in chapter 0.
It will be presented in chapter 0, how Dynamic Directory Services may be realised with a
layered architecture that extends existing directory server architectures. Design issues and
options for realising that architecture as part of the development of a Dynamic Directory
server prototype are discussed and the Open Mobility Platform prototype realised on that
server is introduced. The functionality of the Open Mobility Platform and its scaleability
concerning the number of users that may be supported depending on the number of Dynamic Directory servers are discussed in chapter 0 to evaluate whether the developed solutions meet the aims of this thesis. Further applications of the Dynamic Directory Services
beyond the scope of mobility support will be presented in chapter 0. The last chapter then
summarises the results of this thesis and provides an outlook for future interesting research issues.
Page 30
Support techniques enabling mobility
In this chapter, we present the major research issues being investigated aiming to support
mobility of users, terminals, and applications, and to support location-aware applications.
An inventory of problem areas and proposed solutions is made and four mobility abstraction levels are defined that classify the degree to which mobility of users and terminals is
seen by applications. Each identified abstraction level is analysed concerning the support
techniques that may be used to build applications belonging to the category. The technical
inventory and the analysis performed in this chapter will be used in chapter 1.21 to identify
which support functionality should be offered by the Open Mobility Platform.
1.10 Mobility management
The GSM mobility management architecture is currently the de-facto standard for terminal
mobility and is used in many of the deployed second-generation mobile networks. However, huge amounts of research work are dedicated to research on mobility management
techniques for third-generation mobile networks that will offer terminal and user mobility.
Research topics are mainly related to the following central issues, all of them having significant impact on the mobility management database architecture and signalling protocols:
Lifelong personal numbers associated with mobile subscribers must be used by the
mobility management services to access subscriber profile and location data. On the
other hand, the numbers must be independent of the network topology since otherwise
they could change over time. The research aim is to develop database architectures
that minimise effort and time spent for finding subscriber information from the personal
number. Current GSM databases do not provide a solution to this problem since HLRs
storing subscriber data are identified by dialling numbers [Lam97], [Yoshino98].
Location tracking mechanisms must store location data about mobile users and terminals. The aim is to develop distributed database architectures that allow fast access
from all network points (which suggests to replicate location data) and ensure minimal
update costs (which prevents replication). Research is therefore needed for developing
location tracking schemes that store location information at several abstraction levels
distributed over the network, so that an appropriate balance between access time and
update costs can be achieved. GSM only supports a two-layer database, where the
HLR stores the terminal’s current VLR, which in turn stores the terminal’s current paging area.
Profile handling must manage subscriber profiles in a way that allows efficient access
from all network points, especially from the user’s current location for interacting with
the local switching equipment. Research is developing variations of the HLR/VLR approach adapted to the distributed databases being developed for numbering and loca-
Page 31
tion tracking since the GSM MAP protocols are limited to the centralised GSM database
architecture.
The use of mobile agents to implement mobility management is a research area summarised in e.g. [Pham98], [Magedanz95]. Mobile agents promise to reduce signalling traffic
over the wireless link and are used to implement user agents that follow a mobile user
to increase the locality of reference for mobility management processing [ Küpper98] and
to provide personalised virtual environments at the user's current location [Hagen98].
Other research issues in subscriber data management include modelling of subscriber
profiles, general database performance issues and database architecture for improving
the availability of databases to tolerate failures. In the following, the most important research issues - personal numbering and location tracking - are discussed in more detail.
Thereafter, research work on mobility management architectures for emerging cordless
networks, for third-generation mobile networks, and for user mobility is briefly summarised.
1.10.1 Issues in lifelong personal numbers
A central issue for mobility management is the analysis and translation of a lifelong personal (i.e. UPT) number. Besides finding the subscriber profile in the database from the
dialling number, a problem is to distinguish UPT numbers from normal dialling numbers to
invoke the IN service logic. Integrated numbering would allow the use of any PSTN
number as personal number, but in this case, detection of such numbers became especially expensive. Structured numbering assigns a prefix to all personal numbers, simplifying personal number detection. ITU-T Recommendation E.168 [Pandya97] defines a
numbering structure for UPT numbers allowing - but not requiring - the use of a prefix to
identify numbers as UPT numbers. Geographical numbering, meaning that the number
reveals knowledge about subscriber data allocation or routing hints, should not be used for
personal numbers since these should ideally be assigned to a person for his whole life.
Several approaches for lifelong personal numbering have been proposed, usually employing one of the following mechanisms:
Forwarding pointers are used to extend the lifetime of a geographical dialling number.
The number identifies the database where name resolution starts. If the subscriber data
is no longer stored in that database, a forwarding pointer to the new database is created. This approach is simple and can be applied in an evolutionary way in today’s network infrastructures [Lin96]. However, this approach works only as long as the first database exists and is willing to carry the pointer, therefore it provides no general solution
for lifelong numbering as network infrastructures evolve.
Name servers offer a generalisation of the forwarding pointer concept. For each subscriber, a pointer to its database is kept in a centralised or replicated name server
[Kato91], [Fenner92], [Carnassa92], [Ng92], [Yoshino98]. Since the name server information is
rather static, it may easily be replicated in the network to allow local name server interrogations [Ng92], [Yoshino98]. The result of name server interrogations may also be
cached [Jain96] to reduce name server query volume. This approach does enable lifelong numbering, but its applicability depends on the maximum number of subscribers
that may be cost-effectively managed by name servers. Replicated name servers have
Page 32
been suggested by the author [Maass93] for implementing personal numbers in private
networks [Havermans93]. The continuing dramatic increase in storage capacity and processing power of computer hardware are extending the applicability of this approach towards metropolitan area networks [Ng92] and large PCS networks [Jain97], [Yoshino98].
Searching in distributed databases is used to retrieve subscriber data stored in one or
multiple database nodes, if the personal number does not contain hints about data allocation. In flat database architectures, a database node has no knowledge about data in
other nodes and search processes may propagate trough the whole database leading
to unacceptably high retrieval delays. Some work suggested the use of broadcast messaging to reduce search time [Iida93], but this approach only works in networks with a
limited number of users and signalling networks with broadcast facilities.
Replication and caching of subscriber information in distributed databases has been
suggested to speed-up searching of subscriber data and to reduce retrieval operation
volume in central subscriber databases. This approach works best for static parts of the
subscriber data since otherwise it leads to consistency problems. Replication may be
static or may be done dynamically (caching), depending on call and mobility patterns.
Replication in conjunction with hierarchical databases has been proposed, for example,
in [Shivakumar95], [Lam97], [Jannink97] where replication uses knowledge about statistical
call and mobility behaviour of individual users to optimise replication of data. Caching at
the originating switches may reduce the need to access centrally stored subscriber data
[Jain94], [Harjono94], [Lin96], depending on the mobile user’s mobility behaviour.
Hierarchical database architectures have been proposed [Awerbuch91], [deBoer91],
[Wang93], [Steen96], [Lam97], to reduce search times in distributed databases. In these
approaches, databases at one hierarchical level may store allocation knowledge about
data held in the level below. A search request typically starts at the bottom of the hierarchy and propagates up to the root of the database tree until allocation knowledge is
found. From there, the request propagates down to the node storing the data that is
searched. A hierarchical database example is presented in the section 1.10.4 on UMTS
mobility management. The performance gain depends on the amount of allocation
knowledge held in the database tree and the number of its levels. A drawback of this
approach is the need to update allocation knowledge when data is moved from one
node to another.
Hash functions have been proposed to map the personal number on an identifier of the
name server that holds allocation knowledge about the subscriber data [ Dasgupta94],
[Jain96a]. This approach achieves load balancing between the name servers and is useful for networks in which a single central name server would not suffice, while replicating the name server at each switching node would be too expensive. In [ Dasgupta94], the
hash function may return one or more name server identifiers that have knowledge
about the subscriber to allow for replicated name servers. In [ Jain97] a model for calculating the costs of the name server equipment for PCS systems is developed, taking
into account variable mobility and call behaviours as well as optimisations such as
caching.
The realisation of lifelong personal numbers - as it is being requested by national regulatory authorities as Mobile Number Portability (MNP) - poses significant challenges on the
existing GSM networks. MNP may be implemented e.g. by managing subscriber numbers
collectively in an Intelligent Network or a central subscriber database; or it may be implePage 33
mented by using call forwarding pointers from the "donor" GSM operator that gave away a
number to the "recipient" GSM operator to which the subscriber moved [ACA98].
1.10.2 Issues in location tracking
The GSM and PCS location tracking technique with its two-level HLR/VLR database hierarchy has often been criticised by academia for its central HLR approach. For location
lookup the HLR is always accessed, independent of the relative distance of caller and
callee during call set-up. For location updates between MSCs, the HLR is updated even
when the two MSCs are served by the same VLR since the roaming number must be updated. Locality of movements is not considered for reducing HLR updates. These facts do
not only produce high transaction volumes for the central HLR, they additionally create
long-distance signalling traffic when the user is far away from his home area, leading to
higher signalling costs and processing delays.
Over the past ten years, a large research community has tried to develop optimal location
tracking techniques for wireless networks, targeting to minimise the resulting network (signalling and database) costs. However, such optimisations are always a trade-off between
signalling costs and database costs. A key measure used in most approaches for characterising user behaviour is the call-to-mobility ratio (CMR) of a mobile user. It is defined
as the number of calls received in a period of time divided by the number of location updates in the same period. In the following, the main approaches in the field of developing
optimal location tracking techniques are explained, and references to representative contributions are given:
Optimisations of the GSM/PCS location database architecture
For the basic HLR/VLR scheme, numerous improvements have been suggested. These
schemes improve the basic scheme in some aspects, but usually only under certain
network assumptions (e.g. whether signalling traffic or database volume is more expensive) and for a certain user mobility and calling pattern.
- Caching location data at originating switches has been proposed in [ Harjono94]
where information obtained from the HLR is cached at VLRs to avoid subsequent interrogations of the same information. If the user moves, the cached information becomes stale. If an originating VLR uses stale information to route a call, the addressed VLR returns a message that invalidates the cache. Depending on the CMR,
the scheme can reduce call set-up time by 35% and HLR query volume by 70%.
Since the scheme is only beneficial for users moving relative infrequently and receiving many calls from the same switch (otherwise the caching overhead dominates the
savings), a method called per-user caching was suggested in [Jain94]. It applies caching only for selected users, depending on their overall CMR and their local CMR
(LCMR), being calculated from the originating calls of a particular switch. An LCMR
of larger than seven was estimated as a practically useful threshold value for caching. The challenge in this approach was to estimate the LCMR values of individual
users at the originating switches from the user's past behaviour.
Page 34
- Forwarding pointers have been proposed in [Jain95] to reduce update volume in
HLR databases. The information in the HLR is not updated when the terminal
moves; instead, in the old VLR a pointer to the new VLR is added. During call set-up,
the HLR is queried first, and the chain of forwarding pointer to the user's current location is followed. The length of the pointer chain is limited to a defined value to keep
set-up times in appropriate limits. This scheme has advantages for users with a very
low CMR, e.g. below 0.5, in which case the scheme promises to reduce total network
costs by 40-60%. The main advantage is that the update volume of the central HLR
is reduced by distributing updates over the VLRs.
- Local anchoring has been suggested [Ho95] to reduce location update signalling to
distant HLRs. Instead, a nearby VLR is used as anchor and is updated with the actual location data. This approach reduces long-distance signalling to the remote HLR
and reduces update volume in the HLR itself. The difference to forwarding pointers is
that the length of the forwarding chain is limited to two VLRs.
- Reactive replication of location data was suggested to reduce HLR queries and
signalling traffic. In [Leung96], it is suggested to replicate the complete HLR subscriber
record including location information in a VLR, if the user is far away from his home
network. On call set-up to the user originating in the visited region, the replicated
data in the VLR would be queried instead of querying the remote HLR. This approach is advantageous if call origination to a user exploits locality to the user's current location. A disadvantage is the increased signalling overhead for keeping the
replicated records identical. To reduce the database synchronisation overhead, in
[Leung97a] the idea of partial replication was formulated, suggesting that only the VLR
has a full copy of the record, and that the HLR does not contain the exact location information. The advantages of reactive replication approaches strongly depend on the
fraction of calls that are made local to the user's current location and the weight of
replication costs compared to retrieval costs.
- Pro-active replication of location data was developed in [Shivakumar95]. Data is not
only replicated in the user's current region, but at all network sites from which calls to
the mobile user will originate with a certain probability. The number of replicas and
their allocation is optimised according to calling and mobility patterns, which may be
fixed or incrementally adapting. To avoid replication of frequently changing data,
[Palat96] suggests replicating the mobility pattern of a user, described as a list of frequently visited locations together with location probabilities (these probability lists are
also employed in [Pollini93a], [Tabbane95a]). The disadvantage is that all listed frequently-visited locations must be paged at call set-up. Pro-active replication approaches are advantageous in environments where users exhibit very regular
movement and calling patterns.
Flat location databases have been suggested in [LaPorta95], [Qin95], [Dommety97] for
speeding-up call set-up times by avoiding the overhead caused by VLRs. In [ Qin95],
subscriber profiles (without location data) are distributed over the network in independent databases, whereas location information is held centrally. In [ Dommety97], a central
tracking is suggested for users being in their home area, whereas for remote users a
two-level scheme using a proxy HLR (comparable to anchor VLR) is suggested. Flat lo-
Page 35
cation database approaches are advantageous in environments where signalling is
cheap and fast and connection set-up delay is of prime concern.
Hierarchical location databases have been employed in numerous approaches [ Fujioka90], [Awerbuch91], [deBoer91], [Maylan93], [Wang93], [Ito95], [Hac96] since in general a tree
can be efficiently searched. Trees have not only been used for finding subscriber data
from a dialling number, as explained above, but also to store location data in different
granularities. In the leaf nodes, exact location information is stored; in the upper levels,
only coarse information about the user's current region is held by means of forwarding
pointers to the subordinate database level. This has the advantage that higher layer information changes less frequently while providing enough information to continue the
search. Several variants of the hierarchical database approach employing, e.g. caching
[Jain96], broadcasting searches to multiple databases [ Ng92], and using history information [Krishna94] have been investigated. In [Badrinath92b], the higher layers only store
probabilities about the presence of a user in the lower levels, which has the advantage
that such information is nearly static in environments with regular mobility patterns. The
use of hierarchical databases for naming and locating of computing objects was investigated in [Steen96]. The hierarchical database developed for third-generation mobile
networks [Buitenwerf95] is explained in more detail in section 1.10.4. The main advantage
of hierarchical databases is that they scale better for large mobile networks. They distribute database transaction volume over multiple databases instead of relying on central HLRs. Additionally, mobile users often exhibit locality in their mobility and the calls
they receive [Li95], [Park97], both are most of the time limited to a region around their
permanent home. Hierarchical databases are able to exploit such locality by keeping
database transactions localised in a nearby database, instead of signalling to a distant
HLR. The disadvantage is that the more levels they use, the more database retrieval
and update operations may be required in the worst case. Depending on the assumptions on network costs and user behaviour, it has been shown that hierarchical approaches may outperform two-level databases, but the opposite fact has also been
shown [Schopp97].
Optimal location area design is a popular research area, aiming at reducing signalling
traffic over the air interface associated with location updating and paging. Classical location updating occurs when a user crosses the boundary of a defined, static location
area. This causes high signalling traffic over the air interface in the cells at the boundary and no traffic in the inner regions. To better distribute update signalling traffic over
the cells, location update methods based on distance [ Verkama97], movement, timers
[Rose95], and reporting cells being evenly distributed [ Bar-Noy93] have been suggested.
In [Okasaka91] it is proposed to layer multiple staggered location areas and divide users
into groups, so that update traffic is distributed over the layers (and thereby cells). Location areas with variable sizes, depending on the user's mobility behaviour, were investigated in [Xie93]. Reducing location area size by overlaying global paging networks was
suggested [Lin95], using a reverse call set-up scheme from the called terminal to the
originating switch (whose location is known) after successful paging. Since timer and
distance methods create unnecessary location updates, the location area approaches
are predominantly used.
User modelling and mobility prediction are required for many of the above-mentioned
techniques to optimise dynamic location area designs, to place databases in the net-
Page 36
work, and to manage replicas within databases. User modelling is necessary to compare different location management schemes, such as performed e.g. in [Schopp97].
Mobility prediction was investigated in [Liu96] to pre-inform location areas about a user
that will most probably - based on past movements - enter soon. The prediction is also
sent to the terminal, which then determines whether it must explicitly update its location
in case of false predictions.
Evaluating the signalling traffic and database operation volume is needed for dimensioning the signalling switches and links [Pollini95] and the mobility database servers
[Lo92], [Lo93b], [Wirth95]. These are part of a larger work area, called teletraffic engineering and covering in addition the dimensioning and planning of radio cells, switching
and trunking capacity, and planning of radio resource allocation and admission control
policies [Steele92], [Grillo98]. The task of this research area is to use estimated figures for
mobile subscriber numbers, mobility behaviour, and call volume to calculate resulting
teletraffic figures. These are then used to evaluate the achievable grade of service in
the mobile network concerning, e.g., call set-up times, overall call volume, and call
blocking or dropping probabilities. These calculations are carried out for multiple network configurations, trying to arrive at optimal network configurations. A detailed overview on this subject including the emerging teletraffic engineering standardisation efforts in ITU-T can be found in [Grillo98].
1.10.3 Mobility management approaches for cordless networks
To provide mobility management services that allow subscribers to roam between cordless networks, two main approaches are under development. One approach is to use
GSM mobility management infrastructures as described, for example, in [ Deissner97], the
other is to use dedicated infrastructure based on distributed directory services for storing
subscriber and location information. Cordless terminal mobility in private networks using
DECT is standardised by ETSI as Cordless Terminal Mobility (CTM) [ Ciancetta96] and by
the Telecommunications Industry Association (TIA) as Private Network Mobility Management [King96] for DECT, CT-2Plus, and PHS cordless technologies. The Japanese Personal Handyphone System (PHS) uses cordless terminal technology for providing widearea wireless multimedia communication services [Murase98a]. Work on using X.500 directory services for roaming in cordless networks was pioneered by the author starting in
1992 [Maass92]; subsequent developments building on our concepts have been performed
thereafter [Berger96], [Berger97]. Work on using X.500 directory services for roaming between cordless PHS networks was performed by Suzuki et al. [ Suzuki95], [Suzuki96]. The
common element of all X.500-based proposals is to store subscriber and location information in directory entries. The approaches differ in how an entry belonging to a subscriber is
named. Naming entries has direct consequences on finding entries in a distributed directory.
We proposed an X.500 directory architecture and schema for user and cordless terminal
mobility in corporate networks [Maass93], [Ahlers92], which enables the allocation of subscriber profiles independent of the associated personal numbers. This was achieved by
means of replicated lookup tables serving as name service that returns for each number
which database server holds the subscriber profile. A prototype of user and cordless ter-
Page 37
minal mobility in a corporate PBX network has been implemented and demonstrated at
the Telecom’95 fair [Falck95]. Contrary to our approach, the work of Suzuki et al. uses hierarchically structured numbers for finding data in the directory. They suggest to have country and PHS provider prefixes in the dialling number and structure the directory tree in
country and PHS provider subtrees. This makes their scheme impractical for implementing
lifelong personal numbers as discussed above. The proposal of Berger et al. is based on
the author’s previous work. A distinction is that it proposes to use the DECT terminal identifiers - consisting of a prefix and the terminal’s extension number - additionally for navigating in the directory, but this prevents the realisation of user mobility with lifelong personal
numbers.
1.10.4 Mobility management for third-generation mobile networks
Much research was dedicated to the development of mobility management architectures
for third-generation mobile networks, especially by the European RACE project phases I
and II R1043 [deBoer91] and R2066 MONET [Buitenwerf95] developing the original UMTS
fixed network architectures. A distributed database was proposed for UMTS mobility management to increase performance, reduce signalling and improve reliability and availability, and to allow incremental database growth compared to the GSM database architecture
[deBoer91]. The UMTS distributed database architecture [ Buitenwerf95], [MONET-D14] is based
on a hierarchical directory tree to employ efficient access and searching procedures. The
database is divided into storage nodes, holding profile and location information, and directory nodes, storing references to either the storage nodes or to other directory nodes. It
was also investigated how the directory structure could be realised by means of X.500 directory services [MONET-D44].
For each subscriber X, one storage node has a permanent instance of the subscriber profile and is called home node. A copy of the profile is held at storage node of the current
network part, called visited node. In the directory nodes, the mobility management services maintain references to the home node and optionally to the visited node, depending
on the used locating strategies. Multiple strategies of this kind have been proposed, all being divided into up and down phases. The up phase starts at the point where the profile is
being requested. If it is not found locally, the directory nodes are traversed towards the
root until a reference to the searched subscriber data is found. Following that reference,
the tree is traversed towards the bottom, following consecutive references until the storage
node is reached. Based on this general mechanism, three locating strategies have been
defined [MONET-D14]:
Strategy R always forwards searches to the resident node, that stores either a reference
to the visited node (flat location tracking) or a reference to a directory node from which
the search must traverse downwards towards the visited node (hierarchical location
tracking). The advantage of this strategy is that all references are quite static, but it
does not exploit locality of calls.
Strategy V forwards searches directly to the visited node, the resident node is not involved. The advantage is that queries do not have to propagate to the home network
Page 38
but may be solved locally in the visited network. The disadvantage is that references to
the visited node are highly dynamic, causing high database update costs.
Strategy RV combines the previous two. A search propagates upwards until the first reference towards subscriber data is found, being either resident or visited node.
An inherent advantage of the UMTS database is that calls to nearby subscribers may require local database operations only, if references to the visited node are found. If many
calls exhibit such locality, the overall system performance scales much better than the
GSM approach, where every call leads to central HLR operations. However, maintaining
all the pointers during movements of subscribers creates an additional update problem, if
too many references exist. Choosing the appropriate strategy, tree depth, and placing required references in the directory nodes is a complex problem. The aim is to minimise the
number of references to be followed and to keep the number of references to be updated
within appropriate limits. Since this depends on numerous technical and behavioural factors - as already explained in section 1.10.2 - no general solution to that problem could be
provided by the MONET project.
strategy R
strategy V
directory
nodes
data storage
nodes
visited
node
visited
(calling)
resident
node
Figure 8: Locating strategies in UMTS distributed database
Consecutive work on UMTS mobility management was devoted to modelling subscriber
profiles for multiple roles of subscribers [Eleftheriadis94], performance evaluations of the
UMTS distributed database [Eynard95], performance evaluations on using UMTS databases for UPT services [Ritterbecks95], keeping location information confidential by hiding
subscriber identities [Hoff96], and to the inclusion of two-phase commit protocols into the
directory database to ensure database consistency [ Adamidis97]. As a consequence of the
complex database optimisation task and the evolutionary approach adopted for the introduction of UMTS, it is currently envisioned to base the initial UMTS mobility management
infrastructures on GSM databases [Ojanpera98], although this should be seen as a pragmatic intermediate step only.
Page 39
1.10.5 Mobility management approaches for user mobility
Mobility management for realising user mobility as defined by UPT in IN-enabled networks
requires the handling of UPT service profiles and user registration data in the IN Service
Data Function (SDF). An important question is how the UPT service profile is realised in
the SDF functions in form of X.500-conformant directory entries, since X.500 directory
services have been selected as SDF access protocol by ETSI. Contributions on modelling
of user profiles as X.500 entries in the SDF have been developed by Obana et al.
[Obana92a], by Chatras and Gallant [Chatras94], and by the author [Maass93]. Obana et al.
proposed a name [Obana92] for translating UPT numbers based on distributed X.500 directory services. They assumed a hierarchically structured UPT number with country codes,
network codes, and group numbers that were used to create names for the directory entries, allowing to determine which directory server holds a particular subscriber profile.
Forwarding pointers based on alias entries were suggested to provide lifelong personal
numbers. Chatras and Gallant proposed a UPT information model based on X.500 to
ETSI standardisation groups [Gallant93] on UPT and IN after ETSI decided to use X.500 as
access protocol. Their main contribution was a detailed proposal of how the UPT subscriber profile information can be mapped on X.500 object classes and attributes and
which services would be required to perform the necessary retrieval and modification operations. They did not discuss, however, how the proposed entries are allocated to SDFs
and how they are retrieved based on UPT numbers, instead, they modelled the SDF as
black box.
User mobility in TINA is conceptually supported in the access session by controlling the
registration of users on terminals. Furthermore, it allows service personalisation according
to individual user preferences. A TINA auxiliary project "PCS in TINA" [ Eckardt96] added
advanced user mobility features, such as automatic call-forwarding to a user's current location and terminal registrations based on current locations and personal schedules. It
also supports a rule-based personal call logic to control how incoming connections are
handled by called parties. The project added PCS-enhanced User Agent and User Location objects to the TINA access session layer. Extensions to the TINA business model and
the impact on and extensions to the computational model for supporting personal mobility
were developed in the ACTS DOLMEN project [Wind98]. An approach often used for simple user mobility is the introduction of proxies residing at the user's home location that accept communication requests and re-direct them to a person's actual address. The mobile
user must manually or automatically update his current location with the proxy. Additional
functions such as call screening and schedule-dependent routing can be introduced with
such proxies. The advantage is that no dedicated network infrastructures are required.
The disadvantage is that only incoming connections are handled but that the user obtains
no personalised settings or allowances at the current location. A proxy therefore only enables a very limited form of user mobility. An example of a proxy-based architecture has
been suggested as part of the Mobile People Architecture [ Maniatis99].
Page 40
1.11 Mobile applications
Research on supporting mobile applications received huge interest in the last years. Different terms have been established in this context, dealing with slightly different mobility
environments. The term mobile computing [Imielinski97] usually refers to an environment
where portable computers communicate over a wireless connection. The computers may
be moved while being actively used. The term does usually not comprise user mobility.
The term nomadic computing [Kleinrock95] refers to portable computers which are connected from time to time at different points of attachment to a network and are otherwise
disconnected. They are actively used being either connected or disconnected. Nomadic
computing sometimes also refers to user mobility. Researchers at Xerox PARC introduced
the term ubiquitous computing [Weiser93]. It refers to an environment where computers
are pervasively available for all kinds of purposes, communicating and co-operating with
each other while being effectively invisible to their human users. The concept comprises
mobile computing but also encompasses user mobility, application mobility, and locationaware applications.
1.11.1 Support for finding and accessing services
The dramatically increasing resource richness of the Internet and privately operated Intranets creates the problem of communicating the existence and the location of services to
potentially interested applications and users. Mobile users and applications are affected
even more by this difficulty. Many applications are traditionally built for a distributed computing environment based on the client-server paradigm, and make use of various infrastructure services, such as naming, email, printing, calendar, video retrieval, or speech
recognition services. When these applications are transformed into mobile applications
running on portable terminals, the usage of the service infrastructure becomes a hurdle.
Today, applications or the terminals on which they are running are configured with the
names of the services or even with the service providers (e.g. in the case of printing). In a
mobile environment, the configuration of infrastructure services may significantly differ at
the various network parts the terminal may move to, so that the application cannot make
use of fixed configuration knowledge but has to explore its environment in a more intelligent way.
The support techniques being developed for finding and accessing services in unfamiliar
or dynamic environments are based on the model of a service broker. The process of
finding services is also called resource discovery or service discovery. The interaction
model between client, broker and service provider is roughly the same in all approaches
being investigated. A service provider registers its service offering at the broker, together
with information on the address it can be accessed at and optionally with some parameters that describe the service offer properties. A client wishing to invoke a service first contacts the broker and specifies the service it is looking for, plus optionally some preferences
concerning the service properties. The broker searches in its database and returns potentially matching service descriptions to the client, which then contacts the service provider
directly.
Page 41
The techniques for realising service broker functionality can be divided into three groups,
which are further described in the following subsections:
Directory services, offering white- and yellow pages services. White pages services allow mapping a service name onto its address. Yellow pages additionally allow searching for services that match attribute-based descriptions and return their names and addresses.
Trading services, offering similar functionality like yellow pages services plus the ability to
select the optimal service based on selection criteria.
Resource discovery services, allowing an application to discover lookup services, such
as directories or traders, without pre-configured knowledge.
1.11.1.1 Directory services
Directory services are a natural candidate for offering broker functionality. Traditional simple directory services that provide only name-to-address mappings are often also called
name services or white pages services [Barker94]. An example for such a traditional name
service is the Domain Name System (DNS) defined as Internet standard name service
[RFC1034]. Name services allow retrieving the address of a service provider, if the client already knows the name of the registered service. More powerful directory services such as
X.500 [X.501], DCE directory services [Rosenberry92], [Leser93], Netware Directory Services
(NDS) [Herbon94] allow to store additional attributes with their entries that can be used to
implement so-called yellow pages services [Meulemans96]. Useful broker services managing service offer properties and allowing their clients to formulate more sophisticated queries would likely be based on the latter type of directories. How its clients and service providers find a directory service itself is not specified as part of the directory specifications.
Currently ongoing work suggests borrowing principles from the Service Location Protocol,
which is described in section 1.11.1.3. Recent progress in smart-card technology has enabled the realisation of directory services on smart cards. This will allow mobile users to
have their personal directory available in every terminal in which a SIM module may be inserted [Macaire99]. A detailed introduction to X.500 and LDAP directory services is presented in chapter 0.
1.11.1.2 Trading services
In the framework of Open Distributed Processing [ X.901] a broker function has been standardised, called trader [X.950]. A service provider, called exporter, contacts the trader to
add a service offer to its service offer database. Additional service offer characteristics
may be registered as so-called service offer properties. A service client, called importer,
interacts with the trader for retrieving those services that match the client selection criteria.
The trader service model is derived from the ODP computational viewpoint. A service is
provided by an object (i.e. the exporter) at its computational interface and is used by other
objects (i.e. importers) that bind to this interface. A service is an instance of a service type,
specifying an interface type and service property types. The interface type defines the type
of computational interface the service is provided at and specifies its signature and
thereby its operations in an Interface Description Language (IDL). The service type also
determines the allowed set of service properties describing static or dynamic service char-
Page 42
acteristics. An exporter creates a service offer by specifying its service type, an interface
reference, a set of service property values, and service offer property values. The service
type defines the kind of service being offered. The interface reference identifies the interface that must be used by clients to access the service. The service property values describe static and dynamic service property values of this service instance. Additionally, the
exporter may specify service offer property values describing properties of the service offer, e.g. its expiration date.
The most important trader operations offered to exporters are export and withdraw for adding and removing service offers from the trader's database. Trader operations for importers are search and select. For search, the importer specifies type and criteria of services in
which it is interested. The trader searches its service offer database for service offers
matching the criteria and returns all potentially interesting service offers. The importer receives an optionally sorted list of service offers and performs a selection of the best service offer. For a select operation, the importer additionally specifies selection criteria and a
trader policy. The trader searches for service offers matching the criteria and selects a
service offer based on the selection criteria and the requested trader policy. The importer
receives only one service offer, representing the best choice concerning the specified criteria. Traders are able to co-operate in so-called federations [Lima95], [Meyer96] to exchange
knowledge about service offers as shown in Figure 9.
Import
Requests
Trader 1
Import
Requests
Importer
(client)
Import
Replies
Trader 2
Import
Replies
Exports
Evaluations
Service Invocation
Exporter
(server)
Service Replies
Figure 9: Trader operations
The main difference between traders and directories is the ability of a trader to perform the
selection of the best service on behalf of the client, whereas a directory is usually not able
to return an optimal result but returns all (or a requested number of) possible candidate
service offers. Research subjects are the trader mechanisms of choosing optimal services
[Thißen96]. A further difference is the ability of a trader to manage dynamic service offer
properties. The static properties are held in the trader's internal database, whereas dynamic service properties, such as the length of a printer queue, are dynamically obtained
from the service provider through the service offer evaluator interface. Strategies for
evaluating dynamic service offer properties can be pro-active, caching relevant properties
at regular intervals, or reactive, determining service properties on-demand when clients issue an import request [Küpper96].
Functionality offered either as integral part of a trader or as an add-on component is the
type manager [Indulska93], [Vogel95a], [Meyer96], [Puder96]. The type manager is used to
Page 43
manage service types and interface types. It stores types and type names as well as the
relationships between types, and is able to compare types and determine compatibility between types. During export operations, the type manager ensures that an exported service
offer’s service type is known and that the exported service properties are valid. During import operations it ensures that a requested service type is known and that the requested
service properties are valid. Furthermore, it is used to find a list of compatible service
types - called sub-types - which might fit the importer's requirements. Equivalence between service types means that the interface types and service properties are semantically identical although having different names. Detection of equivalence between service
types is the aim of artificial intelligence-based type management systems.
The use of traders specifically for supporting mobile users and applications has been reported in [Chang93], [Davies95a], and [Redlich96]. Problems that arise when mobile service
importers and exporters participate in trading have been discussed in [ Böttcher94]. Several
implementations of traders on different platforms have been developed in the last years,
many of them being X.500-based. The use of X.500 directory services for building trading
services was explored in several projects, e.g. in Y [Popescu91], Melody [Kovacs92],
[Kovacs94], the work of Richman and Hong [Richman95], and the work of Pratten et al. [Pratten95]. The use of X.500 services as part of the DCE environment for building traders was
explored in the TRADE project [Müller95b], and in X* [Funke95]. The ODP trader standards
[X.952] define one approach of how an X.500 directory can be used as static data repository for implementing a trading function. All known X.500-based solutions use X.500 as
repository for static service properties and build additional functionality around it to provide
support for dynamic properties and to perform selection of optimal service offers. In the
ODP standards for example, a special Trader-Directory User Agent is proposed that shall
obtain dynamic properties and evaluate selection criteria.
1.11.1.3 Resource and service discovery
Work being conducted in the area of resource and service discovery augments the functionality of a service broker with mechanisms to detect the existence and location of the
service broker without pre-configured knowledge. This is important in mobile computing
environments, where terminals roam into realms of brokers other than those used at
home. Eliminating pre-configured knowledge allows mobile applications to discover and
make use of network services in any network they can connect to.
The Service Location Protocol (SLP) provides a flexible and scalable framework for providing hosts with access to information about the existence, location, and configuration of
networked services [Guttman98]. Client applications are modelled as user agents, service
providers as service agents, and the broker function is called directory agent. The user
agent issues a service request specifying the characteristics of the service the client requires. The user agent will receive a service reply specifying the location of all services in
the network, which satisfy the request. User agents may issue the request directly to service agents, using a multicast message. In this case, the user agents receiving the request
for a service which they had advertised send the service reply via unicast to the client. To
provide scalability of the protocol in larger networks, one or more directory agents may be
employed as cache. Service agents send register messages to the directory agent to ad-
Page 44
vertise their services. These are kept for a limited time. Therefore, advertisements must
be periodically repeated. User agents knowing a directory agent may now send the service
request as unicast to the directory agent and will receive service reply messages.
Services advertised via SLP are described by Uniform Resource Locators (URL) [ Guttman98a]. These URLs contain a service type, the advertised service address, and optionally a number of descriptive attributes. Service types specify the kind of service and therefore potentially map to multiple advertised services. Clients may make use of attributes to
specify more precisely the service instance they are looking for. Since the functionality offered by the directory agent is very similar to that of existing directory services, an approach for mapping SLP directory agent data onto LDAP directory entries has been suggested [StPierre98]. The detection of directory agents by user and service agents can be
achieved with multicast messaging or by means of DHCP as explained below.
The Dynamic Host Configuration Protocol (DHCP) [RFC2131] has been developed [Perkins96], [Guttman98] as a mechanism to configure hosts dynamically without manual intervention. DHCP provides configuration parameters to Internet hosts and consists of two
components: A protocol for delivering host-specific configuration parameters from a DHCP
server and a mechanism for allocation of network addresses to hosts. Clients discover
DHCP servers by broadcasting a dhcp-discover message to their local subnetwork. Each
DHCP server receiving this message may respond to the client, offering an available network address. The client may then select one server and issue a dhcp-request, identifying
the configuration parameters it is interested in. The DHCP server then provides the requested parameters.
SUN Microsystems has developed a Java Infrastructure for the Internet, called Jini [Waldo98].
Core ingredients of Jini are lookup and discovery mechanisms that allow clients to discover services, both implemented as Java objects. The broker function is called lookup
service and is used to register and retrieve objects very similar to a trading service. It is,
however, smoothly integrated into Java, since it provides object references for immediate
use of the server through smart proxies or through Remote Method Invocation (RMI) calls.
The discovery mechanism of Jini is based on multicast protocols used by clients to discover unknown lookup servers and by new lookup servers to announce their presence to
clients and servers. A competing approach to resource discovery is Universal Plug and
Play (UPnP) intended to enable home networking that is pushed by an industry consortium formed around Microsoft [UPnP-Forum00]. UPnP is centred around a set of Internet
standards that realise a Simple Service Discovery Protocol (SSDP) [Goland00] and make
use of XML [XML1.0] documents to exchange resource descriptions between servers and
clients. SSDP is based on multicast IP messaging and allows peer-to-peer discovery without central lookup servers.
1.11.2 Support for disconnected and partially connected operation
In cases where the terminal's network connection completely disappears, e.g. because the
mobile user leaves the wireless network's coverage area, it should be possible to continue
execution of those applications that might cache data locally - if they know in advance that
Page 45
they will lose their on-line connection. The task of mobility support functions is to enable
so-called disconnected operation. Often the connection does not disappear completely but
becomes very slow. Mobility support functions may enhance application performance on
such so-called partially connected terminals as discussed in the following. We differentiate
in this section between support techniques for handling data and for handling connections.
1.11.2.1 Data management
Supporting mobile users that intermittently disconnect with their portable computer from
the network was pioneered in the CODA file system [ Kistler92], a successor of the Andrew
file system [Howard88]. The initial aim of CODA was to support mobile users that had
planned disconnection, e.g. before disconnecting a laptop from a network. Recent extensions to CODA also cope with situations where users are involuntarily disconnected and
where they are only connected over a slow network, the latter being called partially connected operation. The basic mechanism of CODA to allow disconnected operation is
whole-file caching. During connected operation, and especially before voluntary disconnecting, a CODA client caches files of interest in a process called hoarding. Using a callback mechanism, clients are informed about cached files being invalidated by update operations from any client. While being disconnected, a client can operate on the files it has
in its local cache. Accessing a file that is missing in the cache results in an error. In this
mode CODA employs an optimistic caching scheme, allowing clients to modify files in their
local cache. All write operations are logged and are replayed on the server’s central file
copy after reconnection in the reintegration phase. If write conflicts occur because of write
operations by more than one user, the user is notified and must reconcile the conflicts.
Partially connected operation optimises the performance of disconnected operation by
performing reintegration phases in the background. All operations on cached files are performed locally. Additionally, if a user accesses a file that was not cached, it is retrieved
over the wireless link, thereby enhancing file availability [ LaPorta96]. Another extension to
Andrew for supporting partially connected operation with similar design principles to those
of CODA was presented in [Huston95].
Aggressive caching and optimistic replication are the common mechanisms of systems
trying to support disconnected users. Several other file systems with support for disconnected operation have been developed. Examples are Echo, Deceit, Locus/Ficus, and the
work of Columbia University [Tait91a]. DOC is a client-side file system cache supporting
disconnected and partially disconnected operation, which was designed to work with already existing non-mobile file systems [Huizinga95]. An overview of replication mechanisms
being employed in those systems can be found in [ Helal96]. The work of CODA was used
at Karlsruhe University [Kottmann95] to provide generic disconnected operation support for
(C++) objects. Considerable work on disconnected WWW browsing has been performed,
usually consisting of a proxy web server on the mobile host acting as local cache for
WWW pages and as queue for requests that could not be served from the cache or which
submit forms to servers. Examples of such work are the ARTour/eNetwork Web Express
system [Chang97], [Floyd98] and the work on pre-fetching of web pages at University of California [Jiang98].
Page 46
At Xerox PARC, the Bayou replicated data manager has been developed for handling replicated data in mobile and intermittently connected environments [ Terry94]. Bayou is a platform of replicated, highly available, variable-consistency, mobile databases on which collaborative applications may be built. It offers application-specific conflict detection, called
dependency checks, and allows the application to have control over the offered consistency degrees. Bayou's anti-entropy protocol for update propagation between weakly consistent replicas is based on pair-wise communication that tolerates low bandwidth links
and temporary disconnections [Peterson97].
1.11.2.2 Connection management
To handle the annoyances of wireless links providing only weak connections to applications, the use of proxies at transport and application layer levels has been suggested as
support functionality in mobile computing environments. Proxies have been suggested
[Brewer98] to mediate service requests from mobile clients, cache service requests and
their results, re-transmit messages in case of errors, and perform security functions [ Hesselmann95], [Richter96]. SNOOP is a proxy-based protocol for improving TCP performance
over wireless links by caching and re-transmitting packets without intervention of the fixed
network parts [Balakrishnan95]. The Rover mobile application toolkit [Joseph97] implements a
non-blocking remote procedure call allowing asynchronous object invocations in order to
prevent synchronously communicating mobile applications from blocking, when parts of
the infrastructure are not connected.
1.11.3 Support for migratory applications
Two research areas on support for migratory applications shall be briefly presented here:
Window migration and mobile code. The advantage of window migration techniques over
mobile code is that the user’s application can be redirected very quickly onto any nearby
computer in the same state as the user left it without having to save and transfer the
whole application code and execution state. The disadvantage is the need of a fast network connection between the current computer and the application host to exchange user
input and application output. A further disadvantage is that window migration does not allow applications to adapt themselves to varying terminal properties, since mobility is hidden from the applications.
1.11.3.1 Window migration
The Teleporting system was developed at Olivetti Research [ Bennet94] with the aim to allow
mobile users to make temporary but personalised use of stationary computers. The system enables users to interact with their existing X Window applications running on any
computer by redirecting its output to the user’s current location. The system consists of a
special X server, called proxy server, redirecting the X protocol communication between
the application and its current real X server to any other real X server, as required by the
mobile user. The original system limited application mobility to computers running an X
server. A new version of the Teleporting system has been developed [Wood97] that allows
X sessions to be redirected to any Java-enabled computer. This is enabled by an applet
Page 47
that displays the user’s X screen content in the browser and intercepts all user input and
sends it to the X application as if the user was local.
1.11.3.2 Mobile code
Telescript was among the first interpreted languages with built-in dedicated migration capabilities for constructing mobile agents. Telescript technology was designed primarily with
the electronic marketplace in mind and consisted of a high-level procedural agent programming language and an interpreting engine. Meanwhile, General Magic has replaced
its Telescript agent environment with a system called Odyssey [ GenMagic97], being implemented in Java but based on many of the Telescript principles. Another example for a
mobile agent framework based on Java is IBM's Aglets system [ Lange98]. The Visual Obliq
environment was developed to support the migration of arbitrary user interface applications for allowing user mobility [Bharat95]. It has built-in support for check-pointing the state
information of the user interface and rebuilding it on another computer running an Obliq
scripting language interpreter.
Redirecting multimedia communication sessions from one place to another by means of
mobile agents was developed in [Bates96], [Bacon97]. So-called multimedia endpoints realised as mobile agents can move to a mobile user’s new location while preserving their
user interface and their state. The system was used in conjunction with a locating system
to allow users participating in audio- and video-conferences to roam while automatically
carrying their communication session with them. To allow mobile users to interact with local services in unknown terrain in an ad-hoc way, [Hodes97] proposes to use mobile code
for user interfaces in conjunction with service discovery. The system dynamically
downloads appropriate user interface code written in Tcl/Tk onto the mobile terminal. In
this way, mobile users can interact with previously non-configured services, e.g. to interact
with local audio/video equipment.
1.11.4 Support for adaptive applications
There are two main groups of support for adaptive applications: Support for providing information about the application’s current processing and communication environment and
support for reducing dynamically the application’s processing and communication requirements in response to changes in the environment. In the first group, we mainly find
development work on so-called profiling services, offering the application facilities to be
informed about status and changes in processing and communication resources, and
quality-of-service management, providing applications with information about the current
throughput and service quality of communication links. In the second group, mainly developments in the area of content reduction can be found, trying to reduce the content being
transferred over the communication link.
1.11.4.1 Profiling services
System support for adaptive applications provides means to inform applications about current status and changes of their surrounding environment, such as available network con-
Page 48
nection, available power supply, display type, or network services. Responsibility for adaptation is usually left to the application itself. Applications running in a web browser may for
example access environment variables describing some of the system characteristics, but
a generally usable solution requires the provision of a profiling service from which every
application can retrieve the desired information about terminal and communication network capabilities. One example for this approach was developed as part of the Odyssey
system [Noble95] an experimental Unix platform for mobility. It allows an application to register its interest in a system resource, which is then monitored by the operating system.
Upon changes that exceed a defined tolerance window the application is informed and is
then responsible for adapting itself to the new conditions. Another approach to this problem was presented in [Schilit93], called dynamic environment variables. These variables are
used by applications like static environment variables. The difference is that they are not
only interpreted at application initialisation time but during their whole lifetime. Changes in
the environment represented by the variables are detected by dynamic environment servers, which update the variables accordingly. Applications having subscribed to a variable
are asynchronously informed about changes in the variable's value to trigger application
adaptation.
The aforementioned approaches were operating system-dependent and did not provide
general support for adaptation in heterogeneous environments. An example for operating
system-independent support of adaptive WWW browsing is presented in [Freytag98]. A resource information base was developed, storing user and terminal profiles, that are used for
adapting the filtering of HTML pages to make them accessible over wireless links. The
proposed user and device profiling service is an independent but centrally running process
interacting with the WWW browser and the content filtering applications. Another example
is the Application Configuration Access Protocol (ACAP) [ RFC2244] that has been developed by the IETF to let users access their configuration data from any network-connected
computer. ACAP suggests a tree-based data model with entries storing attributes with
relevant information. ACAP re-invents many aspects that already exist for directory services. It adds facilities for clients to be informed about modifications on the data held in an
ACAP server, a feature that is not supported in today's directories.
1.11.4.2 Quality-of-service management
Quality-of-service (QoS) in multimedia communication networks is a research topic that
found much attention. Research copes with the problems of negotiating and mapping
[Jung96] QoS parameters at connection establishment performed by so-called QoSManagers [Sreenan96], -Brokers [Nahrstedt95] or -Negotiators [Fry97], and with guaranteeing
QoS parameters during system operation by means of system resource reservation and
scheduling algorithms [Aurrecoechea95], [Campbell94]. Most of the issues in QoS management encompass all communication layers and the operating system internals. An overview on QoS architectures can be found in [Aurrecoechea95] and [Campbell96].
The ideal aim of mobility support functionality would be to guarantee the provision of the
application’s quality of service requirements concerning bandwidth, delay, jitter, etc. independent of the application’s mobility. However, in wireless environments, this aim is in
general not realistic. For example, unless the required radio resources are reserved in all
Page 49
surrounding wireless network cells, a connection might be handed-over into a cell in which
the resources required to offer the previously guaranteed QoS do not exist. Within certain
limits, it would be possible to assign priorities to applications and to sustain QoS for applications with high priority while reducing QoS for others. Even this would not suffice for
heterogeneous environments, where connections may be handed over between different
network types, e.g. from GSM to DECT. Furthermore, fading connection quality due to radio interference or weak radio coverage can never be avoided completely. Therefore, for
mobile applications more applicable research on QoS management is dedicated to inform
applications about changing QoS conditions to initiate application adaptation. Pioneer
work in this area was developed in the course of the MOST project at Lancaster University
[Davies94]. It extended the ANSAware platform with mobile multimedia communication capabilities, offering QoS management and application adaptation support. The system supports callback functions to inform an application when the delivered communication QoS
falls below a specified threshold. Other approaches for QoS management in the context of
adaptive mobile communications were developed as part of the CORBA-based Mobiware
toolkit [Angin98], [Liao98], [Campbell99] and in [Inouye97], [Srivastava97], [Bhagarvan98].
1.11.4.3 Content reduction and conversion
Much research has been dedicated to the problem of delivering content to mobile hosts
over resource-poor wireless links. In order to reduce transmitted content, and thereby
communication bandwidth requirements, filtering of content (i.e. deleting selective parts),
compression of content, and conversion of content into less demanding formats have been
suggested. Most approaches make use of a so-called proxy to perform the content processing in the fixed network. The proxy is a server representing the mobile application in
the fixed network infrastructure. This has the advantage that existing services do not need
to be changed when wireless terminals are introduced. Furthermore, there might be multiple different content processing algorithms for different terminals so that this function is
better separated from the content server [ Hokimoto96a], [Zenel97]. Another technique sometimes employed on the mobile terminal itself is pre-fetching of data to decrease latency of
service requests. However, this does not solve the bandwidth problem, even to the contrary, due to unnecessary pre-fetches that problem may even be aggravated. WebExpress
uses proxies for reducing HTTP protocol overhead with connection multiplexing, caching,
and differential transmission of content [Housel98].
Content filtering and compression was investigated mainly for wireless WWW browsing
and wireless continuous media such as video streams. Examples for projects working on
HTML filtering and (image) compression are [Han98], [Freytag98], [Fox98]. Work on filtering
content streams for mobile devices was for example performed in the Mobiware project
[Balachandran97] for MPEG, H.261 and motion JPEG coded streams. Media scaling is
achieved by so-called active filters, being written in Java, and dynamically inserted into
base stations and network switches. Filter insertion is done during handoffs or QoS degradations, so that the user does not perceive it. Media scaling in terms of image size and
frame rate has been presented in [Hess96]. In some approaches, content being delivered
to a mobile terminal is converted into another - less demanding -presentation format. An
example is content distillation from a resource-consuming format like PostScript into HTML
to avoid the necessity of a PostScript viewer on the mobile host [ Brewer98].
Page 50
1.12 Location-aware applications
Since several competing positioning technologies are emerging and no single technology
is suitable for all potential application environments, the main task for useful application
development support is to abstract from the used locating system and to present the application developer with a technology-independent locating model. Based on such a
model, services for the on-demand retrieval of location information and the definition and
autonomous observation of location-related events should be offered to the application.
The support functionality to be provided can therefore be characterised as location database function and location event handling function that obtain their information from the
positioning infrastructure. Another useful technique is a navigation information server
providing graphical maps and routes to applications offering navigation support in indoor
or outdoor environments.
1.12.1 Support for single locating technologies
A location server for the Active Badge System was described in [ Harter94]. It is divided into
a name server to lookup badge and location identifiers, and a location server, maintaining
and caching the actual location information of active badges. An exchange server is responsible for distributing the information between organisations and for enforcing appropriate access control. The system was implemented on the ANSA platform. A CORBAbased implementation of an object-oriented software layer for the Active Badge System
has been developed [Szymaszek98]. The system offers event services based on a lightweight notification mechanism realised with so-called smart proxies, being part of the Orbix Object Request Broker used in the implementation.
1.12.2 Locating technology-independent support
In the context of the PARCTab system, architectural proposals for a general location service have been developed, and many applications and experiments have been implemented [Elrod93], [Schilit94a], [Want95]. The Active Map Server (AMS), presented in [ Schilit95],
publishes information about so-called located-objects. Location information is collected
and updated in the AMS by user agents. The AMS offers pull and push information retrieval methods and represents locations in a hierarchical containment tree, consisting for
example of building, floor, room. Representation of located-object information was done
with self-describing attribute-value pairs. This allowed representing any information of interest in the system. Some attributes such as location were pre-defined and must be present in every located object. No schema publishing and enforcement functionality was offered which was identified as problem for exchanging information between applications.
[Schilit94] discusses communication issues of pushing location update messages from the
AMS to multiple clients. To reduce communication overhead of sending individual messages to every subscribed client, the usage of multiple multicast channels is proposed.
Each channel is used for a group of clients being interested in the same type of location
update events. The problem is then the detection of "compatible" subscriptions issued by
Page 51
different clients, which was solved by offering pre-structured subscriptions from which the
clients can choose. Another concept was to allow a client to specify the maximum bandwidth it is accepting for location update messages to avoid communication overload conditions on simple client terminals.
Architectural considerations for security and scalability issues related to providing location
information for mobile computing applications have been presented in [ Spreitzer93],
[Spreitzer93a], and [Spreitzer94]. A user-agent-centric architecture is suggested as being capable of guaranteeing a useful degree of privacy when one assumes that some location
servers may not be trustworthy. The authors mandate the provision of a "heterogeneous
system" approach, where individual users can operate the location service in a moded
fashion, so that individual privacy models can be enforced by the location system. They
introduced the notion of uncertainty regarding location information, meaning that invisible
people might be present (because they do not want to publish their presence) and that
services returning information about nearest objects only give hints.
Rizzo [Rizzo94] proposes a Master Location System (MLS) that acquires location data from
multiple slave positioning infrastructures. When the location of a user is requested from
the MLS, it interrogates its slave systems controlled by a locating policy that may be dependent on the user being located to reflect personal habits. The system always returns a
confidence value indicating how reliable the location information is expected to be. Representation of locations is done in a location directory storing a list of attributes having
names and values for each location. This directory is used to correlate data from different
sources and to store the personal locating policies. Implementation of the approach was
performed on ANSAware.
Leonhardt [Leonhardt98] proposed to use a hierarchical location model that integrates location data from heterogeneous location infrastructures. A symbolic location model is used
that maps position data from multiple sources to hierarchically nested areas. He discusses
algorithms to use the hierarchical model to detect conflicts between data from multiple positioning sources and to solve overlapping information to determine the most useful position information. Interpolation of uncertain sightings and provisioning of security features
for location services was discussed. To support wide-area locating, the concept of federating locating services by means of centralised directory services was proposed, but no solutions to this problem have been provided. Additionally, the problem of users roaming between positioning infrastructures and the required cooperation between distributed location infrastructures and the directory service have not been solved.
Supporting mobile applications by means of an Active Mobile Database System has been
proposed in [Murase98]. An event-condition-action rule mechanism with two dedicated
events, "appear" and "disappear", has been realised. A mobile host may define events
that trigger when the mobile terminal changes its radio cell. The database evaluates the
event condition when the event triggers and executes an action or notifies the application
when the event-related condition is fulfilled.
The aim of the recently started Nexus project [Hohl99] is to develop a generic platform for
location-aware systems. So far, the problems of replicating and distributing location information between location servers have been addressed. Analytical evaluations of different
Page 52
location replication schemes from a source to a secondary location server [ Leonhardi99] and
different location information distribution approaches - location server per located object or
location server per observed area - [Kubach00] have been performed.
1.12.3 Support for fine-grained location information
Nelson [Nelson95] suggests the approach of using the concepts of temporal and spatial colocation together with so-called spheres of influence as underlying paradigms for structuring
data and queries. The need for complex queries covering spatial as well as non-spatial
data is discussed, and a hierarchical information gathering scheme from multiple location
sources is proposed. Implementation of the system was done based on a POSTGRES database. [Nelson98] describes a system architecture capable of handling fine-grained location information and supporting simple and composite event types. The simple event types
are dependent on the used location and context sensors, such as e.g. 'door opened' or
'door closed', and a set of operators constructing composite events is proposed. All application interfaces are implemented as CORBA IDL interfaces. A proprietary database system was implemented that stores all information in main memory. In contrast to other approaches, located-objects have a physical extent and an orientation that is observed by
the spatial matching algorithms to determine physical presence, proximity, and facing between objects. As fine-grained locating system, the ultrasonic Active Bat technology was
employed in addition to Active Badge, door position, workstation activity, and telephone
handset position sensors.
An approach suggested in [Wachowicz96] is to use a specialised spatio-temporal database
to store a three-dimensional model of all locations of interest and include the actual position data acquired by the locating system. The advantage is that this approach allows using the spatial indexing and query features of the database to retrieve the required information. The used database also support event monitoring capabilities. A similar approach
of maintaining a spatially indexed database is employed in the SPIRT project [ Adly97] to
manage fine-grained location data from Active Badge and Active Bat systems. The system
was implemented on an Oracle 7 database being extended with a spatial indexing component communicating via shared memory with the main database server.
1.12.4 Support for navigation
Several research institutes and companies have developed support for providing maps
and navigation information to applications for outdoor environments building on the popularity of GPS receivers. Two types of information must be distinguished, maps and waypoints. Maps are graphical images constructed from bitmap or vector graphics and may be
displayed to a human user for obtaining information about his or her surroundings. Most
systems have coordinate information included in the maps that are compatible with absolute position information obtained from GPS receivers. This allows an application to display a user's current position on a map. Since maps consist of large amounts of data, they
were formerly mainly distributed by means of CD-ROMs, recently a number of on-line services emerged that allow downloading map information from Internet servers. This ap-
Page 53
proach was e.g. followed in the OnTheMove project [Kreller98a] for providing maps to tourists on a mobile terminal.
Waypoints define points of interest and consist of a type field, waypoint name, positional
information (e.g. latitude and longitude), timestamp, and usually an associated name.
Waypoints may be used to draw streets onto maps and to calculate routes between two
waypoints. By combining maps with waypoints, graphical navigation support may be offered to applications such as car or nautical navigation systems. An overview on map and
waypoint databases and services can be found in [ Wormley00].
For navigation support in indoor environments, prototypes have been developed by
aforementioned research projects on location-aware applications and commerciallyavailable products recently appeared [Executone00], [PinPoint99a]. Indoor navigation support
is usually limited to displaying maps of the rooms inside a building and overlaying the
room-grained positions of located objects and persons, e.g. in [ Harter94], [Leonhardt98]. Providing navigation and maps on location-dependent HTML pages was discussed in Mobisaic [Voelker94]. Such approaches have the advantage that existing HTML browsers can
be used on the client terminal for displaying information. Displaying fine-grained location
information using 3D VRML (Virtual Reality Markup Language) models of buildings was
jointly developed by Olivetti and Oracle Research [ Ward97], enabling not only to present
position but also orientation of a located object inside a room. Provision of navigation information inside large buildings by means of visual, audible, or tactile signals and by displaying information on PDAs was the aim of the Ariadne Project [Foster97].
1.12.5 Other support
A combination of mobile agents with location-ware technologies is proposed in [Bates96]
and [Bacon97]. The aim is to enable mobile agents to migrate to a user instead of migrating
to a host. A location-awareness subsystem has been developed that contains a database
storing location data and other useful information about locations, such as available computer equipment. Location information is acquired by an Active Badge system and retrieved in an event-driven manner from locator objects. The locating model is fixed and
consists of rooms. The system was mainly used to control the routing of multimedia communication streams between mobile users, similar to the idea of the teleporting system
[Richardson94].
The use of multicast groups that represent physical locations to exchange information between senders and receivers dependent on their location was proposed as part of the
DataMan project [Imielinski97]. Sender and receiver determine their position via GPS
equipment and use this information to select an appropriate multicast group. In this way
information exchange happens only between entities choosing the same group. The system was implemented to let users specify in their WWW browser which servers they want
to contact, e.g. only those inside the same building.
To manage communication between two or multiple parties based on their awareness of
each other, a spatial awareness model is used in [Greenhalgh98]. Interested parties register
their video or audio auras that define the space in which interaction may occur with a spaPage 54
tial trader. The trader detects aura collisions between parties and informs them so that
they can initiate interaction with each other. The interesting aspect in this work is that it extends the aspect of location with focus, defining the area of interest for a certain medium,
and nimbus, representing the wish to be perceived over a certain medium.
1.13 Analysis
This section analyses the mobility support techniques presented in this chapter concerning
their relevance for different mobile application requirements and discusses shortcomings
of the existing solutions that may be solved with the Open Mobility Platform. These discussions provide the basis for identifying which support techniques should be incorporated
in the Open Mobility Platform specification developed in chapter 0.
1.13.1 Mobility abstraction levels
To enable a summary of the inventory of mobility support techniques made in this chapter,
we identified four mobility abstraction levels that classify the degree to which mobility of
users and terminals is seen by applications. The abstractions distinguish between mobility-transparent, mobility-robust, mobility-aware, and location-aware applications. An application does not necessarily fall into exactly one of the four categories but may make use
of arbitrary combinations of the mobility abstractions. The identified mobility abstraction
levels are summarised in Table 1.
Abstraction
level
Operational phase
Support technique
Described in
Mobilitytransparent
establish connections
directory,
trader, broker
1.11.1
maintain connections
proxy, cache, data
synchronisation, QoS
manager
1.11.2 and
1.11.4.2
obtain information about
environment
profiling service, event
service, QoS manager
1.11.4.1 and
1.11.4.2
perform adaptation
content reduction,
trader, type manager
1.11.4.3
1.11.1.2
locate or register mobile user or terminal
location database,
directory
1.10.2 to
1.10.5,
1.10.1
obtain or update profile of user or terminal
profile database,
directory
1.3.1, 1.3.2,
1.10.1
obtain location information
location database,
location event handler
1.12.2 and
1.12.3
obtain navigation information
map / waypoint server,
route calculator
1.12.4
Mobilityrobust
Mobilityaware
Locationaware
Page 55
All levels
find support services
resource discovery
1.11.1.3
control access to support services
Table 1: Summary of mobility abstraction levels
Mobility-Transparent
This mobility abstraction level completely hides the effects of mobility from mobile applications and users. During connection establishment, network services and resources
can be transparently accessed. During connection lifetime, an application-defined quality-of-service for the underlying network connections can be sustained in spite of mobility. If connections fail, data availability and consistency of replicated data are ensured.
Useful support techniques required for this mobility abstraction during connection establishment are directories, traders, and brokers, as described in section 1.11.1. The application may use these support techniques to find and access services and resources at
unfamiliar network sites. During connection lifetime, useful support techniques are proxies, caches and data synchronisation managers for disconnected and partially connected operation, as described in section 1.11.2. Support techniques above the transport layer will probably not be able to guarantee an application-defined QoS-level in the
presence of terminal mobility, as argued in section 1.11.4.2.
Mobility-Robust
This mobility abstraction level allows mobile applications and users to tolerate those effects of mobility that cannot be hidden by lower layers. Mobile applications may see
mobility effects as varying terminal characteristics and changing network performance.
Reasons can be congestion of radio cells, degradation of radio link qualities or change
of terminals in case of migratory applications. Mobility-robust applications tolerate these
effects by adapting themselves to the changing environment.
Relevant support techniques for mobility-robust applications to obtain adaptation
knowledge are profiling and event services to obtain information and event notifications
about the environment's properties, as described in section 1.11.4.1, as well as qualityof-service managers informing about variations in communication link properties, as described in section 1.11.4.2. Useful support techniques to react to changing environments are content reduction functions to reduce communication requirements, as described in section 1.11.4.3, as well as traders to invoke alternative network services with
less demanding requirements, as described in section 1.11.1.2.
Mobility-Aware
This mobility abstraction level allows applications to be aware of the mobility of users
and terminals. Mobility-aware applications see mobility effects at the granularity of
changing network addresses and points of attachment. To realise user and terminal
mobility, a suite of mobility-aware control services realising mobility management services must be deployed in a network.
Required support techniques include location databases for handling location data
about mobile terminals and users, as described in sections 1.10.2 to 1.10.5. Also rePage 56
quired are: Profile databases for handling subscription profiles and replicating data near
to the mobile user similar to the HLR/VLR approach, as described in sections 1.3.1 and
1.3.2. Finally, directory services for retrieving location and profile data in the distributed
databases using the user and terminal identifiers are required to enable lifelong personal numbering, as described in section 1.10.1.
Location-Aware
This mobility abstraction level allows applications and users to be aware of locations
and location changes caused by mobility. Location-aware services see mobility effects
at the granularity of absolute or relative physical locations or spatial distances between
real-world objects. This abstraction level allows applications to query location information and react upon location-related events.
Relevant support techniques for location-aware applications include location databases
and event handlers being independent of the used locating technology and offering location retrieval and location event handling features, as described in sections 1.12.2
and 1.12.3. For location-aware navigation applications, support techniques for retrieving
graphical maps and calculating routes and distances, as described in section 1.12.4,
are useful.
For all mobility abstraction levels, resource discovery support, as described in section
1.11.1.3, is required to allow a mobile application to discover the support services being
available at an unfamiliar network site in the first instance. Additionally, for all abstraction
levels support techniques ensuring access control onto data and services are required, as
described for some of the support techniques in the previous sections.
1.13.2 Opportunities for improving mobility support
Although several individual mobility support techniques have already been developed as
presented above, the Open Mobility Platform has the potential to provide significant advantages to its users by combining support services into a homogeneous architecture.
Shortcomings of the solutions developed so far are:
No consistent approach for supporting mobility in future mobile networks with integrated
voice and data services exists today, since different research communities performed
development of mobility support for telecommunication and computer networks as
separate issues. As an example, user and terminal mobility support in computer networks offers similar functions like in telecommunication networks but uses noncompatible technologies for subscriber data management.
Research work on mobility management so far concentrated on the identification of theoretically optimal database architectures for personal numbering and location tracking,
although the optimal configuration depends on numerous - and often unknown - technical and behavioural factors. Instead, a flexible and customisable mobility platform is required that may be adapted to different environments and mobility patterns.
Previous work was dedicated either to mobility management or to mobile application support, leading to similar but inconsistent concepts for location and profile handling of mobile terminals and subscribers. As an example, development of location-aware call-
Page 57
forwarding applications and development of mobility management services for user and
terminal mobility would benefit from a common support environment offering a consistent application framework.
The emerging mobility support techniques such as profiling services, trading services, location databases and event handlers, do not offer homogeneous functional architectures, data models, services, and APIs. Application developers requiring support from
multiple functions are confronted with a variety of models and services.
Deployment, configuration, and management of the support functions employ proprietary
and non-consistent approaches for the different functions. The same holds for security
and access control to different support functions.
Most mobility support functions have been developed as hard-coded services, which are
not easily customisable by its users concerning their functionality and data models.
Such support functions are restricted to few application environments only and cannot
adapt to evolving user requirements.
Directory services and hierarchical data models have been employed in several approaches to be used as naming and address resolution service. However, no attempts
to make use of directory information models and access services for homogeneous
mobility information management have been made. A systematic inventory of functional
requirements on directories and the subsequent development of additional directory
features - with special attention to the integration of dynamic information into directory
services - are open issues that are approached by our research.
Relatively little work was done for supporting mobility in multi-site campus-area environments, compared with the efforts spent on enabling wide-area mobility. However, investigations into the mobility of the professional workforce in the US and in Europe indicate
that most mobility takes place in the immediate vicinity of the workplace, i.e. within the
building and on the campus.
1.14 Summary
This chapter has reviewed in detail the state-of-the-art in mobility support techniques for
mobility management services, mobile applications, and location-aware applications. The
aim of this chapter was to identify a list of potentially useful support techniques from which
we may derive the functionality to be provided by the Open Mobility Platform. To analyse
the applicability of the proposed techniques, we classified mobile applications into four
categories called mobility abstraction levels. The categories define to which extent effects
caused by mobility are seen by the application. For each mobility abstraction level, the
chapter has identified which support techniques are relevant in different operational
phases. This analysis is used in chapter 1.21 to specify which support services are offered
by the Open Mobility Platform. Additionally, the review of mobility support techniques revealed several shortcomings of existing support techniques. A major improvement would
be to provide an integrated, homogeneous, customisable information and service model
across different support techniques. This finding is consistent with the aims of this thesis
to realise an Open Mobility Platform on a homogeneous directory-based information
model. Before we specify the Open Mobility Platform in chapter 0, we present in the next
Page 58
chapter an introduction to the capabilities of X.500 and LDAP directory services as specified by the current ITU-T and IETF standards.
Page 59
LDAP/X.500 directory services
This chapter introduces the standardised LDAP and X.500 directory features and specification techniques that are used in the following for the development of the Dynamic Directory Services. The X.500 recommendations define the information model elements,
whereas the LDAP standards define the access services and protocols used as basis for
our work. The chapter also briefly presents some recently proposed LDAP extensions that
are of relevance.
1.15 Introduction
The X.500 set of recommendations [X.501] standardises a distributed directory service as
OSI layer-seven service and protocol. A Directory System Agent (DSA) offers the directory
service to the Directory User Agent (DUA), representing an application or human directory
user. The DSA offers a number of standardised services to add, retrieve, modify, and delete the directory information by means of 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 cooperating 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.
Two interaction principles have been defined as depicted in Figure 10:
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.
DSA
DAP
DUA
DSP
chaining
DSA
DSA
DAP
DUA
referral
DAP
DSA
Figure 10: X.500 distributed directory model
Although the X.500 recommendations are commonly accepted as standard distributed directory, its widespread usage was hampered by the complexity of the OSI upper layers
and the complexity of the X.500 model. Excellent introductions to the 1993 edition of the
X.500 recommendations can be found in [ Steedman93] and [Chadwick95]. The latest edition
of X.500 recommendations was published by ITU-T in 1997; it added only minor functional
aspects and administration functions using Systems Management to the 1993 edition. The
Page 61
IETF decided to define a Lightweight Directory Access Protocol (LDAP) [ RFC1777],
[RFC2251] with the aim to provide “90% of the X.500 functionality at 10% of the costs”
[Howes97].
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.
 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. Accordingly, it was based on LDAP-to-X.500 gateway servers, see Figure 11. Meanwhile, most
X.500 servers natively support LDAP, and pure LDAP servers have been developed (see
also section 1.34.1) which helped LDAP to become the de-facto standard directory service
used in the Internet.
X.500
DSA
LDAP
client
LDAP
gateway
LDAP gateway
LDAP
server
LDAP
client
X.500
DSA
native LDAP servers
LDAP
server
Figure 11: LDAP gateway and native server
The latest version of the protocol is LDAPv3 [ RFC2251], in the following called LDAP. The
associated IETF RFC documents are at the time of writing in status Proposed Standard,
they are in the following referred to as standards. The LDAP protocol operations can be
mapped on a strict subset of the X.500 (1997) directory abstract service [ X.511], however,
there is no one-to-one mapping. The data model employed by the LDAP directory services
is that of X.500 directories, as specified in [ X.501]. The LDAP standards prescribe the
minimum X.500 data model to be supported by LDAP servers, e.g. in [ RFC2252], but generally do not pose limitations to the X.500 information model being accessible with LDAP.
1.16 LDAP/X.500 information model
The information held by LDAP servers is organised in a Directory Information Tree (DIT)
which is made up of entries that consist of sets of attributes. Each attribute may have one
or more associated values. Entries have names that are used to identify and find entries in
the DIT. One or more attribute values of each entry form its Relative Distinguished Name
(RDN), which is unique among all its siblings. An entry's Distinguished Name (DN) is made
up of the concatenation of the RDNs from the entry itself up to the immediate subordinate
of the root of the tree. A DN is thereby unique inside a DIT and unambiguously identifies
an entry.
Page 62
There are three types of entries:
Object entries represent the user information to be stored in the directory.
Alias entries provide alternative names for object entries. The directory may automatically
replace an alias entry with the entry it provides an alternative name for; this is called
alias dereferencing.
Subentries represent information for administrative and operational requirements of the Directory. Subentries are not returned to directory clients unless they are explicitly requested.
The DIT does not have to be mastered by a single LDAP server but may be distributed
over multiple servers. The granularity of information distribution is a naming context. It is
the largest collection of entries managed by a single server starting at any entry and including all its subordinates, down to entries that are mastered by another server. A particular server may hold one or more naming contexts. The root of the DIT is no real entry,
it is a so-called DSA-Specific Entry (DSE), in this case the root DSE. It has a zero-length
DN. Each server has different attribute values in the root DSE, it is used by clients to obtain information about a particular server by issuing a search for the root entry. One kind
of information held in the root DSE is the DNs of subschema (sub-)entries which administer knowledge about the directory schema enforced in a particular part - called administrative domain - of the tree. Additionally, information about the naming contexts managed by
the server is held in the root DSE.
virtual root
entry
attribute
RDN: o = philips
attribute
RDN: ou = research
RDN: name=maass
entry
attribute
attribute
type
DN: name=maass, ou=research, o=philips
attribute
value
attribute
value
Figure 12: X.500 directory information tree
Besides their values, attributes have a type that is identified by one or more descriptive
names - being case insensitive - and an object identifier (OID). The attribute type governs
several aspects of the attribute including: Whether there can be more than one value of
that attribute type in an entry; the syntax to which the attribute values must conform; the
matching rules which may be applied to values of that attribute; whether the attribute may
be modified by LDAP clients, and whether the attribute is for use by applications or by the
LDAP server itself. X.500 attribute types may be derived from other attribute types (and
Page 63
then called attribute subtypes), this may be used to express semantically related attributes.
Some attributes, called operational attributes, are used by directory servers for administering the directory system itself. Example operational attributes are createTimestamp,
creatorsName, etc. [RFC2252], which are automatically added to an entry by the server.
They are not intended for user applications and are not returned to directory clients unless
they are explicitly requested. Collective attributes are part of subentries and appear in a collection of object entries with the same value. A server should list all attribute types it supports in its subschema (sub-)entries using the attribute attributeTypes, which takes
attribute type descriptions as values.
An attribute type is defined in LDAP using the following augmented BNF (see [ RFC2234]
and Appendix C for definition of BNF syntax and basic terms):
AttributeTypeDescription = "(" whsp
numericoid whsp
; attribute type identifier
[ "NAME" qdesrs ]
; attribute type names
[ "DESC" qdstring ]
; description of attribute type
[ "OBSOLETE" whsp ]
[ "SUP" woid ]
; derived from this attribute type
[ "EQUALITY" woid ]
; matching rule used for equality matches
[ "ORDERING" woid ]
; matching rule used for ordering matches
[ "SUBSTR" woid ]
; matching rule used for substring matches
[ "SYNTAX" whsp noidlen whsp ] ; oid of attribute value syntax1
[ "SINGLE-VALUE" whsp ]
; default is multi-valued
[ "COLLECTIVE" whsp ]
; default is non-collective
[ "NO-USER-MODIFICATION" whsp ] ; default is user modifiable
[ "USAGE" whsp AttributeUsage ] ; default is user application
whsp ")"
AttributeUsage =
"userApplications" / "directoryOperation" /
"distributedOperation" / "dSAOperation"
An attribute syntax governs how attribute values are encoded as strings. There is no size
limit on attribute values, so they may include extremely large values such as photographs.
A number of syntaxes has been defined in the LDAP standards, such as DN, DirectoryString, PrintableString, NumericString, Boolean, Audio, etc. Most attributes employ the syntax DirectoryString, being a specifically encoded form of ISO
10646, a superset of Unicode. Printable characters are encoded with their ASCII pendants, whereas other characters are variable-length encoded into byte strings. This has
the advantage that as long as a string contains only printable characters, a simple ASCII
string is produced that may be easily displayed by LDAP clients. PrintableString is a
subset of DirectoryString and allows only printable characters, NumericString only
digits.
Matching rules are used by directory servers to compare attribute values against so-called
Attribute Value Assertions (AVA) when performing search and compare operations. An AVA
1
In this document, we slightly deviate from this definition for the sake of legibility and define attribute syntaxes with the syntax name (e.g. DirectoryString) instead of its numeric oid (e.g.
1.3.6.1.4.1.1466.115.121.1.15).
Page 64
involves an attribute type and an attribute value. It is a proposition provided by the directory client (e.g. "name = maass") that may be true, false, or undefined. A matching
rule allows entries to be selected by making a particular assertion about their attribute values. It defines the syntax of the assertion value and the process to be performed by the
server to evaluate the provided proposition. A matching rule definition consists of a unique
object identifier, a name, a description string, and the identifier of the assertion value syntax [RFC2252].
Five categories of matching rules that should be generally understood by directory servers
are defined in [X.501]: Present, equality, substrings, ordering, and approximate match.
Three of these matching rule types may be explicitly associated with a particular attribute
type in its definition, as shown above: One for equality, one for ordering (i.e. less than,
greater than, etc.) and one for substrings. For these types, the object identifier of a particular matching rule may be specified, indicating to the server which matching rule must
be applied to this attribute type and which syntax will be used for assertion values supplied
by the client. The presence match is applicable to any attribute type and does not need
further specification, and the approximate match is a local matter of the directory server
and therefore not further specified, too. Matching rules are defined in [X.520] for X.500 directory servers. In [RFC2252] the matching rules that must be supported by LDAP servers
are specified. Servers may implement additional matching rules not defined in the directory standards but must publish the matching rule definitions in their subschema entries.
Each entry must have an objectClass attribute specifying the object classes of an entry.
Object classes define which attributes must and which may be contained in a particular
entry. Typical object classes are country, organisation, person, etc. Object classes
(i.e. subclasses) may be derived from other classes (i.e. superclasses). When creating an
entry or adding objectClass values, all superclasses of the named classes are implicitly
added, and the directory client must provide the mandatory attributes of all superclasses.
In this way, an object class inherits all attributes from its superclasses. An optional attribute may be defined as mandatory in a subclass. An object class may be derived from two
or more direct superclasses; this is called multiple inheritance.
An object class is defined in LDAP according to the following BNF:
ObjectClassDescription = "(" whsp
numericoid whsp
; identifier of object class
[ "NAME" qdescrs ]
; names of object class
[ "DESC" qdstring ] ; description
[ "OBSOLETE" whsp ]
[ "SUP" oids ]
; superior object classes
[ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ] ; default structural
[ "MUST" oids ]
; attribute types of mandatory attributes
[ "MAY" oids ]
; attribute types of optional attributes
whsp ")"
To enhance legibility of object class definitions, attribute sets are defined in [ X.521] to
group multiple attributes - e.g. a postal address consisting of street, city, ZIP code, etc. for the purpose of referencing them in object class definitions.
Page 65
There are three kinds of object classes:
Abstract object classes are used to derive other object classes. An entry must belong not
only to abstract object classes.
Structural object classes are used to define the basic structure of an entry representing a
real-world object including its name and position in the DIT. Every entry has a single
structural object class as the most subordinate object class which shall not be changed
during the lifetime of the entry (e.g. a country shall not become a person).
Auxiliary object classes are used to add further descriptive attributes to entries. An entry
may be optionally member of one or more auxiliary object classes in addition to its
structural superclass chain. An entry's auxiliary object classes may change over time.
All structural object classes are a subclass of the abstract object class top (which prescribes the single mandatory attribute objectClass). A server should list all object
classes it supports in its subschema (sub-)entries in the attribute objectClasses with
values taking the above object class description format.
Each entry may have several objectClass values, representing the superclass chains of
all structural and auxiliary object classes. Each entry has a single structural object class
that is indicated in the operational attribute structuralObjectClass. The value is the
most subordinate object class of the entry's structural object superclass chain. The structural object class governs major properties of an entry, including its naming and placement
rules.
Schema is the collection of attribute type definitions and object class definitions plus additional rules that determine the contents and the structure of the DIT. The user schema
governs information intended for use by directory clients (i.e. it manages user attribute
types only), whereas the system schema governs information required for the directory
server operation, e.g. subentry object classes and operational attribute type definitions. A
minimum collection of attribute and object class definitions for use with LDAP is defined in
[RFC2252], further use of X.500 object classes of LDAP is proposed in [ RFC2256].
Name forms and DIT structure rules together specify how an entry is named and where it is
to be placed in the DIT hierarchy. A name form defines which attribute types are used in
the RDN of an entry and assigns an object identifier to the name form. A name form identifies the named entry with its structural object class. A DIT structure rule identifies to
which name form it applies and specifies one or more superior name forms. An entry may
only be placed as a subordinate (i.e. below) to another entry (the superior), if a DIT structure rule exists in the schema which a) indicates the entry and b) includes the entry's superior structure rule as a possible superior structure rule. An entry is identified with its
structural object class and a DIT structure rule does not apply to subclasses of the named
structural object class.
A DIT content rule governs the content of entries of a particular structural object class. It
specifies the auxiliary object classes being permitted to be included. It specifies attribute
types being additionally permitted to appear (besides those required by its object class
definition) or being excluded from appearing in entries of the structural object class. DIT
Page 66
content rules also control the appearance of collective attributes in an entry permitting
them to be present or not.
1.17 LDAP service model
All LDAP messages exchanged by clients and servers are encapsulated in a common
message envelope, which contains a message identifier, an LDAP protocol operation field,
and optionally control specifications. The identifier of a request must have a value different
from any other requests outstanding in the LDAP session the message is part of. A control
may be used to specify extension information. It consists of a type, an optional value, and
a criticality flag, indicating whether the extension must be supported by the server in order
to process the request. A control sent with a request only applies to that particular request,
not to the other operations of a session. An LDAP protocol operation may be a request to
the server to perform an operation, or it may be a response of the server to a client containing the results or error indications of an operation issued before.
An LDAP response message may contain an LDAPResult structure to return success or
failure information from servers to clients. It consists of an enumerated error code indicating success or the reason of a failure, an error message that contains a textual error description, and a matchedDN field that indicates the hierarchically lowest entry that
matched a request in case the target entry was not found by the server. Additionally, a referral identifying another server by means of its LDAP URL [ RFC2255] may be returned to
the client if the server does not hold the target entry of the request. There is a single message, unsolicited notification, which is sent from the server to a client and is no response
to an earlier request. It is used to signal extraordinary conditions, such as server or connection shut down.
The following LDAP operations are defined for LDAP request messages:
Bind
The Bind operation allows authentication information to be exchanged between a client
and a server. A client may invoke operations without a preceding bind but has then only
the privileges of an anonymous client. A Bind is valid for a whole LDAP session, or until
another Bind or Unbind request is sent. In a Bind request, the client provides the name
(i.e. DN) of its entry in the DIT and additional authentication parameters that depend on
the authentication type:
- No authentication, or anonymous bind, means that the client does not provide any
authentication information; the DN may be empty in this case.
- Simple authentication is based on the exchange of a cleartext password that is compared by the server against the values of the userPassword attribute stored in the
client's entry. If there is a match, a success code is sent to the client; otherwise an
invalidCredentials error code will be returned.
- Strong authentication uses any method defined for the Simple Authentication and
Security Layer (SASL) [RFC2222], the mechanism to be used is specified in the Bind
Page 67
request. For this choice, the client has to provide the necessary SASL credentials,
possibly in a multi-stage procedure.
The Bind response is sent to inform the client about the status of its Bind request. It
may indicate success, failure, or require a further Bind request in a multi-stage SASL
authentication process.
The use of simple authentication in server and client implementations is strongly discouraged by the standards. X.509-based strong SASL authentication using asymmetric
(public key) mechanisms has two advantages over simple authentication. The password does not have to be sent as cleartext to the server, and it does not have to be
stored in every server (e.g. using shadowing) that shall be able to authenticate a client
[Kille00].
Unbind
The Unbind operation is used by clients to terminate an LDAP session. No response is
sent to the client.
Search
The Search operation can be used by the client to obtain attributes from a single entry,
from entries immediately below a particular entry, or a whole subtree of entries. For this,
the client has to provide a base object DN and a search scope, being one of: baseObject, singleLevel, or wholeSubtree. The client also has to provide a search filter
that defines the conditions that must be fulfilled in order for the search to match a given
entry in the search scope. A filter may be a combination from other filters using 'and',
'or', and 'not' operators or a basic filter matching against attribute values. The following
filter types are defined: equalityMatch, substrings, greaterOrEqual, lessOrEqual, present, approxMatch, and extensibleMatch. The filter type provided by the client is used by the server to determine which matching rule must be used
to evaluate the filter. Like the matching rules, a filter evaluates to true, false, or undefined. Only in the first case is the entry returned to the client - provided that access
control checks are passed -, otherwise not. A filter on an attribute type is also evaluated
to true, if there is only an attribute subtype present in the entry on which the filter
evaluates to true. Subentries are returned by LDAP servers only if their object class
(i.e. LdapSubEnty as proposed in [Reed00] or subentry [X.501]) is explicitly specified
in the search filter.
An extensible match may be used to match a value against several attribute types and
to allow the client to specify a particular matching rule to be applied in a search operation. For the extensible match to be performed by the server, the client does not have to
provide a complete AVA in the filter. Instead, it is sufficient to provide an assertion value
and optionally a matching rule identifier. The directory will compare the value against a
number of attributes in an entry. The attribute types that are applicable to extensible
matches are specified in a server's subschema entries in matchingRuleUse attributes.
Other important parameters to be provided by the client are limits for time to spend on
the request and number of entries to return to the client, and which attributes should be
returned to the client. Furthermore, the client must specify how the server should handle alias entries found during the search, i.e. whether they should be dereferenced for
base objects and/or for entries falling into the search scope.
Page 68
For each entry returned to the client, a Search response message is sent containing all
or the explicitly requested attributes. Additionally, the server may optionally send one or
more Search response messages that contain a SearchResultReference, also
called Continuation Reference. It consists of a URL reference (coded as defined in
[RFC2255]) to another LDAP server that must be contacted by the client in order to complete the search operation. This is the case, if the server does not hold the complete
part of the DIT that falls into the search scope, so that the client must continue the
search at other servers to obtain a complete result. The data format of continuation references is the same as for referrals. The last Search response message contains an
indication that the operation is done or that an error has occurred, or it contains a referral. Only if the server does not hold the base object of the search will it return a referral
to the client indicating which server might hold the base object.
Modify
The Modify operation allows a client to request the server to perform an entry modification on its behalf. The request must provide the DN of the entry to be modified and a list
of modifications to be performed. The following modifications are allowed: Add listed
values to an attribute, delete all or listed values from an attribute, or replace all existing
values with listed values of an attribute. Whilst individual modifications are allowed to
temporarily violate the schema, the resulting entry after all modifications have been performed must conform to the directory schema. A Modify operation is atomic, i.e. all
modifications or none of them are performed. Attribute values used in the entry's RDN
may not be modified with this operation. Instead, the Modify DN operation must be
used. The Modify response indicates whether the request has been performed successfully or not, or it contains a referral in case the server does not hold the target entry.
Add
The Add operation is used by clients to add entries to the DIT. The client has to provide
the DN of the new entry and all attributes that shall be present in the new entry. The DN
provided by the client must not already exist, the parent entry must exist for the request
to succeed. The Add response indicates failure or success and optionally contains a referral, if the parent entry is managed by another directory server.
Delete
This operation allows removing entries which do not have subordinate entries from the
DIT. The DN of the entry is provided by the client. The Delete response indicates success or failure.
Modify DN
The Modify DN operation allows changing the RDN component of an entry's name or
moving a whole subtree to another place in the DIT. The request must identify the DN
to be changed, a new value for the RDN, and optionally the DN of the new superior entry, if the entry is not just being re-named but also moved. X.500 restricts movements of
entries only within a single server whilst LDAP does not explicitly prevent this. Generally, a directory client may not expect this feature to work across servers. The Modify
DN response indicates success or failure of the request.
Compare
Page 69
This operation allows a client to request the server to compare an attribute value assertion with an entry in the directory. The operation performs an equality comparison using
the equality matching rule associated with the attribute type. The client provides the entry's DN and an AVA, the server returns either a response indicating true or false, if
the entry was found, otherwise an optional referral.
Abandon
The Abandon operation may be used by clients to request a server to cancel outstanding operations, being identified by their request message identifier. No response is
sent by the server.
Extended Operation
This is an extension mechanism to allow additional operations to be defined for services not being supported by the LDAP standards. The request consists of a request
identifier and arbitrary parameters encoded as octet string. The response returns an optional response identifier and arbitrary string-encoded response parameters.
1.18 Proposed LDAP Extensions
Several functional and schema extensions to LDAPv3 are being investigated in the IETF
working groups. Those that are of interest in the scope of the Open Mobility Platform are
briefly introduced in the following.
Shadowing
An LDAP server might contain cache or shadow (i.e. replicated) copies of entries, which
may be used to answer search and comparison queries. They will return referrals, if modification operations on such entries are requested. The mechanisms of how shadowed entries are kept consistent between LDAP servers are being investigated in an IETF working
group as future extensions of the LDAP standards.
Distributed services
LDAP servers return referrals and continuation references to re-direct requests to servers
that manage the information requested by clients. LDAP does not specify a chaining
mechanism between LDAP servers, however, since some X.500 DSAs also offer LDAP
access, chaining of LDAP requests over DSP is de-facto available. An LDAP server may
forward an LDAP request received from a client directly to another LDAP server, but this
mode of operation is not covered by the current version of LDAP standards. Nevertheless,
some commercial stand-alone LDAP servers support chaining, e.g. [MessagingDirect00]. In
order to know which other servers are able to satisfy a client request, servers must store
knowledge references to other servers, collectively called glue or Knowledge Information.
How such information should be managed by LDAP servers is currently being discussed
in the relevant IETF groups [Chadwick99].
Access control
Page 70
The LDAPv3 standards do not specify an access control model. However, the IETF working group responsible for LDAP extensions is actively working on that topic. According to
the latest draft document [Stokes00], access control will be enforced defining permissions
on attribute and entry level. Each permission may be granted on specified attributes or collections of attributes and on individual entries or whole subtrees. The following permissions may be granted to individuals or groups, identified by their DN:
Permissions that apply to attributes:
Read: Read attribute values
Write: Write attribute values
Search: Search entries with specified attribute values
Compare: Compare attributes.
Permissions that apply to an entire entry:
Add: Add an entry below this entry
Delete: Delete this entry
EditDN: Edit an entry's DN
Browse: Browse an entry's DN, i.e. discover the entry in the DIT.
An example of how to employ permissions: To be allowed to search for an entry, the
browse permission must be set (you can only search for things that you are allowed to
discover) and the attributes specified in the search filter must have search permission set.
If attribute values shall be returned in a response, those attributes must additionally have
read permission set.
Non-persistent directory entries
An auxiliary object class DynamicObject has been proposed as LDAP extension in
[RFC2589]. It stores an entry that only temporarily persists in the directory as long as it is
periodically refreshed by a client. All LDAP operations may be applied on the entry, but a
dynamic object may not be changed into a static one, or vice versa. It has a time-to-live
(TTL) value associated with it, which is decremented by the server and determines how
long a server keeps the entry in its storage. The client may update the TTL attribute with
an additionally defined Refresh Operation. When a client ceases to refresh the entry, it
automatically disappears from the directory without prior notice. The name "dynamic object" might mislead the reader to assume that functionality similar to our Dynamic Directory
Services are offered. Temporary directory entries are only a very small subset of the functionality that we developed for our Dynamic Directory Services.
Persistent search
A Persistent Search Operation has been proposed for LDAP [ Smith00] to allow clients to be
informed about changes that occur in an LDAP server. This proposal will not be included
into future versions of the LDAP standards, it only documents a current practice implemented in Netscape's LDAP server [Netscape00]. A new PersistentSearch search control was defined that is used to define which types of changes shall be monitored (add, delete, modify, modifyDN). A persistent search does not end after the last matching entry
Page 71
which was returned to the client, but keeps the operation - and the associated TCP session - active until the operation is abandoned or the session is closed. After modifications
that match a specified category are performed on a directory entry, the server applies the
persistent search filter on the entry. If the filter evaluates to true, the modified entry is returned to the client.
Server-side sorting
A search control containing a sequence of sort keys was proposed in [ Herron99] to support
server-side sorting of entries. It introduces a new search control containing keys (i.e. attribute types) to be used for sorting matching entries before returning them to the client.
The sort key is used to create ascending or descending orders of entries according to the
specified key. This functionality is intended for capability-restricted clients not able to sort
results on their own.
Integrity checking
Many databases support the automatic execution of procedures that are triggered by database operations performed by clients. These procedures are often used to perform integrity checks on the database contents. Two proprietary approaches have been suggested to introduce integrity checking also for LDAP servers. Both approaches are beyond
the scope of the current LDAP standardisation activities.
The Lightweight Trigger Access Process (LTAP) [Arlein99] model defines an LDAP serverexternal gateway that intercepts all client operations performed on the directory and implements the trigger detection and procedure execution. The procedure may be invoked
before or after directory entries are added, deleted, modified, or searched. The result of
the procedure is one of proceed (i.e. continue with the LDAP operation), stop-success
(i.e. abort the LDAP operation), or stop-failure, indicating that the procedure failed.
The intended application of LTAP is performing additional security or integrity checks on
LDAP operations. It does not support notifications to LDAP users, nor does it allow performing operations on the LDAP database. Furthermore, it requires that all LDAP operations sent to a server be passed through the LTAP gateway to inspect the operation. Its
advantage is that it works with any LDAP server since LTAP does not require server-side
modifications. However, this approach prevents its combination with dynamic directory
data, since changes to dynamic data are only visible inside an LDAP server.
Netscape's LDAP server possesses an extension mechanism that allows adding so-called
plug-ins to the LDAP server code [Netscape99]. Plug-ins may be called before or after performing LDAP operations and may pass, stop or modify an operation issued by a client.
Other plug-ins may be called for extended operations and for new matching rules. A plugin is a C-written function that must be compiled and linked with the LDAP server code. The
function is called before or after an LDAP operation is performed by the server. It receives
a set of parameters that describe the operation. The parameters may be modified by the
plug-in function to change the performed operation. The plug-in may also send an LDAP
message back to the client, e.g. to abort an operation with an error code. Plug-ins may not
be dynamically added or modified during server operation, therefore they are not suited for
providing client-customised procedures. They do not allow the directory clients to dynamiPage 72
cally specify events. They can be seen as a flexible mechanism to extend an LDAP server
with proprietary server functionality, e.g. for extended operations or new matching rules.
1.19 Summary
This chapter has presented an introduction to the capabilities of X.500 and LDAP directory
services as specified by the current ITU-T and IETF standards. It has introduced all directory features and specification techniques that are required for the development of the Dynamic Directory Services in chapter 0. It has also presented the most important extension
proposals to the LDAP standards that are relevant for our work.
The following chapter defines in detail the Open Mobility Platform and maps its information
model and services to the X.500 and LDAP models. From this mapping it identifies functional gaps of the existing X.500/LDAP specifications and derives a list of new directory
features that have to be developed for the Dynamic Directory Services as part of our work.
Page 73
Open Mobility Platform
This chapter specifies the Open Mobility Platform (OMP) using the Unified Modelling Language (UML). First, we define the general functional model and identify the required OMP
support services from the analysis of mobility support techniques performed in chapter 0.
We then specify the Open Mobility Platform information model by means of UML class
diagrams. Furthermore, we discuss how the OMP information model can be realised
based on an X.500 directory information model and how the OMP mobility support services can be realised based on LDAP directory access services. These discussions reveal
which of the existing directory mechanisms may be used to realise an Open Mobility Platform and which functionality must be additionally developed as part of the Dynamic Directory Services.
1.20 Functional model
The aim of this thesis is to develop the Open Mobility Platform based on LDAP directory
services which are functionally extended - where required - but are on the access protocol
level as standards-compliant as possible. Accordingly, the OMP functional model must be
based on a directory functional model as depicted in Figure 13.
OMP clients
OMP clients
LDAP
Open Mobility Platform Server
OMP objects
wired & wireless
wired
& wireless
network
infrastructures
network infrastructures
Open Mobility Platform
Server
positioning
positioning
infrastructures
infrastructures
Figure 13: OMP functional model
The mobile and location-aware applications and mobility management services are modelled as clients of one or more OMP servers that are accessed with LDAP directory services and protocols. The servers manage their internal data compliant to the X.500/ LDAP
directory information models. Therefore, all information is modelled as OMP objects being
arranged in a tree. The information managed by an OMP server represents properties of
real-world objects such as humans, terminals, services, equipment, and geographical
places. Not all data accessed by OMP clients should be stored in the OMP servers. Frequently changing information from external positioning infrastructures should be dynamiPage 75
cally passed-through from external servers interacting with the communication and positioning infrastructures. This allows providing up-to-date information of frequently changing
data to OMP clients.
The scope of the Open Mobility Platform is campus-area and multi-site mobility. This
scope determines the coverage area to be provided by the underlying communication and
positioning infrastructures and the mobility management topologies to be supported by the
platform. To structure the OMP coverage area, we divide the overall coverage area into
so-called Mobility Management Domains (MMDs), see also Figure 14. This allows dividing
administrative and operational authority and allows distributing the support service provisioning efforts over multiple OMP servers.
Multi-Site Network
Campus-Area
Network
Campus-Area
Network
MMD Federation
MMD Federation
MMD
MMD
MMD
Figure 14: Mapping of network topology on OMP Mobility Management Domains
Each OMP server manages one or more MMDs. MMDs that belong to a larger campus or
to a multi-site network are composed into so-called MMD Federations. MMD Federations
may be nested to structure management authority on hierarchical levels, e.g. for administering OMP users belonging to multiple MMDs and for realising hierarchical mobility management schemes. The distributed operations of OMP support services make use of referrals, since we want to adhere to LDAP standards which currently do not support chaining
requests between servers. An OMP client may initially contact any MMD to make use of
mobility support services associated with a particular real-world entity or service. The OMP
platform will determine the OMP server that manages the required information and will redirect the client to that OMP server. The re-direction of requests may, however, be hidden
from the actual application by enhanced LDAP APIs.
1.21 Support services
This section identifies the support services to be provided by the platform. As defined in
the problem statement, the OMP mobility support services shall allow management of and
access to all mobility-related control information needed for realising mobility including
terminal, user, and application mobility. The scope of the support services shall be re-
Page 76
stricted to management of control information. Connection management and communication content handling are beyond the scope of our research. The set of support services to
be included into the Open Mobility Platform is derived from analysing the state-of-the-art in
mobility support techniques that we presented in chapter 0. Assuming that the reviewed
support functions are representative, the OMP mobility support services may be identified 2
by defining a subset consisting of those techniques which are related to control information, not with content and connection management.
Abstraction
level
Operational
phase
Support technique
OMP support services
Mobilitytransparent
establish
connections
directory
white pages directory services
trader, broker
trading services, yellow
pages directory services
maintain
connections
proxy, cache, data
synchronisation, QoS manager
out of scope
obtain information
about
environment
profiling service
profile handling services
event service
event handling services
QoS manager
out of scope
perform adaptation
content reduction
out of scope
trader, type manager
trading services
locate or register
mobile user or
terminal
location database
location handling services
directory
white pages directory services
obtain or update
profile of user or
terminal
profile database
profile handling services
directory
white pages directory services
obtain location
information
location database
location handling services
location event handler
event handling services
obtain navigation
information
map, waypoint server
location handling services
route calculator
too specific
find support services
resource discovery
discovery services,
yellow pages directory services
Mobilityrobust
Mobility-aware
Locationaware
All levels
control access to
support services
security services
Table 2: Open Mobility Platform support services
In Table 2, we generalise the mobility support techniques identified in chapter 0 and identify those techniques which are beyond our scope since they are not related to control in-
2
An earlier version of the support services has been presented by us in [Maass97].
Page 77
formation. Support techniques for handling mobility-related control information are typed in
normal font, support techniques for handling communication links or content are typed in
italic font. Additionally, we identified functions that would be too specific to be wellsupported based on generic directory services. This led us to exclude optimal route calculation functions from the OMP support services. The rightmost table column identifies the
name of the OMP support service that realises the mobility support techniques.
The resulting support services that we identified to be included into the Open Mobility Platform are:
Location handling services
These support services allow clients to retrieve and update location information representing spatial positions and communication network addresses of real-world entities.
They also cover managing the registrations of users on terminals and positioning devices, i.e. they include location handling support for user and terminal mobility. They
also cover roaming services between network or positioning infrastructures inside or between Mobility Management Domains. Location information may be distributed over
multiple network sites and OMP servers. Mobility management services should be supported with any flat or hierarchical location handling schemes. Position-related information for navigation applications is also accessible from these services.
Profile handling services
All profiling information describing mobile or fixed real-world entities may be managed
and retrieved by the profile handling services. Information in the profile may be synchronised (i.e. replicated) with real-world infrastructure to enforce privileges or service
characteristics as prescribed by the profile.
Event handling services
Clients must be supported to define events and obtain notifications about their occurrence. Event handling services allow the definition of events on location- and profilerelated information but also allow defining events on any other information managed by
the support services. For mobile applications, temporary unavailability should be supported by the event handling functions.
Directory services
White pages - i.e. naming - services assign identifiers and names to entities managed
by the profile and location services. Both may be used to unambiguously identify realworld entities and obtain information about them from the Open Mobility Platform. Distribution of information over OMP servers is resolved by re-directing OMP clients to that
server that manages an identified or named object.
Yellow pages services support finding real-world entities representing users, terminals,
applications, or services of interest based on search criteria provided by the client. Directory services may operate on any information held by the location and profile services. The search scope of yellow pages service may be restricted to a particular MMD,
or it may cover any level in the MMD Federation hierarchy.
Trading services
Trading services extend the yellow pages services with advanced selection functions to
retrieve real-world entities that fulfil client-defined criteria optimally. They also allow entities to be determined that have defined properties and are spatially nearest to a given
Page 78
position. Simple type management services allow retrieving specialisation and compatibility relationships between service and terminal types managed by the support functions.
Security services
Retrieval and manipulation of information managed by the support services is subject to
access control enforced by the support functions. Clients of the support services may
be forced to authenticate themselves. Management of access control lists and subscription of clients to support functions is solved by these services. Security services are
managed inside an MMD or at higher MMD Federation levels.
Discovery services
This category of services allows discovering OMP servers that offer the above-listed
support services. It also provides means to discover the information model employed by
the support services and the capabilities of particular OMP servers.
The detailed functionality offered by each of these support services and their mapping on
LDAP directory access services will be discussed in section 1.24. Before that, the Open
Mobility Platform information model underlying these services and its realisation based on
X.500 directory information model elements will be presented in the following.
1.22 Information model
In the following sections, the functional model of the Open Mobility Platform is specified by
means of Unified Modelling Language class diagrams [ Eriksson98]. One reason for choosing the UML notation is its extensibility, which allowed us to introduce additional modelling
constructs required for describing the OMP object class model. The UML syntax used for
defining the OMP object class model is summarised in Appendix A.
The OMP functional model is specified by defining a collection of object classes. OMP object classes are used for structuring the content held by an OMP server in the same way
as LDAP object classes structure the data managed by a directory server. All objects
managed by the OMP must be instances of one or multiple object classes. An object class
specifies which attributes must or may be contained in an object. Attributes may be subtypes of other attributes to express semantic compatibility. All objects have an attribute
objectClass that specifies to which object classes the object belongs.
The OMP object class model makes use of three different types of object classes for
structuring the OMP information: Structural, auxiliary, and abstract object classes. A structural object class may be used to create objects from it. An object contains all mandatory
attributes of its class and may or may not have optional attributes. An instance of an auxiliary object class may not exist independently, it may only be aggregated with an instance
of a structural object class. An abstract object class may not be instantiated at all, it is only
used to derive subclasses from it. Structural object classes have a name that is formed
from the value of one of their attributes, being identified with the type "N" in the UML
specifications. Object names are unique inside an OMP platform. Figure 15 illustrates a
Page 79
hypothetical example of object classes and an object instance specified in UML graphical
notation.
The OMP object class model employs two different types of derived attributes: Externally
derived and internally derived, their UML syntax is defined in Appendix A. As explained in
the previous section, not all data provided to OMP clients is held internally in an OMP
server, some data is obtained on request from an external communication or positioning
infrastructure. In the OMP object class model, this data is modelled as externally derived
attributes. Internally derived attributes allow deriving attribute values in one object from attribute values in another object. Both types of derived attributes need a derivation rule that
is part of the OMP object class definition. Internally derived attribute rules are cumulative;
i.e. rules from superclasses and auxiliary classes all apply in parallel in a class.
<<abstract>>
Class0
[attribute0]
<<auxiliary>>
ClassA
has
ClassB
attributeA
attributeB
attributeX : N
instance-of
instance-of
abc:ClassA
objectclass = ClassA
objectclass = ClassB
attributeA = value1
attributeA = value2
attributeB = value3
attributeX = abc
Figure 15: Hypothetical OMP object classes and objects specified in UML syntax
In the OMP model, attribute derivation rules are modelled like methods and are depicted
in the UML operation compartments. The UML diagrams in the following sections define
the OMP object classes and their attributes and attribute derivation rules. For the sake of
legibility, the derivation rules for attributes are not specified including their arguments and
return values, only the place of the rule definition is indicated. For selected object classes,
the derivation rules are depicted in separate illustrations including parameters.
1.22.1 OMP object class model overview
The Open Mobility Platform object class model is made up of four main packages, as depicted in Figure 16. The packages provide a structure for the OMP object classes and define regions of interest for the different parties that use or customise the OMP model. The
package structure has only descriptive purposes; it has no influence on the functionality
provided by the Open Mobility Platform.
The OMP Framework package defines the main object classes on which the OMP support
services are realised. It is structured into further packages, called Subscription Framework, Addressing Framework, and Positioning Framework. They define the basic concepts
of all support services and are described in detail in the following sections. The OMP
Page 80
Framework defines a homogeneous model for handling the two aspects of locating that
are relevant for mobile applications. It encompasses concepts for handling the spatial position of entities in the Positioning Framework as well as handling the network address of
communicating entities in the Addressing Framework. As specified in Figure 16, the Addressing Framework is dependent on the Positioning Framework. The reason for this are
the position-dependent addressing support services, such as follow-me to the nearest
terminal, where an addressing-related object class makes use of positioning-related object
classes. A distinguishing feature of the OMP compared to other approaches is the integrated support for positioning and addressing with a common underlying model and a
common set of support services.
Open Mobility Platform
Application
Customisation
OMP Framework
Hospital
Subscription
Framework
Dynamic
Directory
Exhibition
Addressing
Framework
Positioning
Framework
.......
Service and Terminal Customisation
Phone
.......
Fax
Positioning Customisation
ABS
RF
DECT
.......
Figure 16: OMP top-level architecture
The OMP Framework is generic for mobile and location-aware applications and contains
no environment or application-specific object classes. The supplier of the OMP platform
(i.e. for the first OMP version the author of this thesis) defines the object classes of the
OMP Framework package.
The Positioning Customisation package defines object classes that customise and extend the platform functionality for various positioning technologies. For each technology
supported by the OMP, a sub-package contains auxiliary classes and subclasses of OMP
Framework classes. They are defined by the positioning system developer, or by an OMP
Page 81
operator. In Figure 16, example packages already provided by the OMP developer for Active Badge Systems, for RF positioning systems and for wireless network-based positioning systems - in this case DECT - are shown.
The Service and Terminal Customisation package defines object classes for customising
and extending the platform functionality for additional communication services and associated terminal types. For each service that shall be supported with the Addressing Framework of the OMP, a sub-package must be defined by the equipment provider or OMP operator. Example packages such as fax and phone are provided by the OMP developer, as
shown in Figure 16.
Service and Terminal
Customisation
Dynamic
Directory
OMP Framework
Application
Customisation
Positioning
Cust omisation
defined by
DynamicDirectory
develop er
defined by
OMP
develop er
added by
equipment
developer and
OMP operator
added by
application
developers and
OMP operator
increasing degree of customization
Dynamic Directory
development
Open Mobility
Platform
development
Open Mobility
Platform
extension
OMP installation
and application
development
Figure 17: Incremental OMP model refinement and customisation
The Application Customisation package contains application-specific object classes,
which are defined by OMP operators or application programmers. They model the specific
data items of OMP applications needed for the OMP support services. The Application
Customisation object classes are only loosely coupled with OMP Framework object
classes. They only define auxiliary object classes that are used in aggregations with OMP
Framework object classes. This promises a maximum of flexibility in the applicationspecific part of the object model. Additionally, it provides re-usability of OMP object class
definitions in different application environments since the OMP object class inheritance hierarchy is not affected by changes in the Application Customisation package. The Application Customisation object classes may be further structured into sub-packages. In Figure
16, two example packages for hospital and for exhibition applications are shown. In a real
OMP installation, multiple sub-packages like these may be present.
Figure 16 shows a fifth package, called Dynamic Directory. It contains object classes for
directory service extensions being required for implementing the OMP support services.
Page 82
Since these extensions are generic and not limited to being useful for realising the Open
Mobility Platform, they are not part of the OMP package. Instead, these new object
classes defined by the Dynamic Directory developer (i.e. again the author of this thesis)
are part of the extended LDAP system schema. This package will be described in more
detail in chapter 1.32.
Figure 17 summarises the incremental refinement and customisation of the OMP object
model by the different parties involved in development, installation and application development of the Open Mobility Platform.
1.22.2 OMP Framework and Subscription Framework
The UML object class model of the OMP Framework is depicted in Figure 18. The Subscription Framework defines object classes for managing subscriptions of locatable realworld entities and OMP clients to the Open Mobility Platform. It also structures the logical
and physical distribution of the subscription information over administrative areas and
OMP servers.
Each entity that shall be locatable by the Open Mobility Platform must have a subscription.
A subscription is performed by creating an instance of the LocatableObject class inside the OMP platform. The coverage area of the OMP is partitioned into Mobility Management Domains (MMDs). A conglomerate of cooperating MMDs is called MMD Federation. Upon subscription, a LocatableObject instance is created within the MMD which
represents the coverage area in which the subscribed real-world entity normally is. This
subscription is called resident subscription. When the real-world entity temporarily visits the
coverage area of another MMD, an additional visitor subscription is created at the visiting
MMD. The visitor subscription is also an instance of LocatableObject and exists inside
an MMD as long as the entity stays in its coverage area. This concept is similar to the
HLR/VLR approach in GSM networks where two instances of the subscription profile are
held in the network. MMDs and MMD Federations are represented in the OMP platform
with instances of object classes MMD, respectively MMDFederation, as shown in Figure
18. They have mandatory identifiers being unique inside a multi-site campus-area environment. MMD Federations may be logically nested to structure management authority in
campus-area and multi-site networks hierarchically. However, this nesting is not reflected
in a containment or placement relation between OMP objects, as will be discussed in section 1.22.7.
All LocatableObject instances are identified by an objectId attribute having a unique
value inside an MMD Federation. Every LocatableObject has an attribute managingMMD that identifies the MMD that should be contacted by an application for obtaining
information about the real-world object. An optional attribute name may be present in a
LocatableObject to assign one or multiple names to an object. LocatableObject is
an abstract object class. Therefore, only instances of one of its subclasses and not of the
class itself may be created. The subclass chosen upon subscription determines which
type of support services will be available for the subscribed entity.
Page 83
Dy namic D irectory
A dapter
name : N
<A dapterInfo>
O M P F ramew ork
A pplication
C ustomisation
S ubscription F ramew ork
O M P U ser
name : N
[passw ord]
Exhibition
<<auxiliary >>
V isitor
<V isitorP rofile> 0..1
<<auxiliary >> 0..1
Exhibitor
<E xhibP rofile>
has
1
has 1
1
has
Hospital
0..1
<<abstract>>
LocatableO bject
objectId : N
managingM M D
[name]
HookedO bject
homeM M D
1
0..*
0..*
manages
0..*
0..*
0 ..1
1
0..*
refers-to
1 federates
0..1
managingM M D
1
1..2 specifies
0..1 0..*
O M P S erv er
MMD
operates
1
<S chemaInfo>
mM DId : N
1..*
1 <S erv erInfo>
manages
1
contains
contains
associated-w ith
0..*
has
M M DF ederation
mM DId : N
manages
has
<<auxiliary >>
Wheelchair
<C hairP rofile>
M M DP ointer
homeM M D
1
0..*
0..1
1
0..*
1
1
1
federates
1
has
contains
0..*
RoamingA rea
roamingA reaId : N
1
0..*
associated-w ith
O M P A dapter
roamingA reaId
0..*
0..1
<<auxiliary >>
M edicalD octor
<D ocP rofile>
0..*
A ddressingF ramew ork
<<abstract>>
HookedA ddress
related-to
0..*
0..1
<<abstract>>
Terminal
P ositioning F ramew ork
0..*
<<auxiliary >>
HookedP osition
hooked-on
0..*
0..1
<<abstract>>
Tag
0..*
located-in
0..*
0..*
<<abstract>>
S patialA rea
0..*
Figure 18: OMP Framework and Subscription Framework
The following subclasses of the abstract class LocatableObject have been defined as
part of the OMP Framework:
Terminal
The main property of a Terminal object is that it possesses at least one address. This
address may be used to establish connections to the real-world terminal that is represented by the object. Through further subclassing of the Terminal object class, fixed
and mobile terminals are represented in the OMP. These subclasses are defined in the
OMP Addressing Framework.
Tag
A Tag object possesses a position attribute representing the physical position of the
real-world entity. The position identifies an instance of the SpatialArea object class
that represents a real-world area such as a room or an exhibition booth. The OMP Positioning Framework defines the Tag and SpatialArea object classes.
HookedObject
Entities represented by instances of the HookedObject class may be associated with
other LocatableObject instances in order to become addressable or positionable.
An example is a human being that hooks onto a terminal for using communication services, or hooks onto a tag for being positioned. In the OMP functional model, instances
of class HookedObject may aggregate instances of HookedAddress - if they shall be
addressable - and instances of HookedPosition, if they shall be positionable. Since
HookedObject instances represent inherently mobile entities, each instance contains
Page 84
a homeMMD attribute that identifies which MMD contains the HookedObject's resident
subscription. Another important aspect of the HookedObject class is that it allows customising the OMP data schema according to application requirements. Customisation is
achieved through aggregation of HookedObject instances with application-specific
auxiliary object class instances that are defined by application developers. In this way,
application-specific attributes may be added to HookedObject instances during OMP
subscription. In Figure 18, the attributes contained in the application-specific object
classes are abbreviated with attribute sets.
MMDPointer
Instances of object class MMDPointer are required to offer mobility support services
across multiple Mobility Management Domains. For each LocatableObject that shall
be locatable across MMDs, an MMDPointer object must be created at each MMD at
which support services for this entity shall be offered. The MMDPointer object specifies
two MMD identifiers: The attribute managingMMD identifies the MMD that should be
contacted next by the application to obtain further information about the LocatableObject. The MMDPointer object must also contain the identifier of the LocatableObject's home MMD in an attribute homeMMD. An application requesting information about the LocatableObject's resident subscription knows from the value of this
attribute which MMD should be contacted. The MMDPointer object implicitly refers to
the OMPServer that manages the MMD specified by the managingMMD attribute. Either the OMP server or the OMP clients may use this information to re-direct service requests. MMDPointer objects may be also used to implement hierarchical mobility
management schemes. In this case, they refer with the attribute managingMMD to an
MMD Federation instead of an MMD.
An MMD may contain roaming areas to structure the coverage areas of communication
and positioning infrastructures. Roaming areas may be hierarchically nested. They are
represented by instances of object class RoamingArea and have a mandatory attribute
roamingAreaId whose value must be unique inside an MMD and is used for naming. If a
LocatableObject uses the services of an infrastructure, it is associated with its RoamingArea object as shown in Figure 18. Because of this, roaming areas may also be used
to structure the placement of resident and visiting LocatableObject instances inside an
MMD. This is further discussed in section 1.22.7 defining the allowed placement of objects.
A host implementing the OMP services is represented in the platform with an OMPServer
object. An OMP server may operate one or multiple Mobility Management Domains. An
OMPServer object contains information about the data schema being enforced in the attribute set <SchemaInfo>. This may be used by applications to discover object classes
and attributes used by the mobility support services. Additional information about the OMP
server is contained in the <ServerInfo> attribute set. The details of how the OMP server
interacts with the positioning and communication infrastructure to exchange information
about real-world entities represented by LocatableObject instances are specified by
the <AdapterInfo> attribute set of the OMPAdapter object class. It is inherited from the
Adapter class defined in the Dynamic Directory package. Multiple OMPAdapter objects
may be associated with a RoamingArea instance to interface with multiple infrastructures
Page 85
of the represented type. The OMPAdapter also contains knowledge of how externally derived attribute values may be obtained from physical equipment.
Another functionality of the Subscription Framework is handling the subscription of users
to the Open Mobility Platform. Subscribed users have a federation-unique name and optionally a password associated with them that allow an OMP server to authenticate a user.
Depending on the access control requirements of an OMP operator, access to certain
OMP objects will be restricted to selected users. Only users that are known and optionally
authenticated may then invoke support services accessing such protected OMP objects.
An OMP user is represented in the platform with an instance of object class OMPUser.
The user object is associated with the MMD Federation, because the user subscription
should not necessarily be limited to a single MMD. To access a LocatableObject in an
MMD Federation, it might be necessary to contact multiple MMDs; therefore, the user
subscription should be known federation-wide.
1.22.3 Positioning Framework
The OMP Positioning Framework is depicted in Figure 19. The main concept underlying
the OMP positioning support services is the tag, which is represented in the OMP model
with an instance of the Tag object class. A Tag object represents a real-world entity that
possesses a spatial position. It may be either fixed or mobile. In the first case its position
is known and static, in the second case its position must be measurable by an appropriate
positioning technology, e.g. one of the infrared or RF positioning systems introduced in
section 1.4. The position of a tag is contained in a position attribute that may have
none, one, or several values. The latter is for example the case, if the tag was located by
multiple positioning sensors simultaneously - a situation that will not always be avoidable
in real-world positioning infrastructure installations and must therefore be tolerated by the
Open Mobility Platform model.
Spatial areas
The positioning is done at the granularity of real-world areas, which are represented by instances of object class SpatialArea. Each SpatialArea instance has an identifier attribute areaId the value of which must be unique inside an MMD. The internally derived
attribute presentHookedObjects contains the identifiers of all HookedObject instances, which are positioned inside the real-world area. How this positioning is achieved
is specified in the Positioning Customisation package. Two sub-types of areas have been
defined to model hierarchical structures of areas inside other areas. A BasicArea is a
SpatialArea that contains no further areas, whereas a CompositeArea may contain
any number of - composite or basic - areas. To add application-specific semantics to SpatialArea instances, auxiliary object classes containing application-specific attributes
may be defined in the Application Customisation package. Examples for auxiliary classes
are e.g. OfficeRoom, Floor, Building, ExhibitionBooth, etc. These auxiliary
classes are not intended to contain all application data, but only those that are of relevance for the operation of the OMP support services. Application-specific attributes might
be useful for, e.g., searching areas with certain characteristics, or for usage in filters for
Page 86
event definitions. In Figure 19, the attributes of the auxiliary classes are abbreviated with
attribute sets.
S ubscription F ramew ork
H ookedO bject
homeM M D
<<abstract>>
LocatableO bject
objectId : N
managingM M D
[name]
A pplication
C ustomisation
MMD
mM D Id : N
H ospital
1
1
has
0..1
contains
BasicA rea
0..*
<<auxiliary >>
H ookedP osition
[attachedTag]
/position
/ lastLocating
/managingM M D
0..*
<<abstract>>
hooked-on
Tag
0..*
0..1 position
<<abstract>>
M obileTag
/position
homeM M D
[>lastLocating]
[roamingA rea]
[>currentRoamingA rea]
has
0..1
0..*
has
<<abstract>>
F ixedTag
1
1..*
0..*
<<abstract>>
P ositioningRegion
>presentTags
has
contains
/presentH ookedO bjects()
1
<<auxiliary >>
Building
<BuildingP rofile>
1
<<abstract>>
S patialA rea
located-in areaId : N
0..* /presentH ookedO bjects
0..*
/position()
/lastLocating()
/managingM M D ()
has
1
P ositioning F ramew ork
<<auxiliary >>
Room
<RoomP rofile>
cov ers
1
0..1
C ompositeA rea
<<auxiliary >>
Booth
<BoothP rofile>
/presentH ookedO bjects()
0..*
M ap
mapId : N
cov eredA reas
graphicalM ap
[description]
1
E xhibition
has
0..1
<<auxiliary >>
H all
<H allP rofile>
Figure 19: OMP Positioning Framework
Tags
The position attribute value of a Tag object equals the identifier of the SpatialArea in
which the tag is positioned. A fixed tag is represented by the FixedTag subclass of object class Tag, a mobile tag by the MobileTag subclass. Both of these classes are abstract and are further subclassed in the Positioning Customisation package. There is a
fundamental difference between the position attributes in the two subclasses of Tag:
The position attribute of FixedTag instances is static and only rarely modified by OMP
clients (i.e. humans or applications), whereas the position attribute of MobileTag instances is dynamic and reflects the real-world position determined by a positioning infrastructure. This latter attribute is therefore modelled as internally derived attribute. The
derivation rule for position is not specified in the MobileTag object class itself; it is
specified in the Positioning Customisation package since the rule varies for different types
of positioning technologies.
The FixedTag object class does not define additional attributes. Its purpose is to allow an
application to discriminate between fixed and mobile tags by their objectClass attribute.
This discrimination possibility is also used in the Addressing Framework to select fixed
terminals. Further subclasses of FixedTag may be defined in the Application Customisation package to represent any kind of static real-world entities possessing a position. This
Page 87
includes modelling of waypoints, representing points of interest that may be associated
with additional descriptive profile information to be searchable by applications.
The MobileTag object class defines a number of additional attributes:
homeMMD
The mandatory attribute homeMMD contains the identifier of the mobile tag's home
MMD. This information is for example needed by mobility management applications that
must access a visiting tag's resident subscription, e.g. to create a new visitor subscription from it.
lastLocating
The lastLocating attribute is optional and contains date and time when the mobile
tag was positioned for the last time. The OMP model assumes that its value is dynamically derived from the positioning infrastructure; therefore, the attribute is modelled as
externally derived attribute. This information may be used by applications to determine
how recently the tag's position was determined.
currentRoamingArea
The optional attribute currentRoamingArea identifies in which roaming area the tag
is currently positioned. This attribute is an externally derived attribute since its value is
derived from a positioning infrastructure dynamically. When the real-world tag moves
into the positioning system coverage area represented by a different roaming area, this
attribute's value changes accordingly. The value of this attribute is monitored by mobility
management services and used to update the roamingArea attribute for establishing
a new roaming area association. For monitoring, the mobility management services
may make use of the OMP event services.
roamingArea
The optional attribute roamingArea identifies the positioning system - represented by
a roaming area - the tag is associated with. This attribute is used as parameter in external attribute derivation rules to identify the infrastructure from which dynamic information for a real-world entity must be obtained. The roamingArea attribute is updated by
a mobility management service every time the value of currentRoamingArea
changes.
Hooked positions
Applications are mainly interested in locating HookedObject instances, representing for
example real-world persons using tags for being positioned. The Positioning Framework
defines the auxiliary object class HookedPosition that may be aggregated with instances of HookedObject. HookedPosition may contain an attribute attachedTag
that specifies at most one tag that shall determine the position of the HookedObject instance. The mandatory position attribute of HookedPosition has a value that is
equal to the position attribute of the associated tag. Accordingly, the position attribute of HookedPosition is modelled as internally derived attribute, as depicted in Figure
19. Whenever the position attribute's value changes in a Tag instance, the position
attribute's value of an attached HookedPosition instance changes accordingly. Similarly, the internally derived attributes lastLocating and managingMMD obtain their values from corresponding attributes of the tag attached to the HookedObject instance.
Page 88
Positioning
The Positioning Framework is application- and technology-independent, i.e. the object
classes define the generic positioning aspects. To support specific positioning technologies, OMP operators or equipment providers must define auxiliary subclasses of object
class PositioningRegion in the Positioning Customisation package. Each PositioningRegion subclass represents a particular positioning infrastructure technology. Each
auxiliary subclass must define a derivation rule for the externally derived attribute presentTags. The information contained in the presentTags attribute is used by SpatialArea object instances to determine which instances of HookedObject are present. For
this purpose, a derivation rule for the internally derived attribute presentHookedObjects has been defined for the SpatialArea object class.
The attribute value derivation works as follows: The attribute presentTags is taken as
argument for the derivation rule. It is used to select the HookedObject instance from
which the presentHookedObjects value is derived. For each value of attribute presentTags in a SpatialArea instance, the objectId attribute value of that HookedObject instance where the attachedTag attribute value equals the presentTags attribute value must be obtained. Each obtained value is added to the presentHookedObjects values in the SpatialArea instance. How that derivation rule is specified in the
OMP object class model is depicted in Figure 20.
<<abstract>>
S patialA rea
/presentH ookedO bjects(presentTags) : H ookedO bject(attachedTag=presentTags):objectId
C ompositeA rea
/presentH ookedO bjects() : S patialA rea(C H ILD RE N ):presentH ookedO bjects
Figure 20: Derivation rules for attribute presentHookedObjects
A CompositeArea determines its present HookedObject instances in two ways. On the
one hand it acquires information from the positioning infrastructures in the same way as a
BasicArea. Additionally, a CompositeArea also determines all HookedObjects that
are present in the hierarchically immediately below areas. The derivation rule for this is defined in the CompositeArea object class. Since internal derivation rules are cumulative,
the rules from SpatialArea and CompositeArea are both evaluated to obtain the value
for attribute presentHookedObjects in CompositeArea objects.
To offer navigation support to OMP applications, the OMP Positioning framework defines
a Map object class. A Map object has an attribute mapId to identify the map and an attribute coveredAreas that contains the areaId values of all SpatialArea instances being
covered. The map information itself is contained in the attribute graphicalMap whose
value contains an image to be used by the application, e.g. for presenting it to human users. A Map instance covers at least one SpatialArea, and an area may be covered by
zero or multiple maps, as indicated in the "covers" association in Figure 19.
Page 89
1.22.4 Positioning Customisation
The Positioning Customisation package provides the link between a positioning technology and the MobileTag and SpatialArea instances. For each positioning technology, a
sub-package is defined that specifies all required object classes including the derivation
rules for internally and externally derived attributes. In Figure 21, three example packages
are specified, one for DECT-based positioning, one for an Active Badge System, and one
for RF-based positioning systems. For other positioning technologies, additional packages
will have to be defined either by the equipment supplier or by the OMP platform operator.
Tag customisation
From the abstract class MobileTag defined in the Positioning Framework, a structural
subclass must be derived for each positioning technology which must define:
According to which rule the internally derived position attribute value is obtained.
The MobileTag object class does not specify the derivation rule for position since
the rule depends on the chosen technology. Therefore, each MobileTag subclass
must specify a derivation rule for position.
Whether or not the lastLocating attribute must be present.
In the MobileTag object class, lastLocating is defined as optional, since it may not
be supported by each positioning technology. However, the subclass may override the
definition as mandatory.
Technology-specific position information.
Additional attributes may be required in the MobileTag subclasses for representing the
technology-specific position information obtained from the positioning infrastructures.
Positioning infrastructure customisation
The other type of information needed for adapting the OMP model to a dedicated positioning technology is the representation of positioning infrastructure technology and coverage
areas. For this purpose, an auxiliary subclass of the PositioningRegion object class
must be defined for each positioning technology. The auxiliary object class is then used
for aggregations with SpatialArea objects to provide the link between the positioning
system coverage areas and the spatial areas of an MMD. Each auxiliary object class must
define a derivation rule for the externally derived attribute presentTags, whose value
represents the identifiers of all tags currently positioned by the infrastructure inside the
reach of a PositioningRegion.
For the positioning technologies depicted in Figure 21, the object classes are described in
detail in the following sections. These technologies represent the typical positioning systems being available today: IR-based systems employing sensors, RF-based systems determining absolute position coordinates, and wireless network-based systems employing
the coverage area of radio base stations for determining positions of mobile terminals. Deriving the Positioning Customisation classes for other positioning technologies should be
straightforward.
Page 90
P ositioning F ramew ork
<<auxiliary >>
H ookedP osition
[attachedTag]
/position
/ lastLocating
/managingM M D
BasicA rea
<<abstract>>
Tag
0..1 position
hooked-on
0..*
0..*
<<abstract>>
M obileTerminal
1
has
<<abstract>>
M obileTag
/position
homeM M D
[>lastLocating]
[roamingA rea]
[>currentRoamingA rea]
<<abstract>>
P ositionableTerminal
0..*
contains
/presentH ookedO bjects()
/position()
/lastLocating()
/managingM M D ()
A dressing F ramew ork
<<abstract>>
F ixedTag
1
1..*
C ompositeA rea
cov ers
0..*
<<abstract>>
P ositioningRegion
>presentTags
/presentH ookedO bjects()
0..*
M ap
mapId : N
cov eredA reas
graphicalM ap
[description]
P ositioning C ustomisation
S erv ice and Terminal
C ustomisation
P ositionableP hone
>currentDE C TRF P
>lastLocating
<<abstract>>
S patialA rea
areaId : N
0..* /presentH ookedO bjects
located-in
DEC T
0..*
<<auxiliary >>
D E C TRF P
0..1
dE C TRF P Id
connected-w ith
>currentDE C TRF P ()
>currentRoamingA rea()
>lastLocating()
/position()
>presentTags()
A BS Tag
>currentA B S S ensor
>lastLocating
A BS
0..*
sighted-by
0..1
>currentA B S S ensor()
>currentRoamingA rea()
>lastLocating()
/position()
<<auxiliary >>
A BS S ensor
aBS S ensorId
>presentTags()
RF
.......
RF Tag
>currentRF C oordinates
>lastLocating
>currentRF C oordinates() 0..*
>currentRoamingA rea()
>lastLocating()
/position()
is-in
0..*
<<auxiliary >>
RF C oordinatesRange
RF RectangularS olid
>presentTags()
Figure 21: OMP Positioning Customisation
1.22.4.1 Active Badge positioning
For positioning Active Badges (see section 1.4.3.2), the ABSTag and ABSSensor object
classes have been defined. An Active Badge system consists of IR badges that have a
worldwide unique identifier associated with them. The badges periodically send out IR signals that are detected by sensors connected to a network. Each sensor has a sensor identifier that is unique inside an Active Badge system. An Active Badge system must be extended with a positioning server that allows querying for that sensor at which badges were
seen for the last time and for badges seen at a sensor currently. The positioning server
must also provide the date and time of the last sighting along with the position data.
Page 91
The ABSSensor auxiliary object class represents ABS sensors. It defines the mandatory
attribute aBSSensorId, which contains the identifier of a sensor. For each ABS sensor
that is installed in a real-world area, an auxiliary object instance is aggregated with the
SpatialArea instance representing the area. This allows covering a real-world area with
as many ABS sensors as required for providing physical coverage with the ABS positioning infrastructure. The mandatory externally derived attribute presentTags identifies
which Active Badges have been detected by the ABS sensor. For each detected badge,
the attribute has a value that represents its badge identifier (see below). Since IR signals
cannot penetrate through walls and are typically limited in their power, Active Badges will
usually be located inside BasicArea instances representing bounded real-world areas
such as rooms.
The ABSTag object class represents Active Badges. The Active Badge identifier is used
as value for the tag object's objectId attribute. The OMP model assumes that the Active
Badge identifier is unique and can therefore be used as LocatableObject identifier. In
case this cannot be guaranteed - e.g. because different positioning systems use the same
identifiers for their tags - the OMP platform employs a prefixing mechanism specified in
the Adapter instance responsible for the interworking with the positioning infrastructure.
The value of the mandatory externally derived attribute currentABSSensor represents
the Active Badge sensor at which the badge was sighted for the last time. As shown in
Figure 21, an ABSTag instance may be sighted by zero or one ABSSensor instance. The
same badge should not be sighted simultaneously by more than one sensor of the same
Active Badge positioning infrastructure to provide unambiguous position data. The externally derived attribute lastLocating contains the date and time of the last sighting.
An example for an ABS positioning infrastructure and its OMP object model representation
is illustrated in Figure 223. It shows two persons equipped with Active Badges, both are located in Mobility Management Domain Aachen, office room G116. The person with objectId=533 is resident of MMD Aachen, person 549 is visitor from MMD Eindhoven.
As explained above, the ABSTag object class must specify the derivation rule for the internally derived position attribute. This rule depends on the chosen positioning technology, and in this case it must translate the Active Badge System sensor identifiers representing the last sighting of a badge into SpatialArea identifiers representing a LocatableObject's position in the OMP model. Since this translation is a central feature of the
OMP it shall be described in more detail in the following. The UML definition of the position attribute derivation rule is depicted in Figure 23.
The attribute currentABSSensor is taken as argument for the derivation rule to select
from which SpatialArea instance the position attribute value is derived. The attribute
currentABSSensor may have at most one value, as explained above. The derivation
rule selects that SpatialArea instance that has an attribute aBSSensorId with the
same value as the currentABSSensor attribute. From the selected object, the value of
attribute areaId provides the derived value for attribute position. In other words: The
3
In the examples, not all objectClass attribute values but only the most subordinate ones are
shown.
Page 92
position of an Active Badge is the area identifier of that area where the ABS sensor having
sighted the badge is installed. If no sensor has sighted the badge - or the last sighting is
too old - no currentABSSensor value is present in the ABSTag object and, therefore,
the position attribute has no value, too.
Positioning infrastructure
sensor
17
office room G116
Active
Badge 2
person 533
sensor
18
office room G112
sensor
19
Active
Badge 1
person 549
OMP object model
533:H ookedO bject
objectclass = H ookedO bject
objectclass = H ookedP osition
objectclass = P erson
objectId = 533
hooked-o n
position = g116
attachedTag = 2
managingM M D = ac
homeM M D = ac
lastLocating = 2000-03-06 09:45:12
2:A BS Tag
sighted-by
objectclass = A BS Tag
objectId = 2
position = g116
currentA BS S ensor = 17
managingM M D = ac
homeM M D = ac
lastLocating = 2000-03-06 09:45:12
g116:BasicA rea
objectclass = BasicA rea
objectclass = A BS S ensor
objectclass = O fficeRoom
areaId = g116
presentHookedO bjects = 533
presentHookedO bjects = 549
presentTags = 1
presentTags = 2
aBS S ensorId = 17
sigh ted -by
549:H ookedO bject
objectclass = H ookedO bject
objectclass = H ookedP osition
objectclass = P erson
hook ed-on
objectId = 549
position = g116
attachedTag = 1
managingM M D = ac
homeM M D = ehv
lastLocating = 2000-03-06 09:40:32
1:A BS Tag
objectclass = A BS Tag
objectId = 1
position = g116
currentA BS S ensor = 17
managingM M D = ac
homeM M D = ehv
lastLocating = 2000-03-06 09:40:32
g112:BasicA rea
objectclass = BasicA rea
objectclass = A BS S ensor
objectclass = O fficeRoom
areaId = g112
aBS S ensorId = 18
aBS S ensorId = 19
Figure 22: OMP object model for an example ABS positioning infrastructure
Derivation rules for externally derived attributes may contain parameters. In Figure 23, a
first parameter (objectId) specifies the real-world entity for which data shall be retrieved.
A second parameter (roamingArea) identifies from which physical equipment the information shall be obtained (i.e. it selects the responsible OMPAdapter object associated
with the identified roaming area). The details of how the OMP server interacts with the positioning infrastructure are not specified in the UML model.
Page 93
A BS Tag
>currentA BS S ensor(objectId, roamingA rea)
>currentRoamingA rea(objectId) : E V E N T(new roamingA rea)
>lastLocating(objectId, roamingA rea)
/position(currentA BS S ensor) : S patialA rea(aBS S ensorId=currentA BS S ensor):areaId
Figure 23: Derivation rule for position attribute in object class ABSTag
The currentRoamingArea attribute makes use of a special type of attribute derivation
rule. The attribute value is not retrieved from the positioning infrastructure on initiative of
the OMP server; instead, it is determined on initiative of the external equipment upon the
occurrence of pre-defined events. This rule may be used by mobility management services to monitor changes in the value of currentRoamingArea in order to update the
roamingArea attribute of an ABSTag instance as discussed before.
1.22.4.2 RF positioning
RF positioning systems determine the absolute position of RF tags by measuring the timeof-arrival of a signal exchanged between the tag and multiple base stations as introduced
in section 1.4.3.1. In contrast to IR-based systems, RF-based systems do not require to
install sensors in real-world areas; therefore, no RF sensor object class may be used as
representation in the OMP model. Instead, the object class RFCoordinatesRange has
been defined as subclass of PositioningRegion, representing coordinates in a threedimensional Cartesian coordinate system employed by the RF positioning infrastructure.
In the OMP RF Positioning model, a three-dimensional real-world area is represented by
defining one or multiple rectangular solids. Each of the rectangular solids is represented
by a value of the attribute RFRectangularSolid. Each value specifies the coordinates
of two diagonally opposite corners of the associated real-world rectangular solid (see Figure 25).
An RF positioning system tag is represented in the OMP model by an instance of object
class RFTag. It has an externally derived attribute currentRFCoordinates representing
the real-world three-dimensional coordinates acquired from the positioning system. To determine in which SpatialArea the tag is located, the tag's coordinates must be matched
against all defined rectangular solids. If the tag is located within one of the solids, the tag's
internally derived position attribute is obtained from the associated SpatialArea instance. This attribute derivation rule is part of the RFTag object class definition shown in
Figure 24. The derivation rule operator ^ expresses a selection rule for determining
whether a coordinate is contained within a rectangular solid. If it is contained, the object is
selected to derive an attribute value from it, otherwise not.
Page 94
RF Tag
>currentRF C oordinates(objectId, roamingA rea)
>currentRoamingA rea() : EV EN T(new roamingA rea)
>lastLocating(objectId, roamingA rea)
/position(currentRF C oordinates) : S patialA rea(RF RectangularS olid^currentRF C oordinates):areaId
Figure 24: Derivation rule for position attribute in object class RFTag
An example illustrating the representation of an RF positioning system with OMP objects
is shown in Figure 25.
Positioning infrastructure
y
z
office room G113
office room G115
10
20
RF
tag rf2
10
person 500
0
x
0
0
10
20
30
40
50
OMP object model
500:H ookedO bject
rf2:RF Tag
objectclass = H ookedO bject
objectclass = RF Tag
objectclass = H ookedP osition
objectId = rf2
objectclass = P erson
is-in
position = g115
hooked-on
objectId = 500
managingM M D = ac
position = g115
homeM M D = ac
attachedTag = rf2
currentRF C oordinates = 20x5y 5z
managingM M D = ac
lastLocating = 2000-03-06 09:45:12
homeM M D = ac
lastLocating = 2000-03-06 09:45:12
g115:BasicA rea
objectclass = BasicA rea
objectclass = RF C oordinatesRange
objectclass = O fficeRoom
areaId = g115
presentH ookedO bjects = 500
presentTags = rf2
RF RectangularS olid = 10x0y 0z30x10y 10z
RF RectangularS olid = 20x10y 0z30x20y 10z
g113:BasicA rea
objectclass = BasicA rea
objectclass = RF C oordinatesRange
objectclass = O fficeRoom
areaId = g113
RF RectangularS olid = 32x0y 0z52x10y 10z
Figure 25: OMP object model for an RF positioning infrastructure
RF positioning systems are able to penetrate concrete walls and are able to cover whole
buildings. Therefore, RF tags will be locatable in CompositeArea and BasicArea instances. If a CompositeArea is aggregated with an RFCoordinatesRange and contains further SpatialAreas also being aggregated with RFCoordinatesRanges, more
than one position will be derived for an RF tag. This is so because its currentRFCoordinates are located within more than one rectangular solid. This phenomenon will also
occur in OMP installations with multiple overlapping positioning infrastructures and for
Page 95
HookedObject instances with multiple associated tags. It is the task of the application to
interpret multi-position values in an appropriate way, i.e. to determine which position is the
most detailed.
1.22.4.3 DECT positioning
As an example for positioning infrastructures based on wireless networks, a DECT positioning package has been defined for the Open Mobility Platform. Wireless networks can
be employed to position wireless terminals such as portable phones or laptops by determining the base station to which the terminal is connected. The terminal's real-world position can then be derived from the coverage area of the basestation. The smaller the radio
cells are, the better is the positioning resolution. Since wireless terminals are mainly used
for communication purposes, the object class representing a terminal is defined in the
Service and Terminal Customisation package. The OMP representation of a wireless network basestation is only needed for positioning; therefore, it is defined as part of the Positioning Customisation package.
Page 96
Positioning infrastructure
floor G1
office room G116
DECT
phone d1
person 511
office room G112
DECT
phone d2
person 522
DECT RFP1
OMP object model
d1:P ositionableP hone
objectclass = P ositionableP hone
objectId = d1
connected-w ith
position = g1
currentDE C TRF P = rfp1
currentRoamingA rea = sopho1
g1:C om posit eA rea
managingM M D = ac
ob jectclass = C ompos iteA rea
homeM M D = ac
ob jectclass = DE C TRF P
lastLocating = 2000-03-05 19:47:01
ob jectclass = F lo or
are aI d = g 1
pre sentHo okedO bje cts = 51 1
522:H ookedO bject
pre sentHo okedO bje cts = 52 2
d2:P ositionableP hone
pre sentT ags = d1
objectclass = H ookedO bject
objectclass = P ositionableP hone
pre sentT ags = d2
objectclass = H ookedP osition
objectId = d2
dE CTRF P Id = rfp1
objectclass = P erson
ho oked-on position = g1
objectId = 522
currentDE C TRF P = rfp1
position = g1
currentRoamingA rea = sopho1
con necte d-w ith
attachedTag = d2
managingM M D = ac
managingM M D = ac
homeM M D = ac
homeM M D = ac
lastLocating = 2000-03-06 08:15:42
lastLocating = 2000-03-06 08:15:42
511:H ookedO bject
ob jectclass = H ookedO bject
ob jectclass = H ookedP ositi on
ob jectclass = P ers on
hooked-on
ob jectId = 511
po sition = g1
att ached Tag = d1
ma nagin gM M D = ac
ho meM M D = ac
lastLoca ting = 2000-03-05 1 9:47:01
Figure 26: OMP object model for a DECT positioning infrastructure
The auxiliary object class DECTRFP has been defined as subclass of PositioningRegion and represents the coverage area of a DECT RFP (Radio Fixed Part, the DECT
name for basestations). It is identified by the value of the attribute dECTRFPId that is
unique inside an MMD. It also defines the derivation rule for the externally derived attribute
presentTags whose value contains the object identifiers of all terminals connected to the
DECT RFP. A DECTRFP instance is aggregated with a SpatialArea that equals the
coverage area of the represented basestation. Since DECT radio cells are quite large,
they will typically be aggregated with CompositeArea objects representing, e.g., floors,
halls, or small buildings.
For modelling a DECT terminal, the object class PositionablePhone has been defined
in the Service and Terminal Customisation package. It is defined as subclass of PositionableTerminal defined in the Addressing Framework, which is a subclass of mobileTerminal and MobileTag, since the terminal serves two purposes. In the follow-
Page 97
ing, only the attributes relevant for positioning the terminal are described. The attributes
are similar to those for ABS tags, only the attribute currentDECTRFP is defined instead
of currentABSSensor. Its value contains the identifier of the DECT RFP to which the
terminal is connected. The position attribute derivation also works similar to the ABS
positioning package; it is depicted in Figure 27. An example of a DECT-based positioning
infrastructure and the resulting OMP object model is shown in Figure 26.
P ositionableP hone
>currentD E C TRF P (objectId, roamingA rea)
>currentRoamingA rea(objectId) : E V E N T(new roamingA rea)
>lastLocating(objectId, roamingA rea)
/position(currentD E C TRF P ) : S patialA rea(dE C TRF P Id=currentD E C TRF P ):areaId
Figure 27: Derivation rule for position attribute in PositionablePhone
1.22.5 Addressing Framework
The object classes for supporting the addressing of LocatableObject instances are defined in the OMP Addressing Framework depicted in Figure 28. The main ones are the
Terminal and HookedAddress object classes, for which several subclasses have been
defined to realise different types of mobility, including user and terminal mobility. To support location-aware communication features, the Addressing Framework uses object
classes from the Positioning Framework. This allows sophisticated automatic registration
and "follow-me"-like features for communication services, such as registration on the nearest phone.
1.22.5.1 Terminal addressing
The abstract object class Terminal is a subclass of LocatableObject, and its main
property is to have an address attribute. The value of this attribute contains the communication address that may be used to establish connections to the real-world entity represented by the Terminal object. Depending on the type of terminal, the address value
may for example have the format of an IP address, a telephone number 4, or any other address format. The optional roamingArea attribute represents the communication infrastructure to which the terminal is connected. This attribute is updated by mobility management services whenever the Terminal moves into the coverage area of a different
communication infrastructure, similar to the roamingArea attribute in object class MobileTag. However, the use of the roamingArea value is different for terminals compared to tags. For tags, it is used to determine from which positioning infrastructure the
4
Conventional telephone numbers are treated like addresses in the OMP Framework, and additional terminal identifiers may be associated with terminals with LocatableObject object identifiers. It is, however, also possible to use telephone numbers as object identifiers and manage
communication network-internal port addresses as terminal address in the Open Mobility Platform.
For fixed terminals, identifier and address will typically have the same value.
Page 98
current position can be obtained. For terminals, the roaming area specifies to which communication infrastructure the terminal is connected. This information is required in some
OMP installations - depending on the communication services and the employed equipment - to exchange user and terminal subscription data with the communication equipment. This is further discussed in section 1.22.6.1.
The Addressing Framework defines two basic types of terminals through abstract subclasses of Terminal. A terminal frequently changing its point of network attachment is
represented by an instance of the object class MobileTerminal. Mobile terminals typically represent real-world devices that are carried by their owners, such as laptops or
cordless phones. These types of terminals often communicate over wireless networks, but
they may also employ wired connections. Terminals having a fixed point of network attachment are represented by instances of object class FixedTerminal. These terminals
are usually not carried around but stay at the same place, such as desktop computers or
wired phones. These terminals are typically connected over wires to the network, although
they might use wireless networks for ease of installation.
Fixed terminals
A FixedTerminal object has all the attributes defined for object class Terminal, i.e. an
address and optionally a roamingArea. Since the terminal is stationary, not only its address but also its physical position do not change frequently over time. For this reason, the
OMP model defines the FixedTerminal as being also a subclass of object class
FixedTag. This means that fixed terminals have a position attribute representing their
real-world position. Therefore, HookedObjects can attach themselves onto fixed terminals for being located. This can be used favourably in conjunction with user mobility, allowing users not only to register their communication service on a terminal but also their
position. The purpose of the attribute roamingArea may not be obvious for fixed terminals since the roaming area does not change over time. It is needed for user mobility, allowing a mobile user to register temporarily on a fixed (or mobile) terminal. There, the
roamingArea of the terminal must be known in order to exchange the user's subscription
data with the communication equipment for realising personal allowances and preferences
in the network.
Page 99
0..*
S ubscription F ramew ork
P ositioning F ramew ork
<<auxiliary >>
H ookedP osition
[attachedTag]
/position
/ lastLocating
/managingM M D
<<abstract>>
LocatableO bject
objectId : N
managingM M D
[name]
H ookedO bject
homeM M D
1
<<abstract>>
F ixedTag
<<abstract>>
M obileTag
/position
homeM M D
[>lastLocating]
[roamingA rea]
[>currentRoamingA rea]
has
A ddressingF ramew ork
0..*
<<abstract>>
H ookedA ddress
/hookedA ddress : A
0..*
related-to
<<abstract>>
LocalA ddress
/localTerminal : A
<<abstract>>
RegisteredA ddress
[attachedTerminal] : A
0..1
registered-on
0..*
0..*
<<abstract>>
N earestA ddress
/nearestT erminal : A
<<abstract>>
Terminal
address
[roamingA rea]
0..1
0..1
local-to
0..*
1
<<abstract>>
M obileTerminal
[>currentA ddress]
[>currentRoamingA rea]
homeM M D
<<abstract>>
F ixedTerminal
<<abstract>>
P ositionableTerminal
nearest-to
Figure 28: OMP Addressing Framework
0..*
0..*
Mobile terminals
The MobileTerminal object class is only a subclass of Terminal since it cannot be
assumed that every communication network allows determining the terminal's spatial position. However, for terminals being positionable by their network, a subclass PositionableTerminal has been defined, being also a subclass of MobileTag. The use of
PositionableTerminal objects was already explained in section 1.22.4.3.
The object class MobileTerminal defines these additional attributes:
homeMMD
The value of this attribute represents the identifier of the MMD managing the terminal's
resident subscription.
currentAddress
This externally derived attribute represents the terminal's current address. It is obtained
from the communication network to which the terminal is connected every time the
value changes. This attribute is comparable to the Mobile Station Roaming Number in
GSM networks (cf. section 1.3.1). It represents a temporary address assigned to a terminal used for routing messages to the terminal. A mobility management service may
use this value to update the address attribute in the MobileTerminal object whenever the value of currentAddress changes. To monitor changes in this attribute
value, the OMP event services may be used by the mobility management services.
currentRoamingArea
This externally derived attribute represents the terminal's current roaming area. It is obtained from the communication network to which the terminal is newly connected. A
mobility management service uses this value to update the roamingArea attribute in
Page 100
the MobileTerminal object whenever the value of currentRoamingArea changes.
As holds for the currentAddress attribute, the OMP event services may be used by
the mobility management services to monitor changing values of this attribute.
The terminal object classes of the OMP Addressing Framework are all technologyindependent and may not be used to model real-world devices directly; hence, they are
abstract classes. To represent real-world terminals, appropriate subclasses must be defined in the Service and Terminal Customisation package by either the OMP supplier or
the equipment supplier. Examples for this are discussed in section 1.22.6.
1.22.5.2 HookedObject Addressing
The second major concept defined by the OMP Addressing Framework is the ability of
LocatableObject instances to hook onto terminals for obtaining a communication address. A typical example application of this concept is user mobility, where a mobile user
registers on a terminal to be reachable under the terminal's address. This concept is modelled by the abstract class HookedAddress. A HookedObject instance may aggregate
any number of HookedAddress instances, e.g. to obtain addresses for multiple communication services on different terminals. An example is a user registering on different terminals - and therewith addresses - for phone and fax services.
The address obtained from a terminal is modelled as an internally derived attribute in object class HookedAddress. When aggregating multiple HookedAddress instances into
one HookedObject instance, multiple attribute values would be derived, and the application would be unable to distinguish which address belongs to which communication service. This problem is solved by defining the address attribute as an abstract attribute
hookedAddress instead of defining it as a "normal" attribute. The abstract attribute must
be replaced in non-abstract subclasses by one of its attribute subtypes. With this mechanism, different subclasses of HookedAddress can define different attributes for representing addresses in the Service and Terminal Customisation package. The advantage of
defining the abstract attribute in the abstract superclass as compared to defining the attributes independently in the subclasses is that all address attributes are semantically related with each other and that the developer of the subclass knows that an attribute subtype must be defined in the class.
To express different relation types between HookedObject and Terminal, multiple subclasses of HookedAddress have been defined. These different relation types allow to
model different mobility concepts, ranging from statically coupled registration-like relations
to dynamically coupled relations that associate a HookedObject with a terminal based on
their relative position to each other.
The following abstract object classes have been defined:
RegisteredAddress
The RegisteredAddress object class models a registration of an HookedObject instance on a Terminal instance. The "registered-on" relationship represents a
static many-to-one association between HookedAddress and Terminal. The object
class defines an optional abstract attribute attachedTerminal whose value contains
Page 101
at most one object identifier of the terminal on which the HookedAddress is registered.
In the Service and Terminal Customisation package, subclasses of this object class
may be defined for dedicated communication services. In the subclasses, additional attributes may be and the derivation rule for the hookedAddress attribute must be defined. The derivation rule obtains the value of hookedAddress from the address attribute in that Terminal instance whose identifier equals the value of attachedTerminal. An example for customisation of RegisteredAddress is presented in section
1.22.6.1.
LocalAddress
This object class models an automatic follow-me feature which allows a HookedObject instance to be associated with a FixedTerminal instance which is in the same
SpatialArea. The "local-to" relationship between HookedAddress and FixedTerminal is a dynamic many-to-one association. In order to determine the position of
the HookedObject, the LocalAddress class is defined as a subclass of HookedPosition as shown in Figure 28. It defines an internally derived abstract attribute localTerminal whose value contains the object identifier of at most one FixedTerminal instance that is positioned in the same SpatialArea as the HookedObject. The
LocalAddress derivation rule considers only fixed terminals, since mobile terminals
are usually carried around by their owners, who might be embarrassed by automatic
registrations from other people on their terminal. The derivation rule for this must be defined in a subclass of LocalAddress, see for example 1.22.6.2.
NearestAddress
The object class NearestAddress may be used to model a variant of the LocalAddress-based follow-me feature. The difference is that it associates a HookedAddress
with that FixedTerminal that is positioned spatially closest to the HookedAddress
instance's position. For this, the object class defines an internally derived abstract attribute nearestTerminal whose value contains the object identifier of the fixed terminal being spatially closest to the HookedObject instance. An example for the use of
NearestAddress subclasses is described in section 1.22.6.3.
The mobility concepts of the OMP Addressing Framework described so far are serviceindependent and must be customised to the communication services that shall be supported in an OMP installation. The customisation is done by means of subclasses as described in the following sections.
1.22.6 Service and Terminal Customisation
The purpose of the Service and Terminal Customisation package is to derive communication service-specific subclasses for the abstract classes of the OMP Addressing Framework. The customisation classes may be structured into further sub-packages for each
service, as depicted in Figure 29. In the figure, only two sub-packages are shown, one
each for phone and one fax services. In a real OMP installation, additional packages might
be required depending on the services to be supported. The packages are defined either
by the OMP supplier, by the communication equipment supplier, or by an OMP operator.
Page 102
0..*
0..*
0..*
A ddressingF ramew ork
<<abstract>>
HookedA ddress
0..*
/hookedA ddress : A
related-to
0..1
registered-on
0..1
<<abstract>>
Terminal
address
[roamingA rea]
<<abstract>>
LocalA ddress
/localTerminal : A
0..*
<<abstract>>
RegisteredA ddress
[attachedTerminal] : A
0..*
local-to
<<abstract>>
N earestA ddress
/nearestT erminal : A
0..*
0..1
<<abstract>>
F ixedTerminal
1
<<abstract>>
M obileTerminal
[>currentA ddress]
[>currentRoamingA rea]
homeM M D
nearest-to
<<abstract>>
P ositionableTerminal
S erv ice and Terminal C ustomisation
<<auxiliary >>
P honeRegisteredA ddress
/phoneA ddress
[phoneA ttachedTerminal]
/phoneRoamingA rea
<<auxiliary >>
P honeLocalA ddress
/phoneA ddress
/phoneLocalT erminal
/phoneRoamingA rea
/phoneA ddress()
/phoneRoamingA rea()
#shortN umberRelation()
/phoneLocalT erminal()
/phoneA ddress()
/phoneRoamingA rea()
<<abstract>>
P honeS erv iceP rofile
<P honeS erv iceP rofile>
P hone
F ixedP hone
P ortableP hone
roamingA rea
<DEC TP honeP rofile>
>currentA ddress()
>currentRoamingA rea()
<<auxiliary >>
P honeN earestA ddress
/phoneA ddress
/phoneN earestTerminal
<<abstract>>
C ommonP honeP rofile
<C ommonP honeP rofile>
P ositionableP hone
>currentDEC T RF P
>lastLocating
/phoneA ddress()
/phoneN earestTerminal()
<<auxiliary >>
F axN earestA ddress
/faxA ddress
/faxN earestTerminal
F ax
F ixedF ax
<F axP rofile>
.......
/faxN earestTerminal()
/faxA ddress()
Figure 29: OMP Service and Terminal Customisation
Service-specific subclasses of the abstract terminal classes defined in the OMP Addressing Framework may be defined to represent different types of real-world terminals. For example, the Phone package defines three subclasses: FixedPhone, PortablePhone,
and PositionablePhone. Since all phone types share common characteristics, they are
all subclasses of an additionally defined object class CommonPhoneProfile that represents the so-called profile of the terminal. The latter class defines several attributes not
explicitly shown in Figure 29. Instead, they are abbreviated with an attribute set <CommonPhoneProfile> to keep the specification compact. The attributes specify functional
characteristics of the phone, such as whether it has a loudspeaker, whether it allows to
make international calls, etc. The profile may be used by applications as a selection criterion to search for terminals, and it may be exchanged with the communication equipment
to enforce preferences and allowances for terminals. The contents of the profile may be
static, but they may also change over time. In the latter case, they are either stored in the
Page 103
OMP server or are dynamically obtained from the terminal or networking equipment as externally derived attributes.
FixedPhone
The object class FixedPhone is a subclass of FixedTerminal. It represents a stationary phone, e.g. a wired POTS or ISDN terminal. It may, however, also represent a
PC with built-in voice conferencing capabilities that implements a phone service.
PortablePhone
The PortablePhone object class is used to represent cordless DECT phones. It is a
subclass of MobileTerminal and defines additional attributes. To support installations with multiple DECT clusters, the attribute roamingArea - being only optional in
class Terminal - is defined as mandatory. An additional set of attributes for describing
DECT-specific terminal characteristics, e.g. authentication parameters and terminal
identifiers, is defined as part of <DECTPhoneProfile>. Additionally, the derivation
rules for the externally derived attributes currentAddress and currentRoamingArea are specified. They derive new values for the attributes every time the values obtained from the communication equipment change as depicted in Figure 30.
PositionablePhone
This object class is a subclass of PortablePhone and PositionableTerminal and
is used to represent DECT terminals that may be positioned by the DECT wireless network infrastructure. The attributes that were defined in addition to those of PortablePhone have already been described for the Positioning Customisation package in section 1.22.4.3.
PortablePhone
>currentA ddress(objectid, roamingA rea) : EV ENT(new address)
>currentRoamingA rea(objectId) : EV ENT(new roamingA rea)
Figure 30: Rules in object class PortablePhone
In the following sections, the realisation of mobility features using phone- and fax-related
subclasses of the HookedAddress object class is described in detail. The phone service
subclasses all share a common set of attributes describing a HookedObject's phone
service subscription characteristics. For this reason, they are all subclasses of PhoneServiceProfile for which only an attribute placeholder is shown in Figure 29. The service profile describes the preferences and allowances of the HookedObject instance,
e.g. short dialling numbers, allowances for placing calls, authentication parameters, etc.
These characteristics may be exchanged with communication equipment when the
HookedObject is associated with a terminal to enforce object-specific service settings.
1.22.6.1 Registration on terminal
The object class PhoneRegisteredAddress is defined to allow HookedObject instances to register on a fixed or mobile phone. Since it is a subclass of RegisteredAddress it has to define attributes requested by the abstract attributes of its superclasses.
The resulting attributes are phoneAttachedTerminal and the internally derived attrib-
Page 104
ute phoneAddress. Additionally, an internally derived attribute phoneRoamingArea
represents the roaming area identifier of the terminal to which PhoneRegisteredAddress is attached. The derivation rules for phoneAddress and phoneRoamingArea are
quite similar: From that Terminal instance, whose object identifier equals the value of
phoneAttachedTerminal, the value of address, respectively roamingArea, is used
to derive the attribute values. The corresponding derivation rules are depicted in Figure
31.
<<auxiliary >>
P honeRegisteredA ddress
/phoneA ddress(phoneA ttachedTerminal) : Terminal(objectId=phoneA ttachedTerminal):address
/phoneRoamingA rea(phoneA ttachedTerminal) : Terminal(objectId=phoneA ttachedTerminal):roamingA rea
#shortN umberRelation(phoneRoamingA rea, phoneA ttachedT erminal)
Figure 31: Rules in object class PhoneRegisteredAddress
The use of the phoneRoamingArea attribute shall be illustrated in more detail. The
HookedObject has service-specific settings associated with it, which are represented by
attributes being defined in the PhoneServiceProfile object class. Depending on the
communication equipment, some of these service settings must be physically present in
the communication switch or terminal in order to process the data. This is usually the case
for security- and authentication-related data and data needed for connection set-up. For
this purpose, the Open Mobility Platform allows to export data automatically from its internal database into external communication equipment. In the UML specification, the export
rule for attributes is specified in the operation compartment (starting with "#").
A HookedObject instance has service-specific settings represented for example by the
attribute shortNumberRelation defining short numbers for frequently used dialling
numbers. When the HookedObject is associated with a terminal, its service-specific attributes are exported to the real-world communication equipment serving the terminal. The
attribute phoneRoamingArea indirectly identifies the receiving equipment, since roaming
areas represent coverage areas of physical infrastructures, and is therefore used as parameter in the export rule. The other export rule parameter is the phone's identifier to
specify to which terminal the short number shall be assigned.
An example for the OMP object model representing a phone communication infrastructure
and a HookedObject being attached to a fixed phone 5 is shown in Figure 32. In the example, the registration was performed on a phone of another area than the one the person stays in.
5
In this example, terminal identifier and address have different values. Often the telephone number will serve both purposes as already discussed in section 1.22.5.
Page 105
Communication infrastructure
roaming area sopho1
office room G217
office room G219
ph1
address = 123
ph2
address = 456
person 600
OMP object model
600:H ookedO bject
objectclass = H ookedOb ject
objectclass = P honeR egisteredA d dress
objectclass = P erson
objectId = 6 00
phoneA ttach edTerminal = ph2
mana gingM M D = ac
home M M D = ehv
phoneA ddress = 456
phoneRoamingA rea = sopho1
sh ortN umb erRelation = 1:12345
ph 1:F ixedP hone
objectclass = F ixedP hone
objectId = ph1
managingM M D = ac
address = 123
loudS peaker = y es
roamingA rea = sopho1
position = g217
registered-on
ph2:F ixedP hone
objectclass = F ixedP hone
objectId = ph2
managingM M D = ac
address = 456
loudS peaker = no
roamingA rea = sopho1
position = g219
Figure 32: OMP object model supporting registrations on fixed phones
1.22.6.2 Automatic registration on local terminal
In environments where HookedObject instances are positioned for enabling locationaware applications, the registration on terminals can be performed automatically based on
the physical position of the HookedObject and the terminal. For this purpose, the object
class PhoneLocalAddress was defined. It defines an internally derived single-valued attribute phoneLocalTerminal whose value contains the object identifier of at most one
FixedPhone instance being positioned in the same SpatialArea. The object class also
defines a derivation rule for phoneAddress that works similar to that of class phoneRegisteredAddress, but it uses the values of phoneLocalTerminal instead of phoneAttachedTerminal as selection parameter, as shown in Figure 33.
<<auxiliary >>
P honeLocalA ddress
/phoneLocalTerminal(position) : F ixedP hone(position=position)[1]:objectId
/phoneA ddress(phoneLocalTerminal) : F ixedP hone(objectId=phoneLocalTerminal):address
/phoneRoamingA rea(phoneLocalTerminal) : F ixedP hone(objectId=phoneLocalTerminal):roamingA rea
Figure 33: Rules in object class PhoneLocalAddress
Figure 34 shows an example of the OMP object model representing a phone communication and Active Badge positioning infrastructure with support for automatic registration of
persons on local phones. The PhoneLocalAddress object class can also be combined
Page 106
with PhoneRegisteredAddress by aggregating them both with a HookedObject instance. With such a combination it is possible to download user-specific settings such as
e.g. short numbers onto the nearest phone automatically. For this, a mobility management
service must monitor the phoneLocalTerminal attribute using the OMP event services
and update the phoneAttachedTerminal attribute upon changes.
Communication infrastructure
sensor
17
office room G217
Active
Badge 3
sensor
18
office room G219
ph1
address = 123
sensor
19
ph2
address = 456
person 601
OMP object model
60 1:H o oke dO bj ect
objectclass = H ookedO bject
objectclass = P honeLocalA ddress
objectclass = P erson
objectId = 601
attachedTag = 3
position = g217
phoneLocalTerminal = ph1
phoneA ddress = 123
managingM M D = ac
homeM M D = ac
phoneRoamingA rea = sopho1
shortN umberRelation = 1:04056
hooked-on
3:A BS Tag
objectclass = A BS Tag
objectId = 3
position = g217
currentA BS S ensor = 17
managingM M D = ac
homeM M D = ac
ph1:F ixedP hone
loca l-t o
objectclass = F ixedP hone
objectId = ph1
managingM M D = ac
address = 123
loudS peaker = y es
roamingA rea = sopho1
position = g217
ph2:F ixedP hone
objectclass = F ixedP hone
objectId = ph2
managingM M D = ac
address = 456
loudS peaker = no
roamingA rea = sopho1
position = g219
Figure 34: OMP object model supporting automatic registrations on fixed phones
1.22.6.3 Automatic registration on nearest terminal
For some services, it cannot be assumed that there is always a terminal located in the
same SpatialArea as the HookedObject. A typical example is that of fax machines
and printers which are usually located in a central room and are shared by a number of
users. To determine automatically the address of a fax or printer that is nearest to a
HookedObject instance, the OMP model defines subclasses of the abstract NearestAddress object class.
The class FaxNearestAddress is used to enable automatic registrations on that fax
terminal that is closest to the HookedObject instance. The internally derived singlevalued attribute faxNearestTerminal contains the object identifier of the nearest fax
terminal. The value is obtained by selecting that fax terminal whose position is physically
nearest to the position of the HookedObject instance. In order to perform this selection,
Page 107
the OMP platform has to determine the spatial distance of SpatialAreas. The OMP
platform first determines the distance of all fax terminals to the HookedObject instance
and then selects that fax which has the shortest distance. From that FixedFax object, the
address attribute is used to obtain the faxAddress attribute value. The corresponding
attribute derivation rules are shown in Figure 35. The ~ operator expresses the nearest-to
selection rule.
<<auxiliary >>
F axN earestA ddress
/faxN earestTerminal(position) : F ixedF ax(position~position)[1]:objectId
/faxA ddress(faxN earestTerminal) : F ixedF ax(objectId=faxN earestT erminal):address
Figure 35: Rules in object class FaxNearestAddress
An example where registrations on local phones and nearest fax terminals are combined
is presented in Figure 36. The shown HookedObject is an aggregation of PhoneLocalTerminal and FaxNearestTerminal instances and therefore has two addresses:
phoneAddress and faxAddress, both are determined based on the HookedObject's
physical position determined from its Active Badge.
Communication infrastructure
office room G217
Active
Badge 3
sensor
17
ph1
address = 123
person 602
sensor
18
office room G219
fax1
address = 987
sensor
19
ph2
address = 456
OMP object model
3:A BS Tag
602:H ookedO bject
objectclass = H ookedO bject
objectclass = F axN earestA ddress
objectclass = P honeLocalA ddress
objectclass = P erson
objectId = 602
attachedTag = 3
position = g217
faxN earestTerminal = fax1
faxA ddress = 987
phoneLocalTerminal = ph1
phoneA ddress = 123
managingM M D = ac
homeM M D = ac
hooked-on
nearest-to
local-to
objectclass = A BS Tag
objectId = 3
position = g217
currentA BS S ensor = 17
managingM M D = ac
homeM M D = ac
ph1:F ixedP hone
objectclass = F ixedP hone
objectId = ph1
managingM M D = ac
address = 123
loudS peaker = y es
roamingA rea = sopho1
position = g217
fax1:F ixedF ax
objectclass = F ixedF ax
objectId = fax1
managingM M D = ac
address = 987
position = g219
Figure 36: OMP object model supporting automatic local and nearest registration
Page 108
1.22.7 Object placement model
The object class model presented in the previous sections defines which information must
and which may be contained in the objects managed by the Open Mobility Platform. This
section specifies how the OMP objects are structured inside the OMP server. Since our
aim is to realise the Open Mobility Platform based on directory services, which make use
of a hierarchical placement of information, the OMP information is also organised in a hierarchical fashion. The OMP object placement model specifies a number of placement
rules that constrain the arrangement of objects in an OMP information tree. An example
for an OMP information tree is depicted in Appendix B. It shows an MMD Federation and
two of its Mobility Management Domains.
The object placement model is formulated by means of "placed-below" and "aliasedbelow" associations between object classes, modelled as UML dependency relationships
(see also Appendix A). All instances of an object class having a placed-below dependency to another class, must be placed directly below instances of the superior class.
Placement rules may also be expressed on abstract classes and on structural classes that
are further subclassed. A rule applies to the class for which it is specified and to all its
subclasses, unless a different rule is specified on a subclass. In the latter case, the
placement rule of the subclass has precedence to the class and further subclasses. More
than one placement rule may be specified for an object class; in this case all specified
placements are equally legal for instances of the class. No placement rules may be defined for auxiliary object classes. An aliased-below dependency defines that an additional virtual placement for an object may be generated by creating an alias instance below a specific superior object. The alias allows navigation from the superior object to the
aliased-below object.
Figure 37 shows the placement rules defined for the Open Mobility Platform. All objects
belonging to an MMD Federation - except OMPServer objects - are arranged in a tree that
has as root object either an MMDFederation instance or an MMD instance - if the campus area consists of a single MMD only.
Below an MMDFederation, a single level of further MMDFederation objects or MMD objects may be placed. This is expressed with the placed-below(root) dependency, defining that this association is only allowed, if the superior object is the root of the OMP information tree. To model additional levels of hierarchical containment between MMD Federations and MMDs, logically contained objects may be aliased-below superior objects,
e.g. to facilitate searching in MMD Federations. Additionally, a RoamingArea object and a
subtree with OMPUser objects may be placed below MMDFederation objects.
The OMPUser objects are placed below an additionally-defined object of class Users that
allows structuring the users into better manageable subtrees. The subtrees may be placed
below an MMDFederation or an MMD entry. They may also be aliased-below an MMD entry if they are replicated. A RoamingArea object placed below the root MMDFederation
object is used as root for a global subtree of MMDPointer objects. This subtree must additionally be aliased below an MMD to find entries in this subtree with search operations
starting below that MMD. A RoamingArea object placed below a non-root MMDFedera-
Page 109
tion object may be used as subtree of MMDPointer objects in hierarchical mobility management schemes.
Below an MMD object, objects of class SpatialArea are allowed. SpatialArea objects
structure the physical areas defined inside an MMD. CompositeArea objects can be hierarchically nested, whereas a BasicArea may not contain other areas. Below each type
of SpatialArea, either Map or FixedTag objects may be placed. Map objects contain
graphical images covering the area placed directly above and any number of its subareas. FixedTag objects may be placed below a SpatialArea object when the associated real-world entity is physically located in the represented real-world area. The hierarchical arrangement of areas and fixed objects reflects real-world containment relations, allowing an OMP user to browse through the information tree and incrementally discover the
OMP object model in a natural way. OMPServer objects are not placed in the MMDFederation tree and are therefore not accessible by navigating through the tree.
placed-below(root)
aliased-below
RoamingArea
placed-below
aliased-below
placed-below
placed-below
OMPAdapter
placed-below
placed-below
MMDPointer
<<abstract>>
SpatialArea
Objects
Users
CompositeArea
placed-below
placed-below
OMPUser
placed-below
placed-below
<<abstract>>
LocatableObject
placed-below
aliased-below
placed-below
placed-below
placed-below
placed-below(root)
MMD
RoamingArea
placed-below
Objects
MMDFederation
placed-below
aliased-below
<<abstract>>
FixedTag
placed-below
Map
OMPServer
Figure 37: OMP object placement rules
RoamingArea objects placed below MMDs are used for OMP objects representing residents or visitors of that particular MMD. To structure the coverage areas of communication
and positioning infrastructures installed at an MMD, roamingArea instances may be
placed below each other. OMPAdapter objects may be placed below roamingArea objects. An additional object class Objects was defined that allows grouping of LocatableObject instances according to common characteristics inside a roaming area, e.g.
according to resident and visitor subscriptions. The containment tree of roaming areas
should be designed so that LocatableObject instances do not have to be moved between subtrees if they roam between roaming areas in the same MMD. Therefore, for
each type of infrastructure there should be a single roamingArea entry under which all
Page 110
resident and visitor subscriptions to that infrastructure are placed. An example of such a
tree is shown in Appendix B.
1.23 Realisation of OMP model with X.500 information model
The aim of this thesis is to realise the Open Mobility Platform on LDAP directory services
which are functionally extended - where required - but are on the access protocol level as
standards-compliant as possible. The OMP information model must therefore be based on
the X.500 information model to be functionally compliant with directory services. In this
section, the different OMP information model elements are mapped on the available X.500
information model elements, and requirements for extensions of the X.500 information
model are identified. These requirements form the basis for the development of the Dynamic Directory Services specification presented in chapter 0.
OMP objects and object classes: OMP objects may be realised with X.500 entries, and
OMP object classes can be mapped directly onto X.500 object classes. Structural, auxiliary and abstract object classes are all supported in X.500 as required by the OMP specification.
Attributes: Attributes of OMP objects can be mapped directly on X.500 attributes. For
most OMP attributes, the attribute syntax DirectoryString [RFC2252] is used, exceptions see below. The OMP attribute objectClass directly maps on the X.500 attribute
objectClass. The restrictions on the number of attribute values specified for some OMP
attributes can be realised using the X.500 attribute type definitions. Attribute sets < > in
object class definitions are used in the UML model to represent a set of attributes that
shall not be explicitly shown for legibility reasons. This maps on the attribute set used in
[X.521] for defining X.500 object classes. For realising the OMP with directory services, the
attribute sets have to be expanded into fully specified attributes. Abstract attributes used
in the OMP model are not supported in X.500 and must be developed as part of the Dynamic Directory Services based on the X.500 attribute subtype mechanisms [X.501].
Subclassing and subtyping: Subclassing as used in the UML model, including multiple
inheritance, is supported by the X.500 information model. Subtyping of attributes is also
possible in the X.500 information model.
Aggregation: The restrictions expressed in the UML diagrams on the auxiliary object
classes that may be aggregated with structural object classes can be specified in X.500
using DIT content rules. If multiple instances of the same auxiliary object class are aggregated, every attribute will occur only once in the compound entry but will have multiple
values. Therefore, restrictions on the number of auxiliary classes that may be aggregated
must be expressed in the X.500 attribute type description with restrictions on the attribute's number of allowed values.
Object naming and placement rules: The naming and placement rules defined in the
UML specifications can be mapped on X.500 name forms and DIT structure rules. For
each OMP structural object class, a name form must be provided that defines which atPage 111
tributes are used for naming the entry, i.e. forming its RDN. The RDN attributes are identified in the UML object class definitions with the attribute type "N". Additionally, for each
name form at least one DIT structure rule must be defined that identifies the superior
name forms - and thereby the allowed superior object classes - for that particular object
class. The aliased-below relationship used in section 1.22.7 can be realised by placing
X.500 alias entries below instances of the indicated superior entry.
A difference between the UML specification and an X.500-compliant realisation is that
X.500 requires specifying naming and placement rules on structural object classes only.
Furthermore, the rules only apply to the named class, not to subclasses of that class. In
the UML specification, we allocated naming and placement rules for superclasses and
even abstract object classes to make the specification compact. The mapping on X.500
therefore requires to expand the UML rules onto every individual structural object class,
which is a straightforward procedure but makes the X.500 directory schema definition
more redundant compared to the UML specification.
Packages. Packages are used in the UML model to structure the specification into related
sets of object classes. They are used for making the specification legible and compact.
X.500 does not offer a similar construct; there are no containers to structure object class
definitions. For realising the OMP with directory services, this feature is useful but not
mandatory.
Derived attributes: The OMP model makes intensive use of derived attributes, i.e. attributes whose values are internally derived from other entries or externally derived from positioning or communication infrastructures. The X.500 information model does not support
derived attributes; therefore, this is one of the extensions that must be developed as part
of the Dynamic Directory Services.
The UML object class specifications prescribe which derived attributes must and may be
present in an OMP object. Attribute types may in one object class be a normal attribute
and in another object class a derived one (e.g. address, position). Furthermore, it
must be possible to override a normal attribute as derived attribute in a subclass. Hence,
the specification whether an attribute is a derived one or not must be part of the object
class definition, not of the attribute type definition. The X.500 object class definitions must
be extended in the Dynamic Directory Services with a mechanism for specifying attributes
as derived attributes.
Attribute derivation rules: The derivation rules for internally and externally derived attributes are specified in the OMP object class definitions. The rules may be inherited from superclasses and may be aggregated (the latter only for internally derived attributes). A
straightforward mapping to an X.500 information model would imply to extend the X.500
object class definitions with a means for expressing derivation rules. An alternative is to
model the derivation rules as collective operational attributes which are defined in subentries and apply to all entries of a particular object class. This second solution has the advantages that it does not require the further extending of the X.500 object class specification mechanisms, provides built-in support for inheritance and aggregation, and allows
OMP clients to manage derivation rules - as far as allowed - using the existing directory
Page 112
access services. The Dynamic Directory Services therefore should support attribute derivation rules in form of collective operational attributes.
The OMP derivation rules for internally derived attributes make use of entry selection
mechanisms. At least all derivation rules used for the OMP specification must be supported by the new operational attributes: Equality selection, nearest-to selection, contains selection, and children selection. The derivation rules should be developed in such a way that
entry selection rules can be mapped on X.500 matching rules. Some of the OMP attribute
derivation rules cannot be mapped on existing X.500 matching rules: The Dynamic Directory Services must provide a containment matching rule to determine whether a point is
contained in a rectangular solid and vice versa. Additionally, they must provide a nearestMatch matching rule to determine which position is spatially nearest to another position.
Exported attributes: The OMP model makes use of an attribute export functionality that
allows to synchronise the contents of OMP attributes with databases in external infrastructures, with the master copy being held by the OMP server. This functionality cannot be
mapped on proposed LDAP replication mechanisms because they provide only asynchronous replication mechanisms between directory servers. The Dynamic Directory Services
must therefore offer an attribute export capability that allows tightly synchronising attributes with external servers.
Event monitoring: The OMP specification requires that clients are able to monitor the
contents of OMP objects and are informed when pre-defined changes occur. The monitoring must be possible on normal but also on internally or externally derived attributes.
Event monitoring functionality is not supported by the X.500 information model and the
LDAP standards but is of major importance for realising the Open Mobility Platform. The
proposed persistent search LDAP operation cannot meet the OMP requirements since it
does not support derived attributes and cannot express event conditions on attribute value
changes (required e.g. to express conditions such as "enters an area", "leaves an area",
etc.). The procedure triggering proposals LTAP and Netscape plug-ins are also not applicable, because LTAP is not suited for derived attributes and plug-ins do not allow defining
events without recompiling the server code. Therefore, the Dynamic Directory Services
must provide new event monitoring functionality.
Mapping of particular object classes
MMD object: The MMD object is mapped on an entry that forms the root of an X.500 naming
context. In this way, all objects held in an OMP MMD are part of the same X.500 naming context. This facilitates to use the MMD entry as base object for search operations
and allows to generate continuation references to other MMDs that include a new base
object (i.e. MMD entry) to be used by the OMP client at the indicated server.
MMDFederation object: This object can be used as root entry of X.500 naming contexts,
similar to the MMD object.
MMDPointer object: The MMDPointer object can be mapped on an X.500 alias entry
that contains the Distinguished Name of the requested OMP object in that MMD which
should be contacted next by the client. MMDPointer must be a subclass of alias,
since it contains additional attributes besides the mandatory aliasedObjectName atPage 113
tribute [RFC2256]. The alias points to the MMD that is identified in the entry's managingMMD attribute. The attribute aliasedObjectName contains a DN that identifies the
OMP object in its MMD naming context. When the client searches for the alias OMP object, the LDAP directory server will generate a continuation reference identifying the
server that holds the entry which is referenced by the alias entry. The knowledge about
naming contexts held by other directory servers must be held in DSEs not shown in the
OMP model UML specifications.
OMPServer object: The OMPServer object is mapped on the root DSE and subschema
entries of an LDAP directory server. The root DSE contains among others the names of
subschema entries relevant for this server. In the subschema entries, information about
the enforced schema is available to the OMP client.
Adapter object: The OMPAdapter and Adapter object classes cannot be mapped on
any existing X.500 feature and must be developed as part of the Dynamic Directory
Services.
Mapping of particular attribute syntaxes
graphicalMap attribute: The OMP attribute graphicalMap can be mapped for example
on the LDAP attribute syntax JPEG, which provides a string encoding of JPEG images
[RFC2252].
RFRectangularSolid attribute: The OMP attribute RFRectangularSolid represents
a rectangular solid in a three-dimensional Cartesian coordinate system. A matching rule
shall be applicable to this attribute type for determining whether a point is contained in
the solid or not. Therefore, a new attribute syntax for three-dimensional rectangular solids and associated matching rules must be developed as part of the Dynamic Directory
Services.
currentRFCoordinates attribute: The OMP attribute currentRFcoordinates represents a point in a three-dimensional Cartesian coordinate system. A matching rule is
required that allows to determine whether a rectangular solid (see above) contains this
point or not. A new attribute syntax must be defined for three-dimensional points as part
of the Dynamic Directory Services, and associated matching rules must be developed.
1.24 Realisation of OMP support services with LDAP services
The OMP mobility support services identified in section 1.21 must be realised based on
the LDAP directory services for accessing the OMP information model specified in the
previous sections. In the following, the realisation of the mobility support services using
LDAP directory services and the X.500-based OMP information model will be discussed6.
For each category of support services, the relevant parts of the information model and the
LDAP services that are used by the OMP client are identified. Furthermore, the discussions will disclose where the X.500 information model or the LDAP services have to be
6
Early versions of subsets of these mappings have been presented by us in [Maass97a],
[Maass98], [Maass98a].
Page 114
further extended by our Dynamic Directory Services to provide all the required functionality
to OMP clients.
1.24.1 Location handling services
The main purpose of location handling services is to allow OMP clients to retrieve the current location of real-world entities that are subscribed to the OMP platform. The location
encompasses in the OMP model either the address or the position of the real-world entity,
or both. A complementary function is to determine which real-world entities are located in
a given area.
 Location retrieval is realised by means of the LDAP search service. The client searches
for an entry of object class LocatableObject with a search filter on the entry's objectId attribute. The client must start its search from a Mobility Management Domain
root entry and search the whole MMD subtree. This allows that LocatableObject entries are placed anywhere in the OMP tree without influencing the functionality of the location handling services. The client either requests all attributes to be returned or specifies in which attributes it is interested. The latter has the advantage that only those internally and externally derived attributes in which the client is interested have to be determined by the OMP server. Retrieving the identifiers of real-world entities present in
an area is also realised by an LDAP subtree search, asking for an entry of object class
SpatialArea with an equality filter on the attribute areaIdentifier. At least the attribute presentHookedObjects should be requested by the OMP client.
Frequently-changing location information should not be stored in the OMP server but
should be dynamically obtained from external infrastructures to avoid the provisioning of
stale data and to avoid frequent updates on OMP server data.
 Position data of mobile entities might change very frequently, depending on their mobility and the size of the areas. The frequency of address changes for mobile terminals
depends on the sizes of the radio cells and on the network structure of the wireless
network. If an address is related to a radio cell it changes more often than if related to a
subnetwork. In our OMP model we assume that addresses change infrequently enough
to store them in the OMP server in an address attribute which is updated by mobility
management services (see discussion below). For position information the OMP model
assumes that it changes too frequently to be stored in the OMP server, instead it is obtained on demand from the positioning infrastructures. This is achieved by modelling
the position attribute of tags as externally derived attribute whose values are dynamically obtained when the entry is retrieved by a client, see Figure 38. From the viewpoint
of a client, derived attributes are indistinguishable from "normal" attributes except for
the fact that they may not be modified. If the assumptions on data volatility should not
hold in future OMP installations, the OMP model may be easily adapted by an OMP
operator with simple modifications to the OMP schema.
To reduce processing effort, the OMP server may make use of caching to buffer data
obtained from external servers for use in subsequent client requests. The OMP client
should be able to control whether or not cached data are used for externally derived at-
Page 115
tributes with a new LDAP service control implemented by our Dynamic Directory Services.
Application
OMP server
Positioning
infrastructure
Search(objectId=x)
……
get tag location (objectId=y)
get externally
derived attributes
……
sensorId
SearchResult(position)
Figure 38: Message sequence for retrieving externally derived attributes
Obtaining location data about real-world entities must be possible from every OMP Mobility Management Domain, independent of the actual location of the real-world entity.
 To support distributed location handling from multiple Mobility Management Domains,
the concept of resident and visitor subscriptions is used in combination with MMD
pointers. This allows realising arbitrary location handling schemes, ranging from flat
schemes to hierarchical ones. A resident subscription - and thereby a LocatableObject entry - is created at the MMD where the real-world entity normally stays, also
called home MMD. At all MMDs from which the entity shall be locatable except the
home MMD, MMDPointer entries are created which point at least to the entry's home
MMD. These pointers are also called home pointers. When the real-world entity moves
to another MMD - then called visited MMD - an additional visitor subscription is created.
Both subscriptions and all home pointers of an entity have the same objectIdentifier value.
When an OMP client's search request results in an MMDPointer or LocatableObject entry that points to another MMD with its managingMMD attribute, an LDAP continuation reference is returned to the client. It identifies the OMPServer of the managing
MMD and the new base object to use. This continuation reference may be used by an
enhanced LDAP API to repeat the LDAP request at the identified server automatically.
Thereby the distribution of location handling across OMP servers may be hidden from
OMP clients as shown in the message sequence chart in Figure 39.
Page 116
Application LDAP API
OMP server1 at MMD1
OMP server2 at MMD2
OMP server3 at MMD3
Search(objectId=x: managingMMD, position)
MMD pointer entry matches
SearchResult(managingMMD=MMD2)
Continuation reference(server2)
detect missing
attribute position
Search(objectId=x: managingMMD, position)
SearchResult(managingMMD=MMD3)
resident subscription
entry matches
Continuation reference(server3)
detect missing
attribute position
Search(objectId=x: managingMMD, position)
visitor subscription
entry matches
get externally
derived attributes
……
SearchResult(managingMMD=3, position=G1)
Figure 39: Distributed location handling hidden by an enhanced LDAP API
In a flat location handling scheme, the managingMMD attribute in the resident and visitor subscription always points directly to the visited MMD. The managingMMD attribute
in the MMDPointer entry points to the home MMD or the visited MMD, the latter may
occur if the MMD is being visited by the mobile real-world entity. If an OMP client invokes location handling services by issuing an LDAP search below an MMD root of the
OMP server to which it is connected, one of the following four cases may occur:
1. The MMD is the home MMD: In this case, the search will return the resident subscription entry. If the entity stays at the MMD, all requested information is present in
the entry. If the entity stays at another MMD, only the managingMMD attribute will be
returned together with an LDAP continuation reference to the OMP server managing
the identified MMD. From this information, the OMP client can then determine which
MMD must be contacted to obtain further location information. The information can
even be interpreted automatically by an enhanced LDAP API that detects that not all
requested information was returned and then follows the continuation reference and
repeats the request at the identified MMD.
2. The MMD is the visited MMD: In this case, the search will return the visitor subscription entry containing all requested information. Additionally, an MMDPointer entry
may be returned to the client, which should be ignored since it is not needed for locating the entity in this case.
3. The MMD has only a home pointer but no subscription: The search will return the
MMDPointer entry containing only the homeMMD and managingMMD attributes. Additionally, a continuation reference to the OMP server managing the home MMD is
returned. The further client processing is the same as in case 1. The client or the
LDAP API next contacts the home MMD and repeats its request as shown in Figure
39
Page 117
4. The MMD has no knowledge about the entity: In this case, no entry matching the
search request is found in the local MMD tree. The client then must repeat the request with the MMDFederation root entry as search base object. The request is
then forwarded to all OMP servers by continuation references (or by chaining if this
is supported in future LDAP versions). The processing of this last case is very resource-costly because all servers must process the request. This should therefore
be avoided by creating home pointers at all MMDs from which the entity is frequently
located by OMP clients.
In hierarchical location handling schemes, the managingMMD attribute does not necessarily point to the visited MMD directly but it may also point to an MMD Federation. The
MMD Federation only contains MMDPointer entries that identify the next managing
MMD that should be contacted. This allows an OMP operator to set up arbitrary
schemes of location pointers, optimised to the mobility patterns of mobile objects belonging to an OMP installation.
For non-mobile real-world entities, location handling services must allow to store and update the real-world address or position in the OMP server.
 This is realised by the position and address attributes in FixedTag and FixedTerminal entries. An OMP client having appropriate access rights may update the
values using LDAP modify services. First, the client must determine the Distinguished
Name of the object with a search request using its object identifier as filter; then, it can
update the entry as required.
Location handling services must allow OMP clients to monitor changes in location data efficiently without having to poll the OMP server continuously.
 Monitoring changes in location information is supported by the OMP event services as
described below. Location-related events are defined and notified in the same way as
any other events.
OMP clients must be able to retrieve information about real-world entities based on their
absolute position or spatial distance to a given position. An example is to obtain information about a printer that is nearest to the client.
 Retrieving information selected by absolute positions as parameters is based on LDAP
search with an equality match on area identifiers. An additional search filter may specify
the type of object being searched for, e.g. its object class or properties of other attributes. To support retrieving entries based on their spatial distance to a given position, a
new matching rule must be developed for the Dynamic Directory Services. The matching rule must return an entry that is spatially nearest to a given position specified with
an area identifier as described in section 1.23. This is discussed in detail below, in context with the OMP trading services that provide a generic variant of this matching rule
functionality.
OMP servers must provide graphical maps for real-world areas to OMP clients, e.g. for
navigation applications. Additionally, waypoint information should be retrievable from the
OMP server.
Page 118
 The OMP clients must search for entries of class Map that have one value of their coveredAreas attribute in common with the area identifier provided in the search request.
The position of the Map entry in the OMP tree is not relevant for the support service. To
support incremental browsing services by OMP clients, maps are placed below the hierarchically highest area they cover. Waypoint information related to an OMP position
may be supported easily by deriving environment-specific subclasses of FixedTag to
represent information of interest to OMP users.
The OMP must support management, i.e. creation, modification, and deletion of LocatableObject subscriptions.
 Management of subscriptions is possible using LDAP add, modify and delete services.
Management of home pointers can be performed efficiently by first creating a subtree
with all globally-required MMDPointer entries below an MMDFederation entry at one
OMP server, and then replicating this subtree to every OMP server that needs home
pointers. In this way, clients can manage home pointers easily by just modifying a single entry; the propagation of these updates to all MMDs is handled by the LDAP shadowing mechanisms. If the home pointers are placed below an MMDFederation entry,
an alias entry that points to the root entry of the home pointer subtree must be placed
below the MMD entry. This alias entry is dereferenced during searches under an MMD,
and thereby the home pointers are included in the search as described above. Minor
disadvantages of replicating home pointers is that the currentMMD attribute may not
be updated to indicate that a user is visiting the local MMD and that a home pointer is
also created at the home MMD.
The OMP platform must support roaming of mobile real-world entities between Mobility
Management Domains and between positioning and communication infrastructures being
operated by the same MMD.
 To support roaming between MMDs, dedicated OMP clients implementing mobility
management services are required. They must be implemented by the equipment provider or the OMP operator. When a mobile tag or terminal roams into the coverage area
of another MMD, the mobility management service at the new MMD detects its arrival
from a notification it gets from the OMP event services. The notification contains the
associated object identifier with which the mobility management service then searches
for the resident subscription. It creates a local visitor subscription with LDAP add services and updates the managingMMD attribute in the resident subscription to point to
the local MMD. Furthermore, the mobility management service must check whether it
must repeat the procedure for HookedObject entries that are attached to the roaming
terminal or tag. An example LDAP operation sequence for roaming of tags between
MMDs is shown in Figure 40.
If devices roam between infrastructures inside the same MMD, not the subscription but
only the roaming area identifiers must be updated. The infrastructure that serves a realworld entity is represented in LocatableObject entries by attributes containing the
roaming area identifier. The roaming area identifier is used by the OMP model for processing external attribute derivation rules and for exchanging information with the external equipment. When a mobile object roams into the coverage area of another roaming
area, the roaming area identifier in LocatableObject is updated accordingly by the
Page 119
mobility management service. To monitor changes in the current roaming area, the mobility management service makes use of the OMP event support services. Simple but
commonly employed mobility management services that only copy the externally provided roaming area identifier onto an OMP-internal attribute, should optionally be supported solely by OMP event handling functionality without the need for additional mobility management services.
tag roams
222
2
subscribe to event
“tag enters MMD”
objectId=533
3 notify
OMP
client
old visiting MMD
of tag 222
delete
add
6
8
/local/abs/visitors
222
tag
entry
/global/residents
222
MMDPointer
homeMMD=3
OMP
client
1
search
4
search
5
OMP
client
home MMD
7 update of tag 222
/local/abs/visitors
/global/residents
/local/abs/residents
222
tag entry
managingMMD=2
222
MMDPointer
homeMMD=3
222
tag entry
managingMMD=1->2
MMD = 1
MMD = 2
MMD = 3
Figure 40: Example mobility management service for tag roaming
If only a HookedObject without attached mobile terminal or tag arrives at a new MMD
(i.e. user mobility), this is detected as soon as the real-world entity tries to register on a
local terminal or tag. The registration procedure will detect that there is no local subscription available and will create a visitor subscription as described above.
1.24.2 Profile handling services
The OMP must allow to store, update, and retrieve service subscription profiles of realworld users.
 The OMP subclasses of HookedAddress have service-specific attributes to represent
service profile characteristics. The attributes are modelled with attribute sets, such as
e.g. <PhoneServiceProfile> to keep the specification compact. The attributes contained in the set are created at subscription time with an LDAP add service creating a
HookedAddress subclass entry aggregated with a LocatableObject entry. The
subscription parameters may be accessed by OMP clients using LDAP modify and
search services.
The OMP must allow to store, update, and retrieve device characteristics of real-world
terminals and tags.
 The OMP subclasses of Terminal have device-specific attributes to represent device
characteristics. The attribute sets such as, e.g., <CommonPhoneProfile> and
Page 120
<DECTPhoneProifile> serve as placeholders to keep the specification compact. The
attribute sets are created at subscription time with an LDAP add service creating a LocatableObject subclass entry and may be accessed by OMP clients using LDAP
modify and search services, like the service subscription characteristics. Profile characteristics of tags may be added in technology-specific subsclasses of object class Tag.
It must be possible to exchange subscription parameters and terminal profiles with communication equipment automatically in order to personalise service characteristics and allowances.
 An OMP server implementing the Dynamic Directory Services is able to synchronise attributes from its internal database with external equipment by means of attribute export
rules. The interfacing between the OMP model and the equipment is specified in OMPAdapter entries being identified by the roaming area to which a LocatableObject
entry is associated. Whenever exported attributes are added, modified, or deleted by
OMP clients using LDAP access services, the OMP server modifies its internal database and forwards the modification request to the external equipment. If the external
synchronisation fails, the internal modification is also cancelled in order to keep exported information consistent with the OMP server database.
OMP servers must allow clients to search for real-world entities with certain characteristics
specified in their profile.
 This is realised by LDAP services using search filters with matching rules on profile attributes; see also the description about yellow pages directory services.
OMP servers must allow clients to monitor changes in subscription and terminal characteristics without having to poll the server continuously.
 This is achieved by means of the OMP event handling services that allow monitoring
changes in any information held by the OMP server.
OMP profiles must be able to contain application-specific information to support searching
and formulating event monitoring conditions on that data.
 Application-specific attributes may easily be added to the OMP schema by defining auxiliary object classes and aggregating their entries with LocatableObject or SpatialArea entries. If the information held in the OMP server is redundant with information
held in other application databases, it is the task of the application to keep data consistent. Whenever the externally held application data are changed, the application must
update the OMP-internal data using LDAP modify operations.
1.24.3 Event handling services
OMP clients must be supported in monitoring the contents of an OMP server. They shall
be able to formulate event conditions that trigger a notification of the client when the specified event occurs. OMP clients should also be able to share event definitions of general interest to reduce the processing burden of the directory server and to simplify event handling initiation.
Page 121
 OMP servers based on our Dynamic Directory Services allow clients to formulate event
conditions by means of LDAP services. The conditions apply to the OMP server contents and contents from external sources, such as positioning and communication infrastructures. Whenever a specified condition is fulfilled, a notification is sent to the OMP
client using an LDAP message. The message contains information about which entry
caused the notification and, optionally, further client-requested attribute values of the
entry. The interaction principle between application and OMP server is depicted in Figure 41.
Application
OMP server
DefineEvent
start monitoring
SubscribeEvent
EventNotification
event fires
event fires
EventNotification
CancelEvent
stop monitoring
Figure 41: OMP event handling message sequence
Sharing of event definitions by clients is enabled by separating the definition of an event
from the subscription to notifications. The exact realisation using LDAP messages is
discussed in chapter 1.28.
OMP servers must allow monitoring of location-related events.
 The OMP model represents location information, i.e. addresses or positions, as LDAP
attributes. Therefore, the generic event handling services of the Dynamic Directory Services are also applicable to monitor location-related events. The event condition syntax
must be powerful enough to formulate real-world conditions such as "enters an area",
"leaves an area", etc. This functionality cannot be realised with the proposed persistent
search since it does not allow to define conditions on attribute value changes. Instead,
a more powerful LDAP event handling mechanism must be developed as part of the
Dynamic Directory Services. The monitored location information may be an externally
derived attribute value. In this case, the OMP server may delegate the monitoring of
these attributes to the external equipment providing the attribute values.
OMP servers should support simple mobility management without requiring additional mobility management services.
 The event handling features of our Dynamic Directory Services should allow specifying
simple LDAP operations to be performed when event conditions are fulfilled. This can
Page 122
be used for example to update roaming area identifier attributes when the current roaming area changes.
OMP clients must be supported in monitoring profile-related events, e.g. allowing adaptive
applications to be notified that the terminal on which they are running has changed its
characteristics.
 This functionality may be realised using the event handling features of the Dynamic Directory Services since profile attributes can be monitored as any other attribute. The
profile may contain externally derived attributes that have to be monitored, too. In this
case, the OMP server may delegate the monitoring of these attributes to the external
equipment providing the attribute values.
Application
OMP server
DefineEvent
start monitoring
SubscribeEvent
event fires
EventNotification
event fires
power off or
disconnected
EventNotification
Re-SubscribeEvent
EventNotification
Figure 42: OMP event notifications with temporary application unavailability
Since OMP applications running on mobile terminals will often be temporarily suspended
or disconnected, the OMP should offer a mechanism to buffer notifications in the server,
allowing applications to receive all event notifications in spite of temporary unavailability.
The application must be able to control which of the missed notifications are sent again by
the server, e.g. only the last one.
 This functionality requires that event notifications are temporarily stored in the Dynamic
Directory so that applications that become available again can optionally request all or
some notifications they missed during their unavailability as depicted in Figure 42. This
functionality is also not supportable by LDAP persistent search. This feature could be
partly realised by underlying transport mechanisms such as message queues, but their
general availability in OMP environments cannot be assumed, and they do not allow to
selectively obtain missed notifications.
Page 123
1.24.4 Directory services
The OMP platform must support white pages services, i.e. provide information about realworld entities selected by an identifier or name.
 Since the OMP is based on directory services, and LocatableObject and SpatialArea entries have unique identifiers associated with them, white pages services are
inherently supported. The client issues a subtree search below the local MMD root for
LDAP entries that match the given identifier in their RDN attribute such as objectId or
areaId. When a pointer to another MMD (i.e. an alias entry returning a DN outside any
local naming context) is encountered during a white pages search request, a continuation reference is returned to the client pointing to the OMP server where the request
should be redirected. Any number of additional unique name attributes may be associated with objects managed by the OMP, e.g. to add application-specific identifiers and
names.
The OMP platform must support yellow pages services, i.e. provide information about realworld entities selected by search criteria.
 The OMP information model has a deep inheritance hierarchy and makes intensive use
of aggregation. It thereby allows clients to make effective use of the objectClass attribute as a search criterion, e.g. to search for selected types of objects or areas. Additional search criteria can be formulated using any of the attributes defined in the OMP
object class model including service subscription and terminal profile attributes and application-specific attributes. Yellow pages search requests will only find matching entries
below the search root specified by the client. The search request must therefore be
started below the MMD object if only local OMP objects are of interest, or the search
must start under the MMDFederation root object to initiate a global search. To facilitate searches below MMD Federations that are not the root MMD Federation, it is necessary to place alias entries below the intermediate MMD Federation that points to the
MMDs being logically included in the Federation. This is modelled in the OMP placement model of section 1.22.7 with the aliased-below relationships between MMD and
MMDFederation objects.
1.24.5 Trading services
OMP trading services allow clients to retrieve information about real-world entities that fulfil search criteria optimally, such as, for example, being cheapest, fastest, or nearest. The
client must be able to select how many results - sorted according to the optimisation criterion - are returned.
 This feature can be mapped on the LDAP search service. The search filter must specify
selection criteria and optimisation criteria. The first kind of criteria are expressed by the
existing LDAP matching rules, whereas for the latter a new matching rule called nearestMatch must be developed as part of the Dynamic Directory Services. The number
of returned results is controlled by the size limit parameter of the LDAP search request.
This service cannot be realised with LDAP server-side sorting (cf. section 1.18), since
Page 124
that only supports sorting in ascending or descending attribute value order, not sorting
according to the difference of attribute values to a given value.
The nearestMatch matching rule must be applicable for commonly-used attribute syntaxes representing strings and numeric values and for OMP attributes representing positions (i.e. area identifiers).
 The OMP server can derive from an attribute's type which matching rules must be applied to a particular attribute. All OMP attributes representing physical positions, i.e.
area identifiers, must be identified in the matchingRuleUse specification (see an example in section 1.29.1.4) of the new nearestMatch matching rule.
The nearestMatch matching rule must be applicable to "normal" attributes as well as to
derived attributes.
 The nearestMatch filter for externally derived attributes should be used with care, because it implies that for a number of candidate entries fulfilling the selection criteria, all
externally derived attribute values must be determined. Thereafter, the OMP server can
decide which entry fulfils the nearestMatch filter best. This may lead to significant
processing effort and response times. An OMP client should therefore specify very narrow selection criteria, so that the number of matching candidate objects is as small as
possible.
The OMP server should offer type management functions to OMP clients, e.g. to determine subtypes and compatibility between types of OMP objects, such as types of terminals, services, tags, areas.
 Basic support for determining subtypes is provided by the deep inheritance hierarchy of
the OMP information model. Since the types of all superclasses and aggregated
classes (and their superclasses) are present in the objectClass attribute, a client can
derive subtype relationships between entries. To express semantic compatibility relationships between entries that are not already expressed through subtyping, an additional attribute compatibleClass may be defined for object classes for which type
management shall be supported. From the values of this attribute, a client may determine the objectClass value of semantically compatible object classes, similar to the
type management graph representation in X.500 proposed in [ Klotz92]. If compatible object classes contain attributes with similar semantics but different attribute names, these
attributes should be defined as subtypes of each other or as subtypes of a common attribute supertype to express the semantic relation between them. This allows clients to
detect semantically compatible attributes in compatible object classes.
1.24.6 Security services
The OMP must allow operators to enforce access control policies on the OMP support
services. Access must be limitable to selected users, which may optionally be forced to
authenticate themselves.
 The OMP security services should be realised based on the LDAP authentication and
access control mechanisms proposed for standardisation [ Stokes00]. To use symmetric
authentication mechanisms, an OMPUser entry must be held by an OMP server for
Page 125
each OMP user to store the user's credentials as introduced in section 1.17. For asymmetric authentication mechanisms, these entries are not required. Access control on
support services is realised by limiting access to OMP entries, using access control lists
that grant permissions on attribute and entries. The new Dynamic Directory event handling features should be compatible with the proposed access control mechanisms, i.e.
it should be possible to formulate permissions on event definitions using the proposed
standard access control mechanisms.
User subscriptions shall have MMD Federation-wide coverage, since a user must be able
to use services from potentially all MMDs.
 User subscriptions that shall have MMD Federation-wide coverage may be realised with
LDAP asymmetric public key authentication mechanisms or with OMPUser entries that
are replicated between all OMP servers participating in an MMD Federation.
Management of user subscriptions must be possible for OMP operators using LDAP services.
 Management of user subscriptions is trivially supported since OMPUser entries are
normal LDAP entries. Management of access control lists will be supported by the relevant LDAP extensions being defined currently.
1.24.7 Discovery services
OMP clients must be able to discover an OMP server at every MMD in an MMD Federation.
 This is the generic problem of discovering LDAP directory services at an unfamiliar
network site. Generic solutions to this problem already exist based for example on the
Service Location Protocol [Guttman98] or Dynamic Host Configuration Protocol [RFC2131],
see also 1.11.1.3. Which method should be used depends on the requirements of the
OMP operator and on the configuration and discovery services supported in the network infrastructure for which the OMP shall be installed.
OMP clients must be able to discover which MMDs are managed by the OMP server they
discovered.
 MMDs are root entries of naming contexts held by the OMP server. This information
can be found in the LDAP root DSE entry in the namingContexts attribute. The root
DSE can be retrieved by clients with a base object search of the root with filter ("objectclass=*") as defined in [RFC2251].
OMP clients must be able to explore the OMP schema of an MMD.
 Information about the schema enforced by an LDAP server can be found in the LDAP
root DSE entry and the server's subschema subentries.
OMP clients must be able to explore the functional capabilities of OMP servers.
 Information about LDAP service controls and extended operations supported by an
LDAP server is maintained in the root DSE and may be retrieved by OMP clients as described before.
Page 126
1.24.8 Impact of entry placement on Open Mobility Platform functionality
The following entry placement rules specified in section 1.22.7 are mandatory for the
Open Mobility Platform functionality presented before, whilst all others have no influence
and may be changed by OMP operators:
An MMDFederation entry must be the root of the OMP information tree if multiple MMDs
shall be federated.
An MMD entry serves as base object in directory search operations covering a single Mobility Management Domain and must therefore be the root of all entries in an MMD. It may
be the root of the OMP information tree, if only a single MMD is managed by the OMP.
All MMD entries must be placed below the root MMDFederation entry to allow OMP servers to generate continuation references to other MMDs.
To allow searching below MMDFederation entries not being the root of the DIT, additional alias entries must be placed below those MMDFederation entries to refer to the
logically included MMDFederation or MMD entries.
OMPUser entries must be placed in a subtree below MMDFederation to allow shadowing
of the entries at multiple OMP servers optionally. If user entries are only needed inside
a single MMD, they may be placed below MMD entries.
If shadowing of MMDPointer entries shall be used, the entries must be placed in a subtree below the MMDFederation root entry. Without replication, the subtree may also
be placed below MMD entries.
The hierarchical placement of SpatialArea entries must reflect their real-world containment since CompositeArea entries derive their presentHookedObjects attribute
from the areas being placed below.
Map entries should be placed below the hierarchically highest area that they cover to allow
browsing by OMP clients.
1.25 Summary
The achievements reached in this chapter are briefly summarised in the following. First,
we have defined the Open Mobility Platform functional model. It identifies the OMP functional entities and specifies how the coverage area of a multi-site campus-area environment is represented. Thereafter, we have identified the set of support services that shall
be included in the functionality of the Open Mobility Platform.
As main achievement, we have specified an OMP information model that enables the realisation of all identified support services with a homogeneous object class model. The
core of the information model is the OMP Framework, being structured into three packages: The Subscription Framework, the Positioning Framework, and the Addressing
Framework. A distinguishing feature of the Open Mobility Platform model is its integrated
support for applications requiring addressing and positioning location information. All OMP
applications will make use of the Subscription Framework object classes, defining the
Page 127
overall structure of MMD Federations and Mobility Management Domains, including subscriptions of LocatableObject entities and OMP users. The Positioning Framework
supports location-aware applications and mobility management services that make use of
absolute or relative positioning information. The Addressing Framework will be used by
applications and mobility management services interested in communication addresses of
users and terminals.
One of the major aims of our work is to enable a high degree of customisation of the Open
Mobility Platform information model. This was achieved by defining frameworks of structural and abstract object classes that may be used by others to derive subclasses to
model for example technology-specific aspects of network and positioning infrastructures.
Additionally, users of the Open Mobility Platform may add application-specific information
by aggregating their own auxiliary classes with the structural classes provided by the platform. These additional object classes have been structured into three Customisation
Packages that may be extended by the future users of the Open Mobility Platform. We already defined customisation object classes for the most popular positioning technologies
and user mobility features. Following these examples, it should be straightforward for
OMP operators to define, if required, additional customisation packages in the future.
After the OMP information model was defined, we mapped its elements on the information
model elements supported by the existing X.500 information model that is employed by
LDAP directory services. Additionally, for each mobility support service we confirmed that
the required functionality can be realised with LDAP access services operating on the proposed information model. The result of that discussion was the finding that it is principally
possible to realise the OMP functionality based on X.500/LDAP models, but that a number
of important features are not supported in the current directory models.
These are the functional gaps we identified that form the requirements for the development of the Dynamic Directory Services:
Internally derived attributes
Dynamic Directory Services must support deriving attribute values from attribute values
held in other entries inside the same directory server. If the entry from which attributes
shall be derived is not held in a naming context of the local server, a continuation reference should optionally be returned to the client. The attribute derivation rules must at
least support all entry and attribute selection mechanisms required by the OMP model.
Externally derived attributes
Dynamic Directory Services must support deriving attribute values from external infrastructures to represent frequently-changing data in the Directory Information Tree.
Caching of external data must be supported to reduce request processing effort and delay; the client must be able to control whether cached data is used to answer a request.
Event handling functionality
Dynamic Directory Services must support monitoring of event conditions with notifications being sent to its clients when conditions are met. The event monitoring functions
must be more powerful than the proposed LDAP persistent search: Event monitoring
must consider changes caused by modification requests as well as changes in externally derived attribute values. The event conditions must be expressive enough to for-
Page 128
mulate conditions representing real-world positioning and addressing events, such as
"leaves an area" or "registers on a phone". Furthermore, Dynamic Directory event handling must be aware of internally derived attributes since changes to an entry may
cause events to fire on other entries that derive attribute values from the changed entry.
Besides these mandatory requirements, a number of useful capabilities should optionally be supported. Notifications should be buffered by Dynamic Directory servers, allowing clients on mobile terminals being temporarily unavailable to obtain notifications later,
when they become available again. It should optionally be possible to define LDAP operations to be performed by the server when event conditions are met. Additionally, it
should be possible to share event conditions of general interest between multiple directory clients.
Exported attributes
Dynamic Directory Services must support to synchronise selected attributes of their entries with external infrastructures. A tightly coupled master/slave mechanism should be
offered that keeps both master and slave strictly consistent.
Spatial matching
Dynamic Directory Services must support new attribute syntaxes representing threedimensional points and rectangular solids. They must offer new containment matching rules to evaluate whether a point is contained within a rectangular solid and vice
versa.
Nearest matching
Dynamic Directory Services must support new nearestMatch matching rules to
evaluate which spatial position is nearest to a given position. The matching rule shall
also be applicable to generic attribute types, such as numeric attributes, to support
searching for entries having optimal attribute values for trading services.
Enhanced directory information model
Dynamic Directory Services must implement an enhanced information model - i.e. additional operational attributes and object classes - to realise the aforementioned functional directory extensions.
The next chapter will present the solutions to these requirements provided by the Dynamic
Directory Services we developed as part of this thesis.
Page 129
Dynamic Directory Services
In this chapter, we present the extensions to X.500 and LDAP we developed based on the
requirements discussed in the previous chapter. We call the resulting enhanced directory
services Dynamic Directory Services (DDS)7. The extensions developed by us cover all of
the identified requirements, so that a Dynamic Directory will be able to realise the Open
Mobility Platform specification. Although the requirements on the Dynamic Directory Services were identified from mobile applications, the new directory features are not limited to
support mobility. This was achieved by designing the new directory features as generic extensions being completely OMP-independent. Consequently, a Dynamic Directory will be
useful for several other applications; some of them will be briefly introduced in chapter 0.
This chapter introduces several extensions to conventional directory services. For each of
the new features, we specify an extended X.500 and LDAP directory information model
that defines new operational attributes to manage the operational information associated
with the new functionality. We also define operational models that specify how the Dynamic Directory interacts with its clients using LDAP to perform the new functions. For
some features, new LDAP controls and error codes are defined. At the end of each feature description we present an example that illustrates how the new feature may be applied in the Open Mobility Platform context. A summary of all new operational attributes,
object classes, LDAP controls and error messages is given in Appendix D.
Notation used in this chapter
Before we specify the new Dynamic Directory features, we extend the notation used in the
LDAP standards to specify object classes and attribute types. In the X.500 and LDAP
standards, user schema and system schema are separated from each other (cf. section
1.16). Directory clients may only add user attributes that have no operational significance
for the directory server. For the Dynamic Directory Services, we relax this separation by:
Specifying in an LDAP object class definition all attributes - user attributes and operational
attributes - that must or may be added to an entry or subentry from directory users. This
allows or forces users to add certain operational attributes to directory entries.
Allowing an attribute to have multiple "USAGE" clauses present in its definition (cf. page
64). This is necessary because some of the new attributes we defined for the Dynamic
Directory Services are used by the server to perform its operation but are added by the
user and should therefore always be returned in directory operations. These attributes
7
We use the term Dynamic Directory Services (DDS) as a name for the service specifications including information model and operational model developed in our work. The term Dynamic Directory server represents a process that implements the DDS specification and offers the extended LDAP-based services to its clients at a particular service access point. The term Dynamic
Directory represents an abstract directory information repository compliant with the DDS specifications and consisting of one or more Dynamic Directory servers.
Page 131
have to be classified with both usage types, userApplications and directoryOperation.
A second extension affects the notation for specifying object classes. An attribute may be
present in an entry due to these reasons: It may be added by the client, it may be automatically added by the server, or it may be added from a collective attribute subentry. To
reflect the source of an attribute, we defined additional clauses for the object class notation (cf. page 65):
The attributes that are automatically added by the directory server are currently not specified in the object class description. Since we defined a number of new operational attributes that are added to specific object classes by the server, we extended the object
class description format with a new clause "FROM SERVER". This clause is only informational for the reader of this document and lists the attribute types of all attributes
added by the server. It is not part of a real directory schema definition.
Attributes added from collective attribute subentries to object classes are currently not
specified in the entry's object class description. They must be specified in the object
class description of the subentry and must not be excluded by DIT content rules governing the entry. If one or more collective attributes must be obtained from a subentry to
allow the entry itself to be added to the DIT, these mandatory attribute types should be
listed in a new clause "FROM SUBENTRY". This clause is not intended for the directory
user, its purpose is to remind the directory administrator of creating an associated subentry.
We defined further notational extensions that will be introduced in the following sections.
1.26 Internally derived attributes
Internally derived attributes are a new feature that must be supported by the Dynamic Directory Services. Internally derived attributes have no static value stored in a database.
Instead, their value is dynamically obtained on demand when it is needed to fulfil a client
request. The value is derived from the value of another attribute defined in the same or in
another entry held in the same server. Conventional attributes that are held in a database
are called static attributes in the following to distinguish them from internally derived attributes.
1.26.1 Information model
The same attribute type shall be classifiable in some object classes as internally derived
attribute and in other object classes as static attribute. For this reason, an object class
definition is the appropriate place to define an attribute as internally derived attribute. An
object class must define an attribute as being either static or derived.
The following BNF extends object class definitions for classifying attributes as internally
derived. For this it adds "MUST DERIVED" and "MAY DERIVED" clauses.
Page 132
ObjectClassDescription = "(" whsp
numericoid whsp
; identifier of object class
[ "NAME" qdescrs ]
; names of object class
[ "DESC" qdstring ]
; description
[ "OBSOLETE" whsp ]
[ "SUP" oids ]
; superior object classes
[ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ] ; def. struct.
[ "MUST" oids ]
; mandatory static attribute types
[ "MAY" oids ]
; optional static attribute types
[ "MUST DERIVED" oids ]
; mandatory derived attribute types
[ "MAY DERIVED" oids ]
; optional derived attribute types
[ "FROM SERVER" oids ]
; attributes added by Dyn. Dir. server
[ "FROM SUBENTRY" oids ] ; mandat. collective attr. from subentry
whsp ")"
An attribute type may only be declared as either static or derived, not both. The interpretation of the MUST and MAY keywords in the object class definition is a different one for internally derived attributes and for static attributes. Whereas for static attributes the presence of attribute values is specified, for internally derived attributes only the presence of
derivation rules is specified. The reason: It is impossible to mandate that an internally derived attribute must have an attribute value since the existence of values is determined
only when the value is derived. If the derivation rule does not lead to an attribute value, the
internally derived attribute has no value either. Therefore, a schema check on the object
class performed when the entry is created or modified cannot mandate the presence of internally derived attribute values.
1.26.1.1 Derivation rule placement
In the OMP specification, each internally derived attribute needs a derivation rule that defines how its value is to be derived. The derivation rule is part of the OMP object class
definition of the entry that defines the attribute as internally derived. Derivation rules may
be inherited from superclasses and aggregated from auxiliary object classes. If an entry
belongs to multiple object classes - e.g. due to subclassing and aggregations with auxiliary
object classes - and the same attribute type is classified in more than one class as being
internally derived, all derivation rules for that attribute type must be evaluated by the Dynamic Directory. The internally derived attribute will possess all values resulting from all
derivation rules, if its attribute type allows multiple attribute values. If the derived attribute
is single-valued, at most one of the internally derived values will actually be present in the
attribute.
The Dynamic Directory Services slightly deviate from the OMP model. The DDS derivation
rules for internally derived attributes are modelled as operational attributes being part of
the entry itself, not as part of the object class. This has the advantage that derivation rules
may be stored and handled by the Dynamic Directory in the same way as other attributes.
Furthermore, Dynamic Directory clients may make use of LDAP services to access and
modify the derivation rules, if this is allowed by access control rules being enforced. The
new operational attribute was named reference, it employs the DirectoryString
syntax, and it is defined as follows:
( dds.1.1 NAME 'reference' EQUALITY caseIgnoreMatch
SYNTAX DirectoryString COLLECTIVE USAGE directoryOperation )
Page 133
The reference operational attribute may be contained in the entry itself, or it may be a
collective attribute that the entry receives from a collective attribute subentry [ X.501]. In any
of these cases, the internally derived attributes must be allowed in the entry's object class.
In the first case, the reference operational attribute must be additionally admitted by the
object class or DIT content rule governing the entry. The directory client may add, modify,
or delete the operational attribute, provided it has sufficient access rights to do so. This
approach is not used by the OMP model, but it may be useful for other Dynamic Directory
applications. In the second case, the operational attribute is part of a collective attribute
subentry that applies to all entries belonging to a particular object class. In this way, all entries of that object class obtain a value of the operational attribute, realising the required
aggregation and inheritance of derivation rules from all object classes used in the OMP
model. The reference operational attribute must be admitted in the subentry's object
class. It does not have to be admitted explicitly in the entry's object class but must also not
be excluded from it by its content rule. Management of the derivation rule is done by modifying the subentry - if allowed. The second approach has the strategic advantage that a
derivation rule applies to all instances of an object class in the same way, while the first
approach allows tailoring derivation rules for individual entries. A comparison of these two
alternatives is depicted in Table 3.
Reference attribute placed in
entry
Reference attribute placed in
collective attribute subentry
Derivation rule applies to
single entry
all entries of the object class on
which the subentry is applied
attribute must be allowed
in entry object class
in subentry object class
attribute may be excluded
by DIT content rule for entry
by DIT content rule for entry
derivation rule may be modified by client
yes, if access rights suffice
unlikely, since subentries usually
grant access only for administrators
attribute is inherited from superclasses of entry
no, not defined by object class
yes, from all superclasses for
which subentries with derivation
rules are defined
attribute is aggregated from
structural and auxiliary entries
yes
yes
for caching, cachetime attribute must be allowed
in entry object class
in subentry object class
Table 3: Comparison of allowed reference attribute placements
The object class of the collective attribute subentry used in the Dynamic Directory is defined in 1.31 since it is used for several new directory service features.
1.26.1.2 Caching
The Dynamic Directory may make use of cached data for internally derived attributes.
Whether caching of derived attributes is performed for a particular entry is controlled with
the new cachetime operational attribute taking positive numeric values. If the attribute is
Page 134
absent, it is up to the Dynamic Directory to decide whether caching is performed or not. If
the attribute specifies a value of zero, no caching is performed on this entry. If it specifies
a value larger than zero, the value may be cached only for the specified number of seconds, thereafter it may not be used. The cachetime attribute may be specified in the entry itself or in one of its collective attribute subentries. If multiple values for cachetime are
specified, the smallest cachetime value is used for all derived attributes.
The cachetime attribute employs the NumericString syntax, and its attribute type is
defined as follows:
( dds.1.2 NAME 'cachetime' EQUALITY numericStringMatch
SYNTAX NumericString COLLECTIVE USAGE directoryOperation )
1.26.1.3 Derivation rule model and syntax
The internally derived attributes employ an underlying derivation rule model that assigns
two different roles for entries during derivation rule processing: Target entry and source
entry. The entry for which internally derived attributes are defined plays the role of the target entry. The derived attribute is called target attribute. The values of the target attribute
are derived on-demand from the values of another attribute - the so-called source attribute
- in the same or another entry, playing the source entry role as depicted in Figure 43.
Derivation rules may be cascaded, allowing a source attribute in a source entry being itself
an internally derived attribute. Furthermore, source and target entry role may be played by
the same entry, if attributes are derived from attributes of the same entry.
<<targetEntry>>
:Class1
/attr1 : targetAttribute
derives-from
<<sourceEntry>>
:Class2
attr2 : sourceAttribute
Figure 43: Entry and attribute roles for internally derived attributes
The value of a reference operational attribute (i.e. a derivation rule) is comprised of the
following components:
Target attribute name: Specifies the type of the internally derived attribute.
Source entry selection rule: Specifies a rule that is evaluated by the server to select
source entries.
Source attribute name: Specifies the type of the source attribute in the source entry whose
values shall be used to derive the target attribute values.
Parameter list (optional): Specifies one or more attribute types of the target entry whose
values are used by the Dynamic Directory for deriving attributes in the source entry.
The use of this component is intended for externally derived attributes in the source entry, see section 1.27.
The target entry selection rule supports multiple selection mechanisms. Some mechanisms allow parameterising the source entry selection rule with attribute values of the tar-
Page 135
get entry. This allows to make the source entry selection dependent on the target entry's
current values, a feature that is of major importance for the usefulness of internally derived
attributes for the OMP but also for many other applications.
The following source entry selection mechanisms are supported:
Selection by search filter: The rule specifies a subset of the LDAP search parameters including an LDAP search filter. At least one equality AVA on the source entry's object
class must be specified. All entries matching the filter are used as source entries. The
following elements of LDAP search parameters may be used to specify the source entries:
- Base object (optional): The DN of the base object. One or more RDN components of
the DN may be parameterised using attribute values of the target entry. If base object is omitted, the root entry of the target entry's naming context is used as base object. The reserved value "SELF" may be specified to use the target entry itself as
base object for the search. If base object is specified and identifies an entry held in
another naming context than the context holding the target entry, a continuation reference is optionally sent back to the directory client with the search response.
- Scope (optional): May be declared as baseObject, singleLevel or subtree, default is subtree.
- Filter: The filter may use all existing and additionally defined (see 1.29) LDAP search
filters and logical operators. The attribute value propositions may be parameterised
with attribute values of the target entry.
- Maxentries (optional): Specifies the number of entries that shall be returned by the
search operation. If omitted, all matching entries are used as source entries. If present, the specified number of entries is randomly chosen from all entries matching
the filter.
Selection by DN: The rule specifies the Distinguished Name of the source entry. If the entry is located outside the target entry's naming context, a continuation reference is optionally sent back to the directory client. One or more RDN components of the DN
specification may be parameterised using attribute values of the target entry. The reserved value "SELF" may be specified to select the target entry itself as source entry.
The following syntax has been defined for the new reference operational attribute:
InternalAttributeDerivationRule =
targetAttribute "=" selectionRule ":" sourceAttribute "(" parameterList ")"
targetAttribute
sourceAttribute
parameterList
selectionrule
dNRule
filterRule
base
scopes
nentries
attrList
Page 136
=
=
=
=
=
=
=
=
=
=
attr
attr
[attrList]
dNRule / filterRule
"DN=" ( pDN / "SELF" )
["BASE=" base] [":SCOPE=" scopes] [":MAX=" nentries] filter
pDN / "SELF"
"BASE" / "SUBTREE" / "SINGLELEVEL"
numericstring
attr *( "," attr )
The definition of pDN is a subset of the DN string representation defined in [ RFC2253] with
the addition of a parameterised relative distinguished name pRDN:
pDN
= [name]
; empty name is root of DIT
name
= name-component *(";" name-component)
name-component
= attributeTypeAndValue *("+" attributeTypeAndValue)
attributeTypeAndValue = attr "=" pvalue
pvalue
= value / "$" attr
; attr is attr. type from target entry
This allows the DN to be parameterised by specifying an attribute type (preceded by a '$'
character) of the target entry in the value part of an RDN. During rule evaluation, the term
is replaced with the attribute's current value and the DN is constructed and used to select
the source entry. If the specified attribute type is not present in the entry, the derivation
rule is ignored. If the attribute type has more than one value, for each value the DN is
constructed and the derivation rule evaluated.
The definition of filter is derived from the string representation of LDAP search filters
defined in [RFC2254] with the only change of introducing the term pvalue for parameterised values. The values must be replaced during derivation rule evaluation in the same
way as described for parameterised DNs.
filter
=
filtercomp
=
and
=
or
=
not
=
filterlist
=
item
=
simple
=
filtertype
=
equal
=
approx
=
greater = ">="
less
=
extensible
=
"(" filtercomp ")"
and / or / not / item
"&" filterlist
"|" filterlist
"!" filter
1*filter
simple / present / substring / extensible
attr filtertype pvalue
equal / approx / greater / less
"="
"~="
"<="
attr [":dn"] [":" matchingrule] ":=" pvalue
/ [":dn"] ":" matchingrule ":=" pvalue
present = attr "=*"
substring
= attr "=" [initial] any [final]
initial = pvalue
any
= "*" *(value "*")
final
= pvalue
attr
= AttributeDescription
matchingrule = MatchingRuleId
value
= AttributeValue
; from RFC2251; name of attribute type
; from RFC2251; oid of matchingrule
; from RFC2251, OCTET STRING
1.26.2 Directory data consistency
The new internally derived attributes functionality introduces a potential data consistency
problem that must be addressed by the operational model of the Dynamic Directory. The
consistency problem stems from a major difference between conventional directories and
Dynamic Directories concerning the way in which an entry's attributes are obtained. Conventional directories obtain all attributes in a single-step atomic operation that derives all
attributes from a persistent database. In such a system, consistency of attributes is easy
Page 137
to guarantee by locking an entry during database updates, so that only consistent versions
of an entry are returned to clients.
In Dynamic Directories, obtaining the attributes of an entry is a multi-step operation in
which several other (source-) entries may be involved. Multiple scenarios might lead to inconsistencies in derived attributes. These are typical examples:
A source entry is accessed multiple times during derivation rule processing of a single entry. The source entry's attributes change in between due to modifications or changes in
externally derived attributes, so that the derived attributes in the target entry are inconsistent with one another. This is illustrated in Figure 44. In the picture, the time lines inside the Dynamic Directory server illustrate the interworking between source and target
entries during evaluation of derivation rules.
A target entry and a source entry are both returned to a client. After the target entry has
been sent - including attributes derived from the source entry - the source entry
changes and is then sent to the client, too (or vice versa).
<<targetEntry>>
:Class3
/attr1 : targetAttribute
/attr2 : targetAttribute
DDS server
derives-from
<<sourceEntry>>
:Class4
attr3 : sourceAttribute
attr4 : sourceAttribute
Client
Search
GetValue(attr3)
Value(attr3)
add attr1(attr3)
attr3 and attr4
change
GetValue(attr4)
Value(attr4)
Value(attr4)
add attr2(attr4)
SearchResponse
inconsistent entry returned!!!
has old attr3 and new attr4 value
Figure 44: Potential entry consistency problem with internally derived attributes
The first scenario type leads to an inconsistency between attributes of the same entry.
This situation is unacceptable for any application since the returned attributes do not contain meaningful values. This type of inconsistency must be avoided with appropriate
mechanisms to be developed for the Dynamic Directory. The second scenario type leads
to inconsistencies between two or more entries returned to a client. Depending on the expectations of the client on the atomicity of directory operations this might be tolerable or
not. If the client wishes to obtain a consistent view on multiple entries and their relative
contents in relation to each other, attributes in different entries should be consistent with
Page 138
one another. If the client wishes to retrieve the most actual contents in every entry, it
would be better to always include the latest changes in every entry returned to the client
and only guarantee that attributes inside the same entry are consistent with one another.
To provide a generic solution to different client expectations concerning consistency of
data, the Dynamic Directory Services provide two different levels of data consistency that
may be specified by the client in a search request.
Entry-consistent
The attributes contained in an entry are consistent with one another. Modifications performed on the directory database and changes in externally derived attributes during
the search may affect only attributes in different entries returned to the client, not attributes inside the same entry. For entry-consistent operations, the server may make use
of cached data to process the request if allowed by the client. This consistency level
avoids the first inconsistency example described above.
Operation-consistent
All entries returned to the user are consistent with one another. Modifications performed
on the directory database and changes in externally derived attributes during the search
are not reflected in the result. For operation-consistent operations the server must not
make use of cached data, since it may not be consistent with the actual directory database status. This consistency level avoids the second inconsistency example described
above.
With the conventional approach employed in directory servers - locking an entry during
modifications - the consistency problems described above may not be solved. Instead, alternative solutions have to be developed for Dynamic Directories. We developed a solution to this problem that restricts how often the values of derived attributes are evaluated
during an operation. For entry-consistent operations, the internally derived attributes of an
entry are evaluated only once per entry being returned to a client. If an entry is accessed
multiple times as source entry, the derived attribute values evaluated before are re-used.
For operation-consistent operations, the internally derived attribute values are evaluated
only once for the whole directory operation and are re-used in subsequent accesses to an
entry. In chapter 1.34, we present how this approach may be implemented.
1.26.3 Operational model
1.26.3.1 Dependency resolution
A Dynamic Directory implementation must address the issue of detecting and resolving
dependencies between derivation rules of the same entry. If an entry contains more than
one derivation rule, the order in which the rules are evaluated may be of significance for
the operation result. This will be the case if an internally derived attribute value is used as
parameterisation of another derivation rule. The latter rule is dependent on the first one
and must therefore be executed after the first one. The dependency problem may not be
solved by manually ordering the rules in the entry by the directory users during creation of
the entry, because additional rules may be added by the directory server from collective
Page 139
attribute subentries. The rules may therefore be sorted only after the collective attributes
are added to an entry.
Therefore, before any derivation rule of an entry is evaluated, all derivation rules must be
analysed concerning dependencies between rules. The rules must then be sorted into a
sequence that resolves all dependencies. There may be situations where derivation rules
define dependencies that lead to conflicts not solvable by re-ordering the rules. These
conflicts must be detected by a Dynamic Directory server, and an error must be returned
to the client trying to retrieve that entry. An entry must be rejected by the Dynamic Directory server at entry creation or modification time, if it causes a derivation rule conflict internally or in conjunction with its subentries. Example algorithms that detect loops and sort
derivation rules into an executable sequence are discussed in Appendix E.
1.26.3.2 Derivation rule processing
The values of an internally derived attribute are evaluated by the Dynamic Directory if:
Its values are needed for evaluation of search filters
Its values are requested by clients to be returned as part of search response messages
Its values are required as parameters for other attribute derivation rules
Its values are required as source attributes for another internally derived attribute
Its values are required for checking event conditions, see also section 1.28.
The Dynamic Directory server may avoid the repeated evaluation of derivation rules by
making use of cached values obtained during previous requests. However, the client may
demand that no cached values be used to answer a particular request.
The following tasks must be performed by the Dynamic Directory server when internally
derived attributes must be evaluated:
Check whether internally derived attributes are needed for completing the request. If not,
return the entry, if yes, continue.
Check whether cached data can be used for internally derived attributes. This is possible if
cached data exists and is not too old and the client has not excluded the use of cached
data. If possible, return entry with cached data, if not, continue.
Check dependencies between derivation rules and determine which rules must actually be
evaluated (depending on required attributes and dependencies between rules). Determine a conflict-free evaluation sequence by sorting the required evaluation rules. If a
conflict between the rules cannot be resolved, return an error; otherwise continue with
the following steps for each derivation rule that must be evaluated:
- Replace parameterised elements in derivation rule with actual values from target entry attributes. If one or more values are missing, ignore derivation rule and continue
with next rule. If one or more values exist, evaluate source entry selection rule for all
possible combinations of parameterised elements.
- For each source entry selection rule, check whether a source entry exists that fulfils
the selection rule. If not, ignore selection rule and continue with next rule. If yes, continue with next step.
Page 140
- For each found source entry, check if source entry is different from target entry. If
yes, retrieve source entry from Dynamic Directory internal database; otherwise use
target entry as source entry. If source entry has internally derived attributes, the requested internally derived attributes must be evaluated. Before this, the Dynamic Directory must check whether the requested derived attributes of the source entry were
already derived during this directory operation. If the earlier derivation has not been
completed yet, a loop between derivation rules of different entries has been detected. In this case, the Dynamic Directory returns an error. If not, the procedure continues.
- For each source attribute specified in the derivation rule, obtain its values from the
source entry and add them to the specified target attribute in the target entry. Duplicate values for target attributes are to be removed.
When all derivation rules have been processed, return entry to client or directory operation
requesting the entry. If allowed by cachetime attribute, store entry with derived attribute values in an internal cache for future requests.
The following error situations may occur during processing of internally derived attributes:
If an entry is added in which an attribute is defined as static and as internally derived in
the same entry - including the attributes that may be obtained from collective attribute
subentries - the Dynamic Directory returns a derivationRuleConflict error to the
client.
If a client attempts to add, modify, or delete internally derived attributes, the Dynamic Directory sends an error message containing an insufficientAccessRights error
code.
If the source entry is not held in the target entry's naming context, the entry's static attributes and a continuation reference are returned to the client indicating which server
could hold a more complete instance (i.e. including all derived attributes) of the requested entry. It is a configuration option of a Dynamic Directory server to allow resolving continuation references to contexts held inside the same server automatically.
If the source entry is held in the target entry's naming context but the determination of its
values raises a continuation reference, the entry's static attributes and the reference are
returned to the client.
If a conflict between derivation rules of the same entry cannot be solved, the Dynamic Directory returns the entry's static attributes and a derivationRuleConflict error to
the client.
If a loop between derivation rules of different entries has been detected, the Dynamic Directory returns only the static attributes and a derivationRuleLoop error to the client.
If a derivation rule cannot be evaluated due to syntactical errors, the Dynamic Directory returns only the static attributes of the entry and a derivationRuleError error to the
client.
If the server cannot guarantee the consistency of all entries during an operation-consistent
search, the Dynamic Directory cancels the operation after sending the last consistent
entry and sends a consistencyError indication to the client.
Page 141
1.26.3.3 LDAP controls
The following new service controls have been defined for the Dynamic Directory to allow
clients to control the handling of internally derived attributes:
excludeDerivedAttributes - true or false; default false. Requests the server to
use only static attributes for evaluating search filters, and for inclusion in search responses.
noAttributeCaching - true or false; default false. Requests the server not to use
cached attributes for evaluating internal attribute derivation rules. In combination with
operation-consistent operations, this service control is irrelevant since the server does
not cache anyway.
consistencyLevel - entry, or operation; default entry. Requests the server to apply the specified consistency level to the directory operation.
With the extensions described in this section, a Dynamic Directory server may return a
continuation reference caused by a source entry during a search operation. We defined a
new search operation control that is interpreted by LDAP Application Programming Interfaces that controls whether a continuation reference is automatically followed by the LDAP
API or not. The decision whether to follow it or not depends on the fact whether all attribute types listed in the search request were received by at least one entry returned in the
search response. If so, and the control skipReferenceIfComplete is set to true, the
reference is not followed by the API; in all other cases a reference is automatically followed by the API - if following references is enabled. With this control, an application may
demand that an LDAP API automatically follows continuation references until all requested
attributes are found in any server.
1.26.3.4 Access control
Access control policies on entries with internally derived attributes must not only govern
the (target) entry itself but also the source entries from which attributes are obtained. We
use in this section the LDAP access control proposal described in section 1.18 to define
which permissions must be set on the involved entries to evaluate internally derived attributes.
For the target entry, the normal access control permissions must be set to allow the entry
to be found and returned to a directory user. For an entry to be discovered in the DIT, the
user must have browse permission on that entry. For an attribute to be found by a search
filter, the user must have search permission on the attribute; and for an attribute to be returned to the user, he or she must have read permission on it.
To allow internally derived attribute values from a source entry to be returned to a user,
the user must have search and read permission on the source attribute. The user does
not have to have browse permission on the source entry since it is not perceived by the
user. This allows to hide the existence of entries to directory users while still being able to
derive attributes from such entries. The use of this capability is further discussed in section 1.27.4.
Page 142
1.26.4 OMP example
To illustrate the definition and usage of internally derived attributes, the derivation rules for
the Active Badge positioning example from section 1.22.4.1 are presented below in the
Dynamic Directory syntax. The example shows the static and operational attributes of an
entry of class HookedObject. The entries are specified as LDAP attribute/value pairs.
In the example, the entry HookedObject has three internally derived attributes that are
derived from the source entry ABSTag. The source entry is selected with a filter selection
rule, consisting of an equality filter on (objectclass=ABSTag) and another equality filter
on (objectId=$attachedTag). The second filter is parameterised with the target entry's
attribute attachedTag, so that the source entry is selected based on attachedTag's
current value. In this example, the entry of class ABSTag having an attribute "objectId=2" is selected from the local naming context as source entry. Three internally derived
attributes are obtained from it and added to the target entry. The derived attributes may be
cached for 10 seconds to be re-used for subsequent LDAP operations.
objectClass = HookedObject
objectClass = HookedPosition
objectClass = Person
objectId = 533
// RDN
homeMMd = ac
attachedTag = 2
cachetime = 10
// allows 10 seconds caching of intern. derived attributes
reference =
managingMMD=(&(objectclass=ABSTag)(objectId=$attachedTag)):managingMMD()
reference =
position=(&(objectclass=ABSTag)(objectId=$attachedTag)):position()
reference =
lastLocating=(&(objectclass=ABSTag)(objectId=$attachedTag)):lastLocating()
objectClass = ABSTag
objectId = 2
// RDN
roamingArea = ABS0 // roamingArea identifies ABS infrastr. serving the tag
position = g116
// should be internally derived, simplified here
currentABSSensor = 17
// should be externally derived, simplified here
managingMMD = ac
homeMMD = ac
lastLocating = 2000-03-06 09:45:12 // should be externally derived
1.27 Externally derived attributes
A new functionality to be supported by Dynamic Directory Services is the support of externally derived attributes. This kind of attribute has no static value stored in the Dynamic Directory database. Instead, its value is dynamically obtained from servers being external to
the Dynamic Directory when it is needed to fulfil a client request.
An important design issue with externally derived attributes is to decide which access protocols to external servers should be supported by the Dynamic Directory server. One approach would be to support a variety of different services and protocols (e.g. CORBA,
RMI, DCOM, SNMP, etc.), but this would make the Dynamic Directory server implementaPage 143
tion very complex. Still, this would not allow connecting to all potentially required infrastructure types. Furthermore, as the external access protocols evolve over time, the Dynamic Directory server implementation would have to follow each technological evolution
path. The other approach is to choose a single or a few simple protocols that are widely
supported and may optionally be converted by external proxy servers into the access protocols of the infrastructure used in a particular environment. The advantage of the second
approach is that it simplifies the server implementation; its disadvantage is that a protocol
conversion will impose performance degradation. Furthermore, data loss and inconsistency must be avoided by the protocol translator. We chose the second approach for the
Dynamic Directory development to keep its initial implementation complexity manageable.
However, the information and operational model were designed comprehensive enough to
support additional protocols to be built into Dynamic Directory servers, if required in the future.
In our approach, the external server contains a number of data items called external objects. Each external object has a number of properties, which each may have one or more
values. The properties represent the external data that shall be retrieved by the Dynamic
Directory and converted into directory attributes. Each property is mapped on an attribute
with all of its values. If the external server contains more than one external object, each
object must possess at least one property that may be used as identifier to select the object that shall be retrieved from the external server.
The general interaction model between Dynamic Directory servers and external servers is
a client/server relationship, as depicted in Figure 45, wherein the Dynamic Directory plays
the client role. The Dynamic Directory sends a retrieval request to the external server
when externally derived attributes must be obtained, for example during a search operation. The retrieval request contains an identifier that selects the external object to be retrieved from the external server. The server returns the requested object in a response
message that contains all properties of the external object that are converted into LDAP
attribute values by the Dynamic Directory. The external server may also return an error
message, which causes an LDAP error message to be sent to the directory client. Our
model assumes that for each retrieval request usually only a single external object is returned. If multiple objects are returned, all their properties are assigned to externally derived attribute values of one directory entry.
While the general interaction pattern is independent from the protocol used to communicate with the external server, the format of the request and response messages is protocol-dependant. Therefore, different Dynamic Directory operational attributes must be defined for different access protocols.
Page 144
Client
DDS server
External server
Search
RetrievalRequest(object identifier)
RetrievalResponse(object properties)
create externally
derived attributes
SearchResponse
Figure 45: Interaction between Dynamic Directory and external servers
Externally derived attributes specified for an entry must be accompanied with operational
information defining from which server and with which access protocol the attribute values
shall be obtained. If an entry requires externally derived attributes from more than one
server, it would be difficult to allocate all the required operational information in a single
entry since the operational attributes for the different sources must be distinguishable.
Furthermore, if multiple entries specify externally derived attributes, the operational information becomes redundant in multiple entries.
Therefore, we decided to further extend the approach taken in the OMP model and defined a dedicated object class ImportAdapter that contains all operational attributes required to communicate with an external server. Externally derived attributes must be defined for an ImportAdapter entry. Other entries requiring externally derived attributes
must make use of the internal attribute derivation feature discussed in the previous section
to obtain externally derived attributes from ImportAdapter entries, as illustrated in Figure 46. This approach has the additional advantage that externally derived attributes may
be shared between multiple entries by means of caching data inside the ImportAdapter
entry.
Dynamic Directory
<<targetEntry>>
:Class3
/attr1 : targetAttribute
/attr2 : targetAttribute
derives-from
<<sourceEntry>>
:ImportAdapter
>attr3 : sourceAttribute
>attr4 : sourceAttribute
External server
retrie ves
<<externalObject>>
:exte rnalClass1
prop erty1 : N
prop erty2
prop erty3
Figure 46: ImportAdapter entry for externally derived attributes
1.27.1 Information model
All externally derived attribute types of an ImportAdapter object class must be defined
in a "MUST DERIVED" clause. No optional externally derived attributes are allowed. The
Page 145
Dynamic Directory schema developer must define appropriate ImportAdapter subclasses for each set of externally derived attributes. An ImportAdapter entry must not
have internally derived attributes; i.e. all its attributes are either static or externally derived.
This prevents conflicts in the processing sequence of internal and external attribute derivation rules.
The object class ImportAdapter is a subclass of Adapter, the generic object class for
interfacing a Dynamic Directory server with external equipment. These two abstract object
classes are defined as follows:
( dds.2.1 NAME 'adapter'
SUP top ABSTRACT
MUST ( commonName ) )
( dds.2.2 NAME 'importAdapter'
SUP adapter ABSTRACT
MUST import
MAY cachetime )
The mandatory attribute commonName may be used as RDN of an Adapter entry. The
operational attribute import contains a derivation rule of how a single LDAP attribute is
derived from the response of the external server. It is of syntax DirectoryString and
its encoding depends on the particular access protocol. Optionally, an entry may have a
cachetime attribute present (see definition in 1.26.1), indicating the number of seconds
for which externally retrieved attributes may be cached by the Dynamic Directory. If the attribute is absent, it is up to the Dynamic Directory to decide whether caching is to be performed or not. If the attribute specifies a value of zero, no caching is allowed for this entry.
( dds.1.3 NAME 'import' EQUALITY caseIgnoreMatch
SYNTAX DirectoryString USAGE directoryOperation )
For each external access protocol, an ImportAdapter subclass must be defined indicating the type of service to be used and defining the operational attributes being specific to
that access protocol. Required information is in particular the server's address and a
string-encoded retrieval request that must be sent to the external server for obtaining the
required data.
The retrieval request may be parameterised to create identifiers of the external data dynamically. The parameters are created from attribute values passed on by the internal attribute derivation rule from a target entry as introduced in section 1.26.1. Parameters may
be specified with the following syntax in the string-encoded retrieval request. They are replaced at retrieval time with the corresponding attribute values of the target entry by the
Dynamic Directory:
retrievalParameter = "$" index ["$(" separator ")"] ["$:" prefix ":"]
index
= numericstring
separator
= LDAPString
prefix
= LDAPString
Page 146
A retrieval parameter8 $n is replaced with the value of the n-th attribute in the parameter
list supplied from the target entry. The optional element separator defines how multivalued parameter attributes are handled. If the element is omitted, only the first value is
used for the retrieval string, even if the attribute has multiple values. If the element is supplied, all parameter attribute values are concatenated with the identified separator in between. If an optional prefix string is specified, the Dynamic Directory server assumes that
each value of the parameter attribute starts with the specified prefix and removes the prefix in order to transform the value into its externally-used representation.
1.27.2 External access protocols
We chose two protocols that should be supported as external server access protocols by
Dynamic Directory servers: LDAP and SOAP (Simple Object Access Protocol) [ Box99].
LDAP is the protocol that should naturally be supported to access information held by
other directory servers. SOAP is an emerging protocol that provides a platform- and language-neutral format for accessing servers, services, and objects. The ImportAdapter
subclasses required for these two protocols are defined in this section. For each protocol,
the operational attributes required to interact with external servers and the syntax of the
import attribute are defined.
1.27.2.1 SOAP
The Simple Object Access Protocol (SOAP) [Box99] makes use of the HTTP protocol
[RFC2616] combined with XML-encoding [XML1.0] of request and response messages. It is
also referred to as XML-RPC (Remote Procedure Call). SOAP is an emerging technologyneutral technology allowing clients to access services offered by objects. It has been submitted as proposal to the IETF [Box99]. The main aim of SOAP is to facilitate interoperability between competing technologies. SOAP is a protocol that acts as the glue between
heterogeneous software components and is therefore an ideal candidate to be used as
generic interface between Dynamic Directory servers and any external infrastructure.
Translators between the SOAP protocol and technologies such as Java or COM [Skonnard00] and CORBA [Roguewave00] are currently under development. The emergence of
these generic translators will allow to combine a Dynamic Directory server with many deployed server platforms without additional development effort. The current application of
SOAP is mainly method invocation over Internet environments, but with the continuing
progress in XML parser performance, we believe that SOAP will become a universally
used method invocation protocol. Microsoft strongly supports SOAP and will employ
SOAP as a general inter-component communication protocol [Bisson00].
8
The syntax uses the character "$" for coding parameters. If a retrieval request contains that
character, it must be encoded using an escape mechanism based on the '%' character followed by
the decimal ASCII code of the reserved character [RFC1738]. In this case, '$' would be encoded
as "%36".
Page 147
SOAP makes use of the HTTP POST or M-POST method to invoke a method in the
SOAP server. A number of parameters defined in the SOAP specification are required to
construct an appropriate HTTP message. Each parameter is represented in the Dynamic
Directory server with an LDAP attribute in an entry of object class SoapImportAdapter:
( dds.2.3 NAME 'soapImportAdapter'
SUP importAdapter STRUCTURAL
MUST ( host $ mPOST $ endpoint $ xmlPayload )
MAY ( port $ interfaceName $ methodName ) )
All attributes are single-valued operational attributes and all except mPost employ the DirectoryString syntax. The mandatory host attribute contains the name or address of
the SOAP server; the optional port attribute identifies the port unless the default HTTP
port 80 shall be used. The attribute mPost has a Boolean value, whereby true means
that the Dynamic Directory shall make use of M-POST instead of POST HTTP requests.
The endpoint attribute contains the Uniform Resource Identifier (URI) of the component
being invoked. It is up to the SOAP server to interpret the endpoint information and to invoke the component implementing the method from this URI. One possible example would
be the path to a CGI script in an HTTP server or the URI of an active web element. The
optional methodName attribute specifies the method to be called, interfaceName optionally identifies the interface implementing the method.
The SOAP XML payload is specified in the attribute xmlPayload, which must be encoded using the SOAP syntax defined in [ Box99]. The payload consists of an optional
header element and a method element. The method element consists of an XML tag taking the name of the method that may contain further child elements representing parameters to be passed on to the server. The child elements either have parameter names corresponding with the method's parameter names; or they use __param0 , __param1, ..
element names to identify the ordering of unnamed parameters. The XML payload is
transparent to the Dynamic Directory except the replacement of retrieval parameters before sending the payload to the SOAP server.
A simple example XML payload representing an invocation of method LocateTag would
be encoded - without header elements -as follows:
<LocateTag>
<tagId>2</tagId>
</LocateTag>
The response to a method call is received as an HTTP CallResponse message type. It
is encoded in SOAP with an element having the same name as the method name, with
the string "Response" added to the end of the name. The element contains either a return
value (tagged with __return) or a fault indication (tagged with __fault). An example
response might look like this:
<LocateTagResponse>
<__return>17</__return>
</LocateTagResponse>
Page 148
If multiple values - i.e. external object properties - or compound values are returned by a
method, compound types (including structs and arrays) may be constructed using the
rules defined in [SOAP-Proposal]. An example of a compound result is:
<LocateTagResponse>
<__return>
<Sighting>
<TagId>2</TagId>
<SensorId>17</SensorId>
<LastSighting>2000-03-06 09:45:12</LastSighting>
</Sighting>
</__return>
</LocateTagResponse>
The operational attribute import must define for each LDAP attribute that shall be externally derived how it is obtained from the XML-encoded SOAP response. Attribute values
are created from the elements contained in the SOAP response. For this, we defined the
following syntax:
xmlImportFilter =
targetAttribute "=" [":p:" prefix ":"] [xmlElementPath] [colsep] [rowsep]
targetAttribute = AttributeDescription ; from RFC2251, attribute type name
xmlElementPath = xmlElementName *("/" xmlElementName)
xmlElementName = LDAPString
prefix = LDAPString
colsep = ":c:" LDAPString ":"
rowsep = ":r:" LDAPString ":"
The xmlElementPath consists of the concatenation of the XML element names starting
below the __return element. A missing xmlElementPath indicates that a simple, scalar, non-named value is returned as SOAP response that shall be assigned to the LDAP
attribute. If multiple elements matching the specified scoped name are returned from the
server, an attribute with multiple values, one for each element, is created in the ImportAdapter entry.
From each received XML element matching the xmlImportFilter, its contents are
added to an LDAP attribute named by targetAttribute. The identified XML element
must be a scalar type, a struct of scalar elements, or an array of scalar elements to be encoded in an LDAP value. To encode structs or arrays, the optional separator terms must
be specified in the xmlImportFilter. The filter expression defines a simple mechanism
to transform compound XML elements such as structs or arrays into a string encoding by
concatenating the contained elements or array elements using the row (for arrays) and
column (for structs and arrays) separator strings. If compound elements with more complex subelements must be assigned to LDAP attributes, the subelements must be filtered
separately into LDAP attributes with multiple import attribute values. If the SOAP response should contain multiple external objects (which we assume not to be the case, but
which we still have to tolerate), the properties of all objects are extracted and merged into
the externally derived attributes.
An optional prefix may be used to add a prefix string to externally derived values, e.g. to
make values unique within a name space. An example usage is to add a prefix "abs" to
numeric identifiers obtained from an Active Badge infrastructure in order to make them
Page 149
unambiguous with numeric terminal identifiers obtained from a wireless network infrastructure.
1.27.2.2 LDAP
The support of externally derived attributes using the LDAP access protocol allows a Dynamic Directory server to retrieve attribute values from other LDAP directory servers dynamically. This is different from chaining requests between servers, where a client request
is forwarded by a server to other servers that might hold the request's target entry. Externally derived attributes obtain attribute values for a target entry by issuing a different LDAP
request not related to the client request, only triggered by it.
( dds.2.4 NAME 'ldapImportAdapter'
SUP importAdapter STRUCTURAL
MUST ldapURL )
The object class LDAPImportAdapter defines a single mandatory attribute ldapURL
that contains the specification of an LDAP request and the LDAP server to which it must
be sent when the derived attributes shall be obtained. The attribute ldapURL is singlevalued and employs the attribute syntax DirectoryString. It is encoded according to
the LDAP URL specification defined in [RFC2255] with the only addition that it may be parameterised as specified above for the SOAP protocol. The parameters are replaced by
the Dynamic Directory before sending the search request to the external LDAP server.
The URL specifies a complete LDAP search request including information on how the Dynamic Directory server must bind to the external server and indicating which attributes
shall be returned in the response.
The result of the search request is an entry containing the requested attributes or an
LDAP error indication. From the result entry, the Dynamic Directory server retrieves the
requested attributes indicated in the import attribute of the target entry using the following syntax:
ladpImportFilter = targetAttribute "=" sourceAttribute
targetAttribute = AttributeDescription ; from RFC2251, attribute type name
sourceAttribute = AttributeDescription ; from RFC2251, attribute type name
Each source attribute contained in the search result and being requested is assigned to an
externally derived attribute identified in the import rule. If the external server responds
with multiple result entries, the externally derived attributes are extracted from each entry.
Duplicate attribute values are removed from externally derived attributes.
1.27.3 Directory data consistency
Processing externally derived attributes must ensure an adequate data consistency level
as specified by the client in its search request. To ensure the data consistency levels we
defined for internally derived attributes, we must ensure that the externally derived attributes are consistent with one another. The sequential processing of derivation rules must
Page 150
result in consistent values between the derived attributes even when the data held in the
external server changes during the directory operation.
Figure 47: Ensuring data consistency of externally derived attributes using
pre-fetching
Another potential problem might arise with externally derived attributes in those cases
where multiple entries derive attributes from the same ImportAdapter entry during the
same directory operation. This is so because the entries will usually pass on different parameters to the ImportAdapter entry, which will in turn retrieve properties of different
external objects. The externally derived attributes obtained for the different source entries
must not be mixed up.
To solve these problems, a request to an external server (with identical request parameters) should be invoked only once per entry requested by a client or per directory operation - depending on the consistency level of the operation:
Entry-consistent
The externally derived attributes are obtained only once (per set of identical retrieval
parameters) per entry being returned to the client.
Operation-consistent
The externally derived attributes are obtained only once (per set of identical retrieval
parameters) per directory operation initiated by the client.
Page 151
Additionally, all externally derived attributes of an ImportAdapter entry are always obtained in a single atomic request to ensure that they are consistent with each other. If multiple internal attribute derivation rules - from one or multiple entries - request externally derived attributes from an ImportAdapter entry, always the same pre-fetched data of a
single external request is used.
An illustration of the combination of internally and externally derived attributes and the use
of data pre-fetching for providing data consistency is depicted in Figure 47. The three time
lines inside the DDS server represent internal directory entries and their interaction for
processing internal attribute derivation rules. How such pre-fetching of data can be realised in a Dynamic Directory implementation is discussed in chapter 1.34.3.
1.27.4 Operational model
If at least one externally derived attribute of an ImportAdapter entry is required, all externally derived attributes defined in that entry are retrieved. An externally derived attribute
is required if:
Its values are needed for evaluation of search filters
Its values are requested by clients to be returned in search response messages
Its values are required as source attributes for another internally derived attribute
Its values are required for checking event conditions, see also section 1.28.
The Dynamic Directory server may avoid the repeated retrieval of externally derived attributes by making use of cached values obtained during previous requests to answer a client
request if permitted by the client. The new service control noAttributeCaching that
was already introduced in section 1.26.3 allows clients to control handling of externally derived attributes in the same way as internally derived attributes.
The following tasks must be performed by the Dynamic Directory server when an ImportAdapter entry with externally derived attributes is requested in a search operation
of a client or is required as source entry for internally derived attributes in other entries:
Check whether at least one externally derived attribute is needed for completing the request. If not, return the entry, if so, continue to obtain all externally derived attributes.
Check whether cached data can be used for externally derived attributes. This is possible
if cached data exists and is not too old and the client has not excluded the use of
cached data. If possible, return entry with cached data, if not, continue.
If parameters are specified in the retrieval rule, replace them with attribute values passed
on from the target entry.
Send retrieval request to external server identified in the ImportAdapter's operational
attributes.
Wait for retrieval response message from the external server and create all externally derived attributes according to the filter expressions specified in the import attribute values.
Page 152
When all import filters have been processed, return entry. Keep derived attributes for
further attribute derivations, depending on the type of data consistency level of this operation.
If allowed by cachetime attribute, store ImportAdapter entry with externally derived attribute values in a cache for future requests.
The following error situations may occur during retrieval of externally derived parameters:
If an ImportAdapter entry is added in which an attribute is defined as static and as externally derived in the same entry, the Dynamic Directory returns a derivationRuleConflict error to the client.
If an ImportAdapter entry is added which defines internally derived attributes, the Dynamic Directory returns a derivationRuleConflict error to the client.
If a client attempts to add, modify, or delete externally derived attributes in an ImportAdapter entry, the Dynamic Directory sends an error message containing an insufficientAccessRights error code.
If the retrieval parameters cannot be replaced because they were not passed on from the
calling directory operation, the Dynamic Directory returns only static attributes with a
derivationRuleParameterMissing error to the client. This will typically occur, if an
Importdapter falls directly into a client's search scope and matches its filter.
If the external server cannot be located or does not respond to the request, the Dynamic
Directory returns only static attributes with an externalServerUnavailable error to
the client.
If the external server returns an error message, the Dynamic Directory returns only static
attributes with an externalServerError error to the client.
If not all externally derived attributes can be extracted from the response received from
the external server, the Dynamic Directory returns only static attributes with an incompleteExternalAttributes error to the client.
If externally derived attributes cannot be evaluated due to syntactical errors, the server returns only static attributes with a derivationRuleError error to the client.
Access control
Access control policies on entries with externally derived attributes govern retrieval of the
static and externally derived attributes of the ImportAdapter entry. Furthermore, permissions defined for the ImportAdapter influence which attributes may be obtained as
internally derived attributes from other Dynamic Directory entries. In this context, it will
usually be useful to set search and read permissions on the entry's externally derived
attributes to make them derivable by other entries. However, browse permission on the
ImportAdapter entry itself will often be restricted to directory administrators because
regular users and applications will typically not be interested in retrieving Adapter entries.
1.27.5 OMP example
We now can extend the OMP example from section 1.26.4 with the externally derived attributes for object class ABSTag (being internally derived attributes, in fact). For this, an
Page 153
additional entry ImportAdapter is required that contains the operational attributes and is
used by object class ABSTag as source entry to derive attributes.
objectClass = ABSTag
objectId = 2
// RDN, also used as parameter for extern. derived attr.
roamingArea = ABS0 // roamingArea identifies ABS infrastr. serving the tag
position = g116
// internally derived attribute
managingMMD = ac
homeMMD = ac
reference =
currentABSSensor=(&(objectclass=ABSAdapter)(roamingAreaId=$roamingArea)):
currentABSsensor(objectId)
reference =
lastLocating=(=(&(objectclass=ABSAdapter)(roamingAreaId=$roamingArea)):
lastLocating(objectId)
objectClass = adapter
objectClass = importAdapter
objectClass = soapImportAdapter
objectClass = ABSAdapter // subclass allowing externally derived attributes
cn = ABS0
// RDN
roamingAreaId = ABS0
// used by tag to select adapter
host = micon1
mPost = true
endpoint = /absbadgelocator
methodName = LocateTag
xmlpayload = <LocateTag><tagId>$1</tagId></LocateTag> // $1 replaced with '2'
import = currentABSSensor=Sighting/SensorId // assign SensorId to attribute
import = lastLocating=Sighting/LastSighting // assign LastSighting to attr.
1.28 Event handling
A sophisticated new feature of Dynamic Directory Services is the support for event handling. Directory clients may formulate event conditions on the contents of the Dynamic Directory, which are subsequently monitored by the directory server. Upon occurrence of an
event, the server notifies all clients that are interested in that event.
The proposed extension to LDAP called persistent search [ Smith00] is not suited for Dynamic Directory event handling since it lacks a number of important capabilities:
It does not allow formulating conditions on changes to attribute values required to express
real-world conditions such as "user enters an area" or "user leaves an area".
It may only monitor modifications to the directory but is unable to take changes in externally derived attributes into account.
It is unable to deal with internally derived attributes, where a modification in one - source entry may cause an event to fire on another - target - entry.
The Dynamic Directory event handling feature offers additional advantages, such as support for clients on mobile terminals which may temporarily be unavailable - and therefore
might miss event notifications - and support for allowing multiple clients to share a monitored event in order to reduce processing efforts for servers and simplify event definitions
for clients.
Page 154
In this chapter, we discuss major design options for the Dynamic Directory event handling
model, specify the information model and operational model in detail, and finally present
an example of how the event handling capabilities may be used for the Open Mobility Platform.
1.28.1 Design options
This section discusses the main design decisions that influence the Dynamic Directory
event handling architecture in order to motivate the developed directory extensions and to
understand the pros and cons of the chosen approaches. For the development of the Dynamic Directory event handling features, two major technological areas must be taken into
account. When viewing the directory as a database, the concepts of Active Database
Management Systems (ADBMS) [Paton98], [ACT-NET96] are of relevance, since active databases incorporate means to react to changes in the database contents automatically.
When viewing the directory system as a server, the concepts of event notification services
- like CORBA Event Service [OMG95] and CORBA Notification Service [OMG99] - are of interest since they offer mechanisms for clients to receive notification messages from a
server.
1.28.1.1 Event definition
An event from the directory user's point of view means an occurrence of interest in the application domain, e.g. a doctor enters a certain room, at least two persons are present in a
meeting room, etc. Two general approaches for the definition of events can be distinguished:
 The Dynamic Directory offers pre-defined event types tailored for the application domain.
 The Dynamic Directory offers an event definition language that allows defining at least all
events required by the application domain.
The first case can be expected to be simpler for the application developer since he or she
just has to choose an event type out of an event catalogue, whereas in the second case
he or she has to construct an event definition using the provided language. However,
unless the application domain is quite specialised so that all possible event types can be
known beforehand, it is very likely that the fixed set of event types will not exactly meet all
future application developers' requirements. An advantage of the first approach is that the
application developer need not care about the directory-internal occurrences that trigger
events. Especially with the presence of internally and externally derived attributes it is difficult for an application programmer to specify the directory operations that might cause an
event to fire. The changes in the contents of a directory entry containing derived attributes
depend not only on modifications to that entry but also on modifications to other entries,
including changes in external servers. Furthermore, the exact rules of how the derived attributes are determined might be hidden to the directory user due to insufficient access
rights. Therefore, the explicit formulation of event definitions involving dynamic attributes is
a non-trivial or even impossible task for an application developer.
Page 155
The challenge of the second alternative is to provide an event definition language that on
the one hand fits into the directory service and data model and on the other hand is expressive enough to cover all application requirements using an easy-to-use event definition syntax. A straightforward approach to the second alternative would be to base the
condition part of the event definition on the LDAP search filter expression, this is the
method used in the LDAP persistent search proposal [ Smith00]. The drawback of this solution is that its expressiveness is limited and allows formulating conditions only on the final
contents of an entry. It does not allow to formulate conditions that relate to the contents
before the event occurs, which is necessary to formulate that a particular attribute value
has been removed from an entry or that a particular attribute has changed its value.
Resulting from these considerations, we decided to develop a combination of the two approaches. We chose a compromise between generic applicability and ease of use by developing a generic specification language combined with an implicit event specification
model. With our approach, the developer only has to formulate conditions on attribute
value changes that shall cause an event to fire. The event definition is added to the Dynamic Directory as a first-class object. The Dynamic Directory system takes care of monitoring the directory operations that affect the specified value changes including the handling of internally and externally derived attributes. Since our resulting event definition
might still become quite complex in some cases, we additionally allow Dynamic Directory
schema developers to create pre-defined event conditions tailored to an application domain. These so-called event templates may be used by clients as a catalogue to define
events with virtually no knowledge about the event handling definition syntax. The predefined events may be extended without the need to upgrade the Dynamic Directory
server implementation.
The combination of these approaches allows sophisticated clients to formulate flexible
event definitions on any Dynamic Directory schema and at the same time enables functionally limited clients to make use of application-tailored event definitions.
1.28.1.2 Event subscription
Event subscription names the process in which an application expresses its interest in notifications of event occurrences. This process can be coupled to the event definition - we
call that implicit subscription - or it can be a separate process - we call that an explicit subscription. Implicit subscriptions have the advantage that they only require a single operation to be performed by a client to define events and subscribe to them. They are for example employed in the LDAP persistent search proposal. Explicit subscriptions allow to
realise more sophisticated operational models, because directory clients may be given
more control over the notifications they receive.
For the Dynamic Directory event handling functionality, we chose an explicit event subscription approach that clearly distinguishes between event definition and event subscription. The two main reasons for this approach are:
Explicit subscriptions allow a directory client to subscribe to events specified by other clients, provided that access control restrictions allow for this. In environments where multiple clients are interested in the same events of general interest, it lets the Dynamic DiPage 156
rectory share the monitoring effort between multiple clients. Furthermore, simple directory clients with limited capabilities just have to search for already defined events without the need to define own events in order to subscribe for event monitoring functionality.
Explicit subscriptions allow support of applications on mobile terminals that are temporarily
unreachable. After an application becomes reachable again, it just has to re-subscribe
to the event to continue to receive notifications. Additionally, it may request during resubscription forwarding of all those notifications it has missed in the meantime.
Filtering notifications by clients - as offered by the CORBA notification service [OMG99] - is
only partially supported in the Dynamic Directory. We assume that clients only subscribe
to events in which they are interested, therefore, they will receive all notifications caused
by an event definition. The Dynamic Directory supports retrieval of buffered notifications
as explained in the next section. For those notifications, clients should be able to specify
filters to receive only a subset of the buffered notifications.
1.28.1.3 Sending notifications
Notifications can be sent using push models and pull models [OMG95]. A push model allows
a supplier to initiate the transfer of event notifications to the consumer. A pull model allows
a consumer to request the event data from a supplier. For the Dynamic Directory event
handling, the criteria for selecting one of the approaches are related to the compatibility
with the conventional LDAP service model and to the possibility to support applications on
temporarily unreachable mobile terminals. Both of these aspects can be favourably answered with the pull model. First, the pull model is compatible with the LDAP operation
model that is client-server based and requires clients to initiate actions that are answered
by the server in an associated response message. Second, pulling notifications allows a
client to re-initiate receiving of notifications after it becomes reachable again, while a push
model would require the server to keep track of the reachability of its clients.
For the Dynamic Directory event handling, the pull model can be easily mapped on the
LDAP search operation that is not completed by the server but kept alive for sending notifications as search response messages. Each notification then consists of an entry that
contains all information to be conveyed with the notification. This approach has the additional advantage that it enables to temporarily buffer notifications (i.e. their associated entries) for applications that become unreachable. When an application re-subscribes to the
event, it just has to issue a search request with an appropriate filter that matches all buffered notification entries that are of interest to the application. After these missed notification entries have been sent to the client, the normal notification sending mode continues.
1.28.2 Dynamic Directory event handling overview
This section defines the overall design of Dynamic Directory event handling based on the
considerations done in the previous section. It also discusses the realisation of event handling based on the LDAP information and operation model. We define different operational
Page 157
phases during the life cycle of an event definition in the Dynamic Directory and identify
multiple roles that a directory entry may play in these phases.
Dynamic Directory event handling can be divided into the following phases:
Event definition
An event definition is created in the Dynamic Directory by adding an entry of object
class EventDefinition to the directory server. The entry contains a number of operational attributes that define among others the event condition and the event scope,
the latter being the set of entries on which the condition is formulated. This set of entries is also called scoped entries. During this phase, the operational attributes in the
EventDefinition entry are checked concerning their correctness and completeness.
Thereafter, the Dynamic Directory server determines automatically all entries that must
be monitored - the so-called monitored entries - and creates associated event triggers.
If the monitored entries contain externally derived attributes, the Dynamic Directory
server establishes monitoring subcontracts with the external servers. Additionally, the
externally derived attributes of all monitored entries must be obtained by the Dynamic
Directory, if they are not already available for use during event trigger evaluation as preevent values. If all triggers and subcontracts could be created successfully, the Dynamic Directory server confirms the event definition to the client with an LDAP add response message.
Event monitoring
The event monitoring phase follows the event definition phase. During this phase, the
Dynamic Directory server checks after each directory operation whether a monitored
entry is affected by that particular operation. If that is so, e.g. due to an entry modification or due to a change notification from an external server, the entry is called trigger
entry and its associated event trigger fires. An event trigger evaluation is performed on
the fired trigger while the event monitoring phase continues.
- Event trigger evaluation
An event trigger evaluation starts with determining all event definitions that are interested in the event trigger. For each interested event definition, all candidate entries
that potentially fulfil the event condition are determined. The candidate entries are either specified in the event definition, or they are identified from values of the trigger
entry. For each identified candidate entry, the event condition is checked. If the condition evaluates to true, the event fires and the event action part is executed. A notification entry is created and placed below the event definition entry. All notifications
created by an event definition are thereby placed in a single-level subtree below the
definition entry. A search result containing the notification entry is sent to all directory
clients having a subscription to the event definition. Optionally, if an LDAP operation
is specified for the event definition, the operation is performed before the notification
is sent.
During the event monitoring phase, the following processes may be initiated by directory clients:
Page 158
- Event subscription
An event subscription is performed by clients by issuing a search request for notification entries with the event definition of interest serving as the base object of the
search. All notification entries are placed in a single-level subtree below their event
definition entry; therefore, a search below the definition entry will find all notifications
for this particular event. If the search filter requests it, all existing notifications - or
those that the client has missed in the meantime - are immediately sent to the client.
The search request is not completed by the server after the last notification has been
sent. Instead, further notification entries are sent upon event occurrences until the
event monitoring finishes or the client cancels its event subscription.
- Event subscription cancellation
A client may cancel its subscription by abandoning the search request issued for
event subscription. The subscription is cancelled by the server when the event monitoring phase stops or when the connection between server and client is interrupted.
Event termination
An event monitoring phase may be terminated for several reasons, e.g. when the
event's lifetime is expired, the maximum number of notifications has been created, the
client has cancelled the event, or an error has occurred. All client subscriptions to the
event are cancelled, all event triggers are deleted, and monitoring subcontracts with external servers are cancelled. After the lifetime of the notification entries is expired, they
are automatically removed from the directory information tree.
Figure 48 specifies a State Chart [Harel88] for these Dynamic Directory event handling
phases.
event status
event existing
client adds
event
definition
event
definition
event
not
existing client
deletes
event
definition
all event triggers
created
event monitoring
client searches
for notifications
event not
subscribed
event
subscribed
search abandoned
error during
event definition
event
stopped
all event
triggers
deleted
event
termination
trigger[j] status
error, time limit,
notification limit,
user cancellation
trigger not
fired
trigger fires
event fires
trigger
evaluation
finished
notification [i] status
notification existing
event [i] fires
notification not
existing
lifetime
expired,
notific. deleted,
event deleted
notification
existing
notification created
(event subscribed),
notification
search request
sent to client
finished
Figure 48: State Chart of Dynamic Directory event handling phases
Page 159
An entry in the Dynamic Directory Information Tree may play different roles in the context
of event handling, which are summarised in Figure 49.
condition checked for
creates
client
event definition
subscribes
selected-by
scoped entries
subset-of
created-from
placed-below
event triggers
candidate entries
identifies
selected-by
monitored entries
is-a
trigger entry
affects
sent-to
event notification
creates
event monitoring
monitors
directory operation
Figure 49: Entities and entry roles involved in Dynamic Directory event handling
Scoped entries are a collection of all entries on which an event condition is formulated.
For every scoped entry, the Dynamic Directory must be able to derive the pre-event as
well as the post-event values.
Candidate entries are a subset of (or all) the scoped entries on which an event condition
must be evaluated to determine whether an event fires.
Monitored entries are a collection of all entries that might cause an event trigger to fire, if
an LDAP operation is applied to one of the entries or if externally derived attributes of
the entries change. For every monitored entry, the Dynamic Directory must be able to
derive the pre-event as well as the post-event values.
Trigger entry is a monitored entry that causes an event trigger to fire.
1.28.3 Information model
In this section, the information model required to manage the operational information associated with Dynamic Directory event handling is defined. Two types of entries are used
to structure the client-perceivable information required for Dynamic Directory event handling: EventDefinition and Notification entries. In the following, these object
classes and their operational attributes are defined in detail. Additional information model
elements - called event triggers - that are not modelled as directory entries and are invisible to directory applications are managed by the Dynamic Directory server; they are introduced in section 1.28.4.
Entries of object class EventDefinition contain the operational attributes that define
an event rule. These entries are added by directory clients in any part of the DIT where the
client is allowed to add entries. To facilitate unambiguous naming of event definitions and
enforce application-specific access rights, all event definitions belonging to the same application might be placed under a common root entry as shown in Figure 50. This addi-
Page 160
tionally enables a directory client to clean up efficiently all its event-related entries when
they are no longer needed by the client. The collection of all EventDefinition entries
makes up the rulebase of a Dynamic Directory server. For administrative reasons, e.g. to
grant access rights, the rulebase may optionally be structured as a separate subtree, as
shown in Figure 50.
rulebase
root
events of
client A
eId=1
event
definition
nId=1
nId=2
nId=3
nId=4
nId=5
nId=6
events of
client B
eId=2
event
definition
nId=1
nId=2
nId=3
nId=4
nId=5
notification
Created by directory administrator.
Structures name space and access rights.
Hierarchy has no influence on functionality
except granting access rights.
Created by clients.
Used as base object for search.
Created by server.
Sent to clients as notifications.
notification
Figure 50: Entry placement for event handling
During the event monitoring phase, the directory server automatically creates entries of
object class Notification and places the entries in a subtree below the event definition
entry. Notification entries contain all information that must be conveyed in a notification
message to a subscribed client. By searching for notification entries below an event definition, the client may subscribe to an event it has defined itself or that was defined by another client, provided it has sufficient access privileges. Notification entries contain unique
identifiers and timestamps that may be used by clients in search filters to request only
those notifications they have not received in an earlier subscription. Entries of object class
Notification are dynamic entries that are only temporarily stored in the Dynamic Directory. They are automatically removed by the server after their lifetime expires, allowing
the Dynamic Directory server to perform housekeeping of the temporary DIT contents.
Most of the attributes that are defined in this chapter are classified as operational and as
user attribute. They are classified as operational because they are required for the internal
operation of the directory, and they are classified as user attribute, because they shall be
returned in search responses without being explicitly requested. The latter allows simple
directory clients that are not capable of requesting operational attributes to receive event
handling-related information.
1.28.3.1 Event definitions
An event definition is represented in the Dynamic Directory with an entry of object class
EventDefinition that contains a number of operational attributes specifying all required parameters of an event rule.
Page 161
The following groups of operational information are present in an event definition (cf. Figure 51):
Event scope defines to which entries of the DIT the event condition shall be applied. The
event scope defines the binding of an event definition to the contents held in a Dynamic
Directory.
Event condition may consist of two parts: It formulates mandatory conditions on changes
to attribute values of a Dynamic Directory entry (called trigger condition) and optionally
further conditions on the current attribute values (called action condition). If the trigger
condition evaluates to true, the event is said to fire. If the action condition also evaluates to true, the event action is executed.
Event action specifies the actions to be performed, including sending of notifications and
performing directory operations on the candidate entry for which the event fired.
Event lifetime defines the lifetime of the event definition.
Event status reflects the current state of the event handling process.
event definition
<<attributeSet >>
event scope
<<at tribu teSet >>
event condition
<<attributeSet>>
event action
<<at tribut eSet>>
event lif etime
<<attributeSet>>
event status
Figure 51: Contents of event definition
The object class EventDefinition is defined as follows:
( dds.2.5 NAME 'eventDefinition'
SUP top STRUCTURAL
MUST ( eventDefinitionId $ scopeFilter $ triggerConditions $
notificationLifetime $ eventLifetime $ eventStatus )
MAY ( scopeClass $ scopeLimitNamingContext $ classCandidateAVA $
actionConditions $ optimisticPartialCandidate $
notificationContent $ includeOldValues $
includeReference $ includeAliasValues $ includeExternalValues $
eventAction $ notificationLimit $ description $ noRDNTriggers )
FROM SERVER ( eventStartTime $ createdEventTrigger $ eventError $
eventStopReason ) )
The attribute eventDefinitionId is used as RDN of the entry, it uniquely identifies the
event definition between its siblings in the DIT (i.e. usually the other event definitions of a
directory client):
( dds.1.4 NAME 'eventDefinitionId' EQUALITY caseIgnoreMatch
SYNTAX DirectoryString SINGLE-VALUE
USAGE directoryOperation userApplications)
The other operational attributes defined for eventDefinition are discussed in detail in
the following subsections.
Page 162
1.28.3.1.1 Event scope
The event scope defines the Dynamic Directory entries on which the event definition applies. The event scope is specified by the directory clients with the operational attributes
scopeFilter (optional) and scopeClass (mandatory). The scopeFilter consists of
one or more equality match AVAs that must evaluate to true in every entry within the
event scope. The scopeClass optionally defines a single objectClass value that must
be present in all entries within the event scope.
( dds.1.5 NAME 'scopeFilter' EQUALITY caseIgnoreMatch
SYNTAX DirectoryString COLLECTIVE
USAGE directoryOperation userApplications )
scopeFilter = attr equal value ; from definitions in section 1.26.1
( dds.1.6 NAME 'scopeClass' EQUALITY caseIgnoreMatch
SYNTAX DirectoryString SINGLE-VALUE COLLECTIVE
USAGE directoryOperation userApplications )
With the optional Boolean-valued attribute scopeLimitNamingContext, the event
scope may be limited to the naming context in which the event definition entry is located. If
the value is false or the attribute is omitted, all entries held by the Dynamic Directory
server may fall into an event scope.
( dds.1.7 NAME 'scopeLimitNamingContext'
SYNTAX Boolean SINGLE-VALUE COLLECTIVE
USAGE directoryOperation userApplications )
Using combinations of these attributes, three different event scopes may be specified by
directory clients, see also Table 4.
Entry Scope
The entry scope selects a single directory entry that is identified with its Distinguished
Name. The scopeFilter attribute specifies the reserved attribute type DN with the entry's name as assertion value. The attribute scopeClass must not be present. The
identified entry must exist at the time of event definition, otherwise the event is rejected.
The Dynamic Directory creates event triggers on the scoped entry and on all entries the
scoped entry depends on, e.g. due to internally derived attributes. If one of the triggers
fires during event monitoring, the single scoped entry of the event definition is used as
candidate entry.
Collection scope
The collection scope identifies a collection of entries with one or more attribute value
assertions specified in scopeFilter and an optional object class value specified in
scopeClass. At least one scoped entry must exist at the time of event definition, otherwise the event is rejected. The Dynamic Directory creates event triggers on all scoped
entries and on all entries the scoped entries depend on, e.g. due to internally derived
attributes. If one of the triggers fires during event monitoring, all scoped entries are
used as candidate entries for event condition evaluation.
Page 163
Class scope
The class scope identifies all directory entries that belong to the object class specified
in scopeClass. The scope selects all entries of that class, including those that do not
exist at the time of event definition. The event may be accepted even if no single entry
exists at the time of event definition. The scopeFilter must specify an attribute type
of the scoped object class together with the reserved assertion value "any". If one of the
triggers fires during event monitoring, a subset of the scoped entries identified from the
trigger entry is used as candidate entries for event condition evaluation.
Entry scope
Collection scope
Class scope
Value of
scopeFilter
single equality match
AVA with DN as attribute type, assertion value
= entry's Distinguished
Name
one or more equality
match AVAs on any attribute type of entries in
event scope
single equality match
AVA on an attribute
type, assertion value =
"any"
Value of
scopeClass
not present
optionally present
present, identifies single
object class
Applies to
single entry inside
server or naming context that exists at event
definition time and has
the DN specified in
scopeFilter
all entries inside server
or naming context that
exist at event definition
time and match the filters specified in scopeFilter
all entries inside server
or naming context that
exist at trigger evaluation time and have object class specified in
scopeClass
Empty scope
allowed
no, event rejected
no, event rejected
yes
Table 4: Event scopes supported by the Dynamic Directory Services
To limit the complexity of event handling operations, some restrictions are applied as
summarised in Table 5. The collection scope potentially leads to large numbers of created
event triggers and - even worse - candidate entries to be evaluated. Therefore, the Dynamic Directory administrator may enforce restrictions on the number of scoped entries
identified by an event definition and reject all definitions that exceed that limit.
For the class scope, additional restrictions apply. First, the combination of scopeClass
and scopeFilter must identify unambiguously a so-called class template, which facilitates event trigger creation. This will be further discussed in section 1.28.4.2.2. If no class
template exists for the specified values, the event is rejected. Second, it must be possible
for the Dynamic Directory to identify a limited set of candidate entries from the trigger entry
that causes an event to fire. This ensures that during event trigger evaluation, the event
condition must be evaluated only for a limited number of candidate entries. Without this
restriction, all entries belonging to the scoped object class would potentially have to be
evaluated, which would necessitate considerable processing efforts in the Dynamic Directory server.
Page 164
Entry scope
Collection scope
Class scope
Number of candidate entries
candidate entry identical
with scoped entry
all scoped entries are
candidate entries
limited number of candidate entries identified
from values in trigger entry
Further restrictions on scope
validity
entry must be placed in
naming context if scopeLimitNamingContext is
true
selected entries must be
placed in naming context
if scopeLimitNamingContext is true
class template for object
class scopeClass must
exist, AVA attribute type
must be present in template (see section
1.28.4.2.2)
maximum number of
scoped entries must be
smaller than optional
administrative limit
classCandidateAVA attribute must specify AVA
for each potential trigger
entry object class (see
section 1.28.4.2.2)
Table 5: Restrictions on event scopes supported by the Dynamic Directory Services
1.28.3.1.2 Event condition
An event condition formulates an expression that is evaluated on the attributes of a candidate entry to determine whether an event fires or not. It may evaluate to true, false, or
undefined. Only if the condition evaluates to true, will the action part of the event definition be executed by the Dynamic Directory server, including the sending of notifications
to directory clients that subscribed to that particular event definition. The event condition
consists of two parts: A trigger condition and an action condition.
The mandatory trigger condition formulates an expression on the changes of attribute values in the candidate entry; i.e. it compares the pre- and post-event entry contents. If the
trigger condition evaluates to true for a candidate entry, the event fires, meaning that the
other parts of the event definition are processed. The optional action condition expression
formulates an expression on the post-event candidate's attribute values, ignoring the preevent contents that were present before the trigger fired. If the action condition also evaluates to true, the action part of the event definition is executed by the Dynamic Directory
server. Therefore, for every scoped entry, the Dynamic Directory must be able to derive
the pre-event as well as the post-event values to compare the values of a candidate entry
present before and after a trigger fired. How this may be realised in a Dynamic Directory
implementation will be discussed in 1.34.3.
An event condition is formulated with values of two operational attributes. The attribute
triggerConditions is mandatory and formulates an expression that consists of an optional logical composition operator and one or more test operators according to the BNF
specified below. Each test operator is represented as a value of the triggerConditions attribute. The optional attribute actionConditions formulates an expression on
the candidate's attribute values at the time of condition evaluation.
( dds.1.9 NAME 'triggerConditions' EQUALITY caseIgnoreMatch
SYNTAX DirectoryString COLLECTIVE
USAGE directoryOperation userApplications )
Page 165
( dds.1.10 NAME 'actionConditions' EQUALITY caseIgnoreMatch
SYNTAX DirectoryString COLLECTIVE
USAGE directoryOperation userApplications )
Condition test operators
The various test operators defined for the Dynamic Directory and their syntax are described below. They can be classified into changeTest and valueTest operators.
triggerConditions
triggerCondition
actionConditions
actionCondition
=
=
=
=
compositionOp 1*(triggerCondition)
attr changeTest
; attribute
[compositionOp *(valueCondition)]
attr valueTest
; attribute
; at least one cond.
type and test
; optional
type and test
compositionOp
numbertrue
attr
= ["and" / "or" / "any" numbertrue] ; default is "and"
= numericstring
; number of true conditions
= AttributeDescription
; RFC2251, attribute type name
The changeTest operators compare the current contents of the candidate entry with the
contents the entry had before the event trigger fired. These test operators on changes in
Dynamic Directory entries have been defined:
changeTest
= attributeAdded / attributeChanged / attributeRemoved /
valueAdded / valueChanged / valueRemoved /
anyValueAdded / anyValueRemoved
Test operators on changes to whole attributes:
attributeAdded
attributeRemoved
attributeChanged
= "+"
= "-"
= "^"
; attribute was added
; attribute was removed
; attribute was added or removed
Test operators on changes to attribute values:
valueAdded
anyValueAdded
valueRemoved
anyValueRemoved
valueChanged
anyValueChanged
=
=
=
=
=
=
"+" value-list ; all values of list were added
"+any"
; any value was added
"-" value-list ; all values of list were removed
"-any"
; any value was removed from attribute
"^" value-list ; all values of list were added or removed
"^any"
; any value of attribute changed
value-list
value
= value *( "$" value)
= AttributeValue ; from RFC2251, defined as OCTET STRING
; "$" not permitted in value, must be escaped as "%36"
The valueTest operators evaluate only the current entry contents independent of earlier
values of the entry's attributes. These test operators on current values in Dynamic Directory entries have been defined:
valueTest =
Page 166
allSpecifiedPresent / oneSpecifiedPresent /
noneSpecifiedPresent / onlySpecifiedPresent /
noValuePresent / nValuesPresent /
lessValuesPresent / moreValuesPresent/
oneValueGreater / allValuesGreater /
oneValueSmaller / allValuesSmaller/
beforeTime / afterTime
Test operators on the presence of specified attribute values:
allSpecifiedPresent
oneSpecifiedPresent
noneSpecifiedPresent
onlySpecifiedPresent
=
=
=
=
"&"
"|"
"#"
"!"
value-list
value-list
value-list
value-list
;
;
;
;
all specified values present
at least one specified value present
none of specified values present
only specified values present
Test operators on the number of present attribute values:
nValuesPresent
= "=#" number
lessValuesPresent = "<#" number
moreValuesPresent = ">#" number
; specified number of values present
; less than specified number of values
; more than specified number of values
Test operators comparing present attribute values with specified reference value:
oneValueGreater
allValuesGreater
oneValueSmaller
allValuesSmaller
=
=
=
=
">" value
">>" value
"<" value
"<<" value
;
;
;
;
at least one value larger
all values larger
at least one value smaller
all values smaller
Condition evaluation
An event condition evaluates to true, if the triggerConditions expression and - if
specified - the actionConditions expression evaluate to true. Each of these conditions may be a composite expression logically composed with the "and", "or", or "any n"
operator defined above. The latter means that for the composite expression to be true, at
least n test operators must evaluate to true.
An event condition evaluates to undefined, if for at least one attribute specified in the
test operators either the pre-event - in case of a change test - or the current value may not
be derived by the Dynamic Directory server. This situation may occur, if an external server
provides data that do not identify a candidate entry existing in the Dynamic Directory.
Other situations are that the candidate entry is an alias entry that cannot be dereferenced
or an entry with internally derived attributes that return a continuation reference to another
server. In all these cases, the Dynamic Directory has no or only partial information about
the candidate entry's contents.
The directory client may specify that an event condition may evaluate to true, even if attribute values are missing. This option is selected by the directory client by adding the optional Boolean-valued attribute optimisticPartialCandidate with the value true.
This name was chosen because the Dynamic Directory server optimistically assumes that
the test operators on all attribute values missing in the candidate entry evaluate to true.
( dds.1.8 NAME 'optimisticPartialCandidate'
SYNTAX Boolean SINGLE-VALUE COLLECTIVE
USAGE directoryOperation userApplications )
Time-related events
The support of time-related events is principally possible with the above described approach and was supported in earlier versions of the Dynamic Directory event handling
functions. To initiate events depending on the current time, an additional triggerCondition expression on singular or recurring time conditions allows to define a time in the fu-
Page 167
ture at which the event shall fire, or an interval, at which the event shall fire repeatedly.
We believe, however, that initiating events based on time should be triggered outside the
Dynamic Directory, since the event initiative is not dependent on directory entry contents.
Supporting time-related conditions that are checked when the trigger condition evaluates
to true is another possible feature that could be included in the Dynamic Directory. With
the following additional definitions for actionCondition test operators, time-related
conditions may be checked by the server: The reserved attribute type triggerTime must
be specified with one of the following time-related test operators:
beforeTime
afterTime
time
= "<" time
= ">" time
= GeneralizedTime ; string encoding from [X.208], cf. page 172
1.28.3.1.3 Event action
If an event fires and its action condition evaluates to true, an event action is executed by
the Dynamic Directory. The action is specified by clients with a number of operational attributes in the EventDefinition entry. It may consist of two parts: A notification entry
may be created that is sent to subscribed clients, and an optional LDAP operation may be
performed by the Dynamic Directory on the candidate entry before the notification is sent.
Notifications
The contents of a notification entry and the time it shall be kept in the Directory Information Tree are controlled with the following operational attributes. The mandatory attribute
notificationLifetime specifies the number of seconds for which the notification entry shall be kept in the Directory Information Tree. If the lifetime is specified as zero, notifications are sent to the client but the entries are not stored by the Dynamic Directory.
( dds.1.11 NAME 'notificationLifetime' EQUALITY numericStringMatch
SYNTAX NumericString SINGLE-VALUE COLLECTIVE
USAGE directoryOperation userApplications )
The optional attribute notificationContent contains a list of attribute types. They
identify attributes from the candidate entry that shall be included in the notification entry. If
the attribute has multiple values, the lists are concatenated. For all specified attribute
types, a copy of the attribute and all its current values is created in the notification entry.
( dds.1.12 NAME 'notificationContent' EQUALITY caseIgnoreMatch
SYNTAX DirectoryString COLLECTIVE
USAGE directoryOperation userApplications )
notificationContent = attr *("," attr) ; list of attribute type names
Applications may wish not only to receive the candidate entry's current attribute values,
but may want to receive selected pre-event attribute values that the entry contained before
the event fired. This may be requested with the optional attribute includeOldValues
that specifies the list of attribute types for which pre-event values are required:
( dds.1.13 NAME 'includeOldValues' EQUALITY caseIgnoreMatch
SYNTAX DirectoryString COLLECTIVE
USAGE directoryOperation userApplications )
Page 168
includeOldValues = attr *("," attr)
; list of attribute type names
During determination of the candidate entry's current attribute values, a continuation reference may be created, e.g. due to internally derived attributes or due to alias dereferencing. If the optional Boolean attribute includeReference is present and has the value
true, the continuation reference is added to the notification entry.
( dds.1.14 NAME 'includeReference'
SYNTAX Boolean SINGLE-VALUE COLLECTIVE
USAGE directoryOperation userApplications )
If the optional attribute includeAliasValues is set to true, attributes from an alias entry are added to the notification, if the alias could not be dereferenced for determining the
candidate entry. Only attribute types identified in notificationContent are copied
from the alias entry.
( dds.1.15 NAME 'includeAliasValues'
SYNTAX Boolean SINGLE-VALUE COLLECTIVE
USAGE directoryOperation userApplications )
For some applications, it will be useful to additionally receive the externally derived attribute values, if the trigger entry is an ImportAdapter. This is useful especially if the candidate entry cannot be determined from the trigger entry. If the option attribute
includeExternalValues is true, all externally derived attributes contained in the trigger entry will be added to the notification. These attributes are copied independently of the
attribute types specified in notificationContent.
( dds.1.42 NAME 'includeExternalValues'
SYNTAX Boolean SINGLE-VALUE COLLECTIVE
USAGE directoryOperation userApplications )
LDAP operations
Performing an LDAP operation on the candidate entry is the other type of action that a
Dynamic Directory server may execute, if an event fires and its action condition evaluates
to true. The LDAP operation is executed after the notification entry has been created (to
ensure that the operation may not influence the contents of the notification), but before the
notification message is sent to the directory client (to ensure the client sees its effects
when it accesses the directory after the notification is received).
Two types of modification operations have been defined as possible actions. The
addValue operation adds all values of a specified source attribute to a specified target attribute inside the candidate entry. The replaceValue operation replaces all values of the
target attribute with all values of the source attribute. Both operations may be specified using the eventAction attribute, which is encoded according to the BNF specified below.
The attribute may have multiple values; in this case all specified operations are performed,
the sequence of operations, however, is not guaranteed.
( dds.1.16 NAME 'eventAction' EQUALITY caseIgnoreMatch
SYNTAX DirectoryString COLLECTIVE
USAGE directoryOperation userApplications )
eventAction = actionType ":" targetAttribute "=" sourceAttribute
Page 169
actionType = "add" / "replace"
targetAttribute = attr
sourceAttribute = attr
attr = AttributeDescription ; from RFC2251, attribute type name
If an error occurs during the LDAP operations (e.g. the target attribute is not allowed by
the candidate entry's object class definition), the error is reported in the notification entry in
the attribute actionStatus, as described in the following section.
Although the Dynamic Directory's action capabilities may be easily extended, if application
requirements for more complex operations are identified in the future (e.g. incrementing
numeric attribute values for event counting, etc.), we believe that for many applications
these simple operations will suffice.
1.28.3.1.4 Event lifetime
The lifetime of the event monitoring phase can be controlled in several ways. It can be directly terminated by modifying the event status as described in the following section, and it
can be defined during event definition. With the operational attributes eventLifetime
and notificationLimit, the client can define upper limits to the duration in seconds
the event is active and to the number of notifications created by the event definition. Once
defined, these limits may not be modified by clients for an active event.
( dds.1.17 NAME 'eventLifetime' EQUALITY numericStringMatch
SYNTAX NumericString SINGLE-VALUE COLLECTIVE
USAGE directoryOperation userApplications )
( dds.1.18 NAME 'notificationLimit' EQUALITY numericStringMatch
SYNTAX NumericString SINGLE-VALUE COLLECTIVE
USAGE directoryOperation userApplications )
If the client specifies a lifetime of zero, the lifetime is not limited by the client but controlled
by administrative limits specified by the Dynamic Directory administrator. If the optional
notificationLimit is specified as zero or omitted, no maximum number of notifications is enforced (then the only limit is the lifetime).
1.28.3.1.5 Event status
A client may inform itself about the status of an event definition, e.g. to check whether an
event is still being monitored and which part of the Dynamic Directory DIT is being monitored. To represent the current event status and to control the operational behaviour of the
server, the mandatory eventStatus operational attribute may be used. In contrast to
most other operational attributes, which are created and modified either by the client or by
the server, this attribute may be modified by both.
( dds.1.23 NAME 'eventStatus' EQUALITY caseIgnoreMatch
SYNTAX DirectoryString SINGLE-VALUE COLLECTIVE
USAGE directoryOperation userApplications )
eventStatus = "active" / "cancelled" / "stopped"
Page 170
The following values are defined for the eventStatus attribute:
Active: The event rule is monitored by the server, and notifications are sent to subscribed
clients.
Cancelled: The event rule is cancelled by a client by modifying the value to cancelled.
The server will modify the status to stopped when the event monitoring phase is terminated and start the event termination phase.
Stopped: The event monitoring phase has been stopped by the server. This value may
only be set by the Dynamic Directory server. Reasons for stopping the event may be
that an error occurred, the time limit or notification limit was reached, the user cancelled
the event, or the event scope may have become empty.
The reason is indicated in the attribute eventStopReason that is automatically created by the server, see also the State Chart in Figure 52.
( dds.1.24 NAME 'eventStopReason' EQUALITY caseIgnoreMatch
SYNTAX DirectoryString SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation userApplications
eventStopReason = "time limit reached" / "notification limit reached"
"error occurred" / "cancelled by client" / "empty scope"
eventStatus values
cancelled
client cancels
event
active
monitoring stopped
by server
server enforces
time limit notification
limit reached
stopped
cancelled
by client
time limit
reached
notification
limit reached
error
client deletes
last entry in scope
error
occurred
empty scope
Figure 52: State Chart of eventStatus and eventStopReason values
The eventStatus attribute must be specified by the directory client in the event definition
entry, with the attribute value being active. Once the status is set to cancelled by a
client, the event may not be activated again. In order to activate an identical event definition, a new event definition entry must be added to the Dynamic Directory. Modifications to
the eventStatus attribute should be protected for public event definitions, since a client
may cancel the event although other clients are subscribed to it, too.
The operational attribute eventStartTime contains the date and time at which the event
definition was added to the Dynamic Directory. The attribute is automatically created by
the Dynamic Directory when the event definition entry is added to the server, its value is
Page 171
therefore the same as the createTimestamp attribute value (a standard operational attribute added by the server [RFC2252]). It employs the standard LDAP syntax GeneralizedTime [RFC2252] that makes use of a string encoding defined in [ X.208].
( dds.1.20 NAME 'eventStartTime' EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX generalizedTime
SINGLE-VALUE
// e.g. YYYYMMDDHHMMSS
NO-USER-MODIFICATION USAGE directoryOperation userApplications )
The start time plus the number of seconds defined in eventLifetime specifies the time
after which the event monitoring phase will be stopped by the Dynamic Directory server.
This attribute is therefore important for clients to determine the remaining event monitoring
time. The optional attribute eventDescription may contain a textual description of the
event definition to be used by human users of the Dynamic Directory. This attribute is useful for browsing through the already active event definitions to search for events to which
the client may subscribe.
( dds.1.19 NAME 'eventDescription' EQUALITY caseIgnoreMatch
SYNTAX DirectoryString COLLECTIVE
USAGE userApplications )
The operational attribute createdEventTrigger contains a string representation of all
event triggers created by the Dynamic Directory server during the event definition phase.
An event trigger classifies the information that must be monitored by the Dynamic Directory in response to an event definition. Every event trigger is represented by a value of this
attribute. This attribute is added to the event definition entry by the Dynamic Directory and
may not be modified by directory clients. From the values of this attribute, the client may
derive which entries and attributes of the DIT are being monitored for this particular event
definition. The encoding syntax of this attribute is defined in section 1.28.4.1 in context
with the event trigger descriptions.
( dds.1.21 NAME 'createdEventTrigger' EQUALITY caseIgnoreMatch
SYNTAX DirectoryString
NO-USER-MODIFICATION
USAGE directoryOperation )
If during event definition or event monitoring an error occurs, an error indication will be
created by the Dynamic Directory as string-encoded value of the eventError attribute.
Every error will add a separate attribute value.
( dds.1.22 NAME 'eventError' EQUALITY caseIgnoreMatch
SYNTAX DirectoryString NO-USER-MODIFICATION
USAGE directoryOperation userApplications )
1.28.3.1.6 Pre-configured event definitions
To simplify the creation of event definitions for directory clients with limited capabilities, the
operational attributes required for event handling may be added from collective attribute
subentries. For this purpose, a dedicated object class PreconfiguredEventDefinition was defined, that requires only the attribute eventDefinitionId to be supplied
by the client, all other attributes may be automatically added from a subentry. Different
Page 172
subentries with pre-configured events will typically be offered by the Dynamic Directory
administrator.
( dds.2.6 NAME 'preconfiguredEventDefinition'
SUP top STRUCTURAL
MUST ( eventDefinitionId )
MAY ( notificationContent $ includeOldValues )
FROM SUBENTRY ( scopeFilter $ triggerConditions $ notificationLifetime $
eventLifetime $ eventStatus ) )
For each pre-configured event, a subclass of PreconfiguredEventDefinition must
be defined that is instantiated by the client in order to define the event. The subclass is required to be used as a filter by the collective attribute subentry adding the remaining operational attributes, see also section 1.31.2.
1.28.3.2 Notifications
Notifications are created by the Dynamic Directory, if an event fires and its action condition
evaluates to true. Their content is modelled as directory entry that is added to the DIT, if
the notification lifetime is greater than zero. Notification entries are soft entries that have a
limited lifetime and are automatically removed by the Dynamic Directory when their lifetime is expired, as described in section 1.31.1. Additionally, all notifications of an event
definition may be removed with a single delete operation applied to the event definition entry; this is an inherent feature of soft entries. Notification entries may not be created or
modified by directory clients, they may only be deleted. Any attempt by clients to modify
9
notification entries will be rejected with an insufficientAccessRights error code.
( dds.2.7 NAME 'eventNotification'
SUP top STRUCTURAL
FROM SERVER ( notificationId $ notificationTime $ notificationReason $
triggerEntry $ candidateEntry $ actionError $
candidateReference $ triggerFireId )
The attribute notificationId unambiguously identifies the notification entry from its
siblings in the DIT and from other notifications sent for the same event definition. It has a
numeric value starting with one and being incremented by the Dynamic Directory with
each notification created for the same event definition.
( dds.1.25 NAME 'notificationId' EQUALITY numericStringMatch
SYNTAX NumericString SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation userApplications )
This attribute may be used by directory clients when retrieving already existing notification
entries to select only those notifications that were created after a notification the client has
already received. The client may for example request all notifications having a larger notification identifier than specified in a search filter.
9
This is more restrictive than for other soft entries, which may be modified as discussed in 1.31.1.
Page 173
1.28.3.2.1 Generic attributes in notification entries
Each notification entry contains a number of generic attributes independent of the event
definition contents. The notificationTime attribute specifies the date and time at
which the notification was created. The attribute employs the same syntax and encoding
as the eventStartTime attribute.
( dds.1.26 NAME 'notificationTime' EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX generalizedTime SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation userApplications )
The attribute may be used by directory clients when retrieving already existing notification
entries to select only those notifications that were created after a specified time.
The reason why the notification was created, i.e. the LDAP operation that caused the
event to fire, is identified with the notificationReason attribute. It has one of the values specified below.
( dds.1.27 NAME 'notificationReason' EQUALITY caseIgnoreMatch
SYNTAX DirectoryString SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation userApplications )
notificationReason = "add operation" / "delete operation" /
"modify operation" / "modify DN operation" /
"extended operation" / "external attribute value changed"
A single firing event trigger may cause multiple notifications to be created and sent to a
subscribed client. To allow clients to associate multiple notifications with each other, the
attribute triggerFireId may be added to a notification. All notifications caused by the
same firing event trigger contain the same triggerFireId, allowing the client to associate those notifications with the same firing event.
( dds.1.58 NAME 'triggerFireId' EQUALITY numericStringMatch
SYNTAX NumericString SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation userApplications )
The trigger entry on which the LDAP operation was performed is specified in the triggerEntry attribute; the candidate entry on which the event condition evaluated to true
is identified in the candidateEntry attribute. Both employ DistinguishedName syntax
and contain the DN of the entries. The candidateEntry attribute is optional, it might be
absent if the candidate entry was not found by the Dynamic Directory server.
( dds.1.28 NAME 'triggerEntry' EQUALITY distinguishedNameMatch
SYNTAX DistinguishedName SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation userApplications )
( dds.1.29 NAME 'candidateEntry' EQUALITY distinguishedNameMatch
SYNTAX DistinguishedName SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation userApplications )
If an action operation is defined in the event definition, the optional attribute actionError may contain a string-encoded error code, if the LDAP operations caused an error.
The values contain the LDAP error names specified in [RFC2251].
Page 174
( dds.1.30 NAME 'actionError' EQUALITY caseIgnoreMatch
SYNTAX DirectoryString SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation userApplications )
If the option includeReference is specified in the event definition, the attribute candidateReference is present in the notification entry containing the URL - encoded as
specified in [RFC2255] - of the server that contains further information about the candidate
entry.
( dds.1.31 NAME 'candidateReference' EQUALITY caseExactIA5Match
SYNTAX IA5 String SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation userApplications )
1.28.3.2.2 Application-defined attributes in notification entries
The remaining attributes of the notification entry depend on the contents of the event definition entry. All attribute types specified in the notificationContent attribute list may
be present in the notification entry. Therefore, notification entries are instances of the auxiliary LDAP object class extensibleObject [RFC2252], allowing any attribute to be present in an entry. The extensibleObject approach was chosen, since the presence of
attributes is defined at directory runtime by the client, preventing the definition of notification subclasses (like e.g. for externally derived attributes).
If the attribute includeOldValues was specified by the client, all specified attribute
types preceded with "-" may be present additionally.
oldValue = "-" AttributeDescription
; from RFC2251, attribute type name
Similarly, if the option includeExternalValues was set by the client, all externally derived attribute types of the trigger entry preceded with ">" may be present additionally. The
attribute values are obtained from the ImportAdapter that triggered the event.
externalValue = ">" AttributeDescription ; from RFC2251, attribute type name
1.28.4 Event triggers
This section defines the role of event triggers and their creation by Dynamic Directory
servers. Additional information model elements that are needed by a Dynamic Directory
server to perform event trigger creation and interpretation are defined; some of them are
invisible to directory clients.
An event trigger is used by the Dynamic Directory to classify a piece of information that
shall be monitored because it might affect an event definition. Event triggers are not specified by directory clients but are created automatically by the Dynamic Directory based on
the event scope and event condition. Event triggers are created on all directory entries
and attributes that have impact on the outcomes of the event condition. The contents of
an entry depend not only on its own static attributes but may depend also on internally and
externally derived attributes. Therefore, event triggers must not only be created on the
scoped entries but on a larger collection of entries that influences the contents of all
scoped entries. The overall set of entries to which event triggers are assigned is called
monitored entries (see Figure 49).
Page 175
The triggers are associated with the entries in the DIT, and for every modifying LDAP operation performed on the DIT, the directory server must check whether an event trigger is
affected by the operation. If an operation modifies an entry that is associated with an
event trigger, the trigger fires, and the entry is called a trigger entry. For each firing trigger,
the associated event definition must be determined, and the event condition must be
checked for all candidate entries. Candidate entries are either all scoped entries (for entry
and collection scope) or a subset of the scoped entries (for class scope).
1.28.4.1 Trigger types
Two types of event triggers must be differentiated: Update triggers and import triggers.
Update triggers specify which entries and attributes must be monitored during LDAP modification operations. Import triggers are required to monitor changes in externally derived
attributes. Two different update trigger types are used by the Dynamic Directory. An entry
trigger identifies a single attribute type in a single entry to be monitored by the server. A
class trigger identifies a single attribute in all entries belonging to a particular object class
to be monitored.
The operational attribute createdEventTrigger (defined in section 1.28.3.1.5) contains
the following string representations of the event triggers that were created by the Dynamic
Directory during an event definition phase:
createdEventTrigger = updateTrigger / importTrigger
updateTrigger = "update:" attr ":" ( entryTrigger / classTrigger )
importTrigger = "import:" attr ":" entryTrigger
attr
= AttributeDescription // attribute type, from section 1.26.1.3
entryTrigger = name
// entry DN, name from section 1.26.1.3
classTrigger = "<" value ">" [contextprefix] // objectClass value
// from 1.26.1.3
contextPrefix = name
// prefix of naming context, if scope shall be limited
An event trigger identifies a single attribute type that shall be monitored in an entry or in a
class of entries. An update (entry) trigger may also apply to the Distinguished Name of an
entry instead of to an attribute of the entry. In this case, the attribute specified in the update trigger has the reserved value "DN". A class trigger may be limited to all entries within
a naming context being identified with its prefix. This is the case, if the event definition limited the scope of the event to the naming context to which the event definition was added.
Without specified prefix, a class trigger encompasses all entries of an object class held by
the Dynamic Directory. If for an update (class) trigger the specified objectClass is
"Top", the trigger applies to all entries in the Dynamic Directory server or naming context
(because all entries are subclass of Top).
1.28.4.2 Trigger creation
Event triggers are created by the Dynamic Directory during the event definition phase. For
entry and collection scope, the principal creation method is simple; it is based on evaluating the event condition for all scoped entries and creating event triggers on all attributes
affecting the outcomes of the event conditions. For the class scope, the approach is more
complex, since the Dynamic Directory server may not evaluate the event condition for all
Page 176
entries of a class and triggers must be created even on entries that do not exist at event
definition time.
1.28.4.2.1 Entry and collection scope
To create triggers for entry and collection scope events, the Dynamic Directory server determines all attribute values that are required to evaluate the event's triggerCondition
expression. All attributes - in the scoped entries and in other entries on which the scoped
entries depend - that affect the outcome of the triggerCondition expression must be
monitored by the Dynamic Directory and appropriate event triggers must be created. If the
expression also depends on externally derived attributes, import triggers are created on
these attributes, see section 1.28.4.3.
Initially, all scoped entries are added to the set of monitored entries. For each monitored
entry, event triggers are created in the following way:
First, update triggers are created on all static attributes that are required to evaluate the
triggerCondition expression, if the entry is a scoped entry, or that are required as
source attributes, if the entry acts as source entry. In the first case, the update triggers are
entry triggers. In the second case, the update triggers are entry triggers, if the source entry
was selected by its DN, whereas class triggers are created, if the source entry was selected by a search derivation rule. The reason for creating class triggers on source entries
selected by a search is that if an entry is modified, it might fulfil the selection criterion and
become a source entry. If only entry triggers were created, new source entries would not
be monitored by the server. The class trigger is created on the object class specified in the
attribute derivation rule. No update triggers are created for static attributes of ImportAdapter entries because we assume that those attributes will usually not be modified
during directory operation.
The next step depends on whether the monitored entry contains internally or externally derived attributes. For all externally derived attributes that are required to evaluate the
triggerCondition expression, import triggers are created on the required externally
derived attributes (this procedure is defined in section 1.28.4.3). If the monitored entry
contains internally derived attributes that are required to evaluate the triggerCondition expression, update triggers must be created:
For all attributes that are used for parameterising a selection of a source entry required for
condition evaluation.
For all attributes that are conveyed as parameter to a source entry required for condition
evaluation.
The created trigger is a class trigger if the target entry itself is a source entry that was selected by a search from a derivation rule, otherwise it is an entry trigger.
Thereafter, update triggers must be created on those attributes in the source entries that
affect the selection of the source entry:
If the source entry is selected by its DN, an update (entry) trigger on its DN is created.
Page 177
If the source entry is selected by a search derivation rule, class triggers are created on all
attribute types used in the source entry selection rule.
The last step is to add all source entries to the set of monitored entries and to perform the
trigger creation procedure on these new monitored entries, as described above.
Before an update trigger is created, the Dynamic Directory server may check whether a
compatible trigger already exists. If so, the existing trigger may be re-used for the event
condition. If a class trigger on an attribute exists for which an entry trigger shall be created,
that trigger may be re-used, too, since the entry is already covered by its class.
The above-defined procedure has the following consequences:
The set of monitored entries may be much larger than the set of scoped entries, if multiple
internally derived attributes are defined in the scoped entries.
There may be scoped entries that do not have any trigger associated, e.g. if they only contain internally derived attributes that are not parameterised and have no parameters associated with their derivation rules. These scoped entries do not belong to the set of
monitored entries.
Update triggers are created on many attributes, which theoretically affect the outcome of
the event condition but in reality never change. Examples are attributes that serve as
RDN or unique identifier of entries, which usually do not change during the lifetime of a
monitored entry. To prevent the creation of update triggers on these attributes, an additional operational attribute noRDNTriggers has been defined. If this attribute is present in an event definition with the value true, no update triggers on RDN attributes
are created.
( dds.1.32 NAME 'noRDNTriggers'
SYNTAX Boolean SINGLE-VALUE COLLECTIVE
USAGE directoryOperation userApplications )
1.28.4.2.2 Class scope
Handling events with class scope faces two additional challenges compared to entry and
collection scope: Creating event triggers on all entries belonging to an object class and
identifying the candidate entries when an event trigger fires.
Trigger creation
The creation of event triggers could be approached in the same way as for the other
scopes by evaluating the event condition on all existing entries of the specified object
class and by creating class triggers instead of entry triggers. However, this approach has
two drawbacks. It necessitates considerable processing effort, since the procedure described in the section before must be applied to all entries belonging to the specified class.
Furthermore, it is not guaranteed that all required triggers are created, since triggers are
only created for entries that exist at trigger creation time. If later additional entries belonging to a subclass of the specified class are created, they might not be monitored correctly.
The problem arises, if the object class specified in the event scope is not the structural object class of the monitored entry, but any class of its superclass chain. In this situation, all
Page 178
monitored entries may belong to the same object class but differ considerably in their rules
for internally and externally derived attributes. An example is an event on the OMP object
class Tag. There may be entries with different subclasses of Tag in the Dynamic Directory, such as ABSTag or RFTag entries. If the OMP attribute position shall be monitored, the event triggers required for the different subclasses differ considerably from one
another. If at trigger creation time there were only ABSTag entries present, the required
triggers for RFTag entries would not be created.
The simplest solution would be to allow class scope events only on structural object class
values (in the example on ABSTag and RFTag). That would allow to create the event triggers by randomly selecting any existing entry belonging to that class and creating class
triggers on all its attributes, similar to the procedure described in the previous section. We
decided to employ an alternative solution that allows the definition of events on nonstructural object classes, since this increases the usefulness of the Dynamic Directory
event handling functions considerably.
Our approach is to create an additional entry in the Dynamic Directory that represents all
entries belonging to the specified object class. This entry is called class template and is an
aggregation of the attributes of all subclasses that shall be represented with that template.
In the example, the class template of object class Tag contains all attributes of all Tag
subclasses, including those of ABSTag and RFTag. All static attributes have the reserved
value "any" present, irrespective of their syntax. In addition to the attributes, also the attribute derivation rules are aggregated from all subclasses. In the derivation rules, source
entries are selected by name or by search selection rules in which source entry attribute
values are specified as "any". Therefore, the selected source entries must also be represented by class templates. If attribute values are internally derived from a source entry
that is a class template, the resulting attribute value is always "any".
The event triggers may now be created in a similar way as for entry and collection scope.
The event scope selects the class template with the object class specified in scopeClass
and with the value "any" specified in the scopeFilter (see also 1.28.3.1.1). For the
class template, the server evaluates the event triggerCondition expression and creates event triggers on all attributes that affect the expression's outcome, as specified in
the previous section. The differences to creating triggers for entry and collection scope as
described above are:
Update triggers on scoped entries are class triggers instead of entry triggers, since no entry trigger on the class template itself shall be created.
Attributes may be defined as static and as internally derived in different subclasses. If this
is detected during trigger creation, it is necessary to create an update trigger on the attribute and create triggers on a source entry from which the attribute is internally derived.
For every source entry that is selected by a derivation rule, a class template must exist
that is used for deriving the attributes and creating the triggers.
For externally derived attributes, a class template for the ImportAdapter of the attributes must exist that controls the subcontracting of the event handling to the external
server. This is further discussed in 1.28.4.3.
Page 179
Our class template approach has the advantage that it allows the definition of events on
classes of entries that are non-structural object classes. The drawback is that the directory
administrator must specify class templates for all object classes for which events with
class scope shall be supported. Since in practice not all object classes will have class
templates associated, the attribute classScopeEvents lists all those object classes for
which class templates are defined. The attribute is held in subschema subentries of the
Dynamic Directory and may be used by clients to inform themselves about the class scope
events supported by a particular Dynamic Directory server.
A class template is held in the Dynamic Directory like a conventional entry to allow management of templates with normal LDAP operations. Like any entry, a class template has
an object class associated with it that is derived by multiple inheritance from all classes
that shall be represented. A special naming convention applies to the name of the class
template's object class. It consists of the character sequence "any" concatenated with the
name of the hierarchically highest object class being represented (being the hierarchically
lowest common superclass of all classes from which it inherits). An example inheritance
tree with some selected OMP class template object classes is shown in Figure 53.
<<abstract>>
Tag
<<abstract>>
FixedTag
<<abstract>
MobileTag
AnyFixedTag
ABSTag
AnyABSTag
RFTag
AnyMobileTag
AnyTag
Figure 53: Example for definition of class template object classes
A class template deviates from other object classes in its ability to have attributes being
defined as static and as derived at the same time. An entry of this object class has two
deviating properties. First, every static attribute has a single value "any" present, irrespective of its syntax. Second, it may have a DN that does not have to be part of any naming
context held by the server (or any other server). This is necessary since some RDN parts
may have the form of <attribute type>=any which does not map to an existing naming context.
Page 180
Candidate entry identification
For events with class scope, additional information may be required in the event definition,
to allow the Dynamic Directory to identify a set of candidate entries from the trigger entry
attribute values. The additional information is required, if the object class specified in the
class scope contains internally or externally derived attributes. In this case, the candidate
entry could be different from the trigger entry, so that the Dynamic Directory has to check
the event condition on all scoped entries, if no further identification is provided.
We defined an operational attribute classCandidateAVA that may be placed in an event
definition and specifies an attribute type for each potential trigger entry object class. The
attribute is used by the Dynamic Directory server to construct an AVA that selects the associated candidate entry. It must be specified for every event definition with class scope
and must cover all object classes containing derived attributes being required for the
evaluation of the event condition. The attribute may have multiple values that are encoded
as specified below.
( dds.1.57 NAME 'classCandidateAVA' EQUALITY caseIgnoreMatch
SYNTAX DirectoryString USAGE directoryOperation )
classCandidateAVA =
candidateEntryAttr "=<" triggerEntryClass ">" triggerEntryAttr
candidateEntryAttr = AttributeDescription ; from RFC2251, attribute type name
triggerEntryAttr = AttributeDescription ; from RFC2251, attribute type name
triggerEntryClass = AttributeValue
; from RFC2251, OCTET STRING
The classCandidateAVA attribute specifies the trigger entry's object class and an attribute type of that class from which the value is taken as value assertion combined with
the attribute type specified for the candidate entry. When the candidate entries must be
selected after an event trigger fired, the Dynamic Directory constructs an equality AVA for
each value present in the trigger entry attribute after the trigger had fired and for each
value that was present in the trigger entry attribute before the trigger had fired. All equality
AVAs are then applied against the Dynamic Directory contents (or current naming context)
to identify the candidate entries on which the event condition must be evaluated. During
trigger creation, the Dynamic Directory checks whether for each monitored object class
serving as source entry in attribute derivation rules a classCandidateAVA is specified in
the event definition entry. If not, the event definition is rejected since otherwise the Dynamic Directory will be unable to identify candidate entries from the contents of the trigger
entries. For every monitored entry, the Dynamic Directory must be able to derive the preevent as well as the post-event values to identify all potential candidate entries from a trigger entry. How this may be realised in a Dynamic Directory implementation will be discussed in 1.34.3.
Without the presented mechanism, the Dynamic Directory would have to check an event
condition of class scope events on all entries belonging to the object class specified in the
event definition, or the applicability of class scope events would have to be restricted to
entries without internally derived attributes. We believe that the additional attribute is tolerable, especially in combination with pre-defined events (see section 1.28.3.1.6), for
which the client does not have to specify the operational attributes.
Page 181
1.28.4.3 Import triggers
If a monitored entry contains externally derived attributes that are relevant for the evaluation of the event's triggerCondition expression, an import trigger is created on the attribute. The purpose of an import trigger is to fire, if the externally derived value changes.
Two principal approaches to this task are conceivable: Trigger pull and trigger push.
Trigger pull is realised by the Dynamic Directory server without additional functionality to
be provided by the external server. The Dynamic Directory regularly interrogates the external server for the actual values of the derived attributes and compares the values
with those obtained at the last interrogation. If there is a deviation, the import trigger
fires, and the event condition evaluation starts as described before.
Trigger push is realised with an extended interaction model between the Dynamic Directory and the external server. During event definition, the Dynamic Directory creates a
monitoring subcontract with the external server that defines in which value changes the
Dynamic Directory is interested. If a specified change occurs, the external server notifies the Dynamic Directory server and sends the actual values of all derived attributes.
This causes the import trigger to fire and invokes the consecutive event processing
steps.
The trigger pull approach has the advantage of imposing fewer requirements on the functionality of the external server, but may impose considerable processing overhead on the
Dynamic Directory server and on the external server, if the polling frequency is high. A low
polling frequency creates less overhead but increases the reaction time to value changes.
The trigger push approach requires more complex functionality from external servers,
which prevent its application with servers that only support retrieval functionality. The advantage of the second approach is its potentially fast reaction time to changing external
values, while minimising the processing overhead for the Dynamic Directory server.
Since the applicability of these approaches depends on the particular application environment (requirements on reaction time, supported functionality of external server), both approaches should be supported by the Dynamic Directory. Wherever supported by the external server, the trigger push approach should be used. The trigger pull should be used
only for simple external servers containing infrequently-changing data that tolerates longer
event reaction times. For each of these approaches, subclasses of the ImportAdapter
object class have been defined that contain the required operational attributes.
1.28.4.3.1 Trigger pull
To employ the trigger pull approach, the object class PullEventImportAdapter has
been defined which must be used to derive subclasses for particular access protocols as
defined in section 1.27.2. If an externally derived attribute is obtained from an Adapter
being a subclass of pullEventImportAdapter, an import trigger employing the pull
approach will be created by the Dynamic Directory server during event definition.
( dds.2.8 NAME 'pullEventImportAdapter'
SUP importAdapter ABSTRACT
MUST ( pollingInterval ) )
Page 182
The mandatory operational attribute pollingInterval specifies the number of seconds
that the Dynamic Directory server shall wait between two external server interrogations.
( dds.1.41 NAME 'pollingTime' EQUALITY numericStringMatch
SYNTAX NumericString SINGLE-VALUE USAGE directoryOperation )
With every retrieval operation, the Dynamic Directory obtains a single external object with
all its properties from which all externally derived attributes are created. The parameters
used for the external interrogation are the same than those supplied to the ImportAdapter entry during event definition. After each interrogation, the retrieved values are
compared with the values obtained during the last interrogation. If a change is detected,
the import trigger fires.
The retrieval request message is defined at trigger creation and reflects the status of the
monitored entries at that time. If one of the monitored entries is modified in a way that affects an update trigger created for that entry, the Dynamic Directory server must check
whether the update also affects other event triggers. The creation procedure of update
triggers inherently avoids inter-trigger dependencies by creating class triggers that do not
depend on actual values of parameter attributes. Import triggers however, reflect the values of parameter attributes and might require being deleted and newly created after an
update trigger has fired.
Another restriction on trigger pull usage is that it is not suited for realising import triggers
for class scope events, since that usually requires monitoring the changes of multiple external objects held by the external server. With a polling-based interaction model this
would require to retrieve with every external server interrogation all external object properties and compare them with the last obtained properties which imposes significant processing effort on the Dynamic Directory server. An event definition with class scope that requires an import trigger on a pullEventImportAdapter is therefore rejected by the
Dynamic Directory.
1.28.4.3.2 Trigger push
To allow the Dynamic Directory to make use of the trigger push approach, an Adapter
entry must be a subclass of the object class PushEventImportAdapter. It may contain
additional protocol-dependent operational attributes that are required for establishing the
monitoring subcontracts between Dynamic Directory and external server.
( dds.2.9 NAME 'pushEventImportAdapter'
SUP importAdapter ABSTRACT )
During import trigger creation, the Dynamic Directory will interact with the external server,
as shown in Figure 54. The Dynamic Directory server sends a notification request message to the external server that identifies the external object that shall be monitored by the
external server. For class scope events, the Dynamic Directory will have to provide a notification request that calls for changes to multiple external objects.
After the notification request has been sent to the external server, the first notification response message is interpreted as confirmation of the request. The external server may
Page 183
optionally send the current contents of all monitored external objects in the first notification
response message to allow the Dynamic Directory to obtain a snapshot of all externally
derived attributes. Without these object values, the Dynamic Directory may have to send
subsequent retrieval requests to obtain the current values of all scoped and monitored entries to be able to compare pre-event and post-event values. The Dynamic Directory administrator should be able to configure whether this initialisation is done by the external
server. If an error is returned after the notification request, the contract could not be established by the external server and the event definition is rejected by the Dynamic Directory.
If no error is returned, the connection between Dynamic Directory server and external
server is kept open to receive further notification response messages upon changes in the
external objects. A monitoring subcontract is terminated by either side by closing the connection.
Client
DDS server
External server
Add(EventDefinition)
NotificationRequest(object identifier)
NotificationResponse
([object identifier, object properties])
AddResponse
Search(Notifications)
NotificationResponse
(object identifier, object properties)
check event
condition
SearchResponse(Notification Entry)
Figure 54: Monitoring subcontract with external server
The Dynamic Directory waits for notifications from the external server. Notifications contain (typically) a single external object with at least the properties that would have been
sent as a result of a retrieval request for the changed external object. This prevents that
the Dynamic Directory must issue a retrieval request for the changed data after it has received a notification. It thereby improves processing performance and ensures operation
consistency, since otherwise the external object could change between the notification
and the subsequent retrieval. The notification message must also contain the identifier of
the external object to associate the external object properties with the external object identifier inside the Dynamic Directory. This is required to re-use the properties received in notifications instead of invoking subsequent retrieval requests.
The trigger push model will probably not be used with external LDAP servers, since that
would imply cascading the Dynamic Directory event handling and the associated processing efforts. In such environments, the application should monitor directly the contents of
the LDAP server. The Dynamic Directory therefore only supports SOAP as external ac-
Page 184
cess protocol for event handling employing trigger push approaches. The object class
SoapPushEventImportAdpater specifies all required operational attributes.
( dds.2.10 NAME 'soapPushEventImportAdapter'
SUP pushEventImportAdapter STRUCTURAL
MUST ( eventXmlPayload $ notify )
MAY ( eventMethodName $ extractIdentifier ) )
The optional attribute eventMethodName has the same properties and syntax as
methodName (cf. 1.27.2.1) and specifies the method that must be called for subscribing to
notifications from the external server. The attribute eventXmlPayload is an extension of
the attribute xmlPayload and specifies the notification request message to be sent to the
external server. It specifies a method call in the same way as the xmlPayload attribute.
The difference is that the attribute may be multi-valued and specifies different versions of
the XML query that depend on which property of the external object shall be monitored by
the external server. Each version of the notification request is encoded as a separate attribute value and is preceded by a list of externally derived attribute names that may be
monitored with the request.
( dds.1.44 NAME 'eventXmlPayload' EQUALITY caseIgnoreMatch
SYNTAX DirectoryString USAGE directoryOperation )
eventXmlPayload = monitoredAttributes ":" xmlString
monitoredAttributes = attrList ; from section 1.26.1.3
xmlString = OCTET STRING
; encoded like xmlPayload, see section 1.27.2.1
Only one value of the attribute is chosen as notification request. Therefore, attribute name
combinations should be specified, too. During import trigger creation, the server will select
that notification request version that covers all attribute types that must be monitored for
the event condition. If not all required attribute types may be monitored by the external
server, the event definition is rejected.
The notify attribute has the same properties and syntax as the attribute import (cf.
1.27.2.1) and specifies which externally derived attributes shall be constructed from a notification message received from the external server. The notify attribute must derive at
least all externally derived attributes that are defined in the import attribute of the same
ImportAdapter. For each notification message received from the external server, the
import trigger fires, and a trigger evaluation is performed as described before. If a notification message contains more than one external object, all received object properties are
used to identify candidate entries. All candidates are evaluated in the same trigger evaluation process, and all LDAP notifications created for this trigger will contain the same
triggerFireId (cf. page 174).
During import trigger creation, parameters in the notification request use the values supplied at trigger creation time. Since an update on one of the monitored entries might
change the parameter conveyed to the ImportAdapter entry, the Dynamic Directory
must check all import triggers after an update trigger fired. If a new import trigger is required, the old trigger must be deleted, and a new trigger must be created to initiate a
monitoring subcontract with the actual parameters.
Page 185
Class scope events
The concepts defined so far are sufficiently powerful to create import triggers for event
definitions using the entry and collection scope. To define events with a class scope, the
class template concept must be extended to cover also ImportAdapter entries. The Dynamic Directory administrator must derive an additional subclass from object class SoapPushEventImportAdpater according to the naming conventions defined in section
1.28.4.2.2, such as:
( x.x.x NAME 'anySoapPushEventImportAdapter'
SUP soapPushEventImportAdapter STRUCTURAL )
All non-operational static attributes of the class template have the reserved value "any",
and all externally derived attributes return the value "any", if externally derived values
shall be obtained. The xmlEventPayload attribute must specify a notification request
that starts a monitoring subcontract on all external objects held by the external server that
are relevant for the class scope event.
Sharing monitoring subcontracts
In the same way in which import triggers may be shared between multiple event definitions, monitoring subcontracts may be shared, too. If the same monitoring subcontract that
was already established by the Dynamic Directory is required by another event definition,
the already existing subcontract will be re-used. Additionally, a single-object monitoring
subcontract may re-use an already existing class scope subcontract that includes the particular object. The Dynamic Directory implementation may perform further optimisations
that deviate from the pure concepts described in this chapter. It may for example keep a
monitoring subcontract longer than the event requires to avoid recurring initialisation
phases or may even establish pro-actively the subcontract at Dynamic Directory server
start-up time.
1.28.5 Directory data consistency
During the event definition phase, the event condition is evaluated for all scoped entries.
For this, their current attribute values are determined by means of a server-internal search
operation on all scoped entries. It is performed as entry-consistent operation like clientinvoked search operations for the scoped entries. This search operation also obtains the
current values of the externally derived attributes in all monitored entries that are needed
during event trigger evaluation as pre-event values.
If an event trigger fires, the event condition must be evaluated on all candidate entries. To
ensure consistency between notifications sent as result of different event definitions, all internally and externally derived attributes should be obtained only once during the evaluation of all event conditions. The event trigger evaluation is treated as a single directory operation that is classified as operation-consistent. This is necessary since otherwise an application might receive multiple notifications that differ in their notification contents, although they were caused by the same event trigger.
Page 186
To achieve this consistency level, it is necessary that an external server sends all properties of a changed external object in a notification response message to avoid subsequent
retrieval requests that might return non-consistent data. Additionally, the notify attribute
must derive all externally derived attributes that are defined in the import attribute of the
ImportAdapter. This allows the Dynamic Directory to use the data values received in a
notification for deriving all externally derived attributes in the ImportAdapter entry. To
realise this behaviour, the externally derived attributes obtained from the notification message must be temporarily stored and re-used during the subsequent condition evaluation.
One approach for realising this in a Dynamic Directory server is presented in chapter 0,
discussing options for Dynamic Directory implementation.
External object identifier extraction
Since the data provided in the notification message from the external server shall be used
to construct all externally derived attribute values as discussed above, an additional optional operational attribute extractIdentifier has been defined for the object class
SoapPushEventImportAdapter. The optional attribute must be specified, if a parameter passed on from a target entry is used to select an external object in retrieval requests.
The attribute has a single value and specifies a filter with a format similar to that of the
import attribute.
( dds.1.46 NAME 'extractIdentifier' EQUALITY caseIgnoreMatch
SYNTAX DirectoryString SINGLE-VALUE USAGE directoryOperation )
extractIdentifier =
"$" index "=" [":p:" prefix ":"] [xmlElementPath] [colsep] [rowsep]
index = numericstring
; from retrievalParameter definition, see 1.27.1
; other terms from section 1.27.2.1
The filter retrieves a value from the notification message and assigns the value to one parameter variable passed on to the Adapter entry from its target entries. It must be assigned to that parameter that is used as identifier for the external object. During import
trigger creation, the Dynamic Directory server stores with the import trigger the attribute
type of the target entry that provides the parameter value. When a notification message is
received from the external server, the Dynamic Directory obtains a value from the extractIdentifier filter. That value is needed by our implementation of the Dynamic Directory server for evaluating the externally derived attributes. The value is used to retrieve
the data pre-fetched from the notification sent by the external server (cf. section 1.34.3.1).
1.28.6 Operational model
The operational model of Dynamic Directory event handling covers two aspects: The interaction between client and Dynamic Directory including the definition of events and the
evaluation of firing event triggers including the interaction with external servers that monitor externally derived attributes.
Page 187
1.28.6.1 Event handling services offered to clients
The interaction between the Dynamic Directory and its clients for event handling is performed with conventional LDAP add, modify, delete, and search operations with the event
definition entry being the target entry or search base object.
client adds
entry
object class =
eventDefinition ? -
continue
normal add
+
operational attributes
ok ?
+
class scope ?
-
for each entry done
in scope
+
class template
existing ?
+
create triggers
-
error ?
+
create triggers
- error ?
+
for each entry done
in scope
determine
current value of
externally derived
attributes
send add
response
(success)
send add
response
(error)
done
Figure 55: Flow chart of event definition processing
If the client adds an entry that is of object class EventDefinition, the Dynamic Directory must initiate the event definition phase depicted in Figure 55. If the operational attribute values provided by the client do not adhere with the syntactic and semantic requirements formulated in this chapter, the LDAP add operation is rejected by the Dynamic Directory. An eventDefinitionError is returned to the client with an error message de-
Page 188
tailing the definition error. If the event is defined correctly, the Dynamic Directory evaluates
the event condition for all scoped entries or for the class templates, depending on the
event scope. This process creates all event triggers as described in 1.28.4.2 and establishes the required monitoring subcontracts as described in 1.28.4.3. Additionally, the current values of all externally derived attributes in the monitored entries are obtained by the
Dynamic Directory if they are not already available. If an error occurs during trigger creation, the LDAP add operation is rejected with an eventTriggerError. Errors that occur
in interaction with the external servers are reported with error messages defined for handling externally derived attributes. If the event definition phase is completed successfully,
an LDAP success result is sent to the client. If the client receives such a success message, it may expect that the event is being monitored by the Dynamic Directory.
Upon modifications to the event definition entry, the Dynamic Directory must check
whether modification is permitted concerning the access privileges of the client and concerning the semantics of the modification. The only allowed modification for existing
eventDefinition entries is changing the value of the eventStatus attribute to cancelled. In this case, the event monitoring phase is finished, all outstanding client subscriptions to this event are closed, the event triggers are deleted, and the eventStatus
is eventually set to stopped by the Dynamic Directory. All other modification requests are
rejected by the Dynamic Directory server with an eventDefinitionError and a textual
error message.
Deletions of the EventDefinition entry - if allowed by the client's access privileges are handled by the Dynamic Directory similar to setting the event status to cancelled.
The only difference is that the eventDefintion entry is eventually deleted instead of
merely setting the eventStatus to stopped. If the event has already the status
stopped when the client sends the LDAP delete operation, the operation needs no further processing by the Dynamic Directory.
If the client issues an LDAP search operation with an EventDefintion entry as base
object, the Dynamic Directory first checks the scope of the search to decide how to process the request:
If the scope is baseObject, the event definition entry is returned to the client in a conventional search operation.
If the scope is singleLevel, the Dynamic Directory searches below the event definition
and returns all entries that match the provided search filter. This operation will be used
by clients to retrieve all existing notifications of an event definition.
If the scope is wholeSubtree, the Dynamic Directory first searches for all existing entries
below the event definition entry and returns all entries that match the provided search
filter to the client. The further processing depends on the status of the event. If the
status is not active, the search operation is completed. If the status is active, the
Dynamic Directory will not complete the search operation and will not close the connection over which the search was received. If during the event monitoring phase further
notification entries are created, these are sent to the client as result of the outstanding
search operation. During this second phase, the search filter provided by the client is
not applied to the entries. Instead, all newly created notifications are sent.
Page 189
The different handling of the search filter in the two phases allows clients either to reestablish subscriptions to events they had subscribed earlier, or to subscribe to events
from other clients that exist already. With the filter they can select which existing notifications are sent to the client before the normal subscription to all new notifications is
established. Useful filters will typically contain value assertions that compare notificationId or notificationTime values with client-provided limits.
The search operation is completed with a SearchResultDone message when the event
monitoring phase finishes. If the client abandons a standing search operation of a subscribed event, the subscription is terminated by the Dynamic Directory. No further search
result is sent to the client as mandated by [RFC2251].
Access control
The event handling model we propose for Dynamic Directory Services is compatible to the
current proposals for LDAP access control [Stokes00]. Event handling requires the ability to
grant or deny these permissions:
Defining an event: Parent entry must have add permission for the client attempting to define an event.
Detecting events from other clients: Event definition entry must have browse permission,
entry attributes must have search and read permission for the client attempting to detect the event.
Subscribing for notifications: Subtree below event definition must have browse permission for the client attempting to subscribe to the event.
Modifying (i.e. cancelling) an event: eventStatus attribute must have write permission
for the client attempting to modify the event status.
Once the access control standardisation for LDAP matures, it must be integrated into the
Dynamic Directory server implementation described in chapter 0. This should be possible
without requiring modifications to the LDAP extensions we developed.
1.28.6.2 Event monitoring
The operational model for event monitoring covers monitoring of update triggers, management of monitoring subcontracts with external servers, and evaluating the event conditions for firing event triggers, see also Figure 56.
Update triggers
If a client modifies or deletes an entry held by the Dynamic Directory server, the server
must check whether there is an update trigger that is affected by the modification. It may
find entry triggers that identify the modified entry and specify a modified attribute as being
monitored. It may also find class triggers that identify an object class value present in the
modified entry, and specify a modified attribute as being monitored. For every update trigger that is affected by the performed operation, the Dynamic Directory must process all
event definitions that are interested in that trigger.
Page 190
For every event definition, the event triggerCondition is evaluated on every candidate entry. For entry and collection scope, the candidate entries are the scoped entries.
For class scope events, the candidate entry must be identified from attributes in the trigger
entry as defined in section 1.28.4.2.2. If an event fires, i.e. its trigger condition evaluates to
true, the optional action condition is evaluated and, if its result is true, the event action
is processed. The action processing consists of creating the notification entry, performing
the optionally specified LDAP operations, and sending the notification entry to all subscribed clients.
trigger
fires
for each event done
interested in trigger
done
identify
candidate entries
done
for each
candidate entry
-
trigger condition
fires ?
+
action condition
fires ?
+
create
notification entry
perform
LDAP operations
done
for each
subscribed client
send notification
entry
Figure 56: Flow chart of event trigger evaluation processing
Page 191
If an entry is added to the Dynamic Directory, the server must check whether the entry affects a class trigger. If this is the case, all event definitions interested in that trigger are
processed, as defined above. If an update trigger fires after any LDAP operation, the Dynamic Directory must check all interested event definitions whether the triggers must be
adjusted according to the modified entry. This may be done in parallel with the evaluation
of the event condition in the same way as during initial creation of event triggers (cf.
1.28.4.2). The additional task is to remove those triggers that are no longer needed by any
event definition.
Import triggers
During event monitoring, the Dynamic Directory either polls external servers for changes in
their object properties or listens for incoming notification messages from the external servers as described in section 1.28.4.3. If an import trigger fires, the Dynamic Directory must
process all event definitions that are interested in that trigger. For every event definition,
the Dynamic Directory must determine the candidate entries from the event scope or - in
case of class scope - from the externally derived attributes obtained from the external notification message. For every candidate entry, its current values are obtained and the event
condition is evaluated in the same way as for update triggers. If the candidate entry that is
identified from the data provided by the external server does not exist inside the Dynamic
Directory, an event that has the option optimisticPartialCandidate set to true
may still fire.
If an LDAP modification operation affects an existing import trigger, the Dynamic Directory
must create a new import trigger and delete the old one - including replacing the existing
monitoring subcontract by a new one.
Event monitoring errors
Non-fatal errors that occur during condition evaluation or action processing are added to
the eventError attribute in the EventDefintion entry. If an event scope has become
empty because all scoped entries have been deleted by clients, the event monitoring
phase is finished, and the event status is set to stopped. A fatal error that leads to the
termination of an event monitoring phase is reported to all subscribed clients with an
eventMonitoringError in the search response message that terminates the search
operation.
Monitoring limits
The Dynamic Directory must monitor the eventLifetime and notificationLimit
values and must terminate the event monitoring phase, if one of these limits is reached.
1.28.7 OMP example
The following example combines the examples from section 1.26.4 and 1.27.5 and illustrates how an event definition for OMP-related events may be specified. These are the
Dynamic Directory OMP entries shown before:
Page 192
objectClass = HookedObject
objectClass = HookedPosition
objectClass = Person
objectId = 533
// RDN
homeMMd = ac
attachedTag = 2
cachetime = 10
reference =
managingMMD=(&(objectclass=ABSTag)(objectId=$attachedTag)):managingMMD()
reference =
position=(&(objectclass=ABSTag)(objectId=$attachedTag)):position()
reference =
lastLocating=(&(objectclass=ABSTag)(objectId=$attachedTag)):lastLocating()
objectClass = ABSTag
objectId = 2
// RDN
roamingArea = ABS0
position = g116
// internally derived attribute
managingMMD = ac
homeMMD = ac
reference =
currentABSSensor=(&(objectclass=ABSAdapter)(roamingAreaId=$roamingArea)):
currentABSsensor(objectId)
reference =
lastLocating=(&(objectclass=ABSAdapter)(roamingAreaId=$roamingArea)):
lastLocating(objectId)
This Adapter entry allows the Dynamic Directory to initiate monitoring subcontracts with
an external server (the attributes and attribute values that are added or modified compared with those of section 1.27.5 are written in italics):
objectClass = adapter
objectClass = importAdapter
objectClass = pushEventImportAdapter
objectClass = soapPushEventImportAdapter
objectClass = ABSAdapter
// allows externally derived attributes
cn = ABS0
// RDN
roamingAreaId = ABS0
host = micon1
mPost = true
endpoint = /absbadgelocator
methodName = LocateTag
xmlpayload = <LocateTag><tagId>$1</tagId></LocateTag> // $1 replaced with 2
eventMethodName = SubscribeTagLocation
eventXmlPayload =
currentABSsensor:
<SubscribeTagLocation><tagId>$1</tagId></SubscribeTagLocation>
import = currentABSSensor=Sighting/SensorId // assign SensorId to attribute
import = lastLocating=Sighting/LastSighting // assign LastSighting to attr.
notify = currentABSSensor=Sighting/SensorId // assign SensorId to attribute
notify = lastLocating=Sighting/LastSighting // assign LastSighting to attr.
notify = objectId=Sighting/TagId
// for candidate identification
extractIdentifier = $1=Sighting/TagId
// assign TagId value to $1 para.
A simple event definition that monitors the current position of the person with "objectId=533" - being a collection scope with a single scoped entry - may look like this (only attributes provided by client shown):
objectClass = eventDefinition
eventDefinitionId = 1
// RDN
Page 193
scopeFilter = objectId=533
// object with objectId=533 shall be monitored
triggerConditions = position^g116 // fires if object enters or leaves g116
notificationLifetime = 3600 // notification entries shall exist for 1 hour
eventLifetime = 28800
// event shall be monitored for 8 hours
eventStatus = active
// start monitoring after event definition
noRDNTrigger = true
// do not create triggers on RDN attributes
notificationContent = objectId,position // provide these attr. vals in notif.
includeOldValues = position // provide pre-event position value in notif.
The server creates additional operational attributes, so that a client that retrieves the
eventDefintion entry will receive for example this entry:
objectClass = eventDefinition
eventDefinitionId = 1
scopeFilter = objectId=533
triggerConditions = position^g116
notificationLifetime = 3600
eventLifetime = 28800
eventStatus = active
noRDNTrigger = true
notificationContent = objectId,position
includeOldValues = position
eventStartTime = 20000523104532
// started on May 23, 2000, 10:45, 23 sec.
createdEventTrigger =
udate:attachedTag:objectId=533,objects=residents,roamingareaId=local,
mmdId=ac,mmdId=philips
createdEventTrigger =
update:roamingArea:objectId=2,objects=residents,roamingareaId=ABS,
roamingareaId=local,mmdId=ac,mmdId=philips
createdEventTrigger =
import:currentABSSensor:cn=ABS0,roamingAreaId=ABS,roamingareaId=local,
mmdId=ac,mmdId=philips
Without the noRDNTrigger option, one additional event trigger would have been created:
createdEventTrigger = update:objectId:<ABSTag>
The trigger is an update class trigger on all entries of object class ABSTag. It would be
created since objectId is used in the internal attribute derivation rule of the HookedObject entry to select an ABSTag. If an entry of class ABSTag would change its objectId
to the specified value, it would affect the internal attribute derivation and thereby the event
condition. Since objectId is used for naming and therefore will likely not change during
the existence of the entry, the trigger may favourably be suppressed without loosing functionality.
This is a notification created by this event when the real-world person leaves the area
G116 and enters another area:
objectClass = eventNotification
objectClass = softEntry // entry will be discarded after entryLifetime expired
objectClass = extensibleObject // allows all attribute types to be present
notificationId = 5
notificationTime = 20000523110259 // notif. created at 11:02 and 59 seconds
notificationReason = external attribute value changed // from position. syst.
triggerFireId = 17 // identifier of trigger fire, links notifications
triggerEntry =
cn=ABS0,roamingAreaId=ABS,roamingareaid=local,mmdId=ac,mmdId=philips
candidateEntry =
objectId=533,objects=residents,roamingareaid=local,mmdId=ac,mmdId=philips
Page 194
objectId = 533
position = g120
-position = g116
entryLifetime = 2365
//
//
//
//
value requested; objectId of candidate entry
value requested; object entered area g120
value requested; old position of object was g116
remaining lifetime of entry in sec.
1.29 New matching rules
The Open Mobility Platform requirements developed in chapter 0 mandate the development of three new matching rule types. Spatial matching handles spatial real-world information, nearest matching allows searching for entries that match a filter optimally, and
configurable matching allows defining application-specific metrics for evaluating matching
rules. These new matching rule types are introduced in the following. They are not restricted to be used for mobile applications but are of a generic nature as are all other new
Dynamic Directory features.
1.29.1 Spatial matching
To represent spatial information about real-world objects in the Dynamic Directory, a number of new attribute syntaxes for representing three-dimensional shapes has been defined. Additionally, to search for spatial information and to detect spatial relationships between multiple shapes, new matching rules for evaluating shapes concerning their spatial
containment have been defined.
1.29.1.1 Attribute syntaxes
The Open Mobility Platform requirements identified two geometric shapes as being mandatory: Rectangular solids and points. We assumed lines connecting two points to be additionally useful for directory applications, they are therefore also supported by the Dynamic Directory. Two-dimensional shapes are expressible with three-dimensional shape
attribute syntaxes by omitting the information representing the third dimension.
These are the new attribute syntaxes for three-dimensional shapes in a Cartesian coordinate system:
D3Point:
( dds.3.1 DESC 'D3Point' )
Values in this syntax represent a point defined by three positive coordinate values and are
encoded according to the following BNF:
point
xval
yval
zval
val
=
=
=
=
=
xval yval [zval]
val "x"
val "y"
val "z"
numericstring
; (see Appendix C)
A two-dimensional point may be represented by skipping the optional z-value component.
Page 195
D3RectangularSolid:
( dds.3.2 DESC 'D3RectangularSolid' )
Values in this syntax represent a rectangular solid defined by two D3Point values and are
encoded according to the following BNF:
rectangularsolid = point point
The two points represent the diagonally opposite edge points of the rectangular solid. A
two-dimensional rectangle may be represented by skipping the optional z-value component.
D3Line:
( dds.3.3 DESC 'D3Line' )
Values in this syntax represent a line defined by two D3Point values and are encoded according to the following BNF:
line = point point
The two points represent the end points of the line. A two-dimensional line may be represented by skipping the optional z-value component.
1.29.1.2 New matching rules containsMatch and containedMatch
The Open Mobility Platform specification requires new matching rules to evaluate whether
a point is contained in a rectangular solid and vice versa. We defined for the Dynamic Directory the containsMatch and containedMatch matching rules serving this purpose.
For the attribute syntax D3Line, these matching rules are applicable, too, and evaluate
whether a line contains a point or whether a line is contained in a rectangular solid.
The new matching rules are defined as follows:
matchingRule: ( dds.4.1.1 NAME 'containsMatch' SYNTAX D3Point )
matchingRule: ( dds.4.1.2 NAME 'containedMatch' SYNTAX D3RectangularSolid )
The matching rules assign object identifiers (OID) to the rules (see also Appendix D) and
define the syntax of the assertion value to which the entry's attributes shall be compared.
The attribute syntax combinations being allowed for containsMatch and containedMatch are summarised in Table 6.
Assertion value syntax in matching rule
Entry's attribute syntax
3DPoint
3DLine
3DRectangularSolid
3DPoint
equality
-
containedMatch
3DLine
containsMatch
equality
containedMatch
3DRectangularSolid
containsMatch
-
equality
Table 6: Allowed attribute syntax combinations for containment matching rules
Page 196
The new matching rules may be invoked by directory clients or in internal attribute derivation rules using an extensible match filter in an LDAP search filter. The filter type must be
of the extensibleMatch choice, the matchingRule field must be "containsMatch"
or "containedMatch", and the type field must indicate the attribute type that shall be
compared to the value.
1.29.1.3 Operational model
For each allowed attribute syntax combination, the matching rule evaluation algorithm
must be defined.
A match between a value of D3RectangularSolid syntax and a value encoded with
D3Point syntax is evaluated in the following way:
The point (x,y,z) is contained in the rectangular defined by the two points (x1,y1,z1) and
(x2,y2,z2) if the following is true (if z-values are missing, third line must be omitted):
( x2>=x1 and x>=x1 and x<=x2 ) or ( x2<x1 and x<=x1 and x>=x2 ) and
( y2>=y1 and y>=y1 and y<=y2 ) or ( y2<y1 and y<=y1 and y>=y2 ) and
( z2>=z1 and z>=z1 and z<=z2 ) or ( z2<z1 and z<=z1 and z>=z2 )
match between a value of D3Line syntax and a value encoded with
D3RectangularSolid syntax is evaluated similar to the rule stated above. It evaluates the containment of the two end points of the line within the rectangular solid.
A match between an attribute of D3Line syntax and an assertion value encoded with
D3Point syntax is evaluated in the following way:
A
The point (x,y,z) is located on the line defined by the two points (x1,y1,z1) and
(x2,y2,z2) if the following condition is fulfilled:
( x2>=x1 and x>=x1 and x<=x2 ) or ( x2<x1 and x<=x1 and x>=x2 ) and
x - x1
y - y1
z - z1
------- = ------- = ------x2 - x1
y2 - y1
z2 - z1
(if z-values are missing the third term must be omitted)
If the specified condition is fulfilled, the matching rule evaluates to true, otherwise to
false. If two-dimensional and three-dimensional attribute and assertion values are compared to each other, the matching rule evaluates to undefined.
1.29.1.4 OMP example
To specify which attribute types may be used with the newly defined containsMatch
matching rule, the OMP schema must provide a matchingRuleUse description [RFC2252]
listing the applicable attribute types. In the OMP case, the attribute RFRectangularSolid makes use of syntax D3RectangularSolid.
matchingRuleUse: ( dds.4.1.1 APPLIES RFRectangularSolid ) // containsMatch MR
// OID
A client or a derivation rule may now specify a search filter containing an extensible match
filter with the containsMatch matching rule specified (identified by its OID dds.4.1.1):
(&(objectclass=spatialarea)(RFRectangularSolid:dds.4.1.1:15x5y5z))
Page 197
The presented filter returns the entry of that spatial area whose three-dimensional shape being defined by one or more values of its attribute RFRectangularSolid - contains the
point "15x5y5z". An example entry matching that search filter is the OMP SpatialArea
entry "areaId=g115" introduced in section 1.22.4.2.
objectClass = SpatialArea
objectClass = BasicArea
objectClass = RRCoordinatesRange
objectClass = OfficeRoom
areaId = g115
RFRectangularSolid = 10x0y0z30x10y10z // value syntax D3RectangularSolid
RFRectangularSolid = 20x10y0z30x20y10z // value syntax D3RectangularSolid
1.29.2 Nearest matching
The OMP requirements analysis showed that there is demand for a new type of matching
rule to be supported by the Dynamic Directory. Clients wish to not only retrieve all directory entries that fulfil specified search criteria, they also demand to retrieve a number of
entries that best fulfil a specified criterion, sorted according to their ranking. For this purpose, we developed a new matching rule type called nearestMatch that may be used by
clients in LDAP search filters to specify the assertion value which shall be matched best
by the returned entries.
Conventional LDAP servers must evaluate filters according to the three-valued logic of
X.511 [X.511], allowing a filter to evaluate to true, false, or undefined. An entry is returned to the client, if the search filter evaluates to true. The new nearestMatch matching rule evaluates to a numeric value, indicating the relative distance of a value to the assertion value provided by the client. This numeric value is then used by a Dynamic Directory server to sort entries before returning the best matching entries to the client.
There is a proposal for an extension to LDAP supporting server-side sorting (SSS)
[Herron99], see also section 1.18. Our nearestMatch provides more comprehensive functionality than the SSS proposal. The nearestMatch uses an attribute type and an assertion value as sorting criterion, whereas SSS only specifies a type but no value. The nearestMatch evaluation therefore is able to sort the directory entries according to their value
distance to the specified assertion value. This allows clients to retrieve an entry that does
not exactly match a search filter but that comes closest to the specified assertion value
provided by the client.
1.29.2.1 New matching rules
The new matching rule type shall be applicable to specific OMP attributes such as position as well as to commonly used attributes representing string and numeric values.
Since the syntax of the assertion value and the matching algorithms differ for these attributes, separate matching rules must be defined for the different attribute types.
Page 198
For the Dynamic Directory Services we defined the following nearestMatch matching
rules, allowing assertion values that represent numbers, strings, three-dimensional points,
or OMP positions to be specified by the clients and in internal attribute derivation rules.
matchingRule:
matchingRule:
matchingRule:
matchingRule:
(
(
(
(
dds.4.2.1
dds.4.2.2
dds.4.2.3
dds.4.2.4
NAME
NAME
NAME
NAME
'numericNearestMatch' SYNTAX NumericString
'd3NearestMatch' SYNTAX D3Point
'positionNearestMatch' SYNTAX DirectoryString
'stringNearestMatch' SYNTAX DirectoryString
Every directory schema that allows the use of one of the nearestMatch matching rules
through the LDAP extensible filter mechanism must specify a set of matchingRuleUse
specifications. They define to which attribute types the matching rules are applicable, see
an example in section 1.29.1.4. Two reserved values - "min" and "max" - have been defined for the assertion value allowing clients to formulate matches with minimum and
maximum criteria. They may be applied to numericNearestMatch, d3NearestMatch,
and to positionNearestMatch matching rules.
1.29.2.2 Directory data consistency
Directory operations that must evaluate a nearestMatch filter item are processed by the
Dynamic Directory server using the data consistency level "operation-consistent". The
consistency level requested by the client for this search operation is ignored by the Dynamic Directory server. This consistency level is necessary because a valid ranking between entries may only be evaluated, if their values are consistent to each other.
1.29.2.3 Operational model
The operational model for a search filter containing one or more nearestMatch filters is
an extension to the conventional search filter processing model and is depicted in Figure
57. The search operation is divided into three phases: During the first search operation
phase, the search filter is applied to all entries to identify which entries pass the search filter and to evaluate the numeric outcomes of the nearestMatch filters. During this first
phase, no entries are returned to the client. In the second search operation phase, all entries that passed the first phase are sorted according to their nearestMatch-ranking. If a
search filter contains more than one nearestMatch filter item, the order in which the
items are specified in the search filter determines the priorities between them during sorting. The entries are first sorted according to the first nearestMatch filter item. Those entries which have equal ranking for this criterion are then sorted according to the second
nearestMatch filter item, and so forth. In the third operation phase, that number of entries that the client requested to be returned are sent to the client, starting with the best
matching entry first.
The processing of a search filter for a particular entry has also been extended for nearestMatch filter items. In a first filter pass, all conventional search filter items are evaluated for the entry. The nearestMatch filter items may optionally be evaluated concerning
the presence of the identified attribute type in that entry. Only if the attribute specified as
nearest criterion is present in the entry, will it be considered for further evaluation. During
this first pass, all internally and externally derived attribute values required for the search
Page 199
operation are obtained. If the entry matches the search filter during the first pass, the second pass is performed on it. During this evaluation, only the nearestMatch filter items
are evaluated and their numerical results are associated with the entry for later sorting.
This two-phase processing prevents that the potentially calculation-intensive (for nearestPositonMatch) nearest match processing is performed on entries that do not match
the conventional search filter items. If during the second pass of the rule evaluation the
server detects that it cannot process the rule for this value pair, the rule evaluates to undefined, and the entry is not further considered to be returned to the client.
evaluate
search filter
test filter
get candidates
from attr index
obtain derived
attributes in entry
done
for each
search candidate
test non-nearest
match filter items
nearest
match ?
test filter
-
+
-
-
return false
+
evaluates
to true ?
sort entries in
sort_list
nearest
match ?
+
+
evaluates
to true ?
for each entry
in sort_list
nearest
match ?
done
send
search
result (entry)
send
search
result (entry)
requested number
of entries sent ?
-
requested number
of entries sent ?
-
+
-
+
evaluate nearest
match result
add entry with
result to sort_list
return true
+
send
search
result (done)
done
Figure 57: Flow chart of nearestMatch search filter processing
Page 200
1.29.2.4 Filter evaluation
A nearestMatch filter must calculate a numeric equivalence of the distance between an
entry's attribute values and the assertion value provided by the client.
Evaluation of numericNearestMatch
This matching rule accepts positive numeric values as assertion value and supports "min"
and "max" values. The rule can be applied to any attribute having a numeric string or integer syntax. The filter evaluation is simple: It just has to calculate the absolute numeric difference between two numeric values or to take the attribute value in case of minimum or
maximum matching.
Evaluation of d3NearestMatch
This matching rule accepts three-dimensional points as assertion value. The rule can be
applied to attributes representing three-dimensional points, lines, and rectangular solids.
The numeric distance can be calculated using simple analytic geometry in a Cartesian coordinate system. The possible combinations of attribute syntax and assertion value provided by the matching rule and their evaluation by the Dynamic Directory is defined in Table 7.
Assertion value syntax in matching rule
Entry's attribute syntax
3DPoint
min
max
3DPoint
shortest distance
shortest distance to
(0,0,0)
largest distance to
(0,0,0)
3DLine
shortest distance
between point and line
shortest line
longest line
3DRectangularSolid
shortest distance between point and rectangular solid
smallest volume
largest volume
Table 7: Evaluation of d3NearestMatch for supported attribute syntax combinations
Evaluation of positionNearestMatch
The realisation of positionNearestMatch as part of a generic Dynamic Directory Service introduces an additional challenge. The matching rule must be capable of calculating
the spatial distance between real-world areas. This function can, of course, not be implemented as generic function, since the calculation results depend on the particular environment for which the areas are specified.
In general, the following alternative approaches can be employed to solve this problem.
They differ mainly in the aspects where the matching rule logic is allocated and where the
area configuration data is stored, both having impact on the performance and manageability of a Dynamic Directory server.
1. Dedicated matching rule logic (including area configuration data) as part of the DDS
code.
Page 201
2. Dedicated matching rule logic (including area configuration data) as external service.
3. Generic matching rule as logic part of DDS server, area configuration data from external service.
4. Dedicated matching rule logic (including area configuration data) as interpreted code,
such as Java byte code, stored in the DDS directory or configuration database, interpreter part of DDS code or external process.
5. Generic matching rule logic as part of DDS server, area configuration data stored as
part of DDS configuration data.
6. Generic matching rule logic as part of DDS server, area configuration data stored as
part of DDS directory database.
Solution 1) has the disadvantage that for each installation of the DDS server, its executable code must be modified in order to adapt the server to the area environment. Furthermore, if the area configuration changes, the DDS software must be changed, too, complicating system administration. Solution 2) limits these disadvantages to the code/data of
the external server but requires invocations of external servers for each matching rule
evaluation, e.g. using the SOAP protocol approach discussed in 1.27.2.1. If an entry has
multiple attribute values, multiple invocations are required during rule evaluation, increasing processing effort and operation round-trip time. Solution 3) has the same disadvantages as solution 2). Solution 4) is challenging with respect to the question of how the
DDS process can execute the interpreted code, i.e. how the interpreter code can be called
from the DDS code with satisfactory performance.
Solution 5) avoids the overhead of external server communications and the necessity to
change the code of the DDS server. However, all these five solutions have the common
disadvantage that the area configuration data is represented with data that is not visible in
the DIT and can therefore not be managed with directory protocols.
Solution 6) avoids all disadvantages mentioned before. It may employ generic matching
rule logic as part of the DDS server code and at the same time allows to modify the area
configuration data (i.e. the rule calculation results) using directory access protocols and
management mechanisms. The challenge here lies in a representation of the data required by the matching rule as directory operational information, e.g. placing it in subentries.
As a result of these considerations we decided to define a generic, configurable matching
rule mechanism that allows the realisation of the last approach for nearestPositionMatch but is also able to realise other configurable matching rules. This is described in
detail in the following section. The concept of configurable matching adds a further advantage to solution 6). It allows the application to select different configurations of the positionNearestMatch matching rule depending on the application context of the search
request. This allows extremely flexible applications of the Dynamic Directory Services, because the same value pair may evaluate to different matching results depending on the
application context. This allows an application, for example, to limit the scope for the
nearest position evaluation to position values within the same building or to include all position values managed by an MMD.
Page 202
Evaluation of stringNearestMatch
So far, we did not specify how nearestMatch filters on string values are to be evaluated.
We only specified the placeholders to add this functionality in the future, to make sure that
our Dynamic Directory information model is flexible enough to include such functionality.
1.29.3 Configurable matching
Configurable matching is a significant improvement to the extensible match concept of
LDAP and X.500. Extensible matching allows clients to invoke non-standardised matching
rules in search operations. The matching rule itself, however, is rigidly implemented in the
directory server; its behaviour cannot be customised by directory operators or application
developers. Configurable matching allows directory clients to set up a decision matrix that
specifies how pairs of values should be evaluated during matching rule processing. Its application is therefore limited to attributes with a limited - and known in advance - set of values.
1.29.3.1 Information model
For each configurable matching rule to be supported by a Dynamic Directory server, a
subentry of object class MatchingRuleSubentry must be created. The object class is
defined as follows (see section 1.31.1 for definition of object class Subentry):
( dds.2.11 NAME 'matchingRuleSubentry'
SUP subentry STRUCTURAL
MUST ( configuredMatchOID $ nearestMatch $ evaluationMatrix )
MAY description )
configuredMatchOID has a single OID syntax value [RFC2252] that contains a dotteddecimal string identifying uniquely the configurable matching rule within a particular Dynamic Directory server.
nearestMatch contains a single Boolean value that identifies whether the matching
rule evaluates to true and false or whether it evaluates to a numeric value for realising nearestMatch functionality.
evaluationMatrix has one or more values that contain the configuration knowledge of
the matching rule in form of a decision or value matrix, depending on the nearestMatch value.
description may optionally be present for use by directory clients to inform themselves
about the purpose of the matching rule.
Except description, all attributes are classified as operational attributes. The attribute
evaluationMatrix takes values encoded to the following syntax specifying the configuration knowledge to be used by the server during rule processing.
evaluationMatrix = assertionValue ":" 1*("/" candidateValue "=" matchResult)
assertionValue = AttributeValue
;from RFC2251, OCTET STRING
candidateValue = AttributeValue
;from RFC2251, OCTET STRING
matchResult = "t" / "f" / "u" / numericvalue ; true, false, undefined, value
numericvalue = numericstring
; decision value is integer >= 0
Page 203
Each evaluationMatrix attribute value specifies one row of the decision matrix. Each
row contains an assertion value and a list of candidate value/matching rule result pairs.
The result may be true, false, undefined, or a numeric value.
A configuredMatch matching rule is identified by directory clients in an extensible
match search filter with the matching rule object identifier specified in the configuredMatchOID attribute. A directory client must inform itself about the matching rules that are
configured in a Dynamic Directory server to get to know the matching rule object identifiers
supported by the server. For this purpose, the root DSE of the server contains an attribute
configuredMatchingRule whose values contain the DNs of all MatchingRuleSubentry subentries that are known to the Dynamic Directory server.
1.29.3.2 Operational model
When an extensible search is issued by the client containing a configuredMatch
matching rule object identifier, the server selects the decision matrix to be used from the
configuredMatchOID attribute values. If there is no decision matrix row defined for the
provided assertion value, the server can evaluate the rule immediately as undefined for
the inspected entry. If a row is present, the entry's attribute value is looked up in the matrix
row. If it is found, the associated value provides the matching rule result. If the value is not
found, the rule evaluates to undefined. If there is no decision matrix with the specified
configuredMatchOID found by the server, it returns an inappropriateMatching error [RFC2251] to the client.
As an implementation option, all MatchingRuleSubentry subentries may be retrieved
from the directory database upon server start-up to improve the matching rule evaluation
performance.
1.29.3.3 OMP example
This is an example of a matchingRuleSubentry subentry of a configured nearestMatch matching rule for a specific OMP installation. It contains the numeric distances between real-world areas that are used during matching rule evaluation to determine which
area is nearest to a given position value.
objectClass = subentry
objectClass = matchingRuleSubentry
commonName = nearestPositionMatchMatrix
configuredMatchOID = dds.4.3.1
nearestMatch = true
description = matching rule for finding nearest positions at Philips Aachen
evaluationMatrix = g113:/g111=5/g112=5/g113=0/g114=3/g115=5/g116=3
……
evaluationMatrix = g116:/g111=10/g112=5/g113=3/g114=5/g115=8/g116=0
……
If a client or an internal attribute derivation rule formulates a configured nearestMatch
search filter, such as
(&(objectClass=printer)(position: dds.4.3.1:g116))
Page 204
the Dynamic Directory server will determine from the specified matching rule object identifier that it has to use the matchingRuleSubentry shown above for evaluating the
search filter. First, it will determine all candidate printer entries, determine its position
value for each entry, evaluate the value distance from the criterion value (g116) by means
of the matrix, and later sort the entries. Thereafter, the number of entries requested in the
search request is returned to the client or used as source entries for internal attribute derivation.
1.30 Exported attributes
The purpose of exported attributes is to synchronise part of the information held in the Dynamic Directory with external servers. When entries containing exported attributes are
added, modified, or deleted, the modifications are performed on the external replica, too. If
the external modification fails, so does the internal directory operation, and the client is notified with an LDAP error message. This is different from conventional X.500 [ X.525] and
LDAP directory replication mechanisms [Merrels00], [Stokes00a], which are asynchronous. In
X.500 and LDAP, replication is called shadowing. The directory operation is first performed
on a master replica in one directory server, and the effects of the operation are later forwarded to all slave replicas held by other directory servers.
For the Dynamic Directory Services, we developed a synchronous replication mechanism
that allows tight synchronisation of partial entries with objects held in an external server. It
is based on exchanging a description of the changes that were applied to the exported attributes to an external server that must acknowledge the changes for a successful completion of the LDAP operation. If the external server returns an error or is not available, the
internal LDAP operation fails, too. No changes to the internal entry will be performed that
are not reflected in the external replica.
So far, we restrict synchronisation of attributes to one external server per entry to limit the
complexity of the synchronisation procedure. From the information model viewpoint, support of multiple external servers is straightforward. However, a two-phase commit protocol
would have to be realised to ensure that the overall transaction fails, if one of the external
servers rejects the modification or fails during the update.
1.30.1 Information model
We designed the information model for exported attributes similar to that of externally derived attributes. An operational attribute export must be present in all entries from which
selected attributes shall be replicated to external servers. The export attribute specifies
the attribute types to be exported from that entry and identifies an ExportAdapter entry,
which specifies the interaction with the external server. The export attribute is collective
and may have a single value only.
( dds.1.54 NAME 'export' EQUALITY caseIgnoreMatch
SYNTAX DirectoryString
Page 205
SINGLE-VALUE COLLECTIVE USAGE directoryOperation )
exportRule = exportedAttributes "=" selectionRule ":" "(" parameterList ")"
exportedAttributes = attrList ; attrList from section 1.26.1.3
; selectionRule and parameterList from 1.26.1.3
The selectionRule expression has the same syntax as the one defined for internally
derived attributes and selects one ExportAdapter entry, which specifies the interaction
with the external server. Values of attributes may optionally be passed on as parameter to
the ExportAdapter in the same way as to ImportAdapter entries.
Entries of object class ExportAdapter contain operational attributes similar to those of
ImportAdapter entries. They specify an access protocol that is used to exchange a description of the changes performed on the exported LDAP attributes.
( dds.2.17 NAME 'exportAdapter'
SUP adapter ABSTRACT )
For the SOAP access protocol, we defined an object class SoapExportAdapter that
contains most attributes of the object class SoapImportAdapter, as described in
1.27.2.1.
( dds.2.18 NAME 'soapExportAdapter'
SUP exportAdapter STRUCTURAL
MUST ( host $ mPOST $ endpoint $ xmlPayload )
MAY ( port $ interfaceName $ methodName $ suppressDN ) )
The XMLpayload attribute may contain the same parameters as defined in section
1.27.2.1. This is usually necessary for sending a method parameter that identifies the external object that shall be replicated. The Distinguished Name of the entry from which the
attributes are exported has usually no significance for the external server, so that a separate identification of the external object becomes necessary.
One addition to the operational attributes already defined is the reserved parameter
$LDIF that must be specified in the xmlPayload attribute value encapsulated in an XML
CDATA section [XML1.0]. The parameter is replaced with a string-encoded description of
the exported attributes or changes applied to them. The string encoding is based on the
LDAP Data Interchange Format LDIF [Good96] that was originally used to exchange directory entries and changes to directory entries between directory servers. Encapsulating the
LDIF string in a CDATA section prevents the SOAP server from parsing the LDIF string for
XML markup characters.
It is up to the external server to interpret the XML string with the contained LDIF description and to apply the specified changes to the external servers database. The LDIF description may contain the current values of the exported attributes or changes that shall be
applied to one or more of the attributes. The format of the LDIF encoding is specified in
[Good96]. The optional operational attribute suppressDN has a single Boolean value and
specifies - if true - that the generated LDIF string shall not contain the DN of the entry
that owns the exported attributes. This attribute should be specified, if the entry's DN is irrelevant for the external server to make the LDIF stream more compact.
Page 206
If the external server refuses to perform the updates specified in the SOAP method, it
must return a SOAP error indication, which is encoded with a __fault XML element
[Box99]. Upon receipt of such an element, the Dynamic Directory will - independent of the
actual contents of the __fault element - assume that the specified method failed.
1.30.2 Operational model
When the Dynamic Directory server initially starts up, it must check all entries for exported
attributes. For every entry containing attributes that shall be exported, the exported attribute values are sent to the specified external server. During this phase, an LDIF string that
describes the current contents of the exported attributes is created and sent to the external server. If an error occurs during this phase, the Dynamic Directory server must signal
that it is unable to replicate its contents. Depending on the requirements of the Dynamic
Directory administrator, the Dynamic Directory server must not become operational until
such errors are fixed. Alternatively, the administrator may specify Dynamic Directory
server options that switch off external server replication or request the server to tolerate
individual unavailable servers.
If a Dynamic Directory client adds, modifies, or deletes an entry with exported attributes,
the Dynamic Directory creates an LDIF description that contains the exported attribute
changes. Then the Dynamic Directory selects the ExportAdapter entry identified by the
modified entry. If the export rule or the selected ExportAdapter entry contains a syntactical error, an exportRuleError is returned to the client. The same applies, if more than
one ExportAdapter is specified. Otherwise, the Dynamic Directory sends the SOAP
method invocation including the LDIF stream to the identified external server. If the server
is not available or signals a SOAP error, the LDAP modification operation fails, no
changes are performed on the Dynamic Directory database. The Dynamic Directory sends
an externalServerUnavailable error or an externalServerError error to the client in the modification response message. If the modification is accepted by the external
server, the modification operation is performed on the Dynamic Directory database and
the operation is confirmed to the client with a success indication.
1.30.3 OMP example
This section introduces an example for exported attributes in an OMP entry of a mobile
user that is registered on a phone (cf. Figure 32). The short number data of the user shall
be exported to that PBX infrastructure to which the user is currently registered. The identifier of the external replicated data is the phone identifier on which the user is registered.
objectClass = HookedObject
objectClass = HookedAddress
objectLcass = RegisteredAddress
objectClass = PhoneRegisteredAddress
objectClass = Person
objectId = 600
// RDN
homeMMD = ehv
managingMMD = ac
phoneAttachedTerminal = ph1 // terminal id on which user is registered
Page 207
phoneAdress = 123
// should be internally derived from terminal
phoneRoamingArea = SOPHO1
// registered roaming area, selects exportAdapter
shortNumberRelation = 1:0406543554// short number definition
export = shortNumberRelation=
(&(objectClass=sophoAdapter)(roamingAreaId=$phoneRoamingArea)):
(phoneAttachedTerminal)
This is an example for an ExportAdapter entry that interfaces with a PBX to export profiles for terminals connected to the PBX. The SOAP method contains a parameter for the
terminal identifier and a parameter for the profile content.
objectClass = adapter
objectClass = exportAdapter
objectClass = soapExportAdapter
objectClass = sophoAdapter
cn = SOPHO1
// RDN
roamingAreaId = SOPHO1 // roaming area id, used to select Adapter
host = micon2
mPost = true
endpoint = /sophoadapter
methodName = ExportProfile
suppressDN = true // do not send DN of exporting entry to external server
xmlpayload = <ExportProfile><TerminalId>$1</TerminalId>
<Profile> <![CDATA[ $LDIF ]]> </Profile></ExportProfile>
If a directory client adds a value 2:0190666666 to the shortNumberRelation attribute, this resulting SOAP XML payload is sent to the external SOAP server handling the interaction with the PBX infrastructure. (The carriage returns are not sent in the message,
the lines have been wrapped and indented for legibility.)
<ExportProfile>
<TerminalId>ph1</TerminalId>
<Profile><![CDATA[
changetype: modify
add: shortNumberRelation
shortNumberRelation: 2:0190666666
]]></Profile>
</ExportProfile>
1.31 Supportive directory extensions
This section introduces a number of supportive Dynamic Directory features that we developed to satisfy the Open Mobility Platform requirements but which are of general value.
Most of these features are used by the other Dynamic Directory extensions that were already described in this chapter.
1.31.1 Soft entries
We employ a concept called soft entries to allow temporary information to be stored in the
Dynamic Directory. We use this concept mainly to temporarily store notification entries in
the Dynamic Directory that are automatically removed when their lifetime is expired, but
Page 208
this feature may be applied to numerous other purposes, too. For performance reasons,
soft entries do not require to be persistently stored in a database that survives directory
server shut downs or failures. Therefore, directory applications should tolerate the occasional loss of soft entries and must not assume that they are persistently stored. A Dynamic Directory soft entry has the auxiliary object class SoftEntry present in its objectClass attribute and possesses the mandatory operational attribute entryLifetime that controls the duration the entry is kept in the DIT. A soft entry may only be leaf
entry, i.e. it must not have any children placed below.
( dds.2.12 NAME 'softEntry'
SUP top AUXILIARY
MUST ( entryLifetime ) )
The mandatory attribute entryLifetime has a single value that specifies the number of
seconds the entry is kept in the DIT before it may be deleted by the Dynamic Directory
server. The attribute value is decremented by the Dynamic Directory server down to a
value of zero, so that clients may retrieve the remaining time the entry will be kept.
( dds.1.52 NAME 'entryLifetime' EQUALITY numericStringMatch
SYNTAX NumericString
SINGLE-VALUE USAGE directoryOperation userApplications )
The main difference between our soft entry concept and the dynamicObject entry standard proposed in [RFC2589] is that we allow the lifetime of the entries to be prolonged with
normal LDAP modification operations instead of defining an extended refresh operation. A
client may prolong the lifetime of a soft entry by modifying the attribute entryLifetime
to a remaining time required by the client. The lifetime may not be diminished by clients,
attempts to such modifications are rejected with an LDAP error constraintViolation.
The directory administrator may enforce upper limits to the lifetime of a soft entry and reduce the entryLifetime value provided by clients without notice. The prolongation of
the entry lifetime may be prevented by the directory administrator in denying modification
access rights on the entryLifetime attribute. For event notification entries, no prolongation capability is offered to the client since discarding of notifications is important for
housekeeping of the DIT.
A Dynamic Directory client may perform any operation on a soft entry that is in accordance
with the access rights granted to it. It may not, however, change the soft entry into a conventional entry by modifying its object class. This is rejected by the Dynamic Directory
server with an objectClassViolation error. As a further extension to the dynamic entry proposal, we extended the LDAP delete operation to allow the automatic removal of all
soft entries that are placed below a normal entry, if that entry is deleted. The deletion is
subject to access rights assigned to the individual soft entries. The deletion feature is extremely useful for implementing an efficient housekeeping policy if multiple applications
populate aggressively the DIT with long-living soft entries. We use that feature, for example, to efficiently remove all notifications created by an event with a single delete operation. An example of an OMP notification soft entry was already discussed in section
1.28.7.
Page 209
1.31.2 Entry templates
Part of the Dynamic Directory administrative and operational information is held in subentries. This is particularly useful for adding operational attributes to entries that are created
by Dynamic Directory clients. This allows to control and simplify the creation of entries
containing operational attributes. We employ entry templates based on collective attribute
subentries to simplify the creation of entries with internally derived attributes, pre-defined
event definitions, and for entries with exported attributes. The structure and placement of
such subentries is aligned with the [X.501] recommendation and explained in this section.
The X.500 information model defines so-called administrative areas - being subtrees of
the DIT - for controlling administrative and operational aspects of a collection of entries.
The root of the administrative area is an administrative entry, identified by the presence of
the operational attribute administrativeRole. Its values determine which administrative aspects are covered by the administrative area, e.g. the presence of collective attributes in the entries of the administrative area. Immediately below an administrative entry,
one or more subentries may be placed containing operational and collective attributes to
be applied to entries within the administrative area.
Each subentry must be an instance of a subclass of subentry, which we defined similar
to the subentry definition from [X.501]:
( dds.2.13 NAME 'subentry'
SUP top ABSTRACT
MUST ( commonName )
MAY ( subtreeSpecification ) )
A subentry must have an attribute commonName (abbreviated cn) and may have a subtreeSpecification attribute that specifies to which entries in the administrative area
the subentry applies. Without the latter attribute, the subentry applies to all entries in the
administrative area, this is different from X.501 subentries. We defined the following syntax for subtreeSpecification (having a single value with DirectoryString attribute syntax) being a string-based encoding of a subset of its X.501 counterpart (the chop
feature of X.501 has been omitted.).
subtreeSpecification = [ "BASE=" DN ] filter ; filter as specified in
1.26.1.3
; only equality filters on attribute type objectClass allowed
The subtree specification consists of an optional base object and a filter expression that
may consist of composed equality filters on attribute objectClass. For the different
types of subentries, further subclasses from subentry must be derived. An example is
the object class collectiveAttributeSubentry, which defines no additional attributes. Its purpose is just to add an object class value to the subentry for identifying its functional purpose.
A client may specify the new control returnSubentriesOnly in a search operation that
will instruct the Dynamic Directory server to return only subentries in the search response.
Without this control, subentries are invisible to clients, unless their DN is used as target of
Page 210
a base object search. This new control is important to allow clients to discover which entry
templates are available in a particular Dynamic Directory server.
1.31.2.1 Derivation rule and export rule template
For specifying derivation rules for internally derived attributes outside the entry itself, we
defined a subentry subclass called DerivationRuleTemplate for the Dynamic Directory Services that contains collective reference attributes and optionally a collective
cachetime attribute.
( dds.2.15 NAME 'derivationRuleTemplate'
SUP collectiveAttributeSubentry STRUCTURAL
MUST reference
MAY cachetime )
A similar ExportRuleTemplate for the inclusion of export rules in entries has been defined, too. It contains the single mandatory attribute export and may be used to define
export rules for all entries that belong to a specified object class.
1.31.2.2 Event definition template
To allow the pre-configuration of event definitions, collective attribute subentries with object class EventDefinitionTemplate may be used by Dynamic Directory administrators as described in 1.28.3.1.6. The entry template contains all operational attributes required for the specification of pre-configured event definitions, as described in 1.28.3.1.6.
( dds.2.16 NAME 'EventDefinitionTemplate'
SUP collectiveAttributeSubentry STRUCTURAL
MUST ( scopeFilter $ triggerConditions $ notificationLifetime $
eventLifetime $ eventStatus )
MAY ( scopeClass $ scopeLimitNamingContext $ classCandidateAVA $
actionConditions $ optimisticPartialCandidate $
notificationContent $ includeOldValues $ includeReference $
includeAliasValues $ includeExternalValues $ eventAction $
notificationLimit $ description $ noRDNTriggers ) )
1.31.2.3 OMP example
The following example shows how the derivationRuleTemplate subentry can be
used to add attribute derivation rules to OMP entries. The MMD entry serves as administrative entry, i.e. the whole MMD subtree is an administrative domain for collective attributes. Below the MMD entry, subentries are placed for each object class that requires to
obtain collective reference attributes for internally derived attributes.
We take the example from section 1.26.4 and show the MMD entry and the subentry attribute/value pairs additionally.
objectClass = MMD
mMDId = Aachen
administrativeRole = autonomousArea
// see [X.501] clause 10
administrativeRole = collectiveAttributeSpecificArea // controls coll. att.
administrativeRole = collectiveAttributeInnerArea
// nested areas possible
Page 211
objectClass = subentry
// placed below MMD entry
objectClass = collectiveAttributeSubentry
objectClass = derivationRuleTemplate
cn = hookedPositionSubentry
subtreeSpecification = (objectClass=HookedPosition) // selects HookedPosition
cachetime = 60
// collective operational attribute
reference =
managingMMD=(&(objectclass=ABSTag)(objectId=$attachedTag)):managingMMD()
reference =
position=(&(objectclass=ABSTag)(objectId=$attachedTag)):position()
reference =
lastLocating=(&(objectclass=ABSTag)(objectId=$attachedTag)):lastLocating()
objectClass = ABSTag
// placed according OMP placement rules
objectId = 2
position = g116
// externally derived attribute
currentABSSensor = 17
// externally derived attribute
managingMMD = ac
homeMMD = ac
lastLocating = 2000-03-06 09:45:12 // externally derived attribute
The following entry has to be added by Dynamic Directory clients to add a new user to the
OMP. It shows the attributes provided by the client in normal font, the collective attributes
automatically added from the subentry by the Dynamic Directory are shown in italic font:
objectClass = HookedObject
// placed according OMP placement rules
objectClass = HookedPosition // entry gets collective attributes from subentry
objectClass = Person
objectId = 533
homeMMd = ac
attachedTag = 2
cachetime = 10
// smaller than cachetime of subentry, 10 sec. will be used
cachetime = 60
reference =
managingMMD=(&(objectclass=ABSTag)(objectId=$attachedTag)):managingMMD()
reference =
position=(&(objectclass=ABSTag)(objectId=$attachedTag)):position()
reference =
lastLocating=(&(objectclass=ABSTag)(objectId=$attachedTag)):lastLocating()
1.31.3 Abstract attributes
The concept of abstract attributes allows specifying in an abstract object class that subclasses must contain non-abstract subtypes of the abstract attribute. An attribute is classified as abstract with an additional clause in the attribute type description (cf. page 64):
AttributeTypeDescription = "(" whsp
numericoid whsp
[ "NAME" qdesrs ]
[ "DESC" qdstring ]
[ "OBSOLETE" whsp ]
[ "SUP" woid ]
[ "EQUALITY" woid ]
[ "ORDERING" woid ]
[ "SUBSTR" woid ]
[ "SYNTAX" whsp noidlen whsp ]
[ "SINGLE-VALUE" whsp ]
[ "COLLECTIVE" whsp ]
Page 212
[ "NO-USER-MODIFICATION" whsp ]
[ "ABSTRACT" whsp ]
-- abstract attribute, default non-abstract
[ "USAGE" 1*(whsp AttributeUsage) ] -- multiple usage clauses allowed
whsp ")"
Abstract attributes may only be used in abstract object class definitions. In a structural object class derived from an abstract class defining abstract attributes, for each inherited abstract attribute a non-abstract subtype of the attribute must be defined. The abstract attribute itself is not part of any entry. The abstract clause is only used for checking an
LDAP schema concerning consistency and completeness and for specifying that the
schema developer must define abstract attribute subtypes for the inclusion in subclasses
of the abstract object class.
The abstract attribute feature is very useful to mandate that different subclasses of a
common superclass shall possess semantically compatible attributes with different attribute names. This is typical for object class frameworks that specify abstract superclasses
which application developers must customise by deriving subclasses.
1.31.4 Entry content control
An entry in the Dynamic Directory contains different types of attributes, which may be
classified concerning their purpose, storage, and source. To allow directory clients to control which types of attributes are returned in an entry, three additional controls have been
defined, one for each of these categories:
Purpose (classified by attribute type definition):
User attributes are for use by directory clients. User attributes are returned in directory operations, if all attributes are requested or the attribute name is explicitly requested.
Operational attributes control the operation of the directory. Operational attributes are not
returned to clients unless they are explicitly requested by name. An operational attribute
may be classified as being a user attribute, too. Those attributes are returned like user
attributes.
The new control includeOperationalAttributes may be specified by clients in a
search request to receive all operational attributes in an entry returned by an LDAP search
operation in addition to the user attributes.
Storage (classified by object class definition):
Static attributes are persistently stored in the directory and may be modified - if allowed by
access control. Their values do not change over time unless they are explicitly modified
by clients.
Derived attributes are dynamically obtained from other entries or from external sources.
Their values may not be modified by clients and may change over time without modification of the entry.
The new control excludeDerivedAttributes may be specified by clients in a search
request to receive only static attributes in an entry returned by an LDAP search operation.
Page 213
Source (classified by object class definition and DIT content rules):
Entry attributes are added to an entry by the client or by the Dynamic Directory server.
They must be allowed by the entry's object class definition.
Collective attributes are added from a subentry when the entry is retrieved from the Dynamic Directory. The entry reflects the collective attribute contents of the subentry at
entry retrieval time - not at entry creation time [X.511].
The new control excludeCollectiveAttributes may be specified by clients in a
search request to suppress all collective attributes from an entry returned by an LDAP
search operation.
1.32 System schema overview
The directory system schema governs the operational information elements required for
the operation of a directory server. The new operational information model elements of the
Dynamic Directory may be summarised in a UML diagram shown in Figure 58. It details
the Dynamic Directory package that was already introduced in the OMP UML specification
in Figure 16 and Figure 18. Only object class definitions are shown, the attributes have
been omitted.
The Dynamic Directory package may be sub-structured into these six packages:
The Soft Entries package defines the auxiliary object class SoftEntry that may be used
by directory schema developers to create entries with limited lifetime in the Dynamic Directory. It is for example used by the Dynamic Directory system schema itself to limit
the lifetime of notification entries.
The Event Handling package contains all Dynamic Directory object classes that have been
defined to enable the definition and monitoring of events.
The Subentries package defines the subentry abstract object classes Subentry, CollectiveAttributeSubentry, and MatchingRuleSubentry.
The Entry Templates package defines several subclasses of object class CollectiveAttributeSubentry serving as entry templates. These templates will be used as such
by applications or will be further sub-classed by schema developers to define entry
templates that are customised for an application environment.
The Generic Adapters package defines the abstract Adapter object classes known to the
Dynamic Directory. They control the basic interaction principles between a Dynamic Directory server and an external server for externally derived and for exported attributes.
These abstract Adapter classes are sub-classed in the Protocol Customisation package to
define object classes and operational attributes dedicated to the external server access
protocols supported by a Dynamic Directory server implementation. This package so far
contains object classes for the SOAP and LDAP protocols, but it may be extended in the
future if additional protocols are required.
A summary of all new operational attributes and object classes can be found in Appendix
D.
Page 214
DynamicDirectory
EventHandling
EventDefinition
Subentries
PreConfiguredEventDefinition
<<Abstract>>
Subentry
placed-below placed-below
EventNotification
CollectiveAttributeSubentry
MatchingRuleSubentry
has
SoftEntries
EntryTemplates
<<Auxiliary>>
SoftEntry
DerivationRuleTemplate
EventDefinitionTemplate
ExportRuleTemplate
GenericAdapters
<<Abstract>>
Adapter
<<Abstract>>
ImportAdapter
<<Abstract>>
PullEventImportAdapter
<<Abstract>>
ExportAdapter
<<Abstract>>
PushEventImportAdapter
ProtocolCustomisation
LDAP
LDAPImportAdapter
SOAPImportAdapter
SOAP
SOAPPushEventImportAdapter
SOAPExportAdapter
Figure 58: UML diagram of Dynamic Directory system schema
1.33 Summary
In this chapter, we have presented the new functionality offered by Dynamic Directory
Services extending the X.500 information model and LDAP specifications. The new Dynamic Directory features were motivated by requirements from the Open Mobility Platform
specified in chapter 0, but they have been developed as generic directory service extensions that will be useful to many other directory applications.
The main functional improvement of Dynamic Directory Services compared with conventional directory services is that not only information being persistently stored in underlying
databases is accessible to clients, but that information may be derived on-demand by the
directory server from internal and external sources. Additionally, the client may be informed about the occurrence of events inside the directory. All these features make our
Page 215
Dynamic Directory Services dynamic in contrast to conventional services. Further extensions cover support for representing spatial position information and retrieving directory
entries based on spatial search filters. The introduction of the new nearestMatch matching rules allow the provisioning of sophisticated trading services by the Dynamic Directory,
and the attribute export feature allows synchronous replication of directory information to
external servers.
The functional extensions are reflected in an extended directory system schema, for which
several new object classes and operational attributes have been defined in this chapter.
Although the information model and operational models of LDAP and X.500 have been
significantly enhanced, the LDAP service and protocol models did not have to be changed
for the Dynamic Directory extensions. This is of special importance since it allows application developers to use existing LDAP protocol stacks and APIs to access Dynamic Directory servers. Furthermore, the operational attributes required for these new Dynamic Directory features may be added automatically from entry templates specified in an application framework, so that directory applications and users may make use of the new features without having to know syntax and semantics (even not the existence) of these new
operational attributes. This is a useful feature for the definition of application platforms,
where users are allowed to add new entries to the directory, but the operational information belonging to these entries may stay under the control of the directory administrator.
The next chapter discusses how the new Dynamic Directory features can be implemented
as an extension of conventional directory servers and how the data consistency challenges introduced by derived attributes and event handling may be solved with a common
architectural approach. The chapter also introduces the Open Mobility Platform prototype
that has been built using our Dynamic Directory server prototype implementation.
Page 216
Implementation
This chapter discusses how the new Dynamic Directory features developed in this thesis
can be implemented as an extension of conventional directory servers. Additionally, it introduces an Open Mobility Platform prototype implementing most of the specification developed in chapter 0. It has been built using our Dynamic Directory server implementation
and has been integrated into a test environment with real-world communication and positioning systems.
1.34 Dynamic Directory Services
In chapter 0, we presented several new directory features that distinguish our Dynamic Directory Services from conventional directory services. The main difference is that information returned by the directory is no longer only static information that is retrieved from an
internal database. Instead, the Dynamic Directory dynamically derives information from internal and external sources and informs directory clients about changes in its contents.
This chapter discusses the impacts of the new features on the implementation of Dynamic
Directory Services. After reviewing the architecture of conventional directory servers, we
present an extended architecture that allows the implementation of Dynamic Directory
servers re-using as much of the conventional server software as possible. We then discuss the main architectural extension, called Dynamic Entry layer, and introduce the concept of entry cloning that solves most of the new implementation challenges introduced by
the Dynamic Directory Services with a homogeneous solution. Finally, we briefly present in
this chapter the Dynamic Directory server prototype implementation we performed as part
of this work.
1.34.1 Conventional directory server architecture
The typical architecture found in conventional directory servers consists of three main layers, as illustrated in Figure 59: A protocol layer, a directory operation layer, and a database layer. The protocol layer implements one or more protocol engines that realise the
different Directory Access and System Protocols. Some servers support multiple protocols
such as X.500 and LDAP (e.g. the X.500 DirX DSA [ Siemens00] or the M-Vault DSA from
[MessagingDirect00]), others only LDAP (e.g. the LDAP servers from Netscape [Netscape00] or
OpenLDAP [OpenLDAP00]). The directory operation layer implements the scheduling and
execution of directory operations. It receives requests from the protocol layer, schedules
operations to be executed, monitors their progress, and initiates that the result is returned
to the clients. The database layer implements persistent storage of entry information in
one or more database backends. The database layer is usually built around a disk-based
database system that stores large amounts of entries and allows retrieving entries during
search operations with appropriate database indexing mechanisms [ Howes]. To improve
Page 217
processing performance, the database layer often employs a main memory cache of entry
information that offers faster entry retrieval times.
DAP
protocol
engine
…….
LDAP
protocol
engine
operation
scheduling
and execution
database
backend
…….
database
backend
Figure 59: Conventional directory server architecture
In conventional directory servers, only a single logical instance of every entry is kept by
the database layer. This assumes that the disk instance and the cache instance are always tightly synchronised, and entry updates are immediately propagated to the disk database. Every directory operation performed by the server may operate on the same logical instance of the entry, since only short retrieval and update operations are performed
on the data. The entry must only be locked during update operations against access by
concurrently running operations to prevent retrieval operations from returning an inconsistent state of the entry data. This model allows retrieval operations to be performed in parallel tasks without additional synchronisation needs. Only update operations require synchronisation with other operations.
Database backends usually employ indexing of entry attribute values. Which indices are
maintained by the database depends on the matching rules that are defined for attribute
types and on administrative configuration settings. Indices improve database lookup performance but increase database update time and database size heavily. Each entry owns
a unique identifier that serves as primary key for the database.
Interaction between operation execution layer and database layer is typically realised as a
two-phase process. As an example, the typical interaction employed for a search operation is described in the following and illustrated in Figure 60. In the first step, the value assertions provided in a search request or the entry's DN are matched against the database
indices. From this, a list of candidate entries that potentially match the search filter or
match the name is generated using the logical operators of the search filters. The list contains the entry identifiers and is in the second phase processed sequentially to evaluate
which candidates match the specified filter. If an entry's name has been supplied, the list
will contain at most one entry identifier, if the name is found in the database indices. During the second phase, the entry contents must be retrieved from the database or from the
cache in order to have all attribute values available for comparison with the supplied value
assertions. Each entry matching the search filter is sent to the client by the protocol layer.
Additional functions are offered by the database layer to add, update, or delete entries in
main memory cache and in persistent storage (i.e. usually disk) including updating of the
indices maintained by the backend.
Page 218
Client
Protocol
layer
LDAP search
request
Operation
layer
Database
layer
Disk
database
search request (filter)
schedule operation
execute operation
getCandidates
(filter)
search db index
for each entryId in
entryIdList
returnCandidates
(entryIdList)
getEntry(entryId)
entry in cache?
getEntry(entryId)
entry
returnEntry(entry)
add entry to cache
check filter
send search Response (entry)
LDAP search
response
Figure 60: Interaction principle between directory server layers
1.34.2 Dynamic Directory server architecture
We propose the architecture shown in Figure 61 for realising a Dynamic Directory server.
It is an extension of the three-layer architecture discussed in the previous section and
supports all new Dynamic Directory features. The main extension is an additional Dynamic
Entry layer that is placed between database layer and operation execution layer. It realises most entry-related Dynamic Directory extensions. This architecture minimises the impact of introducing the Dynamic Directory concepts into a conventional layered directory
system. This allows efficient re-use of existing directory server software for realising Dynamic Directory servers.
Our approach requires the following additions and modifications to the aforementioned
layered architecture:
Protocol layer
The existing protocol layer implementations can be used for Dynamic Directory server implementations, since we do not require changes to the LDAPv3 protocol except some additionally defined error codes and service controls. If the new LDAP controls we defined
for the Dynamic Directory are mapped on additional X.500 DAP service controls [ X.511], it
is also possible to access the Dynamic Directory server with the X.500 DAP access protocol.
Page 219
LDAP
protocol
engine
…….
DAP
protocol
engine
event
definition
event trigger
creation
extended
matching
derived
attributes
database
backend
…….
database
backend
clone
manager
operation
scheduling
and execution
Dynamic Entry
layer
exported
attributes
event
execution
event trigger
monitoring
external
server
protocol
engine
SOAP
…….
protocol
engine
others
Figure 61: Dynamic Directory server architecture
Operation scheduling and execution layer
This layer needs mainly extensions that implement the operational models for defining and
processing events and for evaluating the new Dynamic Directory matching rules. Event
definition functions are invoked by LDAP add operations, if the added entry is of object
class EventDefinition. The event definition module evaluates the operational attributes provided by the user and determines the entries that are part of the event scope. For
all scoped entries, the current attribute values are obtained that are needed for evaluating
the event condition by the Dynamic Entry layer. During this process, the event trigger creation module identifies all monitored entries and creates all required event triggers. The
event definition module also handles the subscription of clients to events, invoked by
LDAP search operations.
The event execution module is invoked by the Dynamic Entry layer, if an event trigger
fires. The event execution functions evaluate all associated event conditions and determine whether the events fire. In this case notification entries are created and temporarily
stored by the Dynamic Entry layer. The event execution module includes functions for the
execution of event actions and the sending of notification messages to all subscribed clients.
The extended matching module implements the new matching rules defined for the Dynamic Directory. It is invoked by the search operation functions. For spatial matching and
configurable matching, only additional AVA evaluation functions need to be implemented.
For nearest matching, the search processing needs changes that are more profound. Entries obtained from the Dynamic Entry layer during a nearestMatch search are not immediately sent to the client but are buffered until all entries have been found. Then, the
entries are ordered according to the nearestMatch criteria, and the requested number of
entries is sent back to the client.
Two general extensions must be added to the operation scheduling function. First, the operation scheduler must periodically invoke housekeeping functions in the Dynamic Entry
Page 220
layer that perform garbage collection of soft entries and entry clones. Second, the event
processing functions must be invoked from event trigger monitoring functions to evaluate
event conditions for fired triggers. The operation execution functions must be slightly extended to interpret the additional LDAP controls, return the new error codes specified for
the Dynamic Directory, and to pass on additional parameters to the Dynamic Entry layer
as defined in section 1.34.3.2.2.
Dynamic Entry layer
This additional layer contains most of the new functionality required for realising Dynamic
Directory servers. It encompasses five main modules that handle entry cloning, derived attributes, exported attributes, event trigger creation and event trigger monitoring.
The clone manager is a module that creates an instance of the directory entry - called
clone - being associated with a particular directory operation. The clone contains all attributes of an entry: Static, collective, and derived attributes. First, the static entry attributes
are retrieved from the database layer. After that, collective attributes are added from subentries, and finally, the derived attributes are obtained from the derived attributes module
and added to the entry clone. For modification operations, only the static attributes are returned by the Dynamic Entry layer. Because of this approach, the operation execution
modules are not concerned with distinguishing between the different attribute types. Depending on the directory operation, different types of clones may be retrieved from this
module, e.g. if the client specified LDAP controls to suppress certain attribute types. The
concept of entry cloning is further discussed in section 1.34.3.
The derived attributes module contains all functions for evaluating the operational attributes contained in an entry clone - those which are natively present and those added before from collective attribute subentries. If internally derived attributes have to be added to
the entry, the functions evaluate the derivation rules, identify the source entries, retrieve
them, and obtain the target attribute values from the specified source attributes. Since the
source entries in turn may contain derived attributes, the source entries are not directly obtained from the database layer but recursively from the Dynamic Entry layer. If externally
derived attributes must be added to an ImportAdapter entry clone, the derived attributes module interacts with the external server protocol engine to retrieve the attributes
specified in the import operational attribute. All externally derived attributes are added to
the entry clone.
The exported attributes module is invoked when the Dynamic Entry layer shall perform a
modification to an entry that contains the export operational attribute. Before the entry is
updated in the database backends, this module calculates the LDIF string describing the
entry or its modifications and interacts with the specified external server to synchronise the
entry contents. If the modifications are accepted by the external server, the modifications
are applied to the database. During the whole update process, the entry is locked against
other modification and read operations to prevent conflicting updates and inconsistent retrievals.
The event trigger creation module is responsible for creating update and import event triggers, for storing them, and for deleting them, if they are no longer required. This module is
Page 221
invoked from the derived attributes module during the event definition phase. The derived
attributes functions analyse the dependencies of the event condition on the entry's static
attributes and derivation rules and instruct the event trigger creation module to create the
required triggers, as defined in 1.28.4.2 and 1.28.4.3.
The event trigger monitoring module contains functions that evaluate whether an entry
modification affects one or more update triggers. These functions are invoked when the
Dynamic Entry layer shall perform an update on an entry. The module also contains import trigger monitoring functions that listen for incoming notifications from external servers.
If a trigger fires, the monitoring module determines which event definitions are interested
in that trigger and invokes the event execution module of the operation scheduling and
execution layer to evaluate the event conditions and execute their actions.
Database layer
The database layer does not need mandatory extensions for realising a Dynamic Directory
server. It is used to store the static attributes of entries in the conventional way including
the processing of database indices. Derived attributes may not be indexed since their values are unknown to the database. This approach allows to re-use existing database
backends for the realisation of Dynamic Directory Services.
However, the performance of Dynamic Directory servers could benefit from the development of dedicated database backends that implement additional features currently not
supported by the backends:
The database backend could support the new containsMatch and containedMatch
matching rules with a dedicated spatial database indexing mechanism that allows determining candidate entries for these new value assertion types.
The database could be based on an Active Database Management System (ADBMS) that
performs monitoring of update triggers in the backend instead of checking them in the
Dynamic Entry layer. This approach depends on the general feasibility of replacing the
performance-tuned database backends with ADBMS backends. Additionally, it requires
that the update trigger specifications can be mapped on trigger rules in the ADBMS.
External server protocol layer
This layer implements the different access protocols needed to interact with external servers. It contains modules for interacting with servers to retrieve externally derived attributes,
for receiving notifications from monitoring subcontracts, and for exporting attributes to external servers.
1.34.3 Dynamic Entry layer
The main concept of the Dynamic Entry layer is the so-called entry cloning, which is discussed in more detail in this section. Most of the new Dynamic Directory implementation
challenges are solved by that concept with a homogeneous approach. We first present the
challenges inherently associated with Dynamic Directories that are solved by the entry
cloning concept. Two of the issues that are raised during entry cloning implementation are
Page 222
pre-fetching of derived attributes and accessing clones from concurrent directory operations. How these issues are tackled in our implementation, which information model we
defined for managing clones, and the operational model of the clone manager module are
presented.
1.34.3.1 Requirements solved with entry cloning
Entry cloning is a concept that creates a temporary instance of a directory entry - called
clone - that is created and managed by the Dynamic Entry layer in a main memory database. From the viewpoint of the operation execution layer, the clone database behaves
like a main memory cache of entries similar to a cache offered by a conventional database
layer. The operation layer may retrieve pointers to entry instances held in main memory
that may be used for executing the directory operation and sending results to clients.
When the entry is no longer needed, the operation layer invokes a release function in the
database layer that manages reference counters to the entry's data structure and eventually frees the allocated main memory. Entry cloning extends the concept of main memory
caching by allowing the existence of multiple entry instances in the cache that represent
different states of the entry and are used by concurrently executed directory operations.
We developed the entry cloning concept to satisfy the following requirements that we identified for Dynamic Directory servers in the previous chapters:
Clone provides temporary storage of derived and collective attributes
In addition to the static attributes of an entry that are contained in the database
backend, the entry that is processed and eventually returned to clients must contain
operational and derived attributes. These attributes must be added to a temporary instance of the entry, since they must not be added to the database backend persistent
storage. The entry clone provides such a temporary instance that is returned by the Dynamic Entry layer to the operation and execution layer for operation execution and
sending to the clients.
Clone is re-used to obtain derived attributes only once for consistency
Depending on the data consistency level of an operation, the derived attributes may
only be obtained once for an entry for a certain thread of operation execution. Either
during determining the values of a single entry or during a complete directory operation,
the derived attributes must be re-used once they are evaluated. This requires that the
clone is not discarded immediately after it is released by the operation execution layer.
Instead, the clone must be kept until no further retrievals of the entry are required by
the operation execution layer in the context of a single returned entry or the whole directory operation.
Clone realises temporary storage of derived attributes for caching
The lifetime of a clone may be extended beyond the time needed for realising data
consistency to realise caching of derived attributes. Before the Dynamic Entry layer
creates a new entry clone, it checks its cache whether an existing clone may be reused, depending on the data consistency, the noAttributeCaching control, the age
of the clones, and the derived attributes contained in the clone.
Page 223
Clone captures values sent in notification messages from external servers to avoid subsequent retrievals
The data sent by an external server in a notification message are added as externally
derived attributes to a clone of the ImportAdapter entry. During the following condition evaluation, these attributes are re-used instead of sending a retrieval message to
the server (cf. section 1.28.5).
Clone avoids redundant retrieval requests to external server
As long as a monitoring subcontract with an external server exists, no additional retrieval requests for the monitored external object are necessary, since the latest external values are already available in a clone of the ImportAdapter entry. The Dynamic
Entry layer may obtain the externally derived values from that clone irrespective of
whether caching is allowed for that entry or not.
Clone realises temporary storage of pre-event entry values for event processing
During evaluation of event triggerCondition expressions, the pre-event attribute
values of a candidate entry must be compared to the current attribute values. The clone
that is created to capture derived attributes may be used to store temporarily pre-event
entry values for comparison with current values. This requires that a clone is not discarded until a new clone containing a more recent state of the entry is created. The
same is true for all monitored entries, where pre-event values are needed for the identification of all candidate entries.
Clone may provide temporary storage of entry to shield operation-consistent LDAP operations against concurrently running modifications
During processing of operation-consistent LDAP operations, clones are created for
each entry retrieved from the database layer. If that entry is modified by another operation during the operation-consistent operation, the Dynamic Directory server can still refer to the pre-modification values stored in the clone. This application of cloning implies
that clones may be created even for entries having static attributes only. Therefore, this
data consistency level should be used with care since it implies considerable processing and storage effort in the Dynamic Directory server.
Clone realises temporary storage of entries for sorting
During processing of a search operation containing a nearestMatch filter item, the
entries obtained in the first phase of the search filter evaluation (see Figure 57) must be
stored temporarily in a list. The list is later sorted by the operation layer according to the
assertion value provided by the client. Entry cloning realises the temporary storage of
the entries - including their derived attributes. The nearest matching function in the operation layer just has to create a list of pointers to the clones managed in the Dynamic
Entry layer.
The entry cloning concept leads to the creation of clones for entries with only static attributes during operation-consistent operations to shield an operation against concurrently
executed modifications. To suppress cloning of entries that are in practice never modified,
such as alias entries and directory client entries, we defined an additional operational attribute doNotClone that - if set to true - prevents an entry from being cloned. This attribute must not be specified in entries with internally or externally derived attributes, otherwise this raises a derivationRuleConflict error. It may be added easily from collective attribute subentries to all entries that shall not be cloned. For the Open Mobility
Page 224
Platform, it should for example be used for MMDPointer and OMPUser entries to prevent
the Dynamic Directory from creating clones of these entries.
1.34.3.2 Implementation concepts
The clone concept allows to temporarily store an instance of an entry containing all static,
collective and derived attributes that are consistent with each other. The clone is re-used
throughout a directory operation whenever the operation layer or the Dynamic Entry layer
needs to access an entry to ensure that always the same entry instance is used. Entry
cloning raises two major issues that must be solved in a Dynamic Entry layer implementation: First, which derived attributes are contained in a clone - all or only selected attributes,
and second, how are clones accessed by concurrently executed operations? The first issue may be addressed with attribute pre-fetching, the second with atomic steps.
1.34.3.2.1 Pre-fetching derived attributes
Since a clone that is created once shall be re-used in further retrievals of the entry, it will
be often necessary to pre-fetch all derived attributes at clone creation time. The reason is
that only a complete clone will ensure that it may be used for further requests. Prefetching has the drawback that derived attributes might be obtained by the server although
they are not needed to answer the client's directory operation.
To decide which derived attributes must be obtained for a clone, the operation type, its
consistency level, and the role of the entry in the operation must be taken into account by
the Dynamic Entry layer:
For clones of entries that are requested by the operation layer to be potentially returned to
clients in an operation:
All dynamic attributes are pre-fetched, if
- the data consistency level is operation-consistent (to re-use the clone as source entry in later steps of this operation), or if
- the data consistency level is entry-consistent, and caching is enabled for that entry,
and at least one dynamic attribute is requested by the client (to re-use the clone as
cache for other operations).
Otherwise, only the derived attributes requested by the client are obtained for the clone.
For clones of entries that are requested by the Dynamic Entry layer itself because they are
needed as source entries in attribute derivation rules:
All dynamic attributes are pre-fetched (to ensure consistency if multiple derivation rules
use the entry).
For clones of entries that are requested by the Dynamic Entry layer or the operation layer
and are used to evaluate event triggers:
All dynamic attributes are pre-fetched (to ensure consistency, if multiple event conditions must be evaluated on the entry and to re-use the clone for obtaining pre-event
contents of future events).
Page 225
1.34.3.2.2 Atomic Steps
The derived attributes of an entry shall be created only once during a thread of operation
execution that depends on the operation type and consistency level. The question that
arises is, how concurrently-issued directory operations may access clones of entries.
Some directory operations may be rather long lasting, if multiple access methods to external servers have to be carried out, or if a nearest match is performed that requires all
matching entries to be sorted before clones may be discarded. Therefore, operations
should be able to be executed concurrently and must not be restricted to sequential execution.
This poses the problem that different concurrently executed directory operations have to
access different instances of entry clones, since the contents of the clones may change
over time. Furthermore, different co-existing clones of the same entry are required to allow
simultaneous access to ImportAdapter entries. Since the values of Adapter clones
depend on the parameters that are passed on from target entries, clones of Adapter entries must be stored along with the parameters that are used to create their derived attributes. For each set of parameters, an individual entry clone must be created and managed
by the Dynamic Entry layer. These considerations raise the question of how the Dynamic
Entry layer ensures that each thread of operation execution operates on the appropriate
clone version of an entry.
The solution we propose to this problem is the introduction of a so-called atomic step. An
atomic step is a thread of operation execution characterised by an Atomic Step Type
(AST) and an Atomic Step Identifier (ASI). An atomic step may represent a whole clientinitiated directory operation, any sub-part of such operation, or an internally-initiated operation such as the evaluation of event triggers. All entry access requests that belong to
the same atomic step will retrieve the same clone instance of an entry from the Dynamic
Entry layer. This guarantees that repeating retrievals of the same entry during an atomic
step will always return the same attribute values for that entry. An entry-consistent directory operation performs the retrieval of each search candidate entry as a different atomic
step. An operation-consistent directory operation retrieves all candidates in a single atomic
step. When a notification is received from an external server, an atomic step is started for
evaluating the event condition. Thereby the same clone created upon notification receipt is
used for condition evaluation.
The Atomic Step Identifier is used to differentiate between different versions of a clone
that may exist at any time. The identifier is used in conjunction with the entry identifier and optionally a parameter set - to unambiguously identify an entry clone in the Dynamic
Entry layer. All access operations to the Dynamic Entry layer that specify the same ASI will
operate on a set of consistent clones. For a given ASI, the derived attribute values of a
clone are obtained at most once. The ASI may be created by the operation execution
layer depending on the type of operation, or it will be created by the Dynamic Entry layer.
The latter has the advantage that for retrieving entries without derived attributes, no ASI
must be generated by the operation execution layer. If no ASI is provided and the Dynamic Entry layer decides to obtain derived attributes, the ASI is generated by the Dynamic Entry layer.
Page 226
The Atomic Step Type specifies for which purpose the clone is retrieved from the Dynamic
Entry layer. Whether a new clone must be created or whether an existing clone may be returned to the requester depends on the Atomic Step Type (this is further discussed in section 1.34.3.4).
These Atomic Step Types have been defined:
get - entry is needed for an entry-consistent operation, cached data may be used.
getNoCache - entry is needed for an entry-consistent operation, cached data must not be
used.
getOperationConsistent - entry is needed for an operation-consistent operation,
cached data must not be used.
getOldValues - entry is needed to compare pre-event contents to post-event contents
during event condition evaluation.
getCreateTriggers - entry is monitored entry needed to define event condition, requests Dynamic Entry layer to return current entry contents and to simultaneously create all required event triggers.
getUpdateTriggerFired - entry is needed to evaluate event condition after update
trigger has fired.
getImportTriggerFired - entry is needed to evaluate event condition after import trigger has fired.
getUpdate - entry shall be updated; this AST is provided from a modification operation to
the Dynamic Entry layer.
Applying this concept extends the two-phase entry retrieval model we described for conventional directories: The first phase needs no modification, the entry identifier may be obtained from the Dynamic Entry layer using the database backend's indexing mechanisms.
The second phase now allows additional parameters to be optionally passed to the Dynamic Entry layer: entry = f (entry_id, AST, [ASI], [source_entry_parameters]).
The source_entry_parameters parameter needs to be provided only, if the entry is of
object class ImportAdapter. In this case, the parameters equal the values that were
passed to the ImportAdapter (source-) entry when the externally derived attributes
were obtained.
1.34.3.3 Information model
The X.500 standards define a DSA information model that defines types of DSA-specific
entries, also called DSEs, and their operational attributes used by the server to realise the
directory service [X.501]. A DSE might represent an entry, a subentry, or other type of information such as glue knowledge for creating references to other directory servers. The
DSA information model, however, says nothing about the implementation of the DSEs in
the directory server.
We extended the DSE model with additional operational attributes that specify the type,
status, and completeness of an entry managed by the Dynamic Entry layer. The information held in these attributes are used internally by the Dynamic Entry layer to control the
Page 227
usage and lifetime of entries in that layer and are not returned to directory clients. Each
entry has an associated identifier entryId, a type DynamicEntryType, and specifies
the Atomic Step Identifier that created - or most recently modified - the DSE.
<<abstract>>
DSASpecificEntry
DynamicEntryType
entryId
ASI
Zombie
Persistent Entry
entryId
has
1
Master Entry
<<abstract>>
Cached Entry
0..1
1
Soft Entry
entryLifetime
has
0..*
Clone
[creationParameters]
cloneContents
cloneStatus
creationTimestamp
Figure 62: DSE types managed in the Dynamic Entry layer and database backend
The following types of DSEs are managed by the Dynamic Entry layer, as shown in Figure
62:
Persistent entry
This DSE type represents the entry instance persistently stored in the database
backend. It reflects all successfully finished modification operations applied to that entry. It contains only attributes being innate to that entry, i.e. no collective or derived attributes. This type of entry is obtained by the Dynamic Entry layer from the database
backend and further processed before being stored in the Dynamic Entry layer main
memory database.
Master entry
This DSE type is an extended copy of a persistent entry obtained from a database
backend. It is further processed by adding all collective attributes from subentries and
by pre-processing the operational attributes held by the entry. The derivation rules of internally derived attributes are converted into efficiently processable data structures, and
the derived attributes are sorted into an executable sequence - including the detection
of loops between derivation rules. Directory modifications are performed on the master
entry instance and on the persistent entry in parallel, so that they are tightly synchronised. The ASI of the most recently applied modification is reflected in the ASI attribute
of the master entry. There may exist at most one master entry in the Dynamic Entry
layer for every persistent entry, at any time. If a collective attribute subentry is modified,
the master entries of all affected entries must be re-created to include the modified collective attribute values. All its associated clones are set to status stale.
Page 228
The master entry is created when an entry is retrieved for the first time from the database backend. It is kept until the entry is deleted or the Dynamic Directory server is shut
down. A master entry is cloned when a new entry instance is needed for an operation
that has an ASI for which no instance has been created yet and the entry contains derived attributes. One master entry may possess several clone entries at the same time.
A master entry may not be destroyed as long as it possesses any clone entry. If the directory user deletes an entry and its master entry still possesses clones, the associated
persistent entry is deleted, and the master entry in the Dynamic Entry layer becomes a
'zombie' entry.
Soft entry
A soft entry (cf. 1.31.1) only exists in the Dynamic Entry layer and is not stored in the
database backends. Soft entries have an associated lifetime after which they are automatically destroyed by the Dynamic Entry layer. This function is performed by housekeeping functions in the Dynamic Entry layer which are periodically invoked by the operation scheduler. A soft entry may be cloned in the same way as a master entry if it
contains derived attributes. If a soft entry having clones shall be discarded, it first becomes a zombie entry until all its clones have been discarded.
Zombie entry
A zombie entry represents a master or soft entry that was deleted by a client user but
that still possesses clones. It has been deleted in the database backends but not in the
Dynamic Entry layer. The zombie is not returned to the user as result of directory operations, but its clones are used to answer retrieval requests for ongoing operationconsistent directory operations. After all its clones have been destroyed, the zombie is
destroyed, too.
Clone
A clone is a copy of a master entry or soft entry that is associated with the ASI of the
atomic step that created the clone and optionally with a parameter value set. A creationTimestamp attribute holds its creation time, which is needed for deciding whether
the clone may be used as cache. The clone is the only entry type that may contain derived attributes (depending on its status). A clone is discarded when it is no longer
needed to buffer derived attributes for its associated operation, to cache entries, or to
store pre-event entry values for event handling.
To describe the completeness of the contents of a clone, every clone has cloneContents and operational attributes that are used by the Dynamic Entry layer to decide for
which operations a clone may be re-used. The attributes are only used for clones, not
for the other types of entries.
A clone managed by the Dynamic Entry layer may have one of the following cloneStatus values:
- creating
The clone is in its creation phase and is still being processed to obtain its derived attributes. It contains all of its static attributes, it may contain any number of its derived
attributes. This clone is not retrievable from the Dynamic Entry layer, its main purpose is to enable loop detection. It may be obtained by the derived attributes functions, if an internal attribute derivation rule creates a loop between two or more enPage 229
tries. If only static attributes are required from a source entry for which a clone with
status creating was found, those attributes are used as source attributes. If derived attributes are required, a derivation rule loop has been detected and an error
must be sent back to the client, as described in section 1.26.3.
- stable
A stable clone has been completed by the Dynamic Entry layer and may be retrieved
from the layer. Its contents are reflected by the value of the cloneContents attribute as described below.
- stale
A clone becomes stale, if an update is performed on its master or soft entry, e.g.
when the entry itself or one of its associated subentries is modified. The clone may
only be retrieved by requests from that particular atomic step which created the clone
(i.e. has the same ASI), or by event handling operations for pre-event value comparison. It must not be used to answer other retrieval requests.
- deleting
A clone with status deleting must not be further used by the Dynamic Entry layer. It
will be discarded as soon as the reference counter of the clone will be zero, indicating that the data structure is no longer used by any module. Clones are set to deleting, if they are no longer needed by the Dynamic Entry layer or if an error occurred
during clone creation.
clone status
all required derived
attributes obtained
creating
stable
entry
is cloned
clone not
existing
error during
clone creation
reference
counter is zero
stable clone
no longer
needed
deleting
entry is
modified
stale clone
no longer needed
entry is modified
stale
Figure 63: State Chart of clone status
The State Chart of the clone's possible status values is defined in Figure 63. The state
transitions being related to the lifetime of a clone are further explained in the next section.
Page 230
The attribute cloneContents indicates how complete the derived attributes were obtained for a clone:
- complete
The clone contains all mandatory and optional derived attributes defined for the entry.
- incomplete
The clone contains all static attributes and some but not all derived attributes defined
for the entry.
- staticOnly
The clone contains all static attributes, but it does not contain any derived attributes
although there are derivation rules defined for that entry. The contents of this clone
do not change unless its status is re-set to creating, if the derived attributes shall be
added to the clone at a later point of time.
- referenceRaised
Determining the clone's values led to a continuation reference to another directory
server (that was not followed). The clone may contain any subset of the derived attributes defined for that entry.
1.34.3.4 Operational model
The operational model for the Dynamic Entry layer specifies the conditions under which a
new Atomic Step is initiated by the Dynamic Entry layer and the conditions under which
clones are created or re-used during retrieval requests. Additionally, it defines when
clones may be deleted from the Dynamic Entry layer. An example illustrating the interaction with the Dynamic Entry layer is shown in Figure 64.
Creation of ASIs
For these Atomic Step Types, the Dynamic Entry layer creates an ASI if none is provided
in the Dynamic Entry layer request:
get - ASI created if not provided and derived attributes defined for entry.
getNoCache - ASI created if not provided and derived attributes defined for entry.
getOperationConsistent - ASI always created if not provided.
getUpdate - ASI always created if not provided.
getCreateTriggers - ASI always created if not provided.
For these ASTs, an ASI of an existing Atomic Step must be provided in the Dynamic Entry
layer request:
getOldValues
getImportTriggerFired - (ASI that was created when trigger fired).
getUpdateTriggerFired - (ASI that was created when trigger fired).
Page 231
Retrieval of clones
If an entry is retrieved from the Dynamic Entry layer, either an existing clone will be retrieved from the main memory database or a new clone must be created and added to the
database, depending on the Atomic Step Type provided with the retrieval request:
All requests except getUpdate and getOldValues: If an ASI is provided by the operation, the Dynamic Entry layer will first search whether a clone for this ASI already exists.
If so, that clone is returned, if its cloneStatus is not deleting. In the latter case, no
entry is returned. If no clone is found for the ASI, the Dynamic Entry layer checks
whether another clone can be used as cache.
To be usable as cache, a clone must be complete and stable. Furthermore, the difference between the current time and the clone's creationTime value must be
smaller than the cachetime (cf. 1.26.1) associated with the entry.
If no clone is found for a specified ASI, a new clone is created. If no ASI was provided,
but the Dynamic Entry layer decides to create one - e.g. because the entry contains derived attributes, a new clone is created.
getUpdate retrieval: The master entry is returned to perform updates on master instance. The master is locked against other requests, and no clone is created. After successful update, the update ASI is associated with the master entry, and the persistent
entry is updated accordingly. All existing clones of the modified master entry are set to
status stale.
getOldValues operation: The Dynamic Entry layer searches for a complete clone with
status stable or stale that was created before any clone having the ASI specified in
the request was created. To be usable as old value, the clone's status must be stable
or stale, and its cloneContents attribute must not be staticOnly.
Creation of Clones
When a clone is created, it is associated with an ASI, a creation timestamp (for caching),
and optionally the parameters that are used to obtain its externally derived attributes. In
case of a notification from an external server, these parameters must be created from the
data provided by the external server using the extractIdentifier attribute (cf. section
1.28.5).
Lifetime of clones
Clones are automatically discarded by the Dynamic Entry layer when they are no longer
needed. Before they are discarded, their status is set to deleting to allow other Dynamic
Directory server modules to release pointers to the clone. Clones are discarded (i.e. set to
status deleting) in the following cases:
Generally, a clone is discarded when the operation that created the ASI associated with
the clone is terminated. Deviating from this rule, a clone is not discarded at operation termination time in the following cases:
Stable clones with complete contents are kept as long as they are useful as cache or are
needed for storing pre-event values (i.e. no newer complete clone has been created).
Page 232
Stable clones with contents completeness referenceRaised are kept as long as they
are needed for storing pre-event values (i.e. no newer complete clone has been created).
Stale clones are kept as long as they are needed for storing pre-event values (i.e. no
newer complete clone has been created).
Client
Protocol
layer
LDAP search
request
Operation
layer
Dynamic Entry
layer
External
server
search request
(filter, operation-consistent)
schedule operation
execute operation
create ASI
getCandidates
(filter)
search db index
for each entryId in
entryIdList
returnCandidates
(entryIdList)
getNoCache
(entryId, ASI)
search clone
clone master entry
get external attrs
properties
returnEntry(entry)
add attrs to clone
check filter
LDAP search
response
send search Response
(entry)
Figure 64: Dynamic Directory layers interaction example
1.34.4 Dynamic Directory server prototype
We implemented a Dynamic Directory server prototype based on the publicly available
SLAPD (Stand-alone LDAP Daemon) LDAP server implementation from the University of
Michigan [Howes96]. The prototype was mainly built to validate the feasibility and usefulness of the Dynamic Directory concepts and to improve the developed features iteratively.
Most of the Dynamic Directory features and information model concepts presented in this
document have been integrated into the prototype. The Dynamic Entry layer has been implemented following the design presented in this chapter as an extension of the main
memory cache of the SLAPD server. The implementation includes also some generic
X.500 information model concepts that are not supported in SLAPD, e.g. subentries and
collective attributes.
One difference between the prototype software and the Dynamic Directory specification is
the supported LDAP protocol version. Whereas the Dynamic Directory Services specification presented in this document is based on LDAP version 3, the SLAPD server - and
thereby our prototype, too - are based on LDAP version 2. Practically, this affects mainly
Page 233
the way in which the additionally defined LDAP controls and matching rules are conveyed
from clients to servers:
LDAPv3 has built-in support for newly defined LDAP controls. Therefore, we had to multiplex the new controls into the parameters used in LDAPv2 in the prototype.
LDAPv3 allows the invocation of extensible matching rules, which we used in this document for invoking the new matching rules. In our prototype server, we re-defined existing matching rules (e.g. substring) for the new matching rules, if they were applied to
the newly defined attribute types.
The other difference between the Dynamic Directory specification and the prototype are
the access protocols to external servers supported by the prototype. The prototype makes
use of proprietary string-based access protocols, since SOAP did not exist at the time of
development. One of the supported protocols makes also use of HTTP and XML for encoding operation invocations and results, but does not follow the latest SOAP specification
used in the Dynamic Directory specification.
Besides the differences in the access protocols mentioned above, most Dynamic Directory
features have successfully been implemented and used for implementing an Open Mobility Platform that possesses all capabilities like the ones specified in chapter 0. Undergoing
the implementation work was extremely important to identify missing pieces and conceptual inconsistencies in early stages of the Dynamic Directory Services specification.
1.35 Open Mobility Platform
We have implemented an Open Mobility Platform prototype using the Dynamic Directory
server prototype. Implementation of the Open Mobility Platform involved two aspects: Realising a Dynamic Directory schema and interfacing with external servers that interact with
communication and positioning infrastructures. Access to the Open Mobility Platform prototype is supported from desktop and laptop PCs using wired and wireless LAN networks.
Most LDAP-based mobility support services described in section 1.24 are supported by
the Open Mobility Platform prototype.
The Open Mobility Platform prototype maps the OMP information model defined in section
1.22 on a Dynamic Directory schema employing the mapping principles specified in section 1.23 and making use of the new Dynamic Directory operational attributes defined in
chapter 0. The Dynamic Directory OMP schema defines additional object classes that
have not been specified in section 1.22 to capture the operational information required by
a Dynamic Directory:
Object classes for entry templates using collective attribute subentries
The OMP prototype makes heavy use of entry templates (cf. section 1.31.2). This simplifies the creation of entries in the OMP prototype, since the operational attributes do
not have to be provided by directory clients but are added from the associated subentries automatically.
Page 234
Object classes for class templates
The OMP prototype supports a number of class scope events for which class templates
(cf. section 1.28.4.2.2) had to be defined.
Object classes for Adapter entries
To interface with external servers and to support event monitoring on externally-derived
attributes, subclasses of the ImportAdapter and ExportAdapter object classes
had to be defined for the OMP prototype.
The remaining Dynamic Directory schema is a rather strict mapping of the object classes
defined for the OMP information model on LDAP object classes. Most OMP attributes defined in section 1.22 have been realised with DirectoryString syntax attributes in the
OMP prototype. A difference that was already mentioned in section 1.23 is that externally
derived attributes are not directly defined for the OMP object classes shown in the UML
specifications. Instead, those object classes make use of internal attribute derivation from
Adapter object classes, which in turn perform the external attribute derivation.
The Open Mobility Platform prototype interfaces with the following external infrastructures:
Active Badge System
An Active Badge System installed at Philips Research Laboratories Aachen has been
connected by a proxy server to the Dynamic Directory server. The OMP prototype uses
the Active Badge proxy server to obtain externally derived attributes representing the
physical location of badges and to monitor the movements of badges within the building.
PBX with wired phones
A Philips SOPHO PBX system [Philips-PBC] consisting of two networked PBXs connected to wired ISDN phones has been connected to the OMP prototype. For each
PBX, a proxy server allowing downloading profile data has been implemented. The
proxy server is used by the OMP prototype to export user profile attributes to a wired
phone on which a user is registered, e.g. to enforce user-specific abbreviated dialling
numbers.
DECT cordless PBX
Two DECT cordless PBXs have been connected to the testbed, and a proxy server that
allows retrieving the current basestation to which a DECT terminal is attached and subscribing for notifications upon DECT terminal roaming events has been implemented.
This allows the OMP prototype to obtain externally derived attributes representing addresses and positions of DECT terminals and to monitor the roaming of DECT terminals
between DECT cordless PBXs.
Since no physical RF tag positioning system was available for our work, only a proxy
server for such positioning infrastructures has been implemented to emulate positioning
of tags with absolute coordinates.
An HTTP server was installed as external map server that contains XML-wrapped graphical images of the building covered by the OMP prototype. The graphical images are obtained by the Dynamic Directory as externally derived attributes being defined as part of
the Map object class in our prototype. This is an extension to the OMP schema proposed in section 1.22.3, where the graphicalMap attribute was defined as static.
Page 235
The overall physical structure of the Dynamic Directory server prototype and Open Mobility
Platform testbed realised in the course of this work is depicted in Figure 65. A number of
test applications have been built using the Open Mobility Platform prototype. They realise
most of the OMP example scenarios that were presented in this thesis to illustrate the usage of the Dynamic Directory capabilities.
Examples for application scenarios that we tested with the platform prototype are:
Positioning mobile users and devices
Mobile users may be positioned with Active Badges, DECT terminals, or emulated RF
badges within a building at Philips Research Laboratories Aachen.
Addressing a mobile user on a local phone
A mobile user positioned via a tag may have assigned a telephone number associated
with his or her local real-world terminal automatically.
Addressing a mobile user on a nearest device
This application assigns an address of a nearest device (e.g. fax or printer) automatically to a positioned user.
User registration on wired phones with automatic downloading of user preferences
A mobile user positioned via an Active Badge may be registered on a local phone and
have his or her user preferences - e.g. abbreviated dialling numbers - automatically
downloaded into the PBX and assigned to the physical phone.
DECT terminal roaming
A mobility management service that defines an event definition on changes on the
currentRoamingArea attribute of DECT terminals and updates its roamingArea attribute automatically has been realised.
ABS
Proxy
Server
Dynamic
Directory Server
ABS
Polling Box
ABS
Sensor
ABS
Sensor
ABS
Sensor
serial
PBX
Proxy
Server
V.24
DECT
Proxy
Server
V.24
ISDN
DECT
Controller
RF Tag
Proxy
Server
WLAN
LAN
HTTP
Server
mobile OMP client
Figure 65: Structure of Open Mobility Platform testbed
Page 236
ABS
Sensor
1.36 Summary
This chapter has discussed how the Dynamic Directory Services may be implemented
based on conventional directory servers. It has presented a layered architecture and an
approach called entry cloning that allows solving most of the new challenges with an extended main memory cache that assigns dedicated entry instances to concurrentlyrunning directory operations. Entry cloning solves the data consistency issues introduced
by internally and externally derived attributes and may be used for caching and event
handling, too. This chapter has further presented a prototype of an Open Mobility Platform
that implements most of the OMP application scenarios that were discussed throughout
this thesis. The presented prototypes have been invaluable means to iteratively improve
the concepts developed in this thesis.
Page 237
Discussion
This chapter reflects on the results developed in this thesis concerning their functionality
and scaleability. The aim is to point out critical issues we identified in the developed concepts and to evaluate whether the Dynamic Directory is suitable for the realisation of an
Open Mobility Platform for multi-site campus-area environments. For the latter, we calculate the upper limits on the number of supportable locatable objects and OMP clients depending on the number of employed Dynamic Directory servers.
1.37 Concept discussion
Directory-enabled networks and applications are a major trend of the last years. In parallel
to our work on Dynamic Directory Services, LDAP has gained enormous momentum, and
several extensions to and new applications of the original LDAP standard have been proposed. Several new directory APIs have emerged, and commercial high-performance
LDAP implementations supporting more than 8,000 base object search operations per
second [Keylabs00] have appeared as well as Open Source implementations for several
operating system platforms [OpenLDAP00]. This confirms in a way the relevance of our approach to choose LDAP directory services as base technology for the Open Mobility Platform. However, while working on this thesis we also identified some critical issues that deserve attention. In this section we address in particular the issues of using existing LDAP
APIs and applications, interpreting multi-valued attributes, and limiting the load of client
operations. All identified issues may be resolved with appropriate attention from application developers and Dynamic Directory server operators.
Usability of existing LDAP APIs and applications
One aim of choosing LDAP as OMP access protocol was to allow existing LDAP protocol
stacks, APIs, and applications to access the Open Mobility Platform. This was achieved
for LDAP protocol stacks by developing the new Dynamic Directory features without modifying the LDAP protocol proper, except for some additional service controls and return
codes. LDAP APIs with hard-coded service controls and a fixed set of return codes may
encounter problems in using and interpreting the additionally defined LDAP codes, or may
only invoke the default Dynamic Directory behaviour defined in this thesis.
Existing applications such as LDAP DIT browsers may encounter problems in using a Dynamic Directory server, if the server returns a no-success result, e.g., due to external
server problems or syntax errors in attribute derivation rules. In no-success cases, some
existing applications assume that no useful data was returned and ignore the entries returned by the Dynamic Directory server. This makes diagnosing and debugging the source
of the problems difficult for a user of such applications, since this behaviour prevents any
browsing through the DIT as long as the error occurs.
Page 239
To be able to subscribe to events, a requirement on LDAP APIs and applications is that
they must support asynchronous LDAP search operations, i.e. they must receive and
process search results, although the operation is not yet completed. Conventional browsers often support synchronous operations only, and even some LDAP APIs do not support
asynchronous search operations. Such functionally restricted APIs and LDAP browsers
should not try to use the new Dynamic Directory event handling services. If such limited
clients perform subtree searches below event definition entries, they will "hang" until the
LDAP search is successfully completed, i.e. when the event monitoring stops. We see this
as a functional defect of these clients and APIs and not as a problem of the Dynamic Directory, but users of such clients might be annoyed by "hanging" LDAP applications, since
usually no abort function is offered to users.
Interpretation of multi-valued attributes
A potential source of information ambiguity is introduced by the X.500 directory information model with multi-valued attributes. During our work we identified two problem types related to such attributes: A general directory service-inherent problem and an OMP-specific
problem.
The first type of problem may occur, if values of different multi-valued attributes are semantically related to each other. If, for example, a hooked object has multiple tags, multiple values of the position attribute and of the lastLocating attribute will be created one for each tag. From an OMP client point of view, however, there is no relation between
the values of both attributes besides their relative order. Our Dynamic Directory server implementation preserves the order of attribute values; but an application programmer must
make sure that the employed LDAP API does not change the order of attribute values.
Simple ordering may also fail, if one of the attributes has optional values. In this case it
would be necessary to replace missing optional values in one attribute with placeholder
values; this is currently not supported by the Dynamic Directory services. To reliably solve
this issue, one may attempt to define compound attribute values encoding two or more
values into a single string, but this complicates processing of attribute values in the application software.
The OMP-specific problem stems from the OMP information model allowing the position attribute to have multiple values, e.g. to allow an RF tag to be positioned in multiple
hierarchically contained areas. An OMP client retrieving such a tag entry may not immediately determine which of the entry’s position values is the most accurate one (being
that of a basic area or the smallest composite area). To provide unambiguous position information to applications, an easily deployable solution would be to define two types of
position attributes, one representing only basic areas, the other representing only composite areas. Another simple solution is to introduce an area-naming scheme that reflects hierarchical containment, as it is often found in buildings (e.g. building: G, floor: G1, room:
G116, etc.) and allows a client to determine which is the most accurate position value.
A more general approach to this problem based on confidence values of location information together with hierarchical location models similar to our area model was discussed in
[Leonhardt98]. However, the challenge is that different applications will have different requirements, whether the most confident position (i.e. the hierarchically highest area) or the
Page 240
most accurate position (i.e. the hierarchically lowest area) should be derived. A solution in
the OMP model could again be to derive multiple position attributes with different derivation rules, or to order the values of a single position attribute according to their accuracy or
confidence. These approaches can be easily included into the Open Mobility Platform and
Dynamic Directory Services in the future, if the need for such algorithms should arise.
Limiting the load caused by directory clients
In contrast to application platforms offering a fixed set of services to clients, directory clients may invoke arbitrary search operations on a Dynamic Directory server (subject to access right control) potentially generating huge load. Examples are search operations with
wildcards. They may lead to large numbers of returned entries; therefore, operators of
large OMP DITs will typically restrict the number of returned entries with an administrative
limit that overrides the limit specified by the client in the LDAP operation. Choosing the
appropriate limits requires knowledge about the application environment; it may even require employing client-specific administrative limits.
Furthermore, a Dynamic Directory search operation involving internally and externally derived attributes is more expensive to process than a conventional search operation. Client
operations or attribute derivation rules with filters on non-indexed attributes may lead to
large numbers of candidate entries for which attribute values must be determined. If the
search filter uses externally derived attributes, large numbers of external server invocations would be invoked additionally. This should be prevented by directory operators with
caching of internally and externally derived attributes to increase Dynamic Directory server
performance. The other solution - rejecting search filters with non-indexed attributes could impose too strict client limitations. A derivation rule programmer, however, should
use indexed attributes in the employed search filters whenever possible to maximise performance. A detailed discussion on the Dynamic Directory server performance and the resulting number of supportable clients is provided by the following section.
1.38 Scaleability evaluation
This section evaluates how the size of an Open Mobility Platform installation - i.e. the
number of clients it may support - scales with the number of employed Dynamic Directory
servers. Scaleability of the number of clients is limited by two factors: Size of the server's
main memory cache - for storing clones of directory entries - and the server's operation
throughput - for retrieving and modifying OMP entries and performing OMP event monitoring. How these limits influence the maximal size of an Open Mobility Platform installation
is discussed in the following. We make estimations for representative numbers of directory
entries and for the LDAP operation load generated by each OMP client in a multi-site
campus-area environment. From this, we calculate the upper limits on the number of
manageable OMP clients as function of the number of OMP servers.
Page 241
1.38.1 Memory limits
We make the following assumptions on the numbers of entries to be managed by the Dynamic Directory for an Open Mobility Platform installation in a hypothetical multi-site campus-area environment:
The OMP federation manages Nomp real-world mobile users. Each mobile user has a terminal and a tag associated. Users, terminals and tags shall be locatable federationwide; i.e. they must have home pointer entries replicated at every MMD.
The OMP federation is divided into Nmmd MMDs, each MMD manages the same number of
resident mobile users Nmu (i.e. Nmu=Nomp/Nmmd).
Each MMD is operated by an own OMP server.
Each mobile user is a client of OMP support functionality. The OMP federation therefore
has Ncu clients being equal to the number of mobile users. All clients have a subscription that is known federation-wide; i.e. they have OMPUser entries replicated at every
MMD.
The number of spatial areas managed by each MMD equals the number of its resident
mobile users (i.e. each user owns one spatial area on average).
A spatial area on average contains four static locatable objects (e.g. fixed tags representing non-mobile devices such as wired phones, PCs, etc.).
At each MMD, Nv visiting mobile users (with their terminals and tags) from other MMDs are
present at the same time on average. We assume that N v equals 10% of the residents.
At each MMD, Nev event definitions are defined. We assume that OMP clients altogether
define one event on each of the mobile users; and one event on each tenth spatial
area. Each event possesses on average Nnot=30 notification entries to buffer notifications of the last 30 minutes, as discussed in 1.38.2.
The Dynamic Directory implementation employs a main memory database for managing
cached entries and entry clones (cf. Figure 62). For each entry in the DIT, a master entry
is kept in the main memory as long as possible, since the creation and pre-processing of
the master entry is expensive in terms of processing effort. For each retrieval operation
being performed on entries with derived attributes, a clone entry is created in the main
memory, if re-use of clones for caching is disabled. This clone is kept as long as it is
needed for an ongoing operation and for other purposes, as discussed in section 1.34.3.1.
Not all clones that are no longer needed are immediately destroyed to limit the effort
needed for performing "clone housekeeping". Instead, clone housekeeping is periodically
invoked with configurable interval length. The number of clones present for one entry
therefore depends on the ratio between the rate at which clones are created and the interval between two housekeeping operations. We assume the following numbers of clones:
For each master entry with derived attributes, Nc=10 clones are existing on average at the
same time. For entries with static attributes only (except alias entries and OMPUser entries), we assume that one clone exists at the same time (created by operation-consistent
directory operations). Alias entries, OMPUser entries, event definitions and notifications
are assumed to be not cloned (i.e. cloning is suppressed with the doNotClone attribute,
see 1.34.3.1).
Page 242
From these assumptions, we have calculated the achievable number of MMD Federation
users (i.e. OMP clients) and the number of users per OMP server for a Dynamic Directory
server main memory size of 2 GB. The dependency of these numbers from the number of
employed OMP servers is shown in Figure 66. The calculation details can be found in Appendix F. How the relative memory usage of different entry types depends on the number
of OMP servers is shown in Figure 67.
Discussion
Campus-area environments with up to 18,912 OMP clients may be managed by a single
Dynamic Directory server as far as the memory limits are concerned. The overall number
of manageable users in an MMD federation can be increased to more than one million users. This should be sufficiently large for most real-world companies and organisations.
From this we conclude that, although the Dynamic Directory architecture makes extensive
use of main memory caching for entry cloning, the size of Dynamic Directory server's
physical main memory imposes no practical limitations to applying the Open Mobility Platform in multi-site campus-area environments.
1000000
20,000
18,000
800000
16,000
700000
14,000
600000
12,000
500000
10,000
400000
8,000
300000
6,000
200000
Users per OMP server
Users in MMD Federation
Users in MMD Federation
900000
4,000
Users per OMP server
100000
2,000
248
235
222
209
196
183
170
157
144
131
118
105
92
79
66
53
40
27
14
-
1
0
Number of MMDs / OMP servers
Figure 66: Number of MMD Federation users limited by OMP server main memory
An analysis of the main memory usage of different types of OMP entries shows that the
limitation on the overall number of users is strongly influenced by the number of alias and
OMPUser entries. This is so because these entries are not distributed over the servers; on
the contrary, they are replicated over the servers to make users and locatable objects federation-wide known. In our scenario, 50% of main memory usage are caused from these
entries, if 540,000 users are managed. Therefore, care must be taken that these entries
are not cloned by the Dynamic Directory during operation-consistent directory operations.
Page 243
Additionally, only those entries should be replicated over OMP servers that must really be
known federation-wide. As a further potential optimisation, a Dynamic Directory server
should store globally replicated entries with as little main memory as possible; i.e. any
overhead in the entry data structures not needed for these object classes should be
avoided.
Buffering of event notifications should only be used, if really needed by the OMP clients,
since these entries may consume considerable portions of the available main memory, in
our scenario up to 30% for small MMD Federations. The number of notifications stored
with an event definition should therefore be minimised by setting the smallest possible notification entry lifetime that the mobile applications may tolerate.
100%
Home pointer and
OMP user entries
90%
70%
60%
50%
Event
definition
and
notification
entries
241
226
211
196
181
136
Fixed tag entries
121
106
91
76
61
1
0%
Spatial area and locatable
object entries with internally
derived attributes
46
10%
31
20%
166
30%
151
40%
16
Relative memory usage
80%
Number of MMDs / OMP servers
Figure 67: Relative memory usage of OMP entry types
1.38.2 Performance limits
Besides main memory constraints, a Dynamic Directory server imposes further limits on
the number of clients it may serve, constrained by the maximum operation throughput it
achieves. Depending on the load generated by each OMP client, the number of supportable clients is calculated in the following to explore these limits. Since our Dynamic Directory server prototype has not been optimised for processing performance, we may not use
measured throughput numbers for the following calculations. Instead, we prefer to estimate the operation throughput that could be achieved with an implementation performing
as well as state-of-the-art directory servers.
Results from professional performance tests of Novell's NDS and Microsoft's Active Directory servers have been published in [Keylabs99]. From this source, we derived throughput
Page 244
numbers of tests on a five million entries DIT, which comes close to the number of OMP
entries calculated in the previous section. In those tests, an Active Directory server
achieved a throughput of approx. 2,000 subtree searches per second on a four-processor
(Intel III, 550MHz, 2GB RAM) workstation10. We use this number as achievable search
operation throughput in our calculations - assuming that the additional processing overhead introduced by interpreting the new Dynamic Directory operational attributes will be
compensated by faster hardware that has become available since those tests have been
performed.
For update operations, no performance measurements of Active Directory are available.
From another study on the performance of the Isode LDAP/X.500 Enterprise Directory
Server [Isode97], we extrapolated that on hardware comparable to that of the Active Directory test, at least 36 non-indexed updates or 9 indexed updates per second should be
achievable. Since updates of non-indexed attributes are mainly delayed by disk write and
I/O subsystem delay [Isode97], we assume that the CPU processing effort of a non-indexed
update equals one search operation. The CPU costs of indexed updates relative to one
search operation are assumed to be inverse proportional to the maximal throughput (i.e.
one indexed attribute update costs as much as 2000/9=222 search operations).
To calculate the load on a Dynamic Directory server, we have to make assumptions on the
number of directory operations invoked by each OMP client. In contrast to conventional directory servers, we must take into account that a single client operation may cause multiple server-internal operations, if entries with internally derived attributes are involved. Additionally, we have to include effort for processing externally derived attributes and for
processing events. In the following, two usage scenarios are discussed. In the first scenario, OMP clients only perform queries to the server, whereas in the second scenario, the
OMP clients define events but perform no queries. Both scenarios assume the same
number of update operations from clients. In a real Open Mobility Platform deployment, a
mixture of these load conditions will be found.
Retrieval scenario
In the retrieval scenario we assume that OMP clients heavily invoke retrieval operations on
locatable objects and spatial area entries to poll the Open Mobility Platform for position
and address information about mobile users and terminals. We assume the following in
addition to the statements of section 1.38.1:
Each OMP client performs on average one query for a HookedObject entry every ten
seconds. Each client query leads to six OMP server-internal search operations caused
by internally derived attributes (one LDAP search from client plus internal searches for
a registered terminal, for an associated tag, for an Adapter, one external invocation to
an external server (assumed to be as expensive as a search operation) and one internal search for a SpatialArea entry).
Each OMP client performs on average one update every 10 minutes on non-indexed attributes, e.g. for changing profile properties, and one update on indexed attributes once
10
To avoid over-optimism, we chose a test scenario where the Active Directory server did not
benefit from internal caching. With caching, performance grew to 2,376 operations per second.
Page 245
per hour, e.g. for changing terminal or tag registrations. This update load also contains
non-indexed updates from mobility management services on roaming area identifiers of
mobile locatable objects.
For each tenth SpatialArea entry, one client query is performed every ten seconds.
Each client query leads to eight OMP server-internal search operations caused by internally derived attributes (one LDAP search from client plus an internal search for an
Adapter, one external invocation, one internal search per each mobile tag that is positioned in the area (on average one), and one internal search per fixed tag positioned in
the area (on average four as assumed in 1.38.1)).
Each fixed tag is updated once every 24 hours on non-indexed attributes, e.g. for changing profile properties, and once every 48 hours on indexed attributes, e.g. for moving
them into other spatial areas.
This scenario represents an enormous load on the OMP server, since every client polls
the server for position or address information. For these assumptions, we have calculated
(see also Appendix F) that each OMP server may handle approx. 2,449 OMP clients simultaneously, if the OMP server does not employ caching of internally derived attributes.
As can be seen in Figure 68, the number of OMP users that may be managed in an MMD
Federation grows linearly with the number of servers, and is for a given number of servers
considerably lower than the limit imposed by the OMP server's main memory.
To investigate the impact of caching on OMP performance, we have also calculated the
numbers of users that may be managed, if the OMP server employs caching of internally
derived attributes in LocatableObject and SpatialArea entries. For caching periods
of 20, 30, and 60 seconds the resulting numbers of MMD Federation users are depicted in
Figure 68. As can be seen, caching allows an OMP operator to increase the number of
manageable users significantly – with the disadvantage that the dynamic information returned to OMP clients is less up-to-date than without caching. The optimal compromise
between data freshness and tolerable server load must be determined by an OMP operator for a given OMP application environment.
Event scenario
In the event scenario, clients do not query the OMP server for information repeatedly; instead, they define events to be informed about changes in the information of interest:
Each OMP client has defined one entry-scoped event on a HookedObject entry that fires
once per minute. The event processing effort equals the effort of a client-initiated
search plus one operation for creating the notification entry - assumed to be as expensive as a search since it creates a soft entry in the cache only. The resulting effort
equals seven search operations.
For each tenth spatial area, an entry-scoped event is defined that fires once per minute.
As discussed above, the effort equals the number of search operations from the retrieval scenario plus one additional operation for notification creation, resulting in nine
search operations.
The scenario has to take into account that notification entries must be deleted once their
lifetime expires. We assume a lifetime of 30 minutes (therefore, 30 notification entries
Page 246
exist on average per event, as also assumed in section 1.38.1) and assume that deleting a notification is as expensive as creating it.
Updates from OMP clients occur in this scenario as often as in the retrieval scenario. Defining events causes additional updates to the directory database. We assume that an
event definition is as expensive as an indexed update plus the effort for searching for all
scoped entries of the event. An additional indexed update is required to remove the
event definition entry from the DIT.
The definition of OMP client-defined events is assumed to be spread over a period - i.e.
not all events are defined simultaneously - to allow distribution of this processing effort.
We assume that all event definitions are spread over a period of four hours, i.e. each
OMP client defines on average six events per day.
Class-scoped events are assumed to be defined during server start-up, since they cause
considerable processing load growing linearly with the number of entries belonging to
the monitored object class and the number of source entries referenced by those objects.
For these assumptions, we have calculated that an OMP server is able to handle 7,512
OMP clients simultaneously. For up to 86 OMP servers (i.e. MMD Federations with less
than 650,000 users), this is less than the limitation imposed by main memory. For larger
numbers of servers, the number of users is limited by main memory, as shown in Figure
68.
1000000
Users in MMD Federation
900000
retrieval
30s cache
800000
retrieval
60s cache
700000
retrieval
20s cache
event
600000
500000
memory
limit
retrieval
no cache
400000
300000
200000
100000
241
229
217
205
193
181
169
157
145
133
121
109
97
85
73
61
49
37
25
13
1
0
Number of MMDs / OMP servers
Figure 68: Number of MMD Federation users limited by OMP server performance
A detailed view for up to 350,000 users and up to 40 OMP servers is depicted in Figure
69.
Page 247
350000
memory
limit
event
Users in MM D Federation
300000
retrieval
60s cache
250000
200000
retrieval
30s cache
150000
retrieval
20s cache
retrieval
no cache
100000
50000
0
0
5
10
15
20
25
30
35
40
Num ber of M MDs / OM P servers
Figure 69: Number of MMD Federation users limited by OMP server performance
How the processing load of the Dynamic Directory server is distributed over different types
of operations is shown in Figure 70 for the scenarios discussed in this chapter. As can be
seen from the figure, update operations and event definition operations (involving updates
too) make up significant portions of the overall load for scenarios with a large number of
users. This suggests that in order to support even more OMP users with a given number
of servers, update performance of directory servers should be increased, and indexed attribute updates and event definitions from OMP clients should be minimised as much as
possible.
We have also calculated that the definition of a class-scoped event on an object class
HookedObject requires 18.8 seconds initialisation time for 7,512 OMP users being managed by an OMP server, suggesting that this should be done during or directly after OMP
server start-up or during times of low load from OMP clients.
Page 248
2000
Search-equivalent operations
1800
event
evaluation
1600
1400
search
1200
1000
800
event
definition
600
400
update
200
0
1
retrieval
no cache
2
retrieval
20s cache
3
retrieval
30s cache
4
retrieval
60s cache
5
event
Figure 70: Distribution of OMP server load
Discussion
The scenarios discussed in this chapter represent high-load situations but no absolute
worst-case scenarios, since the load caused by OMP clients may in reality deviate from
our assumptions. However, as shown in the retrieval scenario, OMP operators may effectively protect an OMP server against high retrieval load by employing caching of internally
derived attributes. The principally achievable throughput of the Dynamic Directory server
has been estimated from published performance measurements of commercially-available
LDAP servers, since our implementation has not been optimised for processing throughput preventing representative measurements.
Nevertheless, we believe that a number of important conclusions may be drawn from the
considerations of this chapter:
OMP clients that wish to have up-to-date information should preferably register an entryor collection-scoped event instead of polling the OMP server for changes. This dramatically increases the number of users that can be supported with a given number of OMP
servers as compared to the load generated from polling, especially if no caching is
used.
Processing effort for a client-initiated search grows linearly with the number of source entries from which internally derived attributes are obtained. For entries with large numbers of source entries, and in environments with a high retrieval load from OMP clients,
caching of derived attributes should be employed by OMP operators to reduce server
load.
Attributes modified by OMP clients should only be indexed if they are used as filter criteria
in search operations that must be processed with highest performance. Therefore, identification and registration attributes (e.g. attachedTag) should always be indexed on
equality, but attributes that are subject to more frequent client modifications should be
indexed only, if needed by applications for fast searching. A compromise between
Page 249
search performance in yellow pages services - which benefits from indexing - and update performance - which suffers from indexing - must be found by OMP operators depending on the application environment and the update load caused by clients.
Processing effort for defining and evaluating events grows linearly with the number of entries falling into the event scope. The definition of events with class scope should be restricted to selected OMP clients only, e.g. to mobility management services. Alternatively, event definitions should be shared between clients; the latter also helps to reduce the number of notification entries that have to be managed.
Not all OMP clients should define their entry- or collection-scoped events at the same
time. Instead, this effort should be distributed as evenly as possible over time. In office
environments where many OMP clients are started around the same time in the morning, events should not be deleted at the end of the day but should be kept alive overnight to spread their definition effort over time.
Defining class-scoped events may cause significant processing load since they involve initialising pre-event values of all entries belonging to the object class. Class-scoped
events of general interest should preferably be defined during or directly after OMP
server start-up or during times of low load from clients.
1.39 Summary
In this chapter, we have discussed some critical issues related to the concepts we developed in this thesis that deserve attention by future Dynamic Directory users and operators.
In particular, the issues of using existing LDAP APIs and applications, interpreting multivalued attributes, and limiting the processing load generated by clients have been addressed. Most of these issues may be easily resolved, if application developers and Dynamic Directory server operators pay attention to the traps we identified and choose appropriate configuration parameters and APIs.
We have also shown that the achievable number of OMP clients is large enough to apply
the Open Mobility Platform in multi-site campus-area environments. More than one million
OMP users may be supported, which should be enough for even large multi-national companies and organisations. For environments having less than 650,000 OMP clients - being
the majority of multi-site campus-area environments in practice, the limits on number of
users will be imposed by the performance of the OMP server, rather than by the size of
the server's main memory cache. Furthermore, an OMP operator may influence the OMP
server performance significantly by choosing appropriate caching parameters, attribute indexing strategies, and administrative limits. The calculations have indicated that caching
of derived attributes allows lowering the load on an OMP server considerably.
This chapter has shown that the Dynamic Directory Services developed in this thesis allow
to realise an Open Mobility Platform for multi-site campus-area environments and has
confirmed the suitability of our entry cloning approach proposed for Dynamic Directory
server implementation. The next chapter discusses which other types of applications - beyond supporting mobility - are enabled by the new generic Dynamic Directory features.
Page 250
Other Dynamic Directory applications
The functional scope of the Dynamic Directory Services we developed in this thesis was
defined based on requirements we identified for the realisation of an Open Mobility Platform. The new directory service capabilities we developed from these requirements were
designed in such a way that they are of generic applicability. The new directory features
are not limited to mobile applications but are useful for numerous other directory applications. This chapter briefly identifies other application areas that will benefit from the Dynamic Directory Services' capabilities that were not already mentioned as applications of
the Open Mobility Platform support services.
Network and systems management
There is a trend towards "directory-enabled networks", where all kinds of operational information are stored in a logically centralised directory service. Associated with this is a
design philosophy, where network management information reflecting the current operational state of networking and computing equipment can be accessed via directory protocols, such as LDAP or Novell's NDS, from a logically centralised repository, instead of using conventional network management protocols such as, e.g., SNMP. It provides an integrated view on management information from multiple network resources and captures
the relations between devices as well as between users and devices. This has the advantage of applications sharing directory information and network management information
with the same suite of access protocols.
The Distributed Management Task Force [DMTF00a] industry consortium is specifying a
generic network management information model and defines mappings of that model on
directory schemas, e.g. for LDAP [DMTF00]. Several manufacturers have already started to
integrate directory protocol stacks into their products for management purposes. Microsoft
is integrating all management information related to users and computers into an LDAPbased directory to provide a single centralised repository of configuration management information. Another network management-related application is the storage of policy information in a logically centralised directory that is retrieved from the devices that enforce the
specified policies. This may, for example, be used to enforce Quality-of-Service policies in
communication networks by managing an LDAP-based policy information model [Strassner00].
With the new Dynamic Directory features it will be possible to provide additional features
in such directory-enabled networks. With the externally derived attributes, management
information could be dynamically obtained from equipment; with exported attributes, management operations could be performed on the equipment, and the event handling features would allow the definition and monitoring of management information. Internally derived attributes would allow to model data being dependent on the relation to other managed objects, e.g. status information, addresses, user registrations, etc.
Page 251
Cache and replica synchronisation
Several applications make use of cached or replicated directory information. The replicated information is either presented to the user in a GUI or is held in a local cache that
answers retrieval requests locally instead of sending a request to the server. The new Dynamic Directory event handling mechanisms allow a client to request the server to notify it,
if replicated information changes. Upon the receipt of notification messages, the client
may then update its screen contents or its local entry cache.
Personalised systems
Personalisation of devices and services according to user preferences and allowances requires access to a repository containing the profiles of users. Directories are already beginning to be used for such purposes, e.g. in the latest Microsoft operating systems, all
personalisation information are held in a directory service. One approach to personalisation is to enforce the personalised systems to retrieve profile information from the directory
repository. A complementary approach, which we used also for the Open Mobility Platform, is to replicate information held in the directory to external infrastructures for enforcing the user profile settings. The Dynamic Directory attribute export features allow the personalisation of all systems for which external server access protocols may be realised in
the directory server. With the emerging availability of SOAP converters, the Dynamic Directory server will be usable to export centrally managed user profile settings to numerous
applications and devices that require personalised configuration settings, e.g. in communication networks or on entertainment equipment in the emerging In-Home Digital Networks.
Electronic Bulletin Boards and Meeting Places
Directories traditionally have been systems in which updates occur much less frequently
than do retrieval operations. Dynamic Directory servers that allow the efficient management of non-persistent information (by avoiding database disk updates) will enable numerous applications, where information with a limited lifetime shall be stored. Examples
are electronic bulletin boards or meeting places, where some users post their announcements, service offers, or other information that are of potential interest to other users who
search the directory for such information. An example of such application is Microsoft's directory-based Site Server that supports NetMeeting users to find each other on the Internet (cf. section 1.3.2).
The Dynamic Directory Services allow to manage such information efficiently, impose lifetime boundaries on the information, include information from external servers to provide
even more up-to-date information, and allow users to monitor the information provider by
using the event handling capabilities.
Geographic information services
A new capability of Dynamic Directory servers is the ability to associate any directory information with three-dimensional coordinate ranges. This allows directory users to search
only for information that is relevant to their current spatial position obtained, for example,
from a GPS receiver. To offer such a service on a wide-area scale, efficient
Page 252
containment matching rule implementations using dedicated database backends with
spatial indexing would be beneficial.
Traders and service brokers
Dynamic Directories may provide service selection features to provide trading functionality.
This is used in the Open Mobility Platform, but is also useful for numerous other applications - e.g. service brokers allowing to find cheapest services - to select directory entries
that fulfil search criteria optimally.
Dynamic white and yellow pages services
Conventional white and yellow pages services only contain static information that is returned to the clients. The external attribute derivation feature of the Dynamic Directory
Services allows implementing a late information binding approach, where additional information is added to a directory entry upon retrieval. Example applications cover inclusion of
presence or location information into email directories, include occupancy information or
up-to-date images within entries representing real-world places or rooms, etc. The same
obviously applies to trading services, they have already been discussed as applications of
the Open Mobility Platform based on Dynamic Directory Services.
Directory attributes with large values
An additional advantage of the Dynamic Directory features is that not all information returned by directory entries really must be stored in the directory database. This allows
employing dedicated storage mechanisms for large-valued attributes including sound or
image contents. A conventional directory server might even try to keep such information
in its cache, which would heavily degrade the number of entries being manageable in that
cache.
As can be seen from these examples, Dynamic Directories provide generic and powerful
concepts that are applicable outside the context of mobility support. The presented list is
not exhaustive; numerous other applications may benefit from our new directory features.
Page 253
Summary and outlook
The aims of this thesis were twofold: The specification of an Open Mobility Platform that
supports mobility management services and mobile and location-aware applications, as
well as the development of functionally enhanced directory services - called Dynamic Directory Services - on which the platform may be realised. The platform should be open by
supporting standardised access protocols and by enabling functional customisation and
extension by its users. The scope of the Open Mobility Platform is multi-site campus-area
environments.
A number of principal questions had to be answered to achieve these aims:
Which support functionality should be offered by an Open Mobility Platform?
Is it possible to integrate the platform's support services into a consistent homogeneous
information model?
Is it possible to define an Open Mobility Platform model that supports functional customisation by its users?
Is it possible to map such information model on an X.500 information model?
Is it possible to use LDAP access services to realise the support services on such information model?
Which functionality is missing in the current set of X.500 and LDAP standards to realise
the information model and the support services?
May the new functionality be defined as generic directory extensions that are applicable
beyond supporting mobility?
What are the information and operational models of the resulting Dynamic Directory Services?
How may the new directory features be implemented as extensions to available directory
server software?
Do the developed concepts scale up to a sufficiently large number of clients to be applicable for multi-site campus-area environments?
To answer the first question we performed an analysis of available techniques that support
the realisation of mobility and the development of location-aware applications. To structure
the wealth of available techniques, we derived a four-level framework that defines mobility
abstraction levels, classifying the degree to which mobility is hidden from applications and
control services. The framework also identifies the most useful support techniques for
each level. A mobile application or mobility management service does not have to fall into
only one category, but may make use of any combination. From the analysis we identified
the support services to be included into the Open Mobility Platform by excluding all functions that are not related to handling control information but are related to managing connections or processing content. Furthermore, functions being too specific or environmentdependent were excluded, resulting in these OMP support functions: Location handling
services, profile handling services, event handling services, directory - i.e. white and yellow pages - services, trading services, security services, and discovery services.
Page 255
The second achievement of our work is the specification of an Open Mobility Platform information model that defines a homogeneous object class model on which all the identified support services may be offered. The information model consists of three basic packages: The Subscription Framework defines all required object classes to support subscription of mobile objects and users to the platform and to structure the campus-area and
multi-site environment into Mobility Management Domains. The Positioning Framework
defines all object classes required to support spatial location-handling services and location-aware applications, including the definition of a real-world location model consisting of
hierarchically structured spatial areas. The Addressing Framework supports all applications and control services that require communication addresses of mobile real-world entities. Both Frameworks employ as common abstract class the LocatableObject that
may make use of positioning and addressing functions by aggregating the associated
framework classes.
The major advantage of the Open Mobility Platform model compared to previously developed platform models is the strong support for run-time customisation and extensions by
the users of the platform. One way of customisation is achieved by deriving subclasses of
the framework object classes to adapt the functionality to new communication and positioning infrastructure technologies. This kind of customisation could be performed by administrators of the Open Mobility Platform or by infrastructure equipment providers. The
other type of customisation is achieved by defining additional auxiliary object classes that
may be aggregated with the framework object classes to add application- or environmentspecific attributes to the information model. This type of customisation will typically be
done during installation of the Open Mobility Platform in a particular environment. As part
of this work, we already defined customisation object classes for the most popular positioning technologies and user mobility features. Following these examples, it should be
straightforward to define additional customisation packages, if required in the future for
new technologies.
The next step of our work was to investigate whether the OMP information model can be
mapped on an X.500 information model. We identified which existing X.500 information
model elements are required to realise the specified OMP model and identified a number
of features that are currently not supported in the directory models. Assuming that the
missing features could be provided by our new Dynamic Directory Services, we investigated for each OMP support service how it could be realised based on LDAP services operating on the OMP information model. During this discussion, further requirements on the
Dynamic Directory Services were identified. The outcome of these investigations was the
finding that all identified support services may be realised with the proposed OMP information model, if the following additional features are developed as part of the Dynamic Directory Services: Internally derived attributes, externally derived attributes, event handling
functionality, exported attributes, spatial matching and nearest matching.
All these new directory capabilities were then developed as extensions to the X.500/LDAP
directory service specifications. We designed the extensions as generic features that are
not limited to the mobility support domain but may be useful for many other directory applications. The main extension to conventional directory services is the support of dynamically obtained information and of event handling. The Dynamic Directory is able to derive
Page 256
attribute values on-demand from internal or external sources. The attributes that shall be
derived and the entries or servers that shall provide the values may be specified in attribute derivation rules that are stored as operational attributes in the directory entries. The directory becomes programmable by its users, since the derivation rules may be added or
modified during operation of the Dynamic Directory server. To facilitate and control the
creation of these rules, we employed entry templates that may contain the operational attributes and provide them to all entries belonging to the same object class. This is useful
for the definition of application platforms, where users are allowed to add new entries to
the directory, but the operational information belonging to these entries may stay under
the control of the directory administrator.
To support derivation of attribute values from external servers, we defined operational attributes that allow invoking external methods and receiving results from those methods by
means of the emerging Simple Object Access Protocol SOAP. We defined methods to include parameters in the invocation and to extract LDAP attributes from the XML payload
received with the SOAP response. This will allow the interaction of Dynamic Directory
servers with numerous external servers since SOAP promises to become a generic RPC
mechanism that will interoperate with many of today's object invocation technologies.
The other major new capability is Dynamic Directory event handling that allows directory
clients to be informed about changes in the Dynamic Directory server. We developed an
event definition format that specifies the changes to the DIT contents that shall cause an
event to fire. The changes may affect static attributes as well as internally and externally
derived attributes. The resulting event triggers that define which entries and attributes
have to be monitored subsequently are generated automatically by the Dynamic Directory
server. The server checks after each LDAP operation whether it affects an event trigger
and evaluates all associated event conditions. To monitor changes in externally derived
attributes, the server may make use of monitoring subcontracts with the external servers.
Clients that are interested in events must explicitly subscribe to event definitions to receive
notification messages. An important advantage of our approach is that event definitions
and notifications are represented as directory entries that may be accessed by clients using the conventional LDAP services. This also allows clients to re-subscribe to events after
periods of temporary unavailability to receive all or selected notifications that have been
missed in the meantime as well as to share event definitions between multiple clients.
Exported attributes introduce a new synchronous replication method that allows updating
external servers upon modifications to the Dynamic Directory contents. This augments the
proposed LDAP and X.500 replication mechanisms, which are all of asynchronous nature.
Spatial matching and the associated new attribute syntax definitions representing threedimensional shapes in a Cartesian coordinate system allow managing spatial information
in the Dynamic Directory. The new matching rules allow retrieving directory entries based
on their absolute position or based on their containment in rectangular solids. These
mechanisms allow using information obtained from absolute positioning systems in conjunction with directory services, enabling a wealth of application possibilities. Nearest
matching is the other new type of matching, allowing the directory client to specify one or
more criteria values that are used by the Dynamic Directory server to sort the matching
Page 257
entries before they are sent to the client. Based on this capability trading services may be
offered by the Dynamic Directory without further effort.
In parallel to the development of the Dynamic Directory Services specification, we performed a prototype implementation of a Dynamic Directory server to validate the completeness and usefulness of the new features and to improve the specifications iteratively.
To allow the implementation of the Dynamic Directory server based on existing server
software, we identified an architecture that introduces an additional layer, called Dynamic
Entry layer, into conventional three-layered directory server architectures. The layer encapsulates most of the new features related to derived and exported attributes and realises the creation and monitoring of event triggers. This approach tries to minimise the
changes on the conventional directory server software. We implemented an LDAP information model realising the OMP information model, and interfaced the Dynamic Directory
server prototype with external communication and positioning infrastructure to build an
Open Mobility Platform server prototype. The system has been integrated with wired and
cordless PBX systems and with an Active Badge positioning system. In this test environment, the information model elements and support services defined for the Open Mobility
Platform have been prototypically realised and tested.
Finally, we evaluated the functionality and the scaleability of the Open Mobility Platform.
To determine the number of clients the platform is able to support depending on the number of employed OMP servers, we calculated the upper limits imposed by main memory
and server performance for different usage scenarios and caching parameters. We concluded that the number of supportable clients is large enough to apply the Open Mobility
Platform in multi-site campus-area environments. More than one million OMP users may
be supported which should be enough for even large multi-national companies and organisations. For the greater part of campus-area environments, the practical limits on the
number of users will be imposed by the performance of the OMP server, rather than from
the size of the server's main memory. Furthermore, the calculations have shown that OMP
operators may employ caching of derived attributes to effectively lower the load on an
OMP server. These findings confirm the suitability of the entry cloning approach developed by us for realising Dynamic Directory servers.
Outlook
During the work on this thesis, a number of further interesting questions were identified,
offering several challenging research tasks in the future. One interesting problem area is
to improve the performance of Dynamic Directory servers by employing dedicated database backends. By using spatially-indexed databases, the processing of containment
matches might be improved significantly, if the three-dimensional containment matching
rules can be mapped on appropriate indexing mechanisms (cf. [ Adly97]). The other possibility for performance improvement is the use of Active Database Management Systems
as backends to support the processing of update events on static attributes. Here, the
challenge will be to map the entry and class triggers on event mechanisms supported by
the ADBMS. Further enhancements might be gained by optimising the processing of internal attribute derivation rules using pre-processing of rules. Much performance is lost in the
current prototype with parsing and interpreting the string-encoded derivation rules upon
entry retrieval time and sorting the rules into an executable sequence. By pre-processing
Page 258
the rules into an efficiently interpretable format, major performance gains may be expected.
Besides server performance, the issue of server availability must be further looked at. Directory systems become mission-critical servers in communication networks. By basing
additional applications on top of those services, the dependency on directories grows even
further. A fascinating research topic will be the development of directory server replication
mechanisms that allow enhancing the availability of a Dynamic Directory service. We already developed a causal replication mechanism for X.500 directory servers [ Maass94] that
could be adapted to LDAP servers in the future. The question will be how to integrate the
new directory features into the replication framework, including increasing the availability
of event definitions, combining externally derived attributes and exported attributes with
server replication, and related issues.
Another valuable research topic could be the investigation into how the new Dynamic Directory features combine with distributed directories using chaining of requests. The current Dynamic Directory possesses the same limitations as LDAP, meaning that only referrals but no chained requests are supported. Interesting issues would be to investigate the
use of chaining for deriving attributes from source entries held by other LDAP servers, and
to extend the scope of event definitions from one LDAP server to multiple LDAP servers.
After solving these issues, it would also be possible to integrate the new Dynamic Directory features into full-fledged X.500 servers, since on information model level all Dynamic
Directory features have been based on the X.500 information model.
The second area of potential future investigations is to develop programming support for
application developers using the Dynamic Directory. An application developer could be
supported in exploring the schema of a directory server including visualisation of allowed
aggregations, options for deriving subclasses, and available entry templates. Starting point
for such programming support could be the UML-based directory schema specification
methodology used in this thesis. The developer should have easy-to-use means for defining derivation rules to build new applications using the Dynamic Directory operational attributes. Further improvements would be possible from the development of dedicated APIs
that support the new Dynamic Directory features. The definition of events and the subscription to them could be simplified with easy-to-use API functions; initial proposals for
events in directory APIs are already emerging [JNDI00]. A more general research topic is
the question, whether the LDAP query model could be enhanced to provide more powerful
retrieval operations to applications. As an example of potential future directions, in [Jagadish99] a marking language is proposed that specifies operators to select entries from hierarchical relations, allows computing aggregates and selecting entries from them, and allows to select entries by value semijoin operators. These operators work against hierarchical data models such as X.500 or LDAP, and the usefulness for mobile application support
and their combination with the Dynamic Directory features could present interesting challenges.
Finally, adapting the Open Mobility Platform's information model to other mobility support
approaches such as e.g. SIP or NetMeeting user mobility as well as exploring other possible applications of the Dynamic Directory Services, will be highly interesting research
Page 259
tasks. The era of directory-enabled applications is just beginning and new types of applications we do not know today will emerge. Dynamic Directories provide sophisticated new
capabilities for handling dynamic and spatial data in directory-based environments that will
be useful for numerous applications.
Page 260
Abbreviations
3GPP
Third-Generation Partnership
Project
DUA
Directory User Agent
ABS
Active Badge System
EDGE
Enhanced Data rates for GSM Evolution
ACAP
Application Configuration Access
Protocol
ETSI
European Telecommunications
Standards Institute
AMPS
Advanced Mobile Phone System
FDMA
Frequency Division Multiple Access
ADBMS
Active Database Management System
GLONASS
Global Navigation Satellite System
AMS
Active Map Server
GNSS
Global Navigation Satellite System
API
Application Programming Interface
GPRS
General Packet Radio Service
ASI
Atomic Step Identifier
GPS
Global Positioning System
AST
Atomic Step Type
GSM
AVA
Attribute Value Assertion
Global System for Mobile
Communications
BNF
Backus-Naur Form
HLR
Home Location Register
bps
bits per second
HSCSD
High Speed Circuit-Switched Data
CAMEL
Customised Applications for Mobile
network Enhanced Logic
HTML
HyperText Markup Language
HTTP
HyperText Transfer Protocol
CDMA
Code Division Multiple Access
IDL
Interface Description Language
CDPD
Cellular Digital Packet Data
IEEE
CMIP
Common Management Information
Protocol
Institute of Electrical and Electronics
Engineers
IETF
Internet Engineering Task Force
CMR
Call-to-Mobility Ratio
IMSI
International Mobile Station Identity
CORBA
Common Object Request Broker
Architecture
IMT2000
International Mobile Telecommunications 2000
CS
Capability Set
IN
Intelligent Network
CTM
Cordless Terminal Mobility
INAP
DAP
Directory Access Protocol
Intelligent Network Application
Protocol
DCE
Distributed Computing Environment
IP
Internet Protocol
DCOM
Distributed Component Object
Model
IR
Infrared
ISDN
Integrated Services Digital Network
DECT
Digital European Cordless
Telecommunications
ISM
band
Industrial, Scientific, and Medical
band
DHCP
Dynamic Host Configuration
Protocol
ITU-T
International Telecommunication
Union - Telecommunication Sector
DIT
Directory Information Tree
JDC
Japanese Digital Cellular
DN
Distinguished Name
Jini
Java Infrastructure for the Internet
DNS
Domain Name System
JPEG
Joint Photographic Expert Group
DSA
Directory System Agent
LAN
Local Area Network
DSE
DSA-Specific Entry
LCMR
Local Call-to-Mobility Ratio
DSP
Directory System Protocol
LDAP
Lightweight Directory Access
Protocol
Page 261
Layer
LDIF
LDAP Data Interchange Format
LEO
Low Earth Orbit
SDF
Service Data Function
LTAP
Lightweight Trigger Access Process
SIM
Subscriber Identification Module
MAP
Mobile Application Part
SIP
Session Initiation Protocol
MASE
Mobile Application Support Environment
SLAPD
Stand-alone LDAP Daemon
SLP
Service Location Protocol
MLS
Master Location System
SMS
Short Message Service
MMD
Mobility Management Domain
SNMP
MNP
Mobile Number Portability
Simple Network Management
Protocol
MOBIDICK
Mobile Data InterChange Kit
SOAP
Simple Object Access Protocol
SS7
Signalling System no. 7
MPEG
Motion Picture Expert Group
SSDP
Simple Service Discovery Protocol
MSC
Mobile Switching Center
SSS
Server-Side Sorting
MSISDN
Mobile Station ISDN Number
TCP
Transmission Control Protocol
MSRN
Mobile Station Roaming Number
TDMA
Time Division Multiple Access
NDS
Netware Directory Services
TIA
ODP
Open Distributed Processing
Telecommunications Industry
Association
OID
Object Identifier
TINA
OMG
Open Management Group
Telecommunication Information
Networking Architecture
OMP
Open Mobility Platform
TMN
Telecommunications Management
Network
OSF
Open Software Foundation
TMSI
Temporary Mobile Station Identity
OSI
Open Systems Interconnection
TTL
Time-To-Live
PDC
Personal Digital Cellular
UML
Unified Modelling Language
PBX
Private Branch eXchange
UMTS
PC
Personal Computer
Universal Mobile Telecommunications System
PCS
Personal Communications System
UPnP
Universal Plug and Play
PCSS
Personal Communication Support
System
UPT
Universal Personal Telecommunication
PDA
Personal Digital Assistant
URI
Uniform Resource Identifier
PHS
Personal Handyphone System
URL
Uniform Resource Locator
PIN
Personal Identification Number
US
United States
PSTN
Public Switched Telephone Network
USDC
US Digital Cellular
QoS
Quality-of-Service
VLR
Visitor Location Register
RDN
Relative Distinguished Name
VPN
Virtual Private Network
RF
Radio Frequency
VRML
Virtual Reality Markup Language
RFC
Request For Comments
WAN
Wide Area Network
RFP
Radio Fixed Part
WLAN
Wireless Local Area Network
RMI
Remote Method Invocation
WWW
World-Wide Web
RPC
Remote Procedure Call
XML
eXtensible Markup Language
SASL
Simple Authentication and Security
Page 262
References
[ACA98] Australian Communications Authority: Update to the March 1998 Report on Technical
Options for Mobile Number Portability Implementation in Australia, Nov 1998,
http://www.aca.gov.au/number/portability/accfinrp.pdf
[ACT-NET96] ACT-NET Consortium: The Active Database Management System Manifesto: A
Rulebase of ADBMS Features, ACM SIGMOD Record (25)3, 1996, pp. 40-49
[Adamidis97] Adamidis, E.P., Fleming, G., Sykas, E.D.: Consistency Issues in the UMTS Distributed Database, 4th Int. Conf. on Intelligence in Service and Networks, 27-29 May, 1997, Italy
[Addlesee97] Addlesee, M., Jones, A., Livesey, F., Samaria, F.: The ORL Active Floor, IEEE Personal Communications, Vol. 4 No. 5, October 1997, pp. 35-41
[Adly97] Adly, N., Steggles, P., Harter, A.: SPIRIT: a Resource Database for Mobile Users, Proc.
ACM CHI'97 Workshop on Ubiquitous Computing, Atlanta, Georgia, March 1997
[Ahlers92] Ahlers, Dieter: Investigations on the use of X.500 distributed directory services for managing user profiles in private telecommunication networks, Diploma Thesis at the Aachen Technical University, Chair for Communication Networks, November 1992
[Angin98] Angin, O., Campbell, A.T., Kounavis, M.E., Liao, R.R.-F.: The Mobiware Toolkit: Programmable Support for Adaptive Networking, IEEE Personal Communications, August 1998,
pp. 32-43
[Arlein99] Arlein, R., Gehani, N., Lieuwen, D.: LTAP Trigger Gateway for LDAP Directories, at
http://www-db.research.bell-labs.com/project/ltap/LTAPTM.doc, 1999
[Aurrecoechea95] Aurrecoechea, C.; Campbell, A.; Hauw, L.: A Survey of Quality of Service Architectures, Technical Report, Lancaster University, ftp.comp.lancs.ac.uk/ public/MPG-95-18.ps.Z,
1995
[Awerbuch91] Awerbuch, B., Peleg D.: Concurrent online tracking of mobile users, SIG COMM-91
Conf. on Communication Architectures and Protocols, Zürich, 1991, pp. 221-233
[Bacon97] Bacon, J., Halls, D.: Location-Oriented Multimedia, IEEE Personal Communications,
Vol. 4 No. 5, October 1997, pp. 48-57
[Badrinath92b] Badrinath, B.R., Imielinski, T., Virmani, A.: Locating strategies for Personal Communication Networks, IEEE Globecom-92 Workshop on Networking of Personal Communications Applications, Dec. 1992
[Balachandran97] Balachandran, A., Campbell, A.T., Kounavis, M.E.: Active Filters: Delivering
Scaled Media to Mobile Devices, Proc. 7th Int. Workshop on Network and Operating System
Support for Digital Audio and Video, May 19-21, 1997, St. Louis, Missouri, USA, pp. 125-134
[Balakrishnan95] Balakrishnan, H., Seshan, S., Amir, E., Katz, R.H.: Improving TCP/IP performance over wireless networks, Proc. MobiCom, 1995
[Barker94] Barker, P.: Experiences in providing a white pages directory service based on the
X.500 standard, Computer Networks and ISDN Systems, Vol. 26, 1994, pp. 1365-1374
[Bar-Noy93] Bar-Noy, A., Kessler, I.: Tracking Mobile Users in Wireless Comunications Networks,
Proc. Infocom-93, March 28 - April 1, 1993, San Francisco, California
[Bates96] Bates, J.; Halls, D.; Bacon, J.: A Framework to Support Mobile Users of Multimedia Applications, ACM Mobile Networks and Applications (MONET), Baltzer Journals, Vol. 1, 1996
[Beadle97] Beadle, H.W.P., Maguire, G.O., Smith, M.T.: Using Location and Environment Awareness in Mobile Communications, Proc. EEE/IEEE ICICS'97, Singapore, September 97, pp.
1781-1785
[Beadle98] Beadle, H.W.P., Maguire, G.O., Smith, M.T.: Location Based Personal Mobile Computing and Communication, Proc. 9th IEEE Workshop on Local and Met ropolitan Area Networks,
Banf, May 1998
Page 263
[Bennet94] Bennet, F.; Richardson, T.; Harter, A.: Teleporting - Making Applications Mobile, Proc.
1st International Workshop on Mobile Computing Systems and Applications, Santa Cruz, US,
December 1994
[Bennet97] Bennet, F., Clarke, D., Evans, J.B., Hopper, A., Jones, A., Leask, D.: Piconet: Embedded Mobile Networking, IEEE Personal Communications, Vol. 4 No. 5, October 1997, pp. 8-15
[Berger96] Berger, M.O., Hoff, S., Jakobs, K., Kubitz, O.: Directory Services: Basis for Mobile
Computing with DECT, Proc. International Conference on Universal Personal Communications,
ICUPC-, Sep 29 - Oct 2, Cambridge, Mass, USA
[Berger97] Berger, M.O., Kubitz, O.: DECT for Factory Communication, Proc. ISIE'97, Guimaraes,
Portugal, 1997, pp. 106-111
[Bharat95] Bharat, K., Cardelli, L.: Migratory Applications, Proc. ACM Symp. on User Interfaces
Software and Technology, Pittsburgh, PA, Nov. 1995
[Bhagarvan98] Bhagarvan, V., Lee, K.-W., Lu, S., Ha, S., Li, J.-R., Dwyer, D.: The TIMELY Adaptive Resource Management Architecture, IEEE Personal Communications, August 1998, pp.
20-31
[Bisson00] Bisson S.: Soap without froth, Application Development Advisor, May-June 2000
[Bluetooth00] Bluetooth Home Page, http://www.bluetooth.com
[Böhmak96] Böhmak, W., Schill, A.: Data and Load Distribution with Java Objects in Mobile Environments, Ind. & Short Paper Proceedings of Workshop on Trends in Distributed Systems-96,
Aachen, Germany, 1996, pp. 78-87
[Böttcher94] Böttcher, R., Irmscher, K.: Trading mit mobilen Stationen - Konzepte und Probleme,
Proc. Arbeitstreffen RWTH Aachen Neue Konzepte für die Offene Verteilte Verarbeitung, 5.
Sep 1994, Aachen, pp. 116-124
[Box99] Box, D., Kakivaya, G., Layman, A., Thatte, S., Winer, D.: Simple Object Access Protocol,
Internet Draft HTTP Working Group, September 99
[Brewer98] Brewer, A., Katz, R.H., Chawathe, Y., Gribble, S.D., Hodes, T., Nguyen, G., Stemm,
M., Henderson, T., Amir, E., Balakrishnan, H., Fox, A., Padmanabhan, V.N., Seshan, S.: A
Network Architecture for Heterogeneous Mobile Computing, IEEE Personal Communications,
October 1998, pp. 8-23
[Brown97] Brown, P., Bovey, J., Chen, X.: Context-Aware Applications: From the Laboratory to the
Marketplace, IEEE Personal Communications, Vol. 4 No. 5, Octo ber 1997, pp. 58-64
[Buitenwerf95] Buitenwerf, E.; Colombo, G.; Mitts, H.; Wright, P.: UMTS: Fixed Network Issues
and Design Options, IEEE Personal Communications, Vol. 2, No. 1, Feb ruary 1995, pp. 30-37
[Caffery98] Caffery, J.J., Stüber, G.L.: Overview of Radiolocation in CDMA Cellular Systems, IEEE
Communications Magazine, April 1998, pp. 38-45
[Campbell94] Campbell, A.; Coulson, G.; Hutchison, D.: A Quality of Service Architecture, ACM
Computer Communications Review, April 1994
[Campbell96] Campbell, A.; Aurrecoechea, C.; Hauw, L.: A Review of QoS Architectures, Proc.
IFIP Workshop on Quality of Service, IWQoS96, Paris, March 6-8, 1996, pp. 173-195
[Campbell99] Campbell, A.T., Kounavis, M.E., Liao, R.: Programmable Mobile Networks, Computer Networks and ISDN Systems, Vol. 31 (7), pp. 741-765, April 199
[Caripe98] Caripe, W., Cybenko, G., Moizumi, K., Gray, R.: Network Awareness and Mobile Agent
Systems, IEEE Communications Magazine, July 1998, pp. 44-49
[Carnassa92] Carnassa, J., Freides, D.C.: PCS Data Management in an Intelligent Network, Proc.
ICUPC-92, Sept. 29 - Oct. 2, 1992, Dallas, Texas
[Casademont97] Casademont, J., Paradells, J., Carillo, M.I.L.: Urban CTM System Using DECT,
Proc. IEEE Globecom'97, Phoenix, Arizona, 3-8 November, 1997, pp. 429-433
[CellPoint00] Cellpoint home page at http://www.cellpoint.com
[Chadwick95] Chadwick, D.W.: X.500: Understanding the Directory, Chapman&Hall, ISBN 0 412
43020 7, 1995
Page 264
[Chadwick99] Chadwick, D.W.: Referrals and Knowledge References in LDAP Directories, IETF
LDAPEXT WG Internet Draft, July 1999
[Chang93] Chang, R.N., Mohan, S., Wolff, R.S.: SISAS: A Server-Independent Service Acquisition
System for Distributed Personal Communications, Proc. IEEE Intern. Conf. on Communications
ICC-93, Geneva, Switzerland, 23-26 May, 1993, pp. 307-312
[Chang97] Chang, H., Tait, C., Cohen, N., Floyd, R., Housel, B., Lindquist, D.: Web Browsing in a
Wireless Environment: Disconnected and Asynchronous Operation in ARTour Web Express,
Proc. MobiCom'97, Sepetmber 26-30, 1997, Budapest, Hungary, pp. 260-269
[Chapman95] Chapman, M., Berndt, H., Gatti, N.: Software architecture for the future information
market, computer communications, vol. 18, no. 11, Nov. 1995, pp. 825-836
[Chatras94] Chatras, B., Gallant, F.: Protocols for Remote Data Management in Intelligent Networks CS1, Intelligent Network'94 Workshop, May 24-26, 1994, Heidel berg, Germany
[Chatras95] Chatras, B., Gallant, F.: Guidelines for IN Data Modelling, Proc. Intelligent Network
Workshop, IN-95, Ottawa, Canada, May 9-11, 1995
[Ciancetta96] Ciancetta, M.C., Lavognolo, R., Bjornland, D.F.: CTM Support in European Environment: Requirements on Public IN Internetworking, Proc. ICUPC-96, Cambridge, Mass.,
USA, Sep 29 - Oct 2, 1996
[Dana00]
Dana,
P.H.:
Global
Positioning
System
Overview,
at
http://www.utexas.edu/depts/grg/gcraft/notes/gps/gps.html
[Dasgupta94] Dasgupta, P.: Resource Location in Very Large Networks, Proc. 1st International
Workshop on Services in Distributed and Networked Environments (SDNE), 27th- 28th June
1994, Prague, Czech Republic, pp. 156-163, 1994
[DaSilva97] DaSilva, J.S., Ikonomou, D., Erben, H.: European R&D Programs on Third-Generation
Mobile Communication Systems, IEEE Personal Communica tions, Feb 1997, pp. 46- 52, 1997
[David97] David, K.: Network Evolution Aspects towards a Third Generation Mobile System, Proc.
2nd European Personal Mobile Communications Conference EPMCC, Sep. 30 - October 2,
Bonn, Germany, 1997, pp. 343-349
[Davies94] Davies N., Pink, S., Blair, G.S.: Services to Support Distributed Applications in a mobile
Environment, Proc. 1st International Workshop on Services in Distributed and Networked Environments (SDNE), 27th-28th June 1994, Prague, Czech Republic, 1994
[Davies95a] Davies, N.; Blair, G.S.; Cheverst, K.; Friday, A.: A Collaborative Multimedia Application for a Mobile Environment, Proc. 2nd Int. Workshop on Mobile Multimedia Communications
MoMuC, Bristol, UK, April 1995
[deBoer91] de Boer, H., Meijer, M., Buitenwerf, E.: Network aspects for the third generation mobiles, IEEE GLOBECOM-91, Phoenix, Arizona, 2-5 December, 1991, pp. 1517-1522
[Diehl96] Diehl, N., Grill, D., Held, A., Kroh, R., Reigner, T., Ziegert, T.: System integration for mobile computing and service mobility, Proc. IFIP/IEEE Conf. on Distributed Platforms, ICDP-96,
Dresden, Feb. 1996, pp. 44-56
[DMTF00a] Distributed Management Task Force home page at http://www.dmtf.org/
[DMTF00] Distributed Management Task: LDAP Schema for the DMTF Core CIM v2.2 Model, February 2000
[Dommety97] Dommety, G., Veeraghavan, M., Singhal, M.: Flat Location Management Scheme for
PCNs, Proc. Int. Conf. on Universal Personal Communications, ICUPC'97, San Diego, CA, October 1997, pp. 146-152
[Drane98] Drane, C., Macnaughtan, M., Scott, C.: Positioning GSM Telephones, IEEE Communications Magazine, April 1998, pp. 46-59
[Eckardt96] Eckardt, T., Magedanz, T.: From IN towards TINA-based Personal Communications
Support, Proc. International Conference on Universal Personal Communications, ICUPC-96,
Sep 29 - Oct 2, 1996, Cambridge, Mass, USA
Page 265
[Eckardt97] Eckardt, T., Magedanz, T., Popescu-Zeletin, R.: Beyond IN and UPT - A Personal
Communications Support System based on TMN Concepts, IEEE Journal on Selected Areas in
Communications, Vol.15, No. 7, Sep 1997
[Eckardt97a] Eckardt, T., Magedanz, T., Popescu-Zeletin, R.: A Personal Communications Support System based on X.500 and X.700 standards, Compouter Comunications, Vol. 20, No. 7,
1997
[Eleftheriadis94] Eleftheriadis, G.P., Theologou, M.E.: User Profile Identification in Future Mobile
Telecommunications Systems, IEEE Network, Special Issue on Nomadic Computing, September/October 1994, pp. 33-39
[Elrod93] Elrod, S. et al.: Responsive Office Environments, Communications of the ACM, July
1993, Vol.36, No. 7, pp. 84-85
[Eriksson98] Eriksson, H.-E., Penker, M.: UML Toolkit, Wiley Computer Publishing, 1998
[ESA98] European Space Agency: Telecommunications Projects Page, http://www.esrin.esa.it/
progs/telecom.html
[ETS300374-1]ETSI ETS 300 374-1: Intelligent Network, Core INAP, September 1994, February
1996
[ETSI-BRAN00] ETSI BRAN project home page at http://www.etsi.org/BRAN/BRAN.htm
[ETSI-DECT99] ETSI: Radio Equipment and Systems, Digital European Cordless Telecommunications Common Interface, prETS 300 175-1, June 1999
[Executone00] Executone home page at http://www.executoneorcal.com/health_ils2.htm
[Eynard95] Eynard, C., Lenti, M., Lombardo, A., Marengo, O., Palazzo, S.: A Methodology for the
Performance Evaluation of Data Query Strategies in Universal Mobile Telecommunication Systems (UMTS), IEEE Journal on selected areas in communications, Vol. 13, No. 5, June 1995
[F.851] ITU-T Recommendation F.851: Universal Personal Telecommunication (UPT) - Service
Description (Service Set 1), ITU-T, February 1995
[Falck95] Falck, T., Maass, H., Schreyer, O., Stahl, M.: Personal Mobility Management, Philips
Telecommunication Review, Vol. 52, No. 4, pp. 21-24, Oct. 1995
[Fenner92] Fenner, P.R.: Mobile Address Management and Billing for Personal Communications,
Proc. ICUPC-92, Sept. 29 - Oct. 2, 1992, Dallas, Texas
[Floyd98] Floyd, R., Housel, B., Tait, C.: Mobile Web Access Using eNetwork Web Express, IEEE
Personal Communications, October 1998, pp. 47-52
[Foster97] Foster, G.T.: The ARIADNE Project. Supporting Access, Navigation and Information
Services in Labyrinth of Large Buildings, Proc. AAATE'97, 1997
[Fox98] Fox, A., Gribble, S.D., Chawathe, Y., Brewer, E.A.: Adapting to Network and Client Variation Using Infrastructural Proxies: Lessons and Perspectives, IEEE Personal Communications,
August 1998, pp. 10-19
[Freytag98] Freytag, C., Kumpf, C., Neumann, L.: Utilization of User and Device Profiles for Adaptive WWW Access, Proc. 5th Int. Workshop on Mobile Multimedia Communications MoMuC,
October 12-14, 1998, Berlin, Germany, pp. 283-294
[Fry97] Fry, M., Seneviratne, A., Vogel, A., Witana, V.: QoS management in a World Wide Web
environment which supports continuous media, Distributed Systems Engineering, Special Issue
on Quality of Service, Vol. 4, No. 1, March 1997
[Funke95] Funke, R.: X*-ein DC++ basierter Trader, Proc. Workshop Anwendungsunterstützung
für heterogene Rechnernetze, Freiberg, 30-31.3.1995, pp. 51-58
[Fujioka90] Fujioka, M., Sakai, S., Yagi, H.: Hierarchical and Distributed Information Handling for
UPT, IEEE Network Magazine, Vol. 4, No. 6, Nov. 1990, pp. 50-60
[Furuskaer99] Furuskaer, A., Mazur, S., Mueller, F., Olofsson, H.: EDGE: Enhanced Data Rates
for GSM and TDMA/136 Evolution, IEEE Personal Communications, Vol. 6, No. 9, June 1999,
pp. 56-66
Page 266
[Gallant93] Gallant, F.: UPT Information Model, Contribution TD85 to ETSI SPS2 WPC, Vienna,
26-30 April 1993
[GenMagic97]
General
Magic:
Mobile
Agents
White
Papaer,
1997,
http://www.genmagic.com/technology/techwhitepaper.html
[Geulen97] Geulen, E., Hartmann, J.: Open Service Provisioning in GSM - What Do We Gain With
CAMEL?, Proc. 2nd European Personal Mobile Communications Conference EPMCC, Sep. 30
- October 2, Bonn, Germany, 1997, pp. 335-341
[Goland00] Goland, Y.Y., Cai, T, Leach, P., Gu, Y, Albright, S.: Simple Service Discovery Protocol,
IETF Internet Draft, April 2000
[Good96] Good, G.: The LDAP Data Interchange Format (LDIF), IETF ASID Working Group Internet Draft, November 1996
[Greenhalgh98] Greenhalgh, C.: Awareness-based communication management in the MASSIVE
systems, Distributed Systems Engineering 5 (1998), pp. 129-137
[Grillo98] Grillo, D., Skoog, R.A., Chia, S., Leung, K.K.: Teletraffic Engineering for Mobile Personal
Communications in ITU-T Work: The Need to Match Practice and Theory, IEEE Personal
Communications, Dec. 1998, pp. 38-58
[Guttman98] Guttman, E., Perkins, C., Veizades, J., Day, M.: Service Location Protocol, Version 2,
IETF Draft draft-ietf-svrloc-protocol-v2-10.txt, October 1998
[Guttman98a] Guttman, E., Perkins, C., Kempf, J.: Service Templates and service: Schemes,
IETF Draft, draft-ietf-svrloc-service-scheme-12.txt, October 1998
[Hac96] Hac, A., Sheng, C.: User Mobility Management in PCS Network: Hierarchical Databases
and Their Placement, Proc. ICUPC-96, Cambridge, Mass., USA, Sep 29 - Oct 2, 1996
[Hagen98] Hagen, L., Breugst, M., Magedanz, T.: Impacts of Mobile Agent Technology on Mobile
Communication System Evolution, IEEE Personal Communications, August 1998, pp. 56-69
[Han98] Han, R., Bhagwat, P., LaMaire, R., Mummert, T., Perret, V., Rubas, J.: Dynamic Adaptation in an Image Transcoding Proxy for Mobile Web Browsing, IEEE Personal Communications,
Dec. 1998, pp. 8-17
[Harel88] Harel, D.: On Visual Formalisms, Communications of the ACM, May 1998, Vol. 31, No.
5, pp. 514-529
[Harjono94] Harjono, H.; Jain, R.; Mohan, S.: Analysis and simulation of a cache-based auxiliary
user location strategy for PCS, Proc. of Networks for personal communications NPC-94, 16-18
March 1994, Long Branch, USA, pp. 1-5
[Harter94] Harter, A., Hopper, A.: A Distributed Location System for the Active Office, IEEE Network, January/February 1994, pp. 62-70
[Hascher97] Hascher, W.: GPS: bald überall, Elektronik, 1/1997, Jan 1997, pp. 26-29
[Havermans93] Havermans, G., Pasman, W.: Mobility in Private Networks, Philips Telecommunication Review, Vol. 51, No.2, August 1993, pp. 35-40
[Helal96] Helal, A., Heddaya, A., Bhargava, B.: Replication Techniques in Distributed Systems,
Kluwer Academic Publishers, 1996
[Herbon94] Herbon, G.B.: Designing NetWare Directory Services, M&T Books, ISBN 1- 55851338-8, 1994
[Herron99] Herron, A., Howes, T., Wahl, M., Anantha, A.: LDAP Control Extension for Server Side
Sorting of Search Results, Internet Draft, IETF Network Working Group, April 1999
[Hess96] Hess, R., Hutschenreuther, T., Schill, A.: Video Communication and Media Scaling System Xnetvideo: Design and Implementation, Proc. Workshop Interactive Distributed Multimedia
Systems and Services IDMS, March 1996, Berlin, Germany, pp. 195-210
[Hesselmann95] Hesselmann, M., Irmscher, K., Kulke, M.: Management mobiler Stationen, Proc.
Arbeitstreffen Entwicklung und Management verteilter Anwendungssysteme, Dortmund, Germany, October 1995, pp. 171-178
Page 267
[Ho95] Ho, J.S.M., Akyildiz, L.F.: Local anchor scheme for reducing location tracking costs in PCS,
Proc. ACM MOBICOM, Berkeley, CA, 1995, pp.181-194
[Hodes97] Hodes, T.D., Katz, R.H., Servan-Schreiber, E., Rowe, L.: Composable Ad-hoc Mobile
Services for Universal Interaction, Proc. 3rd Int. Conference on Mobile Computing and Networking, September 26-30, 1997, Budapest, Hungary, pp. 1- 12
[Hoff96] Hoff, S., Jakobs, K., Kesdogan, D.: Anonymous mobility management for third generation
mobile networks, Proc. IFIP TC6/TC11 Int. Conf. on Communications and Multimedia Security,
Essen, Germany, 1996, pp. 72-83
[Hoff98] Hoff, S.: Mobilitätsmanagement in Offenen Systemen - Leistungsbewertung von Verzeichnissystemen, PhD Thesis, Aachen University of Technology, 1998
[Hohl99] Hohl, F., Kubach, U., Leonhardi, A., Rothermel, K., Schwehm, M.: Next Century Challenges: Nexus - An Open Global Infrastructure for Spatial-Aweare Applications, Proc. 5th
ACM/IEEE Int. Conf. on Mobile Computing and Networking (MobiCom'99), Seatlle, Washington,
USA, 1999, pp. 249-255
[Hokimoto96a] Hokimoto, A.; Kurihara, K., Nakajima, T.: An Approach for Constructing Mobile Applications Using Service Proxies, ICDCS-96, Hong Kong, May 27-30, 1996, pp.726-733
[HomeRF] Home RF Working Group home page at http://www.homerf.org/
[Housel98] Housel, B.C., Samaras, G., Lindquist, D.B.: WebExpress: A client/intercept based system for optimising Web browsing in a wireless environment, Mobile Networks and Applications
(MONET), Vol. 3, No. 4, 1998, pp. 419-423
[Howard88] Howard, J.H., Kazar, M.L., et al: Scale and performance in a distributed file system,
ACM Trans. Comput. Syst. 6, 1 (Feb.), pp. 55-81
[Howes] Howes, T., An X.500 and LDAP Database: Design and Implementation, University of
Michigan, at ftp://terminator.rs.itd.umich.edu/ldap/papers/xldbm.ps
[Howes96] Howes, T., Smith, M., Good, G., Sloan, L., Rothwell, S.: The SLAPD and SLURPD
Administrator Guide - Release 3.3, University of Michigan, April 1996
[Howes97] Howes, T., Smith, M.: LDAP - Programming Directory-Enabled Applications with Lightweight Directory Accesss Protocol, Macmillan Technical Publishing, Indianapolis, Indiana, 1997
[Huizinga95] Huizinga, D.M., Heflinger, K.: DOC - a file system cache to support mobile computers, Distrib. Syst. Eng., Vol. 2, No. 3, 1995, pp. 152-160
[Huston95] Huston, L.B.; Honeyman, P.: Partially Connected Operation, Proc. 2nd USENIX Symposium on Mobile and Location-Independent Computing, Ann Arbor, Michigan, April 1995, pp.
91-96
[IEEE-802.11] IEEE 802.11 home page at http://grouper.ieee.org/groups/802/11
[Iida93] Iida, I., Kurita, K., Murakami, K.: System Architecture for Personal-ID Based Communication Services, ISSLS 93, Vancouver, Canada
[Imielinski97] Imielinski, T.: Mobile Computing: DataMan project perspective, Mobile Networks and
Applications, MONET, 1 (1996), pp. 359-369
[Indulska93] Indulska, J.; Bearman, M.; Raymond, K.: A type management system for an ODP
trader, Proc. ICODP-93, 13-16 Sept. 1993, Berlin, Germany, pp. 169-180
[Inouye97] Inoue, J., Cen, S., Pu, C., Walpole, J.: System Support for Mobile Multimedia Applications, Proc. 7th Int. Workshop on Network and Operating System Sup port for Digital Audio and
Video, May 19-21, 1997, St. Louis, Missouri, USA, pp. 135-146
[Isode97] Isode Ltd.: White Paper: Performance Analysis of the Isode LDAP/X.500 Enterprise Directory Server, 1997
[Ito95] Ito, S.: Decentralized Location Registration Information Storage Method for Multimedia Services in Mobile Communication Networks, Proc. ICUPC-95, pp. 263-267
[Jabbari95] Jabbari, B.; Colombo, G.; Nakajima, A.; Kulkarni, J.: Network issues for wireless communications, IEEE Communications Magazine, Jan 1995, pp. 88-98
Page 268
[Jagadish99] Jagadish, H.V., Lakshmanan, L.V.S., Srivastava, D.: Revisiting the Hierarchical Data
Model, IEICE Trans. Inf. & Syst., Vol. E82-D, No. 1, January 1999, pp. 3-12
[Jain94] Jain, R.; Lin, Y.; Lo, C.; Mohan, S.: A caching strategy to reduce network impacts of PCS,
IEEE Journal on Selected Areas in Communications, Vol. 12, No. 8, October 1994, pp. 14341444
[Jain95] Jain, R., Lin, Y-B: An Auxiliary User Location Strategy Employing Forwarding Pointers to
Reduce Network Impacts of PCS, Proc ICC-95, June 18-22, Seattle, Washington, USA, 1995
[Jain96] Jain, R.: Reducing traffic impacts of PCS using hierarchical user location databases, Proceedings of ICC/SUPERCOMM-96, 23-27 June 1996, Dallas, TX, USA, pp. 1153-1157
[Jain96a] Jain, R., Rajagopalan, S., Chang, L.-F.: A Hashing Scheme for Phone Number Portability in PCS Systems with ATM Backbones, 7th IEEE Symp. on Personal, Indoor, and Mobile Radio Communications, PIMRC-96, USA, 1996
[Jain97] Jain, R.: A Model for Estimating Installed First Costs of NGPN Translation in PCS Systems, Proc. IEEE In.t Conf. on Communications, ICC'97, Montreal, Quebec, Canada, 8-12
June, 1997, pp. 386-390
[Jannink97] Jannink, J., Lam, D., Shivakumar, N., Widom, J., Cox, D.C.: Efficient and flexible location management techniques for wireless communication systems, Wireless Networks 3 (1997),
pp. 361-374
[Jiang98] Jiang, Z. Kleinrock, L.: Web Prefetching in a Mobile Environment, IEEE Personal Communications, October 1998, pp. 25-34
[JNDI00] Sun Microsystems: Java Naming and Directory Interface JNDI, V1.2, at
http://java.sun.com/products/jndi/1.2/, 2000
[Joseph97] Joseph, A.D., Tauber, J.A, Kaashoek, M.F.: Mobile Computing with the Rover Toolkit,
IEEE Transactions on Computers, Special issue on mobile computing, 46(3), March 1997
[Jung96] Jung, J.-I.: Translation of user-s QoS requirements into ATM performance parameters in
B-ISDN, Computer Networks and ISDN Systems, 28 (1996), pp. 1753-1767
[Kalden00] Kalden, R., Meirick, I., Meyer, M.: Wireless Internet Access Based on GPRS, IEEE
Personal Communications, Vol. 7, No. 9, April 2000, pp. 8-18
[Kato91] Kato, T., Fujinaga, M., Obana, S., Suzuki, K.: Applying distributed processing technologies to intelligent network, Journal: IEICE Transactions, vol.E74, no.11, pp.3672-82, Nov. 1991
[Katz94] Katz, R.H.: Adaptation and Mobility in Wireless Information Systems, IEEE Personal
Communication Systems, Vol.1 , No.1, 1994, pp. 6-17
[Keylabs99]
Keylabs:
Microsoft
Active
Directory
vs.
Netware
NDS,
at
http://www.keylabs.com/results/microsoft/ad/index.htm, 1999
[Kille00] Kille, S.E.: X.509 Authentication SASL MEchanism, IETF Network WG Internet Draft,
February 2000
[King96] King, N.J.: Mobile Roaming between Private Wireless Networks, Proc. ICUPC-96, Cambridge, Mass., USA, Sep 29 - Oct 2, 1996
[Kirby95] Kirby, G.: Locating The User, Communications International, October 1995, p.49
[Kistler92] Kistler, J.J., Satyanarayanan, M.: Disconnected operation in the Coda file system, ACM
Transactions on Computer Systems, Vol. 10, No. 1, Feb. 1992, pp. 3-25
[Kleinrock95] Kleinrock, L.: Nomadic computing - an opportunity, ACM SIGCOMM, Computer
Communication Review, Vol. 25, No. 1, January 1995, pp. 36-40
[Klotz92] Klotz, P.: Netzwerkressourcen im X.500 Directory, Diplomarbeit Universität Stuttgart, Fakultät Informatik, November 1992
[Kottmann95] Kottmann, D.A.: Abgekoppelte Objekte in heterogenen Umgebungen mit mobilen
Teilnehmern, Proc. Workshop Anwendungsunterstützung für heterogene Rechnernetze,
Freiberg, 30.-31.3.1995, pp. 145-154
[Kovacs92] Kovacs, E.: Effizienter Zugriff auf dynamische Information im MELODY-Trader, Universität Stuttgart, IPVR, 1992
Page 269
[Kovacs94] Kovacs, E.: Trading und Management verteilter Anwendungen: zentrale Aufgaben für
zukünftige verteilte Systeme, Proc. Arbeitstreffen RWTH Aachen Neue Konzepte für die Offene
Verteilte Verarbeitung, 5. Sep 1994, Aachen, pp. 57-66
[Kreller98] Kreller, B., Park, A., Meggers, J., Forsgren, G., Kovacs, E., Rosinus, M.: UMTS: A Middleware Architecture and Mobile API Approach, IEEE Personal Communications, April 1998,
pp. 32-38
[Kreller98a] Kreller, B., Carega, D., Shankar, J., Salmon, P., Böttger, S., Kassing, T.: A MobileAware City Guide Application, ACTS Mobile Communication Summit'98, June 8-11, 1998, Rhodes, Greece
[Krishna94] Krishna, P., Vaidya, N.H., Pradhan, D.K.: Static and Dynamic Location Management in
Distributed Mobile Environments, Department of Computer Science, Texas A&M University,
U.S., Technical Report 94-030, June 1994
[Kubach00] Kubach, U., Leonhardi, A., Rothermel, K., Schwehm, M.: Analysis of Distribution
Schemes for the Management of Location Information, Technical Report, University of Stuttgart, 2000
[Küpper96] Küpper, A., Popien, C., Meyer, B.: Service Management using up-to-date quality properties, Proc. IFIP/IEEE Conf. on Distributed Platforms, ICDP-96, Dresden, Feb. 1996, pp. 447459
[Küpper98] Küpper, A.: User Agents - An Approach for Service Provision and Location Management in 3rd Generation Mobile Networks, Proc. Int. Conf. on Telecommunications'98, Greece,
1998
[Lam97] Lam, D., Cui, Y., Cox, D.C., Widom, J.: A Location Management Technique to Support
Lifelong Numbering in Personal Communications Services, IEEE GLOBECOM-97, 3-8 Nov.
1997, Phoenix, Arizona, USA
[Lange98] Lange, D.B., Oshima, M.: Programming and Deploying Java Mobile Agents with Aglets,
Adison Wesley, 1998
[LaPorta95] La Porta, T.F., Veeraraghavan, M., Treventi, P.A., Ramjee, R.: Distributed Call Processing for Personal Communications Services, IEEE Communications Magazine, June 1995,
pp. 66-74
[LaPorta96] La Porta, T.F., Sabnani, K.K., Gitlin, R.D.: Challenges for nomadic computing: Mobility
management and wireless communications, Mobile Networks and Applications, MONET, Vol. 1,
No. 1, 1996, pp. 3-16
[Leonhardi99] Leonhardi, A., Rothermel, K.: A Comparison for Updating Location Information,
Technical Report, University of Stuttgart, 1999
[Leonhardt98] Leonhardt, U: Supporting Location-Awareness in Open Distributed Systems, Ph.D.
Thesis, Dept. of Computing, Imperial College London, May 1998
[Leser93] Leser, N.: The distributed computing environment naming architecture, Distributed Systems Engineering 1 (1993), pp. 19-28
[Leung96] Leung, K.K., Levy, Y.: Use of Centralized and Replicated Databases for Global Mobility
Management in Personal Communication Networks, Proc. ICUPC-96, Cambridge, Mass., USA,
Sep 29 - Oct 2, 1996
[Leung97a] Leung, K.K., Levy, Y.: Data Replication Schemes for Global Networks, Proc. ITC-15,
23-27 June 1997, pp. 211-222
[Li95] Li, G.: An overview of real-time ANSAware 1.0, Distrib. Syst. Enginnering, Vol. 2, No. 1,
1995, pp. 28-38
[Liao98] Liao, R.R.-F., Kounavis, M.E., Campbell, A.T.: The Design, Implementation and Evaluation of the Mobiware Toolkit, Proc. 5th Int. Workshop on Mobile Multimedia Communications
MoMuC, October 12-14, 1998, Berlin, Germany, pp. 139-149
[Lima95] Lima, F., Madeira, E.: A Model for a Federative Trader, Proc. Int. Conf. on Open Distributed Processing, ICODP-95, Brisbane, Australia
Page 270
[Lin95] Lin, C.-L., Pollini, G., Gitlin, R.D.: The Reverse Virtual Call Setup Algorithm for Mobility
Management in PCS Networks, Proc ICC-95, June 18-22, Seattle, Washington, USA, 1995
[Lin96] Lin, Y.-B.: A cache approach for supporting life-time UPT number, Wireless Networks, 2,
pp. 155-160, 1996
[Liu96] Liu, L.Q., Munro, A.T., Barton, M.H.: Efficient Mobility Management: A Flexible Design Algorithm, Proc. ICUPC-96, Cambridge, Mass., USA, Sep 29 - Oct 2, 1996
[Lo92] Lo, C.N., Wolff, R.S., Bernhardt, R.C.: An estimate of network database transaction volume
to support universal personal communication services, Proc. ICUPC, Sept 92, Dallas, Texas,
1992
[Lo93b] Lo, C.N., Mohan, S., Wolff, R.S.: A Comparison of Data Management Alternatives for Personal Communications Applications, Bellcore Technical Report TM-ARH-022333, June 1993
[Long96] Long, S., Aust, D., Abowd, G.D., Atkeson, C.: Cyberguide: Prototyping context-aware
mobile applications, In ACM SIGCHI Conference on Human Factors in Computing Systems,
April 1996
[M.3010] ITU-T Recommendation M.3010: Principles for a Telecommunications Management
Network, ITU-T, May 1996
[Maass92] Maass, H.: Use of Directory Services for mobility management in private networks,
European Telecommunications Standards Institute - Business Telecommunications (BT): Private Telecommunications Network (PTN) internal mobility - Private user mobility and cordless
terminal mobility - General principles and service aspects, Informative Annex B, STC BT1, WPMobility, DTR/BT-1005, October 1992, pp. 83-87
[Maass93] Maass, H., Schreyer, O., Stahl, M.: Data management for wide-area mobility in private
telecommunications networks, Proc. ITG-Fachtagung Mobile Kommunikation, 26.-29.9. 1993,
Neu-Ulm, Germany, pp. 535-546
[Maass94] Maass, H., van der Cruijs, P.: Replicated Distributed Directory Services for Mobile
Communications Networks, 1st International Workshop on Services in Distributed and Networked Environments (SDNE), 27th-28th June 1994, Prague, Czech Republic, 1994, pp. 90-97
[Maass97] Maass, H.: A Software Platform for Location-Aware Mobile Applications, Proc. 2nd
European Personal Mobile Communications Conference, EPMCC-97, Bonn, Germany, 30 Sep.
- 2 Oct, 1997, pp. 203-210
[Maass97a] Maass, H.: Location-Aware Mobile Applications based on Directory Services, Proc. 3rd
IEEE/ACM Int. Conf. on Mobile Computing and Networking, MobiCom-97, Budapest, Hungary,
26.-29. September, 1997, pp. 23-33
[Maass98] Maass, H.: Open Mobility Management Platform with Directory-Based Architecture and
Signalling Protocols, Proc. 1st IEEE Conference on Open Architectures and Network Programming, OPENARCH-98, San Francisco, CA, USA, April 3-4, 1998, pp. 72-87
[Maass98a] Maass, H.: Location-aware mobile applications based on directory services, Journal
on Mobile Networks & Applications (MONET) - Protocols and Software Paradigms of Mobile
Networks, Vol. 3 (1998), August 1998, pp. 157-173
[Macaire99] Macaire, A., Carlier, D.: A Personal Naming and Directory Service for UMTS Users,
Proc. 6th Int. Conf. on Intelligence and Services in Networks, IS&N'99, 1999 pp. 250-262
[Magedanz95] Magedanz, T.: Modeling IN-based service control capabilities as part of TMN-based
service management, Proc. 4th IFIP Intl. Symposium on Integrated Network Management,
North-Holland, 1995
[Maniatis99] Maniatis, P., Roussopoulos, M., Swierk, E., Lai, K., Appenzeller, G., Zhao, X., Baker,
M.: The Mobile People Architecuture, ACM Mobile Computinmg and Communications Review,
Vol. 1, No. 2, July 1999
[Merrels00] Merrels, J., Reed, E., Srinivasan, U.: LDAP Replication Architecture, IETF LDUP
Working Group Internet Draft, March2000
[MessagingDirect00] MessagingDirect: Description of M-Vault Product, at http://www.messa gingdirect.com/m-vault/features.html
Page 271
[Meulemans96] Meulemans, N.: A Yellow Pages service based on X.500, Computer Networks and
ISDN Systems 28(1996), pp1939-1946
[Meyer96] Meyer, B., Zlatintsis, S., Popien, C.: Enabling Interworking between Heterogeneous Distributed Platforms, Proc. IFIP/IEEE Conf. on Distributed Platforms, ICDP-96, Dresden, Feb.
1996, pp. 329-341
[MONET-D14] RACE Project 2066 Deliverable R2066/PTTNL/MF1/DS/P/014/a1: Stage 2 (draft)
specifications of communications between databases, Oct. 1992
[Mouly95] Mouly, M.; Pautet, M.: Current Evolution of the GSM Systems, IEEE Personal Communications, Vol. 2, No. 5, October 1995
[MS-ILS00] Microsoft Site Server home page at http://www.microsoft.com/netmeeting/ils/
[MS-NM00] Microsoft NetMeeting home page at http://www.microsoft.com/netmeeting/
[MS-W2000] Microsoft Windows 2000 Server home page at http://www.microsoft.com/
ntserver/windowsnt5/
[Müller95b] Müller-Jones, K., Merz, M., Lamersdorf, W.: The TRADEr: Integrating Trading Into
DCE, Proc. Int. Conf. on Open Distributed Processing, ICODP-95, Brisbane, Australia
[Murase98] Murase, T., Tsukamoto, M., Nishio, S.: Active Mobile Database Systems for Mobile
Computing Environments, IEICE Transactions on Information and Systems (Japan), vol. E81-D,
no. 5, pp.427-33, May 1998
[Murase98a] Murase, T., Ohyama, M.: Evolution of Personal Multimedia Communications Services
in Japan, IEEE Personal Communications, Vol. 5, No. 6, December 1998, pp. 66-74
[Nahrstedt95] Nahrstedt, K.; Smith, J.M.: The QOS Broker, IEEE Multimedia Magazine, Spring
1995, pp. 53-67
[Nelson95] Nelson, G.J.: User Interaction with Machines on the Move: Location Aware Computing,
Proc. 4th IEEE Workshop on Enabling Technologies: Infrastructure for Collaborative Environments (WET ICE-95), April 20-22, 1995, Berkeley Springs, West Virginia
[Nelson98] Nelson, G.J.: Context-Aware and Location Systems, Ph.D. thesis University of Cambridge, 1998
[Netscape96] Netscape: An Internet Approach to Directories, Netscape White Paper,
http://home.netscape.com/newsref/ref/ldap.html, 1996
[Netscape99] Netscape Directory Server Plug-In Programmer's Guide,
http://devedge.netscape.com/docs/manuals/directory/dirPlugin40/index.htm, 1999
[Netscape00] Netscape: Product information about Netscape Directory Server at
http://devedge.netscape.com/docs/manuals/index.html?content=directory.html
[Ng92] Ng, L.J.; Donaldson, R.W.; Malyan, A.D.: Distributed architectures and databases for intelligent personal communication networks, Proc. 1992 IEEE International Conference on Selected Topics in Wireless Communications, 25-26 June 1992, Vancouver, BC, Canada, p.3004, 1992
[Noble95] Noble, B.D.; Price, M.; Satyanarayanan, M.: A programming interface for applicationaware adaptation in mobile computing, Proc. 2nd USENIX Symposium on Mobile and LocationIndependent Computing, Ann Arbor, Michigan, April 1995, pp. 57-66
[Obana92] Obana, S., Horiuchi, H., Suzuki, K.: Realization of UPT Name Server based on OSI Directory under Multiple Management Domains Environment, Proc. TINA-92, Narita, Japan, pp.
21-2-1 - 21-2-15, 1992
[Obana92a] Obana, S., Horiuchi, H., Kato, T., Suzuki, K.: Applicability of OSI directory to universal
personal telecommunication (UPT), Journal: Electronics and Communications in Japan, Part 1
(Communications), vol.75, no.10, pp.1-14, 1992
[Ojanpera98] Ojanpera, T., Prasad, R.: An Overview of Third-Generation Wireless Personal
Communications: A European Perspective, IEEE Personal Communications, Vol. 5, No. 6, Dec.
1998, pp. 59-65
Page 272
[Okasaka91] Okasaka, S., Onoe, S., Yasuda, S., Maebara, A.: A new location updating method for
digital cellular systems, Proc. of IEEE VTC-91 Vehicular Technology Conference, Denver, CO.,
May 1991, pp. 345-350
[OMG95] OMG: CORBA services: Common Object Services Specification - Event Service, Version
1.0, March 1995
[OMG99] OMG: Corba services: Common Object Services Specification - Notification Service,
Version 1.3, August 1999
[Omnipoint00] Omnipoint home page at http://www.omnipoint-tech.com/
[OnTheMove-D28] OnTheMove: Specification of the Mobile-API for MASE V2.0, June 1997
[OnTheMove-D33] OnTheMove: Design of MASE V2.0, October 1997
[OpenLDAP00] OpenLDAP home page at http://www.openldap.org/
[Ottmann98] Ottmann, T., Widmayer, P.: Algorithmen und Datenstrukturen, Spektrum
Akademischer Verlag, 1998
[Palat96] Palat, S.K., Andresen, S.: User Profiles and their Replication for Reduction of HLR Accesses and Signalling Load, Proc. ICUPC-96, Cambridge, Mass., USA, Sep 29 - Oct 2, 1996
[Pandya97] Pandya, R.: Numbers and Identities for Emerging Wireless/PCS Networks, IEEE Personal Communications, June 1997, pp. 8-14
[Park97] Park, S.J., Yang, C.Y., Lee, D.C., Song, J.S.: Querying User Location using Call Locality
Relation in Hierarchically Distributed Structures, IEEE GLOBE COM-97, 3-8 Nov. 1997, Phoenix, Arizona, USA
[Paton98] Paton, N.W.: Active Rules in Database Systems, Springer, ISBN 0-387-98529-8, 1998
[Perkins96] Perkins, C.E., Harjono, H.: Resource discovery protocol for mobile computing, Mobile
Networks and Applications, MONET, Vol. 1 (1996), No. 4, Baltzer Science Publishers
[Perkins98] Perkins, C.E.: Mobile networking in the Internet, Mobile Networks and Applications
(MONET), Vol. 3, No. 4, 1998, pp. 419-423
[Perkins00] Perkins, C.E, Johnson, D..: Mobility Support in IPv6, IETF Internet Draft, April 2000
[Peterson97] Peterson, K., Spreitzer, M.J., Terry, D.B., Theimer, M.M., Demers, A.J.: Flexible Update Propagation for Weakly Consistent Replication, Proc. 16th ACM Symposium on Operating
System Principles, 5-8 Oct. 1997, Saint Malo, France, pp.288-301
[Pham98] Pahm, V.A., Karmouch, A.: Mobile Software Agents: An Overview, IEEE Communications Magazine, July 1998, pp. 26-37
[Philips-PBC] Philips Business Communications: SOPHO home page at http://www.busi nesscomms.be.philips.com/
[PinPoint99] PinPoint: Case Studie Mount Sinai/NYU Medical Center, LPS Report, 1999, available
at http://www.pinpointco.com/casestudies/nyu.pdf
[PinPoint99a] PinPoint Local Positioning Systems home page at http://www.pinpointco.com
[Priyantha00] Priyantha, N.B., Chakraborty, A., Balakrishnan, H.: The Cricket location-Support
System, Proc. 6th Int. Conf. on Mobile Computing and Networking, MobiCom'00, August 2000
[Pollini93a] Pollini, G.; Tabbane, S.: The intelligent network signalling and switching costs of an alternate location strategy using memory, Proc. of IEEE-93 Veh. Technol. Conf., Secaucus, NJ,
18-20 May 1993, pp. 931-934
[Pollini95] Pollini, G.P., Meier-Hellstern, K.S., Goodman, D.J.: Signaling Traffic Volume Generated
by Mobile and Personal Communications, IEEE Communications Magazine, June 1995, pp. 6065
[Popescu91] Popescu-Zeletin, R., Tschammer, V., Tschichholz, M.: -Y- distributed application platform, computer communications, vol 14, no. 6, july/august 1991, pp. 366-374
[Pratten95] Pratten, A.W., Hong, J.W., Bauer, M.A., Bennett, J.M., Lutfiyya, H.: A Resource Management System Based on the ODP Trader Concepts and X.500, IEEE International Sympo-
Page 273
sium On Integrated Network Management, INM-95, Red Lion Resort, Santa Barbara, California,
USA, 1-5 May 1995
[Puder96] Puder, A., Burger, C.: New Concepts for Qualitative Trader Cooperation, Proc. IFIP/
IEEE Conf. on Distributed Platforms, ICDP-96, Dresden, Feb. 1996, pp. 301-326
[Qin95] Qin, Z., Veeraghavan, M., La Porta, T.F.: An Improved Mobile Tracking and Location Procedure for ATM-Based PCNs, Proc. Globecom-95, 13-17 Nov. 1995, Singapore, pp.6-11
[Q.1201] ITU-T Recommendation I.312/Q.1201: Principles of Intelligent Network Architecture, ITUT, October 1992
[Q.1221] ITU-T Recommendation Q.1221: Introduction to Intelligent Network Capability Set 2, ITUT, September 1997
[Q.1224] ITU-T Recommendation Q.1224: Distributed Functional Plane for Intelligent Network Capability Set 2, ITU-T, September 1997
[Q.1238] ITU-T Recommendation Q.1238: Interface Recommendation for Intelligent Network Capability Set 3, ITU-T, June 2000, to be published
[Redlich96] Redlich, J.P., Balfanz, D.: Requirements for Personalized User Environments in Telecommunications, Proc. 3rd Intl. Workshop on Services in Distributed and Networked Environments (SDNE-96), Macau, June 1996
[Reed98] Reed, J.H., Krizman, K.J., Woerner, B.D., Rappaport, T.S.: An Overview of the Challenges and Progress in Meeting the E-911 Requirements for Location Service, IEEE Communications Magazine, April 1998, pp. 30-37
[Reed00] Reed, E.: LDAP Subentry Schema, Internet Draft, March 2000
[RFC1034] Domain Names; Concepts and Facilities, RFC1034, Nov. 1987
[RFC1777] Lightweight Directory Access Protocol, RFC1777, March 1995
[RFC1823] The LDAP Application Program Interface, RFC1823, August 1995
[RFC2002] IP Mobility Support, RFC2002, October 1996
[RFC2131] Dynamic Host Configuration Protocol, Request for Comments 2131, March 1997
[RFC2222] Simple Authentication and Security Layer (SASL), RFC2222, October 1997
[RFC2234] Augmented BNF for Syntax Specifications: ABNF, RFC2234, November 1997
[RFC2244] ACAP - Application Configuration Access Protocol, RFC2244, November 1997
[RFC2251] Lightweight Directory Access Protocol (v3), RFC2251, December 1997
[RFC2252] Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions, RFC2252, December 1997
[RFC2253] Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names, RFC2253, December 1997
[RFC2254] The String Representation of LDAP Search Filters, RFC2254, December 1997
[RFC2255] The LDAP URL Format, RFC2252, December 1997
[RFC2256] A Summary of the X.500(96) User Schema for use with LDAPv3, RFC2256, December
1997
[RFC2543bis] SIP: Session Initiation Protocol, RFC2543bis, August 2000
[RFC2589] Lightweight Directory Access Protocol (v3): Extensions for Dynamic Directory Services,
RFC2589, May 1999
[RFC2616] Hypertext Transfer Protocol -- HTTP/1.1, RFC2616, June 1999
[Richardson94] Richardson, T.; Bennet, F.; Mapp, G.; Hopper, A.: Teleporting in an X Window
System Environment, IEEE Personal Communications, Third Quarter 1994, pp. 6-12
[Richman95] Richman, A., Hoang, D.: Accomplishing Distributed Traders Utilizing the X.500 Directory, Proc. MICC-95, 2nd Malaysia International Conference on Communications, November
1995, Malaysia
Page 274
[Richter96] Richter, K., Rudolf, S., Irmscher, K.: Mediator Services for Mobile Clients, Proc.
IFIP/IEEE Conf. on Distributed Platforms, ICDP-96, Dresden, Feb. 1996, pp. 257-262
[Ritterbecks95] Ritterbecks, A., Lawniczak, D., Niebert, N.: Performance Evaluation of Database
Concepts for Personal Communication Systems, Proc. IS&N-95, Heraklion, Crete, Oct. 95, pp.
307-319
[Rizzo94] Rizzo, M., Linnington, P., Utting, I.: Integration of location services in the open distributed office, Technical Report, Computing Laboratory, University of Kent, Canterbury, UK, Sep
1994
[Roguewave00] Rogue Wave: Rogue Wave XML-CORBA Link: XML Access to CORBA-based
Systems , White Paper, 2000, at http://www.roguewave.com/products/ whitepapers/ xorbawp.cfm
[Rose95] Rose, C.: Minimization of Paging and Registration Costs Through Registration Deadlines, Proc ICC-95, June 18-22, Seattle, Washington, USA, 1995
[Rosenberry92] Rosenberry, W., Kenney, D., Fisher, G.: Understanding DCE, O-Reily & Associates Inc, September 1992
[RSF98] Russian Space Forces: GLONASS Home Page, http://mx.iki.rssi.ru/SFCSIC/ glonass.html
[Salkintzis97] Salkintzis, A.K., Chamzas, C.: Mobile Packet Data Technology: An Insight into
MOBITEX Architecture, IEEE Personal Communications, February 1997, pp. 10-18
[Schilit93] Schilit, B.N., Theimer, M.M., Welch, B.B.: Customizing Mobile Applications, Proc.
USENIX Mobile and Location-Independent Computing Symposium, Cambridge, MA, USA, pp.
129-138
[Schilit94a] Schilit, B.; Adams, N.; Want, R.: Context-aware computing applications, Proc. 1st International Workshop on Mobile Computing Systems and Applications, Santa Cruz, US, December 1994
[Schilit95] Schilit, B.N.: A System Architecture for Context-Aware Mobile Computing, PhD Dissertation, Columbia University, New York, NY, 10025, May 1995
[Schill95] Schill, A., Bellmann, B., Böhmak, W., Kümmel, S.: System Support for Mobile Distributed
Applications, SDNE-95, 2nd Int. Workshop on Distributed and Networked Services, Whistler,
British Columbia, June 5-6, 1995, pp. 124-131
[Schopp97] Schopp, M.: User Modelling and Performance Evaluation of Distributed Location Management for Personal Communications Services, Proc. ITC-15, 23-27 June 1997, pp. 23-34
[Shivakumar95] Shivakumar, N., Widom, J.: User Profile Replication for Faster Location Lookup in
Mobile Environments, ACM Int. Con. on Mobile Computing and Networking (MOBICOM'95),
Berkeley, California, pp. 161-169, 1995
[Siemens00] Siemens: DirX 5.5 Product Brochure, Siemens AG, 2000
[Skonnard00] Skonnard, A.: SOAP: The Simple Object Access Protocol, Microsoft Internet Developer, Jan 2000
[Smith00] Smith, M., Good, G., Weltman, R., Howes, T.: Persistent Search: A Simple LDAP
Change Notification Mechanism, Internet Draft, IETF Network Working Group, March 2000
[SnapTrack]
An
Introduction
to
SnapTrack
Server-Aided
GPS
Technology,
http://www.snaptrackinc.com/pdf/ion.pdf
[Spreitzer93] Spreitzer, M., Theimer, M.: Scalable, Secure, Mobile Computing with Location Information, Communications of the ACM, July 1993, Vol.36, No. 7, p. 27
[Spreitzer93a] Spreitzer, M.; Theimer, M.: Providing location information in a ubiquitous computing
environment, Proc. Fourteenth ACM Symposium on Operating Systems Principles, 1993,
SIGOPS, ACM, Asheville, NC, pp. 270-283, December 1993
[Spreitzer94] Spreitzer, M., Theimer, M.: Architectural Considerations for Scaleable, Secure, Mobile Computing with Location Information, Proc. ICDCS-94, , Poznan, Poland, June 21- 24,
1994
Page 275
[Sreenan96] Sreenan, C.J., Mishra, P.P.: Equus: a QoS manager for distributed applications,
Proc. IFIP/IEEE Conf. on Distributed Platforms, ICDP-96, Dresden, Feb. 1996, pp. 496-509
[Srivastava97] Srivastava, M., Mishra, P.P.: On Quality of Service in Mobile Wireless Networks,
Proc. 7th Int. Workshop on Network and Operating System Support for Digital Audio and Video,
May 19-21, 1997, St. Louis, Missouri, USA, pp. 147-158
[Steedman93] Steedman, D.: The Directory Standard and its Application, Technology Appraisals,
Twickenham, UK, 1993
[Steele92] Steele, R.; Nofal, M.: Teletraffic performance of microcellular personal communication
networks IEE Proceedings-I, Vol. 139, No. 4, August 1992, pp. 448-461
[Steen96] van Steen, M., Hauck, F.J., Tanenbaum, A.S.: A Model for Worldwide Tracking of Distributed Objects, Proc. TINA'96 Conference, Heidelberg, Germany, Sept. 1996, pp. 203-212
[Stokes00] Stokes, E.: Access Control Model for LDAP, IETF LDAP Extensions Working Group
Internet Draft, March 2000
[Stokes00a] Stokes, E.: The LDUP Replication Update Protocol, IETF LDUP Working Group Internet Draft, March 2000
[StPierre98] St Pierre, P.: Conversion of LDAP Schema to and from SLP Templates, IETF Draft,
draft-ietf-svrloc-template-conversion-3.txt, June 1998
[Strassner00] Strassner, J., Ellesson, E., Moore, B., Moats, R.: Policy Core LDAP Schema, IETF
Draft, draft-ietf-policy-core-schema-07.txt, July 2000
[Suzuki95] Suzuki, S., Nakanishi, T., Takahashi, T.: Personal Handy-phone System Signalling Protocol Architecture - Study on Internetwork Interface for PHS Roaming, Proc. ICUPC-95, pp.
553-557
[Suzuki96] Suzuki, S., Nakanishi, T: Call Routing and Data Model for Inter-Network Roaming in
PCS, IEICE Transactions on Communications, vol. E79-B, no. 9, pp. 1371-1379, 1996
[Szymaszek98] Szymaszek, J., Uszok, A., Zielinski, K.: Building a scalable and effcient component-oriented system using CORBA - an Active Badge system case study, Distributed Systems
Engineering, 5 (1998), pp. 200-213, 1998
[Tabbane95a] Tabbane, S., Nevoux, R.: An intelligent location tracking method for personal and
terminal FPLMTS/UMTS communication, Proc. XV International Switching Symposium, ISS'95,
Berlin, April 1995, pp. 114-118
[Tait91a] Tait, C.D., Duchamp, D.: Service interface and replica management algorithm for mobile
file system clients, Proceedings of Parallel and Distributed Information Systems Conference,
December 1991
[Tekinay98] Tekinay, S., Chao, E., Richton, R.: Performance Benchmarking for Wireless Location
Systems, IEEE Communications Magazine, April 1998, pp. 72-76
[Terry94] Terry, D.B., Demers, A., Petersen, K., Spreitzer, M., Theimer, M., Welch, B.: Session
guarantees for weakly consistent replicated data, Proc Int. Conf. on Parallel and Distributed Information Systems (PDIS), Austin, Texas, Sept. 1994, pp. 140-149
[Thißen96] Thißen, D., Linnhoff-Popien, C.: Finding Optimal Services Within a CORBA Trader,
Proceedings of Workshop on Trends in Distributed Systems, Aachen, Germany, 1996, pp. 200213
[3GPP] Third Generation Partnership Project (3GPP) home page, at http://www.3gpp.org/
[Trigila98] Trigila, S., Raatikainen, K., Wind, B., Reynolds, P.: Mobility in Long-Term Service Architectures and Distributed Platforms, IEEE Personal Communications, August 1998, pp. 44-55
[TruePosition] TruePosition home page at http://www.trueposition.com/
[Turner95] Turner, D.: Status and Future Directions for Global Intelligent Network Standards, Proc.
Intelligent Network Workshop, IN-95, Ottawa, Canada, May 9-11, 1995
[UPnP-Forum00] Universal Plug and Play Forum home page at http://www.upnp.org/
[UMTS-Forum99] UMTS Forum home page at http://www.umts-forum.org/
Page 276
[Verkama97] Verkama, M.: A Simple Implementation of Distance-Based Location Update, Proc.
Int. Conf. on Universal Personal Communications, ICUPC'97, San Diego, CA, October 1997,
pp. 163-167
[Voelker94] Voelker, G.M., Bershad, B.N.: Mobisaic: An Information System for a Mobile Wireless
Computing Environment, Proc. 1994 Workshop on Mobile Computing Systems and Applications, 1994
[Vogel95a] Vogel, A., Bearman, M., Beitz, A.: Enabling Interworking of Traders, Proc. 3rd IFIP
TC6/WG6.1 International Conf. on Open Distributed Processing (ODP-95), Brisbane, Australia,
1995
[Wachowicz96] Wachowicz, M, Hild, S.: Combining Location and Data Management in an Environment for Total Mobility, In Workshop on Information Visualization and Mobile Computing
(IMC'96), Rostok, Germany, February 1996
[Waldo98] Waldo, J.: Jini Architecture Overview, SUN White Paper, 1998,
http://www.javasoft.com/products/jini/whitepapers/index.html
[Walke97] Walke, B.: The present time and near future of Mobile Radio Networks and Services,
Introduction to Proc. 2nd European Personal Mobile Communica tions Conference EPMCC,
Sep. 30 - October 2, Bonn, Germany, 1997, pp. 343-349
[Wallbaum99] Wallbaum, M., Carrega, D., Krautgärtner, M., Decker, H.: A Mobile Middleware
Component Providing Voice Over IP Services To Mobile Users. Proceedings of ECMAST'99,
Lecture Notes in Computer Science Vol. 1629: Leopold, H.; Garcia, N., (Eds.) Multimedia Applications, Services and Techniques - ECMAST'99, Heidelberg, Germany, May 1999
[Wang93] Wang, J.Z.: A fully distributed location registration strategy for universal personal communication systems, IEEE Journal on Selected Areas in Communications, Vol. 11, No. 6, August 1993, pp. 850-860
[Want92] Want, R.; Hopper, A.: Active badges and personal interactive computing objects, IEEE
Transactions on consumer electronics, Vol. 38, No. 1, February 1992, pp. 10-20
[Want95] Want, R.; Schilit, B.N.; Adams, N.I.; Gold, R.; Petersen, K.; Goldberg, D.; Ellis, J.R.;
Weiser, M.: An Overview of the ParcTab Ubiquitous Computing Experiment, IEEE Personal
Communications, December 1995 - Vol. 2 No. 6
[Ward97] Ward, A., Jones, A., Hopper, A.: A New Location Technique for the Active Office, IEEE
Personal Communications, Vol. 4 No. 5, October 1997, pp. 43-47
[Weiser93] Weiser, M.: Some Computer Science Issues in Ubiquitous Computing, communications of the ACM, July 1993, Vol.36, No. 7, pp. 75-84
[WiData] WiData Firefly: Wireless Ressource Management home page at http://www.wi data.com
[Wind98] Wind, B., Samarotto, M., Nicosia, P., Lambrou, M., Tzifa, E.: Enhancing the TINA Architectural Framework for Personal Mobility Support, Proc. 5th Int. Conf. on Intelligence in Services and Networks, IS&N'98, Antwerp, Belgium, May 1998
[Wirth95] Wirth, P.E.: Teletraffic Implications of Database Architectures in Mobile and Personal
Communications, IEEE Communications Magazine, June 1995, pp. 54-59
[Wood97] Wood, K.R.; Richardson, T.; Bennett, F.; Harter, A.; Hopper, A.: Global Teleporting with
Java: Towards ubiquitous personalised computing, IEEE Computer, Feb. 1997
[Wormley00] Wormlay, S.: Sam Wormley's Overview on GPS maps and waypoints at
http://www.cnde.iastate.edu/staff/swormley/maps/maps_waypoints.html
[X.208] ITU-T Recommendation X.208: Open Systems Interconnection Model And Notation Specification Of Abstract Syntax Notation One (ASN.1), ITU-T, 1988
[X.500] ITU-T Recommendation X.501: Information Technology - Open Systems Interconnection The Directory: Overview of concepts, models, and services, ITU-T, 1997
[X.501] ITU-T Recommendation X.501: Information Technology - Open Systems Interconnection The Directory: Models, ITU-T, 1997
Page 277
[X.509] ITU-T Recommendation X.509: Information Technology - Open Systems Interconnection The Directory: Authentication Framework, ITU-T, 1997
[X.511] ITU-T Recommendation X.511: Information Technology - Open Systems Interconnection The Directory: Abstract Service Definition, ITU-T, 1997
[X.520] ITU-T Recommendation X.520: Information Technology - Open Systems Interconnection The Directory: Selected Attribute Types, ITU-T, 1997
[X.521] ITU-T Recommendation X.521: Information Technology - Open Systems Interconnection The Directory: Selected Object Classes, ITU-T, 1997
[X.525] ITU-T Recommendation X.525: Information Technology - Open Systems Interconnection The Directory: Replication, ITU-T, 1997
[X.701] ITU-T Recommendation X.701: Information Technology - Open Systems Interconnection Systems management overview, ITU-T, August 1997
[X.901] ITU-T Recommendation X.901: Information Technology - Oped distributed processing Reference Model: Overview, ITU-T, August 1997
[X.950] ITU-T Recommendation X.950: Information Technology - Oped distributed processing Trading Function: Specification, ITU-T, August 1997
[X.952] ITU-T Recommendation X.952: Information Technology - Oped distributed processing Trading Function: Provision of trading function using OSI directory service, ITU-T, August 1997
[XDS94] API to Directory Services (XDS), Issue 2, CAE Specification, X/Open Company, 1994
[Xie93] Xie, H.; Tabbane, S.; Goodman, D.: A dynamic location area management and performance analysis, Proc. of IEEE-93 Veh. Technol. Conf., Secaucus, NJ, 18-20 May 1993, pp. 536539
[XML1.0] Extensible Markup Language (XML) 1.0, W3C Recommendation, February 1998
[Yoshino98] Yoshino, H., Yamamoto, H., Matsue, H.: Mobility Management Schemes and Their
Characteristics for Advanced Personal Communication Services in Distributed Environments,
IEICE Trans. Commun., Vol. E81-B, No. 6, June 1998, pp. 1162-1170
[Zagami98] Zagami, J.M., Parl, S.A., Bussgang, J.J., Devereaux, K.: Providing Universal Location
Services Using a Wireless E911 Location Network, IEEE Communications Magazine, April
1998, pp. 66-71
[Zenel97] Zenel, B., Duchamp, D.: A General Purpose Proxy Filtering Mechanism Applied to the
Mobile Environment, Proc. MobiCom'97, 26-30 September, Hungary, Budapest, 1997, pp. 248259
Page 278
A. Appendix: Summary of UML syntax
Structural object class, object instances may
be created from this object class.
ClassA
Auxiliary object class, object instances may
be created from this object class only in aggregations with other - structural - object
classes.
<<auxiliary>>
ClassB
Abstract object class, no instances may be
created from this object class. It is only used
to derive subclasses.
<<abstract>>
ClassD
Attributes of object class. Optional attributes
are embraced in square brackets[ ]. All object
classes have an attribute objectClass not
shown in UML diagrams. Attributes that have
a :N declaration may be used to name object
instances.
ClassE
attributeA
[attributeB]
attributeX : N
ClassA
ClassC
<<auxiliary>>
ClassB
has
ClassA
1
0..*
label
ClassA
1
ClassC
0..*
label
ClassA
0..*
C lassA
C lassA
ClassA
ClassC
1
placed-below
placed-below(root)
aliased-below
C lassC
C lassC
Object class ClassC is a subclass of object
class ClassA and inherits all attributes and
derivation rules.
An instance of object class ClassA may be
aggregated with instances of auxiliary object
class ClassB into a common object.
Bi-directional association between object
classes. Each instance of ClassA may be
associated with any number of instances of
ClassC, but an instance of ClassC is only
associated with one instance of ClassA.
label is the name of the association and
specifies its type or function.
Uni-directional association between object
classes. The association is navigable only in
the direction from ClassC to ClassA.
The placed-below dependency defines
that the instances of object class ClassC
(and all its subclasses) may be placed below
instances of object class ClassA (and all its
subclasses).
placed-below(root) allows placement
only below root object of the OMP information tree.
ClassC
An aliased-below dependency defines
that an additional virtual placement of an object of ClassC is allowed below instances of
object class ClassA (and all its subclasses)
by means of an alias object.
Page 279
The attributeC is an internally derived attribute. The derivation rule must be defined in
the operation compartment of the same class
if it is a structural or auxiliary class. If it is an
abstract class, the derivation rule may be defined in a subclass. A rule defined in a class
applies to all its subclasses.
ClassF
attributeA
/attributeC
/attributeT
/attributeC(attributeA) : ClassG(attributeB=attributeA):attributeD
/attributeT() : ClassH(CHILDREN)[1]:attributeY
ClassG
attributeB
attributeD
The value of attributeC is derived from
the value of attributeD in instance of
classG. Each instance of ClassG is used in
which the specified search filter evaluates to
true.
The derivation rules support these search
filters:
- equality selection (=),
- nearest-to selection (~),
- contains selection (^) and
- children selection
(<class>(CHILDREN):<sourceAttribute>).
The number of selected source entries may
be restricted with the [n] clause after the
search filter.
Static attributes defined in abstract classes
may be re-defined in subclasses as internally
or externally derived attribute. Redefining derived attributes as static is NOT allowed.
<<abstract>>
ClassH
attributeA
ClassI
Attributes defined in non-abstract classes
must not be re-defined in subclasses.
ClassK
/attributeA
/attributeA() : rule1
ClassK
/attributeA
/attributeA() : rule1
<<auxiliary>>
ClassM
/attributeA
ClassL
/attributeA() : rule2
/attributeA() : rule3
C lassO
>attributeA
attributeB
>attributeA (attributeB)
Rules for internally derived attributes are cumulative.
In ClassL three rules are applied to derive
the value of attributeA: Rule 1 is inherited
from its superclass, rule2 is defined in
classL, and rule3 is aggregated from
ClassM.
Externally derived attributes must have a
derivation rule defined in the operation compartment of the same class if it is structural or
auxiliary. Abstract classes may define the
rules in subclasses.
attributeB is used as argument for deriving attributeA. External derivation rules
are not further detailed in the UML specification.
Externally derived attributes are NOT cumulative, for each attribute there may be only a
single derivation rule defined.
Page 280
Changes in externally derived attributes may
be signalled to OMP clients.
ClassQ
>attributeA
>attributeA() : EVENT(condition)
Internally and externally derived attributes
declared as mandatory may or may not have
values.
ClassP
[/attributeA]
/attributeB
Only the derivation rule is mandatory, it may
however be specified in subclasses if the defining class is an abstract class.
Attributes in abstract object classes may be
classified as abstract attributes, specified as
type ":A".
<<abstract>>
ClassR
xAttributeA : A
/xAttributeB : A
ClassS
aAttributeA
/aAttributeB
ClassT
bAttributeA
/bAttributeB
C lassZ
attributeA
attributeB
#attributeA (attributeB)
ClassU
<AttributeSetA>
attributeB
ClassV
attributeB
Every time the event condition is fulfilled, the
attributeA is associated with a new value
and is sent to OMP clients interested in this
information (i.e. having subscribed to this
event).
<<attributeSet>>
AttributeSetA
attributeA
attributeC
<<attributeSet>>
AttributeSetA
attribu teA
attribu teC
Abstract attributes must be replaced by attribute subtypes in non-abstract subclasses.
This allows specifying that an attribute must
be replaced with semantically compatible attributes.
Attribute values may be exported to external
equipment. Export rules "#" specify in the
operation compartment the attribute type and
may contain parameters to specify the target
equipment.
The UML specification may define an attribute set < > for one or more attributes. The
attribute set reduces the number of shown
attributes to either enhance legibility or to delay the more detailed specification to a later
time. The attributes defined by an attribute
set may be specified with an <<attributeSet>> stereotyped class. It defines only attributes but no operations.
An alternative way to specify the containment
of attribute sets in an object class is to use a
containment association with a solid diamond.
Page 281
B. Appendix: OMP information tree example
MMDFederation (mmdId = philips)
root of OMP information tree
|
| RoamingArea (roamingAreaId = global)
subtree of federation-replicated MMD pointers
| | Objects (objects = residents)
value 'residents' reserved for resid. subscript.
|
| MMDPointer (objectId = 500)
home pointer referring to home MMD
|
| MMDPointer (objectId = 501)
|
| MMDPointer (objectId = 502)
|
| MMDPointer (objectId = 549)
|
| MMD (mmdId = AC)
root of MMD subtree
| | Alias (roamingAreaId = global) -> (mmdId = philips, roamingAreaId = global)
| |
alias to replicated home pointer subtree
| | Alias (users = global) -> (mmdId = philips, users = global)
| |
alias to replicated OMP user subtree
| | RoamingArea (roamingAreaId = local)
roaming area for locally managed objects
| | | Objects (objects = residents)
resident hookedObject entries placed below
| | | | HookedObject (objectId = 511)
represents hooked object resident in this MMD
| | | | HookedObject (objectId = 522)
| | | | HookedObject (objectId = 533)
| | |
| | | Objects (objects = visitors)
visiting hookedObject entries are placed below
| | | | HookedObject (objectId = 549)
represents a hooked object visiting this MMD
| | |
| | | RoamingArea (roamingAreaId = sopho)
roaming area of all PBXs
| | | | OMPAdapter (name = sopho0)
adapter for PBX equip. in roamingArea sopho0
| | | | OMPAdapter (name = sopho1)
adapter for PBX equip. in roamingArea sopho1
| | | + Objects (objects = residents)
| | | + Objects (objects = visitors)
| | |
| | | RoamingArea (roamingAreaId = abs)
roaming area of an Active Badge System
| |
| Objects (objects = residents)
root of subtree for resident tag subscriptions
| |
| | ABSTag (objectId = 2)
represents a tag resident in this MMD
| |
|
| |
| Objects (objects = visitors)
root of subtree for visitor tag subscriptions
| |
| | ABSTag (objectId = 1)
represents a tag visiting this MMD
| |
|
| |
| OMPAdapter (name = abs0)
adapter for interfacing with ABS system
| |
| OMPAdapter (name = abs1)
adapter for interfacing with ABS system
| |
| | CompositeArea (areaId=g)
root of subtree for areas inside a building
|
| CompositeArea (areaId=g1)
is a floor
|
| | BasicArea (areaId = g116)
is an office room
|
| | BasicArea (areaId = g117)
|
| | BasicArea (areaId = g119)
|
|
| FixedTerminal (objectId = 1234)
fixed terminals may be placed below an area
|
|
|
+ CompositeArea (areaId=g2)
|
+ CompositeArea (areaId=g3)
|
+ MMD (mmdId = ehv)
root of other MMD subtree
|
| Users (users = global)
subtree for globally subscribed OMP users
| OMPUser (name = maass)
subscription entry of OMP user
| OMPUser (name = meyer)
Note: Not all subtrees have been expanded in the example above, they are preceeded with a "+".
Page 283
C. Appendix: Introduction to Augmented BNF
and LDAP BNF
The LDAP standards and our Dynamic Directory Services specification make use of the
same popular augmented BNF that is used in many Internet RFCs. The BNF syntax is defined in [RFC2234]; the differences to standard BNF involve naming rules and indicating
repetition and "local" alternatives. The extensions of the augmented BNF compared to
conventional BNF and the most important definitions from the LDAP standard used in this
work are summarised in this appendix.
C.1 Augmented BNF
rule naming: Angle brackets ("<", ">") are not used, in general. The name of a rule is
simply the name itself, rather than "<name>". Quotation-marks enclose literal text. Rule
names are case-insensitive.
rule1 / rule2: alternatives: Elements separated by slash ("/") are alternatives. Therefore
"foo / bar" will accept foo or bar.
(rule1 rule2): local alternatives: Elements enclosed in parentheses are treated as a
single element. Thus, "(elem (foo / bar) elem)" allows the token sequences "elem foo
elem" and "elem bar elem".
*rule: repetition: The character "*" preceding an element indicates repetition. The full
form is: <l>*<m>element indicating at least <l> and at most <m> occurrences of element.
Default values are 0 and infinity so that "*(element)" allows any number, including zero;
"1*element" requires at least one; and "1*2element" allows one or two.
[rule]: optional: Square brackets enclose optional elements; "[foo bar]" is equivalent to
"*1(foo bar)".
Comments: Comments start after a semi-colon and continue to the end of line.
Page 285
C.2 Terms defined in the LDAP standards
The following terms defined in the LDAP standard [ RFC2252] are used in the BNF specifications in this document:
a
d
k
p
=
"a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i" /
"j" / "k" / "l" / "m" / "n" / "o" / "p" / "q" / "r" /
"s" / "t" / "u" / "v" / "w" / "x" / "y" / "z" / "A" /
"B" / "C" / "D" / "E" / "F" / "G" / "H" / "I" / "J" /
"K" / "L" / "M" / "N" / "O" / "P" / "Q" / "R" / "S" /
"T" / "U" / "V" / "W" / "X" / "Y" / "Z"
= "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
= a / d / "-" / ";"
= a / d / """ / "(" / ")" / "+" / "," / "-" / "." / "/" / ":" /
"?" / " "
letterstring
numericstring
anhstring
keystring
printablestring
space
whsp
utf8
=
=
=
=
=
=
=
=
1*a
1*d
1*k
a [ anhstring ]
1*p
1*" "
[ space ]
<any sequence of octets formed from the UTF-8
transformation of a character from ISO10646>
dstring
qdstring
qdstringlist
qdstrings
oid
descr
numericoid
woid
oids
oidlist
qdescrs
qdescrlist
qdescr
noidlen
len
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
1*utf8
whsp "'" dstring "'" whsp
[ qdstring *( qdstring ) ]
qdstring / ( whsp "(" qdstringlist ")" whsp )
descr / numericoid
keystring
numericstring *( "." numericstring )
whsp oid whsp
woid / ( "(" oidlist ")" )
woid *( "$" woid )
qdescr / ( whsp "(" qdescrlist ")" whsp )
[ qdescr *( qdescr ) ]
whsp "'" descr "'" whsp
numericoid [ "{" len "}" ]
numericstring
AttributeDescription = LDAPString
AttributeType
= LDAPString ; may contain OID or textual name
AttributeValue
= OCTET STRING
MatchingRuleId
= LDAPString ; may contain OID or textual name
LDAPString
= OCTET STRING ; with UTF-8 encoded ISO10646 character
set
Page 286
D. Appendix: Dynamic Directory Schema
Several LDAP information model elements are identified by globally-unique numeric object
identifiers (OIDs), e.g. attribute types, object classes, and matching rules. Most LDAPv3
object identifiers start with the OID sequence 1.3.6.1.4.1.1466.xxx, being a branch registered by a private company. For the Dynamic Directory extensions to LDAP and the OMP
schema elements, we have to create new OIDs. Since there is no branch assigned to the
author of this work, the new OIDs are not registered globally but privately and are used
solely for unambiguously identifying definitions in this document. In the following, the following OID scheme is used:
dds.1.x
attribute type definitions for Dynamic Directory Services
dds.2.x
object class definitions for Dynamic Directory Services
dds.3.x
attribute syntax definitions for Dynamic Directory Services
dds.4.x
matching rules identifiers for Dynamic Directory Services
dds.5.x
LDAP control identifiers
New Dynamic Directory LDAP controls
Control name
Control
type OID
Criticality
Values
Default value
Defined on
page
consistencyLevel
dds.5.3
false
entry, operation
entry
142
excludeCollectiveAttributes
dds.5.6
false
true, false
false
213
excludeDerivedAttributes
dds.5.1
false
true, false
false
142, 213
includeOperationalAttributes
dds.5.5
false
true, false
false
213
noAttributeCaching
dds.5.2
false
true, false
false
142, 152
returnSubentriesOnly
dds.5.4
false
true, false
false
210
Since all control values are optional, always a default value must be defined. The criticality
field specifies whether a directory server is allowed to perform the operation if it does not
recognise the control type. If criticality is true, it may perform the operation only if it recognises the control type [RFC2251].
One additional control has been defined for Dynamic Directory LDAP APIs:
Control name
Control
type OID
Criticality
Values
Default value
Defined on
page
skipReferenceIfComplete
N/A
N/A
true, false
false
142
Page 287
Control type and criticality are not applicable to API controls, since there is a fixed binding
between application and API. The control is not sent to the Dynamic Directory server but
interpreted solely by the API.
New Dynamic Directory LDAP result codes
Error name
LDAP result code
Returned with LDAP operation
Defined
on page
consistencyError
103
search entry with internally derived attributes
141
derivationRuleConflict
100
search, add, modify entry with internally or externally derived attributes
141,
153, 224
derivationRuleError
102
search, add, modify entry with internally derived attributes
141
derivationRuleLoop
101
search, add, modify entry with internally derived attributes
141
derivationRuleParameterMissing
104
search Adapter entry with externally derived attributes
153
eventDefinitionError
108
add event definition entry
189
eventMonitoringError
110
search for notification entries terminated by server
192
eventTriggerError
109
add event definition entry
189
exportRuleError
111
add, modify, or delete entry with exported attributes
207
externalServerError
106
search entry that derives attributes from Adapter entry
add event definition entry that interacts with external
server
add, modify, or delete entry with exported attributes
153
189
207
externalServerUnavailable
105
search entry that derives attributes from Adapter entry
add event definition entry that interacts with external
server
add, modify, or delete entry with exported attributes
153
189
207
incompleteExternalAttributes
107
search entry that derives attributes from Adapter entry
153
New Dynamic Directory system schema - attributes
Attribute Name
OID
Syntax
Operational
/User
SingleValue
Collective
No User
Modification
Defined
on Page
actionConditions
dds.1.10
DirectoryString
O, U
n
y
n
166
actionError
dds.1.30
DirectoryString
O, U
y
n
y
175
cacheTime
dds.1.2
NumericString
O
n
y
n
135
candidateReference
dds.1.31
IA5String
O, U
y
n
y
175
candidateEntry
dds.1.29
DistinguishedName
O, U
y
n
y
174
classCandidateAVA
dds.1.57
DirectoryString
O, U
n
y
n
181
classScopeEvents
dds.1.33
DirectoryString
O
n
n
y
180
Page 288
configuredMatchingRule
dds.1.48
DistinguishedName
O
n
n
y
204
configuredMatchOID
dds.1.49
DirectoryString
O
y
n
n
203
createdEventTrigger
dds.1.21
DirectoryString
O
n
n
y
172
doNotClone
dds.1.59
Boolean
O
y
y
n
224
endpoint
dds.1.36
DirectoryString
O
y
n
n
148
entryLifetime
dds.1.52
NumericString
O, U
y
n
n
209
evaluationMatrix
dds.1.51
DirectoryString
O
n
n
n
203
eventAction
dds.1.16
DirectoryString
O, U
n
y
n
169
eventDefinitionId
dds.1.4
DirectoryString
O, U
y
n
n
162
eventDescription
dds.1.19
DirectoryString
U
n
y
n
172
eventError
dds.1.22
DirectoryString
O, U
n
n
y
172
eventLifetime
dds.1.17
NumericString
O, U
y
y
n
170
eventMethodName
dds.1.47
DirectoryString
O
y
n
n
185
eventStartTime
dds.1.20
GeneralizedTime
O, U
y
n
y
172
eventStatus
dds.1.23
DirectoryString
O, U
y
y
n
170
eventStopReason
dds.1.24
DirectoryString
O, U
y
n
y
171
eventXmlPayload
dds.1.44
DirectoryString
O
n
n
n
185
export
dds.1.54
DirectoryString
O
y
y
n
206
extractIdentifier
dds.1.46
DirectoryString
O
y
n
n
187
extractIdentifier
dds.1.56
DirectoryString
O
n
n
n
187
host
dds.1.34
DirectoryString
O
y
n
n
148
import
dds.1.3
DirectoryString
O
n
n
n
146
includeExternalValues
dds.1.42
Boolean
O, U
y
y
n
169
includeOldValues
dds.1.13
DirectoryString
O, U
n
y
n
168
includeReference
dds.1.14
Boolean
O, U
y
y
n
169
inlcudeAliasValues
dds.1.15
Boolean
O, U
y
y
n
169
interfaceName
dds.1.37
DirectoryString
O
y
n
n
148
ldapURL
dds.1.41
DirectoryString
O
y
n
n
150
methodName
dds.1.38
DirectoryString
O
y
n
n
148
mPost
dds.1.40
Boolean
O
y
n
n
148
nearestMatch
dds.1.50
Boolean
O
y
n
n
203
noRDNTriggers
dds.1.32
Boolean
O, U
y
y
n
178
notificationContent
dds.1.12
DirectoryString
O, U
n
y
n
168
notificationId
dds.1.25
NumericString
O, U
y
n
y
173
notificationLifetime
dds.1.11
NumericString
O, U
y
y
n
168
notificationLimit
dds.1.18
NumericString
O, U
y
y
n
170
notificationReason
dds.1.27
DirectoryString
O, U
y
n
y
174
Page 289
notificationTime
dds.1.26
GeneralizedTime
O, U
y
n
y
174
notify
dds.1.45
DirectoryString
O
n
n
n
185
optimisticPartialCandidate
dds.1.8
Boolean
O, U
y
y
n
167
pollingTime
dds.1.43
NumericString
O
y
n
n
183
port
dds.1.35
DirectoryString
O
y
n
n
148
reference
dds.1.1
DirectoryString
O
n
y
n
133
scopeClass
dds.1.6
DirectoryString
O, U
y
y
n
163
scopeFilter
dds.1.5
DirectoryString
O, U
n
y
n
163
scopeLimitNamingContext
dds.1.7
Boolean
O, U
y
y
n
163
subtreeSpecification
dds.1.53
DirectoryString
O
y
n
n
210
suppressDN
dds.1.55
Boolean
O
y
y
n
206
triggerConditions
dds.1.9
DirectoryString
O, U
n
y
n
165
triggerEntry
dds.1.28
DistinguishedName
O, U
y
n
y
174
triggerFireId
dds.1.58
NumericString
O, U
y
n
y
174
xmlPayload
dds.1.39
DirectoryString
O
y
n
n
148
New Dynamic Directory system schema - object classes
Object Class Name
OID
Class type
Defined on page
adapter
dds.2.1
abstract
146
collectiveAttributeSubentry
dds.2.14
structural
210
derivationRuleTemplate
dds.2.15
structural
211
eventDefinition
dds.2.5
structural
162
eventDefinitionTemplate
dds.2.16
structural
211
eventNotification
dds.2.7
structural
173
exportAdapter
dds.2.17
abstract
206
exportRuleTemplate
dds.2.19
structural
211
importAdapter
dds.2.2
abstract
146
ldapImportAdapter
dds.2.4
structural
150
matchingRuleSubentry
dds.2.11
structural
203
preconfiguredEventDefinition
dds.2.6
structural
173
pullEventImportAdapter
dds.2.8
abstract
182
pushEventImportAdapter
dds.2.9
abstract
183
soapExportAdapter
dds.2.18
structural
206
soapImportAdapter
dds.2.3
structural
148
soapPushEventImportAdapter
dds.2.10
structural
185
softEntry
dds.2.12
auxiliary
209
Page 290
subentry
dds.2.13
abstract
210
New Dynamic Directory syntax definitions
Syntax Name
OID
Defined on page
D3Line
dds.3.3
196
D3Point
dds.3.1
195
D3RectangularSolid
dds.3.2
196
New Dynamic Directory matching rule definitions
Matching Rule Name
OID
Assertion Value Syntax
Defined on page
configuredMatch
dds.4.3.x
(variable)
204
containedMatch
dds.4.1.2
D3RectangularSolid
196
containsMatch
dds.4.1.1
D3Point
196
d3NearestMatch
dds.4.2.2
D3Point
199
numericNearestMatch
dds.4.2.1
NumericString
199
positionNearestMatch
dds.4.2.3
DirectoryString
199
stringNearestMatch
dds.4.2.4
DirectoryString
199
Page 291
E. Appendix: Attribute derivation algorithms
A number of tasks have to be performed on internal attribute derivation rules before the
rules may be evaluated by the Dynamic Directory server as specified in section 1.26.3.1:
Detect loops, sort rules into an executable sequence, and determine the subset of rules
that must be evaluated for a given set of attributes being requested from an entry.
These tasks may be easily performed with well-known graph algorithms by constructing directed acyclic graphs from the derivation rules and their dependencies. Let |D| be the
number of derived attributes defined in an entry (in the entry itself and in the auxiliary object classes contributing to the entry's contents). At most |D| connected directed graphs
Gi=(Vi,Ei) may be constructed, where Vi are the vertices representing internally derived attributes in Gi and Ei are the edges, representing dependencies of derivation rules from
other internally derived attributes in Gi.
Considering for example the following static and internally derived attributes, two connected directed graphs G1 and G2 may be constructed as depicted in Figure 71:
attC = valueC
// static attribute
attE = valueE
// static attribute
reference = attA=f($attB,$attC) // derived attr. with two parameter attrs.
reference = attA=f($attD)
// derived attribute with parameter attribute
reference = attB=f($attD)
// …
reference = attD=f($attE)
reference = attF=f($attG)
reference = attG=F($attH)
reference = attH=f($attF)
attA
G1
attB
attD
attF
G2
attG
attH
Figure 71: Dependency graphs created from attribute derivation rules
Derived attributes are represented by vertices, the edges represent a "depends-on" relationship caused by using other derived attributes as parameters in derivation rules. The
graph G1 is acyclic, whereas the graph G2 contains a cycle and therefore a loop between
derivation rules that must be detected and rejected as an error by the Dynamic Directory.
For the graph G1, the executable sequence of derived attributes must be attD, attB,
attA. The execution order of rules for the same attribute type is irrelevant since they are
never dependent from each other (otherwise this would impose a dependency from a derived attribute onto itself which is rejected by the Dynamic Directory).
Page 293
The problem of detecting cycles in the graphs and sorting the vertices into an executable
sequence may be solved with well-known algorithms that perform topological sorting (and
detect cycles) on a directed graph, see e.g. [Ottmann98, Chapter 8.1]. It is shown there that
such algorithms can be performed in execution times growing linearly with O(|V|+|E|) if
the graph is efficiently stored as adjacency list. The processing sequence of derivation
rules is defined by the topological order of the vertices, starting with a vertex having no
edge entering the vertex and therefore being independent of the other internally derived
attributes.
For the problem of identifying that subset of all derived attributes that must be evaluated
for a given subset of target attributes it is possible to employ well-known graph searching
algorithms that visit all vertices that are reachable from a given vertex, see e.g. [ Ottmann98,
Chapter 8.3]. By starting from all vertexes (i.e. derived attributes) that are requested by a directory operation, the algorithm detects and marks all attributes that must be derived by
the Dynamic Directory server. For these algorithms it can again be shown that the execution time grows linearly with O(|V|+|E|) if the graph is efficiently stored as adjacency list.
The remaining question is how an adjacency list can be efficiently constructed from a
given set of attribute derivation rules. The principle algorithm for this is:
// Algorithm assumes that for each derived attribute defined for an entry E
// a vertex element has been initialised in a set S(E). This set is also used
// to determine whether an attribute type is derived or static in entry E.
foreach rule R in entry E {
DA = attribute being derived by rule R
search vertex element V(DA) for attribute DA in S(E)
foreach parameter-attribute PA in rule R {
search vertex element V(PA) for attribute PA in S(E)
if found {
add edge-element to the adj. list of V(DA) pointing to V(PA)
} else {
// PA is a static attribute, no edge-element to be added to adj. list
}
}
}
The processing time of the shown algorithm grows with |R|*|PA|*|DA|, where |R| is the
number of derivation rules present in an entry, |PA| is the average number of parameters
in a derivation rule, and |DA| is the number of derived attributes defined for the entry. Assuming that the number of parameters |PA| is constant and does not depend on the number of derived attributes defined for an entry; and further assuming that the number of actually present rules |R| is proportional to the number of derived attributes defined in an entry; the processing time of the initialisation algorithm may be estimated to grow with
O(|DA|2).
The creation of the adjacency list should be performed not for each derivation rule evaluation. Instead, it should be done only once when the entry is initially fetched from the database (i.e. its master entry is created - cf. section 1.34.3.3) and every time after the entry's
derivation rules have been modified. During derivation rule evaluation for a specific directory operation, only the selection of requested derivation rules must then be performed,
which may be executed efficiently as discussed above.
Page 294
F. Appendix: Scaleability calculations
Main memory
We differentiate three sizes of categories of OMP directory entries, as shown in Table 8.
The size estimations have been extrapolated from measured entry sizes in our OMP prototype implementation.
category
represented entries
estimated size
Sse-a
alias and OMPUser entries
500B
Sse-o
entries with static attributes
1000B
Sde
entries with internally derived attributes
1500B
Table 8: Entry size estimations
From the assumptions stated in section 1.38.1, the following numbers and sizes of master
and soft entries contained in each DDS server may be calculated:
symbol
size
number of entries
Ncu
entries of class
OMPUser
Sse-a
Ncu=Nomp
Nmlo
locatableObject (with derived attributes)
Sde
Nmlo=3*(Nmu+Nv)
Nae
MMDpointer
Sse-a
Nae=3*Nomp
Nsa
spatialArea (with derived attributes)
Sde
Nsa=Nmu
Nslo
locatableObject (without derived attributes)
Sse-o
Nslo=4*Nmu
Nev
eventDefinition
Sse-o
Nev=1.1*Nmu
Nne
eventNotification
Sse-o
Nne=Nnot*Nev=33*Nmu
Table 9: Numbers of entries present in OMP DIT per DDS server
The resulting size of main memory SM required for the entry cache for master entries, soft
entries, and clones in each DDS server is:
SM = Sde*(1+Nc)*(Nmlo+Nsa) + Sse-a*(Nae+Ncu) + Sse-o*(2*Nslo+Nev+Nne).
The memory usage of subentries, MMD entries, location area entries and Adapter entries
has been neglected, since these entries represent only a small fraction of the overall
number of entries. The dependency of the achievable number of users in an MMD Federation from the number of OMP servers is shown in Figure 66. How the relative memory
usage of different entry types depends on the number of OMP servers is shown in Figure
67.
Page 295
Performance
For calculating how many users may be handled by an OMP server, we divide the maximum number of directory server operations estimated in section 1.38.2 by the number of
operations associated with a single OMP user on average calculated from the assumptions stated in section 1.38.2. The formulas and calculations for these scenarios are given
in Table 10, Table 11, and Table 12.
retrieval scenario
maximum number of search operations per server
hookedObject retrievals per user: 1/10s
#search ops per hookedObject retrieval: No
relative load for spatialArea retrievals: Ra
#search ops per spatialArea retrieval: Na
sum searches caused per user
clone cleanup operations: 10% of search ops: Rc
search-equivalent ops from non-indexed updates
search equivalent ops from indexed updates
overall search-equivalent operations
maximum number of non-indexed updates per serv.
non-indexed updates per user: 1/10min
non-indexed updates per fixed tag: 1/24h
#fixed tags per user (same as per area)
overall non-indexed updates
maximum number of indexed updates per server
indexed updates per user: 1/h
indexed updates per fixed tag: 1/48h
overall indexed updates
OMP users per MMD / OMP server
per user/s
6
0.1
8
0.1
0.1
0.6
0.01
0.08
0.68
0.068
0.001712963
0.066872428
0.816585391
per server/s
2000
2000.00
36
0.001666667
1.157E-05 4.62963E-05
4
0.001712963
0.000277778
5.787E-06 2.31481E-05
0.000300926
2449.22
Table 10: Retrieval scenario
Page 296
4.20
9
0.68
Lmaxs
Lro
Lso=Lro*No
Lra=Lro*Ra
Lsa=Lra*Na
Lr=Lso+Lsa
Lcc=Lr*Rc
Lniu=Uni
Liu=Ui*Lmaxs/Lmaxiu
Ls=Lr+Lcc+Lniu+Liu
Lmaxniu
Unio
Unift=1/(24*3600)*Nft
Nft
Uni=Unio+Unift
Lmaxiu
Uio=1/3600
Uift=1/(48*3600)*Nft
Ui=Uio+Uift
Nu=Lmaxs/Ls
event scenario
maximum number of search operations per server
event evaluations on hookedObject: 1/60s
#search ops per hookedObject event: No
relative occurrence of spatialArea events: Ra
#search ops per spatialArea event: Na
sum searches caused per user
clone cleanup operations: 10% of search ops: Rc
cleanup operations of notifications: = #events
search-equivalent ops from non-indexed updates
search equivalent ops from indexed updates
search ops from event definition
overall search-equivalent operations
maximum number of non-indexed updates per serv.
non-indexed updates per user: 1/10min
non-indexed updates per fixed tag: 1/24h
#fixed tags per user (same as per area)
overall non-indexed updates
maximum number of indexed updates per server
event definitions on hookedObject: 1/4h
event definitions on spatialArea:
#indexed updates per event definition: Ne
indexed updates per user: 1/h
indexed updates per fixed tag: 1/48h
overall indexed updates
OMP users per MMD / OMP server
per user/s
7
0.1
9
0.1
per server/s
2000
0.01666667
0.116666667
0.00166667
0.015
0.131666667
0.013166667
0.018333333
0.001712963
0.100823045
0.000548611
0.266251286
2000.00
36
0.001666667
1.157E-05 4.62963E-05
4
0.001712963
12.87
9
6.9444E-05
6.9444E-06
2 0.000152778
0.000277778
5.787E-06 2.31481E-05
0.000453704
3.41
7511.70
Lmaxs
Leo
Lso=Leo*No
Lea=Leo*Ra
Lsa=Lea*Na
Le=Lso+Lsa
Lcc=Le*Rc
Lcn=Leo+Lea
Lniu=Uni
Liu=Ui*Lmaxs/Lmaxiu
Lsed=Ledo*No+Leda*Na
Ls=Le+Lcc+Lcn+Lniu+Liu+Lsed
Lmaxniu
Unio
Unift=1/(24*3600)*Nft
Nft
Uni=Unio+Unift
Lmaxiu
Ledo
Leda=Ledo*Ra
Uie=(Ledo+Leda)*Ne
Uio=1/3600
Uift=1/(48*3600)*Nft
Ui=Uie+Uio+Uift
Nu=Lmaxs/Ls
Table 11: Event scenario
retrieval scenario with caching
maximum number of search operations per server
hookedObject retrievals per user: 1/10s
cachetime of locatable object in sec
#search ops per hookedObject retrieval: No
relative load for spatialArea retrievals: Ra
cachetime of spatialArea object in sec
#search ops per spatialArea retrieval: Na
sum searches caused per user
clone cleanup operations: 10% of search ops: Rc
search-equivalent ops from non-indexed updates
search equivalent ops from indexed updates
overall search-equivalent operations
maximum number of non-indexed updates per serv.
non-indexed updates per user: 1/10min
non-indexed updates per fixed tag: 1/24h
#fixed tags per user (same as per area)
overall non-indexed updates
maximum number of indexed updates per server
indexed updates per user: 1/h
indexed updates per fixed tag: 1/48h
overall indexed updates
OMP users per MMD / OMP server
20s cache
30s cache
60s cache
2000
6
0.1
8
0.1
0.1
20
0.25
0.01
20
0.035
0.395
0.0395
0.001712963
0.066872428
0.503085391
0.1
30
0.166666667
0.01
30
0.023333333
0.3
0.03
0.001712963
0.066872428
0.398585391
0.1
60
0.083333333
0.01
60
0.011666667
0.205
0.0205
0.001712963
0.066872428
0.294085391
0.001666667
4.62963E-05
0.001666667
4.62963E-05
0.001666667
4.62963E-05
0.001712963
0.001712963
0.001712963
0.000277778
2.31481E-05
0.000300926
0.000277778
2.31481E-05
0.000300926
0.000277778
2.31481E-05
0.000300926
3975.47
5017.75
6800.75
36
1.16E-05
4
9
5.79E-06
Lmaxs
Lro
Tco
Lso=1/Tco*(No-1)
Lra=Lro*Ra
Tca
Lsa=Ra/Tca*(Na-1)
Lr=Lro+Lra+Lso+Lsa
Lcc=Lr*Rc
Lniu=Uni
Liu=Ui*Lmaxs/Lmaxiu
Ls=Lr+Lcc+Lni+Li
Lmaxniu
Unio
Unift=1/(24*3600)*Nft
Nft
Uni=Unio+Unift
Lmaxiu
Uio=1/3600
Uift=1/(48*3600)*Nft
Ui=Uio+Uift
Nu=Lmaxs/Ls
Table 12: Retrieval scenario with caching
Page 297