SensIT PI Meeting, April 17-20, 2001 1 Distributed Services for Self-Organizing Sensor Networks...

SensIT PI Meeting, April 17-20, 2001 1

Distributed Services forSelf-Organizing Sensor

NetworksAlvin S. Lim

Computer Science and Software EngineeringAuburn University

[email protected]

April 20, 2001

DARPA/ITO Sensor Information Technology

PI MeetingSt. Petersburg, FL


Main Objectives

Provide distributed services that enable distributed sensor software components to self-organize, adapt to changing requirements, react to network changes, relocate and survive sensor failures in a dynamic ad-hoc network

Provide mechanisms for remote execution of distributed application services

Implement distributed services on top of a dynamic network routing protocol (directed diffusion)


Challenges in Self-Organizing Distributed Sensor Systems

Allow sensor nodes with mixed capability to be deployed incrementally and dynamically reconfigured– No or little pre-planning – Node must coordinate impromptu with each other to detect, track and

report activities– Extensible to new types of sensor nodes and services

Distributed sensor system must react rapidly to changes in sensor composition, task requirements, device failures and mobility

Scalable sensor network architecture — sheer large number of sensor devices deployed over a wide area

Highly mobile situations — support for mobility, physical address rebinding and reachability

Deployed in harsh environment and dynamically changing conditions — requires dynamic reconfiguration, adaptability to changing task requirements, survivable in spite of failures and real-time changes

Limitations of wireless communication: range, bandwidth, power, memory, and computing capability


Distributed Services forSelf-Organizing Sensor Networks

DynamicSensor Network

ConfigurableDistributed

Services

Self-OrganizingSensor

Application Systems

DistributedLookupService

DistributedComposition

Service

DistributedAdaptation

Service

CollaborativeSignal

Processing

Sensor DataRepository

Manager DistributedSensor Query

Processing

DatabaseServer

Register/Requestservice

Accept/Reject

Request Add/RemoveFrom

Cluster

StatusChangesin sensordynamics

ExecuteAdaptation

Publish/Subscribe

Publish/Subscribe

Publish/Subscribe

User GUI


Collaborations in Distributed Services– Auburn distributed services may make use of PSU/ARL mobile code to

implement remote execution of distributed service– PSU/ARL mobile code may use Auburn distributed lookup service to

distributed mobile code repository– UTK mobile agents may use PSU/ARL mobile code package and Auburn

lookup service to download agent code and to migrate agents

SensIT Distributed Service Architecture

AuburnDistributedServices

UTKMobileAgents

PSU/ARLMobile codedaemon

ISI-W diffusion routing

Sensoria RF Modem


Enables new types of sensor nodes to be deployed that can discover capabilities of other sensor nodes and begin cooperative activities in a community of sensors

Any node can spontaneously become a lookup server in an area

Basic Concepts of Lookup Service

Lookup Server

Using information on service provider, e.g. location, interest broadcast can be reduced with geographic diffusion routing

ServiceProvider

ServiceProvider

ServiceClient

– Nodes in an area may elect one– In larger area or more dense

networks, several lookup servers may be established

Other nodes may discover the lookup server in the area and cache that info

Service providers in the area register with the lookup server

The lookup server caches the service providers information

– Finding a service provider in an area requires 1 message to the lookup server instead of broadcast to all nodes


Register Service API

– input_list: attribute-value list where service provider may provide • Location• Parameter list• Interface definition• Mobile code

– lifetime: service remains in the lookup server only for the duration of the lifetime

Lookup Server

ServiceProvider

ServiceProvider

ServiceClient

– Allows a service provider to register with a lookup server

– Each node is associated with only 1 lookup server at any time

– If the current node does not know its lookup server, this function will initiate a lookup server discovery algorithm

– service type: generic type of service, e.g. CSP

– service name: specific name of service, e.g. CSP007

Status = register_service(service_type, service_name, input_list, lifetime)


Status = register_service(service_type, service_name, input_list, lifetime)

Register Service API

Lookup Server

ServiceProvider

ServiceProvider

ServiceClient

– Allows a service provider to register with a lookup server

– Each node is associated with only 1 lookup server at any time

– If the current node does not know its lookup server, this function will initiate a lookup server discovery algorithm



– input_list: attribute-value list where service provider may provide • Location• Parameter list• Interface definition• Mobile code

– lifetime: service remains in the lookup server only for the duration of the lifetime


Status = service_deregister(service_type, service_name) – Deregister specific service name of a service type– Alternatively, let the lifetime expire

Service Deregister API


Status = lookup_service(service_type, service_name, input_list, output_list, interface_type)

Lookup Service API

Lookup Server

ServiceProvider

ServiceProvider

ServiceClient

lookup_service()

– Allows a service client to find service info of a provider



– input_list: attribute-value list of the cluster name, predicate for matching service provider, etc.

– interface type: either through known interface, interface definition, or mobile code

– output_list: attribute-value list service name, location, interface definition, mobile codes


Lookup Service API

Lookup Server

ServiceProvider

ServiceProvider

ServiceClient

output_list

Status = lookup_service(service_type, service_name, input_list, output_list, interface_type)

– Allows a service client to find service info of a provider



– input_list: attribute-value list of the cluster name, predicate for matching service provider, etc.

– interface type: either through known interface, interface definition, or mobile code

– output_list: attribute-value list service name, location, interface definition, mobile codes


Status = service_exec(service_name, input_list, output_list, interface_type)

Service Exec API

– Allows service client to remotely execute services of the provider

– Input_list: Attribute-value list containing the input parameters to the service call

– output_list: attribute-value list of results of the service call

– Interface_type: either through known interface, interface definition, or mobile code

– At most once remote execution semantics

Lookup Server

ServiceProvider

ServiceProvider

ServiceClient

service_exec()


Status = service_exec(service_name, input_list, output_list, interface_type)

Service Exec API

– Allows service client to remotely execute services of the provider

– Input_list: Attribute-value list containing the input parameters to the service call

– output_list: attribute-value list of results of the service call

– Interface_type: either through known interface, interface definition, or mobile code

– At most once remote execution semantics

Lookup Server

ServiceProvider

ServiceProvider

ServiceClient

output_list


Status = service_call(service_type, service_name, input_list, output_list, interface_type)– A sequence of lookup_service() and service_exec() calls– Allows a service client that does not have info about the location of the

service provider– But the client must know the interface or have the mobile code for

interacting with the service provider– If service_name is NULL, any service provider of service_type will be

called

Service Call API


Propagation of Service Info to Distributed Lookup Servers

Sensor node

Cluster head at level 1


Level 1 cluster

Level 2 cluster

Lookup Server X

Lookup Server Y

Lookup Server Z

ServiceProvider

SPropagate Service S

ServiceClient

C

A lookup server with new service info may propagate it to other lookup server


A lookup server with new service info may propagate it to other lookup server Lookup servers that need service info may request that from other lookup

servers


Sensor node



Level 1 cluster

Level 2 cluster

Lookup Server X

Lookup Server Y

Lookup Server Z

ServiceProvider

S ServiceClient

C

FindService S


A lookup server with new service info may propagate it to other lookup server Lookup servers that need service info may request that from other lookup

servers


Sensor node



Level 1 cluster

Level 2 cluster

Lookup Server X

Lookup Server Y

Lookup Server Z

ServiceProvider

S ServiceClient

C

DiscoverService S

Location ofLocation of Service Service SS


Service provider S registered with Lookup Server X

Mobility of Sensor Node

Lookup Server X

Lookup Server Y Lookup

Server Z

ServiceProvider

S ServiceClient

C


Service provider S registered with Lookup Server Y Y notifies X of S new location Y propagates S info to Z


Lookup Server X


Server Z

ServiceClient

C

register_service()

Notify X of S new location

ServiceProvider

Srelocates


C calls service provider S in the new location


Lookup Server X


Server Z

ServiceClient

C

ServiceProvider

S


Database server locates and calls dispersed query proxies through service exec call

Dynamic Distributed Query Processing with Distributed

Services

Lookup Server X

Lookup Server Y

Lookup Server Z

CSP Servers

DatabaseServer

Query proxies

service_exec()


Database server locates and calls dispersed query proxies through service exec call

Query proxies locate and call relevant collaborative signal processing elements through service call (combined lookup service and service exec)

CSP nodes may be incrementally deployed with different algorithms; register with lookup server when initiated

Dynamic Distributed Query Processing with Distributed

Services

Lookup Server X

Lookup Server Y

Lookup Server Z

CSP Servers

DatabaseServer

Query proxies

Results ofservice_exec(

)


CSP servers locate repository/cache managers through the lookup service and retrieve data using repository manager interface

Collaborative Signal Processing with Distributed Services

Lookup Server X

Lookup Server Y

Lookup Server Z

CSP Servers

Repository manager



CSP servers may initiate mobile agents by calling mobile agents daemon to download mobile codes from the distributed repository through lookup service call


Lookup Server X

Lookup Server Y

Lookup Server Z

CSP Servers

Mobile Agents




For migration from node to node, agent codes and states are uploaded through the lookup service calls to the next node’s mobile agent demon

CSP and tracker nodes provide services to query proxies for info retrieval


Lookup Server X

Lookup Server Y

Lookup Server Z

CSP Servers

Mobile Agents


Conclusions With distributed services, new sensor nodes with new

services and applications may be deployed spontaneously into existing sensor networks– implements self-organizing and dynamically changing sensor

networks

Service lookup and remote exec may be simpler mechanisms for some distributed sensor operations

Implement these distributed services on top of directed diffusion routing protocol

Reconfigurable smart sensors can be made self-aware, self-reconfigurable and autonomous

SensIT PI Meeting, April 17-20, 2001 1 Distributed Services for Self-Organizing Sensor Networks...

Documents

Transcript of SensIT PI Meeting, April 17-20, 2001 1 Distributed Services for Self-Organizing Sensor Networks...