Composable Ad-hoc Mobile Services for Universal Interaction Todd D. Hodes, Randy H. Katz, Edouard Servan-Schreiber, Lawrence Rowe Computer Science Division University of California at Berkeley (hodes,randy,edss,larry) @cs.berkeley.edu August 2,1997 Abstract This paper introduces the notion of “universal interaction,” allowing a device to adapt its functionality to exploit services it discovers as it moves into a new environment. Users wish to invoke services - such as controlling the lights, printing locally, or reconfiguring the location of DNS servers - from their mobile devices. But aptiotistandardizationof interfaces and methods for service invocation is infeasible. Thus, the challenge is to develop a new service architecture that supports heterogeneity in client devices and controlled objects, and which makes minimal assumptions about standard interfaces and control protocols. There are five components to a comprehensive solution to this problem: 1) allowing device mobility, 2) augmenting controllable objects to make them network-accessible, 3) building an underlying discovery architecture, 4) mapping between exported object inter- faces and client device controls, and 5) building complex behaviors from underlying composableobjects. We motivate the need for these components by using an ex- ample scenario to derive the design requirements for our mobile services architecture. We then present a prototype implementation of elements of the architecture and some example services using it, including controls to audio/visual equipment, extensible map- ping, server autoconfiguration, location tracking, and local printer access. 1 Introduction Researchers have predicted that wireless access coupled with user mobility will soon be the norm rather than the exception, allow- ing users to roam in a wide variety of geographically distributed environments with seamless connectivity [3q. This
`Copyright 1997 ACM 0-8979L988-2l97/9..%3.50 This paperinvestigates novel uses of a ubiquitous network, focus- ing on variable network services in the face of changing connectivity and heterogeneous devices. We propose that providing an “IP dial- tone” isn’t enough; we must add additional service infrastructure to augment basic IP connectivity. Specifically, we describe an ar- chitecture for adaptive network services allowing users and their devices to control their environment. The challenge in the design is developing an open service archi- tecture that allows heterogeneous client devices to discover what they can do in a new environment, and yet which makes minimal assumptions about standard interfaces and control protocols. The key elements of the architectore we have developed include: 1) augmented mobility beacons providing location information and security features, 2) an interface definition language allowing ex- ported object interfaces to be mapped to client device control inter- faces, and 3) client interfaces that maintain a layer of indirection, allowing elements to be remapped as server locations change and object interactions to be composed into complex behaviors. Additionally, we have designed, implemented, and deployed in our Computer Science building the following example services: untethered interaction with lights, video and slide projectors, a VCR, an audio receiver, and an AN routing switcher from a wirelessly connected laptop computer; automatic “on-the-move” reconfiguration for use of local DNS, NTP, and SMTP servers; HTTP proxies; and RTP and multicast-to-unicast gateways; audited local printer access; interactive floor maps with a standardized interface for adver- tising object locations; tracking of users and other mobile objects with privacy control. The testbed for our experiments [18] includes Intel-based lap- top computers with access to a multi-tier overlay network including room-sized infrared cells (IBM IR), floor-sized wireless LAN cells (AT&T WaveLAN), and a wide-area RF packet radio network (Met- ricom Richocet). We also leverage facilities in a seminar room aug- mented with devices that can be accessed and controlled through a workstation. The physical components of the testbed are illustrated iii Figure 1. Our infrastructure builds on the substantial work in mobility sup- port provided by the networking research community. The Mobile- IP working group of the IETF [24] has made great strides in the routing aspects of the problem. Overlay networking [3 l] has demon- strated the feasibility of seamless handoff between Internet service providers and interfaces. The developing Service Location Protocol
`
`environment is characterized by a number of challenges, each illustrating the need for adaptation: continuously available but varying network connectivity, with high handoff rates exacerbated by the demands of spectrum reuse; vari- ability in end clients, making it necessary to push computation into the local infrastructure; and variability in available services as the environment changes around the client. Permission to make digit.Sbard copies of all or part oftbis material for penonal or classroom use is -ted without fee provided that the copies are not made or dkkibukd for profit or commercial advantage, the copy- right notice, the title oftbe publication and its date appear, and no& is
`
`ubiquitous computing
`
`given
`that copyright is by permission of the AChI, Inc. To copy otbenvise, to rcpoblkb, to post
`on
`servers or to redistribute to Ii&, requires specific permission andlor fee
`MOBICOA4 97 Budapest Hungary
`
`APPL-1016 / Page 1 of 12
`Apple v. Uniloc
`
`

`

`
`
`Switcher Switcher
`
`
`
`Receiver Receiver
`
`
`
`VCR VCR
`
`
`
`AN AN
`
`
`
`routiig routiig
`
`I I .L- .L-
`
`3 3
`z z
`b b
`
`5 5
`
`I I
`
`Base
`
`y 0 Station */
`
`Lights
`
`d
`
`Client
`Device
`
`Figure 1: Project operating environment [34] addresses resource discovery and management. Such efforts have been instrumental in motivating this work. The rest of this paper is structured as follows. In Section 2, we discuss the key problem characteristics and provide a framework for a service provision architecture’s core functionality. This is moti- vated by a scenario with a set of high-level functional requirements to be achieved. In Section 3, we detail our architecture’s prototype implementation and the protocols that allow mobile clients to
`
`access
`
`the infrastructure. In Section 4, we describe the suite of example ad-hoc mobile services incorporated into it. In Section 5, we unify the design and implementation with some discussion of interrela- tionships, dependencies, and a layered view of the components. In Section 6, we discuss the relevant related work. In Section 7, we summarize future and continuing work, and finally in Section 8, we present our concIusions.. 2 Designing a Service Interaction Ar- chitecture We motivate our architecture for mobile services with the following scenario: You are on your way to give an invited lecture. After parking on campus, you take out your PDA with wireless connectivity, checking the list of local services available to you. You click on the map icon, and are presented with a campus-widemap that includes a rough indication of where you are. You select “Computer Sci- ence Division” from a list, and a building near you b highlighted. You walk toward it. As you enter the building, you glance down at your client device and the list of available services changes. Addi- tionally, the campus map is replaced with the building floolplan. Using the new map, you find and enter the lecture hall, In preparation for your talk, you select “audio/visual equipment” and “lights” from the list of services, caus- ing a user interface for each to appear. Your selections also cause the rooms’ equipment to be located on the floorplan. You walk to the VCR and insert a tape. The lecture begins. As you finish the introduction, you dim the lights and start the VCR with taps on yourPDA. At that moment, you realize you’ve forgotten your lecture notes. Using your personalized printer user interface, you retrieve a file from your home machine and instruct the closestprinter to print the file. The printer’s location appears on the floorplan. A minute later, you are notified the print job has com- pleted, retrieve your printout, and reNm to finish the lecture as the videotape completes. From this scenario, we can derive a set of required or desirable functions, presented in the next subsection. 2.1 Requirements Analysis The problem is that users wish to invoke services - such as con- trolling the lights, printing locally, or reconfiguring the location of DNS servers - from their mobile devices. But it is difficult to obtain wide-spread agreement on “standard” interfaces and mcth- ods for such service invocation. The challenge is to develop an open service architecture that allows heterogeneous client devices To discover what they can do in a new environment, making minimal assumptions about standard interfaces and control protocols, Implementing such a service architecture makes it posdble to Nm client devices into “universal intemctors!’ An
`
`is, broadly, a device that allows a user to interact with and modify his or her environment. Examples include electronic cquipmcnt remote controls and thermostats. A
`
`universal
`
`inferacror
`
`APPL-1016 / Page 2 of 12
`
`M M
`inleruclor is a device
`

`

`. -- ‘. jr 3;, -__.- that adapts itself to control many devices - if it can discover their control interface. A universal interactor thus exploits what it finds in the environment, and varies its abilities as a function of location. It is not a particular hardware component, but instead a way of using an existing device. Realizing such a capability requires (at least) five technical com- ponents: 1) device mobility, 2) network-accessiblecontrollable ob- jects, 3) an underlying discovery architecture, 4) mapping between exported object interfaces and client device control interfaces, and 5) composing complex behaviors from underlying primitive objects. These are now described in detail in the following subsections. 2.2 Device Mobility A critical component of the scenario is device mobility. The client moves from a wide-area network to a local-area network, and be- tween points in the local-area. This functionality is available through Mobile-IP [24] and net- work overlays [ 173. The former supplies IP-level transparency to changes in location, and the latter augments this functionality with a policy layer for managing connectivity to multiple available network interfaces and a mechanism for seamless (low-latency) hand-off. We build upon this network-layer functionality directly. On top of this, we only require the ability to detect changes in connectivity with an event-delivery mechanism. Such a mechanism is required to implement automatic reconfiguration: when the client device discovers it has moved, it should check (or be notified) if a local instantiation of a remote service is available, and should auto- configure to use the local service in this case. Concrete examples include DNS, NTP, and SMTl? 2.3 Controllable Objects Most objects can be controlled. Doors and windows open; lights turn on; coffee-makers brew. Most physical objects provide only manual controls. A controllable object, on the other hand, is one that exposes the interface to which it responds to control requests or transmits status information. Additionally, it makes this interface accessible over a network. To fit into our architecture, it is crucial that objects be augmented with an ability for network-based control, Open issues include ad- dressability, naming, and aggregation of objects into a controllable unit. Individual controllable objects may be too numerous or the expense of individual control may be too high. For example, while it is possible to make every lightbulb its own controllable object, the sheernumber of them in a typical building, the expense of assigning processing to each one, the difficulty of wiring each to the network, etc., would mitigate such a decision. Instead, control functionality could be assigned to a bank of lights, and what is augmented is the switch bank rather than all of the individual lightbulbs. In gen- eral, this means that the current infrastructure for naming - DNS - must be extended to include objects that do not have (or need) IP addresses. An alternative is to develop a separate infrastructure to match this need rather than overloading DNS. In the latter case, we can take advantage of the fact that instantiations of these name servers need only have a local, rather than global, scope. Another approach for interacting with objects is to use video cap- ture augmented with image processing (“computer vision”) where applicable. Example uses of this approach include fine-grain object tracking, directionality sensing, and event triggers keyed to partic- ular circumstances [22]. E.g., a camera can be used to detectthe opening of a door or window. In this case, it is the camera that exports the control interface. 2.4 Resource Discovery The function of a resource discovery protocol is to maintain dynamic repositories of service information and make this information avail- able through scoped attribute queries. In contrast with DNS, the repositories’ information is specifically local in nature. We couch our discussion of resource discovery in the context of the Service Location Protocol [34], under development by the IETF Service Location working group. Although there are open issues in this domain, we avoid duplicating much of the relevant discussion here. Interested readers are pointed to the Internet draft and the Service Location working group mailing list. From our local-area network perspective, the only mechanism we require is a function to allow mobiles to query the server for a mapping from strings to strings. We describe our own mechanisms for finding the correct local server and initializing the string map- 1 pings. Finding the a correct local server is similar to delivering the correct SCOPE attribute to the mobile host in SLP 1 2.5 lkansduction Protocols A transduction protocol maps a discovered object interface to one thatis expected by a given client device. It supports interoperabiity I . by adapting the client device’s interface to match the controllable I object’s interface. The issue with transduction protocols is how to map control functions into a UI supported by the portable device. As an example, assumea client device has a two-position switch widget for use with the local light controller. At a visited location, the light controller supports continuous dimming. In this case, the client may substitute a slider widget for the switch. Ifit cannotdo this (or choosesnot to), then the purpose of the transduction protocol is to map the on/off settings of the UI to one of the two extremes of the actual dimmer control. Our solution is to transfer an entire GUI to the client in a lan- guage it understands, and when possible, augment the GUI with an interface description that starts with base data types and allows them to be extended hierarchically. A transducer that doesn’t understand a level in the hierarchy can use elements below it. Alternatively, the interface description can be used directly to generate a rough GUI when no language implementation appropriate for the client is available. The interface descriptions not only allow for data type transduc- ers between client and server; they also provide a critical layer of indirection exactly where it is needed: underneath the user inter- face, allowing widgets to be transparently remapped to new servers in a new environment. This function is required to allow custom user interfaces for ad-hoc services, such as allowing a virtual “light switch” on the client device’s control panel to always control the closest set of lights. 2.6 Complex Behaviors Objects have individualized behaviors. We wish to couple and com- pose these individual behaviors to obtain more complex behaviors within the environment. For example, consider a scenario where .
`
`APPL-1016 / Page 3 of 12
`
`

`

`Service
`
`~0.1
`
`Our solution is to use interface discovery, (i.e. any method through which new objects’ input/output data types are learned) paired with the aforementioned data type transducers to allow ob- jects to be cascaded much like UNM pipes to achieve the desired complex behaviors. Additionally, we allow intermediate entities (“proxies”) to maintain state that is independent of the constituent subcomponents. This allows for the incorporation of such features as conditional statements and timing information. 11 register callback 11 dlsconnectad UCB Service Index Client
`
`/_ __ _ music follows you as you move around a building. One behavior of the sound system is to route music to specific speakers. A behavior of location tracking services is to identify where specific objects are located, such as the user. A “complex” behavior allows us to com- pose these more primitive behaviors of sound routing and location tracking to obtain the desired effect of ‘following” music. of base stations in geographic proximity could be associated with a single SII? Beaconing daemons (beacond) run at each base station. An example SIC screenshot is shown in Figure 2. SIP and beacond use configuration files and command-line switches, and thus user interfaces are not shown. A key problem is that there is no common control interface for individual components. Furthermore, some behaviors may require maintenance of state that is independent of both subcomponents. An example of the latter is instructing the coffee maker to brew only the first time each morning that the office door opens. Another issue is the policy-level difficulty implied by this scenario: resolution of incompatible behaviors. If another user considers music to be noise, the visiting user’s music may or may not be turned off in their pres- ence, depending on seniority, social convention, explicit heuristics, or otherwise. At a minimum, the system must guarantee that it will detect such incompatibilities and notify the user(s) involved in order to avoid instability (e.g., music pulsing on and off as each individual behavior is interpreted).
`In ourprototype,complex behaviors are written as scripts invoked by the delivery of particular events. These events are generated (when necessary) by the datatypetransducers that translate between the client user interface invocations and the RFC! commands sent to a service daemon.’ Figure 2: Tire SIC application GUI is currently a series of buttons that can be used to retrieve and invoke application interfaces. 3 Implementing Service Interaction This section describes implementation details of the serviceintemc- tion proxy (SIP), the service interaction client (SIC), and beaconing daemon (beacond) programs. These prototypes implement selected components of our overall mobile services architecture. The prototypes allows a mobile host to enter a cell, bootstrap the local resource discovery server location, and acquire and display a list of available services. They also allows users to maintain a database of scripts to be executed when particular services are discovered for use in autoconfiguration, local state updates, and to trigger location-dependent actions. Each SIP process maintains a database of the services and scr~icc elements that it provides to mobile hosts. An example startup file for such a database is listed in Figure 3. It contains three types of entries: SERVICES, VALUES, and PROPERTIES. VALUeS are used for generic (key, value) lookups. Theseareuseful for, e.g., detecting the need to update server addresses. SERVICES and PROPERTIES are used to specify what, where, and how services are available from that partlcularlocation. EachSWJICE has auniquenamc, and mninlnins
`such as the version number, a pointer to an associated IDL file’, pointers to particular language implementations of User interfaces for the service, and the geographic location (if any) for use with maps. VALUES andPROPERTIEs mayjust be pointers to another SIP, allowing simple incremental deployment to subdomains and yielding a notion of topology. If a user wishes
`a service it does not understand, the client first automatically searches its local cache for an interface to that service; if it is not there, the infrastructure is automatically notified and it attempts to send an interface description and GUI to the client. 3.2 Message-level Detail 3.1 Setup A single copy of the “service interaction client” (SIC) prcgrarn runs at each client device. Copies of the “serverinteraction proxy” (SIP) program run at domain-specific
`For example, a set The client enters a cell with a beaconing daemon. Thedaemon sends periodic broadcasts that contain the bootstrap address and port num- berof that cell’s SE? The client automatically registers with the base station to establish IF’ connectivity. It then requests the well-known me&service INDEX, which returns a list of the services availnblc. Based on the contents of the reply, the client renders labellcd UI buttons for unknown services, remaps the location of running ser- vices, and executes scripts in a database to enable autoconncclion ‘Thus,eveninthecasewherenohanslationisnecess~,anulltransducer *Use of the Interface Definition Language (IDL), a generic format for must be interposed in orderto allow detection of invocations. In otberwords. service interfaces similar in concept to a model-based UI, is described In the transduction layer is t.be layer that provides the indirection. Section 3.6 . 4
`
`PROPERTIES
`
`to use
`
`granularities.
`
`APPL-1016 / Page 4 of 12
`
`

`

`Soda 405: High-Tech Seminar Room 1 set sERvIcRs ( INDM lights (A/V equipment) map printer (location tracking) I set VALUES c DNS (128.32.33.24 128.32.33.25) NTP (orodruin.cs.berkeley.edu harad-dur.cs.berkeley.edu) SMTP [mailspool.cs.berkeley.edu) 1 set PROPERTIES C lights iIDLfile ../helpers/lights.idl version 0.01 \ location (132 210) appName-tk ../helpers/lights.tk \ appArchive-tk ../helpers/405/lights405.tar.uue appName-tcl ../helpers/lights.tcl \ appfuchive-tcl ../helpers/405/lights4OStcl.tar.uue) (A/V equipment) (IDLfile ../helpers/htsr.idl location (132 180) \ version 0.01 appName-tk htsr.tcl \ appArchive-tk '../helpers/405/HTSR.tar.uue'1 . . . Figure 3: An abridged SIP services database example and composed actions3 When a user requests a particular service, the client software checks its local cache of applications. If an interface supporting the requested application is not there, it asks the SIP for the service’s “properties.” This is a list of available interface descriptions and/or implementations. It also receives any service metadata (such as version numbers). It then chooses either to download a particular interface implementation (e.g., as a Java applet) or the generic interface description. The SIC then unpacks the received archives, transduces the interface description to match the device characteristics, and finally executes the GUI. An example exchange of protocol messages for a client moving between SIP servers is illustrated in Figure 4. 3.3 Bootstrap For a client to use services, it must first find the address of the local resource discovery server. In our architecture, this bootstrap above IP is minimal: there is an indirection embedded in the mobility beacons. This minimal bootstrap standardizes the interface for sending service advertisements without constraining the item to which it points. In general, it could point to any type of name server, thereby allowing variation in resource discovery protocols if this were desired. 3.4 Beaconing Beaconing is required in a system to facilitate notification of mobility-based changes in the relative position of system compo- nents. Its use is motivated by inherent availability of physical-level hardware broadcast in many cellular wireless networks and the need to track mobiles to provide connectivity. 3Tbedatabbasecurrentlyresidesontbeclient, butcouldadditionallybe retrieved fmmelsewherebyaproxyserverto addressclientcomputational limitations. ‘Rvo issues arise once the decision to beacon has been made. The first is which direction to send them: uplink or downlink. The second is what information to put on the beacons, if any at all. (An empty beacon acts as a simple notification of the base station address, available in the packet header.) These are discussed in the following subsections. 3.4.1 Beaconing Direction In terms of choosing whether to have client devices or infrastructure servers beacon, existing systems can be found which have made either choice. Client beaconing is used in both the Active Badge [I31 and PARCTAB systems [26], while server beaconing was used in Columbia Mobile IP [14]. lETF Mobile IP utilizes both periodic advertisements
`
`periodic solicitations. One might expect the application-level framing [9] argument to hold here: different policies optimize for different applications’ operating modes. This is indeed the case: there are trade-offs in such a decision, as it varies allowances for privacy, anonymity, particular protocols’ performance, and scalability. Specifically, some benefits of base station beaconing include:
`
`l
`anonymity of location is preserved for non-transmitting mo- biles;
`
`l
`
`allows possibility of “anonymous”access to some data known to the infrastructure (at a cost of management overhead and increased beacon size due to the piggybacking); 5
`
`and
`
`l
`
`less power is consumed at the mobile by periodically listening than by periodically transmitting;
`
`l
`
`finding a base station requires only a single message rather than a broadcast/responsepaic
`
`l
`
`l
`
`APPL-1016 / Page 5 of 12
`
`mobiles need not transmit to detect when contact is lost;
`detection of multiple beacons can be used to assist handoff;
`

`

`l
`
`Mobile IP foreign agent advertisements: 0 pricing information;
`
`l
`
`l
`
`l
`
`(header) 4B 2B 4B (variable length) SIPIPaddr port nonce application-specific payload . . . . Figure 5: The service beacon encoding includes bits for the service interaction bootstrap and location queries. Not shown are Mobile-IP FA router advertisements or other potential application-specific piggybacked fields. SIP #1 SIC (client) SIP #2 Figure 4: Protocol message timings for a client moving be- tween SIP servers (dashed Iines are beacons): (a) INDEX #I request/reply (b) request/reply for “lights” IDL file and inter- face (c) INDEX ##2 request/reply (d) “lights dim” button press retrieves new IDL file to remap RPC, then completes a maintains a consistent mapping behveen geography and bea- con broadcast cell; o impIies Iess beacon trati?c per cell given the naturaI many-to- one mapping of mobile hosts to base station cells, assuming other parameters remain constant. The benefits of havingtbemobile host beacon are complementary to the above and can be inferred from tbe list. Our system uses base station beaconing. We believe this is the correct design choice for three key reasons: the support for user (rather than infrastructure) anonymity, better scalability in a low- bandwidth network where there are many MHs per BS, and because power is more precious on mobile devices. This choice aligns our design with other soft-state announccflisten protocols, such as the MBone session announcement protocol. 3.4.2 Beacon Augmentation The second question is whether to augment mobility beacons with additional data. Doing so makes data available to mobiles before registration (in the Mobile IP sense). Possible uses for such piggy- backed beacon data include:
`
`merging of periodic broadcasts to better amortize header and MAC overhead. The utiIity of beacon payload augmentation is highly dependent on the direction of the beaconing, traffic patterns, and application mix. The argument against beacon augmentation it that orthogonal systems shouldn’t mix application data units that may have been “properly” sized by the application in a form ofjoint source-channel coding [23]. We choose to augment our beacons with bootstrap information, a nonce for scoping of services, and a dynamically configurable application-specific payload. The encoding is shown in figure 5, The nonce is discussed in Section 3.5; a usage of the application- specific payload is discussed in Section 4.3. Merging Mobile IP router advertisements and the resource dls- covery protocol bootstrap may be abenefit,but allowing application- specific or other network-level fields is an area of active debate. WC are still trying to quantitativeIy determine which data, if any, is best dedicated to these bits for optimizing reasonable client-driven workloads. 3.5 Security Making services available to visitors brings up a host of gcncral security issues, including those specific to the wireless domain 17, 11, 41. In addition to standard cryptography-based securlly with passwords,capabilities (e.g., Kerberos), and public-key encryption, service interaction systems specifically require additional
`
`ncccw
`
`control. This is due to our extension of devices to make them network-addressable entities. In general, global access control is necessary,but not enough; the expectedbehavior that environmental changes can only be affected by people in that environment (c.g,, lights cannot be turned off by a person across the country) has been broken. Maintaining this norm is important when extending existing hu- man social metaphors into an environmentwith controllable objects. 6
`
`APPL-1016 / Page 6 of 12
`
`advertisements ;
`time-variant data (e.g., NTP beacons);
`

`

`- We address this by embeddingrwnces, random fixed-length bit vec- tors, in the mobility beacons and requiring the current nonce to be included in all communications to servers. Periodically changing the nonces in an unpredictable way and scoping the broadcast (implicitly via the cellular wireless network broadcast cell or explicitly with the multicast IP ‘ITL field) prevents remote access from nodes even on the access control list that aren’t local or haven’t been separately multicasmmicast the nonce value. This pairs the geographic scoping of the environmental controls (what we cannot control) to the topological scope (what we can control). This nonce-based exclusion can be overridden, but by making the default access restricted, we better emulate the existing paradigm. As for mobile code security, by transferring only a GUI to the client, it is probable that a sandboxed environment (such as Java, Safe-Tel, or Janus [ 121) can be used without constraining the ser- vice’s functionality. 3.6 Client Interfaces Clients can becomputationally impoverished, have variations in dis- play(colordepth,resolution,screensize),supportdifferentinterface paradigms (keyboard, pen, touch), and are often interchangeable with one another (and therefore not preconfigured). Due to the need to support such end devices, especially extremely resource-poor PDAs, thin client interfaces must be available. They also must allow for different realizations on different hardware. As part of our realization of automatic data type transduction, we have developed an initial, minimal grammar for such interfaces, which
`passes along the original RPC. Our current implementation has interfaces manually imple- mented in TcVlk and an ad-hoc IDL specification tuned to Tk. 3.7 Prefetching As an optimization, clients can prefetch the IDL files for active services. We illustrate with a concrete example from our prototype. As the user moves between rooms,thelight controller application UI remains the same. When the user changes the lighting in a new cell, 7 the client application sends the new SIP a request for the lights IDL file, enabling the RPC command invoked by the existing interface to be remapping so that the recipient will be the new server. This late-binding is used to conserve bandwidth on the wireless link; the total number of IDL files may be large and the client may use one only infrequently. The problem with late-binding is that this entire operation latency seenbytheenduser;,andinpracticeitcanbeperceivedasapossible error condition. (The button “doesn’t work” for a number of seconds after it is invoked,andfor this periodit should probably bebegrayed out in the UL) This delay can be minimized by transparently remapping the interface elements to the new server as soon as possible. To do so, we add one bit of per-service state, “active vs. inactive.” This flag is set to “active” whenever there is an RPC call from that service, and reset to “inactive” by a timeout. Upon receipt of any beacons with a new SIP, services with the “active” bit set (and available in the new location) have their new IDL files prefetched automatically. (In our current im