Towards Scalable and Robust Service Discovery in Ubiquitous Computing Environments via Multi-hop Clustering

advertisement
Towards Scalable and Robust
Service Discovery in Ubiquitous
Computing Environments via
Multi-hop Clustering
Wei Gao
MobiQuitous 2007
Service discovery
 Users search for their desired network
services

Examples of network services: remote printers,
scanners, data sources, and webpages……
 Service discovery in ubiquitous computing
environments needs to be:


Scalable to search for matching services
quickly and efficiently
Robust against unpredictable network
topology changes
Service discovery
e
nc
ou
es
An
n
qu
t
Service
Provider
ply
Re
 A service discovery
Re
 Components of a service discovery system:
 Service requesters
Service
Repository
 Service providers
 Service repositories
Access
Service
Requester
process include:


Dissemination of service discovery messages
Matchmaking between the services requested
and provided
Our focus
 Service discovery: partial match
 Services provided rarely match the requests
perfectly
 An acceptable deviation between the services
provided and requested is used in matchmaking
 The searching scope is fixed: Global
 An efficient network architecture is needed
 Ensures that every service request finds all the
matching services on the network
Current solutions
 Solutions with fixed Internet infrastructure
 Jini, UPnP
 Not suitable for mobile environments
 Global DHT-based p2p network
 Too expensive and instable in dynamic
network topology
 Partial match cannot be handled
 Cluster-based approaches
 Clusters are constructed with low stability and
flexibility
Cluster-based Architecture for Service
Discovery (CASD)
 For scalability


The network is organized as multi-hop clusters
based on the Neighborhood Benchmark (NB)
scores of mobile nodes
A virtual backbone is used for disseminating
service discovery messages
Cluster-based Architecture for Service
Discovery (CASD)
 For robustness


Each cluster is constructed to be an extended
local Content-Addressable Network (CAN)
storing service indices
Controllable redundancy of service indices on
multiple service repositories in each cluster
The overall picture
Multi-hop cluster
(Local CAN)
Service discovery
message
Announcement:
store service
indices
Virtual
backbone
A hybrid push-pull approach
Request: local
matchmaking
Distinguished features
 Reduce the communication overhead of
service discovery
 Achieve robust service discovery in cases of
bounded numbers of node failures
 A service request is guaranteed to find all the
matching services in the network
Neighborhood Benchmark (NB)
 The NB score of a node Ni indicates the
qualification of this node to be the
clusterhead
di: the connectivity of


Ni’s
LFi: the
neighborhood
link stability of
Ni’s neighborhood
di : the neighbor degree of Ni
LFi : the number of link failures Ni encountered in
unit time
 NB-based clustering ensures the efficiency
and stability of the clusters constructed
Multi-hop clustering
 1. Network initialization


Initialization by hello beaconing
NB scores of mobile nodes are calculated and
disseminated
 2. Autonomous clusterhead selection

The node with the highest NB score in the Rhop neighborhood is selected to be the
clusterhead
Multi-hop clustering
 3. Handshake with clusterheads
Possible inconsistency during the
clusterhead selection and handshake
process is solved
 All the clusters are connected ones

Construction of local CANs
 Constructed along with
the handshake process
 Clusterheads allocate
spaces for the cluster
members


Node join: the largest
zone is split
Node leave: the
smallest neighbor zone
takes over
 Area deviation among
different zones is
minimized
N1
N2N2N3
N4
N5
N6
N7
N8
N9
N12
N13
N14 N15
N17
N18 N19
N20
N10
N11
N16
Service discovery
 Service discovery messages are
disseminated among different clusters via the
virtual backbone
 Local CANs store service indices with
controllable redundancy


Every node is a service repository
Every service discovery message is forwarded
to multiple destinations in a local CAN
Multiple forwarding destinations for
service announcements
 Redundancy degree dr in a local CAN
 The proportion of the forwarding destinations to
the total number of nodes in the clusters
 Bounded by the radius R1 of a circle in the virtual
coordinate space:
, where
Multiple forwarding destinations for
service announcements
 Every service
announcement falls
into a zone in the
virtual coordinate
space
 All the nodes whose
virtual zone overlaps
with the circle

With the radius R1
N1
N2 N3
N6
S
N4
N5
N8
N9
N7
N10
N12
N13
N14 N15
N18 N19
N20
N11
N16
N17
Multiple forwarding destinations for
service requests
 A service request is forwarded to all the
nodes that possibly contains the matching
services
 R2: The acceptable deviation range in service
matchmaking
 A forwarding process consists of two steps
Multiple forwarding destinations for
service requests
 1. All the nodes
within the
acceptable deviation
range

N6
N2 N3
N7
S
N4
N5
N8
N9
Radius R2
 2. For each recipient
in the 1st step, to its
redundancy range

N1
Radius R1
N10
N12
N13 N14 N15
N11
N16
N17
N18 N19
N20
Simulation settings
 The performance of CASD is compared with
service discovery in flat network architecture

Service discovery functionality is implemented
on ad-hoc routing protocols: AODV and DSR
 Every node periodically announces a service
and requests for another service
 Different variations of CASD


Local CANs are used: CASD-1
Without local CANs: CASD-2
Simulation results
 Successful ratio in different mobility settings
Simulation results
 Overhead in different mobility settings
Simulation results
 Scalability: overhead in different network
scales
Simulation results
 Robustness: successful ratio in cases of node
failures
Effects of different cluster radius
 Multi-hop clusters achieves higher
performance
 Multi-hop clusters are also more expensive to
construct
 Cluster radius should be chosen
appropriately according to application
requirements and network conditions
Conclusions
 Scalable and robust service discovery cannot
be achieved in flat network architecture
 A service discovery architecture based on
multi-hop clustering is presented
 Communication overhead of service
discovery is reduced
 A service request is ensured to find all the
matching services in cases of bounded
numbers of node failures
Future work
 Theoretical analysis on the communication
overhead of service discovery in our
approach
 Comparison with other service discovery
approaches based on clustering and “remote
contacts”
Thank you!
 Questions?
Content-Addressable Network (CAN)
 DHT-based p2p network
 A multi-dimensional
Cartesian coordinate
space
 Each node is allocated a
rectangular zone
 Data items are mapped
to virtual points in the
space
N1
N2 N3
N4
N5
N8
N9
N12
N13
N14 N15
N17
N18 N19
N20
N6
N7
N10
N11
N16
Back
Network initialization
 Network initialization by hello beaconing


Hello beacons: {IPi, NBSi, Head_IPi, HEAD_NBSi, hopi}
Interval of hello beaconing: TH
 The NB scores of mobile nodes are calculated
 di is updated on each node by discovering its 1-hop
neighborhood


If a neighbor record has not been updated for long
than 2TH, a link failure is counted
LFi is updated iteratively in each round of hello
beaconing:
Back
Autonomous clusterhead selection
 Mobile nodes exchange their selected clusterheads
with their neighbors via hello beaconing
 Clusterhead selection consists of R consecutive
rounds


In every round, a node puts the clusterheads of itself
and its 1-hop neighbors into a selection pool
The one in the pool with the highest NB score is
selected
 Hello beaconing ensures that in the kth round, the
selected clusterhead are with the highest NB score in
the k-hop neighborhood
Back
Solving the possible inconsistency
 An example of constructing 2-hop clusters



1. N4 selects N3
N7 is notified about N3
2. N4 hears N6 from N5
N4 transfers to N6
N7 does not know that!
N7 select N3
A disconnected cluster
87
N1
105
N10
107
24
N3
N9
47
82
N7
N2
 Solution: nodes only forwards
N4
65
31
N5
N8
58
N6
115
the handshake messages if they have the same
clusterhead
Back
Download