1 / 39

# SensorBaysianGlobal - PowerPoint PPT Presentation

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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

## PowerPoint Slideshow about ' SensorBaysianGlobal' - sutton

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

### SensorBaysianGlobal

Alfredo Garcia

Enrique Campos-Nanez

Matt Spear

• The Algorithm: A Quick Overview

• The Simulator: Structure

• The Simulator: Examples

• The Messages

• An Alternative formulation of the algorithm

• 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)

• Decide the best course of action given the probability that a neighbor node is on

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.

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

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

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;

}

Me.isOn = BR();

if(Me.isOn)

Me.l = T/(T+1) · Me.l + 1/(T+1);

else

Me.l = T/(T+!) · Me.l;

}

}

State BR() {

COST = 1/(|Neighbors|);

probMeCovered = 1 – Õ(Node n 2 Neighbors)(1 – n.l);

if(COST – 1 > -1 · probMeCovered)

returnOFF;

else

returnON;

}

• 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)

• Node.java maintains:

• int id The unique ID for the node

• double x, y, z The position in R3

• 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

• 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

• 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 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 amount of change for the sensor 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 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.

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

The Simulator: Output

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

The Simulator: Output

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

The Simulator: Output

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

The Simulator: Output

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

The Simulator: Output

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

The Simulator: Output

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

The Simulator: Output

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

The Simulator: Output

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

• Defined five messages for the algorithm:

• PING (1 byte)

• Discovery packet

• PONG (5 bytes)

• STATE_REQUEST (5 bytes)

• A request for the states of the neighbors

• A reply to a state request

• QUIT (Not used)

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

Grid: 72

Grid: 102

Random: 50

Random: 500

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}

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*

Grid: 72, M = 2

Grid: 102, M = 2

Grid: 102, M = 3

Grid: 102, M = 3

Random: 50, M = 2

Random: 500, M = 4

• 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.