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)

x86
macOS
defect
Not set
normal

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.
blocking-b2g: --- → 1.3?
(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.
(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)
(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.)
(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)
(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)
Peter, Is this in your area for Gaia?
Flags: needinfo?(pdolanjski)
I think the option referred to in acceptance criteria 1 would fall on the team managing Settings. Bruce?
Flags: needinfo?(pdolanjski) → needinfo?(bhuang)
blocking-b2g: 1.3? → ---
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.
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)
User Story: (updated)
Flags: needinfo?(rdandu)
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)
Depends on: 823247
Flags: in-moztrap?(hlu)
Move it out from 1.4 feature.
No longer blocks: b2g-WLAN-2.0
Target Milestone: 1.4 S3 (14mar) → ---
Whiteboard: [ucid:WLAN15, 1.4, FT:RIL] → [ucid:WLAN15, FT:RIL]
Please see bug 988150 for the latest UX spec.
Depends on: 990452
Blocks: b2g-WLAN-2.0
No longer blocks: backlog-RIL/Net/Conn
Blocks: 999842
No longer blocks: b2g-WLAN-2.0
Flags: in-moztrap?(hlu) → in-moztrap?(echang)
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)
ni Wilfred, could you help to confirm Comment 14 ? thanks.
Flags: needinfo?(rdandu) → needinfo?(wmathanaraj)
As this is power consumption related I am going to push this over to Ravi and Adam.
Flags: needinfo?(wmathanaraj) → needinfo?(arogers)
Flags: needinfo?(arogers) → needinfo?(rdandu)
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)
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)
Flags: needinfo?(echang)
Flags: in-moztrap?(echang)
Flags: in-moztrap-
(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)
blocking-b2g: backlog → ---
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.