November 2018 doc IEEE 802 11 181725 r

November 2018 doc. : IEEE 802. 11 -18/1725 r 1 ARC-SC-agenda-Nov-2018 Date: 2018 -11 -12 Authors: Agenda Slide 1 Mark Hamilton, Ruckus/ARRIS

November 2018 doc. : IEEE 802. 11 -18/1725 r 1 Abstract Agenda for: ARC SC, November 2018, Bangkok, Thailand Agenda Slide 2 Mark Hamilton, Ruckus/ARRIS

November 2018 doc. : IEEE 802. 11 -18/1725 r 1 IEEE 802. 11 Architecture Standing Committee Agenda November 2018 session Chair: Mark Hamilton (Ruckus/ARRIS) Vice Chair: Joe Levy (Inter. Digital) Agenda Slide 3 Mark Hamilton, Ruckus/ARRIS

November 2018 doc. : IEEE 802. 11 -18/1725 r 1 Tuesday, November 12 th, PM 2 Agenda Slide 4 Mark Hamilton, Ruckus/ARRIS

November 2018 doc. : IEEE 802. 11 -18/1725 r 1 Attendance, etc. • Reminders to attendees: – Sign in for. 11 attendance credit – Noises off – No recordings Agenda Slide 5 Mark Hamilton, Ruckus/ARRIS

November 2018 doc. : IEEE 802. 11 -18/1725 r 1 Participants, Patents, and Duty to Inform All participants in this meeting have certain obligations under the IEEE-SA Patent Policy. • Participants [Note: Quoted text excerpted from IEEE-SA Standards Board Bylaws subclause 6. 2]: • “Shall inform the IEEE (or cause the IEEE to be informed)” of the identity of each “holder of any potential Essential Patent Claims of which they are personally aware” if the claims are owned or controlled by the participant or the entity the participant is from, employed by, or otherwise represents • “Should inform the IEEE (or cause the IEEE to be informed)” of the identity of “any other holders of potential Essential Patent Claims” (that is, third parties that are not affiliated with the participant, with the participant’s employer, or with anyone else that the participant is from or otherwise represents) • The above does not apply if the patent claim is already the subject of an Accepted Letter of Assurance that applies to the proposed standard(s) under consideration by this group • Early identification of holders of potential Essential Patent Claims is strongly encouraged • No duty to perform a patent search Agenda Slide 6 Mark Hamilton, Ruckus/ARRIS

November 2018 doc. : IEEE 802. 11 -18/1725 r 1 Patent Related Links All participants should be familiar with their obligations under the IEEE-SA Policies & Procedures for standards development. Patent Policy is stated in these sources: IEEE-SA Standards Boards Bylaws http: //standards. ieee. org/develop/policies/bylaws/sect 6 -7. html#6 IEEE-SA Standards Board Operations Manual http: //standards. ieee. org/develop/policies/opman/sect 6. html#6. 3 Material about the patent policy is available at http: //standards. ieee. org/about/sasb/patcom/materials. html If you have questions, contact the IEEE-SA Standards Board Patent Committee Administrator at patcom@ieee. org or visit http: //standards. ieee. org/about/sasb/patcom/index. html This slide set is available at https: //development. standards. ieee. org/myproject/Public/mytools/mob/slideset. ppt Agenda Slide 7 Mark Hamilton, Ruckus/ARRIS

November 2018 doc. : IEEE 802. 11 -18/1725 r 1 Call for Potentially Essential Patents • If anyone in this meeting is personally aware of the holder of any patent claims that are potentially essential to implementation of the proposed standard(s) under consideration by this group and that are not already the subject of an Accepted Letter of Assurance: • Either speak up now or • Provide the chair of this group with the identity of the holder(s) of any and all such claims as soon as possible or • Cause an LOA to be submitted Agenda Slide 8 Mark Hamilton, Ruckus/ARRIS

November 2018 doc. : IEEE 802. 11 -18/1725 r 1 Participation in IEEE 802 Meetings Participation in any IEEE 802 meeting (Sponsor, Sponsor subgroup, Working Group subgroup, etc. ) is on an individual basis • Participants in the IEEE standards development individual process shall act based on their qualifications and experience. (https: //standards. ieee. org/develop/policies/bylaws/sb_bylaws. pdf section 5. 2. 1) • IEEE 802 Working Group membership is by individual; “Working Group members shall participate in the consensus process in a manner consistent with their professional expert opinion as individuals, and not as organizational representatives”. (subclause 4. 2. 1 “Establishment”, of the IEEE 802 LMSC Working Group Policies and Procedures) • Participants have an obligation to act and vote as an individual and not under the direction of any other individual or group. A Participant’s obligation to act and vote as an individual applies in all cases, regardless of any external commitments, agreements, contracts, or orders. • Participants shall not direct the actions or votes of any other member of an IEEE 802 Working Group or retaliate against any other member for their actions or votes within IEEE 802 Working Group meetings, see https: //standards. ieee. org/develop/policies/bylaws/sb_bylaws. pdf section 5. 2. 1. 3 and the IEEE 802 LMSC Working Group Policies and Procedures, subclause 3. 4. 1 “Chair”, list item x. By participating in IEEE 802 meetings, you accept these requirements. If you do not agree to these policies then you shall not participate. (Latest revision of IEEE 802 LMSC Working Group Policies and Procedures: http: //www. ieee 802. org/devdocs. shtml) Agenda Slide 9 Mark Hamilton, Ruckus/ARRIS

November 2018 doc. : IEEE 802. 11 -18/1725 r 1 Other Guidelines for IEEE WG Meetings • All IEEE-SA standards meetings shall be conducted in compliance with all applicable laws, including antitrust and competition laws. • • Don’t discuss the interpretation, validity, or essentiality of patents/patent claims. Don’t discuss specific license rates, terms, or conditions. • Relative costs, including licensing costs of essential patent claims, of different technical approaches may be discussed in standards development meetings. • • Technical considerations remain primary focus Don’t discuss or engage in the fixing of product prices, allocation of customers, or division of sales markets. • Don’t discuss the status or substance of ongoing or threatened litigation. • Don’t be silent if inappropriate topics are discussed … do formally object. -------------------------------- See IEEE-SA Standards Board Operations Manual, clause 5. 3. 10 and “Promoting Competition and Innovation: What You Need to Know about the IEEE Standards Association's Antitrust and Competition Policy” for more details. Agenda Slide 10 Mark Hamilton, Ruckus/ARRIS

November 2018 doc. : IEEE 802. 11 -18/1725 r 1 ARC Agenda – November 2018 (1 of 2) Tuesday, November 13, PM 2 • • • Administrative: Minutes IEEE 1588 mapping to IEEE 802. 11/802. 1 ASrev and use of FTM 802 (and 802. 1) activities: 802. 1 CQ IETF/802 coordination WBA liaison, on MAC Address Randomization: 11 -18/1579 r 1, 1118/1671 r 0 Wednesday, November 14, AM 1 • TGba (WUR) continued discussion: 11 -18/1017 r 0, 11 -18/1020 r 5, 1118/1494 r 2, 11 -18/1641 r 0 • New topics: • Multiple MAC Addresses (and IPv 6), “Multiple radios” • System architecture views for common use scenarios • Continue the other items (previous slide), as needed Agenda Slide 11 Mark Hamilton, Ruckus/ARRIS

November 2018 doc. : IEEE 802. 11 -18/1725 r 1 ARC Agenda – September 2018 (2 of 2) Thursday, November 15, AM 2 • Future sessions / SC activities • Finalize Response to WBA liaison, on MAC Address Randomization • NEW TOPIC: Multiple MAC Addresses (and IPv 6), “Multiple radios” (any contributions? ) • NEW TOPIC: System architecture views for common use scenarios (any contributions? ) • “What is an ESS? ”: 11 -18/1051 r 3 • Consider IETF Det. Net/time-sensitive networking input (potential relationship to RTA TIG? ) • AP/DS/Portal architecture and 802 and GLK concepts - 11 -17/0136 r 2, 1116/1512 r 0, 11 -16/0720 r 0, 11 -15/0454 r 0, 11 -14/1213 r 1 (slides 9 -11) • MLME-RESET, versus MLME-JOIN and MLME-START • Does TGba discussion lead into other “split” PHYs (LC, 28 GHz (Phazr))? • Continue the other items (above/previous slide), as needed Agenda Slide 12 Mark Hamilton, Ruckus/ARRIS

November 2018 doc. : IEEE 802. 11 -18/1725 r 1 Prior ARC Minutes • September face-to-face minutes: – https: //mentor. ieee. org/802. 11/dcn/18/11 -18 -1726 -00 -0 arc-scmeeting-minutes-september-2018. docx • Oct 11 teleconference: – < link TBD> Agenda Slide 13 Mark Hamilton, Ruckus/ARRIS

November 2018 doc. : IEEE 802. 11 -18/1725 r 1 IEEE 1588 mapping to IEEE 802. 11/ 802. 1 ASrev use of FTM update • Update (Ganesh Venkatesan) • IEEE 1588/802. 1 AS – First Sponsor Ballot of IEEE 1588 revision, Sept 17 – Oct 28 • 802. 1 ASrev use of 802. 11 FTM: – D 7. 3 in WG recirculation comment resolution (802 -1 AS-rev-d 73. pdf, 802 -1 AS-rev-d 7 -3 -dis-v 01. pdf ) Agenda Slide 14 Mark Hamilton, Ruckus/ARRIS

November 2018 doc. : IEEE 802. 11 -18/1725 r 1 IEEE 802 activities directly related to IEEE 802. 11 ARC • 802. 1 CQ update (Stephen Mc. Cann/Roger Marks) – 802. 1 CQ in Scenarios and Functions gathering process – Considering Local MAC Address Assignment Protocol(LAAP) • Discovery of an address server for local addresses on the network • Relation to 802. 11 aq/other 802. 11? – Discuss with ARC, and 11 aq experts Agenda Slide 15 Mark Hamilton, Ruckus/ARRIS

November 2018 doc. : IEEE 802. 11 -18/1725 r 1 IETF/802 coordination • Peter Yee present topics of interest: Agenda Slide 16 Mark Hamilton, Ruckus/ARRIS

November 2018 doc. : IEEE 802. 11 -18/1725 r 1 WBA liaison on MAC Address randomization • Incoming liaison is here: 11 -18/1579 r 1 – Points out several areas of concern for WBA members, if/when MAC Addresses are randomized – Majority of concerns (but not all) are higher layer uses – Majority of concerns are post-association w/random MAC Address • Discussion notes for 802. 11 (ARC) discussion so far, are here: 11 -18/1671 r 0 • Continue discussion, form proposed response Agenda Slide 17 Mark Hamilton, Ruckus/ARRIS

November 2018 doc. : IEEE 802. 11 -18/1725 r 1 Wednesday, November 14 th, AM 1 Agenda Slide 18 Mark Hamilton, Ruckus/ARRIS

November 2018 doc. : IEEE 802. 11 -18/1725 r 1 TGba architecture topics • Investigation of TGba (WUR) architecture topics – May lead into discussion of other “split” PHYs (LC, 28 GHz (Phazr)) - Thursday • Latest Presentations: – – State machine view: 11 -18/1020 r 5 Power Saving overview (WUR experts): 11 -18/1494 r 4 Nomenclature proposal: 11 -18/1641 r 0 Architecture: 11 -18/1017 r 1 • Background Presentations: – – – – Agenda “ 802. 11 BA topics related to ARC” (Ganesh Venkatesan) 11 -18/0533 r 2 “ 11 BA Arch Discussion” (Mark Hamilton) 11 -17/1025 r 0 Review of “ 802. 11 ba Architecture discussion” (Ganesh Venkatesan) 11 -18/0884 r 1 Review of “Definition of WUR Mode” (11 -17 -0972 r 2) Review of Specification Framework (11 -17/0575 r 11) Review of inputs from ARC teleconferences: 11 -18/1016 r 0, Also see following slides Slide 19 Mark Hamilton, Ruckus/ARRIS

November 2018 doc. : IEEE 802. 11 -18/1725 r 1 TGba architecture comments/answers to questions in 11 -17/1025 (from July 10, 2017 TGba) • • • Ba ckg r Yes, fully independent PHY Probably independent MAC? Always co-located with AP or non-AP STA – a “companion” radio No MAC Address (? ) WUR MAC (assuming it is independent) does need to coordinate with the main MAC. Main MAC negotiates a WUR ID on WUR’s behalf, for example. And, power on/off needs to be coordinated between them – might be through higher layer entity, though (? ) • WUR does not associate to the BSS (it doesn’t have a MAC Address) • WUR only runs in 2. 4/5 GHz. But, can work with all PHYs (maybe? ) • Mesh, IBSS, OCB uses are TBD in the future, not now Agenda Slide 20 oun d Mark Hamilton, Ruckus/ARRIS

November 2018 doc. : IEEE 802. 11 -18/1725 r 1 TGba architecture new questions (from July 12, 2017 ARC) • • Ba ckg r Does every WUR stack have an individual “ID” (“WUR address”)? Or, could a given WUR stack be only addressed using a “group ID” in some scenarios? How are WUR ID’s made globally unique, or are they? What about overlapping WUR coverage? Prevented using the same solution as security protections? Prevented through selection of different sub-carriers? How does the WUR stack become aware of ongoing NAV protections? RX doesn’t need to know. What about the TXr? For protection – how much of a legacy frame header is sent? Just PHY header? Some MAC header (addresses? NAV? Etc) Is there any sharing (necessarily, as part of the design, not implementation choice) of RF front-end? What happens when the Main stack wakes up? Does it still have an association? Is it in some power save state (which)? “Yes, fully independent PHY” – is that for the RX side, or the TX side? What about error recovery? STA goes out of range? What if the AP changes (DFS, ITS, etc)? Agenda Slide 21 oun d Mark Hamilton, Ruckus/ARRIS

November 2018 doc. : IEEE 802. 11 -18/1725 r 1 TGba architecture potential assumptions (from July 12, 2017 ARC) • • • Ba ckg r How does the WUR stack become aware of ongoing NAV protections? RX doesn’t need to know. The master’s Main stack runs the usual medium access, and wait until it has a TXop, then triggers the WUR to TX. On the RXr, only one stack (WUR or Main) are active at a given point in time. When the Main stack wakes up, it still has an association and is in a power save state (a new “WUR” power save state). The Main stack TXs, which is the indication that the wakeup was successful and completed. There are RX–only WURs, at the sleeping node. There are TX-only WURs on the master node, and these are therefore (likely) different architecturally. The WUR “wakeup” frame does not NAV protect to cover the sleeping device’s Main radio waking up and TXing. oun d Review 11 -17/972 to confirm/before proceeding on the above Agenda Slide 22 Mark Hamilton, Ruckus/ARRIS

November 2018 doc. : IEEE 802. 11 -18/1725 r 1 Thursday, November 15 th, AM 2 Agenda Slide 23 Mark Hamilton, Ruckus/ARRIS

November 2018 doc. : IEEE 802. 11 -18/1725 r 1 ARC Future Activities & sessions • ARC SC meets when a specific focused task is requested of the SC for which the is sufficient volunteer interest. • Continue work on architectural models, and liaison with TGs in development of their architecture as appropriate • Investigation of WUR architecture topics; may lead into “split” PHYs (LC, 28 GHz (Phazr)) • Investigation of 802. 11 as part of a Deterministic Network • Multiple MAC Address discussion (IPv 6) – perhaps “multiple radios” too • System architecture(s) for common use scenarios • Will also follow 802. 1/802. 11 activities on links, bridging, and MAC Service definition – “What is an ESS? ”, for example • MLME-RESET, versus MLME-JOIN and MLME-START • Monitor/report on IETF/802 activities, as needed • Monitor/report on IEEE 1588 activities and 802. 1 ASrev use of FTM, as needed If you have ANY other topic that you would like ARC SC to consider, contact the SC chair. Agenda Slide 24 Mark Hamilton, Ruckus/ARRIS

November 2018 doc. : IEEE 802. 11 -18/1725 r 1 Planning for January 2019 • Plan for three individual meeting slots – Usual slot on Wed AM 1 – Another 2 slots for standalone ARC work (Monday/Tuesday? ) – Plus Joint sessions: Another with TGba? • Individuals interested in ARC work are encouraged to also attend AANI SC sessions • Teleconferences: – None planned. Agenda Slide 25 Mark Hamilton, Ruckus/ARRIS

November 2018 doc. : IEEE 802. 11 -18/1725 r 1 What is an ESS? • See 11 -18/1051 r 3 Agenda Slide 26 Mark Hamilton, Ruckus/ARRIS

November 2018 doc. : IEEE 802. 11 -18/1725 r 1 Det. Net and other time-sensitive networking, (IETF, RTA TIG, etc. ) • • • IETF TSN paper declares 802. 11 inappropriate for deterministic networking. But, 802. 15. 4 TSCH appears to be appropriate. Can 802. 11 be used? If not, can/should 802. 11 be “improved” so that it can be used? Does 11 ax scheduling fit into this? What are the requirements coming from the RTA TIG, and do those change the above? Agenda Slide 27 Mark Hamilton, Ruckus/ARRIS

November 2018 doc. : IEEE 802. 11 -18/1725 r 1 AP/DS/Portal architecture and 802 concepts • Presentations on architectural description(s) – https: //mentor. ieee. org/802. 11/dcn/17/11 -17 -0136 -02 -0 arc-bridging-architectureconsiderations. docx • Reference presentations (previously reviewed, current status of thinking): Agenda – https: //mentor. ieee. org/802. 11/dcn/14/11 -14 -1213 -01 -0 arc-ap-arch-concepts-anddistribution-system-access. pptx – https: //mentor. ieee. org/802. 11/dcn/13/11 -13 -0115 -15 -0 arc-considerations-on-aparchitectural-models. doc – https: //mentor. ieee. org/802. 11/dcn/14/11 -14 -0497 -03 -0 arc-802 -11 -portal-and-8021 ac-convergence-function. pptx – https: //mentor. ieee. org/802. 11/dcn/14/11 -14 -0562 -05 -00 ak-802 -11 ak-and-802 -1 acconvergence-function. pptx – https: //mentor. ieee. org/802. 11/dcn/15/11 -15 -0454 -00 -0 arc-some-more-dsarchitecture-concepts. pptx – https: //mentor. ieee. org/802. 11/dcn/16/11 -16 -0720 -00 -0 arc-stacked-architecturediscussion. pptx Slide 28 Mark Hamilton, Ruckus/ARRIS

November 2018 doc. : IEEE 802. 11 -18/1725 r 1 MLME-RESET, versus MLME-JOIN and MLME-START Topic out of REVmd: • No apparent requirement for an “initial” MLME-RESET, in 802. 11. So, what is the initial state? • Many MIB attributes describe taking effect at next MLME-JOIN or MLME-START. – MLME-JOIN occurs at each BSS transition – MLME-START occurs at less well-defined points, seems to require an MLMERESET first – Do these attributes really take effect at these points, or at the MLME-RESET? • How about other state information, such as security association, block agreements, etc. ? Agenda Slide 29 Mark Hamilton, Ruckus/ARRIS