Efficient Handling of WiFi Broadcast Traffic in Smartphone Suspend Mode

Slide Note
Embed
Share

Exploring the dilemma of managing WiFi broadcast traffic in smartphone suspend mode through methods like "receive-all" and "receive-none", this study discusses the power impact and efficiency of different approaches. It evaluates the balance between power consumption and functionality, highlighting challenges and solutions in dealing with broadcast frames during device suspension.


Uploaded on Sep 29, 2024 | 0 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

E N D

Presentation Transcript


  1. All or None? The Dilemma of Handling WiFi Broadcast Traffic in Smartphone Suspend Mode Ge Peng, Gang Zhou, David T. Nguyen, Xin Qi

  2. Smartphone power modes Active Suspend Power consumption: high Power consumption: low switch to suspend mode to save energy 2

  3. Suspend mode is interrupted What are the interrupts? pressing the power button application background synchronization ... WiFi broadcast frames How big is the energy impact? How to deal with them efficiently? switch to high power active mode Power consumption increases 3

  4. Handling WiFi broadcast traffic Galaxy S4 Galaxy Nexus HTC Hero Nexus One 4

  5. receive-all HTC Hero and Nexus One: receive-all Receive all UDP broadcast frames during suspend mode Trigger a wake lock of 1 second for every data frame received MAC layer broadcast frames with UDP payload 5 resume suspend

  6. Power Impact of receive-all Power (mW) Number of UDP broadcast frames/s The receive-all method suffers higher power consumption. 6

  7. receive-none Galaxy Nexus and Galaxy S4: receive-none Block all UDP broadcast frames with a hardware filter Power (mW) Number of UDP broadcast frames/s 7

  8. Problem of receive-none The receive-none method blindly blocks all UDP broadcast frames during smartphone suspend mode Applications cannot receive broadcast frames. What are missed? 8

  9. Broadcast traffic in real world 4 traces are collected in a college department, a college library, a classroom building, and an off-campus Starbucks store, respectively. Is anyone here? The receive none method sacrifices functionality. 9

  10. The Dilemma How to deal with WiFi broadcast traffic during smartphone suspend mode? receive-all : suffers higher power consumption receive-none : sacrifices functionality Binary Choice: All or None? 10

  11. Software Broadcast Filter (SBF) Useless broadcast broadcast Useful broadcast frames frames frames UDP broadcast frames with a UDP port not listened on by any process on the smartphone 11

  12. Software Broadcast Filter (SBF) 12

  13. SBF Energy Efficiency Energy Modeling Trace driven simulation Compare energy consumption of SBF to receive-all method oracle lower bound assume that SBF has the information of future frame arrival time. So, it can decide not to go back to suspend when the overhead is bigger than benefit. 13

  14. SBF Energy Efficiency SBF energy saving Oracle energy saving left: receive-all middle: SBF right : oracle lower bound 14

  15. SBF Delay Overhead To measure the local processing delay Implement the work flow of SBF on Nexus One Create 100 UDP sockets on the smartphone Send 1000 UDP broadcast frames to the local network 15

  16. SBF Delay Overhead SBF introduces an increase of 1.07% in local processing delay. 16

  17. Conclusion Reveal the dilemma of handling WiFi broadcast traffic during smartphone suspend mode receive-all : suffers high power consumption receive-none : sacrifices functionality Propose Software Broadcast Filter (SBF) to address the dilemma SBF only blocks useless broadcast frames SBF reduces power consumption by up to 52.3% with an increase of only 1.07% in local processing delay 17

  18. Thank You! Questions?

Related


More Related Content