Download presentation
Presentation is loading. Please wait.
Published byThomasina Floyd Modified over 9 years ago
1
doc.: IEEE 802.11-15/1067r0 Submission September 2015 Jeongki Kim, LG ElectronicsSlide 1 MU TXOP Truncation Date: 2015-09-13 Authors: NameAffiliationAddressPhoneEmail Jeongki Kim LG Electronics 19, Yangjae-daero 11gil, Seocho-gu, Seoul 137- 130, Korea jeongki.kim@lge.com Kiseon Ryu kiseon.ryu@lge.com Jinsoo Choi js.choi@lge.com Jinyoung Chun jiny.chun@lge.com Suhwook Kim suhwook.kim@lge.com Hyeyoung Choi hy0117.choi@lge.com Dongguk Lim dongguk.lim@lge.com Eunsung Park esung.park@lge.com Jinmin Kim jinmin1230.kim@lge.com HanGyu Cho hg.cho@lge.com
2
doc.: IEEE 802.11-15/1067r0 Submission Robert Stacey Intel 2111 NE 25th Ave, Hillsboro OR 97124, USA +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 Qinghua Li 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 NameAffiliation AddressPhoneEmail Ron Porat Broadcom rporat@broadcom.com Sriram Venkateswaran mfischer@broadcom.com Matthew Fischer Leo Montreuil Andrew Blanksby Vinko Erceg Authors (continued) Jeongki Kim, LG ElectronicsSlide 2 September 2015
3
doc.: IEEE 802.11-15/1067r0 Submission Authors (continued) NameAffiliationAddressPhoneEmail Hongyuan Zhang Marvell 5488 Marvell Lane, Santa Clara, CA, 95054 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 Rui Cao ruicao@marvell.com Jie Huang jiehuang@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 Jeongki Kim, LG ElectronicsSlide 3 September 2015
4
doc.: IEEE 802.11-15/1067r0 Submission Authors (continued) NameAffiliationAddressPhoneEmail Albert Van Zelst Qualcomm Straatweg 66-S Breukelen, 3621 BR Netherlands allert@qti.qualcomm.com Alfred Asterjadhi 5775 Morehouse Dr. San Diego, CA, USA aasterja@qti.qualcomm.com Bin Tian 5775 Morehouse Dr. San Diego, CA, USA btian@qti.qualcomm.com Carlos Aldana 1700 Technology Drive San Jose, CA 95110, USA caldana@qca.qualcomm.com George Cherian 5775 Morehouse Dr. San Diego, CA, USA gcherian@qti.qualcomm.com Gwendolyn Barriac 5775 Morehouse Dr. San Diego, CA, USA gbarriac@qti.qualcomm.com Hemanth Sampath 5775 Morehouse Dr. San Diego, CA, USA hsampath@qti.qualcomm.com Menzo Wentink Straatweg 66-S Breukelen, 3621 BR Netherlands mwentink@qti.qualcomm.com Richard Van Nee Straatweg 66-S Breukelen, 3621 BR Netherlands rvannee@qti.qualcomm.com Rolf De Vegt 1700 Technology Drive San Jose, CA 95110, USA rolfv@qca.qualcomm.com Sameer Vermani 5775 Morehouse Dr. San Diego, CA, USA svverman@qti.qualcomm.com Simone Merlin 5775 Morehouse Dr. San Diego, CA, USA smerlin@qti.qualcomm.com Tevfik Yucek 1700 Technology Drive San Jose, CA 95110, USA tyucek@qca.qualcomm.com VK Jones 1700 Technology Drive San Jose, CA 95110, USA vkjones@qca.qualcomm.com Youhan Kim 1700 Technology Drive San Jose, CA 95110, USA youhank@qca.qualcomm.com Jeongki Kim, LG ElectronicsSlide 4 September 2015
5
doc.: IEEE 802.11-15/1067r0 Submission Authors (continued) NameAffiliationAddressPhoneEmail James Yee Mediatek No. 1 Dusing 1 st Road, Hsinchu, Taiwan +886-3-567-0766 james.yee@mediatek.com Alan Jauh alan.jauh@mediatek.com Chingwa Hu chinghwa.yu@mediatek.co m Frank Hsu frank.hsu@mediatek.com Thomas Pare Mediatek USA 2860 Junction Ave, San Jose, CA 95134, USA +1-408-526-1899 thomas.pare@mediatek.com ChaoChun Wang chaochun.wang@mediatek.c om James Wang james.wang@mediatek.com Jianhan Liu Jianhan.Liu@mediatek.com Tianyu Wu tianyu.wu@mediatek.com Russell Huang russell.huang@mediatek.co m Joonsuk Kim Apple joonsuk@apple.com Aon Mujtaba mujtaba@apple.com Guoqing Li guoqing_li@apple.com Eric Wong ericwong@apple.com Chris Hartmanchartman@apple.com Jeongki Kim, LG ElectronicsSlide 5 September 2015
6
doc.: IEEE 802.11-15/1067r0 Submission Authors (continued) NameAffiliationAddressPhoneEmail Phillip Barber Huawei The Lone Star State, TX pbarber@broadbandmobilete ch.com Peter Loc peterloc@iwirelesstech.com Le Liu F1-17, Huawei Base, Bantian, Shenzhen +86-18601656691 liule@huawei.com Jun Luo 5B-N8, No.2222 Xinjinqiao Road, Pudong, Shanghai jun.l@huawei.com Yi Luo F1-17, Huawei Base, Bantian, Shenzhen +86-18665891036 Roy.luoyi@huawei.com Yingpei Lin 5B-N8, No.2222 Xinjinqiao Road, Pudong, Shanghai linyingpei@huawei.com Jiyong Pang 5B-N8, No.2222 Xinjinqiao Road, Pudong, Shanghai pangjiyong@huawei.com Zhigang Rong 10180 Telesis Court, Suite 365, San Diego, CA 92121 NA zhigang.rong@huawei.com Rob Sun 303 Terry Fox, Suite 400 Kanata, Ottawa, Canada Rob.Sun@huawei.com David X. Yang F1-17, Huawei Base, Bantian, Shenzhen david.yangxun@huawei.com Yunsong Yang 10180 Telesis Court, Suite 365, San Diego, CA 92121 NA yangyunsong@huawei.com Zhou Lan F1-17, Huawei Base, Bantian, SHenzhen +86-18565826350 Lanzhou1@huawei.com Junghoon Suh 303 Terry Fox, Suite 400 Kanata, Ottawa, Canada Junghoon.Suh@huawei.com Jiayin Zhang 5B-N8, No.2222 Xinjinqiao Road, Pudong, Shanghai +86-18601656691 zhangjiayin@huawei.com Jeongki Kim, LG ElectronicsSlide 6 September 2015
7
doc.: IEEE 802.11-15/1067r0 Submission Authors (continued) NameAffiliationAddressPhoneEmail Fei Tong Samsung Innovation Park, Cambridge CB4 0DS (U.K.) +44 1223 434633 f.tong@samsung.com Hyunjeong Kang Maetan 3-dong; Yongtong-Gu Suwon; South Korea +82-31-279-9028 hyunjeong.kang@samsung.com Kaushik Josiam 1301, E. Lookout Dr, Richardson TX 75070 (972) 761 7437 k.josiam@samsung.com Mark Rison Innovation Park, Cambridge CB4 0DS (U.K.) +44 1223 434600 m.rison@samsung.com Rakesh Taori 1301, E. Lookout Dr, Richardson TX 75070 (972) 761 7470 rakesh.taori@samsung.com Sanghyun Chang Maetan 3-dong; Yongtong-Gu Suwon; South Korea +82-10-8864-1751 s29.chang@samsung.com Yasushi Takatori NTT 1-1 Hikari-no-oka, Yokosuka, Kanagawa 239-0847 Japan takatori.yasushi@lab.ntt.co.jp Yasuhiko Inoue inoue.yasuhiko@lab.ntt.co.jp Yusuke Asai asai.yusuke@lab.ntt.co.jp Koichi Ishihara ishihara.koichi@lab.ntt.co.jp Junichi Iwatani Iwatani.junichi@lab.ntt.co.jp Shoko Shinohara Shinohara.shoko@lab.ntt.co.jp Akira Yamada NTT DOCOMO 3-6, Hikarinooka, Yokosuka- shi, Kanagawa, 239-8536, Japan yamadaakira@nttdocomo.com Fujio Watanabe 3240 Hillview Ave, Palo Alto, CA 94304 watanabe@docomoinnovations. com Haralabos Papadopoulos hpapadopoulos@docomoinnova tions.com Jeongki Kim, LG ElectronicsSlide 7 September 2015
8
doc.: IEEE 802.11-15/1067r0 Submission Authors (continued) NameAffiliationAddressPhoneEmail Yuichi Morioka Sony Corporation 1-7-1 Konan Minato-ku, Tokyo 108-0075, Japan Yuichi.Morioka@jp.sony.com Masahito Mori Masahito.Mori@jp.sony.com Yusuke Tanaka YusukeC.Tanaka@jp.sony.com Kazuyuki Sakoda Kazuyuki.Sakoda@am.sony.co m William Carney William.Carney@am.sony.com Bo Sun ZTE #9 Wuxingduan, Xifeng Rd., Xi'an, China sun.bo1@zte.com.cn Kaiying Lv lv.kaiying@zte.com.cn Yonggang Fang yfang@ztetx.com Ke Yao yao.ke5@zte.com.cn Weimin Xing xing.weimin@zte.com.cn Brian Hart Cisco Systems 170 W Tasman Dr, San Jose, CA 95134 brianh@cisco.com Pooya Monajemi pmonajem@cisco.com Thomas DerhamOrange thomas.derham@orange.com Jeongki Kim, LG ElectronicsSlide 8 September 2015
9
doc.: IEEE 802.11-15/1067r0 Submission Background (1/2) TXOP truncation in legacy system [1] –When a STA gains access to the channel using EDCA and empties its transmission queue, it may transmit a CF-End frame provided that the remaining duration is long enough to transmit this frame. –By transmitting the CF-End frame, the STA is explicitly indicating the completion of its TXOP. Jeongki Kim, LG ElectronicsSlide 9 September 2015
10
doc.: IEEE 802.11-15/1067r0 Submission Background (2/2) Example 1) DL MU procedure –If AP does not have any DL MU data in queue, the AP can send CF-End to truncate the remaining TXOP Example 2) UL MU procedure –2-1) Like DL MU, if all the MU STAs doesn’t have any data, an AP can send CF-End –2-2) If AP does not receive data from all MU STAs in response to TF, the AP can send CF-End to truncate the remaining TXOP Jeongki Kim, LG ElectronicsSlide 10 September 2015 AP2 MU STAs DL MU frames TXOP Duration Nominal end of TXOP C-E MU BA DL MU frames MU BA DL MU frames MU BA AP2 MU STAs TF: Trigger frame, C-E: CF-End, TF UL MU frames C-E TXOP Duration Nominal end of TXOP
11
doc.: IEEE 802.11-15/1067r0 Submission Motivation A CF-End frame sent by an OBSS STA can truncate the NAV set by MyBSS’s frame –When a NAV is reset(0), if a channel is idle, a STA can send a frame It will affect the on-going transmission of MyBSS’s frame It will happen more often in 11ax because 11ax considers UL MU procedure and assumes the dense environment (i.e., a lot of OBSSs) We provide a simple rule to avoid resetting the NAV set by myBSS frame due to an OBSS CF- End frame Jeongki Kim, LG ElectronicsSlide 11 September 2015 AP2 (BSS2) MU STAs STA3 TF: Trigger frame, C-E: CF-End AP1 (BSS1) STAs TF UL MU frames MU BA 2) NAV resetting by CF-End 1) NAV set by TF C-E Frames Collision
12
doc.: IEEE 802.11-15/1067r0 Submission Proposal (1/2) In legacy system, a STA saves the TXOP holder address and uses the saved TXOP holder address for responding with the CTS after receiving RTS –“A STA shall save the TXOP holder address for the BSS in which it is associated, which is the MAC address from the Address 2 field of the frame that initiated a frame exchange sequence except when this is a CTS frame, in which case the TXOP holder address is the Address 1 field.” –“If a STA receives an RTS frame with the RA address matching the MAC address of the STA and the MAC address in the TA field in the RTS frame matches the saved TXOP holder address, then the STA shall send the CTS frame after SIFS, without regard for, and without resetting, its NAV.” We can reuse it for TXOP truncation Jeongki Kim, LG ElectronicsSlide 12 September 2015
13
doc.: IEEE 802.11-15/1067r0 Submission Proposal (2/2) Proposed method: When a STA receives a CF-End from an OBSS STA, if the last NAV update was caused by a Intra- BSS frame, the STA should not reset its NAV Jeongki Kim, LG ElectronicsSlide 13 September 2015 2) TA (AP1) of CF-End doesn’t match TXOP holder address(AP2), Not reset NAV 1) NAV updated by TF Save TXOP holder address(AP2) AP2 (BSS2) MU STAs STA3 TF: Trigger frame, C-E: CF-End AP1 (BSS1) STAs TF UL MU frames MU BA C-E
14
doc.: IEEE 802.11-15/1067r0 Submission Conclusion We propose a simple rule of truncating the MU TXOP set by TF of myBSS –A STA that receives a CF-End does not reset its NAV unless the NAV was set by a frame originating from the STA sending a CF- End frame It can protect the TXOP set by a my-BSS frame from OBSS TXOP truncation Jeongki Kim, LG ElectronicsSlide 14 September 2015
15
doc.: IEEE 802.11-15/1067r0 Submission Reference [1] IEEE 802.11REVmc_D4.0 Jeongki Kim, LG ElectronicsSlide 15 September 2015
16
doc.: IEEE 802.11-15/1067r0 Submission Straw Poll Do you agree to add the following text in SFD? –When a STA receives a CF-End from an OBSS STA, if the last NAV update was caused by a Intra-BSS frame, the STA should not reset its NAV Jeongki Kim, LG ElectronicsSlide 16 September 2015
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.