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 paperintroduces the notion of “universal interaction,” allowing
`a deviceto adaptits functionality to exploit services it discovers as
`it moves into a new environment.
`Users wish to invoke services — such as controllingthelights,
`printing locally, or reconfiguring the location of DNS servers —
`from their mobile devices. But apriori standardization ofinterfaces
`and methodsfor 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 objectinter-
`faces andclient device controls, and 5) building complex behaviors
`from underlying composable objects.
`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
`
`This paperinvestigates novel uses ofa ubiquitous network, focus-
`ing on variable network servicesin the face of changing connectivity
`and heterogeneous devices. We proposethat providing an “IP dial-
`tone” isn’t enough; we must add additional service infrastructure
`to augmentbasic 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 heterogeneousclient devices to discover what
`they can do in a new environment, and yet which makes minimal
`assumptions aboutstandard interfaces and control protocols.
`The key elements ofthe architecture 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 mappedto client device controlinter-
`faces, and 3) client interfaces that maintain a layer of indirection,
`allowing elements to be remappedas 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 andslide projectors,
`a VCR,an audio receiver, and an A/V routing switcher from
`a wirelessly connected laptop computer;
`
`
`
`
`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 [37].
`
`
`This ubiquitous computing environment is characterized by a
`numberof challenges, each illustrating the need for adaptation:
`continuously available but varying network connectivity, with high
`handoff rates exacerbated by the demandsof 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 aroundtheclient.
`
`
`
`Permission to make digital/hard copies ofall or part ofthis material for
`personalor classroom use is granted withoutfee provided that the copies
`are not made ordistributed for profit or commercial advantage, the copy-
`right notice, thetitle ofthe publication andits date appear, and notice is
`
`given that copyright is by permission ofthe ACM,Inc. To copyotherwise,
`
`
`to republish, to post on servers orto redistribute to lists, requires specific
`
`permission and/or fee
`
`
`
`
`MOBICOM 97 Budapest Hungary
`Copyright 1997 ACM 0-89791-988-2/97/9..$3.50
`
`¢ 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 mapswith a standardized interface for adver-
`tising object locations;
`
`@ tracking ofusers 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 (BM IR), floor-sized wireless LAN cells
`(AT&T WaveLAN), and a wide-area RF packetradio 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 ofthetestbedareillustrated
`in Figure 1.
`Ourinfrastructure 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 ofthe problem. Overlay networking [31] has demon-
`strated the feasibility of seamless handoff between Internet service
`providers and interfaces. The developing Service Location Protocol
`
`LGE Exhibit-1016/Page 1 of 12
`LGEv. Uniloc
`
`LGE Exhibit-1016/Page 1 of 12
`LGE v. Uniloc
`
`

`

`
`
`@ i
`
`NM
`Slide and Video
`Projectors
`
`
`
`aN
`>
`i
`
`Client a
`
`
`
`Device
`
`
`
`Figure {: Project operating environment
`
`Using the new map,you find andenterthelecture hall.
`[34] addresses resource discovery and management. Such efforts
`In preparation for your talk, you select “audio/visual
`have beeninstrumental in motivating this work.
`equipment” and “lights” from thelist of services, caus-
`Therest of this paperis structured as follows. In Section 2, we
`ing a user interface for each to appear. Your selections
`discuss the key problem characteristics and provide a framework for
`also cause the rooms’ equipmentto be located on the
`a service provision architecture’s core functionality. This is moti-
`floorplan. You walk to the VCR andinsert a tape.
`vated by a scenario withaset of high-level functional requirements
`to be achieved. In Section 3, we detail our architecture’s prototype
`The lecture begins. As you finish the introduction, you
`
`implementation and the protocols that allow mobile clients to access
`dim the lights and start the VCR with taps on yourPDA.
`the infrastructure. In Section 4, we describe the suite of example
`Atthat moment, yourealize you’ve forgotten yourlecture
`ad-hoc mobile services incorporated into it. In Section 5, we unify
`notes. Using your personalized printer user interface,
`the design and implementation with some discussion of interrela-
`you retrieve a file from your home machineandinstruct
`tionships, dependencies,and a layered view of the components. In
`the closest printerto printthefile. Theprinter's location
`Section 6, we discuss the relevant related work. In Section 7, we
`appears on the floorplan.
`summarize future and continuing work, and finally in Section 8, we
`A minute later, you are notified the print job has com-
`present our conclusions..
`pleted, retrieve your printout, and return to finish the
`lecture as the videotape completes.
`
`
`
`2 Designing a Service Interaction Ar-
`chitecture
`
`From this scenario, we can derive a set of required or desirable
`functions, presentedin the next subsection.
`
`We motivate ourarchitecture for mobile services with the following
`scenario:
`
`2.1 Requirements Analysis
`
`You are on your wayto 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-wide mapthat includes a rough
`indication of where you are. You select “ComputerSci-
`ence Division” from a list, and a building near you is
`highlighted. You walk toward it.
`Asyou enterthe building, you glance downat yourclient
`device andthe list of available services changes. Addi-
`tionally, the campus mapis replaced with the building
`floorplan.
`
`The problem is that users wish to invoke services — such as con-
`trolling the lights, printing locally, or reconfiguring the location of
`DNSservers — from their mobile devices, Butit is difficult to
`obtain wide-spread agreement on “standard” interfaces and meth-
`ods for such service invocation. The challenge is to develop an
`openservice architecture that allows heterogeneousclient devices
`‘fo discover what they can do in a new environment, making minimal
`assumptions aboutstandardinterfaces and control protocols.
`Implementing such a service architecture makesit possible to
`
`turn client devices into “universal interactors.” An interactor is,
`broadly, a device that allows a user to interact with and modify
`his or her environment. Examples include electronic equipment
`
`remote controls and thermostats, A universal interactor is a device
`
`
`
`~‘LGEExhibit-1016/Page 2 of12
`
`
`
`
`
`Base
`Service
`AN Server
`
`
`
`
`
`Station
`eai’|
`Interaction
`Computer
`
`
`3 oT
`Proxy
`ae
`pw
`
`
`
`Control
`
`
`|
`Switcher
`
`
`aoal=
`
`
`
`
`
`AN routing
`
`
`
`
`vee
`
`i
`
`{
`
`
`
`t
`
`:
`
`
`
`
`
`
`
`
`
`
`
`g 8
`
`
`
`
`
`
`
`
`LGE Exhibit-1016/Page 2 of 12
`
`
`
`

`

`
`
`A transduction protocol maps a discovered object interface to one
`that is expected bya givenclient device.It supports interoperability
`by adaptingthe client device’s interface to match the controllable
`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 widgetfor use with
`the local light controller. At a visited location, the light controller
`supports continuous dimming. In this case,the client may substitute
`aslider widgetfor the switch. If it cannotdo this (or choosesnotto),
`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.
`Oursolution is to transfer an entire GUI to the client in a Jan-
`guageit understands, and when possible, augmentthe 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 whenno language implementation appropriateforthe clientis
`available.
`
`that adapts itself to control many devices — if it can discover their
`control interface. A universal interactor thus exploits whatit finds
`in the environment, andvariesits abilities as a function of location.
`It is not a particular hardware component, butinstead a wayof using
`an existing device.
`Realizing such a capability requires(at least) five technical com-
`ponents: 1) device mobility, 2) network-accessible controllable 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 [17]. The former supplies IP-level transparency to
`changesin 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.
`Ontop ofthis, 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 serviceis available, and should auto-
`configure to use the local service in this case. Concrete examples
`include DNS, NTP, and SMTP.
`
`2.3 Controllable Objects
`
`Most objects can be controlied. Doors and windows open; lights
`tum 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 whichit responds to control requests or
`transmits status information. Additionally, it makes this interface
`accessible over a network.
`
`Tofit 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 numerousor the
`expense of individual control may be too high, For example, while
`it is possible to make every lightbulb its own controllable object, the
`sheer numberofthem in a typical building, the expenseofassigning
`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 oflights, and what is augmented is
`the switch bank rather than all of the individual lightbulbs. In gen-
`eral, this means that the currentinfrastructure for naming - DNS
`— must be extended to include objects that do not have (or need)
`TP addresses. Analternative is to develop a separate infrastructure
`to matchthis need rather than overloading DNS.In the latter case,
`we can take advantageofthe fact that instantiations of these name
`servers need only havea local, rather than global, scope.
`Another approachforinteracting with objects is to use video cap-
`ture augmented with image processing (“computer vision”) where
`applicable. Example usesofthis approach include fine-grain object
`tracking, directionality sensing, and eventtriggers 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 ofa resource discovery protocolis to maintain dynamic
`repositories of service information and makethis information avail-
`able through scoped attribute queries.
`In contrast with DNS, the
`repositories’ informationis specifically local in nature.
`‘We couch ourdiscussion 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 ofthe relevantdiscussion
`here.
`Interested readers are pointed to the Internet draft and the
`Service Location working group mailinglist.
`From our local-area network perspective, the only mechanism
`we require is a function to allow mobiles to query the serverfor a
`mapping from strings to strings. We describe our own mechanisms
`for finding the correct local server and initializing the string map-
`pings. Finding the a correct local server is similar to delivering the
`correct SCOPEattribute to the mobile host in SLP.
`
`2.5 Transduction Protocols
`
`Theinterface descriptions not only allow for data type transduc-
`ers betweenclient and server; they also provide a critical layer of
`indirection exactly whereit is needed: undemeath the userinter-
`face, allowing widgets to be transparently remapped to new servers
`in a new environment. This function is required to allow custom
`userinterfaces for ad-hoc services, such as allowing a virtual “light
`switch” on the client device’s control panel to always control the
`closest set oflights.
`
`2.6 Complex Behaviors
`
`Objects have individualized behaviors. We wish to couple and com-
`posethese individual behaviors to obtain more complex behaviors
`within the environment. For example, consider a scenario where
`
`LGE Exhibit-1016/Page 3 of 12
`
`LGE Exhibit-1016/Page 3 of 12
`
`

`

`
`
`
`
`its
`
`
`
`
`
`
`3
`
`Implementing Service Interaction
`
`This section describes implementationdetails ofthe service interac-
`tion proxy (SIP), the service interaction client (SIC), and beaconing
`daemon (beacond) programs. These prototypes implementselected
`components ofour overall mobile services architecture.
`Theprototypesallows a mobile host to enter a cell, bootstrap the
`local resource discovery serverlocation, and acquire and display
`a list of available services. They also allows users to maintain
`a databaseof scripts to be executed when particular services are
`discovered for use in autoconfiguration, local state updates, and to
`trigger location-dependentactions.
`If a user wishesto use 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
`andit attempts to send an interface description andGUI to theclient.
`
`3.1 Setup
`
`A single copy ofthe “service interaction client” (SIC) program runs
`at eachclient device. Copies ofthe “serverinteraction proxy”(SIP)
`program run at domain-specific granularities. For example, a set
`
`
`1 Thus, even in the case where notranslationis necessary,a null transducer
`must beinterposedin ordertoallow detection ofinvocations. In other words,
`the transduction layer is the layer that provides the indirection.
`
`Each SIP process maintains a databaseofthe services and service
`elements that it provides to mobile hosts. An examplestartupfile
`for such a databaseis listed in Figure 3. It contains three types of
`entries: SERVICES, VALUES, and PROPERTIES. VALUES are used for
`generic(key, value) lookups. Theseareusefulfor, 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
`particular location. Each SERVICE has a unique name,and maintains
`PROPERTIES suchas the version number, a pointer to an associated
`
`DLfile’, pointers to particular language implementations of user
`interfaces for the service, and the geographiclocation(if any) for use
`with maps. VALUES and PROPERTIES mayjust be pointers to another
`SIP, allowing simple incremental deployment to subdomains and
`yielding a notion of topology.
`
`3.2 Message-level Detail
`Theclient enters a cell with abeaconing daemon. Thedaemonsends
`periodicbroadcasts that contain the bootstrap address and port num-
`berofthat cell’s SIP. The client automatically registers with the base
`station to establish IP connectivity. It then requests the well-known
`meta-service INDEX, which returnsa list of the services available,
`Based on the contents of the reply, the client renders labelled UI
`buttons for unknownservices, remapsthe location of runningser-
`vices, and executes scripts in a database to enable autoconnection
`
`2Use of the Interface Definition Language (IDL), a generic format for
`service interfaces similar in concept to a model-based UI, is described in
`Section 3.6
`
`1 i1
`
`Se
`Nae eeeRRERY IBITRREIET
`PONE Tg a ee ET Ree ste,
`
`~LGEExhibit-1016/Page 4 ofi2
`
`music follows you as you move around a building. One behaviorof
`the sound system is to route musicto specific speakers. A behavior
`oflocation tracking servicesis to identify where specific objects are
`located, such as the user. A “complex” behaviorallowsus to com-
`pose these more primitive behaviors of soundrouting and location
`tracking to obtain the desired effect of “following” music.
`A key problem is that there is no commoncontrol interface for
`individual components. Furthermore, some behaviors may require
`fel] Service index Cient Al (iE
`maintenance ofstate that is independent of both subcomponents.
`
`Service
`Status
`(ceaeeeee
`An exampleofthelatter is instructing the coffee makerto brew only
`up-to-'data
`
`INDEX
`|
`thefirst time each momingthatthe office door opens. Another issue
`is the policy-level difficulty implied by this scenario: resolution of
`retrieved
`
`
`
`lights
`incompatiblebehaviors. If anotheruserconsiders music to be noise,
`
`disconnected
`the visiting user’s music may or may not be turnedoffin their pres-
`ence, depending onseniority, social convention, explicit heuristics,
`
`retrlaved
`or otherwise. At a minimum,the system must guarantee thatit will
`disconnected
`
`detectsuch incompatibilities and notify the user(s) involved in order
`to avoid instability (e.g., music pulsing on andoffas each individual
`
`message board
`disconnected
`behavioris interpreted).
`printfila
`{
`retriaved
`
`
`any method
`Oursolution is to use interface discovery, (i.e.
`
`through which new objects’ input/output data types are learned)
`register callback, [ disconnected
`
`paired with the aforementioned data type transducers to allow ob-
`jects to be cascaded muchlike UNIX pipes to achieve the desired
`“UCB Service index lent vo
`complex behaviors. Additionally, we allow intermediate entities
`(“proxies”) to maintain state that is independentofthe constituent
`subcomponents. This allows for the incorporation of such features
`as conditional statements andtiming information.
`Inourprototype, complexbehaviors are written as scripts invoked
`by the delivery of particular events. These events are generated
`PLA
`(when necessary)bythe data typetransducers thattranslate between
`the client user interface invocations and the RPC commands sentto
`a service daemon.!
`
`ofbasestations in geographic proximity could be associated with a
`single SIP. Beaconing daemons(beacond)run at each basestation,
`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.
`
`
`AV equipment
`
`map
`focal Info
`
`
`
`
`
`
`
`
`
`
`Figure 2: The SIC application GUI is currently a series of
`buttons that can be used to retrieve and invoke application
`interfaces,
`
`LGE Exhibit-1016/Page 4 of 12
`
`

`

`set NAME (
`Soda 405: High-Tech Seminar Room
`
`}s
`
`}s
`
`et SERVICES {
`INDEX lights {A/V equipment) map printer {location tracking}
`
`et VALUES {
`DNS (128.32.33.24 128.32.33.25}
`NTP {orodruin.cs.berkeley.edu barad-dur.cs. berkeley. edu}
`SMTP {mailspool.cs.berkeley.edu}
`
`}s
`
`et PROPERTIES {
`lights {IDLfile ../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 \
`appArchive-tel
`../helpers/405/lights405tcl.tar.uue}
`{A/V equipment} {IDLfile ../helpers/htsr.idl location {132 180} \
`version 0.01 appName-tk htsr.tel \
`appArchive-tk "../helpers/405/HTSR. tar.uue"}
`
`
`
`Figure 3: An abridged SIP services database example
`
`
`
`and composed actions,? 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 forthe 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 chooseseither
`to download a particular interface implementation (e.g., as a Java
`applet) or the generic interface description. The SIC then unpacks
`the received archives, transducesthe interface description to match
`the device characteristics, and finally executes the GUI.
`An example exchangeof protocol messagesfor a client moving
`between SIP servers is illustrated in Figure 4.
`
`3.3 Bootstrap
`Fora client to use services, it mustfirst find the addressofthe 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 changesin the relative position of system compo-
`nents, Its use is motivated by inherent availability of physical-level
`hardware broadcastin many cellular wireless networksand the need
`to track mobiles to provide connectivity.
`
`3The database currently resides on theclient, but could additionally be
`retrieved from elsewhere by a proxy serverto address client computational
`limitations.
`
`Twoissues arise once the decision to beacon has been made.
`Thefirst 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 whetherto have client devicesor infrastructure
`servers beacon, existing systems can be found which have made
`either choice. Client beaconing is used in both the Active Badge
`[13] and PARCTAB systems[26], while server beaconing was used
`in Columbia Mobile IP [14]. IETF Mobile IP utilizes both periodic
`
`advertisements and periodic solicitations.
`One might expect the application-level framing [9] argumentto
`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 basestation beaconinginclude:
`
`
`
`¢ less poweris consumedatthe mobile by periodically listening
`than by periodically transmitting;
`
`e finding a base station requires only a single message rather
`than a broadcast/responsepair;
`
`¢ mobiles need not transmit to detect when contactis lost;
`
`e detection of multiple beaconscan be usedto assist handoff;
`
`e anonymity of location is preserved for non-transmitting mo-
`biles;
`
`@ 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);
`
`
`
`LGE Exhibit-1016/Page 5 of 12
`
`LGE Exhibit-1016/Page 5 of 12
`
`

`

`
`
`(header)
`
`(variable length)
`
`
`
`Figure 5: The service beacon encoding includesbits for the service interaction bootstrap and location queries. Not shown are
`Mobile-IP FA router advertisements or other potential application-specific piggybackedfields.
`
`
`
`
`
`SIP #1
`
`SIC (client)
`
`
`
`x7
`
`Indomain#1
`
`Indomain#2
`
`SIP #2 ew
`
`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 beacondata include:
`
`® Mobile IP foreign agent advertisements;
`
`® pricing information;
`® advertisements ;
`
`@ time-variant data (e.g., NTP beacons);
`
`® merging of periodic broadcasts to better amortize header and
`MACoverhead.
`
`Theutility of beacon payload augmentationis highly dependent
`on the direction of the beaconing,traffic pattems, and application
`mix. The argument against beacon augmentationit 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 shownin figure 5,
`Thenonceis 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 resourcedis-
`covery protocol bootstrap maybe abenefit,but allowing application-
`specific or other network-levelfields is an area of active debate. We
`are still trying to quantitatively determine which data, if any, is
`best dedicated to these bits for optimizing reasonable client-driven
`workloads.
`
`Figure 4: Protocol message timings for a client moving be-
`tween SIP servers (dashed lines are beacons): (a) INDEX #1
`request/reply (b) request/reply for “lights” IDL file and inter-
`face (c) INDEX #2 request/reply (d) “lights dim”button press
`retrieves new IDLfile to remap RPC,then completes
`
`
`
`@ maintains a consistent mapping between geography and bea-
`con broadcastcell;
`
`3.5 Securit