Closed
Bug 930972
Opened 11 years ago
Closed 7 years ago
[User Story] User Control over use of WiFi during sleep mode
Categories
(Firefox OS Graveyard :: Wifi, defect)
Tracking
(tracking-b2g:backlog)
RESOLVED
WONTFIX
tracking-b2g | backlog |
People
(Reporter: arogers, Unassigned)
References
Details
(Whiteboard: [ucid:WLAN15, FT:RIL])
User Story
As a user, I want to be able to manage if and how my device uses WiFi while it is in sleep mode. This will help me to optimize my power consumption if I am not able to charge my devices battery. For optimized power consumption, I might choose to never connect in sleep mode, always connect, or connect only when in charging in sleep mode.
User Story:
As a user, I want to be able to manage if and how my device uses WiFi while it is in sleep mode. This will help me to optimize my power consumption if I am not able to charge my devices battery.
Acceptance Criteria:
1. There is some control or mechanism which allows the user to manipulate the settings for WiFi use while in Sleep mode
2. MVP Options are (Enable Wifi during sleep, Disable WiFi during sleep)
3. Additional options are (enable WiFi at specified interval during sleep - every 1 hour, every 2 hours)
4. If the setting in (2) is set to disable WiFi is not used during sleep mode
5. If the setting in (2) is set to enable WiFi is used during sleep mode
6. If the setting in (3) is set, WiFi is connected for a period of time (ie; 5 minutes) at the specified interval.
Reporter | ||
Updated•11 years ago
|
blocking-b2g: --- → 1.3?
Comment 1•11 years ago
|
||
(In reply to Adam Rogers (:arog) from comment #0)
I wonder if we need the item 3 of this user story. WIFI alliance has introduced a low power mode mechanism for WIFI.In this mechanism, WIFI device can keep connection with low power during sleep mode. So the wifi is enabled and connected anytime even if the device is in sleep mode. Furthermore, WIFI AP can keep the packets for WIFI device and wake up WIFI device to receive packets during sleep mode. That is why I suggest having 3 options for user.
1. Never connect during sleep mode.
2. Always connect during sleep mode. => this need OEM's help to enhance this power consumption.
3. Only connect when device is in charge mode during sleep mode.
To have a period of time is a creative thought. This kind of design had introduced from some vendors. The reason of having this kind design is that the vendors used the old wifi chip without the low power mode.
However, this kind design introduces the packet loss problem. Moreover, it is hard to find out the balance between packet loss and power consumption.
Comment 2•11 years ago
|
||
(In reply to Ken Chang from comment #1)
> (In reply to Adam Rogers (:arog) from comment #0)
> I wonder if we need the item 3 of this user story. WIFI alliance has
> introduced a low power mode mechanism for WIFI.In this mechanism, WIFI
> device can keep connection with low power during sleep mode. So the wifi is
> enabled and connected anytime even if the device is in sleep mode.
> Furthermore, WIFI AP can keep the packets for WIFI device and wake up WIFI
> device to receive packets during sleep mode. That is why I suggest having 3
> options for user.
> 1. Never connect during sleep mode.
> 2. Always connect during sleep mode. => this need OEM's help to enhance this
> power consumption.
> 3. Only connect when device is in charge mode during sleep mode.
>
> To have a period of time is a creative thought. This kind of design had
> introduced from some vendors. The reason of having this kind design is that
> the vendors used the old wifi chip without the low power mode.
> However, this kind design introduces the packet loss problem. Moreover, it
> is hard to find out the balance between packet loss and power consumption.
We will need to find out if the individual OEM partners have a Wifi HW in their BOM that supports the low power mode. Can we phase this into 2 separate phases?
Phase 1. Support the enable / disable mode during sleep (What you list here in comment 1)
Phase 2. Support programmable options (What Adam has listed in comment 0)
Comment 3•11 years ago
|
||
(In reply to Sandip Kamat from comment #2)
> Phase 2. Support programmable options (What Adam has listed in comment 0)
OEM is supposed to own this kind of design. Since it's very hardware dependent.(Depends on OEM's Battery capacities and WIFI power consumption.)
Comment 4•11 years ago
|
||
(In reply to Ken Chang from comment #3)
> (In reply to Sandip Kamat from comment #2)
> > Phase 2. Support programmable options (What Adam has listed in comment 0)
> OEM is supposed to own this kind of design. Since it's very hardware
> dependent.(Depends on OEM's Battery capacities and WIFI power consumption.)
yep, Is phase 1 feasible at 1.3 timeframes?
Flags: needinfo?(kchang)
Comment 5•11 years ago
|
||
(In reply to Sandip Kamat from comment #4)
> (In reply to Ken Chang from comment #3)
> > (In reply to Sandip Kamat from comment #2)
> > > Phase 2. Support programmable options (What Adam has listed in comment 0)
> > OEM is supposed to own this kind of design. Since it's very hardware
> > dependent.(Depends on OEM's Battery capacities and WIFI power consumption.)
>
> yep, Is phase 1 feasible at 1.3 timeframes?
I wonder if it is workable to only have item 1. If you can accept what I proposed in comment 1..:), I would like to suggest having it in 1.4.
But if you insist on only having item 1, the effort is in Gaia team and you need talk with them to add this item into their backlog.
Flags: needinfo?(kchang)
Comment 7•11 years ago
|
||
I think the option referred to in acceptance criteria 1 would fall on the team managing Settings.
Bruce?
Flags: needinfo?(pdolanjski) → needinfo?(bhuang)
Updated•11 years ago
|
Blocks: backlog-RIL/Net/Conn
blocking-b2g: 1.3? → ---
Comment 9•11 years ago
|
||
Jason, I wonder if we could use this bug as a duplicate of 823247. This bug is a user story. It seems better to add 823247 into the "depends on" list of this bug.
Comment 10•11 years ago
|
||
Ravi can you help clarify based on definition of sleep? The settings UI is a relatively small part of the implementation. Thanks.
Flags: needinfo?(bhuang) → needinfo?(rdandu)
Updated•11 years ago
|
User Story: (updated)
Flags: needinfo?(rdandu)
Updated•11 years ago
|
Blocks: b2g-WLAN-2.0
Comment 11•11 years ago
|
||
1.4 user story supposedly needs to be complete before Sprint3.
Will communicate with team to reconfirm target milestone.
blocking-b2g: --- → backlog
Whiteboard: [ucid:WLAN15, 1.4, FT:RIL]
Target Milestone: --- → 1.4 S3 (14mar)
Updated•11 years ago
|
Flags: in-moztrap?(hlu)
Updated•11 years ago
|
Target Milestone: 1.4 S3 (14mar) → ---
Updated•11 years ago
|
Whiteboard: [ucid:WLAN15, 1.4, FT:RIL] → [ucid:WLAN15, FT:RIL]
Comment 13•11 years ago
|
||
Please see bug 988150 for the latest UX spec.
Updated•11 years ago
|
Blocks: b2g-WLAN-2.0
Updated•11 years ago
|
No longer blocks: backlog-RIL/Net/Conn
Updated•11 years ago
|
No longer blocks: b2g-WLAN-2.0
Updated•11 years ago
|
Flags: in-moztrap?(hlu) → in-moztrap?(echang)
Comment 14•11 years ago
|
||
Hi Ravi, I want to confirm this is not in our v2.0 feature scope, since no conclusion on item 1 and v2.0 is already half way through. I suggest move it to backlog until further clarification. Also could you update the product backlog? Thanks.
Flags: needinfo?(rdandu)
Comment 15•11 years ago
|
||
ni Wilfred, could you help to confirm Comment 14 ? thanks.
Flags: needinfo?(rdandu) → needinfo?(wmathanaraj)
Comment 16•11 years ago
|
||
As this is power consumption related I am going to push this over to Ravi and Adam.
Flags: needinfo?(wmathanaraj) → needinfo?(arogers)
Reporter | ||
Updated•11 years ago
|
Flags: needinfo?(arogers) → needinfo?(rdandu)
Comment 17•11 years ago
|
||
The proposal for UX for a setting for "Keep WiFi-on during Sleep" in bug 988150 is good. One comment: can the phrase 'only when plugged in', be changed to 'only when device is charging'.
Is any more info needed to move this forward?
Flags: needinfo?(rdandu) → needinfo?(hochang)
Comment 18•11 years ago
|
||
Thanks Ravi, so only Gaia work remains, to put this in v2.1. @Omega, can you change the phrase Comment 17 ? @Eric, this won't be done in 2.0, no need to put in moztrap now, thanks.
Flags: needinfo?(ofeng)
Flags: needinfo?(hochang)
Flags: needinfo?(echang)
Updated•11 years ago
|
Flags: needinfo?(echang)
Flags: in-moztrap?(echang)
Flags: in-moztrap-
Comment 19•11 years ago
|
||
(In reply to howie [:howie] from comment #18)
> Thanks Ravi, so only Gaia work remains, to put this in v2.1. @Omega, can you
> change the phrase Comment 17 ?
Yeah, it's done.
See bug 988150 for the updated UX spec.
Flags: needinfo?(ofeng)
Assignee | ||
Updated•10 years ago
|
blocking-b2g: backlog → ---
tracking-b2g:
--- → backlog
Comment 20•7 years ago
|
||
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•