1. <month year>
doc.: IEEE
July 2007
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [Power Saving Algorithms for IEEE ]
Date Submitted: [July, 2007]
Source: [Tae Rim Park*, Myung Lee*, Jaehong Ryu**]
Company [*CUNY, **ETRI]
Address [Electrical Engineering, Steinman Hall, 140th St & Convent Ave, New York, NY 10031, USA]
Voice:[ ], FAX: [ ],
Re: []
Abstract: [This proposal discusses power saving issue arising in IEEE WPAN Mesh]
Purpose: [This proposal is provided for the discussion for IEEE WPAN Mesh]
Notice: This document has been prepared to assist the IEEE P It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P
Tae Rim Park
Tae Rim Park

2. Power Saving Algorithms
<month year>
doc.: IEEE
July 2007
Power Saving Algorithms
Tae Rim Park, Myung Lee, Jaehong Ryu
CUNY, ETRI
Tae Rim Park
Tae Rim Park

3. <month year>
doc.: IEEE
July 2007
Objectives
Providing background information to discuss power saving algorithms
To propose a power saving solution for the current IEEE draft.
Tae Rim Park
Tae Rim Park

4. Proposal Outline Design consideration Possible power saving algorithms
<month year>
doc.: IEEE
July 2007
Proposal Outline
Design consideration
Possible power saving algorithms
Algorithm comparison
Discussion
Summary
Tae Rim Park
Tae Rim Park

5. Design Consideration Mesh layer solution based on IEEE 802.15.4-2006
doc.: IEEE
July 2007
Design Consideration
Mesh layer solution based on IEEE
Supporting long battery life
Two AA batteries, 1year
Flexible active time
End-to-end latency constraint
Synchronous usually has longer latency
Considering receiver energy consumption
Tree relation
Easy implementation
Tae Rim Park

6. Long Battery Life Two AA batteries Energy consumption of cc2420
<month year>
doc.: IEEE
July 2007
Long Battery Life
Two AA batteries
2000 mA-hr
Energy consumption of cc2420
Tx; 17.4 mA
Rx; 19.7 mA
When a device turns on the transceiver
4.2 days
When the device keeps 5% active time
84 days (under 3 months)
 Minimizing active ratio is the key!
Tae Rim Park
Tae Rim Park

7. Mesh Layer Solution Two reasons Control methods Timing problem
<month year>
doc.: IEEE
July 2007
Mesh Layer Solution
Two reasons
Fine control
Minimize active time
Currently on the beacon mode the minimum value is ms
Reliable communication
Overcome possible problems of IEEE
Control methods
Standard primitive
MCPS-DATA/PURGE
MLME-SET/GET
Can not use information inside MAC
Can not add MAC control frames
Timing problem
Can not guarantee response time
Ex. The time from calling MCPS-DATA.request to starting backoff
Tae Rim Park
Tae Rim Park

8. Possible Algorithms On beacon mode On non-beacon mode
<month year>
doc.: IEEE
July 2007
Possible Algorithms
On beacon mode
Non-beacon Tracking (NBT)
Beacon Tracking (BT)
On non-beacon mode
Long Preamble Emulation (LPE); BMAC
Long Preamble Emulation with Ack (LPEA); XMAC
Non-beacon Tracking Emulation (NTE)
Global Synchronization (GS); SMAC
Tae Rim Park
Tae Rim Park

9. Algorithms on Beacon Mode
<month year>
doc.: IEEE
July 2007
Algorithms on Beacon Mode
Reliability, Beacon collision
Upper control also required
Tae Rim Park
Tae Rim Park

10. Synchronous Algorithm on Non-Beacon
<month year>
doc.: IEEE
July 2007
Synchronous Algorithm on Non-Beacon
SMAC
Time control precision
Difficult to synchronize all devices
Tae Rim Park
Tae Rim Park

11. Asynchronous on Non-beacon Mode
doc.: IEEE
July 2007
Asynchronous on Non-beacon Mode
LPE
LPEA
NTE
Tae Rim Park

12. Beacon vs. Non-beacon Mode
<month year>
doc.: IEEE
July 2007
Beacon vs. Non-beacon Mode
Beacon mode
Suitable for the networks
Long beacon interval & small number of neighbors
Hard time beacon transmission  beacon collision
Unreliable
NBT; beacon collision
BT; Sync tree problem
Upper layer support for
Active time scheduling, minimizing active time, broadcasting frames
Non-beacon mode
Requires all operation at the mesh layer
Difficulty in timing control
Flexible !, can make better solutions for large scale networks
Tae Rim Park
Tae Rim Park

13. Synchronous vs. Asynchronous
<month year>
doc.: IEEE
July 2007
Synchronous vs. Asynchronous
Synchronous
Ideal for broadcasting (RREQ in AODV)
Requires overhead to synchronize devices
Relatively long active duration
Control packet overhead
Requires tight frame control
Usually longer latency
Asynchronous
Easy to implement
Ethernet vs. Token ring, TCP vs. ATM, DCF vs. PCF
Can have minimum active duration (BMAC emulation); longest battery life
Loose frame control
Tae Rim Park
Tae Rim Park

14. Discussion Rebroadcasting in 15.5 Protocol issues (out of scope?)
doc.: IEEE
July 2007
Discussion
Rebroadcasting in 15.5
Two hop broadcasting with n neighbor
n+1 for transmission
n(n+1) for reception
n=316, n=536
Protocol issues (out of scope?)
Association procedure and time
Mesh layer backoff
Active duration adjustment
Distributed wakeup interval selection
Local synchronization
Tae Rim Park

15. Summary To get long battery life Mesh layer solution
<month year>
doc.: IEEE
July 2007
Summary
To get long battery life
Minimizing active time
Accepting trade off relation
Mesh layer solution
With only standard primitives
Asynchronous algorithms is better to implement
Asynchronous algorithms have similar behaviors
Non-beacon Tracking Emulation (NTE)
Can have flexible active duration
Tae Rim Park
Tae Rim Park