mobile middleware for energy-awareness wei li [email protected]
TRANSCRIPT
Contents:
Definition and usageNeeds for Energy-Awareness Mobile
MiddlewareA SolutionSummary
Definition
• The framework with which the mobile devices make power adaptations
• Considerations: current battery status, local CPU demand, and network environment.
• Hide the heterogeneity of low level platforms, and thus enable the higher layers of the system to build scalable solutions.
Target: prolong battery use time in the meantime provide acceptable QoS
A typical usage scenario
Put the network interface into sleep mode
Reduce backlight luminanceLower the video transcoding rateSuggest user to stop watching video when the battery is even lower
Reduce the message sending rate. Filter the messages according to the priority
1. When the train is going through a tunnel2. When the battery status drops from high to medium3. When the battery status drops from medium to low
Contents:
Definition and usageNeeds for Energy-Awareness Mobile
MiddlewareA SolutionSummary
Why we need such a middleware?
1. More and more multimedia usage.
2. Battery technology evolves really slowly
Comparison between two smart phones in ten years:Nokia 9210 Communicator (2000) VS. HTC Desire (2010)
Hardware:Processor : 52 MHz 1G HzMemory: 16 MB 576 MBCamera: NA 5 megapixel
Network: EGSM HSCSD 43.2 Kbit/s WCDMA/HSPA 14 Mbit/s
Software:Don’t even want to start it
…..
Battery: Li-Ion 1300 mAh Li-Ion 1500 mAh
Why do we need such a middleware?
Why we need such a middleware?
3. Battery is the most restricting factor for Mobile phones
If we have more powerful battery?
Bigger screen, watch a couple of movies on the plane, charge once and use one month
Why we need such a middleware?
charge our nuclear phone once and use it for the entire life
Maybe someday…
Why we need such a middleware?
Let’s get back down to earth
Before new technology in energy area, the energy-awareness middleware is indeed needed
Contents:
Definition and usageNeeds for Energy-Awareness Mobile
MiddlewareA SolutionSummary
The adaptations:
Local:• Processor voltage• CPU frequency• Backlight luminance• Network interface settings
Global:• Transfer some computation from the devices to remote
entities• Negotiated transmission
Architecture
Resource Manager
Target:
separate the low level resources
Functions:
1. Process the information requests
2. Control the hardware device
Application Classifer
Target: Classify applications into different classes
Resource consumption patterns:
CPU processing load {LOW, HIGH} Memory access mode {STABLE,
BURSTY} Network transmission load {LOW,
HIGH}
Currently three classes:
audio/video decoder/encoder, intensive network transmission, extensive network transmission
Power Estimator
Target:
Estimate the power consumption for the application
Component-level power modeling:Unconcerned about application details.
Application-level modeling:Power estimation for each application
Policy Manager
Target:
Make different power policies
Input: application classification, network conditions, platform settings…
Output: adaptive operations
Processing Engine
Target:
Responsible for scheduling power adaptations automatically
The procedure:
1. Subscribe to the resource manager for events
2. Request for application classification, power estimation or policy
3. Execute policy
Messaging
Target:
1. Communicate with other middleware and OS components
2. Communicate with remote entities
Inter-process communication (IPC) such as D-Bus is used for the first target
HTTP is used for the second target
Work flow
Step 1
Step 2
Step 3
Step 4
Step 5
Another policy request and execution
Evaluation environment and result:
• Device: Nokia N810 Internet tablet
• Download and playback content: a YouTube video clip with duration of 257 seconds. File size 9472KB.
• Network environment: 802.11g WLan
• Result: the energy consumption is reduced by 8%
Contents:
Definition and usageNeeds for Energy-Awareness Mobile
MiddlewareA SolutionSummary
1. Save the energy consumption while provide an acceptable quality of service for mobile devices.
2. Independent on operation system and hardware
3. Possible to extend to a distributed middleware with a proxy
Thank you for your attention!