Communication Between Peer Wireless Sensor Networks over 2.5G/3G Mobile Networks

1. Communication Between Peer Wireless Sensor Networks over 2.5G/3G Mobile Networks Srdjan Krco R&D Ericsson Ireland srdjan.krco@ericsson.com

2. About Ericsson Ireland • 3G research and development; • Training center; • Applied Research Lab • Network management; • Wireless sensor networks; • Ad-hoc networks; • Distributed systems;

3. Acknowledgments • Skylark project team • David Cleary • Daryl Parker

4. Presentation outline • Introduction; • Wireless sensor networks gateway architecture; • P2P sensor networks; • Conclusion;

5. Introduction – Ericsson Interests • Ericsson fields of interest: • Mobile infrastructure; • Mobile services – design and development of new services that will increase number of mobile network subscribers; • Sensor networks in mobile networks context; • Potential source of new traffic and hence revenue; • Issues: • How to connect sensor networks to mobile networks; • How to enable easy access to sensor networks and information they provide; • Impact of numerous sensors connected to a mobile network;

6. Introduction – Wireless Sensor Networks • Number of small nodes with sensing, computing and wireless communication capability; • Data gathered in one node; • Hop-by-hop communication; • Redundant number of nodes; • Data fusion; • Querying and tasking;

7. Introduction – Wireless Sensor Networks • Gateway node • injects queries and tasks; • gathers responses; • User-gateway communication • using short-range wireless technology or • wide area networks (fixed and mobile); • Sensor networks deployed, maintained, operated and used by one organization;

8. Introduction – Wireless Sensor Networks

9. Introduction – Resarch Focus • Popular research topics: • Routing; • MAC layer issues; • Data aggregation; • Security; • Middleware; • Less popular: • Interaction with external networks; • Interaction between wireless sensors networks;

10. Introduction – Standard Assumptions • Users have applications designed for a particular sensor network; • Available services known in advance (temperature monitoring, military vehicles tracking); • Means for establishing communication links with gateways (protocol, gateway address, etc.) known in advance;

11. Focus of Our Research • Design and development of software and protocol architecture of a wireless sensor network gateway • Generic, supports various sensor types and data format; • Independent of underlying transmission technologies; • Creation of a peer-to-peer sensor network over a 2.5/3G mobile network, where each sensor network represents one peer node • Peers able to exchange data and provide more complex services; • Users also peers or have access to services provided by any peer via communication with one peer node only;

12. Our Testbed

13. Smart Sensor • Micro controller • Controls Bluetooth link; • Implements communication protocol for interaction with gateway; • Controls attached sensors; • Memory • Stores sensor data temporarily; • Sensors • One or more attached; • Described by attributes;

14. WSN Gateway Implementation • Linux OS laptop; • Java; • Bluetooth PCMCIA card; • GPRS PCMCIA card or infrared connection to a GPRS enabled mobile phone;

15. WSN Gateway • Entry point into a sensor network; • Short-range wireless communication • With sensors; • With users in the vicinity; • Wide area network access • Remote users; • Other gateways;

16. WSN Gateway • Hides internal organization of the sensor network; • Aware of all sensor types in the network and their characteristics • Sensor attributes (sensor type, location, data format, accuracy etc.) described and transferred as XML string; • Sensor querying based on sensor attributes (XML based); • Describes supported functions (max, min, average);

17. WSN Gateway Functionality • Discovers smart sensors; • Gathers description of available sensors; • Controls communication with and functionality of sensors; • Creates an object for each available sensor • Has methods for communication with the sensor; • Keeps an up to date description of the sensor; • Provides API for access and control of the sensor network;

18. WSN Gateway – Architecture

19. Core Services • Common procedures and services required by all layers • Logging; • Scheduling; • Event subscription; • Services required for automatic application start and restart;

20. Sensor Network Communication Interface • Transmission technology specific; • Provides methods for data transfer to/from sensors over the chosen communication interface; • Provides additional, interface specific methods (Inquiry, Service Discovery);

21. Sensor Network Abstraction Layer • Each sensor in the network represented as one object: • Methods for sending and receiving data to/from sensors; • Stores the complete description of sensor’s capabilities; • Data transmission specifics hidden from users; • Uses XML based communication protocol • Discover sensors’ characteristics; • Transfer data and commands; • Change sensor settings; • Applications access objects using SN interface; • Collected replies are formatted into a structured XML document and forwarded to users;

22. Sensor Network Abstraction Layer – GetData <?xml version="1.0" encoding="UTF-8"?> <getData> <sensor> <sensorID> 2 </sensorID> <transmitMode> <attribute name=”periodical”> <attribute name=”period”> 5 </attribute> <attribute name=”unit”> min </attribute> </attribute> </transmitMode> </sensor> </getData>

23. <sensorProfile> <attributeProfile> <attribute name="location"> <attribute name="town"> Dublin </attribute> <attribute name="building"> <attribute name="name"> Woodpark </attribute> </attribute> <attribute name=“floor"> 3 </attribute> <attribute name="room"> <attribute name="name"> Conference room </attribute> <attribute name="number"> 12394 </attribute> </attribute> </attribute> </attributeProfile> Sensor Profile

24. <dataProfile> <dataAttribute> <name> temperature </name> <unit> Celsius </unit> <sampleLength> 4 </sampleLength> </dataAttribute> </dataProfile> </sensorProfile>

25. Sensor Network API • Generic methods, provide consistent interface regardless of sensor type and characteristics; • List of sensors in the network; • Description of available sensors (sensor attributes); • XML querying based on description of required data; • Listeners: • Sensor has been added/removed from the network; • New data available;

26. Sensor Network API – Query • Users define data they are interested in (for example: temperature on the first floor in the HQ building) instead of defining the network address of a particular sensor; • Query definition similar to the sensor attribute profile; • Constraints given in the query compared against characteristics (attributes) of available sensors and returns a list of sensor IDs that correspond to the query;

27. Sensor Network API – Query <?xml version="1.0" encoding="UTF-8"?> <querySensors> <constraint attrName="location"> <constraint attrName="building"> <constraint attrName="name"> <equals> HQ House </equals> </constraint> </constraint> <constraint attrName="level"> <moreThan> 1 </moreThan> <lessThan> 4 </lessThan> </constraint> </constraint> </querySensors>

28. P2P Sensor Networks • Sensor networks • Deployed on ad-hoc basis by various entities; • Appear and disappear based on the operator needs, requirements and schedule; • Short-range (Bluetooth) and wide-range (UMTS) wireless interface for communication with users; • Users interact with networks in an ad-hoc manner based on theirs needs at a given moment and location;

29. P2P Sensor Networks

30. P2P Sensor Networks • Users are external to the network • do not know about the existence of the network or services they provide; • Sensor network’s characteristics, type or format of data unknown; • Sensor network detection, service discovery and service provision mechanisms required;

31. P2P Sensor Networks • Numerous services • Traffic congestion info; • Water pollution of a river; • Weather info; • Personal health care network; • Free spaces in a car park; • Not feasible to have a central service listing server;

32. P2P Sensor Networks • Individual sensor networks • Cooperate; • Form groups; • Provide more comprehensive service; • Available to more users; • Users • Communicate with one sensor network gateway; • Able to get information about/from all other sensor networks in the group;

33. P2P Sensor Networks • Possible scenarios: • Users access sensor network over a short-range wireless interface (Bluetooth): • Bluetooth Inquiry; • Access to information from via the gateway; • Users access sensor network over a mobile network: • Join peer group; • Access to information using P2P protocols;

34. P2P Sensor Networks and Users

35. P2P Sensor Networks • Issues • Detection of other sensor networks; • Information exchange between sensor networks; • Description of sensor network services; • Forwarding users request and sensor network responses to/from proper sensor network;

36. JXTA • Network programming and computing platform for creating interoperable P2P applications and services; • Designed for ad-hoc, pervasive, multi-hop P2P networks; • Allows any connected heterogeneous device on the network (mobile phone, PDA, PC et.) to communicate and collaborate with one another;

37. JXTA - Architecture

38. JXTA – Core Layer • Peers: any networked device that implements JXTA; • Peer Groups: collection of peers that have a common set of interests; • Pipes: the basic communication means – a virtual unidirectional connection between peers; • Advertisements: Describe all entities (resources), such as peers, peer groups, pipes, or services; • XML structured documents; • Network Transport: provides a mechanism to handle the transmission of data over the network;

39. JXTA – Protocols

40. JXTA – Protocols • Peer Resolver Protocol – mechanism by which a peer can send a generic query to other peers; • Peer Discovery Protocol (PDP) – used to discover any published resources represented as advertisements. The PDP is based on the use of rendezvous peers; • Peer Membership Protocol – mechanism by which peers can organize themselves to form groups. Peer groups are discovered using the PDP; • Pipe Binding Protocol – used to establish pipe connections between peers;

41. JXTA - Protocols • Rendezvous Protocol – propagates messages within the specified group on behalf of peers from within the same group • primary purpose is to provide a service whereby peers can connect to a rendezvous peer to avail of a service that will propagate messages on their behalf; • Rendezvous Peers – Special type of peers with the ability to cache advertisements and forward requests to help peers discover resources; • Interact with different rendezvous peers;

42. JXTA Services • Discovery Service • Provides access to the PDP; • Limited to the context of the peer group; • Searches for JXTA resources; • Pipe Service • Manages and creates virtual channels of communication between peers in a peer group • Limited to the context of the peer group; • Resolver Service • Implements the resolver service to distribute queries among peers;

43. Platform Specific Services • Position Service • Provides peer-positioning services by querying the MPS (Mobile Positioning Service) for a given MSISDN embedded within a PeerID; • Scheduler service • Allows tasks to be remotely scheduled on peers within our network (scheduled code updates, scheduled migration of services between peers); • Sensor Service • JXTA wrapper service around the WSN Gateway functionality; • Communication between peer sensor networks over GPRS network; • Provides remote querying of sensor networks and individual sensors as well as providing sensor event subscription mechanisms;

44. Example • Gateway gathers sensor profiles, compiles a list of available services/sensors characteristics (type, location, accuracy, …) and structure it as its advertisement; • Rendevouz peer has information about all available sensor services in the peer group; • User interacts with a gateway over a short-range interface or becomes a mobile peer; • Gets information about all services in the peer group from the local gateway or a rendevouz peer; • Query network based on description of available services;

45. Conclusion • Gateway architecture: • Supports various types of sensors; • Easily adaptable to different communication technologies; • XML structured sensor profiles and communication protocol; • WSN API supports attribute based querying; • JXTA platform can be used as a P2P middleware layer, but: • Poor performance; • Slow, consumes large amount of memory, quite unreliable; • Prototype scaling-down required;