TOWARDS ENERGY EFFICIENT VOIP OVER WIRELESS LANS VINOD NAMBOODIRI, LIXIN GAO. ACM MOBIHOC Youngbin Im

CONTENTS Introduction Background GreenCall algorithm Evaluation through commodity HW/SW Simulation Conclusion 2/21

INTRODUCTION Emergence of dual mode phone/devices like Apple iPhone and RIM Blackberry  Voice of IP(VoIP) calls over WLANs became a common option Driving factors of the shift to dual mode Cost effectiveness Lack of coverage of cellular networks 3/21

INTRODUCTION Limitation Energy consumption of WLAN interface can be significant Ex) iPhone 14 hours’ talk time with WLAN off 8 hours with both interfaces on 6 hours with web browsing and access of once every hour Reducing the energy consumed during VoIP calls is a critical step towards extending the operating lifetime of these mobile devices. Battery capacity1000mAh Talk time255 min Stand-by time210~340 hours Battery capacity1300mAh Talk time190 min Stand-by time40 hour 4/21

INTRODUCTION Difficulties of energy reduction during VoIP Short tolerable latencies Order of hundreds of ms Short packet generation intervals Order of tens of ms In this paper Address the issue of how to reduce energy consumption of the WLAN interface during a VoIP call While preserving the quality within acceptable levels 5/21

BACKGROUND Key idea of saving energy of wireless interface Allow sleep as much as possible reducing the time in idle  but, the radio may not know when it has to wake up to receive packets E. Shih, P. Bahl and M. J. Sinclair. Wake on Wireless: An Event-Driven Energy Saving Strategy for Battery Operated Devices. MOBICOM /21

BACKGROUND Power Save Mode(PSM) in for infrastructure WLANs A node transition to sleep state when it is not actively sending/receiving by notifying AP with PS-Bit AP buffers packets for sleeping nodes Announces frames buffered by TIM(traffic indication map) sent with every beacon Power Saving stations wake up periodically listen for Beacons If TIM indicates frame buffered station sends PS-Poll and stays awake to receive data After receiving all, goes to sleep else station sleeps again If don’t want PSM anymore, sets the PS-Bit off 7/21

BACKGROUND VoIP scenario on WLAN interface Client / peer Playout deadline For precise sleep/wakeup scheduling we should consider latencies 8/21

BACKGROUND 9/21

GREENCALL ALGORITHM Approach Trade-off the possibility of some packet loss by introducing a parameter LR (the tolerable loss rate of the application) That is, seek a sleep schedule that maximizes energy savings while targeting a loss rate no greater than LR Three steps to calculate sleep periods Determine playout deadlines of each arriving packet Estimate times at which packets would have been received at the client if it never used PSM Calculate sleep period for future packets 10/21

GREENCALL ALGORITHM Calculation of playout deadlines generation sending arriving deadline peerclient Internet estimated network latency estimated wireless latency client’s AP whereIs the constant tolerable latency of all packets Is the constant encoding and packetization delay whereis the constant packet generation interval m is the sequence number 11/21

GREENCALL ALGORITHM Estimation of times at which packets would have been received without PSM arriving deadline client pseudo spare time : difference b/w playout time and arrival time minus : the time required to decode and play out a packet We should find the actual spare time (difference b/w playout deadline/receive time w/o PSM) Approach : add the possible buffering delay to its observed spare time Observation : the first packet buffered during a sleep period incurs the maximum delay among all packets in the AP buffer Minimum buffering delay Estimate of the actual spare time(becomes upper bound on actual spare times of all packets) client’s AP start of buffering start of sleep end of sleep, request for packet end of buffering arrival of first packet arrival of first buffered packet : last used sleep period 12/21

GREENCALL ALGORITHM Calculation of sleep period for future packets Estimate the actual spare times of packets arriving in the future Use the minimum of last H spare times as an estimator where H is chosen large enough to ensure that the spare time of the first arrived packet during last sleep is considered Calculate sleep period Adapt the window H to control the loss rate 13/21

GREENCALL ALGORITHM Example (arrival at AP) (delay b/w AP & client) (arrival at client) (playout deadline) (previous sleep period) (actual spare time) (next sleep period) (decoding time) (packet generation interval) 14/21

GREENCALL ALGORITHM 15/21

EVALUATION Experiment setup A laptop running Linux with Intel PRO2200 adapter connected to an g AP Emulate traffic with parameters derived from typical VoIP calls to provide flexibility & repeatability Continuously exchange UDP packets of 160 bytes Traffic generating interval was 30ms or 60ms Silence-suppression using recommendations of ITU-T for generating artificial conversations 12 minute conversation (average length of VoIP sessions) Parameters 250 ms tolerable latency, 2% tolerable loss rate Initial H=100, H min =100, H max =1000, C interval =500, C incf =1.25, C decf =0.80 Only used sleep period of 100 ms due to the standard which states that sleep periods be specified as multiple of AP’s beacon interval 16/21

EVALUATION Result Higher energy savings without silence suppression GreenCall allows more energy to be saved when more packets are actually being sent No packet loss Static sleep periods still left plenty of spare time 17/21

SIMULATION To study the possible energy savings achievable if the sleep period was fully configurable Run GreenCall over multiple actual traces using a custom built simulator Similar parameter values Power consumption values were obtained from spec 18/21

SIMULATION Energy savings under different settings Default : no silence suppression, 30 ms packet generation interval, peer doesn’t run GreenCall 19/21

CONCLUSION Presented the GreenCall algorithm that leverages the IEEE PSM mode to save energy while ensuring that application quality is preserved. Through experiments and trace-based simulations over diverse Internet paths, showed the utility of GreenCall 20/21

APPENDIX : PSM 21/21