mpac 2004rae harbird 1 rubi adaptive resource discovery for ubiquitous computing

MPAC 2004 Rae Harbird 1

RUBI

Adaptive Resource Discovery for Ubiquitous Computing


RUBI• Why resource discovery?

• Review of existing protocols

• RUBI, design and evaluation

• Future work

• Conclusions and questions


Ubiquitous Computing • Weiser’s vision becoming reality

– 250 million microprocessors sold monthly, < 2 % destined for PCs

• Ubicomp revenue

– Provision of novel services, low / no ROI from connectivity alone

• Resource discovery and management

– Vital component in the realisation of the ubicomp vision

– Key enabler for revenue stream


• Huge heterogeneity

– Device capabilities and characteristics

• Immense scale

• Dynamic operation and volatility

– Number, types and attributes of services will change fast

• Result: administrative complexity

– Must be hidden from users

Environmental ImplicationsEnvironmental Implications


• Distributed and highly scalable

– Information available at many points in the network

• Accommodate heterogeneity

– Participants

– Network topologies

• Autonomic

– Function despite the frequent failure of resources, devices and the links between them

Resource Discovery Requirements


Previous Work • Global, central index of resources

– Jini

• Global, distributed index

– Distributed Hash Tables

• Resources discovered as needed

– Konark, UPnP, SLP


• Resource Discovery for Ubiquitous Computing

• Overarching adaptive process

– Controlling the way that information is disseminated and retrieved

• Based on local view of the network

• Founded on routing algorithms

– Exchange of routing information more generally applied to the exchange of service details

RUBI


• Chosen ad hoc routing algorithms for RUBI

• Low, relative mobility: low rate of change

– Proactive routing algorithm (OLSR)

• High, relative mobility: high rate of change

– Reactive routing algorithm (AODV)

• Regions with these characteristics will coexist

– Resource discovery must adapt

Adaption


Protocol Messages• Resource advertisement (proactive)

• Resource cancellation (proactive)

• Resource requests (proactive and reactive)

• Resource request replies (proactive and reactive)


• Resource information distributed periodically

– Period length dependent upon whether a node detects change in its locality

• Uses optimised flooding

– Reducing costs as compared with classic flooding

• Subset of neighbours elected as relays

– Used to propagate resource information through the network

Proactive Resource Advertisement


Proactive Resource Advertisement (1)


Proactive Algorithm• Resource requests

– Can be generated by nodes which are not relays

– Used by relays where the resource search should traverse a proactive region

• Resource request replies

– Sent by relays to neighbouring nodes

• Resource cancellation

– Next advertisement will not contain information about the cancelled resource


Reactive Resource Requests & Replies• All nodes responsible for maintaining their own cache

• Resource information preserved for recently queried resources only

– Deleted from cache if not used after a specified time interval

• Requests are flooded through the network

• Scope is controlled by Time To Live (TTL)

– Uses Expanding Ring Search (ERS) if no resource found

– Overhead of finding a resource is reduced if there is a resource nearby

• Replies are unicast back to the sender


Algorithm Selection• How does a node determine the type of region it belongs to?

– Assesses this using locally available information.

• Select routing algorithm based on perceived stability

• Link duration is used as a mobility feedback mechanism

– Gleaned from neighbour establishment (NE) process


Neighbour Establishment• RUBI nodes broadcast HELLO beacons periodically

• HELLO message contains:

– List of that node’s direct neighbours

– Flag indicating whether neighbour has been selected as a relay

– Willingness value (between 0-7)

• Receiver uses HELLO information to build up a picture of local topology


Relay Selection Rules• Simple heuristic

1. Neighbours advertising maximum willingness

2. Neighbour nodes that are the only nodes through which a 2-neighbour can be reached

3. Neighbours through which the remaining 2-hop neighbour set can be reached

• If there is more than one neighbour that fulfils this role, the one with the greatest number of links is chosen


Neighbour Establishment


Protocol Coexistence• There will be regions where the proactive and reactive areas

border each other

• We must ensure consistent resource discovery behaviour


Proactive Request Reaches Reactive Region

• Node b sends resource request to its relay A

• Node p will also hear request

• Node p will deal with the request according to the reactive protocol rules


Proactive Reply Reaches Reactive Region

• Node A, a relay, unicasts a reply to node b

• Node p is within the transmission range of node A

• Node p will hear the reply and may cache the information


Reactive Request Reaches Proactive Region

• Node p broadcasts a request which reaches node b in a proactive region

• Node b may respond if it has cached relevant information

• Otherwise it can forward the request to its relay set


Proactive Request in Reactive Region


Failure Recovery• Resource fails

– Jini-like approach to information currency

– Period in which incorrect information might be served

– Proactive algorithm may be more responsive

• Node fails

– All neighbour information deleted, including resources

– Incorrect information will remain in the network for a period


Discussion• RUBI represents trade-off between:

– Context-aware operation

– Efficiencies gained by assuming stability

• Greater overhead than the other approaches reviewed

– Neighbour establishment and monitoring

• Will not realise efficiencies gained in other approaches


Future Plans• Evaluate performance through emulation as part of the

ADAM framework

• Evaluate proposed design improvements

– Border nodes could act as gateways

• Address security issues

– ADAM trust management framework


Conclusions• Resource discovery

– Key factor in realisation of ubicomp vision

• RUBI designed with ubicomp environment in mind

– Stability of underlying network is not assumed

– Heterogeneity is assumed and exploited where possible

– Routing algorithms ensure the efficient dissemination of information

– Autonomously adapts to prevailing network conditions


Spare Slides


Resource Discovery• Conceptually very simple

– Resource owners register service in distributed directory

– Clients query the directory for services matching a particular set of attributes

• Implementation is more complex

– How to describe resources and express queries?

– What form of distributed directory to use?

– Where to locate information and how to move it around?

– How to control access to that information?


Effects on Resource Discovery

• Must be distributed

– Available at many points in the network

– Highly scalable

• Must require minimal human interaction

• Must operate on even the most resource-poor devices

• Take advantage of available resources where these are present

– Bandwidth, processor speed, memory


Routing Algorithms

• Proactive

– Forwarding paths periodically exchanged: OSPF

– Applicable in areas of low, relative mobility

• Reactive

– Route information exchanged as needed: DSR and AODV

– Suited to regions of high, relative mobility

• Hybrid approaches: ZRP


• Based on two routing algorithms:

– OLSR, suited to stable, fairly dense networks

– AODV, suited to networks that have a fairly high mobility rate

• Algorithms integrate well

– All nodes cache information

– Requests answered by any node with up-to-date information

• RUBI is resilient over wider range of network conditions

Resource Discovery Operation


Reactive Reply Reaches Proactive Region

• Node p sends a reply to node b

• If node b is not the packet destination, it will drop the packet.

• Node b may cache the resource information in the reply

mpac 2004rae harbird 1 rubi adaptive resource discovery for ubiquitous computing

Documents

rae harbird

resource information

cancelled resource slide

resource search

reactive resource requests

reactive slide

slp slide

adaption slide