Restriction of 20MHz Operating Devices in OFDMA
In this document, authors from various affiliations discuss the restriction of 20MHz operating devices in Orthogonal Frequency Division Multiple Access (OFDMA) systems, focusing on IEEE 802.11-16/0906r0. The content includes author details, addresses, and contact information. Different companies like Apple, Intel, Marvell, Huawei, Broadcom, and Qualcomm are represented, highlighting collaborative efforts in technological standards. The document also showcases submission slides with detailed information about the authors involved in the research and development of OFDMA systems.
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
doc.: IEEE 802.11-16/0906r0 RU Restriction of 20MHz Operating Devices in OFDMA Date: 2016-07-25 Authors: Name Affiliation Address Phone Email Joonsuk Kim +1-408-862-3055 joonsuk@apple.com Aon Mujtaba mujtaba@apple.com 1 Infinite Loop Cupertino, CA 95014 USA Guoqing Li Apple guoqing_li@apple.com Jarkko Kneckt jkneckt@apple.com Chris Hartman chartman@apple.com Robert Stacey robert.stacey@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 quinghua.li@intel.com +1-503-724-893 Xiaogang Chen Intel xiaogang.c.chen@intel.com Chitto Ghosh chittabrata.ghosh@intel.com Laurent Cariou laurent.cariou@intel.com Yaron Alpert yaron.alpert@intel.com Assaf Gurevitz assaf.gurevitz@intel.com Submission Slide 1 Joonsuk Kim (Apple)
doc.: IEEE 802.11-16/0906r0 Authors (continued) Name Affiliation Address Phone Email Hongyuan Zhang hongyuan@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 Rui Cao Marvell 408-222-2500 ruicao@marvell.com Sudhir Srinivasa sudhirs@marvell.com Saga Tamhane sagar@marvell.com Mao Yu my@marvell..com Xiayu Zheng xzheng@marvell.com Hui-Ling Lou hlou@marvell.com Ron Porat rporat@broadcom.com Matthew Fischer Sriram Venkateswaran mfischer@broadcom.com Zhou Lan Broadcom Leo Montreuil Andrew Blanksby Mingyue Ji Vinko Erceg Submission Slide 2 Joonsuk Kim (Apple)
doc.: IEEE 802.11-16/0906r0 Authors (continued) Name Affiliation Address Phone Email F1-17, Huawei Base, Bantian, Shenzhen 5B-N8, No.2222 Xinjinqiao Road, Pudong, Shanghai 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 F1-17, Huawei Base, Bantian, Shenzhen F1-17, Huawei Base, Bantian, Shenzhen F1-17, Huawei Base, Bantian, Shenzhen 10180 Telesis Court, Suite 365, San Diego, CA 92121 NA 303 Terry Fox, Suite 400 Kanata, Ottawa, Canada David X. Yang david.yangxun@huawei.com Jiayin Zhang zhangjiayin@huawei.com +86-18601656691 Jun Luo jun.l@huawei.com Yi Luo Roy.luoyi@huawei.com +86-18665891036 Yingpei Lin linyingpei@huawei.com Jiyong Pang pangjiyong@huawei.com Zhigang Rong zhigang.rong@huawei.com Jian Yu ross.yujian@huawei.com Huawei Ming Gan ming.gan@huawei.com Yuchen Guo guoyuchen@huawei.com Yunsong Yang yangyunsong@huawei.com Junghoon Suh Junghoon.Suh@huawei.com Peter Loc peterloc@iwirelesstech.com 303 Terry Fox, Suite 400 Kanata, Ottawa, Canada F1-17, Huawei Base, Bantian, Shenzhen F1-17, Huawei Base, Bantian, Shenzhen Edward Au edward.ks.au@huawei.com Teyan Chen chenteyan@huawei.com Yunbo Li liyunbo@huawei.com Submission Slide 3 Joonsuk Kim (Apple)
doc.: IEEE 802.11-16/0906r0 Authors (continued) Name Affiliation Address Phone Email Straatweg 66-S Breukelen, 3621 BR Netherlands 5775 Morehouse Dr. San Diego, CA, USA 5775 Morehouse Dr. San Diego, CA, USA 5775 Morehouse Dr. San Diego, CA, USA 5775 Morehouse Dr. San Diego, CA, 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 2100 Lakeside Boulevard Suite 475, Richardson TX 75082, USA 1060 Rincon Circle San Jose CA 95131, USA 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 Albert Van Zelst allert@qti.qualcomm.com Alfred Asterjadhi aasterja@qti.qualcomm.com Bin Tian btian@qti.qualcomm.com George Cherian gcherian@qti.qualcomm.com Gwendolyn Barriac gbarriac@qti.qualcomm.com Hemanth Sampath hsampath@qti.qualcomm.com Lin Yang linyang@qti.qualcomm.com Lochan Verma lverma@qti.qualcomm.com Menzo Wentink mwentink@qti.qualcomm.com Qualcomm Naveen Kakani nkakani@qti.qualcomm.com Raja Banerjea rajab@qit.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 VK Jones vkjones@qca.qualcomm.com Youhan Kim youhank@qca.qualcomm.com Submission Slide 4 Joonsuk Kim (Apple)
doc.: IEEE 802.11-16/0906r0 Authors (continued) Name Affiliation Address Phone Email Jinmin Kim Jinmin1230.kim@lge.com Kiseon Ryu kiseon.ryu@lge.com Jinyoung Chun jiny.chun@lge.com Jinsoo Choi js.choi@lge.com 19, Yangjae-daero 11gil, Seocho-gu, Seoul 137- 130, Korea Jeongki Kim jeongki.kim@lge.com LG Electronics Dongguk Lim dongguk.lim@lge.com Suhwook Kim suhwook.kim@lge.com Eunsung Park esung.park@lge.com JayH Park Hyunh.park@lge.com HanGyu Cho hg.cho@lge.com Thomas Derham Orange thomas.derham@orange.com Brian Hart brianh@cisco.com 170 W Tasman Dr, San Jose, CA 95134 Cisco Systems Pooya Monajemi pmonajem@cisco.com Submission Slide 5 Joonsuk Kim (Apple)
doc.: IEEE 802.11-16/0906r0 Authors (continued) Name Affiliation Address 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 Phone Email Fei Tong f.tong@samsung.com +44 1223 434633 Hyunjeong Kang hyunjeong.kang@samsung.com +82-31-279-9028 Kaushik Josiam k.josiam@samsung.com (972) 761 7437 Samsung Mark Rison m.rison@samsung.com +44 1223 434600 Rakesh Taori rakesh.taori@samsung.com (972) 761 7470 Sanghyun Chang s29.chang@samsung.com +82-10-8864-1751 Yasushi Takatori takatori.yasushi@lab.ntt.co.jp Yasuhiko Inoue inoue.yasuhiko@lab.ntt.co.jp 1-1 Hikari-no-oka, Yokosuka, Kanagawa 239-0847 Japan Yusuke Asai NTT asai.yusuke@lab.ntt.co.jp Koichi Ishihara ishihara.koichi@lab.ntt.co.jp Akira Kishida kishida.akira@lab.ntt.co.jp 3-6, Hikarinooka, Yokosuka- shi, Kanagawa, 239-8536, Japan Akira Yamada yamadaakira@nttdocomo.com watanabe@docomoinnovations. com hpapadopoulos@docomoinnova tions.com Fujio Watanabe NTT DOCOMO 3240 Hillview Ave, Palo Alto, CA 94304 Haralabos Papadopoulos Submission Slide 6 Joonsuk Kim (Apple)
doc.: IEEE 802.11-16/0906r0 Authors (continued) Name Affiliation Address Phone Email 2860 Junction Ave, San Jose, CA 95134, USA Jianhan Liu +1-408-526-1899 jianhan.Liu@mediatek.com Thomas Pare thomas.pare@mediatek.com chaochun.wang@mediatek.c om james.wang@mediatek.com ChaoChun Wang Mediatek USA James Wang Tianyu Wu tianyu.wu@mediatek.com russell.huang@mediatek.co m Russell Huang No. 1 Dusing 1st Road, Hsinchu, Taiwan James Yee +886-3-567-0766 james.yee@mediatek.com Mediatek Frank Hsu frank.hsu@mediatek.com Bo Sun Sub.bo1@zte.com.cn Kaiying Lv lv.kaiying@zte.com.cn #9 Wuxing duan, Xifeng Rd, Xi an, China Yonggang Fang ZTE yfang@ztetx.com Ke Yao Yao.ke5@zte.com.cn Weimin Xing Xing.weimin@zte.com.cn Submission Slide 7 Joonsuk Kim (Apple)
doc.: IEEE 802.11-16/0906r0 Authors (continued) Name Affiliation Address Phone Email Masahito Mori Masahito.Mori@jp.sony.com Yusuke Tanaka YusukeC.Tanaka@jp.sony.com Yuichi Morioka Sony Corp. Yuichi.Morioka@jp.sony.com Kazuyuki Sakoda Kazuyuki.Sakoda@am.sony.com William Carney William.Carney@am.sony.com Sigurd Schelstraete Sigurd@quantenna.com Quantenna Huizhao Wang hwang@quantenna.com Minho Cheong minho.cheong@newracom.com Reza Hedayat reza.hedayat@newracom.com younghoon.kwon@newracom.co m yongho.seok@newracom.com Young Hoon Kwon 9008 Research Dr. Irvine, CA 92618 Newracom Yongho Seok Daewon Lee daewon.lee@newracom.com Yujin Noh yujin.noh@newracom.com Submission Slide 8 Joonsuk Kim (Apple)
doc.: IEEE 802.11-16/0906r0 Authors (continued) Name Narendar Madhavan Masahiro Sekiya Toshihisa Nabetani Tsuguhide Aoki Tomoko Adachi Kentaro Taniguchi Daisuke Taki Koji Horisaki David Halls Filippo Tosato Zubeir Bocus Fengming Cao Affiliations Toshiba Address Phone email narendar.madhavan@toshiba.co.jp Submission Slide 9 Joonsuk Kim (Apple)
doc.: IEEE 802.11-16/0906r0 Background 802.11ax agreed on tone mapping and pilot location for 20/40/80/160 MHz for OFDMA Current design of tone mapping requires the bandwidth operation for Rx to match with Tx Operation: If AP sends 80MHz OFDMA, an STA allocated with 20 MHz RU may need to perform 80MHz reception (1024 FFT) and cut out the rest 60 MHz in digital domain No benefits on power saving If STAs operates with 20MHz Rx filter, it may not operate for some RU assignment Capability: 20MHz-only (w/ 256 FFT) STAs [2] cannot be OFDMA PPDU recipients for some RU assignment, when AP sends OFDMA with more than 20 MHz Due to tone mapping discrepancy in 20 MHz, 40 MHz and 80 MHz, there are some affected tones for Rx process, when we reduce Rx BW to operate Submission Slide 10 Joonsuk Kim (Apple)
doc.: IEEE 802.11-16/0906r0 Scalability Issue of BW Operation in OFDMA 20 MHz tone mapping is not aligned within 40 MHz OFDMA operation There is no DC tone Guard tones are not aligned Pilot locations are not aligned 40 MHz DC Tones Guard Tones DC Tones 20 MHz Submission Slide 11 Joonsuk Kim (Apple)
doc.: IEEE 802.11-16/0906r0 Affected RUs for 20 MHz Devices 20 MHz only devices (with corresponding Rx filtering) cannot receive some RUs without penalty in 40 MHz OFDMA operation The number of RUs without impact is a lot less Submission Slide 12 Joonsuk Kim (Apple)
doc.: IEEE 802.11-16/0906r0 20 MHz in 40 MHz OFDMA When 20 MHz operating devices are used in 40 MHz OFDMA, RUs in pink are impacted by Tx/Rx filters or DC tones Some RUs are usable at band-edge of 20 MHz Submission Slide 13 Joonsuk Kim (Apple)
doc.: IEEE 802.11-16/0906r0 20 MHz in 80 MHz OFDMA When 20 MHz operating devices are used in 80 MHz OFDMA, RUs in pink are impacted by Tx/Rx filters or DC tones Some RUs are usable at band-edge of 20MHz Submission Slide 14 Joonsuk Kim (Apple)
doc.: IEEE 802.11-16/0906r0 Affected Tones at 20MHz Receiver - DL OFDMA - AP (Tx) and STA (Rx) keep the same tone mapping for 40/80/80+80/160 BW OFDMA 20MHz operating STA (Rx) recovers affected tones by decoding If those affected tones are not many, STAs (Rx) may decode PPDU successfully, depending on MCS For certain RU26s and RU52s, where affected tones are more than 10% of operating data tones (based on simulation), we better not assign such RUs For RU106s and RU242s, STA (Rx) may suffer from PER performance penalty, depending on location of RU, operating BW and MCS. There is another factor to consider, such as DC tracking and leakage Submission Slide 15 Joonsuk Kim (Apple)
doc.: IEEE 802.11-16/0906r0 What about UL-OFDMA? Similar to some tones of shifted RUs being attenuated by RX filters, some tones of the shifted RUs may be attenuated by TX filters (if the RUs are too close to 20 MHz channel edge). Also, some of the shifted RUs may fall outside of the HE20 TX spectral mask If such shifted RUs are agreed by the group to be usable, then exceptions for relevant TX quality requirements (e.g. TX spectral mask, TX flatness) would be granted. Since the most useful cases of UL-OFDMA is for responding to DL PPDU, e.g., BA, we may send smaller size RUs to operate with Submission Slide 16 Joonsuk Kim (Apple)
doc.: IEEE 802.11-16/0906r0 Simulation We conducted more intensive simulations and checked which RUs are seriously impacted, when we keep the current tone mapping, in channel D. Submission Slide 17 Joonsuk Kim (Apple)
doc.: IEEE 802.11-16/0906r0 TxBW=40, RxBW=20 tx40,rx20 tx40,rx40 Data subcarrier loss % baseline SNR @ PER=0.1 RU type RU index SNR @ PER=0.1 MCS1 : 15.6 MCS3 : 21.4 MCS5 : 33.5 MCS7 : error floor MCS1 : 12.8 MCS3 : 18.3 MCS5 : 25.7 MCS7 : 30.4 5, 14 12.5 26 MCS1 : 12.3 MCS3 : 17.5 MCS5 : 25.5 MCS7 : 30.2 MCS1 : 11.3 MCS3 : 16.7 MCS5 : 24.1 MCS7 : 28 9, 10 8.33 MCS1 : 11.8 MCS3 : 17.3 MCS5 : 25 MCS7 : 30.85 MCS1 : 11.2 MCS3 : 16.8 MCS5 : 24.3 MCS7 : 29.1 4, 5 4.17 52 Submission Slide 18 Joonsuk Kim (Apple)
doc.: IEEE 802.11-16/0906r0 TxBW=40, RxBW=20 (Cont.) tx40,rx20 tx40,rx40 Data subcarrier loss % baseline SNR @ PER=0.1 RU type RU index SNR @ PER=0.1 MCS1 : 11.1 MCS3 : 16.35 MCS5 : 24.3 MCS7 : 32 MCS1 : 10.9 MCS3 : 16 MCS5 : 23.5 MCS7 : 30.5 1.96 106 2 MCS1 : 9.76 MCS3 : 15.3 MCS5 : 23.8 MCS7 : 30.74 MCS1 : 9.4 MCS3 : 14.8 MCS5 : 22.9 MCS7 : 27.8 2.56 242 1 Submission Slide 19 Joonsuk Kim (Apple)
doc.: IEEE 802.11-16/0906r0 TxBW=80, RxBW=20 tx80,rx20 tx80,rx80 baseline SNR @ PER=0.1 MCS1 : 12.1 MCS3 : 17.6 MCS5 : 24.9 MCS7 : 28.7 MCS1 : 11.7 MCS3 : 17.1 MCS5 : 24.6 MCS7 : 28.2 MCS1 : 12,8 MCS3 : 18.5 MCS5 : 25.7 MCS7 : 29.6 Data subcarrier loss % RU type RU index SNR @ PER=0.1 MCS1 : 14.4 MCS3 : 20 MCS5 : 31.18 MCS7 : error floor MCS1 : 14.7 MCS3 : 20.7 MCS5 : 30 MCS7 : error floor MCS1 : 13.54 MCS3 : 19.25 MCS5 : 27.23 MCS7 : 32.63 5, 14, 24, 33 12.5 10, 28 25 26 9, 29 8.3 19 58.3 no data no data MCS1 : 12.8 MCS3 : 18.4 MCS5 : 26.1 MCS7 : 31.8 MCS1 : 12.8 MCS3 : 18.5 MCS5 : 26.8 MCS7 : 35.67 MCS1 :12.4 MCS3 : 18.1 MCS5 : 25.3 MCS7 : 30.2 MCS1 : 11.6 MCS3 : 17.2 MCS5 : 24.5 MCS7 : 29.1 4, 13 4.17 52 5, 12 12.5 Submission Slide 20 Joonsuk Kim (Apple)
doc.: IEEE 802.11-16/0906r0 TxBW=80, RxBW=20 (Cont.) tx80,rx20 tx80,rx80 Data subcarrier loss % baseline SNR @ PER=0.1 RU type RU index SNR @ PER=0.1 MCS1 : 11.24 MCS3 : 16.33 MCS5 : 24.55 MCS7 : 31.68 MCS1 : 10.9 MCS3 : 16.16 MCS5 : 23.6 MCS7 : 30.6 1.96 2 106 MCS1 : 10.56 MCS3 : 15.9 MCS5 : 23.96 MCS7 : 32.73 MCS1 : 10 MCS3 : 15.2 MCS5 : 22.8 MCS7 : 29.9 5.88 3 MCS1 : 9.5 MCS3 : 15.14 MCS5 : 23.6 MCS7 : 30.4 MCS1 : 9.1 MCS3 : 14.5 MCS5 : 22.4 MCS7 : 27.3 2.56 1 242 MCS1 : 9.64 MCS3 : 15.2 MCS5 : 23.7 MCS7 : 31.3 MCS1 : 8.8 MCS3 : 14.5 MCS5 : 22.3 MCS7 : 27.3 4.27 2 Submission Slide 21 Joonsuk Kim (Apple)
doc.: IEEE 802.11-16/0906r0 Observation In general, we have checked the performance is badly hit, when the number of affected data tones is more than 10% of data Under this observation, we d like to have this guideline to restriction on RU26s and RU52s Some of RU106s and RU242s overlap with DC tone of the narrower BW modes, or out of FFT index range FFT index range issue RU106 #3 and #6 in HE80 OFDMA have tones located out of FFT range DC tone issue All RU242s in HE40/80 OFDMA has data modulated on the DC tone location of 20 MHz operating STAs This may cause RX DC (DL OFDMA) or TX LO leakage (UL OFDMA) to interfere w/ the data tones, further degrading performance It depends on implementation, so propose as an optional mode for DL- OFDMA Submission Slide 22 Joonsuk Kim (Apple)
doc.: IEEE 802.11-16/0906r0 Straw Poll #1 Do you support to add following rules for 20MHz operating STAs? AP shall not assign following RUs to 20 MHz operating STAs For 26-tone RUs, [1] RU26#5, 14 in 40 MHz DL/UL OFDMA PPDU 2 RU26s are restricted RU26# 5, 10, 14, 19, 24, 28, 33 in 80 MHz DL/UL OFDMA PPDU 7 RU26s are restricted RU26# 5, 10, 14, 19, 24, 28, 33 in lower 80 MHz and upper 80 MHz, in 80+80 or 160 MHz DL/UL OFDMA PPDU 14 RU26s are restricted For 52-tone RUs, [1] RU52#5, 12 in 80 MHz DL/UL OFDMA PPDU 2 RU52s are restricted RU52#5, 12 in lower 80 MHz and upper 80 MHz, in 80+80 or 160 MHz DL/UL OFDMA PPDU 4 RU52s are restricted For 106-tone RUs, [1] RU106#3, 6 in 80MHz DL/UL OFDMA PPDU 2 RU106s are restricted RU106#3, 6 in lower 80 MHz and upper 80 MHz, in 80+80 or 160 MHz DL/UL OFDMA PPDU 4 RU106s are restricted Center RU26 in primary 20 channel shall not be assigned to any STAs where 20MHz operating STAs are recipients of 40/80/160/80+80 OFDMA [1] Table 26-9 and 26-10 of 16/0024r1 Submission Slide 23 Joonsuk Kim (Apple)
doc.: IEEE 802.11-16/0906r0 Straw Poll #2 Do you support to add following rules for 20MHz operating STAs? It is optional whether all RU242s of 20 MHz operating STAs to be supported in 40/80/160/80+80 MHz DL-OFDMA If supported, there is no restriction on RU242s RU242 shall not be allocated to 20MHz operating STAs in 40/80/160/80+80 for UL-OFDMA 20MHz operating Non-AP STA Function Format Sub-format 40MHz DL- OFDMA RU242 tone mapping In 2.4 GHz O 40 & 80 MHz DL- OFDMA RU242 tone mapping In 5 GHz O 80+80 or 160 MHz DL-OFDMA RU242 tone mapping In 5 GHz O Submission Slide 24 Joonsuk Kim (Apple)
doc.: IEEE 802.11-16/0906r0 Straw Poll #3 Do you agree to adopt the spec text change as shown in doc 11/16- 0908r0? Submission Slide 25 Joonsuk Kim (Apple)
doc.: IEEE 802.11-16/0906r0 Reference [1] 11-16-0024-01-00ax-proposed-draft-specification [2] 11-16-0907-00-00ax-20MHz-only-devices-in-11ax [3] 11-16-0908-00-00ax-RU-restriction-of-20MHz-operating-devices-in- OFDMA-text Submission Slide 26 Joonsuk Kim (Apple)
doc.: IEEE 802.11-16/0906r0 Appendix Submission Slide 27 Joonsuk Kim (Apple)
doc.: IEEE 802.11-16/0906r0 Simulation Setup Multi-antenna transmission : 1 1 and 4 1 MCS: 0, 2, 4, 6 and 8 RU size: 26RU, 52RU, 106RU and 242RU Power is boosted for 26RU, 52RU and 106RU Payload Size: 500 bytes Channel: TGac ChD and ITU NLOS UMi Carrier frequency offset (CFO): fixed at 20 ppm (@ 5GHz) Phase noise (both at Tx/Rx): -41dBc Real timing estimation & synchronization Submission Slide 28 Joonsuk Kim (Apple)
doc.: IEEE 802.11-16/0906r0 1x1 TGac ChD, RU26 & RU52 MCS 0 1/2 MCS 2 3/4 MCS 0 1/2 MCS 4 3/4 MCS 2 3/4 MCS 6 3/4 MCS 4 3/4 MCS 8 3/4 MCS 6 3/4 MCS 8 3/4 Submission Slide 29 Joonsuk Kim (Apple)
doc.: IEEE 802.11-16/0906r0 1x1 TGac ChD, RU106 & RU242 MCS 7 MCS 9 MCS 2 MCS 0 MCS 9 MCS 4 MCS 2 MCS 7 MCS 0 MCS 4 Submission Slide 30 Joonsuk Kim (Apple)
doc.: IEEE 802.11-16/0906r0 4x1 TGac ChD RU26 & RU52 MCS 0 1/2 MCS 0 1/2 MCS 2 3/4 MCS 2 3/4 MCS 4 3/4 MCS 8 3/4 MCS 4 3/4 MCS 8 3/4 MCS 6 3/4 MCS 6 3/4 Submission Slide 31 Joonsuk Kim (Apple)
doc.: IEEE 802.11-16/0906r0 4x1 TGac ChD RU106 & RU242 MCS 4 MCS 5 MCS 2 MCS 3 MCS 6 MCS 4 MCS 2 MCS 7 MCS 5 MCS 3 MCS 9 MCS 6 MCS 9 MCS 8 MCS 8 MCS 7 Submission Slide 32 Joonsuk Kim (Apple)
doc.: IEEE 802.11-16/0906r0 1x1 ITU NLOS UMi RU26 & RU242 MCS 4 MCS 8 MCS 2 MCS 5 MCS 8 3/4 MCS 2 3/4 MCS 4 3/4 MCS 3 MCS 9 MCS 7 MCS 6 3/4 MCS 0 1/2 Submission Slide 33 Joonsuk Kim (Apple)
![BCH 462- Biotechnology & Genetic engineering [Practical]](/thumb/273367/bch-462-biotechnology-genetic-engineering-practical.jpg)
