as a PDF
Transcrição
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