sensit pi meeting, april 17-20, 2001 1 distributed services for self-organizing sensor networks...
Post on 22-Dec-2015
215 views
TRANSCRIPT
SensIT PI Meeting, April 17-20, 2001 1
Distributed Services forSelf-Organizing Sensor
NetworksAlvin S. Lim
Computer Science and Software EngineeringAuburn University
April 20, 2001
DARPA/ITO Sensor Information Technology
PI MeetingSt. Petersburg, FL
SensIT PI Meeting, April 17-20, 2001 2
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)
SensIT PI Meeting, April 17-20, 2001 3
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
SensIT PI Meeting, April 17-20, 2001 4
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
SensIT PI Meeting, April 17-20, 2001 5
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
SensIT PI Meeting, April 17-20, 2001 6
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
SensIT PI Meeting, April 17-20, 2001 7
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)
SensIT PI Meeting, April 17-20, 2001 8
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
– service type: generic type of service, e.g. CSP
– service name: specific name of service, e.g. CSP007
– 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
SensIT PI Meeting, April 17-20, 2001 9
Status = service_deregister(service_type, service_name) – Deregister specific service name of a service type– Alternatively, let the lifetime expire
Service Deregister API
SensIT PI Meeting, April 17-20, 2001 10
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
– service type: generic type of service, e.g. CSP
– service name: specific name of service, e.g. CSP007
– 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
SensIT PI Meeting, April 17-20, 2001 11
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
– service type: generic type of service, e.g. CSP
– service name: specific name of service, e.g. CSP007
– 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
SensIT PI Meeting, April 17-20, 2001 12
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()
SensIT PI Meeting, April 17-20, 2001 13
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
SensIT PI Meeting, April 17-20, 2001 14
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
SensIT PI Meeting, April 17-20, 2001 15
Propagation of Service Info to Distributed Lookup Servers
Sensor node
Cluster head at level 1
Cluster head at level 2
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
SensIT PI Meeting, April 17-20, 2001 16
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
Propagation of Service Info to Distributed Lookup Servers
Sensor node
Cluster head at level 1
Cluster head at level 2
Level 1 cluster
Level 2 cluster
Lookup Server X
Lookup Server Y
Lookup Server Z
ServiceProvider
S ServiceClient
C
FindService S
SensIT PI Meeting, April 17-20, 2001 17
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
Propagation of Service Info to Distributed Lookup Servers
Sensor node
Cluster head at level 1
Cluster head at level 2
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
SensIT PI Meeting, April 17-20, 2001 18
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
SensIT PI Meeting, April 17-20, 2001 19
Service provider S registered with Lookup Server Y Y notifies X of S new location Y propagates S info to Z
Mobility of Sensor Node
Lookup Server X
Lookup Server Y Lookup
Server Z
ServiceClient
C
register_service()
Notify X of S new location
ServiceProvider
Srelocates
SensIT PI Meeting, April 17-20, 2001 20
C calls service provider S in the new location
Mobility of Sensor Node
Lookup Server X
Lookup Server Y Lookup
Server Z
ServiceClient
C
ServiceProvider
S
SensIT PI Meeting, April 17-20, 2001 21
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()
SensIT PI Meeting, April 17-20, 2001 22
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(
)
SensIT PI Meeting, April 17-20, 2001 23
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
SensIT PI Meeting, April 17-20, 2001 24
CSP servers locate repository/cache managers through the lookup service and retrieve data using repository manager interface
CSP servers may initiate mobile agents by calling mobile agents daemon to download mobile codes from the distributed repository through lookup service call
Collaborative Signal Processing with Distributed Services
Lookup Server X
Lookup Server Y
Lookup Server Z
CSP Servers
Mobile Agents
SensIT PI Meeting, April 17-20, 2001 25
CSP servers locate repository/cache managers through the lookup service and retrieve data using repository manager interface
CSP servers may initiate mobile agents by calling mobile agents daemon to download mobile codes from the distributed repository through lookup service call
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
Collaborative Signal Processing with Distributed Services
Lookup Server X
Lookup Server Y
Lookup Server Z
CSP Servers
Mobile Agents
SensIT PI Meeting, April 17-20, 2001 26
CSP servers locate repository/cache managers through the lookup service and retrieve data using repository manager interface
CSP servers may initiate mobile agents by calling mobile agents daemon to download mobile codes from the distributed repository through lookup service call
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
Collaborative Signal Processing with Distributed Services
Lookup Server X
Lookup Server Y
Lookup Server Z
CSP Servers
Mobile Agents
SensIT PI Meeting, April 17-20, 2001 27
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