IEEE 802.11-19/0181r0: Reducing Capability for Wi-Fi IoT Applications

January 2019 doc.: IEEE 802.11-19/0181r0 Reduced Capability HT Devices Date: 2019-01-16 Name Affiliation Address Phone email 9120 Irvine Center Drive, Ste.200, Irvine, CA 92618, USA Se n Coffey Realtek +1 (415) 572-6221 coffey@realtek.com CIDs addressed: LB 236 CID 2186 (with different proposed change) r0 (January 16, 2019): Initial draft Submission Slide 1 Sean Coffey, Realtek

January 2019 doc.: IEEE 802.11-19/0181r0 Abstract For very low power Wi-Fi IoT applications operating at 2.4 GHz, designers currently must choose between baseline 802.11 (DSSS), 11b (HR), 11g (ERP), and 11n (HT). Each poses problems: ERP devices are required to support 1, 2, 5.5, 11 HR/DSSS and 6, 12, and 24 Mbps rates: the OFDM rates are burdensome and the data rates are often overkill HT adds STBC (good), but also 8 more OFDM rates, extending to 65 Mbps (very bad) But DSSS- and HR/DSSS-only devices don t do any OFDM preamble detect, require single-tone protection modes, increasing time on air and lowering power consumption for all devices in the BSS, including themselves IoT applications and requirements are very heterogeneous, and Wi-Fi is widely perceived to be high power in this market segment. It would be useful to widen the design space by allowing allow reduced functionality HT devices. This presentation introduces a way of achieving this N.B. for information--no motion at January 2019 meeting Submission Slide 2 Sean Coffey, Realtek

January 2019 doc.: IEEE 802.11-19/0181r0 CID 2186 236 2 19.1.1 2949 10 It would be useful for several purposes to add an extra reduced- capability PHY, permitting implementers to choose a subset of PHY modes from the HR/DSSS, ERP, and HT PHYs. For some applications that have stringent constraints on complexity, such as many IoT applications, it might be useful to be able to implement a device that supports only the 1 and 2 Mbps HR/DSSS modes and the 6 Mbps ERP mode, for example (perhaps transmitting at 1 and 2 Mbps most of the time, but able to process 6 Mbps preambles). Or it might be useful to implement a device that implemented only the HR/DSSS rates, but also supported short slot time. At present, such devices would not be IEEE 802.11 compliant. An easy change to the specification would suffice to permit these variations. Interoperability should not be a problem since even a full HT device operating at long range might not be able to process PPDUs sent at any but the lowest rates, and this possibility has existed since the beginning. Submission Slide 3 Sean Coffey, Realtek

January 2019 doc.: IEEE 802.11-19/0181r0 Proposed change 1/2 Add at end of first paragraph of 19.1.1 (Introduction to the HT PHY): "In addition, a reduced capability PHY based on the HT PHY ("RC-HT") is defined in this clause. Submission Slide 4 Sean Coffey, Realtek

January 2019 doc.: IEEE 802.11-19/0181r0 Proposed change 2/2 Add new paragraph at the end of 19.1.1 (2941.41): A non-AP STA is an RC-HT STA if it satisfies all of the following conditions: (1) The STA shall operate in the 2.4 GHz band, and shall have operating channel width 20 MHz; (2) The STA shall support transmission and reception of DSSS 1 Mb/s and 2 Mb/s; (3) The STA shall support DSSS long preamble and short preamble; (4) The CCA functionality for ERP-OFDM in 18.4.6(a),(b) and for HT in 19.3.19.5.4 (CCA Sensitivity in 20 MHz) are optional; (5) Each (non-DSSS) HR/DSSS, ERP-OFDM, and HT data rate is optional; (6) If transmission or reception of any ERP-OFDM or HT data rate is supported, then the STA shall support transmission and reception of ERP-OFDM 6 Mb/s, and the CCA functionality for ERP- OFDM in 18.4.6(a),(b) and for HT in 19.3.19.5.4 shall be supported; (7) The minimum receiver sensitivity requirements of Clauses 15, 16, 17, 18, and 19 are optional; (8) In all other respects the STA shall follow the requirements of the HT PHY. NOTE--In particular, an RC-HT STA shall signal HT capabilities during association and reassociation, and in beacons and probe requests." Submission Slide 5 Sean Coffey, Realtek

January 2019 doc.: IEEE 802.11-19/0181r0 Comments I Interoperability: No real distinction between RC-HT devices and HT devices operating at long enough range that many data rates don t work this happens all the time By including the lowest rates, we ensure that fallback ends up with rates that work If beacons are sent at a rate the RC-HT STA doesn t support (e.g., 11 Mbps), the STA may associate but immediately drop again no difference to case where the STA is too far RC-HT versus pure DSSS or HR/DSSS: An RC-HT device that implements only DSSS or HR/DSSS rates (which is allowed) has the following differences compared to a DSSS or HR/DSSS device: RC-HT STA supports short (9 s) slot time not defined in Clauses 15/16 and no way to signal (APs must switch to 20 s slot when NonERP device associates) RC-HT STA does not trigger required single-tone protection for all transmissions in the BSS (and possibly OBSSs) RC-HT STA supports DSSS short (96 s) preamble (optional for ERP) Submission Slide 6 Sean Coffey, Realtek

January 2019 doc.: IEEE 802.11-19/0181r0 Comments II No change to other rules: All devices continue to support transmission and reception of 1 Mbps and 2 Mbps DSSS, and the DSSS long preamble Requirements to protect pure DSSS / HR/DSSS devices remain unchanged designers remain free to choose such devices No additional requirements for other devices RC-HT STA represents itself as an HT STA; it doesn t ask for any special treatment by AP Advantages for RC-HT: IEEE compliant, so (in principle) can use technology from Clauses 15-19 Standardization of requirements high degree of flexibility, but not unlimited eases the task of managing variant devices IEEE adoption helps get modes adopted in other industry organizations Submission Slide 7 Sean Coffey, Realtek

January 2019 doc.: IEEE 802.11-19/0181r0 Next steps A motion to adopt the changes on slides 4-5 will be made during the March 2019 meeting Submission Slide 8 Sean Coffey, Realtek