Presentation is loading. Please wait.

Presentation is loading. Please wait.

WIRELESS SENSOR NETWORKS ` Author: Aleksandar Crnjin, 00/17 Supervised by: Dr Veljko Milutinović,

Similar presentations

Presentation on theme: "WIRELESS SENSOR NETWORKS ` Author: Aleksandar Crnjin, 00/17 Supervised by: Dr Veljko Milutinović,"— Presentation transcript:

1 WIRELESS SENSOR NETWORKS ` Author: Aleksandar Crnjin, 00/17 Supervised by: Dr Veljko Milutinović,

2 Topics  Introduction  What are WSNs?  An example: ESB  WSN applications  Energy conservation  Ad-hoc routing  Basic principles  Overview of routing protocols  Data-centric protocols  Rumor Routing  Geographical protocols  Localization and Positioning  Synchronization and Security  The TinyOS operating system  The TinyDB query system  Proto programming language 2/105

3 Introduction: What are WSNs?  Sensors, connected into wireless networks, are:  Very small computer systems  With very high interconnection ability 3/105

4 2 Introduction: What are WSNs? 2 4/105 Overview of networking technologies

5 3 Introduction: What are WSNs? 3 5/105  The idea of wireless sensor networks was first popularized by scientists from UC Berkeley  They have developed:  series of sensor nodes (so-called mica nodes)  open-source software TinyOS operating system TinyDB query system for efficient manipulation of sensed data  An interesting fact:  one of the first applications for small interconnected autonomous systems was in submarine warfare  Integrated Undersea Sound Survelliance System (IUSS)

6 4 Introduction: What are WSNs? 4 6/105  Sensor network (def):  a set of small autonomous systems (sensor nodes) working together to solve at least one common problem  their tasks always include some way of perception of the physical environment  Sensor nodes:  basic units in a sensor network  they are usually powered by batteries and they have some kind of a radio transceiver  Alternative names: motes (most often) smart dust

7 Architecture of a sensor node 7/105 Block diagram of a typical sensor node (mote)

8 An example: ESB, FU-Berlin 8/105 Source: [1]

9 WSN Applications 9/105  Treatment of ill people: wearable computing  under-skin implants – measurement of blood parameters, early detection of some illnesses  already marketed – capsules with 24 hours of battery life which move through the patient’s body and relay images to the doctor through another device worn externally by the patient  Embedded systems: home automation  temperature measurement  alarm systems  Traffic – sensors in cars, early traffic congestion warning  Military applications  Many other; new applications are constantly devised.

10 One application: Camalie Vineyards 10/105 One mote in the vineyards: Crossbow mica2dot mote, NiMH batteries, solar panel, 3V voltage regulator. Source: [12].

11 2 One application: Camalie Vineyards 2 11/105 The visitors of the Camalie Vineyards website can view graphs of ambient temperature (with respect to time) in all points where sensors are present. Slightly colder temperatures come from sensors in the wine cellar; dysfunctional motes report absolute zero. Source: [12].

12 Topics  Introduction  What are WSNs?  An example: ESB  WSN applications  Energy conservation  Ad-hoc routing  Basic principles  Overview of routing protocols  Data-centric protocols  Rumor Routing  Geographical protocols  Localization and Positioning  Synchronization and Security  The TinyOS operating system  The TinyDB query system  Proto programming language 12/105

13 13/105  Careful use of available energy is of paramount importance in WSNs cannot be recharged!  Batteries, in most cases, cannot be recharged!  Inefficient energy use shortens battery life considerably!  Some of the methods for reduced energy consumption and prolonged battery life:  Passive conservation methods  Use of sophisticated energy sources  Placement of sensors into energy efficient topologies  Active conservation methods  Hardware solutions (watchdog timer, reduced clock frequency...)  Energy aware routing protocols; energy efficient medium access (MAC layer)  The choice of an energy-saving operating system Energy conservation

14 Energy sources for motes 14/105  Rechargeable macro-batteries as a secondary energy source  Micro-batteries on a wafer  Ultracapacitors  They not only hold electrical charge in the dielectric,  they also hold ionic charge in the double electrical layer  Energy density larger than in ordinary capacitors by an order of magnitude  Micro Fuel Cells  Microturbines  Radioactive power sources  Solar cells  Energy of the human body  Wearable computing Hydrogen micro-fuel cell 4mm micro turbine Source: [13]

15 Energy conservation: hardware solutions 15/105  Watchdog timers  deliberately turn the power down if the software is stuck in an infinite loop  Sleep states  Variable voltage processing  Deliberate performance degradation by dropping the voltage and reducing the clock frequency  so the same task could be done with smaller energy consumption, at the expense of performance. Variable Voltage Processing Same task can be performed with smaller energy consumption if voltage and frequency are reduced (shaded area). Source: [13]

16 MAC energy aware protocols 16/105  Energy aware protocols are used at the MAC layer (energy efficient medium access).  Basic principle:  Energy required for signal transmission is proportional to d α  d – distance between two nodes  α – attenuation factor (medium dependent)

17 2 MAC energy aware protocols 2 17/105  For optimum α = 2, transmitting a signal to ½ of distance requires ¼ of energy: (½ d) 2 = ¼ d 2 → If a protocol can find a node on ½ distance to target, which can supply additional ¼ of energy to transmit the signal through the remaining half, ½ of energy is saved! (½ d) 2 + (½ d) 2 = ¼ d 2 + ¼ d 2 = ½ d 2

18 Energy solutions in the ESB 18/105  Microcontroller TI MSP340: energy consumption 3V, 1mA (3mW)  total energy consumption is 12mA at 4.5 V, plus additional 12mA during data transmission  program memory: 8KB EEPROM  only 2KB of conventional RAM memory; 60KB Flash RAM for special purposes only (high energy consumption!)  watchdog timer: uses an NMI interrupt to shut the node down immediately, if software gets stuck in an infinite loop  sleep mod, consumes only 0.008 mA (practically equivalent to battery self-discharge) Printed circuit of the ESB

19 Topics  Introduction  What are WSNs?  An example: ESB  WSN applications  Energy conservation  Ad-hoc routing  Basic principles  Overview of routing protocols  Data-centric protocols  Rumor Routing  Geographical protocols  Localization and Positioning  Synchronization and Security  The TinyOS operating system  The TinyDB query system  Proto programming language 19/105

20 Ad-hoc routing 20/105 :  Wireless networks: computer networks with wireless communication links :  Ad-hoc networks: every node can forward packages  in ad-hoc nets every node can forward packages dynamically,  the decision whether each node will or will not forward packages is made dynamically, current connectivity matrix.  with regard to current connectivity matrix.  Comparison:  in conventional computer networks, there are dedicated nodes (routers, switches, hubs...) which forward packages.  Such approach is impossible in ad hoc networks – all nodes are constantly on the move, connectivity changes all the time so there are no good candidates for dedicated routers.

21 2 Ad-hoc routing 2 21/105 have no a priori knowledge  In ad-hoc networks, individual nodes have no a priori knowledge of network topology  when connected, they gradually discover other nodes  Basic principle: advertises  a newly connected nodes advertises it’s presence  reads broadcast messages  reads broadcast messages from neighboring nodes  In this way, a node gradually discovers:  the positions of other nodes in a network,  ways to reach each one of them.

22 3 Ad-hoc routing 3 22/105 routing protocol convergence  When enough time has passed, routing protocol convergence is established.  When this happens, each node “knows” about all the other nodes in the net, and how to reach each one of them.  Convergence time  Convergence time is total time elapsed from when the network topology is changed (for example, when a communication link goes down) to when all nodes have restructured their routing tables in accordance with the change.

23 4 Ad-hoc routing 4 23/105  Conventional networks use data-centric routing: each node has an unique data identifier which serves as its address on the network (IP-address, MAC-address...)  Some ad-hoc networks use different concepts  For example, it might not be necessary for information to be routed from a specific starting point to a specific endpoint, but only to be propagated and diffused through the network. This is called Rumor Routing.  Or, geographical coordinates could be used as means for addressing (Geographical Routing).

24 Overview of ad hoc routing protocols 24/105

25 1 Data-centric protocols 1 25/105 Proactive protocols: routing tables maintain consistent knowledge of network topology through routing tables which are exchanged between nodes periodically Drawbacks:  network bandwidth is wasted: routing tables are an overhead which decreases available bandwidth for useful data  some paths are never used, and yet they are kept in the tables very long convergence time  simulations show very long convergence time some proactive protocols never converge in large wireless networks! Example:  WRP – Wireless Routing Protocol

26 2 Data-centric protocols 2 26/105 Reactive protocols: on demand onlyRoute Request information about paths is not kept; a path is discovered on demand only, by flooding the network with Route Request packages Drawbacks:  on demand path discovery introduces significant delays  flooding the network can lead to severe network congestion Examples: can be found, in detail, in [10]  AODV – Ad-hoc On-demand Distance Vector  DSR – Dynamic Source Routing  TORA – Temporally Oriented Routing Algorithm

27 3 Data-centric protocols 3 27/105 Hybrid protocols: locally proactive, globally reactive e.g. ZRP – Zone Routing Protocol routing zones  The network is divided into routing zones  the zone is usually an sphere with a specified diameter, measured in hop counts  the nodes positioned at the maximum distance from central node X are called peripheral nodes for the routing zone centered at X.  When package needs to be sent from node A to node B:  if B is within the same routing zone as A, local routing table is looked up to find the path to B (proactive behaviour),  if this is not the case, Route Request packages are sent to all peripheral nodes  each peripheral node repeats this step (checks whether the destination B is inside its routing zone).

28 4 Data-centric protocols 4 28/105  ZRP example:  A sphere centered at S: is a zone of radius ρ = 2  J, G, H, I: peripheral nodes  If a package is sent from node S to node G:  Destination is within the same zone, routing table is looked up.  If a package is sent from node S to node T:  Destination is in a different zone, Route Request packages are sent to nodes G, H, I, J.  Node I discovers that T is within its routing zone (d = 2),  It looks up its routing table, and sends the package to L.

29 Rumor Routing 29/105  first proposed by Braginsky and Estrin (UCLA) in their paper [4].  All nodes are divided into two groups: perceive  nodes that perceive events, seek information  nodes which seek information about events, from the nodes of the preceding group  There is no network topology  There is no coordinate system  The protocol doesn’t try to find an optimum route, it seeks only to relay the information end-to-end  sub-optimum routes are satisfactory for this purpose

30 2 Rumor Routing 2 30/105 Illustration of Rumor Routing protocol (Source: [1]) Rumor Routing protocol: 1.Events A and B are perceived on some nodes 2.An agent is sent from both groups (A and B) to “spread rumors” about the whereabouts of possible sources of information for events A and B 3.When agent B meets agent A on its way, it goes on to spread information about both events A and B 1 1 2 2 3

31 3 Rumor Routing 3 31/105 Illustration of Rumor Routing protocol (Source: [1]) Handling the information requests: 1.A node requests information about event A 2.It’s request “moves blindly” through the network until it stumbles upon a node visited by the information spreading agent. While moving, it leaves traces so it can backtrack when information is found. 3.When a node visited by the agent is found, a route is followed to the source of information 4.Information is retrieved and brought back to the source of the request. 2 4 3 1

32 Geographical Protocols: An Overview 32/105  Routing relies on geographical position information (as opposed to data centric routing)  Destination for a package is a specific area  e.g. a city, a section of a highway, or, at the micro level, a part of the conference room  recipient cannot determine exactly who is the sender, it can only determine roughly from where the package came from  Routing decision are made with respect to real, spatial coordinates positioning information  For that to be possible, positioning information is necessary  one way of obtaining position information is GPS (Global Positioning System)

33 An example: GeoCast 33/105  Proposed by Navas and Imielinski, 1997.  Three-tiered architecture:  GeoHosts  GeoHosts are endpoints of the network Client processes (applications) are run on them GeoHosts initiate message transfer On receipt of the package, they check if their geographical region is the destination of the package.  GeoGateways  GeoGateways are the network’s entry and exit points GeoHosts communicate with GeoRouters through broadcast messages a GeoGateway is responsible for a given area specified by a radius  GeoRouters  GeoRouters perform the actual routing they are aware of the coordinates of neighboring GeoRouters and GeoGateways they route the package through neighboring GeoRouters to the destination GeoGateway so that it can reach the destination geographical area.

34 2 GeoCast routing 2 34/105 Ilustracija koncepata GeoHost, GeoGateway, GeoRouter

35 3 GeoCast routing 3 35/105 Client Process Direct message GeoRouter GeoHost GeoGateway Event Source: [5] GeoCast communication: 1.A node on Net A perceives the event 2.It sends a message to its GeoGateway 3.Gateway forwards the message to a neighboring GeoRouter 4.Routing is performed 5.At some moment, destination Gateway is direct neighbor to a router; the router hands the message to destination Gateway. 6.Destination Gateway delivers the message to Net B. Client Process

36 4 GeoCast routing 4 36/105  With classical IP networks, next hop address is determined by looking up a routing table  With GeoCast, destination addresses are areas specified by necessary parameters  if the area is a circle, location of center and length of radius are required  if the area is a polygon, locations of all angles are required  Routers are organized in a hierarchical manner  routers responsible for smaller geographical areas are lower in the hierarchy  routers responsible for larger geographical areas are lower in the hierarchy

37 5 GeoCast routing 5 37/105 1. A client process, running on a GeoHost, delivers a message to its GeoRouter through its network’s GeoGateway 2. GeoRouter consults lower-level GeoRouters and determines:  Is there any overlap between the zone of responsibility of the lower level router, and the destination area?  If there is an overlap, the message is forwared to the lower-level GeoRouter.  When this is repeated for all lower level routers, was the destination area covered completely? 3. If it was, the procedure ends here. 4. If it wasn’t, the message is unicast to a higher level router, responsible for wider geographical area, which repeats the procedure starting at 2.

38 6 GeoCast routing 6 38/105  In order to implement the described procedure, another procedure is necessary, one that will determine if the two areas overlap.  If the two areas are both circles, the procedure is simple  if the distance between centers is smaller than the sum of the radiuses, the circles indeed overlap

39 7 GeoCast routing 7 39/105  If the two areas are a circle and a polygon, or they are both polygons, things get complicated  Geographical calculations of higher complexity are necessary  Comparison with IP nets:  In IP networks, a simple query on the routing table is all that is necessary  In GeoCast networks, routing decision complexity is several orders of magnitude higher!

40 Routing Protocols: A Conclusion 40/105  Rough classification of protocols:  Data-centric: an address is some kind of datum (e.g. an IP address – 4 bytes of data)  Diffusion: it is not necessary to address individual nodes, only to diffuse the information through the network  Geographical: an address is a geographical area, described by geographical parameters  Most uses for data centric protocols are outside of wireless sensor networks  Diffusion protocols are simple  but they are suitable only for a small number of use cases  Geographical protocols are conceptually most suitable for wireless sensor networks  but making a routing decision can be very complex

41 Topics  Introduction  What are WSNs?  An example: ESB  WSN applications  Energy conservation  Ad-hoc routing  Basic principles  Overview of routing protocols  Data-centric protocols  Rumor Routing  Geographical protocols  Localization and Positioning  Synchronization and Security  The TinyOS operating system  The TinyDB query system  Proto programming language 41/105

42 Localization and Positioning 42/105  Measurements by sensor networks are substantially more valuable if the location of measurement is known  Therefore, a sensor has to be aware of its position in the real world  Two approaches:  Localization  Positioning C A B

43 2 Localization and Positioning2 43/105  Localization: location of the sensor is given as relative to some local point it is then possible to calculate distances and angles between individual nodes but it is not possible to determine the sensor’s global position  Positioning: a sensor is given absolute coordinates on the world map e.g. coordinates can be longitude and latitude

44 3 Localization and Positioning3  The simplest solution to the problem of positioning is to put a GPS device in each sensor node.  GPS receivers are still too expensive and too big!  The remaining possibilities can be divided into 4 groups (picture). 1 Some nodes know their position, and distances between nodes are known. 2 No node knows its position, but distances between nodes are known. 3 Some nodes know their position, but distances between nodes are not known. 4 No node knows its position and distances between nodes are not known. 44/105

45 4 Localization and Positioning4 1. Global coordinates are available for the complete topology, 2. Only local coordinates are known, 3. It is possible only to roughly estimate the position of the whole system, 4. Only the network’s connectivity matrix is available. 1 Some nodes know their position, and distances between nodes are known. 2 No node knows its position, but distances between nodes are known. 3 Some nodes know their position, but distances between nodes are not known. 4 No node knows its position and distances between nodes are not known. 45/105

46 5 Localization and Positioning5 46/105  Since only some nodes need to be aware of their position in order to establish positioning for the complete network,  only some nodes need to be equipped with a GPS device,  because of high energy consumption, GPS could be turned on only occasionally,  in those intervals, remaining nodes perform localization with respect to the GPS-equipped nodes.  Alternate solution: instead of equipping them with a GPS device, some nodes could have their position manually input by an operator (based on measurements from his GPS device).  This solution is sometimes neither practical nor possible!  For mobile networks, public positioning stations are usually used.

47 1 Positioning1 47/105  Positioning of every node is possible in Case 1 from the table  that is the case when positions of some nodes are known, and distances between nodes are known, too.  Three already positioned nodes are enough to determine position of another node  if the distances between nodes are known.  one way of measuring distance is measuring the attenuation of the radio signal  If some of the 3 nodes is not positioned with sufficient precision, the error propagates quickly!

48 2 Positioning (2D) 2 48/105  p i, p j – already positioned nodes  n – newly added node  We consider two spheres, with radiuses d n, i i d n, j, around their centers p i i p j  They intersect in two points: n i n’  The final step in positioning is to choose one of these points  In order to do this, we need the third already positioned node  Mutual visibility is checked with the third node, in order to discount one of the points n i n’. In satellite positioning (3D) the final step is usually unnecessary; the object has to be on Earth’s surface→ points in space or below surface are instantly discarded

49 1 Localization1 49/105  In case no node is aware of it’s position, but distances between nodes are known, localization is the only possible approach.  Capkun, Hamdi, Hubaux, “GPS-free Positioning in Mobile Ad-hoc Networks”  Describes the procedure which establishes a global coordinate system (CS)  based on measurements of distances between nodes

50 2 Localization2 50/105 Basic procedure for establishment of a global coordinate system (CS), in a two-dimensional environment, is as follows: 1. Each node searches for its immediate neighbors  in this way, “immediate neighborhood”, consisting of all nodes one hop away, is formed. 2. The distance table obtained in (1) is sent to all neighbors 3. In each node a local coordinate system is established, with that node in the center 4. For each node n, two additional nodes p and q are chosen from the immediate neighborhood, in order to define x and y axes  x-axis is a line drawn from the circle, through node p, oriented outwards  y-axis is always perpendicular to the x-axis, node q is necessary only to determine its orientation

51 3 Localization3 5. In each node, the remaining nodes’ positions are expressed in the local coordinate system 6. One of the local coordinate systems is chosen (for example, CS of node i); origins of all other CS’s have their locations in the CS of node i 7. For each node j, j ≠ i: 1. Axes are rotated so that they become parallel to axes of CS i 2. Coordinates of the origin of CSj, with respect to CSi, are added to coordinates of all pointsd in CSj. 51/105 In this way, all local coordinate systems are unified into a global coordinate system, in which node i holds the position (0,0).

52 Localization and Positioning: Conclusion 52/105  For the measurements to be truly useful, it is necessary to know the location of the measurement.  When some of the nodes are aware of their global position, it is possible to establish positioning information for each node in the network.  If there are no such nodes, it is still possible to construct a local coordinate system.

53 Topics  Introduction  What are WSNs?  Primer čvora senzora  WSN applications  Energy conservation  Ad-hoc routing  Basic principles  Overview of routing protocols  Data-centric protocols  Rumor Routing  Geographical protocols  Localization and Positioning  Synchronization and Security  The TinyOS operating system  The TinyDB query system  Proto programming language 53/105

54 Synchronization 54/105  Time synchronization of events and activities is essential in all distributed systems  In wireless sensor networks:  even more precise synchronization is needed  and it has to obtained with scarce critical resources (battery power, communication channel availability, etc.)  Comparison with conventional distributed systems:  each node can operate only as long as its batteries last therefore, clocks in all nodes cannot be maintained from a central place (so called master clock) as that node may run out of power  each use of the CPU and the communication medium comes with a great price in energy  therefore, existing systems aren’t good enough!

55 2 Synchronization 2 55/105  Possible distortions of measured time, as the clock propagates through the sensor network:  Jitter: “podrhtavanje” časovnika usled nepreciznosti.  Skew: the clock becomes faster or slower than normal (frequency distortion)  Drift: measured time differs by a constant offset (phase distortion)  this is a problem only if different nodes have different offsets Source: [1]

56 3 Synchronization 3 56/105  There is no optimum solution with satisfies all criteria (preciseness, lifespan, availability)  Different approaches are often combined  Some commonly applied solutions:  Explicit synchronization instead of keeping all clocks in synch all the time events are recorded with respect to local time when needed, these time marks are converted to another scale on demand only  Peer-to-peer synchronization amount of synch related errors between two nodes is proportional to distance between them therefore, keeping a centralized clock is not a good approach instead, only neighboring nodes exchange synch related information

57 Security 57/105  Sensor networks usually consist of a large number of nodes  To supervise each node is practically impossible  Therefore, sensor networks are:  highly susceptible to logical and physical attacks  and communication interception a node could be seized, reprogrammed, then put back into the network by means of reverse engineering, nodes could be designed to trick the network into treating them as authentic  Various forms of abuse are then possible  intercepting confidential information (sensed data)  falsifying sensor readings  Distributed Denial of Service (DDoS) attacks.

58 2 Security 2 58/105  To protect every single node from reprogramming is economically unfeasible  Other approaches are used:  node-to-node authentication: nodes in the network have to prove their identity to each other  node revocation: when an intruding node is discovered, it is forbidden to access the network any further  Applied protocols have to be made resilient  Meaning, the network has to be able to continue functioning properly, even if some nodes are compromised.

59 3 Security 3 59/105  Privacy of sensed data is kept by encryption  Conventional approach – large keys  Unsuitable for sensor networks – because of limited memory!  Commonly applied approach – hop-to-hop encryption  Messages are encrypted using short keys in every node  Drawback: if one node in the chain is taken over, there is no more encryption for any messages passing through that node  Multipath routing  before it is sent, the message is broken into several chunks  these chunks move through the network using different routes  they are not reassembled until they reach the destination

60 4 Security 4 60/105  DoS attacks – another threat  through DDoS attacks, attackers can deliberately drain the batteries  physical protection: spread spectrum communication frequency hopping  logical protection: constantly checking and discarding messages with invalid authenticity information  danger:  danger: in this way, the very protection from DDoS can drain the battery! because, power is constantly spent on authenticity checks for incoming messages

61 5 Security 5 61/105 Energy cost of added security through authentification: as much as 71% extra energy cost is due to increased amount of transmission!

62 Synchronization and Security: Conclusion 62/105  These are the problems also present in conventional networks  However, because of different architecture, many traditional approaches are not suitable  Solutions for sensor networks have to be designed with respect to the specific architecture of sensor nodes  most of all, the scarcity of energy resources

63 Topics  Introduction  What are WSNs?  Primer čvora senzora  WSN applications  Energy conservation  Ad-hoc routing  Basic principles  Overview of routing protocols  Data-centric protocols  Rumor Routing  Geographical protocols  Localization and Positioning  Synchronization and Security  The TinyOS operating system  The TinyDB query system  Proto programming language 63/105

64 TinyOS 64/105  Because of the specific architecture of sensor networks, a suitable operating system had to be devised  Conventional OSes for embedded systems  VxWorks  Windows CE  PalmOS  QNX  They all require ROM of 100KB or more!  The ESB, introduced in Chapter 1, has only 8 KB ROM!  Because of this, TinyOS was developed.

65 Characteristics of TinyOS 65/105  Event-driven programming  conventional context switching is impossible, there is no room for the stack!  a system of components is used instead; each component has its own static area in memory (“frame”)  in this way, the need for stack is eliminated  programs are executed only in response to the events  events are registered by components beforehand  Energy conservation  Interrupt polling is forbidden: if the CPU constantly checks the status register, battery power is continuously expended  Interrupt masking is forbidden, too: node which requests the interrupt would spend power while it waits

66 TinyOS Architecture 66/105  TinyOS has:  a short-term task scheduler  components, which usually have:  command handling routines (command handlers)  event handling routines (event handlers)  a fixed amount of allocated memory (frame)  a few simple tasks  Each component advertises:  which commands it can handle,  which events it can report.  All tasks, commands, and event handler routines are executed only within the allocated memory frame

67 2 TinyOS Architecture 2  Memory frames are allocated statically at compile time  Commands are issued by higher level components, to lower level components  they place parameters on pre-defined locations within the memory frame  they deposit tasks for later execution  at some moment, they provide feedback to the caller component  Event handling routines:  respond to hardware events  write information to the memory frame  deposit tasks for later execution  signal events to higher level components  issue commands to lower level components 67/105

68 3 TinyOS Architecture 3 68/105  Tasks:  perform the actual work  with respect to other tasks, they are atomic once started, they cannot be interrupted by other tasks higher level events, however, can interrupt them (pre-emption)  issue commands to lower level components  signal events to higher level components  deposit new tasks to their component  Short-term scheduler: a simple FIFO buffer

69 TinyOS: An example Component 69/105  A message transfer component  Sends and receives individual packages to/from the lower level  Sends and receives whole messages to/from the higher level  As all components, it sends commands to the lower level: an initialization command: init, an initialization command: init, power management command: power(mode) power management command: power(mode)  It recieves the same components from the higher level

70 2 TinyOS: An example Component 2 70/105  It also sends the transfer initiation command: TX_packet (buf)  It responds to following events (from lower level): package is transmitted TX_packet_done (success) package is transmitted TX_packet_done (success) package is received RX_packet_done (buffer) package is received RX_packet_done (buffer)  It signals the following events (to higher level): message is transmitted msg_send_done (success) message is transmitted msg_send_done (success) message is received msg_rec (type, data) message is received msg_rec (type, data)

71 3 TinyOS: An example Component 3 71/105 This code is used to declare the message transfer component

72 4 TinyOS: An example Component 4 72/105  An illustration of the amount of occupied memory in a typical sensor node:  Our component, AM, takes up 356 bytes of ROM and 40 bytes of RAM  In the list of components, we can also see the components which provide for hardware abstraction  For example, RFM represents the built-in RFM transciever  A fully functional sensor node needs only 3450 bytes of ROM and 226 bytes of RAM!

73 Topics  Introduction  What are WSNs?  Primer čvora senzora  WSN applications  Energy conservation  Ad-hoc routing  Basic principles  Overview of routing protocols  Data-centric protocols  Rumor Routing  Geographical protocols  Localization and Positioning  Synchronization and Security  The TinyOS operating system  The TinyDB query system  Proto programming language 73/105

74 TinyDB 74/105  A query processing system, which gathers information from sensor nodes which have TinyOS installed  It uses a declarative programming language, TinySQL sensors  Queries are always performed on a unique, default, logic table: sensors  The sensors table has:  one row, for each measurement performed by any sensor node;  one column, for each relevant attribute of the measurement: nodeID, temp, state,...  It is bundled together with TinyOS as a component which is installed on every mote in the net

75 2 TinyDB 2 75/105  TinySQL is very similar to standard SQL, but there are some very important conceptual differences  It also has aggregate functions and triggers  A query, once input, is performed repeatedly  performing frequency is input through the epoch parameter  it has to be chosen carefully, having in mind the limited battery capacity  Queries can be input:  visually, through an application bundled with TinyOS  through coding, in a language very similar to SQL

76 3 TinyDB 3 76/105  Basic form of the query: SELECT select-list [FROM sensors] WHERE where-clause [GROUP BY gb-list [HAVING having-list]] [TRIGGER ACTION cmd-name[(param)]] [EPOCH DURATION integer]  An example: SELECT temp FROM sensors WHERE temp > thresh TRIGGER ACTION SetSnd(512) EPOCH DURATION 512  If temperature higher than specified threshold is found on any sensor, a beep 512ms long is sounded, and the query is performed again after 512ms.

77 4 TinyDB 4 77/105  Queries can be performed in response to external events, too  for example: an event which signals that the temperature has risen above some threshold  Two procedures are necessary:  Writing a component which detects the event and notifies TinyDB that it has indeed happened  A query in TinyDB of the form: on event: SELECT...

78 5 TinyDB 5 78/105  Example: ON evtTest: SELECT nodeid,light SAMPLE PERIOD 1024  In response to event evtTest, sensed light data is collected every 1 second.

79 Topics  Introduction  What are WSNs?  Primer čvora senzora  WSN applications  Energy conservation  Ad-hoc routing  Basic principles  Overview of routing protocols  Data-centric protocols  Rumor Routing  Geographical protocols  Localization and Positioning  Synchronization and Security  The TinyOS operating system  The TinyDB query system  Proto programming language 79/105

80 Proto programming language 80/105  Proto: a high-level programming language used to program sensor and actuator networks  Proposed by Jonathan Bachrach and Jacob Beal  from the Massachusetts’ Institute of Technology Computer Science and Artificial Intelligence laboratory (MIT-CSAIL)  Paper: “Programming sensor networks as an amorphous medium” [7]

81 2 Proto programming language 2 81/105  The goals of the Proto language:  to relieve the programmer from worrying about the physical aspects of sensor network programming  the exact way of providing fast, efficient and robust communication between nodes is below the barrier of abstraction  instead, the programmer writes declarative code, such as  If the temperature is high, (sensor measurement)  Then, the field should be watered, every few hours (a command to actuators)

82 3 Proto programming language 3 82/105  In order to accomplish this,  the sensor network is imagined as an amorphous medium  Continuous field of calculable material  Sensed data in each sensor node is a point in the field  Dimensions and physical distribution of the points is not known  Each point in the amorphous field: executes the same code advertises its state to the immediate neighborhood Approximation of an amorphous medium

83 4 Proto programming language 4 83/105  Proto programs manipulate over fields  One field is a mapping scheme which assigns some value to a set of points in space

84 5 Proto programming language 5 84/105 Primitives in Proto can be:  terminals  operators common arithmetic operators, in prefix notation if operator  special primitives mux sense and act let and def

85 6 Proto programming language 6 85/105  Primitives can be combined into complex expressions  Besides the individual fields, field streams can be also used  When evaluating expressions with field streams, the result has to be calculated separately for each field from the stream  Therefore, the result is a field stream, too

86 7 Proto programming language 7 86/105  Terminals correspond to constants and they generate fields  For example, the terminal 2 generates a field with value 2 in every point  Operators calculate the output field using a set of input fields  for example, the expression + 2 5 generates a field with value 7 in every point  the if operator has standard meaning

87 8 Proto programming language 8 87/105  mux uses a selector field of booleans in order to generate a field in which for every point, one of two possible values is chosen: the value from the corresponding point in field #1, or, the value from the corresponding point in field #2.  this is performed for each point separately, with respect to the boolean value in the corresponding point in the selector field.

88 9 Proto programming language 9 88/105  sense and act represent the sensor readings and actuator commands, respectively.  They are analogous to, for example, read and write procedures in Pascal  In this way, Proto programs communicate with their environment.  let assigns a value to a variable  E.g. (let x 3)  def defines a procedure (a macro)  E.g. (def sq(x) (* x x))

89 1 Proto examples 1 89/105  Example (a): terminal 2 generates a field which has value 2 in every point (“2”)  Example (b): we add up the field “2” with field stream (“1”, “3”) the result is a field stream (“3”, “5”)

90 2 Proto examples 2 90/105  Example (c): input parameters are fields “2”, “3” and field stream (“false”, “true”)  As the selector is a field stream and not a field, the result will be a field stream too  One field from the result field stream corresponds to selector field “false”: that is field “3”  selector has semantics “do we choose the first field?”, and as it is false, we choose the 2nd  Second field corresponds to “true”; that is field “2”

91 3 Proto examples 3 91/105  Example (d): a complex operation  Firstly, terminals 2 and 5 generate fields “2” and “5”  Secondly, as a result of add operation the result field “7” is generated.

92 4 Proto examples 4 92/105  Example (e): definition of a procedure we define sq(x) as x*x  Example (f): terminal 3 generates field “3” as a result of a sq call, field “9” is generated  Proto code: (def sq(x) (* x x)) sq(3)

93 5 Proto examples 5 93/105  an input and output example: input – light is perceived output – a signalization light is emitted

94 6 Proto examples 6 94/105  the following code turns the red light emitter on each sensor where any light is perceived

95 Proto: reduce-nbrs 95/105  Proto also has primitives which enable it to describe behavior which depends not only on a single point in space (single sensor), but it’s immediate neighborhood, too  The neighborhood of a single point is an infinite number of points  Amorphous medium – continuous space! nbrs (x): neighborhood of point x

96 2 Proto: reduce-nbrs 2 96/105  The reduce-nbrs primitive summarizes the neighborhood of a single point  using some quantificator applicable to infinite sets  Proto has five such quantificators:  integral  forall  exists  limsup equivalent to max, for infinite sets  liminf equivalent to min, for infinite sets

97 3 Proto: reduce-nbrs 3 97/105  In this way, implicit communication between points is established  By aggregating the values in neighborhood of x, the points from the neighborhood communicate their value to x  Real-life communication has a delay  Proto simulates this delay using primitives delay and letfed

98 An example Proto application 98/105  the Threat Avoidance problem  If we have:  current coordinates,  a means for perceiving the danger (threat sensor)  a model of exponentially falling danger  how can we calculate the safest route?  Implementation in the nesC language (standard procedure language for sensor networks) ~ 2000 lines of code  Implementation in Proto: only 22 lines of code

99 2 An example Proto application 2  In order to test the threat avoidance program, a model is required  So, we describe a model with exponentially falling danger: 99/105

100 3 An example Proto application 3  Now, with regard to our current location, we can calculate the cumulative probability of survival 100/105

101 4 An example Proto application 4  Greedy-ascent procedure: in every point, the direction for next move is chosen in which the threat is best avoided 101/105

102 5 An example Proto application 5  By combining all these procedures, a complete solution for threat avoidance is obtained 102/105

103 6 An example Proto application 6  The results obtained when the threat avoidance program is run on a simulator 103/105 For more information, please consult [7] and [9].

104 References 104/105 [1] Thomas Hänselmann, Sensor Networks, 2006. [2] Jason Hill et al., System Architecture Directions for Networked Sensors, Department of EE/CS, UC Berkeley [3] Sam Madden, Joe Hellerstein, Wei Hong, TinyDB: In-Network Query Processing with TinyOS, UC Berkeley, 2003. [4] David Braginsky, Deborah Estrin, Rumor Routing in Sensor Networks, LECS-UCLA [5] Joe Polastre, Rachel Rubin, GeoMote: Geographical Network Architecture for Sensor Networks, CS Berkeley [6] Jeremy Elson, Time Synchronization in Wireless Sensor Networks, UCLA, 2003. [7] Jonathan Bachrach, Jacob Beal, Programming a Sensor Network as an Amorphous Medium, MIT-CSAIL, 2006. [8] Haowen Chan, Adrian Perrig, Security and Privacy in Sensor Networks, Carnegie Mellon University, 2003. [9] Jacob Beal, Continuous Semantics of Proto, MIT-CSAIL, 2006.

105 2 References 2 105/105 [10] Đ. Trifunović, N.Milanović, V.Milutinović, Ad-hoc Networks: Estabilishing node-to-node communication with no infrastructure needed, [11], USA, [12], USA, [13] M. Ilyas, I. Mahgoub (ed.), Handbook of Sensor Networks: Compact Wireless and Wired Sensing Systems, CRC Press, 2005. [14] I. Stojmenović (ed.), Handbook of Sensor Networks: Algorithms and Architectures, Wiley, 2004.

Download ppt "WIRELESS SENSOR NETWORKS ` Author: Aleksandar Crnjin, 00/17 Supervised by: Dr Veljko Milutinović,"

Similar presentations

Ads by Google