Etiquette protocol for Ultra Low Power Operation in Sensor Networks Samir Goel and Tomasz Imielinski {gsamir, imielins}@cs.rutgers.edu DataMan Lab, Department of Computer Science Acknowledgement: Prof. Roy Yates helped in shaping some of the core ideas
35
Embed
Etiquette protocol for Ultra Low Power Operation in Sensor … · 2005-01-27 · Etiquette protocol for Ultra Low Power Operation in Sensor Networks Samir Goel and Tomasz Imielinski
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Etiquette protocol for Ultra Low Power Operation in Sensor Networks
Samir Goel and Tomasz Imielinski{gsamir, imielins}@cs.rutgers.edu
DataMan Lab,Department of Computer Science
Acknowledgement: Prof. Roy Yates helped in shaping someof the core ideas
ProblemSensor nodes operate on battery with limited energy (Life: 48 hrs with Energizer CR2450 battery[Hill00])
Numerous applications require network lifetime of months/years
Example: In Great Duck Island project, sensor nodes were configured to transmit once every 5 mins
It would take 24000 motes to produce an average load of 19.2 kbps (pkt size = 30 bytes)
Tolerance for higher delay (100s msecs)Example: In Great Duck Island project, tolerance of a few seconds per-hop communication delay would be acceptable
Requires multi-hop sensor network
Problem: Idle Listening
Radio is the major consumer of energy in a sensor nodeMica Motes [Ye02]:
Transmit Power : 0.024 WReceive Power : 0.013 WIdle listening (radio is ON but IDLE) : 0.013 W
0
20
40
60
80
100
0 50 100 150 200
# transmissions/minute
% e
nerg
y sp
ent i
nid
le li
sten
ing
Energy consumed in idle listeningdominates all other costs
Example:Mote transmitting 1 pkt/min:
Idle listening: 99.94%
Pkt Size: 50 bytes, b/w: 19.2 KbpsRadio Always ON
Related Work
IEEE 802.11-like protocolPower Saving Mode only works for one-hop network
IEEE 802.15.4Defines PHY and MAC layer for low rate Personal Area NetworkPower saving mode not defined for peer-to-peer communication topology
S-MAC (Ye02) “Day and night” protocol: Synchronized Active and Sleep statesFixed duty cycle (solved in T-MAC (Dam03))Synchronization messages constitute significant overheadTraffic concentrated in the active part
…
Active SleepActive
Sleep Active Sleep
Etiquette Protocol
Basic Idea::Teaching Assistant Analogy
Nodes hold office hours at regular intervalsAccept request for appointments from neighbors
Nodes select their office hours independently
Office hr Office hr
Office Hour Announcement Time
Basic Idea ::Teaching Assistant Analogy, cont’d…
Communicating data:During office hours, neighbor requests an appointment Node responds with Grant-request (or, Deny-request)Perform communication at appointed time
For a receiver, radio needs to be ON only during office hours and appointment
Appt Request Grant-Request
Office hrAppointment
Time
How to determine Office Hours of a node?
Network property (invariant)::Toff-period ≤ Toff-max (Toff-max is a pre-defined constant)
Office Hour Announcement specifies:Duration of office hoursPeriod
Determining office hours involves scanning the channel for at most a known maximum period, Toff-max
Office hours Period (Toff-period) Office hr duration
Office Hour Announcement Time
Nodes holding office hours
Office hrNode A
Time
Node B
Office HourAnnouncement
Interaction
Node A
Time
Node B
Office hr
Has packetfor B
Channel Scan
Found officehours of B
Interaction
Node A
Time
Node B
Office hr
Has packetfor B
SendAppt Request
SendGrant-Request
AppointmentChannel Scan
Why do we expect to save energy?
Relative size of various overheads:(Office hour period: in secs)
Office hour duration : in 100s of msecs
Appointment request Pkt : in 10s of msecs
Appointment grant Pkt : in 10s of msecs
Small fraction ofOffice hour period
Radio can be turned OFF rest of the time⇒ Reduction in idle listening more than compensates
for the overhead
Why do we expect to save energy?
Relative size of various overheads:(Office hour period: in secs)
Office hour duration : in 100s of msecs
Appointment request Pkt : in 10s of msecs
Appointment grant Pkt : in 10s of msecs
Small fraction ofOffice hour period
Channel Scanning Time (Tscan) :E[Tscan ] = Toff-period/2Significant energy drain
How to reduce energy consumed in scanning?
Node sends blurbs at regular intervalsBlurb: Small message indicating the next start time for office hours
Using blurbs to reduce channel scanning time
Node A
Time
Node B
Office hr
Has packetfor B
Blurb
Found officehours of B
Channel Scan
Using blurbs to reduce channel scanning time
Node A
Time
Node B
Office hr
Has packetfor B
SendAppt Request
SendGrant-Request
AppointmentChannel Scan
Blurb
Scanning Cost: Analysis
Cost of transmitting a blurb is very smallRadio time of ~10 msecs
Savings:In general, ‘n’ blurbs can reduce E[Tscan ] by (n+1)
As ‘n’ becomes large, the cost of transmitting blurbs may out-weigh the savings
Optimal ‘n’:1
2* −=
blurb
recvoff
JJKT
n
We show that anode can estimaten* using local info
Important CharacteristicsEnergy versus latency tradeoff
Energy ∝ 1/office hour periodPer-hop latency ∝ office hour period
PHYMAC
EtiquetteNetworkTransport
Onus of communication is on the senderEnergy consumption proportional to number of packet transmissions
Fine clock synchronization not requiredAll times are relativeGuard-bands are used to take care of clock-drifts
Typical clock drift: ±0.2 msecs per sec [Ye02]
Etiquette: A Link-layer protocol:Controls radio ON/OFF schedule at macro-levelMAC layer still handles the micro-level issues(e.g., channel contention)
Performance Analysis
Simulation Setup
Protocols Compared:S-MAC:
duty cycle: 5% to 50%Etiquette:
office hour period: 10 sec and 20 secIDEAL-802.11: IEEE 802.11 DCF with cost of idle-listening set to 0
Scenario: Homogeneous Traffic [Rajendran03, Dam03]::A node sends each packet to a randomly selected neighbor
EtiquettePerformance for two different office hour periods is identicalGraceful performance degradationAt low load, packet delivery ratio suffers because of higher traffic
Energy Efficiency
Graph truncated when corresponding pkt delivery ratio falls below 70%
Characteristics:Etiquette performs much better than S-MAC at low loadEnergy/bit reduces with increase in office hours period
Average Queuing Delay
Etiquette:Queuing delay in Etiquette stays constantFunction of office hour period
S-MAC:Queuing delay sky-rockets when capacity is reached
Etiquette: Recap
Simple, intuitive protocol
Energy consumption proportional to the number of packet transmissions
Ability to handle fluctuations in traffic load
Allows trading latency for energy
Comments/Questions?
More info:http://www.cs.rutgers.edu/~gsamir/
Additional Slides
S-MACSynchronized listen/sleep state
Listen is split into two parts: SYNC, RTS/CTS
Listen Listen ListenSleep Sleep
Receiver
Listen
Sleepfor SYNC for RTS for CTS
Sender 1
Sender 2
CS
Tx SYNC
CS
Tx RTS Got CTSSend data
Sleep
Listen Listen ListenSleep Sleep
Node A
Node B
T-MAC
Improves S-MACAdaptive duty cycle: (L fixed at 600 msecs)
A node is in active mode until no activation event occurs for time TA
Periodic frame timer event, receive, carrier sense, send-done, knowledge about end of other transmissions