Doc.: IEEE 802.11-20/0467r0



IEEE P802.11Wireless LANsMinutes for TGbe MAC Ad-Hoc teleconferences in May and July 2020Date: 2020-05-11Author(s):NameAffiliationAddressPhoneemailLiwen ChuNXPJeongki KimLG Electronics-66675207645AbstractThis document contains the meeting minutes for the TGbe MAC ad hoc teleconferences held in May 2020 and July 2020.Revisions:Rev0: Added the minutes from the telephone conferences held on May 11, 2020.Rev1: Added the minutes from the telephone conferences held on May 18, 2020.Rev2: Added the minutes from the telephone conferences held on May 20, 2020.Rev3: Added the minutes from the telephone conferences held on May 21, 2020.Rev4: Added the minutes from the telephone conferences held on May 27, 2020.Rev5: Added the minutes from the telephone conferences held on June 1, 2020.Rev6: Added the minutes from the telephone conferences held on June 3, 2020.Rev7: Added the minutes from the telephone conferences held on June 4, 2020.Rev8: Added the minutes from the telephone conferences held on June 8, 2020.Rev9: Added the minutes from the telephone conferences held on June 10, 2020.Rev10: Added the minutes from the telephone conferences held on June 15, 2020.Added the minutes from the telephone conferences held on June 17, 2020.Added the minutes from the telephone conferences held on June 18, 2020.Rev11: Added the minutes from the telephone conferences held on June 22, 2020.Rev12: Added the minutes from the telephone conferences held on July 02, 2020.Rev13: Added the minutes from the telephone conferences held on July 08, 2020.Rev13: Adding the attendance requested through email for teleconference on July 08, 2020.00AbstractThis document contains the meeting minutes for the TGbe MAC ad hoc teleconferences held in May 2020 and July 2020.Revisions:Rev0: Added the minutes from the telephone conferences held on May 11, 2020.Rev1: Added the minutes from the telephone conferences held on May 18, 2020.Rev2: Added the minutes from the telephone conferences held on May 20, 2020.Rev3: Added the minutes from the telephone conferences held on May 21, 2020.Rev4: Added the minutes from the telephone conferences held on May 27, 2020.Rev5: Added the minutes from the telephone conferences held on June 1, 2020.Rev6: Added the minutes from the telephone conferences held on June 3, 2020.Rev7: Added the minutes from the telephone conferences held on June 4, 2020.Rev8: Added the minutes from the telephone conferences held on June 8, 2020.Rev9: Added the minutes from the telephone conferences held on June 10, 2020.Rev10: Added the minutes from the telephone conferences held on June 15, 2020.Added the minutes from the telephone conferences held on June 17, 2020.Added the minutes from the telephone conferences held on June 18, 2020.Rev11: Added the minutes from the telephone conferences held on June 22, 2020.Rev12: Added the minutes from the telephone conferences held on July 02, 2020.Rev13: Added the minutes from the telephone conferences held on July 08, 2020.Rev13: Adding the attendance requested through email for teleconference on July 08, 2020.Monday 11 May 2020, 19:00 – 22:00 ET (TGbe MAC ad hoc conference call)Chairman: Jeongki Kim (LG Electronics)Secretary: Liwen Chu (NXP)This meeting took place using a webex session.IntroductionThe Chair (Jeongki, LG) calls the meeting to order at 19:04 EDT. The Chair introduces himself and the Secretary, Liwen Chu (NXP)The Chair goes through the 802 and 802.11 IPR policy and procedures and asks if there is anyone that is aware of any potentially essential patents. Nobody speaks up.The Chair recommends using IMAT for recording the attendance.Please record your attendance during the conference call by using the IMAT system: 1) login to imat, 2) select “802.11 Telecons (<Month>)” entry, 3) select “C/LM/WG802.11 Attendance” entry, 4) click “TGbe <MAC/PHY/Joint> conference call that you are attending.If you are unable to record the attendance via IMAT then please send an e-mail to Jeongki Kim ( HYPERLINK "mailto:jeongki.kim@" jeongki.kim@) and Liwen Chu ( HYPERLINK "mailto:liwen.chu@" liwen.chu@)Recorded attendance through Imat and e-mail:TimestampNameAffiliation5/11Adachi, TomokoTOSHIBA Corporation5/11Akhmetov, DmitryIntel Corporation5/11Andersdotter, AmeliaNone - Self-funded5/11Au, Kwok ShumHuawei Technologies Co., Ltd5/11Bredewoud, AlbertBroadcom Corporation5/11Cariou, LaurentIntel Corporation5/11Carney, WilliamSony Corporation5/11CHAN, YEEFacebook5/11Cheng, PaulMediaTek Inc.5/11CHERIAN, GEORGEQualcomm Incorporated5/11Chitrakar, RojanPanasonic Asia Pacific Pte Ltd.5/11Chu, LiwenNXP Semiconductors5/11Das, DibakarIntel Corporation5/11Das, SubirPerspecta Labs Inc.5/11Derham, ThomasBroadcom Corporation5/11de Vegt, RolfQualcomm Incorporated5/11Ding, BaokunHuawei Technologies Co. Ltd5/11Dong, XiandongXiaomi Inc.5/11Fang, YonggangZTE TX Inc5/11Fischer, MatthewBroadcom Corporation5/11Gan, MingHuawei Technologies Co., Ltd5/11Garg, LalitBroadcom Corporation5/11Guo, QiangInfomTechnologies5/11Guo, YuchenHuawei Technologies Co., Ltd5/11Gwak, YongsuPersonnel5/11Hamilton, MarkRuckus/CommScope5/11Han, JonghunSAMSUNG5/11Han, ZhiqiangZTE Corporation5/11Ho, DuncanQualcomm Incorporated5/11Hu, ChunyuFacebook5/11Huang, Guogang?Huawei5/11Huang, Po-KaiIntel Corporation5/11Inoue, YasuhikoNippon Telegraph and Telephone Corporation (NTT)5/11Jang, InsunLG ELECTRONICS5/11Jiang, JinjingApple, Inc.5/11Jung, hyojinHyundai Motor Company5/11Kain, CarlUSDoT5/11Kandala, SrinivasSAMSUNG5/11kim, namyeongLG ELECTRONICS5/11Kim, Sang GookLG ELECTRONICS5/11Kim, SanghyunWILUS Inc5/11Kim, YonghoKorea National University of Transportation5/11Kishida, AkiraNippon Telegraph and Telephone Corporation (NTT)5/11Kneckt, JarkkoApple, Inc.5/11Kondo, YoshihisaAdvanced Telecommunications Research Institute International (ATR)5/11Kwon, Young HoonNXP Semiconductors5/11Lalam, MassinissaSAGEMCOM BROADBAND SAS5/11Levy, JosephInterDigital, Inc.5/11Li, YiqingHuawei Technologies Co. Ltd5/11Li, YunboHuawei Technologies Co., Ltd5/11Liu, YongApple, Inc.5/11Lou, HanqingInterDigital, Inc.5/11Lu, LiumingZTE Corporation5/11Lv, kaiyingMediaTek Inc.5/11Monajemi, PooyaCisco Systems, Inc.5/11NANDAGOPALAN, SAI SHANKARCypress Semiconductor Corporation5/11Nezou, PatriceCanon Research Centre France5/11Ouchi, MasatomoCanon5/11Park, MinyoungIntel Corporation5/11Park, Sung-jinLG ELECTRONICS5/11Patil, AbhishekQualcomm Incorporated5/11Patwardhan, GauravHewlett Packard Enterprise5/11Raissinia, AlirezaQualcomm Incorporated5/11Rosdahl, JonQualcomm Technologies, Inc.5/11Seok, YonghoMediaTek Inc.5/11Son, Ju-HyungWILUS Inc.5/11Song, TaewonLG ELECTRONICS5/11Sun, Li-HsiangInterDigital, Inc.5/11Sun, YanjunQualcomm Incorporated5/11Tanaka, YusukeSony Corporation5/11Torab Jahromi, PayamFacebook5/11Wang, LeiHuawei R&D USA5/11Wang, XiaofeiInterDigital, Inc.5/11Wu, HaoXGIMI Technology Co.,Ltd5/11Yano, KazutoAdvanced Telecommunications Research Institute International (ATR)5/11Yee, JamesMediaTek Inc.5/11yi, yongjiangFuturewei Technologies5/11Yukawa, MitsuyoshiCanon, Inc.5/11Zhou, YifanHuawei Technologies Co., LtdThe Chair reminds that the agenda can be found in 11-20/735r0. The chair add an item about the time of additional MAC teleconference. The Chair asked for the comments bout the agenda. Hui-Zhao announced he will postpone his contribution 11-20/115. Kaiying announced her presentation 11-19/1547 was already presented. So 11-19/1547, 11-20/115 were removed from the agenda of today.Discussuin of schedule time of additional teleconference:Prefer 7:00om or 10:00am on FridayPrefer 10:00am since it is better for Europe people.It was announced in last week’s call. And there was no objection in the teleconference. It is better to comment when announcing/discussing the teleconference.Zhou mentioned that his 292 is about R1, R2 discussion. It is better to move it to the session about R1, R2 discussion.Tgbe chair said that it will happen in joint meeting in next week. It is better in joint session since there is sone dependency between MAC PHY.There was one request to defer the presentation 11-20/105 since the quthor can’t attend this meeting. 11-20/105 was removed from today’s agenda.MAC chair runs the straw poll about rotating the time betweem 10:00am and 7:00pm on Wednesday.The result is 31Y, 13N, 15ATechnical Submissions after the agenda discussion: ML-Med Access408r2 Prioritized EDCA Channel Access Over Latency Sensitive Links in MLO (Chunyu Hu) [Cont.]1547r5 Multi-link-operation-and-channel-access-discussion (Kaiying Lu)469r0 Multi-link channel sensing (Yonggang Fang)Technical Submissions: ML-General1822r7 Multi-link security consideration (Po-Kai Huang) [1 SP]069r2 Multi-link communication mode definition (Yonggang Fang) [2 SPs]105r4 Link Latency Statistics of Multi-band Operations in EHT (Frank Hsu) [2 SPs]115r4 Multilink Feature Candidates For Release 1 (Huizhao Wang) 292r0 MLO Typical Operating Scenarios and Sub-feature prioritization (Zhou Lan)434r0 Multi-link Secured Retransmissions (Rojan Chitrakar)472r0 Discussion of More Data subfield for multi-link (Yunbo Li)489r0 Applied Case Study of Multi-link Framework and Operation (Yoshihisa Kondo)562r0 Enhanced multi-link single radio operation (Minyoung Park)Technical Submissions: MAC-General363r0 Proposals on unused bandwidth utilizations (Sindhu Verma)463r0 Priority Access Support Options for NS/EP Services (Subir Das)468r0 Access-category (Yonggang Fang)569r0 11be-txop-protection-coexistence-11ax (Chunyu Hu)591r0 Channel width selection for various frame types with preamble puncture and puncture location indication (Lochan Verma)624r0 EHT-Operation-Element-for-320MHz (Jason Yuchen Guo)680r0 Operating bandwidth indication for eht bss (Huang Guogang) Submissions408r3 Prioritized EDCA Channel Access Over Latency Sensitive Links in MLO (Chunyu Hu) [Cont.] Discussion:C: it seems time-slot is assigned.A: it is not same as scheduling. It is not like HCCA. It more about STAs signíng slots. C: question about straw poll 1, traffic is mapped to different link per TID. Is this ok for straw poll 1. how the service is mapped, to TID?A: it depends on how to define that. One key part is priritized EDCA. Mapping TID to link is not the whole solution. This (TID to link mapping) may create collision.C: what could we have on top of multi-link features already approved? How to deal with medium access within assigned slots and outside of the assigned slots? How about admission control? A: admission control is not sufficient. With admission control, collision still may happen. Disributing the STAs to different slots can futher save power. About EDCA parameters, more detail needs to added, e.g. parameters within and outside of assigned slots.C: time concern, some features should be in R2 since time doesn’t allow so many features in R1.A: agree to consider the timing about R1, R2.Talking about whether questions should focus on the presentation or on straw poll. The chair confirm the following comments are about SPs...C: it seems SFD already allows it, e.g. TID to link mapping, EDCA per link.A: Per link TID mapping in the SFD may not be sufficient.The straw polls are deferred.469r1 Multi-link Channel Access Dsicussion (Yonggang Fang) Summary:Medium access under multi-link to support high priority/low latency services.Joint backoff procedure among multiple links: when one link is detected idle, the backoff counter is decreased by 1.Discussion:C: question about joint backoff. Get one backoff value that applies to multiple links?A: separate CCA sensing among links. Same backoff counter applies to multiple links. C: one back off counter for each AC. If two links are idle, how to count down the backoff counter. Another concern is regulatory concern: this operation may not be allowed.A: the backoff counter will be decreased by 2 in the example.C: This may not be easy to be implemented because of the process delay. A: it should be fine since they are internal processing.C: this is not fair to legacy STAs.A: if you look at it from another angle, it is fair since MLD has multiple devcies.C: more concern about fairness. How to decrease the backoff counter when multiple links are idle?A: more than one are decreased. This is for low latency service.C: do you estimate the gain?A: no simulation since so many models esist.C: clarification question: for joint medium access, do you imagine dobled CW?A: The CW is same as the single link CW. But the CW is shared among the links. SP1: Do you support to include the following in SFD ? STAs of MLD may use the joint backoff counters during EDCA process on multi-links for HP/LL transmissions. The straw poll is deferred.11-19/1822r9 Multi-link Security Consideration (Po-kai) [1 SPs]Discussion:No discussionSP3:Between two MLDs, do you support to use the MLD MAC addresses to derive PMK under SAE method and PTK? The straw poll is approved with uanimous consent11-20/0069r5 Multi-Link Communication Mode Discussion (Yonggang Fang)SP1: Do you support to define the following in SFD ? STR: simultaneous transmission and reception STR Operation: is the operation of which a transmission on one link is independent to (i.e. non-interruptible on) the operation on another link.STR-constraint Operation: is the operation on a link may depend on the operation of another link.e.g. a transmission on a link may be constrained if it causes the reception interruption on another link, or a reception on a link may be constrained if a transmission is on anther link.STR-constraint links: A pair or group of links are in the STR-constraint Operation.Discussion:C: question: do you think STR/STR-constraint operation should be restricted between a pair of links?A: can add it.C: question on wording. Should we define STR/NSTR MLD devcie? Why do we want to define operation?A: it is really about the operation.C: we have STR, NSTR in SFD. Do you mean that STR-constraint is same as NSTR? It is better to unify them.A: yes. The straw poll is changed as follows per the discussion:Do you support to define the following in SFD ? ?STR: simultaneous transmission and reception ?STR Operation: is the operation of which a transmission on one link is independent to (i.e. non-interruptible on) the operation on another link of MLD. ?STR-constraint Operation: is the operation on a link may depend on the operation of another link of MLD. ?i.e. a transmission on a link may be constrained if it causes the reception interruption on another link, or a reception on a link may be constrained if a transmission is on anther link of MLD. ?STR-constraint links: A pair or group of links are in the STR-constraint Operation.16Y, 25N, 29A434r1 Multi-link Secured Retransmissions (Rojan Chitrakar)Summary:The presentation focuses on the issues related to retransmission of protected frames (CCMP/GCMP) and present a proposal to simplify the retransmission of protected frames.MLD address instead of link address is used for encrypting/decrypting the transmitted frame..Discussion:C: straw poll 1 is ok since all people agree with it.C: AAD Nonce only happen when AP link MAC addresses of AP MLD are same and STA link addresses of STA MLD are different or AP link MAC addresses of AP MLD are different and STA link addresses of STA MLD are same.A: agree.C: For the TID without BA agreement, it is open question about wheter we allow retransmisison of a frame in another link.C: similarly it is open question about whether fragment can be retransmitted in different link from the the link for original transmission.The straw polls are differed.472r0 Discussion of More Data subfield for multi-link (Yunbo Li)Summary:The setting of More Data subfield is not accurate in MLD case, it is better to adjust it to fit MLD scenario. The following solutions are proposed:When AP MLD transmit a BU in one link to a non-AP MLD, if there is at least one more BU of any TID or management frames that mapping to this link present for the same non-AP MLD, the More Data subfield is set to 1, otherwise the More Data subfield is set to 0A QoS Null frame with More Data subfield sets to 0 is transmitted in one link to indicate no more BU of any TID or management frames that mapping to this link presentDiscussion:C: the first bullet is too restricted.C: the setting should be based on the TID to link mapping.The teleconference was adjourned at 10:00pm.Monday 18 May 2020, 10:00am – 01:00pm ET (TGbe MAC ad hoc conference call)Chairman: Jeongki Kim (LG Electronics)Secretary: Liwen Chu (NXP)This meeting took place using a webex session.IntroductionThe Chair (Jeongki, LG) calls the meeting to order at 10:04am EDT. The Chair introduces himself and the Secretary, Liwen Chu (NXP)The Chair goes through the 802 and 802.11 IPR policy and procedures and asks if there is anyone that is aware of any potentially essential patents. Nobody speaks up.The Chair recommends using IMAT for recording the attendance.Please record your attendance during the conference call by using the IMAT system: 1) login to imat, 2) select “802.11 Telecons (<Month>)” entry, 3) select “C/LM/WG802.11 Attendance” entry, 4) click “TGbe <MAC/PHY/Joint> conference call that you are attending.If you are unable to record the attendance via HYPERLINK "" IMAT then please send an e-mail to Jeongki Kim ( HYPERLINK "mailto:jeongki.kim@" jeongki.kim@) and Liwen Chu ( HYPERLINK "mailto:liwen.chu@" liwen.chu@)Recorded attendance through Imat and e-mail:5/18Adhikari, ShubhodeepBroadcom Corporation5/18Andersdotter, AmeliaNone - Self-funded5/18Asai, YusukeNippon Telegraph and Telephone Corporation (NTT)5/18Asterjadhi, AlfredQualcomm Incorporated5/18Au, Kwok ShumHuawei Technologies Co., Ltd5/18baron, stephaneCanon Research Centre France5/18Bredewoud, AlbertBroadcom Corporation5/18Cariou, LaurentIntel Corporation5/18Carney, WilliamSony Corporation5/18Cheng, PaulMediaTek Inc.5/18Chitrakar, RojanPanasonic Asia Pacific Pte Ltd.5/18Ciochina, DanaSony Corporation5/18Das, DibakarIntel Corporation5/18Das, SubirPerspecta Labs Inc.5/18de Vegt, RolfQualcomm Incorporated5/18Ding, BaokunHuawei Technologies Co. Ltd5/18Dong, XiandongXiaomi Inc.5/18Fang, YonggangZTE TX Inc5/18Garg, LalitBroadcom Corporation5/18Ghosh, ChittabrataIntel Corporation5/18Guo, QiangInfomTechnologies5/18Guo, YuchenHuawei Technologies Co., Ltd5/18Han, JonghunSAMSUNG5/18Han, ZhiqiangZTE Corporation5/18Handte, ThomasSony Corporation5/18Hsu, Chien-FangMediaTek Inc.5/18Hu, ChunyuFacebook5/18Huang, Po-KaiIntel Corporation5/18Hwang, Sung HyunElectronics and Telecommunications Research Institute (ETRI)5/18Inoue, YasuhikoNippon Telegraph and Telephone Corporation (NTT)5/18Jiang, JinjingApple, Inc.5/18Kain, CarlUSDoT5/18kim, namyeongLG ELECTRONICS5/18Kim, Sang GookLG ELECTRONICS5/18Kim, YonghoKorea National University of Transportation5/18Kishida, AkiraNippon Telegraph and Telephone Corporation (NTT)5/18Ko, GeonjungWILUS Inc.5/18Kondo, YoshihisaAdvanced Telecommunications Research Institute International (ATR)5/18Kumar, ManishMarvell Semiconductor, Inc.5/18Kwon, Young HoonNXP Semiconductors5/18Levitsky, IlyaIITP RAS5/18Levy, JosephInterDigital, Inc.5/18Li, YiqingHuawei Technologies Co. Ltd5/18Li, YunboHuawei Technologies Co., Ltd5/18Lv, kaiyingMediaTek Inc.5/18Max, SebastianEricsson AB5/18Monajemi, PooyaCisco Systems, Inc.5/18NANDAGOPALAN, SAI SHANKARCypress Semiconductor Corporation5/18Naribole, SharanSAMSUNG5/18Nezou, PatriceCanon Research Centre France5/18Park, MinyoungIntel Corporation5/18Park, Sung-jinLG ELECTRONICS5/18Patil, AbhishekQualcomm Incorporated5/18Patwardhan, GauravHewlett Packard Enterprise5/18Petrick, AlbertInterDigital, Inc.5/18RISON, MarkSamsung Cambridge Solution Centre5/18Rosdahl, JonQualcomm Technologies, Inc.5/18Sedin, JonasEricsson AB5/18Seok, YonghoMediaTek Inc.5/18Solaija, Muhammad SohaibIstanbul Medipol University; Vestel5/18Song, TaewonLG ELECTRONICS5/18Sun, Li-HsiangInterDigital, Inc.5/18Sun, YanjunQualcomm Incorporated5/18Torab Jahromi, PayamFacebook5/18Verma, SindhuBroadcom Corporation5/18VIGER, PascalCanon Research Centre France5/18Wang, HaoTencent5/18Wang, HuizhaoQuantenna Communications, Inc.5/18Wang, LeiHuawei R&D USA5/18Wang, XiaofeiInterDigital, Inc.5/18Wentink, MenzoQualcomm5/18Wu, HaoXGIMI Technology Co.Ltd5/18Wullert, JohnPerspecta Labs5/18Yang, JayNokia5/18Yano, KazutoAdvanced Telecommunications Research Institute International (ATR)5/18Yee, JamesMediaTek Inc.5/18Yukawa, MitsuyoshiCanon, Inc.The Chair reminds that the agenda can be found in 11-20/735r6. The chair asked whether there is comment about the agenda. No response. The agenda is approved.Submissions408r4 Prioritized EDCA Channel Access Over Latency Sensitive Links in MLO (Chunyu Hu) [SP only] Chunyu went through the straw polls. No comments/qestions to the straw polls. SP #1Do you support that the TGbe SFD shall include that An MLD AP may offer differentiated quality of service over different links ?61Y, 8N,17ASP #2Do you support that the TGbe SFD shall include:An optional mechanism of dividing medium time into slots of duration TBD during which prioritized EDCA access operates for specifically allowed STAs15Y, 30N, 39A358r3 Multi-BSSID Operation with MLO (Abhishek Patil) [SP only] Per the advice, the straw poll is updated as following SP #4Do you support that each AP of an AP MLD is independently configured to operate as transmitted or nontransmitted BSSID of a multiple BSSID set or as an AP of a co-hosted BSSID set or not part of either a multiple BSSID set or co-hosted BSSID set? ?52Y, 2N, 33A105r4 Link Latency Statistics of Multi-band Operations in EHT (Frank Hsu) [SP only] SP #1Do you support that EHT AP should provide BSS transmit delay statistics carried in an information element?Transmit delay statistics details are TBD? ?C: per AC, DL only.A: Yes it is DL only whether it is per AC is TBD.C: the parameters are already in 11md.A: only average is in 11md. Other parameters are missing.C: about SP #2. It seems SP #1 covers SP #2.A: for SP#2, each link may different statistics. SP #1 is the combination of all links. SP #2 is about per link statistics.C: The BSS TX delay, detail is TBD. But they are important.A: May be modify the language to show DL only. Detail can be discussed later.C: it is useful to be included for latency, load for STA to select link. Question: long time, short time etc. should be defined. BSS is not clrear under MLD. It is better to change the text to average among links.A: After the discussion, the SP #1 is changed toDo you support that EHT AP should provide DL transmit delay statistics over all links carried in an information element? ?DL transmit delay statistics details are TBD ?30Y, 25N, 27ASP #2Do you support that EHT AP MLD should provide transmit delay statistics of each link carried in an information element?Transmit delay statistics details are TBD38Y, 24N, 22A434r2 Multi-link Secured Retransmissions (Rojan Chitrakar) [SP only] Per the advice, the straw poll is updated as following SP #4Do you support that each AP of an AP MLD is independently configured to operate as transmitted or nontransmitted BSSID of a multiple BSSID set or as an AP of a co-hosted BSSID set or not part of either a multiple BSSID set or co-hosted BSSID set? ?SP #1Do you support to add the following to the 11be SFD:When a BA agreement for a TID exists between two MLDs, if the transmission of a frame that belongs to the TID, and which is not a fragment, fails on a link, the frame may be retransmitted on a different link.C: failure is not clear. The retry can be done in respective link of the original transmission.A: it is per MLD level. SP #1 is deferred.472r1 Discussion of More Data subfield for multi-link (Yunbo Li) [SP only] SP #1Do you support to adjust the setting of More Data subfield to fit MLD scenario?45Y, 8N, 25ASP #2Do you support below setting of More Data subfield? ?When AP MLD transmit a BU in one link to a non-AP MLD, if there is at least one additional buffered BU of any TID or management frames that mapping to this link present for the same non-AP MLD, the More Data subfield is set to 1, otherwise the More Data subfield is set to 0. ?A QoS Null frame with More Data subfield sets to 0 can be transmitted in one link to indicate no more additional buffered BU of any TID or management frames that mapping to this link present. ?Based on the feedback, SP #2 is changed toDo you support below setting of More Data subfield? ?When AP MLD transmit a BU in one link to a non-AP MLD, if there is at least one additional buffered BU of any TID or management frames that is mapped to this link by TID-to-link mapping or default mapping for the same non-AP MLD, the More Data subfield is set to 1, otherwise the More Data subfield is set to 0. ?43Y, 7N, 28ASP #3Do you support below setting of More Data subfield? ?A QoS Null frame with More Data subfield sets to 0 may be transmitted in one link to indicate no more additional buffered BU of any TID or management frames that mapping to this link present?29Y, 16N, 37A562r1 Enhanced multi-link single radio operation (Minyoung Park) Summary: many non-AP MLDs are expected to operate with a single radio. This presentation proposes an enhanced multi-link single radio operation where the non-AP MLDs can listen to two (or more) pre-configured channels simultaneously.C: Is dynamic SM power save for one TXOP only? A: detail for more discussion. Currently assume the same baseline dynamic SM power save operation: dynamic SM power save is applied to one frame exchange sequences within the TXOP.C: dynamic configuration of radio needs to be done within 16us. Do we assume madatory or optional?A: it should be optional.C: radio switch may require several ms. Your propposal proposes radio switch within several 10us. A: our PHY expert assumes it can be done within several 10us.The straw polls were deferred.398r4 EHT BSS with Wider BW (Liwen Chu) [SP only]SP #1Do you support that in 6GHz band, an EHT AP may announce different BSS operating bandwidth to non-EHT STAs than the BSS operating bandwidth it announces to EHT STAs when EHT BW covers disallowed 20MHz channels and/or when the announced EHT BW is not supported by non-EHT amendments. The advertised BSS operating bandwidth to EHT STA shall include the advertised BSS operating bandwidth to non-EHT STA?31Y, 1N, 33A363r1 Proposals on unused bandwidth utilizations (Sindhu Verma) Summary: This contribution discusses changes required to enable a device to transmit on the DL or enable transmission on the UL, on any subset of channels that are a part of its operating bandwidth and are idle, even when the primary channel is busy.C: it seems that the parallel CCA is needed. C: When the primary channel is busy, you switch to another channel. Do you need to do link status synchronization (recover NAV information)?C: when you transmit in secondary channel and the primary channel is busy, this requires STA nneds to do parallel PPDU detection.A: it could be predetermined pattern. C: it seems this imply full duplex radio.The teleconference was adjourned at 01:00pm EDT Wendesday 20 May 2020, 10:00am – 01:00pm ET (TGbe MAC ad hoc conference call)Chairman: Jeongki Kim (LG Electronics)Secretary: Liwen Chu (NXP)This meeting took place using a webex session.IntroductionThe Chair (Jeongki, LG) calls the meeting to order at 10:04am EDT. The Chair introduces himself and the Secretary, Liwen Chu (NXP)The Chair goes through the 802 and 802.11 IPR policy and procedures and asks if there is anyone that is aware of any potentially essential patents. Nobody speaks up.The Chair recommends using IMAT for recording the attendance.Please record your attendance during the conference call by using the IMAT system: 1) login to imat, 2) select “802.11 Telecons (<Month>)” entry, 3) select “C/LM/WG802.11 Attendance” entry, 4) click “TGbe <MAC/PHY/Joint> conference call that you are attending.If you are unable to record the attendance via HYPERLINK "" IMAT then please send an e-mail to Jeongki Kim ( HYPERLINK "mailto:jeongki.kim@" jeongki.kim@) and Liwen Chu ( HYPERLINK "mailto:liwen.chu@" liwen.chu@)Recorded attendance through Imat and e-mail:TGbe (MAC) 5/20 Gaurav PatwardhanHewlett Packard EnterpriseTGbe (MAC)5/20Aboulmagd, OsamaHuawei Technologies Co.,? LtdTGbe (MAC)5/20Adhikari, ShubhodeepBroadcom CorporationTGbe (MAC)5/20Akhmetov, DmitryIntel CorporationTGbe (MAC)5/20Asterjadhi, AlfredQualcomm IncorporatedTGbe (MAC)5/20Au, Kwok ShumHuawei Technologies Co., LtdTGbe (MAC)5/20baron, stephaneCanon Research Centre FranceTGbe (MAC)5/20Bredewoud, AlbertBroadcom CorporationTGbe (MAC)5/20Carney, WilliamSony CorporationTGbe (MAC)5/20Cheng, PaulMediaTek Inc.TGbe (MAC)5/20CHERIAN, GEORGEQualcomm IncorporatedTGbe (MAC)5/20Chitrakar, RojanPanasonic Asia Pacific Pte Ltd.TGbe (MAC)5/20Choi, JinsooLG ELECTRONICSTGbe (MAC)5/20Ciochina, DanaSony CorporationTGbe (MAC)5/20Das, DibakarIntel CorporationTGbe (MAC)5/20Das, SubirPerspecta Labs Inc.TGbe (MAC)5/20Derham, ThomasBroadcom CorporationTGbe (MAC)5/20Ding, BaokunHuawei Technologies Co. LtdTGbe (MAC)5/20Dong, XiandongXiaomi Inc.TGbe (MAC)5/20Doostnejad, RoyaIntel CorporationTGbe (MAC)5/20Fang, YonggangZTE TX IncTGbe (MAC)5/20Garg, LalitBroadcom CorporationTGbe (MAC)5/20Ghosh, ChittabrataIntel CorporationTGbe (MAC)5/20Guo, YuchenHuawei Technologies Co., LtdTGbe (MAC)5/20Han, JonghunSAMSUNGTGbe (MAC)5/20Han, ZhiqiangZTE CorporationTGbe (MAC)5/20Handte, ThomasSony CorporationTGbe (MAC)5/20Hervieu, LiliCable Television Laboratories Inc. (CableLabs)TGbe (MAC)5/20Ho, DuncanQualcomm IncorporatedTGbe (MAC)5/20Hong, HanseulYonsei UniversityTGbe (MAC)5/20Huang, Guogang?HuaweiTGbe (MAC)5/20Inoue, YasuhikoNippon Telegraph and Telephone Corporation (NTT)TGbe (MAC)5/20Jang, InsunLG ELECTRONICSTGbe (MAC)5/20Jiang, JinjingApple, Inc.TGbe (MAC)5/20Kain, CarlUSDoTTGbe (MAC)5/20Kedem, OrenHuawei Technologies Co. LtdTGbe (MAC)5/20Kim, JeongkiLG ELECTRONICSTGbe (MAC)5/20kim, namyeongLG ELECTRONICSTGbe (MAC)5/20Kim, Sang GookLG ELECTRONICSTGbe (MAC)5/20Kim, SanghyunWILUS IncTGbe (MAC)5/20Kim, YonghoKorea National University of TransportationTGbe (MAC)5/20Kim, YouhanQualcomm IncorporatedTGbe (MAC)5/20Kishida, AkiraNippon Telegraph and Telephone Corporation (NTT)TGbe (MAC)5/20Ko, GeonjungWILUS Inc.TGbe (MAC)5/20Kondo, YoshihisaAdvanced Telecommunications Research Institute International (ATR)TGbe (MAC)5/20Kumar, ManishMarvell Semiconductor, Inc.TGbe (MAC)5/20Kwon, Young HoonNXP SemiconductorsTGbe (MAC)5/20Lalam, MassinissaSAGEMCOM BROADBAND SASTGbe (MAC)5/20Li, QinghuaIntel CorporationTGbe (MAC)5/20Li, YiqingHuawei Technologies Co. LtdTGbe (MAC)5/20Li, YunboHuawei Technologies Co., LtdTGbe (MAC)5/20LIU, CHENCHENHuawei Technologies Co., LtdTGbe (MAC)5/20Lou, HanqingInterDigital, Inc.TGbe (MAC)5/20Lu, LiumingZTE CorporationTGbe (MAC)5/20Lv, kaiyingMediaTek Inc.TGbe (MAC)5/20Lv, LilyHuawei Technologies Co. LtdTGbe (MAC)5/20Max, SebastianEricsson ABTGbe (MAC)5/20Monajemi, PooyaCisco Systems, Inc.TGbe (MAC)5/20Nezou, PatriceCanon Research Centre FranceTGbe (MAC)5/20Nguyen, AnDHS/CISATGbe (MAC)5/20Park, MinyoungIntel CorporationTGbe (MAC)5/20Park, Sung-jinLG ELECTRONICSTGbe (MAC)5/20Patil, AbhishekQualcomm IncorporatedTGbe (MAC)5/20Rosdahl, JonQualcomm Technologies, Inc.TGbe (MAC)5/20Salman, HanadiIstanbul Medipol UniversityTGbe (MAC)5/20Sedin, JonasEricsson ABTGbe (MAC)5/20Solaija, Muhammad SohaibIstanbul Medipol University; VestelTGbe (MAC)5/20Song, TaewonLG ELECTRONICSTGbe (MAC)5/20Strauch, PaulQualcomm IncorporatedTGbe (MAC)5/20Sun, Li-HsiangInterDigital, Inc.TGbe (MAC)5/20Sun, YanjunQualcomm IncorporatedTGbe (MAC)5/20Torab Jahromi, PayamFacebookTGbe (MAC)5/20Verma, SindhuBroadcom CorporationTGbe (MAC)5/20VIGER, PascalCanon Research Centre FranceTGbe (MAC)5/20Wang, LeiHuawei R&D USATGbe (MAC)5/20Wang, QiApple, Inc.TGbe (MAC)5/20Wang, XiaofeiInterDigital, Inc.TGbe (MAC)5/20Wentink, MenzoQualcommTGbe (MAC)5/20Wullert, JohnPerspecta LabsTGbe (MAC)5/20YANG, RUIInterDigital, Inc.TGbe (MAC)5/20Yano, KazutoAdvanced Telecommunications Research Institute International (ATR)TGbe (MAC)5/20Yee, JamesMediaTek Inc.TGbe (MAC)5/20yi, yongjiangFuturewei TechnologiesTGbe (MAC)5/20Yu, JianHuawei Technologies Co., LtdThe Chair reminds that the agenda can be found in 11-20/735r8. The chair asked whether there is comment about the agenda. No response. The agenda is approved.Submissions363r1 Proposals on unused bandwidth utilizations (Sindhu Verma) [SP only] Sindu would like to defer her straw polls and bring back later after the offline discussion.429r4 Link Latency Statistics of Multi-band Operations in EHT (Kaiying Lu) SummaryThis presentation proposes to use partial bandwidth transmission opportunities to increase spectrum utilization in a wide band system and improve quality of services for low latency applications. ?C: slide 9 question. Second bullet requirement is critical: parallel preamble detection.A: second subbullet doesn’t mean that an AP may need to do parallel preamble detection.C: Does the SC rule mean randomly select one 20MHz channel to do backoff?A: here the proposal is that if the primary 20MHz channel is busy, other 20MHz channel is selected.C: AP needs multiple PPDU decoders.A: this depends on AP’s capability. If AP can’t decode multiple parallel PPDUs, it just selects one another channel to do backoff.C: AP and STA may have different receiving strength. How the threshold in slide 9 works? This may create more hidden node problem.A: This happens in the current BSS.C: do you have the result about the improvement?A: will do further investment.463r1 Priority Access Support Options for NS/EP Services (Subir Das) SummaryThis presentation proposes an approach for supporting priority access to NS/EP Priority Service non-AP STA(s) using OFDMA-based Triggered Uplink Access. ?Specific TID is allocated to such service.C: STA’s announcement of TID is just an advice to AP. It may not be trustable.A: we assume the support of this is optional to AP, and mandatory to STA. C: this can be generalized for other service. Instead of specific TID value, the more general method could be considered, e.g. through management etc. A: would like to do further offline discussion.C: separate BSS can be used since the service requires specific authentication.A: we want to avoid that since what I proposed is used by other network..468r0 Access category (Yonggang Fang) SummaryThis contribution discusses the channel access in Multi-Link communication to support low latency applications and high priority services. The new TID/ACs are used ?C: slide about new AC/TID. Adding AC can provide higher priority. But if there are many traffic for such AC, the performance may be influenced. The backoff parameters of AC VO are already aggresive. A: the separate queues will be used for the new AC.C: question for slide 8. How to deal with TID 8 to 11 (e.g. no mapping of TID to AC) is not clear to me.A: this is from 802.11 baseline.C: the separate queue for specific traffic is already supported in baseline.A: but the ACs are same in baseline.C: agree the idea. The priority for low latency traffic should be higher than control message,A: agreed.C: how to handle the cases of multiple low latency traffics. More flexible/genernal solution should be considered.A: need further study. 569r1 11be txop protection coexistence 11ax (Payam Torab, Chunyu Hu) SummaryThis contribution proposes TXOP protection for >160MHz TXOP through new frame formats. ?C: 11ax will approve in enxt 6 months. We shouldn’t change 11ax. A: Let me give a similar method in 11ay. In 11ay, new channel mode is proposed. 11ay defines a capability to announce whether 11ad device supports the new channel access mode.C: agree with the proposal.C: In general, CTS time out may create fariness issue to legacy STAs. Using the frame format is preferable.SP #1Do you support defining new MAC-level mechanism for TXOP protection in 11be as HE capability?Yes: No: Abstain:NotesExamples of MAC-level mechanisms include modified or new RTS, MU-RTS and CTS frames, and NAV set/reset procedures to the extent that they are independent of EHT PHY headerA feature can be defined as an HE capability through using bits/fields in HE Capabilities element (9.4.2.247), Extended Capabilities element (9.4.2.26), or similar fields/elements accessible to HE STAsC: why do you need this capability. An HE device can do it if it wants..17Y, 40N, 37ASP #2Do you support requiring formats for new RTS, MU-RTS and CTS frames (if defined) to be forward compatible?Yes: No: Abstain:NotesOne examples of forward compatibility is using a version field; see 802.11-19-1519/r5 for ”forward compatibility” discussionCombination of Straw Polls #1 and #2 means “forward compatibility” to start from 11ax, but for 11ax as optional (capability) 24Y, 20N, 40ASP #3Do you support defining new control frames in 11be using the existing “Control Frame Extension” subtype (6) and using bits 8-11 in Frame Control field?Yes: No: Abstain:NotesThis means different definitions for control frames under “Control Frame Extension” subtype (6) in 2.4/5/6 GHz and in 60 GHz)10Y, 26N, 49A591r0 Channel width selection for various frame types with preamble puncture and puncture location indication (Lochan Verma) SummaryThis contribution proposes channel width selection for Control frame, individually addressed Data frame and Management frame with Preamble Puncture. ?A-Control and management element are used to carry the puncture information.C: A-Control notifies the preferred puncture. Is this optional. Puncture is not new, e.g. 11ax has BQR.A: too eary to say mandatory. The difference is how fast you can indicate your channel puncture pattern.C: when AP will appy the STA’s puncture notification?A: ideally it should be applied immediately after the PPDU carrying the nootification.C: seems two parts are in the sldies. Long term signling, e.g. static signaling. This useful way. Different power envelope can provide flexble way, lower power channel to totally punctured channel.A: we didn’t consider this.Please also consider our proposal in slide 6.The teleconference was adjourned at 01:00pm EDT..Thursday 21 May 2020, 07:00pm – 10:00pm ET (TGbe MAC ad hoc conference call)Chairman: Jeongki Kim (LG Electronics)Secretary: Liwen Chu (NXP)This meeting took place using a webex session.IntroductionThe Chair (Jeongki, LG) calls the meeting to order at 10:04am EDT. The Chair introduces himself and the Secretary, Liwen Chu (NXP)The Chair goes through the 802 and 802.11 IPR policy and procedures and asks if there is anyone that is aware of any potentially essential patents. Nobody speaks up.The Chair recommends using IMAT for recording the attendance.Please record your attendance during the conference call by using the IMAT system: 1) login to imat, 2) select “802.11 Telecons (<Month>)” entry, 3) select “C/LM/WG802.11 Attendance” entry, 4) click “TGbe <MAC/PHY/Joint> conference call that you are attending.If you are unable to record the attendance via HYPERLINK "" IMAT then please send an e-mail to Jeongki Kim ( HYPERLINK "mailto:jeongki.kim@" jeongki.kim@) and Liwen Chu ( HYPERLINK "mailto:liwen.chu@" liwen.chu@)Recorded attendance through Imat and e-mail:5/21Adachi, TomokoTOSHIBA Corporation5/21Akhmetov, DmitryIntel Corporation5/21Au, Kwok ShumHuawei Technologies Co., Ltd5/21Cariou, LaurentIntel Corporation5/21Carney, WilliamSony Corporation5/21CHAN, YEEFacebook5/21Cheng, PaulMediaTek Inc.5/21Coffey, JohnRealtek Semiconductor Corp.5/21Das, SubirPerspecta Labs Inc.5/21Derham, ThomasBroadcom Corporation5/21Ding, BaokunHuawei Technologies Co. Ltd5/21Dong, XiandongXiaomi Inc.5/21Fischer, MatthewBroadcom Corporation5/21Guo, QiangInfomTechnologies5/21Guo, YuchenHuawei Technologies Co., Ltd5/21Han, JonghunSAMSUNG5/21Han, ZhiqiangZTE Corporation5/21Hong, HanseulYonsei University5/21Huang, Po-KaiIntel Corporation5/21Jang, InsunLG ELECTRONICS5/21Jiang, JinjingApple, Inc.5/21Jung, hyojinHyundai Motor Company5/21Kain, CarlUSDoT5/21Kakani, NaveenQualcomm Incorporated5/21Kandala, SrinivasSAMSUNG5/21kim, namyeongLG ELECTRONICS5/21Kim, Sang GookLG ELECTRONICS5/21Kim, SanghyunWILUS Inc5/21Kim, YonghoKorea National University of Transportation5/21Kishida, AkiraNippon Telegraph and Telephone Corporation (NTT)5/21Kneckt, JarkkoApple, Inc.5/21Kondo, YoshihisaAdvanced Telecommunications Research Institute International (ATR)5/21Kwon, Young HoonNXP Semiconductors5/21Levy, JosephInterDigital, Inc.5/21Li, YunboHuawei Technologies Co., Ltd5/21Lu, LiumingZTE Corporation5/21Monajemi, PooyaCisco Systems, Inc.5/21NANDAGOPALAN, SAI SHANKARCypress Semiconductor Corporation5/21Naribole, SharanSAMSUNG5/21Ouchi, MasatomoCanon5/21Park, MinyoungIntel Corporation5/21Patil, AbhishekQualcomm Incorporated5/21Patwardhan, GauravHewlett Packard Enterprise5/21Raissinia, AlirezaQualcomm Incorporated5/21Rosdahl, JonQualcomm Technologies, Inc.5/21Salman, HanadiIstanbul Medipol University5/21Seok, YonghoMediaTek Inc.5/21Song, TaewonLG ELECTRONICS5/21Sun, Li-HsiangInterDigital, Inc.5/21Sun, YanjunQualcomm Incorporated5/21Tanaka, YusukeSony Corporation5/21Torab Jahromi, PayamFacebook5/21VIGER, PascalCanon Research Centre France5/21Wang, HaoTencent5/21Wang, HuizhaoQuantenna Communications, Inc.5/21Wu, HaoXGIMI Technology Co.Ltd5/21Yang, JayNokia5/21Yano, KazutoAdvanced Telecommunications Research Institute International (ATR)5/21Yee, JamesMediaTek Inc.5/21Yukawa, MitsuyoshiCanon, Inc.The Chair reminds that the agenda can be found in 11-20/735r11. The chair asked whether there is comment about the agenda. Abhi asked to defer his submission 11-19/1955. Lochan asked some time for his unfinished presented slides in 11-20/591r0. The agenda is updated per the request.Submissions591r0 Channel Width Selection for various Frame Types with Preamble Puncture and Puncture Location Indication (Lochan Verma) [SP only]After some discussion, the straw poll is deferred.624r0 EHT Operation Element for 320MHz (Jason Yuchen Guo) SummaryThis presentation proposes that one BSS can operate in more than one band and the EHT operation element format.?C: whether 160+80 is identified by BW should be discussed with PHY. C: 6GHz has many regulatory rules that are different from 5GHz band operation. It is difficult to operate both bands in one BSS.A: Indoor should be fine.C: the power limit is different.A: AP should follow the strict one.C: 160+80 should be identified through channel puncture. The mixed bands for a BSS may be difficult.A: this is for future extension. The channel access rules for 5GHz and 6GHz band are same.C: the question is secondary channel rule.A: we think IFS is enough.C: the activity of two bands may be difficult. PIFS may create fairness issue.680r0 Operating bandwidth indication for eht bss (Huang Guogang) SummaryThis presentation proposes the BW, CCFSs for EHT BSS.?Independent BW, CCFSs from EHT/HE operation element for EHT STAs are proposed.C: we are ok with the solution to put everything in EHT operation element. For the multiple options, do you have any preference?A: prefer option 1.C: similar to my option 2 in reference 1.C: what is the reason for option 1?A: two CCFS fields are used in option 1.C: the reason for the channel puncturing may be lower power subchannel. static channel puncturing should not be bitmap.C: for straw poll 1, do you want to restrict to 6GHz?A: Agreed.After the discussion the straw poll is changed toSP #1Do you support to define EHT operation element to indicate the channel configuration for EHT STA, which does not need to combine with the indication of CCFS0 and CCFS1 in HE operation elements at 6 GHz? Approved with unanimous consent1988r1 Power Save for Multi-link (Ming Gan)SummaryThis presentation proposes the primary link for monitoring Beacon etc., buffer status notification through one specific link, TWT set up through one specific link etc.?C: multiple TWT with same SP, interval in multiple links can be established. This is good. What do you think about other TWT establishment scheme?A: we prefer the proposed one.C: one association for multiple links. Why not to use same AID for multiple links of a STA MLD?C: slide 3, anchor channel is similar to your primary link. STA can pick link as primary link that AP MLD is beaconing.A: I should update my slides since AP MLD broadcasts Beacons in each link.SP #1Do you agree that not every STA operating in PS mode in a non-AP MLD is required to receive the beacon frames periodically?This is an exemption besides the existing ones, such as individual TWT agreement, WNM sleep mode and NonTIM modeC: this is already allowed by baseline. Probably we don’t need to run this. C: similar question. Implementation specific.C: what is the implication of the spec? looks more implementation thing.A: the intention is that monitoring one link’s beacon is enough.C: then you should reword the straw poll as that.A: that is another straw poll.26Y, 5N, 40ASP #2Do you agree that an AP in an AP MLD shall provide DL traffic notification for another AP in the same AP MLDThe detail for DL traffic notification is TBDC: I have similar contribution. Please defer this one.A: the straw poll is about collect the opinion.The straw poll is deferred.The other straw polls are deferred037r1 Power Saving Considering non-AP without STR Cap. (Namyeong Kim)SummaryThis presentation proposes the power saving mechanism considering the constraints of MLD that doesn’t support simultaneous TX/RX (STR) capability on a pair of links.?C: proposal 1 about slide 5. We don’t need to define specific power save rules. Normal NSTR rule should be enough.A: basically, agree with the comment. However the proposal is like intra-PPDU power that is already in baseline.C: Proposal 2. We don’t want to let one link to sleep because of throughput concern.A: if the STA MLD want to increase the throughput, STA MLD will not go to power save mode.C: Question to slide 8. Does STA2 notifies the mode in link 2?A: No signaling is needed. C: if no signaling, isn’t it just implementation issue?C: this may decrease the throughput.A: the link1 can indicate whether there are buffered frames in link2.C: similar questions as previous comments.SP # 1Do you support 11be defines a power saving mechanism considering unused duration which is generated to avoid interference among links of non-STR non-AP MLD?The details of unused duration are TBD (e.g., TXOP or PPDU)C: the SP is not clear, e.g. unused duration. A: ok, we can defer the SP for offline discussion.066r3 Multi-link TIM (Young Hoon Kwon)SummaryThis presentation proposes propose possible ways of expanding conventional TIM mechanism to be used for indication of multiple link status.?C: generally, agree with the SPs. Slide 12 bullet 2, the conclusion may not be right. It is better to have TID indication.A: we have 8 TIDs. TID based indication has higher overhead.C: Slide 12 bullet 2, I don’t think different AIDs for STA MLD have some issue.A: TIMs in different links may have different meaning.C: when TID maps multiple links, it is not clear which link to wake up.A: STA MLD needs to wake up in those links. . The teleconference was adjourned at 10:00pm EDTWednesday 27 May 2020, 10:00am – 01:00pm ET (TGbe MAC ad hoc conference call)Chairman: Jeongki Kim (LG Electronics)Secretary: Liwen Chu (NXP)This meeting took place using a webex session.IntroductionThe Chair (Jeongki, LG) calls the meeting to order at 10:04am EDT. The Chair introduces himself and the Secretary, Liwen Chu (NXP)The Chair goes through the 802 and 802.11 IPR policy and procedures and asks if there is anyone that is aware of any potentially essential patents. Nobody speaks up.The Chair recommends using IMAT for recording the attendance.Please record your attendance during the conference call by using the IMAT system: 1) login to imat, 2) select “802.11 Telecons (<Month>)” entry, 3) select “C/LM/WG802.11 Attendance” entry, 4) click “TGbe <MAC/PHY/Joint> conference call that you are attending.If you are unable to record the attendance via HYPERLINK "" IMAT then please send an e-mail to Jeongki Kim ( HYPERLINK "mailto:jeongki.kim@" jeongki.kim@) and Liwen Chu ( HYPERLINK "mailto:liwen.chu@" liwen.chu@)Recorded attendance through Imat and e-mail:5/27Adhikari, ShubhodeepBroadcom Corporation5/27Akhmetov, DmitryIntel Corporation5/27baron, stephaneCanon Research Centre France5/27Bredewoud, AlbertBroadcom Corporation5/27Carney, WilliamSony Corporation5/27Cheng, PaulMediaTek Inc.5/27CHERIAN, GEORGEQualcomm Incorporated5/27Chitrakar, RojanPanasonic Asia Pacific Pte Ltd.5/27Choi, JinsooLG ELECTRONICS5/27Coffey, JohnRealtek Semiconductor Corp.5/27Das, DibakarIntel Corporation5/27Das, SubirPerspecta Labs Inc.5/27Derham, ThomasBroadcom Corporation5/27de Vegt, RolfQualcomm Incorporated5/27Ding, BaokunHuawei Technologies Co. Ltd5/27Dong, XiandongXiaomi Inc.5/27Fang, YonggangZTE TX Inc5/27Fischer, MatthewBroadcom Corporation5/27Gan, MingHuawei Technologies Co., Ltd5/27Ghosh, ChittabrataIntel Corporation5/27Guo, YuchenHuawei Technologies Co., Ltd5/27Han, JonghunSAMSUNG5/27Han, ZhiqiangZTE Corporation5/27Handte, ThomasSony Corporation5/27Ho, DuncanQualcomm Incorporated5/27Hong, HanseulYonsei University5/27Hsu, Chien-FangMediaTek Inc.5/27Hu, ChunyuFacebook5/27Hu, MengshiHUAWEI5/27Huang, Guogang?Huawei5/27Huang, Po-KaiIntel Corporation5/27Ji, ChenheHuawei Technologies Co. Ltd5/27Jiang, JinjingApple, Inc.5/27Kakani, NaveenQualcomm Incorporated5/27Kandala, SrinivasSAMSUNG5/27Kim, JeongkiLG ELECTRONICS5/27kim, namyeongLG ELECTRONICS5/27Kim, SanghyunWILUS Inc5/27Kim, YonghoKorea National University of Transportation5/27Kim, YouhanQualcomm Incorporated5/27Kishida, AkiraNippon Telegraph and Telephone Corporation (NTT)5/27Kondo, YoshihisaAdvanced Telecommunications Research Institute International (ATR)5/27Kwon, Young HoonNXP Semiconductors5/27Lalam, MassinissaSAGEMCOM BROADBAND SAS5/27Li, YiqingHuawei Technologies Co. Ltd5/27Li, YunboHuawei Technologies Co., Ltd5/27Liang, dandanHuawei Technologies Co., Ltd5/27LIU, CHENCHENHuawei Technologies Co., Ltd5/27Lou, HanqingInterDigital, Inc.5/27Lu, LiumingZTE Corporation5/27Lv, kaiyingMediaTek Inc.5/27Max, SebastianEricsson AB5/27Monajemi, PooyaCisco Systems, Inc.5/27NANDAGOPALAN, SAI SHANKARCypress Semiconductor Corporation5/27Park, MinyoungIntel Corporation5/27Park, Sung-jinLG ELECTRONICS5/27Patil, AbhishekQualcomm Incorporated5/27Petrick, AlbertInterDigital, Inc.5/27Raissinia, AlirezaQualcomm Incorporated5/27Rosdahl, JonQualcomm Technologies, Inc.5/27Sedin, JonasEricsson AB5/27Seok, YonghoMediaTek Inc.5/27Solaija, Muhammad SohaibIstanbul Medipol University; Vestel5/27Song, TaewonLG ELECTRONICS5/27Stacey, RobertIntel Corporation5/27Sun, Li-HsiangInterDigital, Inc.5/27Sun, YanjunQualcomm Incorporated5/27Verma, SindhuBroadcom Corporation5/27VIGER, PascalCanon Research Centre France5/27Wang, HaoTencent5/27Wang, HuizhaoQuantenna Communications, Inc.5/27Wang, LeiHuawei R&D USA5/27Wang, XiaofeiInterDigital, Inc.5/27Yee, JamesMediaTek Inc.5/27yi, yongjiangFuturewei Technologies5/27Yu, JianHuawei Technologies Co., Ltd5/27Yu, MaoNXP SemiconductorsThe Chair reminds that the agenda can be found in 11-20/735r12. The chair asked whether there is comment about the agenda. Abhi asked to defer his submission 11-19/1955. Young Hoon asked for runing his deferred SP. The Chair ageed to add the deferred SPs at he end of the queue of power save topic. The agenda is updated per the request.Submissions0070r1 Multi-link power saving operation (Yonggang Fang)SummaryThis presentation follows up the discussion of EHT multi-link communication to support low latency, high reliability and high throughput applications, and discusses the issue of power consumption in ML operation. It also proposes a possible approach for establishing an anchored link for ML power saving operation. C: totch the different topics. In slide 7, how does the operating mode fit here?A: this is single case. For multiple link case, disable/enable should exist.C: why do we need the link awake state? Are link doze/active states enough?A: link doze means no listen to anything. C: lot of material. Question for SP, anchor link mentioned in several slides. some things need to be clear. What the anchor link is used? The Beacon in one link is not good for single radio STA MLD. For negotiation, it is not good for AP to decide.A: do you have suggestion? AP needs to know which link the STA MLD will monitor the Beacon for AP to decide where to transmit buffer status indication.C: agree with previous commenter. Anchor link is not clear. The role of the AP should be to serve the STA and send beacon in all its links. STA may internally to select one link.A: For single link, it has to use the associated link for power save mode. For multiple link STA MLD, it should notify the AP MLD one link as anchor link so that AP can transmit the buffer status of the STA MLD through the negotiated link.C: broadcast/multicast is decided by up layer. They are per link traffic. Anchor link is pretty much coverred by baseline. STA just goes to the link at TBTT time and check the bit for it. No negotiation is needed. Don’t think the proposal is needed.A: for save power, one link should be used. Other link could be in deep sleep mode.SP#1Do you support to include the following in SFD ? A non-AP MLD may negotiate with the associated AP MLD a link as the anchored link for the power saving operation. 13Y, 28N, 38A084r1 Multi-link TIM design (Minyoung Park)SummaryThis presentation proposes the power saving mechanism considering the constraints of MLD that doesn’t support simultaneous TX/RX (STR) capability on a pair of links.?C: Agree single AID for STA MLD. Assume two TIDs have buffered frames, TID1 Maps to link 1 and TID2 maps to two links. STA select link2. TID1 is stock in link1. The better way is to indicate the TID.A: what you describe is similar to multi-link TIM.C: is multi-link TIM per TID or per link?A: it is based on TID to link mapping.C: do you mean that all STA MLD has same mapping. If the mapping for STA MLDs are different, how do you transmit the information.A: for 3 links, the maximum is 3.C: for the two options of TIM and ML TIM, which one do you prefer?A: they can work together.C: what is the logic for TIM and ML TIM? A: TIM indicates the buffer frames in AP MLD. ML TIM will indicate which link to wake up.The SPs are deferred.085r1 Multi-link power save - link bitmap (Minyoung Park)SummaryThis presentation proposes a method to extend legacy power save operations to multi-link operation for 802.11be.?C: slide 4 generally makes sense. Does this apply to PS Poll.A:I am not sure there is space to carry the indication. Maybe this is why I don’t include PS Poll here. PS Poll works in legacy way.C: UAPSD case, if link bitmap is used, there may be a delay in AP MLD for APs’ communication.A: agree with the delay.C: PS Poll is typical case. How about only 1 has meaning, 0 has no meaning.A: didn’t consider it.C: for SP1, STA MLD can indicate awake state in the link of the indication transmission only. Why do we need to indicate other link’s awake state?A: TWT can use such mechanism.C: the simpler way is to indicate the state of a link in the link only.A: different people have different opinion.SP #1Do you agree with the following?Between a non-AP MLD and an AP MLD, a STA may transmit a frame to an AP to indicate the transition to the awake state of the other STA(s) of the non-AP MLD- Optional for both AP and non-APC: which sequence do you think the idea can be applied?A: it will depend on STA MLD’s decision.C: motion 84 is similar to this SP.A: Then we don’t need to run this. Will check the motion. The SP is not run..289r1 On multi-link power save and link management (Sindhu Verma)SummaryThis presentation proposes 1) fallback link(s) to help individual/broadcast TWT operation, 2) monitor channel segment narrower than 20MHz, 3) fast beacon channel switch etc.?C: question on slide 7. Are you talking about channel switch?A: For three links in MLD, Link1 and 2 are used. If link 2 can’t work. Link1 and 3 can be used after such operation.C: slide 5. Non-AP STA monitor channel less than 20MHz.A: it depends on whether less than 20MHz monitoring is allowed by PHY design. This can save power if allowed by PHY.C: it is difficult to co-exist with legacy devices.A: the PPDU starts with 20MHz preamble.The SPs are deferred.370r1 Multi-link Power Save Discussion (Sharan Naribole)SummaryThis presentation proposes the extreme power save mode of MLO operation, the anchor link for MLO operation etc.?C: trying to understand the extreme low power mode. Based on the current agreement, a STA MLD can monitor one link. You don’t need any new thing.A: it is not defined clearly that an AP MLD will include all the information of their links in one link’s beacon. It is not clear whether the buffer status indication in one link applies to other links. C: my understanding is that a STA MLD can monitor one link. But some rules should be defined to decrease Beacon overhead.C: for links other than anchor link, they can be disabled. What is the difference between disabling and power save mode?A: power save need to wake up to receive Beacon. Disabling link means the buffer frames are only in anchor link.C: is it related to TID to link mapping? A: we think about all possible case, special TID to link mapping, default mode.C: do you prefer fixed anchor link or dynamic anchor link?A: we support option 2 more than option 1.C: The goals are good for extreme low power mode. For anchor link, do we need specific link?C: several people already made similar comments. Power save mode of links can support extremely low power mode.A: monitoring one link may need some consideration about Beacon overhead etc.The straw polls are deferred.391r0 Power save state after enablement (Laurent Cariou)SummaryThis presentation clarifies the power save mode, power state of various links of STA MLS after the multi-link setup.?C: for multi-link, if there are no traffic in a link that the association is done, is it possible the link is not in active mode.A: it is wired case. By your example, all the links are not in active mode after the association.The straw polls are deferred since there is no time to run it.The teleconference was adjourned at 01:00pm EDTMonday 1 June 2020, 10:00am – 01:00pm ET (TGbe MAC ad hoc conference call)Chairman: Jeongki Kim (LG Electronics)Secretary: Liwen Chu (NXP)This meeting took place using a webex session.IntroductionThe Chair (Jeongki, LG) calls the meeting to order at 10:04am EDT. The Chair introduces himself and the Secretary, Liwen Chu (NXP)The Chair goes through the 802 and 802.11 IPR policy and procedures and asks if there is anyone that is aware of any potentially essential patents. Nobody speaks up.The Chair recommends using IMAT for recording the attendance.Please record your attendance during the conference call by using the IMAT system: 1) login to imat, 2) select “802.11 Telecons (<Month>)” entry, 3) select “C/LM/WG802.11 Attendance” entry, 4) click “TGbe <MAC/PHY/Joint> conference call that you are attending.If you are unable to record the attendance via HYPERLINK "" IMAT then please send an e-mail to Jeongki Kim ( HYPERLINK "mailto:jeongki.kim@" jeongki.kim@) and Liwen Chu ( HYPERLINK "mailto:liwen.chu@" liwen.chu@)Recorded attendance through Imat and e-mail:6/1Aboulmagd, OsamaHuawei Technologies Co.,? Ltd6/1Adhikari, ShubhodeepBroadcom Corporation6/1Asterjadhi, AlfredQualcomm Incorporated6/1Au, Kwok ShumHuawei Technologies Co.,? Ltd6/1baron, stephaneCanon Research Centre France6/1Carney, WilliamSony Corporation6/1CHAN, YEEFacebook6/1Cheng, PaulMediaTek Inc.6/1CHERIAN, GEORGEQualcomm Incorporated6/1Chitrakar, RojanPanasonic Asia Pacific Pte Ltd.6/1Chu, LiwenNXP Semiconductors6/1Das, DibakarIntel Corporation6/1Das, SubirPerspecta Labs Inc.6/1Derham, ThomasBroadcom Corporation6/1de Vegt, RolfQualcomm Incorporated6/1Ding, BaokunHuawei Technologies Co. Ltd6/1Fang, YonggangZTE TX Inc6/1Fischer, MatthewBroadcom Corporation6/1Ghosh, ChittabrataIntel Corporation6/1Guo, QiangInfomTechnologies6/1Guo, YuchenHuawei Technologies Co., Ltd6/1Han, JonghunSAMSUNG6/1Han, ZhiqiangZTE Corporation6/1Ho, DuncanQualcomm Incorporated6/1Hsu, Chien-FangMediaTek Inc.6/1Hu, ChunyuFacebook6/1Huang, Guogang?Huawei6/1Inohiza, HirohikoCanon Inc.6/1Jang, InsunLG ELECTRONICS6/1Jiang, JinjingApple, Inc.6/1Kain, CarlUSDoT6/1Kakani, NaveenQualcomm Incorporated6/1Kandala, SrinivasSAMSUNG6/1Kedem, OrenHuawei Technologies Co. Ltd6/1Kim, JeongkiLG ELECTRONICS6/1kim, namyeongLG ELECTRONICS6/1Kim, Sang GookLG ELECTRONICS6/1Kim, YonghoKorea National University of Transportation6/1Kishida, AkiraNippon Telegraph and Telephone Corporation (NTT)6/1Klein, ArikIntel Corporation6/1Kneckt, JarkkoApple, Inc.6/1Ko, GeonjungWILUS Inc.6/1Kondo, YoshihisaAdvanced Telecommunications Research Institute International (ATR)6/1Kwon, Young HoonNXP Semiconductors6/1Levy, JosephInterDigital, Inc.6/1Li, YiqingHuawei Technologies Co. Ltd6/1Li, YunboHuawei Technologies Co., Ltd6/1Monajemi, PooyaCisco Systems, Inc.6/1NANDAGOPALAN, SAI SHANKARCypress Semiconductor Corporation6/1Naribole, SharanSAMSUNG6/1Park, MinyoungIntel Corporation6/1Patil, AbhishekQualcomm Incorporated6/1Patwardhan, GauravHewlett Packard Enterprise6/1Petrick, AlbertInterDigital, Inc.6/1Raissinia, AlirezaQualcomm Incorporated6/1RISON, MarkSamsung Cambridge Solution Centre6/1Sedin, JonasEricsson AB6/1Seok, YonghoMediaTek Inc.6/1Solaija, Muhammad SohaibIstanbul Medipol University; Vestel6/1Song, TaewonLG ELECTRONICS6/1Stacey, RobertIntel Corporation6/1Sun, Li-HsiangInterDigital, Inc.6/1Sun, YanjunQualcomm Incorporated6/1Torab Jahromi, PayamFacebook6/1Turkmen, HaliseVestel6/1Verma, SindhuBroadcom Corporation6/1Wang, HaoTencent6/1Wang, HuizhaoQuantenna Communications, Inc.6/1Wang, LeiHuawei R&D USA6/1Wentink, MenzoQualcomm6/1Yano, KazutoAdvanced Telecommunications Research Institute International (ATR)6/1Zuo, XinTencentThe Chair reminds that the agenda can be found in 11-20/735r14. The chair asked whether there is comment about the agenda. Several people (Ming 11-19/1988, Yong Hoon 11-20/66, Laurent 11-20/391) announced the deferred SPs that need to be added to the agenda. The agenda is updated per the request.Submissions1955r2 Multi-link Operation: Per-link AID (Abhishek Patil)SummaryThis contribution provides an efficient mechanism to signal the TID(s) for which an AP MLD has BUs for a particular non-AP MLD: Beacon (TIM) indicates BUs for a non-AP MLD; Beacon also identifies a single TID for which the AP has BUs; Additional TID(s) being signalled via new A-Control field (TID Control).?C: two other contributions have different solutions. Are you proposing the solution in slide 7 or 8? A: propose solution in slide 8.C: do you need TIDs’ indication in slide 8?A: We can further discuss it.C: slide 7 cover all TIDs. Slide 8 only indicates single TID. A: Our view is that TID can map to any link in R1. TIM element is enough. Slide 9 proposes the solution for R2.A: link indication is recommendation. Link based solution can’t always work as in my example. The chair cut the discussion.280r2 Link Enablement Considerations (Frank Hsu) SummaryThis presentation proposes that in addition to responding to the TID-link mapping update to enable a link, the response frame should be able to carry information of the link to be enabled from disable state.?C: agree with the point. But has the concern to SP1. The TID to link mapping should be decoupled from the link enablement. A: I think the combination is the agreement in the group.C: when transition from no TID mapping to TID mapped to a link in order to enable a link, you can’t transmit frames right away. When STA wants the frame exchange, it changes its power state to awake.A: the long delay is not good. If further information is provided, it is better.C: when link can be enabled from disabled state, the simple way is that the STA is in doze state.A: I agree your SP about default state. If the device can provide further information, we should allow it.C: why do we provide more ways to solve the same question.A: The additional information provides some benefit.C: what is the way to indicate enable/disable link other than TID to link mapping.A: We agree with TID to link mapping to indicate enable/disable link.C: what is the other way?A: it is not related to the presentation.C: the long transition delay is meaningful to single-radio STA MLD. It is not meaningful to multiple-radio STA MLD.A: it applies to any STA MLD. Not directly related to single-radio STA MLD.The SPs are deferred after 391’s SP.11-20/391r0 Power save state after multi-link setup (laurent cariou ) [SP only]SP 1Do you agree to add to the 11be SFD: When a link becomes enabled for a STA that is part of a non-AP MLD through multi-link setup sent on that link, the initial power management mode of the STA, immediately after the signaling exchange, is active modeWhen a link is enabled for a STA that is part of a non-AP MLD through signaling (multi-link setup or TID to link mapping update) send on another link, the initial power management mode of the STA, immediately after the exchange, is power save mode, and its power state is dozeC: confused by the SP. Legacy mechanism is clear for the first bullet. I don’t think the SP is needed.A: may need more time for the explanation. Follow the baseline. Here we do multi-link association. The second bullet is that you may don’t need to use other links. The second bullet also applies to STA MLDs that can’t enable more than one link.C: You just define default power save state after association. STA side’s indication is better.A: we just follow baseline. But it need cross-link signaling.C: the data port only open after the negotiation. There should be no latency issue. But if the link is enabled later, latency will be introduced.A: if more links are enabled, do you want to enable more links to waste your power?23Y, 18N, 25A280r2 Link Enablement Considerations (Frank Hsu) [SP only]SP 1Do you agree that the response frame corresponds to the link TID-mapping update should be able to carry operational parameters of the link to be enabled?C: the TID to link mapping should be decupled from link enablement.A: they should be coupled.C: the SP is too wide. It is not clear about the operational parameters.A: I don’t want to make the restriction at this stage.12Y, 13N, 40A11-19/1988r3 Power Save for Multi-link (Ming Gan) [SP only]SP 2Do you agree that an AP in an AP MLD shall provide BSS specific parameters update indication for one or more other APs in the same AP MLDThe detail for BSS specific parameters update indication is TBD C: this is related to link management. It is better to run it with the presentations of the same topics. I am in line with you. But the detail should be provided.A: It is already deferred one time. The SP doesn’t touch the detail. C: the word is not clear.C: in general, it is good direction. The questions are asked by the previous commenter.A: the SP already mentioned that the detail is TBD.C: agree with the SP.39Y, 6N, 25ASP 3Do you agree that an AP in an AP MLD shall provide DL traffic notification for one or more other APs in the same AP MLD if TID-to-Link Mapping is establishedThe detail for DL traffic notification is TBDC: we already have TIM. This is not really needed anymore. A: here it is different from the current TIM. C: it is related to Abhi’s SP. Do you agree?A: Yes.26Y, 10N, 32ASP 4Do you agree that the a TWT could be set up on a setup link between a AP MLD and a non-AP MLD for more than one setup link?C: the wording is not clear. The word should be to negotiate the TWT agreement of other links through a link.A: how about removing AP/STA MLD? One agreement applies to multiple links.C: the agreements in multiple links may have different TWT interval, SP duration etc. C: the management level to set TWT in one link for other links. Dynamic operation level includes the early termination etc. If it is for dynamic part, we need to think about how quick it is possible for such operation. Is this SP only for management level?A: what is dynamic case?C: one example is early termination of TWT SP.A: this is not for dynamic part.C: is SP applied to individual and broadcast TWT?A: it should be applied to individual one.After the further discussion the SP is changed toDo you agree that the individual TWT agreement(s) could be set up on a setup link for more than one setup link?34Y, 8N, 21ASP 5Do you agree that each non-AP MLD should select one link to monitor DL traffic indication and BSS parameter updateWhether the non-AP MLD provides the notification of the selected link to the AP MLD and the detailed notification are TBDC: if notification is TBD. The SP is not needed.A: this SP provide some benefit, e.g. save power.C: are you expect that AP knows which link a STA MLD monitor?A: your question is about TBD. Either way is fine to me.C: it is better to ask which the group want to go.C: it is better that AP MLD put TIM in all links.A: this put burden to AP MLD side.17Y, 20N, 27A11-20/66r3 Multi-Link TIM(Young Hoon Kwon) [SP only] SP 1Do you agree to add the following to 11be SFD:? A bit in a partial virtual bitmap of a TIM element that corresponds to a non-AP MLD is set to 1 if any individually addressed BUs for the non-AP MLD are buffered by the AP MLD.C: is there any implication of AID?A: yes, AID needs to be allocated per STA MLD. It is covered by another SP.41Y, 1N, 19ASP 2Do you agree to add the following to 11be SFD:? When a non-AP MLD made a multi-link setup with an AP MLD, one AID is assigned to the non-AP MLD across all links.C: this SP is same as SP1.A: this SP talks about AID allocation. SP1 still allows AIDs for different links of STA MLD to be different.C: this is related TID to link mapping.A: this SP doesn’t touch TID to link mapping.C: does this mean all STA in a STA MLD have same AID value?A: yes35Y, 4N, 26A27r0 Expansion of SN Space (Duncan Ho) Postpone to R2.?61r1 BA Consideration(Liwen Chu) SummaryThis presentation proposes several methods to decrease BA overhead: HE/EHT PPDU to carry BA; BAR to indicate whether the WinStartR is adjusted after sending BA; A-MPDU transmitter to indicate the BA bitmap size.?The teleconference was adjourned at 01:00pm EDTWednesday 3 June 2020, 10:00am – 01:00pm ET (TGbe MAC ad hoc conference call)Chairman: Jeongki Kim (LG Electronics)Secretary: Liwen Chu (NXP)This meeting took place using a webex session.IntroductionThe Chair (Jeongki, LG) calls the meeting to order at 10:04am EDT. The Chair introduces himself and the Secretary, Liwen Chu (NXP)The Chair goes through the 802 and 802.11 IPR policy and procedures and asks if there is anyone that is aware of any potentially essential patents. Nobody speaks up.The Chair recommends using IMAT for recording the attendance.Please record your attendance during the conference call by using the IMAT system: 1) login to imat, 2) select “802.11 Telecons (<Month>)” entry, 3) select “C/LM/WG802.11 Attendance” entry, 4) click “TGbe <MAC/PHY/Joint> conference call that you are attending.If you are unable to record the attendance via IMAT then please send an e-mail to Jeongki Kim ( HYPERLINK "mailto:jeongki.kim@" jeongki.kim@) and Liwen Chu ( HYPERLINK "mailto:liwen.chu@" liwen.chu@)Recorded attendance through Imat and e-mail:6/3Akhmetov, DmitryIntel Corporation6/3Asterjadhi, AlfredQualcomm Incorporated6/3Au, Kwok ShumHuawei Technologies Co.,? Ltd6/3baron, stephaneCanon Research Centre France6/3Bredewoud, AlbertBroadcom Corporation6/3Carney, WilliamSony Corporation6/3Cheng, PaulMediaTek Inc.6/3Chitrakar, RojanPanasonic Asia Pacific Pte Ltd.6/3Choi, JinsooLG ELECTRONICS6/3DeLaOlivaDelgado, AntonioInterDigital, Inc.6/3Derham, ThomasBroadcom Corporation6/3Ding, BaokunHuawei Technologies Co. Ltd6/3Dong, XiandongXiaomi Inc.6/3Fang, YonggangZTE TX Inc6/3Gan, MingHuawei Technologies Co., Ltd6/3Ghosh, ChittabrataIntel Corporation6/3Guo, YuchenHuawei Technologies Co., Ltd6/3Han, JonghunSAMSUNG6/3Han, ZhiqiangZTE Corporation6/3Handte, ThomasSony Corporation6/3Hervieu, LiliCable Television Laboratories Inc. (CableLabs)6/3Ho, DuncanQualcomm Incorporated6/3Hu, ChunyuFacebook6/3Hu, MengshiHUAWEI6/3Huang, Guogang?Huawei6/3Huang, Po-KaiIntel Corporation6/3Jang, InsunLG ELECTRONICS6/3Jiang, JinjingApple, Inc.6/3Kain, CarlUSDoT6/3Kandala, SrinivasSAMSUNG6/3Kedem, OrenHuawei Technologies Co. Ltd6/3Kim, JeongkiLG ELECTRONICS6/3Kim, Sang GookLG ELECTRONICS6/3Kim, SanghyunWILUS Inc6/3Kim, YonghoKorea National University of Transportation6/3Kim, YouhanQualcomm Incorporated6/3Kishida, AkiraNippon Telegraph and Telephone Corporation (NTT)6/3Klein, ArikIntel Corporation6/3Ko, GeonjungWILUS Inc.6/3Kondo, YoshihisaAdvanced Telecommunications Research Institute International (ATR)6/3Kwon, Young HoonNXP Semiconductors6/3Lalam, MassinissaSAGEMCOM BROADBAND SAS6/3Lansford, JamesQualcomm Incorporated6/3Li, YiqingHuawei Technologies Co. Ltd6/3Li, YunboHuawei Technologies Co., Ltd6/3Liang, dandanHuawei Technologies Co., Ltd6/3LIU, CHENCHENHuawei Technologies Co., Ltd6/3Lou, HanqingInterDigital, Inc.6/3Lu, LiumingZTE Corporation6/3Lv, kaiyingMediaTek Inc.6/3Max, SebastianEricsson AB6/3Monajemi, PooyaCisco Systems, Inc.6/3Naribole, SharanSAMSUNG6/3Nezou, PatriceCanon Research Centre France6/3Ouchi, MasatomoCanon6/3Park, MinyoungIntel Corporation6/3Park, Sung-jinLG ELECTRONICS6/3Patil, AbhishekQualcomm Incorporated6/3Patwardhan, GauravHewlett Packard Enterprise6/3Petrick, AlbertInterDigital, Inc.6/3Raissinia, AlirezaQualcomm Incorporated6/3RISON, MarkSamsung Cambridge Solution Centre6/3Rosdahl, JonQualcomm Technologies, Inc.6/3Sedin, JonasEricsson AB6/3Solaija, Muhammad SohaibIstanbul Medipol University; Vestel6/3Song, TaewonLG ELECTRONICS6/3Strauch, PaulQualcomm Incorporated6/3Sun, YanjunQualcomm Incorporated6/3Torab Jahromi, PayamFacebook6/3Wang, HaoTencent6/3Wang, LeiHuawei R&D USA6/3Xin, YanHuawei Technologies Co., Ltd6/3Yano, KazutoAdvanced Telecommunications Research Institute International (ATR)6/3Yee, JamesMediaTek Inc.6/3yi, yongjiangFuturewei Technologies6/3Yu, JianHuawei Technologies Co., Ltd6/3Yukawa, MitsuyoshiCanon, Inc.6/3Zhang, MeihongHuawei Technologies Co., Ltd6/3Zuo, XinTencentThe Chair reminds that the agenda can be found in 11-20/735r16. The chair asked whether there is comment about the agenda. Liwen asked to add the SPs for 0062 at the end of BA topic. The agenda is updated per the request.Submissions114r0 Block Ack Window extension(Yongho Seok)The presentation is deferred. 462r0 11be BA Indication(Po-Kai Huang)SummaryThis contribution proposes the ideas to let the A-MPDU transmitter to control the BA length in order to decrease the BA overhead.?C: originator indicates the BA bitmap size. The baseline lets the recipient of A-MPDU to decide the BA bitmap size. We should find the tradeoff between the originator and recipient. A: we have high level view here. The detail can be discussed.C: do we need SSN besides BA bitmap size?A: BAR includes SSN already. A-MPDU includes implicitly the SSN. C: how about partial BA operation?A: start with what is received. C: I am wondering whether the problem exist in TB case. The length indicated by Trigger frame implicitly give you the BA bitmap size.A: Trigger frame doesn’t indicate the BA bitmap size explicitly. But currently the BA transmitter can transmit any BA bitmap size that is no more than the negotiated BA buffer size.C: CF-End can reset NAV if smaller BA is transmitted than the Duration.A: CF-End will reset the NAV that was set by the other STAs.SP:Do you support to design a mechanism for the originator of a BlockAck negotiation of a TID to indicate to the recipient the range of reported received status of a solicited BA?if supported by the recipient, it is supported for all negotiated buffer sizes25Y, 12N, 34A294r0 11be block ack bitmap size discussion(Zhou Lan)SummaryThis contribution proposes that 1), the transmitter of A-MPDU may inform the receiver to use an arbitrary BA bitmap that is under the constrain of the negotiated buffer size; 2) if the received status of QoS Data frame of a TID received on a link is signalled on other links, then the receive status are duplicated on all the links.?C: Do you want to say that MPDU status received on a link is duplicated on another link? A: the SP from Abhi assume the BA transmitter may transmit the BA information of another link. This SP put the thing a little bit further. C: the BA information of one link may not be able to be duplicated in another link.A: the SP only assume the ending time of PPDUs is same.C: may need more time to think about it.A: ok. I don’t want to run the AP today.C: for arbitrary BA bitmap size, do you mean any size? How do you signal it?C: BA bitmap indication can’t guarantee the PPDUs ending time to be same.A: Agree MCS/rate may also have influence on the Tx time of PPDU. But if the BA bitmap sizes of different links are hugely different, it is difficult to align the end time of PPDUs.The SPs are deferred.681r1 Scoreboard operation for multilink aggregation (Huang Guogang)SummaryThis contribution proposes the Delayed shift rules of scoreboard window by using the minimal SSNs among links.?C: the responding side needs to communicate among links to acquire the WinStartR. C: similar comment.A: multiple links need to sync.C: If the SSN in one link is 500, then in the same link the SSN is 300. It is difficult to set the WinStartR of the link.C: the solution should be general enough.The SP is deferred after the discussion.061r2 BA Consideration(Liwen Chu) [SP only]SP 1After the discussion the SP 1 is changed as follows:Do you support to allow an EHT STA to use HE SU PPDU to carry the solicited BA if the transmit time of HE SU PPDU is less than the PPDU duration of a non-HT PPDU containing the Control frame sent at the primary rate?Approved with unanimous consent.SP 2After the discussion the SP 1 is changed as follows:Do you support to allow EHT SU PPDU to carry the solicited BA if the transmit time of EHT SU PPDU is less than the PPDU duration of a non-HT PPDU containing the Control frame sent at the primary rate and the soliciting PPDU is EHT PPDU?Approved with unanimous consent.Other SPs were deferred.1943r3 Multi-link Management (Taewon Song) [SP only]SP 1Do you agree to add the following text to the TGbe SFD?A non-AP MLD may send its associated AP MLD a frame to request to switch link to other link among enabled links of the AP MLD.C: would like to know the motivation of SP 1. Do you think TID to link mapping can be used?A: As far as I know, TID to link mapping is defined, but its signaling is not defined. SP1 add some detail to specify how to switch link in MLO. But agree the motivation is similar.C: My understanding is that the passed motion already covers SP 1. C: agree with the previous comment. Power save means that a STA MLD can use different links to receive frames, i.e. link switch. For long term link switch, TID to link mapping can be used.A: ok, I see your point. I will do more thinking then decide what to do. C: agree with the previous commenter.17Y, 18N, 37ASP 2Do you agree to add the following text to the TGbe SFD?An AP MLD may send an non-AP MLD a frame to request to switch a link of the non-AP MLD to other link among enabled links of the AP MLD.SP 2 is deferred. SP 3Do you agree to define the following?MLD with shared radio*: an MLD, consisting of a single radio, that can operate in multiple frequency bands/channels (e.g., 5GHz and 6GHz), but cannot transmit and receive data frame on multiple links simultaneously.Note: A specific name is TBD.Note: Capability of simultaneous transmission and reception for control frame and management frame is TBD.Note: With this definition, enhanced features (e.g., link switching and so on) could be supported to the MLD with shared radio in multi-link scenario.C: I have similar SP. It is better to defer this one.C: I understand your intention. But the wording is not clear, e.g. whether a single-radio MLD can listen to multiple links, whether the control frames are used at the beginning of the TXOP.A: agree we can do some offline discussion.C: is shared radio same as STR and NSTR.A: the shared radio can only transmit in one link at a time. This enhanced feature is similar to Minyoung’s presentation. C: Is the radio to RF or PHY? Maybe we can discuss offline.C: it is good to have offline discussion about the concept. This and another one is similar.A: agree.The SP is deferred.028r2 Indication of Multi-link Information(Insun Jang) [SP only]SummaryThe presentation discusses the format and the transmission of a newly defined element that includes a Common information and Per-link information. The new element can be in Probe/Association Request/Response, Beacon.?SP 1Do you support that an STA of an MLD provides information that is common to all STAs affiliated with the MLD and information that is specific to the STA on each link in management frames during multi-link discovery and multi-link setup?The specific information is TBDC: for ML setup, we think association request/response which include all the information of all links. It is not necessary to include all of them in Probe request/Response, Beacon etc. Some clarification is needed.A: I didn’t touch the detail about when to include common info for all links and link specific link information.C: do you want to change the SP to “define a mechanism for STA to provide…”. C: in general, discovery should be different from association. Can we focus on discovery in a SP to find the tools to carry the necessary information, RNR etc.?C: do you mean all the information?A: this means common information and link specific information.C: do you mean that MLD level information is common information?A: agree to change common information to MLD level information.C: agree with previous comment. If you remove discovery, I can support it. The RNR should be enough for discovery.A: agree to remove discovery.C: same comment as previous one to remove discovery.After the discussion, the SP is changed toDo you support that an STA of an MLD can provide MLD-level information that is common to all STAs affiliated with the MLD and per-link information that is specific to the STA on each link in management frames during multi-link setup? ?The specific information is TBD ?The SP is approved with unanimous consentSP 2Do you support that the following?Beacon, Probe Request and Probe Response frames are reused for multi-link discoveryAssociation Request and Association Response frames are reused for multi-link setupC: we already agree Association Request/Response.A: the agreed motion doesn’t mention multi-link setup.C: ok, I will support it.C: can you clarify the use of Probe request/response.A: Probe Response is used for active scanning.C: are we excluding other method, e.g. ANQP related message etc.?A: I didn’t touch other mechanism.C: add the note that other mechanism is TBD.A: ok. Do you want to reuse the other mechanism?C: I would.C: change the first bullet to “reuse the existing mechanism”C: mechanism is not good since it includes the procedure.C: We should use the existing mechanism. But we should also define the secure method also.C: the security discovery is not related to the SP.C: if you have security contribution, we would like to hear about it.The teleconference was adjourned at 01:00pm EDTThursday 4 June 2020, 10:00am – 01:00pm ET (TGbe MAC ad hoc conference call)Chairman: Jeongki Kim (LG Electronics)Secretary: Liwen Chu (NXP)This meeting took place using a webex session.IntroductionThe Chair (Jeongki, LG) calls the meeting to order at 10:04am EDT. The Chair introduces himself and the Secretary, Liwen Chu (NXP)The Chair goes through the 802 and 802.11 IPR policy and procedures and asks if there is anyone that is aware of any potentially essential patents. Nobody speaks up.The Chair recommends using IMAT for recording the attendance.Please record your attendance during the conference call by using the IMAT system: 1) login to imat, 2) select “802.11 Telecons (<Month>)” entry, 3) select “C/LM/WG802.11 Attendance” entry, 4) click “TGbe <MAC/PHY/Joint> conference call that you are attending.If you are unable to record the attendance via HYPERLINK "" IMAT then please send an e-mail to Jeongki Kim ( HYPERLINK "mailto:jeongki.kim@" jeongki.kim@) and Liwen Chu ( HYPERLINK "mailto:liwen.chu@" liwen.chu@)Recorded attendance through Imat and e-mail:6/4Aboulmagd, OsamaHuawei Technologies Co.,? Ltd6/4Adachi, TomokoTOSHIBA Corporation6/4Akhmetov, DmitryIntel Corporation6/4Asterjadhi, AlfredQualcomm Incorporated6/4Au, Kwok ShumHuawei Technologies Co.,? Ltd6/4Carney, WilliamSony Corporation6/4Cheng, PaulMediaTek Inc.6/4Chitrakar, RojanPanasonic Asia Pacific Pte Ltd.6/4Das, DibakarIntel Corporation6/4Derham, ThomasBroadcom Corporation6/4Dong, XiandongXiaomi Inc.6/4Ghosh, ChittabrataIntel Corporation6/4Guo, YuchenHuawei Technologies Co., Ltd6/4Han, ZhiqiangZTE Corporation6/4Ho, DuncanQualcomm Incorporated6/4Hsu, Chien-FangMediaTek Inc.6/4Hu, ChunyuFacebook6/4Huang, Guogang?Huawei6/4Huang, Po-KaiIntel Corporation6/4Inohiza, HirohikoCanon Inc.6/4Jiang, JinjingApple, Inc.6/4Jung, hyojinHyundai Motor Company6/4Kandala, SrinivasSAMSUNG6/4Kedem, OrenHuawei Technologies Co. Ltd6/4kim, namyeongLG ELECTRONICS6/4Kim, Sang GookLG ELECTRONICS6/4Kim, SanghyunWILUS Inc6/4Kishida, AkiraNippon Telegraph and Telephone Corporation (NTT)6/4Ko, GeonjungWILUS Inc.6/4Kwon, Young HoonNXP Semiconductors6/4Li, YiqingHuawei Technologies Co. Ltd6/4Li, YunboHuawei Technologies Co., Ltd6/4Lu, LiumingZTE Corporation6/4Lv, kaiyingMediaTek Inc.6/4NANDAGOPALAN, SAI SHANKARCypress Semiconductor Corporation6/4Naribole, SharanSAMSUNG6/4Nezou, PatriceCanon Research Centre France6/4Ouchi, MasatomoCanon6/4Park, Sung-jinLG ELECTRONICS6/4Patil, AbhishekQualcomm Incorporated6/4Patwardhan, GauravHewlett Packard Enterprise6/4Raissinia, AlirezaQualcomm Incorporated6/4Seok, YonghoMediaTek Inc.6/4Son, Ju-HyungWILUS Inc.6/4Song, TaewonLG ELECTRONICS6/4Sun, Li-HsiangInterDigital, Inc.6/4Torab Jahromi, PayamFacebook6/4Wang, Chao ChunMediaTek Inc.6/4Wang, HuizhaoQuantenna Communications, Inc.6/4Wang, LeiHuawei R&D USA6/4Yano, KazutoAdvanced Telecommunications Research Institute International (ATR)6/4Yee, JamesMediaTek Inc.6/4Yukawa, MitsuyoshiCanon, Inc.6/4Zuo, XinTencent.The Chair reminds that the agenda can be found in 11-20/735r18. The chair asked whether there is comment about the agenda. Liwen asked to add the SPs for 0062 at the end of BA topic. Harry asked to add his SP in 11-20/512r3 to the agenda. The agenda is updated per the request.Submissions0512r3 Indication of Multi-link Information (Insun Jang) [SP only]SP 1Should 11be consider a mechanism to configure the Link addresses of the MLDs within a BSS?Note: the link address is the MAC address assigned for each STA affiliated with a MLD.C: one AP creates one BSS. Multiple APs of AP MLD create mulple BSSs.A: I mean multi-link BSS. C: multi-link BSS is not in FRDA: I can remove it.C: have you through about interact with other group about address assignment?A: In that group, the address is randomly selected. Here we don’t want totally randomly select the link address.After the discussion the SP was changed toShould 11be consider a mechanism to configure the Link addresses of the MLDs?Note: the link address is the MAC address assigned for each STA affiliated with a MLD.16Y, 25N, 32A.SP 2Should AP MLD assign link address for each AP affiliated with AP MLD?19Y, 28N, 27ASP 3May the link addresses assignment in a Non-AP MLD be assisted by AP-MLD?14Y, 34N, 24A028r5 Indication of Multi-link Information (Insun Jang) [SP only]SP 2. Do you support that the following?Existing frames are reused for multi-link discovery Association Request and Association Response frames are reused for multi-link setupNOTE: New signaling to query AP link specific parameters or AP MLD parameters by using Protected Management Frames (PMF) encrypted Management frames is TBDC: For the added note, it sounds like a proposal. Do we need to add this note? Do you agree that with or without this note, the SP doesn’t change?C: I would like to add the note to keep this topic open.C: the SP just say to use the current frame. The new information can be added to the current frames.C: generally good with this, do we have multi-link discovery? I assume what you mean is to use the current frame to discover the APs that are affiliated with the AP MLD or discover the AP MLD.C: 11az defines pre-association security. C: I mean post-association. If you want to add pre-association, I am open to it.C: 11az include PMF for pre-association.C: fine to add post-association.After the discussion, the SP was changed toDo you support that the following? ?Existing frames are reused for discovering APs that are affiliated with AP MLD ?Association Request and Association Response frames are reused for multi-link setup ?NOTE: After association, new signaling to query AP link specific parameters or AP MLD parameters by using Protected Management Frames (PMF) encrypted Management frames is TBD ?The AP was approved with unanimous consent 030r6 Multi-link Association Follow UP(Guogang Huang) [SP only]SP 3Do you support that the MLD info shall be carried in a newly defined element which has a MLD common info subfield and a non-transmitted STA profile sub-field?The non-transmitted STA profile sub-field contains a list of non-transmitted STA profiles for one or more non-transmitted STAs For each non-transmitted STA, non-transmitted STA profile contains a link identifier field and a variable number of elements??????????? For each non-transmitted STA, an element is carried in a non-transmitted STA profile only when it has different content from transmitted STAC: I have SPs similar to this. The profile can be inherited or absent. For the second bullet, it is covered by other SPs. If you can defer the SP it is nice. Or at least defer bullet 2 and 3.A: remove the 3rd is fine.C: generally, we are aligned. Probably we need more discussion, e.g. Common Info may not be carried, Per Link Info may not be needed.A: can you clarify why the common info is not needed?C: that is why I want to defer the SP. You may change to “may include Common Info” and “may include per link info”. After the discussion, the SP is deferred.226r5 MLO Constraint Ind. and Operating Mode(Sharan Naribole) The presentation inclues multiple topics. The author focus on link management topic in the presentation in this session.C: Question to SP 5. I assume we already agreed each side can reject the TID to link mapping request.A: We are trying to highlight that AP MLD shall not reject the request.C: If you look at AP MLD side, whether to reject or not should be treated same as STA MLD side.C: similar comment. TID to link mapping is used to enable/disable link. Other things can be done through pwoer save mechanism. So other simplified enable/disable is not needed.A: I don’t find anything in SFD cover the other things. I don’t think they should be coupled with pwoer save.C: slide 12, OM Control in link a disable link b. Why not to transmit enable/disble in its own link?A: we don’t preclude it. This is just an example. Another observation is that if one link is busy, using anotherlink to transmit crosslink information avoid the delay.The SP was deferred.337r2 Multi-link BSS Parameter Update (Yongho Seok) SummaryThe presentation discusses that when the BSS parameter of the link on which the a non-AP MLD does not monitor is updated, an AP MLD announces a change of system information related with the BSS of other link.?C: question to SP 1, why do you define the initial value of Change Sequence to be 0?A: This is baseline behavior.C: all the links have the same values?A: I don’t know whether we need to have different initial values.C: are we updating separately for each link?A: they are independently updated.C: initialize means when the AP is bootup?A: yes.C: have similar presentation. I support this idea. To the previous comment, the initial values of different links are same. But later the values in different links are different.C: it is in line with my presentation. The SP is a little bit unclear. I assume what you mean is that each change sequence is for one AP.C: do we need shall for Probe Request? It is better to reuse Beacon for such operation.A: The baseline mandates one method. We should follow it. And I prefer Beacon.C: This is in line with my method.C: it is good idea. Trying to understand the assumption of the presentation. IS this because of the power save in STA MLD side?A: yes. STA in another link of STA MLD may be in power save mode. SP 1Do you support that an AP within an AP MLD shall include in the Beacon and Probe Response frames it transmits the Change Sequence fields that indicate changes of system information for other APs within the same AP MLD, where the change sequence field value for the reported AP is initialized to 0, that increments as the critical update of the reported AP is occurred?The signaling of the Change Sequence field is TBD.The critical updates are defined in 11.2.3.15 TIM Broadcast and the additional update can be added if needed.Approved with uanimous consent.356r1 MLO: Discovery and beacon-bloating(Abhishek Patil) SummaryThis contribution discusses the topic of multi-link capability advertisement and provides a flexible framework to carry MLO information.?C: like the concept. Can we also say that RNR should be included?A: I have another contribution mentioned RNR.C: I have similar comment. I assume we should define what is the mandatory information to be included in Probe Request, Beacon etc.A: For the mandatory information we may have different view. But generally, we are in line.C: Regarding the partial info, one is through RNR, another is through ML element? Which one is your preference?A: let us discuss the signaling detail later.C: for SP 1, the previous presentation also proposes the common info and per link info. Do you think Common Info and Per link info should be all included?A: this SP just discuss the framework.C: We should reuse RNR as much as possible to avoid beacon bloating. A: I agree to avoid beacon bloating. Some common information for all APs may not be able to be added in RNR.C: I believe in general we can do per link scanning?A: this can burn the STA MLD’s power.C: we can reuse something of outof band discovery.C: for Beacon, we should be very careful about what to be added?A: we are in same page.386r0 Multi link association follow up(Young Hoon Kwon) SummaryThis contribution discusses the multi-link resetup mechanism to resetup with another AP MLD or changing configuration of existing multi-link setup with an AP MLD.?C: I think the presentation makes sense. Reuse the current frames is good.C: multi-link device, I just want to remove two links to another AP MLD. Is there any problem?A: In my case this means tear down some links.C: instead of removing links, do you want to avoid discontinuity?A: you can add link and delete link by using link enable/disable.C: what happen to the first AP MLD? Are you saying it is just disable of the link?C: based on your contribution, multi-link resetup is reassociation.C: add another bullet reuse reassociation request/response.A: ok to add it.C: fast BSS transition should also be applied.The teleconference was adjourned at 01:00pm EDTMonday 8 June 2020, 07:00pm –10:00pm ET (TGbe MAC ad hoc conference call)Chairman: Jeongki Kim (LG Electronics)Secretary: Liwen Chu (NXP)This meeting took place using a webex session.IntroductionThe Chair (Jeongki, LG) calls the meeting to order at 10:04am EDT. The Chair introduces himself and the Secretary, Liwen Chu (NXP)The Chair goes through the 802 and 802.11 IPR policy and procedures and asks if there is anyone that is aware of any potentially essential patents. Nobody speaks up.The Chair recommends using IMAT for recording the attendance.Please record your attendance during the conference call by using the IMAT system: 1) login to imat, 2) select “802.11 Telecons (<Month>)” entry, 3) select “C/LM/WG802.11 Attendance” entry, 4) click “TGbe <MAC/PHY/Joint> conference call that you are attending.If you are unable to record the attendance via IMAT then please send an e-mail to Jeongki Kim ( HYPERLINK "mailto:jeongki.kim@" jeongki.kim@) and Liwen Chu ( HYPERLINK "mailto:liwen.chu@" liwen.chu@)Recorded attendance through Imat and e-mail:Adachi, TomokoTOSHIBA CorporationAkhmetov, DmitryIntel CorporationAsterjadhi, AlfredQualcomm IncorporatedAu, Kwok ShumHuawei Technologies Co., Ltdbaron, stephaneCanon Research Centre FranceCarney, WilliamSony CorporationCheng, PaulMediaTek Inc.Chitrakar, RojanPanasonic Asia Pacific Pte Ltd.Das, DibakarIntel CorporationDas, SubirPerspecta Labs Inc.Derham, ThomasBroadcom CorporationDing, BaokunHuawei Technologies Co. LtdFang, YonggangZTE TX IncFischer, MatthewBroadcom CorporationHamilton, MarkRuckus/CommScopeHo, DuncanQualcomm IncorporatedHsu, Chien-FangMediaTek Inc.Hu, ChunyuFacebookHuang, Po-KaiIntel CorporationInohiza, HirohikoCanon Inc.Jang, InsunLG ELECTRONICSJiang, JinjingApple, Inc.Jung, hyojinHyundai Motor CompanyKain, CarlUSDoTkim, namyeongLG ELECTRONICSKim, Sang GookLG ELECTRONICSKim, SanghyunWILUS IncKim, YonghoKorea National University of TransportationKishida, AkiraNippon Telegraph and Telephone Corporation (NTT)Kneckt, JarkkoApple, Inc.Ko, GeonjungWILUS Inc.Kondo, YoshihisaAdvanced Telecommunications Research Institute International (ATR)Kwon, Young HoonNXP SemiconductorsLevy, JosephInterDigital, Inc.Li, YiqingHuawei Technologies Co. LtdLv, kaiyingMediaTek Inc.Monajemi, PooyaCisco Systems, Inc.NANDAGOPALAN, SAI SHANKARCypress Semiconductor CorporationOuchi, MasatomoCanonPark, MinyoungIntel CorporationPark, Sung-jinLG ELECTRONICSPatil, AbhishekQualcomm IncorporatedPatwardhan, GauravHewlett Packard EnterpriseRaissinia, AlirezaQualcomm IncorporatedSeok, YonghoMediaTek Inc.Son, Ju-HyungWILUS Inc.Song, TaewonLG ELECTRONICSSun, YanjunQualcomm IncorporatedTanaka, YusukeSony CorporationTorab Jahromi, PayamFacebookWang, Chao ChunMediaTek Inc.Wang, HaoTencentWang, HuizhaoQuantenna Communications, Inc.Wang, LeiHuawei R&D USAWang, QiApple, Inc.Wang, XiaofeiInterDigital, Inc.Yang, JayNokiaYano, KazutoAdvanced Telecommunications Research Institute International (ATR)Yee, JamesMediaTek Inc.Yukawa, MitsuyoshiCanon, Inc.Zhang, MeihongHuawei Technologies Co., LtdThe Chair reminds that the agenda can be found in 11-20/735r19. The chair asked whether there is comment about the agenda. Jarkko mentioned his submitted contribution about the ML managment. Chair aksed him to make reuqest then it can be added.Submissions434r4 Multi-link Secured Retransmissions (Rojan Chitrakar) [SP only]SP 1Do you agree to revise Motion 61 of the 11be SFD as follows:The established block ack agreement allows the QoS Data frames of the TID, aggregated within the A-MPDUs, to be exchanged between the two MLDs on any available link.Note – QoS Data frames that are not fragments might be retransmitted on any available link.Approved with unanimous consent386r1 Multi link association follow up (Young Hoon Kwon) [SP only]SP 1Do you agree to add the following to 11be SFD:TGbe shall define a multi-link resetup mechanism to resetup with another AP MLD or changing configuration of existing multi-link setup with an AP MLD.Reassociation Request/Response frame is used for this purpose.C: some concern for attribute change.A: we can do attribute change without reassociation.C: we have 11r FT. Is this similar to 11r mechanism.A: 11r also uses reassociation.C: do you have anything related to 11r feature?A: no.C: clarification. The word is too broad. It is not clear whether your proposal in line with multi-link management (e.g. power management of multiple links) or resetup?A: I just use the similar word in 802.11 baseline.C: Support the SP. Still have similar with the previous commenter. Clarification question of second part of SP, e.g. security issue. A: just want to follow the current rules. The security will need further discussion.Approved with unanimous consentSP 2Do you agree to add the following to 11be SFD:When a non-AP MLD that has multi-link setup with current AP MLD sends a Reassociation Request frame to either a new AP or a new AP MLD, AP MLD MAC address of the current AP MLD is used in Current AP Address field of the frame.C: do you mean address 1 for AP address?A: it is a different field.C: when you say a new AP, do you mean just an AP?A: when I say a new AP, it means a legacy AP.35Y, 7N, 20AThere are some concerns about adding a new AP to the AP. SP 2 is amended and run with the following text:Do you agree to add the following to 11be SFD:When a non-AP MLD that has multi-link setup with current AP MLD sends a Reassociation Request frame to a new AP MLD, AP MLD MAC address of the current AP MLD is used in Current AP Address field of the frame.46Y, 3N, 19A387r3 Multi-link setup follow up II(Po-Kai Huang) SummaryThis contribution proposes 1), to allow only one STA in MLD framework, 2) to reuse current container for setup, resetup, teardown, authentication, 3) to clarify MLD address indication under SAE method.?C: slide 4. Right hand side, can you clarify in which case AP MLD has only one STA?A: I don’t want to exclude it. As a framework we want the flexibility.C: I am struggling about the difference between baseline association and the cases in slide 4.A: As I mentioned, the framework just wants to be as flexible as possible.C: slide 7. Non-AP MLD can setup link1 and link2. Why do you do resetup for the new link.A: it is discussed in other presentation. This is not straw polled here.C: we have long debate. You bring one STA again. Single radio STA and multiple radio STA MLD are totally different.A: As I mentioned, the framework just wants to be as flexible as possible.C: for conclusion, the statement of the first bullet is confusing. the overall idea is to reuse the container whenever is applicable. In mind it may need some new change for such single link STA.A: we think to reuse the framework is right way to go.C: general support of this.C: support this also.SP 1:Do you support the following? ?Reuse disassociation frame for multi-link teardown ?Reuse authentication frame for multi-link SAE exchange and multi-link Open System authentication ?Approved with unanimous consentSP 2:Do you support the following?An AP that is part of an AP MLD that supports SAE authentication shall include the MLD address in beacon and probe response frames it transmits.EHT MLD shall indicate its MLD MAC address during authentication request/response exchangeSame link is used for authentication request/response exchange and multi-link setup request/response exchangeC: in this case, if the MLD address is different from address for authentication, then the address filter will need more consideration.A: the same link is used before the association.C: during the authentication, the link address where the authentication is done is not used in authentication procedure.A: authentication is not be protected anyway.C: the last point why do you want to mandate the same?A: there is no multi-link before association.C: the authentication is just used for acquire PMK. I am fine the first two bullets.C: same point as previous comment.After the discussion, the first two bullets are kept.Updated SP 2:Do you support the following? ?An AP that is part of an AP MLD that supports SAE authentication shall include the MLD address in beacon and probe response frames it transmits. ?EHT MLD shall indicate its MLD MAC address during authentication request/response exchange ?Approved with unanimous consent389r1 Multi-link Discovery part 1(Laurent Cariou) SummaryThis contribution discusses 1), to decrease beacon bloating by carrying only the necessary information in Beacon, 2), to use RNR as much as possible.?C: question about STA probing one AP to get all other APs. For STA MLD, 2.4 GHz radio always stay in 2.4 band, one radio switches between 5/6GHz. There is no need for 2.4 GHz to get 5/6GHz information. And 5/6GHz link is not needed to get 2.4GHz information.A: The Probe Request to request another link information can be further discussed. C: under some scenario, it is not necessary to get all links’ information through one link.C: what is usefulness for TBTT to be carried?A: TBTT is for receive beacon in other links.C: slide 5, agreed that RNR provide basic information. What is the other thing to add in RNR?A: e.g. critical information indication. MAC address for security in Probe Request/Response.C: agree the minimal information. But should further discuss the detail about which information is added.C: SP 1 should be for reporting AP being transmitted BSSID or not support multiple BSSID.A: agreed.After the discussion, SP 1 is deferred.C: question for SP 2, the indication is a special case of BSSID index.A: this is a concept. Can add the note that the signaling is TBD.All SPs were deferred per the request.390 r3 Multi-link Discovery part 2(Laurent Cariou) SummaryThis contribution discusses the inheritance for AP information of the reported APs without multi-BSSID support or with multi-BSSID support.?C: slide 4, why ML element is not carried in Beacon or Probe Response?A: I didn’t say ML element is never transmitted in Beacon, Probe Response.C: In your proposal RNR is used as primary method. ML element is additional if required. ML element is much easier to carry the information. What is your thought on that?A: 11ax is trying to speed the scan by using RNR. Here is same spirit. RNR is used for carrying the basic information.C: agree that RNR is simple. The difference is that 11ax doesn’t allow more than link association.The SPs were deferred per the request.392r0 MLD Max Idle period(Laurent Cariou) SummaryThis contribution proposes that one Max Idle period is applied to non-AP MLD level.?C: is this necessary for AP MLD to have same max idle period. Once 2.4GHz band is IoT, it should have longer max idle period.A: we can have different max idle period for legacy STA and EHT STA MLD.C: what I propose is to have different max idle periods for different APs. C: agree with previous commenter. We should not mandate same max idle period for all APs.C: which side initiates the keeping alive? A: keep alive is initiated by STA.The teleconference was adjourned at 10:00pm EDTWednesday 10 June 2020, 10:00am – 01:00pm ET (TGbe MAC ad hoc conference call)Chairman: Jeongki Kim (LG Electronics)Secretary: Liwen Chu (NXP)This meeting took place using a webex session.IntroductionThe Chair (Jeongki, LG) calls the meeting to order at 10:04am EDT. The Chair introduces himself and the Secretary, Liwen Chu (NXP)The Chair goes through the 802 and 802.11 IPR policy and procedures and asks if there is anyone that is aware of any potentially essential patents. Nobody speaks up.The Chair recommends using IMAT for recording the attendance.Please record your attendance during the conference call by using the IMAT system: 1) login to imat, 2) select “802.11 Telecons (<Month>)” entry, 3) select “C/LM/WG802.11 Attendance” entry, 4) click “TGbe <MAC/PHY/Joint> conference call that you are attending.If you are unable to record the attendance via HYPERLINK "" IMAT then please send an e-mail to Jeongki Kim ( HYPERLINK "mailto:jeongki.kim@" jeongki.kim@) and Liwen Chu ( HYPERLINK "mailto:liwen.chu@" liwen.chu@)Recorded attendance through Imat and e-mail:Adhikari, ShubhodeepBroadcom CorporationAkhmetov, DmitryIntel CorporationAsterjadhi, AlfredQualcomm IncorporatedAu, Kwok ShumHuawei Technologies Co., Ltdbaron, stephaneCanon Research Centre FranceBoldy, DavidBroadcom CorporationBredewoud, AlbertBroadcom CorporationCarney, WilliamSony CorporationCheng, PaulMediaTek Inc.CHERIAN, GEORGEQualcomm IncorporatedChitrakar, RojanPanasonic Asia Pacific Pte Ltd.Choi, JinsooLG ELECTRONICSCoffey, JohnRealtek Semiconductor Corp.Das, SubirPerspecta Labs Inc.DeLaOlivaDelgado, AntonioInterDigital, Inc.Derham, ThomasBroadcom Corporationde Vegt, RolfQualcomm IncorporatedDong, XiandongXiaomi Inc.ElSherif, AhmedQualcomm IncorporatedFang, YonggangZTE TX IncGarg, LalitBroadcom CorporationGuo, YuchenHuawei Technologies Co., LtdHan, ZhiqiangZTE CorporationHo, DuncanQualcomm IncorporatedHsu, Chien-FangMediaTek Inc.Hu, ChunyuFacebookHu, MengshiHUAWEIHuang, Guogang HuaweiHuang, Po-KaiIntel CorporationInohiza, HirohikoCanon Inc.Inoue, YasuhikoNippon Telegraph and Telephone Corporation (NTT)Jang, InsunLG ELECTRONICSJiang, JinjingApple, Inc.Kain, CarlUSDoTKakani, NaveenQualcomm IncorporatedKandala, SrinivasSAMSUNGKim, Sang GookLG ELECTRONICSKim, SanghyunWILUS IncKishida, AkiraNippon Telegraph and Telephone Corporation (NTT)Kneckt, JarkkoApple, Inc.Ko, GeonjungWILUS Inc.Kondo, YoshihisaAdvanced Telecommunications Research Institute International (ATR)Kwon, Young HoonNXP SemiconductorsLalam, MassinissaSAGEMCOM BROADBAND SASLevy, JosephInterDigital, Inc.Li, YiqingHuawei Technologies Co. LtdLi, YunboHuawei Technologies Co., LtdLou, HanqingInterDigital, Inc.Lu, LiumingZTE CorporationLv, kaiyingMediaTek Inc.Madpuwar, GirishBroadcom CorporationMirfakhraei, KhashayarCisco Systems, Inc.Monajemi, PooyaCisco Systems, Inc.Montreuil, LeoBroadcom CorporationNANDAGOPALAN, SAI SHANKARCypress Semiconductor CorporationOuchi, MasatomoCanonPalm, StephenBroadcom CorporationPark, MinyoungIntel CorporationPark, Sung-jinLG ELECTRONICSPatil, AbhishekQualcomm IncorporatedPatwardhan, GauravHewlett Packard EnterprisePuducheri, SrinathBroadcom CorporationRaissinia, AlirezaQualcomm IncorporatedRISON, MarkSamsung Cambridge Solution CentreSeok, YonghoMediaTek Inc.Solaija, Muhammad SohaibIstanbul Medipol University; VestelSong, TaewonLG ELECTRONICSStacey, RobertIntel CorporationStrauch, PaulQualcomm IncorporatedSUH, JUNG HOONHuawei Technologies Co. LtdSun, BoZTE CorporationSun, YanjunQualcomm IncorporatedTorab Jahromi, PayamFacebookVerma, SindhuBroadcom CorporationVIGER, PascalCanon Research Centre FranceWang, Chao ChunMediaTek Inc.Wang, HuizhaoQuantenna Communications, Inc.Wang, LeiHuawei R&D USAWang, QiApple, Inc.Wentink, MenzoQualcommWullert, JohnPerspecta LabsYANG, RUIInterDigital, Inc.Yee, JamesMediaTek Inc.yi, yongjiangFuturewei TechnologiesYoung, ChristopherBroadcom CorporationYu, JianHuawei Technologies Co., LtdThe Chair reminds that the agenda can be found in 11-20/735r21. The chair asked whether there is comment about the agenda. The following were requested: deferred SP in 1943r5, deferred SPs in 356r2, deferred SP 386r3. Question: are you willing to add the new submitted contribution? There are the concerns and discussions about the other documents can’t be discussed if the new documents are kept adding. After the discussion, 865, 659 were not in the agenda. Submissions463r3 Priority Access Support Options for NS/EP Services(Subir Das) [1 SP]SP 1Do you support the addition of following text to TGbe SFD? The NS/EP Priority Service if supported by a non-AP STA, shall use a TID value >7 to indicate the need for priority access to AP STANote: The identification of the need is outside the scope of this specification. Note: The container of the TID is TBD.C: add TBD after “shall use a TID value” .A: ok.C: if we have a specific TID for NS/EP, do we have security issue, e.g. identify NS/EP once the TID is figured out?A: only when the network is congested, this will be used.After the discussion the SP was changed toDo you support the addition of following text to TGbe SFD? ?The NS/EP Priority Service if supported by a non-AP STA, shall use a TID value (TBD) that is greater than 7 to indicate the need for priority access to its associated AP STA ?Note: The identification of the need is outside the scope of this specification. ?Note: The container of the TID is TBD. ?40Y, 12N, 41A1943r5 Multi-link Management (Taewon Song) [SP only]SP 3Do you agree to define the following?Single-link non-AP MLD: A non-AP MLD that transmits or receives frames to/from another MLD on a single link at a time.C: what is the motivation that it is called single-link non-AP MLD? A: the motivation is that the MLD has single link that can be switch among links.C: do you assume CCA on multiple link in your SP?A: Whether it allows CCA in multiple links is not mentioned in SP.C: Intel’s presentation is about enhanced single link MLD. What is the difference between them?A: What I proposed is that the single radio can’t do CCA in multiple links.C: This is just naming issue. Some people like single-radio, some people like single-link.C: is the frame in the SP the non-control frame?A: we don’t any capability about sensing.37Y, 21N, 37A562r2 Enhanced Multi-Link Single Radio Operation (Minyoung Park) [SP only]SP 2Do you support the concept of the multi-link operation for an enhanced single-link non-AP MLD that is defined as follows for R1?An MLD that can: 1) transmit or receive data/management frames to another MLD on one link, and 2) listening on one or more links.The “listening” operation includes CCA as well as receiving initial control messages (e.g., RTS/MU-RTS)Link switch delay may be indicated by the non-AP MLDC: “single-link” is not good word. “Single-radio” is better.A: can add name TBD.C: concern of receiving control frame in more than one link. This has same as other type of device.A: the performance is better. If only control frames are received in multiple radio, the complexity decreased.C: in general, support this in R1, but more discussion/analysis should be done. This should be able to be extended to two-radio case.C: we think this is useful scheme.After the discussion, the SP becomes:Do you support the concept of the multi-link operation for an enhanced single-link/radio (TBD) non-AP MLD that is defined as follows for R1? ?An MLD that can: 1) transmit or receive data/management frames to another MLD on one link, and 2) listening on one or more links. ?The “listening” operation includes CCA as well as receiving initial control messages (e.g., RTS/MU-RTS) ?Link switch delay may be indicated by the non-AP MLD ?56Y, 23N, 16A 356r2 MLO Discovery Signalling (Abhishek Patil) [SP only]SP 1Do you agree to define mechanism(s) to include MLO information that a STA of an MLD provides in its mgmt. frames, during discovery and ML setup, as described below? MLD (common) Information Information common to all the STAs of the MLDPer-link information Capabilities and Operational parameter of other STAs of the MLD other than the advertising STANote: The condition under which a STA of a non-AP MLD includes MLO information in its Probe Request frame is TBDC: some concern about putting more information in Probe Request/Response because of security.A: a note is added about TBD.C: you don’t talk about container. Just general concept. Don’t understand why a note about Probe Request of TBD is added.A: signaling is not covered in this presentation. I am open about when and where to carry the information.C: the note about TBD should be removed.After the discussion, the SP is changed toDo you agree to define mechanism(s) to include MLO information that a STA of an MLD provides in its mgmt. frames, during discovery and ML setup, as described below? MLD (common) Information Information common to all the STAs of the MLDPer-link information Capabilities and Operational parameter of other STAs of the MLD other than the advertising STA54Y, 17N, 21ASP 2:Do you support that the MLO framework should follow an inheritance model when advertising complete information of other links? Note: inheritance mechanism is similar to that defined in 11ax for multiple BSSID featureFor example, if an element is not carried in the profile for a link, the value of the element is the same as that of the advertising linkC: we agree the inheritance. But the inheritance is not always used.A: agree. I can remove the note if there is concern about the note.C: does it include all or one?A: it should be one or more per the request.After the discussion, the SP becomes:Do you support that the MLO framework should follow an inheritance model when advertising complete information of other link(s)? ?Note: inheritance mechanism is similar to that defined in 11ax for multiple BSSID feature Approved with unanimous consentSP 3Do you support that an AP of an AP MLD may advertise complete or partial information of other links when possible?Partial information to prevent frame bloatingFor example, frames exchanged during ML setup are expected to carry complete information while Beacon frame is expected to carry partial informationThe exact set of elements/fields that constitute partial information is TBD ?C: more information may be needed for deciding the association.C: same concern. C: do you mean that MLD may be advertised? A: this is high level concept.After the discussion, the SP is changed toDo you support that 11be shall define mechanism(s) for an AP of an AP MLD to advertise complete or partial information of other links? ?Partial information to prevent frame bloating ?For example, frames exchanged during ML setup are expected to carry complete information while Beacon frame is expected to carry partial information ?The exact set of elements/fields that constitute partial information is TBD ? ?54Y, 5N, 25ASP 4Do you support that a STA of non-AP MLD shall include in its Probe Request an indication that it supports MLO operation?Note: Exact signaling TBDC: more discussion is required for this one and SP 5.A: the intention is that if the Probe request is not from STA MLD, the MLO information from AP MLD is not necessary.C: All Probe Request includes RNR. We should define MLD Probe Request.C: big concern about Probe request to request information for other links because of security issue.SP 4 and 5 are deferred386r3 Multi-link Association Follow Up (Young Hoon Kwon) [SP only]SP 3Do you agree to add the following to 11be SFD:When a STA of a non-AP MLD that has multi-link setup with current AP MLD sends a Reassociation Request frame to a new AP, AP MLD MAC address of the current AP MLD is used in Current AP Address field of the frame.Note: Only the STA that sends the Reassociation Request frame can associate with the new AP.C: add new AP not affiliated with AP MLD.A: ok.C: the STA that has STA MLD address can do this?A: we don’t have such restriction.After the discussion, the SP is changed toDo you agree to add the following to 11be SFD: ?When a STA of a non-AP MLD that has multi-link setup with current AP MLD sends a Reassociation Request frame to a new AP that is not affiliated with an AP MLD, AP MLD MAC address of the current AP MLD is used in Current AP Address field of the frame. ?Note: Only the STA that sends the Reassociation Request frame can associate with the new AP. ?43Y, 5N, 24A395r3 Beaconing, capability, operation parameter(Liwen Chu)SummaryThis contribution discusses the method to decrease overhead of transmitting multi-link information of AP/STA MLD.?The teleconference was adjourned at 01:00pm EDTMonday 15 June 2020, 10:00am – 01:00pm ET (TGbe MAC ad hoc conference call)Chairman: Jeongki Kim (LG Electronics)Secretary: Liwen Chu (NXP)This meeting took place using a webex session.IntroductionThe Chair (Jeongki, LG) calls the meeting to order at 10:04am EDT. The Chair introduces himself and the Secretary, Liwen Chu (NXP)The Chair goes through the 802 and 802.11 IPR policy and procedures and asks if there is anyone that is aware of any potentially essential patents. Nobody speaks up.The Chair recommends using IMAT for recording the attendance.Please record your attendance during the conference call by using the IMAT system: 1) login to imat, 2) select “802.11 Telecons (<Month>)” entry, 3) select “C/LM/WG802.11 Attendance” entry, 4) click “TGbe <MAC/PHY/Joint> conference call that you are attending.If you are unable to record the attendance via HYPERLINK "" IMAT then please send an e-mail to Jeongki Kim ( HYPERLINK "mailto:jeongki.kim@" jeongki.kim@) and Liwen Chu ( HYPERLINK "mailto:liwen.chu@" liwen.chu@)Recorded attendance through Imat and e-mail:Adhikari, ShubhodeepBroadcom CorporationAkhmetov, DmitryIntel CorporationAndersdotter, AmeliaNone - Self-fundedAnsley, CarolCommScopeAsterjadhi, AlfredQualcomm IncorporatedAu, Kwok ShumHuawei Technologies Co., Ltdbaron, stephaneCanon Research Centre FranceBei, JianweiNXP SemiconductorsBredewoud, AlbertBroadcom CorporationCarney, WilliamSony CorporationCheng, PaulMediaTek Inc.CHERIAN, GEORGEQualcomm IncorporatedChitrakar, RojanPanasonic Asia Pacific Pte Ltd.Coffey, JohnRealtek Semiconductor Corp.Das, DibakarIntel CorporationDas, SubirPerspecta Labs Inc.DeLaOlivaDelgado, AntonioInterDigital, Inc.Derham, ThomasBroadcom Corporationde Vegt, RolfQualcomm IncorporatedDing, BaokunHuawei Technologies Co. LtdFang, YonggangZTE TX IncFischer, MatthewBroadcom CorporationGan, MingHuawei Technologies Co., LtdGhosh, ChittabrataIntel CorporationGuo, YuchenHuawei Technologies Co., LtdHan, JonghunSAMSUNGHan, ZhiqiangZTE CorporationHervieu, LiliCable Television Laboratories Inc. (CableLabs)Ho, DuncanQualcomm IncorporatedHsu, Chien-FangMediaTek Inc.Hu, ChunyuFacebookHu, MengshiHUAWEIHwang, Sung HyunElectronics and Telecommunications Research Institute (ETRI)Inohiza, HirohikoCanon Inc.Ji, ChenheHuawei Technologies Co. LtdJiang, JinjingApple, Inc.Kain, CarlUSDoTKakani, NaveenQualcomm IncorporatedKandala, SrinivasSAMSUNGkim, namyeongLG ELECTRONICSKim, Sang GookLG ELECTRONICSKishida, AkiraNippon Telegraph and Telephone Corporation (NTT)Klein, ArikHuawei Technologies Co. LtdKondo, YoshihisaAdvanced Telecommunications Research Institute International (ATR)Lalam, MassinissaSAGEMCOM BROADBAND SASLevitsky, IlyaIITP RASLevy, JosephInterDigital, Inc.Li, YiqingHuawei Technologies Co. LtdLi, YunboHuawei Technologies Co., LtdLiang, dandanHuawei Technologies Co., LtdLiu, YongApple, Inc.Lu, LiumingZTE CorporationLv, kaiyingMediaTek Inc.Mirfakhraei, KhashayarCisco Systems, Inc.Monajemi, PooyaCisco Systems, Inc.NANDAGOPALAN, SAI SHANKARCypress Semiconductor CorporationNezou, PatriceCanon Research Centre FranceOuchi, MasatomoCanonPark, MinyoungIntel CorporationPark, Sung-jinLG ELECTRONICSPatil, AbhishekQualcomm IncorporatedPatwardhan, GauravHewlett Packard EnterprisePetrick, AlbertInterDigital, Inc.RISON, MarkSamsung Cambridge Solution CentreSedin, JonasEricsson ABSeok, YonghoMediaTek Inc.Shilo, ShimiHUAWEISolaija, Muhammad SohaibIstanbul Medipol University; VestelSong, TaewonLG ELECTRONICSSUH, JUNG HOONHuawei Technologies Co. LtdSun, YanjunQualcomm IncorporatedTorab Jahromi, PayamFacebookVerma, SindhuBroadcom CorporationVIGER, PascalCanon Research Centre FranceWang, Chao ChunMediaTek Inc.Wang, LeiHuawei R&D USAWang, QiApple, Inc.Wang, XiaofeiInterDigital, Inc.Wentink, MenzoQualcommXin, YanHuawei Technologies Co., LtdYang, JayNokiaYano, KazutoAdvanced Telecommunications Research Institute International (ATR)Yu, JianHuawei Technologies Co., LtdThe Chair reminds that the agenda can be found in 11-20/735r23 with the additional SPs requested through emails. The chair asked whether there is comment about the agenda. There is no further discussion. The agenda was approved. Submissions432r1 Bug Fix for Acknowledgement rule in Multi-link (Yunbo Li) [SP only] Deferred because of login issue.389r2 Multi-Link Discovery – part 1 (Laurent Cariou) [SP only]SP1 Do you agree that all APs that are part of the same MLD as a reporting AP and that are collocated with the reporting AP shall be reported in the RNR element that is included in the beacons and the broadcast probe responses transmitted by the reporting AP when the reporting AP is either not part of a multiple BSSID set or corresponds to a transmitted BSSID in a multiple BSSID set. ?Do you agree that all APs that are part of the same MLD as a non-transmitted BSSID and that are collocated with the non-transmitted BSSID shall be reported in the RNR element that is included in the beacons and the broadcast probe responses transmitted by the transmitted BSSID that is in the same Multiple BSSID set as the non-transmitted BSSID ?Note: an AP is not included if it is not discoverable ?Note: RNR provides basic information (operating class, channel, BSSID, short SSID, …) ?Note: 11ax rules also apply, and any AP in other AP MLDs can optionally be reported ?.?C: 1st bullet for single BSSID, agree with it. The second bullet is for multi-BSSID. Why do you need second bullet?A: MLD related to non-transmitted BSSID should also be reported since there is no beacon transmitted by non-transmitted BSSID.C: there will be more than one MLD in a frame. These two bullets can’t cover all cases.A: let us first deal with these two cases.37Y, 24N, 31ARerun the first bullet of SP 1Do you agree that all APs that are part of the same MLD as a reporting AP and that are collocated with the reporting AP shall be reported in the RNR element that is included in the beacons and the broadcast probe responses transmitted by the reporting AP when the reporting AP is either not part of a multiple BSSID set or corresponds to a transmitted BSSID in a multiple BSSID set. ?Note: an AP is not included if it is not discoverable ?Note: RNR provides basic information (operating class, channel, BSSID, short SSID, …) ?42Y, 9N, 35ASP2 Do you agree: ?to include in a TBTT Information field of the RNR, corresponding to a reported AP that is part of the same MLD as the reporting AP, an indication that the reported AP is part of the same MLD as the reporting AP when the reporting AP is either not part of a multiple BSSID set or corresponds to a transmitted BSSID in a multiple BSSID set ?Note: signaling of that indication is TBD ?Approved with unanimous consentSP 4Do you agree to define a mechanism for a STA of a non-AP MLD to send a probe request frame to an AP belonging to an AP MLD, that enables to request a probe response from the AP that includes the complete set of capabilities, parameters and operation elements of other APs affiliated to the same MLD as the APThe complete information is defined as all elements that would be provided if the reported AP was transmitting that same frame (exceptions TBD)It’s TBD if the AP is mandated or not to respond with the requested informationC: assume that this is not mandatory requirement.A: we can discuss this point. The last bullet addresses this.C: do we need to adopt the inheritance?A: yes.Approved with unanimous consent390r3 Multi-Link Discovery – part 2(Laurent Cariou) [SP only]SP1 Do you agree to define a new Multi-Link element (MLE) to report/describe multiple STAs of an MLD with at least the following characteristics?MLD-level information may be includedA STA profile subelement is included for each reported STA (if any) and is made of a variable number of elements describing this STA ?.?C: confused with element and subelement.A: the structure is similar to multiple BSSID element.C: There is MLD control field. It is better to clarify that it is not the MLD-level informationA: ok.C: do you think the information of the reporting STA is included or not?A: I don’t think it should be included. After the discussion, the SP is changed toDo you agree to define a new Multi-Link element (MLE) to report/describe multiple STAs of an MLD with at least the following characteristics? ?MLD-level information may be included ?A STA profile subelement is included for each reported STA (if any) and is made of a variable number of elements describing this STA ?Note: a control field for the element is not considered as MLD-level information ?Note: Name can be changed ?51Y, 3N, 30ASP 2Do you support that, for the ML element, we define an inheritance model to prevent frame bloating when advertising complete information of other links?Define the inheritance mechanism, similar to 11ax, so that the value of an element of a reported STA that is not present in a STA profile of a ML element in a frame sent by a reporting STA is the same as the element of the reporting STA, present elsewhere in the frame.Define the inheritance mechanism, similar to 11ax, so that the value of an element of a reported STA that is not present in a STA profile of a ML element included in a non-transmitted BSSID profile of a non-transmitted BSSID in a multiple BSSID element in a frame sent by a reporting STA is the same as the element of the non-transmitted BSSID, present elsewhere in the frame or as the element of the reporting STA, present elsewhere in the frame.Note: an “element of a STA” refers in the text above to the instance of the element describing the capabilities/operation/functionalities of that STA, in a frame where multiple instances of the element can be found for other STAs.Note: some elements may not be inherited, signaling TBDAfter the discussion, ”if any” is added to bullet 2.Do you support that, for the ML element, we define an inheritance model to prevent frame bloating when advertising complete information of other links?Define the inheritance mechanism, similar to 11ax, so that the value of an element of a reported STA that is not present in a STA profile of a ML element in a frame sent by a reporting STA is the same as the element of the reporting STA, present elsewhere in the frame.Define the inheritance mechanism, similar to 11ax, so that the value of an element of a reported STA that is not present in a STA profile of a ML element , if any, included in a non-transmitted BSSID profile of a non-transmitted BSSID in a multiple BSSID element in a frame sent by a reporting STA is the same as the element of the non-transmitted BSSID, present elsewhere in the frame or as the element of the reporting STA, present elsewhere in the frame.Note: an “element of a STA” refers in the text above to the instance of the element describing the capabilities/operation/functionalities of that STA, in a frame where multiple instances of the element can be found for other STAs.Note: some elements may not be inherited, signaling TBD33Y, 3N, 49A392r0 MLD Max Idle Period(Laurent Cariou) [SP only]SP1 Do you agree to add to the 11be SFD:The MLD Max Idle Period of an AP MLD applies at the MLD level and not at the STA levelThe MLD Max Idle Period of an AP MLD indicates, for a non-AP MLD, the time period during which a non-AP MLD can be inactive (i.e. refrain from transmitting frames to the AP MLD on any of the setup links) without the Multi-link setup to be teared downA non-AP MLD is considered inactive if none of the APs of the AP MLD have received a Data frame, PS-Poll frame, or Management frame (protected or unprotected) of a frame exchange sequence initiated by a STA from the non-AP MLD for a time period greater than or equal to the time specified by the MLD Max Idle Period field of the AP MLDIf the non-AP MLD is inactive for a duration greater than the MLD Max Idle Period, then the AP MLD may tear down the multi-link setup for that non-AP MLD ?.?C: understand the need. Don’t know why we need new parameters here.A: this SP does not try to solve the issue the non-AP MLD monitor one link.C: MLD MAC will deal with it.A: the SP is doing what you want.C: do you suggest the new element?A: signaling is TBD.After the discussion the SP is changed toThe MLD Max Idle Period of an AP MLD applies at the MLD level and not at the STA level ?The MLD Max Idle Period of an AP MLD indicates, for a non-AP MLD, the time period during which a non-AP MLD can be inactive (i.e. refrain from transmitting frames to the AP MLD on any of the setup links) without the Multi-link setup to be torn down ?A non-AP MLD is considered inactive if none of the APs of the AP MLD have received a Data frame, PS-Poll frame, or Management frame (protected or unprotected) of a frame exchange sequence initiated by a STA from the non-AP MLD for a time period greater than or equal to the time specified by the MLD Max Idle Period of the AP MLD ?If the non-AP MLD is inactive for a duration greater than the MLD Max Idle Period, then the AP MLD may tear down the multi-link setup for that non-AP MLD ?Approved with unanimous consent396r4 MLO BSS Info. TX. and Multiple BSSID Support(Liwen Chu) SummaryThis contribution discusses the transmission and inheritance for AP information of the reported APs without multi-BSSID support or with multi-BSSID support.?411r2 MLO: Information Exchange for Link switching(Namyeong Kim) SummaryThis contribution proposes the method for the STA to obtain additional information in order to determine the suitable switching link.?C: AP of AP MLD can have change sequence to report other AP’s critical information change of same AP MLD.A: further information exchange is used to acquire the critical information change of another link’s AP of the AP MLD.C: agree with the direction. But it seems SP 3 doesn’t capture the unsolicited case. Is 20us a typo.A: yes, it should be 20ms.C: the SP includes static information. But the intention is to deal with dynamic information.C: slide 4’s question. Information Req/Res is used to get another link’s information of same AP MLD. Is the frame exchange used for every link switch?A: it can be generally used (request specific information from specific AP of the AP MLD).C: SP 3’s question. Is unsolicited announcement a broadcast or unicast frame?A: this will be broadcast frame.C: Why is the information changed frequently?A: BSS load information is changed dynamically. Getting such information may be shorter than the BI. C: there are many scenarios. It is better to differentiate them. C: in general, we want to reduce the overhead in the air. If some information is changed, it is not good that the whole information is transmitted.C: in general, like the idea. One comment is that it is better to define a mechanism to encrypt/decrypt the information.A: ok.412r2 MLO: Link Switching Method(Namyeong Kim) SummaryThis contribution discusses the link re-setup process after link switching and provide available link re-setup processes.?C: what is the motivation for link resetup? It is more efficient to set up all its links at the beginning, then some links are disabled.C: similar comment. I assume what you want is to update the parameters. When you do resetup, you have to change everything.A: I think we will remain the parameters after the resetup of additional link.C: similar opinion. There are several people raise the similar concerns.The teleconference was adjourned 7 minutes early than 01:00pm EDTWednesday 17 June 2020, 10:00am – 01:00pm ET (TGbe MAC ad hoc conference call)Chairman: Jeongki Kim (LG Electronics)Secretary: Liwen Chu (NXP)This meeting took place using a webex session.IntroductionThe Chair (Jeongki, LG) calls the meeting to order at 10:04am EDT. The Chair introduces himself and the Secretary, Liwen Chu (NXP)The Chair goes through the 802 and 802.11 IPR policy and procedures and asks if there is anyone that is aware of any potentially essential patents. Nobody speaks up.The Chair recommends using IMAT for recording the attendance.Please record your attendance during the conference call by using the IMAT system: 1) login to imat, 2) select “802.11 Telecons (<Month>)” entry, 3) select “C/LM/WG802.11 Attendance” entry, 4) click “TGbe <MAC/PHY/Joint> conference call that you are attending.If you are unable to record the attendance via IMAT then please send an e-mail to Jeongki Kim ( HYPERLINK "mailto:jeongki.kim@" jeongki.kim@) and Liwen Chu ( HYPERLINK "mailto:liwen.chu@" liwen.chu@)Recorded attendance through Imat and e-mail:TGbe (MAC)6/17Aboulmagd, OsamaHuawei Technologies Co.,? LtdTGbe (MAC)6/17Adhikari, ShubhodeepBroadcom CorporationTGbe (MAC)6/17Asterjadhi, AlfredQualcomm IncorporatedTGbe (MAC)6/17Au, Kwok ShumHuawei Technologies Co.,? LtdTGbe (MAC)6/17baron, stephaneCanon Research Centre FranceTGbe (MAC)6/17Boldy, DavidBroadcom CorporationTGbe (MAC)6/17Bredewoud, AlbertBroadcom CorporationTGbe (MAC)6/17Carney, WilliamSony CorporationTGbe (MAC)6/17Cheng, PaulMediaTek Inc.TGbe (MAC)6/17Chitrakar, RojanPanasonic Asia Pacific Pte Ltd.TGbe (MAC)6/17Choi, JinsooLG ELECTRONICSTGbe (MAC)6/17Coffey, JohnRealtek Semiconductor Corp.TGbe (MAC)6/17Das, DibakarIntel CorporationTGbe (MAC)6/17Das, SubirPerspecta Labs Inc.TGbe (MAC)6/17Derham, ThomasBroadcom CorporationTGbe (MAC)6/17Ding, BaokunHuawei Technologies Co. LtdTGbe (MAC)6/17Dong, XiandongXiaomi Inc.TGbe (MAC)6/17Fang, YonggangZTE TX IncTGbe (MAC)6/17Fischer, MatthewBroadcom CorporationTGbe (MAC)6/17Gan, MingHuawei Technologies Co., LtdTGbe (MAC)6/17Ghosh, ChittabrataIntel CorporationTGbe (MAC)6/17Guo, YuchenHuawei Technologies Co., LtdTGbe (MAC)6/17Han, JonghunSAMSUNGTGbe (MAC)6/17Han, ZhiqiangZTE CorporationTGbe (MAC)6/17Hervieu, LiliCable Television Laboratories Inc. (CableLabs)TGbe (MAC)6/17Hsu, Chien-FangMediaTek Inc.TGbe (MAC)6/17Hu, ChunyuFacebookTGbe (MAC)6/17Hu, MengshiHUAWEITGbe (MAC)6/17Huang, Guogang?HuaweiTGbe (MAC)6/17Huang, LeiPanasonic Asia Pacific Pte Ltd.TGbe (MAC)6/17Huang, Po-KaiIntel CorporationTGbe (MAC)6/17Jang, InsunLG ELECTRONICSTGbe (MAC)6/17Ji, ChenheHuawei Technologies Co. LtdTGbe (MAC)6/17Jia, JiaHuawei Technologies Co., LtdTGbe (MAC)6/17Jiang, JinjingApple, Inc.TGbe (MAC)6/17Kain, CarlUSDoTTGbe (MAC)6/17Kakani, NaveenQualcomm IncorporatedTGbe (MAC)6/17Kedem, OrenHuawei Technologies Co. LtdTGbe (MAC)6/17Kim, Sang GookLG ELECTRONICSTGbe (MAC)6/17Kishida, AkiraNippon Telegraph and Telephone Corporation (NTT)TGbe (MAC)6/17Ko, GeonjungWILUS Inc.TGbe (MAC)6/17Kondo, YoshihisaAdvanced Telecommunications Research Institute International (ATR)TGbe (MAC)6/17Lalam, MassinissaSAGEMCOM BROADBAND SASTGbe (MAC)6/17Levitsky, IlyaIITP RASTGbe (MAC)6/17Levy, JosephInterDigital, Inc.TGbe (MAC)6/17Li, YiqingHuawei Technologies Co. LtdTGbe (MAC)6/17Li, YunboHuawei Technologies Co., LtdTGbe (MAC)6/17Liang, dandanHuawei Technologies Co., LtdTGbe (MAC)6/17Lin, WeiHuawei Technologies Co. LtdTGbe (MAC)6/17LIU, CHENCHENHuawei Technologies Co., LtdTGbe (MAC)6/17Lou, HanqingInterDigital, Inc.TGbe (MAC)6/17Lu, LiumingZTE CorporationTGbe (MAC)6/17Lv, kaiyingMediaTek Inc.TGbe (MAC)6/17NANDAGOPALAN, SAI SHANKARCypress Semiconductor CorporationTGbe (MAC)6/17Nezou, PatriceCanon Research Centre FranceTGbe (MAC)6/17Park, MinyoungIntel CorporationTGbe (MAC)6/17Park, Sung-jinLG ELECTRONICSTGbe (MAC)6/17Patil, AbhishekQualcomm IncorporatedTGbe (MAC)6/17Raissinia, AlirezaQualcomm IncorporatedTGbe (MAC)6/17Rosdahl, JonQualcomm Technologies, Inc.TGbe (MAC)6/17Sedin, JonasEricsson ABTGbe (MAC)6/17Solaija, Muhammad SohaibIstanbul Medipol University; VestelTGbe (MAC)6/17Song, TaewonLG ELECTRONICSTGbe (MAC)6/17Stacey, RobertIntel CorporationTGbe (MAC)6/17Strauch, PaulQualcomm IncorporatedTGbe (MAC)6/17SUH, JUNG HOONHuawei Technologies Co. LtdTGbe (MAC)6/17Sun, BoZTE CorporationTGbe (MAC)6/17Sun, YanjunQualcomm IncorporatedTGbe (MAC)6/17Torab Jahromi, PayamFacebookTGbe (MAC)6/17VIGER, PascalCanon Research Centre FranceTGbe (MAC)6/17Wang, HaoTencentTGbe (MAC)6/17Wang, LeiHuawei R&D USATGbe (MAC)6/17Wang, QiApple, Inc.TGbe (MAC)6/17Wentink, MenzoQualcommTGbe (MAC)6/17Wilhelmsson, LeifEricsson ABTGbe (MAC)6/17Xin, YanHuawei Technologies Co., LtdTGbe (MAC)6/17Yang, JayNokiaTGbe (MAC)6/17YANG, RUIInterDigital, Inc.TGbe (MAC)6/17Yano, KazutoAdvanced Telecommunications Research Institute International (ATR)TGbe (MAC)6/17Yee, JamesMediaTek Inc.TGbe (MAC)6/17yi, yongjiangFuturewei TechnologiesTGbe (MAC)6/17Yu, JianHuawei Technologies Co., LtdTGbe (MAC)6/17Yukawa, MitsuyoshiCanon, Inc.TGbe (MAC)6/17ZEGRAR, Salah Eddine[NV] Salah Eddine ZEGRAR (Vestel)TGbe (MAC)6/17Zhang, JohnGuangDong OPPO Mobile Telecommunications Corp., Ltd.TGbe (MAC)6/17Zhang, MeihongHuawei Technologies Co., LtdThe Chair reminds that the agenda can be found in 11-20/735r23 with the additional SPs requested through emails. The chair asked whether there is comment about the agenda. There is one request to remoe 432 from the agenda. The agenda was adjusted accordingly. Submissions426r2 Multi-Link TSF Discussion(Minyoung Park) SummaryThis contribution discusses the cross-link TSF synchronization.?C: case 1 is about TWT setup. Is case 1 applied to case 2?A: yes.C: since APs of AP MLD start at the same time. Their TSF times should be similar or same.A: sharing the clock is fundamental. Whether running the counter same is different thing.C: what is the requirement of the accuracy of the tracking? This will have influence to the implementation.A: the accuracy is valid question. The SPs don’t mention the accuracy. I don’t have the number now. C: how about the usage of the TSF sync. beaside TWT, any other use case?A: TDM kind of operations may also use it.C: one assume that APs can’t commucate with other. Which one do you prefer?A: prefer option 1.C: once TSF is calibarated, you don’t need to deliver the TSF difference among the links.A: the starting times of APs may be different.C: slide 5 is related to SP 2. Does AP needs to announce the TSF difference in Beacons?C: case 1 lets the non-P MLD to figure out the TSF drift between APs. Your SP asks the AP MLD do the job. Am I right?A: Yes.C: what if the accuracy requirement makes the implementation too difficult?A: it depends on the use cases. We auume that the major use cases of TWT or similar shouldn’t be any issue.SP deferred.443r1 MLA: SSID Handling(Duncan) SummaryThis contribution discusses SSID of AP MLD for non-AP MLD and non-EHT STA.?C: option 1 is good way to go. Option 2 will confuse the STAs since three SSIDs are required. For guest case, some guests are EHT devices, some are non-EHT STAs.A: we don’t force anyone to use three SSIDs. We provide the mechanism that AP vendors can use 3 SSIDs if they want.C: but this create complication to client sides. I don’t think we need to define MLD SSID.A: I talked several people. Some like option 1 and some like option 2.C: like the option to keep different SSIDs. Do we need to maintain one SSID for MLO?A: the MLO clients should see one SSID.C: similar comment with the first one. Agree that one SSID is used for AP MLD. But different SSIDs for non-EHT and EHT are not good.A: understand your preference.C: we assume that option 1 can deal with non-EHT STAs with option 1, e.g. defining a new AP.C: agree with you that option 2 is better. ML SSID has overlap function as MLO address.A: assume we need ML SSID.SP are defered357r1 MLO: Container Structure for Cap. Advertisement (Abhishek Patil) SummaryThis contribution discusses the container of AP MLD information.?C: lots of similarities. Question about multiple BSSID, association request/response should have no multiple BSSID element.A: yes, it is possible.C: for non-transmitted BSSID, its MLD informaiton is in multiple BSSID element. Am I right?A: yes.SP deferred.503r1 BSS parameter update for Multi-link Operation(Ming Gan) SummaryThis contribution discusses BSS parameter update.?C: genrally agree with you. Having similar presentation.SP 1Do you agree that an AP in an AP MLD shall provide BSS specific parameters update indication for one or more other APs in the same AP MLD?BSS specific parameters update indication includes Link ID and Change Sequence Number for each reported AP, where Link ID is an identifier of the reported APReusing the existing Check beacon field as Change Sequence Number field is TBDC: is the notification per link based?A: the counter is per link counter.C: assume link ID already exists in the previous SP. Will double check it.C: Change Sequence Number is just name in the previous SP. Second subbullet is not needed.A: ok.C: it is preferable to add Change Sequence to RNR.After the discussion, the SP (will be in R2) is changed toDo you agree to amend the SP # 77 by adding the following subbullet ?BSS specific parameters update indication includes Link ID and Change Sequence Number for each reported AP, where Link ID is an identifier of the reported AP in the AP MLD ?Note： the signaling for Link ID is TBD ?33Y, 18N, 19ASP 2Do you agree that a non-AP MLD shall maintain a record of the most recently received sequence counter for each reported APs with which a STA in the non-AP MLD is associatedC: association is not clear. You should use multi-link setup.A ok.After the discussion, the SP is changed toDo you agree that a non-AP MLD shall maintain a record of the most recently received change sequence number for each reported APs in the AP MLD with which it has multi-link setup?51Y, 7N, 14A.508r0 MLO: Reachability Problem ???????????????????????????????? (Abhishek Patil) SummaryThis contribution discusses BSS parameter update.?Thursday 18 June 2020, 07:00pm – 10:00pm ET (TGbe MAC ad hoc conference call)Chairman: Jeongki Kim (LG Electronics)Secretary: Liwen Chu (NXP)This meeting took place using a webex session.IntroductionThe Chair (Jeongki, LG) calls the meeting to order at 10:04am EDT. The Chair introduces himself and the Secretary, Liwen Chu (NXP)The Chair goes through the 802 and 802.11 IPR policy and procedures and asks if there is anyone that is aware of any potentially essential patents. Nobody speaks up.The Chair recommends using IMAT for recording the attendance.Please record your attendance during the conference call by using the IMAT system: 1) login to imat, 2) select “802.11 Telecons (<Month>)” entry, 3) select “C/LM/WG802.11 Attendance” entry, 4) click “TGbe <MAC/PHY/Joint> conference call that you are attending.If you are unable to record the attendance via HYPERLINK "" IMAT then please send an e-mail to Jeongki Kim ( HYPERLINK "mailto:jeongki.kim@" jeongki.kim@) and Liwen Chu ( HYPERLINK "mailto:liwen.chu@" liwen.chu@)Recorded attendance through Imat and e-mail:6/18Abdelaal, RanaBroadcom Corporation6/18Aboulmagd, OsamaHuawei Technologies Co.,? Ltd6/18Adachi, TomokoTOSHIBA Corporation6/18Adhikari, ShubhodeepBroadcom Corporation6/18Agarwal, PeyushBroadcom Corporation6/18Akhmetov, DmitryIntel Corporation6/18Au, Kwok ShumHuawei Technologies Co.,? Ltd6/18Bhandaru, NehruBroadcom Corporation6/18Boldy, DavidBroadcom Corporation6/18Cariou, LaurentIntel Corporation6/18Carney, WilliamSony Corporation6/18CHAN, YEEFacebook6/18Chen, XiaogangIntel6/18CHERIAN, GEORGEQualcomm Incorporated6/18Chitrakar, RojanPanasonic Asia Pacific Pte Ltd.6/18Choi, JinsooLG ELECTRONICS6/18Coffey, JohnRealtek Semiconductor Corp.6/18Das, SubirPerspecta Labs Inc.6/18Derham, ThomasBroadcom Corporation6/18de Vegt, RolfQualcomm Incorporated6/18Ding, BaokunHuawei Technologies Co. Ltd6/18Doostnejad, RoyaIntel Corporation6/18Erceg, VinkoBroadcom Corporation6/18Fang, YonggangZTE TX Inc6/18Fischer, MatthewBroadcom Corporation6/18Gan, MingHuawei Technologies Co., Ltd6/18Garg, LalitBroadcom Corporation6/18Ghosh, ChittabrataIntel Corporation6/18Godbole, sachinBroadcom Corporation6/18Guo, YuchenHuawei Technologies Co., Ltd6/18Hamilton, MarkRuckus/CommScope6/18Han, ZhiqiangZTE Corporation6/18Hirata, RyuichiSony Corporation6/18Ho, DuncanQualcomm Incorporated6/18Hsu, Chien-FangMediaTek Inc.6/18Hu, ChunyuFacebook6/18Hu, MengshiHUAWEI6/18Huang, Guogang?Huawei6/18Huang, LeiPanasonic Asia Pacific Pte Ltd.6/18Inohiza, HirohikoCanon Inc.6/18Ji, ChenheHuawei Technologies Co. Ltd6/18Jia, JiaHuawei Technologies Co., Ltd6/18jiang, fengApple Inc.6/18Jiang, JinjingApple, Inc.6/18Jung, hyojinHyundai Motor Company6/18Kain, CarlUSDoT6/18Kedem, OrenHuawei Technologies Co. Ltd6/18Khericha, samirBRoadcom6/18kim, namyeongLG ELECTRONICS6/18Kim, Sang GookLG ELECTRONICS6/18Kim, SanghyunWILUS Inc6/18Kim, YouhanQualcomm Incorporated6/18Kishida, AkiraNippon Telegraph and Telephone Corporation (NTT)6/18Kondo, YoshihisaAdvanced Telecommunications Research Institute International (ATR)6/18kristem, vinodIntel Corporation6/18Kwon, Young HoonNXP Semiconductors6/18Lee, WookbongSAMSUNG6/18Li, YiqingHuawei Technologies Co. Ltd6/18Li, YunboHuawei Technologies Co., Ltd6/18Lim, Dong GukLG ELECTRONICS6/18LIU, CHENCHENHuawei Technologies Co., Ltd6/18Lou, HanqingInterDigital, Inc.6/18Lu, LiumingZTE Corporation6/18Lv, kaiyingMediaTek Inc.6/18Ma, MengyaoHUAWEI6/18Mirfakhraei, KhashayarCisco Systems, Inc.6/18Monajemi, PooyaCisco Systems, Inc.6/18Montreuil, LeoBroadcom Corporation6/18NANDAGOPALAN, SAI SHANKARCypress Semiconductor Corporation6/18Palm, StephenBroadcom Corporation6/18Park, EunsungLG ELECTRONICS6/18Park, MinyoungIntel Corporation6/18Park, Sung-jinLG ELECTRONICS6/18Patil, AbhishekQualcomm Incorporated6/18Patwardhan, GauravHewlett Packard Enterprise6/18Petrick, AlbertInterDigital, Inc.6/18Petry, BrianBroadcom Corporation6/18Puducheri, SrinathBroadcom Corporation6/18Raissinia, AlirezaQualcomm Incorporated6/18Rosdahl, JonQualcomm Technologies, Inc.6/18Sadeghi, BaharehIntel Corporation6/18Seok, YonghoMediaTek Inc.6/18Solaija, Muhammad SohaibIstanbul Medipol University; Vestel6/18Song, TaewonLG ELECTRONICS6/18Strauch, PaulQualcomm Incorporated6/18SUH, JUNG HOONHuawei Technologies Co. Ltd6/18Sun, BoZTE Corporation6/18Sun, Li-HsiangInterDigital, Inc.6/18Sun, YanjunQualcomm Incorporated6/18Tanaka, YusukeSony Corporation6/18Verma, SindhuBroadcom Corporation6/18VIGER, PascalCanon Research Centre France6/18Wang, LeiHuawei R&D USA6/18Wang, QiApple, Inc.6/18Wu, HaoXGIMI Technology Co.Ltd6/18Xin, LiangxiaoSony Corporation6/18Xin, YanHuawei Technologies Co., Ltd6/18Yan, AiguoOppo6/18Yang, JayNokia6/18Yano, KazutoAdvanced Telecommunications Research Institute International (ATR)6/18yi, yongjiangFuturewei Technologies6/18Young, ChristopherBroadcom Corporation6/18Yu, JianHuawei Technologies Co., Ltd6/18Yukawa, MitsuyoshiCanon, Inc.6/18Zhang, JohnGuangDong OPPO Mobile Telecommunications Corp., Ltd.6/18Zhang, MeihongHuawei Technologies Co., LtdThe Chair reminds that the agenda can be found in 11-20/735r27 with the additional SPs requested through emails. The chair asked whether there is comment about the agenda. Deferred SP of 562r4 was requested. The agenda was adjusted accordingly. Submissions562r4 Enhanced multi-link single radio operation (Minyoung Park) [SP only].?SP 2Do you support the concept of the multi-link operation for an enhanced single-link/radio (TBD) non-AP MLD that is defined as follows for R1?An MLD that can: 1) transmit or receive data/management frames to another MLD on one link, and 2) listening on one or more links.The “listening” operation includes CCA as well as receiving initial control messages (e.g., RTS/MU-RTS)Link switch delay may be indicated by the non-AP MLDC: still have strong concern about it. After checking the implementation team, the cost is almost same as separate MAC/PHY. But the performance is worse.A: you still misunderstand the idea.59Y, 29N, 21A.1947r6 Enhanced multi-link single radio operation (Minyoung Park) [SP only]SP 3after the editorial change, SP3 is updated to Do you agree to define the following?Single-link/radio (TBD) non-AP MLD: A non-AP MLD that supports operation on more than one link but can only transmit frames to or receive frames from another MLD on one link at a time.46Y, 18N, 33A411r3 MLO: Information Exchange for Link switching (Namyeong Kim) [SP only]SP 1Do you support that 802.11be allows the following operation :A STA of non-AP MLD may request the peer AP of AP MLD the specific information of one or more APs of the same AP MLD after multi-link setup.NOTE 1: The specific information can be information which didn’t obtain from beacon frame or to be updated by change sequence field. The detail of specific information is TBD (e.g., other AP’s BSS parameter (BSS load, latency info, TWT info), updated parameters, etc.).NOTE 2: The signaling for requesting the specific information is TBD. NOTE 3: The request frame is TBD (e.g., Probe request). C: the general frame exchange for the SP and change sequence should be defined.A: the SP assume that STA MLD can acquire the information whenever it wants to do.C: we agree specific MLD probe request to acquire all MLD information. Here part of parameters is polling. I am not sure whether this is needed.C: the first case being applied is for link switching. The second case being applied is to acquire critical information.C: note 1 is not clear.A: we want to generalize the information acquiring from AP MLD. C: it seems MLD probe request should be enough to acquire all information of APs in other links.A: the SP is trying to acquire specific information instead of all information.C: is Probe Request used.A: whether probe request is used is TBD.31Y, 20N, 46A586r2 MLO: Signaling of critical updates (Abhishek Patil) SummaryThis contribution discusses the cross link critical updates, cross-link signal silencing of a reported AP.?C: change sequence is ok. Question on SP 1, not sure whether this is right way to go. We can use the current method. It may also be abused.A: we want to keep beacon size small. Quiet element is longer than one-bit signaling.C: the critical event happens infrequently. The beacon bloating shouldn’t be the problem.C: agree with change sequence. Same concerns with the previous commenter. RNR is not good way to carry change sequence. Currently, an associated STA doesn’t need to check RNR.A: for RNR checking by associated STAs, our consideration is that this is new amendment. Adding some information to RNR should be fine. C: probe storm may be created because of probing the critical information.A: STA doesn’t have to use Probe Request.C: big concern about SP 1. What is the purpose of silencing of reported AP? Legacy STAs don’t understand it and will transmit frames to the reported AP.A: how about channel switch?C: agree with channel switch.SPs are deferred.616r0 BW indication of 320MHz for non-HT & non-HT dup. frames (Yunbo Li) SummaryThis contribution discusses to use scrambler sequence to indicate >160/80+80MHz BW.?C: the proposal doesn’t address channel puncture. It is not complete solution.A: I proposed type 1 (no puncture) and type 2 solutions (with channel puncture). My SPs is bout type 1. Your presentation is about type 2.C: this is important topic. The solution is similar. Generally, support it. For static puncture it still works.C: it seems we already agree to use the MAC level solution. From technical point of view, 3-bit random bits may not be enough. A: it should be fine from my internal feedback.C: similar comment to George for static channel puncturing.SP 1Do you support to indicate BW larger than 160MHz through scrambler sequence in non-HT or non-HT duplicated frames?46Y, 15N, 32ASP 2Do you support to use one more bit in scrambler sequence, which is B3, to indicate bandwidth larger than 160MHz in non-HT or non-HT duplicated frames?43Y, 15N, 38A747r0 RTS-CTS-in-11be (Lochan Verma) SummaryThis contribution discusses to use MU-RTS to solicit CTS or (eht)CTS for TXOP protection with channel puncture operation.?C: comment on slide 13, it is not easy to select the PPDU format of CTS based on the number of the solicited STAs.A: MU-RTS can indicate the responding PPDU format.C: we would like to have extension of Control frame.A: our concern is the NAV resetting rule.C: Is EHT-CTS similar to BQRP feature? want to understand the puncture pattern.A: That is for long term purpose. Here the feedback is for immediate use.C: RU allocation should be good enough.1622r0 Use Auto Repetition in low latency queue (Tony Zeng) Presentation withdrawed.0003r0 Discussion on latency metric(Suhwook Kim) SummaryThis contribution discusses on target metric for low latency feature and suggests Xth percentile value rather than other metric.?C: trying to understand your proposal. Is it about how to evaluate the QoS performance and put them in the spec.?A: I don’t propose the solution. The proposal is the first step for how to evaluate the solution.C: In general, agree with it.C: the actual processing for the accurate delay measurement is difficult.A: some latency metric is already supported in 802.11. I think the latency processing should not be that difficult.C: I am not sure whether they are implemented.C: good direction. Question: the 3 options in SP may mean different directions.A: these options are not exclusive.C: BSS load is already certified in other organization. The teleconference was adjourned 5 minutes early than 10:00pm EDTMonday 22 June 2020, 07:00pm –10:00pm ET (TGbe MAC ad hoc conference call)Chairman: Jeongki Kim (LG Electronics)Secretary: Liwen Chu (NXP)This meeting took place using a webex session.IntroductionThe Chair (Jeongki, LG) calls the meeting to order at 10:04am EDT. The Chair introduces himself and the Secretary, Liwen Chu (NXP)The Chair goes through the 802 and 802.11 IPR policy and procedures and asks if there is anyone that is aware of any potentially essential patents. Nobody speaks up.The Chair recommends using IMAT for recording the attendance.Please record your attendance during the conference call by using the IMAT system: 1) login to imat, 2) select “802.11 Telecons (<Month>)” entry, 3) select “C/LM/WG802.11 Attendance” entry, 4) click “TGbe <MAC/PHY/Joint> conference call that you are attending.If you are unable to record the attendance via HYPERLINK "" IMAT then please send an e-mail to Jeongki Kim ( HYPERLINK "mailto:jeongki.kim@" jeongki.kim@) and Liwen Chu ( HYPERLINK "mailto:liwen.chu@" liwen.chu@)Recorded attendance through Imat and e-mail:6/22Aboulmagd, OsamaHuawei Technologies Co.,? Ltd6/22Adachi, TomokoTOSHIBA Corporation6/22Agarwal, PeyushBroadcom Corporation6/22Akhmetov, DmitryIntel Corporation6/22Asterjadhi, AlfredQualcomm Incorporated6/22Au, Kwok ShumHuawei Technologies Co.,? Ltd6/22Carney, WilliamSony Corporation6/22CHAN, YEEFacebook6/22Cheng, PaulMediaTek Inc.6/22Chitrakar, RojanPanasonic Asia Pacific Pte Ltd.6/22Coffey, JohnRealtek Semiconductor Corp.6/22Das, DibakarIntel Corporation6/22Das, SubirPerspecta Labs Inc.6/22Derham, ThomasBroadcom Corporation6/22de Vegt, RolfQualcomm Incorporated6/22Ding, BaokunHuawei Technologies Co., Ltd6/22Fang, YonggangZTE TX Inc6/22Fischer, MatthewBroadcom Corporation6/22Gan, MingHuawei Technologies Co., Ltd6/22Ghosh, ChittabrataIntel Corporation6/22Guo, YuchenHuawei Technologies Co., Ltd6/22Hamilton, MarkRuckus/CommScope6/22Han, ZhiqiangZTE Corporation6/22Ho, DuncanQualcomm Incorporated6/22Hsu, Chien-FangMediaTek Inc.6/22Hu, ChunyuFacebook6/22Huang, Guogang?Huawei6/22Huang, Po-KaiIntel Corporation6/22Inohiza, HirohikoCanon Inc.6/22Jiang, JinjingApple, Inc.6/22Jung, hyojinHyundai Motor Company6/22Kain, CarlUSDoT6/22Kedem, OrenHuawei Technologies Co. Ltd6/22kim, namyeongLG ELECTRONICS6/22Kim, Sang GookLG ELECTRONICS6/22Kim, YonghoKorea National University of Transportation6/22Kishida, AkiraNippon Telegraph and Telephone Corporation (NTT)6/22Ko, GeonjungWILUS Inc.6/22Kondo, YoshihisaAdvanced Telecommunications Research Institute International (ATR)6/22Kumar, ManishMarvell Semiconductor, Inc.6/22Kwon, Young HoonNXP Semiconductors6/22Levy, JosephInterDigital, Inc.6/22Li, YiqingHuawei Technologies Co. Ltd6/22Li, YunboHuawei Technologies Co., Ltd6/22Lin, WeiHuawei Technologies Co. Ltd6/22Liu, YongApple, Inc.6/22Ma, MengyaoHUAWEI6/22Naribole, SharanSAMSUNG6/22Ouchi, MasatomoCanon6/22Park, MinyoungIntel Corporation6/22Patil, AbhishekQualcomm Incorporated6/22Patwardhan, GauravHewlett Packard Enterprise6/22Raissinia, AlirezaQualcomm Incorporated6/22Rosdahl, JonQualcomm Technologies, Inc.6/22Solaija, Muhammad SohaibIstanbul Medipol University; Vestel6/22Son, Ju-HyungWILUS Inc.6/22Song, TaewonLG ELECTRONICS6/22Sun, Li-HsiangInterDigital, Inc.6/22Sun, YanjunQualcomm Incorporated6/22Tanaka, YusukeSony Corporation6/22Wang, Chao ChunMediaTek Inc.6/22Wang, HuizhaoQuantenna Communications, Inc.6/22Wang, LeiHuawei R&D USA6/22Wang, QiApple, Inc.6/22Wu, HaoXGIMI Technology Co.Ltd6/22Wullert, JohnPerspecta Labs6/22Xin, LiangxiaoSony Corporation6/22Yang, JayNokia6/22Yano, KazutoAdvanced Telecommunications Research Institute International (ATR)6/22Yee, JamesMediaTek Inc.6/22Yukawa, MitsuyoshiCanon, Inc.The Chair reminds that the agenda can be found in 11-20/735r30 with the additional SPs requested through emails. The chair asked whether there is comment about the agenda. The requests of deferred SPs from last week were raised. The agenda was adjusted accordingly. Submissions408r6 Prioritized EDCA Channel Access Over Latency Sensitive Link(s) In MLO (Chunyu Hu) [SP only].?SP 3Do you support that the TGbe SFD shall include:A definition of Latency Sensitive Link in Multi-Link Operation as a link over which the AP MLD defines TBD QoS mechanisms to provide the latency sensitive traffic streams improved latency and reliability performance. NotesThere can be multiple latency sensitive links in a BSS.The regular traffic streams can be served over the latency sensitive links as well subject to the AP MLD’s link management.C: what happens if you don’t have the definition of latency sensitive link?A: We propose to have MAC mechanism to allow the traffic other than the normal MAC traffic in some link.29Y, 17N, 34A357r2 Container for advertising ML Information (Abhishek Patil) [SP only].?SP 3Do you agree to amend SP #97 as following:Do you agree to define a mechanism for a STA of a non-AP MLD to send a probe request frame to an AP belonging to an AP MLD, that enables to request a probe response from the AP that includes the complete set of capabilities, parameters and operation elements of other APs affiliated to the same MLD as the APThe complete information is defined as all elements that would be provided if the reported AP was transmitting that same frame (exceptions TBD)It’s TBD if the AP is mandated or not to respond with the requested informationNote: Such a directed probe request requesting complete MLO information for one or more APs of the MLD is referred to as an ML probe request.Note: A directed probe response sent in response to an ML probe request containing complete MLO Information for the requested AP(s) is referred to as an ML probe responseC: what does “directly” mean?A: individually addressed frame.C: the response could be broadcast frame.A: I am ok with responding frame as broadcast frame.The SP is changed per the comment as follows:Do you agree to amend SP #97 as following: ?Do you agree to define a mechanism for a STA of a non-AP MLD to send a probe request frame to an AP belonging to an AP MLD, that enables to request a probe response from the AP that includes the complete set of capabilities, parameters and operation elements of other APs affiliated to the same MLD as the AP ?The complete information is defined as all elements that would be provided if the reported AP was transmitting that same frame (exceptions TBD) ?It’s TBD if the AP is mandated or not to respond with the requested information ?Note: Such a directed probe request requesting complete MLO information for one or more APs of the MLD is referred to as an ML probe request. ?Note: A probe response sent in response to an ML probe request containing complete MLO Information for the requested AP(s) is referred to as an ML probe response ?Y: ?N: ?A: ?TGbe editor: Please replace SP #97 with the above SP text for motion ?48Y, 1N, 30A105r6 Link Latency Statistics of Multi-band Operations in EHT (Frank Hsu) [SP only].?SP 1Do you support to define a mechanism so that an EHT AP MLD can provide information about traffic conditions of each link (e.g., DL transmit Delay, BSS load)?Signaling details is TBD. C: We are trying to get some clarity about the delay compared with BSS load. Some metric may be implementation dependent. We can hold these things off.A: in the slides I discussed that BSS load is not enough. C: is the delay metric the access delay?A: it includes queue delay ack delay etc. based on the current definition.Continue the discussion about BSS load vs delay.C: in generally, we support it. The question about signaling TBD.A: it is better in Association Response. It may also be carried in Beacon.36Y, 12N, 29A418r2 QoS Management framework in 802.11be (Dave Cavalcanti) .?SummaryThis contribution proposes the following:Announce new QoS capabilities (e.g. LLRS) in ML Discovery and OperationEnable Traffic stream QoS description and negotiation for QoS ML-operationTraffic classification and lightweight prioritization to enable new QoS metrics.?C: what is your view of the existing mechanisms, e.g. TSPEC etc.?A: we are open to reuse the existing mechanism. Some parameters may need to be redefined.C: the simulation question about AP’s scheduling.A: AP will schedule a certain number of STAs in a SP.C: For mapping TCs to queues, do you think the spec will define the mapping?A: you need to differentiate the new TIDs from the current voice traffic.C: Note 2 of SP1, how the announcement of legacy STAs will be do?A: we should not preclude the legacy STAs.C: question of slide 11. How the mapping to VO will help the low latency STAs if the other STAs have AC VO?A: I agree that if other STAs have AC VO traffic, it will have influence on the delay. This will be addressed by the different tiers.SPs are deferred.484r1 Latency Measurement for Low Latency Applications(Liuming Lu) .?SummaryThis contribution proposes to add the latency statistics including BSS Access Delay for intra-BSS transmission and BSS Access Delay for inter-BSS transmission.?C: it is interesting idea. some frames can’t be decoded correctly. It is difficult to clarify such time.A: this presentation gives some concept. The detail of defining the element needs further study. Some other group mentioned inter and intra delay. For the idle time, it could be part of transmission delay, inter-BSS delay, or intra-BSS delay.C: some PDUs can be detected and clarified. It may be difficult to measure the metrics.A: we can do future discussion.C: similar comments. But I think it is important to differentiate the intra-BSS delay and inter-BSS delay.SP is deferred.151r1 Target STA Announcement in DL TXOP for Synch. Mode STAs of MLO (Frank Hsu) .?SummaryThis contribution assumes MLD AP is capable of STR and explores issues when STAs are non-STR during an AP TXOP only on one link:Knowing which STAs to have frame exchange during the Link 1 AP’s TXOP helps improving non-STR STA efficiency during the TXOP and use Link 2 regardless what happens on Link1.?C: slide 9’s question. Please elaborate the different level of service. A: the emergent traffic to be served on time can be in the list.C: for the uplink, is it based on the Trigger frame?A: BSRP Trigger will solicit the required information before scheduling the data frames.C: 11ax has OPS that is similar to what you are trying to do.A: ok will check it.C: is the motivation power save?A: first intention is for MLD device. It is possible to do power save also.C: the passing of information between links within the TXOP may be difficult. Why does the information exchange between links become important?A: it needs only monitor the single link.C: in general, the proposed frame exchange sequence is complicated.C: slide 7 question, is announcement frame for the STAs in the transmitting link?A: yes.C: if target STAs are 1 and 2, how do the STAs in another link work.A: do you mean the operation at STA side or AP side?C: STA side. The question is about the STA’s operation in another link.A: the presentation is about the STA’s operation in the link where the announcement is transmitted.SP is deferred.427r1 Synchronous multi link operation (Young Hoon Kwon) .?SummaryThe presentation discussed the possible options for retransmission on synchronous mode multi-link operation has been discussed.Terminate the TXOPContinue transmission on the failed linkDummy frame transmission on the failed linkC: slide 6’s question. You assume tight synchronization. On link 2, is there any rule to disallow the operation?A: it can extend the time to do the synchronized transmission.C: general question, how do you determine that happens?A: the STA needs to know that at the beginning the AP transmits PPDUs in both links to the same STA MLD.C: this improvement can only happen in some scenario.A: yes.C: after D0 and D1, the starting time and ending time of the following simultaneous PPDUs are same?A: yes.SP 1Do you support the following transmission sequence for the constrained multi-link operation:When an AP MLD obtains TXOPs on multiple links and transmits frames to a non STR non-AP MLD soliciting immediate response on the multiple links, and intends to align the ending time of DL PPDUs during the obtained TXOPs:If the AP MLD does not receive an immediate response successfully on a link that is not a first frame exchange within the obtained TXOP of the link, and if the AP MLD receives an immediate response on at least one another link, the AP MLD can continue its transmission on the link within the obtained TXOP TBD (e.g., SIFS or PIFS) time after the failed reception of the immediate response if the channel is A mechanism on the link is TBD.C: it may have no time to do cross link decision with SIFS.A: the detail is TBD.The SP is deferred after the discussion.638r0 STR AP Sync. MLO operation (Zhou Lan) .?The presentation was deferred per the author’s request.357r2 Container for advertising ML Information (Abhishek Patil) [SP only].?SP 3Do you agree that the Multi-Link Attribute (MLA) element when included in a Beacon or non-ML Probe Response frame should carry only MLD-level/common information? NOTE : Exact name for the element TBDNOTE: Whether the Multi-Link Attribute element is always present in the Beacon and non-ML Probe Response frames or is optionally present is TBD.C: how about clarifying that MLD address will be included?A: some other information may also be included in common information.C: suggest to multi-ink element.A: ok.After the discussion, the SP (in R4) is updated toDo you agree that the Multi-Link element when included in a Beacon or non-ML Probe Response frame should carry only MLD-level/common information? ?NOTE : Exact name for the element TBD ?NOTE: Whether the Multi-Link element is always present in the Beacon and non-ML Probe Response frames or is optionally present is TBD. ?NOTE: MLD-Level/Common information includes at least MLD Address, and other information (TBD) ? Approved with unanimous consent.The teleconference was adjourned 5 minutes early than 10:00pm EDT Thursday 2 July 2020, 07:00pm –10:00pm ET (TGbe MAC ad hoc conference call)Chairman: Jeongki Kim (LG Electronics)Secretary: Liwen Chu (NXP)This meeting took place using a webex session.IntroductionThe Chair (Jeongki, LG) calls the meeting to order at 10:04am EDT. The Chair introduces himself and the Secretary, Liwen Chu (NXP)The Chair goes through the 802 and 802.11 IPR policy and procedures and asks if there is anyone that is aware of any potentially essential patents. Nobody speaks up.The Chair recommends using IMAT for recording the attendance.Please record your attendance during the conference call by using the IMAT system: 1) login to imat, 2) select “802.11 Telecons (<Month>)” entry, 3) select “C/LM/WG802.11 Attendance” entry, 4) click “TGbe <MAC/PHY/Joint> conference call that you are attending.If you are unable to record the attendance via HYPERLINK "" IMAT then please send an e-mail to Jeongki Kim ( HYPERLINK "mailto:jeongki.kim@" jeongki.kim@) and Liwen Chu ( HYPERLINK "mailto:liwen.chu@" liwen.chu@)Recorded attendance through Imat and e-mail:7/2Aboulmagd, OsamaHuawei Technologies Co.,? Ltd7/2Adachi, TomokoTOSHIBA Corporation7/2Akhmetov, DmitryIntel Corporation7/2Au, Kwok ShumHuawei Technologies Co.,? Ltd7/2Baek, SunHeeLG ELECTRONICS7/2baron, stephaneCanon Research Centre France7/2Bims, HarryBims Laboratories, Inc.7/2Carney, WilliamSony Corporation7/2CHAN, YEEFacebook7/2Cheng, PaulMediaTek Inc.7/2Chitrakar, RojanPanasonic Asia Pacific Pte Ltd.7/2Coffey, JohnRealtek Semiconductor Corp.7/2Das, DibakarIntel Corporation7/2Ding, BaokunHuawei Technologies Co., Ltd7/2Dong, XiandongXiaomi Inc.7/2Fang, YonggangZTE TX Inc7/2Fischer, MatthewBroadcom Corporation7/2Ghosh, ChittabrataIntel Corporation7/2Guo, YuchenHuawei Technologies Co., Ltd7/2Hamilton, MarkRuckus/CommScope7/2Han, ZhiqiangZTE Corporation7/2Ho, DuncanQualcomm Incorporated7/2Hu, ChunyuFacebook7/2Huang, Guogang?Huawei7/2Huang, Po-KaiIntel Corporation7/2Hwang, Sung HyunElectronics and Telecommunications Research Institute (ETRI)7/2Inohiza, HirohikoCanon Inc.7/2Jang, InsunLG ELECTRONICS7/2Ji, ChenheHuawei Technologies Co. Ltd7/2Jiang, JinjingApple, Inc.7/2Kain, CarlUSDoT7/2Kakani, NaveenQualcomm Incorporated7/2Kandala, SrinivasSAMSUNG7/2Kedem, OrenHuawei Technologies Co. Ltd7/2kim, namyeongLG ELECTRONICS7/2Kim, Sang GookLG ELECTRONICS7/2Kim, SanghyunWILUS Inc7/2Kishida, AkiraNippon Telegraph and Telephone Corporation (NTT)7/2Ko, GeonjungWILUS Inc.7/2Kondo, YoshihisaAdvanced Telecommunications Research Institute International (ATR)7/2Kwon, Young HoonNXP Semiconductors7/2Lalam, MassinissaSAGEMCOM BROADBAND SAS7/2Levy, JosephInterDigital, Inc.7/2Li, YiqingHuawei Technologies Co. Ltd7/2Li, YunboHuawei Technologies Co., Ltd7/2Lin, WeiHuawei Technologies Co. Ltd7/2Lu, LiumingZTE Corporation7/2Luo, ChaomingBeijing OPPO telecommunications corp., ltd.7/2Lv, kaiyingMediaTek Inc.7/2Ma, MengyaoHUAWEI7/2Monajemi, PooyaCisco Systems, Inc.7/2NANDAGOPALAN, SAI SHANKARCypress Semiconductor Corporation7/2Ouchi, MasatomoCanon7/2Park, MinyoungIntel Corporation7/2Patil, AbhishekQualcomm Incorporated7/2Patwardhan, GauravHewlett Packard Enterprise7/2Petrick, AlbertInterDigital, Inc.7/2Raissinia, AlirezaQualcomm Incorporated7/2Rezk, MeriamQualcomm Incorporated7/2Rosdahl, JonQualcomm Technologies, Inc.7/2Seok, YonghoMediaTek Inc.7/2Sun, Li-HsiangInterDigital, Inc.7/2Sun, YanjunQualcomm Incorporated7/2Tanaka, YusukeSony Corporation7/2Torab Jahromi, PayamFacebook7/2Wang, Chao ChunMediaTek Inc.7/2Wang, HaoTencent7/2Wang, LeiHuawei R&D USA7/2Wang, QiApple, Inc.7/2Yang, JayNokia7/2Yano, KazutoAdvanced Telecommunications Research Institute International (ATR)7/2Yee, JamesMediaTek Inc.7/2Yukawa, MitsuyoshiCanon, Inc.The Chair reminds that the agenda can be found in 11-20/735r36 with the additional SPs requested through emails. The chair asked whether there is comment about the agenda. The requests of deferred SPs from last week were raised. The agenda was adjusted accordingly. Submissions 442r2 Group Addressed Frame Delivery for EHT Duncan Ho [SP only].?SP 2Do you agree to add to the TGbe SFD the followingA non-AP MLD shall follow the baseline rules to receive the group addressed data frames on one link selected by the non-AP MLDThe non-AP MLD may change the selected link at any time except during an ongoing group addressed delivery periodThe non-AP MLD shall discard any group addressed data frames that are not received in the selected link21Y, 17N, 27A. 26r7 Group Addressed Frame Delivery for EHT Duncan Ho [SP only].?SP 2Do you agree to add to the TGbe SFD:Define signaling for an AP MLD to advertise whether it is capable of aligning the end of DL PPDUs that are sent simultaneously on multiple links to the same non-STR non-AP MLD:If not capable, the AP MLD is not capable of such featureIf capable, the AP MLD shall perform the following:The AP MLD aligns the end of DL PPDUs (that contain QoS data soliciting an immediate UL response) are sent simultaneously on multiple links to the same non-STR non-AP MLD, in such a way that the response to any of the PPDUs will not overlap with any of the DL PPDUsException: a high priority DL PPDU sent on one link may not be aligned with another DL PPDU sent on the other linkAfter the discussion, the SP is changed toDo you agree to add to the TGbe SFD:Define signaling for an AP MLD to advertise whether it can align the end of DL PPDUs that are sent simultaneously on multiple links to the same non-STR non-AP MLD:If not capable, the AP MLD is not capable of such featureIf capable, the AP MLD shall perform the following:The AP MLD aligns the end of DL PPDUs (that contain QoS data soliciting an immediate UL response) that are sent simultaneously on multiple links to the same non-STR non-AP MLD, in such a way that the response to any of the PPDUs will not overlap with any of the DL PPDUsExcept for a high priority DL PPDU sent on one link, which may not be aligned with another DL PPDU sent on the other link36Y, 13N, 24A427r2 Synchronous multi-link operation (Young Hoon Kwon) [SP only].?SPDo you support the following transmission sequence for the constrained multi-link operation:When an AP MLD obtains TXOPs on multiple links and transmits frames to a non STR non-AP MLD soliciting immediate response on the multiple links, and intends to align the ending time of DL PPDUs during the obtained TXOPs:If the AP MLD does not receive an immediate response successfully on a link that is not a first frame exchange within the obtained TXOP of the link, and if the AP MLD receives an immediate response on at least one another link, the AP MLD can continue its transmission on the link within the obtained TXOP TBD (e.g., SIFS or PIFS) time after the failed reception of the immediate response if the channel is A mechanism on the link is TBD.After the discussion, the SP is deferred638r0 STR AP Sync. PPDU Transmission (Zhou Lan) .?SummaryThe presentation proposed to allow sync transmission at AP MLD side from STR AP MLD to NSTR non-AP MLD for transmitting RTS/CTS at both links to protect the TXOPs at two links.C: for option 2, do you mean receiving RTS in one link and transmiting CTS in multiple links? This requires real-time communication between STAs of non-AP MLD.A: agree. I just list the options being proposed.C: what is sync PPDU? It is not clearly defined.A: By sync PPDU, I mean both starting time and ending time are aligned.C: What is the use case for STR AP and NSTR non-AP MLD for such high throughput?A: mobile phone, laptop may require such high throughput.C: the main use case should between two STR MLDs.A: high throughput is selling point between any types of MLDs.C: using short PPDU instead of RTS/CTS at the beginning of TXOP can avoid the collision. It can be done by not using RTS/CTS. Adding the remaining backoff counter value to the following backoff can’t solve the fairness issue. There may be some regulatory issue for the options.A: the regulatory rules can change. RTS/CTS exchange is the typical method to do the TXOP protection compared with short PPDU and its responding PPDU.No SP was run..661r2 Group addressed frames delivery for MLO (Ming Gan) .?SummaryThe presentation proposed the group addressed frame transmission by using the current method: no duplicate group-addressed frames among links.C: you don’t want the STA MLD to switch link to receive group address frames. AP MLD needs to transmit the group addressed frames in all links anyway for legacy STAs.A: there is no issue for multiple radio device to receive group addressed frames in multiple links.C: for option 2, how does STAs know which link the AP MLD will send group addressed frames?A: AP provides the additional information about the link indication. It is AP’s choice.C: the group-addressed frames could be delivered in a specific link. There should some guideline to notify the STAs. The SP is deferred.557r1 Multiple BSSID for Multi-link Operation (Ming Gan) SummaryThe presentation proposed the options to report the collocated AP MLDs with affiliated AP in reporting link or without affiliated AP in reporting link.C: slide 6 question: the non-transmitted BSSID information will carry its MLD information. It is a burden to carry the information of MLD that doesn’t have AP in the reporting link.A: this is not right. With your assumption, the information of other links is missing.C: RNR already provides the information of other links.A: Agree that green MLD and yellow MLD in slide 7 can be optional.C: yellow MLD shouldn’t be optional otherwise no AP wants to be non-transmitted BSSID.The SP is deferred.659r1 TDM Multilink Operation(Sindhu Verma) The author is not in the meeting. The presentation is deferred.688r0 ML individual addressed data delivery without BA(Po-Kai Huang) SummaryThe presentation proposed the rules to transmit individual addressed data in multi-link without BA negotiation.C: question to slide 4, is that happen when link switch is done?A: we assume any link can be used for frame transmission.C: Is this done in MLD level?A: yes. The link level doesn’t need maintain the information.C: So, the address translation is needed. Right?A: yes. It is similar to frame exchange under BA.C: Agree this is good proposal.C: how about retry counter?A: it is MLD level counter.SPAfter multi-link setup, do you support the following to enable delivery of individual addressed QoS traffic without BA negotiation across links? For Transmitter:Expand Table 10-5—Transmitter sequence number spaces to have a new entry?Indexed by <destined MLD Address, TID>Continue to transmit the failed QoS Data frame until retry counter is metCannot transmit other QoS Data frame from the same TID in any link until the current frame finish transmission or dropped For Receiver:Maintain at least the most recent record of <peer MLD address, TID, sequence number>.Drop the frame with retry bit set and record matchC: You mentioned that individual frame may not need to be transmitted in multiple links. Whether the proposal is useful will depend on whether we allow unicast frame without BA agreement to be transmitted in multiple links.A: We assume this should be treated same as frames with BA agreement.24Y, 15N, 21AThe teleconference was adjourned 5 minutes early than 10:00pm EDTWednesday 8 July 2020, 10:00am –01:00pm ET (TGbe MAC ad hoc conference call)Chairman: Jeongki Kim (LG Electronics)Secretary: Liwen Chu (NXP)This meeting took place using a webex session.IntroductionThe Chair (Jeongki, LG) calls the meeting to order at 10:04am EDT. The Chair introduces himself and the Secretary, Liwen Chu (NXP)The Chair goes through the 802 and 802.11 IPR policy and procedures and asks if there is anyone that is aware of any potentially essential patents. Nobody speaks up.The Chair recommends using IMAT for recording the attendance.Please record your attendance during the conference call by using the IMAT system: 1) login to imat, 2) select “802.11 Telecons (<Month>)” entry, 3) select “C/LM/WG802.11 Attendance” entry, 4) click “TGbe <MAC/PHY/Joint> conference call that you are attending.If you are unable to record the attendance via IMAT then please send an e-mail to Jeongki Kim ( HYPERLINK "mailto:jeongki.kim@" jeongki.kim@) and Liwen Chu ( HYPERLINK "mailto:liwen.chu@" liwen.chu@)Recorded attendance through Imat and e-mail:7/8AbidRabbu, Shaima'Istanbul Medipol University; Vestal Company7/8Adhikari, ShubhodeepBroadcom Corporation7/8Agarwal, PeyushBroadcom Corporation7/8Akhmetov, DmitryIntel Corporation7/8Andersdotter, AmeliaNone - Self-funded7/8Baek, SunHeeLG ELECTRONICS7/8baron, stephaneCanon Research Centre France7/8Bhandaru, NehruBroadcom Corporation7/8Boldy, DavidBroadcom Corporation7/8Bredewoud, AlbertBroadcom Corporation7/8Carney, WilliamSony Corporation7/8Cheng, PaulMediaTek Inc.7/8CHERIAN, GEORGEQualcomm Incorporated7/8Chitrakar, RojanPanasonic Asia Pacific Pte Ltd.7/8Choi, JinsooLG ELECTRONICS7/8Coffey, JohnRealtek Semiconductor Corp.7/8Das, DibakarIntel Corporation7/8Das, SubirPerspecta Labs Inc.7/8Derham, ThomasBroadcom Corporation7/8Ding, BaokunHuawei Technologies Co., Ltd7/8Dogan, MithatApple, Inc.7/8Dong, XiandongXiaomi Inc.7/8Doostnejad, RoyaIntel Corporation7/8Erceg, VinkoBroadcom Corporation7/8Fang, YonggangZTE TX Inc7/8Fischer, MatthewBroadcom Corporation7/8Gan, MingHuawei Technologies Co., Ltd7/8Garg, LalitBroadcom Corporation7/8GUIGNARD, RomainCanon Research Centre France7/8Guo, YuchenHuawei Technologies Co., Ltd7/8Han, JonghunSAMSUNG7/8Han, ZhiqiangZTE Corporation7/8Hervieu, LiliCable Television Laboratories Inc. (CableLabs)7/8Ho, DuncanQualcomm Incorporated7/8Hsu, Chien-FangMediaTek Inc.7/8Hu, MengshiHUAWEI7/8Huang, Guogang?Huawei7/8Huang, Po-KaiIntel Corporation7/8Hwang, Sung HyunElectronics and Telecommunications Research Institute (ETRI)7/8Inohiza, HirohikoCanon Inc.7/8Jang, InsunLG ELECTRONICS7/8Jia, JiaHuawei Technologies Co., Ltd7/8Jiang, JinjingApple, Inc.7/8Kain, CarlUSDoT7/8Kakani, NaveenQualcomm Incorporated7/8Kandala, SrinivasSAMSUNG7/8Kedem, OrenHuawei Technologies Co. Ltd7/8kim, namyeongLG ELECTRONICS7/8Kim, SanghyunWILUS Inc7/8Kim, YonghoKorea National University of Transportation7/8Kishida, AkiraNippon Telegraph and Telephone Corporation (NTT)7/8Klein, ArikHuawei Technologies Co. Ltd7/8Kondo, YoshihisaAdvanced Telecommunications Research Institute International (ATR)7/8Kwon, Young HoonNXP Semiconductors7/8Lalam, MassinissaSAGEMCOM BROADBAND SAS7/8Lan, ZhouBroadcom Corporation7/8Lansford, JamesQualcomm Incorporated7/8Le Houerou, BriceCanon Research Centre France7/8Levitsky, IlyaIITP RAS7/8Levy, JosephInterDigital, Inc.7/8Li, YiqingHuawei Technologies Co. Ltd7/8Li, YunboHuawei Technologies Co., Ltd7/8Liang, dandanHuawei Technologies Co., Ltd7/8Lim, Dong GukLG ELECTRONICS7/8Lin, WeiHuawei Technologies Co. Ltd7/8Lou, HanqingInterDigital, Inc.7/8Lu, LiumingZTE Corporation7/8Luo, ChaomingBeijing OPPO telecommunications corp., ltd.7/8Lv, kaiyingMediaTek Inc.7/8Ma, MengyaoHUAWEI7/8Madpuwar, GirishBroadcom Corporation7/8Martinez Vazquez, MarcosMaxLinear Corp7/8Max, SebastianEricsson AB7/8Montreuil, LeoBroadcom Corporation7/8NANDAGOPALAN, SAI SHANKARCypress Semiconductor Corporation7/8Naribole, SharanSAMSUNG7/8Nezou, PatriceCanon Research Centre France7/8Ozbakis, BasakVESTEL7/8Palm, StephenBroadcom Corporation7/8Park, MinyoungIntel Corporation7/8Patil, AbhishekQualcomm Incorporated7/8Petrick, AlbertInterDigital, Inc.7/8Pettersson, CharlieEricsson AB7/8Puducheri, SrinathBroadcom Corporation7/8Qi, EmilyIntel Corporation7/8Rai, KapilQualcomm Incorporated7/8Raissinia, AlirezaQualcomm Incorporated7/8Rosdahl, JonQualcomm Technologies, Inc.7/8Salman, HanadiIstanbul Medipol University7/8Sandhu, ShivrajQualcomm Incorporated7/8Sedin, JonasEricsson AB7/8Segev, JonathanIntel Corporation7/8Seok, YonghoMediaTek Inc.7/8Sevin, JulienCanon Research Centre France7/8Solaija, Muhammad SohaibIstanbul Medipol University; Vestel7/8Song, TaewonLG ELECTRONICS7/8Stacey, RobertIntel Corporation7/8SUH, JUNG HOONHuawei Technologies Co. Ltd7/8Sun, BoZTE Corporation7/8Sun, Li-HsiangInterDigital, Inc.7/8Sun, YanjunQualcomm Incorporated7/8THOUMY, FrancoisCanon Research Centre France7/8Uln, KiranCypress Semiconductor Corporation7/8Verenzuela, DanielSony Corporation7/8Verma, SindhuBroadcom Corporation7/8Wang, Chao ChunMediaTek Inc.7/8Wang, HuizhaoQuantenna Communications, Inc.7/8Wang, LeiHuawei R&D USA7/8Wang, XiaofeiInterDigital, Inc.7/8Wentink, MenzoQualcomm7/8Wullert, JohnPerspecta Labs7/8Yang, JayNokia7/8Yee, JamesMediaTek Inc.7/8yi, yongjiangFuturewei Technologies7/8Yu, JianHuawei Technologies Co., Ltd7/8Zuo, XinTencent7/8 Ghosh, Chittabrata IntelThe Chair reminds that the agenda can be found in 11-20/735r37 with the additional SPs requested through emails. The chair asked whether there is comment about the agenda. The requests of deferred SPs from last week were raised. An argument was raised about some contribvutions were uploaded very late and may not be approriate to be added to the agenda. The agenda was adjusted accordingly. Submissions 357r4 Container for advertising ML Information Abhishek Patil [SP only].?SP 3Do you agree that Multi-Link element if included in a non-ML Probe Request frame shall carry only the MLD-level/common information of the non-AP MLD? NOTE: Whether the Multi-Link element is always present in the non-ML Probe Request frames or is optionally present is TBD.C: from non-AP side, what is the MLD level information?A: STR/non-STR capability etc.C?: is the number of supported links MLD level information?A: it is a good example of MLD level information. C: what is the motivation to include common information? The “shall” is too strong. I am not comfortable about it.A: We define non-ML and ML Probe Request. ML Probe Request will solicit full information. Here we provide the information of non-ML probe.C: since ML common information is just capability announcement. One bit should be enough.A: ML element is not always included in non-ML Probe Request.34Y, 28N, 46A 659r3 TDM Multilink Operation Sindhu Verma.?SummaryThe presentation proposed the TDM multilink operation where a MLD can monitor the medium using multiple radios and use less radio to receive frames.C: you propose a more general session of my ESR idea and with simulation.C: conclusion slide, does the first bullet mean NSTR? What is the difference between your proposal and Minyoung’s ESR idea.A: for the first question we mean NSTR MLD. Our proposal is similar to ESR idea. Our assumption is that the idea can be applied to multi-radio device.C: what is the multi-radio concept? Is multi-radio similar to multi-link?A: radio is related to architecture. We assume the listen can be more links, but the transmission can be in less links.The SP is deferred. 562r5 Enhanced Multi-Link Single Radio Operation Minyoung Park [SP only].?SP 2Do you support the multi-link operation for a non-AP MLD that is defined as follows for R1?An MLD that can: 1) transmit or receive data/management frames to another MLD on one link at a time, and 2) listening on one or more links.The “listening” operation includes CCA as well as receiving initial control messages (e.g., RTS/MU-RTS)The initial control message may have one or more additional limitations: spatial stream, MCS (data rate), PPDU type, frame typeLink switch delay may be indicated by the non-AP MLDC: the concern is the influence on the CCA of the radio. C: what happens if the delay is more than 100us?A: we assume the delay should be about several tens us. Some feedback was received that the delay may be more than several tens us.C: in trigger there is padding feature. Here it is similar to trigger padding.A: but trigger only pad <=16us.C: the trigger padding can be any length.A: worry about whether it can be implemented.C: some concern about the motivation, e.g. cost, improvement compared with normal MLD. Did you consider the sounding in your simulation? If not, the simulation should be done with the consideration of sounding.A: this method can avoid the full MAC, PHY in multiple links. The cost can be decreased.70Y, 28N, 21A1943r8 Multi-link Management [SP only].?SP 3Do you agree to define the following?Single-link/radio (TBD) non-AP MLD: A non-AP MLD that supports operation on more than one link but can only listen, receive, or transmit frames on one link at a time.53Y, 12N, 40A 659r3 TDM Multilink Operation Sindhu Verma [SP only].?SPDo you support the following addition to the SFD:A mode of multi-link operation shall be supported in R1 wherein a non-AP MLD can simultaneously listen on N links and can simultaneously transmit/receive data on M links, where M is a subset of N; M>=1,N>=1The “listen” operation includes CCA as well as receiving initial control messages with specified parameters (e.g., RTS/MU-RTS).The initial control message may have one or more additional limitations: spatial stream, MCS (data rate), PPDU type, frame typeLink switch delay between listen only and transmit/receive operation may be indicated by the non-AP MLD.C: the following text contradict with each other: “M is a subset of N” and “M>=1,N>=1”.A: “M>=1,N>=1” applies to static mode.C: for static, do you need switch delayA: we say that link switch delay may be required.C: it is better to separate them to make things clear.C: how about the link switch delay? RTS may not be able to handle to link switch delay.A: it is transmitter’s choice.C:it is better to change to “M>1”.42Y, 56N, 19A 727r0 MLA link MAC addresses security(Duncan Ho).?SummaryThe presentation addressed the security issue by authenticate the link addresses of MLD. The presentation also proposed to do authentication/association in same link.C: in slide 6, you assume SAE protocol is not used. If SAE protocol is used, step one will not happen. A: SAE has to be studied separately.C: but SP2 includes SAE.A: I can remove SAE from SP2.C: Association Request is changed and relayed. How about Association Response?A: the Association Response is relayed.C: if AP can hear STA’s Association Request, this will not happen.A: the relay can have high power.C: Why do you want to do reassociation in same link as association?A: what the SP mean is that the reassociation is in the same link but may be different from the association link.C: when does the attack happen, in association stage or not?A: in association stage.SP 1Do you agree to the following?A non-AP MLD includes the following in the (re)Association Request frame:The non-AP MLD addressThe MAC addresses of all the STAs of the non-AP MLDAn AP MLD includes the following in the Association Response frame:The AP MLD addressThe MAC addresses of all the APs of the AP MLDC: is this the mandatory requirement? A STA MLD may not want the neighbor to know its multiple link capability and other link’s address.A: if you avoid multiple link capability in this case, in the future this capability will be known.C: you can do association in this link and do secure association for other links.A: I can stop here and do more offline discussion.770r0 MLO: AID Allocation(Yong hoon Kwon).?SummaryThe presentation proposed all STAs of non-AP MLD have same AID and the value is not reserved.The teleconference was adjourned at 01:00pm EDT ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download