1. 1 A Context Discovery Middleware for Context-Aware Applications with Heterogeneous Sensors Yu-Min Tseng

2. 2 Sensor & Sensor Network Deployed freely in the environment Context information may be sensed & extracted by various sensors - Temperature, pressure, location, audio, image… Heterogeneous (Different sensing & computing capabilities)  Sensor mote are named via high-level descriptions Self-organization, power efficiency, large scale, reliability Need ad hoc interaction for energy conservation & operation efficiency

3. 3 The fundamental issue - How to deploy a sensor network that provide ad hoc comm. between sensors - An atomic ad hoc talk is end-to-end communication Briefly - A robust & efficient ad hoc data-centric routing infrastructure Problem Statement

4. 4 Assumption Each sensor is capable of  Wireless comm. Only can talk to its geographical neighbor  Computation  Buffering Each sensor does not need GPS, MAC, or IP address support Transmit requests & responses of sensory data only between those interested parties Other nodes shouldn ’ t be involved, except those nodes that must relay messages

5. 5 Support data-centric routing, request can be directed easily & efficiently. This reduces the overhead of address mapping & directory lookup. Self-calibration, self-management, self-healing. Assumption (cont’d)

6. 6 Data-centric Routing Concept  Q: Prof. King ’ s cellular phone? A friend is contacted. Who ever taught by Prof. King The friend may ask his graduate classmate who joined the lab hosted by Prof. King The graduate student may ask the lab assistant

7. 7 Data-centric Routing (cont ’ d) Numerical perspectives  Translate each query to a number  Search a given number by numerically approaching  Example Q: Search a given number N1=Prof. King ’ s cellular phone N 2 =the friend N 3 =the graduate student N 4 =the assistant N 2 > N 3 > N 4 > … N m = N 1

8. 8 Data-centric naming  A sensor is characterized by its meta descriptor about its sensory data  The meta descriptor is attribute-value pairs Example Data-centric Routing (cont ’ d)

9. 9 Convert each sensor’s meta descriptor to a value by adopting a hash function (ex. SHA-1) Requirement for the hashing  Generate a unique hashing value For naming various sensor  Uniform distribution Prevent overloading some particular sensors

10. 10 Data-centric Routing (cont ’ d) Example: V o receive a request for V 4 V o  V 1 V 1  V 4

11. 11 Operations - Route

12. 12 Operations - Join

13. 13 Operations - Update Cost(x, y) denotes the total energy consumed by routing a request torwards y from x The energy of signal consumed between 2 sensor is 1/d 4, where d is the distance between the antennas

14. 14 Operations - Construct

15. 15 When to trigger a mote to update its discovery & neighbor tables? 1.A mote detects that leader stop forwarding requests Failure of link or motes 2.A node cannot communicate with its neighbor nodes 3.Periodical update Maintenance

16. 16 Evaluation 1 ~ 5000 sensors Uniformly & randomly deploy over 210x210 meters square Each sensor is randomly named

17. 17 Result

18. 18 Result (cont ’ d)

19. 19 Result (cont ’ d)

20. 20 Optimization The logical network may not follow the actual network topology Example  A given named value u not appear in mote v  If the cost of path from v to u is relatively economic than the one from v to a leader representing mote v ’ s i-th discovery scope  Mote u replace the leader

21. 21 Optimization (cont ’ d) Each mote v locally eliminates loops Ex: a  b  c  a  d  c  e  d  f a  d  c  e  d  f a  d  f

22. 22 It is possible that multiple leaders & neighbors appeared in he discovery & neighbor tables in a mote are the same The path to the same leaders & the neighbors may not have same route Replace those with the one have the minimally routing cost Optimization (cont ’ d)

23. 23 Summary Heterogeneity Sensor motes are named via high-level descriptions Data-centric Discovery is based on named data Named data resolution and routing are integrated Robustness Each mote (a)periodically refreshes its discovery and/or neighbor tables Multiple routes are constructed by having multiple leaders for a given particular discovery scope Multiple neighbors in a mote are also maintained Large-scale Each mote only maintain O(log n) leaders The discovery overhead is O(log n) in terms of messages and energy consumption Vicinity motes help the discovery Maintenance-free See the operation algorithm (Join, Construct, Update) Each mote refresh its discovery and neighbor tables Energy-constrained Via the vicinity discovery