Receive Operating Mode Indication for Power Save
This document presents the operating mode indication for power save in September 2015 as part of the IEEE 11-15/1060r0 standard. It includes contributions from various authors affiliated with companies such as Apple, Mediatek, Broadcom, Intel, Marvell, and Qualcomm. The collaboration aims to enhance understanding and implementation of power-saving mechanisms in communication protocols.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
September 2015 Receive Operating Mode Indication for Power Save doc.: IEEE 11-15/1060r0 Date: 2015-09-14 Authors: Name Affiliations Address Phone E-mail Eric Wong +1 (408) 974-5967 ericwong@apple.com Chris Hartman chartman@apple.com Joonsuk Kim Apple Inc. Cupertino, CA joonsuk@apple.com Aon Mujtaba mujtaba@apple.com Guoqing Li guoqing_li@apple.com James Yee +886-3-567-0766 james.yee@mediatek.com Alan Jauh alan.jauh@mediatek.com st Road, No. 1 Dusing 1 Hsinchu, Taiwan Mediatek Chingwa Hu chinghwa.yu@mediatek.com Frank Hsu frank.hsu@mediatek.com ? Submission Slide 1 Eric Wong (Apple)
September 2015 doc.: IEEE 11-15/1060r0 Authors (Continued) Name Affiliations Address Phone E-mail Thomas Pare +1-408-526-1899 thomas.pare@mediatek.com ChaoChun Wang chaochun.wang@mediatek.com James Wang james.wang@mediatek.com Mediatek USA 2860 Junction Ave, San Jose, CA 95134, USA Jianhan Liu Jianhan.Liu@mediatek.com Tianyu Wu tianyu.wu@mediatek.com Russell Huang russell.huang@mediatek.com ? Brian Hart brianh@cisco.com 170 W Tasman Dr, San Jose, CA 95134 Cisco Systems Pooya Monajemi pmonajem@cisco.com David Kloper dakloper@cisco.com Submission Slide 2 Eric Wong (Apple)
September 2015 doc.: IEEE 11-15/1060r0 Authors (Continued) Name Ron Porat Affiliations Address Phone E-mail rporat@broadcom.com mfischer@broadcom.com Sriram Venkateswaran Matthew Fischer Broadcom Leo Montreuil Andrew Blanksby Vinko Erceg Robert Stacey +1-503-724-893 robert.stacey@intel.com Eldad Perahia eldad.perahia@intel.com Shahrnaz Azizi shahrnaz.azizi@intel.com Po-Kai Huang po-kai.huang@intel.com 2111 NE 25th Ave, Hillsboro OR 97124, USA Qinghua Li Intel quinghua.li@intel.com Xiaogang Chen xiaogang.c.chen@intel.com Chitto Ghosh chittabrata.ghosh@intel.com Laurent Cariou laurent.cariou@intel.com Rongzhen Yang rongzhen.yang@intel.com Submission Slide 3 Eric Wong (Apple)
September 2015 doc.: IEEE 11-15/1060r0 Authors (Continued) Name Affiliations Address Phone E-mail Hongyuan Zhang +1-408-222-2500 hongyuan@marvell.com Yakun Sun yakunsun@marvell.com Lei Wang Leileiw@marvell.com Liwen Chu liwenchu@marvell.com Jinjing Jiang jinjing@marvell.com Yan Zhang yzhang@marvell.com 5488 Marvell Lane, Santa Clara, CA, 95054 Marvell Rui Cao ruicao@marvell.com Sudhir Srinivasa sudhirs@marvell.com Saga Tamhane sagar@marvell.com Mao Yu my@marvel..com Edward Au edwardau@marvell.com Hui-Ling Lou hlou@marvell.com Submission Slide 4 Eric Wong (Apple)
September 2015 doc.: IEEE 11-15/1060r0 Authors (Continued) Name Affiliations Address Phone E-mail Straatweg 66-S Breukelen, 3621 BR Netherlands 5775 Morehouse Dr. San Diego, CA, USA 5775 Morehouse Dr. San Diego, CA, USA 1700 Technology Drive San Jose, CA 95110, USA 5775 Morehouse Dr. San Diego, CA, USA 5775 Morehouse Dr. San Diego, CA, USA 5775 Morehouse Dr. San Diego, CA, USA Straatweg 66-S Breukelen, 3621 BR Netherlands Straatweg 66-S Breukelen, 3621 BR Netherlands 1700 Technology Drive San Jose, CA 95110, USA 5775 Morehouse Dr. San Diego, CA, USA 5775 Morehouse Dr. San Diego, CA, USA 1700 Technology Drive San Jose, CA 95110, USA 1700 Technology Drive San Jose, CA 95110, USA 1700 Technology Drive San Jose, CA 95110, USA Albert Van Zelst allert@qti.qualcomm.com Alfred Asterjadhi aasterja@qti.qualcomm.com Bin Tian btian@qti.qualcomm.com Carlos Aldana caldana@qca.qualcomm.com George Cherian gcherian@qti.qualcomm.com Gwendolyn Barriac gbarriac@qti.qualcomm.com Hemanth Sampath hsampath@qti.qualcomm.com Menzo Wentink Qualcomm mwentink@qti.qualcomm.com Richard Van Nee rvannee@qti.qualcomm.com Rolf De Vegt rolfv@qca.qualcomm.com Sameer Vermani svverman@qti.qualcomm.com Simone Merlin smerlin@qti.qualcomm.com Tevfik Yucek tyucek@qca.qualcomm.com VK Jones vkjones@qca.qualcomm.com Youhan Kim youhank@qca.qualcomm.com Submission Slide 5 Eric Wong (Apple)
September 2015 doc.: IEEE 11-15/1060r0 Authors (Continued) Name Affiliations Address Phone E-mail Peter Loc peterloc@iwirelesstech.com F1-17, Huawei Base, Bantian, Shenzhen 5B-N8, No.2222 Xinjinqiao Road, Pudong, Shanghai F1-17, Huawei Base, Bantian, Shenzhen 5B-N8, No.2222 Xinjinqiao Road, Pudong, Shanghai 5B-N8, No.2222 Xinjinqiao Road, Pudong, Shanghai 10180 Telesis Court, Suite 365, San Diego, CA 92121 NA 303 Terry Fox, Suite 400 Kanata, Ottawa, Canada Le Liu +86-18601656691 liule@huawei.com Jun Luo jun.l@huawei.com Yi Luo +86-18665891036 Roy.luoyi@huawei.com Yingpei Lin linyingpei@huawei.com Jiyong Pang pangjiyong@huawei.com Zhigang Rong zhigang.rong@huawei.com Huawei Rob Sun Rob.Sun@huawei.com F1-17, Huawei Base, Bantian, Shenzhen 10180 Telesis Court, Suite 365, San Diego, CA 92121 NA F1-17, Huawei Base, Bantian, Shenzhen David X. Yang david.yangxun@huawei.com Yunsong Yang yangyunsong@huawei.com Yanchun Li liyanchun@huawei.com 303 Terry Fox, Suite 400 Kanata, Ottawa, Canada Junghoon Suh Junghoon.Suh@huawei.com 5B-N8, No.2222 Xinjinqiao Road, Pudong, Shanghai Jiayin Zhang +86-18601656691 zhangjiayin@huawei.com Submission Slide 6 Eric Wong (Apple)
September 2015 doc.: IEEE 11-15/1060r0 Authors (Continued) Name Affiliations Address Phone E-mail Kiseon Ryu kiseon.ryu@lge.com Jinyoung Chun jiny.chun@lge.com Jinsoo Choi js.choi@lge.com Jeongki Kim jeongki.kim@lge.com Giwon Park giwon.park@lge.com 19, Yangjae-daero 11gil, Seocho-gu, Seoul 137- 130, Korea Dongguk Lim LG Electronics dongguk.lim@lge.com Suhwook Kim suhwook.kim@lge.com Eunsung Park esung.park@lge.com Hyeyoung Choi hy0117.choi@lge.com Jinmin Kim jinmin1230.kim@lge.com HanGyu Cho hg.cho@lge.com Submission Slide 7 Eric Wong (Apple)
September 2015 doc.: IEEE 11-15/1060r0 Authors (Continued) Name Affiliations Address Phone E-mail Bo Sun sun.bo1@zte.com.cn Kaiying Lv lv.kaiying@zte.com.cn #9 Wuxingduan, Xifeng Rd., Xi'an, China ZTE Yonggang Fang yfang@ztetx.com Ke Yao yao.ke5@zte.com.cn Weimin Xing xing.weimin@zte.com.cn Innovation Park, Cambridge CB4 0DS (U.K.) Maetan 3-dong; Yongtong-Gu Suwon; South Korea 1301, E. Lookout Dr, Richardson TX 75070 Innovation Park, Cambridge CB4 0DS (U.K.) 1301, E. Lookout Dr, Richardson TX 75070 Maetan 3-dong; Yongtong-Gu Suwon; South Korea Fei Tong +44 1223 434633 f.tong@samsung.com Hyunjeong Kang +82-31-279-9028 hyunjeong.kang@samsung.com Kaushik Josiam (972) 761 7437 k.josiam@samsung.com Samsung Mark Rison +44 1223 434600 m.rison@samsung.com Rakesh Taori (972) 761 7470 rakesh.taori@samsung.com Sanghyun Chang +82-10-8864-1751 s29.chang@samsung.com Submission Slide 8 Eric Wong (Apple)
September 2015 doc.: IEEE 11-15/1060r0 Authors (Continued) Name Affiliations Address Phone E-mail Thomas Derham Orange thomas.derham@orange.com Yasushi Takatori takatori.yasushi@lab.ntt.co.jp Yasuhiko Inoue inoue.yasuhiko@lab.ntt.co.jp Yusuke Asai asai.yusuke@lab.ntt.co.jp 1-1 Hikari-no-oka, Yokosuka, Kanagawa 239-0847 Japan NTT Koichi Ishihara ishihara.koichi@lab.ntt.co.jp Junichi Iwatani Iwatani.junichi@lab.ntt.co.jp Shoko Shinohara Shinohara.shoko@lab.ntt.co.jp 3-6, Hikarinooka, Yokosuka-shi, Kanagawa, 239-8536, Japan Akira Yamada yamadaakira@nttdocomo.com NTT DOCOMO Fujio Watanabe watanabe@docomoinnovations.com 3240 Hillview Ave, Palo Alto, CA 94304 Haralabos Papadopoulos hpapadopoulos@docomoinnovations.com Yuichi Morioka Yuichi.Morioka@jp.sony.com Masahito Mori Masahito.Mori@jp.sony.com 1-7-1 Konan Minato-ku, Tokyo 108-0075, Japan Yusuke Tanaka Sony Corporation YusukeC.Tanaka@jp.sony.com Kazuyuki Sakoda Kazuyuki.Sakoda@am.sony.com William Carney William.Carney@am.sony.com Submission Slide 9 Eric Wong (Apple)
September 2015 doc.: IEEE 11-15/1060r0 Outline Existing spatial multiplexing features in 802.11n/ac Proposal Receive operating mode (ROM) indication Discussion Conclusion Submission Slide 10 Eric Wong (Apple)
September 2015 doc.: IEEE 11-15/1060r0 Existing Spatial Multiplexing Power Save for HT STA (11n) An HT STA (11n) uses the spatial multiplexing (SM) power save feature to allow a STA to operate with only one active receive chain for a significant portion of time [1] for the purpose of power conservation There are currently two SM power save modes i.e. static and dynamic In static mode, a STA operates with only one active receive chain In dynamic mode, a STA enables all its receive chains upon receipt of an individually addressed single-spatial stream frame, e.g. RTS, ; STA reverts back to one active receive chain upon completion of the current frame exchange A STA in dynamic SM power save mode notifies the AP of changes to the number of active receive chains either by an exchange of HT Capabilities element, or SM Power Save frame Submission Slide 11 Eric Wong (Apple)
September 2015 doc.: IEEE 11-15/1060r0 Existing Spatial Multiplexing Power Save for HT STA (11n) Drawbacks of this mechanism A single-spatial stream frame needs to be sent prior to the transmission of a multiple spatial stream frame; this overhead affects MAC efficiency Choice of either one or maximum number of active receive chains available; inflexibility in the number of active receive chains leads to sub optimal power consumption Operating bandwidth is unchanged, i.e. fixed at negotiated bandwidth Submission Slide 12 Eric Wong (Apple)
September 2015 doc.: IEEE 11-15/1060r0 Existing Operating Mode Notification for VHT STA (11ac) An VHT STA (11ac) uses an Operating Mode Notification frame or element to notify STAs that the transmitting STA is changing its operating channel width, the maximum number of spatial streams it can receive, or both [2] The Operating Mode Notification frame or element contains the Operating Mode field that conveys Channel width, i.e. 20, 40, 80, 160 MHz Maximum number of spatial streams that STA can receive, i.e. 1, 2, , 8 Improves 802.11n mechanism by allowing Configurable maximum number of active receive chains Configurable channel width Submission Slide 13 Eric Wong (Apple)
September 2015 doc.: IEEE 11-15/1060r0 Existing Operating Mode Notification in VHT STA (11ac) Drawbacks of this mechanism Operating Mode Notification frame exchange is needed for any changes in channel width or maximum number of active receive chains; this overhead affects MAC efficiency Slow adaptation of number of active receive chains and channel width to match existing link conditions, i.e. <MCS, BW, NSS> where NSS denotes number of spatial streams Submission Slide 14 Eric Wong (Apple)
September 2015 doc.: IEEE 11-15/1060r0 Proposal This contribution describes a mechanism for receive operating mode indication for STAs to dynamically adapt the number of active receive chains and channel width for reception of the subsequent PPDUs Allow STAs to operate in a lower power RX operating mode for a significant portion of time Improve MAC efficiency, i.e. reduction in management frame exchanges Submission Slide 15 Eric Wong (Apple)
September 2015 doc.: IEEE 11-15/1060r0 Receive Operating Mode Indication (1) Proposed a receive operating mode indication mechanism allow STAs to adapt and operate with an appropriate number of active receive chains and channel width for reception of the subsequent PPDU frames Submission Slide 16 Eric Wong (Apple)
September 2015 doc.: IEEE 11-15/1060r0 Receive Operating Mode Indication (2) Octets: 2 2 4 1 variable 4 Frame Control QoS Control HT RX Frame Body FCS . Control Operating Mode MAC Header Introduce a one byte Receive (RX) Operating Mode (ROM) field in the MAC header of DATA RX NSS (3-bit), denotes the number of receive spatial streams of the receiver RX Channel Width (3-bit), denotes the channel width of the receiver Presence of RX operating mode field indicated using a reserved bit in both HT and VHT variant of HT Control field Submission Slide 17 Eric Wong (Apple)
September 2015 doc.: IEEE 11-15/1060r0 Receive Operating Mode Indication (3) Format of Receive (RX) Operating Mode (ROM) field in DATA type MAC header is TBD Submission Slide 18 Eric Wong (Apple)
September 2015 doc.: IEEE 11-15/1060r0 Receive Operating Mode Indication (4) The STA originating a unicast frame exchange shall use the RX Operating Mode field in the DATA type MAC header to indicate to the intended receiving STA the state of its receiver upon successful receipt of the response frame The STA receiving the RX Operating Mode field in the DATA type MAC header shall not transmit a multiple spatial stream frame with a larger number of spatial stream and bandwidth back to the originating STA after an outage time (TBD) Different outage times may be specified for NSS (TBD ms) or BW (TBD ms) Outage times may be negotiated by a management frame exchange (e.g. Association) Submission Slide 19 Eric Wong (Apple)
September 2015 doc.: IEEE 11-15/1060r0 Example of Receive Operating Mode Indication Operation STA sends DATA with RX NSS=2, and RX Channel Width=40MHz Accepted AP shall not start any PPDU transmissions to this STA after outage time AP BA DATA STA DATA BA AP sends DATA in NSS=2 and BW=40MHz NSS=2 BW=40MHz TX RX, NSS=2, BW=40MHz Outage Submission Slide 20 Eric Wong (Apple)
September 2015 doc.: IEEE 11-15/1060r0 Discussion Power conservation, i.e. minimizing the number of active receive chains and bandwidth while anticipating the next intended frame In a congested environment, a STA can spend a significant amount of time and power on Listen state Improved MAC efficiency, i.e. no need for exchange of Management frames on a per frame basis to change the NSS and channel width; these frames are typically sent at legacy rates Instead of using RTS to trigger a dynamic NSS and bandwidth change on the intended receiving STA the proposed mechanism uses information in the MAC header of data frame Proposed mechanisms can be supported between multiple STAs, i.e. no AP-STA requirement unlike in legacy SM power save in HT STA Submission Slide 21 Eric Wong (Apple)
September 2015 doc.: IEEE 11-15/1060r0 Conclusion This contribution proposed a mechanism for receive operating mode indication so as to dynamically adapt the number of active receive chains and channel width for reception of the next subsequent PPDU Allow STAs in Listen state to save power Improve MAC efficiency Add one byte Receive (RX) Operating Mode field in the Data type MAC header to include RX NSS (3-bit) RX Channel Width (3-bit) Use outage time(s) to give receivers ample time to adjust to the new NSS or BW settings Submission Slide 22 Eric Wong (Apple)
September 2015 doc.: IEEE 11-15/1060r0 Straw Poll Do you support defining a mechanism for a transmitting STA to indicate its RX operating mode, i.e. RX NSS, RX channel width, in a transmitted DATA type MAC header, so that the responding STA shall not transmit a subsequent PPDU using an NSS or channel width value not indicated as supported in the RX operating mode of the transmitting STA. The responding STA shall not adopt the new NSS and BW until a time TBD. Yes No Abstain Submission Slide 23 Eric Wong (Apple)
September 2015 doc.: IEEE 11-15/1060r0 Motion Move to add to the spec framework: The spec shall define a mechanism for a transmitting STA to indicate its RX operating mode, i.e. RX NSS, RX channel width, in a transmitted DATA type MAC header, so that the responding STA shall not transmit a subsequent PPDU using an NSS or channel width value not indicated as supported in the RX operating mode of the transmitting STA. The responding STA shall not adopt the new NSS and BW until a time TBD. Yes No Abstain Submission Slide 24 Eric Wong (Apple)
September 2015 doc.: IEEE 11-15/1060r0 References 1. 2. 3. 4. IEEE 802.11-2012 IEEE 802.11ac-2013 IEEE 802.11REVmc D4.0 802.11 HEW SG Proposed PAR, 11-14/0165r0 Submission Slide 25 Eric Wong (Apple)
