| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
17/0029r6 has still not be posted, and by the time my next working day starts the discussion will already have taken place (Monday AM2, according to the last schedule I've seen). Since there has been no indication of what changes, if any, will have been made in r6 to address the comments I made previously, I will reiterate these comments and suggest possible changes to address them. 1) in Usage Model 1: Smart Home, I suspect the power required to move the curtains twice a day will vastly exceed that required to run a STA in legacy PS mode for a day (using a suitable listen interval and BSS max idle period etc.). So I don't think this particular part of the usage model is convincing. Even the door seems a bit borderline to me (some kind of energy budget should be done to show that the energy needed to operate the lock a couple of times a day is significantly less than that needed to run a STA in legacy PS mode) It has been indicated that this UM assumes the controller is powered separately from the motor. If so, this is a pretty broken design: there's no point super-optimising the controller power consumption when you've got a huge battery around to power the motor! I assume the lock part of the UM is not similarly deficient? I suggest one of two possible changes: - Preferably, just delete the "smart curtain" part of the UM - If you really want to keep the "smart curtain" part of the UM, make it explicit that this use case only applies when the curtain motor and curtain controller are separately powered. This will at least be an indication that this is a UM of very limited applicability In any case, also: - provide an energy budget to show the lock part of the UM makes sense, i.e. that the energy required by existing 802.11 is a significant fraction of the energy required by the lock (including its motor) 2) in Usage Model 3: Outdoor Cattle Farms, I don't think it will make a difference whether the emergency cow rustling signal takes 1 ms or 1 s to get transmitted. So I don't think "Delay should be a critical factor in case of emergency report"
is convincing. I'm similarly unconvinced by the Quick message/Incoming call notification/sensor alarm aspects of Usage Model 1: Smart Home If the emergency cow rustling signal is sent with a second or so's latency, that will be quite sufficient. This is eminently achievable with existing 802.11. Therefore the only benefit of WUR here is the power benefit;
"Delay should be a critical factor in case of emergency report" is not a benefit provided by WUR over existing 802.11. I suggest the following changes: - Instead of claiming that
"Delay should be a critical factor" for cows, say that the delay needs to be no more than of the order of a second. WUR can achieve this as well as existing 802.11, so the UM will allow for WUR (but delay will not be an argument for it of itself) - Similarly, for the Quick message/Incoming call notification/sensor alarm stuff, say that the delay needs to be no more than a few hundred ms. WUR can achieve this as well as existing 802.11, so the UM will allow for WUR (but delay will not be an argument for it of itself) Thanks, Mark --
Mark RISON, Standards Architect, WLAN English/Esperanto/Français Samsung Cambridge Solution Centre Tel: +44 1223 434600 Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601 ROYAUME UNI WWW:
http://www.samsung.com/uk From: *** 802.11 TGba - WUR- Wake-up Radio Operation *** [mailto:STDS-802-11-TGBA@xxxxxxxx]
On Behalf Of Yujian (Ross Yu) Hi Minyoung, Since in last meeting, I didn’t get a chance to review the usage model document, and I further make some minor changes regarding on Mark’s comments, I am going to have a quick overview of the changes
made in usage model document r6 and then run the motion. 11/17-029r6 WUR Usage Model Document Regards Ross Jian Yu Huawei Technologies Co.,Ltd. 发件人:
*** 802.11 TGba - WUR- Wake-up Radio Operation *** [mailto:STDS-802-11-TGBA@xxxxxxxx]
代表
Leif Wilhelmsson R Hi Minyoung, I have one contribution 11/17-0062, “Simulated WUR Performance in Frequency Selective Channels” BR, Leif From: *** 802.11 TGba - WUR- Wake-up Radio Operation *** [mailto:STDS-802-11-TGBA@xxxxxxxx]
On Behalf Of Park, Minyoung Dear TGba participants, If you have submissions for the May TGba F2F meeting in Daejeon, please send me the document number, title, your name and affiliation. Regards, Minyoung Intel Labs | Intel Corporation |