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