Active Coordination in Ad Hoc Networks

1. Active Coordination in Ad Hoc Networks Christine Julien Gruia-Catalin Roman Mobile Computing Laboratory Washington University in Saint Louis

2. Ad Hoc Networks • Form opportunistically • Change rapidly in response to mobility • Rely on no fixed infrastructure • Provide transient interactions • Foster decoupled computing

3. Computational Model • Ad hoc network • Host (mobile or stationary) • Defines location in physical space • Agents/Application Components • Unit of mobility residing on a host • Data • Owned and generated by each agent Host 2 Host 1 Host 3

4. Context-Awareness • Software and hardware components constantly move and change • Applications must opportunistically adapt • Context scope extends beyond the local host • Perception of context varies by application • Application specific context definition • Asymmetric context interaction • Multiple contexts evolving over time

5. Example Application

6. EgoSpaces Middleware • Presents coordination model for easing application development • Facilitates asymmetric coordination • Allows applications to flexibly interact with the environment • Based on tuple spaces • Provides high-level abstractions of ad hoc network environment

7. The View Construct • Maximal context contains all available data • A view is a projection of the maximal context • Egocentric abstraction of operating context • Tailored to an application’s individual needs • Allow agent to control scope of views • Ease program development • Minimize performance penalties Host 2 Host 1 Reference agent’s view: yellow data within one hop Host 3

8. Programming in EgoSpaces • Application provides declarative view specifications • EgoSpaces builds and maintains views • Facilitates application’s interactions with views • Presents application with local-like data structure Application EgoSpaces Network Support

9. Interacting with Context • Present view contents as tuple space • Use Linda-like operations • Content-based pattern matching • retrieve tuples (rd) • remove tuples (in) • Can affect overlapping views • Atomic blocking, atomic probing, and scattered probing operations 4 2 1 rdgp(pattern) match 3 5

10. Model Limitations • Lacks natural adaptation mechanisms • Provides only polling operations • Allows interaction only with the system state • Requires explicit interaction with individual data items • Difficult to specify behaviors that affect general classes of data • Does not cater to variations in programmer expertise

11. Reacting to Context • Facilitate behavioral adaptation • Agents respond to presence of certain tuple • Application responds by removing or changing the tuple Reactive view F C react change =react to p [remove] [and outmodifiers()]

12. Transactional Programming • Atomic sequence of operations over a set of views • Intermediate results are not visible • Requires locking all view participants • Cannot include blocking operations • Reference agent provides view restriction • Makes a deadlock-free implementation possible T=transaction overv1, v2, … beginop1, op2, … end

13. Augmented Reactions • Extended reaction • Local trigger • Reaction and transaction are atomic • Followed reaction • Remote trigger • Trigger, removal, and notification are atomic • Transaction is a separate step Reactive view inpg T T T react A out =react to p [remove] [and outmodifiers()] followed by T()

14. Active Coordination • Applications benefit from high-level coordination with context • Active views capture natural context interactions • Apply lessons learned in other coordination middleware while accounting for ad hoc networks • Reference agents attach behaviors to views • Encountering specified conditions triggers an automatic response • Generality and extensibility

15. Active Coordination:Data Migration • Replica management is impractical • Transparently collect certain data • Without explicitly reading each data item • Migration automatically collects matching data • Responds to changes in the view Migration view migrate work order work order M=migratep [modifiers()]

16. Active Coordination:Data Duplication • Data availability is often more important than consistency • Duplicate certain data items • Duplicates available upon disconnection • Originals are unaffected Duplication view 4 3 1 duplicate 3 2 2 5 D=duplicatep [modifiers()]

17. Active Coordination:Event Capture • Response to events instead of state • e.g., agent/host arrival, data access • Special event generation mechanism • Multiple registrations for same event • Transaction specifies event’s callback Event view !! inspector arrived event E=eventpfollowed by Te()

18. Consistency Concerns • Transactional semantics • Strong application guarantees • Can be expensive • Can be guaranteed using special protocols • Eager scheduling modality • “Best-effort” semantics • Allow more flexible implementation • Increase performance • Lazy scheduling modality

19. Simplifying Programming • Programming abstractions • Reduce programmer error • Tailored to common needs of real applications • Reduced programming effort • Desirable changes in semantics • = [structural data on this floor] p = …pattern of data to collect… seenTuples = new Vector() while(true) sleep(time) data[] = .rdgp(p) if data  null for i=1 to data.length data[i].newID() out(data[i]) seenTuples.add(data[i]) • = [structural data on this floor] p = …pattern of data to collect… d = new Duplicate(p) .enable(d, eager)

20. Conclusions • Coordination middleware must address constraints of ad hoc networks • Allow adaptation to changing context • Tailor context provision to applications’ needs • Programming abstractions must satisfy application developers’ requirements • Reactive and active constructs provide high-level coordination in EgoSpaces • Required middleware support should be minimized • EgoSpaces’ view abstraction defines context • Behaviors are reducible to reactive construct

21. Thank You • For more information: • http://www.cse.wustl.edu/mobilab