Design and Evaluation of Power Management Support for UPnP Devices

1. Design and Evaluation of Power Management Support for UPnP Devices Jakob Klamra and Martin Olsson Department of Communication Systems Lund Institute of Technology Lund, SWEDEN Masters Defense – June 7, 2005 (Tampa, Florida)

2. Acknowledgments • Thanks to: • Dr. Christensen, USF • Dr. Nyberg, LTH • Dr. Labrador and Dr. Rundus, USF • Bruce Nordman, LBNL • Chamara Gunaratne, USF

3. Topics • Introduction • Analysis • Design • Implementation • Validation • Energy Savings Estimate • Conclusions and Future Work

4. Introduction • Problem: increased energy use by IT equipment • More devices in US households • IT equipment use 280 kWh/year per US household • Adds up to $2240 million • Problem: IT equipment always on, even when idle • Required by some protocols • Universal Plug and Play (UPnP) has this problem • Our work solves the problem for UPnP • Investigate the use of a power management proxy

5. Introduction continued • UPnP is for automatic device configuration • Network analogy of Microsoft plug-and-play • Control points and services • Discovery, eventing and control • Standardized by UPnP Forum • More than 700 vendors, Microsoft, Intel, Nokia • UPnP uses Simple Service Discovery Protocol • SSDP is the key issue

6. SSDP:discover Service HTTP OK Service SSDP:discover HTTP OK Control Point SSDP:discover HTTP OK Service Introduction continued • SSDP – message exchange • Discovery SSDP:discover • Answered by HTTP OK

7. Service SSDP:alive Service SSDP:alive Control Point SSDP:alive Service Introduction continued • SSDP – message exchange (continued) • Notification SSDP:alive • Sent out periodically

8. Introduction continued • UPnP foundation, the stack Eventing and control use TCP UPnP Vendor Specific SSDP use UDP Our work is done here UPnP Forum Specific UPnP Device Architecture SOAP HTTP-MU HTTP-U HTTP SSDP GENA SSDP GENA TCP UDP IP

9. Analysis • Requirements for power management solutions: • R1 – Enable UPnP devices to enter power sleep • R2 - Not interfere with existing UPnP functionality • R3 - Be robust • R4 - Work for wired and wireless • R5 - Handle many devices • R6 - Be possible for us to implement

10. 4. Service powered up Proxy Control Point 3. Wake up Analysis continued New • Low power proxy • Acts (answers and speaks) for sleeping devices • Wakes up sleeping devices when they are needed SLEEP 1. Service in power sleep 2. Request for service Service

11. Analysis continued • Possible solutions to UPnP power management • Three categories: • Centralized proxy, no change to devices • Invisible proxy • Centralized proxy, minor change to devices • Cooperating proxy • No proxy, major change to devices • Proxying NICs

12. Design • Selection of the solutions • All requirements must be fulfilled • Desirable properties • As much power sleep as possible • As little configuration as possible • As little changes to UPnP protocol as possible • … • Our design decision • Invisible proxy • Cooperating proxy

13. Design continued • Design of invisible proxy SSDP:discover Timeout ST = Printer TCP SYN (Spoofed) HTTP OK ST=Printer start proxy Control point Proxy TCP SYN ACK Wake On Lan Forward TCP SYN SLEEP Service

14. Design continued • Invisible proxy FSM CHECK PROXY CACHE DISCOVERY P3 LISTENING P1 PROXY DEVICE P2 P12 Timeout P23 SSDP:discover P32b S in proxy cache Discovery answer CHECK PROXY CACHE TCP P4 P24 TCP from CP WAIT FOR ALIVE P5 P45 S in proxy cache WOL to S P51a SSDP:alive from S P55 Timeout Forward packet from CP CP = Control point, S = Service, WOL = Wake On Lan

15. Design continued • Design of cooperating proxy Control point Proxy SSDP:discover ST = Printer HTTP OK (Spoofed) ST=Printer TCP SYN HTTP OK TCP SYN ACK ForwardTCP SYN Wake On Lan GENA Powermgmt = SLEEP GENA Powermgmt = POWER SLEEP Service

16. Design continued CHECK PROXY CACHE DISCOVERY P3 • Cooperating proxy FSM PROXY DEVICE P2 LISTENING P1 P12 GENA, Power mgmt=SLEEP HTTP OK P23 SSDP:discover P32a S in proxy cache Discovery answer CHECK PROXY CACHE TCP P4 P51a GENA, Power mgmt=POWER HTTP OK Forward packet from CP P24 TCP from CP FORWARD PACKET P5 P51a GENA Power mgmt=POWER HTTP OK, Forward packet from CP P45 S in proxy cache WOL to S CP = Control point, S = Service, WOL = Wake On Lan

17. Implementation • Development Tools • Programming environment • Dev-C++ • Packet handling routines • NETWIB libraries • Packet capture and decoding • Ethereal • UPnP device toolkit • Intel software for UPnP technologies

18. UPnP Device UPnP Device UPnP Device UPnP Device UPnP Device UPnP Device UPnP Device UPnP Device Implementation continued • Data structure for proxies Device Cache All devices on the network Proxy Cache All devices proxy is answering for

19. Implementation continued Service Service Service Service

20. Check Proxy Cache Check Proxy Cache Check devices in Device Cache Check devices in Device Cache Sniff packets Sniff packets If needed send SSDP:alive If needed send SSDP:alive Process packets Process packets Update Proxy Cache Update Proxy Cache Send answer and update caches Send answer and update caches Implementation continued • Implementation of invisible proxy Main thread Discover devices and build cache Notification Notification Start threads Proxy cache update Proxy cache update Main loop Main loop

21. Read and parse incoming events Read and parse incoming events Check Device cache Check Device cache Check Proxy cache Check Proxy cache Sniff packets Sniff packets Update Proxy cache Update Proxy cache Process packets Process packets Update Device cache Update Device cache Send SSDP:alive Send SSDP:alive Answer and update caches Answer and update caches Implementation continued • Implementation of cooperating proxy Main Thread Read event socket Read event socket Discover power management services and build cache Start threads Cache update Cache update Notification Notification Main loop Main loop

22. Validation • Validation – design and implementation must meet requirements • Known shortcomings • TCP forwarding not implemented • Cannot detect crashed devices • Test cases • 7 tests for each solution • 3 tests not executed because lack of equipment

23. Validation continued • Validation of invisible proxy • 1 test passed • 3 partially failed • No unexpected behavior • Validation of cooperating proxy • 2 tests passed • 2 partially failed • No unexpected behavior

24. Energy saving estimation • Estimates made for US residential IT equipment • Estimates made for: • Stock, power consumption, usage patterns • Calculations made for: • Total energy and economic savings in 2008 • Estimates from work by Energy Analysis Program atLawrence Berkley National Laboratory • Bruce Nordman

25. Device Devices 2008 Network Connected devices 2008 Devices 2001 Notebooks 17.3 44.7 42.4 Desktops 67.9 89.3 82.8 Inkjets 54.9 107 102 Laser printers 6.3 11.9 11.3 Energy saving estimation continued • Background, stocks (all figures are in million)

26. Savings in million dollars per year 71 285 Energy saving estimation continued • Results Savings in GWh/year Low estimation 5% 890 High estimation 20% 3560 (8 cents/kWh)

27. Conclusions and future work • Conclusions • Power management in UPnP achieved • Proved by implementation and validation • $71 - $285 million saved in American households using UPnP by 2008 • Contributions • First to design and implement power management proxy for UPnP • Energy savings estimate motivates our work • Member and contributors to UPnP Forum UPnP power management problem solved

28. Conclusions and future work continued • Shortcomings of the design • Long response time • TCP connection between service and control point not established • Proxy can crash • Lost information about sleeping devices • Proxy not discoverable • Need to support several medium • UPnP is media independent

29. Conclusion and future work continued • Future work • UPnP power management standard • Smart NIC • NIC with proxy capability • Distributed solution • Extended proxy functionality • Automatic configuration of power management • Routing of services

30. References • In order of importance: [20] M. Jeronimo and J. Weast, UPnP Design by Example, Volume 1, April 2003 [26] B. Nordman and A. Meier, Energy Consumption of Home Information Technology, July 2004 [2] Y. Y. Goland, T. Cai, P. Leach and Y. Gu, Simple Service Discovery Protocol/1.0 Operating without an Arbiter, draft-cai-ssdp-v1-03.txt, IETF draft, October 1999 [5] UPnP Forum, http://www.upnp.org/, May 2005 [27] K. Christensen, B. Nordman and A. George, The Next Frontier for Communications Networks: Power Management, Computer Communications, Volume 27, Number 18, pages 1758-1770, December 2004 [3] D. Box, G. Kakivaya, A. Layman, S. Thatte and D. Winer, SOAP: Simple Object Access Protocol, draft-box-http-soap-01.txt, IETF draft, November 1999 [4] J. Cohen, S. Aggarwal and Y. Y. Goland, General Event Notification Architecture Base: Client to Arbiter, draft-cohen-gena-p-base-01.txt, IETF draft, September 2000

31. Thank you Jakob Klamra d00jk@efd.lth.se Martin Olsson d00mol@efd.lth.se Project homepage: www.csee.usf.edu/~jklamra/upnp