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
1
Masters Defense – June 7, 2005 (Tampa, Florida)
Acknowledgments
 Thanks to:
 Dr. Christensen, USF
 Dr. Nyberg, LTH
 Dr. Labrador and Dr. Rundus, USF
 Bruce Nordman, LBNL
 Chamara Gunaratne, USF
2
Topics
 Introduction
 Analysis
 Design
 Implementation
 Validation
 Energy Savings Estimate
 Conclusions and Future Work
3
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
4
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
5
Introduction continued
 SSDP – message exchange
 Discovery SSDP:discover
• Answered by HTTP OK
Service
SSDP:discover
HTTP OK
Service
Control Point
Service
6
Introduction continued
 SSDP – message exchange (continued)
 Notification SSDP:alive
• Sent out periodically
Service
SSDP:alive
Service
Control Point
Service
7
Introduction continued
 UPnP foundation, the stack
Eventing and control
use TCP
UPnP Vendor Specific
SSDP use UDP
UPnP Forum Specific
Our work is done
here
UPnP Device Architecture
HTTP-MU
HTTP-U
HTTP
SOAP
SSDP
SSDP
GENA
GENA
TCP
UDP
IP
8
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
9
Analysis continued
 Low power proxy
 Acts (answers and speaks) for sleeping devices
 Wakes up sleeping devices when they are needed
4. Service powered up
1. Service in power sleep
SLEEP
2. Request for service
Service
Control Point
10
Proxy
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
11
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
12
Design continued
 Design of invisible proxy
SSDP:discover
Timeout
ST = Printer
TCP SYN
(Spoofed) HTTP OK
ST=Printer
start proxy
Control point
Proxy
SLEEP
Service
13
Design continued
 Invisible proxy FSM
LISTENING P1
P12 Timeout
PROXY DEVICE P2
CHECK PROXY CACHE
DISCOVERY P3
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
14
CP = Control point, S = Service, WOL = Wake On Lan
Design continued
 Design of cooperating proxy
Proxy
SSDP:discover
ST = Printer
HTTP OK (Spoofed)
ST=Printer
TCP SYN
SLEEP
15
Service
Control point
Design continued
 Cooperating proxy FSM
LISTENING P1
P12 GENA,
Power mgmt=SLEEP
HTTP OK
P51a GENA,
Power mgmt=POWER
HTTP OK
Forward packet from CP
PROXY
DEVICE P2
P23 SSDP:discover
P32a S in proxy cache
Discovery answer
CHECK PROXY
CACHE TCP P4
P24 TCP from CP
FORWARD
PACKET P5
P51a GENA Power mgmt=POWER
HTTP OK, Forward packet from CP
16
CHECK PROXY
CACHE
DISCOVERY P3
P45 S in proxy cache
WOL to S
CP = Control point, S = Service, WOL = Wake On Lan
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
17
Implementation continued
 Data structure for proxies
UPnP Device
Device Cache
All devices on the network
UPnP Device
UPnP Device
UPnP Device
UPnP Device
Proxy Cache
UPnP Device
All devices proxy is answering for
UPnP Device
UPnP Device
18
Implementation continued
UPnP Device
Name
Description
ip
IP address
eth
Ethernet address
service
All services of the
device
server
Server name
Service
Service
Service
Service
19
location
Location
last_activity
Time for last activity
from the device
Implementation continued
 Implementation of invisible proxy
Main thread
Discover devices and build cache
Notification
Start threads
Main loop
Sniff packets
Proxy cache update
Check devices in
Device Cache
Process packets
Update Proxy Cache
Send answer and
update caches
20
Check Proxy Cache
If needed send
SSDP:alive
Implementation continued
 Implementation of cooperating proxy
Main Thread
Read event
socket
Discover power management
services and build cache
Start threads
Main loop
Sniff packets
Cache update
Check
Device
cache
Process packets
Answer and update
caches
21
Update
Device
cache
Notification
Check
Proxy
cache
Send
SSDP:alive
Read and
parse
incoming
events
Update
Proxy
cache
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
22
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
23
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
at Lawrence Berkley National Laboratory
 Bruce Nordman
24
Energy saving estimation continued
 Background, stocks
Device
Devices 2001
Network
Connected
devices 2008
Notebooks
17.3
44.7
42.4
Desktops
67.9
89.3
82.8
Inkjets
54.9
Laser printers
(all figures are in million)
25
Devices
2008
6.3
107
11.9
102
11.3
Energy saving estimation continued
 Results
Savings in
GWh/year
Savings in million
dollars per year
Low estimation
5%
890
71
20%
3560
285
High estimation
(8 cents/kWh)
26
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
27
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
28
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
29
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
30
Jakob Klamra
d00jk@efd.lth.se
Thank you
Martin Olsson
d00mol@efd.lth.se
Project homepage:
www.csee.usf.edu/~jklamra/upnp
31