SensorBaysianGlobal

SensorBaysianGlobal Alfredo Garcia Enrique Campos-Nanez Matt Spear

Agenda • The Algorithm: A Quick Overview • The Simulator: Structure • The Simulator: Examples • The Messages • An Alternative formulation of the algorithm

The Algorithm: Definitions • A node is covered iff it or one of its neighbors is ON • lis the probability that a node will be ON • A node is ON iff it is sensing • For now we assume that a nodes communication radius is the same as its sensor radius. • Nodes are static and have a position in R3 • Nodes have a list of their neighbors • Turning ON has a COST · 1/(|Neighbors|) • A Node has two functions: • Update • For each neighbor update the information (l and the state of said node) • BR (Best reply) • Decide the best course of action given the probability that a neighbor node is on

The Algorithm: General Formulation If sensors could see all other sensors, they will choose their actions to solve a common payoff function. This way sensor i, will choose its action ai = {0, 1} to solve the optimization problem: maxUai(ai, a-i) = åj=1N(1{sensor j covered under (ai, a-i)} – c · aj) With c < 1, the cost of a Node turning on.

The Algorithm: Local Formulation Let N(i) = {j | j can cover i}, i.e. the neighbors of i, and let N(i) = N(i) [ {i}. Sensor i’s view of the problem is to choose between the action ON, or OFF. To select its best action given an action profile a−i for the other sensors, sensor i can compare U(1, a-i) – U(0, a-i) = |N(i)| - c – Ki(0, a-i) Where Ki(0, a-i) = åj 2 N(i)(1{sensor j covered under action profile}) • Notes: • Ki(0, a-i) is simply the number of Nodes that can cover i if i is OFF • All information can be computed locally

The Algorithm: l Sensor i keeps track of an empirical frequency (l) for each neighbor where: l(a-i) = (Iterations in which a-i was used) / (Total iterations) With l the best reply is selected by comparing: E[U(1, a-i)] - E[U(0, a-i)] And this expectation is taken with respect to l

The Algorithm: Update Update() { foreach(Node n 2Neighbors) { n.isOn = IsNeighborOn(n); if(n.isOn) n.l = T/(T+1) · n.l + 1/(T+1); else n.l = T/(T+!) · n.l; } if(received reply from all neighbors) { Me.isOn = BR(); if(Me.isOn) Me.l = T/(T+1) · Me.l + 1/(T+1); else Me.l = T/(T+!) · Me.l; } }

The Algorithm: BR State BR() { COST = 1/(|Neighbors|); probMeCovered = 1 – Õ(Node n 2 Neighbors)(1 – n.l); if(COST – 1 > -1 · probMeCovered) returnOFF; else returnON; }

The Simulator • Main goal was to make it extensible and to implement the algorithm we were testing, the following is our framework. • Five main classes: • Node.java • Abstract, subclasses must override Update() • Represents the information of a Node • SBGNode.java • The implementation of the Node that uses this algorithm • Communicator.java • Static class that allows a Node to send a message to its neighbors (those within its communication radius) • Simulator.java • Abstract, subclasses must override Update(int numSteps) • SBGSimulator.java • The implementation of our simulator. • SimGUI.java • The GUI for the simulator (only allows visualization of nodes in R2)

The Simulator: Node • Node.java maintains: • int id The unique ID for the node • double x, y, z The position in R3 • double sensorRadius The sensor radius • double commRadius The communication radius • boolean on If the node is ON • ArrayList neighbors The set of neighbors • int myTime The local time • ArrayList messages The queue of messages • double batteryLife The percentage of battery left • SBGNode.java also maintains: • double cost The cost of turning on • double lambda The l • int countOfNodes The number of Nodes that have responded

The Simulator: Simulator • Simulator.java maintains/implements: • static int time The actual time • static ArrayList nodes The set of nodes to simulate • static int maxTime The maximum time to run • double width, height, depth The volume the nodes are in • boolean isNeighbors(Node a, Node b) True if a is within b’s comm. radius • int numberOn() The number of Nodes that are ON • int numberOff() The number of Nodes that are OFF • SBGSimulator.java simply implements: • Update(int numSteps) Runs the simulation numSteps • int numberCovered() The number of covered Nodes

The Simulator: Communication • Communication is broadcast to all Nodes in the initiator’s communication radius • Messages are a byte array and a timestamp of when they are sent (used to determine which Messages are available to a Node and which have not reached it, i.e. as the Simulator is synchronous “later” Nodes receive message for the current time but these would actually not be seen until the next time step in an asynchronous environment so they should be ignored) • Communicator.java adds the Message to a Node’s Message queue • Will explain Messages we defined later.

The Simulator: GUI • The dialog box to create a new simulation. Specify: • Width • Height • Location to save the CSV output to • Location to save the sequence of images to (as png) • The number of nodes • The sensor radius • The amount of change for the sensor radius • The communication radius • The amount of change for the communication radius • The maximum simulation time • Whether to draw images • Whether to draw the comm. radius • Whether to draw the sensor radius (if the Node is on) • Grid drop (rounds number of nodes as needed) or randomly dropped

The Simulator: GUI The simulator with a grid, 31x31 size, sensor radius only. The simulator with random, 31x31 size, comm. and sensor radius. The simulator draws Nodes as circles, green denoting ON and red denoting off, yellow for the sensor radius, blue for the comm. radius, all colors are alpha-blended; clicking run runs the simulation until max time is reached.

The Simulator: Output Grid: 143 nodes, 31x31, c.r = s.r = 3.0, c.r.D = s.r.D = 0.0

The Simulator: Output The Simulator: Output Grid: 143 nodes, 31x31, c.r = s.r = 3.0, c.r.D = s.r.D = 0.0

The Simulator: Output The Simulator: Output Random: 150 nodes, 31x31, c.r = s.r = 3.0, c.r.D = s.r.D = 0.0

The Simulator: Output The Simulator: Output Random: 1500 nodes, 31x31, c.r = s.r = 1.5, c.r.D = s.r.D = 0.0

The Messages • Defined five messages for the algorithm: • PING (1 byte) • Discovery packet • PONG (5 bytes) • Reply to a ping • STATE_REQUEST (5 bytes) • A request for the states of the neighbors • STATE_REPLY (6 bytes) • A reply to a state request • QUIT (Not used)

Alternative Algorithm: Compact Rep A key note is that the difference: E[U(1, a-i)] - E[U(0, a-i)] = |N(i)| - c - åa-i[å{j 2N(i)}(Ki(0, a-i) )] · l(a-i) Can be computed with local information. This can be achieved if sensor i maintains: l(k) = (Iterations in which k nodes were covered) / (Total iterations) With this representation i will choose to be ON if the difference E[U(1, a-i)] - E[U(0, a-i)] = |N(i)| - c - åk = 0|N(i)|[k · l(k)] > 0

Alternative Algorithm: Example Grid: 72

Alternative Algorithm: Example Grid: 102

Alternative Algorithm: Example Random: 50

Alternative Algorithm: Example Random: 500

Alternative Algorithm: Duty Cycles Suppose we want to build M partitions of the sensors such that the nodes in each partition can cover all other nodes, and that energy consumption is minimized. This can be used to build fixed time duty cycles (as in ASCENT), where nodes in each partition alternate their ON and OFF states. Instead of selecting an action ai2 {0, 1}, we can model the game as sensor i choosing which partition to join, i.e. ai2 {0, 1, . . . ,M}. The overall utility can be written as: U(a) = åi = 1N[åm = 1M(1{i covered in partition m under action profile})] – c · 1{ai ¹ 0}

Alternative Algorithm: Duty Cycles Similar to our prior analysis, sensor i can decide which partition, if any, to join using only local information, namely, the number of covered sensors in the neighborhood on each partition. Given an action profile a−i, sensor i can compare between actions m, m’ > 0 by looking at the difference: U(m, a-i) – U(m’, a-i) = Kim(0, a-i) – Kim’(0, a-i) Where Kim(0, a-i) is the number of sensors in the neighborhood N(i) covered under partition m. Let m* = argminm = 1, …, M[Kim*(0, a-i)], then i should choose to join m* if |N(i)| - c - Kim*(0, a-i) > 0 I.e. if it is economical to turn on given the coverage in partition m*

Duty Cycles: Example Grid: 72, M = 2

Duty Cycles: Example Random: 50, M = 2

Duty Cycles: Example Random: 500, M = 4

Work In Progress • A better coverage test. Verify that all of a sensor’s radius of action is covered (Voronoi test). • Adaptive partitioning. Suppose that the number of partitions depends on recharge (solar) ability • Convergence to Endogenous Correlated Equilibria. since the localized versions of the algorithm shown here are equivalent to the global game (with sensors accessing all available information), we speculate that a minor revision of Garcia’s et al (2005) will show convergence to ECE’s.

Questions?

SensorBaysianGlobal

SensorBaysianGlobal

Presentation Transcript