IEEE P802.11be/D1.

5, March 2022

1 IEEE P802.11be™/D1.5, March 2022

2
(amendment to IEEE 802.11-2020 standards
3
4 as amended by IEEE P802.11ax™-2021,
5 IEEE P802.11ay™-2021,
6 IEEE P802.11az™/D4.0,
7 IEEE P802.11ba™-2021,
8 IEEE P802.11bb™/D0.7,
9 IEEE P802.11bc™/D2.0,
10
IEEE P802.11bd™/D2.1)
11
12 and IEEE P802.11-REVme™/D1.1)

IEEE P802.11be™/D1.5 
13
14
15
16
17
Draft Standard for Information technology— Tele-
18
19 communications and information exchange between
20
21 systems Local and metropolitan area networks—
22
23 Specific requirements
24
25
26

27
28
Part 11: Wireless LAN Medium Access Control 
29
30 (MAC) and Physical Layer (PHY) Specifications
31
32 
33
34 Amendment 8: Enhancements for extremely high
35
36
37
throughput (EHT)
38
39
40 Prepared by the 802.11 Working Group of the
41
42 LAN/MAN Standards Committee 
43 of the IEEE Computer Society
44
45 Copyright © 2022 by the IEEE.
46
Three Park Avenue
47
48 New York, New York 10016-5997, USA
49 All rights reserved.
50
51
This document is an unapproved draft of a proposed IEEE Standard. As such, this document is subject to
52
53 change. USE AT YOUR OWN RISK! Because this is an unapproved draft, this document must not be
54 utilized for any conformance/compliance purposes. Permission is hereby granted for IEEE Standards
55 Committee participants to reproduce this document for purposes of international standardization
56 consideration. Prior to adoption of this document, in whole or in part, by another standards development
57
organization permission must first be obtained from the IEEE Standards Activities Department
58
59 ([email protected]). Other entities seeking permission to reproduce this document, in whole or in part, must
60 also obtain permission from the IEEE Standards Activities Department.
61
62 IEEE Standards Activities Department
63
64 445 Hoes Lane
65 Piscataway, NJ 08854, USA

Copyright © 2022 IEEE. All rights reserved. 1

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Abstract: This amendment defines standardized modifications to both the IEEE Std 802.11 physi-
2 cal layers (PHY) and the Medium Access Control Layer (MAC) that enable at least one mode of
3
operation capable of supporting a maximum throughput of at least 30 Gbps, as measured at the
4
5 MAC data service access point (SAP), with carrier frequency operation between 1 and 7.250 GHz
6 while ensuring backward compatibility and coexistence with legacy IEEE Std 802.11 compliant
7 devices operating in the 2.4 GHz, 5 GHz, and 6 GHz bands. This amendment defines at least one
8 mode of operation capable of improved worst case latency and jitter.
9
10
11 Keywords: EHT, extremely high throughput, jitter, latency, MAC, medium access control, PHY,
12 physical layer, wireless local area network, WLAN
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

2 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2
Introduction
3
4 This introduction is not part of IEEE P802.11be /D1.5, March 2022, IEEE Standard for Information technology—
5 Telecommunications and information exchange between systems—Local and metropolitan area network—Spe-
6 cific requirements—Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifica-
7 tions—Amendment 8: Enhancements for extremely high throughput (EHT).
8
9
10
11
12 This amendment defines standardized modifications to both the IEEE Std 802.11 physical layers (PHY) and
13 the Medium Access Control Layer (MAC) that enable at least one mode of operation capable of supporting
14 a maximum throughput of at least 30 Gbps, as measured at the MAC data service access point (SAP), with
15 carrier frequency operation between 1 and 7.250 GHz while ensuring backward compatibility and
16
17 coexistence with legacy IEEE Std 802.11 compliant devices operating in the 2.4 GHz, 5 GHz, and 6 GHz
18 bands. This amendment defines at least one mode of operation capable of improved worst case latency and
19 jitter.
20
21
22 Laws and regulations
23
24 Users of these documents should consult all applicable laws and regulations. Compliance with the
25
provisions of this standard does not imply compliance to any applicable regulatory requirements.
26
27 Implementers of the standard are responsible for observing or referring to the applicable regulatory
28 requirements. IEEE does not, by the publication of its standards, intend to urge action that is not in
29 compliance with applicable laws, and these documents may not be construed as doing so.
30
31
32 Copyrights
33
34
35 This document is copyrighted by the IEEE. It is made available for a wide variety of both public and private
36 uses. These include both use, by reference, in laws and regulations, and use in private self-regulation,
37 standardization, and the promotion of engineering practices and methods. By making this document
38
39
available for use and adoption by public authorities and private users, the IEEE does not waive any rights in
40 copyright to this document.
41
42
43 Updating of IEEE documents
44
45
46 Users of IEEE standards should be aware that these documents may be superseded at any time by the
47 issuance of new editions or may be amended from time to time through the issuance of amendments,
48 corrigenda, or errata. An official IEEE document at any point in time consists of the current edition of the
49 document together with any amendments, corrigenda, or errata then in effect. In order to determine whether
50 a given document is the current edition and whether it has been amended through the issuance
51
52 of amendments, corrigenda, or errata, visit the IEEE Standards Association website at http://
53 ieeexplore.ieee.org/xpl/standards.jsp, or contact the IEEE at the address listed previously.
54
55 For more information about the IEEE Standards Association or the IEEE standards development process,
56
57 visit the IEEE-SA website at http://standards.ieee.org.
58
59
60 Errata
61
62
Errata, if any, for this and all other standards can be accessed at the following URL: http://
63
64 standards.ieee.org/findstds/errata/index.html. Users are encouraged to check this URL for errata
65 periodically.

Copyright © 2022 IEEE. All rights reserved. 3

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Patents
2
3
4 Attention is called to the possibility that implementation of this standard may require use of subject matter
5 covered by patent rights. By publication of this standard, no position is taken by the IEEE with respect to the
6 existence or validity of any patent rights in connection therewith. If a patent holder or patent applicant has
7 filed a statement of assurance via an Accepted Letter of Assurance, then the statement is listed on the IEEE-
8 SA Website at http://standards.ieee.org/about/sasb/patcom/patents.html. Letters of Assurance may indicate
9
10 whether the Submitter is willing or unwilling to grant licenses under patent rights without compensation or
11 under reasonable rates, with reasonable terms and conditions that are demonstrably free of any unfair dis-
12 crimination to applicants desiring to obtain such licenses.
13
14 Essential Patent Claims may exist for which a Letter of Assurance has not been received. The IEEE is not
15
16 responsible for identifying Essential Patent Claims for which a license may be required, for conducting
17 inquiries into the legal validity or scope of Patents Claims, or determining whether any licensing terms or
18 conditions provided in connection with submission of a Letter of Assurance, if any, or in any licensing
19 agreements are reasonable or non-discriminatory. Users of this standard are expressly advised that determi-
20 nation of the validity of any patent rights, and the risk of infringement of such rights, is entirely their own
21
22 responsibility. Further information may be obtained from the IEEE Standards Association.
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

4 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Participants
2
3
4 At the time this revision was sent to sponsor ballot, the IEEE 802.11 Working Group had the following
5 officers:
6
7 Dorothy Stanley, Chair
8
9 Jon W. Rosdahl, 1st Vice Chair
10 Robert Stacey, 2nd Vice Chair
11 Stephen McCann, Secretary
12
13 The officers and members of the Task Group be Working Group ballot pool are as follows:
14
15
16 Alfred Asterjadhi, Chair
17 Laurent Cariou, Vice Chair
18 Matthew Fischer, Vice Chair
19 Dennis Sundman, Secretary
20
21 Edward Au, Technical Editor
22
23 Editor’s Note: A 3-column list of working group voters at the time the working group first approved the
24 draft will be inserted here.
25
26
27 Major contributions were received from the following individuals:
28
29 Editor’s Note: A 3-column list of those who made major contributions will be inserted here.
30
31 The following members of the individual balloting committee voted on this revision. Balloters may have
32
33 voted for approval, disapproval, or abstention.
34
35 Editor’s Note: A 3-column list of sponsor ballot voters will be inserted here.
36
37 Editor’s Note: The date of approval will be inserted on the following line.
38
39
40 When the IEEE-SA Standards Board approved this revision on <date>, it had the following membership:
41
42 Editor’s Note: The officers of the IEEE-SA Standards board will be inserted here.
43
44
45 Editor’s Note: A 3-column list of the IEEE-SA Standards board members will be inserted here.
46
47 Also included are the following nonvoting IEEE-SA Standards Board liaisons:
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 5

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

6 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Contents
2
3
4 Contents ............................................................................................................................................... 7
5
6 Figures ............................................................................................................................................... 27
7
8
Tables................................................................................................................................................. 33
9
10
11 Editorial Notes ................................................................................................................................... 39
12
13 1. Overview............................................................................................................................................ 43
14
15
16 1.5 Terminology for mathematical, logical, and bit operations....................................................... 43
17
18 3. Definitions, acronyms, and abbreviations.......................................................................................... 45
19
20
3.1 Definitions ................................................................................................................................. 45
21
22 3.2 Definitions specific to IEEE 802.11 .......................................................................................... 45
23 3.4 Abbreviations and acronyms ..................................................................................................... 52
24
25 4. General description ............................................................................................................................ 53
26
27
28 4.3 Components of the IEEE Std 802.11 architecture ..................................................................... 53
29 4.3.16aExtremely high throughput (EHT) STA ........................................................................ 53
30 4.3.21 Wireless network management ...................................................................................... 54
31 4.3.21.2 BSS max idle period management................................................................. 54
32
4.3.21.23 WNM sleep mode .......................................................................................... 54
33
34 4.3.21.24 MLD max idle period management ............................................................... 55
35 4.5 Overview of the services............................................................................................................ 55
36 4.5.3 Connectivity-related services......................................................................................... 55
37 4.5.3.1 General........................................................................................................... 55
38
4.5.3.2 Mobility types ................................................................................................ 55
39
40 4.5.3.3 Association..................................................................................................... 56
41 4.5.3.4 Reassociation ................................................................................................. 57
42 4.5.3.5 Disassociation ................................................................................................ 58
43 4.5.13 EPCS priority access(#5284) ......................................................................................... 58
44
4.9 Reference model ........................................................................................................................ 59
45
46 4.9.5 Reference model for multi-link operation (MLO)(#2239)(#2720)(#3410)(#3417) ...... 59
47
48 5. MAC service definition ..................................................................................................................... 63
49
50
5.1 Overview of MAC services ....................................................................................................... 63
51
52 5.1.5 MAC data service architecture ...................................................................................... 63
53 5.1.5.1 General........................................................................................................... 63
54 5.1.5.10 Non-AP MLD role(#2239) ............................................................................ 65
55 5.1.5.11 AP MLD role(#2239)..................................................................................... 65
56
57
58 6. Layer management............................................................................................................................. 67
59
60 6.3 MLME SAP interface ................................................................................................................ 67
61 6.3.3 Scan................................................................................................................................ 67
62
6.3.3.2 MLME-SCAN.request(#1004)(#2246).......................................................... 67
63
64 6.3.3.2.2Semantics of the service primitive................................................... 67
65 6.3.3.3 MLME-SCAN.confirm(#1004)(#2246) ........................................................ 68

Copyright © 2022 IEEE. All rights reserved. 7

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 6.3.3.3.2Semantics of the service primitive................................................... 68

2 6.3.4 Synchronization ............................................................................................................. 68
3
6.3.4.2 MLME-JOIN.request(#1004)(#2246)............................................................ 68
4
5 6.3.4.2.2Semantics of the service primitive................................................... 68
6 6.3.5 Authenticate ................................................................................................................... 69
7 6.3.5.1 Introduction.................................................................................................... 69
8 6.3.5.2 MLME-AUTHENTICATE.request ............................................................... 69
9
6.3.5.2.2Semantics of the service primitive................................................... 69
10
11 6.3.5.2.3When generated ............................................................................... 69
12 6.3.5.2.4Effect of receipt ............................................................................... 69
13 6.3.5.3 MLME-AUTHENTICATE.confirm.............................................................. 70
14 6.3.5.3.2Semantics of the service primitive................................................... 70
15
6.3.5.4 MLME-AUTHENTICATE.indication .......................................................... 70
16
17 6.3.5.4.1Function ........................................................................................... 70
18 6.3.5.4.2Semantics of the service primitive................................................... 70
19 6.3.5.5 MLME-AUTHENTICATE.response ............................................................ 71
20 6.3.5.5.1Function ........................................................................................... 71
21
6.3.5.5.2Semantics of the service primitive................................................... 71
22
23 6.3.5.5.3When generated ............................................................................... 71
24 6.3.6 Deauthenticate ............................................................................................................... 71
25 6.3.6.2 MLME-DEAUTHENTICATE.request.......................................................... 71
26 6.3.6.2.3When generated ............................................................................... 71
27
6.3.7 Associate ........................................................................................................................ 72
28
29 6.3.7.1 Introduction.................................................................................................... 72
30 6.3.7.2 MLME-ASSOCIATE.request........................................................................ 72
31 6.3.7.2.1Function ........................................................................................... 72
32 6.3.7.2.2Semantics of the service primitive................................................... 72
33
6.3.7.2.3When generated ............................................................................... 73
34
35 6.3.7.2.4Effect of receipt ............................................................................... 73
36 6.3.7.3 MLME-ASSOCIATE.confirm ...................................................................... 74
37 6.3.7.3.1Function ........................................................................................... 74
38 6.3.7.3.2Semantics of the service primitive................................................... 74
39
6.3.7.3.3When generated ............................................................................... 75
40
41 6.3.7.4 MLME-ASSOCIATE.indication ................................................................... 75
42 6.3.7.4.1Function ........................................................................................... 75
43 6.3.7.4.2Semantics of the service primitive................................................... 75
44 6.3.7.5 MLME-ASSOCIATE.response ..................................................................... 76
45
6.3.7.5.1Function ........................................................................................... 76
46
47 6.3.7.5.2Semantics of the service primitive................................................... 76
48 6.3.7.5.3When generated ............................................................................... 77
49 6.3.8 Reassociate..................................................................................................................... 78
50 6.3.8.1 Introduction.................................................................................................... 78
51
6.3.8.2 MLME-REASSOCIATE.request .................................................................. 78
52
53 6.3.8.2.1Function ........................................................................................... 78
54 6.3.8.2.2Semantics of the service primitive................................................... 78
55 6.3.8.2.3When generated ............................................................................... 79
56 6.3.8.2.4Effect of receipt ............................................................................... 79
57
6.3.8.3 MLME-REASSOCIATE.confirm ................................................................. 79
58
59 6.3.8.3.1Function ........................................................................................... 79
60 6.3.8.3.2Semantics of the service primitive................................................... 79
61 6.3.8.3.3When generated ............................................................................... 80
62 6.3.8.4 MLME-REASSOCIATE.indication .............................................................. 80
63
6.3.8.4.2Semantics of the service primitive................................................... 80
64
65 6.3.8.5 MLME-REASSOCIATE.response ................................................................ 81

8 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 6.3.8.5.1Function ........................................................................................... 81
2 6.3.8.5.2Semantics of the service primitive................................................... 82
3
6.3.8.5.3When generated ............................................................................... 83
4
5 6.3.9 Disassociate ................................................................................................................... 83
6 6.3.9.1 MLME-DISASSOCIATE.request ................................................................. 83
7 6.3.9.1.3When generated ............................................................................... 83
8 6.3.11 Start ................................................................................................................................ 83
9
6.3.11.2 MLME-START.request(#1004)(#2246)........................................................ 83
10
11 6.3.11.2.2Semantics of the service primitive................................................. 83
12 6.3.12 Stop ................................................................................................................................ 84
13 6.3.12.2 MLME-Stop.request ...................................................................................... 84
14 6.3.12.2.3When generated ............................................................................. 84
15
6.3.39 SA Query support .......................................................................................................... 84
16
17 6.3.39.1 General........................................................................................................... 84
18 6.3.39.2 MLME-SA-QUERY.request ......................................................................... 84
19 6.3.39.2.1Function ......................................................................................... 84
20 6.3.39.2.3When generated ............................................................................. 84
21
6.3.39.2.4Effect of receipt ............................................................................. 84
22
23 6.3.39.3 MLME-SA-QUERY.confirm ........................................................................ 85
24 6.3.39.3.4Effect of receipt ............................................................................. 85
25 6.3.39.4 MLME-SA-QUERY.indication ..................................................................... 85
26 6.3.39.4.1Function ......................................................................................... 85
27
6.3.39.5 MLME-SA-QUERY.response ....................................................................... 85
28
29 6.3.39.5.1Function ......................................................................................... 85
30 6.3.39.5.3When generated ............................................................................. 85
31 6.3.39.5.4Effect of receipt ............................................................................. 85
32 6.3.82 SCS request and response procedure ............................................................................. 85
33
6.3.82.3 MLME-SCS.confirm ..................................................................................... 85
34
35 6.3.82.3.2Semantics of the service primitive................................................. 85
36 6.3.82.5 MLME-SCS.response .................................................................................... 86
37 6.3.82.5.2Semantics of the service primitive................................................. 86
38 6.3.131EPCS priority access(#5284) ......................................................................................... 86
39
6.3.131.1 Introduction.................................................................................................... 86
40
41 6.3.131.2 MLME-EPCSPRIACCESSENABLE.request(#5587)(#5284)...................... 86
42 6.3.131.2.1Function ....................................................................................... 86
43 6.3.131.2.2Semantics of the service primitive............................................... 86
44 6.3.131.2.3When generated ........................................................................... 87
45
6.3.131.2.4Effect of receipt ........................................................................... 87
46
47 6.3.131.3 MLME-EPCSPRIACCESSENABLE.confirm(#5587)(#5284) .................... 87
48 6.3.131.3.1Function ....................................................................................... 87
49 6.3.131.3.2Semantics of the service primitive............................................... 87
50 6.3.131.3.3When generated ........................................................................... 88
51
6.3.131.3.4Effect of receipt ........................................................................... 88
52
53 6.3.131.4 MLME-EPCSPRIACCESSENABLE.indication(#5284)(#5587) ................. 88
54 6.3.131.4.1Function ....................................................................................... 88
55 6.3.131.4.2Semantics of the service primitive............................................... 88
56 6.3.131.4.3When generated ........................................................................... 88
57
6.3.131.4.4Effect of receipt ........................................................................... 88
58
59 6.3.131.5 MLME-EPCSPRIACCESSENABLE.response(#5284)(#5587) ................... 88
60 6.3.131.5.1Function ....................................................................................... 88
61 6.3.131.5.2Semantics of the service primitive............................................... 89
62 6.3.131.5.3When generated ........................................................................... 89
63
6.3.131.5.4Effect of receipt ........................................................................... 89
64
65 6.3.131.6 MLME-EPCSPRIACCESSTEARDOWN.request(#5284)(#5587) .............. 89

Copyright © 2022 IEEE. All rights reserved. 9

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 6.3.131.6.1Function ....................................................................................... 89
2 6.3.131.6.2Semantics of the service primitive............................................... 89
3
6.3.131.6.3When generated ........................................................................... 89
4
5 6.3.131.6.4Effect of receipt ........................................................................... 90
6 6.3.131.7 MLME-EPCSPRIACCESSTEARDOWN.indication(#5284)(#5587) .......... 90
7 6.3.131.7.1Function ....................................................................................... 90
8 6.3.131.7.2Semantics of the service primitive............................................... 90
9
6.3.131.7.3When generated ........................................................................... 90
10
11 6.3.131.7.4Effect of receipt ........................................................................... 90
12 6.3.132TID-to-link mapping(#4133) ......................................................................................... 90
13 6.3.132.1 Introduction.................................................................................................... 90
14 6.3.132.2 MLME-TIDTOLINKMAPPING.request ...................................................... 90
15
6.3.132.2.1Function ....................................................................................... 90
16
17 6.3.132.2.2Semantics of the service primitive............................................... 90
18 6.3.132.2.3When generated ........................................................................... 91
19 6.3.132.2.4Effect of receipt ........................................................................... 91
20 6.3.132.3 MLME-TIDTOLINKMAPPING.confirm ..................................................... 91
21
6.3.132.3.1Function ....................................................................................... 91
22
23 6.3.132.3.2Semantics of the service primitive............................................... 91
24 6.3.132.3.3When generated ........................................................................... 92
25 6.3.132.3.4Effect of receipt ........................................................................... 92
26 6.3.132.4 MLME-TIDTOLINKMAPPING.indication.................................................. 92
27
6.3.132.4.1Function ....................................................................................... 92
28
29 6.3.132.4.2Semantics of the service primitive............................................... 92
30 6.3.132.4.3When generated ........................................................................... 92
31 6.3.132.4.4Effect of receipt ........................................................................... 92
32 6.3.132.5 MLME-TIDTOLINKMAPPING.response.................................................... 92
33
6.3.132.5.1Function ....................................................................................... 92
34
35 6.3.132.5.2Semantics of the service primitive............................................... 93
36 6.3.132.5.3When generated ........................................................................... 93
37 6.3.132.5.4Effect of receipt ........................................................................... 93
38 6.3.132.6 MLME-TIDTOLINKMAPPINGTEARDOWN.request ............................... 93
39
6.3.132.6.1Function ....................................................................................... 93
40
41 6.3.132.6.2Semantics of the service primitive............................................... 93
42 6.3.132.6.3When generated ........................................................................... 93
43 6.3.132.6.4Effect of receipt ........................................................................... 94
44 6.3.132.7 MLME-TIDTOLINKMAPPINGTEARDOWN.indication........................... 94
45
6.3.132.7.1Function ....................................................................................... 94
46
47 6.3.132.7.2Semantics of the service primitive............................................... 94
48 6.3.132.7.3When generated ........................................................................... 94
49 6.3.132.7.4Effect of receipt ........................................................................... 94
50 6.3.133EML operating mode notification(#4134) ..................................................................... 94
51
6.3.133.1 Introduction.................................................................................................... 94
52
53 6.3.133.2 MLME-EMLOPERATINGMODENOTIF.request ....................................... 94
54 6.3.133.2.1Function ....................................................................................... 94
55 6.3.133.2.2Semantics of the service primitive............................................... 94
56 6.3.133.2.3When generated ........................................................................... 95
57
6.3.133.2.4Effect of receipt ........................................................................... 95
58
59 6.3.133.3 MLME-EMLOPERATINGMODENOTIF.indication .................................. 95
60 6.3.133.3.1Function ....................................................................................... 95
61 6.3.133.3.2Semantics of the service primitive............................................... 95
62 6.3.133.3.3When generated ........................................................................... 95
63
6.3.133.3.4Effect of receipt ........................................................................... 95
64
65

10 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 7. DS SAP specification......................................................................................................................... 96
2
3
7.1 Introduction................................................................................................................................ 96
4
5
6 8. PHY service specification.................................................................................................................. 98
7
8 8.3 Detailed PHY service specifications.......................................................................................... 98
9
8.3.5 PHY SAP detailed service specification........................................................................ 98
10
11 8.3.5.12 PHY-CCA.indication ..................................................................................... 98
12 8.3.5.12.2Semantics of the service primitive................................................. 98
13 8.3.5.12.3When generated ............................................................................. 99
14
15
9. Frame formats .................................................................................................................................. 101
16
17
18 9.2 MAC frame formats................................................................................................................. 101
19 9.2.4 Frame fields ................................................................................................................. 101
20 9.2.4.1 Frame Control field...................................................................................... 101
21
9.2.4.1.3Type and Subtype fields ................................................................ 101
22
23 9.2.4.1.8More Data subfield ........................................................................ 101
24 9.2.4.5 QoS Control field......................................................................................... 102
25 9.2.4.5.4Ack Policy Indicator subfield ........................................................ 102
26 9.2.4.5.6Queue Size subfield ....................................................................... 103
27
9.2.4.6 HT Control field........................................................................................... 103
28
29 9.2.4.6.4HE variant ...................................................................................... 103
30 9.2.4.7 Control subfield variants of an A-Control subfield ..................................... 104
31 9.2.4.7.8EHT OM Control ........................................................................... 104
32 9.2.4.7.9SRS Control ................................................................................... 107
33
9.2.4.7.10AAR Control................................................................................ 107
34
35 9.2.4.8 Frame Body field ......................................................................................... 108
36 9.2.4.8.1General........................................................................................... 108
37 9.2.5 Duration/ID field (QoS STA) ...................................................................................... 113
38 9.2.5.2 Setting for single and multiple protection under enhanced distributed channel
39
access (EDCA) 113
40
41 9.3 Format of individual frame types............................................................................................. 113
42 9.3.1 Control frames ............................................................................................................. 113
43 9.3.1.2 RTS frame format ........................................................................................ 113
44 9.3.1.5 PS-Poll frame format ................................................................................... 114
45
9.3.1.5.1General........................................................................................... 114
46
47 9.3.1.6 CF-End frame format................................................................................... 114
48 9.3.1.7 BlockAckReq frame format......................................................................... 114
49 9.3.1.7.1Overview........................................................................................ 114
50 9.3.1.8 BlockAck frame format ............................................................................... 115
51
9.3.1.8.2Compressed BlockAck variant ...................................................... 115
52
53 9.3.1.8.7Multi-STA BlockAck variant ........................................................ 116
54 9.3.1.19 VHT/HE/Ranging/EHT NDP Announcement frame format....................... 117
55 9.3.1.22 Trigger frame format ................................................................................... 124
56 9.3.1.22.1General......................................................................................... 124
57
9.3.1.22.3BFRP Trigger frame format......................................................... 149
58
59 9.3.1.22.5MU-RTS Trigger frame format ................................................... 149
60 9.3.3 (PV0) Management frames .......................................................................................... 152
61 9.3.3.2 Beacon frame format ................................................................................... 152
62 9.3.3.5 Association Request frame format............................................................... 152
63
9.3.3.6 Association Response frame format ............................................................ 153
64
65 9.3.3.7 Reassociation Request frame format ........................................................... 153

Copyright © 2022 IEEE. All rights reserved. 11

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 9.3.3.8 Reassociation Response frame format ......................................................... 154

2 9.3.3.9 Probe Request frame format ........................................................................ 154
3
9.3.3.10 Probe Response frame format...................................................................... 155
4
5 9.3.3.11 Authentication frame format........................................................................ 155
6 9.4 Management and Extension frame body components ............................................................. 156
7 9.4.1 Fields that are not elements ......................................................................................... 156
8 9.4.1.4 Capability Information field ........................................................................ 156
9
9.4.1.5 Current AP Address field............................................................................. 156
10
11 9.4.1.6 Listen Interval field...................................................................................... 157
12 9.4.1.8 AID field ...................................................................................................... 157
13 9.4.1.9 Status Code field .......................................................................................... 158
14 9.4.1.11 Action field .................................................................................................. 158
15
9.4.1.53 Operating Mode field................................................................................... 159
16
17 9.4.1.70 EHT MIMO Control field............................................................................ 160
18 9.4.1.71 EHT Compressed Beamforming Report field ............................................. 162
19 9.4.1.72 EHT MU Exclusive Beamforming Report field .......................................... 166
20 9.4.1.73 EHT CQI Report field.................................................................................. 166
21
9.4.1.74 EML Control field ....................................................................................... 167
22
23 9.4.2 Elements....................................................................................................................... 170
24 9.4.2.1 General......................................................................................................... 170
25 9.4.2.5 TIM element ................................................................................................ 170
26 9.4.2.5.1General........................................................................................... 170
27
9.4.2.22 Quiet element ............................................................................................... 171
28
29 9.4.2.26 Extended Capabilities element..................................................................... 171
30 9.4.2.36 Neighbor Report element............................................................................. 172
31 9.4.2.45 Multiple BSSID element.............................................................................. 173
32 9.4.2.47 Fast BSS Transition element (FTE)............................................................. 173
33
9.4.2.61 Link Identifier element ................................................................................ 175
34
35 9.4.2.71 Nontransmitted BSSID Capability element ................................................. 176
36 9.4.2.78 BSS Max Idle Period element...................................................................... 176
37 9.4.2.121 SCS Descriptor element............................................................................... 177
38 9.4.2.139 ADDBA Extension element......................................................................... 178
39
9.4.2.157 VHT Capabilities element ........................................................................... 178
40
41 9.4.2.157.3Supported VHT-MCS and NSS Set field .................................. 178
42 9.4.2.163 AID element................................................................................................. 179
43 9.4.2.164 Quiet Channel element................................................................................. 179
44 9.4.2.170 Reduced Neighbor Report element.............................................................. 179
45
9.4.2.170.2Neighbor AP Information field.................................................. 179
46
47 9.4.2.177 FILS Request Parameters element ............................................................... 182
48 9.4.2.199 TWT element ............................................................................................... 182
49 9.4.2.240 Non-Inheritance element.............................................................................. 185
50 9.4.2.248 HE Capabilities element .............................................................................. 185
51
9.4.2.248.4Supported HE-MCS and NSS Set field ..................................... 185
52
53 9.4.2.311 EHT Operation element ............................................................................... 185
54 9.4.2.312 Multi-Link element ...................................................................................... 188
55 9.4.2.312.1General....................................................................................... 188
56 9.4.2.312.2Basic Multi-Link element(#6700) ............................................. 190
57
9.4.2.312.3Probe Request Multi-Link element(#6701) ............................... 199
58
59 9.4.2.312.4Reconfiguration Multi-Link element(#4659) ............................ 200
60 9.4.2.312.5TDLS Multi-Link element(#4031) ............................................ 202
61 9.4.2.312.6Priority Access Multi-Link element(#4176).............................. 203
62 9.4.2.313 EHT Capabilities element(#4819) ............................................................... 205
63
9.4.2.313.1General(#1126) .......................................................................... 205
64
65 9.4.2.313.2EHT MAC Capabilities Information field(#1126) .................... 205

12 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 9.4.2.313.3EHT PHY Capabilities Information field .................................. 207

2 9.4.2.313.4Supported EHT-MCS And NSS Set field(#1126) ..................... 216
3
9.4.2.313.5EHT PPE Thresholds field......................................................... 222
4
5 9.4.2.314 TID-To-Link Mapping element ................................................................... 224
6 9.4.2.315 Multi-Link Traffic Indication element(#4107)(#2341) ............................... 225
7 9.4.2.316 QoS Characteristics element(#4918) ........................................................... 226
8 9.6 Action frame format details ..................................................................................................... 230
9
9.6.7 Public Action details .................................................................................................... 230
10
11 9.6.7.16 TDLS Discovery Response frame format.................................................... 230
12 9.6.7.36 FILS Discovery frame format...................................................................... 230
13 9.6.8 FT Action frame details ............................................................................................... 231
14 9.6.8.1 General......................................................................................................... 231
15
9.6.8.2 FT Request frame......................................................................................... 231
16
17 9.6.8.3 FT Response frame ...................................................................................... 231
18 9.6.8.4 FT Confirm frame........................................................................................ 232
19 9.6.8.5 FT Ack frame............................................................................................... 232
20 9.6.12 TDLS Action field formats .......................................................................................... 233
21
9.6.12.2 TDLS Setup Request Action field format.................................................... 233
22
23 9.6.12.3 TDLS Setup Response Action field format ................................................. 233
24 9.6.12.4 TDLS Setup Confirm Action field format ................................................... 234
25 9.6.12.12 TDLS Discovery Request Action field format ............................................ 234
26 9.6.13 WNM Action details .................................................................................................... 234
27
9.6.13.8 BSS Transition Management Query frame format ...................................... 234
28
29 9.6.13.9 BSS Transition Management Request frame format ................................... 235
30 9.6.13.10 BSS Transition Management Response frame format................................. 236
31 9.6.13.20 WNM Sleep Mode Response frame format................................................. 237
32 9.6.18 Robust AV Streaming Action frame details ................................................................ 239
33
9.6.18.3 SCS Response frame format ........................................................................ 239
34
35 9.6.34 EHT Action frame details(#1119)(#1488)................................................................... 240
36 9.6.34.1 EHT Action field ......................................................................................... 240
37 9.6.34.2 EHT Compressed Beamforming/CQI frame format.................................... 240
38 9.6.34.3 EML Operating Mode Notification frame format ....................................... 241
39
9.6.35 Protected EHT Action frame details ............................................................................ 241
40
41 9.6.35.1 Protected EHT Action field ......................................................................... 241
42 9.6.35.2 TID-To-Link Mapping Request frame format............................................. 242
43 9.6.35.3 TID-To-Link Mapping Response frame format .......................................... 242
44 9.6.35.4 TID-To-Link Mapping Teardown frame format ......................................... 243
45
9.6.35.5 EPCS Priority Access Enable Request frame format(#5284)(#1119)(#1488) ..
46
47 243
48 9.6.35.6 EPCS Priority Access Enable Response frame format(#5284)(#1119)(#1488)
49 244
50 9.6.35.7 EPCS Priority Access Teardown frame details(#5284)(#1127) .................. 245
51
9.7 Aggregate MPDU (A-MPDU)................................................................................................. 245
52
53 9.7.1 A-MPDU format .......................................................................................................... 245
54 9.7.2 A-MPDU contents ....................................................................................................... 247
55 9.8 MAC frame format for PV1 frames......................................................................................... 250
56 9.8.2 General PV1 frame format........................................................................................... 250
57
9.8.3 PV1 frame fields .......................................................................................................... 251
58
59 9.8.3.1 Frame Control field...................................................................................... 251
60
61 10. MAC sublayer functional description.............................................................................................. 253
62
63
10.1 Introduction.............................................................................................................................. 253
64
65 10.2 MAC architecture .................................................................................................................... 253

Copyright © 2022 IEEE. All rights reserved. 13

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 10.2.1 General......................................................................................................................... 253

2 10.3 DCF.......................................................................................................................................... 254
3
10.3.2 Procedures common to the DCF and EDCAF ............................................................. 254
4
5 10.3.2.9 CTS and DMG CTS procedure.................................................................... 254
6 10.3.2.11 Acknowledgment procedure ........................................................................ 256
7 10.3.2.14 Duplicate detection and recovery ................................................................ 256
8 10.3.2.14.2Transmitter requirements ........................................................... 256
9
10.3.2.14.3Receiver requirements ............................................................... 257
10
11 10.6 Multirate support...................................................................................................................... 261
12 10.6.1 Overview...................................................................................................................... 261
13 10.6.6 Rate selection for Control frames ................................................................................ 261
14 10.6.6.1 General rules for rate selection for Control frames ..................................... 261
15
10.6.10Modulation classes....................................................................................................... 261
16
17 10.6.11Non-HT basic rate calculation ..................................................................................... 267
18 10.8 HT Control field operation ...................................................................................................... 268
19 10.11A-MSDU operation................................................................................................................. 268
20 10.12A-MPDU operation................................................................................................................. 268
21
10.12.2A-MPDU length limit rules ......................................................................................... 268
22
23 10.12.3Minimum MPDU start spacing rules ........................................................................... 269
24 10.12.4A-MPDU aggregation of group addressed Data frames .............................................. 270
25 10.12.6A-MPDU padding for VHT, HE, EHT or S1G PPDU ................................................ 271
26 10.12.7Setting the EOF/Tag field of the MPDU delimiter...................................................... 272
27
10.13PPDU duration constraint ....................................................................................................... 272
28
29 10.15Low-density parity check code (LDPC) operation ................................................................. 272
30 10.23HCF......................................................................................................................................... 272
31 10.23.2HCF contention based channel access (EDCA) .......................................................... 272
32 10.23.2.2 EDCA backoff procedure ............................................................................ 272
33
10.23.2.5 EDCA channel access in a VHT, HE, EHT or TVHT BSS(#1936) ............ 273
34
35 10.23.2.8 Multiple frame transmission in an EDCA TXOP ........................................ 273
36 10.23.2.9 TXOP limits ................................................................................................. 274
37 10.25Block acknowledgment (block ack) ....................................................................................... 275
38 10.25.2Setup and modification of the block ack parameters ................................................... 275
39
10.29Reverse direction protocol ...................................................................................................... 275
40
41 10.29.4Rules for RD responder ............................................................................................... 275
42
43 11. MLME ............................................................................................................................................. 277
44
45
11.1 Synchronization(#1096)........................................................................................................... 277
46
47 11.1.4 Acquiring synchronization, scanning .......................................................................... 277
48 11.1.4.3 Active scanning and probing procedures..................................................... 277
49 11.1.4.3.4Criteria for sending a response .................................................... 277
50 11.2 Power management.................................................................................................................. 277
51
11.2.3 Power management in a non-DMG infrastructure network......................................... 277
52
53 11.2.3.1 General......................................................................................................... 277
54 11.2.3.5 Power management with APSD .................................................................. 277
55 11.2.3.5.1Power management with APSD procedures ................................ 277
56 11.2.3.6 AP operation ................................................................................................ 277
57
11.2.3.7 Receive operation for STAs in PS mode ..................................................... 278
58
59 11.2.3.9 STAs operating in active mode.................................................................... 278
60 11.2.3.10 AP and AP MLD aging function ................................................................. 278
61 11.2.3.15 TIM Broadcast ............................................................................................. 279
62 11.2.3.16 WNM sleep mode ........................................................................................ 279
63
11.2.3.16.1WNM sleep mode capability ..................................................... 279
64
65 11.2.3.16.2WNM sleep mode non-AP STA operation ................................ 279

14 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 11.2.3.16.3WNM sleep mode AP operation ................................................ 280

2 11.3 STA authenticationAuthentication and association(#2277) .................................................... 280
3
11.3.1 General(#2278) ............................................................................................................ 280
4
5 11.3.2 State variables .............................................................................................................. 281
6 11.3.3 State transition diagram for nonmesh STAs or MLDs ................................................ 281
7 11.3.4 Frame filtering based on STA or MLD state ............................................................... 282
8 11.3.5 Authentication and deauthentication ........................................................................... 283
9
11.3.5.1 General......................................................................................................... 283
10
11 11.3.5.2 Authentication—originating STA or MLD ................................................. 284
12 11.3.5.3 Authentication—destination STA or MLD ................................................. 285
13 11.3.5.4 Deauthentication—originating STA or MLD.............................................. 286
14 11.3.5.5 Deauthentication—destination STA or MLD.............................................. 286
15
11.3.6 Association, reassociation, and disassociation ............................................................ 287
16
17 11.3.6.1 General......................................................................................................... 287
18 11.3.6.2 Non-AP STA, non-AP MLD, and non-PCP STA association initiation proce-
19 dures 288
20 11.3.6.3 AP, AP MLD, or PCP association receipt procedures................................. 289
21
11.3.6.4 Non-AP, non-AP MLD, and non-PCP STA reassociation initiation procedures
22
23 292
24 11.3.6.5 AP, AP MLD, or PCP reassociation receipt procedures.............................. 295
25 11.3.6.6 Non-AP, non-AP MLD, and non-PCP STA disassociation initiation proce-
26 dures 298
27
11.3.6.7 Non-AP, non-AP MLD, and non-PCP STA disassociation receipt procedure..
28
29 298
30 11.3.6.8 AP, AP MLD, or PCP disassociation initiation procedure .......................... 299
31 11.3.6.9 AP, AP MLD, or PCP disassociation receipt procedure.............................. 300
32 11.8 DFS procedures........................................................................................................................ 300
33
11.8.3 Quieting channels for testing ....................................................................................... 300
34
35 11.13SA Query procedures.............................................................................................................. 300
36 11.20Tunneled direct-link setup ...................................................................................................... 301
37 11.20.1General......................................................................................................................... 301
38 11.21Wireless network management procedures ............................................................................ 302
39
11.21.13BSS max idle period management............................................................................. 302
40
41 11.21.14Proxy ARP service..................................................................................................... 303
42 11.22WLAN interworking with external networks procedures....................................................... 304
43 11.22.3Interworking procedures: generic advertisement service (GAS)................................. 304
44 11.22.3.3 ANQP procedures ........................................................................................ 304
45
11.22.3.3.10TDLS Capability procedure..................................................... 304
46
47 11.24Quality-of-service Management frame (QMF)....................................................................... 304
48 11.24.1General......................................................................................................................... 304
49 11.24.1.2 Default QMF policy..................................................................................... 304
50 11.25Robust AV streaming.............................................................................................................. 304
51
11.25.2SCS procedures............................................................................................................ 304
52
53 11.49Reduced neighbor report......................................................................................................... 305
54
55 12. Security ............................................................................................................................................ 307
56
57
12.1 Conventions ............................................................................................................................. 307
58
59 12.2 Framework ............................................................................................................................... 307
60 12.2.4 RSNA establishment.................................................................................................... 307
61 12.3 Pre-RSNA security methods .................................................................................................... 307
62 12.3.3 Pre-RSNA authentication ............................................................................................ 307
63
12.3.3.1 Overview(#2086)(#2283) ............................................................................ 307
64
65 12.3.3.2 Open System authentication ........................................................................ 307

Copyright © 2022 IEEE. All rights reserved. 15

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 12.3.3.2.1General......................................................................................... 307
2 12.4 Authentication using a password ............................................................................................. 308
3
12.4.1 SAE overview .............................................................................................................. 308
4
5 12.4.3 Representation of a password ...................................................................................... 309
6 12.4.4 Finite cyclic groups...................................................................................................... 310
7 12.4.4.1 General......................................................................................................... 310
8 12.4.4.2 Elliptic curve cryptography (ECC) groups .................................................. 310
9
12.4.4.2.3Hash-to-element generation of the password element with ECC
10
11 groups 310
12 12.4.4.3 Finite field cryptography (FFC) groups....................................................... 310
13 12.4.4.3.3Direct Generation of the password element with FFC groups..... 310
14 12.4.5 SAE protocol................................................................................................................ 311
15
12.4.5.2 PWE and secret generation .......................................................................... 311
16
17 12.4.5.4 Processing of a peer’s SAE Commit message ............................................. 311
18 12.4.6 Anti-clogging tokens.................................................................................................... 312
19 12.4.8 SAE finite state machine.............................................................................................. 312
20 12.4.8.3 Events and output......................................................................................... 312
21
12.4.8.3.1Parent process events and output ................................................. 312
22
23 12.5 RSNA confidentiality and integrity protocols ......................................................................... 313
24 12.5.3 CTR with CBC-MAC protocol (CCMP) ..................................................................... 313
25 12.5.3.3 CCMP cryptographic encapsulation ............................................................ 313
26 12.5.3.3.1General......................................................................................... 313
27
12.5.3.3.2PN processing .............................................................................. 314
28
29 12.5.3.3.3Construct AAD ............................................................................ 314
30 12.5.3.3.4Construct CCM nonce ................................................................. 315
31 12.5.3.3.7CCM originator processing.......................................................... 315
32 12.5.3.4 CCMP decapsulation ................................................................................... 316
33
12.5.3.4.1General......................................................................................... 316
34
35 12.5.5 GCM protocol (GCMP) ............................................................................................... 316
36 12.5.5.1 GCMP overview .......................................................................................... 316
37 12.5.5.3 GCMP cryptographic encapsulation ............................................................ 317
38 12.5.5.3.1General......................................................................................... 317
39
12.5.5.3.4Construct GCM nonce ................................................................. 317
40
41 12.5.5.3.6GCM originator processing ......................................................... 318
42 12.5.5.4 GCMP decapsulation ................................................................................... 318
43 12.5.5.4.1General......................................................................................... 318
44 12.6 RSNA security association management ................................................................................. 318
45
12.6.1 Security associations.................................................................................................... 318
46
47 12.6.1.1 Security association definitions ................................................................... 318
48 12.6.1.1.2PMKSA........................................................................................ 318
49 12.6.1.1.6PTKSA......................................................................................... 319
50 12.6.2 RSNA selection............................................................................................................ 320
51
12.6.3 RSNA policy selection in an infrastructure BSS ......................................................... 320
52
53 12.6.3.1 General......................................................................................................... 320
54 12.6.3.2 RSNA policy selection for MLO(#1578)(#2482)........................................ 321
55 12.6.10RSNA authentication in an infrastructure BSS............................................................ 321
56 12.6.10.2 Preauthentication and RSNA key management........................................... 321
57
12.6.14RSNA key management in an infrastructure BSS ....................................................... 321
58
59 12.6.21RSNA rekeying............................................................................................................ 321
60 12.7 Keys and key distribution ........................................................................................................ 322
61 12.7.1 Key hierarchy............................................................................................................... 322
62 12.7.1.1 General......................................................................................................... 322
63
12.7.2 EAPOL-Key frames..................................................................................................... 322
64
65 12.7.4 EAPOL-Key frame notation ........................................................................................ 326

16 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 12.7.5 Nonce generation ......................................................................................................... 327

2 12.7.6 4-way handshake.......................................................................................................... 327
3
12.7.6.1 General......................................................................................................... 327
4
5 12.7.6.2 4-way handshake message 1 ........................................................................ 328
6 12.7.6.3 4-way handshake message 2 ........................................................................ 329
7 12.7.6.4 4-way handshake message 3 ........................................................................ 331
8 12.7.6.5 4-way handshake message 4 ........................................................................ 333
9
12.7.7 Group key handshake................................................................................................... 334
10
11 12.7.7.1 General......................................................................................................... 334
12 12.7.7.2 Group key handshake message 1 ................................................................. 335
13 12.7.8 TDLS PeerKey (TPK) security protocol ..................................................................... 336
14 12.7.8.2 TPK handshake ............................................................................................ 336
15
12.7.8.4 TPK Security Protocol handshake messages ............................................... 338
16
17 12.7.8.4.3TPK handshake message 2 .......................................................... 338
18 12.7.8.4.4TPK handshake message 3 .......................................................... 338
19
20 13. Fast BSS transition........................................................................................................................... 340
21
22
23 13.1 Overview.................................................................................................................................. 340
24 13.2 Key holders .............................................................................................................................. 340
25 13.2.1 Introduction.................................................................................................................. 340
26 13.2.2 Authenticator key holders ............................................................................................ 340
27
13.2.3 Supplicant key holders................................................................................................. 341
28
29 13.3 Capability and policy advertisement........................................................................................ 341
30 13.4 FT initial mobility domain association .................................................................................... 341
31 13.4.1 Overview...................................................................................................................... 341
32 13.4.2 FT initial mobility domain association in an RSN ...................................................... 342
33
13.4.3 FT initial mobility domain association in a non-RSN ................................................. 344
34
35 13.5 FT protocol .............................................................................................................................. 346
36 13.5.1 Overview...................................................................................................................... 346
37 13.5.2 Over-the-air FT protocol authentication in an RSN .................................................... 346
38 13.7 FT reassociation ....................................................................................................................... 348
39
13.7.1 FT reassociation in an RSN ......................................................................................... 348
40
41 13.8 FT authentication sequence ..................................................................................................... 351
42 13.8.1 Overview...................................................................................................................... 351
43 13.8.2 FT authentication sequence: contents of first message................................................ 352
44 13.8.3 FT authentication sequence: contents of second message ........................................... 353
45
13.8.4 FT authentication sequence: contents of third message............................................... 353
46
47 13.8.5 FT authentication sequence: contents of fourth message ............................................ 355
48 13.9 FT security architecture state machines................................................................................... 356
49 13.9.1 Introduction.................................................................................................................. 356
50 13.9.5 S1KH state machine..................................................................................................... 356
51
13.9.5.3 S1KH state machine variables ..................................................................... 356
52
53
54 17. Orthogonal frequency division multiplexing (OFDM) PHY specification ..................................... 358
55
56 17.2 OFDM PHY specific service parameter list ............................................................................ 358
57
17.2.2 TXVECTOR parameters.............................................................................................. 358
58
59 17.2.2.1 General......................................................................................................... 358
60 17.2.2.7 TXVECTOR CH_BANDWIDTH_IN_NON_HT....................................... 358
61 17.2.3 RXVECTOR parameters ............................................................................................. 359
62 17.2.3.1 General......................................................................................................... 359
63
17.3 OFDM PHY ............................................................................................................................. 359
64
65 17.3.5 DATA field .................................................................................................................. 359

Copyright © 2022 IEEE. All rights reserved. 17

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 17.3.5.2 SERVICE field ............................................................................................ 359

2 17.3.5.5 PHY DATA scrambler and descrambler ..................................................... 360
3
4
5 26. High efficiency (HE) MAC specification ........................................................................................ 363
6
7 26.2 HE channel access ................................................................................................................... 363
8 26.2.6 MU-RTS Trigger/CTS frame exchange procedure ..................................................... 363
9
26.2.6.3 CTS frame response to an MU-RTS Trigger frame .................................... 363
10
11 26.2.7 EDCA operation using MU EDCA parameters ........................................................... 363
12 26.5 MU operation ........................................................................................................................... 363
13 26.5.1 HE DL MU operation .................................................................................................. 363
14 26.5.1.1 General......................................................................................................... 363
15
26.5.1.1a Additional rules on an HE MU PPDU(#1087) ............................................ 364
16
17 26.5.1.3 RU allocation in an HE MU PPDU ............................................................. 364
18 26.5.1.3a Minimum RU allocation in an HE MU PPDU(#1087)................................ 365
19 26.5.2 UL MU operation......................................................................................................... 365
20 26.5.2.2 Rules for soliciting UL MU frames ............................................................. 365
21
26.5.2.2.1General......................................................................................... 365
22
23 26.5.2.2.1aAdditional rules for soliciting UL MU frames(#1088) .............. 366
24 26.10Spatial reuse operation............................................................................................................ 366
25 26.10.2OBSS PD-based spatial reuse operation ...................................................................... 366
26 26.10.2.2 General operation with non-SRG OBSS PD level....................................... 366
27
26.10.2.3 General operation with SRG OBSS PD level .............................................. 367
28
29
30 35. Extremely high throughput (EHT) MAC specification ................................................................... 369
31
32 35.1 Introduction.............................................................................................................................. 369
33
35.2 Channel access ......................................................................................................................... 369
34
35 35.2.1 TXOP ........................................................................................................................... 369
36 35.2.1.1 Bandwidth signaling .................................................................................... 369
37 35.2.1.2 Triggered TXOP sharing procedure ............................................................ 369
38 35.2.1.2.1General......................................................................................... 369
39
35.2.1.2.2AP behavior ................................................................................. 370
40
41 35.2.1.2.3Non-AP STA behavior................................................................. 372
42 35.2.2 MU-RTS trigger/CTS frame exchange procedure for EHT STAs .............................. 373
43 35.2.2.1 MU-RTS Trigger frame transmission.......................................................... 373
44 35.2.2.2 CTS frame response to an MU-RTS Trigger frame .................................... 373
45
35.2.3 Intra-BSS and inter-BSS PPDU classification for EHT STA(#4287) ......................... 374
46
47 35.3 Multi-link operation ................................................................................................................. 374
48 35.3.1 General......................................................................................................................... 374
49 35.3.2 Advertisement of multi-link information in Multi-Link element(#2294) ................... 374
50 35.3.2.1 General......................................................................................................... 374
51
35.3.2.2 Advertisement of complete or partial per-link information(#1859) ............ 376
52
53 35.3.2.3 Inheritance in a per-STA profile .................................................................. 378
54 35.3.2.3.1Inheritance in the per-STA profile of Basic Multi-Link ele-
55 ment(#6700)(#2416) 378
56 35.3.2.3.2Inheritance in the per-STA profile of Probe Request Multi-Link ele-
57
ment(#2416)(#6700) 380
58
59 35.3.3 Multi-link device addressing ....................................................................................... 381
60 35.3.4 Discovery of an AP MLD ............................................................................................ 382
61 35.3.4.1 AP behavior ................................................................................................. 382
62 35.3.4.2 Use of ML probe request and response(#2583)(#3360) .............................. 382
63
35.3.4.3 Non-AP MLD behavior(#6687)(#1010)(#1020) ......................................... 384
64
65 35.3.4.4 Multi-Link element usage rules in the context of discovery ....................... 385

18 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 35.3.4.5 Active scanning for a non-AP EHT STA .................................................... 385

2 35.3.5 Multi-link (re)setup...................................................................................................... 386
3
35.3.5.1 Multi-link (re)setup procedure..................................................................... 386
4
5 35.3.5.2 Multi-link security ....................................................................................... 388
6 35.3.5.3 Multi-link tear down procedure ................................................................... 388
7 35.3.5.4 Usage and rules of Basic Multi-Link element in the context of multi-link
8 (re)setup(#6700) 388
9
35.3.6 Multi-Link reconfiguration(#4659) ............................................................................. 390
10
11 35.3.6.1 General......................................................................................................... 390
12 35.3.6.2 Adding or removing affiliated APs.............................................................. 390
13 35.3.6.2.1Adding new affiliated APs........................................................... 390
14 35.3.6.2.2Removing affiliated APs.............................................................. 390
15
35.3.7 Link management ........................................................................................................ 391
16
17 35.3.7.1 TID-to-link mapping.................................................................................... 391
18 35.3.7.1.1General......................................................................................... 391
19 35.3.7.1.2Default mapping mode................................................................. 392
20 35.3.7.1.3Negotiation of TID-to-link mapping............................................ 392
21
35.3.7.1.4Power state after enablement ....................................................... 394
22
23 35.3.7.1.5Power state after disablement(#5778).......................................... 394
24 35.3.7.1.6Use of More Data subfield by an MLD ....................................... 394
25 35.3.7.2 Dynamic link transitions .............................................................................. 395
26 35.3.8 Block ack procedures in Multi-link operation(#4111) ................................................ 396
27
35.3.9 Fragmentation in multi-link operation ......................................................................... 397
28
29 35.3.10BSS parameter critical update procedure..................................................................... 397
30 35.3.11Multi-link procedures for channel switching, extended channel switching, and channel
31 quieting(#4112)(#2324)(#2600)399
32 35.3.12Multi-link power management..................................................................................... 403
33
35.3.12.1 General......................................................................................................... 403
34
35 35.3.12.2 Basic BSS operation .................................................................................... 404
36 35.3.12.3 MLD max idle period management ............................................................. 404
37 35.3.12.4 Traffic indication ......................................................................................... 405
38 35.3.12.5 WNM sleep mode in multi-link operation ................................................... 407
39
35.3.12.6 Operation for MLD listen interval ............................................................... 407
40
41 35.3.13Multi-link device individually addressed data delivery without block ack negotiation ....
42 410
43 35.3.14Multi-link device individually addressed Management frame delivery(#2496) ......... 410
44 35.3.15Multi-link group addressed frame delivery and reception........................................... 411
45
35.3.15.1 Group addressed frame delivery .................................................................. 411
46
47 35.3.15.2 Group addressed frame reception ................................................................ 412
48 35.3.16Multi-link channel access ............................................................................................ 412
49 35.3.16.1 General......................................................................................................... 412
50 35.3.16.2 Multi-link device capability signaling(#4752)(#4116)................................ 412
51
35.3.16.3 Simultaneous transmit and receive (STR) operation ................................... 414
52
53 35.3.16.4 Nonsimultaneous transmit and receive (NSTR) operation .......................... 414
54 35.3.16.5 PPDU end time alignment ........................................................................... 415
55 35.3.16.5.1General(#4229) .......................................................................... 415
56 35.3.16.5.2End time alignment of response PPDUs using SRC Control
57
field(#4229) 417
58
59 35.3.16.6 Start time sync PPDUs medium access ....................................................... 418
60 35.3.16.7 Error recovery on a NSTR link pair within PIFS(#8196)............................ 419
61 35.3.16.8 Medium access recovery procedure............................................................. 419
62 35.3.16.8.1General....................................................................................... 419
63
35.3.16.8.2MediumSyncDelay OFDM ED based recovery procedure(#6352).
64
65 420

Copyright © 2022 IEEE. All rights reserved. 19

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 35.3.16.8.3AP assisted medium synchronization recovery procedure ........ 421

2 35.3.16.9 Multi-link retransmit procedures(#1064)(#2714)(#2598)(#2761)(#3381) .. 422
3
35.3.17Enhanced multi-link single radio operation................................................................. 422
4
5 35.3.18Enhanced multi-link multi-radio operation.................................................................. 426
6 35.3.19NSTR mobile AP MLD operation(#5386) .................................................................. 428
7 35.3.19.1 General......................................................................................................... 428
8 35.3.19.2 Discovery of an NSTR mobile AP MLD(#4079) ........................................ 429
9
35.3.19.3 NSTR mobile AP MLD multi-link procedures for channel switching, extended
10
11 channel switching, and channel quieting(#4082)(#5699)(#6966)429
12 35.3.20Multi-link operation in a multiple BSSID set or co-hosted BSSID
13 set(#1095)(#2292)(#2540)429
14 35.3.20.1 General......................................................................................................... 429
15
35.3.20.2 Inheritance in the per-STA profile of Basic Multi-Link element for an AP in a
16
17 multiple BSSID set(#3021)(#3212)(#6700)430
18 35.3.21TDLS procedure in multi-link operation(#4032)......................................................... 431
19 35.3.21.1 General......................................................................................................... 431
20 35.3.21.2 TDLS direct link over a single link ............................................................. 431
21
35.3.22Multi-link SCS procedure(#1977) ............................................................................... 437
22
23 35.3.23Multi-link MSCS procedure(#4812)............................................................................ 439
24 35.3.24Proxy ARP service in AP MLDs(#6715) .................................................................... 440
25 35.3.25BSS transition management for MLDs(#5322) ........................................................... 441
26 35.4 EHT acknowledgment procedure(#4111)(#5167) ................................................................... 442
27
35.4.1 Overview...................................................................................................................... 442
28
29 35.4.2 Block ack bitmap lengths............................................................................................. 442
30 35.5 MU operation ........................................................................................................................... 443
31 35.5.1 EHT DL MU operation(#1087) ................................................................................... 443
32 35.5.1.1 General(#1087) ............................................................................................ 443
33
35.5.1.2 RU allocation in an EHT MU PPDU(#1306) .............................................. 443
34
35 35.5.2 EHT UL MU operation(#1088) ................................................................................... 444
36 35.5.2.1 General......................................................................................................... 444
37 35.5.2.2 Rules for soliciting UL MU frames ............................................................. 444
38 35.5.2.2.1General(#1088) ............................................................................ 444
39
35.5.2.2.2Requirements for allocating resources(#1088) ............................ 445
40
41 35.5.2.2.3Padding for a triggering frame(#1088) ........................................ 445
42 35.5.2.2.4Allowed settings of the Trigger frame fields and TRS Control sub-
43 field 446
44 35.5.2.2.5AP access procedures for UL MU operation(#1088) .................. 446
45
35.5.2.3 Non-AP STA behavior for UL MU operation ............................................. 446
46
47 35.5.2.3.1General(#1088) ............................................................................ 446
48 35.5.2.3.2TXVECTOR parameters for EHT TB PPDU response to Trigger
49 frame 447
50 35.5.2.3.3Conditions for not responding with a TB PPDU(#4839) ............ 448
51
35.5.2.4 UL MU CS mechanism for EHT STAs ....................................................... 448
52
53 35.6 A-MPDU operation in an EHT PPDU(#4295) ........................................................................ 448
54 35.6.1 General......................................................................................................................... 448
55 35.7 EHT sounding operation(#5853)(#8363)................................................................................. 449
56 35.7.1 General......................................................................................................................... 449
57
35.7.2 EHT sounding protocol................................................................................................ 450
58
59 35.7.3 Rules for EHT sounding protocol sequences............................................................... 462
60 35.7.4 Rules for generating segmented feedback ................................................................... 466
61 35.7.5 EHT sounding NDP transmission................................................................................ 466
62 35.8 TWT operation......................................................................................................................... 467
63
35.8.1 General(#4767)(#6410) ............................................................................................... 467
64
65 35.8.2 Individual TWT agreements ........................................................................................ 467

20 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 35.9 Restricted TWT (r-TWT)......................................................................................................... 468

2 35.9.1 General......................................................................................................................... 468
3
35.9.2 r-TWT agreement setup ............................................................................................... 469
4
5 35.9.2.1 Latency sensitive traffic differentiation ....................................................... 469
6 35.9.2.2 The setup procedure(#2920) ........................................................................ 469
7 35.9.3 r-TWT service periods announcement......................................................................... 470
8 35.9.4 Channel access rules for r-TWT service periods ......................................................... 470
9
35.9.4.1 TXOP rules for r-TWT SPs(#6950)(#2215) ................................................ 470
10
11 35.9.4.2 Quieting STAs during r-TWT service periods(#2215)................................ 470
12 35.9.5 Traffic delivery(#4775)................................................................................................ 470
13 35.10Operating mode indication...................................................................................................... 471
14 35.11EHT Spatial reuse operation(#5444) ...................................................................................... 472
15
35.11.1General......................................................................................................................... 472
16
17 35.11.2OBSS PD-based spatial reuse operation(#5776) ......................................................... 472
18 35.11.3EHT PSR-based spatial reuse operation(#5444) ......................................................... 473
19 35.11.3.1 EHT PSR-based spatial reuse initiation(#5444) .......................................... 473
20 35.12Rules related to the PHY interface of an EHT STA(#4627)(#4633)...................................... 473
21
35.12.1Setting TXVECTOR parameters for an EHT PPDU................................................... 473
22
23 35.12.1.1 STA_ID........................................................................................................ 473
24 35.12.1.2 POWER_BOOST_FACTOR(#4630) .......................................................... 473
25 35.12.2SPATIAL_REUSE(#6799).......................................................................................... 474
26 35.12.3Contents of the EHT PHY Capabilities Information field and Supported EHT-MCS And
27
NSS Set field(#4627)475
28
29 35.12.4CENTER_FREQUENCY_SEGMENT(#4633) .......................................................... 477
30 35.12.5INACTIVE_SUBCHANNELS(#6686)....................................................................... 478
31 35.13Intra-PPDU power save for non-AP EHT STAs(#5034)........................................................ 478
32 35.14Nominal packet padding values selection rules ...................................................................... 478
33
35.14.1General(#7735) ............................................................................................................ 478
34
35 35.14.2PPET not present in both HE and EHT(#7735)........................................................... 478
36 35.14.3PPET not present in EHT but present in HE(#7735)................................................... 479
37 35.14.4PPE threshold present in EHT(#7735)......................................................................... 481
38 35.14.5STA behavior related to nominal packet padding(#7735)........................................... 482
39
35.15PPDU format, BW, MCS, NSS, and DCM selection rules(#1752)........................................ 483
40
41 35.15.1General......................................................................................................................... 483
42 35.15.2PPDU format selection ................................................................................................ 483
43 35.16EHT BSS operation ................................................................................................................ 483
44 35.16.1Basic EHT BSS operation(#7913) ............................................................................... 483
45
35.16.2Preamble puncturing operation(#1086)(#1667)(#2148)(#2147) ................................. 485
46
47 35.17EPCS priority access(#5284) .................................................................................................. 486
48 35.17.1General......................................................................................................................... 486
49 35.17.2EPCS priority access operation(#5284) ....................................................................... 487
50 35.17.2.1 General(#4173) ............................................................................................ 487
51
35.17.2.2 Setup procedures for EPCS priority access(#5284)..................................... 487
52
53 35.17.2.2.1General....................................................................................... 487
54 35.17.2.2.2Procedures at the originating non-AP MLD(#4173) ................. 488
55 35.17.2.2.3Procedures at the originating AP MLD(#4173)(#1706) ............ 489
56 35.17.2.2.4Procedure at the receiving AP MLD(#4173) ............................. 490
57
35.17.2.2.5Procedures at the receiving non-AP MLD(#4173)(#1707) ....... 491
58
59 35.17.3EPCS priority access procedure(#5284) ...................................................................... 492
60 35.17.3.1 General(#1709) ............................................................................................ 492
61 35.17.3.2 EDCA operation using EPCS EDCA parameters(#5284)(#1709)(#2171).. 492
62
63
36. Extremely high throughput (EHT) PHY specification .................................................................... 495
64
65

Copyright © 2022 IEEE. All rights reserved. 21

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 36.1 Introduction.............................................................................................................................. 495

2 36.1.1 Introduction to the EHT PHY ...................................................................................... 495
3
36.1.2 Scope............................................................................................................................ 500
4
5 36.1.3 EHT PHY functions..................................................................................................... 500
6 36.1.3.1 General......................................................................................................... 500
7 36.1.3.2 PHY management entity (PLME)................................................................ 500
8 36.1.3.3 Service specification method ....................................................................... 501
9
36.1.4 PPDU formats .............................................................................................................. 501
10
11 36.2 EHT PHY service interface ..................................................................................................... 501
12 36.2.1 Introduction.................................................................................................................. 501
13 36.2.2 TXVECTOR and RXVECTOR parameters ................................................................ 502
14 36.2.3 TRIGVECTOR parameters.......................................................................................... 514
15
36.2.4 PHY CONFIG_VECTOR............................................................................................ 516
16
17 36.2.5 Effect of CH_BANDWIDTH parameter on PPDU format ......................................... 517
18 36.2.6 Support for non-HT, HT, VHT, and HE formats......................................................... 518
19 36.2.6.1 General......................................................................................................... 518
20 36.2.6.2 Support for non-HT format.......................................................................... 520
21
36.2.6.3 Support for HT format ................................................................................. 522
22
23 36.2.6.4 Support for VHT format .............................................................................. 522
24 36.2.6.5 Support for HE format ................................................................................. 523
25 36.3 EHT PHY................................................................................................................................. 523
26 36.3.1 Introduction.................................................................................................................. 523
27
36.3.2 Subcarrier and resource allocation............................................................................... 524
28
29 36.3.2.1 Subcarriers and resource allocation in EHT PPDUs(#4636)....................... 524
30 36.3.2.2 Subcarriers and resource allocation for multiple RUs ................................. 531
31 36.3.2.2.1General......................................................................................... 531
32 36.3.2.2.2Small size MRUs(#2024)............................................................. 531
33
36.3.2.2.3Large size MRUs(#2025)............................................................. 541
34
35 36.3.2.3 Null subcarriers(#1606) ............................................................................... 552
36 36.3.2.4 Pilot subcarriers ........................................................................................... 553
37 36.3.2.5 20 MHz operating non-AP EHT STAs(#1244)(#1254) .............................. 553
38 36.3.2.6 RU and MRU restrictions for 20 MHz operation(#3276)............................ 554
39
36.3.2.7 80 MHz operating non-AP EHT STAs(#1244)(#1254) .............................. 556
40
41 36.3.2.8 160 MHz operating non-AP EHT STAs(#1244)(#1254) ............................ 556
42 36.3.3 MU-MIMO .................................................................................................................. 557
43 36.3.3.1 DL MU-MIMO ............................................................................................ 557
44 36.3.3.1.1Supported RU/MRU sizes in DL MU-MIMO(#2699) ................ 557
45
36.3.3.1.2Maximum number of spatial streams in an EHT MU PPDU ...... 557
46
47 36.3.3.2 UL MU-MIMO ............................................................................................ 558
48 36.3.3.2.1Introduction.................................................................................. 558
49 36.3.3.2.2Supported RU/MRU sizes in UL MU-MIMO(#4591) ................ 558
50 36.3.3.2.3UL MU-MIMO EHT-LTF mode ................................................. 559
51
36.3.3.2.4Maximum number of spatial streams in UL MU-MIMO ............ 559
52
53 36.3.3.3 Maximum number of users in MU-MIMO.................................................. 560
54 36.3.4 EHT PPDU formats ..................................................................................................... 560
55 36.3.5 EHT DUP transmission(#7637)................................................................................... 561
56 36.3.6 Transmitter block diagram........................................................................................... 562
57
36.3.7 Overview of the PPDU encoding process.................................................................... 570
58
59 36.3.7.1 General......................................................................................................... 570
60 36.3.7.2 Construction of L-STF................................................................................. 570
61 36.3.7.3 Construction of L-LTF................................................................................. 571
62 36.3.7.4 Construction of L-SIG ................................................................................. 571
63
36.3.7.5 Construction of RL-SIG............................................................................... 571
64
65 36.3.7.6 Construction of U-SIG................................................................................. 572

22 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 36.3.7.7 Construction of EHT-SIG ............................................................................ 573

2 36.3.7.8 Construction of EHT-STF ........................................................................... 573
3
36.3.7.9 Construction of EHT-LTF ........................................................................... 574
4
5 36.3.7.10 Construction of Data field in an EHT PPDU............................................... 574
6 36.3.8 EHT modulation and coding schemes (EHT-MCSs) .................................................. 575
7 36.3.9 EHT-SIG modulation and coding schemes (EHT-SIG-MCSs) ................................... 575
8 36.3.10Timing-related parameters ........................................................................................... 576
9
36.3.11Mathematical description of signals ............................................................................ 582
10
11 36.3.11.1 Notation ....................................................................................................... 582
12 36.3.11.2 Subcarrier indices in use .............................................................................. 582
13 36.3.11.3 Channel frequencies..................................................................................... 583
14 36.3.11.4 Transmitted signal........................................................................................ 584
15
36.3.12EHT preamble.............................................................................................................. 592
16
17 36.3.12.1 Introduction.................................................................................................. 592
18 36.3.12.2 Cyclic shift ................................................................................................... 592
19 36.3.12.2.1Cyclic shift for pre-EHT modulated fields ................................ 592
20 36.3.12.2.2Cyclic shift for EHT modulated fields....................................... 592
21
36.3.12.3 L-STF........................................................................................................... 593
22
23 36.3.12.4 L-LTF........................................................................................................... 593
24 36.3.12.5 L-SIG ........................................................................................................... 594
25 36.3.12.6 RL-SIG......................................................................................................... 596
26 36.3.12.7 U-SIG........................................................................................................... 596
27
36.3.12.7.1General....................................................................................... 596
28
29 36.3.12.7.2Content....................................................................................... 596
30 36.3.12.7.3Encoding and modulation .......................................................... 611
31 36.3.12.8 EHT-SIG ...................................................................................................... 614
32 36.3.12.8.1General....................................................................................... 614
33
36.3.12.8.2EHT-SIG content channels ........................................................ 614
34
35 36.3.12.8.3Common field for OFDMA transmission .................................. 617
36 36.3.12.8.4Common field for non-OFDMA transmission........................... 630
37 36.3.12.8.5User Specific field ..................................................................... 633
38 36.3.12.8.6Encoding and modulation .......................................................... 641
39
36.3.12.9 EHT-STF ..................................................................................................... 649
40
41 36.3.12.10EHT-LTF .................................................................................................... 653
42 36.3.12.11EHT preamble of preamble punctured EHT MU PPDU(#1952) ............... 660
43 36.3.12.11.1General..................................................................................... 660
44 36.3.12.11.2Preamble puncturing for EHT MU PPDUs in an OFDMA trans-
45
mission(#7236) 661
46
47 36.3.12.11.3Preamble puncturing for EHT MU PPDUs in a non-OFDMA
48 transmission(#7236) 661
49 36.3.12.11.4Preamble puncturing for EHT TB PPDUs(#7236) .................. 661
50 36.3.13Data field...................................................................................................................... 662
51
36.3.13.1 SERVICE field ............................................................................................ 662
52
53 36.3.13.2 EHT PHY DATA scrambler and descrambler ............................................ 662
54 36.3.13.3 Coding.......................................................................................................... 663
55 36.3.13.3.1General....................................................................................... 663
56 36.3.13.3.2BCC coding................................................................................ 663
57
36.3.13.3.3LDPC coding ............................................................................. 664
58
59 36.3.13.3.4EHT PPDU padding process...................................................... 664
60 36.3.13.3.5Encoding process for an EHT MU PPDU ................................. 664
61 36.3.13.3.6Encoding process for an EHT TB PPDU................................... 669
62 36.3.13.4 Stream parser ............................................................................................... 670
63
36.3.13.5 Segment parser............................................................................................. 670
64
65 36.3.13.6 BCC interleavers.......................................................................................... 675

Copyright © 2022 IEEE. All rights reserved. 23

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 36.3.13.7 Constellation mapping(#3115) .................................................................... 676

2 36.3.13.8 LDPC tone mapper(#3115).......................................................................... 679
3
36.3.13.9 Segment deparser(#2993) ............................................................................ 681
4
5 36.3.13.10Frequency domain duplication.................................................................... 681
6 36.3.13.11Pilot subcarriers .......................................................................................... 682
7 36.3.13.12OFDM modulation...................................................................................... 688
8 36.3.13.13Dual carrier modulation(#2993) ................................................................. 689
9
36.3.14Packet extension .......................................................................................................... 689
10
11 36.3.15Non-HT duplicate transmission ................................................................................... 693
12 36.3.16Transmit requirements for PPDUs sent in response to a triggering frame .................. 695
13 36.3.16.1 Introduction.................................................................................................. 695
14 36.3.16.2 Power pre-correction.................................................................................... 695
15
36.3.16.3 Pre-correction accuracy requirements ......................................................... 696
16
17 36.3.17Beamforming ............................................................................................................... 697
18 36.3.17.1 General......................................................................................................... 697
19 36.3.17.2 EHT beamforming feedback matrix V ........................................................ 698
20 36.3.17.3 EHT CQI feedback ...................................................................................... 699
21
36.3.18EHT sounding NDP ..................................................................................................... 699
22
23 36.3.19Transmit specification.................................................................................................. 700
24 36.3.19.1 Transmit spectral mask ................................................................................ 700
25 36.3.19.1.1General....................................................................................... 700
26 36.3.19.1.2Additional restrictions for puncturing in EHT PPDU ............... 705
27
36.3.19.1.3Additional restrictions of preamble puncturing for non-HT dupli-
28
29 cate PPDU 711
30 36.3.19.2 Spectral flatness ........................................................................................... 713
31 36.3.19.3 Transmit center frequency and symbol clock frequency tolerance ............. 718
32 36.3.19.4 Modulation accuracy.................................................................................... 719
33
36.3.19.4.1Introduction to modulation accuracy tests ................................. 719
34
35 36.3.19.4.2Transmit center frequency leakage ............................................ 719
36 36.3.19.4.3Transmitter constellation error................................................... 719
37 36.3.19.4.4Transmitter modulation accuracy (EVM) test ........................... 720
38 36.3.20Receiver specification.................................................................................................. 727
39
36.3.20.1 General......................................................................................................... 727
40
41 36.3.20.2 Receiver minimum input sensitivity ............................................................ 727
42 36.3.20.3 Adjacent channel rejection........................................................................... 728
43 36.3.20.4 Nonadjacent channel rejection..................................................................... 729
44 36.3.20.5 Receiver maximum input level .................................................................... 729
45
36.3.20.6 CCA sensitivity............................................................................................ 729
46
47 36.3.20.6.1General....................................................................................... 729
48 36.3.20.6.2CCA sensitivity for operating classes requiring CCA-ED ........ 729
49 36.3.20.6.3CCA sensitivity for occupying the primary 20 MHz channel ... 730
50 36.3.20.6.4Per 20 MHz CCA sensitivity ..................................................... 731
51
36.3.21EHT transmit procedure............................................................................................... 731
52
53 36.3.22EHT receive procedure ................................................................................................ 735
54 36.3.23Channel numbering and channelization(#1577) .......................................................... 739
55 36.3.23.1 General......................................................................................................... 739
56 36.3.23.2 Channelization for 320 MHz channel(#1577) ............................................. 740
57
36.3.24Regulatory requirements.............................................................................................. 740
58
59 36.4 EHT PLME .............................................................................................................................. 740
60 36.4.1 PLME_SAP sublayer management primitives ............................................................ 740
61 36.4.2 PHY MIB ..................................................................................................................... 740
62 36.4.3 TXTIME and PSDU_LENGTH calculation................................................................ 742
63
36.4.4 EHT PHY..................................................................................................................... 745
64
65 36.5 Parameters for EHT-MCSs ...................................................................................................... 746

24 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 36.5.1 EHT-MCSs for 26-tone RU ......................................................................................... 747

2 36.5.2 EHT-MCSs for 52-tone RU ......................................................................................... 748
3
36.5.3 EHT-MCSs for 52+26-tone MRU ............................................................................... 749
4
5 36.5.4 EHT-MCSs for 106-tone RU ....................................................................................... 750
6 36.5.5 EHT-MCSs for 106+26-tone MRU ............................................................................. 751
7 36.5.6 EHT-MCSs for 242-tone RU ....................................................................................... 752
8 36.5.7 EHT-MCSs for 484-tone RU ....................................................................................... 753
9
36.5.8 EHT-MCSs for 484+242-tone MRU ........................................................................... 754
10
11 36.5.9 EHT-MCSs for 996-tone RU ....................................................................................... 755
12 36.5.10EHT-MCSs for 996+484-tone MRU ........................................................................... 756
13 36.5.11EHT-MCSs for 996+484+242-tone MRU................................................................... 757
14 36.5.12EHT-MCSs for 2×996-tone RU................................................................................... 758
15
36.5.13EHT-MCSs for 2×996+484-tone MRU....................................................................... 759
16
17 36.5.14EHT-MCSs for 3×996-tone MRU ............................................................................... 760
18 36.5.15EHT-MCSs for 3×996+484-tone MRU....................................................................... 761
19 36.5.16EHT-MCSs for 4×996-tone RU................................................................................... 762
20 36.5.17EHT-MCS 14 for EHT DUP mode.............................................................................. 762
21
36.6 Parameters for EHT-SIG MCSs(#8097).................................................................................. 763
22
23
24 Annex B ...................................................................................................................................................... 765
25
26 B.2 Abbreviations and special symbols.................................................................................. 765
27
B.2.2 General abbreviations for Item and Support columns........................................ 765
28
29 B.4 PICS proforma—IEEE Std 802.11-<year> ..................................................................... 765
30 B.4.3 IUT configuration............................................................................................... 765
31 B.4.4 MAC protocol .................................................................................................... 766
32 B.4.4.2 MAC frames........................................................................................ 766
33
B.4.40 Extremely High Throughput (EHT) features ..................................................... 767
34
35 B.4.40.1 EHT PHY features .............................................................................. 767
36 B.4.40.2 EHT MAC features(#6672)................................................................. 777
37
38 Annex C ...................................................................................................................................................... 781
39
40
41 C.3 MIB Detail ....................................................................................................................... 781
42
43 Annex E ...................................................................................................................................................... 809
44
45
E.1 Country information and operating classes ..................................................................... 809
46
47
48 Annex R ...................................................................................................................................................... 810
49
50 R.4 Interworking and SSPN interface support ....................................................................... 810
51
R.4.2 SSPN interface parameters................................................................................. 810
52
53 R.4.2.1 General ................................................................................................ 810
54 R.4.2.4 Non-AP STA Interworking Capability ............................................... 810
55 R.4.2.14 Authorized EPCS priority access type(#5284) ................................... 810
56
57
Annex Z ...................................................................................................................................................... 811
58
59
60 Z.1 General............................................................................................................................. 811
61 Z.2 HE-SIG-B example Example 1........................................................................................ 811
62 Z.3 HE-SIG-B example Example 2........................................................................................ 811
63
Z.4 HE-SIG-B example Example 3........................................................................................ 811
64
65 Z.5 HE-SIG-B example Example 4........................................................................................ 811

Copyright © 2022 IEEE. All rights reserved. 25

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Z.6 EHT-SIG example 1 ........................................................................................................ 812

2 Z.7 EHT-SIG example 2 ........................................................................................................ 813
3
Z.8 EHT-SIG example 3 ........................................................................................................ 815
4
5 Z.9 EHT-SIG example 4 ........................................................................................................ 818
6 Z.10 EHT-SIG example 5 ........................................................................................................ 821
7 Z.11 EHT-SIG example 6 ........................................................................................................ 823
8 Z.12 EHT-SIG example 7(#5496)............................................................................................ 824
9
Z.13 EHT-SIG example 8 ........................................................................................................ 826
10
11
12 Annex AA ................................................................................................................................................... 829
13
14 AA.1 Introduction...................................................................................................................... 829
15
AA.2 Examples illustrating the relationship between profile periodicity and DTIM interval .. 829
16
17 AA.3 Example illustrating the relationship between multi-link operation and multiple BSSID set
18 or co-hosted BSSID set(#1095)(#2292)(#2540)829
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

26 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Figures
2
3
4 Figure 4-30a—Reference model for an MLD for two links .......................................................................... 60
5 Figure 4-30b—Example MLD and the affiliated STA communication system ............................................ 61
6 Figure 5-2a—MAC data plane architecture (MLO) for unicast data frames(#2239).................................... 64
7 Figure 5-11—Role-specific behavior block for a non-AP MLD(#2239) ...................................................... 65
8
Figure 5-12—Role-specific behavior block for a AP MLD(#2239) ............................................................. 65
9
10 Figure 7-1—DS architecture(#2239)(#2720)(#3410)(#3417) ....................................................................... 96
11 Figure 9-33a—Control Information subfield format in an EHT OM Control subfield............................... 104
12 Figure 9-33b—Control Information subfield format in an SRS Control subfield....................................... 107
13 Figure 9-33c—Control Information subfield format in an AAR Control subfield(#4805)(#4141) ............ 108
14
Figure 9-54—BA Information field format (Compressed BlockAck) ........................................................ 115
15
16 Figure 9-61—Per AID TID Info subfield format if the AID11 subfield is not 2045 .................................. 116
17 Figure 9-77—Sounding Dialog Token field format(#5787)........................................................................ 118
18 Figure 9-80a—STA Info field format in an EHT NDP Announcement frame ........................................... 119
19 Figure 9-80b—Partial BW Info subfield format.......................................................................................... 120
20
Figure 9-88—HE variant Common Info field format(#4104) ..................................................................... 125
21
22 Figure 9-88a—EHT variant Common Info field format(#4104)................................................................. 126
23 Figure 9-88b—UL Spatial Reuse subfield format ....................................................................................... 131
24 Figure 9-90—HE variant User Info field format ......................................................................................... 133
25 Figure 9-91—SS Allocation subfield format of an HE variant User Info field........................................... 136
26
Figure 9-92—RA-RU Information subfield format..................................................................................... 137
27
28 Figure 9-92a—EHT variant User Info field format..................................................................................... 138
29 Figure 9-92b—SS Allocation subfield format of an EHT variant User Info field ...................................... 146
30 Figure 9-92c—Special User Info field format ............................................................................................. 147
31 Figure 9-92d—U-SIG Disregard and Validate subfield format(#4607)...................................................... 148
32
Figure 9-96—UL BW subfield and B7–B1 of RU Allocation subfield in MU-RTS Trigger frame for various
33
34 bandwidths ................................................................................................................................................... 151
35 Figure 9-132—Capability Information field format (non-DMG STA)(#4064)(#5258).............................. 156
36 Figure 9-144h—EHT MIMO Control field format ..................................................................................... 160
37 Figure 9-144i—EML Control field format(#4425)(#4759)(#5766)(#6342) ............................................... 167
38
Figure 9-144j—EMLMR Supported MCS And NSS Set subfield format(#4425) ..................................... 169
39
40 Figure 9-398—BSSID Information field format(#1010)(#1128) ................................................................ 172
41 Figure 9-425a—MLO GTK subelement format .......................................................................................... 174
42 Figure 9-425b—Link Info field format of the MLO GTK subelement ....................................................... 175
43 Figure 9-425c—MLO IGTK subelement format......................................................................................... 175
44
Figure 9-425d—MLO BIGTK subelement format...................................................................................... 175
45
46 Figure 9-522—BSS Max Idle Period element format ................................................................................. 176
47 Figure 9-523—Idle Options field format..................................................................................................... 177
48 Figure 9-603—SCS Descriptor element format(#4918)(#1977) ................................................................. 177
49 Figure 9-646—ADDBA Extension element format .................................................................................... 178
50
Figure 9-647—ADDBA Additional Parameter Set Capabilities field format ............................................. 178
51
52 Figure 9-709—TBTT Information field for-
53 mat(#1901)(#1902)(#2566)(#2969)(#1016)(#1017)(#1205)(#1125) .......................................................... 180
54 Figure 9-709b—TBTT Information field format when the TBTT Information Field type is equal to 1 and the
55 TBTT information length is equal to 3(#4079) ........................................................................................... 180
56
Figure 9-709c—MLD Parameters subfield for-
57
58 mat(#1068)((#1901)(#1902)(#1016)(#1017)(#1903)(#4064)(#5258)......................................................... 181
59 Figure 9-764—Control field format ............................................................................................................ 182
60 Figure 9-765—Individual TWT Parameter Set field format ....................................................................... 182
61 Figure 9-766—Broadcast TWT Parameter Set field format(#2920) ........................................................... 182
62
Figure 9-770—Broadcast TWT Info subfield format(#6414)(#2920)......................................................... 183
63
64 Figure 9-770a—Restricted TWT Traffic Info field format(#2920)............................................................. 184
65 Figure 9-770b—Traffic Info Control field format(#2920) .......................................................................... 184

Copyright © 2022 IEEE. All rights reserved. 27

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Figure 9-1002a—EHT Operation element format(#4261)(#6603)(#1086)(#1667)(#2148)(#2147)........... 186

2 Figure 9-1002b—EHT Operation Parameters field format(#6603)............................................................. 186
3
Figure 9-1002c—EHT Operation Information field format(#6603) ........................................................... 186
4
5 Figure 9-1002d—Control subfield format(#6603) ...................................................................................... 187
6 Figure 9-1002e—Multi-Link element format.............................................................................................. 188
7 Figure 9-1002f—Multi-Link Control field(#1068) ..................................................................................... 188
8 Figure 9-1002g—Presence Bitmap subfield of the Basic Multi-Link element for-
9
mat(#6700)(#3247)(#1773)(#2603)(#1078)(#1475)(#2981)(#3017) .......................................................... 190
10
11 Figure 9-1002h—Common Info field of the Basic Multi-Link element for-
12 mat(#5052)(#6700)(#5043)(#1068)(#2139)(#2159)(#2161)(#3018)(#1773)(#2603)(#3017) .................... 191
13 Figure 9-1002i—Link ID Info subfield format(#6868) ............................................................................... 191
14 Figure 9-1002j—Medium Synchronization Delay Information subfield format......................................... 192
15
Figure 9-1002k—EML Capabilities subfield format(#4425)(#1773)(#2603)(#6346) ................................ 193
16
17 Figure 9-1002l—MLD Capabilities subfield format(#4079)(#6605)(#7041)(#1078)(#1475)(#2981) ....... 195
18 Figure 9-1002m—Per-STA Profile subelement format............................................................................... 197
19 Figure 9-1002n—STA Control field format(#5784)(#1906)(#1907)(#1078)(#1475)(#2981)(#4453)(#4457).
20 197
21
Figure 9-1002o—STA Info field format(#5044)(#6366)(#4453)(#4457)................................................... 198
22
23 Figure 9-1002p—DTIM Info subfield format ............................................................................................. 198
24 Figure 9-1002q—Presence Bitmap field of the Probe Request Multi-Link element for-
25 mat(#6262)(#6237)(#6238) ......................................................................................................................... 199
26 Figure 9-1002r—Common Info field of the Probe Request Multi-Link element for-
27
mat(#6262)(#6237)(#6238) ......................................................................................................................... 199
28
29 Figure 9-1002s—Per-STA Profile subelement of the Probe Request Multi-Link element for-
30 mat(#6701)(#6451)(#6865)(#3247)............................................................................................................. 200
31 Figure 9-1002t—STA Control field of the Probe Request Multi-Link element for-
32 mat(#6701)(#6451)(#6865)(#3247)............................................................................................................. 200
33
Figure 9-1002u—Presence Bitmap subfield of the Reconfiguration Multi-Link element format(#4659).. 201
34
35 Figure 9-1002v—Common Info field of the Reconfiguration Multi-Link element format(#4659)............ 201
36 Figure 9-1002w—Per-STA Profile subelement for the Reconfiguration Multi-Link element(#4659)....... 201
37 Figure 9-1002x—STA Control field format for the Reconfiguration Multi-Link element(#4659) ............ 202
38 Figure 9-1002y—Delete Timer subfield format(#4659) ............................................................................. 202
39
Figure 9-1002z—Format of the Common Info field of the TDLS Multi-Link element.............................. 203
40
41 Figure 9-1002aa—Presence Bitmap subfield of the Priority Access Multi-Link element format(#4176).. 203
42 Figure 9-1002ab—Common Info field of the Priority Access Multi-Link element format(#4176) ........... 203
43 Figure 9-1002ac—Per-STA Profile subelement format for the Priority Access Multi-Link element(#4176) ..
44 204
45
Figure 9-1002ad—STA Control field format for the Priority Access Multi-Link element(#4176) ............ 204
46
47 Figure 9-1002ae—EHT Capabilities element format .................................................................................. 205
48 Figure 9-1002af—EHT MAC Capabilities Information field format(#4295)(#4918)(#6630)(#2920)(#1977)
49 205
50 Figure 9-1002ag—EHT PHY Capabilities Information field format .......................................................... 208
51
Figure 9-1002ah—Supported EHT-MCS And NSS Set field format(#4970) ............................................. 216
52
53 Figure 9-1002ai—EHT-MCS Map (20 MHz-Only Non-AP STA) subfield and Basic EHT-MCS and NSS Set
54 field format(#5872)...................................................................................................................................... 220
55 Figure 9-1002aj—EHT-MCS Map (BW ≤ 80 MHz, Except 20 MHz-Only Non-AP STA), EHT-MCS Map
56 (BW = 160 MHz), and EHT-MCS Map (BW = 320 MHz) subfield format(#5872) .................................. 220
57
Figure 9-1002ak—EHT PPE Thresholds field format(#7736).................................................................... 222
58
59 Figure 9-1002al—PPE Thresholds Info field format(#7736)...................................................................... 222
60 Figure 9-1002am—TID-To-Link Mapping element format(#7707) ........................................................... 224
61 Figure 9-1002an—TID-To-Link Control field format(#7707).................................................................... 224
62 Figure 9-1002ao—Multi-Link Traffic Indication element format(#4107).................................................. 225
63
Figure 9-1002ap—Multi-Link Traffic Indication Control field format(#4107) .......................................... 225
64
65 Figure 9-1002aq—Per-Link Traffic Indication List field format(#6373).................................................... 225

28 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Figure 9-1002ar—Per-Link Traffic Indication Bitmap subfield format...................................................... 226

2 Figure 9-1002as—QoS Characteristics element format(#4918) ................................................................. 226
3
Figure 9-1002at—Control Info field format(#4918) ................................................................................... 227
4
5 Figure 9-1153—Request Mode field format(#4659)................................................................................... 235
6 Figure 9-1162a—WNM Sleep Mode MLO GTK subelement format ........................................................ 238
7 Figure 9-1162b—Link Info field format ..................................................................................................... 238
8 Figure 9-1162c—WNM Sleep Mode MLO IGTK subelement format ....................................................... 238
9
Figure 9-1162d—WNM Sleep Mode MLO BIGTK subelement format .................................................... 239
10
11 Figure 9-1176—SCS Response frame Action field format(#1977) ............................................................ 239
12 Figure 10-1—Non-DMG non-CMMG non-S1G STA MAC architecture(#1737) ..................................... 253
13 Figure 11-20—Relationship between state and services between a given pair of nonmesh STAs or nonmesh
14 MLDs ........................................................................................................................................................... 282
15
Figure 12-18—CCMP encapsulation block diagram................................................................................... 313
16
17 Figure 12-21—CCM nonce ......................................................................................................................... 315
18 Figure 12-23—CCMP decapsulation block diagram................................................................................... 316
19 Figure 12-27—GCMP encapsulation block diagram .................................................................................. 317
20 Figure 12-29—GCMP decapsulation block diagram .................................................................................. 318
21
Figure 12-36a—MLO GTK KDE format(#2290) ....................................................................................... 323
22
23 Figure 12-42a—MLO IGTK KDE format(#2290) ...................................................................................... 323
24 Figure 12-48a—MLO BIGTK KDE(#2290) ............................................................................................... 325
25 Figure 12-48b—MLO Link KDE(#2290) ................................................................................................... 325
26 Figure 12-48c—Link Information field(#2290)(#6594).............................................................................. 325
27
Figure 13-5—Over-the-air FT protocol in an RSN(#5070)(#6700) ............................................................ 346
28
29 Figure 17-6—SERVICE field bit assignment ............................................................................................. 360
30 Figure 35-1—Example of MU-RTS TXS Trigger frame with TXOP Sharing Mode subfield value equal to 1
31 soliciting UL PPDU(#5153)(#5518)............................................................................................................ 371
32 Figure 35-2—Example of MU-RTS TXS Trigger frame with TXOP Sharing Mode subfield value equal to
33
2(#5153)(#8324) .......................................................................................................................................... 371
34
35 Figure 35-3—Example of Basic Multi-Link element in an Association Request
36 frame(#4248)(#6700)(#1050)(#1778)(#2165)............................................................................................. 377
37 Figure 35-4—Example of inheritance in a complete per-STA profile(#6700)(#8331)(#5907)(#3021)...... 380
38 Figure 35-5—Example of inheritance in a Request element for ML probe request(#6701)(#2416) .......... 381
39
Figure 35-6—Example of multi-link setup(#2899) ..................................................................................... 387
40
41 Figure 35-7—Example of operation of a single radio non-AP MLD with default mapping (all TIDs mapped
42 to all setup links), where the non-AP MLD transitions from operating on link 1 with STA 1 to operating on
43 link 2 with STA 2......................................................................................................................................... 395
44 Figure 35-8—Example of an AP carrying a Quiet element to signal channel quieting on another link (#1073)
45
402
46
47 Figure 35-9—Example of an AP carrying a Channel Switch Announcement element to signal channel switch-
48 ing on another link (#1073) ......................................................................................................................... 403
49 Figure 35-10—Each STA affiliated with a non-AP MLD maintains its own power
50 state(#4386)(#4387)(#6134)(#2325) ........................................................................................................... 404
51
Figure 35-11—Example of Multi-Link Traffic Indication element construction(#8180)(#4107) .............. 406
52
53 Figure 35-12—Example of operation for MLD listen interval.................................................................... 408
54 Figure 35-13—Another example of operation for MLD listen interval ...................................................... 409
55 Figure 35-14—Channel access of two MLDs over an STR link pair(#6493)(#2553)(#1175).................... 414
56 Figure 35-15—PPDU end time alignment timing relationships.................................................................. 417
57
Figure 35-16—An example of a frame exchange sequence between an AP affiliated with an AP MLD and a
58
59 STA affiliated with a non-AP MLD that is in the EMLSR mode(#7063)(#7337) ...................................... 425
60 Figure 35-17—An example of a frame exchange sequence between an AP (AP 1) affiliated with an AP MLD
61 and n STAs affiliated with n different non-AP MLDs that are in the EMLSR mode(#7063)(#7337) ........ 425
62 Figure 35-18—An example of EHT non-TB sounding in the EMLSR operation....................................... 426
63
Figure 35-19—An example of EHT TB sounding in the EMLSR operation (beamformee 1 is in the EMLSR
64
65 mode, the other beamformees are not in the EMLSR mode) ...................................................................... 426

Copyright © 2022 IEEE. All rights reserved. 29

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Figure 35-20—An example of EHT TB sounding in the EMLSR operation (BSRP is used as the initial Con-
2 trol frame) .................................................................................................................................................... 426
3
Figure 35-21—Example of inheritance in a complete per-STA profile for a multiple BSSID scenario(#6700)
4
5 431
6 Figure 35-22—Example A of TDLS discovery initiated by a non-AP MLD(#4032)................................. 434
7 Figure 35-23—Example B of TDLS discovery initiated by a non-AP MLD(#4032) ................................. 434
8 Figure 35-24—Example of TDLS discovery initiated by a STA to a non-AP MLD(#4032) ..................... 435
9
Figure 35-25—Transmission of TDLS Setup Request frame between two STAs each affiliated with a differ-
10
11 ent non-AP MLD(#4032)............................................................................................................................. 436
12 Figure 35-26—Transmission of TDLS Setup Response frame between two STAs each affiliated with a dif-
13 ferent non-AP MLD(#4032) ........................................................................................................................ 436
14 Figure 35-27—TDLS direct link involving a STA affiliated with a non-AP MLD and a STA that is not affil-
15
iated with a non-AP MLD(#4032)............................................................................................................... 437
16
17 Figure 35-28—TDLS direct link involving STAs affiliated with different non-AP MLDs(#4032) ........... 437
18 Figure 35-29—Example of proxy ARP service by an AP MLD(#6715) .................................................... 440
19 Figure 35-30—An illustration of EHT non-TB sounding ........................................................................... 462
20 Figure 35-31—An illustration of EHT TB sounding(#7079) ...................................................................... 462
21
Figure 35-32—Example of TWT agreements negotiation across multiple links ........................................ 468
22
23 Figure 35-33—Enabling EPCS priority access(#5284)(#5856)(#4436)(#1127)(#7358) ............................ 487
24 Figure 36-1—PHY interaction on transmit for various PPDU formats(#7992) .......................................... 519
25 Figure 36-2—PHY interaction on receive for various PPDU formats(#7992)............................................ 519
26 Figure 36-3—PHY-CONFIG and CCA interaction with various PPDU formats(#7992) .......................... 519
27
Figure 36-4—RU locations in an 80 MHz EHT PPDU(#1984) .................................................................. 524
28
29 Figure 36-5—Allowed 52+26-tone MRUs in an OFDMA 20 MHz EHT PPDU(#8092)(#3270) .............. 532
30 Figure 36-6—Allowed 52+26-tone MRUs in an OFDMA 40 MHz EHT PPDU(#8092)(#3270) .............. 532
31 Figure 36-7—Allowed 52+26-tone MRUs in each 80 MHz frequency subblock of an OFDMA 80 MHz,
32 160 MHz, or 320 MHz EHT PPDU(#8092)(#1279)(#3270)....................................................................... 533
33
Figure 36-8—Allowed 106+26-tone MRUs in an OFDMA 20 MHz EHT PPDU(#8092)(#3270) ............ 533
34
35 Figure 36-9—Allowed 106+26-tone MRUs in an OFDMA 40 MHz EHT PPDU(#8092)(#3270) ............ 533
36 Figure 36-10—Allowed 106+26-tone MRUs in each 80 MHz frequency subblock of an OFDMA 80 MHz,
37 160 MHz, or 320 MHz EHT PPDU(#8092)(#1279)(#3270)....................................................................... 534
38 Figure 36-11—Allowed 484+242-tone MRUs in a non-OFDMA 80 MHz EHT PPDU(#4791)(#1296)... 541
39
Figure 36-12—Allowed 996+484-tone MRUs in a non-OFDMA 160 MHz EHT PPDU(#4792)(#1296). 542
40
41 Figure 36-13—Allowed 996+484+242-tone MRUs in a non-OFDMA 160 MHz EHT PPDU(#4793)(#1296)
42 543
43 Figure 36-14—Allowed 2×996+484-tone MRUs in a non-OFDMA 320 MHz EHT PPDU(#4794)(#1296) ..
44 544
45
Figure 36-15—Allowed 3×996-tone MRUs in a non-OFDMA 320 MHz EHT PPDU(#4795)(#1296)..... 544
46
47 Figure 36-16—Allowed 3×996+484-tone MRUs in a non-OFDMA 320 MHz EHT PPDU(#4796)(#1296) ..
48 545
49 Figure 36-17—EHT MU PPDU format(#1309)(#1963)(#3156)................................................................. 560
50 Figure 36-18—EHT TB PPDU format(#1309)(#1964)(#3156) .................................................................. 560
51
Figure 36-19—Transmitter block diagram for the L-SIG, RL-SIG, and U-SIG fields for an EHT MU PPDU
52
53 563
54 Figure 36-20—Transmitter block diagram for the L-SIG, RL-SIG, and U-SIG fields of an EHT TB PPDU..
55 564
56 Figure 36-21—Transmitter block diagram for the EHT-SIG field for an EHT MU PPDU(#4543) ........... 564
57
Figure 36-22—Transmitter block diagram for the UL transmission or DL non-MU-MIMO transmission of a
58
59 Data field with BCC encoding on an RU/MRU that is the same size as or smaller than a 242-tone
60 RU(#7750)(#1315)....................................................................................................................................... 565
61 Figure 36-23—Transmitter block diagram for the UL transmission or DL non-MU-MIMO transmission of a
62 Data field with LDPC encoding on an RU/MRU that is the same size or smaller than a 996-tone RU(#1315)
63
566
64
65 Figure 36-24—Transmitter block diagram for the DL MU-MIMO transmission of a Data field with BCC en-

30 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 coding on a 242-tone RU ............................................................................................................................. 567

2 Figure 36-25—Transmitter block diagram for the DL MU-MIMO transmission of a Data field with LDPC
3
encoding on a 242-, 484-, 484+242-, or 996-tone RU or MRU(#1946)...................................................... 568
4
5 Figure 36-26—Transmitter block diagram for the Data field of an EHT single user transmission in RU/MRU
6 size larger than 996 tones with LDPC encoding.......................................................................................... 569
7 Figure 36-27—Transmitter block diagram for the transmission of a Data field with EHT-MCS 14 in 80 MHz
8 or 160 MHz PPDU(#4906)(#1966) ............................................................................................................. 569
9
Figure 36-28—Transmitter block diagram for the transmission of a Data field with EHT-MCS 14 in 320 MHz
10
11 PPDU(#4907)(#1966) .................................................................................................................................. 570
12 Figure 36-29—Timing boundaries for EHT PPDU fields(#1968)(#6808) ................................................. 586
13 Figure 36-30—Data subcarrier constellation of U-SIG symbols(#8015)(#1372)(#1373) .......................... 613
14 Figure 36-31—EHT-SIG content channel format for OFDMA transmission if bandwidth is 20/40/
15
80 MHz(#5485)(#3295)(#1383)(#1384)(#1390) ......................................................................................... 615
16
17 Figure 36-32—EHT-SIG content channel format for OFDMA transmission if bandwidth is
18 160 MHz(#5485)(#3295)(#1383)(#1384)(#1390) ....................................................................................... 615
19 Figure 36-33—EHT-SIG content channel format for OFDMA transmission if bandwidth is
20 320 MHz(#5485)(#3295)(#1383)(#1384)(#1390) ....................................................................................... 615
21
Figure 36-34—EHT-SIG content channel format for non-OFDMA transmission to a single us-
22
23 er(#5485)(#1390)(#2174) ............................................................................................................................ 616
24 Figure 36-35—EHT-SIG content channel format for EHT sounding NDP(#5485)(#1390)(#2174) .......... 616
25 Figure 36-36—EHT-SIG content channel format for non-OFDMA transmission to multiple us-
26 ers(#5485)(#1390)(#1393)(#2174)(#3159) ................................................................................................. 617
27
Figure 36-37—EHT-SIG content channel for a 20 MHz PPDU for OFDMA transmission and non-OFDMA
28
29 transmission to multiple users...................................................................................................................... 643
30 Figure 36-38—EHT-SIG content channel for a 40 MHz PPDU for OFDMA transmission and non-OFDMA
31 transmission to multiple users...................................................................................................................... 644
32 Figure 36-39—EHT-SIG content channels and their duplication in an 80 MHz PPDU for OFDMA transmis-
33
sion and non-OFDMA transmission to multiple users ................................................................................ 644
34
35 Figure 36-40—EHT-SIG content channels and their duplication in a 160 MHz PPDU for OFDMA transmis-
36 sion and non-OFDMA transmission to multiple users ................................................................................ 645
37 Figure 36-41—EHT-SIG content channels and their duplication in a 320 MHz PPDU for OFDMA transmis-
38 sion and non-OFDMA transmission to multiple users ................................................................................ 646
39
Figure 36-42—EHT-SIG content channel for a 20 MHz PPDU for non-OFDMA transmission to a single user
40
41 or EHT sounding NDP(#1629) .................................................................................................................... 647
42 Figure 36-43—EHT-SIG content channel for a 40 MHz PPDU for non-OFDMA transmission to a single user
43 or EHT sounding NDP(#1629) .................................................................................................................... 647
44 Figure 36-44—EHT-SIG content channel for an 80 MHz PPDU for non-OFDMA transmission to a single
45
user or EHT sounding NDP(#1629) ............................................................................................................ 647
46
47 Figure 36-45—EHT-SIG content channel for a 160 MHz PPDU for non-OFDMA transmission to a single
48 user or EHT sounding NDP(#1629) ............................................................................................................ 648
49 Figure 36-46—EHT-SIG content channel for a 320 MHz PPDU for non-OFDMA transmission to a single
50 user or EHT sounding NDP(#1629) ............................................................................................................ 649
51
Figure 36-47—Generation of EHT-LTF symbols in an EHT MU PPDU and EHT TB PPDU.................. 658
52
53 Figure 36-48—Generation of 1× EHT-LTF symbols.................................................................................. 659
54 Figure 36-49—Generation of 2× EHT-LTF symbols.................................................................................. 659
55 Figure 36-50—Data scrambler(#3070)........................................................................................................ 662
56 Figure 36-51—EHT PPDU padding process in the last OFDM-symbol if a = 1 for the u-th user ............. 664
57
Figure 36-52—Illustration of the proportional round robin parser with leftover bits processing(#7303)... 674
58
59 Figure 36-53—Illustration of the segment parser for 996+484-tone RU(#7304) ....................................... 674
60 Figure 36-54—Illustration of the segment parser for 996+484+242-tone RU............................................ 675
61 Figure 36-55—PE field duration of an EHT MU PPDU if the maximum value of TXVECTOR parameters
62 NOMINAL_PACKET_PADDING[u] is 8 µs and TPE = TPE,nominal .................................................... 691
63
Figure 36-56—PE field duration of an EHT MU PPDU if the maximum value of TXVECTOR parameters
64
65 NOMINAL_PACKET_PADDING[u] is 16 µs and TPE = TPE,nominal .................................................. 691

Copyright © 2022 IEEE. All rights reserved. 31

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Figure 36-57—PE field duration of an EHT MU PPDU if the maximum value of TXVECTOR parameters
2 NOMINAL_PACKET_PADDING[u] is 20 µs and TPE = TPE,nominal(#8140)...................................... 692
3
Figure 36-58—EHT sounding NDP format(#7256) .................................................................................... 699
4
5 Figure 36-59—Example transmit spectral mask for a 20 MHz mask PPDU .............................................. 701
6 Figure 36-60—Example transmit spectral mask for a 40 MHz mask PPDU .............................................. 702
7 Figure 36-61—Example transmit spectral mask for an 80 MHz mask PPDU ............................................ 703
8 Figure 36-62—Example transmit spectral mask for a 160 MHz mask PPDU ............................................ 704
9
Figure 36-63—Example transmit spectral mask for a 320 MHz mask PPDU ............................................ 704
10
11 Figure 36-64—Example transmit spectral mask for a 320 MHz non-HT duplicate PPDU ........................ 705
12 Figure 36-65—Preamble puncture mask for preamble puncturing at the edge of the EHT PPDU............. 706
13 Figure 36-66—Example for the construction of the overall interim spectral mask for 80 MHz EHT PPDU
14 with the lowest 20 MHz subchannel punctured........................................................................................... 707
15
Figure 36-67—Preamble puncture mask for preamble puncturing in the EHT PPDU when the bandwidth of
16
17 the punctured subchannel is equal to or greater than 40 MHz and the punctured subchannel is not at the edge
18 of the PPDU bandwidth(#7262) .................................................................................................................. 708
19 Figure 36-68—Example for the construction of the overall interim spectral mask for 160 MHz EHT PPDU
20 with the second lowest 40 MHz subchannel punctured............................................................................... 709
21
Figure 36-69—Preamble puncture mask for preamble puncturing in the EHT PPDU when the bandwidth of
22
23 the punctured subchannel is equal to 20 MHz and the punctured subchannel is not at the edge of the PPDU
24 bandwidth(#7262) ........................................................................................................................................ 710
25 Figure 36-70—Example for the construction of the overall interim spectral mask for 80 MHz EHT PPDU
26 with the second lowest 20 MHz subchannel punctured(#6149) .................................................................. 711
27
Figure 36-71—Preamble puncture mask for preamble puncturing at the edge of the non-HT duplicate PPDU
28
29 712
30 Figure 36-72—Preamble puncture mask for preamble puncturing in the non-HT duplicate PPDU when the
31 bandwidth of the punctured subchannel is equal to or greater than 40 MHz and the punctured subchannel is
32 not at the edge of the PPDU bandwidth(#7262) .......................................................................................... 712
33
Figure 36-73—Preamble puncture mask for preamble puncturing in the non-HT duplicate PPDU when the
34
35 bandwidth of the punctured subchannel is equal to 20 MHz and the punctured subchannel is not at the edge
36 of the PPDU bandwidth(#7262)(#1594)...................................................................................................... 712
37 Figure 36-74—Example for the construction of the overall interim spectral mask for 320 MHz non-HT du-
38 plicated transmission with the lowest 40 MHz subchannel punctured ........................................................ 713
39
Figure 36-75—PHY transmit procedure for an EHT MU PPDU(#4913) ................................................... 732
40
41 Figure 36-76—PHY transmit procedure for an EHT TB PPDU(#7271) .................................................... 732
42 Figure 36-77—PHY transmit state machine for an EHT PPDU ................................................................. 734
43 Figure 36-78—PHY receive procedure for an EHT MU PPDU ................................................................. 735
44 Figure 36-79—PHY receive procedure for an EHT TB PPDU(#8147) ...................................................... 735
45
Figure 36-80—PHY receive state machine(#6819)(#3196) ........................................................................ 736
46
47 Figure AA-6—Example of affiliated APs from different multiple BSSID sets(#8253) ............................. 830
48 Figure AA-7—Example of affiliated APs belonging to a multiple BSSID set, a co-hosted BSSID set, and nei-
49 ther of these two cases(#1819)(#8253) ........................................................................................................ 831
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

32 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Tables
2
3
4 Table 1—Draft Status .................................................................................................................................... 40
5 Table 8-5—The channel-list parameter entries.............................................................................................. 98
6 Table 9-1—Valid type and subtype combinations ...................................................................................... 101
7 Table 9-13—Ack policy .............................................................................................................................. 102
8
Table 9-25—Control ID subfield values ..................................................................................................... 103
9
10 Table 9-33a—The encoding of the Rx NSS Extension subfield in EHT OM Control subfield combined with
11 the Rx NSS subfield in OM Control subfield(#4138) ................................................................................. 105
12 Table 9-33b—The encoding of the Channel Width Extension subfield in EHT OM Control subfield combined
13 with the Channel Width subfield in OM Control subfield(#6574) .............................................................. 106
14
Table 9-33c—The encoding of the Tx NSTS Extension subfield in EHT OM Control subfield combined with
15
16 the Tx NSTS subfield in OM Control subfield(#4138) ............................................................................... 106
17 Table 9-34—Maximum data unit sizes (in octets) and durations (in microseconds) .................................. 109
18 Table 9-38—Fragment Number subfield encoding for the Compressed BlockAck variant ....................... 115
19 Table 9-40—Fragment Number subfield encoding for the Multi-STA BlockAck variant ......................... 117
20
Table 9-42a—NDP Announcement frame variant encoding....................................................................... 118
21
22 Table 9-42b—AID11 subfield encoding in an NDP Announcement frame(#5788)(#1487) ...................... 119
23 Table 9-42c—Settings for BW, Partial BW Info subfield in the EHT NDP Announcement frame(#8157)121
24 Table 9-44—Feedback Type And Ng subfield and Codebook Size subfield encoding for HE and EHT TB
25 sounding(#7918) .......................................................................................................................................... 123
26
Table 9-45—Feedback Type And Ng subfield and Codebook Size subfield encoding for HE and EHT non-
27
28 TB sounding(#7918) .................................................................................................................................... 123
29 Table 9-46—Trigger Type subfield encoding ............................................................................................. 127
30 Table 9-47—UL BW subfield encoding...................................................................................................... 128
31 Table 9-48—GI And HE/EHT-LTF Type subfield encoding ..................................................................... 128
32
Table 9-49—MU-MIMO HE-LTF Mode subfield encoding ...................................................................... 129
33
34 Table 9-50—Pre-FEC Padding Factor and PE Disambiguity subfields ...................................................... 130
35 Table 9-50a—Valid combinations of B54 and B55 in the Common Info field, B39 in the User Info field, and
36 solicited TB PPDU format ........................................................................................................................... 133
37 Table 9-51—AID12 subfield encoding ....................................................................................................... 134
38
Table 9-52—B7–B1 of the RU Allocation subfield in an HE variant User Info field ................................ 135
39
40 Table 9-53—UL Target Receive Power subfield in Trigger frame............................................................. 137
41 Table 9-53a—Encoding of PS160 and RU Allocation subfields in an EHT variant User Info field .......... 139
42 Table 9-53b—Lookup table for X1 and N(#7032) ...................................................................................... 144
43 Table 9-53c—UL Bandwidth Extension subfield encoding........................................................................ 147
44
Table 9-53d—Mapping from Special User Info field to U-SIG-1 and U-SIG-2 fields in the EHT TB
45
46 PPDU(#4607)............................................................................................................................................... 148
47 Table 9-53e—TXOP Sharing Mode subfield encoding .............................................................................. 150
48 Table 9-60—Beacon frame body(#8264)(#1004)(#2246)(#3352) .............................................................. 152
49 Table 9-62—Association Request frame body(#1004)(#2246)(#3353) ...................................................... 152
50
Table 9-63—Association Response frame body(#1004)(#2246)(#3354).................................................... 153
51
52 Table 9-64—Reassociation Request frame body(#1004)(#2246)(#3355)................................................... 153
53 Table 9-65—Reassociation Response frame body(#1004)(#2246)(#3356) ................................................ 154
54 Table 9-66—Probe Request frame body(#1004)(#2246)(#3357)................................................................ 154
55 Table 9-67—Probe Response frame body(#1004)(#2246)(#3359) ............................................................. 155
56
Table 9-68—Authentication frame body ..................................................................................................... 155
57
58 Table 9-71—Action frame body and Action No Ack frame body .............................................................. 155
59 Table 9-78—Status codes ............................................................................................................................ 158
60 Table 9-79—Category values(#4007)(#4299)............................................................................................. 158
61 Table 9-108—Subfield values of the Operating Mode field ....................................................................... 159
62
Table 9-127a—EHT MIMO Control field encoding ................................................................................... 161
63
64 Table 9-127b—Subcarrier indices when not all bits in Partial BW Info subfield corresponding to the 80 MHz
65 subblock are set to 1(#4890)(#1279) ........................................................................................................... 163

Copyright © 2022 IEEE. All rights reserved. 33

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 9-127c—Subcarrier indices when all bits in Partial BW Info subfield corresponding to the 80 MHz sub-
2 block are set to 1 for Ng = 4(#4890)(#1279) ............................................................................................... 164
3
Table 9-127d—Subcarrier indices when all bits in Partial BW Info subfield corresponding to the 80 MHz sub-
4
5 block are set to 1 for Ng = 16(#4890)(#1279) ............................................................................................. 165
6 Table 9-127e—Subfields of the EMLMR Supported MCS And NSS Set subfield(#4425) ....................... 169
7 Table 9-128—Element IDs(#1009)(#1121)................................................................................................. 170
8 Table 9-190—Extended Capabilities field .................................................................................................. 171
9
Table 9-210—Optional subelement IDs for Neighbor Report(#1010)(#1128) ........................................... 172
10
11 Table 9-218—Subelement IDs .................................................................................................................... 174
12 Table 9-321—TBTT Information field contents(#1205)(#1728)(#2567) ................................................... 179
13 Table 9-328—PHY Support Criterion subfield(#1014)(#1130).................................................................. 182
14 Table 9-339—Broadcast TWT Recommendation field for a broadcast TWT element............................... 183
15
Table 9-401a—Channel width, CCFS0, and CCFS1 subfields(#6603)(#1086)(#1667)(#2148)(#2147).... 187
16
17 Table 9-401b—EHT BSS channel width(#6603) ........................................................................................ 188
18 Table 9-401c—Type subfield encoding(#4813)(#1905)(#2160)(#3247).................................................... 189
19 Table 9-401d—Optional subelement IDs for Link Info field of the Multi-Link element(#5967)(#5833).. 189
20 Table 9-401e—Medium Synchronization OFDM ED Threshold subfield ................................................. 192
21
Table 9-401f—Encoding of the EMLSR Padding Delay subfield(#7335)(#5829) ..................................... 193
22
23 Table 9-401g—Encoding of the EMLMR Delay subfield(#5830).............................................................. 194
24 Table 9-401h—Encoding of the Transition Timeout subfield(#5845)(#7581) ........................................... 194
25 Table 9-401i—Subfields of the MLD Capabilities field(#1078)(#1475)(#2981) ....................................... 195
26 Table 9-401j—Optional subelement IDs for the Priority Access Multi-Link element(#4176)................... 204
27
Table 9-401k—Subfields of the EHT MAC Capabilities Information field ............................................... 206
28
29 Table 9-401l—Subfield of the EHT PHY Capabilities Information field................................................... 209
30 Table 9-401m—Subfields of the Supported EHT-MCS And NSS Set field(#4972)(#4516)...................... 217
31 Table 9-401n—Encoding of the maximum number of Nss for a specified MCS value.............................. 221
32 Table 9-401o—Constellation index............................................................................................................. 223
33
Table 9-401p—RU allocation index............................................................................................................ 223
34
35 Table 9-401q—Direction subfield encoding(#4918)................................................................................... 227
36 Table 9-401r—MSDU Delivery Ratio field values(#4918) ........................................................................ 229
37 Table 9-454—TDLS Discovery Response Action field format(#1133)...................................................... 230
38 Table 9-464—BSS Operating Channel Width(#1020) ................................................................................ 230
39
Table 9-466—PHY Index subfield(#1020) ................................................................................................. 230
40
41 Table 9-467—FILS Minimum Rate(#1020)................................................................................................ 231
42 Table 9-494—Information for TDLS Setup Request Action field(#1133) ................................................. 233
43 Table 9-495—Information for TDLS Setup Response Action field(#1133) ............................................... 233
44 Table 9-496—Information for TDLS Setup Confirm Action field(#1133)................................................. 234
45
Table 9-507—Information for TDLS Discovery Request Action field(#4031) .......................................... 234
46
47 Table 9-509—Optional subelement IDs for WNM Sleep Mode parameters .............................................. 237
48 Table 9-623a—EHT Action field values ..................................................................................................... 240
49 Table 9-623b—EHT Compressed Beamforming/CQI frame Action field format(#6078) ......................... 240
50 Table 9-623c—EML Operating Mode Notification frame Action field format .......................................... 241
51
Table 9-623d—Protected EHT Action field values(#1119)(#1488) ........................................................... 241
52
53 Table 9-623e—TID-To-Link Mapping Request frame Action field format ............................................... 242
54 Table 9-623f—TID-To-Link Mapping Response frame Action field format ............................................. 242
55 Table 9-623g—TID-To-Link Mapping Teardown frame Action field format............................................ 243
56 Table 9-623h—EPCS Priority Access Enable Request frame Action field format(#5284) ........................ 243
57
Table 9-623i—EPCS Priority Access Enable Response frame Action field format(#5284)....................... 244
58
59 Table 9-623j—EPCS Priority Access Teardown Action field format(#5284) ............................................ 245
60 Table 9-627—MPDU delimiter fields ......................................................................................................... 246
61 Table 9-628—A-MPDU contexts ................................................................................................................ 248
62 Table 9-632—A-MPDU contents in the control response context.............................................................. 250
63
Table 9-634—A-MPDU contents in the HE non-ack-enabled single-TID immediate response context
64
65 (#4295)or in the EHT non-ack-enabled single-TID immediate response context....................................... 251

34 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 9-635—A-MPDU contents in the HE ack-enabled single-TID immediate response context (#4295)or
2 in the EHT ack-enabled single-TID immediate response context ............................................................... 251
3
Table 9-636—A-MPDU contents in the HE non-ack-enabled multi-TID immediate response context
4
5 (#4295)or in the EHT non-ack-enabled multi-TID immediate response context ........................................ 251
6 Table 9-637—A-MPDU contents in the HE ack-enabled multi-TID immediate response context (#4295)or in
7 the EHT ack-enabled multi-TID immediate response context .................................................................... 252
8 Table 10-5—Transmitter sequence number spaces ..................................................................................... 257
9
Table 10-6—Receiver caches ...................................................................................................................... 259
10
11 Table 10-9—Modulation classes(#1141)..................................................................................................... 262
12 Table 10-10—Non-HT reference rate.......................................................................................................... 267
13 Table 10-12—Conditions for including Control subfield variants .............................................................. 268
14 Table 11-13a—Frame type and their pathway in a TDLS setup(#4032)..................................................... 302
15
Table 11-18—Default QMF policy ............................................................................................................. 304
16
17 Table 12-10—KDE selectors....................................................................................................................... 323
18 Table 13-1—FT authentication elements .................................................................................................... 352
19 Table 17-1—TXVECTOR parameters ........................................................................................................ 358
20 Table 17-2—RXVECTOR parameters ........................................................................................................ 359
21
Table 17-7—Contents of the first 7 bits of the scrambling sequence.......................................................... 361
22
23 Table 17-8—TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT values ..................................... 361
24 Table 17-9a—RXVECTOR parameter CH_BANDWIDTH_IN_NON_HT values for an EHT STA ....... 362
25 Table 17-9—RXVECTOR parameter CH_BANDWIDTH_IN_NON_HT values for a VHT or HE STA 362
26 Table 35-1—Negotiated buffer size and Block Ack Bitmap subfield length ............................................. 442
27
Table 35-2—Informative summary of supported RU/MRU sizes for sounding feedback.......................... 457
28
29 Table 35-3—EHT nominal packet padding indication when the PPE Thresholds Present subfield is set to 0 in
30 both the EHT and HE Capabilities elements(#7942)................................................................................... 479
31 Table 35-4—EHT nominal packet padding indication for NSS ≤ NSTS+1 when the PPE Thresholds Present
32 subfield is set to 0 in the EHT Capabilities element and 1 in the HE Capabilities element(#7942) ........... 480
33
Table 35-5—PPE thresholds per PPET8 and PPETmax(#7736)................................................................. 481
34
35 Table 35-6—Indication of supported channel widths by an EHT STA(#6930)(#4509) ............................. 484
36 Table 36-1—TXVECTOR and RXVECTOR parameters........................................................................... 502
37 Table 36-2—TRIGVECTOR parameters(#1539) ....................................................................................... 515
38 Table 36-3—Interpretation of FORMAT, NON_HT_MODULATION, and CH_BANDWIDTH parameters
39
517
40
41 Table 36-4—Mapping of the EHT PHY parameters for non-HT operation................................................ 521
42 Table 36-5—Data and pilot subcarrier indices for RUs in an 80 MHz EHT PPDU ................................... 525
43 Table 36-6—Data and pilot subcarrier indices for RUs in a 160 MHz EHT PPDU ................................... 526
44 Table 36-7—Data and pilot subcarrier indices for RUs in a 320 MHz EHT PPDU ................................... 528
45
Table 36-8—Indices for small size MRUs in an OFDMA 20 MHz EHT PPDU........................................ 534
46
47 Table 36-9—Indices for small size MRUs in an OFDMA 40 MHz EHT PPDU........................................ 535
48 Table 36-10—Indices for small size MRUs in an OFDMA 80 MHz EHT PPDU...................................... 535
49 Table 36-11—Indices for small size MRUs in an OFDMA 160 MHz EHT PPDU.................................... 537
50 Table 36-12—Indices for small size MRUs in an OFDMA 320 MHz EHT PPDU.................................... 538
51
Table 36-13—Indices for large size MRUs in an OFDMA 80 MHz EHT PPDU and in a non-OFDMA
52
53 80 MHz EHT PPDU(#5466)(#4903)(#2398) .............................................................................................. 547
54 Table 36-14—Indices for large size MRUs in an OFDMA 160 MHz EHT PPDU and in a non-OFDMA
55 160 MHz EHT PPDU(#5466)(#4903)(#2398) ............................................................................................ 548
56 Table 36-15—Indices for large size MRUs in an OFDMA 320 MHz EHT PPDU and in a non-OFDMA
57
320 MHz EHT PPDU(#4989)(#5466)(#4903)(#2398)................................................................................ 550
58
59 Table 36-16—Null subcarrier indices for 80 MHz, 160 MHz, and 320 MHz............................................. 553
60 Table 36-17—EHT PPDU fields ................................................................................................................. 560
61 Table 36-18—Timing-related constants ...................................................................................................... 576
62 Table 36-19—Subcarrier allocation related constants for the EHT-modulated fields in a nonpunctured non-
63
OFDMA EHT PPDU(#8100) ...................................................................................................................... 578
64
65 Table 36-20—Subcarrier allocation related constants for the EHT-modulated fields in a punctured non-OFD-

Copyright © 2022 IEEE. All rights reserved. 35

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 MA EHT PPDU ........................................................................................................................................... 579

2 Table 36-21—Subcarrier allocation related constants for RUs in an OFDMA EHT PPDU....................... 580
3
Table 36-22—Subcarrier allocation related constants for MRUs in an OFDMA EHT PPDU ................... 580
4
5 Table 36-23—Frequently used parameters.................................................................................................. 581
6 Table 36-24—Fields to specify EHT channels............................................................................................ 583
7 Table 36-25—Center frequency of the transmitted PPDU .......................................................................... 585
8 Table 36-26—Number of modulated subcarriers and guard interval duration values for EHT PPDU fields ...
9
589
10
11 Table 36-27—CH_BANDWIDTH and phase rotation for a given bandwidth for pre-EHT modulated
12 fields(#1560)(#4846) ................................................................................................................................... 591
13 Table 36-28—U-SIG field of an EHT MU PPDU ...................................................................................... 598
14 Table 36-29—Combination of UL/DL and PPDU Type And Compression Mode field(#1562)(#1352)... 601
15
Table 36-30—Definition of the Punctured Channel Information field in the U-SIG for an EHT MU PPDU
16
17 using non-OFDMA transmissions(#8011)(#2402) ...................................................................................... 602
18 Table 36-31—U-SIG field of an EHT TB PPDU........................................................................................ 606
19 Table 36-32—U-SIG field of an ER preamble ............................................................................................ 610
20 Table 36-33—Common field for OFDMA transmission ............................................................................ 617
21
Table 36-34—RU Allocation subfield......................................................................................................... 622
22
23 Table 36-35—RUs associated with each RU Allocation subfield for each EHT-SIG content channel and
24 PPDU bandwidth ......................................................................................................................................... 628
25 Table 36-36—Common field for non-OFDMA transmission to a single user and non-OFDMA transmission
26 to multiple users........................................................................................................................................... 630
27
Table 36-37—Common field for EHT sounding NDP................................................................................ 632
28
29 Table 36-38—The common encoding block in an EHT-SIG field for non-OFDMA transmission to a single
30 user and multiple users(#5485)(#8018)(#1390) .......................................................................................... 634
31 Table 36-39—The user encoding block(#5485) .......................................................................................... 635
32 Table 36-40—User field format for a non-MU-MIMO allocation.............................................................. 636
33
Table 36-41—User field format for an MU-MIMO allocation(#7095)....................................................... 638
34
35 Table 36-42—Spatial Configuration subfield encoding(#5483) ................................................................. 639
36 Table 36-43—Initial number of EHT-LTFs required for different number of spatial streams(#4953)....... 653
37 Table 36-44—EHT-LTF type and GI duration combinations for various EHT PPDU formats ................. 654
38 Table 36-45—SERVICE field ..................................................................................................................... 662
39
Table 36-46—NSD,short values for EHT-MCS values from 0 to 13 and 15.............................................. 666
40
41 Table 36-47—NSD,short values for EHT-MCS 14..................................................................................... 666
42 Table 36-48—Values of (#7294) ................................................................................................................ 671
43 Table 36-49—Segment parser parameters(#7293)(#1411) ......................................................................... 672
44 Table 36-50—Joint BCC interleaver parameters for small size MRUs ...................................................... 675
45
Table 36-51—4096-QAM encoding table ................................................................................................... 676
46
47 Table 36-52—LDPC tone mapping distance for each RU/MRU size within an 80 MHz subblock(#2658).....
48 679
49 Table 36-53—Pilot indices for a 26-tone RU transmission......................................................................... 683
50 Table 36-54—Pilot indices for a 52-tone RU transmission......................................................................... 683
51
Table 36-55—Pilot indices for a 106-tone RU transmission....................................................................... 684
52
53 Table 36-56—Pilot indices for a 242-tone RU transmission....................................................................... 684
54 Table 36-57—Pilot indices for a 484-tone RU transmission....................................................................... 685
55 Table 36-58—Pilot indices for a 996-tone RU transmission....................................................................... 685
56 Table 36-59—Pilot indices for a 2×996-tone RU transmission .................................................................. 686
57
Table 36-60—Pilot indices for a 4×996-tone RU transmission .................................................................. 686
58
59 Table 36-61—Nominal TPE values............................................................................................................. 690
60 Table 36-62—Transmit power and RSSI measurement accuracy............................................................... 696
61 Table 36-63—Maximum transmit spectral flatness deviations for EHT PPDU ......................................... 714
62 Table 36-64—Maximum transmit spectral flatness deviations for non-HT duplicate PPDU ..................... 715
63
Table 36-65—Allowed relative constellation error versus constellation size and coding rate.................... 719
64
65 Table 36-66—iRU26, start for RUs other than a 26-tone RU(#7265) ........................................................ 724

36 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-67—Receiver minimum input level sensitivity............................................................................ 727

2 Table 36-68—Minimum required adjacent and nonadjacent channel rejection levels................................ 728
3
Table 36-69—EHT PHY MIB attributes(#7281) ........................................................................................ 740
4
5 Table 36-70—EHT PHY characteristics ..................................................................................................... 746
6 Table 36-71—EHT-MCSs for 26-tone RU, NSS,u = 1 ............................................................................... 747
7 Table 36-72—EHT-MCSs for 52-tone RU, NSS,u = 1 ............................................................................... 748
8 Table 36-73—EHT-MCSs for 52+26-tone MRU, NSS,u = 1 ..................................................................... 749
9
Table 36-74—EHT-MCSs for 106-tone RU, NSS,u = 1............................................................................. 750
10
11 Table 36-75—EHT-MCSs for 106+26-tone MRU, NSS,u = 1 ................................................................... 751
12 Table 36-76—EHT-MCSs for 242-tone RU, NSS,u = 1............................................................................. 752
13 Table 36-77—EHT-MCSs for 484-tone RU, NSS,u = 1............................................................................. 753
14 Table 36-78—EHT-MCSs for 484+242-tone MRU, NSS,u = 1 ................................................................. 754
15
Table 36-79—EHT-MCSs for 996-tone RU, NSS,u = 1............................................................................. 755
16
17 Table 36-80—EHT-MCSs for 996+484-tone MRU, NSS,u = 1 ................................................................. 756
18 Table 36-81—EHT-MCSs for 996+484+242-tone MRU, NSS,u = 1......................................................... 757
19 Table 36-82—EHT-MCSs for 2×996-tone RU, NSS,u = 1......................................................................... 758
20 Table 36-83—EHT-MCSs for 2×996+484-tone MRU, NSS,u = 1............................................................. 759
21
Table 36-84—EHT-MCSs for 3×996-tone MRU, NSS,u = 1 ..................................................................... 760
22
23 Table 36-85—EHT-MCSs for 3×996+484-tone MRU, NSS,u = 1............................................................. 761
24 Table 36-86—EHT-MCSs for 4×996-tone RU, NSS,u = 1......................................................................... 762
25 Table 36-87—EHT-MCS 14 for EHT DUP mode, NSS,u = 1(#4909) ....................................................... 762
26 Table 36-88—EHT-SIG MCSs(#8152)....................................................................................................... 763
27
Table E-4—Global operating classes .......................................................................................................... 809
28
29 Table R-3—SSPN Interface information or permission parameters(#5284)(#5652) .................................. 810
30 Table Z-8—U-SIG overflow example 1 ...................................................................................................... 812
31 Table Z-9—Resource allocation signaling example 1................................................................................. 812
32 Table Z-10—Resource Allocation subfield illustration example 1 ............................................................. 812
33
Table Z-11—EHT-SIG content for example 1 ............................................................................................ 813
34
35 Table Z-12—U-SIG overflow example 2 .................................................................................................... 813
36 Table Z-13—Resource allocation signaling example 2............................................................................... 814
37 Table Z-14—Resource Allocation subfield illustration example 2 ............................................................. 814
38 Table Z-15—EHT-SIG content for example 2 ............................................................................................ 814
39
Table Z-16—U-SIG overflow example 3 .................................................................................................... 815
40
41 Table Z-17—Resource allocation signaling example 3............................................................................... 815
42 Table Z-18—Resource Allocation subfield illustration for the lower 80 MHz example 3 ......................... 816
43 Table Z-19—Resource Allocation subfield illustration for the upper 80 MHz example 3 ......................... 816
44 Table Z-20—EHT-SIG content in the lower 80 MHz for example 3.......................................................... 816
45
Table Z-21—EHT-SIG content in the upper 80 MHz for example 3.......................................................... 817
46
47 Table Z-22—U-SIG overflow example 4 .................................................................................................... 818
48 Table Z-23—Resource allocation signaling example 4............................................................................... 818
49 Table Z-24—Resource Allocation subfield illustration for the lower 80 MHz example 4 ......................... 819
50 Table Z-25—Resource Allocation subfield illustration for the upper80 MHz example 4 .......................... 819
51
Table Z-26—EHT-SIG content in the lower 80 MHz for example 4.......................................................... 819
52
53 Table Z-27—EHT-SIG content in the upper 80 MHz for example 4.......................................................... 820
54 Table Z-28—U-SIG overflow example 5 .................................................................................................... 821
55 Table Z-29—Resource allocation signaling example 5............................................................................... 822
56 Table Z-30—EHT-SIG content for example 5 ............................................................................................ 822
57
Table Z-31—U-SIG overflow example 6 .................................................................................................... 823
58
59 Table Z-32—Resource allocation signaling example 6............................................................................... 823
60 Table Z-33—EHT-SIG content for example 6 ............................................................................................ 824
61 Table Z-34—U-SIG overflow example 7 (#5496) ...................................................................................... 824
62 Table Z-35—Resource allocation signaling example 7 (#5496) ................................................................. 825
63
Table Z-36—RU Allocation subfield illustration for each 80 MHz frequency subband example 7(#5496) ....
64
65 825

Copyright © 2022 IEEE. All rights reserved. 37

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table Z-37—EHT-SIG content in each 80 MHz frequency subband for example 7(#5496) ..................... 826
2 Table Z-38—U-SIG overflow example 8 .................................................................................................... 826
3
Table Z-39—Resource allocation signaling example 8............................................................................... 827
4
5 Table Z-40—RU Allocation subfield illustration for each 80 MHz frequency subband example 8........... 827
6 Table Z-41—EHT-SIG content in each 80 MHz frequency subband for example 8 .................................. 828
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

38 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2 IEEE P802.11be™/D1.5
3
4 
5
6 Draft Standard for Information technology—Tele-
7
8
9
communications and information exchange be-
10
11
tween systems Local and metropolitan area
12
13 networks—Specific requirements
14
15 
16
17 Part 11: Wireless LAN Medium Access Control
18
19
20
(MAC) and Physical Layer (PHY) specifications
21
22

23
24 Amendment 8: Enhancements for extremely high
25
26 throughput (EHT)
27
28
29
30 [This amendment is based on IEEE 802.11-2020 standards as amended by IEEE P802.11ax-2021, IEEE
31 P802.11ay-2021, IEEE P802.11az/D4.0, IEEE P802.11ba-2021, IEEE P802.11bb/D0.7, IEEE P802.11bc/
32
33 D2.0, IEEE P802.11bd/D2.1, and IEEEP802.11REVme/D1.1.]
34
35
36
37
38 NOTE—The editing instructions contained in this amendment define how to merge the material contained therein into
39 the existing base standard and its amendments to form the comprehensive standard.
40
41 The editing instructions are shown in bold italic. Four editing instructions are used: change, delete, insert, and replace.
42 Change is used to make corrections in existing text or tables. The editing instruction specifies the location of the change
43 and describes what is being changed by using strikethrough (to remove old material) and underscore (to add new mate-
44 rial). Delete removes existing material. Insert adds new material without disturbing the existing material. Insertions may
45 require renumbering. If so, renumbering instructions are given in the editing instruction. Replace is used to make
46 changes in figures or equations by removing the existing figure or equation and replacing it with a new one. Editorial
47 instructions, change markings and this NOTE will not be carried over into future editions because the changes will be
48 incorporated into the base standard.
49
50
51
52 Editorial Notes
53
54
55 Editor’s Note: Editorial Notes in the body of the standard appear like this. They will be removed before
56 publication. They may highlight some issue that the editor has had to address during the implementation
57 of a change. Where there may be any technical impact from an editing issue, the editor will raise a tech-
58 nical letter ballot comment. There is no need for voters to comment on such issues unless they have a spe-
59
60 cific resolution they wish to present.
61
62
Editor’s Note: Headings with empty content or Headings preceding editing instructions that modify the
63
64 contents of the referenced subclause are there to provide context to the reader of this document, they have
65 no other significance.

Copyright © 2022 IEEE. All rights reserved. 39

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Editor’s Note: The default IEEE-SA style for tables is to "float". This means that they be repositioned
2 later, usually at the head of the next page, to avoid splitting the table and reduce the amount of blank
3
space. The table can appear to move out of the subclause it is referenced first from, and can even split a
4
5 paragraph. This is the intended IEEE-SA behavior, please do not report it as a defect in the draft. In
6 many cases, additional line feeds have been inserted to force tables to follow text, rather than float beyond
7 sequential text. The additional line feeds will be removed before publication, please do not report them as
8 a defect in the text.
9
10
11 Editor’s Note: Line numbering is only approximate. This is a limitation of the FrameMaker tool.
12 Whitespace between paragraphs is part of the IEEE-SA style, as defined in their templates. The combina-
13 tion of these two facts leads to the appearance of blank lines in the draft between every paragraph. Please
14 do not report this as an editorial defect as it is the unavoidable behavior.
15
16
17
18 Tags:
19
20 Tags are placed in this draft near changes to identify the source of the change. Changes resulting from incor-
21 poration of an approved proposal are shown like this: (#<number>), where <number> identifies the submis-
22 sion/revision that introduced that change.
23
24 These tags will be hidden in versions of the draft sent out to letter ballot - i.e., they are present only to assist
25 the editorial review panel in checking that changes have been properly applied.
26
27 Tags are shown close to the point of change. When a whole subclause is new, the heading is tagged.
28
Otherwise, when a whole paragraph is new, the paragraph is tagged. Otherwise tags are placed after a section
29
30 of changes within a paragraph or at the end of the paragraph if the changes are substantial.
31 New tables are tagged in the table caption (if there is one), or in the introductory paragraph. Otherwise, new
32
rows in existing tables are tagged only in the first column, to avoid distraction. Otherwise, a modified cell is
33
34 tagged.
35 Finally, any other changes made by the editor (e.g., for grammar, language, style & consistency with other
36
comment resolutions, baseline, etc.) are tagged (#Ed).
37
38
39 Editor’s Note: A cumulative status of the versions of this draft is shown below.
40
41 Table 1—Draft Status
42
43 Draft Date Status
44
45
D0.01 2020-07-06 Initial skeleton.
46
47 D0.1 2020-09-30 Include Motion 134 from the September 30th, 2020, teleconference call.
48
49 D0.2 2020-12-02 Include Motion 145 from the November 2020 plenary.
50
51 D0.3 2021-01-16 Include Motion 151 from the January 2021 interim.
52
53 D0.4 2021-03-19 Include Motion 165 from the March 2021 plenary.
54
55 D1.0 2021-05-19 Include Motion 203 from the May 2021 interim.
56
57 D1.01 2021-06-30 Include Motions 204, 205, 206, 209, 210, 211, and 212.
58
59 D1.1 2021-07-23 Include Motion 225 from the July 2021 plenary.
60
61 D1.2 2021-09-21 Include Motion 253 from the September 2021 interim.
62
63 D1.3 2021-11-18 Include Motion 274 from the November 2021 plenary.
64
D1.31 2021-12-17 Include Motions 275 to 282 from the December 15th, 2021, teleconference call.
65

40 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 1—Draft Status (continued)

2
3 Draft Date Status
4
5
D1.4 2022-01-26 Include Motion 300 from the January 2022 interim.
6
7 D1.5 2022-03-18 Include Motions 302 to 312, 315 to 320, and 324 from the March 2022 plenary.
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 41

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

42 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 1. Overview
2
3
4 1.5 Terminology for mathematical, logical, and bit operations
5
6
7 Insert the following terminologies at the end of the subclause:
8
9 (#7107)min(x, y) is the lower of the two values x and y.
10
11
12 (#7107)max(x, y) is the higher of the two values x and y.
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 43

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

44 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 3. Definitions, acronyms, and abbreviations

2
3
4 3.1 Definitions
5
6
7 Change the following definitions:
8
9
10 authenticator address (AA): The medium access control (MAC) address of the IEEE 802.1X Authentica-
11 tor’s STA or the multi-link device (MLD) MAC address of the IEEE 802.1X Authenticator’s MLD.
12
13 Supplicant address (SPA): The medium access control (MAC) address of the IEEE 802.1X Supplicant’s
14
STA or the multi-link device (MLD) MAC address of the IEEE 802.1X Supplicant’s MLD.
15
16
17 Insert the following definitions (maintaining alphabetical order):
18
19
20 (#5284)(#2257)(#3345)(#1721)Emergency Preparedness Communications Service (EPCS) priority
21 access: An on-demand capability that allows access point (AP) multi-link devices (MLDs) to authorize non-
22 access point (non-AP) MLDs to communicate EPCS traffic with a higher priority, (#4091)as described in
23 35.17 (EPCS priority access(#5284)).
24
25
26 (#5284)(#2258)(#1721)Emergency Preparedness Communications Service (EPCS) traffic: The traffic
27 generated by (#7483)an authorized non-access point (non-AP) multi-link device (MLD) or traffic destined
28 for an authorized non-AP MLD when the EPCS priority access is authorized (#4804)and enabled for that
29 authorized non-AP MLD.
30
31
32 restricted target wake time (r-TWT): TWT with enhanced medium access protection and resource reser-
33 vation for latency sensitive traffic.
34
35
restricted target wake time (r-TWT) service period (SP): A restricted period of time during which certain
36
37 stations (STAs) can transmit and/or receive frames as defined in 35.9 (Restricted TWT (r-TWT)).
38
39
40 3.2 Definitions specific to IEEE 802.11
41
42
43
Change the following definitions:
44
45 20 MHz mask physical layer (PHY) protocol data unit (PPDU): One of the following PPDUs:
46
47 a) A Clause 17 (Orthogonal frequency division multiplexing (OFDM) PHY specification) PPDU trans-
48 mitted using the 20 MHz transmit spectral mask defined in Clause 17 (Orthogonal frequency divi-
49 sion multiplexing (OFDM) PHY specification).
50
51
b) A Clause 18 (Extended Rate PHY (ERP) specification) orthogonal frequency division multiplexing
52 (OFDM) PPDU transmitted using the transmit spectral mask defined in Clause 18 (Extended Rate
53 PHY (ERP) specification).
54
55
c) A high throughput (HT) PPDU with the TXVECTOR parameter CH_BANDWIDTH equal to
56 HT_CBW20 and the CH_OFFSET parameter equal to CH_OFF_20 transmitted using the 20 MHz
57 transmit spectral mask defined in Clause 19 (High Throughput (HT) PHY specification).
58
d) A very high throughput (VHT) PPDU with the TXVECTOR parameter CH_BANDWIDTH equal to
59
60 CBW20 transmitted using the 20 MHz transmit spectral mask defined in Clause 21 (Very High
61 Throughput (VHT) PHY specification).
62
e) A Clause 17 (Orthogonal frequency division multiplexing (OFDM) PHY specification) PPDU trans-
63
64 mitted by a VHT STA using the 20 MHz transmit spectral mask defined in Clause 21 (Very High
65 Throughput (VHT) PHY specification).

Copyright © 2022 IEEE. All rights reserved. 45

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 f) An HT PPDU with the TXVECTOR parameter CH_BANDWIDTH equal to HT_CBW20 and the
2 CH_OFFSET parameter equal to CH_OFF_20 transmitted by a VHT STA using the 20 MHz trans-
3
mit spectral mask defined in Clause 21 (Very High Throughput (VHT) PHY specification).
4
5 g) A high efficiency (HE) PPDU with TXVECTOR parameter CH_BANDWIDTH equal to CBW20
6 transmitted using the 20 MHz transmit spectral mask defined in Clause 27 (High Efficiency (HE)
7
8 PHY specification).
9 h) A Clause 17 (Orthogonal frequency division multiplexing (OFDM) PHY specification) PPDU trans-
10
11 mitted by an HE STA using the 20 MHz transmit spectral mask defined in Clause 27 (High Effi-
12 ciency (HE) PHY specification).
13
14 i) (#1081)An extremely high throughput (EHT) PPDU with TXVECTOR parameter CH_BAND-
15 WIDTH equal to CBW20 transmitted using the 20 MHz transmit spectral mask defined in Clause 36
16 (Extremely high throughput (EHT) PHY specification).
17
18
19 (#1081)20 MHz physical layer (PHY) protocol data unit (PPDU): A Clause 15 (DSSS PHY specification
20 for the 2.4 GHz band designated for ISM applications) PPDU, a Clause 17 (Orthogonal frequency division
21 multiplexing (OFDM) PHY specification) PPDU (when using 20 MHz channel spacing), a Clause 16 (High
22 rate direct sequence spread spectrum (HR/DSSS) PHY specification) PPDU, a Clause 18 (Extended Rate
23 PHY (ERP) specification) orthogonal frequency division multiplexing (OFDM) PPDU, a Clause 19 (High
24
25 Throughput (HT) PHY specification) 20 MHz high throughput (HT) PPDU with the TXVECTOR parameter
26 CH_BANDWIDTH equal to HT_CBW20, or a Clause 21 (Very High Throughput (VHT) PHY specifica-
27 tion) 20 MHz very high throughput (VHT) PPDU with the TXVECTOR parameter CH_BANDWIDTH
28 equal to CBW20, or a Clause 27 (High Efficiency (HE) PHY specification) 20 MHz high efficiency (HE)
29 PPDU with the TXVECTOR parameter CH_BANDWIDTH equal to CBW20, or a Clause 36 (Extremely
30
31 high throughput (EHT) PHY specification) 20 MHz extremely high throughput (EHT) PPDU with TXVEC-
32 TOR parameter CH_BANDWIDTH equal to CBW20.
33
34
40 MHz mask physical layer (PHY) protocol data unit (PPDU): One of the following PPDUs:
35
36 a) A 40 MHz high throughput (HT) PPDU (TXVECTOR parameter CH_BANDWIDTH equal to
37
HT_CBW40) transmitted using the 40 MHz transmit spectral mask defined in Clause 19 (High
38
39 Throughput (HT) PHY specification).
40 b) A 40 MHz non-HT duplicate PPDU (TXVECTOR parameter CH_BANDWIDTH equal to
41
42 NON_HT_CBW40) transmitted by a non-very high throughput (non-VHT) STA using the 40 MHz
43 transmit spectral mask defined in Clause 19 (High Throughput (HT) PHY specification).
44
45 c) A 40 MHz non-HT duplicate PPDU (TXVECTOR parameter CH_BANDWIDTH equal to CBW40)
46 transmitted by a very high throughput (VHT) STA using the 40 MHz transmit spectral mask defined
47 in Clause 21 (Very High Throughput (VHT) PHY specification).
48
49 d) A 20 MHz HT PPDU with the TXVECTOR parameter CH_BANDWIDTH equal to HT_CBW20
50 and the CH_OFFSET parameter equal to either CH_OFF_20U or CH_OFF_20L transmitted using
51 the 40 MHz transmit spectral mask defined in Clause 19 (High Throughput (HT) PHY specifica-
52 tion).
53
54 e) A 20 MHz VHT PPDU with the TXVECTOR parameter CH_BANDWIDTH equal to CBW20
55 transmitted using the 40 MHz transmit spectral mask defined in Clause 21 (Very High Throughput
56
57
(VHT) PHY specification).
58 f) A 40 MHz VHT PPDU with the TXVECTOR parameter CH_BANDWIDTH equal to CBW40
59
transmitted using the 40 MHz transmit spectral mask defined in Clause 21 (Very High Throughput
60
61 (VHT) PHY specification).
62
g) A 40 MHz HT PPDU (TXVECTOR parameter CH_BANDWIDTH equal to HT_CBW40) transmit-
63
64 ted by a VHT STA using the 40 MHz transmit spectral mask defined in Clause 21 (Very High
65 Throughput (VHT) PHY specification).

46 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 h) A 20 MHz non-HT PPDU (TXVECTOR parameter CH_BANDWIDTH equal to CBW20) transmit-

2 ted using the 40 MHz transmit spectral mask defined in Clause 19 (High Throughput (HT) PHY
3
specification).
4
5 i) A 20 MHz non-HT PPDU (TXVECTOR parameter CH_BANDWIDTH equal to CBW20) transmit-
6 ted by a VHT STA using the 40 MHz transmit spectral mask defined in Clause 21 (Very High
7 Throughput (VHT) PHY specification).
8
9 j) A 40 MHz high efficiency (HE) PPDU with TXVECTOR parameter CH_BANDWIDTH equal to
10 CBW40 transmitted using the 40 MHz transmit spectral mask defined in Clause 27 (High Efficiency
11 (HE) PHY specification).
12
13 k) A 40 MHz VHT PPDU (TXVECTOR parameter CH_BANDWIDTH equal to CBW40) transmitted
14 by an HE STA using the 40 MHz transmit spectral mask defined in Clause 21 (Very high throughput
15 (VHT) PHY specification).
16
17 l) A 40 MHz non-HT duplicate PPDU (TXVECTOR parameter CH_BANDWIDTH equal to CBW40)
18 transmitted by an HE STA using the 40 MHz transmit spectral mask defined in Clause 19 (High
19 Throughput (HT) PHY specification).
20
21 m) (#1081)A 40 MHz extremely high throughput (EHT) PPDU with TXVECTOR parameter
22 CH_BANDWIDTH equal to CBW40 transmitted using the 40 MHz transmit spectral mask defined
23 in Clause 36 (Extremely high throughput (EHT) PHY specification).
24
25
26 (#1081)40 MHz physical layer (PHY) protocol data unit (PPDU): A 40 MHz high throughput (HT)
27 PPDU (TXVECTOR parameter CH_BANDWIDTH equal to HT_CBW40), or a 40 MHz non-HT duplicate
28 PPDU (TXVECTOR parameter CH_BANDWIDTH equal to NON_HT_CBW40 or TXVECTOR parameter
29 CH_BANDWIDTH equal to CBW40), or a 40 MHz very high throughput (VHT) PPDU (TXVECTOR
30 parameter CH_BANDWIDTH equal to CBW40), or a Clause 27 (High Efficiency (HE) PHY specification)
31
32 40 MHz high efficiency (HE) PPDU with the TXVECTOR parameter CH_BANDWIDTH equal to CBW40,
33 or a Clause 36 (Extremely high throughput (EHT) PHY specification) 40 MHz extremely high throughput
34 (EHT) PPDU with the TXVECTOR parameter CH_BANDWIDTH equal to CBW40.
35
36 80 MHz mask physical layer (PHY) protocol data unit (PPDU): One of the following PPDUs:
37
38 a) An 80 MHz very high throughput (VHT) PPDU (TXVECTOR parameter CH_BANDWIDTH equal
39 to CBW80) transmitted using the 80 MHz transmit spectral mask defined in Clause 21 (Very High
40 Throughput (VHT) PHY specification).
41
42 b) An 80 MHz non-high throughput (non-HT) duplicate PPDU (TXVECTOR parameter CH_BAND-
43 WIDTH equal to CBW80) transmitted using the 80 MHz transmit spectral mask defined in
44 Clause 21 (Very High Throughput (VHT) PHY specification).
45
46 c) A 20 MHz non-HT, high throughput (HT), or VHT PPDU (TXVECTOR parameter CH_BAND-
47 WIDTH equal to CBW20) transmitted using the 80 MHz transmit spectral mask defined in
48 Clause 21 (Very High Throughput (VHT) PHY specification).
49
50 d) A 40 MHz non-HT duplicate, HT, or VHT PPDU (TXVECTOR parameter CH_BANDWIDTH
51 equal to CBW40) transmitted using the 80 MHz transmit spectral mask defined in Clause 21 (Very
52 High Throughput (VHT) PHY specification).
53
54 e) An 80 MHz high efficiency (HE) PPDU (TXVECTOR parameter CH_BANDWIDTH equal to
55 CBW80) transmitted using the 80 MHz transmit spectral mask defined in Clause 27 (High Effi-
56 ciency (HE) PHY specification).
57
58 f) (#1081)An 80 MHz extremely high throughput (EHT) PPDU (TXVECTOR parameter CH_BAND-
59 WIDTH equal to CBW80) transmitted using the 80 MHz transmit spectral mask defined in
60 Clause 36 (Extremely high throughput (EHT) PHY specification).
61
62
(#1081)80 MHz physical layer (PHY) protocol data unit (PPDU): A Clause 21 (Very High Throughput
63
64 (VHT) PHY specification) 80 MHz very high throughput (VHT) PPDU (TXVECTOR parameter
65 CH_BANDWIDTH equal to CBW80) or, a Clause 21 (Very High Throughput (VHT) PHY specification)

Copyright © 2022 IEEE. All rights reserved. 47

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 80 MHz non-high throughput (non-HT) duplicate PPDU (TXVECTOR parameter CH_BANDWIDTH

2 equal to CBW80), or a Clause 27 (High Efficiency (HE) PHY specification) 80 MHz high efficiency (HE)
3
PPDU with the TXVECTOR parameter CH_BANDWIDTH equal to CBW80, or a Clause 36 (Extremely
4
5 high throughput (EHT) PHY specification) 80 MHz extremely high throughput (EHT) PPDU with the
6 TXVECTOR parameter CH_BANDWIDTH equal to CBW80.
7
8
9
160 MHz mask physical layer (PHY) protocol data unit (PPDU): One of the following PPDUs:
10 a) A 160 MHz very high throughput (VHT) PPDU (TXVECTOR parameter CH_BANDWIDTH equal
11
to CBW160) transmitted using the 160 MHz transmit spectral mask defined in Clause 21 (Very
12
13 High Throughput (VHT) PHY specification).
14 b) A 160 MHz non-high throughput (non-HT) duplicate PPDU (TXVECTOR parameter CH_BAND-
15
16 WIDTH equal to CBW160) transmitted using the 160 MHz transmit spectral mask defined in
17 Clause 21 (Very High Throughput (VHT) PHY specification).
18
19 c) A 20 MHz non-HT, high throughput (HT), or VHT PPDU (TXVECTOR parameter CH_BAND-
20 WIDTH equal to CBW20) transmitted using the 160 MHz transmit spectral mask defined in
21 Clause 21 (Very High Throughput (VHT) PHY specification).
22
23 d) A 40 MHz non-HT duplicate, HT, or VHT PPDU (TXVECTOR parameter CH_BANDWIDTH
24 equal to CBW40) transmitted using the 160 MHz transmit spectral mask defined in Clause 21 (Very
25 High Throughput (VHT) PHY specification).
26
27 e) An 80 MHz non-HT duplicate or VHT PPDU (TXVECTOR parameter CH_BANDWIDTH equal to
28 CBW80) transmitted using the 160 MHz transmit spectral mask defined in Clause 21 (Very High
29 Throughput (VHT) PHY specification).
30
31 f) A 160 MHz high efficiency (HE) PPDU (TXVECTOR parameter CH_BANDWIDTH equal to
32 CBW160) transmitted using the 160 MHz transmit spectral mask defined in Clause 27 (High Effi-
33 ciency (HE) PHY specification).
34
35 g) (#1081)A 160 MHz extremely high throughput (EHT) PPDU (TXVECTOR parameter CH_BAND-
36 WIDTH equal to CBW160) transmitted using the 160 MHz transmit spectral mask defined in
37
38
Clause 36 (Extremely high throughput (EHT) PHY specification).
39
40 (#1081)160 MHz physical layer (PHY) protocol data unit (PPDU): A Clause 21 (Very High Throughput
41
42 (VHT) PHY specification) 160 MHz very high throughput (VHT) PPDU (TXVECTOR parameter
43 CH_BANDWIDTH equal to CBW160) or, a Clause 21 (Very High Throughput (VHT) PHY specification)
44 160 MHz non-high throughput (non-HT) duplicate PPDU (TXVECTOR parameter CH_BANDWIDTH
45
46 equal to CBW160), or a Clause 27 (High Efficiency (HE) PHY specification) 160 MHz high efficiency
47 (HE) PPDU with the TXVECTOR parameter CH_BANDWIDTH equal to CBW160, or a Clause 36
48 (Extremely high throughput (EHT) PHY specification) 160 MHz extremely high throughput (EHT) PPDU
49
50 with the TXVECTOR parameter CH_BANDWIDTH equal to CBW160.
51
52 bandwidth signaling transmitter address (TA): A TA that is used by a very high throughput (VHT)
53
54 station (STA), or a high efficiency (HE) STA, (#1081)or an extremely high throughput (EHT) STA to
55 indicate the presence of additional signaling related to the bandwidth to be used in a subsequent transmission
56 in an enhanced distributed channel access (EDCA) transmission opportunity (TXOP). It is the IEEE medium
57
58
access control (MAC) individual address of the transmitting STA but with the Individual/Group bit set to 1.
59
60 (#1081)multi-user (MU) physical layer (PHY) protocol data unit (PPDU): A PPDU that carries one or
61 more PHY service data units (PSDUs) for one or more stations (STAs) using the downlink multi-user multi-
62
ple input, multiple output (DL-MU-MIMO) technique, orthogonal frequency division multiple access (DL
63
64 OFDMA) technique, or a combination of the two techniques, or that carries a PSDU for an AP and is in a
65 high efficiency (HE) MU PPDU format or an extremely high throughput (EHT) MU PPDU format.

48 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#1081)non-high-throughput (non-HT): A modifier meaning not high throughput (HT), not very high
2 throughput (VHT), and not high efficiency (HE), and not extremely high throughput (EHT).
3
4
5 (#1415)(#2744)reported access point (AP): An AP that is describedidentified(#4093) in an element such as
6 a Neighbor Report element or a Reduced Neighbor Report element or Basic Multi-Link element(#6700).
7
8
9 (#1415)(#2744)reporting access point (AP): An AP that is transmitting an element, such as a Neighbor
10 Report element or a Reduced Neighbor Report element or Basic Multi-Link element(#6700), describing a
11 reported AP.
12
13
14
(#1977)service period (SP): A period of time during which one or more downlink individually addressed
15 frames are transmitted to a quality-of-service (QoS) station (STA) and/or one or more (portions of) transmis-
16 sion opportunities (TXOPs) are granted or allocated to the same STA. SPs are either scheduled or unsched-
17 uled.
18
19 NOTE—A (#5499)non-access-pointnon-access point (non-AP) STA can have at most one nongroupcast with retries SP
20 (non-GCR-SP) active at any time.
21
22
wireless network management (WNM) sleep mode: An extended power save mode for (#5499)non-
23
24 access-pointnon-access point (non-AP) stations (STAs) and non-AP multi-link devices (MLDs) whereby a
25 non-AP STA or STAs affiliated with a non-AP MLD need not listen for every delivery traffic indication
26 map (DTIM) Beacon frame and does not perform group temporal key/integrity group temporal key/beacon
27 integrity group temporal key (GTK/IGTK/BIGTK) updates An extended power save mode for (#5499)non-
28
access-pointnon-access point (non-AP) stations (STAs) whereby a non-AP STA need not listen for every
29
30 delivery traffic indication map (DTIM) Beacon frame and does not perform group temporal key/integrity
31 group temporal key/beacon integrity group temporal key (GTK/IGTK/BIGTK) updates.
32
33
34 Insert the following definitions (maintaining alphabetical order):
35
36 (#1081)(#5499)20 MHz-only non-access point (non-AP) extremely high throughput station (EHT
37 STA): A non-AP EHT STA that indicates in the Supported Channel Width Set subfield in the HE PHY
38
39 Capabilities Information field in the HE Capabilities element that it supports only 20 MHz channel width for
40 the frequency band in which it is operating.
41
42 (#1081)(#5499)20 MHz operating non-access point (non-AP) extremely high throughput station (EHT
43
44
STA): A non-AP EHT STA that is operating in 20 MHz channel width mode, such as a 20 MHz-only non-
45 AP EHT STA or an EHT STA that has reduced its operating channel width to 20 MHz using operating mode
46 indication (OMI).
47
48
(#1081)(#5499)80 MHz operating non-access point (non-AP) extremely high throughput station (EHT
49
50 STA): A non-AP EHT STA that is operating in 80 MHz channel width mode, such as a non-AP STA
51 (excluding the 20 MHz-only non-AP EHT STA) which is not capable of 160 MHz operation or a non-AP
52 STA that has reduced its operating channel width to 80 MHz using operating mode indication (OMI).
53
54
55 (#1081)(#5499)160 MHz operating non-access point (non-AP) extremely high throughput station
56 (EHT STA): A non-AP EHT STA that is operating in 160 MHz channel width mode, such as a non-AP
57 STA (excluding the 20 MHz-only non-AP EHT STA) which is not capable of 320 MHz operation or a non-
58 AP STA that has reduced its operating channel width to 160 MHz using operating mode indication (OMI).
59
60
61 (#1081)320 MHz mask physical layer (PHY) protocol data unit (PPDU): One of the following PPDUs:
62
a) A 320 MHz non-high throughput (non-HT) duplicate PPDU (TXVECTOR parameter CH_BAND-
63
64 WIDTH equal to CBW320) transmitted using the 320 MHz transmit spectral mask defined in
65 Clause 36 (Extremely high throughput (EHT) PHY specification).

Copyright © 2022 IEEE. All rights reserved. 49

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 b) A 320 MHz extremely high throughput (EHT) PPDU (TXVECTOR parameter CH_BANDWIDTH
2 equal to CBW160) transmitted using the 320 MHz transmit spectral mask defined in Clause 36
3
(Extremely high throughput (EHT) PHY specification).
4
5
6 (#1081)320 MHz physical layer (PHY) protocol data unit (PPDU): A Clause 36 (Extremely high
7 throughput (EHT) PHY specification) 320 MHz non-high throughput (non-HT) duplicate PPDU (TXVEC-
8 TOR parameter CH_BANDWIDTH equal to CBW320) or a Clause 36 (Extremely high throughput (EHT)
9
PHY specification) 320 MHz extremely high throughput (EHT) PPDU with the TXVECTOR parameter
10
11 CH_BANDWIDTH equal to CBW320.
12
13 access point (AP) multi-link device (MLD): An MLD, where each station (STA) affiliated with the MLD
14 is an AP.
15
16
17 (#1081)downlink (DL) extremely high throughput (EHT) multi-user (MU) physical layer (PHY) pro-
18 tocol data unit (PPDU): An EHT MU PPDU transmitted by an access point (AP). This PPDU carries one
19 or more physical layer (PHY) service data units (PSDUs) for one or more users.
20
21
22
(#1081)extremely high throughput (EHT) basic service set (BSS): A BSS in which the transmitted Bea-
23 con frame includes an EHT Operation element.
24
25 (#4867)(#5500)((#1081)extremely high throughput (EHT) beamformee: An EHT station (STA) that
26 receives an EHT physical layer (PHY) protocol data unit (PPDU) that was transmitted using a beamforming
27
28
steering matrix.
29
30 (#5501)((#1081)extremely high throughput (EHT) beamformer: An EHT station (STA) that transmits an
31 EHT physical layer (PHY) protocol data unit (PPDU) using a beamforming steering matrix.
32
33
34 (#1081)extremely high throughput (EHT) modulation and coding scheme (EHT-MCS): A specification
35 of the EHT physical layer (PHY) parameters that consists of modulation order (BPSK, QPSK, 16-QAM, 64-
36 QAM, 256-QAM, 1024-QAM, 4096-QAM) and forward error correction (FEC) coding rate (1/2, 2/3, 3/4, 5/
37 6) and that is used in an EHT PHY protocol data unit (PPDU).
38
39
40 (#1081)extremely high throughput (EHT) multi-user (MU) physical layer protocol data unit (PPDU):
41 A PPDU transmitted with EHT MU PPDU format.
42
43 (#1081)(#7016)extremely high throughput (EHT) physical layer (PHY) protocol data unit (PPDU): A
44 Clause 36 (Extremely high throughput (EHT) PHY specification) PPDU.
45
46
47 (#1081)extremely high throughput (EHT) trigger based (TB) physical layer (PHY) protocol data unit
48 (PPDU): A PPDU transmitted with EHT TB PPDU format. This PPDU carries a single physical layer ser-
49 vice data unit (PSDU).
50
51
52 multi-link device (MLD): A device that is a logical entity and has more than one affiliated station (STA)
53 and has (#7488)one MAC data service and a single medium access control (MAC) service access point
54 (SAP) to logical link control (LLC).
55
56 (#6178)(#6179)multi-link operation (MLO): Operations between two multi-link devices (MLDs) as
57
58 described in 35.3 (Multi-link operation).
59
60 (#1759)multi-radio non-access point (non-AP) multi-link device (MLD): A non-AP MLD that supports
61 (#6106)reception or transmission of frames on more than one link at a time.
62
63
64 (#7019)multiple resource unit (MRU): A group of subcarriers that consist of multiple RUs of 26-tone RU,
65 52-tone RU, 106-tone RU, 242-tone RU, 484-tone RU, 996-tone RU, and 2996-tone RU.

50 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#1661)(#2455)(#2259)(#6104)(#7874)nonsimultaneous transmit and receive (NSTR) link pair: A pair

2 of links within a multi-link device (an MLD) for which the receiver requirements specified in Clause 36
3
(Extremely high throughput (EHT) PHY specification) are not met on one of the links when a station (STA)
4
5 of the MLD is transmitting on the other link. Each link of such a pair is a member of the NSTR link pair.
6
7 (#1482)NOTE—If an MLD supports transmission on link 1 concurrent with reception on link 2, but cannot support
8 transmission on link 2 concurrent with reception on link 1, this pair of links is NSTR (#6959)for that MLD.
9
10
11 non-access point (non-AP) multi-link device (MLD): An MLD, where each station (STA) affiliated with
12 the MLD is a non-AP STA.
13
14
15 (#1081)non-orthogonal frequency division multiple access (non-OFDMA) extremely high throughput
16 (EHT) physical layer (PHY) protocol data unit (PPDU): An EHT PPDU which consists of a single
17 resource unit (RU) or a single multiple resource unit (MRU) (#5454)that occupies all the nonpunctured
18 20 MHz channels within the PPDU bandwidth.
19
20
21 (#1081)non-orthogonal frequency division multiple access (non-OFDMA) uplink (UL) multi-user
22 multiple input multiple output (MU-MIMO): a transmission where there are no other resource units/mul-
23
24
tiple resource units (RUs/MRUs) scheduled other than the one doing UL MU-MIMO.
25
26 (#6530)non-Trigger-based (non-TB) physical layer (PHY) protocol data unit (PPDU): A PPDU that is
27 not transmitted with high efficiency (HE) TB PPDU or extremely high throughput (EHT) TB PPDU format.
28
29
30 (#1081)orthogonal frequency division multiple access (OFDMA) extremely high throughput (EHT)
31 physical layer (PHY) protocol data unit (PPDU): An EHT PPDU which consists of more than one
32
33
resource unit (RU) or multiple resource unit (MRU). Each of them is allocated to a different station (STA).
34
35 (#1604)primary 160 MHz channel: In a 320 MHz basic service set (BSS), the 160 MHz channel that con-
36 tains the primary 20 MHz channel.
37
38
39 (#1415)(#2744)(#7368)reported station (STA): An access point (AP) or a non-AP STA that is describe-
40 didentified(#4093) in an element such as a Basic Multi-Link element(#6700).
41
42
43 (#1415)(#2744)(#7368)reporting station (STA): An access point (AP) or a non-AP STA that is transmit-
44 ting an element, such as a Basic Multi-Link element(#6700), describing a reported STA.
45
46
47 (#7019)resource unit (RU): A group of 26, 52, 106, 242, 484, 996, 2996, or 4996 subcarriers as an allo-
48 cation of subcarriers for transmission.
49
50
51 (#1607)secondary 160 MHz channel: In a 320 MHz basic service set (BSS), the 160 MHz channel not
52 including the primary 20 MHz channel, which together with the primary 160 MHz channel form the
53 320 MHz channel of the 320 MHz EHT BSS.
54
55
56 (#2487)(#5649)simultaneous authentication of equals (SAE) entity: an entity that is a station (STA) or a
57 multi-link device (MLD) that participates in SAE authentication (see 12.4 (Authentication using a password)).
58
59
60 (#1660)(#1821)(#2116)(#3409)simultaneous transmit and receive (STR) link pair: A pair of links that is
61 not a nonsimultaneous transmit and receive (NSTR) link pair.
62
63
64 (#5499)single radio non-access point (non-AP) multi-link device (MLD): A non-AP MLD that supports
65 operation on more than one link but receives or transmits frames only on one link at a time.

Copyright © 2022 IEEE. All rights reserved. 51

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 3.4 Abbreviations and acronyms

2
3
4 Insert the following acronym definitions (maintaining alphabetical order):
5 AAR AP assistance request(#5652)
6
7 EHT extremely high throughput(#7496)
8 EML enhanced multi-link
9
EMLMR enhanced multi-link multi-radio
10
11 EMLSR enhanced multi-link single radio(#7498)
12 EPCS Emergency Preparedness Communications Service(#5284)
13
14 ML multi-link
15 MLD multi-link device(#8305)
16
MLO multi-link operation
17
18 MRU multiple resource unit
19 NSTR nonsimultaneous transmit and receive
20
21 r-TWT restricted TWT
22 SRS(#5438) single response scheduling
23
STR simultaneous transmit and receive(#5655)(#5656)
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

52 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 4. General description
2
3
4 4.3 Components of the IEEE Std 802.11 architecture
5
6
7 Insert the following new subclause at the end of subclause 4.3.16 (High-efficiency (HE) STA):
8
9 4.3.16a Extremely high throughput (EHT) STA
10
11
12 The IEEE 802.11 EHT STA operates in frequency bands between 1 GHz and 7.250 GHz(#1106).
13
14 (#2234)(#2243)(#2259)In the 5 GHz and 6 GHz bands, the following apply:
15
16 — An EHT STA is also an HE STA
17 — Support for 20 MHz operating channel width is mandatory in an EHT STA
18
19 — Support for 40 MHz and 80 MHz operating channel width is mandatory in an EHT STA that is not a
20 20 MHz-only non-AP EHT STA
21
22
— Support for 160 MHz operating channel width is mandatory in an EHT AP in the 6 GHz band
23 — Support for 160 MHz operating channel width is optional in an EHT STA in the 5 GHz band
24
25 — Support for 160 MHz operating channel width is optional in a non-AP EHT STA in the 6 GHz band
26 — Support for 320 MHz operating channel width is optional in an EHT STA in the 6 GHz band
27
28
29
(#2234)(#2243)(#2259)In the 2.4 GHz band, the following apply:
30 — An EHT STA is also an HE STA
31
32 — Support for 20 MHz operating channel width is mandatory in an EHT STA
33 — Support for 40 MHz operating channel width is optional in an EHT STA
34
35
(#1719)(#2260)(#2560)The main PHY features in an EHT STA that are not present in HE STA, VHT STA
36
37 or HT STA are the following:
38 — Mandatory support for MRU
39
40 — Mandatory support for non-OFDMA preamble puncturing with any pattern needed to support man-
41 datory MRU for non-OFDMA
42
— Mandatory support for non-OFDMA UL MU-MIMO transmission for a non-AP EHT STA
43
44 — Mandatory support for single spatial stream EHT-MCSs 8 and 9 for a non-AP EHT STA that is not a
45 20 MHz-only non-AP EHT STA
46
47 — Mandatory support for single spatial stream EHT-MCS 15 in an RU
48 — Mandatory support for participating in 160 MHz/320 MHz UL/DL OFDMA for an 80 MHz operat-
49 ing non-AP EHT STA
50
51 — Mandatory support for participating in 320 MHz UL/DL OFDMA for a 160 MHz operating non-AP
52 EHT STA
53
54 — Optional support for EHT-MCSs 12 and 13
55 — Optional support for single spatial stream EHT-MCS 14 in 6 GHz band
56
57 — Optional support for single spatial stream EHT-MCS 15 in an MRU
58
59 The main MAC features in an EHT STA that are not present in HE STA or VHT STA or HT STA are the
60 following:
61
62 — Mandatory support for GCMP-256
63 — In an MLD, mandatory support for multi-link discovery procedure
64
65 — In an MLD, mandatory support for multi-link (re)setup procedure

Copyright © 2022 IEEE. All rights reserved. 53

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — In an MLD, mandatory support for multi-link BlockAck procedure

2
3 — In an MLD, mandatory support for link management procedure with default TID-to-link mapping
4 — In an MLD, mandatory support for MLD level sequence number spaces
5
6 — In an MLD, mandatory support for BSS parameter critical update procedure
7 — In an MLD, mandatory support for multi-link power management
8
9 — In an AP MLD, mandatory support for serving a single radio non-AP MLD
10
— In an AP MLD that is not an NSTR mobile AP MLD(#5386), mandatory support for STR operation
11
12 — In an AP MLD, mandatory support for PPDU end time alignment when the AP-MLD is serving
13 (#7555)an NSTR non-AP MLD.
14
15 — In an AP MLD, mandatory support for multi-link group addressed frame delivery
16 — In a non-AP MLD operating on a STR link pair, mandatory support for STR operation
17
18 — In an MLD, optional support for TID-to-link mapping negotiation
19
— In an MLD, optional support for EMLSR mode
20
21 — In an MLD, optional support for EMLMR mode
22
23 — In an MLD, optional support for start time sync PPDUs medium access
24 — In an MLD, optional support for NSTR mobile AP MLD operation(#5386)
25
26 — Optional support for EPCP(#5284) priority access operation
27 — Optional support for BlockAck Bitmap field lengths of 512 and 1024
28
29 — Optional support for r-TWT
30 — Optional support for triggered TXOP sharing procedure
31
32
33 4.3.21 Wireless network management
34
35 4.3.21.2 BSS max idle period management
36
37
38 Change as follows:
39
40 (#1027)(#8222)When association is not for an MLD association (see 11.3.2 (State variables)), BSS max idle
41
42
period management enables an AP to indicate a time period during which the AP does not disassociate a
43 STA due to nonreceipt of frames from the STA (also see 4.3.21.24 (MLD max idle period management) for
44 the case when the association is for an MLD association)(#2561). This supports improved STA power sav-
45 ing and AP resource management.
46
47
48 4.3.21.23 WNM sleep mode
49
50 Change as follows:
51
52
53
WNM sleep mode is an extended power save mode for non-AP STAs in which a non-AP STA or STAs affil-
54 iated with a non-AP MLD need not listen for every DTIM Beacon frame, and need not perform GTK/IGTK/
55 BIGTK updates. (#4128)For non-MLO, WNM sleep mode enables a non-AP STA to signal to an AP that it
56 might sleep for a specified length of time. (#6178)For MLO, WNM sleep mode enables a STA affiliated
57 with the non-AP MLD to signal to an AP affiliated with the AP MLD that all the STAs affiliated with the
58
59
non-AP MLD might sleep for a specified length of time. This enables a non-AP STA or a non-AP MLD to
60 reduce power consumption and remain associated while the non-AP STA(#5781) or the non-AP MLD has
61 no traffic to send to or receive from the AP or AP MLD.
62
63
64
Insert the following new subclause at the end of subclause 4.3.21 (Wireless network manage-
65 ment):

54 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 4.3.21.24 MLD max idle period management

2
3
4 (#1027)(#6179)For MLO, MLD max idle period management service enables an AP MLD to indicate a time
5 period during which the AP MLD does not disassociate a non-AP MLD(#4129)(#2090)(#1108) due to non-
6 receipt of frames from the non-AP MLD on any setup link. This supports improved power saving at the non-
7 AP MLD and resource management at the AP MLD.
8
9
10 4.5 Overview of the services
11
12
13 4.5.3 Connectivity-related services
14
15 4.5.3.1 General
16
17
18 Change the first paragraph as follows:
19
20
21 The primary purpose of a MAC sublayer is to transfer MSDUs between MAC sublayer entities. The
22 information required for the distribution system service to operate is provided by the association services.
23 Before an MSDU can be handled by the distribution system service a STA or an MLD is “associated.”
24
25
26
4.5.3.2 Mobility types
27
28 Change the first paragraph as follows:
29
30
31
The three transition types of significance to this standard that describe the mobility of STAs or
32 MLDs(#7400) within a network are as follows:
33 a) No-transition: In this type, two subclasses that are usually indistinguishable are identified:
34
35 1) Static—no motion.
36
37
2) Local movement—movement within the PHY range of the communicating STAs, i.e.,
38 movement within a basic service area (BSA).
39 b) BSS-transition: This type is defined for a STA or an MLD as follows:
40
41 • aA STA movement from one BSS in one ESS to another BSS within the same ESS.
42 • A non-AP MLD movement from(#6115) one AP MLD in one ESS, where each non-AP STA
43 affiliated with the non-AP MLD being in one BSS and different non-AP STAs affiliated with the
44
45 non-AP MLD being in different BSSs, to (#6115)another AP MLD within the same ESS, where
46 each non-AP STA affiliated with the non-AP MLD being(#6115) in another BSS and different
47 non-AP STAs affiliated with the non-AP MLD being in different BSSs.
48 • A non-AP MLD movement from (#6115)one AP MLD in one ESS, where each non-AP STA
49
50 affiliated with the non-AP MLD being in one BSS and different non-AP STAs affiliated with the
51 non-AP MLD being in different BSSs, to another BSS within(#5575) the same ESS and being a
52 non-AP STA(#6115), where the MLD MAC address of the non-AP MLD is the same as the
53 MAC address of the non-AP STA(#2236).
54
• A non-AP STA movement from one BSS in one ESS to an AP MLD within the same ESS and
55
56 being a non-AP MLD(#6115), where each non-AP STA affiliated with the non-AP MLD be in
57 another BSS, different non-AP STAs affiliated with the non-AP MLD being in different BSSs
58 and the MAC address of the non-AP STA is the same as the MLD MAC address of the non-AP
59 MLD(#2236).
60
61 A fast BSS transition is a BSS transition that establishes the state necessary for data connectivity
62 before the reassociation rather than after the reassociation.
63
64 c) ESS-transition: This type is defined as STA movement from a BSS in one ESS to a BSS in a
65 different ESS. This case is supported only in the sense that the STA might move. Maintenance of

Copyright © 2022 IEEE. All rights reserved. 55

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 upper-layer connections cannot be guaranteed by IEEE Std 802.11; in fact, disruption of service is
2 likely to occur.
3
4
5 Move the following third paragraph as the first paragraph of this subclause:
6
7 (#2235)The different association services support the different categories of mobility.
8
9
10
4.5.3.3 Association
11
12 Change the first three paragraphs as follows:
13
14 To deliver an MSDU within an ESS via the DS, the DS needs to know which AP or AP MLD within the ESS
15
16 to deliver the MSDU, so that the MSDU might ultimately be delivered to the addressed IEEE 802.11 non-
17 AP(#7401) STA or non-AP MLD(#1000). This information is provided to the DS by the concept of
18 association. Association is necessary, but not sufficient, to support BSS-transition mobility. Association is
19 sufficient to support no-transition mobility. Association is one of the services in the DSS.
20
21
22 Before a non-AP(#7401) STA or a non-AP MLD is allowed to senddeliver(#2118) an MSDU via an AP or
23 an AP MLD, respectively, it first becomes associated with the AP or the AP MLD, respectively.
24
25 (#2238)Association between two STAs is called STA association. Association between a non-AP MLD and
26 an AP MLD is called MLD association.
27
28
29 For a non-GLK STA that is not affiliated with an MLD, the act of becoming associated with an AP invokes
30 the association service (STA association), which provides the STA to AP mapping to the DS. For a non-AP
31 MLD, the act of becoming associated with an AP MLD invokes the association service (MLD association,
32 see 11.3 (STA authenticationAuthentication and association(#2277))(#6111)), which provides the non-AP
33
34 MLD to AP MLD mapping to the DS(#6111). How the information provided by the association service is
35 stored and managed within the DS is not specified by this standard.
36
37 Change the fifth paragraph as follows:
38
39
40 Within a robust security network (RSN), association is handled differently. In an RSNA, the IEEE 802.1X
41 Port determines when to allow data traffic across an IEEE 802.11 link between two STAs or multiple IEEE
42 802.11 links between two MLDs(#2263). A single IEEE 802.1X Port maps to one association, and each
43 association maps to an IEEE 802.1X Port. An IEEE 802.1X Port consists of an IEEE 802.1X Controlled Port
44 and an IEEE 802.1X Uncontrolled Port. The IEEE 802.1X Controlled Port is blocked from passing general
45
46 data traffic between two STAs or between two MLDs until an IEEE 802.1X authentication procedure
47 completes successfully over the IEEE 802.1X Uncontrolled Port. Once the AKM completes successfully,
48 data protection is enabled to prevent unauthorized access, and the IEEE 802.1X Controlled Port unblocks to
49 allow protected data traffic. IEEE 802.1X Supplicants and Authenticators exchange protocol information via
50 the IEEE 802.1X Uncontrolled Port. It is expected that most other protocol exchanges use the IEEE 802.1X
51
52 Controlled Ports. However, a given protocol might need to bypass the authorization function and make use
53 of the IEEE 802.1X Uncontrolled Port.
54
55 Change the seventh, eighth, and ninth paragraphs as follows:
56
57
58 (#3006)At any given instant, a non-AP STA is associated with no more than one AP, and a non-AP MLD is
59 associated with no more than one AP MLD. This allows the DS to determine a unique answer to the
60 questions, “Which AP is serving non-AP STA X?” and “Which AP MLD is serving non-AP MLD X?” Once
61 ana non-AP(#4840)(#7401) STA association is completed, a non-AP STA can make full use of a DS (via the
62
AP) to communicate. Similarly, once an MLD association is completed a non-AP MLD can make full use of
63
64 a DS (via the AP MLD) to communicate. STA Aassociation is always initiated by the non-AP STA, not the
65 AP. MLD association is always initiated by the non-AP MLD, not the AP MLD.

56 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 An AP or an AP MLD might be associated with many non-AP(#7401) STAs or non-AP MLDs, respectively,
2 at the same time.
3
4
5 A non-AP(#7401) STA or a non-AP MLD learns what APs or AP MLDs, respectively, are present and what
6 operational capabilities are available from each of those APs or AP MLDs and APs affiliated with each AP
7 MLD(#2900), respectively, and then invokes the association service to establish an STA or an MLD associ-
8
ation, respectively. A FILS STA is able to discover, authenticate and associate with the AP with a reduced
9
10 number of frame transmissions. For details of how a STA learns about what APs are present, see 11.1.4
11 (Acquiring synchronization, scanning).
12
13
4.5.3.4 Reassociation
14
15
16 Change the first paragraph as follows:
17
18
19 Association is sufficient for no-transition MSDU delivery between IEEE 802.11 STAs or MLDs. Additional
20 functionality is needed to support BSS-transition mobility. The additional required functionality is provided
21 by the reassociation service. Reassociation is one of the services in the DSS.
22
23
24 Change and split the second paragraph as follows:
25
26 (#1762)(#2091)(#3415)The reassociation service (see 11.3.6 (Association, reassociation, and
27
disassociation)) is invoked to “move”:
28
29 — a current STA association (see 4.5.3.3 (Association) and 11.3 (STA authenticationAuthentication
30 and association(#2277))(#7505)) of a non-AP STA from one AP to the same AP or another AP.
31
32 — or a current MLD association (see 4.5.3.3 (Association) and 11.3 (STA authenticationAuthentication
33 and association(#2277))(#7505)) of a non-AP MLD from one AP MLD to the same AP MLD or
34
another AP MLD
35
36 — or a current STA association of a non-AP STA with an AP to an MLD association of a non-AP MLD
37 with an AP MLD, where the MAC address of the non-AP STA is the same as the MLD MAC
38
39 address of the non-AP MLD
40 — or a current MLD association of a non-AP MLD with an AP MLD to a STA association of a non-AP
41
STA with an AP, where the MLD MAC address of the non-AP MLD is the same as the MAC
42
43 address of the non-AP STA.
44
45 In an ESS with a DS, the reassociation service informs the DS of the current mapping between AP and non-
46
AP(#7401) STA or between AP MLD and non-AP MLD as the STA moves from BSS to BSS within the
47
48 ESS. For a general link in an IEEE 802.1Q network, the reassociation service informs higher layer services
49 how the link is reconfigured, commonly, with which BSS the GLK non-AP STA is a member of. The higher
50 layer services will then destroy, disable, or maintain the existing Internal Sublayer Service SAPs, create or
51 enable new Internal Sublayer Service SAPs, inform the GLK convergence function of the reconfigured
52
general link mapping of the Internal Sublayer Service SAPs, and inform the network routing protocol of the
53
54 updated general link. The GLK AP and GLK non-AP STA each then establish or maintain a
55 service_access_point_identifier for the reconfigured general link, for their respective MS SAPs.
56 Reassociation also enables changing association attributes of an established association while the non-AP
57 STA or non-AP MLD remains associated with the same AP or the same AP MLD, respectively.
58
Reassociation is always initiated by the non-AP STA or the non-AP MLD.
59
60
61 Change the last paragraph as follows:
62
63
64 Only the fast BSS transition facility can move an RSNA during reassociation. Therefore, if FT is not used,
65 the old RSNA is deleted and a new RSNA is constructed.

Copyright © 2022 IEEE. All rights reserved. 57

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 4.5.3.5 Disassociation
2
3
4 Change the second paragraph as follows:
5
6 For a non-GLK STA that is not affiliated with an MLD, the act of becoming disassociated invokes the
7 disassociation service, which voids any existing non-AP(#7401) STA to AP mapping known to the DS, for
8
9 the disassociating non-AP(#7401) STA. For a non-AP MLD, the act of becoming disassociated invokes the
10 disassociation service, which voids any existing non-AP MLD to AP MLD mapping known to the DS, for
11 the disassociating non-AP MLD (see 35.3.5.3 (Multi-link tear down procedure)).
12
13 Change the fourth, fifth, and sixth paragraphs as follows:
14
15
16 The disassociation service can be invoked by either party in ana STA(#4840) association (non-AP STA or
17 AP, see 4.5.3.3 (Association)) or an MLD(#4840) association (non-AP MLD or AP MLD). Disassociation is
18 a notification, not a request. Disassociation cannot be refused by the receiving STA or the receiving MLD
19
except when management frame protection is negotiated and the message integrity check fails.
20
21
22 An AP or an AP MLD can disassociate non-AP(#7401) STAs or non-AP MLDs, respectively, to enable the
23 AP or the AP MLD to be removed from a network for service or for other reasons.
24
25
26 STAs or MLDs attempt to disassociate when they leave a network. However, the MAC protocol does not
27 depend on STAs or MLDs invoking the disassociation service. (MAC management is designed to
28 accommodate loss of communication with an associated STA or an associated MLD.)
29
30
31 Insert the following new subclause at the end of subclause 4.5 (Overview of the services):
32
33 4.5.13 EPCS priority access(#5284)
34
35
36
Existing national security and emergency preparedness communication services1 in multiple countries pro-
37 vide priority for voice and data exchanges on public networks. (#5284)EPCS priority access is intended to
38 provide capabilities to support such priority services on IEEE 802.11-based networks2.
39
40 (#5284)EPCS priority access provides prioritized access to system resources for authorized devices(#6480)
41
42 to increase their probability of successful communication during periods of network congestion.
43 (#1722)(#1820)Priority access involves treating the EPCS traffic with a higher priority, as described in
44 35.17.3 (EPCS priority access procedure(#5284)) in obtaining channel access and in allocation of network
45 resources. The service is only available to designated, authorized devices who normally represent a small
46 fraction of the overall number of devices operating in the area.
47
48
49 (#5284)(#1110)(#2264)(#1721)AP MLDs that have EPCS priority access activated advertise this capability
50 in Beacon and Probe Response frames. AP MLDs authorize non-AP MLDs to use EPCS priority access
51 based on locally available information or through a service provider’s authorization infrastructure via an
52 SSPN interface (see 11.22.5 (Interworking procedures: interaction with SSPN))(#4132). The AP MLD
53
54 might cache authorization information locally to enable subsequent verification and use it to confirm author-
55 ity during (re)association(#7522).
56
57 (#2265)(#1721)(#5284)An AP MLD or a non-AP MLD invokes EPCS priority access on-demand when
58
instructed to do so by a higher layer function, such as an authorized user or a managed service provider that
59
60
1
61 For example, EPCP services in the United States is called National Security and Emergency Preparedness (NS/EP) service that
62 includes the Government Emergency Telecommunications Service and the Wireless Priority Services and run on commercial cellular
63 networks(#5285).
2
64 Priority access capabilities to support these services in other types of networks are defined in appropriate international standards, (e.g.,
65 Multimedia Priority Service (MPS) in 3GPP).

58 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 detects the need for priority. The process for detecting the need for EPCS priority access by the higher layer
2 function is outside the scope of this standard.
3
4
5 (#1721)(#2266)(#5284)Non-AP MLDs enable EPCS priority access by sending an EPCS Priority Access
6 Enable Request frame (see 9.6.35.5 (EPCS Priority Access Enable Request frame for-
7 mat(#5284)(#1119)(#1488)))(#4132)(#7519) to an associated AP MLD that advertises the capability. A
8 non-AP MLD can send the request on any available enabled link between the non-AP MLD and the AP
9
MLD. If the non-AP MLD is authorized, EPCS priority access will be enabled on all enabled links within
10
11 the MLD. The AP MLD authorizes the non-AP MLD using locally stored verification information or infor-
12 mation received from an EPCS service provider via the SSPN interface (see 11.22.5 (Interworking proce-
13 dures: interaction with SSPN)) and sends an EPCS Priority Access Enable Response frame (see 9.6.35.6
14 (EPCS Priority Access Enable Response frame format(#5284)(#1119)(#1488)))(#4132)(#7520) to the non-
15
AP MLD. Alternatively, the AP MLD can enable EPCS priority access by sending an unsolicited EPCS Pri-
16
17 ority Access Enable Request frame (see 9.6.35.5 (EPCS Priority Access Enable Request frame for-
18 mat(#5284)(#1119)(#1488)))(#4132)(#7521) to a non-AP MLD and the non-AP MLD confirms the request
19 by sending an EPCS Priority Access Enable Response frame(#7520). An AP MLD can send the request on
20 any available enabled link between the AP MLD and non-AP MLD and EPCS priority access will be
21
enabled on all links within the MLD.
22
23
24 (#1112)(#1721)(#2266)(#5284)While the EPCS priority access is enabled, all traffic to and from the non-AP
25 MLD is treated with a higher priority, as described in 35.17.3 (EPCS priority access procedure(#5284)).
26 EPCS priority access is applied individually for each link within an MLD. Either the AP MLD or the non-
27
AP MLD can tear down EPCS priority access by transmitting an EPCS Priority Access Teardown frame (see
28
29 9.6.35.7 (EPCS Priority Access Teardown frame details(#5284)(#1127)))(#4132)(#4133).
30
31 Insert the following new subclause at the end of subclause 4.9 (Reference model):
32
33
34 4.9 Reference model
35
36
37 4.9.5 Reference model for multi-link operation (MLO)(#2239)(#2720)(#3410)(#3417)
38
39 MLO allows operation over multiple links. The reference model of an MLD (see 35.3 (Multi-link
40 operation)) is shown in Figure 4-30a (Reference model for an MLD for two links).
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 59

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 NOTE—For simplicity, Figure 4-30a (Reference model for an MLD for two links) depicts the reference model when
2 there are two links, while in general, an MLD can support more than two links.
3
4
5 IEEE 802.1X
6
7
8 SME
9 IEEE 802.1X
10 Authenticator
or Supplicant
11
12 RSNA Key
Management
13 MAC SAP

14 MLD Upper MAC Sublayer

MAC Sublayer MAC Sublayer
15 MLD Lower MAC MLD Lower MAC

MLME SAP
Management Entity
MLME SAP

Management Entity
16 Sublayer Sublayer
17 MLME-PLME SAP PHY SAP PHY SAP MLME-PLME SAP
18
19
20 PHY Management PHY Management

PLME SAP
PLME SAP

PHY PHY
Entity Entity
21
22
23
24 Link 2
Link 1
25 (i.e., an AP1 affiliated with an AP MLD or (i.e., an AP2 affiliated with an AP MLD or
26 A STA1 affiliated with a non-AP MLD (e.g., in 2.4 GHz)) A STA2 affiliated with a non-AP MLD (e.g., in 5 GHz))
27
28 Figure 4-30a—Reference model for an MLD for two links
29
30
31
32 An MLD manages communication over multiple links. Communication across different frequency bands/
33 channels can occur simultaneously or not depending on the capabilities of both the AP MLD and the non-AP
34 MLD (see 35.3.16.3 (Simultaneous transmit and receive (STR) operation) and 35.3.16.4 (Nonsimultaneous
35 transmit and receive (NSTR) operation)).
36
37 NOTE—The SME boundary top is left open in Figure 4-30a (Reference model for an MLD for two links) to indicate
38 that the SME can contain other functions that are not defined by this standard.
39
40
41 An MLD supports multiple MAC sublayers, coordinated by an SME.
42
43 The SME maintains the authentication and association states. The Authenticator and the MAC-SAP of the
44 AP MLD are identified by the same AP MLD MAC address. The Supplicant and the MAC-SAP of the non-
45 AP MLD are identified by the same non-AP MLD MAC address.
46
47
48 The MLO procedures (see 35.3 (Multi-link operation)) allow a pair of MLDs to discover, synchronize,
49 (de)authenticate, (re)associate, disassociate, and manage resources with each other on any common bands or
50 channels that are supported by both MLDs.
51
52
53 As described in 35.3.1 (General), each AP MLD has a single MAC-SAP and each non-AP MLD has a single
54 MAC-SAP. Each AP affiliated with an AP MLD has a different MAC address within the MLD and each
55 STA affiliated with a non-AP MLD has a different MAC address within the MLD.
56
57
58 The SME is responsible for coordinating each of the MLMEs of all affiliated STAs to maintain a single
59 RSNA key management entity, as well as a single IEEE 802.1X Authenticator or Supplicant for MLO.
60
61 An example of an AP MLD with two links (Link 1 and Link 2) is shown in Figure 4-30b (Example MLD
62
and the affiliated STA communication system). An AP MLD with MLD MAC address M and two affiliated
63
64 APs (AP1 with MAC address w and AP2 with MAC address x) associated with a non-AP MLD with MLD
65 MAC address P and two affiliated STAs (STA1 with MAC address y and STA2 with MAC address z).

60 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Link 1 is established between AP1 and STA1 and link 2 is established between AP2 and STA2. In general,
2 the MAC address of an MLD and the MAC address of the STAs affiliated with the MLD are all different
3
(e.g., M, P, w, x, y, and z have different values).
4
5
6 DS
7
8
9
10 AP MLD MAC‐SAP
11 MLD MAC addr=M MLD
Upper
12 MAC
13 sublayer
14
15
16 MLD
17 AP1 AP2 Lower
MAC
18 MAC addr=w MAC addr=x sublayer
19
20 Link 1 Link 2
21
22
MLD
23 STA1 STA2 Lower
24 MAC addr=y MAC addr=z MAC
25 sublayer
26
27 Non‐AP MLD
MLD MAC addr=P
28 MLD
Upper
29 MAC
30 sublayer
31
32 MAC‐SAP
33
34
35 Figure 4-30b—Example MLD and the affiliated STA communication system
36
37
38 The MAC Sublayer is further divided into an MLD Upper MAC sublayer and an MLD Lower MAC sub-
39
layer. The MLD Upper MAC sublayer (MLD) performs functionalities that are common across all links and
40
41 the MLD Lower MAC sublayer (AP or STA affiliated with the MLD) performs functionalities that are local
42 to each link. Some of the functionalities require joint processing of both the MLD Upper and the MLD
43 Lower MAC sublayers.
44
45
46 The MLD Upper MAC sublayer functions include:
47 — Authentication, association, and reassociation (between an AP MLD and a non-AP MLD)
48
49 — Security association (e.g., PMKSA, PTKSA) and distribution of GTK/IGTK/BIGTK
50
51
— SN/PN assignment for frames to be encrypted by PTK for unicast frames
52 — Encryption/decryption using PTK for unicast frames
53
54 — Selection of the MLD Lower MAC sublayer for transmission (TID-to-link mapping (see 35.3.7.1
55 (TID-to-link mapping)))
56
57 — Reordering of packets to ensure in-order delivery per each Block Ack session
58 — Block Ack scoreboarding for individually addressed frames (in collaboration with the MLD Lower
59
MAC sublayer). Optionally, the MLD Upper MAC sublayer delivers the Block Ack record on one
60
61 link to the MLD Lower MAC sublayer of other links
62 — MLD level management information exchange/indication via the MLD Lower MAC sublayer
63
64
65 The MLD Lower MAC sublayer functions include:

Copyright © 2022 IEEE. All rights reserved. 61

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — Maintenance of link specific GTK/IGTK/BIGTK (between an AP affiliated with the AP MLD and a
2 STA affiliated with the non-AP MLD)
3
4 — Link-specific encryption/decryption/integrity protection and PN assignment using GTK/IGTK/
5 BIGTK (between an AP affiliated with the AP MLD and a STA affiliated with the non-AP MLD)
6
— Link specific management information exchange/indication (e.g., beacon)
7
8 — Link specific control information exchange/indication (e.g., RTS/CTS, acknowledgements, NDP,
9 etc.)
10
11 — Power save state and mode
12 — MAC address filtering for frame reception
13
14 — Block Ack scoreboarding for individually addressed frames (in collaboration with the MLD Upper
15 MAC sublayer). Optionally, the MLD Lower MAC sublayer receives from the Block Ack record on
16 the other links from the MLD Upper MAC sublayer
17
18 NOTE 1—The above functionality partitioning is meant for modeling the functionalities of each MAC sublayer and is
19 not meant for describing the MAC sublayer for which the actual implementation of each function should reside.
20 NOTE 2—The Block Ack scoreboarding maintenance collaborated between the MLD Upper MAC sublayer and MLD
21 Lower MAC sublayer is implementation dependent.
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

62 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 5. MAC service definition

2
3
4 5.1 Overview of MAC services
5
6
7 5.1.5 MAC data service architecture
8
9 5.1.5.1 General
10
11 Insert the following paragraphs at the end of this subclause:
12
13
14 For MLO, one or more links are used for communication between the AP MLD and non-AP MLD after
15 MLD (re)setup as described in 35.3.5 (Multi-link (re)setup). The MAC data plane architecture with n links
16 (i.e., processes that involve transport of all or part of an MSDU) is shown in Figure 5-2a (MAC data plane
17 architecture (MLO) for unicast data frames(#2239))).
18
19
20 During transmission, an MSDU from the MAC SAP goes through the processes shown in the left hand side
21 of Figure 5-2a (MAC data plane architecture (MLO) for unicast data frames(#2239)), then through the TID-
22 to-link mapping process (see 35.3.7.1 (TID-to-link mapping)) that forwards the MPDUs down to one of the
23 MLD Lower MAC sublayers and then to the corresponding PHY SAP.
24
25
26 NOTE 1—TID-to-link mapping negotiation is an optional feature.
27
28 During reception, MPDUs originating from different PHY SAPs first go through an MLD Lower MAC
29 sublayer, followed by a merging process, and then go through the process in the right-hand side of Figure 5-
30
31 2a (MAC data plane architecture (MLO) for unicast data frames(#2239)). Then, one or more MSDUs are
32 delivered to the MAC SAP or, via the DSAF to the DS. The IEEE 802.1X Controlled/Uncontrolled Ports
33 discard any received MSDUs if the Controlled Port is not enabled and if the MSDU does not represent an
34 IEEE 802.1X frame.
35
36
37 NOTE 2—Many of the processes shown in Figure 5-2a (MAC data plane architecture (MLO) for unicast data
38 frames(#2239)) also apply to MLD-level MMPDU flows for the MAC control plane architecture, and the processes
39 shown at the MLD Lower MAC sublayer also apply to Control and Extension frames.
40
41 When MLO is being used, the same security association (PTKSA) is used to encrypt the unicast MPDUs and
42 MMPDUs prior to transmission on the links. The same security association (PTKSA) is used to decrypt the
43 unicast MPDUs and MMPDUs received on the links. The GTK of a link is used to encrypt the group
44
45 addressed frames MPDUs and MMPDUs prior to transmission on the link. The GTK of a link is used to
46 decrypt the group addressed frames MPDUs and MMPDUs received on the link.
47
48 When MLO is being used, the “Block Ack Scoreboarding” block in the MLD Upper MAC sublayer
49 manages the Block Ack status of the MPDUs (of this Block Ack session) that are received on any setup link.
50
51 The “Block Ack Scoreboarding” block in the MLD Lower MAC sublayer manages the Block Ackstatus of
52 the MPDUs (of this Block Ack session) that are received on this link. It may convey Block Ack status of the
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 63

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 MPDUs received on another link if it obtained such info from the other link via the MLD Upper MAC
2 sublayer..
3
4
5 Local Higher
6 802.1X PAE Layer Upper
7 Entities Layers
8
9
LPD/EPD LLC
10 LPD/EPD
sublayer
11 ()
()
12
802.1AC 802.1AC
13 convergence convergence
14 function function
15 () ()

16 802.11
17 For AP role specific behavior
this connection is not present
18
19
20 Role‐specific
21 behavior Legend:
(M) – MAC SAP
22 (U) – Uncontrolled port
23 (C) - Controlled port

24
25 (U ) (C )

26 IEEE 802.1X
Controlled and Uncontrolled Port
27 Filtering (optional)
28 (M)
29 RX/TX MSDU MLD Upper MAC Sublayer:
30 Rate Limiting Common
31 Functionalities
32 A-MSDU
Aggregation (TX) / De-aggregation (RX)
33
34 Replay Detection
PS defer queueing
35 (AP MLD only) Per PN (optional)
MSDU Flow - Transmitting

36 Block Ack
MSDU Flow – Receiving

37 Buffering and
Sequence Number
Reordering per SN
38 Assignment
MPDU Decryption
39
Packet Number
40 Assignment
Duplicate
41 Detection per SN
42 MPDU Encryption Block Ack
43 Scoreboarding
44 TID-to-Link mapping (TX) / Merging (RX)
45
46
47
48
49
50 MLD Lower MAC
51 Null(TX)/Block Ack Scoreboarding (RX) Null(TX)/Block Ack Scoreboarding (RX) Sublayer:
52 Per‐link
Null (TX)/ Address 1 address filtering Null (TX)/ Address 1 address filtering
Functionalities
53 (RX) (RX)
54
55 MPDU Header + CRC …. MPDU Header + CRC
Creation (TX) / Validation (RX)
Creation (TX) / Validation (RX)
56
57 A-MPDU A-MPDU
Aggregation (TX) / De-aggregation (RX) Aggregation (TX) / De-aggregation (RX)
58
59
60 PHY of Link 1 PHY of Link n
61
62 Figure 5-2a—MAC data plane architecture (MLO) for unicast data frames(#2239)
63
64
65

64 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Insert the following new subclauses at the end of subclause 5.1.5 (MAC data service
2 architecture):
3
4
5 5.1.5.10 Non-AP MLD role(#2239)
6
7 The MAC data plane architecture of a non-AP MLD as shown in Figure 5-2a (MAC data plane architecture
8 (MLO) for unicast data frames(#2239)) is completed by replacing the role-specific behavior block with that
9
10 shown in Figure 5-11 (Role-specific behavior block for a non-AP MLD(#2239)). The function of this block
11 in a non-AP MLD is to perform destination address filtering as described in 10.2.7 (MAC data service).
12
13
NOTE—In implementations, the DA address filtering function may be done “lower in the stack.” It is shown in the role-
14
specific behavior block location for simplicity, and any implementation choice needs to provide equivalent behavior.
15
16
17
18 DA address
19 filtering

20
21
22
23
24 Figure 5-11—Role-specific behavior block for a non-AP MLD(#2239)
25
26
27 5.1.5.11 AP MLD role(#2239)
28
29
30 In an AP MLD, the MAC data plane architecture as shown in Figure 5-2a (MAC data plane architecture
31 (MLO) for unicast data frames(#2239)) includes Distribution System (DS) access in its role-specific
32 behavior block, as shown in Figure 5-12 (Role-specific behavior block for a AP MLD(#2239)). This block
33 provides access to the DS for associated non-AP MLDs as described in 4.5.2.1 (Distribution).
34
35
36 NOTE—This behavior block indicates that there is no access through the controlled port to or from the local upper lay-
37 ers (e.g., the LLC sublayer) at an AP MLD. Any such access is logically achieved in the architecture via transition of the
38 DS and Portal to an integrated LAN. In actual implementations, this is likely to be optimized, and Data frames appear to
39 be delivered directly to one or more local LLC sublayer entities on the same physical device as the AP MLD. Such opti-
40 mization is effectively distributing the functions of the DS and Portal, and it is the responsibility of the implementation
41 to ensure the logical behavior of these entities is maintained.
42
43
44 Other APs/Mesh Gates/
45 Portal in the ESS
46 DSAF
47
48
49
50 Distribution
(C) (DS SAP) *
51 System (DS)
52
53
54
55
56
57 * - DSS may conceptually
58 be provided by the
59 “recursive” use of a
60 network stack
61
62 Figure 5-12—Role-specific behavior block for a AP MLD(#2239)
63
64
65

Copyright © 2022 IEEE. All rights reserved. 65

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

66 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 6. Layer management
2
3
4
5 6.3 MLME SAP interface
6
7 6.3.3 Scan
8
9
10 6.3.3.2 MLME-SCAN.request(#1004)(#2246)
11
12
13
6.3.3.2.2 Semantics of the service primitive
14
15 Change the primitive parameters as follows (not all existing parameters are shown):
16
17
18 The primitive parameters are as follows:
19 MLME-SCAN.request(
20
21 …,
22 EHTCapabilities,
23
24
VendorSpecificInfo
25 )
26
27
28 Name Type Valid range Description
29 EHTCapabilities As defined in EHT As defined in 9.4.2.313 Specifies the parameters in the
30 Capabilities (EHT Capabilities EHT Capabilities element that are sup-
31 element element(#4819)) ported by the STA. The parameter is pres-
32 ent if dot11EHTOptionImplemented is
33 true; otherwise not present.
34 VendorSpecificInfo A set of elements As defined in 9.4.2.25 Zero or more elements.
35 (Vendor Specific ele-
36 ment)
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 67

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 6.3.3.3 MLME-SCAN.confirm(#1004)(#2246)
2
3
4 6.3.3.3.2 Semantics of the service primitive
5
6 Insert the following rows to the untitled IBSS adoption table as follows:
7
8
9 Name Type Valid range Description IBSS adoption
10 EHT Capabilities As defined in As defined in The value from the EHT Capa- Do not adopt
11 EHT 9.4.2.313 (EHT bilities element. The parame-
12 Capabilities Capabilities ter is present if
13 element element(#4819)) dot11EHTOptionImplemented
14 is true and an EHT Capabilities
15 element was present in the
16 Probe Response or Beacon
17 frame from which the BSSDe-
18 scription was determined. Oth-
19 erwise, the parameter is not
20 present.
21
22 EHT Operation As defined in As defined in The value from the EHT Oper- Adopt
23 frame format 9.4.2.311 (EHT ation element. The parameter is
24 Operation element) present if dot11EHTOptionIm-
25 plemented is true and an EHT
26 Operation element was present
27 in the Probe Response or Bea-
28 con frame from which the
29 BSSDescriptionSet was deter-
30 mined. Otherwise, the parame-
31 ter is not present.
32
33 6.3.4 Synchronization
34
35
36 6.3.4.2 MLME-JOIN.request(#1004)(#2246)
37
38
39 6.3.4.2.2 Semantics of the service primitive
40
41 Change the primitive parameters as follows (not all existing parameters are shown):
42
43
44 The primitive parameters are as follows:
45 MLME-JOIN.request(
46
47 …,
48 EHTCapabilities,
49
50
(#6165)MultiLink,
51 VendorSpecificInfo
52 )
53
54
55 Name Type Valid range Description
56
EHTCapabilities As defined in EHT As defined in Specifies the parameters in the
57
Capabilities element 9.4.2.313 (EHT EHT Capabilities element that are sup-
58
Capabilities ported by the STA. The parameter is pres-
59
element(#4819)) ent if dot11EHTOptionImplemented is
60
true; otherwise not present.
61
62 (#6165)MultiLink Basic Multi-Link As defined in Indicates the Multi-Link parameters of
63 element 9.4.2.312 (Multi- the MLD. This parameter is present if
64 Link element) dot11MultiLinkActivated is true and is
65 absent otherwise.

68 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
Name Type Valid range Description
2
3 VendorSpecificInfo A set of elements As defined in Zero or more elements.
4 9.4.2.25 (Vendor
5 Specific element)
6
7 6.3.5 Authenticate
8
9
10 6.3.5.1 Introduction
11
12 Insert the following paragraph after the first paragraph (“This mechanism supports ...”):
13
14
15
In 6.3.5 (Authenticate), the reference of a “STA” means the “STA” that is not affiliated with an MLD unless
16 specified otherwise, and the reference of an “AP” means the AP that is not affiliated with an MLD unless
17 specified otherwise. When referring to MLD management, the “SME” is the entity that manages the MLD.
18 The peer MAC entity can be (#5581)within a STA that is not affiliated with an MLD or an MLD depending
19 on the context. The PeerSTAAddress can be the MAC address of (#5582)a STA that is not affiliated with an
20
21
MLD or an MLD MAC address depending on the context.
22
23 6.3.5.2 MLME-AUTHENTICATE.request
24
25 6.3.5.2.2 Semantics of the service primitive
26
27
28 Change the primitive parameters as follows (not all existing parameters are shown):
29
30 The primitive parameters are as follows:
31 MLME-AUTHENTICATE.request(
32
33 ...
34 MultiLink,
35 VendorSpecificInfo
36 )
37
38
39 Name Type Valid range Description
40 MultiLink Basic Multi- As defined in 9.4.2.312 Indicates the Multi-Link parameters of
41 Link (Multi-Link element) the (#7759)local MLD. This parameter
42 element(#6700) is present if dot11MultiLinkActivated
43 is true and is absent otherwise.
44
45 VendorSpecificInfo A set of As defined in Zero or more elements.
46 elements 9.4.2.25 (Vendor Specific
47 element)
48
49 6.3.5.2.3 When generated
50
51
52 Change the first paragraph as follows:
53
54 This primitive is generated by the SME for a STA to establish authentication with a specified peer MAC
55 entity in order to permit Class 2 frames, or mesh peering Management frames for AMPE utilizing SAE
56 authentication, to be exchanged between the two STAs; or for a MLD to establish authentication with a
57
58 specified peer MAC entity in order to permit Class 2 frames to be exchanged between the two MLDs.
59 During the authentication procedure, the SME might generate additional MLME-AUTHENTICATE.request
60 primitives.
61
62
6.3.5.2.4 Effect of receipt
63
64
65 Change the first paragraph as follows:

Copyright © 2022 IEEE. All rights reserved. 69

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 This primitive initiates an authentication procedure. In the case that a response is received from the
2 responder STA or MLD, the MLME subsequently issues an MLME-AUTHENTICATE.confirm primitive
3
that reflects the results.
4
5
6 6.3.5.3 MLME-AUTHENTICATE.confirm
7
8 6.3.5.3.2 Semantics of the service primitive
9
10
11 Change the primitive parameters as follows (not all existing parameters are shown):
12
13 The primitive parameters are as follows:
14
MLME-AUTHENTICATE.confirm(
15
16 ...
17 MultiLink,
18 VendorSpecificInfo
19 )
20
21
22 Name Type Valid range Description
23
MultiLink Basic Multi- As defined in 9.4.2.312 Indicates the Multi-Link parameters of
24
Link (Multi-Link element) the (#7760)peer MLD. This parameter is
25
element(#6700) present if dot11MultiLinkActivated is
26
true and is absent otherwise.
27
28 VendorSpecificInfo A set of As defined in Zero or more elements.
29 elements 9.4.2.25 (Vendor Specific
30 element)
31
32 6.3.5.4 MLME-AUTHENTICATE.indication
33
34
35 6.3.5.4.1 Function
36
37 Change the first paragraph as follows:
38
39
40 This primitive indicates receipt of a request from a specific peer MAC entity to establish an authentication
41 relationship with the STA or MLD processing this primitive.
42
43 6.3.5.4.2 Semantics of the service primitive
44
45
46 Change the primitive parameters as follows (not all existing parameters are shown):
47
48 The primitive parameters are as follows:
49 MLME-AUTHENTICATE.indication(
50
51 ...
52 MultiLink,
53 VendorSpecificInfo
54 )
55
56
57 Name Type Valid range Description
58
MultiLink Basic Multi-Link As defined in 9.4.2.312 Indicates the Multi-Link parameters of
59
element(#6700) (Multi-Link element) the (#7761)peer MLD. This parameter
60
is present if dot11MultiLinkActivated
61
is true and is absent otherwise.
62
63 VendorSpecificInfo A set of elements As defined in Zero or more elements.
64 9.4.2.25 (Vendor Specific
65 element)

70 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 6.3.5.5 MLME-AUTHENTICATE.response
2
3
4 6.3.5.5.1 Function
5
6
7
Change the first paragraph as follows:
8
9 This primitive is used to send a response to a specific peer MAC entity that requested authentication with the
10
STA, or MLD that issued this primitive.
11
12
13 6.3.5.5.2 Semantics of the service primitive
14
15
16 Change the primitive parameters as follows (not all existing parameters are shown):
17
18
19 The primitive parameters are as follows:
20 MLME-AUTHENTICATE.response(
21
22 ...
23 MultiLink,
24 VendorSpecificInfo
25 )
26
27
28 Name Type Valid range Description
29
MultiLink Basic Multi-Link As defined in Indicates the Multi-Link parameters of
30
element(#6700) 9.4.2.312 (Multi- the (#7762)local MLD. This parameter is
31
Link element) present if dot11MultiLinkActivated is
32
true and is absent otherwise.
33
34 VendorSpecificInfo A set of elements As defined in Zero or more elements.
35 9.4.2.25 (Vendor
36 Specific element)
37
38
39 6.3.5.5.3 When generated
40
41 Change the first paragraph as follows:
42
43
44 This primitive is generated by the SME of a STA or MLD as a response to an MLME-
45 AUTHENTICATE.indication primitive.
46
47
48 6.3.6 Deauthenticate
49
50
51 6.3.6.2 MLME-DEAUTHENTICATE.request
52
53 6.3.6.2.3 When generated
54
55
56 Change the first paragraph as follows:
57
58
59 This primitive is generated by the SME for a STA to invalidate authentication with a specified peer MAC
60 entity in order to prevent the exchange of Class 2 frames, or mesh peering Management frames for AMPE
61 utilizing SAE authentication, between the two STAs; or for a MLD to invalidate authentication with a spec-
62
ified peer MAC entity in order to prevent the exchange of Class 2 frames between the two MLDs. During
63
64 the deauthentication procedure, the SME might generate additional MLME-DEAUTHENTICATE.request
65 primitives.

Copyright © 2022 IEEE. All rights reserved. 71

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 6.3.7 Associate
2
3
6.3.7.1 Introduction
4
5
6 Insert the following paragraph as the first paragraph of the subclause:
7
8 In 6.3.7 (Associate), the reference of a “STA” means the “STA” that is not affiliated with an MLD unless
9
specified otherwise, and the reference of an “AP” means the AP that is not affiliated with an MLD unless
10
11 specified otherwise. When referring to MLD management, the “SME” is the entity that manages the MLD.
12 The peer MAC entity can be (#5581)within a STA that is not affiliated with an MLD or an MLD depending
13 on the context. The PeerSTAAddress can be the MAC address of (#5582)a STA that is not affiliated with an
14 MLD or an MLD MAC address depending on the context.
15
16
17 Change the now-shifted second paragraph as follows:
18
19 The following primitives describe how a STA becomes associated with an AP and how a non-AP MLD
20 becomes associated with an AP MLD.
21
22
23 6.3.7.2 MLME-ASSOCIATE.request
24
25 6.3.7.2.1 Function
26
27
28
Change the first paragraph as follows:
29
30 This primitive requests association with a specified peer MAC entity that is within an AP or an AP MLD.
31
32 6.3.7.2.2 Semantics of the service primitive
33
34
35 Change the primitive parameters as follows (not all existing parameters are shown):
36
37 The primitive parameters are as follows:
38 MLME-ASSOCIATE.request(
39
...
40
41 EHTCapabilities,
42 MultiLink,
43 (#4134)TID-To-Link Mapping,
44 VendorSpecificInfo
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

72 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 )
2
3
Name Type Valid range Description
4
5 ...
6 ListenInterval Integer 0 Specifies how often the STA awakens and
7 listens for the next Beacon frame, if it
8 enters power save mode when an
9 association is not (#6109)an MLD
10 association (see 11.3 (STA
11 authenticationAuthentication and
12 association(#2277)))(#8222).
13
14 Specifies how often at least (#5583)one
15 STA affiliated with the MLD awakens
16 and listens for the next Beacon frame, if
17 all STAs affiliated with the MLD enter
18 power save mode when an association is
19 (#6109)an MLD association (see 11.3
20 (STA authenticationAuthentication and
21 association(#2277)))(#8222).
22
23 ...
24 EHTCapabilities As defined in EHT As defined in Specifies the parameters in the EHT
25 Capabilities element 9.4.2.313 (EHT Capabilities element that are supported by
26 Capabilities the STA. The parameter is present if
27 element(#4819)) dot11EHTOptionImplemented is true;
28 otherwise not present.
29 MultiLink Basic Multi-Link As defined in Indicates the Multi-Link parameters of
30 element(#6700) 9.4.2.312 (Multi- the (#7763)local MLD. This parameter is
31 Link element) present if dot11MultiLinkActivated is
32 true and is absent otherwise.
33
(#4134)TID-To-Link TID-To-Link As defined in Indicates links on which frames
34
Mapping Mapping element 9.4.2.314 (TID-To- belonging to each TID can be exchanged.
35
Link Mapping This parameter is present if
36
element) dot11MultiLinkActivated is true,
37
dot11TIDtoLinkMappingActivated is
38
true, and the STA affiliated with an MLD
39
initiates both an MLD association and a
40
TID-to-link mapping negotiation.
41
Otherwise it is not present.
42
43 VendorSpecificInfo A set of elements As defined in Zero or more elements.
44 9.4.2.25 (Vendor
45 Specific element)
46
47
48
6.3.7.2.3 When generated
49
50 Change the first paragraph as follows:
51
52
53 This primitive is generated by the SME when a STA wishes to establish association with an AP or PCP, or
54 when a non-AP MLD wishes to establish association with an AP MLD.
55
56
57 6.3.7.2.4 Effect of receipt
58
59
60 Change the first paragraph as follows:
61
62
This primitive initiates an association procedure. In the case that a response is received from the responder
63
64 STA or responder MLD, the MLME subsequently issues an MLME-ASSOCIATE.confirm primitive that
65 reflects the results.

Copyright © 2022 IEEE. All rights reserved. 73

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 6.3.7.3 MLME-ASSOCIATE.confirm
2
3
6.3.7.3.1 Function
4
5
6 Change the first paragraph as follows:
7
8 This primitive reports the results of an association attempt with a specified peer MAC entity that is in an AP
9
or PCP, or in an AP MLD.
10
11
12 6.3.7.3.2 Semantics of the service primitive
13
14 Change the primitive parameters as follows (not all existing parameters are shown):
15
16
17 The primitive parameters are as follows:
18 MLME-ASSOCIATE.confirm(
19 ...
20
EHTCapabilities,
21
22 EHTOperation,
23 MultiLink,
24 (#4134)TID-To-Link Mapping,
25 VendorSpecificInfo)
26
27
28 Name Type Valid range Description
29 ...
30
31 BSSMaxIdlePeri As defined in As defined in 9.4.2.78 (BSS Max Idle Indicates the BSS max idle period
32 od BSS Max Idle Period element) parameters of the AP or PCP
33 Period (#1027)when association is not
34 element for an MLD association (see 11.3
35 (STA
36 authenticationAuthentication and
37 association(#2277)))(#8222);
38 otherwise indicates the MLD max
39 idle period parameter of the AP
40 MLD. This parameter is present if
41 dot11WirelessManagementImple
42 mented is true and is not present
43 otherwise.
44 ...
45 EHTCapabilities As defined in As defined in 9.4.2.313 (EHT Specifies the parameters in the
46 EHT Capabilities element(#4819)) EHT Capabilities element that are
47 Capabilities supported by the STA. The
48 element parameter is present if
49 dot11EHTOptionImplemented is
50 true; otherwise not present.
51
52 EHTOperation EHT As defined in 9.4.2.311 (EHT Operation (#5586)Provides additional
53 Operation element) information for operating the
54 element EHT BSS. This parameter is
55 present if
56 dot11EHTOptionImplemented is
57 true; otherwise not present.
58
59
60
61
62
63
64
65

74 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
Name Type Valid range Description
2
3 MultiLink Basic Multi- As defined in 9.4.2.312 (Multi-Link Indicates the Multi-Link
4 Link element) parameters of the (#7764)peer
5 element(#670 MLD. This parameter is present if
6 0) dot11MultiLinkActivated is true
7 and is absent otherwise.
8 (#4134)TID-To- TID-To-Link As defined in 9.4.2.314 (TID-To-Link Indicates links on which frames
9 Link Mapping Mapping Mapping element) belonging to each TID can be
10 element exchanged. This parameter is
11 present if
12 dot11MultiLinkActivated is true,
13 dot11TIDtoLinkMappingActivate
14 d is true, and the STA affiliated
15 with an MLD initiates both an
16 MLD association and a TID-to-
17 link mapping negotiation.
18 Otherwise it is not present.
19
20 VendorSpecificIn A set of As defined in 9.4.2.25 (Vendor Specific Zero or more elements.
21 fo elements element)
22
23 6.3.7.3.3 When generated
24
25 Change the first paragraph as follows:
26
27
28 This primitive is generated by the MLME as a result of an MLME-ASSOCIATE.request primitive or receipt
29 of an Association Response frame from the peer MAC entity to associate with a specified peer MAC entity
30 that is in an AP or PCP, or in an AP MLD.
31
32
6.3.7.4 MLME-ASSOCIATE.indication
33
34
35 6.3.7.4.1 Function
36
37 Change the first paragraph as follows:
38
39
40 This primitive indicates that a specific peer MAC entity is requesting association with the local MAC entity,
41 which is in an AP or PCP, or in an AP MLD.
42
43 6.3.7.4.2 Semantics of the service primitive
44
45
46 Change the primitive parameters as follows (not all existing parameters are shown):
47
48 The primitive parameters are as follows:
49 MLME-ASSOCIATE.indication(
50
...
51
52 EHTCapabilities,
53 MultiLink,
54 (#4134)TID-To-Link Mapping,
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 75

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 VendorSpecificInfo
2 )
3
4
5 Name Type Valid range Description
6 ...
7
8 ListenInterval Integer 0 Specifies how often the STA awakens and
9 listens for the next Beacon frame, if it enters
10 power save mode when an association is not
11 (#6109)an MLD association (see 11.3 (STA
12 authenticationAuthentication and
13 association(#2277)))(#8222).
14
15 Specifies how often at least (#5583)one STA
16 affiliated with the MLD awakens and listens
17 for the next Beacon frame, if all STAs affili-
18 ated with the MLD enter power save mode
19 when an association is (#6109)an MLD associ-
20 ation (see 11.3 (STA authenticationAuthenti-
21 cation and association(#2277)))(#8222).
22 ...
23 EHTCapabilities As defined in EHT As defined in (#1004)(#2246)Specifies the parameters in the
24 Capabilities 9.4.2.313 (EHT EHT Capabilities element that are supported
25 element Capabilities by the peer STA. The parameter is present if
26 element(#4819)) dot11EHTOptionImplemented is true and the
27 EHT Capabilities element is present in the
28 Association Request frame received from the
29 STA; otherwise not present.
30
31 MultiLink Basic Multi-Link As defined in Indicates the Multi-Link parameters of the
32 element(#6700) 9.4.2.312 (Multi- (#7765)peer MLD. This parameter is present if
33 Link element) dot11MultiLinkActivated is true and is absent
34 otherwise.
35 (#4134)TID-To- TID-To-Link As defined in Indicates links on which frames belonging to
36 Link Mapping Mapping element 9.4.2.314 (TID-To- each TID can be exchanged. This parameter is
37 Link Mapping present if dot11MultiLinkActivated is true,
38 element) dot11TIDtoLinkMappingActivated is true, and
39 the STA affiliated with an MLD initiates both
40 an MLD association and a TID-to-link
41 mapping negotiation. Otherwise it is not
42 present.
43 VendorSpecificInfo A set of elements As defined in Zero or more elements.
44 9.4.2.25 (Vendor
45 Specific element)
46
47
48 6.3.7.5 MLME-ASSOCIATE.response
49
50 6.3.7.5.1 Function
51
52
53 Change the first paragraph as follows:
54
55 This primitive is used to send a response to a specific peer MAC entity that requested an association with the
56 STA that issued this primitive, which is in an AP or PCP, or a response to a specific peer MAC entity that
57 requested an association with the AP MLD that issued this primitive.
58
59
60 6.3.7.5.2 Semantics of the service primitive
61
62 Change the primitive parameters as follows (not all existing parameters are shown):
63
64
65 The primitive parameters are as follows:

76 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 MLME-ASSOCIATE.response(
2 ...
3
4 EHTCapabilities,
5 EHTOperation,
6 MultiLink,
7
8 (#4134)TID-To-Link Mapping,
9 VendorSpecificInfo
10 )
11
12
13 Name Type Valid range Description
14 ...
15
16 BSSMaxIdlePeriod BSS Max Idle As defined in 9.4.2.78 Indicates the BSS max idle period
17 Period element (BSS Max Idle Period parameters of the AP or PCP (#1027)when
18 element) association is not for an MLD association
19 (see 11.3 (STA
20 authenticationAuthentication and
21 association(#2277)))(#8222); otherwise
22 indicates the MLD max idle period
23 parameter of the AP MLD. This parameter
24 is present if
25 dot11WirelessManagementImplemented is
26 true or dot11S1GOptionImplemented is
27 true; otherwise not present.
28 ...
29 EHTCapabilities As defined in As defined in 9.4.2.313 Specifies the parameters in the EHT
30 EHT Capabilities (EHT Capabilities Capabilities element that are supported by
31 element element(#4819)) the STA. The parameter is present if
32 dot11EHTOptionImplemented is true;
33 otherwise not present.
34
35 EHTOperation EHT Operation As defined in 9.4.2.311 Provides additional information for
36 element (EHT Operation operating the EHT BSS. This parameter is
37 element) present if dot11EHTOptionImplemented is
38 true; otherwise not present.
39 MultiLink Basic Multi-Link As defined in 9.4.2.312 Indicates the Multi-Link parameters of the
40 element(#6700) (Multi-Link element) (#7766)local MLD. This parameter is
41 present if dot11MultiLinkActivated is true
42 and is absent otherwise.
43 (#4134)TID-To- TID-To-Link As defined in 9.4.2.314 Indicates links on which frames belonging
44 Link Mapping Mapping element (TID-To-Link Mapping to each TID can be exchanged. This
45 element) parameter is present if
46 dot11MultiLinkActivated is true,
47 dot11TIDtoLinkMappingActivated is true,
48 and the STA affiliated with an MLD
49 initiates both an MLD association and a
50 TID-to-link mapping negotiation.
51 Otherwise it is not present.
52
VendorSpecificInfo A set of elements As defined in Zero or more elements.
53
9.4.2.25 (Vendor
54
Specific element)
55
56
57 6.3.7.5.3 When generated
58
59
60 Change the first paragraph as follows:
61
62
This primitive is generated by the SME of a STA that is in an AP or PCP as a response to an MLME-ASSO-
63
64 CIATE.indication primitive, or by the SME of an AP MLD as a response to an MLME-ASSOCIATE.indi-
65 cation primitive.

Copyright © 2022 IEEE. All rights reserved. 77

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 6.3.8 Reassociate
2
3
4 6.3.8.1 Introduction
5
6 Change the first paragraph as follows:
7
8
9 The following primitives describe how a STA becomes associated with another AP or PCP, or how a
10 non-AP MLD becomes associated with another AP MLD.
11
12
13 6.3.8.2 MLME-REASSOCIATE.request
14
15 6.3.8.2.1 Function
16
17
18 Change the first paragraph as follows:
19
20 This primitive requests a change in association to a specified new peer MAC entity that is in an AP or PCP,
21
22
or in an AP MLD.
23
24 6.3.8.2.2 Semantics of the service primitive
25
26
27 Change the primitive parameters as follows (not all existing parameters are shown):
28
29 The primitive parameters are as follows:
30 MLME-REASSOCIATE.request(
31
32 ...
33 EHTCapabilities,
34 MultiLink,
35
36 (#4134)TID-To-Link Mapping,
37 VendorSpecificInfo
38 )
39
40 Name Type Valid range Description
41
42 ...
43 ListenInterval Integer 0 Specifies how often the STA awakens and
44 listens for the next Beacon frame, if it
45 enters power save mode when an
46 association is not (#6109)an MLD
47 association (see 11.3 (STA
48 authenticationAuthentication and
49 association(#2277)))(#8222).
50
51 Specifies how often at least (#5583)one
52 STA affiliated with the MLD awakens and
53 listens for the next Beacon frame, if all
54 STAs affiliated with the MLD enter power
55 save mode when a reassociation is
56 (#6109)an MLD association (see 11.3
57 (STA authenticationAuthentication and
58 association(#2277)))(#8222).
59
...
60
61 EHTCapabilities As defined in EHT As defined in Specifies the parameters in the EHT
62 Capabilities element 9.4.2.313 (EHT Capabilities element that are supported by
63 Capabilities the STA. The parameter is present if
64 element(#4819)) dot11EHTOptionImplemented is true;
65 otherwise not present.

78 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
Name Type Valid range Description
2
3 MultiLink Basic Multi-Link As defined in Indicates the Multi-Link parameters of the
4 element(#6700) 9.4.2.312 (Multi- (#7767)local MLD. This parameter is
5 Link element) present if dot11MultiLinkActivated is true
6 and is absent otherwise.
7 (#4134)TID-To- TID-To-Link As defined in Indicates links on which frames belonging
8 Link Mapping Mapping element 9.4.2.314 (TID-To- to each TID can be exchanged. This
9 Link Mapping parameter is present if
10 element) dot11MultiLinkActivated is true,
11 dot11TIDtoLinkMappingActivated is true,
12 and the STA affiliated with an MLD
13 initiates both an MLD association and a
14 TID-to-link mapping negotiation.
15 Otherwise it is not present.
16
17 VendorSpecificInfo A set of elements As defined in Zero or more elements.
18 9.4.2.25 (Vendor
19 Specific element)
20
21 6.3.8.2.3 When generated
22
23 Change the first paragraph as follows:
24
25
26 This primitive is generated by the SME for a STA to change association to a specified new peer MAC entity
27 that is in an AP or PCP, or in an AP MLD.
28
29
30 6.3.8.2.4 Effect of receipt
31
32 Change the first paragraph as follows:
33
34
35 This primitive initiates a reassociation procedure. In the case that a response is received from the responder
36 STA or MLD, the MLME subsequently issues an MLME-REASSOCIATE.confirm primitive that reflects
37 the results.
38
39
6.3.8.3 MLME-REASSOCIATE.confirm
40
41
42 6.3.8.3.1 Function
43
44
45
Change the first paragraph as follows:
46
47 This primitive reports the results of a reassociation attempt with a specified peer MAC entity that is in an AP
48 or PCP, or in an AP MLD.
49
50
51 6.3.8.3.2 Semantics of the service primitive
52
53 Change the primitive parameters as follows (not all existing parameters are shown):
54
55
56 The primitive parameters are as follows:
57 MLME-REASSOCIATE.confirm(
58
...
59
60 EHTCapabilities,
61 EHTOperation,
62 MultiLink,
63
64 (#4134)TID-To-Link Mapping,
65 VendorSpecificInfo

Copyright © 2022 IEEE. All rights reserved. 79

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 )
2
3
4 Name Type Valid range Description
5 ...
6
BSSMaxIdlePeriod BSS Max As defined in 9.4.2.78 (BSS Indicates the BSS max idle period
7
Idle Period Max Idle Period element) parameters of the AP or PCP
8
element (#1027)when association is not for an
9
MLD association (see 11.3 (STA
10
authenticationAuthentication and
11
association(#2277)))(#8222); otherwise
12
indicates the MLD max idle period
13
parameter of the AP MLD. This
14
parameter is present if
15
dot11WirelessManagementImplemented
16
is true or dot11S1GOptionImplemented
17
is true; otherwise not present.
18
19 ...
20 EHTCapabilities As defined in As defined in 9.4.2.313 (EHT Specifies the parameters in the EHT
21 EHT Capabilities element(#4819)) Capabilities element that are supported
22 Capabilities by the STA. The parameter is present if
23 element dot11EHTOptionImplemented is true;
24 otherwise not present.
25 EHTOperation EHT As defined in 9.4.2.311 (EHT (#5586)Provides additional information
26 Operation Operation element) for operating the EHT BSS. This
27 element parameter is present if
28 dot11EHTOptionImplemented is true;
29 otherwise not present.
30
31 MultiLink Basic Multi- As defined in 9.4.2.312 (Multi- Indicates the Multi-Link parameters of
32 Link Link element) the (#7768)peer MLD. This parameter is
33 element(#67 present if dot11MultiLinkActivated is
34 00) true and is absent otherwise.
35 (#4134)TID-To- TID-To-Link As defined in 9.4.2.314 (TID- Indicates links on which frames
36 Link Mapping Mapping To-Link Mapping element) belonging to each TID can be exchanged.
37 element This parameter is present if
38 dot11MultiLinkActivated is true,
39 dot11TIDtoLinkMappingActivated is
40 true, and the STA affiliated with an MLD
41 initiates both an MLD association and a
42 TID-to-link mapping negotiation.
43 Otherwise it is not present.
44 VendorSpecificInfo A set of As defined in 9.4.2.25 (Vendor Zero or more elements.
45 elements Specific element)
46
47
48 6.3.8.3.3 When generated
49
50 Change the first paragraph as follows:
51
52
53 This primitive is generated by the MLME as a result of an MLME-REASSOCIATE.request primitive to
54 reassociate with a specified peer MAC entity that is in an AP or PCP, or in an AP MLD.
55
56 6.3.8.4 MLME-REASSOCIATE.indication
57
58
59 6.3.8.4.2 Semantics of the service primitive
60
61 Change the primitive parameters as follows (not all existing parameters are shown):
62
63
64 The primitive parameters are as follows:
65 MLME-REASSOCIATE.indication(

80 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 ...
2 EHTCapabilities,
3
4
MultiLink,
5 (#4134)TID-To-Link Mapping,
6 VendorSpecificInfo
7 )
8
9
10 Name Type Valid range Description
11 ...
12
13 CurrentAPAddress MAC address Any valid individual Specifies the address of the AP or PCP or
14 MAC address MLD with which the peer STA is currently
15 associated.
16 ListenInterval Integer 0 Specifies how often the STA awakens and
17 listens for the next Beacon frame, if it
18 enters power save mode when an
19 association is not (#6109)an MLD
20 association (see 11.3 (STA
21 authenticationAuthentication and
22 association(#2277)))(#8222).
23
24 Specifies how often at least (#5583)one
25 STA affiliated with the MLD awakens and
26 listens for the next Beacon frame, if all
27 STAs affiliated with the MLD enter power
28 save mode when a reassociation is
29 (#6109)an MLD association (see 11.3 (STA
30 authenticationAuthentication and associa-
31 tion(#2277)))(#8222).
32 ...
33
34 EHTCapabilities As defined in EHT As defined in (#1004)(#2246)Specifies the parameters in
35 Capabilities element 9.4.2.313 (EHT the EHT Capabilities element that are sup-
36 Capabilities ported by the peer STA. The parameter is
37 element(#4819)) present if dot11EHTOptionImplemented is
38 true and the EHT Capabilities element is
39 present in the Reassociation Request frame
40 received from the STA; otherwise not pres-
41 ent.
42 MultiLink Basic Multi-Link As defined in Indicates the Multi-Link parameters of the
43 element(#6700) 9.4.2.312 (Multi- (#7769)peer MLD. This parameter is
44 Link element) present if dot11MultiLinkActivated is true
45 and is absent otherwise.
46 (#4134)TID-To- TID-To-Link As defined in Indicates links on which frames belonging
47 Link Mapping Mapping element 9.4.2.314 (TID-To- to each TID can be exchanged. This
48 Link Mapping parameter is present if
49 element) dot11MultiLinkActivated is true,
50 dot11TIDtoLinkMappingActivated is true,
51 and the STA affiliated with an MLD
52 initiates both an MLD association and a
53 TID-to-link mapping negotiation.
54 Otherwise it is not present.
55
VendorSpecificInfo A set of elements As defined in Zero or more elements.
56
9.4.2.25 (Vendor
57
Specific element)
58
59
60 6.3.8.5 MLME-REASSOCIATE.response
61
62 6.3.8.5.1 Function
63
64
65 Change the first paragraph as follows:

Copyright © 2022 IEEE. All rights reserved. 81

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 This primitive is used to send a response to a specific peer MAC entity that requested a reassociation with
2 the STA that issued this primitive, which is in an AP or PCP, or in an AP MLD.
3
4
5 6.3.8.5.2 Semantics of the service primitive
6
7 Change the primitive parameters as follows (not all existing parameters are shown):
8
9
10 The primitive parameters are as follows:
11 MLME-REASSOCIATE.response(
12 ...
13 EHTCapabilities,
14
15 EHTOperation,
16 MultiLink,
17 (#4134)TID-To-Link Mapping,
18 VendorSpecificInfo
19
20 )
21
22 Name Type Valid range Description
23
24 ...
25 BSSMaxIdlePeriod BSS Max Idle As defined in 9.4.2.78 (BSS Indicates the BSS max idle period
26 Period Max Idle Period element) parameters of the AP or PCP
27 element (#1027)when association is not for an
28 MLD association (see 11.3 (STA
29 authenticationAuthentication and
30 association(#2277)))(#8222); otherwise
31 indicates the MLD max idle period
32 parameter of the AP MLD. This
33 parameter is present if
34 dot11WirelessManagementImplemented
35 is true or dot11S1GOptionImplemented
36 is true; otherwise not present.
37 ...
38
39 EHTCapabilities As defined in As defined in 9.4.2.313 (EHT Specifies the parameters in the EHT
40 EHT Capabilities element(#4819)) Capabilities element that are supported
41 Capabilities by the STA. The parameter is present if
42 element dot11EHTOptionImplemented is true;
43 otherwise not present.
44 EHTOperation EHT As defined in 9.4.2.311 (EHT Provides additional information for
45 Operation Operation element) operating the EHT BSS. This parameter
46 element is present if
47 dot11EHTOptionImplemented is true;
48 otherwise not present.
49 MultiLink Basic Multi- As defined in 9.4.2.312 Indicates the Multi-Link parameters of
50 Link (Multi-Link element) the (#7770)local MLD. This parameter is
51 element(#670 present if dot11MultiLinkActivated is
52 0) true and is absent otherwise.
53
(#4134)TID-To- TID-To-Link As defined in 9.4.2.314 (TID- Indicates links on which frames
54
Link Mapping Mapping To-Link Mapping element) belonging to each TID can be exchanged.
55
element This parameter is present if
56
dot11MultiLinkActivated is true,
57
dot11TIDtoLinkMappingActivated is
58
true, and the STA affiliated with an MLD
59
initiates both an MLD association and a
60
TID-to-link mapping negotiation.
61
Otherwise it is not present.
62
63 VendorSpecificInfo A set of As defined in Zero or more elements.
64 elements 9.4.2.25 (Vendor Specific
65 element)

82 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 6.3.8.5.3 When generated

2
3
4 Change the first paragraph as follows:
5
6 This primitive is generated by the SME of a STA that is in an AP or PCP, or in an AP MLD as a response to
7 an MLME-REASSOCIATE.indication primitive.
8
9
10 6.3.9 Disassociate
11
12 6.3.9.1 MLME-DISASSOCIATE.request
13
14
15 6.3.9.1.3 When generated
16
17 This primitive is generated by the SME for a STA to disassociate from a STA with which it has an associa-
18
19 tion, or by the SME for a MLD to disassociate from a MLD with which it has an association.
20
21 6.3.11 Start
22
23
24
6.3.11.2 MLME-START.request(#1004)(#2246)
25
26 6.3.11.2.2 Semantics of the service primitive
27
28
29
Change the primitive parameters as follows (not all existing parameters are shown):
30
31 The primitive parameters are as follows:
32 MLME-START.request(
33
34 …,
35 EHTCapabilities,
36 EHTOperation,
37 (#6165)MultiLink,
38
39 VendorSpecificInfo
40 )
41
42 Name Type Valid range Description
43
44 EHTCapabilities As defined in As defined in 9.4.2.313 Specifies the parameters in the EHT
45 EHT (EHT Capabilities Capabilities element that are supported by
46 Capabilities element(#4819)) the STA. The parameter is present if
47 element dot11EHTOptionImplemented is true;
48 otherwise this parameter is not present.
49 EHTOperation EHT As defined in 9.4.2.311 Provides additional information for operating
50 Operation (EHT Operation the EHT BSS. This parameter is present if
51 element element) dot11EHTOptionImplemented is true;
52 otherwise this parameter is not present.
53
(#6165)MultiLink Basic Multi- As defined in 9.4.2.312 Indicates the Multi-Link parameters of
54
Link element (Multi-Link element) the MLD. This parameter is present if
55
dot11MultiLinkActivated is true and is
56
absent otherwise.
57
58 VendorSpecificInfo A set of As defined in 9.4.2.25 Zero or more elements.
59 elements (Vendor Specific ele-
60 ment)
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 83

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 6.3.12 Stop
2
3
4 6.3.12.2 MLME-Stop.request
5
6 6.3.12.2.3 When generated
7
8
9 Change the first paragraph as follows:
10
11 This primitive is generated by the SME to terminate an infrastructure BSS (with the MAC entity within an
12
13 AP or an MLD(#7836)) or a PBSS (with the MAC entity within the PCP). The MLME-STOP.request prim-
14 itive shall be generated only after successful use of an MLME-START.confirm primitive.
15
16
17
18 6.3.39 SA Query support
19
20
21 Insert the following subclause as the first child subclause of 6.3.39 (SA Query support):
22
23 6.3.39.1 General
24
25
26 In 6.3.39 (SA Query support), the reference of a “STA” means the “STA” that is not affiliated with an MLD
27 unless specified otherwise, and the reference of an “AP” means the AP that is not affiliated with an MLD
28 unless specified otherwise. When referring to MLD management, the “SME” is the entity that manages the
29 MLD. The peer MAC entity can be (#5581)within a STA that is not affiliated with an MLD or an MLD
30
31 depending on the context. The PeerSTAAddress can be the MAC address of (#5582)a STA that is not affili-
32 ated with an MLD or an MLD MAC address depending on the context.
33
34 6.3.39.2 MLME-SA-QUERY.request
35
36
37 6.3.39.2.1 Function
38
39
40
Change as follows:
41
42 This primitive requests that an SA Query Request frame be sent to a specified peer STA to which the STA is
43 associated or be sent to an affiliated STA of the specified peer MLD to which the MLD is associated.
44
45
46 6.3.39.2.3 When generated
47
48
49
Change as follows:
50
51 This primitive is generated by the SME to request that an SA Query Request frame be sent to a specified
52 peer STA with which the STA is associated or be sent to a STA affiliated with the specified peer MLD with
53
54
which the MLD is associated.
55
56 6.3.39.2.4 Effect of receipt
57
58
59 Change as follows:
60
61 On receipt of this primitive, the MLME constructs an SA Query Request frame. The STA then attempts to
62
transmit this to the peer STA with which it is associated or a STA affiliated with the MLD attempts to trans-
63
64 mit this to another STA affiliated with the peer MLD with which the MLD is associated on the correspond-
65 ing link.

84 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 6.3.39.3 MLME-SA-QUERY.confirm
2
3 6.3.39.3.4 Effect of receipt
4
5
6
Change as follows:
7
8 On receipt of this primitive, the SME may use the response as a sign of liveness of the peer STA or the peer
9 MLD.
10
11
12
6.3.39.4 MLME-SA-QUERY.indication
13
14 6.3.39.4.1 Function
15
16 Change as follows:
17
18
19 This primitive indicates that an SA Query Request frame was received from a STA.
20
21 6.3.39.5 MLME-SA-QUERY.response
22
23
24 6.3.39.5.1 Function
25
26 Change as follows:
27
28 This primitive is generated in response to an MLME-SA-QUERY.indication primitive requesting an SA
29
30 Query Response frame be sent to a STA or to a STA affiliated with the peer MLD.
31
32 6.3.39.5.3 When generated
33
34 Change as follows:
35
36
37 This primitive is generated by the SME, in response to an MLME-SA-QUERY.indication primitive,
38 requesting an SA Query Response frame be sent to a STA or to a STA affiliated with the peer MLD.
39
40 6.3.39.5.4 Effect of receipt
41
42
43 Change as follows:
44
45 On receipt of this primitive, the MLME constructs an SA Query Response frame. The STA then attempts to
46 transmit this to the STA indicated by the PeerSTAAddress parameter or a STA affiliated with the MLD then
47
48 attempts to transmit this to a STA affiliated with the peer MLD indicated by the PeerSTAAddress parame-
49 ter.
50
51 6.3.82 SCS request and response procedure
52
53
54 6.3.82.3 MLME-SCS.confirm
55
56 6.3.82.3.2 Semantics of the service primitive
57
58
59
Change the primitive parameters as follows (not all existing parameters are shown):
60
61 The primitive parameters are as follows:
62 MLME-SCS.confirm(
63 PeerSTAAddress,
64
DialogToken, 
65

Copyright © 2022 IEEE. All rights reserved. 85

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 SCSID,
2 Status,
3
SCS Descriptor,(#1977)
4
5 VendorSpecificInfo
6 )
7
8
Name Type Valid range Description
9
10 (#1977)SCS Descriptor SCS Descriptor SCS Descriptor SCS descriptor.
11 element
12 VendorSpecificInfo A set of elements As defined in 9.4.2.25 Zero or more elements.
13 (Vendor Specific element)
14
15
16 6.3.82.5 MLME-SCS.response
17
18 6.3.82.5.2 Semantics of the service primitive
19
20
21 Change the primitive parameters as follows (not all existing parameters are shown):
22
23 The primitive parameters are as follows:
24 MLME-SCS.response(
25
26 PeerSTAAddress,
27 DialogToken, 
28 SCSID,
29 Status,
30 SCS Descriptor,(#1977)
31
32 VendorSpecificInfo
33 )
34
35 Name Type Valid range Description
36 (#1977)SCS Descriptor SCS Descriptor element SCS Descriptor SCS descriptor.
37
38 VendorSpecificInfo A set of elements As defined in 9.4.2.25 Zero or more elements.
39 (Vendor Specific
40 element)
41
42 Insert the following at the end of subclause 6.3 (MLME SAP interface):
43
44
6.3.131 EPCS priority access(#5284)
45
46
47 6.3.131.1 Introduction
48
49 The following primitives support (#5284)EPCS priority access operation (see 35.17 (EPCS priority
50
access(#5284))).
51
52
53 6.3.131.2 MLME-EPCSPRIACCESSENABLE.request(#5587)(#5284)
54
55 6.3.131.2.1 Function
56
57
58 This primitive initiates a request to a peer MAC entity to enable (#5284)EPCS priority access(#5587).
59
60 6.3.131.2.2 Semantics of the service primitive
61
62
The primitive parameters are as follows:
63
64 (#5587)(#5284)MLME-EPCSPRIACCESSENABLE.request(
65 PeerSTAAddress,

86 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Dialog Token,
2 EDCAParameterSet
3
4 )
5
6 Name Type Valid range Description
7
8 PeerSTAAddress MAC address Any valid individual Specifies the address of the peer MAC
9 MAC address entity with which the (#5284)EPCS priority
10 access procedure is performed.
11 Dialog Token Integer 0–255 The dialog token to identify the
12 (#5284)EPCS priority access procedure.
13 (#5587)EDCAPara EDCA Parameter Set As defined in Specifies service parameters for the
14 meterSet element 9.4.2.28 (EDCA (#5284)EPCS EDCA parameter set.
15 Parameter Set
16 element)
17
18
19 6.3.131.2.3 When generated
20
21 (#7549)This primitive is generated by the SME to send a request to a peer MAC entity to enable
22
23
(#5284)EPCS priority access.
24
25 6.3.131.2.4 Effect of receipt
26
27
(#7550)This primitive initiates transmission of an (#5284)EPCS Priority Access Request frame to the peer
28
29 MAC entity.
30
31 6.3.131.3 MLME-EPCSPRIACCESSENABLE.confirm(#5587)(#5284)
32
33
34 6.3.131.3.1 Function
35
36 (#5587)This primitive reports the response to a request to enable (#5284)EPCS priority access with a peer
37 MAC entity.
38
39
40 6.3.131.3.2 Semantics of the service primitive
41
42 The primitive parameters are as follows:
43 (#5587)(#5284)MLME-EPCSPRIACCESSENABLE.confirm(
44
45 PeerSTAAddress,
46 Dialog Token,
47 Status Code,
48
49
EDCAParameterSet
50 )
51
52 Name Type Valid range Description
53
54 PeerSTAAddress MAC address Any valid individual Specifies the address of the peer MAC
55 MAC address entity with which the (#5284)EPCS priority
56 access procedure is performed.
57 Dialog Token Integer 0–255 The dialog token to identify the
58 (#5284)EPCS priority access procedure.
59
Status Code As defined in frame As defined in 9.4.1.9 Indicates the status of the request procedure
60
format (Status Code field)
61
62 (#5587)EDCAPara EDCA Parameter Set As defined in Specifies service parameters for the
63 meterSet element 9.4.2.28 (EDCA (#5284)EPCS EDCA parameter set.
64 Parameter Set
65 element)

Copyright © 2022 IEEE. All rights reserved. 87

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 6.3.131.3.3 When generated

2
3
4 This primitive is generated by the MLME as a result of the receipt of an (#5284)EPCS Priority Access
5 Enable Response frame(#5587) from the peer MAC entity.
6
7
6.3.131.3.4 Effect of receipt
8
9
10 The SME is notified of the results of the (#5284)EPCS priority access procedure.
11
12
13 6.3.131.4 MLME-EPCSPRIACCESSENABLE.indication(#5284)(#5587)
14
15 6.3.131.4.1 Function
16
17
18 (#5587)This primitive indicates that a request to enable (#5587)EPCS priority access has been received from
19 a peer MAC entity.
20
21
22 6.3.131.4.2 Semantics of the service primitive
23
24 The primitive parameters are as follows:
25
26 (#5587)(#5284)MLME-EPCSPRIACCESSENABLE.indication(
27 PeerSTAAddress,
28
29 Dialog Token,
30 EDCAParameterSet
31 )
32
33
34 Name Type Valid range Description
35
PeerSTAAddress MAC address Any valid individual Specifies the address of the peer MAC
36
MAC address entity with which the (#5284)EPCS priority
37
access procedure is performed.
38
39 Dialog Token Integer 0–255 The dialog token to identify the
40 (#5284)EPCS priority access procedure.
41 (#5587)EDCAPara EDCA Parameter Set As defined in Specifies service parameters for the
42 meterSet element 9.4.2.28 (EDCA (#5284)EPCS EDCA parameter set.
43 Parameter Set
44 element)
45
46
47 6.3.131.4.3 When generated
48
49 This primitive is generated by the MLME as a result of the receipt of an (#5284)EPCS Priority Access
50
51 Enable Request frame(#5587) from a peer MAC entity.
52
53 6.3.131.4.4 Effect of receipt
54
55
56 The SME is notified of the receipt of the (#5284)EPCS priority access request.
57
58
6.3.131.5 MLME-EPCSPRIACCESSENABLE.response(#5284)(#5587)
59
60
61 6.3.131.5.1 Function
62
63
64 (#5587)This primitive is generated by the MLME to send a response to a peer MAC entity that sent a request
65 to enable (#5284)EPCS priority access.

88 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 6.3.131.5.2 Semantics of the service primitive

2
3
The primitive parameters are as follows:
4
5 (#5587)(#5284)MLME-EPCSPRIACCESSENABLE.response(
6 PeerSTAAddress,
7 Dialog Token,
8 Status Code,
9
10 EDCAParameterSet
11 )
12
13
Name Type Valid range Description
14
15 PeerSTAAddress MAC address Any valid individual Specifies the address of the peer MAC
16 MAC address entity with which the (#5284)EPCS priority
17 access procedure is performed.
18 Dialog Token Integer 0–255 The dialog token to identify the
19 (#5284)EPCS priority access procedure.
20
21 Status Code As defined in frame As defined in 9.4.1.9 Indicates the status of the request procedure
22 format (Status Code field)
23 (#5587)EDCAPara EDCA Parameter Set As defined in Specifies service parameters for the
24 meterSet element 9.4.2.28 (EDCA (#5284)EPCS EDCA parameter set.
25 Parameter Set
26 element)
27
28 6.3.131.5.3 When generated
29
30
31 (#5587)This primitive is generated by the SME as a response to an (#5284)MLME-EPCSPRIACCESSEN-
32 ABLE.indication primitive.
33
34 6.3.131.5.4 Effect of receipt
35
36
37 (#5284)This primitive initiates transmission of an EPCS Priority Access Enable Response frame(#5587) to
38 the peer MAC entity that requested the change to EPCS priority access.
39
40
6.3.131.6 MLME-EPCSPRIACCESSTEARDOWN.request(#5284)(#5587)
41
42
43 6.3.131.6.1 Function
44
45 This primitive instructs a peer MAC entity to tear down (#5284)EPCS priority access.
46
47
48 6.3.131.6.2 Semantics of the service primitive
49
50 The primitive parameters are as follows:
51 (#5284)MLME-EPCSPRIACCESSTEARDOWN.request(
52
53 PeerSTAAddress
54 )
55
56
Name Type Valid range Description
57
58 PeerSTAAddress MAC address Any valid individual Specifies the address of the peer MAC
59 MAC address entity with which the (#5284)EPCS priority
60 access procedure is performed.
61
62 6.3.131.6.3 When generated
63
64
65 This primitive is generated by the SME when a STA intends a tear down (#5284)EPCS priority access.

Copyright © 2022 IEEE. All rights reserved. 89

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 6.3.131.6.4 Effect of receipt

2
3
4 This primitive initiates an (#5284)EPCS priority access teardown procedure.
5
6 6.3.131.7 MLME-EPCSPRIACCESSTEARDOWN.indication(#5284)(#5587)
7
8
9 6.3.131.7.1 Function
10
11 This primitive indicates that a peer MAC entity is tearing down (#5284)EPCS priority access.
12
13
14 6.3.131.7.2 Semantics of the service primitive
15
16
17 The primitive parameters are as follows:
18 (#5284)MLME-EPCSPRIACCESSTEARDOWN.indication(
19 PeerSTAAddress
20
21 )
22
23 Name Type Valid range Description
24
25 PeerSTAAddress MAC address Any valid individual Specifies the address of the peer MAC
26 MAC address entity with which the (#5284)EPCS priority
27 access procedure is performed.
28
29
30 6.3.131.7.3 When generated
31
32 This primitive is generated by the MLME as a result of the receipt of an (#5284)EPCS Priority Access Tear-
33 down frame from a peer MAC entity.
34
35
36 6.3.131.7.4 Effect of receipt
37
38
39 The SME is notified of the results of the (#5284)EPCS priority access procedure.
40
41 6.3.132 TID-to-link mapping(#4133)
42
43
44 6.3.132.1 Introduction
45
46 The following primitives support TID-to-link mapping operation (35.3.7.1 (TID-to-link mapping)).
47
48
49 6.3.132.2 MLME-TIDTOLINKMAPPING.request
50
51
52
6.3.132.2.1 Function
53
54 This primitive initiates a request to negotiate a TID-to-link mapping for setup links with a peer MAC entity.
55
56
57 6.3.132.2.2 Semantics of the service primitive
58
59 The primitive parameters are as follows:
60
61 MLME-TIDTOLINKMAPPING.request(
62 PeerSTAAddress,
63
Dialog Token,
64
65 TID-To-Link Mapping

90 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 )
2
3
4 Name Type Valid range Description
5 PeerSTAAddress MAC address Any valid individual Specifies the address of the peer MAC
6 MAC address entity with which the TID-to-link mapping
7 procedure is performed.
8
Dialog Token Integer 0–255 The dialog token to identify the TID-to-link
9
mapping procedure.
10
11 TID-To-Link TID-To-Link As defined in Indicates links on which frames belonging
12 Mapping Mapping element 9.4.2.314 (TID-To- to each TID can be exchanged.
13 Link Mapping
14 element)
15
16
17 6.3.132.2.3 When generated
18
19 This primitive is generated by the SME to send a request to a peer MAC entity to negotiate a TID-to-link
20
mapping.
21
22
23 6.3.132.2.4 Effect of receipt
24
25
26 This primitive initiates transmission of a TID-To-Link Mapping Request frame to the peer MAC entity.
27
28
29 6.3.132.3 MLME-TIDTOLINKMAPPING.confirm
30
31 6.3.132.3.1 Function
32
33
34 This primitive indicates that a TID-To-Link Mapping Response frame has been received. That may be in
35 response to an earlier MLME-TIDTOLINKMAPPING.request primitive or an autonomous response.
36
37
38 6.3.132.3.2 Semantics of the service primitive
39
40
41 The primitive parameters are as follows:
42 MLME-TIDTOLINKMAPPING.confirm(
43
44 PeerSTAAddress,
45 Dialog Token,
46
47 Status Code,
48 TID-To-Link Mapping
49
50 )
51
52 Name Type Valid range Description
53
54 PeerSTAAddress MAC address Any valid individual Specifies the address of the peer MAC
55 MAC address entity with which the TID-to-link mapping
56 procedure is performed.
57 Dialog Token Integer 0–255 The dialog token to identify the TID-to-link
58 mapping procedure.
59
Status Code As defined in frame As defined in 9.4.1.9 Indicates the status of the request proce-
60
format (Status Code field) dure.
61
62 TID-To-Link TID-To-Link As defined in Indicates links on which frames belonging
63 Mapping Mapping element 9.4.2.314 (TID-To- to each TID can be exchanged.
64 Link Mapping
65 element)

Copyright © 2022 IEEE. All rights reserved. 91

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 6.3.132.3.3 When generated

2
3
4 This primitive is generated by the MLME when a TID-To-Link Mapping Response frame is received from
5 the peer MAC entity.
6
7
6.3.132.3.4 Effect of receipt
8
9
10 The SME is notified of the receipt of the TID-to-link mapping.
11
12
13 6.3.132.4 MLME-TIDTOLINKMAPPING.indication
14
15 6.3.132.4.1 Function
16
17
18 This primitive indicates that a request to negotiate a TID-to-link mapping has been received from a peer
19 MAC entity.
20
21
22 6.3.132.4.2 Semantics of the service primitive
23
24 The primitive parameters are as follows:
25
26 MLME-TIDTOLINKMAPPING.indication(
27 PeerSTAAddress,
28
29 Dialog Token,
30 TID-To-Link Mapping
31 )
32
33
34 Name Type Valid range Description
35
PeerSTAAddress MAC address Any valid individual Specifies the address of the peer MAC
36
MAC address entity with which the TID-to-link mapping
37
procedure is performed.
38
39 Dialog Token Integer 0–255 The dialog token to identify the TID-to-link
40 mapping procedure.
41 TID-To-Link TID-To-Link As defined in Indicates links on which frames belonging
42 Mapping Mapping element 9.4.2.314 (TID-To- to each TID can be exchanged.
43 Link Mapping
44 element)
45
46
47 6.3.132.4.3 When generated
48
49 This primitive is generated by the MLME as a result of the receipt of a TID-To-Link Mapping Request
50
51 frame from a peer MAC entity.
52
53 6.3.132.4.4 Effect of receipt
54
55
56 The SME is notified of the receipt of the TID-to-link mapping request.
57
58
6.3.132.5 MLME-TIDTOLINKMAPPING.response
59
60
61 6.3.132.5.1 Function
62
63
64 This primitive is generated by the MLME to send a response. This may be in response to an MLME-TIDTO-
65 LINKMAPPING.indication primitive or an autonomous response.

92 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 6.3.132.5.2 Semantics of the service primitive

2
3
The primitive parameters are as follows:
4
5 MLME-TIDTOLINKMAPPING.response(
6 PeerSTAAddress,
7 Dialog Token,
8 Status Code,
9
10 TID-To-Link Mapping
11 )
12
13
Name Type Valid range Description
14
15 PeerSTAAddress MAC address Any valid individual Specifies the address of the peer MAC
16 MAC address entity with which the TID-to-link mapping
17 procedure is performed.
18 Dialog Token Integer 0–255 The dialog token to identify the TID-to-link
19 mapping procedure.
20
21 Status Code As defined in frame As defined in 9.4.1.9 Indicates the status of the request proce-
22 format (Status Code field) dure.
23 TID-To-Link TID-To-Link As defined in Indicates links on which frames belonging
24 Mapping Mapping element 9.4.2.314 (TID-To- to each TID can be exchanged.
25 Link Mapping
26 element)
27
28 6.3.132.5.3 When generated
29
30
31 This primitive is generated by the SME to request a TID-To-Link Mapping Response frame be sent. That
32 may be in response to an MLME-TIDTOLINKMAPPING.indication primitive or a request to transmit an
33 autonomous response.
34
35
36 6.3.132.5.4 Effect of receipt
37
38 This primitive initiates transmission of a TID-To-Link Mapping Response frame to the peer MAC entity.
39
40
6.3.132.6 MLME-TIDTOLINKMAPPINGTEARDOWN.request
41
42
43 6.3.132.6.1 Function
44
45 This primitive instructs a peer MAC entity to tear down TID-to-link mapping.
46
47
48 6.3.132.6.2 Semantics of the service primitive
49
50 The primitive parameters are as follows:
51 MLME-TIDTOLINKMAPPINGTEARDOWN.request(
52
53 PeerSTAAddress
54 )
55
56
Name Type Valid range Description
57
58 PeerSTAAddress MAC address Any valid individual Specifies the address of the peer MAC
59 MAC address entity with which the TID-to-link mapping
60 procedure is performed.
61
62 6.3.132.6.3 When generated
63
64
65 This primitive is generated by the SME when a STA intends a tear down TID-to-link mapping.

Copyright © 2022 IEEE. All rights reserved. 93

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 6.3.132.6.4 Effect of receipt

2
3
4 This primitive initiates a TID-to-link mapping teardown procedure.
5
6 6.3.132.7 MLME-TIDTOLINKMAPPINGTEARDOWN.indication
7
8
9 6.3.132.7.1 Function
10
11 This primitive indicates that a peer MAC entity is tearing down TID-to-link mapping.
12
13
14 6.3.132.7.2 Semantics of the service primitive
15
16 The primitive parameters are as follows:
17
18 MLME-TIDTOLINKMAPPINGTEARDOWN.indication(
19 PeerSTAAddress
20 )
21
22
23 Name Type Valid range Description
24
PeerSTAAddress MAC address Any valid individual Specifies the address of the peer MAC
25
MAC address entity with which the TID-to-link mapping
26
procedure is performed.
27
28
29 6.3.132.7.3 When generated
30
31
32 This primitive is generated by the MLME as a result of the receipt of a TID-To-Link Mapping Teardown
33 frame from a peer MAC entity.
34
35 6.3.132.7.4 Effect of receipt
36
37
38 The SME is notified of the results of the TID-to-link mapping procedure.
39
40
6.3.133 EML operating mode notification(#4134)
41
42
43 6.3.133.1 Introduction
44
45
46 The following primitives support EML operating mode notification operation.
47
48 6.3.133.2 MLME-EMLOPERATINGMODENOTIF.request
49
50
51 6.3.133.2.1 Function
52
53 This primitive requests the transmission of an EML Operating Mode Notification frame to a peer MAC
54 entity.
55
56
57 6.3.133.2.2 Semantics of the service primitive
58
59
The primitive parameters are as follows:
60
61 MLME-EMLOPERATINGMODENOTIF.request(
62 PeerSTAAddress,
63
64
Dialog Token,
65 EML Control

94 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 )
2
3
4 Name Type Valid range Description
5 PeerSTAAddress MAC address Any valid individual Specifies the address of the peer MAC
6 MAC address entity to which the EML operating mode
7 notification is sent.
8
Dialog Token Integer 0–255 The dialog token to identify the EML oper-
9
ating mode notification procedure.
10
11 EML Control As defined in EML As defined in Indicates the information that is changing
12 Control field 9.4.1.74 (EML Con- the EML operation.
13 trol field)
14
15 6.3.133.2.3 When generated
16
17
18 This primitive is generated by the SME to request that an EML Operating Mode Notification frame be sent
19 to a peer MAC entity.
20
21
22 6.3.133.2.4 Effect of receipt
23
24 This primitive initiates transmission of an EML Operating Mode Notification frame to the peer MAC entity.
25
26
27 6.3.133.3 MLME-EMLOPERATINGMODENOTIF.indication
28
29 6.3.133.3.1 Function
30
31
32 This primitive indicates that an EML Operating Mode Notification frame has been received.
33
34 6.3.133.3.2 Semantics of the service primitive
35
36
37 The primitive parameters are as follows:
38 MLME-EMLOPERATINGMODENOTIF.indication(
39 PeerSTAAddress,
40
Dialog Token,
41
42 EML Control
43 )
44
45
46 Name Type Valid range Description
47 PeerSTAAddress MAC address Any valid individual Specifies the address of the peer MAC
48 MAC address entity to which the EML operating mode
49 notification is sent.
50
Dialog Token Integer 0–255 The dialog token to identify the EML oper-
51
ating mode notification procedure.
52
53 EML Control As defined in EML As defined in Indicates the information that is changing
54 Control field 9.4.1.74 (EML Con- the EML operation.
55 trol field)
56
57 6.3.133.3.3 When generated
58
59
60 This primitive is generated by the MLME when an EML Operating Mode Notification frame is received.
61
62 6.3.133.3.4 Effect of receipt
63
64
65 On receipt of this primitive, the SME uses the information contained within the notification.

Copyright © 2022 IEEE. All rights reserved. 95

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5 March 2022

1 7. DS SAP specification
2
3
4
5
7.1 Introduction
6
7 Change the contents of this subclause, including Figure 7-1 (DS
8 architecture(#2239)(#2720)(#3410)(#3417)), as follows:
9
10
11 (#2239)(#2720)(#3410)(#3417)The DS SAP is the interface between the DS SAP service users and the DS
12 SAP service provider. The DS SAP service users are the connected APs, mesh gates, and the portal, and AP
13 MLDs. The DS SAP service provider is the DS. Figure 7-1 (DS architecture(#2239)(#2720)(#3410)(#3417))
14 shows the location of the DS in the IEEE 802.11 architecture. The DS SAP is indicated in this Figure by the
15
16 lines connecting the DS to its service users. In Figure 7-1 (DS architecture(#2239)(#2720)(#3410)(#3417)),
17 the DS has four users, two APs, a mesh gate, and a portal, and an AP MLD, so the DS is shown passing
18 behind the MAC/PHYs of the STAs.
19
20
21 DSAF DSAF DSAF Portal DSAF
MAC MAC Mesh MUMS
22 MAC MAC MAC MAC MUMS
23 PHY PHY PHY PHY DS PHY PHY MLMS MLMS MLMS MLMS
24 PHY PHY PHY PHY
25 802.11 Medium 802.11 Medium 802.11 Medium Non‐802.11 Medium
26
27 802.11 Media
Non‐AP STAs AP1 AP2 Mesh Gate Portal
28 AP MLD non‐AP MLD
29 ‐ DS SAP MUMS = MLD Upper MAC Sublayer
30 MLMS = MLD Lower MAC Sublayer
31
32 Figure 7-1—DS architecture(#2239)(#2720)(#3410)(#3417)
33
34
35 (#2239)(#2720)(#3410)(#3417)The DS SAP interface specification describes the primitives required to get
36
37 MAC service tuples in and out of the DS and
38 — update the DS’s mapping of STAs to APs or to mesh gates.,
39
40 — update the DS’s mapping of non-AP MLDs to AP MLDs.
41
42 Describing the DS itself or the functions thereof is out of scope of this annexstandard.
43
44 (#2239)(#2720)(#3410)(#3417)The DS SAP actions are as follows:
45
46 a) Accept MSDUs (as part of MAC service tuples) from APs, mesh gates, and the portal, and AP
47 MLDs.
48
49 b) Deliver MSDUs (as part of MAC service tuples) to APs, mesh gates, or the portal, or the AP MLDs.
50 c) Accept STA-to-AP mapping updates from the APs.
51
52 d) Accept STA-to-mesh gate mapping updates from the mesh gates.
53 e) Accept non-AP-MLD-to-AP-MLD mapping updates from the AP MLDs.
54
55 NOTE—For MLDs, the source address or destination address parameters of the MAC service tuples (see
56 5.2.3.2 (Semantics of the service primitive)) are set to the MLD MAC address of the non-AP MLD, which is the identity
57 of the non-AP MLD known by the DS.
58
59 (#2239)(#2720)(#3410)(#3417)When the DS delivers the MAC service tuples to an AP, the AP then
60 determines when and how to deliver the MAC service tuples to the AP’s MAC (via the MAC SAP). When
61 the DS delivers the MAC service tuples to a mesh gate, the mesh gate then determines when and how to
62
deliver the MAC service tuples to the mesh gate’s MAC (via the MAC SAP). When the DS delivers the
63
64 MAC service tuples to an AP MLD through DSAF, the AP MLD then determines when and how to deliver
65 the MAC service tuples to the AP MLD’s MLD Upper MAC sublayer (via the MAC SAP).

96 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5 March 2022

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 97

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 8. PHY service specification

2
3
4
5
8.3 Detailed PHY service specifications
6
7 8.3.5 PHY SAP detailed service specification
8
9 8.3.5.12 PHY-CCA.indication
10
11
12 8.3.5.12.2 Semantics of the service primitive
13
14 Change the entry “primary” in Table 8-5 (The channel-list parameter entries)as follows:
15
16
17
18 Table 8-5—The channel-list parameter entries
19
20
21 Channel-list parameter entry Meaning
22
23 primary (#6940)In an HT STA that is neither a VHT STA nor an HE STA nor an
24 EHT STA, indicates that the primary channel is busy according to the rules
25 specified in 19.3.19.5.4 (CCA sensitivity in 20 MHz) and
26 19.3.19.5.5 (CCA sensitivity in 40 MHz)19.3.19.5.2 (CCA-Energy Detect
27 (CCA-ED)).
28 (#6940)In a VHT STA that is neithernot an HE STA nor an EHT STA,
29 indicates that the primary 20 MHz channel is busy according to the rules
30 specified in 21.3.18.5.3 (CCA sensitivity for signals occupying the
31 primary 20 MHz channel).
32 In a TVHT STA, indicates that the primary channel is busy according to
33 the rules specified in 22.3.18.6.3 (CCA sensitivity for signals occupying
34 the primary channel).
35 (#6940)In an HE STA that is not an EHT STA, indicates that the primary
36 20 MHz channel is busy according to the rules specified in
37 27.3.20.6.3 (CCA sensitivity for the primary 20 MHz channel).
38 In an EDMG STA, indicates that the primary 2.16 GHz channel is busy
39 according to the rules specified in 28.3.8 (CCA sensitivity).
40 (#6940)In an EHT STA, indicates that the primary 20 MHz channel is
41 busy according to the rules specified in 36.3.20.6.3 (CCA sensitivity for
42 occupying the primary 20 MHz channel).
43
44
45
46 Change the ninth paragraph as follows:
47
48 (#6940)If the STA is an HE STA or an EHT STA with an operating channel width greater than 20 MHz,
49 then the per20bitmap parameter is present; otherwise, it is absent. If present, the per20bitmap parameter in
50 an HE STA that is not an EHT STA is a bitmap where each bit represents the busy/idle status of a 20 MHz
51
52 subchannel in the operating channel width as defined in 27.3.20.6.5 (Per 20 MHz CCA sensitivity); the
53 per20bitmap parameter in an EHT STA is a bitmap where each bit represents the busy/idle status of a
54 20 MHz subchannel in the operating channel width as defined in 36.3.20.6.4 (Per 20 MHz CCA sensitivity).
55
56 Insert the following NOTE as the tenth paragraph of the subclause:
57
(#6940)NOTE—When CCA-Energy Detect is required, the primitive in an HT STA that is neither a VHT STA nor an
58
HE STA nor an EHT STA indicates a medium busy condition as defined in 19.3.19.5.2 (CCA-Energy Detect (CCA-
59
ED)); the primitive in a VHT STA that is neither an HE STA nor an EHT STA indicates a medium busy as defined in
60
21.3.18.5.2 (CCA sensitivity for operating classes requiring CCA-ED); the primitive in an HE STA that is not an EHT
61
STA indicates a medium busy as defined in 27.3.20.6.2 (CCA sensitivity for operating classes requiring CCA-ED); the
62
primitive in an EHT STA indicates a medium busy as defined in 36.3.20.6.2 (CCA sensitivity for operating classes
63
requiring CCA-ED).
64
65

98 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 8.3.5.12.3 When generated

2
3
4 Change the first paragraph as follows:
5
6 For Clause 15 (DSSS PHY specification for the 2.4 GHz band designated for ISM applications) to
7 Clause 20 (Directional multi-gigabit (DMG) PHY specification) PHYs, this primitive is generated within
8 aCCATime of the occurrence of a change in the status of the primary channel from channel idle to channel
9
10 busy or from channel busy to channel idle or when the entries of the channel-list parameter change. For
11 Clause 21 (Very high throughput (VHT) PHY specification) and Clause 22 (Television very high
12 throughput (TVHT) PHY specification) PHYs, this primitive is generated when the status of the channel(s)
13 changes from channel idle to channel busy or from channel busy to channel idle or when the entries of the
14 channel-list parameter change. This includes the period of time when the PHY is receiving data. For
15
16 Clause 27 (High-efficiency (HE) PHY specification) and Clause 36 (Extremely high throughput (EHT)
17 PHY specification) PHYs(#6940), this primitive is generated when the status of the channel(s) changes from
18 channel idle to channel busy or from channel busy to channel idle, when the entries of the channel-list
19 parameter change, or when the per20bitmap parameter changes. The timing of PHY-CCA.indication
20 primitives related to transitions on secondary channel(s) is PHY specific. The timing of PHY-
21
22 CCA.indication primitives related to transitions on secondary channel(s) is PHY specific. Refer to specific
23 PHY clauses for details about CCA behavior for a given PHY.
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 99

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

100 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 9. Frame formats
2
3
4 9.2 MAC frame formats
5
6
7 9.2.4 Frame fields
8
9 9.2.4.1 Frame Control field
10
11
12 9.2.4.1.3 Type and Subtype fields
13
14 Change the following entry of Table 9-1 (Valid type and subtype combinations) (only relevant
15 row shown):
16
17
18
19 Table 9-1—Valid type and subtype combinations
20
21
22 Type value Type Subtype value
Subtype description
23 B3 B2 description B7 B6 B5 B4
24
01 Control 0101 (#4292)VHT/HE NDP Announcement
25
26
27
28 9.2.4.1.8 More Data subfield
29
30
31 Change the second paragraph as follows:
32
33 (#1497)(#3379)(#1001)A non-DMG and non-S1G STA uses the More Data subfield to indicate to a STA in
34 PS mode that more BUs are buffered for that STA at the AP. The More Data subfield is valid in individually
35
36 addressed Data or Management frames transmitted by an AP to a STA in PS mode. The More Data subfield
37 is set to 1 to indicate that at least one additional buffered BU is present for the same STA (see 11.2.3.6 (AP
38 operation)).
39
40 (#1497)(#3379)(#1001)For a non-AP MLD, an AP affiliated with an AP MLD uses the More Data subfield
41
42 to indicate to a non-AP STA in PS mode affiliated with the non-AP MLD that more BUs, corresponding to
43 Data frames with TIDs that are mapped to this link by the most recent DL TID-to-link mapping (negotiated
44 TID-to-link mapping or default link mapping, see 35.3.7.1 (TID-to-link mapping)) or Management frames
45 that are not measurement MMPDUs (see 35.3.12.4 (Traffic indication)) are buffered for the non-AP MLD at
46 the AP MLD (see 35.3.7.1.6 (Use of More Data subfield by an MLD)). The More Data subfield is valid in
47
48 individually addressed Data or Management frames transmitted by an AP (#6581)affiliated with an AP
49 MLD to a STA (#6581)affiliated with a non-AP MLD that is in PS mode and in certain control frames as
50 defined below.
51
52
53
Change the fourth paragraph as follows:
54
55 (#1497)(#3379)(#1001)The AP can set the More Data subfield to 1 to indicate that it has a pending transmis-
56 sion for the STA or, if the AP is affiliated with an AP MLD, to indicate that the AP MLD has additional
57 buffered BUs corresponding to frames with TIDs that are mapped to the link on which the AP operates by
58
59
the most recent DL TID-to-link mapping (negotiated TID-to-link mapping or default mode mapping, see
60 35.3.7.1 (TID-to-link mapping)) or Management frames that are not measurement MMPDUs (see 35.3.12.4
61 (Traffic indication)) if it has received a frame that contains a QoS Info field in which the More Data Ack
62 subfield is equal to 1 from the STA and one of the following conditions is true:
63
64 — The STA is in PS mode and has one or more ACs that are delivery enabled (see 11.2.2.6 (AP opera-
65 tion during the CP)).

Copyright © 2022 IEEE. All rights reserved. 101

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — The STA is in PS mode and is a TWT requester or a TWT scheduled STA (see 26.8 (TWT opera-
2 tion))
3
4
5 9.2.4.5 QoS Control field
6
7 9.2.4.5.4 Ack Policy Indicator subfield
8
9
10
Change Table 9-13 (Ack policy) as follows (only relevant rows shown):
11
12
13 Table 9-13—Ack policy
14
15
16 Bits in QoS
17 Control field
Ack policy Other conditions Meaning
18
19 Bit 5 Bit 6
20
21 No 0 1 Bit 6 of the Frame Con- There might be a response frame to the frame that is
22 Explicit trol field (see 9.2.4.1.3 received, but it is neither the Ack frame nor any Data frame
23 Acknowl- (Type and Subtype of subtype +CF-Ack.
24 edgment fields)) is equal to 1 and This ack policy is used for QoS CF-Poll and QoS CF-Ack
25 the frame is not carried +CF-Poll Data frames.
26 in an HE MU PPDU,
27 HE SU PPDU or HE ER NOTE—Bit 6 of the Frame Control field (see 9.2.4.1.3 (Type
28 SU PPDU that contains and Subtype fields)) indicates the absence of a Frame Body
29 a frame that solicits a field in a QoS Data frame. If equal to 1, the QoS Data frame
30 response in an HE TB contains no Frame Body field, and any response is generated
31 PPDU (#7828)and the in response to a QoS CF-Poll or QoS CF-Ack +CF-Poll
32 frame is not carried in frame, but does not signify an acknowledgment of data.
33 an EHT MU PPDU that
34 contains a frame that
35 solicits a response in an
36 EHT TB PPDU.
37
38 PSMP Ack 0 1 Bit 6 of the Frame Con- The acknowledgment for a frame indicating PSMP Ack
39 trol field (see 9.2.4.1.3 when it appears in a PSMP downlink transmission time
40 (Type and Subtype (PSMP-DTT) is to be received in a later PSMP uplink trans-
41 fields) is equal to 0 and mission time (PSMP-UTT).
42 the frame is not carried The acknowledgment for a frame indicating PSMP Ack
43 in an HE MU PPDU, when it appears in a PSMP-UTT is to be received in a later
44 HE SU PPDU or HE ER PSMP-DTT.
45 SU PPDU that contains See 10.30.2.7 (PSMP acknowledgment rules).
46 a frame that solicits a
47 response in an HE TB
48 PPDU (#7828)and the
49 frame is not carried in
50 an EHT MU PPDU that
51 contains a frame that
52 solicits a response in an
53 EHT TB PPDU.
54
55
56
57
58
59
60
61
62
63
64
65

102 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 9-13—Ack policy (continued)

2
3
4 Bits in QoS
5 Control field
6 Ack policy Other conditions Meaning
7 Bit 5 Bit 6
8
9 HETP Ack 0 1 The frame is carried in The addressed recipient returns an Ack, Compressed Block-
10 an HE MU PPDU, HE Ack, or Multi-STA BlockAck frame carried in an HE/EHT
11 SU PPDU or HE ER SU TB PPDU a SIFS after the PPDU, subject to reception of a
12 PPDU that contains a triggering frame in the PPDU, as defined in
13 frame that solicits a 10.3.2.13.2 (Acknowledgment procedure for DL MU PPDU
14 response in an HE TB in MU format), and 26.5.2 (UL MU operation), and 35.5.2
15 PPDU (EHT UL MU operation(#1088)).
16
17 (#7828)Or the frame is
18 carried in an EHT MU
19 PPDU that contains a
20 frame that solicits a
21 response in an EHT TB
22 PPDU.
23
24
25
26 9.2.4.5.6 Queue Size subfield
27
28 Change the first paragraph as follows:
29
30
31 The Queue Size subfield is an 8-bit field that indicates the amount of buffered traffic for a given TC or TS at
32 the non-AP non-HE STA sending the frame that contains this subfield and the amount of buffered traffic for
33 a given TC or TS at the non-AP HE STA for transmission to the HE STA identified by the receiver address
34
35
of the frame that contains this subfield. The Queue Size subfield is present in QoS Data frames with bit 4 of
36 the QoS Control field set to 1 sent by a non-AP STAs and in QoS Null frames with bit 4 of the QoS Control
37 field set to 1 sent by a non-AP HE STA. The AP might use information contained in the Queue Size subfield
38 to determine the TXOP duration assigned to the STA or to determine the UL resources assigned to the non-
39 AP HE STA (see 26.5.2 (UL MU operation) (#7828)and 35.5.2 (EHT UL MU operation(#1088))).
40
41
42 9.2.4.6 HT Control field
43
44 9.2.4.6.4 HE variant
45
46
47 Update Table 9-25 (Control ID subfield values) as follows:
48
49
50 Table 9-25—Control ID subfield values
51
52
53 Length of the
54 Control Control Content of the Control Information
55 Meaning
ID value Information subfield
56 subfield (bits)
57
58 0 Triggered response scheduling (TRS) 26 See 9.2.4.6a.1 (TRS Control)
59
60 1 Operating mode (OM) 12 See 9.2.4.6a.2 (OM Control)
61 2 HE link adaptation (HLA) 26 See 9.2.4.6a.3 (HLA Control)
62
63 3 Buffer status report (BSR) 26 See 9.2.4.6a.4 (BSR Control)
64
65 4 UL power headroom (UPH) 8 See 9.2.4.6a.5 (UPH Control)

Copyright © 2022 IEEE. All rights reserved. 103

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 9-25—Control ID subfield values (continued)

2
3
4 Length of the
5 Control Control Content of the Control Information
Meaning
6 ID value Information subfield
7 subfield (bits)
8
9 5 Bandwidth query report (BQR) 10 See 9.2.4.6a.6 (BQR Control)
10 6 Command and status (CAS) 8 See 9.2.4.6a.7 (CAS Control)
11
12 7 EHT operating mode (EHT OM) 6 See 9.2.4.7.8 (EHT OM Control)
13
14 8 Single response scheduling (SRS) 10 See 9.2.4.7.9 (SRS Control)
15 9 AP assistance request (AAR) 20 See 9.2.4.7.10 (AAR Control)
16 (#4136)
17
18 10–14 Reserved
19 7–14
20 (#4136)
21
22 15 Ones need expansion surely (ONES) 26 Set to all 1s
23
24
25 Insert the following new subclause after 9.2.4.7.7 (CAS Control)
26
27
28 9.2.4.7 Control subfield variants of an A-Control subfield
29
30
31 9.2.4.7.8 EHT OM Control
32
33 The Control Information subfield in an EHT OM Control subfield contains information related to the OM
34
changes for bandwidth of 320 MHz, Tx NSTS larger than 8, and Rx NSS larger than 8 for the STA transmit-
35
36 ting the frame containing this information (see 35.10 (Operating mode indication)). The format of the sub-
37 field is shown in Figure 9-33a (Control Information subfield format in an EHT OM Control subfield).
38
39
40 B0 B1 B2 B3 B5
41
42 Rx NSS Channel Width Tx NSTS
Reserved
43 Extension Extension Extension
44
45 Bits: 1 1 1 3
46
47 Figure 9-33a—Control Information subfield format in an EHT OM Control subfield
48
49
50 If the operating channel width of the STA is greater than 80 MHz, then the Rx NSS Extension subfield in the
51 EHT OM Control subfield (#6574)combined with the Rx NSS subfield in the OM Control subfield
52 (#7551)indicates N SS – 1 , where N SS is the maximum number of spatial streams that the STA supports in
53 reception(#5893)(#4138) for PPDU bandwidths less than or equal to 80 MHz.
54
55
56 If the operating channel width of the STA is less than or equal to 80 MHz, then the Rx NSS Extension sub-
57 field in the EHT OM Control subfield (#6574)combined with the Rx NSS subfield in the OM Control sub-
58 field (#7552)indicates N SS – 1 , where N SS is the maximum number of spatial streams (#5893)(#4138)that
59
60 the STA supports in reception.
61
62
63
64
65

104 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The encoding of the Rx NSS Extension subfield in EHT OM Control subfield combined with the Rx NSS
2 subfield in OM Control subfield is described in Table 9-33a (The encoding of the Rx NSS Extension sub-
3
field in EHT OM Control subfield combined with the Rx NSS subfield in OM Control subfield(#4138)).
4
5
6
7 Table 9-33a—The encoding of the Rx NSS Extension subfield in EHT OM Control subfield
8 combined with the Rx NSS subfield in OM Control subfield(#4138)
9
10
11 Rx NSS Extension subfield Rx NSS subfield
Indication of the N SS
12 in EHT OM Control subfield in OM Control subfield
13
14 0 0 1
15 0 1 2
16
17 0 2 3
18
19 0 3 4
20 0 4 5
21
22 0 5 6
23
24 0 6 7
25 0 7 8
26
27 1 0 9
28
29 1 1 10
30 1 2 11
31
32 1 3 12
33
34 1 4 13
35 1 5 14
36
37 1 6 15
38
1 7 16
39
40
41
42
43 (#7936)An EHT STA with dot11EHTBaseLineFeaturesImplementedOnly equal to true does not set Rx NSS
44 Extension subfield in EHT OM Control subfield to 1.
45
46
47 If the operating channel width of the STA is greater than 80 MHz, then the maximum number of spa-
48 tial(#8064) streams that the STA supports in reception for non-EHT PPDU bandwidths greater than 80 MHz
49 is defined in 26.9 (Operating mode indication).
50
51
52 (#6606)If the operating channel width of the STA is greater than 80 MHz, then the maximum number of
53 spatial streams that the STA supports in reception for EHT PPDU bandwidths greater than 80 MHz is
54 defined in 35.10 (Operating mode indication).
55
56
57 The Channel Width Extension subfield in EHT OM Control subfield (#6574)combined with the Channel
58 Width subfield in OM Control subfield indicates the operating channel width supported by the STA for both
59 reception and transmission.
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 105

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The encoding of the Channel Width Extension subfield in EHT OM Control subfield (#6574)combined with
2 the Channel Width subfield in OM Control subfield is described in Table 9-33b (The encoding of the Chan-
3
nel Width Extension subfield in EHT OM Control subfield combined with the Channel Width subfield in
4
5 OM Control subfield(#6574)).
6
7
8 Table 9-33b—The encoding of the Channel Width Extension subfield in EHT OM Control
9 subfield combined with the Channel Width subfield in OM Control subfield(#6574)
10
11
12 Channel Width Extension
13 Channel Width subfield in Indication of the operating
subfield in EHT OM Control
14 OM Control subfield channel width
subfield
15
16 0 0 Primary 20 MHz
17
18 0 1 Primary 40 MHz
19 0 2 Primary 80 MHz
20
21 0 3 Primary 160 MHz
22
23 1 0 (#4137)320 MHz
24 1 1–3 Reserved
25
26
27
28
29
The Tx NSTS Extension subfield in EHT OM Control subfield (#6574)combined with the Tx NSTS subfield
30 in OM Control subfield indicates N STS – 1 , where N STS is the maximum number of space-time streams
31 (#5893)(#4138)that the STA supports in transmission.
32
33
34 The encoding of the Tx NSTS Extension subfield in EHT OM Control subfield combined with the Tx NSTS
35 subfield in OM Control subfield is described in Table 9-33c (The encoding of the Tx NSTS Extension sub-
36 field in EHT OM Control subfield combined with the Tx NSTS subfield in OM Control subfield(#4138)).
37
38
39
40 Table 9-33c—The encoding of the Tx NSTS Extension subfield in EHT OM Control subfield
41 combined with the Tx NSTS subfield in OM Control subfield(#4138)
42
43
44 Tx NSTS Extension subfield Tx NSTS subfield
Indication of the N SS
45 in EHT OM Control subfield in OM Control subfield
46
0 0 1
47
48 0 1 2
49
50 0 2 3
51
0 3 4
52
53 0 4 5
54
55 0 5 6
56 0 6 7
57
58 0 7 8
59
60 1 0 9
61 1 1 10
62
63 1 2 11
64
65 1 3 12

106 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 9-33c—The encoding of the Tx NSTS Extension subfield in EHT OM Control subfield
2 combined with the Tx NSTS subfield in OM Control subfield(#4138) (continued)
3
4
5 Tx NSTS Extension subfield Tx NSTS subfield
6 Indication of the N SS
in EHT OM Control subfield in OM Control subfield
7
8 1 4 13
9
10 1 5 14
11 1 6 15
12
13 1 7 16
14
15
16
17
(#7936)An EHT STA with dot11EHTBaseLineFeaturesImplementedOnly equal to true does not set Tx
18 NSTS Extension subfield in EHT OM Control subfield to 1.
19
(#6082)NOTE—EHT PHY does not support STBC. The terms “space-time stream” and “spatial stream” are equivalent
20
in EHT.
21
22
23 9.2.4.7.9 SRS Control
24
25 The Control Information subfield in an SRS Control subfield contains scheduling information for the non-
26 TB PPDU containing the control response to the PPDU carrying the MPDU(s) containing the SRS Control
27
28
subfield (see 35.3.16.5.2 (End time alignment of response PPDUs using SRC Control
29 field(#4229)))(#6380). The format of the subfield is shown in Figure 9-33b (Control Information subfield
30 format in an SRS Control subfield).
31
32
33 B0 B7 B8 B9
34
35 PPDU Response
Reserved
36 Duration
37
38 Bits: 8 2
39
40 Figure 9-33b—Control Information subfield format in an SRS Control subfield
41
42
43
The PPDU Response Duration subfield contains the duration of the solicited non-TB PPDU that carries the
44 control response frame that immediately follows the PPDU carrying the SRS Control subfield. The PPDU
45 Response Duration subfield is in units of 4 microseconds and is set as defined in 35.3.16.5.2 (End time
46 alignment of response PPDUs using SRC Control field(#4229))(#6380).
47
48
49
9.2.4.7.10 AAR Control
50
51 The Control Information subfield in an AAR Control subfield contains information of the link identifier(s)
52 of the assisting AP(s) affiliated with an AP MLD that are requested(#4140) to assist a non-AP STA affiliated
53 with a non-AP MLD, (#8065)belonging to (#7555)an NSTR link pair(#7554), to recover its medium syn-
54
55
chronization (35.3.16.8.3 (AP assisted medium synchronization recovery procedure)).
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 107

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The format of this subfield is shown in Figure 9-33c (Control Information subfield format in an AAR Con-
2 trol subfield(#4805)(#4141)).
3
4
5 B0 B15 B16 B19
6
7 Assisting AP Link ID
8 Reserved
Bitmap
9
10 Bits: 16 4
11
12 Figure 9-33c—Control Information subfield format in an AAR Control sub-
13 field(#4805)(#4141)
14
15
16 The Assisting AP Link ID Bitmap subfield in the AAR Control subfield indicates the link(s) associated
17 with(#7680) the link identifier(s) of the assisting AP(s) affiliated with an AP MLD. Each assisting AP is
18
solicited to transmit a Trigger frame to its associated non-AP STA that belongs to (#7555)the same NSTR
19
20 link pair as the non-AP STA that sent the AAR Control field(#4141)(#4805). A value of 1 in bit position i of
21 the Assisting AP Link ID Bitmap subfield means that the link ID i is the link identifier of the assisting AP
22 affiliated with the AP MLD. A value of 0 in bit position i of the Assisting AP Link ID Bitmap subfield
23 means that the link ID i is not the link identifier of the assisting AP affiliated with the AP MLD.
24
25
26 The bit in the Assisting AP Link ID Bitmap subfield, which corresponds to the AP to which the AAR Con-
27 trol field is addressed, is set to 0(#4142). The bit in position 15 of the Assisting AP Link ID Bitmap subfield
28 is reserved(#7341).
29
30
9.2.4.8 Frame Body field
31
32
33 9.2.4.8.1 General
34
35 Change Table 9-34 (Maximum data unit sizes (in octets) and durations (in microseconds)) as
36 follows:
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

108 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 9-34—Maximum data unit sizes (in octets) and durations (in microseconds)
2
3
4 Non-HT
5 non-VHT
EHT
6 non-HE non-S1G HT VHT HE S1G
PPDU DMG PPDU EDMG PPDU
7 non-DMG PPDU PPDU PPDU PPDU PPDU
(#6630)
8 and non-HT
9 duplicate PPDU
10
MMPDU 2304 2304 See See See See 2304 2304
11
size NOTE 1 NOTE 1 NOTE 1 NOTE 1
12
MSDU13 2304 2304 2304 2304 2304 2304 Without SAR Without SAR
size14 agreement: for agreement: for
15 the Basic A- the Basic A-
16 MSDU format, MSDU format,
17 it is equal to the it is equal to the
18 value of A- value of A-
19 MSDU size MSDU size
20 minus 14, or minus 14, or
21 minus 2 for the minus 2 for the
22 short A-MSDU short A-MSDU
23 format, if the format, if the
24 MPDU Limit MPDU Limit
25 subfield of the subfield of the
26 Extended Extended
27 MPDU MPDU
28 Capability field Capability field
29 of the DMG of the DMG
30 Capabilities Capabilities
31 element is element is
32 valid; valid;
33 otherwise, it is otherwise, it is
34 equal to 7920. equal to 7920.
35 With SAR With SAR
36 agreement: see agreement: see
37 NOTE 8. NOTE 8.
38
A-MSDU
39 3839 or 4065  3839 or See 2.4 GHz See See Without SAR Without SAR
size40 (see NOTE 2)  7935  NOTE 3 band NOTE 3 NOTE 3 agreement: agreement:
41 (HT STA, see also (see also  (#6630)of indirectly indirectly
42 Table 9- Table 9- a non- limited by the limited by the
43 221 (Subfields of 221 (Subf EHT value of the value of the
44 the HT Capability ields of STA:  MPDU Limit MPDU Limit
45 Information the HT 3839 or subfield in the subfield in the
46 field)),  Capability 7935  Extended Extended
47 or  Informati (see also  MPDU MPDU
48 N/A (non-HT on field)) Table 9- Capability field Capability field
49 STA, see also 221 (Subf of the DMG of the DMG
50 10.11 (A-MSDU ields of Capabilities Capabilities
51 operation)) the HT element, if the element, if the
52 Capability subfield is subfield is
53 Informati valid; valid;
54 on field)) otherwise, it is otherwise, it is
55 equal to 7935. equal to 7935.
56 Otherwise With SAR With SAR
57 : see agreement: see agreement: see
58 NOTE 3 NOTE 8. NOTE 8
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 109

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 9-34—Maximum data unit sizes (in octets) and durations (in microseconds) (continued)
2
3
4 Non-HT
5 non-VHT
EHT
6 non-HE non-S1G HT VHT HE S1G
PPDU DMG PPDU EDMG PPDU
7 non-DMG PPDU PPDU PPDU PPDU PPDU
(#6630)
8 and non-HT
9 duplicate PPDU
10
MPDU See NOTE 4 See 3895 or 2.4 GHz 3895 or 3895 or (11ay)The The value
11
size NOTE 5 7991 or band 7991 or 7991 (see value indicated indicated in the
12
11 454  (#6630)of 11 454 also in the MPDU MPDU Limit
13
(see also  a non- (see also Table 9- Limit subfield subfield of the
14
Table 9- EHT Table 9- 342 (Subf of the Extended Extended
15
310 (Subf STA:  310 (Subf ields of MPDU MPDU
16
ields of see NOTE ields of the S1G Capability field Capability field
17
the VHT 5 the VHT Capabiliti of the DMG of the DMG
18
Capabiliti Capabiliti es Capabilities Capabilities
19
es Otherwise es Informati element if the element if the
20
Informati : 3895 or Informati on field)) subfield is subfield is
21
on field)) 7991 or on field), valid; valid;
22
11 454 9.4.2.263 otherwise, as in otherwise, as in
23
(see also (HE 6 NOTE 5. NOTE 5.
24
Table 9- GHz Band
25
310 (Subf Capabiliti
26
ields of es
27
the VHT element),
28
Capabiliti and
29
es Table 9-
30
Informati 401k
31
on field), (Subfields
32
9.4.2.263 of the
33
(HE 6 EHT
34
GHz Band MAC
35
Capabiliti Capabiliti
36
es es
37
element), Informati
38
and on field))
39
Table 9-
40
401k See
41
(Subfields NOTE 9
42
of the
43
EHT
44
MAC
45
Capabiliti
46
es
47
Informati
48
on
49
field))(#6
50
630)
51
52
See
53
NOTE 7
54
55
56
57
58
59
60
61
62
63
64
65

110 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 9-34—Maximum data unit sizes (in octets) and durations (in microseconds) (continued)
2
3
4 Non-HT
5 non-VHT
EHT
6 non-HE non-S1G HT VHT HE S1G
PPDU DMG PPDU EDMG PPDU
7 non-DMG PPDU PPDU PPDU PPDU PPDU
(#6630)
8 and non-HT
9 duplicate PPDU
10
PSDU 212–1  216–1 4 692 480 6 500 631 15 523 20 797 160 218–1 222–1
11
size (see Table 15- (see  (~222.16)  (~222.63) 0 (~219.60) (see  (see 
12
5 (DSSS PHY Table 19- (see  (see (~223.89) (see Table 20- Table 28-
13
characteristics), 25 (HT Table 21- Table 27- (see Table 23- 30 (DMG PHY 12 (EDMG-
14
Table 16-4 (HR/ PHY 28 (VHT 54 (HE Table 36- 40 (S1G characteristics)) Header-A field
15
DSSS PHY characteri PHY PHY 70 (EHT PHY structure and
16
characteristics),  stics)) characteri characteri PHY characteri definition for an
17
Table 17- stics)) stics)) characteri stics)) SU PPDU) and 
18
21 (OFDM PHY stics)) Table 28-
19
characteristics), 19 (EDMG-
20
Table 18-5 (ERP Header-B field
21
characteristics)) structure and
22
definition))
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 111

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 9-34—Maximum data unit sizes (in octets) and durations (in microseconds) (continued)
2
3
4 Non-HT
5 non-VHT
EHT
6 non-HE non-S1G HT VHT HE S1G
PPDU DMG PPDU EDMG PPDU
7 non-DMG PPDU PPDU PPDU PPDU PPDU
(#6630)
8 and non-HT
9 duplicate PPDU
10
PPDU See NOTE 6 5484 5484 5484 5484 27 840 2000 2000
11
duration (HT_MF; (see  (see (see (see (see  (see 
12
see Table 21- Table 27- Table 36- Table 23- Table 20- Table 20-
13
10.27.4 (L 28 (VHT 54 (HE 70 (EHT 40 (S1G 30 (DMG PHY 30 (DMG PHY
14
_LENGT PHY PHY PHY PHY characteristics)) characteristics))
15
H and characteri characteri characteri characteri
16
L_DATA stics)) stics)) stics)) stics))
17
RATE
18
parameter
19
values for
20
HT-mixed
21
format
22
PPDUs))
23
or 10 000
24
(HT_GF;
25
see
26
Table 19-
27
25 (HT
28
PHY
29
characteri
30
stics))
31
32 1—No direct constraint on the maximum MMPDU size; indirectly constrained by the maximum MPDU size (see 9.3.3.1 (Format of
NOTE
33 Management frames)).
(PV0)
34 12
NOTE
35 2—Indirect constraint from the maximum PSDU size: 2 –1 octets minus the minimum QoS Data frame overhead (26 octets for the
MAC36 header and 4 octets for the FCS).
37 3—No direct constraint on the maximum A-MSDU size; indirectly constrained by the maximum MPDU size.
NOTE
38
39 4—No direct constraint on the maximum MPDU size; indirectly constrained by the maximum MSDU/MMPDU or (for HT STAs
NOTE
40 A-MSDU size.
only)
41
NOTE
42 5—No direct constraint on the maximum MPDU size; indirectly constrained by the maximum A-MSDU size.
43 6—No direct constraint on the maximum duration, but an L_LENGTH value above 2332 might not be supported by some receivers
NOTE
(see44NOTE 2 in 10.27.4 (L_LENGTH and L_DATARATE parameter values for HT-mixed format PPDUs)).
45
NOTE
46 7—The maximum MPDU size might be greater than the size declared as supported by the recipient if the MPDU is an HE Compressed
Beamforming/CQI
47 frame.
48
NOTE 8—No direct constraint on the maximum MSDU or A-MSDU size; indirectly constrained by the maximum PSDU size. Each MPDU
49 A-MPDU of the PSDU that contains the MSDU or A-MSDU generates an overhead of MPDU Header (26 bytes), FCS (4 bytes), GCMP
in an
50 (8 bytes), MIC (16 bytes), and MPDU delimiter (4 bytes).
Header
51
52
(#6630)NOTE 9—The maximum MPDU size might be greater than the size declared as supported by the recipient if the MPDU is an EHT
53
Compressed Beamforming/CQI frame.
54
55
56
57
58
59
60
61
62
63
64
65

112 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 9.2.5 Duration/ID field (QoS STA)

2
3
9.2.5.2 Setting for single and multiple protection under enhanced distributed channel
4
5 access (EDCA)
6
7 Change the second paragraph as follows:
8
9
The STA selects between single and multiple protection when it transmits the first frame of a TXOP. All
10
11 subsequent frames transmitted by the STA in the same TXOP use the same class of duration settings. A STA
12 always uses multiple protection in a TXOP that includes:
13 — Frames that have the RDG/More PPDU subfield equal to 1
14
15 — PSMP frames
16 — VHT/HE NDP Announcement frames(#4143), Beamforming Report Poll frames or BFRP Trigger
17
18 frames
19 — S1G Beacon frames
20
21 — Frames transmitted by an S1G STA with the TXVECTOR parameter RESPONSE INDICATION
22 equal to Long Response
23 — (#7772)MU-RTS TXS Trigger frame
24
25
26 Change the item a) 2) of the fourth paragraph as follows (not all lines shown):
27
28 The Duration/ID field is set as follows:
29
30
31 The Duration/ID field is determined as follows:
32 a) Single protection settings.
33
34 1) In an RTS frame that is not part of a dual clear-to-send (CTS) exchange and is not part of a
35 BDT exchange, the Duration/ID field is set to the estimated time, in microseconds, required to
36 transmit the pending frame, plus one CTS frame, plus one Ack or BlockAck frame if required,
37 plus any NDPs required, plus explicit feedback if required, plus applicable IFSs.
38
39 2) In an MU-RTS Trigger frame that is not an MU-RTS TXS Trigger frame(#7772), the Duration/
40 ID field is set to the estimated time, in microseconds, required to transmit the pending frame(s),
41 plus one CTS frame, plus the time to transmit the solicited HE TB PPDU if required, plus the
42 time to transmit the acknowledgment for the solicited HE TB PPDU if required, plus applicable
43
44
IFSs.
45
46
47 9.3 Format of individual frame types
48
49 9.3.1 Control frames
50
51
9.3.1.2 RTS frame format
52
53
54 Change the third paragraph as follows:
55
56
The TA field is the address of the STA transmitting the RTS frame or the bandwidth signaling TA of the
57
58 STA transmitting the RTS frame. In an RTS frame transmitted by an EHT STA that is a STA 6G with
59 320 MHz bandwidth support in a non-HT or non-HT duplicate format to another EHT STA (#4147)that is a
60 STA 6G, the scrambling sequence and SERVICE field carry the TXVECTOR parameters CH_BAND-
61 WIDTH_IN_NON_HT and DYN_BANDWIDTH_IN_NON_HT and the TA field is a bandwidth signaling
62
TA. (#4145)In an RTS frame transmitted by a VHT STA or an HE STA in a non-HT or non-HT duplicate
63
64 format to another VHT STA or HE STA, the The scrambling sequence carries the TXVECTOR parameters
65 CH_BANDWIDTH_IN_NON_HT and DYN_BANDWIDTH_IN_NON_HT (see 10.3.2.7 (VHT and SIG

Copyright © 2022 IEEE. All rights reserved. 113

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 RTS procedure)) and the TA field is a bandwidth signaling TA (#4145), when an RTS frame transmitted in
2 a non-HT or non-HT duplicate format in either one of the following cases:.
3
4 — from a VHT STA, an HE STA, an EHT STA that is not a STA 6G, or an EHT STA that is a STA 6G
5 without 320 MHz bandwidth support to another VHT STA, HE STA, or an EHT STA.(#4147)
6
7
8 9.3.1.5 PS-Poll frame format
9
10 9.3.1.5.1 General
11
12
13 Change the second paragraph as follows:
14
15 The BSSID (RA) field is set to the address of the STA contained in the AP. The TA field value is the address
16 of the STA transmitting the frame or a bandwidth signaling TA. In a PS-Poll frame transmitted by an EHT
17
18 STA that is a STA 6G with 320 MHz bandwidth support in a non-HT or non-HT duplicate format and where
19 the scrambling sequence and SERVICE field carry the TXVECTOR parameter CH_BAND-
20 WIDTH_IN_NON_HT, the TA field value is a bandwidth signaling TA. (#4145)In a PS-Poll frame trans-
21 mitted by a VHT STA, or an HE STA, an EHT STA that is not a STA 6G or an EHT STA that is a STA 6G
22 without 320 MHz bandwidth support in a non-HT or non-HT duplicate format and where the scrambling
23
24 sequence carries the TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT, the TA field value is a
25 bandwidth signaling TA.
26
27 9.3.1.6 CF-End frame format
28
29
30 Change the last paragraph as follows:
31 If transmitted by an EHT STA that is a STA 6G with 320 MHz bandwidth support to an EHT AP
32
33
(#4147)that is a STA 6G, the BSSID (TA) field is the address of the STA contained in the AP except that the
34 Individual/Group bit of the BSSID (TA) field is set to 1 in a CF-End frame in a non-HT or non-HT duplicate
35 format to indicate that the scrambling sequence and SERVICE field carry the TXVECTOR parameter
36 CH_BANDWIDTH_IN_NON_HT. (#4145)If transmitted by a non-DMG STA, the BSSID (TA) field is the
37 address of the STA contained in the AP, except that the Individual/Group bit of the BSSID (TA) field is set
38
39 to 1 in a CF-End frame transmitted in a non-HT or non-HT duplicate format (#5696)by a VHT STA to a
40 VHT AP, or an HE STA to an HE AP in a non-HT or non-HT duplicate format to indicate that the
41 scrambling sequence carries the TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT (#4145)in
42 either of the following cases:.
43
44 — from a VHT STA, an HE STA, an EHT STA that is not a STA 6G, or an EHT STA that is a STA 6G
45 without 320 MHz bandwidth support to a VHT AP, an HE AP, or an EHT AP.(#4147)
46
47 If transmitted by a DMG STA, the TA field is the MAC address of the STA transmitting the frame.
48
49 9.3.1.7 BlockAckReq frame format
50
51 9.3.1.7.1 Overview
52
53
54 Change the fourth paragraph as follows:
55
56
The TA field value is the address of the STA transmitting the BlockAckReq frame or a bandwidth signaling
57
58 TA. In a BlockAckReq frame transmitted by an EHT STA that is a STA 6G with 320 MHz bandwidth sup-
59 port in a non-HT or non-HT duplicate format and where the scrambling sequence and SERVICE field carry
60 the TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT, the TA field value is a bandwidth signaling
61 TA. (#4145)In a BlockAckReq frame transmitted by a VHT STA, or an HE STA, an EHT STA that is not a
62
STA 6G or an EHT STA that is a STA 6G without 320 MHz bandwidth support in a non-HT or non-HT
63
64 duplicate format and where the scrambling sequence carries the TXVECTOR parameter CH_BAND-
65 WIDTH_IN_NON_HT, the TA field value is a bandwidth signaling TA.

114 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 9.3.1.8 BlockAck frame format

2
3
4 9.3.1.8.2 Compressed BlockAck variant
5
6 Change Figure 9-54 (BA Information field format (Compressed BlockAck)) as follows:
7
8
9 Block Ack Starting Sequence Control Block Ack Bitmap
10
11 Octets: 2 8, or 32, 64, or 128
12
13 Figure 9-54—BA Information field format (Compressed BlockAck)
14
15
16 Change Table 9-38 (Fragment Number subfield encoding for the Compressed BlockAck vari-
17 ant) as follows:.
18
19
20
Table 9-38—Fragment Number subfield encoding for the Compressed BlockAck
21
22 variant
23
24
Fragment Number subfield Maximum number of
25 Block Ack
Fragmentation Level 3 MSDUs/A-MSDUs
26 Bitmap subfield
(ON/OFF) that can be
27 B3 B2–B1 B0 length (octets)
acknowledged
28
29 0 0 0 8 64
30
31 0 1 0 Reserved Reserved
32 OFF
33 0 2 0 32 256
34 0 3 0 Reserved Reserved
35
36 0 0 1 8 16
37
38 0 1 1 Reserved Reserved
ON
39 0 2 1 32 64
40
41 0 3 1 Reserved Reserved
42
43 1 0 0 64 512
44 1 1 0 OFF 128 1 024
45
46 1 2 and 3 0 Reserved Reserved
47
1 Any Any1 Reserved Reserved
48
49 NOTE—A Compressed BlockAck frame with B0 of the Fragment Number subfield set to 1 is not sent to an HE
50 STA whose Dynamic Fragmentation Support subfield in the HE Capabilities element it transmits is not set to 3
51 (see 26.3 (Fragmentation and defragmentation)).
52
53
54
55 Change the third last paragraph as follows:
56
57
58 If B0 of the Fragment Number subfield is 0 and B3 of the Fragment Number subfield is 0, the Block Ack
59 Bitmap subfield of the BA Information field of the Compressed BlockAck frame indicates the receive status
60 of up to 64 or 256 MSDUs and/or A-MSDUs depending upon the value of B2–B1 in the Fragment Number
61 subfield as shown in Table 9-38 (Fragment Number subfield encoding for the Compressed BlockAck vari-
62
ant). If B0 of the Fragment Number subfield is 0 and B3 of the Fragment Number subfield is 1, the Block
63
64 Ack Bitmap subfield of the BA Information field of the Compressed BlockAck frame indicates the receive
65 status of up to 512 or 1024 MSDUs and/or A-MSDUs depending upon the value of B2–B1 in the Fragment

Copyright © 2022 IEEE. All rights reserved. 115

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Number subfield as shown in Table 9-38 (Fragment Number subfield encoding for the Compressed Block-
2 Ack variant). Each bit that is equal to 1 in the compressed Block Ack Bitmap subfield acknowledges the
3
reception of a single MSDU or A-MSDU in the order of sequence number, with the first bit of the Block
4
5 Ack Bitmap subfield corresponding to the MSDU, A-MSDU, or fragment thereof with the sequence number
6 that matches the value of the Starting Sequence Number subfield of the Block Ack Starting Sequence Con-
7 trol subfield.
8
9
10 9.3.1.8.7 Multi-STA BlockAck variant
11
12 Change Figure 9-61 (Per AID TID Info subfield format if the AID11 subfield is not 2045) as
13 follows:
14
15
16 Block Ack Starting
17 AID TID Info Block Ack Bitmap
Sequence Control
18
19 0, 4, 8, 16, or 32, 64, or
Octets: 2 0 or 2
20 128
21
22 Figure 9-61—Per AID TID Info subfield format if the AID11 subfield is not 2045
23
24
25 Change the eleventh paragraph as follows:
26
27
If B0 of the Fragment Number subfield of the Block Ack Starting Sequence Control subfield is 0 and B3 of
28
29 the Fragment Number subfield of the Block Ack Starting Sequence Control subfield is 0, the BA Informa-
30 tion field of the Multi-STA BlockAck frame contains an 8-octet, 16-octet, 32-octet or 4-octet Block Ack Bit-
31 map subfield depending on B2–B1 of the Fragment Number subfield as defined in Table 9-40 (Fragment
32 Number subfield encoding for the Multi-STA BlockAck variant) indicating the receive status of up to 64,
33
128, 256 or 32 MSDUs (or fragments thereof) and/or A-MSDUs (or fragments thereof), respectively. If B0
34
35 of the Fragment Number subfield of the Block Ack Starting Sequence Control subfield is 0 and B3 of the
36 Fragment Number subfield of the Block Ack Starting Sequence Control subfield is 1, the BA Information
37 field of the Multi-STA BlockAck frame contains an 64-octet, or 128-octet Block Ack Bitmap subfield
38 depending on B2–B1 of the Fragment Number subfield as defined in Table 9-40 (Fragment Number subfield
39
encoding for the Multi-STA BlockAck variant) indicating the receive status of up to 512 or 1024 MSDUs
40
41 and/or A-MSDUs, respectively. Each bit that is equal to 1 in the Block Ack Bitmap subfield acknowledges
42 the reception of a single MSDU (or fragment thereof) or A-MSDU (or fragment thereof) in the order of
43 sequence number with the first bit of the Block Ack Bitmap subfield corresponding to the MSDU or A-
44 MSDU with the sequence number that matches the value of the Starting Sequence Number subfield of the
45
Block Ack Starting Sequence Control subfield.
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

116 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Change Table 9-40 (Fragment Number subfield encoding for the Multi-STA BlockAck variant)
2 as follows:.
3
4
5
6 Table 9-40—Fragment Number subfield encoding for the Multi-STA BlockAck variant
7
8
Fragment Number subfield Maximum number of
9 Block Ack
Fragmentation Level 3 MSDUs/A-MSDUs
10 Bitmap subfield
(ON/OFF) that can be
11 B3 B2–B1 B0 length (octets)
acknowledged
12
13 0 0 0 8 64
14
15 0 1 0 16 128
16 OFF
17 0 2 0 32 256
18 0 3 0 4 32
19
20 0 0 1 8 16
21
22 0 1 1 16 32
ON
23 0 2 1 32 64
24
25 0 3 1 4 8
26
27 1 0 0 64 512
28 1 1 0 OFF 128 1 024
29
30 1 2 and 3 0 Reserved Reserved
31
1 Any Any1 Reserved Reserved
32
33 NOTE—A Multi-STA BlockAck frame with B0 of the Fragment Number subfield set to 1 cannot be sent to an
34 HE STA unless the HE Capabilities element received from the HE STA has the Dynamic Fragmentation Support
35 subfield equal to 3 (see 26.3 (Fragmentation and defragmentation)).
36
37
38
39 Change the title of the subclause 9.3.1.19 as follows:
40
41
42 9.3.1.19 VHT/HE/Ranging/EHT NDP Announcement frame format
43
44
45 Change the first paragraph as follows:
46
47
48 (#5787)The VHT/HE/Ranging NDP Announcement frame has threefour variants, the VHT NDP Announce-
49 ment frame, the HE NDP Announcement frame, and the Ranging NDP Announcement frame, and the EHT
50
51 NDP Announcement frame. The threefour formats are distinguished by the setting of the NDP Announce-
52 ment TypeVariant subfield in the Sounding Dialog Token field.
53
54
55 Change the fourth and fifth paragraphs as follows:
56
57
58 (#5787)The VHT/HE/Ranging NDP Announcement frame contains at least one STA Info field. If the VHT/
59 HE/Ranging NDP Announcement frame contains only one STA Info field, then in the case of VHT or HE
60 NDP Announcement frames the RA field is set to the address of the STA that can provide feedback (see
61 10.37.5.2 (Rules for VHT sounding protocol sequences)), while in the case of Ranging NDP Announcement
62
frames, the RA address is set to the address of the RSTA or ISTA that is the intended recipient of the frame.
63
64 If the VHT/HE/Ranging NDP Announcement frame contains more than one STA Info field, then the RA
65 field is set to the broadcast address.

Copyright © 2022 IEEE. All rights reserved. 117

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#5787)The TA field is set to the address of the STA transmitting the VHT/HE/Ranging NDP Announce-
2 ment frame or the bandwidth signaling TA of the STA transmitting the VHT/HE/Ranging NDP Announce-
3
ment frame. In an EHT NDP Announcement frame transmitted by an EHT STA that is a STA 6G with
4
5 320 MHz bandwidth support in a non-HT or non-HT duplicate format and where the scrambling sequence
6 and SERVICE field carry the TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT, the TA field is
7 set to a bandwidth signaling TA(#5537). (#4145)In an VHT/HE/Ranging NDP Announcement frame trans-
8 mitted by a VHT STA, or an HE STA, an EHT STA that is not a STA 6G or an EHT STA that is a STA 6G
9
without 320 MHz bandwidth support in a non-HT or non-HT duplicate format and where the scrambling
10
11 sequence carries the TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT, the TA field is set to a
12 bandwidth signaling TA.
13
14 Change Figure 9-77 (Sounding Dialog Token field format(#5787)) as follows:
15
16
17 B0 B1 B2 B7
18
19 NDP Announcement Sounding Dialog Token
20 TypeVariant Number
21
22 Bits: 2 6
23
24 Figure 9-77—Sounding Dialog Token field format(#5787)
25
26
27 Change the seventh paragraph as follows:
28
29
(#5787)The setting of the NDP Announcement TypeVariant subfield in the Sounding Dialog Token field
30
31 identifies the variant of the NDP Announcement frame, refer to Table 9-42a (NDP Announcement frame
32 variant encoding).
33
34
35 Table 9-42a—NDP Announcement frame variant encoding
36
37
38 NDP Announcement TypeVariant
39 subfield(#5787)
40 NDP Announcement frame variant
41 B1 B0
42
43 0 0 VHT NDP Announcement frame
44
45 0 1 Ranging NDP Announcement frame
46 1 0 HE NDP Announcement frame
47
48 1 1 ReservedEHT NDP Announcement
49 frame(#5787)
50
51
52
53 Change the fourth and third last paragraphs as follows:
54
55 (#4150)In a broadcastan HE NDP Announcement frame that has more than one STA Info field with a value
56
57
other than 2047 in the AID11 field, the RA is a broadcast address and the following applies to each STA
58 Info subfield with a value other than 2047:
59 — If the Feedback Type subfield indicates SU or MU, the Nc subfield indicates the number of columns,
60
61
Nc , in the compressed beamforming feedback matrix and is set to Nc – 1
62 — If the Feedback Type subfield indicates CQI, the Nc subfield indicates the number of space-time
63 streams, Nc , in the CQI report and is set to Nc – 1
64
65 — (#4150)There is more than one STA Info field with a value other than 2047 in the AID11 field

118 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#4150)In an individually addressed HE NDP Announcement frame with a single STA Info field, the RA is
2 an individual address, the AID11 field in the STA Info field has a value other than 2047, andthe STA Info
3
field having a value in the AID11 field other than 2047, the Nc subfield is reserved.
4
5
6 Insert the following paragraphs at the end of the subclause:
7
8 The frame format of the EHT NDP Announcement frame is the same as the HE NDP Announcement frame
9
10
shown in Figure 9-80 (HE NDP Announcement frame format).
11
12 The Duration, RA, and TA fields are set as in a VHT NDP Announcement frame.
13
14 (#5787)The NDP Announcement Variant subfield is set to 3 to identify the frame as an EHT NDP
15
16 Announcement frame.
17
18 The Sounding Dialog Token Number field in the Sounding Dialog Token field contains a value selected by
19 the beamformer to identify the EHT NDP Announcement frame.
20
21
22 The format of a STA Info field in an EHT NDP Announcement frame is defined in Figure 9-80a (STA Info
23 field format in an EHT NDP Announcement frame). The EHT NDP Announcement frame does not contain
24 a STA Info field with the AID11 subfield larger than 2047(#1487).
25
26
27 B0 B10 B11 B19 B20 B21 B24 B25 B26 B27 B28 B29 B31
28
29 Partial BW
Nc Feedback
Disambigu Codebook
30 AID11 Reserved Index(#16 Type And Reserved
Info ation Size
39 Ng
31
32
33 Bits: 11 9 1 4 2 1 1 3
34
35 Figure 9-80a—STA Info field format in an EHT NDP Announcement frame
36
37 An EHT NDP Announcement frame contains at most one STA Info field per STA.
38
39
40 (#1487)AID11 subfield encoding in NDP Annoucement frame is defined in Table 9-42b (AID11 subfield
41 encoding in an NDP Announcement frame(#5788)(#1487)).
42
43
44
Table 9-42b—AID11 subfield encoding in an NDP Announcement
45
46 frame(#5788)(#1487)
47
48
NDP Announcement frame
49 AID subfield Description
variant applicability
50
51 0 STA Info field is addressed to the associated AP or mesh Applicable to any variant
52 AP or IBSS STA(#5538).
53
54 1–2007 STA Info field is addressed to an associated STA whose Applicable to any variant
55 AID is equal to the value in the AID11 subfield if the NDP
56 Announcement frame is not a Ranging variant.
57
58 STA Info field is addressed to an unassociated STA or an
59 associated STA whose RSID/AID is equal to the value in
60 the RSID11/AID11 subfield if the NDP Announcement
61 frame is a Ranging variant.
62
63 The value 2007 is reserved for EHT variant(#5789).
64
65 2008–2042 Reserved Not applicable to any variant

Copyright © 2022 IEEE. All rights reserved. 119

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 9-42b—AID11 subfield encoding in an NDP Announcement

2 frame(#5788)(#1487) (continued)
3
4
5 NDP Announcement frame
6 AID subfield Description
variant applicability
7
8 2043 STA Info field contains a sequence authentication code if Applicable only to ranging vari-
9 the NDP Announcement frame is a Ranging variant. ant(#5790)
10
11 This AID11 value is reserved otherwise.
12
13 2044 STA Info field contains a partial TSF if the NDP Applicable only to ranging vari-
14 Announcement frame is a Ranging variant. ant(#5790)
15
16 This AID11 value is reserved otherwise.
17 2045 STA Info field contains ranging measurement parameters if Applicable only to ranging vari-
18 the NDP Announcement frame is a Ranging variant. ant(#5790)
19
20 This AID11 value is reserved otherwise.
21
22 2046 Reserved Not applicable to any variant
23
24 2047 STA Info field contains a disallowed subchannel bitmap if Applicable only to HE variant
25 the NDP Announcement frame is an HE variant.
26
27 This AID11 value is reserved otherwise.
28
29
30 The AID11 subfield contains an identifier of a STA expected to process the following EHT sounding NDP
31 and prepare the sounding feedback.
32
33
34 The Partial BW Info subfield is defined in Figure 9-80b (Partial BW Info subfield format).
35
36
37 B0 B1 B8
38
39 Resolution Feedback Bitmap
40
41 Bits: 1 8
42
43 Figure 9-80b—Partial BW Info subfield format
44
45
46 The Resolution subfield in the Partial BW Info subfield indicates the resolution bandwidth for each bit in the
47 Feedback Bitmap subfield. The Feedback Bitmap subfield indicates the request of each resolution band-
48 width from the lowest frequency to the highest frequency with B1 indicating the lowest resolution band-
49 width. Each bit in the Feedback Bitmap subfield is set to 1 if the feedback is requested on the corresponding
50
51
resolution bandwidth.
52
53 When the bandwidth of the EHT NDP Announcement frame is less than 320 MHz, set the Resolution bit B0
54 to 0 to indicate a resolution of 20 MHz.
55
56 — When the bandwidth of the EHT NDP Announcement frame is equal to(#7389) 20 MHz, B1 is set to
57 1 to indicate the request of feedback on the 242-tone RU. B2–B8 are reserved and set to 0.
58
59
— When the bandwidth of the EHT NDP Announcement frame is equal to(#7389) 40 MHz, B1 and B2
60 indicate the request of feedback on each of the two 242-tone RUs from lower frequency to higher
61 frequency. B3–B8 are reserved and set to 0.
62
— (#5394)When the bandwidth of the PPDU carrying the EHT NDP Announcement frame is equal
63
64 to(#7389) 80 MHz, set the Resolution bit B0 to 0 to indicate a resolution of 20 MHz. If B1–B4 are all
65 set to 1, it indicates the feedback request on the 996-tone RU, otherwise B1–B4 indicate the request

120 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 of feedback on each of the four 242-tone RUs from lower frequency to higher frequency. B5–B8 are
2 reserved and set to 0.
3
4 — (#5394)When the bandwidth of the PPDU carrying the EHT NDP Announcement frame is equal
5 to(#7389) 160 MHz, set the Resolution bit B0 to 0 to indicate a resolution of 20 MHz. If B1–B4 are
6 all set to 1, it indicates the feedback request on the lower 996-tone RU, otherwise B1–B4 indicate the
7 request of feedback on each of four 242-tone RUs from lower frequency to higher frequency in the
8
9 lower 80 MHz. If B5–B8 are all set to 1, it indicates the feedback request on the upper 996-tone RU,
10 otherwise B5–B8 indicate the request of feedback on each of the four 242-tone RUs from lower fre-
11 quency to higher frequency in the upper 80 MHz.
12
— (#5394)When the bandwidth of the PPDU carrying the EHT NDP Announcement frame is equal
13
14 to(#7389) 320 MHz, set the Resolution bit B0 to 1 to indicate a resolution of 40 MHz. If B1 and B2
15 are both set to 1, it indicates the feedback request on the first 996-tone RU, otherwise B1 and B2
16 indicate the request of feedback on each of the two 484-tone RUs from lower frequency to higher
17 frequency in the first 80 MHz. If B3 and B4 are both set to 1, it indicates the feedback request on the
18
second 996-tone RU, otherwise B3 and B4 indicate the request of feedback on each of the two 484-
19
20 tone RUs from lower frequency to higher frequency in the second 80 MHz. If B5 and B6 are both set
21 to 1, it indicates the feedback request on the third 996-tone RU, otherwise B5 and B6 indicate the
22 request of feedback on each of the two 484-tone RUs from lower frequency to higher frequency in
23 the third 80 MHz. If B7 and B8 are both set to 1, it indicates the feedback request on the fourth 996-
24
tone RU, otherwise B7 and B8 indicate the request of feedback on each of the two 484-tone RUs
25
26 from lower frequency to higher frequency in the fourth 80 MHz. The feedback tone sets for each
27 484-tone RU is composed of the feedback tone sets of the two 242-tone RUs overlapping with the
28 484-tone RU.
29
30
The Partial BW Info subfield is defined in Table 9-42c (Settings for BW, Partial BW Info subfield in the
31
32 EHT NDP Announcement frame(#8157)). (#5395)Any values of the Partial BW Info subfield other than the
33 ones defined in Table 9-42c (Settings for BW, Partial BW Info subfield in the EHT NDP Announcement
34 frame(#8157)) are reserved.
35
36
37
Table 9-42c—Settings for BW, Partial BW Info subfield in the EHT NDP Announcement
38
39 frame(#8157)
40
41
Bandwidth of
42 Operating channel
Feedback the EHT NDP Partial BW Info subfield values in binary
43 width of the EHT
RU/MRU size Announcement format (B0 B1 B2 B3 B4 B5 B6 B7 B8)(#7921)
44 beamformee (MHz)
frame (MHz)
45
46 242 20 010000000 20, 40, 80, 160, 320
47
48 40 010000000, 001000000
49
50 80 010000000, 001000000, 000100000, 000010000 20, 80, 160, 320
51 160 010000000, 001000000, 000100000, 000010000,
52 000001000, 000000100, 000000010, 000000001
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 121

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 9-42c—Settings for BW, Partial BW Info subfield in the EHT NDP Announcement
2 frame(#8157) (continued)
3
4
5 Bandwidth of
6 Operating channel
Feedback the EHT NDP Partial BW Info subfield values in binary
7 width of the EHT
RU/MRU size Announcement format (B0 B1 B2 B3 B4 B5 B6 B7 B8)(#7921)
8 beamformee (MHz)
frame (MHz)
9
10 484 40 011000000 40, 80, 160, 320
11
12 80 011000000, 000110000 80, 160, 320
13 160 011000000, 000110000, 000001100, 000000011
14
15 320 110000000, 101000000, 100100000, 100010000,
16 100001000, 100000100, 100000010, 100000001
17
18 484+242 80 011100000, 011010000, 010110000, 001110000
19 160 011100000, 011010000, 010110000, 001110000,
20 000001110, 000001101, 000001011, 000000111
21
22 996 80 011110000
23
160 011110000, 000001111
24
25 320 111000000, 100110000, 100001100, 100000011
26
27 996+484 160 011111100, 011110011, 011001111, 000111111 160, 320
28
320 111100000, 111010000, 110110000, 101110000,
29
100001110, 100001101, 100001011, 100000111
30
31 996+484+242 160 011101111, 011011111, 010111111, 001111111,
32 011111110, 011111101, 011111011, 011110111
33
34 2996 160 011111111
35 320 111110000, 100001111
36
37 2996+484 320 111111000, 111110100, 111101100, 111011100, 320
38 110111100, 101111100, 100111110, 100111101,
39 100111011, 100110111, 100101111, 100011111
40
41 3996 320 111111100, 111110011, 111001111, 100111111
42 3996+484 320 111111110, 111111101, 111111011, 111110111,
43 111101111, 111011111, 110111111, 101111111
44
45 4996 320 111111111
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

122 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The Feedback Type And Ng and Codebook Size subfields for EHT TB sounding are defined in Table 9-44
2 (Feedback Type And Ng subfield and Codebook Size subfield encoding for HE and EHT TB sound-
3
ing(#7918)).
4
5
6
7 Table 9-44—Feedback Type And Ng subfield and Codebook Size subfield encoding for HE
8 and EHT TB sounding(#7918)
9
10
11 Codebook
Feedback Type And Ng
12 Size
13 Description
14 B25 B26 B28
15
16 0 0 0 SU, Ng = 4, quantization resolution (   ) = {4, 2}
17
18 0 0 1 SU, Ng = 4, quantization resolution (   ) = {6, 4}
19
20 0 1 0 SU, Ng = 16, quantization resolution (   ) = {4, 2}
21
22 0 1 1 SU, Ng = 16, quantization resolution (   ) = {6, 4}
23 1 0 0 MU, Ng = 4, quantization resolution (   ) = {7, 5}
24
25 1 0 1 MU, Ng = 4, quantization resolution (   ) = {9, 7}
26
27 1 1 0 CQI
28
29 1 1 1 MU, Ng = 16, quantization resolution (   ) = {9, 7}
30
31
32
33 The Feedback Type And Ng and Codebook Size subfields for EHT non-TB sounding are defined in
34 Table 9-45 (Feedback Type And Ng subfield and Codebook Size subfield encoding for HE and EHT non-TB
35 sounding(#7918)).
36
37
38
39 Table 9-45—Feedback Type And Ng subfield and Codebook Size subfield encoding for HE
40 and EHT non-TB sounding(#7918)
41
42
43 Codebook
Feedback Type And Ng
44 Size
Description
45
46 B25 B26 B28
47
48 0 Reserved Reserved SU
49
50 1 1 0 CQI
51
52
53
54 The Disambiguation subfield is set to 1.
55
NOTE—Setting the Disambiguation subfield to 1 prevents a non-EHT VHT STA from incorrectly(#4126) identifying
56
its AID in the EHT NDP Announcement frame. The Disambiguation subfield coincides with the MSB of the AID12 sub-
57
field of a VHT NDP Announcement frame if the EHT NDP Announcement field is parsed as VHT NDP Announcement
58
frame by a non-EHT VHT STA. The MSB of the AID12 subfield is always 0 since the maximum AID is 2007.
59
60
61 In (#4150)an EHT NDP Announcement frame, the RA is a broadcast address and the following applies:
62
— (#1639)If the Feedback Type And Ng subfield and the Codebook Size subfield indicate SU or MU,
63
64 the Nc Index subfield indicates the number of columns in the compressed beamforming feedback
65 matrix minus 1, Nc – 1 . Nc Index subfield values above 7 are reserved.

Copyright © 2022 IEEE. All rights reserved. 123

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — (#1639)If the Feedback Type And Ng subfield and the Codebook Size subfield indicate CQI, the Nc
2 Index subfield indicates the number of spatial streams in the CQI report minus 1, Nc – 1 . Nc Index
3
subfield values above 7 are reserved.
4
5 — (#4150)There is more than one STA Info field.
6
7 (#4150)(#1639)In an EHT NDP Announcement frame with a single STA Info field, the RA is an individual
8
9 address and the Nc index subfield is reserved.
10
11 9.3.1.22 Trigger frame format
12
13 9.3.1.22.1 General
14
15
16 Change the first paragraph as follows:
17
18 A Trigger frame (#4807)which is not an MU-RTS Trigger frame allocates resources for and solicits one or
19 more HE TB PPDU transmissions. An MU-RTS Trigger frame allocates resources for one or more PPDUs
20
21 that are not TB PPDU (see 35.2.1.2 (Triggered TXOP sharing procedure)). The Trigger frame also carries
22 other information required by the responding STA to send an HE TB PPDU (see 26.5.2 (UL MU opera-
23 tion)), an EHT TB PPDU (see 35.5.2 (EHT UL MU operation(#1088))), a non-HT PPDU or a non-HT dupli-
24 cate PPDU (see 26.2.6 (MU-RTS Trigger/CTS frame exchange procedure) and 35.2.1.2 (Triggered TXOP
25 sharing procedure)), or (#5200)an HE ranging NDP (see 11.21.6.4.3 (TB ranging measurement exchange))
26
27 in response to the Trigger frame.
28
29 Change the fourth paragraph as follows:
30
31
32 The RA field is set as follows:
33 — For a Trigger frame that is not a GCR MU-BAR, NFRP or MU-RTS Trigger frame, and that has one
34 User Info field that is not a Special User Info field (see 9.3.1.22.1.2.3 (Special User Info
35
field(#7899))) and the AID12 subfield of the User Info field contains the AID of a non-AP STA, the
36
37 RA field is set to the address of that STA
38 — For a Trigger frame that has at least one User Info field with the AID12 subfield that allocates an
39 RA-RU, the RA field is set to the broadcast address
40
41 — For a Trigger frame that is not a GCR MU-BAR Trigger frame and that has more than one User Info
42 field that is not a Special User Info field (see 9.3.1.22.1.2.3 (Special User Info field(#7899))), the RA
43 field is set to the broadcast address
44
45 — For a Trigger frame that is an NFRP Trigger frame or MU-RTS Trigger frame, the RA field is set to
46 the broadcast address
47
— For a Trigger frame that is a GCR MU-BAR Trigger frame, the RA field is set to the MAC address
48
49 of the group for which reception status is being requested
50
51 Insert a new child subclause of 9.3.1.22.1 as follows:
52
53
54 9.3.1.22.1.1 Common Info field
55
56 (#7378)(#5791)The Common Info field in a Trigger frame is interpreted differently by non-EHT non-AP
57 HE STAs and non-AP EHT STAs. A non-EHT non-AP HE STA interprets the Common Info field as HE
58
variant. A non-AP EHT STA interprets the Common Info field as HE variant if B54 and B55 in the Com-
59
60 mon Info field are equal to 1; and interprets the Common Info field as EHT variant otherwise.
61
62
63
64
65

124 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Move the sixth paragraph of subclause 9.3.1.22.1 as the second paragraph of this child sub-
2 clause and change as follows:
3
4
5 (#4104)The HE variant Common Info field is defined in Figure 9-88 (HE variant Common Info field
6 format(#4104)).
7
8
9
10 B0 B3 B4 B15 B16 B17 B18 B19 B20 B21 B22 B23 B25
11
12 Number Of HE-
13 Trigger UL CS GI And HE- MU-MIMO LTF Symbols
More TF UL BW LTF Type HE-LTF
14 Type Length Required (#4502) Mode And Midamble
15 Periodicity
16
17 Bits: 4 12 1 1 2 2 1 3
18
19
20
21 B26 B27 B28 B33 B34 B35 B36 B37 B52 B53 B54 B62
22
23
LDPC
24 UL Extra AP Tx Pre-FEC PE UL Spatial UL HE-
25 Padding Doppler SIG-A2
STBC Symbol Power Factor Disambiguity Reuse Reserved
26 Segment
27
28 Bits: 1 1 6 2 1 16 1 9
29
30
31
32
B63
33
34
Trigger
35 Dependent
36 Reserved
Common
37 Info
38
39 Bits: 1 variable
40
41
42 Figure 9-88—HE variant Common Info field format(#4104)
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 125

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Insert the following paragraph and figure as the third paragraph of this child subclause:
2
3
4 (#4104)The EHT variant Common Info field is defined in Figure 9-88a (EHT variant Common Info field
5 format(#4104)).
6
7
8
9 B0 B3 B4 B15 B16 B17 B18 B19 B20 B21 B22 B23 B25
10
11 GI And HE/ Number Of HE/
12 EHT-LTF Type/ Reserved
Trigger UL More CS UL BW Triggered TXOP (#4503)(# EHT-LTF
13 Type Length TF Required
Sharing Mode 5439)
Symbols
14 (#5439)(#5794)
(#4502)(#5439)
15
16 Bits: 4 12 1 1 2 2 1 3
17
18
19
20
21 B26 B27 B28 B33 B34 B35 B36 B37 B52 B53 B54
22
23 LDPC Extra Pre-FEC Reserved
Reserved Symbol AP Tx Padding PE UL Spatial (#4503)(# HE/EHT
24 (#4503) Power Disambiguity Reuse P160
Segment Factor 5439)
25
26
27 Bits: 1 1 6 2 1 16 1 1
28
29
30
31 B55 B56 B62 B63
32
33 Special Trigger
EHT
34 User Info
Reserved Reserved
Dependent
35 Field Flag Common
(#4340)
36 (#4327) Info
37
38 Bits: 1 7 1 variable
39
40 Figure 9-88a—EHT variant Common Info field format(#4104)
41
42
43
44 Insert the following NOTE as the fourth paragraph of this child subclause:
45
46 (#4503)(#5439)NOTE—For backward compatibility with HE variant Common Info field, an EHT AP with dot11EHT-
47 BaseLineFeaturesImplementedOnly equal to true sets B22, B26, B53, and B63 to 0 and sets B56–B62 to 1 in the EHT
48 variant Common Info field.
49
50
Insert the following paragraph as the fifth paragraph of this child subclause:
51
52 (#4097)The HE variant Common Info field and the EHT variant Common Info field share the encoding for
53 the Trigger Type, UL Length, More TF, CS Required, LDPC Extra Symbol Segment, AP TX Power, Pre-
54 FEC Padding Factor, PE Disambiguity, and Trigger Dependent Common Info subfields.
55
56
57
58
59
60
61
62
63
64
65

126 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Move the seventh paragraph of subclause 9.3.1.22.1 as the sixth paragraph of this child sub-
2 clause:
3
4
5 The Trigger Type subfield identifies the Trigger frame variant and its encoding is defined in Table 9-46
6 (Trigger Type subfield encoding).
7
8
9
10 Table 9-46—Trigger Type subfield encoding
11
12
13 Trigger Type
Trigger frame variant
14 subfield value
15
16 0 Basic
17
18 1 Beamforming Report Poll (BFRP)
19 2 MU-BAR
20
21 3 MU-RTS
22
23 4 Buffer Status Report Poll (BSRP)
24
25 5 GCR MU-BAR
26
27 6 Bandwidth Query Report Poll (BQRP)
28 7 NDP Feedback Report Poll (NFRP)
29
30 8-15 Reserved
31
32
33
34 Move the eighth paragraph of subclause 9.3.1.22.1 as the seventh paragraph of this child sub-
35
36 clause and change as follows:
37
38 The UL Length subfield of the Common Info field indicates the value of the L-SIG LENGTH field of the
39
40 solicited HE TB PPDU. The UL Length subfield is set:
41
— As defined in 26.5.2.2.4 (Allowed settings of the Trigger frame fields and TRS Control subfield) if
42
43 the solicited PPDU is an HE TB PPDU.
44
45
— As defined in 35.5.2.2.4 (Allowed settings of the Trigger frame fields and TRS Control subfield) if
46 the solicited PPDU is an EHT TB PPDU.
47
48
49
Move the ninth, tenth, and eleventh paragraphs of subclause 9.3.1.22.1 as the eighth, ninth, and
50 tenth paragraphs of this child subclause, and change as follows:
51
52
The More TF subfield of the Common Info field indicates whether or not a subsequent Trigger frame is
53
54 scheduled for transmission. The More TF subfield is set as defined in 26.8.2 (Individual TWT agreements)
55 and 26.8.3.2 (Rules for TWT scheduling AP).
56
57
58 The CS Required subfield of the Common Info field is set to 1 to indicate that the STAs identified in the
59 User Info fields are required to use ED to sense the medium and to consider the medium state and the NAV
60 in determining whether or not to respond. The CS Required subfield is set to 0 to indicate that the STAs
61 identified in the User Info fields are not required to consider the medium state or the NAV in determining
62
whether or not to respond. See 26.5.2.3 (Non-AP STA behavior for UL MU operation)(#4504), and
63
64 26.5.2.5 (UL MU CS mechanism), 35.5.2.3 (Non-AP STA behavior for UL MU operation), and 35.5.2.4
65 (UL MU CS mechanism for EHT STAs) for details.

Copyright © 2022 IEEE. All rights reserved. 127

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The UL BW subfield of the (#5507)HE variant Common Info field indicates the bandwidth in the HE-SIG-
2 A of the HE TB PPDU and is defined in Table 9-47 (UL BW subfield encoding).
3
4
5
6 Table 9-47—UL BW subfield encoding
7
8
9 UL BW
10 subfield Description
11 value
12
13 0 20 MHz
14 1 40 MHz
15
16 2 80 MHz
17
18 3 80+80 MHz or 160 MHz
19
20
21
22 Insert the following paragraph and NOTE as the 11th and 12th paragraphs of this child sub-
23
24 clause:
25
26 The UL BW subfield of the (#5507)EHT variant Common Info field along with the UL BW Extension sub-
27
28 field of the Special User Info field indicates the bandwidth in the U-SIG field(#5657) of the EHT TB PPDU
29 and is defined in Table 9-53c (UL Bandwidth Extension subfield encoding).
30
31 (#4505)NOTE— 80+80 MHz is not applicable to EHT TB PPDU.
32
33
34
Move the 12th paragraph of subclause 9.3.1.22.1 as the 13th paragraph of this child subclause
35 and change as follows:
36
37 (#4502)(#5439)The GI And HE-LTF Type subfield or GI And HE/EHT-LTF Type subfield of the Common
38
39 Info field indicates the GI and HE/EHT-LTF type of the HE or EHT TB PPDU response. The GI And HE-
40 LTF Type subfield or GI And HE/EHT-LTF Type subfield encoding is present in a Trigger frame that solic-
41 its a TB PPDU response and its encoding is defined in Table 9-48 (GI And HE/EHT-LTF Type subfield
42 encoding). The Triggered TXOP Sharing Mode subfield in EHT variant Common Info field indicates the
43 triggered TXOP sharing mode as shown in Table 9-53e (TXOP Sharing Mode subfield encoding). The Trig-
44
45 gered TXOP Sharing Mode subfield is present in an (#5116)MU-RTS Trigger frame and is defined in
46 9.3.1.22.5 (MU-RTS Trigger frame format).
47
48
49 Table 9-48—GI And HE/EHT-LTF Type subfield encoding
50
51
52 GI And HE/EHT-LTF
53 Description
Type subfield value
54
55 0 1 HE/EHT-LTF + 1.6 µs GI
56
57 1 2 HE/EHT-LTF + 1.6 µs GI
58
59 2 4 HE/EHT-LTF + 3.2 µs GI
60
61 3 Reserved
62
63
64
65

128 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Move the 13th and 14th paragraphs of subclause 9.3.1.22.1 as the 14th and 15th paragraphs of
2 this child subclause and change as follows:
3
4
5 (#4503)(#5439)The MU-MIMO HE-LTF Mode subfield of the HE variant Common Info field indicates the
6 HE-LTF mode for an HE TB PPDU that has an RU that spans the entire bandwidth and that is assigned to
7 more than one non-AP STA (i.e., for UL MU-MIMO) when the GI And HE-LTF Type subfield of the HE
8
variant Common Info field indicates either 2 HE-LTF + 1.6 µs GI or 4 HE-LTF + 3.2 µs GI, as defined in
9
10 Table 9-49 (MU-MIMO HE-LTF Mode subfield encoding). Otherwise, this subfield is set to indicate HE
11 single stream pilot HE-LTF mode. B22 of the EHT variant Common Info field is reserved and is set to 0.
12
13
14 Table 9-49—MU-MIMO HE-LTF Mode subfield encoding
15
16
17 MU-MIMO
18 HE-LTF Description
19 subfield value
20
21 0 HE single stream pilot HE-LTF mode
22
23 1 HE masked HE-LTF sequence mode
24
25
26
27 (#5439)(#5794)If the Doppler subfieldB53 of the Common Info field is 0, then the Number Of HE-LTF
28 Symbols And Midamble Periodicity subfield or the Number Of HE/EHT-LTF Symbols subfield of the Com-
29 mon Info field indicates the number of HE-LTF or EHT-LTF symbols present in the HE or EHT TB PPDU
30
and is encoded as follows:
31
32 — 0 for 1 HE-LTF or EHT-LTF symbol
33
— 1 for 2 HE-LTF or EHT-LTF symbols
34
35 — 2 for 4 HE-LTF or EHT-LTF symbols
36
— 3 for 6 HE-LTF or EHT-LTF symbols
37
38 — 4 for 8 HE-LTF or EHT-LTF symbols
39
— 5–7 is reserved
40
41
42 Move the 15th and 16th paragraphs of subclause 9.3.1.22.1 as the 16th and 17th paragraphs of
43 this child subclause and change as follows:
44
45
46 (#4104)If the Doppler subfield of the HE variant Common Info field is 1, then the Number Of HE-LTF
47 Symbols And Midamble Periodicity subfield indicates the number of HE-LTF symbols and the periodicity
48 of the midamble and is encoded as follows:
49
50 — 0 for 1 HE-LTF symbol and 10 symbol midamble periodicity
51 — 1 for 2 HE-LTF symbols and 10 symbol midamble periodicity
52
53 — 2 for 4 HE-LTF symbols and 10 symbol midamble periodicity
54 — 4 for 1 HE-LTF symbol and 20 symbol midamble periodicity
55
56 — 5 for 2 HE-LTF symbols and 20 symbol midamble periodicity
57 — 6 for 4 HE-LTF symbols and 20 symbol midamble periodicity
58
59 — 3 and 7 are reserved
60
61 (#4104)The UL STBC subfield of the HE variant Common Info field indicates the status of STBC encoding
62 for the solicited HE TB PPDUs. It is set to 1 to indicate STBC encoding and set to 0 otherwise.
63
64
65

Copyright © 2022 IEEE. All rights reserved. 129

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Insert the following paragraph as the 18th paragraph of this child subclause:
2
3
4 (#4503)B26 of the EHT variant Common Info field is reserved and is set to 0.
5
6 Move the 17th paragraph of subclause 9.3.1.22.1 as the 19th paragraph of this child subclause
7
8
and changes as follows:
9
10 The LDPC Extra Symbol Segment subfield of the Common Info field indicates the status of the LDPC extra
11 symbol segment. It is set to 1 if the LDPC extra symbol segment is present in the solicited HE or EHT TB
12 PPDUs and set to 0 otherwise.
13
14
15 Move the 18th paragraph of subclause 9.3.1.22.1 as the 20th paragraph of this child subclause
16 and change as follows:
17
18
The AP Tx Power subfield of the Common Info field indicates the AP’s combined transmit power at the
19
20 transmit antenna connector of all the antennas used to transmit the triggering PPDU in units of dBm/
21 20 MHz. The transmit power in dBm/20 MHz, PTX, is calculated as PTX = –20 + FVal, where FVal is the
22 value of the AP Tx Power subfield(#7683), except for the values. Values above 60, which are reserved for
23 the AP Tx Power subfield.
24
25
26 Move the 19th paragraph of subclause 9.3.1.22.1 as the 21st paragraph of this child subclause
27 and change as follows:
28
29 The Pre-FEC Padding Factor and PE Disambiguity subfields are defined in Table 9-50 (Pre-FEC Padding
30
31 Factor and PE Disambiguity subfields) and have the same encoding as their respective subfields in HE SIG-
32 A (see Table 27-20 (HE-SIG-A field of an HE MU PPDU)) or as in their respective subfields in EHT-SIG
33 (see Table 36-33 (Common field for OFDMA transmission)).
34
35
36 Table 9-50—Pre-FEC Padding Factor and PE Disambiguity subfields
37
38
39 Subfield Description Encoding
40
41 Pre-FEC Padding Factor Indicates the pre-FEC padding Set to 0 to indicate a pre-FEC padding factor of 4
42 factor Set to 1 to indicate a pre-FEC padding factor of 1
43 Set to 2 to indicate a pre-FEC padding factor of 2
44 Set to 3 to indicate a pre-FEC padding factor of 3
45
46 PE Disambiguity Indicates PE disambiguity (#8071)When an HE TB PPDU is solicited, setSet to
47 1 if the condition in Equation (27-118) is met; other-
48 wise it is set to 0
49 When an EHT TB PPDU is solicited, set to 1 if the
50 condition in Equation (36-94) is met; otherwise it is
51 set to 0
52
53
54
55 Move the 20th paragraphs of subclause 9.3.1.22.1 as the 22nd paragraph of this child subclause
56 and changes as follows:
57
58
59 (#1599)When the Trigger frame solicits an HE TB PPDU, theThe UL Spatial Reuse subfield of the Com-
60 mon Info field carries the values to be included in the Spatial Reuse fields in the HE-SIG-A field of the
61 solicited HE TB PPDUs. The format of the UL Spatial Reuse subfield is shown in Figure 9-88b (UL Spatial
62
Reuse subfield format), where each Spatial Reuse n subfield, 1  n  4 , is set to the same value as its corre-
63
64 sponding subfield in the HE-SIG-A field of the HE TB PPDU, which are defined in Table 27-21 (HE-SIG-A
65 field of an HE TB PPDU).

130 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2 B0 B3 B4 B7 B8 B11 B12 B15
3
4 Spatial Reuse 1 Spatial Reuse 2 Spatial Reuse 3 Spatial Reuse 4
5
6 Bits: 4 4 4 4
7
8
9 Figure 9-88b—UL Spatial Reuse subfield format
10
11
12 Insert the following five paragraphs as the 23rd, 24th, 25th, 26th, and 27th paragraphs of this
13 child subclause:
14
15
16 (#1599)When the Trigger frame solicits an EHT TB PPDU, each Spatial Reuse n subfield, 1  n  4 , of the
17 Common Info field is determined based on either the (#5440)EHT Spatial Reuse 1 subfield or the EHT Spa-
18 tial Reuse 2 subfield of the Special User Info field (see 9.3.1.22.1.2.3 (Special User Info field(#7899))) as
19 described below.
20
21
22 (#1599)When the Trigger frame solicits a 20 MHz EHT TB PPDU, each Spatial Reuse n subfield,
23 1  n  4 , of the Common Info field is set to the value of the (#5440)EHT Spatial Reuse 1 subfield of the
24 Special User Info field.
25
26
27 (#1599)When the Trigger frame solicits a 40 MHz EHT TB PPDU, the Spatial Reuse 1 subfield and the
28 Spatial Reuse 3 subfield of the Common Info field are set to the value of the (#5440)EHT Spatial Reuse 1
29 subfield of the Special User Info field and the Spatial Reuse 2 subfield and the Spatial Reuse 4 subfield of
30 the Common Info field are set to the value of the (#5440)EHT Spatial Reuse 2 subfield of the Special User
31 Info field.
32
33
34 (#1599)When the Trigger frame solicits an 80 MHz EHT TB PPDU or a 160 MHz EHT TB PPDU, the Spa-
35 tial Reuse 1 subfield and the Spatial Reuse 2 subfield of the Common Info field are set to the value of the
36 (#5440)EHT Spatial Reuse 1 subfield of the Special User Info field and the Spatial Reuse 3 subfield and the
37
38
Spatial Reuse 4 subfield of the Common Info field are set to the value of the (#5440)EHT Spatial Reuse 2
39 subfield of the Special User Info field.
40
41 (#1599)When the Trigger frame solicits a 320 MHz EHT TB PPDU, each Spatial Reuse n subfield,
42 1  n  4 , of the Common Info field is set to the smaller of the values of the (#5440)EHT Spatial Reuse 1
43
44 subfield and the EHT Spatial Reuse 2 subfield of the Special User Info field.
45
46 Move the 21st paragraph of subclause 9.3.1.22.1 as the 28th paragraph of this child subclause
47
48 as follows:
49
50 (#4104)The Doppler subfield of the HE variant Common Info field is set to 1 to indicate that a midamble is
51 present in the HE TB PPDU and set to 0 otherwise.
52
53
54 Insert the following paragraph as the 29th paragraph of this child subclause:
55
56 (#4503)(#5439)B53 of the EHT variant Common Info field is reserved and is set to 0.
57
58
59 Move the 22nd paragraph of subclause 9.3.1.22.1 as the 30th and 31st paragraphs of this child
60 subclause and change as follows:
61
62
(#4104)The UL HE-SIG-A2 Reserved subfield of the HE variant Common Info field carries the value to be
63
64 included in the Reserved field in the HE-SIG-A2 subfield of the solicited HE TB PPDUs. An HE AP sets the
65 UL HE-SIG-A2 Reserved subfield of the HE variant Common Info field to all 1s.

Copyright © 2022 IEEE. All rights reserved. 131

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#4877)An EHT AP sets HE/EHT P160 subfield of the EHT variant Common Info field to 0 to indicate to an
2 EHT STA that the solicited TB PPDU in the primary 160 MHz is an EHT TB PPDU and sets HE/EHT P160
3
subfield of the EHT variant Common Info field to 1 to indicate that the solicited TB PPDU in the primary
4
5 160 MHz is an HE TB PPDU.
6
7
8 Insert the following paragraph as the 32nd paragraph of this child subclause:
9
10
(#4327)The Special User Info Field Flag subfield is always set to 0 in an EHT variant Common Info field,
11
12 indicating that a Special User Info field is included in the Trigger frame that contains the EHT variant Com-
13 mon Info field.
14
15
16 Move the 23th paragraph of subclause 9.3.1.22.1 as the 33rd paragraph of this child subclause:
17
18
The Trigger Dependent Common Info subfield in the Common Info field is optionally present based on the
19
20 value of the Trigger Type field (see 9.3.1.22.2 (Basic Trigger frame format) to 9.3.1.22.9 (NFRP Trigger
21 frame format)).
22
23
24 Insert a second child subclause of 9.3.1.22.1 as follows:
25
26
27 9.3.1.22.1.2 User Info List field
28
29
30
Move the 24th paragraph of subclause 9.3.1.22.1 as the first paragraph of this second child sub-
31 clause:
32
33
The User Info List field contains zero or more User Info fields.
34
35
36 Insert the following paragraphs as the remaining paragraphs of this second child subclause:
37
38
39 (#4584)There are three variants for the User Info field, which are HE variant User Info field, EHT variant
40
User Info field, and Special User Info field.
41
42
43 All User Info fields (#6695)(including the Special User Info field) in the User Info List field of a Trigger
44
frame have the same length unless the Trigger frame is an (#5117)(#4584)MU-BAR Trigger frame (see
45
46 9.3.1.22.4 (MU-BAR Trigger frame format) and 9.3.1.22.1.2.3 (Special User Info field(#7899))).
47
48
(#4584)A non-EHT HE AP does not transmit a Trigger frame with the EHT variant User Info field or the
49
50 Special User Info field, whereas an EHT AP can transmit a Trigger frame with any variant of the User Info
51 field.
52
53
54 (#4584)If a Trigger frame is generated by an EHT AP, the EHT AP does not set the AID12 subfield in an
55 HE variant User Info field to 2007.
56
57
58 A User Info field that is addressed to a non-AP STA is either an HE variant or an EHT variant. The User
59 Info field is an HE variant addressed to a non-AP EHT STA if the B39 of the User Info field is set to 0 and
60 the B54 of the Common Info field is set to 1 in the Trigger frame; otherwise, it is an EHT variant.
61 (#7685)B39 of an HE variant User Info field is reserved for a non-EHT HE STA. B39 is set to 0 for an HE
62
variant User Info field by an EHT AP, and is the PS160 subfield for an EHT variant User Info field. Table 9-
63
64 50a (Valid combinations of B54 and B55 in the Common Info field, B39 in the User Info field, and solicited
65 TB PPDU format) defines valid combinations of the B54 and B55 in the Common Info field, the B39 in the

132 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 User Info field, the presence of the Special User Info (#7686)field in the Trigger frame, the variant of a User
2 Info field, and the corresponding TB PPDU type.
3
4
5
6 Table 9-50a—Valid combinations of B54 and B55 in the Common Info field, B39 in the User
7 Info field, and solicited TB PPDU format
8
9
10 Common Common Presence of
User Info User Info TB PPDU
11 Info field Info field Special User
field B39 field variant type
12 B54 B55 Info field
13
14 1 1 0 No HE variant HE
15
16 0 0 0 Yes EHT variant EHT
17 0 0 1 Yes EHT variant EHT
18
19 1 0 1 Yes EHT variant EHT
20
21 1 0 0 Yes HE variant HE
22
23 (#5510)NOTE 1—A non-AP EHT STA with dot11EHTBaseLineFeaturesImplementedOnly
24 equal to true does not respond with a TB PPDU to a Trigger frame that does not follow the com-
25 binations listed in this table (see 35.5.2.3.3 (Conditions for not responding with a TB
26 PPDU(#4839))).
27 (#6696)NOTE 2—The last row in this table allows a non-AP EHT STA to transmit an HE TB
28 PPDU in the primary 160 MHz as a response to a Trigger frame that contains a Special User Info
29 field.
30
31
32
33
34 (#7896)(#7687)An EHT AP with dot11EHTBaseLineFeaturesImplementedOnly equal to true does not set
35 [B54:B55] in the Common Info field to the value “10” in a Trigger frame. If the bandwidth of a solicited
36 EHT TB PPDU is less than 320 MHz, then B39 of the corresponding (#4323)EHT variant User Info field in
37
the Trigger frame is set to 0.
38
39
40
41 Insert the following subclause as the first child subclause of second child subclause as follows:
42
43
44 9.3.1.22.1.2.1 HE variant User Info field
45
46
47 Move the 25th–46th paragraphs of subclause 9.3.1.22.1 as this new subclause and change as
48 follows (including adding a NOTE after Table 9-51 (AID12 subfield encoding):
49
50
51 The HE variant User Info field is defined in Figure 9-90 (HE variant User Info field format) for all Trigger
52 frame variants except the NFRP Trigger frame, which is defined in 9.3.1.22.9 (NFRP Trigger frame format).
53
54
55
56 B0 B11 B12 B19 B20 B21 B24 B25 B26 B31 B32 B38 B39
57
58
UL FEC SS Allocation/ UL Target Trigger
59 AID12 RU Coding UL HE- UL RA-RU Receive Reserved Dependent
60 Allocation MCS DCM
Type Information Power User Info
61
62 Bits: 12 8 1 4 1 6 7 1 variable
63
64
65 Figure 9-90—HE variant User Info field format

Copyright © 2022 IEEE. All rights reserved. 133

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The AID12 subfield in the User Info field is encoded as defined in Table 9-51 (AID12 subfield encoding):
2
3
4
Table 9-51—AID12 subfield encoding
5
6
7 AID12 subfield Description
8
9 0 User Info field allocates one or more contiguous RA-RUs for associated STAs
10
11 User Info field is addressed to an associated STA whose AID is equal to the value in the
12 1–2007
AID12 subfield
13
14 2008–2044 Reserved
15
16 2045 User Info field allocates one or more contiguous RA-RUs for unassociated STAs
17
18 2046 Unallocated RU
19 2047–4094 Reserved
20
21 (#5544)Start of Padding fieldDisallowed in a User Info field as it indicates the start of the
22 4095
Padding field
23
24 (#5544)NOTE—The Padding field, if present in a Trigger frame, is a field with all padding bits set to 1. The
25 Padding field, if present, has a length of at least two octets and is located between the User Info List field and
26 the FCS field.
27
28
29
30 (#4584)NOTE—The value 2007 in the AID12 subfield can be used for an HE variant User Info field if the Trigger frame
31 is generated by a non-EHT HE AP, whereas the value 2007 in the AID12 subfield cannot be used for an HE variant User
32 Info field if the Trigger frame is generated by an EHT AP (see 9.3.1.22.1.2.3 (Special User Info field(#7899)) for
33 details).
34
35 If the AID12 subfield is equal to(#7390) 2046, then the remaining subfields in the HE variant User Info field
36 are reserved except for the RU Allocation subfield, which indicates the RU location of the unallocated RU.
37
38
39 (#5544)If the AID12 subfield is 4095, then the remaining subfields in the User Info field are not present.
40
41 The RU Allocation subfield in an HE variant User Info field along with the UL BW subfield in the Common
42 Info field identifies the size and the location of the RU. If the UL BW subfield indicates 20 MHz, 40 MHz or
43
80 MHz PPDU, then B0 of the RU Allocation subfield is set to 0. If the UL BW subfield indicates
44
45 80+80 MHz or 160 MHz, then B0 of the RU Allocation subfield is set to 0 to indicate that the RU allocation
46 applies to the primary 80 MHz channel and set to 1 to indicate that the RU allocation applies to the second-
47 ary 80 MHz channel. The mapping of B7–B1 of the RU Allocation subfield for a Trigger frame that is not an
48 MU-RTS Trigger frame is defined in Table 9-52 (B7–B1 of the RU Allocation subfield in an HE variant
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

134 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 User Info field). See 9.3.1.22.5 (MU-RTS Trigger frame format) for the encoding of the RU Allocation sub-
2 field in an MU-RTS Trigger frame.
3
4
5
6 Table 9-52—B7–B1 of the RU Allocation subfield in an HE variant User Info field
7
8
9 B7–B1 of the
10 RU Allocation UL BW subfield RU size RU Index
11 subfield
12
13 20 MHz, 40 MHz, 80 MHz,
0–8 RU1 to RU9, respectively
14 80+80 MHz or 160 MHz
15 40 MHz, 80 MHz, 80+80 MHz
16 9–17 26 RU10 to RU18, respectively
or 160 MHz
17
18 80 MHz, 80+80 MHz or
19 18–36 RU19 to RU37, respectively
160 MHz
20
21 20 MHz, 40 MHz, 80 MHz,
37–40 RU1 to RU4, respectively
22 80+80 MHz or 160 MHz
23
24 40 MHz, 80 MHz, 80+80 MHz
41–44 52 RU5 to RU8, respectively
25 or 160 MHz
26
27 80 MHz, 80+80 MHz or
45–52 RU9 to RU16, respectively
28 160 MHz
29 20 MHz, 40 MHz, 80 MHz,
30 53, 54 RU1 and RU2, respectively
80+80 MHz or 160 MHz
31
32 40 MHz, 80 MHz, 80+80 MHz
33 55, 56 106 RU3 and RU4, respectively
or 160 MHz
34
35 80 MHz, 80+80 MHz or
57–60 RU5 to RU8, respectively
36 160 MHz
37
38 20 MHz, 40 MHz, 80 MHz,
61 RU1
39 80+80 MHz or 160 MHz
40
41 40 MHz, 80 MHz, 80+80 MHz
62 242 RU2
42 or 160 MHz
43 80 MHz, 80+80 MHz or
44 63, 64 RU3 and RU4, respectively
160 MHz
45
46 40 MHz, 80 MHz, 80+80 MHz
47 65 RU1
or 160 MHz
48 484
49 80 MHz, 80+80 MHz or
66 RU2
50 160 MHz
51
52 80 MHz, 80+80 MHz or
67 996 RU1
53 160 MHz
54
55 68 80+80 MHz or 160 MHz 2×996 RU1
56 NOTE—If the UL BW subfield indicates 80+80 MHz or 160 MHz, the description indicates the RU index for the pri-
57 mary 80 MHz channel or secondary 80 MHz channel as indicated by B0 of the RU Allocation subfield.
58
59
60
61 If the UL BW subfield indicates 20 MHz, the mapping of the RU index to RU is defined in Table 27-7 (Data
62
and pilot subcarrier indices for RUs in a 20 MHz HE PPDU and in a non-OFDMA 20 MHz HE PPDU) in
63
64 increasing order.
65

Copyright © 2022 IEEE. All rights reserved. 135

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 If the UL BW subfield indicates 40 MHz, the mapping of the RU index to RU is defined in Table 27-8 (Data
2 and pilot subcarrier indices for RUs in a 40 MHz HE PPDU and in a non-OFDMA 40 MHz HE PPDU) in
3
increasing order.
4
5
6 If the UL BW subfield indicates 80 MHz, 160 MHz or 80+80 MHz, the mapping of the RU index to RU is
7 defined in Table 27-9 (Data and pilot subcarrier indices for RUs in an 80 MHz HE PPDU and in a non-
8
OFDMA 80 MHz HE PPDU) in increasing order.
9
10
11 If the UL BW subfield indicates 160 MHz or 80+80 MHz, B7–B1 of the RU Allocation subfield is set to 68
12 and B0 is set to 1 to indicate a 2×996-tone RU. A non-AP STA ignores B0 for 2×996-tone RU indication.
13
14
15 If the AID12 subfield is in the range 1 to 2007, then the RU Allocation subfield indicates the RU allocated to
16 the STA identified by the AID12 subfield. If the AID12 subfield is 0 or 2045, then the RU Allocation sub-
17 field indicates the starting RU of one or more contiguous RA-RUs allocated by the HE variant User Info
18
field. If the AID12 subfield is 2046, then the RU Allocation subfield indicates an unallocated RU.
19
20
21 If there is more than one RA-RU (i.e., the Number Of RA-RU subfield of this HE variant User Info field has
22 a value greater than 0), then the allocated RUs are contiguous and the RU sizes of all RA-RUs are the same
23
24
and equal to the size of the first RU. Further, all the remaining subfields of the HE variant User Info field
25 apply to all the RA-RUs.
26
27 The UL FEC Coding Type subfield of the User Info field indicates the code type of the solicited HE TB
28
29
PPDU. The UL FEC Coding Type subfield is set to 0 to indicate BCC and set to 1 to indicate LDPC.
30
31 The UL HE-MCS subfield of the HE variant User Info field indicates the HE-MCS of the solicited HE TB
32 PPDU. The encoding of the UL HE-MCS subfield is defined in 27.3.7 (HE modulation and coding schemes
33
34
(HE-MCSs)).
35
36 The UL DCM subfield of the HE variant User Info field indicates DCM of the solicited HE TB PPDU. The
37 UL DCM subfield is set to 1 to indicate that DCM is used in the solicited HE TB PPDU as defined in
38
39
27.3.12.15 (Dual carrier modulation). The UL DCM subfield is set to 0 to indicate that DCM is not used.
40 The UL DCM subfield is set to 0 if the UL STBC subfield of the Common Info field is set to 1.
41
42 If the AID12 subfield is either 0 or 2045, then B26–B31 of the User Info field is the RA-RU Information
43
44
subfield, otherwise B26–B31 of the User Info field is the SS Allocation subfield.
45
46 The SS Allocation subfield of the HE variant User Info field indicates the spatial streams of the solicited HE
47 TB PPDU and the format is defined in Figure 9-91 (SS Allocation subfield format of an HE variant User
48
49 Info field).
50
51
52 B26 B28 B29 B31
53
54 Starting Spatial Number Of Spatial
55 Stream Streams
56
57 Bits: 3 3
58
59
60 Figure 9-91—SS Allocation subfield format of an HE variant User Info field
61
62
63
64 The Starting Spatial Stream subfield indicates the starting spatial stream and is set to the starting spatial
65 stream minus 1 (see 26.5.2.3.3 (TXVECTOR parameters for HE TB PPDU response to Trigger frame)).

136 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The Number Of Spatial Streams subfield indicates the number of spatial streams, and is set to the number of
2 spatial streams minus 1.
3
4
5 The RA-RU Information subfield of the User Info field indicates the RA-RU information and the format is
6 defined in Figure 9-92 (RA-RU Information subfield format).
7
8
9
10 B26 B30 B31
11
12 Number Of RA-RU More RA-RU
13
14 Bits: 5 1
15
16
17 Figure 9-92—RA-RU Information subfield format
18
19
20 The Number Of RA-RU subfield indicates the number of contiguous RUs allocated for UORA. The value of
21
22
the Number Of RA-RU subfield is equal to the number of contiguous RA-RUs minus 1.
23
NOTE—The starting spatial stream and the number of spatial streams of the HE TB PPDU transmitted on each RA-RU
24
are 1.
25
26
27 The More RA-RU subfield is set to 1 to indicate that RA-RUs of the type indicated by the AID12 subfield in
28 this User Info field (see Table 9-51 (AID12 subfield encoding)) are allocated in subsequent Trigger frames
29 that are sent until the end of the TWT SP in which the Trigger frame carrying this field is sent. Otherwise,
30
31
the subfield is set to 0. The More RA-RU subfield is reserved if the More TF field in the Common Info field
32 is set to 0.
33
34 The UL Target Receive Power subfield indicates the expected receive signal power, measured at the AP's
35
antenna connector and averaged over the antennas, for the HE portion of the HE TB PPDU transmitted on
36
37 the assigned RU and is defined in Table 9-53 (UL Target Receive Power subfield in Trigger frame).
38
39
40 Table 9-53—UL Target Receive Power subfield in Trigger frame
41
42
43 UL Target Receive
Description
44 Power subfield
45
46 0–90 The expected receive signal power, in units of dBm, is
47 Targetpwr = –110 + Fval, where Fval is the subfield value
48
49 91–126 Reserved
50
51 127 The STA transmits the HE TB PPDU at the STA’s maxi-
52 mum transmit power for the assigned HE-MCS.
53
54 The expected receive signal power is then the STA’s
55 maximum transmit power for the assigned HE-MCS
56 minus the path loss.
57
58
59
60 The Trigger Dependent User Info subfield in the User Info field is optionally present based on the value of
61 the Trigger Type field (see 9.3.1.22.2 (Basic Trigger frame format) to 9.3.1.22.9 (NFRP Trigger frame for-
62 mat)).
63
64
65

Copyright © 2022 IEEE. All rights reserved. 137

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Insert the following subclause as the second child subclause of second child subclause as fol-
2 lows:
3
4
5 9.3.1.22.1.2.2 EHT variant User Info field
6
7 Insert the following paragraphs:
8
9
10 The EHT variant User Info field is defined in Figure 9-92a (EHT variant User Info field format) for all Trig-
11 ger frame variants except the NFRP Trigger frame(#8074).
12
13
14
15 B0 B11 B12 B19 B20 B21 B24 B25 B26 B31 B32 B38 B39
16
17 UL FEC SS Allocation/ UL Target Trigger
18 RU UL EHT- Reser
AID12 Allocation Coding MCS ved RA-RU Receive PS160 Dependent
19 Type Information Power User Info
20
21 Bits: 12 8 1 4 1 6 7 1 variable
22
23
24 Figure 9-92a—EHT variant User Info field format
25
26
27 If the AID12 subfield is (#7391)equal to 2007, the Trigger frame containing this User Info field is generated
28 by an EHT AP, (#5204)and B55 of the Common Info field of the Trigger frame is equal to 0, then the
29
30 remaining (#7688)subfields of the User Info field are defined in 9.3.1.22.1.2.3 (Special User Info
31 field(#7899)). Otherwise, the AID12 subfield in the EHT variant User Info field is encoded as defined in
32 Table 9-51 (AID12 subfield encoding).
33
34 The RU Allocation subfield in an EHT variant User Info field in a Trigger frame that is not an MU-RTS
35
36 Trigger frame(#7689), along with the UL BW subfield in the Common Info field, the UL BW Extension
37 subfield in the Special User Info field, and the PS160 subfield in the EHT variant User Info field, identifies
38 the size and the location of the RU/MRU. The mapping of B7–B1 of the RU Allocation subfield along with
39 the settings of B0 of the RU Allocation subfield and PS160 subfield in the EHT variant User Info field are
40 defined in Table 9-53a (Encoding of PS160 and RU Allocation subfields in an EHT variant User Info field),
41
42 where the bandwidth is obtained from the combination of the UL BW subfield and UL Bandwidth Extension
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

138 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 subfields as defined in Table 9-53c (UL Bandwidth Extension subfield encoding) and N is obtained from
2 (#7030)Table 9-53b (Lookup table for X1 and N(#7032)) that is derived from Equation (9-0a1).
3
4
5
6 Table 9-53a—Encoding of PS160 and RU Allocation subfields in an EHT variant User Info
7 field
8
9
10 B0 of the B7–B1 of
PHY RU/
11 PS160 RU the RU Bandwidth RU/MRU
RU/MRU index MRU
12 subfield Allocation Allocation (MHz) size
index
13 subfield subfield
14
15 0–3: 20, 40, 80, RU1 to RU9, respec-
0–8
16 80 MHz subblock where the 160, or 320 tively
17 MRU is located(#1279)
18 40, 80, 160, RU10 to RU18,
9–17
19 or 320 respectively 37+ RU
26
20 80, 160, or index
21 18 Reserved
320
22
23 80, 160, or RU20 to RU37
24 19–36
320 respectively
25
26 20, 40, 80, RU1 to RU4, respec-
37–40
27 160, or 320 tively
28
29 40, 80, 160, RU5 to RU8, respec- 16+ RU
41–44 52
30 or 320 tively index
31
32 80, 160, or RU9 to RU16,
45–52
33 320 respectively
34 20, 40, 80, RU1 and RU2,
35 53, 54
160, or 320 respectively
36
37 40, 80, 160, RU3 and RU4, 8+ RU
38 55, 56 106
or 320 respectively index
39
40 80, 160, or RU5 to RU8, respec-
57–60
41 320 tively
42
43 20, 40, 80,
61 RU1
44 160, or 320
45
46 40, 80, 160, 4+ RU
62 242 RU2
47 or 320 index
48 80, 160, or RU3 and RU4,
49 63, 64
320 respectively
50
51 40, 80, 160,
52 65 RU1
or 320 2+ RU
53 484
54 80, 160, or index
66 RU2
55 320
56
57 80, 160, or + RU
67 996 RU1
58 320 index
59
60 0–1: 20, 40, 80,
61 160 MHz 0 160, or Reserved Reserved Reserved
62 segment 320(#7908)
68
63 where the
RU is X1+ RU
64 1 160 or 320 2996 RU1
located index
65

Copyright © 2022 IEEE. All rights reserved. 139

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 9-53a—Encoding of PS160 and RU Allocation subfields in an EHT variant User Info
2 field (continued)
3
4
5 B0 of the B7–B1 of
6 PHY RU/
PS160 RU the RU Bandwidth RU/MRU
7 RU/MRU index MRU
subfield Allocation Allocation (MHz) size
8 index
subfield subfield
9
10 0 0
11 20, 40, 80,
12 0 1 160, or Reserved Reserved Reserved
13 69 320(#7908)
14 1 0
15
16 1 1 320 4996 RU1 RU1
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

140 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 9-53a—Encoding of PS160 and RU Allocation subfields in an EHT variant User Info
2 field (continued)
3
4
5 B0 of the B7–B1 of
6 PHY RU/
PS160 RU the RU Bandwidth RU/MRU
7 RU/MRU index MRU
subfield Allocation Allocation (MHz) size
8 index
subfield subfield
9
10 0–3: 20, 40 52+26 MRU1
11 80 MHz subblock where the
12 70 80, 160, or
MRU is located(#1279) Reserved Reserved
13 320
14
15 20, 40, 80, MRU2 and MRU3,
71–72 52+26
16 160, or 320 respectively
17
18 40, 80, 160, MRU4 and MRU5,
73–74 52+26
19 or 320 respectively
20 40 52+26 MRU6
21 12+
22 75 80, 160, or
Reserved Reserved MRU index
23 320
24
25 20, 40, 80,
26 76 160, or Reserved Reserved
27 320(#7908)
28
29 80, 160, or MRU8 to MRU11,
77–80 52+26
30 320 respectively
31
32 20, 40, 80,
33 81 160, or Reserved Reserved
34 320(#7908)
35 20, 40, 80,
36 82 106+26 MRU1
160, or 320
37
38 20, 40 106+26 MRU2
39
40 83 80, 160, or
Reserved Reserved
41 320
42
43 40 106+26 MRU3
44 84
45 80, 160, or
Reserved Reserved
320
46 8+
47 40, 80, 160, MRU index
48 85 106+26 MRU4
or 320
49
50 80, 160, or
51 86 106+26 MRU5
320
52
53 20, 40, 80,
54 87–88 160, or Reserved Reserved
55 320(#7908)
56
57 80, 160, or
89 106+26 MRU8
58 320
59
60 80, 160, or MRU1 to MRU4, 4+
90–93 484+242
61 320 respectively MRU index
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 141

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 9-53a—Encoding of PS160 and RU Allocation subfields in an EHT variant User Info
2 field (continued)
3
4
5 B0 of the B7–B1 of
6 PHY RU/
PS160 RU the RU Bandwidth RU/MRU
7 RU/MRU index MRU
subfield Allocation Allocation (MHz) size
8 index
subfield subfield
9
10 0–1: MRU1 and MRU2,
11 0
160 MHz respectively
12 segment 4X1+
13 94, 95 160 or 320 996+484
where the MRU3 and MRU4, MRU index
14 MRU is 1
15 respectively
located
16
17 0: MRU is MRU1 to MRU4,
0 MRU
18 located in the 996+484+ respectively
19 primary 160 index(#488
242 MRU5 to MRU8,
20 160 MHz 1 2)
21 96–99 respectively
22
23 20, 40, 80,
24 1 Any 160, or Reserved Reserved Reserved
25 320(#7908)
26 MRU1 to MRU4,
27 0 0 100–103
2996 respectively
28 320
29 +484 MRU5 and MRU6,
30 0 1 100–101
respectively
31
32 20, 40, 80,
33 0 1 102–103 160, or Reserved Reserved
34 320(#7908)
35 MRU index
36 20, 40, 80,
37 1 0 100–101 160, or Reserved Reserved
38 320(#7908)
39
40 MRU7 and MRU8,
1 0 102–103
41 2996 respectively
320
42 +484 MRU9 to MRU12,
43 1 1 100–103
respectively
44
45 0 0 MRU1
46
47 0 1 MRU2
48 104 320 3996 MRU index
49 1 0 MRU3
50
51 1 1 MRU4
52
53
54
55
56
57
58
59
60
61
62
63
64
65

142 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 9-53a—Encoding of PS160 and RU Allocation subfields in an EHT variant User Info
2 field (continued)
3
4
5 B0 of the B7–B1 of
6 PHY RU/
PS160 RU the RU Bandwidth RU/MRU
7 RU/MRU index MRU
subfield Allocation Allocation (MHz) size
8 index
subfield subfield
9
10 MRU1 and MRU2,
11 0 0
respectively
12
13 MRU3 and MRU4,
0 1
14 3996 respectively
15 105, 106 320 MRU index
+484 MRU5 and MRU6,
16 1 0
17 respectively
18
19 MRU7 and MRU8,
1 1
20 respectively
21 20, 40, 80,
22 Any Any 107–127 160, or Reserved Reserved Reserved
23 320(#7908)
24
25 NOTE 1—B0 of the RU Allocation subfield is set to 0 to indicate that the RU/MRU allocation applies to the pri-
26 mary 80 MHz channel and set to 1 to indicate that the RU allocation applies to the secondary 80 MHz channel in
27 the primary 160 MHz. B0 of the RU Allocation subfield is set to 0 to indicate that the RU/MRU allocation applies
28 to the lower 80 MHz in the secondary 160 MHz and is set to 1 to indicate that the (#7029)RU/MRU allocation
29 applies to upper 80 MHz in the secondary 160 MHz.
30
31 NOTE 2—The PHY MRU index of a 52+26-tone MRU is not defined in the case of the MRU index equal to 1, 6,
32 7, or 12, if the bandwidth indicates 80, 160, or 320 MHz. The PHY MRU index of a 106+26-tone MRU is not
33 defined in the case of the MRU index equal to 2, 3, 6, or 7, if the bandwidth indicates 80, 160, or 320 MHz. Refer
34 to 36.3.2.2.2 (Small size MRUs(#2024)) for details.
35 (#7029)NOTE 3—If the size of RU/MRU is smaller than or equal to 2996 tone, then the PS160 subfield is set to 0
36 to indicate the RU/MRU allocation applies to the primary 160 MHz channel and set to 1 to indicate the RU/MRU
37 allocation applies to the secondary 160 MHz channel. Otherwise, the PS160 subfield is used to indicate the RU/
38 MRU index along with the RU Allocation subfield.
39
40
41
42 The parameter N in the Trigger Frame RU Allocation table is calculated using Equation (9-0a1).
43
44
45 N = 2  X1 + X0 (9-0a1)
46
47 Table 9-53b (Lookup table for X1 and N(#7032)) summarizes how to use Equation (9-0a1) to calculate N
48 for different configurations. For a bandwidth less than or equal to 80 MHz, PS160, B0, X0, and X1 are set to
49 0. For a bandwidth of 160 MHz, PS160 and X1 are set to 0, (#7031)while X0 is set to 0 to indicate that the
50
51 RU/MRU allocation applies to the lower 80 MHz subblock and set to 1 to indicate that the RU/MRU alloca-
52 tion applies to the upper 80 MHz subblock. For a bandwidth of 320 MHz, X1 is set to 0 to indicate that the
53 RU/MRU allocation applies to the lower 160 MHz segment and set to 1 to indicate that the RU/MRU alloca-
54 tion applies to the upper 160 MHz segment. Within the indicated 160 MHz segment, X0 is set to 0 to indi-
55 cate that the RU/MRU allocation applies to the lower 80 MHz subblock and set to 1 to indicate that the RU/
56
57 MRU allocation applies to the upper 80 MHz subblock. The configuration indicates the (#7354)frequency
58 order of the primary and secondary 80 MHz and 160 MHz channels. The order from left to right indicates
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 143

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 the order from lower frequency to higher frequency. The primary 80 MHz channel is indicated by P80, the
2 secondary 80 MHz channel is indicated by S80, and the secondary 160 MHz channel is indicated by S160.
3
4
5
6 Table 9-53b—Lookup table for X1 and N(#7032)
7
8
9 Inputs Outputs
Bandwidth
10 (MHz)
11 Configuration PS160 B0 X0 X1 N
12
13 20/40/80 [P80] 0 0 0 0 0
14
15 [P80 S80] 0 0 0 0 0
16 0 1 1 0 1
17 160
18 [S80 P80] 0 0 1 0 1
19
20 0 1 0 0 0
21
22 [P80 S80 S160] 0 0 0 0 0
23
24 0 1 1 0 1
25 1 0 0 1 2
26
27 1 1 1 1 3
28
29 [S80 P80 S160] 0 0 1 0 1
30
31 0 1 0 0 0
32
33 1 0 0 1 2
34 1 1 1 1 3
35 320
36 [S160 P80 S80] 0 0 0 1 2
37
38 0 1 1 1 3
39
40 1 0 0 0 0
41
42 1 1 1 0 1
43 [S160 S80 P80] 0 0 1 1 3
44
45 0 1 0 1 2
46
47 1 0 0 0 0
48
49 1 1 1 0 1
50
51
52
53 (#7033)(#7027)The values of PS160 subfield and B0 of RU Allocation subfield indicate the 80 MHz sub-
54 block in which the RU/MRU is located for 26-tone RU, 52-tone RU, 106-tone RU, 242-tone RU, 484-tone
55 RU, 996-tone RU, 52+26-tone RU, and 106+26-tone RU. The 80 MHz subblock is derived based on the cor-
56 responding PHY RU/MRU index column in Table 9-53a (Encoding of PS160 and RU Allocation subfields
57
58
in an EHT variant User Info field).
59
60 (#7034)The values of PS160 subfield indicates the 160 MHz segment in which the RU/MRU is located for
61 2996-tone RU, 996+484-tone MRU, and 996+484+242-tone MRU.
62
63
64 For 4996-tone RU, 2996+484-tone MRU, 3996-tone MRU, and 3996+484-tone MRU, the description
65 of RU/MRU index indicates the RU/MRU index for the 320 MHz channel.

144 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 If the bandwidth indicates 20 MHz, the mapping of the PHY RU index to RU is defined in Table 27-7 (Data
2 and pilot subcarrier indices for RUs in a 20 MHz HE PPDU and in a non-OFDMA 20 MHz HE PPDU) in
3
increasing order.
4
5
6
If the bandwidth indicates 40 MHz, the mapping of the PHY RU index to RU is defined in Table 27-8 (Data
7
8 and pilot subcarrier indices for RUs in a 40 MHz HE PPDU and in a non-OFDMA 40 MHz HE PPDU) in
9 increasing order.
10
11
12 If the bandwidth indicates 80 MHz, the mapping of the PHY RU index to RU is defined in Table 36-5 (Data
13 and pilot subcarrier indices for RUs in an 80 MHz EHT PPDU) in increasing order.
14
15
16 If the bandwidth indicates 160 MHz, the mapping of the PHY RU index to RU is defined in Table 36-6
17 (Data and pilot subcarrier indices for RUs in a 160 MHz EHT PPDU) in increasing order.
18
19
20 If the bandwidth indicates 320 MHz, the mapping of the PHY RU index to RU is defined in Table 36-7
21
22
(Data and pilot subcarrier indices for RUs in a 320 MHz EHT PPDU) in increasing order.
23
24
25
If the bandwidth indicates 20 MHz, the mapping of the PHY MRU index to MRU is defined in Table 36-8
26 (Indices for small size MRUs in an OFDMA 20 MHz EHT PPDU) in increasing order.
27
28
29 If the bandwidth indicates 40 MHz, the mapping of the PHY MRU index to MRU is defined in Table 36-9
30 (Indices for small size MRUs in an OFDMA 40 MHz EHT PPDU) in increasing order.
31
32
33 If the bandwidth indicates 80 MHz, the mapping of the PHY MRU index to MRU is defined in Table 36-10
34 (Indices for small size MRUs in an OFDMA 80 MHz EHT PPDU) and Table 36-13 (Indices for large size
35 MRUs in an OFDMA 80 MHz EHT PPDU and in a non-OFDMA 80 MHz EHT
36
37 PPDU(#5466)(#4903)(#2398)) in increasing order.
38
39
40 If the (#7402)bandwidth indicates 160 MHz, the mapping of the PHY MRU index to MRU is defined in
41 Table 36-11 (Indices for small size MRUs in an OFDMA 160 MHz EHT PPDU) and Table 36-14 (Indices
42 for large size MRUs in an OFDMA 160 MHz EHT PPDU and in a non-OFDMA 160 MHz EHT
43 PPDU(#5466)(#4903)(#2398)) in increasing order.
44
45
46 If the (#7402)bandwidth indicates 320 MHz, the mapping of the PHY MRU index to MRU is defined in
47 Table 36-12 (Indices for small size MRUs in an OFDMA 320 MHz EHT PPDU) and Table 36-15 (Indices
48
49 for large size MRUs in an OFDMA 320 MHz EHT PPDU and in a non-OFDMA 320 MHz EHT
50 PPDU(#4989)(#5466)(#4903)(#2398)) in increasing order.
51
52
53 The UL FEC Coding Type subfield of the User Info field indicates the code type of the solicited EHT TB
54 PPDU. The UL FEC Coding Type subfield is set to 0 to indicate BCC and set to 1 to indicate LDPC.
55
56
57 The UL EHT-MCS subfield of the User Info field indicates the EHT-MCS of the solicited EHT TB PPDU.
58 In an EHT variant User Info field, the encoding of the UL EHT-MCS subfield is defined in 36.3.8 (EHT
59
modulation and coding schemes (EHT-MCSs)). EHT-MCS 15 cannot be indicated in the UL EHT-MCS
60
61 subfield for UL MU-MIMO. EHT-MCS 14 cannot be indicated in an EHT variant User Info field in a Trig-
62 ger frame.
63
64
65 B25 is reserved in the EHT variant User Info field.

Copyright © 2022 IEEE. All rights reserved. 145

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The SS Allocation subfield of the EHT variant User Info field indicates the spatial streams of the solicited
2 EHT TB PPDU and the format is defined in Figure 9-92b (SS Allocation subfield format of an EHT variant
3
User Info field).
4
5
6
7 B26 B29 B30 B31
8
9 Starting Spatial Number Of Spatial
10 Stream Streams
11
12 Bits: 4 2
13
14
15 Figure 9-92b—SS Allocation subfield format of an EHT variant User Info field
16
17
18
(#4326)The UL Target Receive Power subfield indicates the expected receive signal power, measured at the
19
20 AP’s antenna connector and averaged over the antennas, for the EHT portion of the EHT TB PPDU trans-
21 mitted on the assigned RU and is defined in Table 9-53 (UL Target Receive Power subfield in Trigger
22 frame).
23
24
25 If the size of RU/MRU is smaller than or equal to 2996-tone, then PS160 subfield is set to 0 to indicate that
26 RU/MRU allocation applies to the primary 160 MHz channel and set to 1 to indicate that RU/MRU alloca-
27 tion applies to the secondary 160 MHz channel. Otherwise, (#7353)the PS160 subfield is used to indicate
28 the RU/MRU index along with the RU Allocation subfield. The PS160 subfield is set as defined in Table 9-
29 53a (Encoding of PS160 and RU Allocation subfields in an EHT variant User Info field).
30
31
32 The (#5901)(#4326)RA-RU Information and Trigger Dependent User Info subfields are set as defined in
33 9.3.1.22.1.2.1 (HE variant User Info field).
34
35
36 (#5901)The RA-RU Information subfield is reserved in the EHT variant User Info field.
37
38 Insert a third child subclause of 9.3.1.22.1.2 as follows:
39
40
41 9.3.1.22.1.2.3 Special User Info field(#7899)
42
43 (#7900)The Special User Info field is a User Info field that does not carry the user specific information but
44 carries the extended common information not provided in the Common Info field.
45
46
47 If the Special User Info field is included in the Trigger frame, then the Special User Info Field Flag(#4327)
48 subfield of the EHT variant of the Common Info Field is set to 0, otherwise it is set to 1.
49
50
51 The Special User Info field is identified by an AID12 value of 2007 and is optionally present in a Trigger
52 frame that is generated by an EHT AP.
53
54 NOTE 1—An EHT AP does not use the value 2007 as an AID for any STA associated to it (see 35.5.2 (EHT UL MU
55 operation(#1088))).
56 NOTE 2— The length of the Special User Info field is equal to the length of the other User Info fields present in the
57 same Trigger frame, except when the Trigger frame is an MU-BAR Trigger frame(#7691).
58
59 (#7903)NOTE 3—The Special User Info field is not included in the Trigger frame unless the Trigger frame includes one
60 or more EHT variant User Info fields.
61
62
The Special User Info field, if present, is located immediately after the Common Info field of the Trigger
63
64 frame and carries (#7692)information for the U-SIG field of a solicited EHT TB
65 PPDU(#6823)(#4328)(#8077).

146 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The format of the Special User Info field is defined in Figure 9-92c (Special User Info field format).
2
3
4
5 B0 B11 B12 B14 B15 B16 B17 B20 B21 B24 B25 B36 B37 B39
6
7 PHY U-SIG
8 UL EHT Spatial EHT Spatial Trigger
Version Disregard
AID12 Identifier Bandwidth Reuse 1 Reuse 2 And Reserved Dependent
9 Extension (#5440) (#5440) User Info
10 (#5512) Validate
11
12 Bits: 12 3 2 4 4 12 3 variable
13
14 Figure 9-92c—Special User Info field format
15
16
17
18 The (#5512)PHY Version Identifier subfield indicates the PHY version of the solicited TB PPDU that is not
19
20 an HE TB PPDU. The PHY Version Identifier subfield is set to 0 for EHT. (#4885)Other values from 1 to 7
21 are reserved.
22
23
24 The UL Bandwidth Extension subfield, together with the UL BW subfield in the Common Info field, indi-
25 cates the bandwidth of the solicited TB PPDU from the addressed EHT STA (i.e., the bandwidth in the U-
26 SIG field(#5657) of the EHT TB PPDU). The UL Bandwidth Extension subfield is defined in Table 9-53c
27 (UL Bandwidth Extension subfield encoding).
28
29
30
31 Table 9-53c—UL Bandwidth Extension subfield encoding
32
33
34 UL
Bandwidth for HE TB Bandwidth for EHT
35 UL BW Bandwidth
PPDU (MHz) TB PPDU (MHz)
36 Extension
37
38 0 20 0 20
39 0 20 1 Reserved
40
41 0 20 2 Reserved
42
43 0 20 3 Reserved
44
45 1 40 0 40
46
47 1 40 1 Reserved
48 1 40 2 Reserved
49
50 1 40 3 Reserved
51
52 2 80 0 80
53
54 2 80 1 Reserved
55
56 2 80 2 Reserved
57 2 80 3 Reserved
58
59 3 160 0 Reserved
60
61 3 160 1 160
62
63 3 160 2 320-1
64
65 3 160 3 320-2

Copyright © 2022 IEEE. All rights reserved. 147

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#5440)The EHT Spatial Reuse n subfield, 1  n  2 , (#4508)carries the values to be included in the corre-
2 sponding Spatial Reuse n subfield in the U-SIG field(#5657) of the EHT TB PPDU, which are defined in
3
Table 36-31 (U-SIG field of an EHT TB PPDU).
4
5
6 The U-SIG Disregard And Validate subfield carries the value to be included in the Disregard and Validate
7 subfields of the U-SIG field of the solicited EHT TB PPDUs. The U-SIG Disregard and Validate subfield is
8 further divided into three subfields as shown in Figure 9-92d (U-SIG Disregard and Validate subfield for-
9
10 mat(#4607)). The mapping from the subfields in the U-SIG Disregard And Validate subfield to subfields in
11 the U-SIG field for an EHT TB PPDU is defined in Table 9-53d (Mapping from Special User Info field to
12 U-SIG-1 and U-SIG-2 fields in the EHT TB PPDU(#4607)). The Validate In U-SIG-2 subfield is set to 1.
13 (#6998)The values of the Disregard In U-SIG-1 and Disregard In U-SIG-2 subfields are defined in
14 35.5.2.2.4 (Allowed settings of the Trigger frame fields and TRS Control subfield),
15
16
17
18
B25 B30 B31 B32 B36
19
20
Disregard Validate Disregard
21 In U-SIG-1 In U-SIG-2 In U-SIG-2
22
23
Bits: 6 1 5
24
25
26 Figure 9-92d—U-SIG Disregard and Validate subfield format(#4607)
27
28
29
Table 9-53d—Mapping from Special User Info field to U-SIG-1 and U-SIG-2 fields in the EHT
30
31 TB PPDU(#4607)
32
33
34 Subfields in the
Action to receiving STA
35 Special User Info field
36
37 Disregard In U-SIG-1 (B25–B30) Copy to the Disregard subfield of U-SIG-1 field (B20–B25 of U-SIG-1 field)
38 Validate In U-SIG-2 (B31) Copy to the Validate subfield of U-SIG-2 field (B2 of U-SIG-2 field)
39
40 Disregard In U-SIG-2 (B32–B36) Copy to the Disregard subfield of U-SIG-2 field (B11–B15 of U-SIG-2 field)
41
42
43
44 The presence and length of the Trigger Dependent User Info subfield in the Special User Info field depends
45 on the variant of the Trigger frame. When present, the length and the subfields of the Trigger Dependent
46
47 User Info subfield are as follows:
48 — The length is one octet and all the subfields are reserved in a Basic Trigger frame and in a BFRP
49 Trigger frame.
50
51 — (#5120)The length is four octets and all the subfields, except for the BAR Type subfield, are reserved
52 in an MU-BAR Trigger frame. The BAR Type subfield is set to indicate a Compressed BAR in an
53 MU BAR Trigger frame.
54
55 (#5120)NOTE 4—Trigger Dependent User Info subfield is not present in the Special Info User field if the Special User
56 Info field is contained in other Trigger frame variants.
57
58
59
60
61
62
63
64
65

148 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Insert a fourth child subclause of 9.3.1.22.1 as follows:

2
3
4 9.3.1.22.1.3 Padding field
5
6 Move the last paragraph of subclause 9.3.1.22.1 to this new child subclause and change as fol-
7 lows:
8
9
10 The Padding field is optionally present in a Trigger frame to extend the frame length for the following pur-
11 poses:
12
b) Toto give the recipient STAs enough time to prepare a response for transmission a SIFS after the
13
14 frame is received.
15 c) To align the end time of simultaneously transmitted PPDUs as described in 35.3.16.5 (PPDU end
16
time alignment).
17
18
19 The Padding field, if present, is at least two octets in length and is set to all 1s. If the Padding field is present
20 in a Trigger frame, its length is computed as described in 26.5.2.2.3 (Padding for a trigger frame).
21
22
23 9.3.1.22.3 BFRP Trigger frame format
24
25 Change the second paragraph as follows:
26
27
The Feedback Segment Retransmission Bitmap subfield indicates the requested feedback segments of an HE
28
29 (#5546)or EHT compressed beamforming report. If the bit in position n (n = 0 for LSB and n = 7 for MSB)
30 is 1, then the feedback segment with the Remaining Feedback Segments subfield in the HE MIMO Control
31 field equal to n is requested. If the bit in position n is 0, then the feedback segment with the Remaining Feed-
32 back Segments subfield in the HE MIMO Control field equal to n is not requested.
33
34
35 Insert the following paragraph at the end of the subclause:
36
37 (#5546)If a BFRP Trigger frame solicits an EHT compressed beamforming/CQI report, all of the bits in the
38 Feedback Segment Retransmission Bitmap subfield are set to 1.
39
40
41 9.3.1.22.5 MU-RTS Trigger frame format
42
43
44
Change the second paragraph as follows:
45
46 The UL BW subfield in the Common Info field along with the UL BW Extension subfield in the Special
47 User Info field (if present) indicates the bandwidth of the PPDU carrying the MU-RTS Trigger frame and is
48 defined in Table 9-29d (UL BW subfield encoding) and Table 9-53c (UL Bandwidth Extension subfield
49
50 encoding).
51
52 If any non-AP EHT STA is addressed in an MU-RTS Trigger frame from an EHT AP and any of the follow-
53 ing conditions is met, the User Info field addressed to an EHT STA in the MU-RTS Trigger frame is an EHT
54 variant User Info field:
55
56 — The bandwidth of the PPDU carrying the MU-RTS Trigger frame is 320 MHz.
57
58 — The PPDU carrying the MU-RTS Trigger frame is punctured.
59
60 Otherwise, the EHT AP decides whether the User Info field in the MU-RTS Trigger frame is an HE variant
61 User Info field or an EHT variant User Info field.
62
63
64 (#5514)If the B55 in the Common Info field is equal to 0 in an MU-RTS Trigger frame, an EHT AP does not
65 set the B54 in the Common Info field to 1.

Copyright © 2022 IEEE. All rights reserved. 149

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 NOTE—Refer to 9.3.1.22.1.2 (User Info List field) on valid combinations of B54 and B55 in the Common Info field,
2 B39 in the User Info field, and User Info field variant.
3
4
5
Change the now-shifted seventh paragraph as follows:
6
7 The UL Length, GI And HE-LTF Type, MU-MIMO HE-LTF Mode, Number Of HE-LTF Symbols And
8 Midamble Periodicity, UL STBC, LDPC Extra Symbol Segment, AP Tx Power, Pre-FEC Padding Factor,
9
PE Disambiguity, UL Spatial Reuse, and Doppler and UL HE-SIG-A2 Reserved subfields in the Common
10
11 Info field are reserved. In the HE variant of the Common Info field, the HE-SIG-A2 Reserved subfield is
12 reserved.
13
14
15
Insert the following paragraphs after the now-shifted seventh paragraph:
16
17 The TXOP Sharing Mode subfield in the Common Info field is set to a nonzero value if the MU-RTS Trig-
18 ger frame is sent by an EHT AP that intends to allocate time within an obtained TXOP to an
19 (#5367)associated non-AP EHT STA for transmitting one or more non-TB PPDUs sequentially (see
20
21 35.2.1.2 (Triggered TXOP sharing procedure)); otherwise it is set to 0. The encoding of the TXOP Sharing
22 Mode subfield is defined in Table 9-53e (TXOP Sharing Mode subfield encoding).
23
24
25 Table 9-53e—TXOP Sharing Mode subfield encoding
26
27
28 TXOP Sharing
29 Description
Mode subfield value
30
31 0 MU-RTS that does not initiate MU-RTS TXOP sharing procedure.
32
33 1 MU-RTS that initiates MU-RTS TXOP sharing procedure wherein a scheduled
34 STA can only transmit (#6126)MPDU(s) addressed to its associated AP.
35
36 2 MU-RTS that initiates MU-RTS TXOP sharing procedure wherein a scheduled
37 STA can transmit (#6126)MPDU(s) addressed to its associated AP or addressed
38 to another STA.
39
40 3 Reserved.
41
42
43
44
An MU-RTS Trigger frame that has the TXOP Sharing Mode subfield set to a nonzero value is called an
45 MU-RTS TXS(#6122) Trigger frame for the remainder of this subclause and throughout 35.2.1.2 (Triggered
46 TXOP sharing procedure)(#5315).
47
48 An Allocation Duration subfield in the MU-RTS TXS Trigger frame indicates the time duration allocated to
49
50 the non-AP STA within the TXOP obtained by the AP.
51
52 Change the now-shifted 11th paragraph as follows:
53
54
55 The UL HE-MCS, UL FEC Coding Type, UL DCM, SS Allocation/RA-RU Information and UL Target
56 Receive Power fields in the HE variant User Info field are reserved.
57
58 The UL EHT-MCS, UL FEC Coding Type, SS Allocation/RA-RU Information and UL Target Receive
59
Power fields in the EHT variant User Info field are reserved.
60
61
62
63
64
65

150 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Change the now-shifted 13th paragraph as follows:

2
3
4 The RU Allocation subfield in the User Info field addressed to the STA indicates whether the CTS frame is
5 transmitted on the primary 20 MHz channel, primary 40 MHz channel, primary 80 MHz channel, primary
6
160 MHz channel, or 80+80 MHz channel (HE only) or 320 MHz channel.
7
8
9 Change the now-shifted 14th paragraph as follows:
10
11
12 B0 of the RU Allocation subfield is set to 0 to indicate primary 20 MHz channel, primary 40 MHz channel
13
14
and primary 80 MHz channel. For primary 160 MHz, and 80+80 MHz, and 320 MHz indication, B0 of the
15 RU Allocation subfield is set to 1. A non-AP HE STA ignores B0 for primary 160 MHz and 80+80 MHz
16 (HE only) indication. A non-AP EHT STA checks B0 for primary 160 MHz and 320 MHz indication if the
17 non-AP EHT STA is addressed by an EHT variant User Info field. In an EHT variant User Info field, the
18 PS160 subfield is set to 1 to indicate 320 MHz channel and set to 0 to include primary 20 MHz channel, pri-
19
20
mary 40 MHz channel, primary 80 MHz channel, and primary 160 MHz channel.
21
22
23 Change the now-shifted 18th paragraph as follows:
24
25
26
B7–B1 of the RU Allocation subfield is set to 68 to indicate the primary and secondary 80 MHz channel if
27 the bandwidth of the PPDU that carries the MU-RTS Trigger frame is less than 320 MHz, or to indicate the
28 primary 160 MHz channel if the bandwidth of the PPDU that carries the MU-RTS Trigger frame is
29 320 MHz.
30
31
32 B7–B1 of the RU Allocation subfield is set to 69 to indicate the 320 MHz channel.
33
34
35 Change the now-shifted 20th paragraph and Figure 9-96 (UL BW subfield and B7–B1 of RU
36 Allocation subfield in MU-RTS Trigger frame for various bandwidths) as follows:
37
38
39 The settings for B7–B1 of the RU Allocation subfield are illustrated in Figure 9-96 (UL BW subfield and
40
41 B7–B1 of RU Allocation subfield in MU-RTS Trigger frame for various bandwidths)..
42
43
44 69
(320 MHz)
45
46
PS160 = 1

47
48
49
320 MHz (EHT only)

50
51
Bandwidth

52
53 68
54
B0 = 1

(80+80 MHz
160 MHz or 80+80 MHz

55 or primary 160
MHz)
56
PS160 = 0

57 Higher
Freq 66 (primary 40 MHz is 64 (primary 20 MHz is fourth lowest 20 MHz)
58 the second lowest 40
Increasing

B0 = 0

59
80 MHz

MHz) 63 (primary 20 MHz is third lowest 20 MHz)

67 (primary
60 80 MHz) 62 (primary 20 MHz is second lowest 20 MHz)
40 MHz

65 (primary 40 MHz
61 Lower is the lowest 40 MHz) 61 (primary 20 MHz is the lowest 20 MHz) 20 MHz
Freq
62
63
64
Figure 9-96—UL BW subfield and B7–B1 of RU Allocation subfield in MU-RTS Trigger frame
65 for various bandwidths

Copyright © 2022 IEEE. All rights reserved. 151

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 9.3.3 (PV0) Management frames

2
3
4 9.3.3.2 Beacon frame format
5
6
7 Update existing order 12 and insert four new rows to Table 9-60 (Beacon frame
8 body(#8264)(#1004)(#2246)(#3352)):.
9
10
11
12 Table 9-60—Beacon frame body(#8264)(#1004)(#2246)(#3352)
13
14
Order Information Notes
15
16 12 Quiet The Quiet element is optionally present if dot11SpectrumManage-
17 mentRequired is true or dot11RadioMeasurementActivated is true
18 or dot11RestrictedTWTOptionImplemented is true(#2215).
19
20 <Last Multi-Link (#3016)(#1005)(#1896)(#6700)(#8265)The Basic Multi-Link ele-
21 assigned + ment is present if dot11MultiLinkActivated is true; otherwise it is
22 1> not present.
23
24 <Last EHT Capabilities The EHT Capabilities element is present if dot11EHTOptionIm-
25 assigned + plemented is true; otherwise it is not present.
26 2>
27 <Last EHT Operation The EHT Operation element is present if dot11EHTOptionImple-
28 assigned + mented is true; otherwise it is not present.
29 3>
30
31 <Last Multi-Link Traffic The Multi-Link Traffic Indication element is present if
32 assigned + Indication dot11MultiLinkTIMActivated is true; otherwise it is not present.
33 4>
34
35
36
37 9.3.3.5 Association Request frame format
38
39
40 Insert three new rows to Table 9-62 (Association Request frame body(#1004)(#2246)(#3353)):.
41
42
43
44 Table 9-62—Association Request frame body(#1004)(#2246)(#3353)
45
46
Order Information Notes
47
48 <Last Multi-Link (#6700)(#8266)The Basic Multi-Link element is present if dot11-
49 assigned + MultiLinkActivated is true; otherwise it is not present.
50 1>
51
52 <Last EHT Capabilities The EHT Capabilities element is present if dot11EHTOptionIm-
53 assigned + plemented is true; otherwise it is not present.
54 2>
55
56 <Last TID-To-Link Map- One or two TID-To-Link Mapping elements are present if dot11-
57 assigned + ping MultiLinkActivated is true, dot11TIDtoLinkMappingActivated is
58 3> true, and a non-AP STA (#6581)affiliated with a non-AP MLD
59 initiates (#5320)both an MLD association (see 11.3 (STA authen-
60 ticationAuthentication and association(#2277)))(#8222) and a
61 TID-to-link mapping negotiation. Otherwise it is not present.
62 - If two TID-To-Link Mapping elements are present then the
63 Direction subfield in one of the TID-To-Link Mapping ele-
64 ments is set to 0 and the Direction subfield in the other TID-To-
65 Link Mapping element is set to 1.

152 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 9.3.3.6 Association Response frame format

2
3
4
Insert four new rows to Table 9-63 (Association Response frame body(#1004)(#2246)(#3354)):.
5
6
7 Table 9-63—Association Response frame body(#1004)(#2246)(#3354)
8
9
10 Order Information Notes
11
12 <Last Multi-Link (#6700)(#8267)The Basic Multi-Link element is present if dot11-
13 assigned + MultiLinkActivated is true; otherwise it is not present.
14 1>
15 <Last EHT Capabilities The EHT Capabilities element is present if dot11EHTOptionIm-
16 assigned + plemented is true; otherwise it is not present.
17 2>
18
19 <Last EHT Operation The EHT Operation element is present if dot11EHTOptionImple-
20 assigned + mented is true; otherwise it is not present.
21 3>
22
<Last TID-To-Link Map- One or two TID-To-Link Mapping elements are (#5320)present if
23
assigned + ping dot11MultiLinkActivated is true, dot11TIDtoLinkMappingActi-
24
4> vated is true, and the AP sends an Association Response frame in
25
response to a received Association Request frame that is initiating
26
both a multi-link setup and a TID-to-link mapping negotiation.
27
Otherwise it is not present.
28
- If two TID-To-Link Mapping elements are present then the
29
Direction subfield in one of the TID-To-Link Mapping ele-
30
ments is set to 0 and the Direction subfield in the other TID-To-
31
Link Mapping element is set to 1.
32
33
34
35 9.3.3.7 Reassociation Request frame format
36
37
38 Insert three new rows to Table 9-64 (Reassociation Request frame
39 body(#1004)(#2246)(#3355)):.
40
41
42 Table 9-64—Reassociation Request frame body(#1004)(#2246)(#3355)
43
44
45 Order Information Notes
46
47 <Last Multi-Link (#6700)(#8268)The Basic Multi-Link element is present if dot11-
48 assigned + MultiLinkActivated is true; otherwise it is not present.
49 1>
50
51 <Last EHT Capabilities The EHT Capabilities element is present if dot11EHTOptionIm-
52 assigned + plemented is true; otherwise it is not present.
53 2>
54 <Last TID-To-Link Map- One or two TID-To-Link Mapping elements are present if dot11-
55 assigned + ping MultiLinkActivated is true, dot11TIDtoLinkMappingActivated is
56 3> true, and a non-AP STA (#6581)affiliated with a non-AP MLD
57 initiates (#5320)both a multi-link resetup and a TID-to-link map-
58 ping negotiation. Otherwise it is not present.
59 - If two TID-To-Link Mapping elements are present then the
60 Direction subfield in one of the TID-To-Link Mapping ele-
61 ments is set to 0 and the Direction subfield in the other TID-To-
62 Link Mapping element is set to 1.
63
64
65

Copyright © 2022 IEEE. All rights reserved. 153

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 9.3.3.8 Reassociation Response frame format

2
3
4
Insert four new rows to Table 9-65 (Reassociation Response frame
5 body(#1004)(#2246)(#3356)):.
6
7
8 Table 9-65—Reassociation Response frame body(#1004)(#2246)(#3356)
9
10
11 Order Information Notes
12
13 <Last Multi-Link (#6700)(#8269)The Basic Multi-Link element is present if dot11-
14 assigned + MultiLinkActivated is true; otherwise it is not present.
15 1>
16 <Last EHT Capabilities The EHT Capabilities element is present if dot11EHTOptionIm-
17 assigned + plemented is true; otherwise it is not present.
18 2>
19
20 <Last EHT Operation The EHT Operation element is present if dot11EHTOptionImple-
21 assigned + mented is true; otherwise it is not present.
22 3>
23
24 <Last TID-To-Link Map- One or two TID-To-Link Mapping elements are (#5320)present if
25 assigned + ping dot11MultiLinkActivated is true, dot11TIDtoLinkMappingActi-
26 4> vated is true, and the AP sends a Reassociation Response frame in
27 response to a received Reassociation Request frame that is initiat-
28 ing both a multi-link resetup and a TID-to-link mapping negotia-
29 tion. Otherwise it is not present.
30 - If two TID-To-Link Mapping elements are present then the
31 Direction subfield in one of the TID-To-Link Mapping ele-
32 ments is set to 0 and the Direction subfield in the other TID-To-
33 Link Mapping element is set to 1.
34
35
36
37
9.3.3.9 Probe Request frame format
38
39 Insert two new rows to Table 9-66 (Probe Request frame body(#1004)(#2246)(#3357)):.
40
41
42 Table 9-66—Probe Request frame body(#1004)(#2246)(#3357)
43
44
45 Order Information Notes
46
47 <Last Multi-Link (#1006)(#2095)(#1774)(#1897)(#2860)(#1831)(#1155)(#1414)(#
48 assigned + 2581)(#3367)(#3359)(#2859)(#6701)The Probe Request Multi-
49 1> Link element is present if dot11MultiLinkActivated is true and the
50 Probe Request frame is an ML probe request as defined in
51 35.3.4.2 (Use of ML probe request and response(#2583)(#3360)).
52 Otherwise the Multi-Link element is not present(#4001).
53
54 <Last EHT Capabilities The EHT Capabilities element is present if dot11EHTOptionIm-
55 assigned + plemented is true; otherwise it is not present.
56 2>
57
58
59
60
61
62
63
64
65

154 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 9.3.3.10 Probe Response frame format

2
3
4 Change existing order 11 and insert three new rows to Table 9-67 (Probe Response frame
5 body(#1004)(#2246)(#3359)):.
6
7
8
9 Table 9-67—Probe Response frame body(#1004)(#2246)(#3359)
10
11
Order Information Notes
12
13 11 Quiet The Quiet element is optionally present if dot11SpectrumManage-
14 mentRequired is true or if dot11RadioMeasurementActivated is
15 true or dot11RestrictedTWTOptionImplemented is true(#2215).
16
17 <Last Multi-Link (#3016)(#1005)(#1896)(#1007)(#2861)(#1898)(#2860)(#1155)(#
18 assigned + 1414)(#2581)(#3367)(#3359)(#2859)(#6700)The Basic Multi-
19 1> Link element is present if the AP is affiliated with an AP MLD.
20 Otherwise it is not present.
21
22 <Last EHT Capabilities The EHT Capabilities element is present if dot11EHTOptionIm-
23 assigned + plemented is true; otherwise it is not present.
24 2>
25 <Last EHT Operation The EHT Operation element is present if dot11EHTOptionImple-
26 assigned + mented is true; otherwise it is not present.
27 3>
28
29
30
31
32 9.3.3.11 Authentication frame format
33
34
35 Insert a new row to Table 9-68 (Authentication frame body):.
36
37
38 Table 9-68—Authentication frame body
39
40
41 Order Information Notes
42
43 <Last Multi-Link (#6700)(#4002)The Basic Multi-Link element is present if the
44 assigned + STA is affiliated with an MLD and the frame exchange is with a
45 1> peer STA that is affiliated with an MLD. Otherwise it is not pres-
46 ent.
47
48
49
50 Change Table 9-71 (Action frame body and Action No Ack frame body) as follows:
51
52
53 Table 9-71—Action frame body and Action No Ack frame body
54
55
56 Order Information
57
58 Last – 2 One or more Vendor Specific elements are optionally present.
59
60 These elements are absent when the Category subfield of the Action field is Vendor-Specific,
61 Vendor-Specific Protected, or Self-protected or when the Category subfield of the Action field is
62 VHT and the VHT Action subfield of the Action field is VHT Compressed Beamforming, or
63 when the Category subfield of the Action field is HE and the HE Action subfield of the Action
64 field is HE Compressed Beamforming/CQI, or when the Category subfield of the Action field is
65 EHT and the EHT Action subfield of the Action field is EHT Compressed Beamforming/CQI.

Copyright © 2022 IEEE. All rights reserved. 155

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 9.4 Management and Extension frame body components

2
3
4 9.4.1 Fields that are not elements
5
6 9.4.1.4 Capability Information field
7
8
9 Change Figure 9-132 (Capability Information field format (non-DMG STA)(#4064)(#5258)) as
10 follows:
11
12
13 B0 B1 B2 B3 B4 B5 B6 B7
14
15 Reserved Reserved
16 Short Critical Nontransmitted
ESS IBSS Reserved Reserved Privacy
Preamble Update BSSIDs Critical
17 Flag Update Flag
18
19
20
21
B8 B9 B10 B11 B12 B13 B14 B15
22
23
24 Spectrum Short Slot Radio
QoS APSD EPD Reserved Reserved
Management Time Measurement
25
26
27 Figure 9-132—Capability Information field format (non-DMG STA)(#4064)(#5258)
28
29
30 Insert the following three paragraphs after the fourteenth paragraph (“An ERP STA sets ...”):
31
32
33 The Critical Update Flag subfield is reserved except when the Capability Information field is carried in a
34 Beacon or a Probe Response frame transmitted by an AP (#1237)affiliated with an AP MLD.
35
36 (#1237)(#1900)(#2848)(#3012)An AP affiliated with an AP MLD sets the Critical Update Flag subfield to 1
37
38
if there is a change to a value carried in the (#1068)BSS Parameters Change Count subfield of the MLD
39 Parameters field in the Reduced Neighbor Report element for any AP affiliated with the same AP MLD.
40 Otherwise the AP sets the subfield to 0 (See 35.3.10 (BSS parameter critical update procedure)).
41
42
(#4064)(#5258)The Nontransmitted BSSIDs Critical Update Flag subfield is reserved except when the
43
44 Capability Information field is carried in a Beacon or a Probe Response frame transmitted by an AP corre-
45 sponding to the transmitted BSSID in a multiple BSSID set and there exists at least one AP in the multiple
46 BSSID set that is affiliated with an AP MLD. An AP affiliated with an AP MLD sets the Nontransmitted
47 BSSIDs Critical Update Flag subfield to 1 if the Critical Update Flag subfield of the Nontransmitted BSSID
48
Capability field is set to 1 in at least one nontransmitted BSSID profile in the Multiple BSSID element in the
49
50 same frame. Otherwise the AP sets the subfield to 0.
51
52 9.4.1.5 Current AP Address field
53
54
55 Change as follows:
56
57
58
If the current association is between a non-AP STA and an AP, Tthe Current AP Address field is the MAC
59 address of the AP with which the STA is currently associated. If the current association is between a non-AP
60 MLD and an AP MLD, then the Current AP Address field is the MLD MAC address of the AP MLD with
61 which the non-AP MLD is currently associated. The length of the Current AP Address field is 6 octets. The
62 Current AP Address field is shown in Figure 9-87 (Current AP Address field format).
63
64
65

156 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 9.4.1.6 Listen Interval field

2
3
4
Change the first paragraph as follows:
5
6 When a (re)association is not for an MLD association (see 11.3 (STA authenticationAuthentication and
7 association(#2277)))(#8222), theThe Listen Interval field is used to indicate to the AP how often an S1G
8 STA with dot11NonTIMModeActivated equal to false or a non-S1G STA in power save mode wakes to
9
10
listen to Beacon frames. It is also used to indicate to an AP the duration during which an S1G STA with
11 dot11NonTIMModeActivated equal to true is required to transmit at least one frame that is addressed to the
12 associated AP. This field is derived from the ListenInterval parameter when present as a parameter of an
13 MLME primitive. The value is in units of beacon interval if dot11ShortBeaconInterval is false and in units
14 of short beacon interval if dot11ShortBeaconInterval is true (see 11.1.3.10.2 (Generation of S1G Beacon
15
16
frames)).
17
18 When a (re)association is for an MLD association (see 11.3 (STA authenticationAuthentication and associa-
19 tion(#2277)))(#8222), the Listen Interval field is used to indicate to the AP MLD how often at least a STA
20 affiliated with a non-AP MLD wakes to listen to Beacon frames if all STAs affiliated with the non-AP
21
22 MLD(#8222) are in power save mode. This field is derived from the ListenInterval parameter when present
23 as a parameter of an MLME primitive. The value is in units of the maximum value of beacon intervals corre-
24 sponding to the links that the non-AP MLD intends to setup in the (Re)Association Request frame.
25
26 The length of the Listen Interval field is 2 octets. The Listen Interval field is shown in Figure 9-88 (Listen
27
28 Interval field format carried in a non-S1G PPDU).
29
30 Change the second paragraph as follows:
31
32 NOTE—The value 0 might be used by a STA that is not affiliated with an MLD or all STAs affiliated with an MLD that
33 never enters power save mode.
34
35
36 Change the last paragraph as follows:
37
38 When a (re)association is not for an MLD association (see 11.3 (STA authenticationAuthentication and
39 association(#2277)))(#8222), anAn AP uses the listen interval in determining the lifetime of frames that it buf-
40
41 fers for a STA.
42
43 An AP MLD uses the listen interval in determining the lifetime of frames that it buffers for a non-AP MLD.
44
45
9.4.1.8 AID field
46
47
48 Change the first paragraph as follows:
49
50 In infrastructure BSS operation, the AID field contains a value assigned by (#4390)an AP, or PCP or an AP
51
52
MLD during association. The field represents the 16-bit ID of a STA when assigned by an AP or PCP. The
53 field represents the 16-bit ID of a non-AP MLD when assigned by an AP MLD. In mesh BSS operation, the
54 AID field is a value that represents the 16-bit ID of a neighbor peer mesh STA, assigned during mesh peer-
55 ing. The length of the AID field is 2 octets. The AID field is shown in Figure 9-138 (AID field format).
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 157

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 9.4.1.9 Status Code field

2
3
4 Insert the following news rows to Table 9-78 (Status codes) while maintaining the numerical
5 order and updating the reserved range:
6
7
8 Table 9-78—Status codes
9
10
11 Status code Name Meaning
12
13 130 DENIED_STA_AFFILIAT- Association denied because the requesting STA is affili-
14 ED_WITH_MLD_WITH_EXIST- ated with a non-AP MLD that is associated with the AP
15 ING_MLD_ASSOCIATION MLD.
16
17 131 (#5284)EPCS_DENIED_UNAUTHO- (#5284)(#1008)EPCS priority access denied because the
18 RIZED (#7538)non-AP MLD is not authorized to use the ser-
19 vice.
20 132 (#5284)EPCS_DENIED- (#5284)EPCS priority access denied due to reason out-
21 _OTHER_REASON side the scope of this standard.
22
23 133 DENIED_TID_TO_LINK_MAPPING Request denied because the requested TID-to-link map-
24 ping is unacceptable.
25
26 134 PREFERRED_TID_TO_LINK_MAP- Preferred TID-to-link mapping suggested.
27 PING_SUGGESTED
28 (#4006)135 DENIED_EHT_NOT_SUPPORTED Association denied because the requesting STA does not
29 support EHT features.
30
31
32
33 9.4.1.11 Action field
34
35
36
Insert the following news row to Table 9-79 (Category values(#4007)(#4299)) while maintaining
37 the numerical order and updating the reserved range:.
38
39
40 Table 9-79—Category values(#4007)(#4299)
41
42
43 Group
44 Code Meaning See subclause Robust addressed
45 privacy
46
47 36 EHT 9.6.34 (EHT Action frame No No
48 details(#1119)(#1488))
49
37 Protected EHT 9.6.35 (Protected EHT Action Yes No
50
frame details)
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

158 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 9.4.1.53 Operating Mode field

2
3
4
Change the Rx NSS row in Table 9-108 (Subfield values of the Operating Mode field) as
5 follows:
6
7
8 Table 9-108—Subfield values of the Operating Mode field
9
10
11 Subfield Description
12
13 Rx NSS If the STA that transmits the Operating Mode field (STA1) and the receiver of
14 the Operating Mode field (STA2) are not both HE STAs and if the Rx NSS Type
15 subfield is 0, then this field, combined with other information described in
16 9.4.2.157.3 (Supported VHT-MCS and NSS Set field), indicates the maximum
17 number of spatial streams that STA1 can receive.
18
19 If the STA that transmits the Operating Mode field (STA1) and the receiver of
20 the Operating Mode field (STA2) are both HE STAs, and if the Rx NSS Type
21 subfield is 0, then the following apply:
22 — The value of this field, combined with other information described in
23
9.4.2.157.3 (Supported VHT-MCS and NSS Set field), indicates the
24
25 maximum number of spatial streams that the HE STA can receive in a
26 VHT PPDU
27 — The value of this field, combined with other information described in
28 9.4.2.248.4 (Supported HE-MCS And NSS Set field), indicates the
29 maximum number of spatial streams that STA1 can receive in an HE
30 PPDU.
31
32 — (#4164)If both STAs are also EHT STAs, then the value of this field,
33 combined with other information as described in 9.4.2.313.4 (Supported
34 EHT-MCS And NSS Set field(#1126)), indicates the maximum number
35 of spatial streams that STA1 can receive in an EHT PPDU.
36
37 If the Rx NSS Type subfield is 1, this field, indicates the maximum number of
38 spatial streams that the STA can receive as a beamformee in an SU PPDU using
39 a beamforming steering matrix derived from a VHT Compressed Beamforming
40 report with Feedback Type subfield indicating MU in the corresponding VHT
41 Compressed Beamforming frame sent by the STA.
42
43 In a non-S1G STA:
44 Set to 0 for NSS = 1
45 Set to 1 for NSS = 2
46 …
47 Set to 7 for NSS = 8
48
49 In an S1G STA:
50 Set to 0 for NSS = 1
51 Set to 1 for NSS = 2
52 Set to 2 for NSS = 3
53 Set to 3 for NSS = 4
54
55
56 NOTE—In a STA with dot11VHTExtendedNSSBWCapable equal to true, NSS
57 might be further modified for VHT PPDUs per Table 9-109 (Setting of the
58 Channel Width subfield and 160/80+80 BW subfield at a VHT STA transmit-
59 ting the Operating Mode field). In an HE STA with dot11VHTExtendedNSSB-
60 WCapable equal to true, NSS might be further modified for HE PPDUs per
61 Equation (9-5). (#4164)In an EHT STA with dot11VHTExtendedNSSBWCa-
62 pable equal to true, NSS might be further modified for EHT PPDUs per
63 Equation (9-5a)
64
65

Copyright © 2022 IEEE. All rights reserved. 159

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Insert the following paragraph and NOTE at the end of the subclause:
2
3
4 (#4164)The maximum number of spatial streams that the STA supports in reception for a given EHT-MCS
5 as a function of the received EHT PPDU bandwidth at an EHT STA transmitting an Operating Mode field is
6 defined as
7
8
9
floor  Rx-NSS-from-OMF   Max-EHT-NSS-at-BW  Max-EHT-NSS-at-80   (9-5a)
10
11
12
13 where
14 Rx-NSS-from-OMF is NSS from the Operating Mode field transmitted by the STA.
15
16 Max-EHT-NSS-at-BW is the maximum NSS among all EHT-MCS at BW MHz from the Supported
17
18
EHT-MCS And NSS Set field transmitted by the STA.
19 Max-EHT-NSS-at-80 is the maximum NSS among all EHT-MCS at 80 MHz from the Supported
20 EHT-MCS And NSS Set field transmitted by the STA.
21
22 NOTE 2—For an operating mode between two EHT STAs, the Rx NSS subfield in the Operating Mode field indicates
23 the maximum number of spatial streams at channel width less than or equal to 80 MHz.
24
25
26 Insert the following new subclauses at the end of 9.4.1:
27
28
29 9.4.1.70 EHT MIMO Control field
30
31 The EHT MIMO Control field is defined in Figure 9-144h (EHT MIMO Control field format).
32
33
34 B0 B3 B4 B7 B8 B10 B11 B12 B13 B14 B16
35
36 Feedback
Nc Index Nr Index BW Grouping Reserved
37 Type
38
39 Bits: 4 4 3 1 2 3
40
41 B17 B19 B20 B21 B29 B30 B35 B36 B37 B39
42
43 Remaining First Sounding
44 Partial BW Codebook
Feedback Feedback Dialog Token Reserved
Segments Segment Info Number Information
45
46
47 Bits: 3 1 9 6 1 3
48
49 Figure 9-144h—EHT MIMO Control field format
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

160 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The subfields of the EHT MIMO Control field are defined in Table 9-127a (EHT MIMO Control field
2 encoding).
3
4
5
6 Table 9-127a—EHT MIMO Control field encoding
7
8
Subfield Description
9
10 Nc Index (#1639)If the Feedback Type subfield indicates SU or MU, the Nc Index
11 subfield indicates the number of columns in the compressed beamform-
12 ing feedback matrix minus 1, Nc – 1 .
13
14 If the Feedback Type subfield indicates CQI, the Nc Index subfield
15 indicates the number of spatial streams, Nc , in the CQI report and is set
16 to Nc – 1 .
17
18 (#1639)Nc Index subfield values above 7 are reserved.
19
20 Nr Index (#1639)If the Feedback Type subfield indicates SU or MU, the Nr Index
21 subfield indicates the number of rows in the compressed beamforming
22 feedback matrix minus 1, Nr – 1 . (#5025)The values 0 and 8–15 are
23 reserved.
24
25 If the Feedback Type subfield indicates CQI, then the Nr Index subfield
26 is reserved.
27
28 BW (#4331)(#4889)(#5676)The value of the BW subfield corresponds to the
29 bandwidth of EHT sounding NDP. The values 5–7 are reserved.
30 Set to 0 for 20 MHz
31 Set to 1 for 40 MHz
32 Set to 2 for 80 MHz
33 Set to 3 for 160 MHz
34 Set to 4 for 320 MHz
35 Grouping If the Feedback Type subfield indicates SU or MU, then the Grouping
36 subfield indicates the subcarrier grouping, Ng , used for the compressed
37 beamforming feedback matrix:
38 Set to 0 for Ng = 4
39 Set to 1 for Ng = 16
40 If the Feedback Type subfield indicates CQI, then the Grouping subfield
41 is reserved.
42
43 Codebook Information Indicates the size of codebook entries.
44 If the Feedback Type subfield indicates SU:
45 Set to 0 for 4 bits for  and 2 bits for 
46 Set to 1 for 6 bits for  and 4 bits for 
47 If the Feedback Type subfield indicates MU:
48 Set to 0 for 7 bits for  and 5 bits for 
49 Set to 1 for 9 bits for  and 7 bits for 
50 If the Feedback Type subfield indicates CQI, then the Codebook Infor-
51 mation subfield is reserved.
52
53 NOTE—The codebook size for MU feedback with Ng = 16 is limited
54 to     =  9 7  .
55 Feedback Type Indicate the feedback type:
56 Set to 0 for SU
57 Set to 1 for MU
58 Set to 2 for CQI
59 3 is reserved
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 161

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 9-127a—EHT MIMO Control field encoding (continued)

2
3
4 Subfield Description
5
6 Remaining Feedback Indicates the number of remaining feedback segments for the associated
7 Segments EHT Compressed Beamforming/CQI frame:
8 Set to 0 for the last feedback segment of a segmented report or the
9 only feedback segment of an unsegmented report.
10 Set to a value between 1 and 7 for a feedback segment that is not the
11 last feedback segment of a segmented report.
12 First Feedback Segment Set to 1 for the first feedback segment of a segmented report or the only
13 feedback segment of an unsegmented report.
14 Set to 0 if not the first feedback segment or if the EHT Compressed
15 Beamforming Report field and EHT MU Exclusive Beamforming Report
16 field are not present in the frame.
17
18 NOTE—The First Feedback Segment subfield is always set to 0 if the
19 Feedback Type subfield indicates CQI because the EHT Compressed
20 Beamforming/CQI Report frame is always less than 11454 octets in
21 length.
22
23 Partial BW Info This field is defined as in Figure 9-80b (Partial BW Info subfield format).
24 The Resolution bit indicates the feedback resolution bandwidth. Set to 0
25 to indicate resolution of 20 MHz if the BW subfield is set to 0 to 3. Set to
26 1 to indicate resolution of 40 MHz if the BW subfield is set to 4.
27 The Feedback Bitmap subfield indicates each resolution bandwidth that
28 the beamformer is requesting feedback. Each bit in the Feedback Bitmap
29 subfield is set to 1 if the feedback on the corresponding bandwidth is
30 requested, and is set to 0 otherwise.
31 Sounding Dialog Token Set to the same value as the Sounding Dialog Token Number field in the
32 Number corresponding EHT NDP Announcement frame.
33
34
35
36 In an EHT Compressed Beamforming/CQI frame not carrying all or part of an EHT compressed beamform-
37 ing/CQI report (see 35.7 (EHT sounding operation(#5853)(#8363)) for a description of such a case), the Nc
38 Index, Nr Index, BW, Grouping, Codebook Information, Feedback Type, and Sounding Dialog Token Num-
39
40 ber subfields are reserved, the First Feedback Segment subfield is set to 0, and the Remaining Feedback Seg-
41 ments subfield is set to 7.
42
43 9.4.1.71 EHT Compressed Beamforming Report field
44
45
46 The EHT Compressed Beamforming Report field carries the average SNR of each spatial stream and com-
47 pressed beamforming feedback matrices V for use by a transmit beamformer to determine steering matrices
48 Q , as described in 10.34.3 (Explicit feedback beamforming) and 19.3.12.3 (Explicit feedback beamform-
49 ing).
50
51
52 The size of the EHT Compressed Beamforming Report field depends on the values in the EHT MIMO Con-
53 trol field. The EHT Compressed Beamforming Report field contains EHT compressed beamforming report
54 information or successive (possibly zero-length) portions thereof in the case of segmented EHT compressed
55 beamforming/CQI report (see 35.7.4 (Rules for generating segmented feedback)). EHT compressed beam-
56
forming report information is included in the EHT compressed beamforming/CQI report if the Feedback
57
58 Type subfield in the EHT MIMO Control field indicates SU or MU.
59
60 The EHT Compressed Beamforming Report information contains the channel matrix elements indexed,
61 first, by matrix angles in order shown in Table 9-71 (Order of angles in the compressed beamforming feed-
62
back matrix when used in a non-S1G band), and second, by data and pilot subcarrier index from lowest fre-
63
64 quency to highest frequency. An explanation of how these angles are generated from the beamforming
65 feedback matrix V is given in 19.3.12.3.6 (Compressed beamforming feedback matrix), where Nc is the

162 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 number of columns in a compressed beamforming feedback matrix determined by the Nc Index subfield of
2 the EHT MIMO Control field, and N r is the number of rows in a compressed beamforming feedback matrix
3
determined by the Nr Index subfield of the EHT MIMO Control field.
4
5
6 The beamforming feedback matrix V is formed by the beamformee as follows. The beamformer transmits
7
8
an EHT sounding NDP with N SS NDP spatial streams, where N SS NDP takes a value between 2 and 8(#2228).
9 Based on this EHT sounding NDP, the beamformee estimates the N RX BFEE  N SS NDP channel, and based on
10 that channel it determines a Nr  Nc orthogonal matrix V , where N r and Nc satisfy Equation (9-1).
11 N RX BFEE is the number of receiver chains used to receive the EHT sounding NDP at the beamformee.
12
13
14 Further restrictions on Nc are described in 36.2 (EHT PHY service interface). The angles are quantized as
15 defined in Table 9-74 (Quantization of angles) with b  (bits for  ) and b  (bits for  )(#2229)(#5398)
16 defined by the Codebook Information field of the EHT MIMO Control field (see 9.4.1.70 (EHT MIMO
17
18 Control field)).
19
20 The EHT Compressed Beamforming Report information has the structure and order defined in Table 9-
21
22 91b (HE Compressed Beamforming Report information), where Na is the number of angles used for the
23 compressed beamforming feedback matrix (see Table 9-73 (Order of angles in the compressed beamforming
24 feedback matrix when used in a non-S1G band)).
25
26
27 In Table 9-91b (HE Compressed Beamforming Report information), Ns is the number of subcarriers for
28 which a compressed beamforming feedback matrix is sent back to the beamformer. A beamformer or beam-
29 formee, depending upon which of the two determines the feedback parameters, reduces Ns by using a
30 method referred to as grouping, in which only a single compressed beamforming feedback matrix is reported
31
32 for each group of Ng adjacent subcarriers. Ns is a function of the BW, Partial BW Info, and Grouping sub-
33 fields in the EHT MIMO Control field (see 9.4.1.70 (EHT MIMO Control field)).
34
35
36 Subcarrier indices scidx  i  , i = 0 1  Ns – 1 , are a concatenation of the subcarrier indices for each
37 242-tone RU or 996-tone RU in the frequency order, identified by the Partial BW Info subfields together
38 with the BW and Grouping subfields. The subcarrier indices for each 242-tone RU or 996-tone RU are
39 defined in Table 9-127b (Subcarrier indices when not all bits in Partial BW Info subfield corresponding to
40
the 80 MHz subblock are set to 1(#4890)(#1279)), Table 9-127c (Subcarrier indices when all bits in Partial
41
42 BW Info subfield corresponding to the 80 MHz subblock are set to 1 for Ng = 4(#4890)(#1279)), and
43 Table 9-127d (Subcarrier indices when all bits in Partial BW Info subfield corresponding to the 80 MHz
44 subblock are set to 1 for Ng = 16(#4890)(#1279)).
45
46
47
Table 9-127b—Subcarrier indices when not all bits in Partial BW Info subfield correspond-
48
49 ing to the 80 MHz subblock are set to 1(#4890)(#1279)
50
51
242-tone
52 20 MHz 40 MHz 80 MHz 160 MHz 320 MHz
RU index
53
54 1 Ng = 4 [–122, [–244:Ng:–4] [–500:Ng: [–1012:Ng: [–2036:Ng:
55 –120:4:–4, –260] –772] –1796]
56 –2, 2,
57 4:4:120, 122]
58
59 Ng = 16 [–122,
60 –116:16:–4,
61 –2, 2,
62 4:16:116, 122]
63
64 2 [4:Ng:244] [–252:Ng:–12] [–764:Ng: [–1788:Ng:
65 –524] –1548]

Copyright © 2022 IEEE. All rights reserved. 163

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 9-127b—Subcarrier indices when not all bits in Partial BW Info subfield correspond-
2 ing to the 80 MHz subblock are set to 1(#4890)(#1279) (continued)
3
4
5 242-tone
6 20 MHz 40 MHz 80 MHz 160 MHz 320 MHz
RU index
7
8 3 [12:Ng:252] [–500:Ng: [–1524:Ng:
9 –260] –1284]
10
11 4 [260:Ng:500] [–252:Ng:–12] [–1276:Ng:
12 –1036]
13 5 [12:Ng:252] [–1012:Ng:
14 –772]
15
16 6 [260:Ng:500] [–764:Ng:
17 –524]
18
19 7 [524:Ng:764] [–500:Ng:
20 –260]
21 8 [772:Ng:1012] [–252:Ng:–12]
22
23 9 [12:Ng:252]
24
10 [260:Ng:500]
25
26 11 [524:Ng:764]
27
28 12 [772:Ng:1012]
29
13 [1036:Ng:
30
1276]
31
32 14 [1284:Ng:
33 1524]
34
35 15 [1548:Ng:
36 1788]
37 16 [1796:Ng:
38 2036]
39
40 NOTE– : N g: denotes an arithmetic progression in Ng increments.
41
42
43
44 Table 9-127c—Subcarrier indices when all bits in Partial BW Info subfield corresponding to
45 the 80 MHz subblock are set to 1 for Ng = 4(#4890)(#1279)
46
47
48 996-tone
80 MHz 160 MHz 320 MHz
49 RU index
50
51 1 [–500:4:–4, [–1012:4:–516, [–2036:4:–1540,
52 4:4:500] –508:4:-12] –1532:4:–1036]
53 2 [12:4:508, [–1012:4:–516,
54 516:4:1012] –508:4:–12]
55
56 3 [12:4:508,
57 516:4:1012]
58
4 [1036:4:1532,
59
1540:4:2036]
60
61
62
63
64
65

164 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 9-127d—Subcarrier indices when all bits in Partial BW Info subfield corresponding to
2 the 80 MHz subblock are set to 1 for Ng = 16(#4890)(#1279)
3
4
5 996-tone
6 80 MHz 160 MHz 320 MHz
RU index
7
8 1 [–500:16:–260, [–1012:16:–772, [–2036:16:–1796,
9 –252:16:–12, –764:16:–524, –1788:16:–1548,
10 –4, 4, –516, –508, –1540, –1532,
11 12:16:252, –500:16:–260, –1524:16:–1284,
12 260:16:500] –252:16:–12] –1276:16:–1036]
13
14 2 [12:16:252, [–1012:16:–772,
15 260:16:500, –764:16:–524,
16 508, 516, –516, –508,
17 524:16:764, –500:16:–260,
18 772:16:1012] –252:16:–12]
19 3 [12:16:252,
20 260:16:500,
21 508, 516,
22 524:16:764,
23 772:16:1012]
24
25 4 [1036:16:1276,
26 1284:16:1524,
27 1532, 1540,
28 1548:16:1788,
29 1796:16:2036]
30
31
32
33
The Partial BW Info subfield values are set according to the bandwidth of the EHT NDP Announcement
34 frame and the RU/MRU in which the feedback is solicited, see Table 9-42c (Settings for BW, Partial BW
35 Info subfield in the EHT NDP Announcement frame(#8157)).
36
37
For an EHT NDP Announcement frame of bandwidth 20 MHz or 40 MHz, the subcarrier indices of 242-
38
39 tone RU for each 20 MHz indicated in the Partial BW Info subfield is included in the feedback report.
40
41 For an EHT NDP Announcement frame of bandwidth larger than or equal to 80 MHz, in each 80 MHz sub-
42 block(#1279), if the Partial BW Info subfield indicates the feedback of the entire 80 MHz (all the bits corre-
43
44 sponding to the 80 MHz subblock are set to 1)(#4890), the compressed beamforming information related
45 to(#5085) subcarrier indices of the corresponding 996-tone RU is included in the feedback; otherwise the
46 compressed beamforming information related to(#5085) subcarrier indices of 242-tone RU for each 20 MHz
47 indicated by Partial BW Info subfield is(#5085) included in the feedback report.
48
49 NOTE—This implicitly defines Ns .
50
51
52
The Average SNR of Space-Time Stream i subfield in Table 9-91b (HE Compressed Beamforming Report
53 information) is an 8-bit 2s complement integer defined in Table 9-77 (Average SNR of Space-Time Stream i
54 subfield).
55
56
The AvgSNRi in Table 9-77 (Average SNR of Space-Time Stream i subfield) is found by computing the
57
58 SNR per subcarrier in decibels for the subcarriers identified in Table 9-127b (Subcarrier indices when not all
59 bits in Partial BW Info subfield corresponding to the 80 MHz subblock are set to 1(#4890)(#1279)),
60 Table 9-127c (Subcarrier indices when all bits in Partial BW Info subfield corresponding to the 80 MHz
61 subblock are set to 1 for Ng = 4(#4890)(#1279)), and Table 9-127d (Subcarrier indices when all bits in Par-
62
tial BW Info subfield corresponding to the 80 MHz subblock are set to 1 for Ng = 16(#4890)(#1279)), and
63
64 then computing the arithmetic mean of those values. Each SNR value per subcarrier in stream i (before
65 being averaged) corresponds to the SNR associated with column i of the beamforming feedback matrix V

Copyright © 2022 IEEE. All rights reserved. 165

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 determined at the beamformee. Each SNR corresponds to the predicted SNR at the beamformee when the
2 beamformer applies all columns of the matrix V .
3
4
5 Padding is not present between angles in the EHT compressed beamforming report information, even if they
6 correspond to different subcarriers. If the size of the EHT compressed beamforming report information is
7 not an integer multiple of 8 bits, up to seven 0s are appended to the end of the field to make its size an inte-
8
9
ger multiple of 8 bits.
10
11 9.4.1.72 EHT MU Exclusive Beamforming Report field
12
13
14 The EHT MU Exclusive Beamforming Report field carries explicit feedback in the form of delta SNRs. The
15 information in the EHT Compressed Beamforming Report field and the EHT MU Exclusive Beamforming
16 Report field can be used by the transmit MU beamformer to determine the steering matrices Q , as described
17 in 36.3.3.1 (DL MU-MIMO).
18
19
20 The size of the EHT MU Exclusive Beamforming Report field depends on the values in the EHT MIMO
21 Control field. The EHT MU Exclusive Beamforming Report field contains EHT MU Exclusive Beamform-
22 ing Report information or successive (possibly zero-length) portions thereof in the case of segmented EHT
23
24 compressed beamforming/CQI report (see 35.7.4 (Rules for generating segmented feedback)). EHT MU
25 Exclusive Beamforming Report information is included in the EHT compressed beamforming/CQI report
26 (in addition to EHT compressed beamforming report information) if the Feedback Type subfield in the EHT
27 MIMO Control field indicates MU.
28
29
30 The EHT MU exclusive beamforming report information consists of Delta SNR subfields for each of the
31 spatial streams, 1 to Nc , of a subset of subcarriers typically spaced Ng apart, where Ng is signaled in the
32 Grouping subfield of the EHT MIMO Control field. The subset of subcarriers starts from the lowest fre-
33
quency subcarrier and continues to the highest frequency subcarrier. The subcarrier indices of the feedback
34
35 for each Delta SNR subfield are identical to the subcarrier indices for the compressed beamforming feed-
36 back matrix V .
37
38 NOTE—The feedback subcarrier spacings are mostly equal to Ng , but there are a few exceptions, generally around the
39 RU edge and the DC tone, where extra feedback subcarriers are added to improve the channel interpolation/extrapolation
40 quality.
41
42 No padding is present between SNRk i in the EHT MU Exclusive Beamforming Report field, even if they
43
44
correspond to different subcarriers. The subset of subcarriers included is determined by the values of the
45 Partial BW Info and Grouping subfields of the EHT MIMO Control field. For each subcarrier included, the
46 deviation in decibels of the SNR of that subcarrier for each column of V relative to the average SNR of the
47 corresponding spatial stream is computed using Equation (9-2) except that k is the subcarrier index in the
48 range scidx  0   scidx  Ns – 1  and SNR i is the average SNR of spatial stream i reported in the Aver-
49
50
age SNR of Space-Time Stream i field of the EHT Compressed Beamforming Report Information field.
51
52 The EHT MU Exclusive Beamforming Report information has the structure and order defined in Table 9-
53 91f (HE MU Exclusive Beamforming Report information).
54
55
56 In Table 9-91f (HE MU Exclusive Beamforming Report information), Ns and scidx() are defined in
57 9.4.1.71 (EHT Compressed Beamforming Report field).
58
59
60 9.4.1.73 EHT CQI Report field
61
62
The EHT CQI Report field carries the per-RU average SNRs of each spatial stream, where each per-RU
63
64 average SNR is the arithmetic mean of the SNR in decibels over a 26-tone RU for which the feedback is
65 being requested. The EHT CQI Report field contains information about the quality of the link.

166 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The size of the EHT CQI Report field depends on the values in the EHT MIMO Control field. The EHT CQI
2 Report field contains EHT CQI report information. EHT CQI Report information is included in the EHT
3
compressed beamforming/CQI report if the Feedback Type subfield in the EHT MIMO Control field indi-
4
5 cates CQI feedback.
6
7 (#4891)The EHT CQI Report field has the structure and order defined in Table 9-91g (HE CQI Report infor-
8 mation).
9
10
11 (#1641) Ncqi is the number of RU indices for which the CQI report is sent back to the beamformer. Ncqi
12 equals 9 multiplied by the number of 1s from B1 to B8 of the Partial BW Info subfield when B0 is 0 and
13 Ncqi equals 18 multiplied by the number of 1s from B1 to B8 of the Partial BW Info subfield when B0 is 1.
14 The 26-tone RU subcarrier indices for 20 MHz, 40 MHz, 80 MHz, 160 MHz, and 320 MHz are defined in
15
Table 27-7 (Data and pilot subcarrier indices for RUs in a 20 MHz HE PPDU and in a non-OFDMA
16
17 20 MHz HE PPDU), Table 27-8 (Data and pilot subcarrier indices for RUs in a 40 MHz HE PPDU and in a
18 non-OFDMA 40 MHz HE PPDU), Table 36-5 (Data and pilot subcarrier indices for RUs in an 80 MHz EHT
19 PPDU), Table 36-6 (Data and pilot subcarrier indices for RUs in a 160 MHz EHT PPDU), and Table 36-7
20 (Data and pilot subcarrier indices for RUs in a 320 MHz EHT PPDU), respectively. (#2941)26-tone RUs
21
that are not defined, i.e., RU 19, RU 56, RU 93, and RU 130 (see 36.3.2.1 (Subcarriers and resource alloca-
22
23 tion in EHT PPDUs(#4636))), are not included in the EHT CQI Report field.
24
25 (#4892)The Average SNR of (#6087)spatial time stream i for the RU index k subfield in Table 9-91g (HE
26 CQI Report information) is a 6-bit 2s complement integer whose definition is shown in Table 9-
27
91h (Average SNR of RU index k for space-time stream i subfield).
28
29
30 The AvgSNR k i in Table 9-91h (Average SNR of RU index k for space-time stream i subfield) is found by
31 computing the arithmetic mean of the SNR per subcarrier in decibels for spatial stream i over the subcarriers
32 in RU index k for which the feedback is being requested. The SNR per subcarrier calculation is defined in
33
9.4.1.71 (EHT Compressed Beamforming Report field).
34
35
36 Padding is not present between per-RU average SNRs of each spatial stream information, even if they corre-
37 spond to different RUs and spatial streams. If the size of the EHT CQI report information is not an integer
38 multiple of 8 bits, up to seven 0s are appended to the end of the field to make its size an integer multiple of 8
39
bits.
40
41
42 9.4.1.74 EML Control field
43
44 The EML Control field is defined in Figure 9-144i (EML Control field for-
45
mat(#4425)(#4759)(#5766)(#6342)).
46
47
48 B0 B1 B2 B17 B18 B23 B24 B39 B40 B41 B42 B65/89/113
49
50 EMLMR
51 EMLSR EMLMR EMLSR Link Reserved EMLMR Link MCS Map Supported MCS
52 Mode Mode Bitmap Bitmap Count
And NSS Set
53
54 Bits: 1 1 16 6 0 or 16 0 or 2 variable
55
56 Figure 9-144i—EML Control field format(#4425)(#4759)(#5766)(#6342)
57
58
59 A non-AP MLD that supports enhanced multi-link single radio operation (see 35.3.17 (Enhanced multi-link
60 single radio operation)) sets the EMLSR Mode subfield to 1 to indicate that the non-AP MLD operates in
61 EMLSR mode and to 0 to indicate that the non-AP MLD does not operate in EMLSR mode. (#7563)A non-
62
AP MLD that does not support enhanced multi-link single radio operation (see 35.3.17 (Enhanced multi-link
63
64 single radio operation)) sets the EMLSR Mode subfield to 0. (#7843)The EMLSR Mode subfield is set to 0
65 if the EMLMR Mode subfield is set to 1. (#7699)An AP MLD with dot11EHTEMLSROptionImplemented

Copyright © 2022 IEEE. All rights reserved. 167

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 equal to true that receives an EML Operating Mode Notification frame from a STA affiliated with a non-AP
2 MLD sets the EMLSR Mode subfield of the EML Operating Mode Notification frame that is sent in
3
response to the value obtained from the received EML Operating Mode Notification frame.
4
5
6 A non-AP MLD that supports enhanced multi-link multi-radio operation (see 35.3.18 (Enhanced multi-link
7 multi-radio operation)) sets the EMLMR Mode subfield to 1 to indicate that the non-AP MLD operates in
8
9 EMLMR mode and to 0 to indicate that the non-AP MLD does not operate in EMLMR mode. (#7564)A
10 non-AP MLD that does not support enhanced multi-link multi-radio operation (see 35.3.18 (Enhanced
11 multi-link multi-radio operation)) sets the EMLMR Mode subfield to 0. (#7843)The EMLMR Mode sub-
12 field is set to 0 if the EMLSR Mode subfield is set to 1. (#7699)An AP MLD with dot11EHTEMLMROp-
13 tionImplemented equal to true that receives an EML Operating Mode Notification frame from a STA
14
15 affiliated with a non-AP MLD sets the EMLMR Mode subfield of the EML Operating Mode Notification
16 frame that is sent in response to the value obtained from the received EML Operating Mode Notification
17 frame.
18
19 (#6664)NOTE 1—The EMLSR Mode and EMLMR Mode subfields are used to enable or disable the EMLSR and
20 EMLMR modes, respectively. An EML Operating Mode Notification frame sets either of these subfields to a nonzero
21 value only when the corresponding mode is supported by the receiving MLD. An MLD indicates which mode(s) it sup-
22 ports in the EML Capabilities field of the Basic Multi-Link element that it transmits (see 9.4.2.312.2 (Basic Multi-Link
23 element(#6700))).
24
25
26 (#4759)(#5766)(#6342)The EMLSR Link Bitmap subfield indicates the subset of the enabled links that is
27 used by the non-AP MLD in the EMLSR mode. The bit position i of the EMLSR Link Bitmap subfield cor-
28 responds to the link with the Link ID equal to i and is set to 1 to indicate that the link is used by the non-AP
29 MLD for the EMLSR mode and is a member of the EMLSR links; otherwise the bit position is set to 0.
30
31
(#4759)(#5766)(#6342)NOTE 2—As an example, when a non-AP MLD enables three links and the first link has Link
32
ID equal to 0, the second link has Link ID equal to 1, and the third link has Link ID equal to 2, and the two links with
33
Link ID equal to 1 and Link ID equal to 2 are used for the EMLSR operation, the two bit positions, the second bit and the
34
third bit positions, of the EMLSR Link Bitmap subfield are set to 1 and other bit positions are set to 0.
35
36
37 (#4425)The EMLMR Link Bitmap subfield indicates the subset of the enabled links that is used by the non-
38 AP MLD in the EMLMR mode. The bit position i of the EMLMR Link Bitmap subfield corresponds to the
39
40 link with the Link ID equal to i and is set to 1 to indicate that the link is used by the non-AP MLD for the
41 EMLMR mode and is a member of the EMLMR links; otherwise the bit position is set to 0. The EMLMR
42 Link Bitmap subfield is present if the EMLMR Mode subfield is equal to 1 and is not present otherwise.
43
44 (#4425)NOTE 3—As an example, when a non-AP MLD enables three links and the first link has Link ID equal to 0, the
45 second link has Link ID equal to 1, and the third link has Link ID equal to 2, and the two links with Link ID equal to 1
46 and Link ID equal to 2 are used for the EMLMR operation, the two bit positions, the second bit and the third bit posi-
47 tions, of the EMLMR Link Bitmap subfield are set to 1 and other bit positions are set to 0.
48
49
50 (#4425)The EMLMR Supported MCS And NSS Set subfield indicates the combinations of MCS and num-
51 ber of spatial streams NSS that a non-AP MLD supports for reception and transmission during the EMLMR
52 operation. The MCS Map Count subfield is set to 0, 1, or 2 if the maximum of the supported channel widths
53 for STAs affiliated with the non-AP MLD operating on EMLMR links is equal to 80 MHz, 160 MHz, and
54
55
320 MHz, respectively, and the value 3 is reserved. Otherwise, the MCS Map Count subfield is set to 0. The
56 MCS Map Count subfield is present if the EMLMR Mode subfield is equal to 1 and is not present otherwise.
57
58
(#4425)The EMLMR Supported MCS And NSS Set subfield is present if the EMLMR Mode subfield is
59
60 equal to 1; otherwise it is not present. The format of the EMLMR Supported MCS And NSS Set subfield is
61 shown in Figure 9-144j (EMLMR Supported MCS And NSS Set subfield format(#4425)).
62
63
64 (#4425)The subfields of the EMLMR Supported MCS And NSS Set subfield, and their presence, are defined
65 in Table 9-127e (Subfields of the EMLMR Supported MCS And NSS Set subfield(#4425)).

168 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2 MCS Map MCS Map MCS Map
(BW ≤ 80 MHz) (BW = 160 MHz) (BW = 320 MHz)
3
4
5 Octets: 3 0 or 3 0 or 3
6
7 Figure 9-144j—EMLMR Supported MCS And NSS Set subfield format(#4425)
8
9
10 Table 9-127e—Subfields of the EMLMR Supported MCS And NSS Set subfield(#4425)
11
12
13 Subfield Definition Encoding
14
15 MCS Map Except for a 20 MHz-only non-AP The format and encoding of this subfield are
16 (BW ≤ 80 MHz) STA, indicates the maximum number defined in Figure 9-144j (EMLMR Supported
17 of spatial streams supported for recep- MCS And NSS Set subfield format(#4425))
18 tion and the maximum number of spa- and the associated description.
19 tial streams that STAs of the non-AP
20 MLD can transmit during the
21 EMLMR operation, for each MCS
22 value, in a PPDU with a bandwidth of
23 20, 40 or 80 MHz.
24 MCS Map If the maximum operating channel The format and encoding of this subfield are
25 (BW = 160 MHz) width of the non-AP MLD for the defined in Figure 9-144j (EMLMR Supported
26 EMLMR operation is greater than or MCS And NSS Set subfield format(#4425))
27 equal to 160 MHz, indicates the maxi- and the associated description.
28 mum number of spatial streams sup-
29 ported for reception and the maximum If the MCS Map Count subfield is set to 1 or 2,
30 number of spatial streams that STAs this field is present; otherwise, it is not present.
31 of the non-AP MLD can transmit
32 during the EMLMR operation, for
33 each MCS value, in a PPDU with a
34 bandwidth of 160 MHz.
35
36 MCS Map If the maximum operating channel The format and encoding of this subfield are
37 (BW = 320 MHz) width of the non-AP MLD for the defined in Figure 9-144j (EMLMR Supported
38 EMLMR operation is equal to MCS And NSS Set subfield format(#4425))
39 320 MHz, indicates the maximum and the associated description.
40 number of spatial streams supported
41 for reception and the maximum num- If the MCS Map Count subfield is set to 2, this
42 ber of spatial streams that STAs of the field is present; otherwise, it is not present.
43 non-AP MLD can transmit during the
44 EMLMR operation, for each MCS
45 value, in a PPDU with a bandwidth of
46 320 MHz.
47
48
49
50 (#4425)The MCS Map (BW ≤ 80 MHz), the MCS Map (BW = 160 MHz), and the MCS Map (BW = 320
51 MHz) subfields follow the format shown in Figure 9-1002aj (EHT-MCS Map (BW ≤ 80 MHz, Except
52 20 MHz-Only Non-AP STA), EHT-MCS Map (BW = 160 MHz), and EHT-MCS Map (BW = 320 MHz)
53 subfield format(#5872)) defined in 9.4.2.313.4 (Supported EHT-MCS And NSS Set field(#1126)), respec-
54
tively.
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 169

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 9.4.2 Elements
2
3
4 9.4.2.1 General
5
6
7 Insert a new row to Table 9-128 (Element IDs(#1009)(#1121)):
8
9
10 Table 9-128—Element IDs(#1009)(#1121)
11
12
13 Element ID
Element Element ID Extensible Fragmentable
14 Extension
15
16 EHT Operation (see 9.4.2.311 (EHT 255 106 Yes No
17 Operation element))
18 Multi-Link (see 9.4.2.312 (Multi-Link 255 107 Yes Yes
19 element))
20
21 EHT Capabilities (see 9.4.2.313 (EHT 255 108 Yes No
22 Capabilities element(#4819)))
23
24 TID-To-Link Mapping (see 9.4.2.314 255 109 Yes Yes
25 (TID-To-Link Mapping element))
26 (#4107)Multi-Link Traffic Indication (see 255 110 Yes Yes
27 9.4.2.315 (Multi-Link Traffic Indication (#8274) (#8274)
28 element(#4107)(#2341)))
29
30 (#4918)QoS Characteristics (see 9.4.2.316 255 <ANA> Yes Yes
31 (QoS Characteristics element(#4918))
32
33
34
35 9.4.2.5 TIM element
36
37
38 9.4.2.5.1 General
39
40
41 Change the ninth paragraph as follows:
42
43
44 When the TIM is carried in a non-S1G PPDU, the traffic indication virtual bitmap, maintained by
45 (#6254)the AP, or the mesh STA or the AP MLD that generates a TIM, consists of 2008 bits, and it is
46 organized into 251 octets such that bit number N (0  N  2007) in the bitmap corresponds to bit number
47 (N mod 8) in octet number N / 8 where the low order bit of each octet is bit number 0, and the high order
48 bit is bit number 7. When the TIM is carried in an S1G PPDU, the traffic-indication virtual bitmap has the
49
50 hierarchical structure shown in Figure 9-152 (Hierarchical structure of traffic-indication virtual bitmap
51 carried in an S1G PPDU). Each bit in the traffic indication virtual bitmap corresponds to traffic buffered for
52 a specific neighbor peer mesh STA within the MBSS that the mesh STA is prepared to deliver1, or for a STA
53 that is not affiliated with an MLD within the BSS that the AP is prepared to deliver at the time the Beacon
54 frame is transmitted, or for a non-AP MLD that the AP MLD with which the AP is affiliated is prepared to
55
56 deliver at the time the Beacon frame is transmitted. Bit number N indicates the status of buffered,
57 individually addressed MSDUs/MMPDUs for the STA or the non-AP MLD whose AID is N, or group
58 addressed MSDUs/MMPDUs for the STAs whose group AID is N. It is set as follows:
59
60 — If the STA is not using APSD, and any individually addressed MSDUs/MMPDUs for that STA are
61 buffered and the AP or the mesh STA is prepared to deliver them, then bit number N in the traffic
62 indication virtual bitmap is 1.
63
64 1
65 How the AP or mesh STA determines the traffic it is prepared to deliver is outside the scope of this standard.

170 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — If the STA is using APSD, and any individually addressed MSDUs/MMPDUs for that STA are
2 buffered in at least one nondelivery-enabled AC (if there exists at least one nondelivery-enabled
3
AC), then bit number N in the traffic indication virtual bitmap is 1.
4
5 — If the STA is using APSD, all ACs are delivery-enabled, and any individually addressed MSDUs/
6 MMPDUs for that STA are buffered in any AC, then bit number N in the traffic indication virtual
7
8 bitmap is 1.
9 — Otherwise, bit number N in the traffic indication virtual bitmap is 0.
10
11
12 9.4.2.22 Quiet element
13
14
15 Change the first paragraph as follows:
16
17 (#5594)(#2215)The Quiet element defines an interval during which no transmission occurs in the current
18
19 channel from STAs in the BSS with the exceptions stated in 35.9.4.2 (Quieting STAs during r-TWT service
20 periods(#2215)). This interval might be used to assist in making channel measurements without interference
21 from other STAs in the BSS, or to protect channel access at the start of r-TWT SPs (see 35.9.4.2 (Quieting
22 STAs during r-TWT service periods(#2215))). The format of the Quiet element is shown in Figure 9-
23 284 (Quiet element format).
24
25
26 Change the third paragraph as follows:
27
28
29 (#2132)(#2166)TheFor a non-EHT AP, the Quiet Count field is set to the number of TBTTs until the beacon
30 interval during which the next quiet interval starts. The value of 0 is reserved. For an EHT AP:
31
32 — the Quiet Count field is equal to the number of TBTTs until the beacon interval during which the
33 next quiet interval starts if the field is set to a value lower than or equal to 127.
34
35 — the Quiet Count field minus 127 is equal to the number of TBTTs in the past to reach the beacon
36 interval during which the ongoing quiet interval started if the field is set to a value higher than 127.
37
38 (#2132)(#2166)NOTE—An EHT AP must not advertise the quiet count value greater than 127. A quiet count value
39 greater than 127 is possible when the Quiet element is carried in the per-STA profile of (#6700)Basic Multi-Link ele-
40 ment.
41
42 9.4.2.26 Extended Capabilities element
43
44
45 Change Table 9-190 (Extended Capabilities field) as follows:.
46
47
48
Table 9-190—Extended Capabilities field
49
50
51 Bit Information Notes
52
53 17 WNM Sleep The A non-AP STA or a STA affiliated with(#4105) a non-AP MLD sets the
54 Mode WNM Sleep Mode field to 1 when dot11WNMSleepModeActivated is true, and
55 sets it to 0 otherwise. See 11.2.3.16 (WNM sleep mode).
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 171

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 9.4.2.36 Neighbor Report element

2
3
4 Change Figure 9-398 (BSSID Information field format(#1010)(#1128)) as follows:
5
6 B0 B1 B2 B3 B4 B9 B10 B11 B12 B13 B14
7
8 AP Mobility High Very High High
9 Reachability Security Key Scope Capabilities Domain Throughput Throughput FTM Efficiency
10
11 Bits: 2 1 1 6 1 1 1 1 1
12
13 B15 B16 B17 B18 B19 B20 B21 B21B22 B31
14
15 Members Of OCT
Co- Unsolicited ESS With Supported Co-Located Extremely
16 Probe
ER BSS Located Responses 2.4/5 GHz With With 6 GHz High Reserved
17 AP Co-Located Reporting AP Throughput
18 Active AP AP
19
20 Bits: 1 1 1 1 1 1 1 109
21
22 Figure 9-398—BSSID Information field format(#1010)(#1128)
23
24
25 Insert the following paragraphs and NOTE after the paragraph “The Co-Located With 6 GHz
26
27
AP subfield is set to 1 ...”:
28
29 (#1010)(#1128)The Extremely High Throughput subfield is set to 1 to indicate that the AP represented by
30 this BSSID is an EHT AP and that the EHT Capabilities element (or EHT Operation element), if included as
31
a subelement in the report, is identical in content to the EHT Capabilities element (or EHT Operation ele-
32
33 ment) included in the neighboring AP’s Beacon frame. Otherwise, the Extremely High Throughput subfield
34 is set to 0.
35
36 (#5767)When the Extremely High Throughput subfield is set to 1, the Basic Multi-Link element, if included
37
38 as a subelement in the report, the included fields are identical in content to the corresponding fields that are
39 present in the Basic Multi-Link element included in the neighboring AP’s Beacon frame.
40
41 (#5767)NOTE 1—A Basic Multi-Link subelement included in a Neighbor Report element does not carry the Link Info
42 field as described in 35.3.2 (Advertisement of multi-link information in Multi-Link element(#2294)), except as
43 described in 35.3.25 (BSS transition management for MLDs(#5322))(#5322).
44
45 Insert the following new rows in Table 9-210 (Optional subelement IDs for Neighbor
46
47 Report(#1010)(#1128)):
48
49
50 Table 9-210—Optional subelement IDs for Neighbor Report(#1010)(#1128)
51
52
53 Subelement ID Name Extensible
54
55 <Last assigned + 1> EHT Capabilities Yes
56 <Last assigned + 2> EHT Operation Yes
57
58 <Last assigned + 3> (#6700)Basic Multi-Link Yes
59
60
61
62
63
64
65

172 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Insert the following paragraphs after the last paragraph (“The SSID subelement has the same
2 format ...”):
3
4
5 (#1010)(#1128)The EHT Capabilities subelement is the same as the EHT Capabilities element defined in
6 9.4.2.313 (EHT Capabilities element(#4819)).
7
8
9 (#1010)(#1128)The EHT Operation subelement is the same as the EHT Operation element defined in
10 9.4.2.311 (EHT Operation element).
11
12 (#1010)(#1128)(#6700)The Basic Multi-Link subelement is the same as the Basic Multi-Link element
13
14 defined in 9.4.2.312.2 (Basic Multi-Link element(#6700)). (#6226)The Basic Multi-Link subelement is
15 present in a Neighbor Report element corresponding to a reported AP if the reported AP is affiliated with an
16 AP MLD. Otherwise, the Basic Multi-Link subelement is not present.
17
18 (#1010)(#1128)NOTE 2—The AP follows the rules defined in 35.3.2 (Advertisement of multi-link information in Multi-
19 Link element(#2294)) when it includes a (#6700)Basic Multi-Link subelement in the Neighbor Report element.
20
21 9.4.2.45 Multiple BSSID element
22
23
24 Change the second last item of the seventh paragraph as follows:
25 — (#1011)The Timestamp and Beacon Interval fields, TIM, DSSS Parameter Set, IBSS Parameter Set,
26
27 Country, Channel Switch Announcement, Extended Channel Switch Announcement, Wide Band-
28 width Channel Switch, Transmit Power Envelope, Supported Operating Classes, IBSS DFS, ERP
29 Information, HT Capabilities, HT Operation, VHT Capabilities, and VHT Operation, S1G Beacon
30 Compatibility, Short Beacon Interval, S1G Capabilities, and S1G Operation, HE Capabilities, HE
31 6 GHz Band Capabilities, HE Operation, BSS Color Change Announcement, and Spatial Reuse
32
33 Parameter Set, EHT Capabilities, and EHT Operation elements are not included in the Nontransmit-
34 ted BSSID Profile subelement; the values of these elements for each nontransmitted BSSID are
35 always the same as the corresponding transmitted BSSID element values.
36
37
38
9.4.2.47 Fast BSS Transition element (FTE)
39
40 Change the fourth paragraph as follows:
41
42
43
The RSNXE Used subfield of the MIC Control field is used in the third and fourth messages of the FT
44 authentication sequence to indicate whether the STA or the STA affiliated with the MLD transmitting the
45 frame containing the FTE includes an RSNXE in other frames. This subfield is set to 0 in other frames.
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 173

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Change Table 9-218 (Subelement IDs) as follows:

2
3
4
Table 9-218—Subelement IDs
5
6
7 Value Contents of Data field
8
9 0 Reserved
10
11 1 PMK-R1 key holder identifier (R1KH-ID)
12
13 2 GTK
14
15 3 PMK-R0 key holder identifier (R0KH-ID)
16
17 4 IGTK
18 5 Operating Channel Information (OCI)
19
20 6 BIGTK
21
22 7 MLO GTK
23
24 8 MLO IGTK
25
26 9 MLO BIGTK
27 710–255 Reserved
28
29
30
31
32 Change the 19th paragraph as follows:
33
34
When sent by a non-AP STA or a non-AP MLD through an affiliated non-AP STA, the R0KH-ID indicates
35
36 the R0KH with which the S0KH negotiated the PMK-R0 it is using for this transition. When sent by an AP
37 or an AP MLD through an affiliated AP, the R0KH-ID indicates the R0KH that the S0KH will be using to
38 generate a PMK-R0 security association. It is encoded following the conventions from 9.2.2 (Conventions).
39
40
41 Insert the following paragraphs at the end of the subclause:
42
43
44 The MLO GTK subelement contains the GTK for a link, which is encrypted (see procedures in 13.8.5 (FT
45 authentication sequence: contents of fourth message)) and is defined in Figure 9-425a (MLO GTK subele-
46 ment format).
47
48
49 Subelement Length Key Info Link Info Key Length RSC Wrapped
50 ID Key
51
52 Octets: 1 1 2 1 1 8 24–40
53
54 Figure 9-425a—MLO GTK subelement format
55
56
57
58
59
60
61
62
63
64
65

174 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The Link Info field of the MLO GTK subelement is defined in Figure 9-425b (Link Info field format of the
2 MLO GTK subelement).
3
4
5 B0 B3 B4 B7
6
7 Link ID Reserved
8
9 Bits: 4 4
10
11 Figure 9-425b—Link Info field format of the MLO GTK subelement
12
13
14 The Link ID subfield contains the link identifier for the link.
15
16
17 The definitions of Key Info , Key Length, RSC, and Wrapped Key fields are the same as in the GTK subele-
18 ment.
19
20
21 The MLO IGTK subelement contains the IGTK for a link, used for protecting robust Management frames.
22 The MLO IGTK subelement format is shown in Figure 9-425c (MLO IGTK subelement format).
23
24
25 Subelement Wrapped
Length Key ID IPN Link Info Key Length
ID Key
26
27 Octets: 1 1 2 6 1 1 24–40
28
29 Figure 9-425c—MLO IGTK subelement format
30
31
32 The definitions of Key ID, IPN, Key Length, and Wrapped Key fields are the same as in the IGTK subele-
33 ment.
34
35
36 The definition of Link Info field is the same as the MLO GTK subelement described above.
37
38 The MLO BIGTK subelement contains the BIGTK for a link, used for protecting Beacon frames. The MLO
39
40 BIGTK subelement format is shown in Figure 9-425d (MLO BIGTK subelement format).
41
42 Subelement Wrapped
43 Length Key ID BIPN Link Info Key Length
ID Key
44
45 Octets: 1 1 2 6 1 1 24–40
46
47 Figure 9-425d—MLO BIGTK subelement format
48
49
50 The definitions of Key ID, BIPN, Key Length, and Wrapped Key fields are the same as in the BIGTK sub-
51 element.
52
53
54 The definition of Link Info field is the same as the MLO GTK subelement described above.
55
56 9.4.2.61 Link Identifier element
57
58
59 Change the third and fourth paragraphs as follows:
60
61 The BSSID field is set to the BSSID of the BSS of which the TDLS initiator STA is a member (#4032)when
62
the frame carrying the element is transmitted by a STA that is not affiliated with a non-AP MLD, Otherwise
63
64 the BSSID field is set to the BSSID of the AP that is operating on the link where the non-AP MLD intends to
65 establish a single link TDLS direct link.

Copyright © 2022 IEEE. All rights reserved. 175

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The TDLS initiator STA Address field is set to the TDLS initiator STA’s MAC address (#4032)if the STA is
2 not affiliated with a non-AP MLD. Otherwise, the TDLS initiator STA Address field is set to the MAC
3
address of the initiating non-AP MLD.
4
5
6 9.4.2.71 Nontransmitted BSSID Capability element
7
8 Insert the following NOTEs after the fifth paragraph (“The Nontransmitted BSSID Capability
9
10 field contains the contents of...”):
11 (#1013)NOTE 1—The Critical Update Flag subfield of the Nontransmitted BSSID Capability field is set to 1 in the Bea-
12 con frame(s) until and including the next DTIM Beacon frame of the nontransmitted BSSID if there is a change to a
13 value carried in the BSS Parameters Change Count subfield of the MLD Parameters field in the Reduced Neighbor
14 Report element for any AP in the same AP MLD as the AP corresponding to the nontransmitted or a value carried in the
15 BSS Parameters Change Count subfield in the Common Info field of the (#6700)Basic Multi-Link element in the Non-
16 transmitted BSSID profile corresponding to the nontransmitted BSSID. Otherwise the subfield is set to 0 (See 35.3.10
17 (BSS parameter critical update procedure)).
18
19 (#4064)(#5258)NOTE 2—The Nontransmitted BSSIDs Critical Update Flag subfield of the Nontransmitted BSSID
20 Capability field is reserved.
21
22 9.4.2.78 BSS Max Idle Period element
23
24
25 Change as follows:
26
27 (#3203)When association is not for an MLD association (see 11.3 (STA authenticationAuthentication and
28
association(#2277)))(#8222), theThe BSS Max Idle Period element contains the time period a non-AP STA
29
30 can refrain from transmitting frames to the AP before the AP might disassociates the STA due to inactivity.
31
32 (#3203)When association is for an MLD association (see 11.3 (STA authenticationAuthentication and asso-
33 ciation(#2277)))(#8222), the BSS Max Idle Period element contains the time period a non-AP MLD can
34
35
refrain from transmitting frames to the AP MLD before the AP MLD might disassociate the non-AP MLD
36 due to inactivity.
37
38 (#3203)The format of the BSS Max Idle Period element is shown in Figure 9-522 (BSS Max Idle Period
39 element format).
40
41
42 Element ID Length Max Idle Period Idle Options
43
44 Octets: 1 1 2 1
45
46 Figure 9-522—BSS Max Idle Period element format
47
48
49 The Element ID and Length fields are defined in 9.4.2.1 (General).
50
51
52 (#3203)The BSSMaxIdlePeriod parameter indicates the idle timeout limit, as described in 11.21.13 (BSS
53 max idle period management) and 35.3.12.3 (MLD max idle period management). The time period is
54 specified in units of 1000 TUs. The value of 0 is reserved. In a non-S1G STA, the Max Idle Period field is an
55 unsigned integer that contains the value of the parameter BSSMaxIdlePeriod. In an S1G STA, the two MSBs
56 of the Max Idle Period field contain the Unified Scaling Factor subfield and the remaining 14 bits contain
57
58 the Unscaled Interval subfield (see Figure 9-89 (Listen Interval field format carried in an S1G PPDU)). In an
59 S1G STA, the BSSMaxIdlePeriod parameter used by the MLME primitives is in units of 1000 TUs and is
60 equal to the value of the Unscaled Interval subfield, multiplied by the scaling factor that corresponds to the
61 value indicated in the Unified Scaling Factor subfield. The Unified Scaling Factor subfield encoding is
62 defined in Table 9-48 (Unified Scaling Factor subfield encoding).
63
64
65

176 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The Idle Options field indicates the options associated with the BSS Idle capability. The Idle Options field is
2 shown in Figure 9-523 (Idle Options field format).
3
4
5 B0 B1 B7
6
7 Protected
8 Keep-Alive Reserved
9 Required
10
11 Bits: 1 7
12
13 Figure 9-523—Idle Options field format
14
15
16 The Protected Keep-Alive Required subfield is set to 1 to indicate that only a protected frame indicates
17 activity. The Protected Keep-Alive Required subfield is set to 0 to indicate that either an unprotected or a
18 protected frame indicates activity.
19
20
21 (#3203)The BSS Max Idle Period element is included in Association Request and Response frames, as
22 described in 9.3.3.5 (Association Request frame format) and 9.3.3.6 (Association Response frame format),
23 and Reassociation Request and Response frames, as described in 9.3.3.7 (Reassociation Request frame
24 format) and 9.3.3.8 (Reassociation Response frame format). The use of the BSS Max Idle Period element
25
26 and frames is described in 11.21.13 (BSS max idle period management) and 35.3.12.3 (MLD max idle
27 period management).
28
29 9.4.2.121 SCS Descriptor element
30
31
32 Change Figure 9-603 (SCS Descriptor element format(#4918)(#1977)) as follows:
33
34
35 zero or zero or
36 one QoS
more characteri
37 TCLAS
stics
38 Elements
Elements
39
40 Intra-
41 Access TCLAS QoS
TCLAS Character
42 Element Length SCSID Request Category Elements Processing istics Optional
43 ID Type Priority Element Subelements
Element (optional) (optional) Elements
44 (optional)
(optional)
45
46 Octets: 1 1 1 1 0 or 3 variable 0 or 3 variable variable
47
48 Figure 9-603—SCS Descriptor element format(#4918)(#1977)
49
50
51 Insert the following paragraph after the 7th paragraph (“The TCLAS Processing Element field
52 is present when more than...”):
53
54
55 (#4918)(#1977)The QoS Characteristics Element field contains zero or one QoS Characteristics element to
56 describe the traffic characteristics and QoS expectations of traffic flows that belong to this SCS stream, as
57 defined in 9.4.2.316 (QoS Characteristics element(#4918)). Zero or one QoS Characteristics element is
58
59 present when the Request Type field is equal to “Add” or “Change” and no QoS Characteristics element is
60 present when the Request Type field is equal to “Remove”.
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 177

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 9.4.2.139 ADDBA Extension element

2
3
4 Change Figure 9-646 (ADDBA Extension element format) as follows:.
5
6
ADDBA Additional
7 Element ID Length Parameter Set
8 Capabilities
9
10 Octets: 1 1 1
11
12 Figure 9-646—ADDBA Extension element format
13
14
15 Change as follows:
16
17
18 The ADDBA Additional Parameter Set Capabilities field is shown in Figure 9-647 (ADDBA Additional
19 Parameter Set Capabilities field format).
20
21
22 Change Figure 9-647 (ADDBA Additional Parameter Set Capabilities field format) as follows:.
23
24
B0 B1 B2 B3 B74 B5 B7
25
26
27 No-Fragmentation HE Fragmentation Reserved Extended Buffer Size
Operation
28
29
Bits: 1 2 52 3
30
31
32 Figure 9-647—ADDBA Additional Parameter Set Capabilities field format
33
34
35 Insert the following paragraph at the end of the subclause:
36
37 The Extended Buffer Size field together with the Buffer Size subfield in the Block Ack Parameter Set field
38 indicates the number of buffers available for this particular TID where the buffer size is Extended Buffer
39
40 Size × 1024 + Buffer Size.
41
42 9.4.2.157 VHT Capabilities element
43
44
45 9.4.2.157.3 Supported VHT-MCS and NSS Set field
46
47
48
Change the second last paragraph as follows:
49
50 The value of Max VHT NSS for a given MCS is equal to the smaller of
51
52 — The maximum value of n for which the Max VHT-MCS for n SS has a value that indicates support
53 for that MCS or
54
55 — The maximum supported NSS as indicated in by the value of the Rx NSS field of the OM Control
56 subfield or (#5536)by the value of the Rx NSS Extension field of the EHT OM Control subfield
57 combined with the value of the Rx NSS field of the OM Control subfield (and further defined in the
58 Table 26-9 (Setting of VHT Channel Width and VHT NSS at an HE STA transmitting the OM Con-
59
60 trol subfield))
61
62
63
64
65

178 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 9.4.2.163 AID element

2
3
4
Change the first paragraph as follows:
5
6 The AID element includes the AID assigned by an AP (#4026)or an AP MLD during association (see 11.3
7 (STA authenticationAuthentication and association(#2277))) that represents the 16-bit ID of a STA or a non-
8 AP MLD, respectively. The format of the AID element is shown in Figure 9-619 (AID element format).
9
10
11 9.4.2.164 Quiet Channel element
12
13 Insert the following note at the end of the subclause:
14
15
(#2132)(#2166)NOTE—An EHT AP must not advertise the quiet count value greater than 127. A quiet count value
16
17 greater than 127 is possible when the Quiet element is carried in the per-STA profile of (#6700)Basic Multi-Link ele-
18 ment.
19
20 9.4.2.170 Reduced Neighbor Report element
21
22
9.4.2.170.2 Neighbor AP Information field
23
24
25 Change the seventh paragraph and Table 9-321 (TBTT Information field con-
26 tents(#1205)(#1728)(#2567)) as follows:
27
28
29 The TBTT Information Length subfield is 1 octet in length and indicates the length of each TBTT
30 Information field included in the TBTT Information Set field of the Neighbor AP Information field. If the
31
32 TBTT Information Field Type subfield is 0, the TBTT Information Length subfield:
33
34 — contains the length in octets of each TBTT Information field that is included in the TBTT Informa-
35 tion Set field of the Neighbor AP Information field
36
37 — (#6010)(#6231)(#6232)(#1015)(#1124)(#2567)is set to 1, 2, 5, 6, 7, 8, 9, 11, or 12, 13, or 16; other
38 values are reserved.
39
— indicates the TBTT Information field contents as shown in Table 9-321 (TBTT Information field
40
41 contents(#1205)(#1728)(#2567)).
42
43
44 Table 9-321—TBTT Information field contents(#1205)(#1728)(#2567)
45
46
47 TBTT Information
TBTT Information field contents
48 Length subfield value
49
50 1 The Neighbor AP TBTT Offset subfield
51 2 The Neighbor AP TBTT Offset subfield and the BSS Parameters
52 subfield
53
54 5 The Neighbor AP TBTT Offset subfield and the Short SSID
55 subfield
56
57 6 The Neighbor AP TBTT Offset subfield, the Short-SSID sub-
58 field, and the BSS Parameters subfield
59 7 The Neighbor AP TBTT Offset subfield and the BSSID subfield
60
61 8 The Neighbor AP TBTT Offset subfield, the BSSID subfield,
62 and the BSS Parameters subfield
63
64 9 The Neighbor AP TBTT Offset subfield, the BSSID subfield, the
65 BSS Parameters subfield, and the 20 MHz PSD subfield

Copyright © 2022 IEEE. All rights reserved. 179

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 9-321—TBTT Information field contents(#1205)(#1728)(#2567) (continued)

2
3
4 TBTT Information
TBTT Information field contents
5 Length subfield value
6
7 11 The Neighbor AP TBTT Offset subfield, the BSSID subfield and
8 the Short SSID subfield
9 12 The Neighbor AP TBTT Offset subfield, the BSSID subfield, the
10 Short-SSID subfield and the BSS Parameters subfield
11
12 0, 3, 4, 10, 14, 15 Reserved
13 (#6010)(#6231)(#6232)
14
15 13 The Neighbor AP TBTT Offset subfield, the BSSID subfield, the
16 Short-SSID subfield, the BSS Parameters subfield and the
17 20 MHz PSD subfield
18 16 The Neighbor AP TBTT Offset subfield, the BSSID subfield, the
19 Short-SSID subfield, the BSS Parameters subfield, the 20 MHz
20 PSD subfield and the MLD Parameters subfield
21
22 174–255 The first 163 octets of the field contain the Neighbor AP TBTT
23 Offset subfield, the BSSID subfield, the Short-SSID subfield the
24 BSS Parameters subfield, and the 20 MHz PSD subfield and the
25 MLD Parameters subfield (i.e., same contents as when the length
26 of the TBTT Information field is 163). The remaining octets are
27 reserved
28
29
30
31 Change Figure 9-709 (TBTT Information field for-
32 mat(#1901)(#1902)(#2566)(#2969)(#1016)(#1017)(#1205)(#1125)) as follows:
33
34
Neighbor AP BSSID Short SSID BSS parame- 20 MHz PSD MLD Parame-
35 TBTT Offset (optional) (optional) ters ters
36
37 Octets: 1 0 or 6 0 or 4 0 or 1 0 or 1 0 or 3
38
39 Figure 9-709—TBTT Information field for-
40 mat(#1901)(#1902)(#2566)(#2969)(#1016)(#1017)(#1205)(#1125)
41
42
43
44
Change the 15th paragraph as follows:
45
46
47
The value 254 indicates an offset of 254 TUs or higher (#6970)if the AP is not affiliated with an AP MLD
48 and indicates an offset of 254 TUs if the AP is affiliated with an AP MLD. The value 255 indicates an
49 unknown offset value.
50
51
52 Insert the following at the end of this subclause:
53
54
55 (#4079)If the TBTT Information Field Type subfield is 1, the TBTT Information Length subfield is set to 3,
56
57 other values are reserved.
58
59
MLD Parameters
60
61
62 Octets: 3
63
64 Figure 9-709b—TBTT Information field format when the TBTT Information Field type is
65 equal to 1 and the TBTT information length is equal to 3(#4079)

180 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The format of the MLD Parameters subfield is defined in Figure 9-709c (MLD Parameters subfield for-
2 mat(#1068)((#1901)(#1902)(#1016)(#1017)(#1903)(#4064)(#5258)).
3
4
5 B0 B7 B8 B11 B12 B19 B20 B21 B23
6
7 BSS Parameters All Updates
8 MLD ID Link ID Reserved
Change Count Included
9
10 Bits: 8 4 8 1 3
11
12 Figure 9-709c—MLD Parameters subfield for-
13 mat(#1068)((#1901)(#1902)(#1016)(#1017)(#1903)(#4064)(#5258)
14
15
16
The MLD ID subfield indicates the identifier of the AP MLD (#6233)with which the reported AP is affili-
17
18 ated. If the reported AP is affiliated (#6233)with the same MLD as the reporting AP (#8275)sending the
19 frame carrying this element, the MLD ID subfield is set to 0. If the reported AP is affiliated (#6233)with the
20 same MLD as a nontransmitted BSSID that is in the same multiple BSSID set as the reporting AP
21 (#8275)sending the frame carrying this element, the MLD ID subfield is set to the same value as in the
22
BSSID Index field in the Multiple BSSID-Index element in the nontransmitted BSSID profile corresponding
23
24 to the nontransmitted BSSID. If the reported AP is (#6233)affiliated with another AP MLD, the MLD ID
25 subfield is set to a value (#8163)(#8276)that is unique for this AP MLD in frames sent by the reporting
26 AP and that is higher than 0 and lower than 255 if no Multiple BSSID element is carried in the same
27 n
frame or a value higher than 2 – 1 and lower than 255 if a Multiple BSSID element is carried in the same
28
frame, where n is the value contained in the MaxBSSID Indicator field in the Multiple BSSID ele-
29
30 ment(#2972)(#3361)(#1041)(#1923)(#1973). The MLD ID subfield is set to 255 if the reported AP is not
31 part of an AP MLD, or if the reporting AP does not have information of that MLD(#2156).
32
33 (#3014)(#6233)NOTE 1—The MLD ID is used to identify the list of reported APs affiliated with the same AP MLD,
34 especially when APs from multiple AP MLDs are reported, and (#4099)is assigned such that it is unique to an AP MLD
35 only in the frames which carries the Reduced Neighbor Report element describing reported APs affiliated with the AP
36 MLD. Following the rules to set the MLD ID field, another AP may use a different MLD ID for the same AP MLD.
37
38 (#5122)NOTE 2—An MLD ID subfield set to 255 does not mean that the reported AP has BSSID index set to 255.
39
40
41 (#1019)(#1775)(#2157)(#2568)(#2974)(#3015)(#3259)(#3362)(#2976)The Link ID subfield indicates the
42 link identifier of the reported AP within the AP MLD (#6233)with which the reported AP is affiliated. The
43 Link ID subfield is set to 15 if the reported AP is not part of an AP MLD, or if the reporting AP does not
44 have that information.
45
46
NOTE 3—The link identifier is unique to an AP within an AP MLD.
47
48
49 (#1068)The BSS Parameters Change Count subfield is an unsigned integer, initialized to 0, that increments
50 when a critical update to the (#4079)BSS Parameters of the reported AP occurs. The critical updates are
51
52 defined in 11.2.3.15 (TIM Broadcast). The BSS Parameters Change Count subfield is set to 255(#2156) if
53 the reported AP is not part of an AP MLD, or if the reporting AP does not have that information.
54
55
56 (#4064)(#5258)The All Updates Included subfield indicates if the updated elements that correspond to the
57 latest critical update that generated a change to the value carried in the BSS Parameters Change Count sub-
58 field for the AP are included in the frame carrying the Reduced Neighbor Report element. It is set to 1 if all
59 the updated elements are included and set to 0 otherwise.
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 181

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 9.4.2.177 FILS Request Parameters element

2
3
4 Insert the following row in Table 9-328 (PHY Support Criterion subfield(#1014)(#1130))and
5 change the value of the reserved row:
6
7
8
9 Table 9-328—PHY Support Criterion subfield(#1014)(#1130)
10
11
Value Explanation
12
13 4 Indicates that a responding FILS STA is EHT capable.
14
15 54–7 Reserved
16
17
18
19 9.4.2.199 TWT element
20
21
22 Change Figure 9-764 (Control field format) as follows:
23
24 B0 B1 B2 B3 B4 B5 B6 B6 B7
25
26 TWT
27 Link ID
NDP Paging Responder Negotiation Information Wake Bitmap Reserved
28 Indicator PM Mode Type Frame Duration Unit
Present
29 Disabled
30
31 Bits: 1 1 2 1 1 1 21
32
33 Figure 9-764—Control field format
34
35
36
Change Figure 9-765 (Individual TWT Parameter Set field format) as follows:
37
38
39
40
41 Nominal TWT Wake
Request Target Wake TWT Group Minimum TWT NDP Paging Link ID
42 Interval
Type Time Assignment TWT Wake Mantissa Channel (optional) Bitmap
43 Duration
44
45 Octets: 2 0 or 8 0, 3 or 9 1 2 1 0 or 4 0 or 2
46
47 Figure 9-765—Individual TWT Parameter Set field format
48
49
50 Change Figure 9-766 (Broadcast TWT Parameter Set field format(#2920)) as follows:
51
52
53
54
55 Nominal Restricted
56 Request Target Wake Minimum TWT Wake Broadcast TWT Traffic
Interval
57 Type Time TWT Wake Mantissa TWT Info Info
58 Duration (optional)
59
60 Octets: 2 2 1 2 2 0 or 3
61
62 Figure 9-766—Broadcast TWT Parameter Set field format(#2920)
63
64
65

182 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Insert the following paragraph after the eighth paragraph (“The Wake Duration Unit subfield
2 indicates the unit ...”)
3
4
5 The Link ID Bitmap field is present if the Link ID Bitmap Present field is equal to 1; otherwise, the Link ID
6 Bitmap field is not present.
7
8
9 Change Table 9-339 (Broadcast TWT Recommendation field for a broadcast TWT element) as
10
11 follows (not all rows shown) and insert two new paragraphs right after the table:
12
13
14 Table 9-339—Broadcast TWT Recommendation field for a broadcast TWT element
15
16
17 Broadcast TWT
18 Recommendation Description when transmitted in a broadcast TWT element
19 field value
20
21 … …
22
23 (#2920)4 The corresponding broadcast TWT SP is referred to as a r-TWT SP.
24
25 (#4775)During a restricted TWT SP, the AP and member r-TWT scheduled STAs prioritize
26 their transmission of QoS Data frames that are latency sensitive traffic (see 35.9 (Restricted
27 TWT (r-TWT))).
28
29 (#2920)4-75–7 Reserved
30
31
32
33
34 (#4775)A broadcast TWT parameter set that has the Broadcast TWT Recommendation field value equal to 4
35 is referred to as a restricted TWT parameter set.
36
37
(#2920)A broadcast TWT element that contains only Restricted TWT Parameter Set field(s) is also referred
38
39 to as a restricted TWT element.
40
41
42 Change Figure 9-770 (Broadcast TWT Info subfield format(#6414)(#2920)) as follows and
43 insert the following paragraph right after the figure:
44
45
46 B0 B1 B0 B2 B3 B7 B8 B15
47
48 Restricted TWT Restricted TWT Broadcast TWT
49 Reserved Broadcast TWT ID
Traffic Info Present Schedule Full Persistence
50
51 Bits: 1 1 31 5 8
52
53 Figure 9-770—Broadcast TWT Info subfield format(#6414)(#2920)
54
55
56 (#2920)A Restricted TWT Traffic Info Present subfield, when included in the Restricted TWT Parameter
57 Set field, is set to 1 to indicate that the Restricted TWT Traffic Info field is present; and set to 0 otherwise. It
58
59
is reserved for non-EHT STAs.
60
61 (#6414)Restricted TWT Schedule Full subfield is set to 1 to indicate that the r-TWT scheduling AP is
62
unlikely to accept a request from a STA in the BSS to establish a new membership in the corresponding
63
64 schedule; it is set to 0 otherwise. This subfield is valid when the corresponding Restricted TWT Parameter
65 Set field is carried in a TWT element with Negotiation Type subfield set to 2, and the TWT element is trans-

Copyright © 2022 IEEE. All rights reserved. 183

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 mitted by an EHT AP with dot11RestrictedTWTOptionImplemented set to true; otherwise, the subfield is

2 reserved.
3
4
5 Change the following paragraph as follows:
6
7 Within a TWT element that includes a TWT setup command value of Request TWT, Suggest TWT or
8
9
Demand TWT, the Broadcast TWT ID, if present, indicates a specific Broadcast TWT in which the transmit-
10 ting STA is requesting to participate. Within a TWT element that includes a TWT setup command value of
11 Accept TWT, Alternate TWT, Dictate TWT or Reject TWT, the Broadcast TWT ID, if present, indicates a
12 specific Broadcast TWT for which the transmitting STA is providing TWT parameters. Within a TWT ele-
13 ment that includes a TWT setup command value of TWT Grouping, the Broadcast subfield is 0 and the
14
15
Broadcast TWT ID, is not present. The value 0 in the Broadcast TWT ID subfield indicates the broadcast
16 TWT whose membership corresponds to all STAs that are members of the BSS corresponding to the BSSID
17 of the Management frame carrying the TWT element and that is permitted to contain Trigger frames with
18 RA-RUs for unassociated STAs. (#2920)The Broadcast TWT ID subfield in a Restricted TWT Parameter
19 Set field is always set to a nonzero value.
20
21
22 Insert the following paragraphs and figures after the paragraph (“The Broadcast TWT Persis-
23 tence subfield indicates the number of TBTTs during ...”):
24
25
26 The Link ID Bitmap subfield indicates the links to which the TWT element sent by a STA affiliated with an
27 MLD applies. A value of 1 in bit position i of the Link Bitmap subfield means that the link to which the
28 TWT element sent by a STA affiliated with an MLD applies. A value of 0 in bit position i of the Link Bit-
29 map subfield means that the link associated with the link ID i is not the link to which the TWT element sent
30
by a STA affiliated with an MLD applies.
31
32
33 (#2920)The Restricted TWT Traffic Info field is present in a Restricted TWT Parameter Set field when the
34 Restricted TWT Traffic Info Present subfield of the (#4782)Broadcast TWT Info subfield is set to 1. Its for-
35 mat is defined in Figure 9-770a (Restricted TWT Traffic Info field format(#2920)).
36
37
38 Restricted TWT DL Restricted TWT UL
Traffic Info Control
39 TID Bitmap TID Bitmap
40
41 Octets: 1 1 1
42
43 Figure 9-770a—Restricted TWT Traffic Info field format(#2920)
44
45
46 (#2920)The Traffic Info Control field is defined in Figure 9-770b (Traffic Info Control field format(#2920)).
47
48
B0 B1 B2 B7
49
50
DL TID Bitmap UL TID Bitmap
51 Reserved
Valid Valid
52
53 Bits: 1 1 6
54
55 Figure 9-770b—Traffic Info Control field format(#2920)
56
57
58 (#2920)The DL TID Bitmap Valid subfield indicates if the Restricted TWT DL TID Bitmap field has valid
59 information. When the value is set to 0, it indicates that DL traffic of all TIDs is identified as latency sensi-
60 tive traffic, and the Restricted TWT DL TID Bitmap field is reserved.
61
62
(#2920)The UL TID Bitmap Valid subfield indicates if the Restricted TWT UL TID Bitmap field has valid
63
64 information. When the value is set to 0, it indicates that UL traffic of all TIDs is identified as latency sensi-
65 tive traffic, and the Restricted TWT UL TID Bitmap field is reserved.

184 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#2920)The Restricted TWT DL TID Bitmap and Restricted TWT UL TID Bitmap subfields specify which
2 TID(s) are identified by the TWT scheduling AP or the TWT scheduled STA as latency sensitive traffic
3
streams in the downlink and uplink direction, respectively. A value of 1 at bit position k in the bitmap indi-
4
5 cates that TID k is classified as latency sensitive traffic stream. A value of 0 at bit position k in the bitmap
6 indicates that TID k is not classified as latency sensitive traffic stream.
7
8 9.4.2.240 Non-Inheritance element
9
10
11 Insert the following paragraph as the first paragraph of the subclause:
12
13
The Non-Inheritance element can be present as the last element in the Nontransmitted BSSID Profile subele-
14
15 ment of a Multiple BSSID element or as the last element in the Per-STA Profile subelement of a
16 (#6700)Basic Multi-Link element when the profile is complete.
17
18 Insert the following paragraph after the now-shifted second paragraph (“The Non-Inheritance
19
20
element when present ...”):
21
22 (#6565)When present in the Per-STA Profile subelement of a (#6700)Basic Multi-Link element, the Non-
23 inheritance element identifies one or more elements that are not inherited by the STA corresponding to the
24 per-STA profile. The identified elements are present in the Management frame (#2368)transmitted by the
25
26 STA that carried the (#6700)Basic Multi-Link element.
27
28 9.4.2.248 HE Capabilities element
29
30
31
9.4.2.248.4 Supported HE-MCS and NSS Set field
32
33 Change the fourth last paragraph as follows:
34
35
The maximum receive NSS for a given HE-MCS is equal to the smaller of
36
37 — The maximum value of n for which the Max HE-MCS For n SS has a value that indicates support for
38 that HE-MCS or
39
40 — The maximum supported NSS as indicated by the value of the Rx NSS field of the Operating Mode
41 Notification frame (#5785)or the Operating Mode Notification element if the value of Rx NSS Type
42 is 0, or by the value of the Rx NSS field of the OM Control subfield if EHT OM Control subfield is
43 not present in the same A-Control field, (#5536)or by the value of the Rx NSS Extension field of the
44
45 EHT OM Control subfield combined with the value of the Rx NSS field of the OM Control subfield.
46
47 Change the second last paragraph as follows:
48
49
50
The maximum transmit NSS for a given HE-MCS is equal to the smaller of
51 — The maximum value of n for which the Max HE-MCS For n SS has a value that indicates support for
52 that HE-MCS (0, 1, or 2 for HE-MCS 0–7, 1 or 2 for HE-MCS 8–9, 2 for HE-MCS 10–11) or
53
54 — The maximum supported NSTS as indicated by the value of the Tx NSTS field of the OM Control
55 subfield sent by a non-AP STA (#5536)or by the value of the Tx NSTS Extension field of the EHT
56 OM Control subfield combined with the value of the Tx NSTS field of the OM Control subfield sent
57
by a non-AP STA.
58
59
60 Insert the following new subclauses at the end of subclause 9.4.2:
61
62 9.4.2.311 EHT Operation element
63
64
65 The operation of EHT STAs in an EHT BSS is controlled by the following:

Copyright © 2022 IEEE. All rights reserved. 185

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — The HT Operation element, HE Operation element, and EHT Operation element if operating in the
2 2.4 GHz band
3
4 — The HT Operation element, VHT Operation element (if present), HE Operation element, and EHT
5 Operation element if operating in the 5 GHz band
6
7 — The HE Operation element and EHT Operation element if operating in the 6 GHz band
8
9 The format of the EHT Operation element is shown in Figure 9-1002a (EHT Operation element for-
10
mat(#4261)(#6603)(#1086)(#1667)(#2148)(#2147)).
11
12
13 Element ID EHT Operation EHT Operation
14 Element ID Length
Extension Parameters Information
15
16 Octets: 1 1 1 1 0 or 3 or 5
17
18 Figure 9-1002a—EHT Operation element format(#4261)(#6603)(#1086)(#1667)(#2148)(#2147)
19
20
21 The Element ID, Length, and Element ID Extension fields are defined in 9.4.2.1 (General).
22
23
24 The EHT Operation Parameters field is defined in Figure 9-1002b (EHT Operation Parameters field for-
25 mat(#6603)).
26
27
B0 B1 B2 B7
28
29
EHT Operation Disabled
30 Information Subchannel Reserved
31 Present Bitmap Present
32
33 Bits: 1 1 6
34
35 Figure 9-1002b—EHT Operation Parameters field format(#6603)
36
37
38 (#6603)The EHT Operation Information Present subfield is set to 1 if the EHT Operation Information field
39 is present and set to 0 otherwise. The EHT Operation Information Present subfield is set to 1 if the channel
40 width indicated in an HT Operation, VHT Operation, or HE Operation element that is present in the same
41 Management frame is different from the Channel Width field indicated in the EHT Operation Information
42 field.
43
44
45 (#6603)The Disabled Subchannel Bitmap Present subfield is set to 1 if the Disabled Subchannel Bitmap
46 field is present and set to 0 otherwise. The Disabled Subchannel Bitmap Present subfield is valid only when
47 the HT Operation Information Present subfield is set to 1.
48
49
50 (#6603)The EHT Operation Information field is present if the EHT Operation Information Present subfield
51 is equal to 1; otherwise it is not present. The EHT STA obtains the channel configuration information from
52 the EHT Operation Information field, if present, in the EHT Operation element. The subfields of EHT Oper-
53 ation Information field are defined Figure 9-1002c (EHT Operation Information field format(#6603)).
54
55
56 Disabled
57 Control CCFS0 CCFS1 Subchannel
58 Bitmap
59
60 Octets: 1 1 1 0 or 2
61
62 Figure 9-1002c—EHT Operation Information field format(#6603)
63
64
65

186 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The Control subfield is defined in Figure 9-1002d (Control subfield format(#6603)),

2
3
4 B0 B2 B3 B7
5
6 Channel Width Reserved
7
8 Bits: 3 5
9
10 Figure 9-1002d—Control subfield format(#6603)
11
12 The Channel Width subfield, CCFS0 subfiled and CCFS1 subfield are defined in Table 9-401a (Channel
13 width, CCFS0, and CCFS1 subfields(#6603)(#1086)(#1667)(#2148)(#2147)).
14
15
16
17 Table 9-401a—Channel width, CCFS0, and CCFS1
18 subfields(#6603)(#1086)(#1667)(#2148)(#2147)
19
20
21 Subfield Definition Encoding
22
23 Channel Width This subfield defines the EHT BSS Set to 0 for 20 MHz EHT BSS band-
24 bandwidth. width.
25 Set to 1 for 40 MHz EHT BSS band-
26 width.
27 Set to 2 for 80 MHz EHT BSS band-
28 width.
29 Set to 3 for 160 MHz EHT BSS band-
30 width.
31 Set to 4 for 320 MHz EHT BSS band-
32 width.
33 Values in the ranges 5 to 7 are
34 reserved.
35 CCFS0 This subfield defines a channel center For 20, 40 or 80 MHz BSS band-
36 frequency for a 20, 40, 80, 160, or width, indicates the channel center
37 320 MHz EHT BBS. frequency index for the 20, 40 or
38 80 MHz channel on which the EHT
39 BSS operates.
40
41 For 160 MHz BSS bandwidth, indi-
42 cates the channel center frequency
43 index of the primary 80 MHz channel.
44
45 For 320 MHz BSS bandwidth, indi-
46 cates the channel center frequency
47 index of the primary 160 MHz chan-
48 nel.
49
50 CCFS1 This subfield defines a channel center For a 20, 40 or 80 MHz BSS band-
51 frequency for a 160 or 320 MHz EHT width, this subfield is set to 0.
52 BBS.
53 For a 160 MHz BSS bandwidth, indi-
54 cates the channel center frequency
55 index of the 160 MHz channel on
56 which the EHT BSS operates.
57
58 For a 320 MHz BSS bandwidth, indi-
59 cates the channel center frequency
60 index of the 320 MHz channel on
61 which the EHT BSS operates.
62
63 See Table 9-401b (EHT BSS channel
64 width(#6603)).
65

Copyright © 2022 IEEE. All rights reserved. 187

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 9-401b—EHT BSS channel width(#6603)

2
3
4 Channel Width EHT BSS channel
CCFS1 subfield
5 subfield width (MHz)
6
7 0 0 20
8 1 0 40
9
10 2 0 80
11
12 3 CCFS1 > 0 and |CCFS1 – CCFS0| = 8 160
13 4 CCFS1 > 0 and |CCFS1 – CCFS0| = 16 320
14
15
16
17 (#1086)(#1667)(#2148)(#2147)(#6603)The Disabled Subchannel Bitmap subfield is present if the Disabled
18 Subchannel Bitmap Present subfield is equal to 1 and provides a list of subchannels that are punctured
19 within the BSS bandwidth; otherwise it is not present.
20
21
22 (#6603)The Disabled Subchannel Bitmap subfield is a 16-bit bitmap where the lowest numbered bit corre-
23 sponds to the 20 MHz subchannel that lies within the BSS bandwidth and that has the lowest frequency of
24 the set of all 20 MHz subchannels within the BSS bandwidth. Each successive bit in the bitmap corresponds
25
to the next higher frequency 20 MHz subchannel. A bit in the bitmap is set to 1 to indicate that the corre-
26
27 sponding 20 MHz subchannel is punctured and is set to 0 to indicate that the corresponding 20 MHz sub-
28 channel is not punctured.
29
30 9.4.2.312 Multi-Link element
31
32
33 9.4.2.312.1 General
34
35 The format of the Multi-Link element is defined in Figure 9-1002e (Multi-Link element format). The frames
36
37 carrying this element and usage of this element are described in 35.3.2 (Advertisement of multi-link infor-
38 mation in Multi-Link element(#2294)).
39
40
41 Element Element ID Multi-Link Common
ID Length Extension Control Info Link Info
42
43
Octets: 1 1 1 2 variable variable
44
45
46 Figure 9-1002e—Multi-Link element format
47
48 The Element ID, Length, and Element ID Extension fields are defined in 9.4.2.1 (General).
49
50
51 The format of the Multi-Link Control field is defined in Figure 9-1002f (Multi-Link Control field(#1068)).
52
53
54 B0 B2 B3 B4 B15
55
56 Presence
Type Reserved
57 Bitmap
58
59 Bits: 3 1 12
60
61 Figure 9-1002f—Multi-Link Control field(#1068)
62
63
64 (#7566)The Type subfield is defined in Table 9-401c (Type subfield encod-
65 ing(#4813)(#1905)(#2160)(#3247)). (#5741)It has a common encoding for all variants of the Multi-Link

188 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 element and is used to differentiate the variants of the Multi-Link element. Different variants of the Multi-
2 Link element are used for different multi-link operations. (#4100)The format of each variant of the Multi-
3
Link element is defined in the subclauses below.
4
5
6
7 Table 9-401c—Type subfield encoding(#4813)(#1905)(#2160)(#3247)
8
9
10 Type subfield value Multi-Link element variant name
11
12 0 Basic (see 9.4.2.312.2 (Basic Multi-Link element(#6700)))
13 1 Probe Request (see 9.4.2.312.3 (Probe Request Multi-Link ele-
14 ment(#6701)))
15
16 2(#4659) Reconfiguration (see 9.4.2.312.4 (Reconfiguration Multi-Link
17 element(#4659)))
18
3(#4031) TDLS (see 9.4.2.312.5 (TDLS Multi-Link element(#4031)))
19
20 4(#4176) Priority Access (see 9.4.2.312.6 (Priority Access Multi-Link ele-
21 ment(#4176)))
22
23 5–7 Reserved
24
25
26
27 (#3247)The Presence Bitmap subfield is used to indicate the presence of various subfields in the Common
28 Info field (#5741)and has different format for different variants of the Multi-Link element as described in
29 the subclauses below.(#4813)
30
31 (#4106)(#5742)(#1068)The Common Info field carries information that is common to all the links except for
32
33 Link ID Info subfield and BSS Parameters Change Count subfield that are for the link on which the Multi-
34 Link element is sent(#4813).
35
36 The Link Info field carries information specific to the links and is optionally present(#7567). (#5967)When
37 the Link Info field is present, it contains one or more subelements. The subelement format and ordering of
38
39 subelements are defined in 9.4.3 (Subelements). The Subelement ID field values for the defined subelements
40 of the Multi-Link element are shown in Table 9-401d (Optional subelement IDs for Link Info field of the
41 Multi-Link element(#5967)(#5833)).
42
43
44 Table 9-401d—Optional subelement IDs for Link Info field of the Multi-Link
45
46 element(#5967)(#5833)
47
48
Subelement ID Name Extensible
49
50 0 Per-STA Profile(#3019) Yes
51
52 1–220 Reserved
53
54 221 Vendor Specific Vendor defined
55 222–255 Reserved
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 189

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 9.4.2.312.2 Basic Multi-Link element(#6700)

2
3
4 9.4.2.312.2.1 Multi-Link Control field of the Basic Multi-Link element(#5967)(#7567)
5
6
7 (#6700)The Basic Multi-link element is used to carry information of an MLD and its affiliated STAs during
8 multi-link discovery (see 35.3.4.4 (Multi-Link element usage rules in the context of discovery)) and multi-
9 link setup (see 35.3.5.4 (Usage and rules of Basic Multi-Link element in the context of multi-link
10
11 (re)setup(#6700))).
12
13
14 (#3247)The format of the Presence Bitmap subfield of the (#6700)Basic Multi-Link element is defined in
15 Figure 9-1002g (Presence Bitmap subfield of the Basic Multi-Link element for-
16 mat(#6700)(#3247)(#1773)(#2603)(#1078)(#1475)(#2981)(#3017)).
17
18
19 B0 B1 B2 B3 B4 B5 B11
20
21 BSS Medium
22 Parameters Synchronization EML MLD
Link ID Info
Change Delay Capabilities Capabilities Reserved
23 Present
Count Information Present Present
24 Present Present
25
26 Bits: 1 1 1 1 1 7
27
28 Figure 9-1002g—Presence Bitmap subfield of the Basic Multi-Link element for-
29
mat(#6700)(#3247)(#1773)(#2603)(#1078)(#1475)(#2981)(#3017)
30
31
32
33 (#3017)The Link ID Info Present subfield is set to 1 if the Link ID Info subfield is present in the Common
34 Info field. Otherwise, the Link ID Info Present subfield is set to 0.
35
36
37 (#1068)The BSS Parameters Change Count Present subfield is set to 1 if the BSS Parameters Change Count
38 subfield is present in the Common Info field. Otherwise, the BSS Parameters Change Count Present subfield
39 is set to 0.
40
41
42 (#4815)(#7568)The Medium Synchronization Delay Information Present subfield is set to 1 if the Medium
43
Synchronization Delay Information subfield is present in the Common Info field. Otherwise, the Medium
44
45 Synchronization Delay Information Present subfield is set to 0.
46
47
48 (#4816)(#1773)(#2603)The EML Capabilities Present subfield is set to 1 if the EML Capabilities subfield is
49 present in the Common Info field. Otherwise, the EML Capabilities Present subfield is set to 0.
50
51
52 (#1078)(#1475)(#2981)The MLD Capabilities Present subfield is set to 1 if the MLD Capabilities subfield is
53 present in the Common Info field. Otherwise, the MLD Capabilities Present subfield is set to 0.
54
55
56
57
58
59
60
61
62
63
64
65

190 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 9.4.2.312.2.2 Common Info field of the Basic Multi-Link element(#5967)(#7567)

2
3
4 The format of the Common Info field of the (#6700)Basic Multi-Link element is defined in Figure 9-1002h
5 (Common Info field of the Basic Multi-Link element for-
6 mat(#5052)(#6700)(#5043)(#1068)(#2139)(#2159)(#2161)(#3018)(#1773)(#2603)(#3017)).
7
8
9 BSS Medium
Common
10 Info MLD MAC Link ID Parameters Synchronization EML MLD
Address Info Change Delay Capabilities Capabilities
11 Length Count Information
12
13 Octets: 1 6 0 or 1 0 or 1 0 or 2 0 or 3 0 or 2
14
15 Figure 9-1002h—Common Info field of the Basic Multi-Link element for-
16
17 mat(#5052)(#6700)(#5043)(#1068)(#2139)(#2159)(#2161)(#3018)(#1773)(#2603)(#3017)
18
19 (#5043)The Common Info Length subfield indicates the number of octets in the Common Info field.
20
21
22 (#7569)The MLD MAC Address subfield specifies the MAC Address of the MLD with which the STA
23 transmitting the (#6700)Basic Multi-Link element is affiliated.
24
25
26 The format of the Link ID Info subfield is defined in Figure 9-1002i (Link ID Info subfield format(#6868)).
27 (#7568)(#4102)The Link ID subfield of the Link ID Info field indicates the link identifier of the AP that is
28 affiliated with the AP MLD which is described in the Basic Multi-Link element and satisfies one of the fol-
29 lowing:
30
31 — (#4102)It is the AP that transmitted the (#6700)Basic Multi-Link element.
32
33 — (#4102)It is the AP that corresponds to a nontransmitted BSSID that is a member of the same multi-
34 ple BSSID set as the AP that transmitted the Multiple BSSID element containing the profile for the
35 nontransmitted BSSID which includes the (#6700)Basic Multi-Link element.
36
37
38
(#7568)(#6869)Link ID Info subfield in the Common Info field is not present if the (#6700)Basic Multi-
39 Link element is sent by a non-AP STA.
40
41
B0 B3 B4 B7
42
43
44 Link ID Reserved
45
46 Bits: 4 4
47
48 Figure 9-1002i—Link ID Info subfield format(#6868)
49
50
51 (#7568)(#1068)The BSS Parameters Change Count subfield in the Common Info field is (#4102)one octet in
52 length and carries an unsigned integer, initialized to 0. The value carried in the subfield is incremented when
53 a critical update (as defined in 11.2.3.15 (TIM Broadcast) occurs to the operational parameters for the AP
54 that is affiliated with an AP MLD which is described in the Basic Multi-Link element and satisfies one of the
55
following:
56
57 — (#4102)It is the AP that transmitted the (#6700)Basic Multi-Link element.
58
59 — (#4102)It is the AP that corresponds to a nontransmitted BSSID that is a member of the same multi-
60 ple BSSID set as the AP that transmitted the Multiple BSSID element containing the profile for the
61 nontransmitted BSSID which includes the (#6700)Basic Multi-Link element.
62
63
64 (#4102)(#7568)The BSS Parameters Change Count subfield in the Common info field is not present if the
65 (#6700)Basic Multi-Link element is sent by a non-AP STA.

Copyright © 2022 IEEE. All rights reserved. 191

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#4014)The Link ID Info subfield and the BSS Parameters Change Count subfield are present in the Com-
2 mon Info field of the (#6700)Basic Multi-Link element carried in a Beacon frame, Probe Response frame
3
that is ML probe response, and (Re)Association Response frame(#4002).
4
5
6 (#5057)The Medium Synchronization Delay Information subfield in the Common Info subfield is not pres-
7 ent if the Basic Multi-Link element is sent by a non-AP STA. When the Basic Multi-Link element is
8
9 included in a frame sent by an AP, the condition for the presence of the Medium Synchronization Delay
10 Information subfield in the Common Info field is defined in 35.3.16.8 (Medium access recovery procedure).
11 The format of the Medium Synchronization Delay Information subfield is defined in Figure 9-1002j
12 (Medium Synchronization Delay Information subfield format).
13
14
15 B0 B7 B8 B11 B12 B15
16
17 Medium Synchronization
Medium Synchronization Medium Synchronization
18 Duration OFDM ED Threshold
Maximum Number Of
19 TXOPs
20
21 Bits: 8 4 4
22
23 Figure 9-1002j—Medium Synchronization Delay Information subfield format
24
25
26 The Medium Synchronization Duration subfield contains the duration value of the MediumSyncDelay timer
27 in units of 32 µs (see 35.3.16.8 (Medium access recovery procedure)).
28
29
30 (#7702)The Medium Synchronization OFDM ED Threshold subfield indicates the value of dot11MSDOFD-
31 MEDthreshold to be used by a non-AP STA during medium synchronization recovery and is defined in
32 Table 9-401e (Medium Synchronization OFDM ED Threshold subfield).
33
34
35
36 Table 9-401e—Medium Synchronization OFDM ED Threshold subfield
37
38 Subfield value Description
39
40 0–10 (#7572)The dot11MSDOFDMEDthreshold value, in units
41 of dBm, is MSDOFDMEDthreshold = –72 + Fval, where Fval
42 is the subfield value.
43
44 11–15 Reserved
45
46
47
48 The Medium Synchronization Maximum Number Of TXOPs subfield contains the value of the maximum
49 number of TXOPs (MSD_TXOP_MAX) a non-AP STA is allowed to attempt to initiate while the Medium-
50 SyncDelay timer is running at a non-AP STA minus 1(#4817), except that the value 15 indicates any number
51
52 of TXOPs as long as the MediumSyncDelay timer is nonzero.
53
54 (#1773)(#2603)The condition for the presence of the EML Capabilities subfield in the Common Info field is
55
56
defined in 35.3.17 (Enhanced multi-link single radio operation) and 35.3.18 (Enhanced multi-link multi-
57 radio operation).
58
59
60
61
62
63
64
65

192 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#1773)(#2603)The format of the EML Capabilities subfield is defined in Figure 9-1002k (EML Capabili-
2 ties subfield format(#4425)(#1773)(#2603)(#6346)). The EML Capabilities subfield contains a number of
3
subfields that are used to advertise the capabilities for EMLSR operation and EMLMR operation.
4
5
6 B0 B1 B3 B4 B6 B7 B8 B10 B11 B14 B15
7
8 EMLSR EMLSR
9 EMLSR EMLMR EMLMR Transition
Padding Transition Reserved
10 Support Delay Delay Support Delay Timeout
11
12 Bits: 1 3 3 1 3 4 1
13
14 Figure 9-1002k—EML Capabilities subfield format(#4425)(#1773)(#2603)(#6346)
15
16
17 (#1773)(#2603)The EMLSR Support subfield indicates support of the EMLSR operation for an MLD. The
18 EMLSR Support subfield is set to 1 if the MLD supports the EMLSR operation; otherwise it is set to 0.
19 (#7578)For a non-AP MLD, the EMLSR Support subfield is set to 0 if the EMLMR Support subfield is set
20
21 to 1.
22
23 (#1773)(#2603)(#3206)(#2745)(#2917)(#7335)The EMLSR Padding Delay subfield indicates the minimum
24 MAC padding duration of the Padding field of the initial Control frame requested by the non-AP MLD as
25 defined in 35.3.17 (Enhanced multi-link single radio operation). (#8168)When the EMLSR Padding Delay
26
27 subfield is included in a frame sent by an AP affiliated with an AP MLD, the EMLSR Padding Delay sub-
28 field is set to 0. (#5829)The EMLSR Padding Delay subfield includes 3 bits and is set as defined in Table 9-
29 401f (Encoding of the EMLSR Padding Delay subfield(#7335)(#5829)).
30
31
32 Table 9-401f—Encoding of the EMLSR Padding Delay subfield(#7335)(#5829)
33
34
35 EMLSR Padding EMLSR
36 Delay subfield value padding delay
37
38 0 0 µs
39
40 1 32 µs
41 2 64 µs
42
43 3 128 µs
44
45 4 256 µs
46 5–7 Reserved
47
48
49
50 (#6346)The EMLSR Transition Delay subfield indicates the transition delay time needed by a non-AP MLD
51
to switch from exchanging frames on one of the enabled links to the listening operation on the enabled links
52
53 (see 35.3.17 (Enhanced multi-link single radio operation)). The EMLSR Transition Delay subfield is 3 bits
54 and set to 0 for 0 µs, set to 1 for 16 µs, 2 for 32 µs, set to 3 for 64 µs, set to 4 for 128 µs, set to 5 for 256 µs,
55 and the values 6 to 7 are reserved.
56
57
58 The EMLMR Support subfield indicates support of the EMLMR operation for an MLD. The EMLMR Sup-
59 port subfield is set to 1 if the MLD supports the EMLMR operation; otherwise it is set to 0. (#7578)For a
60 non-AP MLD, the EMLMR Support subfield is set to 0 if the EMLSR Support subfield is set to 1.
61
62
The EMLMR Delay subfield indicates the minimum padding duration required for a non-AP MLD for
63
64 EMLMR link switch when operating in EMLMR mode (see 35.3.18 (Enhanced multi-link multi-radio oper-
65 ation)).

Copyright © 2022 IEEE. All rights reserved. 193

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#5830)When the EMLMR Delay subfield is included in a frame sent by a STA affiliated with a non-AP
2 MLD, the EMLMR Delay subfield is set as defined in Table 9-401g (Encoding of the EMLMR Delay sub-
3
4 field(#5830)). When the EMLMR Delay subfield is included in a frame sent by an AP affiliated with an AP
5 MLD, the EMLMR Delay subfield is set to 0.
6
7
8 Table 9-401g—Encoding of the EMLMR Delay subfield(#5830)
9
10
11 EMLMR Delay
EMLMR delay
12 subfield value
13
14 0 0 µs
15
1 32 µs
16
17 2 64 µs
18
19 3 128 µs
20
4 256 µs
21
22 5–7 Reserved
23
24
25
26
27 (#5845)(#6340)(#6341)(#7834)(#8353)The Transition Timeout subfield indicates the timeout value for
28 EML Operating Mode Notification frame exchange in EMLMR mode (see 35.3.18 (Enhanced multi-link
29 multi-radio operation)) and EMLSR mode (see 35.3.17 (Enhanced multi-link single radio operation)).
30
31
32 (#7581)When the Transition Timeout subfield is included in a frame sent by an AP affiliated with an AP
33 MLD, the Transition Timeout subfield is set as defined in Table 9-401h (Encoding of the Transition Time-
34
35
out subfield(#5845)(#7581)). When the Transition Timeout subfield is included in a frame sent by a non-AP
36 STA affiliated with a non-AP MLD, the Transition Timeout subfield is set to 0.
37
38
39 Table 9-401h—Encoding of the Transition Timeout subfield(#5845)(#7581)
40
41
42 Transition Timeout Transition
43 subfield value timeout
44
45 0 0 TUs
46
1 128 µs
47
48 2 256 µs
49
50 3 512 µs
51
4 1 TU
52
53 2 2 TUs
54
55 3 4 TUs
56 4 8 TUs
57
58 5 16 TUs
59
60 6 32 TUs
61 70 64 TUs
62
63 8 128 TUs
64
65 9–15 Reserved

194 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#4425)(#4014)The MLD Capabilities subfield is present in the Common Info field of the (#6700)Basic
2 Multi-Link element carried in a Beacon, Probe Response, (Re)Association Request, and (Re)Association
3
Response frames(#4002).
4
5
6 (#2139)The format of the MLD Capabilities subfield is defined in Figure 9-1002l (MLD Capabilities sub-
7 field format(#4079)(#6605)(#7041)(#1078)(#1475)(#2981)).
8
9
10 B0 B3 B4 B5 B6 B7 B11 B12 B13 B15
11
12 Maximum TID-To-Link Frequency
13 Number Of SRS Mapping Separation For AAR
Simultaneous Support Negotiation STR/AP MLD Support Reserved
14 Links Supported Type Indication
15
16
Bits: 4 1 2 5 1 3
17
18
19 Figure 9-1002l—MLD Capabilities subfield for-
20 mat(#4079)(#6605)(#7041)(#1078)(#1475)(#2981)
21
22
(#2139)The subfields of the MLD Capabilities subfield are defined in Table 9-401i (Subfields of the MLD
23
24 Capabilities field(#1078)(#1475)(#2981)).
25
26
27 Table 9-401i—Subfields of the MLD Capabilities field(#1078)(#1475)(#2981)
28
29
30 Subfield Definition Encoding
31
32 Maximum Number Of (#4365)Indicates the maximum num- (#5746)Set to the maximum number of affili-
33 Simultaneous Links ber of STAs affiliated with the MLD ated STAs in the non-AP MLD that support
34 that support simultaneous transmis- simultaneous transmission or reception of
35 sion or reception of frames on the frames minus 1.
36 respective links. (#4365)For an AP MLD, set to the number of
37 affiliated APs minus 1
38 (#4014)See 35.3.16.2 (Multi-link device capa-
39 bility signaling(#4752)(#4116)).
40 SRS Support Indicates support for the reception of a (#6016)For an AP MLD:
41 frame that carries an SRS Control sub- Set to 1 to indicate that an AP MLD with
42 field. which the AP is affiliated is capable of
43 receiving a frame with an SRS Control
44 subfield. Set to 0 otherwise.
45 (#4266)(#8284)(#6017)For a non-AP MLD:
46 Set to 1 to indicate that a non-AP MLD,
47 with which the non-AP EHT STA is affili-
48 ated, is capable of generating frames with
49 an SRS Control subfield.
50 Set to 0 otherwise.
51 (#4014)See 35.3.16.5 (PPDU end time align-
52 ment).
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 195

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 9-401i—Subfields of the MLD Capabilities field(#1078)(#1475)(#2981) (continued)

2
3
4 Subfield Definition Encoding
5
6 TID-To-Link Map- Indicates support for TID-to-link Set to 0 if dot11TIDtoLinkMappingActivated
7 ping Negotiation Sup- mapping negotiation. is false (#4267)and TID-to-link mapping is not
8 ported supported by the MLD.
9 Set to 1 if dot11TIDtoLinkMappingActivated
10 is true and the MLD supports the mapping of
11 each TID to the same or different link set.
12 Set to 2 if dot11TIDtoLinkMappingActivated
13 is true and the MLD (#4267)only supports the
14 mapping of all TIDs to the same link set.
15 The value 3 is reserved.
16 (See 35.3.7.1.3 (Negotiation of TID-to-link
17 mapping))
18 Frequency Separation Frequency Separation For STR: Frequency Separation For STR:
19 For STR/AP MLD Indicates the minimum frequency For a non-AP MLD:(#7040)
20 Type Indica- gap between any two links that is Set to 0 to indicate that no frequency sepa-
21 tion(#4079) recommended by the non-AP ration information is provided.
22 MLD for STR operation. The fre- Set to a nonzero value n to indicate that the
23 quency gap is specified as the dif- STR frequency gap is  n – 1   80 MHz.
24 ference between the nearest
25 frequency edges of the two links. AP MLD Type Indication:
26 AP MLD Type Indication: For an AP MLD:(#7040)
27 Indicates the type of an AP MLD. Set B7 to 0 to indicate that the AP MLD is
28 not an NSTR mobile AP MLD;
29 Set B7 to 1 to indicate that the AP MLD is
30 an NSTR mobile AP MLD;
31 B8–B11 are reserved.
32
33 (#4014)See 35.3.16.2 (Multi-link device capa-
34 bility signaling(#4752)(#4116)).
35
36 AAR Support(#6605) An AP MLD indicates support for (#6605)(#6021)If the +HTC-HE Support sub-
37 receiving a frame with an AAR Con- field is 1:
38 trol subfield(#6605)(#6021) Set to 1 if the AP MLD supports the AAR
39 Control subfield functionality.
40 Set to 0 otherwise.
41
42 Reserved for non-AP MLD or if the +HTC-HE
43 Support subfield is 0.
44
45 See 35.3.16.8.3 (AP assisted medium synchro-
46 nization recovery procedure).
47
48
49
50 9.4.2.312.2.3 Link Info field of the Basic Multi-Link element(#7567)
51
52 (#6867)(#2587)(#5967)If the Link Info field is present, one or more Per-STA Profile subelements are
53 included in the list of subelements (see Table 9-401d (Optional subelement IDs for Link Info field of the
54
Multi-Link element(#5967)(#5833))).
55
56
57
58
59
60
61
62
63
64
65

196 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#1035)(#2183)(#2451)(#1799)(#1050)(#1778)(#2165)The format of a Per-STA Profile subelement is

2 defined in Figure 9-1002m (Per-STA Profile subelement format).
3
4
5 Subelement Length STA Control STA Info STA Profile
6 ID
7
8 Octets: 1 1 2 variable variable
9
10 Figure 9-1002m—Per-STA Profile subelement format
11
12
13 The format of the STA Control field is defined in Figure 9-1002n (STA Control field for-
14 mat(#5784)(#1906)(#1907)(#1078)(#1475)(#2981)(#4453)(#4457)).
15
16
17 B0 B3 B4 B5 B6 B7 B8 B9 B10 B11 B15
18
19 BSS
20 STA NSTR
Beacon DTIM NSTR Parameters
Link ID Complete MAC Interval Info Link Bitmap Change Reserved
21 Profile Address Pair
22 Present Present Present Present Size Count
Present
23
24
Bits: 4 1 1 1 1 1 1 1 5
25
26
27 Figure 9-1002n—STA Control field for-
28 mat(#5784)(#1906)(#1907)(#1078)(#1475)(#2981)(#4453)(#4457)
29
30
31 The Link ID subfield specifies a value that uniquely identifies the link where the reported STA is operating
32 on. The usage of link ID is defined in 35.3.2.1 (General)(#1776).
33
34
35 (#2436)The Complete Profile subfield is set to 1 when the Per-STA Profile subelement of the Multi-Link
36 element carries the complete profile as defined in 35.3.2.2 (Advertisement of complete or partial per-link
37 information(#1859)). Otherwise the subfield is set to 0.
38
39
40 (#1035)(#2183)(#2451)(#1799)(#1050)(#1778)(#2165)(#5784)The STA MAC Address Present subfield
41 indicates the presence of the STA MAC Address subfield in the STA Info field and is set to 1 if the STA
42 MAC Address subfield is present in the STA Info field; otherwise set to 0. (#5129)A STA sets this subfield
43
to 1 when the element carries complete profile.
44
45
46 The Beacon Interval Present subfield indicates the presence of the Beacon Interval subfield in the STA Info
47 field and is set to 1 if the Beacon Interval subfield is present in the STA Info field; otherwise set to 0.
48
49 (#8286)A non-AP STA sets the Beacon Interval Present subfield to 0 in the transmitted (#6700)Basic Multi-
50 Link element. An AP sets this subfield to 1 when the element carries complete profile. (#6965)An AP affili-
51 ated with an NSTR mobile AP MLD and that is operating on the nonprimary link set this subfield to 0.
52
53
54 The DTIM Info Present subfield indicates the presence of the DTIM Info subfield in the STA Info field and
55 is set to 1 if the DTIM Info subfield is present in the STA Info field; otherwise set to 0. (#8287)A non-AP
56 STA sets the DTIM Info Present subfield to 0 in the transmitted (#6700)Basic Multi-Link element. An AP
57 sets this subfield to 1 when the element carries complete profile. (#6965)An AP affiliated with an NSTR
58
59
mobile AP MLD and that is operating on the nonprimary link set this subfield to 0.
60
61 (#8287)(#1078)(#1475)(#2981)If the value of the Maximum Number Of Simultaneous Links subfield in the
62
MLD Capabilities field is greater than 0, the NSTR Link Pair Present subfield in the STA Control field indi-
63
64 cates if at least one NSTR link pair is present in the MLD that contains the link corresponding to that STA.
65 It is set to 1 if there is at least one such link pair; otherwise it is set to 0.

Copyright © 2022 IEEE. All rights reserved. 197

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#8288)If the Complete Profile subfield is equal to 1 and the NSTR Link Pair Present subfield is equal to 1
2 in the STA Control field, then the STA Info field contains an NSTR Indication Bitmap subfield whose size
3
is indicated in the NSTR Bitmap Size subfield; otherwise, the NSTR Indication Bitmap subfield is not pres-
4
5 ent in the STA Info field. (#7392)The NSTR Bitmap Size subfield in a STA Control field is set to 1 if the
6 length of the corresponding NSTR Indication Bitmap subfield is equal to 2 and is set to 0 if the length of the
7 corresponding NSTR Indication Bitmap subfield is equal to 1. The NSTR Bitmap Size subfield in the STA
8 Control field is reserved if the NSTR Link Pair Present subfield in that field is 0.
9
10
11 (#4453)(#4457)The BSS Parameters Change Count Present subfield indicates the presence of the BSS
12 Parameters Change Count subfield in the STA Info field and is set to 1 if the BSS Parameters Change Count
13 subfield is present in the STA Info field; otherwise set to 0. A non-AP STA sets the BSS Parameters Change
14
15 Count Present subfield to 0 in the transmitted Basic Multi-Link element. If the Basic Multi-Link element
16 carries complete profile and is carried in the (Re)Association Response frame, an AP sets this subfield to 1.
17 Otherwise, an AP sets this subfield to 0.
18
19
20 (#8288)(#6366)The format of the STA Info field is defined in Figure 9-1002o (STA Info field for-
21 mat(#5044)(#6366)(#4453)(#4457)).
22
23
24 NSTR BSS
STA Info STA MAC Beacon Parameters
25 Length Address Interval DTIM Info Indication Change
26 Bitmap
Count
27
28 Octets: 1 0 or 6 0 or 2 0 or 2 0 or 1 or 2 0 or 1
29
30 Figure 9-1002o—STA Info field format(#5044)(#6366)(#4453)(#4457)
31
32
33 (#5044)The STA Info Length subfield indicates the number of octets in the STA Info field.
34
35
36 (#8170)(#7584)The STA MAC Address subfield of the STA Info field carries the MAC address of the STA
37 that operates on the link identified by the Link ID subfield and is affiliated with the same MLD as the STA
38 that transmitted the (#6700)Basic Multi-Link element.
39
40
41 (#6366)(#1035)The Beacon Interval subfield of the STA Info field is defined in 9.4.1.3 (Beacon Interval
42 field) and carries the value of beacon interval for the reported AP.
43
44
45 The DTIM Info subfield of the STA Info field has the format as defined in Figure 9-1002p (DTIM Info sub-
46 field format).
47
48
49 DTIM Count DTIM Period
50
51 Octets: 1 1
52
53 Figure 9-1002p—DTIM Info subfield format
54
55
56 (#1035)The DTIM Count subfield and the DTIM Period subfield are as defined in 9.4.2.5 (TIM element)
57 and carries the value of DTIM count and DTIM period, respectively, for the reported AP.
58
59
60 (#8288)Each bit Bj  j  i  in the NSTR Indication Bitmap subfield included in the Per-STA Profile subele-
61 ment with Link ID subfield equals to i (where 0  i  15 ) is set to 1 if the link pair corresponding to Link
62
IDs equal to <i, j> is NSTR and the (#6700)Basic Multi-Link element contains a Per-STA Profile subele-
63
64 ment with Link ID value equals to j; otherwise it is set to 0. Bit Bi in the NSTR Indication Bitmap subfield
65 included in the Per-STA Profile subelement with Link ID subfield value equals to i is reserved.

198 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#4453)(#4457)The BSS Parameters Change Count subfield of the STA Info field is defined in 9.4.2.170.2
2 (Neighbor AP Information field) and carries the value of BSS parameters change count for the reported AP.
3
4
5 (#4735)The contents of the STA Profile field are defined in 35.3.2.2 (Advertisement of complete or partial
6 per-link information(#1859)).
7
8
9 (#1908)(#2159)(#2161)The Vendor Specific subelements have the same format as their corresponding ele-
10 ments (see 9.4.2.25 (Vendor Specific element)). Zero or more Vendor Specific subelements are included in
11 the list of optional subelements.
12
13
14 9.4.2.312.3 Probe Request Multi-Link element(#6701)
15
16
17
(#6701)The Probe Request Multi-Link element is used to request an AP to provide information of other APs
18 affiliated with the same AP MLD as the AP. The inclusion of a (#6701)Probe Request Multi-Link element in
19 a Probe Request frame identifies it as an ML probe request(#2583)(#3360).
20
21
22 (#6262)(#6237)(#6238)The format of the Presence Bitmap subfield of the Probe Request Multi-Link ele-
23 ment is defined in Figure 9-1002q (Presence Bitmap field of the Probe Request Multi-Link element for-
24 mat(#6262)(#6237)(#6238)).
25
26
27 B0 B1 B11
28
29 MLD ID Present Reserved
30
31 Bits: 1 11
32
33 Figure 9-1002q—Presence Bitmap field of the Probe Request Multi-Link element for-
34 mat(#6262)(#6237)(#6238)
35
36
37 (#6262)(#6237)(#6238)The MLD ID Present subfield is set to 1 if it is present in the Common Info field.
38
Otherwise the MLD ID Present subfield is set to 0.
39
40
41 (#6262)(#6237)(#6238)The format of the Common Info field of the Probe Request Multi-Link element is
42 defined in Figure 9-1002r (Common Info field of the Probe Request Multi-Link element for-
43
44 mat(#6262)(#6237)(#6238)).
45
46 Common Info Length MLD ID
47
48
Octets: 1 0 or 1
49
50
51 Figure 9-1002r—Common Info field of the Probe Request Multi-Link element for-
52 mat(#6262)(#6237)(#6238)
53
54
55 (#6262)(#6237)(#6238)The Common Info Length subfield indicates the number of octets in the Common
56 Info field.
57
58
59 (#6262)(#6237)(#6238)The MLD ID subfield indicates the identifier of the AP MLD that is targeted by the
60 ML probe request.
61
62
(#5833)(#5967)If the Link Info field is present, one or more Per-STA Profile subelements are included in
63
64 the list of subelements (see Table 9-401d (Optional subelement IDs for Link Info field of the Multi-Link ele-
65 ment(#5967)(#5833))).

Copyright © 2022 IEEE. All rights reserved. 199

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#3247)(#6451)The format of a Per-STA Profile subelement is defined in Figure 9-1002s (Per-STA Profile
2 subelement of the Probe Request Multi-Link element format(#6701)(#6451)(#6865)(#3247)).
3
4
5 Subelement ID Length STA Control STA Profile
6
7 Octets: 1 1 2 variable
8
9 Figure 9-1002s—Per-STA Profile subelement of the Probe Request Multi-Link element for-
10
mat(#6701)(#6451)(#6865)(#3247)
11
12
13 (#5833)(#3247)(#6451)The format of the STA Control field is defined in Figure 9-1002t (STA Control field
14
of the Probe Request Multi-Link element format(#6701)(#6451)(#6865)(#3247)).
15
16
17 B0 B3 B4 B5 B15
18
19
Link ID Complete Profile Reserved
20
21
Bits: 4 1 11
22
23
24 Figure 9-1002t—STA Control field of the Probe Request Multi-Link element for-
25 mat(#6701)(#6451)(#6865)(#3247)
26
27
28 (#3247)The Link ID subfield specifies a value that uniquely identifies the AP (#7585)whose information is
29 requested.
30
31 (#5737)(#2164)The Complete Profile subfield is set to 1 when complete profile (#7586)of the AP identified
32
33 by the Link ID subfield is requested as defined in 35.3.4.2 (Use of ML probe request and
34 response(#2583)(#3360)). Otherwise, the subfield is set to 0.
35
36 (#6130)(#6131)(#5737)(#2164)If the Complete Profile subfield is set to 0, the STA Profile field, if present
37
in a Per-STA Profile subelement (see 35.3.4.2 (Use of ML probe request and response(#2583)(#3360)) and
38
39 35.3.2.3.2 (Inheritance in the per-STA profile of Probe Request Multi-Link element(#2416)(#6700))),
40 includes exactly one of the following:
41
42
— (#5834)one Request element (see 9.4.2.9 (Request element)), or
43 — (#5834)one Extended Request element (see 9.4.2.10 (Extended Request element)), or
44
45 — (#7587)one Request element and one Extended Request element
46
47 If the Complete Profile subfield is set to 1, the STA Profile field is not present in a Per-STA Profile subele-
48
ment.
49
50
51 9.4.2.312.4 Reconfiguration Multi-Link element(#4659)
52
53
54 The Reconfiguration Multi-Link element is used to announce an ML reconfiguration operation (see 35.3.6
55 (Multi-Link reconfiguration(#4659))).
56
57
58
59
60
61
62
63
64
65

200 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The format of the Presence Bitmap subfield of the Reconfiguration Multi-Link element is defined in
2 Figure 9-1002u (Presence Bitmap subfield of the Reconfiguration Multi-Link element format(#4659)).
3
4
5 B0 B1 B11
6
7 MLD MAC
8 Reserved
Address Present
9
10 Bits: 1 11
11
12 Figure 9-1002u—Presence Bitmap subfield of the Reconfiguration Multi-Link element for-
13 mat(#4659)
14
15
16 The MLD MAC Address Present subfield is set to 1 if the MLD MAC Address field is present in the Com-
17 mon Info field. Otherwise, the subfield is set to 0.
18
19
20 The format of the Common Info field of the Reconfiguration Multi-Link element is defined in Figure 9-
21 1002v (Common Info field of the Reconfiguration Multi-Link element format(#4659)).
22
23
24 MLD MAC Address
25
26 Octets: 0 or 6
27
28 Figure 9-1002v—Common Info field of the Reconfiguration Multi-Link element for-
29 mat(#4659)
30
31
32 The MLD MAC Address subfield specifies the MAC Address of the MLD with which the STA transmitting
33
34
the Reconfiguration Multi-Link element is affiliated.
35
36 One or more Per-STA Profile subelements are included in the list of subelements (#5967)in the Link Info
37 field (see Table 9-401d (Optional subelement IDs for Link Info field of the Multi-Link ele-
38
ment(#5967)(#5833))).
39
40
41 Each Per-STA Profile subelement starts with a STA Control field, followed by a variable number of fields
42 and elements, as defined in 35.3.6 (Multi-Link reconfiguration(#4659)).
43
44
45 The format of a Per-STA Profile subelement is defined inFigure 9-1002w (Per-STA Profile subelement for
46 the Reconfiguration Multi-Link element(#4659)).
47
48
49 Subelement ID Length STA Control STA Info STA Profile
50
51 Octets: 1 1 2 variable variable
52
53 Figure 9-1002w—Per-STA Profile subelement for the Reconfiguration Multi-Link ele-
54 ment(#4659)
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 201

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The format of the STA Control field is defined in Figure 9-1002x (STA Control field format for the Recon-
2 figuration Multi-Link element(#4659)).
3
4
5 B0 B3 B4 B5 B6 B7 B15
6
7 Complete MAC Address Delete Timer
8 Link ID Reserved
Profile Present Present
9
10 Bits: 4 1 1 1 9
11
12 Figure 9-1002x—STA Control field format for the Reconfiguration Multi-Link element(#4659)
13
14
15 The Link ID subfield specifies a value that uniquely identifies the link that the reported AP is operating on.
16
17 The Complete Profile subfield is set to 1 when the Per-STA Profile subelement of the Multi-Link element is
18
19 complete as defined in 35.3.2.2 (Advertisement of complete or partial per-link information(#1859)). Other-
20 wise, the subfield is set to 0.
21
22 The MAC Address Present subfield indicates the presence of the STA MAC Address subfield in the STA
23
Info field and is set to 1 if the STA MAC Address subfield is present in the STA Info field; otherwise set to
24
25 0. A STA sets this subfield to 1 when the element carries complete profile.
26
27 The Delete Timer Present subfield is set to 1 to indicate the presence of the Delete Timer subfield in the STA
28 Info field, and that the AP corresponding to the Per-STA Profile subelement will be removed at the time
29
30
indicated by the Delete Timer subfield; it is set to 0 otherwise.
31
32 The STA Info field consists of zero or more fields whose presence is indicated by the subfields of the STA
33 Control field. The subfields in the STA Info field appear in the same order as their corresponding presence
34 subfield in the STA Control field.
35
36
37 The STA MAC Address subfield of the STA Info field carries the MAC address of the AP that can operate
38 on the link identified by the Link ID subfield and is affiliated with the same MLD as the STA that transmit-
39 ted the Reconfiguration Multi-Link element.
40
41
42 The format of the Delete Timer subfield of the STA Info field is defined in Figure 9-1002y (Delete Timer
43 subfield format(#4659)).
44
45
46 Delete Timer
47
48 Octets: 2
49
50 Figure 9-1002y—Delete Timer subfield format(#4659)
51
52
53 The Delete Timer subfield indicates the number of TBTTs of the AP corresponding to the Per-STA Profile
54 subelement until the AP is removed.
55
56 The Vendor Specific subelements have the same format as their corresponding elements (see
57
58
9.4.2.25 (Vendor Specific element)). Zero or more Vendor Specific subelements are included in the list of
59 optional subelements.
60
61 9.4.2.312.5 TDLS Multi-Link element(#4031)
62
63
64 The usage of TDLS Multi-Link element is described in 35.3.21 (TDLS procedure in multi-link opera-
65 tion(#4032)).

202 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The Presence Bitmap subfield of the Multi-Link Control field is reserved in TDLS Multi-link element when
2 TDLS direct link discovery or setup is for a single link (see 35.3.21.2 (TDLS direct link over a single link).
3
4
5 The format of the Common Info field of the TDLS Multi-Link element is defined in Figure 9-1002z (Format
6 of the Common Info field of the TDLS Multi-Link element).
7
8
9 Common Info Length AP MLD MAC Address
10
11 Octets: 1 6
12
13 Figure 9-1002z—Format of the Common Info field of the TDLS Multi-Link element
14
15
16 The Common Info Length subfield indicates the number of octets in the Common Info field.
17
18
19
The AP MLD MAC Address subfield carries the MAC address of the AP MLD with which the non-AP
20 MLD, affiliated with the transmitting STA, has performed multi-link setup.
21
22 Link Info field is not present when TDLS direct link discovery or setup is for a single link (see 35.3.21.2
23
(TDLS direct link over a single link)).
24
25
26 9.4.2.312.6 Priority Access Multi-Link element(#4176)
27
28
29 The Priority Access Multi-Link element carries EDCA Parameter sets used by EPCS priority access (see
30 35.17 (EPCS priority access(#5284))).
31
32 The format of the Presence Bitmap subfield of the Priority Access Multi-Link element is defined in
33
34 Figure 9-1002aa (Presence Bitmap subfield of the Priority Access Multi-Link element format(#4176)).
35
36
B0 B1 B11
37
38
AP MLD MAC Address
39 Present
Reserved
40
41
Bits: 1 11
42
43
44
Figure 9-1002aa—Presence Bitmap subfield of the Priority Access Multi-Link element for-
45 mat(#4176)
46
47
48 The AP MLD MAC Address Present subfield is set to 1 if the AP MLD MAC Address field is present in the
49 Common Info field. Otherwise, the subfield is set to 0.
50
51 The format of the Common Info field of the Priority Access Multi-Link element is defined in Figure 9-
52
53 1002ab (Common Info field of the Priority Access Multi-Link element format(#4176)).
54
55
AP MLD MAC Address
56
57
Octets: 0 or 6
58
59
60 Figure 9-1002ab—Common Info field of the Priority Access Multi-Link element for-
61 mat(#4176)
62
63
64 The AP MLD MAC Address subfield specifies the MAC Address of the AP MLD which the AP transmit-
65 ting the Priority Access Multi-Link element is affiliated with.

Copyright © 2022 IEEE. All rights reserved. 203

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The Link Info field contains zero or more subelements of Per-STA Profile. The subelement format and
2 ordering of subelements are defined in 9.4.3 (Subelements).
3
4
5 The Subelement ID field values for the defined subelements of the Priority Access Multi-Link element are
6 shown in Table 9-401j (Optional subelement IDs for the Priority Access Multi-Link element(#4176)).
7
8
9 Table 9-401j—Optional subelement IDs for the Priority Access Multi-Link element(#4176)
10
11
12 Subelement ID Name Extensible
13
14 0 Per-STA Profile Yes
15
16 1–220 Reserved
17 221 Vendor Specific Vendor defined
18
19 222–255 Reserved
20
21
22
23 Each Per-STA Profile subelement starts with a STA Control field, followed by a variable number of fields
24 and elements.
25
26
27 The format of a Per-STA Profile subelement is defined in Figure 9-1002ac (Per-STA Profile subelement for-
28 mat for the Priority Access Multi-Link element(#4176)).
29
30
31 Subelement ID Length STA Control STA Profile
32
33 Octets: 1 1 2 variable
34
35 Figure 9-1002ac—Per-STA Profile subelement format for the Priority Access Multi-Link ele-
36 ment(#4176)
37
38
39 The format of the STA Control field is defined in Figure 9-1002ad (STA Control field format for the Priority
40 Access Multi-Link element(#4176)).
41
42
43 B1 B3 B4 B15
44
45 Link ID Reserved
46
47 Bits: 4 12
48
49 Figure 9-1002ad—STA Control field format for the Priority Access Multi-Link ele-
50 ment(#4176)
51
52
53 The Link ID subfield specifies a value that uniquely identifies the link that the AP affiliated with the AP
54 MLD is operating on.
55
56
57 The STA Profile subfield optionally contains the following two elements:
58
— The EDCA Parameter Set element defined in 9.4.2.28 (EDCA Parameter Set element) that carries
59
60 the EDCA parameter information used for priority access on the link identified by the Link ID in the
61 STA Control field, and
62
— (#4178)The MU EDCA Parameter Set element defined in 9.4.2.251 (MU EDCA Parameter Set ele-
63
64 ment) which carries the MU EDCA parameter information used for MU priority access on the link
65 identified by the Link ID in the STA Control field.

204 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.25 (Ven-
2 dor Specific element)). Zero or more Vendor Specific subelements are included in the list of optional subele-
3
ments.
4
5
6 9.4.2.313 EHT Capabilities element(#4819)
7
8
9 9.4.2.313.1 General(#1126)
10
11
12 A STA declares that it is an EHT STA by transmitting the EHT Capabilities element.
13
14
15 The EHT Capabilities element contains a number of fields that are used to advertise the EHT capabilities of
16 an EHT STA. The EHT Capabilities element is defined in Figure 9-1002ae (EHT Capabilities element for-
17 mat).
18
19
20 EHT MAC EHT PHY Supported EHT PPE
Element Length Element ID Capabilities Capabilities EHT-MCS Thresholds
21 Extension
22 Information Information And NSS Set (Optional)
23
24 Octets: 1 1 1 2 9 variable variable
25
26 Figure 9-1002ae—EHT Capabilities element format
27
28
29 The Element ID, Length, and Element ID Extension fields are defined in 9.4.2.1 (General).
30
31
32 The EHT MAC Capabilities Information, EHT PHY Capabilities Information, Supported EHT-MCS And
33 NSS Set, and EHT PPE Thresholds fields are defined in the subclauses below.
34
35
36 9.4.2.313.2 EHT MAC Capabilities Information field(#1126)
37
38
39 The format of the EHT MAC Capabilities Information field is defined in Figure 9-1002af (EHT MAC Capa-
40 bilities Information field format(#4295)(#4918)(#6630)(#2920)(#1977)).
41
42
43 B0 B1 B2 B3 B4
44
45 EPCS Priority Triggered TXOP Triggered TXOP
Access EHT OM Control Sharing Mode 1 Sharing Mode 2 Restricted TWT
46 Support Support
Supported(#5284) Support Support
47
48
Bits: 1 1 1 1 1
49
50
51 B5 B6 B7 B8 B9 B15
52
53 SCS Traffic Maximum
Maximum A-MPDU Length
54 Description MPDU Length Exponent Reserved
55 Support
Extension
56
57 Bits: 1 2 1 7
58
59 Figure 9-1002af—EHT MAC Capabilities Information field for-
60
61
mat(#4295)(#4918)(#6630)(#2920)(#1977)
62
63
64 The subfields of the EHT MAC Capabilities Information field are defined in Table 9-401k (Subfields of the
65 EHT MAC Capabilities Information field).

Copyright © 2022 IEEE. All rights reserved. 205

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 9-401k—Subfields of the EHT MAC Capabilities Information field

2
3
4 Subfield Definition Encoding
5
6 (#6239)EPCS Prior- (#6239)Indicates whether or not (#7525)Set to 1 if dot11EHTOptionImple-
7 ity Access Supported EPCS priority access is supported. mented and dot11EHTEPCSPriorityAccess-
8 Activated are true (see 35.17 (EPCS priority
9 access(#5284))).
10 Set to 0 otherwise.
11 EHT OM Control Indicates support for receiving a If the +HTC-HE Support subfield is 1 in a
12 Support frame with an EHT OM Control sub- STA:
13 field. Set to 1 if the STA supports reception of
14 the EHT OM Control subfield.
15 Set to 0 otherwise.
16 Reserved if the +HTC-HE Support subfield is
17 0 in a STA.
18
19 (#4918)Triggered Indicates support for transmitting or For an EHT AP:
20 TXOP Sharing Mode responding to (#7588)an MU-RTS Set to 1 to indicate that the AP is capable
21 1 Support TXS Trigger frame with Triggered of transmitting (#7588)an MU-RTS TXS
22 TXOP Sharing Mode field equal to 1 Trigger frame that allocates time to a STA
23 that does not solicit TB PPDU. to transmit non-TB PPDUs to the EHT AP
24 (i.e., with Triggered TXOP Sharing Mode
25 field equal to 1 (see 35.2.1.2 (Triggered
26 TXOP sharing procedure))).
27 Set to 0 otherwise.
28 For an non-AP EHT STA:
29 Set to 1 to indicate that the non-AP STA is
30 capable of responding to (#7588)an MU-
31 RTS TXS Trigger frame that allocates
32 time to (#8294)the STA to transmit non-
33 TB PPDUs to the EHT AP (i.e., with Trig-
34 gered TXOP Sharing Mode field equal to
35 1 (see 35.2.1.2 (Triggered TXOP sharing
36 procedure))).
37 Set to 0 otherwise.
38
39 (#4918)Triggered Indicates support for transmitting or For an EHT AP:
40 TXOP Sharing Mode responding to (#7588)an MU-RTS Set to 1 to indicate that the AP is capable
41 2 Support TXS Trigger frame with Triggered of transmitting (#7588)an MU-RTS TXS
42 TXOP Sharing Mode field equal to 2 Trigger frame that allocates time to a STA
43 that does not solicit TB PPDU. to transmit non-TB PPDUs to other STAs
44 (#7588)or to its associated AP (i.e., with
45 Triggered TXOP Sharing Mode field
46 equal to 2 (see 35.2.1.2 (Triggered TXOP
47 sharing procedure))).
48 Set to 0 otherwise.
49 For an non-AP EHT STA:
50 Set to 1 to indicate that the non-AP STA is
51 capable of responding to (#7588)an MU-
52 RTS TXS Trigger frame that allocates
53 time to (#8294)the STA to transmit non-
54 TB PPDUs to other STAs (#7588)or to its
55 associated AP (i.e., with Triggered TXOP
56 Sharing Mode field equal to 2 (see
57 35.2.1.2 (Triggered TXOP sharing proce-
58 dure))).
59 Set to 0 otherwise.
60 (#2920)Restricted Indicates support for the r-TWT oper- Set to 1 if dot11RestrictedTWTOptionImple-
61 TWT Support ation. mented is true and the STA supports the r-
62 TWT operation (see 35.9 (Restricted TWT (r-
63 TWT))).
64 Set to 0 otherwise.
65

206 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 9-401k—Subfields of the EHT MAC Capabilities Information field (continued)

2
3
4 Subfield Definition Encoding
5
6 (#1977)SCS Traffic Indicates support for transmission and Set to 1 by an EHT AP that supports transmis-
7 Description Support reception of SCS Descriptor elements sion of SCS Response frames containing SCS
8 containing a (#4918)QoS Characteris- Descriptor element with a (#4918)QoS Char-
9 tics subelement. acteristics element and dot11SCSActivated is
10 true.
11 Set to 1 by a non-AP EHT STA that supports
12 transmission of SCS Request frames contain-
13 ing SCS Descriptor element with a
14 (#4918)QoS Characteristics element and
15 dot11SCSActivated is true.
16 Set to 0 otherwise.(#6605)
17 (#6630)Maximum Indicates the maximum MPDU length Reserved when transmitted in 5 GHz or 6 GHz
18 MPDU Length that the STA is capable of receiving band.
19 (see 10.11 (A-MSDU operation)). Otherwise,
20 set to 0 for 3895 octets.
21 set to 1 for 7991 octets.
22 set to 2 for 11 454 octets.
23 The value 3 is reserved.
24
25 (#4295)Maximum A- Indicates the exponent extension for Set to the value of the maximum A-MPDU
26 MPDU Length Expo- the maximum A-MPDU length sup- exponent extension value.
27 nent Extension ported in reception (see 35.6 (A-
28 MPDU operation in an EHT
29 PPDU(#4295))).
30
31
32
33 9.4.2.313.3 EHT PHY Capabilities Information field
34
35 The format of the EHT PHY Capabilities Information field is defined in Figure 9-1002ag (EHT PHY
36 Capabilities Information field format)(#6367).
37
38
39 The subfields of the EHT PHY Capabilities Information field are defined in Table 9-401l (Subfield of the
40 EHT PHY Capabilities Information field).
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 207

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2 B0 B1 B2 B3 B4 B5 B6
3
4 Support For
Support For 242-tone RU In NDP With Partial
5 Reserved 320 MHz 4 EHT-LTF And Bandwidth SU Beamformer SU Beamformee
BW Wider Than
In 6 GHz 20 MHz
3.2 µs GI UL MU-MIMO
6
7
8 Bits: 1 1 1 1 1 1 Bits: 1
9
10 B7 B9 B10 B12 B13 B15 B16 B18 B19 B21 B22 B24 B25
11
12 Number Of Number Of Number Of
Beamformee SS Beamformee SS Beamformee SS Sounding Sounding Sounding Ng = 16 SU
13 (≤ 80 MHz) (= 160 MHz) (= 320 MHz) Dimensions Dimensions Dimensions Feedback
14 (≤ 80 MHz) (= 160 MHz) (= 320 MHz)
15
16 Bits 3 3 3 3 3 3 1
17
18 B26 B27 B28 B29 B30 B31 B32
19
20 Codebook Size Codebook Size
Triggered SU
Triggered MU
Partial
Ng = 16 MU  ,   =  4, 2   ,   =  7, 5  Beamforming Triggered CQI
21 Feedback
Beamforming
Partial BW Feedback
Bandwidth
Feedback DL MU-MIMO
22 SU Feedback MU Feedback Feedback
23
24 Bits: 1 1 1 1 1 1 1
25
26 B33 B34 B35 B36 B39 B40 B41 B42
27
28 (#5444)EHT
EHT MU PPDU Tx 1024-QAM Rx 1024-QAM
29 Power Boost With Non-Triggered And 4096-QAM And 4096-QAM
PSR-Based SR Max Nc
Factor Support 4 EHT-LTF And CQI Feedback < 242-tone RU < 242-tone RU
30 Support
0.8 µs GI Support Support
31
32 Bits: 1 1 1 4 1 1 1
33
34 B43 B44 B45 B46 B50 B51 B54 B55 B56 B57
35
36 Support For
37 Maximum (#5709)Support 20 MHz
Common Non-OFDMA
PPE Thresholds Nominal Packet
Number Of (#4968)Support Of EHT DUP Operating STA
UL MU-MIMO
38 Present Supported Of MCS 15 (MCS 14) In Receiving NDP
Padding (BW ≤ 80 MHz)
39 EHT-LTFs 6 GHz With Wider
Bandwidth
40
41
Bits: 1 2 5 4 1 1 1
42
43
B58 B59 B60 B61 B62 B63 B64
44
45
(#5770)TB Rx 1024-QAM In
46 Non-OFDMA Non-OFDMA
MU Beamformer MU Beamformer MU Beamformer Sounding Wider Bandwidth
UL MU-MIMO UL MU-MIMO
47 (BW = 160 MHz) (BW = 320 MHz)
(BW ≤ 80 MHz) (BW = 160 MHz) (BW = 320 MHz) Feedback Rate DL OFDMA
48 Limit Support
49
50 Bits 1 1 1 1 1 1 1
51
52 B65 B66 B71
53
54 Rx 4096-QAM In
Wider Bandwidth
55 DL OFDMA Reserved
56 Support
57
58 Bits: 1 6
59
60 Figure 9-1002ag—EHT PHY Capabilities Information field format
61
62
63
64
65

208 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 9-401l—Subfield of the EHT PHY Capabilities Information field

2
3
4 Subfield Definition Encoding
5
6 Support For Indicates support for non-OFDMA 320 MHz Set to 0 if not supported.
7 320 MHz In 6 GHz PPDUs when operating in the 6 GHz fre- Set to 1 if supported.
8 quency band.
9
10 Support For 242-tone Indicates support for reception of a 242-tone (#4510)For a non-AP STA:
11 RU In BW Wider RU in a PPDU with a bandwidth larger than Set to 0 if not supported.
12 Than 20 MHz 20 MHz (#4510)when the STA is a 20 MHz Set to 1 if supported.
13 operating non-AP STA.
(#4510)Reserved for an AP.
14
15 NDP With 4 EHT- For a beamformee, indicates support for If the SU Beamformee field is 1:
16 LTF And 3.2 µs GI receiving an EHT sounding NDP with Set to 0 if not supported.
17 4 EHT-LTF and 3.2 µs guard interval dura- Set to 1 if supported.
18 tion.
19 (#4512)Reserved if the SU Beamfor-
20 mee field is 0.
21
22 Partial Bandwidth For an AP, indicates support for receiving an Set to 0 if not supported.
23 UL MU-MIMO EHT TB PPDU on an RU/MRU where MU- Set to 1 if supported.
24 MIMO is employed and where the RU/MRU
25 does not span the entire nonpunctured portion
26 of the PPDU bandwidth (#5711)(UL MU-
27 MIMO within OFDMA).
28
29 For a non-AP STA, indicates support for trans-
30 mitting an EHT TB PPDU on an RU/MRU
31 where MU-MIMO is employed and where the
32 RU/MRU does not span the entire nonpunc-
33 tured portion of the PPDU bandwidth
34 (#5711)(UL MU-MIMO within OFDMA).
35
36 NOTE—The RU/MRU is a 242-tone or larger
37 RU.
38 SU Beamformer Indicates support for operation as an SU beam- Set to 0 if not supported.
39 former. Set to 1 if supported.
40
41 NOTE—Set to 1 if any of the follow-
42 ing subfields, MU Beamformer (BW
43 ≤ 80 MHz), MU Beamformer
44 (BW = 160 MHz), and MU Beam-
45 former (BW = 320 MHz), is 1.
46
47 SU Beamformee Indicates support for operation as an SU beam- For an AP:
48 formee. Set to 0 if not supported.
49 Set to 1 if supported.
50 Set to 1 for a non-AP STA.
51
52 Beamformee SS For a PPDU bandwidth less than or equal to If the SU Beamformee subfield is 1:
53 (≤ 80 MHz) 80 MHz, indicates the maximum number of Set to the maximum number of
54 spatial streams that the STA can receive in an spatial streams that the STA is
55 EHT sounding NDP, which is also the maxi- capable of receiving in an EHT
56 mum total number of spatial streams over all sounding NDP minus 1. The mini-
57 the users that can be sent in a DL MU-MIMO mum value of this field is 3.
58 transmission on an RU/MRU that includes that Reserved if the SU Beamformee field
59 STA, where the RU/MRU might or might not is 0.
60 span the entire PPDU bandwidth.
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 209

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 9-401l—Subfield of the EHT PHY Capabilities Information field (continued)

2
3
4 Subfield Definition Encoding
5
6 Beamformee SS For a PPDU bandwidth of 160 MHz, indicates If the SU Beamformee subfield is 1:
7 (= 160 MHz) the maximum number of spatial streams that Set to the maximum number of
8 the STA can receive in an EHT sounding NDP, spatial streams that the STA is
9 which is also the maximum total number of capable of receiving in an EHT
10 spatial streams over all the users that can be sounding NDP minus 1. The mini-
11 sent in a DL MU-MIMO transmission on an mum value of this field is 3.
12 RU/MRU that includes that STA, where the Reserved if the SU Beamformee sub-
13 RU/MRU might or might not span the entire field is 0.
14 PPDU bandwidth.
15
16 Beamformee SS For a PPDU bandwidth of 320 MHz, indicates If the SU Beamformee subfield is 1:
17 (= 320 MHz) the maximum number of spatial streams that Set to the maximum number of
18 the STA can receive in an EHT sounding NDP, spatial streams that the STA is
19 which is also the maximum total number of capable of receiving in an EHT
20 spatial streams over all the users that can be sounding NDP minus 1. The mini-
21 sent in a DL MU-MIMO transmission on an mum value of this field is 3.
22 RU/MRU that includes that STA, where the Reserved if the SU Beamformee sub-
23 RU/MRU might or might not span the entire field is 0.
24 PPDU bandwidth.
25
26 Number Of Sounding For bandwidth less than or equal to 80 MHz, it If the SU Beamformer subfield is 1:
27 Dimensions indicates the beamformer’s capability indicat- Set to the supported maximum
28 (≤ 80 MHz) ing the maximum value of the TXVECTOR TXVECTOR parameter
29 parameter NUM_STS for an EHT sounding NUM_STS value minus 1.
30 NDP. Reserved if the SU Beamformer sub-
31 field is 0.
32 Number Of Sounding For bandwidth of 160 MHz, indicates the If the SU Beamformer subfield is 1:
33 Dimensions beamformer’s capability indicating the maxi- Set to the supported maximum
34 (= 160 MHz) mum value of the TXVECTOR parameter TXVECTOR parameter
35 NUM_STS for an EHT sounding NDP. NUM_STS value minus 1.
36 Reserved if the SU Beamformer sub-
37 field is 0 or the Supported Channel
38 Width Set field does not indicate sup-
39 port for bandwidth of 160 MHz.
40
41 Number Of Sounding For bandwidth of 320 MHz, indicates the If the SU Beamformer subfield is 1:
42 Dimensions beamformer’s capability indicating the maxi- Set to the supported maximum
43 (= 320 MHz) mum value of the TXVECTOR parameter TXVECTOR parameter
44 NUM_STS for an EHT sounding NDP. NUM_STS value minus 1.
45 Reserved if the SU Beamformer sub-
46 field is 0 or the Supported Channel
47 Width Set field does not indicate sup-
48 port for bandwidth of 320 MHz.
49
50 Ng = 16 SU Feed- Indicates EHT beamformee support for a sub- Set to 0 if not supported.
51 back carrier grouping of 16 in the EHT Compressed Set to 1 if supported.
52 Beamforming Report field for SU feedback.
53
54 Ng = 16 MU Feed- Indicates EHT beamformee support for a sub- Set to 0 if not supported.
55 back carrier grouping of 16 in the EHT Compressed Set to 1 if supported.
56 Beamforming Report field for MU feedback.
57
58 Codebook Size Indicates EHT beamformee support for a Set to 0 if not supported.
59     =  4 2  SU codebook size     =  4 2  in the EHT Set to 1 if supported.
60 Feedback Compressed Beamforming Report field for SU
61 feedback.
62
63
64
65

210 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 9-401l—Subfield of the EHT PHY Capabilities Information field (continued)

2
3
4 Subfield Definition Encoding
5
6 Codebook Size Indicates EHT beamformee support for a Set to 0 if not supported.
7     =  7 5  codebook size     =  7 5  in the EHT Set to 1 if supported.
8 MU Feedback Compressed Beamforming Report field for
9 MU feedback.
10
11 Triggered SU Beam- For an AP, indicates support for the reception Set to 0 if not supported.
12 forming Feedback of partial and full bandwidth SU feedback in Set to 1 if supported.
13 an EHT TB sounding sequence.
14 For a non-AP STA, indicates support for the
15 transmission of partial and full bandwidth SU
16 feedback in an EHT TB sounding sequence.
17
18 Triggered MU Beam- For an AP, indicates support for the reception Set to 0 if not supported.
19 forming Partial BW of partial bandwidth MU feedback in an EHT Set to 1 if supported.
20 Feedback TB sounding sequence.
21 For a non-AP STA, this field is set to
22 For a non-AP STA, indicates support for the 1 if the Partial Bandwidth DL MU-
23 transmission of partial bandwidth MU feed- MIMO subfield is set to 1.
24 back in an EHT TB sounding sequence.
25 Triggered CQI Feed- For an AP, indicates support for the reception Set to 0 if not supported.
26 back of partial and full bandwidth CQI feedback in Set to 1 if supported.
27 an EHT TB sounding sequence.
28 For a non-AP STA, indicates support for the
29 transmission of partial and full bandwidth CQI
30 feedback in an EHT TB sounding sequence.
31
32 Partial Bandwidth For a non-AP STA, indicates support for the For a non-AP STA:
33 DL MU-MIMO reception of a DL MU-MIMO transmission on Set to 0 if not supported.
34 an RU/MRU in an EHT MU PPDU where the Set to 1 if supported.
35 RU/MRU does not span the entire PPDU
36 bandwidth (DL MU-MIMO within OFDMA). NOTE—A non-AP STA that sets this
37 field to 0 supports receiving a partial
38 bandwidth RU/MRU allocated to a
39 single user within an EHT MU PPDU
40 where some other RU/MRU are
41 employing DL MU-MIMO.
42 Reserved for an AP.
43
44 (#5444)EHT PSR- Indicates support for EHT PSR-based SR Set to 0 if not supported.
45 based SR Support operation. Set to 1 if supported.
46
47 Power Boost Factor (#4630)Indicates that the maximum range of (#4630)Set to 0 to indicate a range of
48 Support power boost factors that a non-AP STA sup-  1  2 2 
49 ports for the RUs in a received OFDMA EHT Set to 1 to indicate a range of [0.5, 2].
50 MU PPDU.
51 Reserved for an AP.
52
53 EHT MU PPDU Indicates support for the reception of an EHT Set to 0 if not supported.
54 With 4 EHT-LTF MU PPDU with 4 EHT-LTF and 0.8 µs Set to 1 if supported.
55 And 0.8 µs GI guard interval duration.
56
57 Max Nc Indicates the maximum supported Nc for an If the SU Beamformee subfield is 1:
58 EHT compressed beamforming/CQI report. Set to the maximum supported Nc
59 for an EHT compressed beam-
60 forming/CQI report minus 1.
61
62 The maximum value of this field is 7.
63
64 Reserved if the SU Beamformee sub-
65 field is 0.

Copyright © 2022 IEEE. All rights reserved. 211

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 9-401l—Subfield of the EHT PHY Capabilities Information field (continued)

2
3
4 Subfield Definition Encoding
5
6 Non-Triggered CQI For an AP, indicates support for the reception Set to 0 if not supported.
7 Feedback of full bandwidth non-triggered CQI feedback. Set to 1 if supported.
8 For a non-AP STA, indicates support for the
9 transmission of full bandwidth non-triggered
10 CQI feedback.
11
12 Tx 1024-QAM And For a non-AP STA, indicates support for the For a non-AP STA:
13 4096-QAM < 242- transmission of 1024-QAM and 4096-QAM Set to 0 if 1024-QAM and 4096-
14 tone RU Support on a 26-, 52-, and 106-tone RU and on a QAM are not supported.
15 52+26-tone and 106+26-tone MRU, is the Set to 1 if support of 1024-QAM
16 same as indicated in the Tx EHT-MCS Map and 4096-QAM is the same as
17 (≤ 80 MHz) subfield. indicated in the Tx EHT-MCS Map
18 (≤ 80 MHz) subfield.
19 Reserved for an AP.
20
21 Rx 1024-QAM And Indicates support for the reception of 1024- Set to 0 if 1024-QAM and 4096-QAM
22 4096-QAM < 242- QAM and 4096-QAM on a 26-, 52-, and 106- are not supported.
23 tone RU Support tone RU and on a 52+26-tone and 106+26- Set to 1 if support of 1024-QAM and
24 tone MRU, is the same as indicated in the Rx 4096-QAM is the same as indicated in
25 EHT-MCS Map (≤ 80 MHz) subfield. the Rx EHT-MCS Map (≤ 80 MHz)
26 subfield.
27 PPE Thresholds Pres- Indicates whether or not the PPE Thresholds Set to 1 if the PPE Thresholds field is
28 ent field is present. present.
29 Set to 0, otherwise
30
31 Common Nominal Indicates the common nominal packet padding Set to 0 if the common nominal packet
32 Packet Padding to be used for all constellations, N SS and RU/ padding is 0 µs for all constellations,
33 MRU allocations the STA supports if the PPE N SS and RU/MRU allocations the
34 Thresholds Present subfield is set to 0. STA supports.
35 Set to 1 if the common nominal packet
36 padding is 8 µs for all constellations,
37 N SS and RU/MRU allocations the
38 STA supports.
39 Set to 2 if the common nominal packet
40 padding is 16 µs for all constellations,
41 N SS and RU/MRU allocations the
42 STA supports.
43 Set to 3 if the common nominal packet
44 padding is 16 µs for all modes with
45 constellation ≤ 1024, N SS  8 and
46 RU/MRU ≤ 2×996, and 20 µs for all
47 other modes the STA supports
48 Reserved if the PPE Thresholds Pres-
49 ent subfield is 1.
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

212 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 9-401l—Subfield of the EHT PHY Capabilities Information field (continued)

2
3
4 Subfield Definition Encoding
5
6 Maximum Number B0 indicates support for reception of extra B0 is set to 0 if not supported.
7 Of Supported EHT- EHT-LTFs for non-OFDMA transmission in B0 is set to 1 if supported.
8 LTFs an EHT MU PPDU.
9 A B1–B2 value of 0 indicates a maxi-
10 B1–B2 indicates the maximum number of mum of four EHT-LTFs. A B1–B2
11 EHT-LTFs supported for reception within a value of 1 indicates a maximum of
12 non-OFDMA transmission to (#4851)a single eight EHT-LTFs. B1–B2 values of 2
13 user. and 3 are reserved.
14
15 (#7044)(#7045)(#7046)B3–B4 indicates the If B0 is set to 0, then B1 and B2 are
16 maximum number of EHT-LTFs supported for both reserved.
17 reception of transmissions to multiple users
18 (OFDMA and non-OFDMA). B3–B4 also A B3–B4 value of 0 indicates a maxi-
19 indicates the maximum number of EHT-LTFs mum of four EHT-LTFs. A B3–B4
20 supported for the reception of an EHT sound- value of 1 indicates a maximum of
21 ing NDP. eight EHT-LTFs. B3–B4 values of 2
22 and 3 are reserved.
23
24 If B0 is set to 0, the B3–B4 applies
25 only to OFDMA transmissions.
26
27 The maximum number of supported
28 EHT-LTFs shall be no less than the
29 value indicated in Table 36-43 (Initial
30 number of EHT-LTFs required for dif-
31 ferent number of spatial
32 streams(#4953)) based on the maxi-
33 mum number of supported spatial
34 streams, which is the highest Nss
35 value indicated by the STA in Beam-
36 formee SS subfield and Supported
37 EHT-MCS And NSS Set field over all
38 supported bandwidths and EHT-
39 MCSs.
40
41 Support Of MCS 15 B0 indicates support for MCS 15 in 52+26- Set to 0 if not supported.
42 tone and 106+26-tone MRUs. Set to 1 if supported
43
44 B1 indicates support for MCS 15 in a If 80 MHz is not supported, then B1,
45 484+242-tone MRU if 80 MHz is supported. B2, and B3 are set to 0.
46
47 B2 indicates support for MCS 15 in 996+484- If 160 MHz is not supported, then B2
48 tone MRU and 996+484+242-tone MRU if and B3 are set to 0.
49 160 MHz is supported.
50 If 320 MHz is not supported, then B3
51 (#4514)B3 indicates support for MCS 15 in a is set to 0.
52 3996-tone MRU if 320 MHz is supported.
53
54 (#4515)Support Of Indicates support for EHT DUP in 6 GHz. Set to 0 if not supported.
55 EHT DUP (MCS 14) Set to 1 if supported
56 In 6 GHz
57 Set to 0 if 6 GHz is not supported.
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 213

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 9-401l—Subfield of the EHT PHY Capabilities Information field (continued)

2
3
4 Subfield Definition Encoding
5
6 Support For 20 MHz Indicates support of a 20 MHz-operating STA Set to 0 if not supported.
7 Operating STA receiving an NDP with a PPDU bandwidth of Set to 1 if supported
8 Receiving NDP With 40, 80 or 160 MHz.
9 Wider Bandwidth
10
11 Non-OFDMA UL For an AP, indicates support for non-OFDMA For an AP STA:
12 MU-MIMO UL MU-MIMO reception of an EHT TB Set to 0 if not supported.
13 (BW ≤ 80 MHz) PPDU, for PPDU bandwidths of 20, 40, and Set to 1 if supported.
14 80 MHz (UL MU-MIMO).
15 If the maximum number of spatial
16 streams indicated for reception, for
17 any MCS, in the EHT-MCS Map
18 (BW ≤ 80 MHz, Excluding 20 MHz-
19 Only Non-AP STAs(#5872)) subfield
20 within the Supported MCS and Nss
21 Set field, is greater or equal to four,
22 then set to 1.
23
24 Reserved for a non-AP STA.
25
26 Non-OFDMA UL For an AP, indicates support for non-OFDMA For an AP STA:
27 MU-MIMO UL MU-MIMO reception of an EHT TB Set to 0 if not supported.
28 (BW = 160 MHz) PPDU, for PPDU with bandwidth of 160 MHz Set to 1 if supported.
29 (UL MU-MIMO).
30 If the maximum number of spatial
31 streams indicated for reception, for
32 any MCS, in the EHT-MCS Map
33 (BW = 160 MHz) subfield within the
34 Supported MCS and Nss Set field, is
35 greater or equal to four, then set to 1.
36
37 Reserved for a non-AP STA.
38 Non-OFDMA UL For an AP, indicates support for non-OFDMA For an AP STA:
39 MU-MIMO UL MU-MIMO reception of an EHT TB Set to 0 if not supported.
40 (BW = 320 MHz) PPDU, for PPDU with bandwidth of 320 MHz Set to 1 if supported.
41 (UL MU-MIMO).
42 If the maximum number of spatial
43 streams indicated for reception, for
44 any MCS, in the EHT-MCS Map
45 (BW = 320 MHz) subfield within the
46 Supported MCS and Nss Set field, is
47 greater or equal to four, then set to 1.
48
49 Reserved for a non-AP STA.
50
51 MU Beamformer For an AP, indicates the support for non- For an AP STA:
52 (BW ≤ 80 MHz) OFDMA DL MU-MIMO transmission and the Set to 0 if not supported.
53 required MU sounding, for PPDU bandwidths Set to 1 if supported.
54 of 20, 40, and 80 MHz.
55 If the maximum number of spatial
56 streams indicated for transmission, for
57 any MCS, in the EHT-MCS Map
58 (BW ≤ 80 MHz, Excluding 20 MHz-
59 Only Non-AP STA(#5872)) subfield
60 within the Supported MCS and Nss
61 Set field, is greater or equal to four,
62 then set to 1.
63
64 Reserved for a non-AP STA.
65

214 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 9-401l—Subfield of the EHT PHY Capabilities Information field (continued)

2
3
4 Subfield Definition Encoding
5
6 MU Beamformer For an AP, indicates the support for non- For an AP STA:
7 (BW = 160 MHz) OFDMA DL MU-MIMO transmission and the Set to 0 if not supported.
8 required MU sounding, for PPDU bandwidths Set to 1 if supported.
9 of 160 MHz.
10 If the maximum number of spatial
11 streams indicated for transmission, for
12 any MCS, in the EHT-MCS Map
13 (BW = 160 MHz) subfield within the
14 Supported MCS and Nss Set field, is
15 greater or equal to four, then set to 1.
16
17 Reserved for a non-AP STA.
18
19 MU Beamformer For an AP, indicates the support for non- For an AP STA:
20 (BW = 320 MHz) OFDMA DL MU-MIMO transmission and the Set to 0 if not supported.
21 required MU sounding, for PPDU bandwidths Set to 1 if supported.
22 of 320 MHz.
23 If the maximum number of spatial
24 streams indicated for transmission, for
25 any MCS, in the EHT-MCS Map
26 (BW = 320 MHz) subfield within the
27 Supported MCS and Nss Set field, is
28 greater or equal to four, then set to 1.
29
30 Reserved for a non-AP STA.
31
32 (#5770)TB Sound- Indicates the maximum supported data rate of For a non-AP EHT STA:
33 ing Feedback Rate the EHT TB PPDU carrying the EHT com- Set to 0 to indicate no maximum
34 Limit pressed beamforming/CQI report in the EHT supported data rate limitation. The
35 TB sounding sequence. same EHT-MCS and Nss are sup-
36 ported as indicated in the Sup-
37 ported EHT-MCS and NSS Set
38 field.
39 Set to 1 to indicate the maximum
40 supported data rate is the lower of
41 the 1500 Mb/s and the maximum
42 supported data rate computed
43 based on the Supported EHT-MCS
44 and NSS Set field.
45
46 Reserved for an AP EHT STA.
47 Rx 1024-QAM In Indicates support for the reception of 1024- Set to 0 if 1024-QAM is not supported
48 Wider Bandwidth DL QAM in an EHT DL OFDMA with PPDU regardless the indication in the Rx
49 OFDMA Support bandwidth wider than the operating bandwidth EHT-MCS Map subfield.
50 of the non-AP STA.
51 Set to 1 if support of 1024-QAM is
52 the same as that indicated in the EHT-
53 MCS Map (20 MHz-Only Non-AP
54 STA) for a 20 MHz-only non-AP
55 STA, the EHT-MCS Map
56 (BW ≤ 80 MHz, Except 20 MHz-
57 Only Non-AP STA) for a 20 MHz or
58 80 MHz operating non-AP STA, and
59 the EHT-MCS Map (BW = 160 MHz)
60 for a 160 MHz operating non-AP
61 STA.
62
63 Reserved for an AP.
64
65

Copyright © 2022 IEEE. All rights reserved. 215

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 9-401l—Subfield of the EHT PHY Capabilities Information field (continued)

2
3
4 Subfield Definition Encoding
5
6 Rx 4096-QAM In Indicates support for the reception of 4096- Set to 0 if 4096-QAM is not supported
7 Wider Bandwidth DL QAM in an EHT DL OFDMA with PPDU regardless the indication in the Rx
8 OFDMA Support bandwidth wider than the operating bandwidth EHT-MCS Map subfield.
9 of the non-AP STA.
10 Set to 1 if support of 4096-QAM is
11 the same as that indicated in the EHT-
12 MCS Map (20 MHz-Only Non-AP
13 STA) for a 20 MHz-only non-AP
14 STA, the EHT-MCS Map
15 (BW ≤ 80 MHz, Except 20 MHz-
16 Only Non-AP STA) for a 20 MHz or
17 80 MHz operating non-AP STA, and
18 the EHT-MCS Map (BW = 160 MHz)
19 for a 160 MHz operating non-AP
20 STA.
21
22 Reserved for an AP.
23
24
25
26 9.4.2.313.4 Supported EHT-MCS And NSS Set field(#1126)
27
28 The Supported EHT-MCS And NSS Set field indicates the combinations of EHT-MCS 0–13, and number of
29
spatial streams NSS, that a STA supports for reception and the combinations that it supports for transmission.
30
31 The format of the field is shown in Figure 9-1002ah (Supported EHT-MCS And NSS Set field for-
32 mat(#4970)). EHT-MCS 14 and 15 can only be combined with a single stream, and are indicated in
33 9.4.2.313.1 (General(#1126)) EHT PHY Capabilities Information field(#8172).
34
35
36 EHT-MCS Map
EHT-MCS Map
37 (BW ≤ 80 MHz, Except EHT-MCS Map EHT-MCS Map
(20 MHz-Only Non-AP
20 MHz-Only Non-AP (BW = 160 MHz) (BW = 320 MHz)
38 STA)(#5872)
STA)(#5872)
39
40 Octets: 0 or 4 0 or 3 0 or 3 0 or 3
41
42
Figure 9-1002ah—Supported EHT-MCS And NSS Set field format(#4970)
43
44
45 The subfields of the Supported EHT-MCS And NSS Set field, and their presence, are defined in Table 9-
46
47 401m (Subfields of the Supported EHT-MCS And NSS Set field(#4972)(#4516)).
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

216 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 9-401m—Subfields of the Supported EHT-MCS And NSS Set field(#4972)(#4516)

2
3
4 Subfield Definition Encoding
5
6 EHT-MCS Map For a 20 MHz-only non-AP The format and encoding of this subfield
7 (20 MHz-Only Non-AP STA(#5872), indicates the maximum are defined in (#7048)Figure 9-1002ai
8 STA)(#5872) number of spatial streams supported (EHT-MCS Map (20 MHz-Only Non-AP
for reception and the maximum num- STA) subfield and Basic EHT-MCS and
9 ber of spatial streams that the STA can NSS Set field format(#5872)) and the asso-
10 transmit, for each MCS value in a ciated description.
11 PPDU with a bandwidth of 20 MHz,
12 40 MHz, 80 MHz, (#6930)160 MHz (#6930)In 5 GHz and 6 GHz, if B1, B2, and
13 or 320 MHz with the following addi- B3 of the Supported Channel Width Set
14 tional restrictions: field in the HE PHY Capabilities Informa-
15 — Support for the reception of tion field are all 0, then this field is present;
16 1024-QAM in a 40 MHz, otherwise, it is not present.
17 80 MHz, (#6930)160 MHz or
320 MHz EHT DL OFDMA is In 2.4 GHz, if B0 of the Supported Channel
18 Width Set field in the HE PHY Capabilities
19 indicated jointly with the Rx
Information field is 0, then this field is pres-
20 1024-QAM In Wider Band- ent; otherwise, it is not present.
21 width DL OFDMA Support
22 subfield.
23 — Support for the reception of
24 4096-QAM in a 40 MHz,
25 80 MHz, (#6930)160 MHz or
26 320 MHz EHT DL OFDMA is
27 indicated jointly with the RX
28 4096-QAM In Wider Band-
29 width DL OFDMA Support
30 subfield.
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 217

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 9-401m—Subfields of the Supported EHT-MCS And NSS Set field(#4972)(#4516)

2
3
4 Subfield Definition Encoding
5
6 EHT-MCS Map Except for a 20 MHz-only non-AP The format and encoding of this subfield
7 (BW ≤ 80 MHz, Except STA(#5872), indicates the maximum are defined in (#7049)Figure 9-1002aj
8 20 MHz-Only Non-AP number of spatial streams supported (EHT-MCS Map (BW ≤ 80 MHz, Except
9 STA(#5872)) for reception and the maximum num- 20 MHz-Only Non-AP STA), EHT-MCS
10 ber of spatial streams that the STA can Map (BW = 160 MHz), and EHT-MCS
11 transmit, for each MCS value, in a Map (BW = 320 MHz) subfield for-
12 PPDU with a bandwidth of 20 MHz, mat(#5872)) and the associated description.
13 40 MHz, or 80 MHz with the follow-
14 ing additional restrictions: In 5 GHz or 6 GHz, if B1 of the Supported
15 — Support for the transmission of Channel Width Set field in the HE PHY
16 1024-QAM and 4096-QAM on Capabilities Information field is 1, then this
17 a 26-, 52-, and 106-tone RU and field is present; otherwise, it is not present.
18 on a 52+26-tone and 106+26-
19 tone MRU is indicated jointly In 2.4 GHz, if B0 of the Supported Channel
20 with the Tx 1024-QAM And Width Set field in the HE PHY Capabilities
21 4096-QAM < 242-tone RU sup- Information field is 1, then this field is pres-
22 port subfield. ent; otherwise it is not present.
23 — Support for the reception of
24 1024-QAM and 4096-QAM on
25 a 26-, 52-, and 106-tone RU and
26 on a 52+26-tone and 106+26-
27 tone MRU is indicated jointly
28 with the Rx 1024-QAM And
29 4096-QAM < 242-tone RU sup-
30 port subfield.
31
32 For a 20 MHz or 80 MHz operating
33 non-AP STA, additionally indicates
34 the maximum number of spatial
35 streams supported for reception and
36 the maximum number of spatial
37 streams that the non-AP STA can
38 transmit, for each MCS value, in a
39 PPDU with a bandwidth of 160 MHz
40 or 320 MHz with the following addi-
41 tional restrictions:
42 — Support for the reception of
43 1024-QAM in a 160 MHz, or
44 320 MHz EHT DL OFDMA is
45 indicated jointly with the Rx
46 1024-QAM In Wider Bandwidth
47 DL OFDMA Support subfield.
48 — Support for the reception of
49 4096-QAM in a 160 MHz, or
50 320 MHz EHT DL OFDMA is
51 indicated jointly with the Rx
52 4096-QAM In Wider Bandwidth
53 DL OFDMA Support subfield.
54
55
56
57
58
59
60
61
62
63
64
65

218 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 9-401m—Subfields of the Supported EHT-MCS And NSS Set field(#4972)(#4516)

2
3
4 Subfield Definition Encoding
5
6 EHT-MCS Map If the operating channel width of the The format and encoding of this subfield
7 (BW = 160 MHz) STA is greater than or equal to are defined in (#7050)Figure 9-1002aj
8 160 MHz, indicates the maximum (EHT-MCS Map (BW ≤ 80 MHz, Except
9 number of spatial streams supported 20 MHz-Only Non-AP STA), EHT-MCS
10 for reception and the maximum num- Map (BW = 160 MHz), and EHT-MCS
11 ber of spatial streams that the STA can Map (BW = 320 MHz) subfield for-
12 transmit, for each MCS value, in a mat(#5872)) and the associated description.
13 PPDU with a bandwidth of 160 MHz.
14 If B2 of the Supported Channel Width Set
15 For a 160 MHz operating non-AP field in the HE PHY Capabilities Informa-
16 STA, additionally indicates the maxi- tion field is 1, then this field is present; oth-
17 mum number of spatial streams sup- erwise, it is not present.
18 ported for reception and the maximum
19 number of spatial streams that the
20 non-AP STA can transmit, for each
21 MCS value, in a PPDU with a band-
22 width of 320 MHz with the following
23 additional restrictions:
24 — Support for the reception of
25 1024-QAM in a 320 MHz EHT
26 DL OFDMA is indicated jointly
27 with the Rx 1024-QAM In
28 Wider Bandwidth DL OFDMA
29 Support subfield.
30 — Support for the reception of
31 4096-QAM in a 320 MHz EHT
32 DL OFDMA is indicated jointly
33 with the Rx 4096-QAM In
34 Wider Bandwidth DL OFDMA
35 Support subfield.
36 EHT-MCS Map If the operating channel width of the The format and encoding of this subfield
37 (BW = 320 MHz) STA is 320 MHz, indicates the maxi- are defined in (#7051)Figure 9-1002aj
38 mum number of spatial streams sup- (EHT-MCS Map (BW ≤ 80 MHz, Except
39 ported for reception and the maximum 20 MHz-Only Non-AP STA), EHT-MCS
40 number of spatial streams that the Map (BW = 160 MHz), and EHT-MCS
41 STA can transmit, for each MCS Map (BW = 320 MHz) subfield for-
42 value, in a PPDU with a bandwidth of mat(#5872)) and the associated description.
43 320 MHz.
44 If the Support For 320 MHz In 6 GHz sub-
45 field, in the EHT PHY Capabilities Infor-
46 mation field is 1, then this field is present;
47 otherwise, it is not present.
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 219

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The EHT-MCS Map (20 MHz-Only Non-AP STA(#5872)) subfield and the Basic EHT-MCS And NSS Set
2 field have the format shown in Figure 9-1002ai (EHT-MCS Map (20 MHz-Only Non-AP STA) subfield and
3
Basic EHT-MCS and NSS Set field format(#5872)).
4
5
6 B0 B3 B4 B7 B8 B11 B12 B15
7
8 Rx Max Nss Tx Max Nss Rx Max Nss Tx Max Nss
9 That Supports That Supports That Supports That Supports
10 EHT-MCS 0–7 EHT-MCS 0–7 EHT-MCS 8–9 EHT-MCS 8–9
11
12 Bits: 4 4 4 4
13
14 B16 B19 B20 B23 B24 B27 B28 B31
15
Rx Max Nss Tx Max Nss Rx Max Nss Tx Max Nss
16 That Supports That Supports That Supports That Supports
17 EHT-MCS 10–11 EHT-MCS 10–11 EHT-MCS 12–13 EHT-MCS 12–13
18
19 Bits: 4 4 4 4
20
21 Figure 9-1002ai—EHT-MCS Map (20 MHz-Only Non-AP STA) subfield and Basic EHT-MCS
22
and NSS Set field format(#5872)
23
24
25
26
The EHT-MCS Map (BW ≤ 80 MHz, Except 20 MHz-Only Non-AP STA(#5872)), EHT-MCS Map
27 (BW = 160 MHz), and EHT-MCS Map (BW = 320 MHz) subfields have the format shown in Figure 9-
28 1002aj (EHT-MCS Map (BW ≤ 80 MHz, Except 20 MHz-Only Non-AP STA), EHT-MCS Map
29 (BW = 160 MHz), and EHT-MCS Map (BW = 320 MHz) subfield format(#5872)).
30
31
32 B0 B3 B4 B7 B8 B11 B12 B15 B16 B19 B20 B23
33
34 Rx Max Nss Tx Max Nss Rx Max Nss Tx Max Nss Rx Max Nss Tx Max Nss
That Supports That Supports That Supports That Supports That Supports That Supports
35 EHT-MCS 0–9 EHT-MCS 0–9 EHT-MCS 10–11 EHT-MCS 10–11 EHT-MCS 12–13 EHT-MCS 12–13
36
37 Bits: 4 4 4 4 4 4
38
39 Figure 9-1002aj—EHT-MCS Map (BW ≤ 80 MHz, Except 20 MHz-Only Non-AP STA), EHT-
40
41 MCS Map (BW = 160 MHz), and EHT-MCS Map (BW = 320 MHz) subfield format(#5872)
42
43
44 The Rx Max Nss That Supports EHT-MCS 0–7 and Tx Max Nss That Supports EHT-MCS 0–7 subfields are
45 encoded according to Table 9-401n (Encoding of the maximum number of Nss for a specified MCS value).
46
47
48 The Rx Max Nss That Supports EHT-MCS 0–9 and Tx Max Nss That Supports EHT-MCS 0–9 subfields are
49 encoded according to Table 9-401n (Encoding of the maximum number of Nss for a specified MCS value).
50
51
52
The Rx Max Nss That Supports EHT-MCS 10–11 and Tx Max Nss That Supports EHT-MCS 10–11 sub-
53 fields are encoded according to Table 9-401n (Encoding of the maximum number of Nss for a specified
54 MCS value).
55
56
57
58
59
60
61
62
63
64
65

220 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The Rx Max Nss That Supports EHT-MCS 12–13 and Tx Max Nss That Supports EHT-MCS 12–13 sub-
2 fields are encoded according to Table 9-401n (Encoding of the maximum number of Nss for a specified
3
MCS value).
4
5
6
7 Table 9-401n—Encoding of the maximum number of Nss for a specified MCS value
8
9
10 Maximum number of spatial
11 Max Nss subfield value streams that supports
12 the specified MCS set
13
14 0 Not supported
15 1 1
16
17 2 2
18
3 3
19
20 4 4
21
22 5 5
23
6 6
24
25 7 7
26
27 8 8
28 9–15(#4269) Reserved
29
30
31
32
33 A value that is reserved in Table 9-401n (Encoding of the maximum number of Nss for a specified MCS
34 value) indicates a maximum Nss of greater than eight spatial streams.
35
36
37 The maximum receive Nss for a given EHT-MCS is equal to the smaller of:
38
39 — The value of the Rx Max Nss That Supports Specified MCS subfield for the given EHT-MCS
40
41 — The maximum supported Nss as indicated by the value of the Rx NSS field of the Operating Mode
42 Notification frame (#5785)or the Operating Mode Notification element if the value of Rx NSS Type
43 is 0, or by the value of the Rx NSS field of the OM Control subfield(#5536) if EHT OM Control sub-
44 field is not present in the same A-Control field, or by the value of the Rx NSS Extension field of the
45
46 EHT OM Control subfield combined with the value of the Rx NSS field of the OM Control subfield
47
48
49
The maximum transmit Nss for a given EHT-MCS is equal to the smaller of:
50
51 — The value of the Tx Max Nss That Supports Specified MCS subfield for the given EHT-MCS
52
53 — The maximum supported Nss(#5712) as indicated by the value of the (#5536)Tx NSTS field of the
54 OM Control subfield sent by a non-AP STA (#5536)or by the value of the Tx NSTS Extension field
55 of the EHT OM Control subfield combined with the value of the Tx NSTS field of the OM Control
56 subfield sent by a non-AP STA
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 221

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 9.4.2.313.5 EHT PPE Thresholds field

2
3
4 The EHT PPE Thresholds field determines the nominal packet padding value (see 35.14 (Nominal packet
5 padding values selection rules)) (#7736)for a particular RU/MRU allocation and particular NSS in an EHT
6 PPDU. The format of the EHT PPE Thresholds field is defined in Figure 9-1002ak (EHT PPE Thresholds
7 field format(#7736)).
8
9
10 B0 B3 B4 B8
11
12 PPE
13 NSS_PE RU Index Thresholds PPE Pad
Bitmask
14 Info
15
16 Bits: 4 5 variable 0 or 7
17
18 Figure 9-1002ak—EHT PPE Thresholds field format(#7736)
19
20
21 (#7736)The NSS_PE subfield contains an unsigned integer NSS_PE that is used to indicate the scope of
22 NSSn for the PPETmax NSSn RUb subfields and PPET8 NSSn RUb subfields in the PPE Thresholds Info
23 field  1  n   NSS_PE + 1   . The scope of RUb for the PPETmax NSSn RUb subfields and PPET8 NSSn
24
RUb subfields in the PPE Thresholds Info field is given by the RU Index Bitmask subfield(#8173).
25
26
27 (#7736)The RU Index Bitmask subfield contains a bitmask that indicates whether the PPE Thresholds Info
28 field contains PPETmax and PPET8 subfields for the five possible RU allocation indices indicated in
29
(#7054)Table 9-401p (RU allocation index). The PPETmax and PPET8 subfields for RU allocation index k
30
31 are present in the PPE Thresholds Info field only if bit k of the RU Index Bitmask subfield (bit 4 + k of the
32 EHT PPE Thresholds field) is 1. For example, if B0 of the RU Index Bitmask subfield (B4 of the EHT PPE
33 Thresholds field) is 1, the PPETmax and PPET8 subfields are present in the PPE Thresholds Info field for
34 the RU allocation size corresponding to the RU allocation index 0 (242-tone RU). If B0 of the RU Index Bit-
35
mask subfield is 0, the PPETmax and PPET8 subfields are not present in the PPE Thresholds Info field for
36
37 the RU allocation size corresponding to the RU allocation index 0. The RU Index Bitmask subfield shall
38 contain at least one bit equal to 1. To indicate nominal packet padding values of 0 µs for all modes, the PPE
39 Thresholds Present subfield and the Common Nominal Packet Padding subfield shall be set to 0 in the EHT
40 Capabilities element (see 35.14 (Nominal packet padding values selection rules) for details). If there exists
41
one or more 0s after the first 1 in the bitmask sequence in the RU Index Bitmask subfield, the PPETmax and
42
43 PPET8 subfields for each RU allocation index corresponding to these 0s are not present, while the PPETmax
44 and PPET8 values of that RU allocation index shall be the same as the PPETmax and PPET8 values of the
45 closest smaller RU allocation index with the bitmask value equal to 1 in the RU Index Bitmask subfield.
46
47
48 (#7736)The PPE Thresholds Info field contains 6   NSS_PE + 1  bits, where NSS_PE is the value in the
49 NSS_PE field, for every bit in the RU Index Bitmask subfield that is nonzero. The format of the PPE
50 Thresholds Info field is defined in Figure 9-1002al (PPE Thresholds Info field format(#7736)).
51
52
53 B0 B2 B3 B5
54
55 PPETmax PPET8 PPETmax PPET8 PPETmax PPET8
56 … … NSS(NSS_PE+1) NSS(NSS_PE+1)
NSS1 RUy NSS1 RUy NSS1 RUm NSS1 RUm RUm RUm
57
58
59 Bits: 3 3 3 3 3 3
60
61 Figure 9-1002al—PPE Thresholds Info field format(#7736)
62
63
64 (#7736)The PPETmax and PPET8 subfields for various NSS and RU allocation index values appear in
65 increasing NSS value and increasing RU allocation index value order. Lower numbered PPE Thresholds

222 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Info field bits contain PPETmax and PPET8 subfields corresponding to lower numbered NSS values. Within
2 a set of PPETmax and PPET8 subfields corresponding to a single value of NSS, lower numbered PPE
3
Thresholds Info field bits contain PPETmax and PPET8 subfields corresponding to lower numbered RU
4
5 index values. The PPETmax NSSn RUb and PPET8 NSSn RUb subfields are present for all values of n and
6 b where 1  n   NSS_PE + 1  and where b belongs to the set of RU allocation indices  y  m  equal to
7 the ordered list of bit positions of all bits that are set to 1 in the RU Index Bitmask subfield, with y being the
8 lowest value.
9
10
11 (#7736)Each PPETmax NSSn RUb and PPET8 NSSn RUb subfield contains an integer as defined in
12 Figure 9-401o (Constellation index), which is used to compute the nominal packet padding value (see
13
Table 35-5 (PPE thresholds per PPET8 and PPETmax(#7736))).
14
15
16
17 Table 9-401o—Constellation index
18
19
20 Corresponding transmission
Constellation index
21 constellation
22
23 0 BPSK
24 1 QPSK
25
26 2 16-QAM
27
3 64-QAM
28
29 4 256-QAM
30
31 5 1024-QAM
32
6 4096-QAM
33
34 7 None
35
36
37
38 (#7736)The value of the PPET8 NSSn RUb subfield is always less than the value of the PPETmax NSSn
39
40
RUb subfield, except if the PPET8 subfield is 7.
41
42 The RU allocation index for each RU allocation size is defined in (#7054)Table 9-401p (RU allocation
43
44 index). For RU allocation index 2, 3, and 4, more than one RU/MRU shares the same RU allocation index.
45 The RU allocation index for the 80 MHz PPDU using EHT-MCS 14 is equal to 2.
46
47
48 Table 9-401p—RU allocation index
49
50
51 RU allocation index RU allocation size
52
53 0 242
54
1 484
55
56 2 484+242, 996
57
58 3 996+484, 996+484+242, 2996
59 4 2996+484, 3996, 3996+484, 4996
60
61
62
63
64 The PPE Pad field contains all 0s. The number of bits in the PPE Pad field is the least number of bits
65 required to round the length of the PPE Thresholds Info field to an integer number of octets.

Copyright © 2022 IEEE. All rights reserved. 223

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 9.4.2.314 TID-To-Link Mapping element

2
3
4 The TID-To-Link Mapping element indicates links on which frames belonging to each TID can be
5 exchanged. The format of the TID-To-Link Mapping element is shown in Figure 9-1002am (TID-To-Link
6
7 Mapping element format(#7707)).
8
9
Element ID TID-To-Link Link Mapping Link Mapping
10 Element ID Length Mapping Of TID 0 … Of TID 7
11 Extension Control (Optional) (Optional)
12
13 Octets: 1 1 1 1 or 2 0 or 2 0 or 2
14
15 Figure 9-1002am—TID-To-Link Mapping element format(#7707)
16
17
18
19
The Element ID, Length, and Element ID Extension fields are defined in 9.4.2.1 (General).
20
21
22
The format of the TID-To-Link Mapping Control field is defined in Figure 9-1002an (TID-To-Link Control
23 field format(#7707)).
24
25
26 B0 B1 B2 B3 B7 B8 B15
27
28 Link Mapping
Default Link
Direction Reserved Presence Indicator
29 Mapping
(Optional)
30
31
Bits: 2 1 5 0 or 8
32
33
Figure 9-1002an—TID-To-Link Control field format(#7707)
34
35
36
37 The Direction subfield is set to 0(#4021) if the TID-To-link Mapping element provides the TID-to-link map-
38 ping information for frames transmitted on the downlink. It is set to 1(#4021) if the TID-To-Link Mapping
39 element provides the TID-to-link mapping information for frames transmitted on the uplink. It is set to
40
41 2(#4021) if the TID-To-Link Mapping element provides the TID-to-link mapping information for frames
42 transmitted both on the downlink and the uplink. The value of 3 is reserved.
43
44
45 The Default Link Mapping subfield is set to 1 if the TID-To-Link Mapping element represents the default
46 TID-to-link mapping. Otherwise, it is set to 0.
47
48
49 The Link Mapping Presence Indicator subfield indicates whether the Link Mapping Of TID n field is present
50 in the TID-To-Link Mapping element (#4023)(i.e., it identifies the TID(s) for which the mapping is pro-
51
52 vided in the element). A value of 1 in bit position n of the Link Mapping Presence Indicator subfield indi-
53 cates that the Link Mapping Of TID n field is present in the TID-To-Link Mapping element. Otherwise, the
54 Link Mapping Of TID n field is not present in the TID-To-Link Mapping element. When the Default Link
55
56
Mapping subfield is set to 1, this subfield is (#7707)not present.
57
58
59
The Link Mapping Of TID n field (where n = 0 1  7 ) indicates the link(s) on which frames belonging
60 to the TID n are allowed to (#4024)be sent (i.e., carries a bitmap of the links to which the TID n is mapped
61 to). A value of 1 in bit position i (#6668)(where i = 0 1  14 ) of the Link Mapping Of TID n field indi-
62 cates that TID n is mapped to the link associated with the link ID i for the direction as specified in the Direc-
63
64 tion subfield. (#5134)A value of 0 in bit position i indicates that the TID n is not mapped to the link
65 associated with the link ID i. When the Default Link Mapping subfield is set to 1, this field is not present.

224 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 9.4.2.315 Multi-Link Traffic Indication element(#4107)(#2341)

2
3
4 The (#4107)Multi-Link Traffic Indication element contains a list of per-link traffic indication bitmap(s) for
5 non-AP MLD(s).
6
7 The (#4107)Multi-Link Traffic Indication element is defined in Figure 9-1002ao (Multi-Link Traffic Indica-
8
9 tion element format(#4107)).
10
11 Multi-Link Traffic
12 Element ID Per-Link Traffic
Element ID Length Indication
13 Extension Control Indication List
14
15 Octets: 1 1 1 2 variable
16
17 Figure 9-1002ao—Multi-Link Traffic Indication element format(#4107)
18
19
20 The Element ID, Length, and Element ID Extension fields are defined in 9.4.2.1 (General).
21
22
23 The (#4107)Multi-Link Traffic Indication Control field is defined in Figure 9-1002ap (Multi-Link Traffic
24 Indication Control field format(#4107)).
25
26
27 B0 B3 B4 B14 B15
28
29 Bitmap Size AID Offset Reserved
30
31 Bits: 4 11 1
32
33 Figure 9-1002ap—Multi-Link Traffic Indication Control field format(#4107)
34
35
36 The Bitmap Size subfield indicates the size of each Per-Link Traffic Indication Bitmap subfield, in bits. The
37 subfield is encoded to m, where  m + 1  is the size of the Per-Link Traffic Indication Bitmap subfield. A
38 value of 0 in the Bitmap Size subfield is reserved.
39
40
41 The AID Offset subfield indicates a bit numbered k of the traffic indication virtual bitmap.
42
43 The Per-Link Traffic Indication List field is defined in Figure 9-1002aq (Per-Link Traffic Indication List
44
field format(#6373)). The Per-Link Traffic Indication List field contains Per-Link Traffic Indication Bitmap
45
46 subfields that correspond to the AIDs of the non-AP MLDs (#5136)and STAs starting from the bit numbered
47 k of the traffic indication virtual bitmap. The Per-Link Traffic Indication List field contains l Per-Link Traf-
48 fic Indication Bitmap subfields, where l is the number of the bits that correspond to the AIDs of the non-AP
49 MLDs (#5137)and STAs (#4350)and set to 1, counting from the bit numbered k of the traffic indication vir-
50
tual bitmap, in the Partial Virtual Bitmap subfield of the TIM element that is included in a Beacon frame
51
52 with the (#4107)Multi-Link Traffic Indication element.
53
54
Per-Link Traffic Per-Link Traffic
55 Indication Bitmap 1
…
Indication Bitmap l
Padding
56
57 Bits: m+1 m+1 variable (0–7)
58
59
Figure 9-1002aq—Per-Link Traffic Indication List field format(#6373)
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 225

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The Per-Link Traffic Indication Bitmap subfield is defined in Figure 9-1002ar (Per-Link Traffic Indication
2 Bitmap subfield format). Each Per-Link Traffic Indication Bitmap subfield indicates per-link traffic indica-
3
tions for a non-AP MLD that has negotiated a (#8174)TID-to-link mapping with an AP MLD (#8264)and
4
5 not all TIDs are mapped to all the enabled links or link recommendation for a non-AP MLD (#8264)that has
6 negotiated a TID-to-link mapping with an AP MLD and all TIDs are mapped to all the enabled links or link
7 recommendation for a non-AP MLD that is in the default mapping mode. (#8176)When a Per-Link Traffic
8 Indication Bitmap subfield corresponds to an AID of a STA that is not affiliated with a non-AP MLD, the
9
Per-Link Traffic Indication Bitmap subfield is reserved.
10
11
12 B0 Bm
13
14 Per-Link Traffic
15 Indication Bitmap
16
17 Bits: m+1
18
19 Figure 9-1002ar—Per-Link Traffic Indication Bitmap subfield format
20
21
22
(#8175)Each bit in the Per-Link Traffic Indication Bitmap subfield corresponds to a link and the bit position
23
24 i of the bitmap, Bi, corresponds to a link with link ID equal to i. When the Per-Link Traffic Indication Bit-
25 map subfield corresponds to a non-AP MLD that has successfully negotiated TID-to-link mapping, a value
26 of 1 in the bit position i in the bitmap (#8175)that corresponds to a link on which a STA affiliated with a
27 non-AP MLD is operating indicates that there is buffered BU(s) with TID(s) mapped to the link with the link
28
ID equal to i or MMPDU(s); a value of 0 in a bit position in the bitmap indicates that there is no buffered
29
30 BU(s) with TID(s) mapped to the corresponding link nor MMPDU(s). When the Per-Link Traffic Indication
31 Bitmap subfield corresponds to a non-AP MLD that is in the default mapping mode, a value of 1 in the bit
32 position i in the bitmap indicates that the link with the link ID equal to i is recommended for retrieving buff-
33 ered BU(s).
34
35
36 The Padding subfield contains 0–7 padding bits so that the length of the Per-Link Traffic Indication List
37 field is a multiple of 8 bits. The padding bits are set to 0.
38
39
40 9.4.2.316 QoS Characteristics element(#4918)
41
42
43 The QoS Characteristics element contains a set of parameters that define the characteristics and QoS expec-
44 tations of a traffic flow, in the context of a particular non-AP EHT STA, for use by the EHT AP and the non-
45 AP EHT STA in support of QoS traffic transfer using the procedures defined in 11.25.2 (SCS procedures)
46
and 35.9 (Restricted TWT (r-TWT)).
47
48
49 The element information format comprises the items as defined in this subclause, and the structure is defined
50
in Figure 9-1002as (QoS Characteristics element format(#4918)).
51
52
53 Element Minimum Maximum
54 Element Control Minimum Delay
ID Length ID Info Service Service Data Rate Bound
55 Extension Interval Interval
56
57 Octets: 1 1 1 4 4 4 3 3
58
59 Maximum MSDU MSDU
Service Mean MSDU Medium
60 MSDU
Start Time Data Rate
Burst Size
Lifetime
Delivery Count
Time
61 Size Ratio Exponent
62
63 Octets: 0 or 2 0 or 4 0 or 3 0 or 4 0 or 2 0 or 1 0 or 1 0 or 1
64
65 Figure 9-1002as—QoS Characteristics element format(#4918)

226 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2
3
4
The structure of the Control Info field is defined in Figure 9-1002at (Control Info field format(#4918)).
5
6 B0 B1 B2 B5 B6 B8 B9 B24 B25 B28 B29 B31
7
8
Presence Bitmap
9 Direction TID User Priority Of Additional LinkID Reserved
10 Parameters
11
12 Bits: 2 4 3 16 4 3
13
14 Figure 9-1002at—Control Info field format(#4918)
15
16
17 The Element ID, Length, and Extended Element ID fields are defined in 9.4.2.1 (General).
18
19
The subfields of the Control Info field are defined as follows:
20
21 — The Direction subfield specifies the direction of data described by this element as defined in Table 9-
22 401q (Direction subfield encoding(#4918)).
23
24
25
26 Table 9-401q—Direction subfield encoding(#4918)
27
28
Bit 5 Bit 6 Usage
29
30 0 0 Uplink, defined as follows:
31
— MSDUs or A-MSDUs are sent from the non-AP STA to the AP.
32
33 0 1 Downlink, defined as follows:
34 — MSDUs or A-MSDUs are sent from the AP to the non-AP STA.
35
36 1 0 Direct link (MSDUs or A-MSDUs are sent from the non-AP STA to
37 another non-AP STA).
38
39 1 1 Reserved
40
41
42
43 — The TID subfield contains the TID value of the data frames that are described by this element. The
44 TID subfield is set to the same value as the User Priority field. The values 8–15 are reserved.
45 — The User Priority subfield contains the user priority value (0–7) of the data frames that are described
46
47
by this element. When the TCLAS element is present in the SCS Request frame containing this ele-
48 ment, the User Priority subfield is set to the user priority value specified in the TCLAS element.
49 — The Presence Bitmap Of Additional Parameters subfield contains a bitmap where the i-th entry of the
50
bitmap is set to 1 if the i-th field starting from the Maximum MSDU Size field is present in this ele-
51
52 ment. For each field starting from the Maximum MSDU Size field, the value 0 is reserved.
53 — The LinkID subfield contains the link identifier of the link for which the direct link transmissions are
54
going to occur. This field is reserved if the Direction subfield is equal to any value but 2 (Direct
55
56 link).
57
58 The Minimum Service Interval field contains the following:
59
60 — If the Direction subfield is set to 0 (Uplink), the Minimum Service Interval field contains an
61 unsigned integer that specifies the minimum interval, in microseconds, between the start of two con-
62 secutive SPs that are allocated to the STA for UL frame exchanges and the value 0 is reserved.
63
64 — If the Direction subfield is set to 1 (Downlink), the Minimum Service Interval field contains an
65 unsigned integer that specifies the minimum interval, in microseconds, between the start of two con-

Copyright © 2022 IEEE. All rights reserved. 227

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 secutive SPs that are allocated for DL frame exchange sequences and the value 0 indicates that this
2 parameter is unspecified.
3
4 — If the Direction subfield is set to 2 (Direct link) the Minimum Service Interval field contains an
5 unsigned integer that specifies the minimum interval, in microseconds, between the start of two con-
6 secutive SPs that are allocated to the STA for direct link frame exchanges and the value 0 is reserved.
7
8
9 The Maximum Service Interval field contains the following:
10 — If the Direction subfield is set to 0 (Uplink), the Maximum Service Interval field contains an
11
unsigned integer that specifies the maximum interval, in microseconds, between the start of two con-
12
13 secutive SPs that are allocated to the STA for UL frame exchanges and the value 0 is reserved.
14 — If the Direction subfield is set to 1 (Downlink), the Maximum Service Interval field contains an
15 unsigned integer that specifies the maximum interval, in microseconds, between the start of two con-
16
17 secutive SPs that are allocated for DL frame exchange sequences and the value 0 indicates that this
18 parameter is unspecified.
19 — If the Direction subfield is set to 2 (Direct link) the Maximum Service Interval field contains an
20
21 unsigned integer that specifies the maximum interval, in microseconds, between the start of two con-
22 secutive SPs that are allocated to the STA for direct link frame exchanges and the value 0 is reserved.
23 — The value of this field is greater than or equal to the value of the Minimum Service Interval field.
24
25
26 The Minimum Data Rate field contains an unsigned integer that specifies the lowest data rate specified at the
27 MAC SAP, in kilobits per second, for transport of MSDUs or A-MSDUs belonging to the traffic flow
28 described by this element.
29
30 — If the Direction subfield is set to 0 (Uplink) or 1 (Downlink), the value 0 is reserved.
31 — If the Direction subfield is set to 2 (Direct link), the value 0 indicates that this parameter is unspeci-
32
33 fied.
34
35 The Delay Bound field contains an unsigned integer that specifies the maximum amount of time, in micro-
36 seconds, allowed to transport an MSDU or A-MSDU belonging to the traffic flow described by this element,
37
measured between the time marking the arrival of the MSDU, or the first MSDU of the MSDUs constituting
38
39 an A-MSDU, at the local MAC sublayer from the local MAC SAP and the time of completion of the suc-
40 cessful transmission or retransmission of the MSDU or A-MSDU to the destination. The completion time of
41 the MSDU or A-MSDU transmission includes the relevant acknowledgment frame transmission time, if
42 present.
43
44 — If the Direction subfield is set to 0 (Uplink) or 2 (Direct link), the value 0 indicates that this parame-
45 ter is unspecified.
46
47 — If the Direction subfield is set to 1 (Downlink), the value 0 is reserved.
48
49 The Maximum MSDU Size field contains an unsigned integer that specifies the maximum size, in octets, of
50 MSDUs or A MSDUs belonging to the traffic flow described by this element.
51
52
53 The Service Start Time field contains an unsigned integer that specifies the time, in microseconds, when the
54 first SP starts. The Service Start Time indicates to the AP the time when the STA expects to exchange
55 frames corresponding to the TID specified in this element. The field represents the four lower order octets of
56 the TSF timer at the start of the SP.
57
58
59 The Mean Data Rate field indicates the average data rate specified at the MAC SAP, in kilobits per second,
60 for transport of MSDUs or A-MSDUs belonging to the traffic flow within the bounds of this element.
61
62
The Burst Size field is 4 octets long and contains an unsigned integer that specifies the maximum burst, in
63
64 octets, of the MSDUs or A-MSDUs belonging to the traffic flow that arrive at the MAC SAP at the peak
65 data rate.

228 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The MSDU Lifetime field contains an unsigned integer that specifies the maximum amount of time, in mil-
2 liseconds, since the arrival of the MSDU at the MAC data service interface beyond which the MSDU is not
3
useful and may be discarded at the MSDU transmitter. The amount of time specified in this field is larger
4
5 than or equal to the amount of time specified in the Delay Bound field, if present.
6
7 The MSDU Delivery Ratio field specifies the MSDU loss requirement and is encoded as follows:
8
9 — The 4 LSBs of the MSDU Delivery Ratio field indicate the percentage of MSDUs that are expected
10 to be delivered within the delay bound specified in the Delay Bound field and its encoding is defined
11 in Table 9-401r (MSDU Delivery Ratio field values(#4918)). The 4 MSBs of the MSDU Delivery
12 Ratio field are reserved.
13
14
15
16 Table 9-401r—MSDU Delivery Ratio field values(#4918)
17
18 Value MSDU delivery ratio
19
20 0 Not specified
21
22 1 95%
23
24 2 96%
25 3 97%
26
27 4 98%
28
5 99%
29
30 6 99.9%
31
32 7 99.99%
33
8 99.999%
34
35 9 99.9999%
36
37 10–15 Reserved
38
39
40
41 The MSDU Count Exponent field contains an unsigned integer that specifies the exponent from which the
42 number of incoming MSDUs used for computing the MSDU delivery ratio is obtained. The number of
43 incoming MSDUs is equal to 10MSDU Count Exponent.
44
45 The Medium Time field contains an unsigned integer that specifies the medium time, in units of 256 micro-
46
47 seconds per second, requested by the STA as the average medium time needed in each second.
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 229

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 9.6 Action frame format details

2
3
4 9.6.7 Public Action details
5
6 9.6.7.16 TDLS Discovery Response frame format
7
8
9 Insert the following row into Table 9-454 (TDLS Discovery Response Action field
10 format(#1133)) after the row for Order 19:
11
12
13
14 Table 9-454—TDLS Discovery Response Action field format(#1133)
15
16
17 Order Information Notes
18
19 <Last EHT Capabilities The EHT Capabilities element is present if dot11EHTOption-
20 assigned + 1> Implemented is true; otherwise it is not present.
21
<Last Multi-Link The TDLS Multi-Link element is present if the STA is affili-
22
assigned + 2> ated with a non-AP MLD; otherwise, it is not present.
23
(#4031)
24
25
26
27
9.6.7.36 FILS Discovery frame format
28
29
30 Change Table 9-464 (BSS Operating Channel Width(#1020)) as follows:
31
32
33
34 Table 9-464—BSS Operating Channel Width(#1020)
35
36
BSS Operating HR/DSSS, OFDM, ERP,
37 EHT BSS operating TVHT BSS operating
Channel HT, VHT, or HE BSS
38 channel width channel width
Width field operating channel width
39
40 0 20 MHz or 22 MHz 20 MHz or 22 MHz TVHT_W
41
42 1 40 MHz 40 MHz TVHT_W+W
43
44 2 80 MHz 80 MHz TVHT_2W
45 3 160 MHz or 80+80 MHz 160 MHz TVHT_4W or TVHT_2W+2W
46
47 4 Reserved 320 MHz Reserved
48
49 45–7 Reserved Reserved Reserved
50
51
52
53 Insert the following row in Table 9-466 (PHY Index subfield(#1020))and change the value of
54 the reserved row:
55
56
57 Table 9-466—PHY Index subfield(#1020)
58
59
60 PHY Index subfield PHY
61
62 5 EHT (see Clause 36 (Extremely high throughput (EHT)
63 PHY specification))
64
65 56–7 Reserved

230 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Insert the following column in Table 9-467 (FILS Minimum Rate(#1020)):

2
3
4
5 Table 9-467—FILS Minimum Rate(#1020)
6
7 FILS PHY Index
8 PHY Index PHY Index PHY Index PHY Index PHY Index
Minimum subfield is 3
9 subfield is 0 subfield is 1 subfield is 2 subfield is 4 subfield is 5
Rate (VHT or
10 (HR/DSSS) (ERP-OFDM) (HT) (HE) (EHT)
subfield TVHT)
11
12 0 1 Mb/s 6 Mb/s HT-MCS 0 VHT-MCS 0 HE-MCS 0 EHT-MCS 0
13
14 1 2 Mb/s 9 Mb/s HT-MCS 1 VHT-MCS 1 HE-MCS 1 EHT-MCS 1
15
16 2 5.5 Mb/s 12 Mb/s HT-MCS 2 VHT-MCS 2 HE-MCS 2 EHT-MCS 2
17 3 11 Mb/s 18 Mb/s HT-MCS 3 VHT-MCS 3 HE-MCS 3 EHT-MCS 3
18
19 4 Reserved 24 Mb/s HT-MCS 4 VHT-MCS 4 HE-MCS 4 EHT-MCS 4
20
5–7 Reserved Reserved Reserved Reserved Reserved Reserved
21
22
23
24
9.6.8 FT Action frame details
25
26
27 9.6.8.1 General
28
29
30 Change the first paragraph as follows:
31
32 Four Action frame formats are defined to support fast BSS transitions over the DS, which are initiated
33 through the currently associated AP or AP MLD(#5175). The FT Action frames are sent over the air
34
35 between the STA and the current AP or between the non-AP MLD and the current AP MLD through an
36 affiliated STA and affiliated AP, respectively(#5175). The Action frame is used as a transport mechanism
37 for data that are destined for the target AP or AP MLD(#5175). An FT Action field, in the octet immediately
38 after the Category field, differentiates the FT Action frame formats. The FT Action field values associated
39 with each FT Action frame format are defined in Table 9-481 (FT Action field values).
40
41
42 9.6.8.2 FT Request frame
43
44
45 Change the first paragraph as follows:
46
47 The FT Request frame is sent by the STA to its associated AP or by the non-AP MLD through an affiliated
48 STA to its associated AP MLD through an affiliated AP(#5175) to initiate an over-the-DS fast BSS transi-
49
50 tion.
51
52 Change the sixth paragraph as follows:
53
54
55 The Target AP Address field is set to the BSSID value of the target APMAC address of the fast BSS transi-
56 tion responder (FTR)(#5175).
57
58
59
9.6.8.3 FT Response frame
60
61 Change the first paragraph as follows:
62
63
64 The FT Response frame is transmitted by the currently associated AP as a response to the STA’s FT Request
65 frame or the currently associated AP MLD through an affiliated AP as a response to the non-AP MLD’s FT

Copyright © 2022 IEEE. All rights reserved. 231

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Request frame(#5175). Figure 9-1140 (FT Response frame Action field format) shows the format of the FT
2 Response frame Action field.
3
4
5 Change the fifth paragraph as follows:
6
7 The Target AP Address field is set to the BSSID value of the target APFTR’s MAC address(#5175).
8
9
9.6.8.4 FT Confirm frame
10
11
12 Change the first paragraph as follows:
13
14 The FT Confirm frame in an RSN is confirmation to the target AP or AP MLD(#5175) of receipt of the
15
ANonce and indicates the liveness of the PTKSA. The FT Confirm frame is optionally used by the FTO to
16
17 request resources. Figure 9-1141 (FT Confirm frame Action field format) shows the FT Confirm frame
18 Action field format.
19
20 Change the fifth paragraph as follows:
21
22
23 The Target AP Address field is set to the BSSID value of the target APFTR’s MAC address(#5175).
24
25 9.6.8.5 FT Ack frame
26
27
28
Change the first paragraph as follows:
29
30 The FT Ack frame is transmitted by the currently associated AP as a response to the STA’s FT Confirm
31 frame or by the currently associated AP MLD through an affiliated AP as a response to the non-AP MLD’s
32 FT Confirm frame(#5175). Figure 9-1142 (FT Ack frame Action field format) shows the FT Ack frame
33
Action field format.
34
35
36 Change the fifth paragraph as follows:
37
38 The Target AP Address field is set to the BSSID value of the target APFTR’s MAC address(#5175).
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

232 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 9.6.12 TDLS Action field formats

2
3
9.6.12.2 TDLS Setup Request Action field format
4
5
6 Change the row “AID” and insert a new row “EHT Capabilities” in Table 9-494 (Information
7 for TDLS Setup Request Action field(#1133)) as follows (not all lines shown):
8
9
10
11 Table 9-494—Information for TDLS Setup Request Action field(#1133)
12
13
14 Order Information Notes
15
16 19 AID The AID element containing the AID of the STA (#4026)or
17 non-AP MLD whose affiliated STA is sending the frame is
18 present if dot11VHTOptionImplemented, dot11HEOptionIm-
19 plemented, dot11EHTOptionImplemented or dot11S1GOption-
20 Implemented is true.
21
<Last EHT Capabilities The EHT Capabilities element is present if dot11EHTOption-
22
assigned + 1> Implemented is true; otherwise it is not present.
23
24 <Last Multi-Link The TDLS Multi-Link element is present if the STA is affili-
25 assigned + 2> ated with a non-AP MLD; otherwise, it is not present.
26 (#4031)
27
28
29
30 9.6.12.3 TDLS Setup Response Action field format
31
32
33 Change the row “AID” and insert a new row “EHT Capabilities” in Table 9-495 (Information
34 for TDLS Setup Response Action field(#1133)) (not all lines shown):
35
36
37
Table 9-495—Information for TDLS Setup Response Action field(#1133)
38
39
40 Order Information Notes
41
42 20 AID The AID element containing the AID of the STA (#4026)or
43 non-AP MLD whose affiliated STA is sending the frame is
44 present if dot11VHTOptionImplemented, dot11HEOptionIm-
45 plemented, dot11EHTOptionImplemented or dot11S1GOption-
46 Implemented is true and the Status Code is SUCCESS and not
47 present otherwise.
48
49 <Last EHT Capabilities The EHT Capabilities element is present if dot11EHTOption-
50 assigned + 1> Implemented is true; otherwise it is not present.
51
52 <Last Multi-Link The TDLS Multi-Link element is present if the STA is affili-
53 assigned + 2> ated with a non-AP MLD and the TDLS Setup Request frame
54 (#4031) soliciting a response carried TDLS Multi-Link element; other-
55 wise, it is not present.
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 233

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 9.6.12.4 TDLS Setup Confirm Action field format

2
3
4 Insert the following row in Table 9-496 (Information for TDLS Setup Confirm Action
5 field(#1133)):
6
7
8
9 Table 9-496—Information for TDLS Setup Confirm Action field(#1133)
10
11
Order Information Notes
12
13
<Last EHT Operation The EHT Operation element is present when dot11EHTOption-
14
assigned + 1> Implemented is true, the TDLS Setup Response frame con-
15
tained an EHT Capabilities element, and the Status Code is
16
SUCCESS; otherwise it is not present. The EHT Operation ele-
17
ment is defined in 9.4.2.311 (EHT Operation element).
18
19 Multi-Link The TDLS Multi-Link element is present if the STA is affili-
<Last
20 ated with a non-AP MLD and the preceding TDLS Setup
assigned + 2>
21 Response frames carried TDLS Multi-Link element; otherwise,
22 it is not present.
23
24
25
26
9.6.12.12 TDLS Discovery Request Action field format
27
28
29 Insert the following row in Table 9-507 (Information for TDLS Discovery Request Action
30
31
field(#4031)):
32
33
34 Table 9-507—Information for TDLS Discovery Request Action field(#4031)
35
36
37 Order Information Notes
38
39 <Last Multi-Link The TDLS Multi-Link element is present if the STA is affili-
40 assigned + 1> ated with a non-AP MLD; otherwise, it is not present.
41
42
43
44 9.6.13 WNM Action details
45
46
47 9.6.13.8 BSS Transition Management Query frame format
48
49
50 Change the first paragraph as follows:
51
52 The BSS Transition Management Query frame is transmitted to request or provide information on BSS tran-
53
54 sition candidate APs or AP MLDs(#5322). The format of the BSS Transition Management Query frame
55 Action field is shown in Figure 9-1151 (BSS Transition Management Query frame Action field format).
56
57 Change the sixth paragraph as follows:
58
59
60 The BSS Transition Candidate List Entries field contains zero or more Neighbor Report elements, as
61 described in 9.4.2.36 (Neighbor Report element). The Neighbor Report elements are collected by the STA or
62
non-AP MLD(#5322) as part of its scanning procedures and provided to the AP or AP MLD(#5322) as
63
64 described in 11.21.7.2 (BSS transition management query) and 35.3.25 (BSS transition management for
65 MLDs(#5322))(#5322). The length of the BSS Transition Candidate List Entries field in a BSS Transition

234 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Management Query frame is limited by the maximum MMPDU size (see 9.3.3.1 (Format of (PV0) Manage-
2 ment frames)).
3
4
5 9.6.13.9 BSS Transition Management Request frame format
6
7 Change the first paragraph as follows:
8
9
The BSS Transition Management Request frame is transmitted by an AP or an AP affiliated with an AP
10
11 MLD(#5322) in response to a BSS Transition Management Query frame, or autonomously. The format of
12 the BSS Transition Management Request frame Action field is shown in Figure 9-1152 (BSS Transition
13 Management Request frame Action field format).
14
15
16 Change the fourth, fifth and sixth paragraphs, including Figure 9-1153 (Request Mode field
17 format(#4659)), as follows:
18
19 The Dialog Token field is defined in 9.4.1.12 (Dialog Token field). It is the nonzero value received in the
20
21 BSS Transition Management Query frame if the BSS Transition Management Request frame is being trans-
22 mitted in response to a BSS Transition Management Query frame. If the BSS Transition Management
23 Request frame is being transmitted other than in response to a BSS Transition Management Query frame,
24 then the Dialog Token field is a nonzero value chosen by the AP or AP MLD(#5180) sending the BSS Tran-
25 sition Management Request frame to identify the request/response transaction.
26
27
28 The Request Mode field is defined in Figure 9-1153 (Request Mode field format(#4659)).
29
30
31 B0 B1 B2 B3 B4 B5 B5B6 B7
32
33 Preferred BSS ESS Link
Candidate List Abridged Disassociation Termination Disassociation Removal Reserved
34 Included
Imminent
Included Imminent Imminent
35
36 Bits: 1 1 1 1 1 1 32
37
38
Figure 9-1153—Request Mode field format(#4659)
39
40
41 — The Preferred Candidate List Included (bit 0) field indicates whether the BSS transition candidate
42 list included in this frame is a preferred candidate list or a list of known BSS transition candidates.
43
44 The Preferred Candidate List Included bit set to 0 indicates that the receiving STA or non-AP
45 MLD(#5322) can ignore the BSS Transition Candidate List Entries field (see 11.21.7.3 (BSS transi-
46 tion management request)). The Preferred Candidate List Included bit set to 1 indicates that the
47 sender expects the receiving STA or non-AP MLD(#5322) to process this frame.
48
49 — The Abridged (bit 1) field indicates to the recipient of the frame the intended treatment of all
50 BSSIDs or AP MLDs(#5322) not listed in the BSS Transition Candidate List Entries field. The AP
51 or AP MLD(#5322) sets the Abridged bit in the Request Mode field to 1 when a preference value of
52 0 is assigned to all BSSIDs or AP MLDs(#5322) that do NOT appear in the BSS Transition Candi-
53
date List. The AP or AP MLD(#5180) sets the Abridged bit in the Request Mode field to 0 when the
54
55 AP or AP MLD(#5322) has no recommendation for or against any BSSID or AP MLD(#5322) not
56 present in the BSS Transition Candidate List Entries field.
57 — The Disassociation Imminent (bit 2) field indicates whether the STA or the non-AP MLD(#5322)
58
59 will be disassociated from the current AP or AP MLD(#5322). The value 1 in the Disassociation
60 Imminent bit in the Request Mode field indicates that the STA or the non-AP MLD(#5322) is to be
61 disassociated from the current AP or AP MLD(#5322), while the value 0 indicates that disassocia-
62 tion from the AP or AP MLD(#5322) is not imminent.
63
64 — The BSS Termination Included (bit 3) field indicates that the BSS Termination Duration field is
65 included, the BSS or the AP MLD(#5322) is shutting down and the STA or the non-AP

Copyright © 2022 IEEE. All rights reserved. 235

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 MLD(#5322) will be disassociated. The AP or AP MLD(#5322) sets the BSS Termination Included
2 bit in the Request Mode field to 1 to indicate that the BSS or AP MLD(#5322) is shutting down. The
3
BSS Termination Included bit is 0 if no BSS Termination Duration information is included in the
4
5 BSS Transition Management Request frame.
6
7 — The ESS Disassociation Imminent (bit 4) field indicates that the Session Information URL field is
8 included, and that the STA or non-AP MLD(#5322) will be disassociated from the ESS. The value 1
9 in the ESS Disassociation Imminent bit in the Request Mode field indicates that the STA or the non-
10 AP MLD(#5322) is to be disassociated from the ESS, while the value 0 indicates that disassociation
11 from the ESS is not imminent. When the ESS Disassociation Imminent bit value is 1, a Session
12
13 Information URL field is included in the BSS Transition Management Request frame.
14
— (#4659)The Link Removal Imminent (bit 5) field is reserved when the transmitting AP is not affili-
15
16 ated with an AP MLD or when the BSS Termination Included field is zero, and is ignored by a
17 receiving STA that is not affiliated with a non-AP MLD or when the BSS Termination Included
18 field is zero. The field is set to 1 to limit the scope of the BSS termination to the link on which the
19 request is being transmitted, and is set to 0 otherwise.
20
21
22 The Disassociation Timer indicates the time after which the AP or AP MLD(#5322) issues a Disassociation
23 frame to this STA or this non-AP MLD(#5322). The Disassociation Timer field contains the number of bea-
24
con transmission times (TBTTs) until the AP or AP MLD(#5322) sends a Disassociation frame to this STA
25
26 or non-AP MLD(#5322). Setting the field to 0 indicates that the AP or AP MLD(#5322) has not determined
27 when it will send a Disassociation frame to this STA or non-AP MLD(#5322). If the Disassociation Immi-
28 nent field is 0, the Disassociation Timer field is reserved. The format of the Disassociation Timer field is
29 shown in Figure 9-1154 (Disassociation Timer field format).
30
31
32 Change the eighth paragraph as follows:
33
34
35 The BSS Termination Duration field contains the BSS Termination Duration subelement (see 9.4.2.36
36 (Neighbor Report element)) for the current BSS or AP MLD(#5180) and is present only when the BSS Ter-
37 mination Included field is 1 in the Request Mode field.
38
39
40 9.6.13.10 BSS Transition Management Response frame format
41
42
43 Change the first paragraph as follows:
44
45
46 The BSS Transition Management Response frame is optionally transmitted by a STA or a STA affiliated
47 with a non-AP MLD(#5322)(#5180) in response to a BSS Transition Management Request frame. The for-
48 mat of the BSS Transition Management Response frame Action field is shown in Figure 9-1156 (BSS Tran-
49 sition Management Response frame Action field format).
50
51
52 Change the fifth to eighth paragraphs as follows:
53
54
55 The BTM Status Code field contains the status code in response to a BSS Transition Management Request
56 frame as defined in Table 9-511 (BTM status code definitions). If the STA or non-AP MLD(#5322) will
57 transition to another BSS or the non-AP MLD will transition to another AP MLD(#5322)(#5180), then the
58
status code is 0 (i.e., Accept). If the STA or non-AP MLD(#5322) intends to retain the association with the
59
60 current BSS or AP MLD(#5322), the status code is one of the “Reject” status codes.
61
62
The BSS Termination Delay field is the number of minutes that the responding STA or non-AP
63
64 MLD(#5322) requests the BSS or AP MLD(#5322) to delay termination. This field is reserved if the Status
65 code field value is not set to 5.

236 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The Target BSSID field is the BSSID of the BSS that the non-AP STA or non-AP MLD(#5322) transitions
2 to or the MLD MAC address of the AP MLD that the non-AP MLD transitions to(#5322). This field is pres-
3
ent if the Status code subfield contains 0, and not present otherwise.
4
5
6 The BSS Transition Candidate List Entries field contains zero or more Neighbor Report elements described
7 in 9.4.2.36 (Neighbor Report element). The Neighbor Report elements are collected by the STA or non-AP
8 MLD(#5322) as part of its scanning procedures and provided to the AP or AP MLD(#5322) as described in
9
10 11.21.7.4 (BSS transition management response) and 35.3.25 (BSS transition management for
11 MLDs(#5322))(#5322). The length of the BSS Transition Candidate List Entries field in a BSS Transition
12 Management Response frame is limited by the maximum MMPDU size (see 9.3.3.1 (Format of (PV0) Man-
13 agement frames)).
14
15
16 9.6.13.20 WNM Sleep Mode Response frame format
17
18 Change the sixth paragraph and Table 9-509 (Optional subelement IDs for WNM Sleep Mode
19
20 parameters) as follows:
21
22 The Key Data field contains zero or more subelements that provide the current GTK, IGTK and BIGTK to
23
24
the STA. The format of these subelements is shown in Figure 9-939 (WNM Sleep Mode GTK subelement
25 format), Figure 9-940 (WNM Sleep Mode IGTK subelement format), and Figure 9-941 (WNM Sleep Mode
26 BIGTK subelement format), Figure 9-1162a (WNM Sleep Mode MLO GTK subelement format), Figure 9-
27 1162c (WNM Sleep Mode MLO IGTK subelement format), and Figure 9-1162d (WNM Sleep Mode MLO
28 BIGTK subelement format). The subelement IDs for these subelements are defined in Table 9-509 (Optional
29
30
subelement IDs for WNM Sleep Mode parameters). When management frame protection is not used, the
31 Key Data field is not present.
32
33
34 Table 9-509—Optional subelement IDs for WNM Sleep Mode parameters
35
36
37 Value Contents of subelement
38
39 0 GTK
40
41 1 IGTK
42
43 2 BIGTK
44 3 MLO GTK
45
46 4 MLO IGTK
47
48 5 MLO BIGTK
49
50 36–255 Reserved
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 237

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Insert the following paragraphs after NOTE 2 (“Management frame protection is used to ...”):
2
3
4 The MLO GTK subelement contains the GTK for the AP operating on the link identified by the Link ID sub-
5 field carried in the subelement. The format of the MLO GTK subelement is shown in Figure 9-1162a (WNM
6 Sleep Mode MLO GTK subelement format).
7
8
9 Subelement ID Length Link Info Key Info Key Length RSC Key
10
11 Octets: 1 1 1 2 1 8 5 to 32
12
13 Figure 9-1162a—WNM Sleep Mode MLO GTK subelement format
14
15
16 The Length field is defined in 9.4.3 (Subelements).
17
18
19 The format of the Link Info field is shown in Figure 9-1162b (Link Info field format).
20
21
22 B0 B3 B4 B7
23
24 Link ID Reserved
25
26 Bits: 4 4
27
28 Figure 9-1162b—Link Info field format
29
30
31 The Link ID subfield identifies the link of the AP MLD.
32
33
34 The Key Info, Key Length, and RSC fields are as defined for GTK subelement.
35
36
37
The Key field is the GTK being distributed for the AP operating on the link identified by the Link ID sub-
38 field.
39
40 The MLO IGTK subelement contains the IGTK for the AP operating on the link identified by the Link ID
41
42 subfield carried in the subelement. The format of the MLO IGTK subelement is shown in Figure 9-1162c
43 (WNM Sleep Mode MLO IGTK subelement format).
44
45
46 Subelement ID Length Link Info Key ID PN Key
47
48 Octets: 1 1 1 2 6 16
49
50 Figure 9-1162c—WNM Sleep Mode MLO IGTK subelement format
51
52
53 The Length field is defined in 9.4.3 (Subelements).
54
55
56
The format of the Link Info field is shown in Figure 9-1162b (Link Info field format).
57
58 The Key ID and PN fields as defined for IGTK subelement.
59
60
61 The Key field is the IGTK being distributed for the AP operating on the link identified by the Link ID sub-
62 field.
63
64
65

238 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The MLO BIGTK subelement contains the BIGTK for the AP operating on the link identified by the Link
2 ID subfield carried in the subelement. The format of the MLO BIGTK subelement is shown in Figure 9-
3
1162d (WNM Sleep Mode MLO BIGTK subelement format).
4
5
6 Subelement ID Length Link Info Key ID BIPN Key
7
8 Octets: 1 1 1 2 6 16 or 32
9
10
Figure 9-1162d—WNM Sleep Mode MLO BIGTK subelement format
11
12
13 The Length field is defined in 9.4.3 (Subelements).
14
15
16 The format of the Link Info field is shown in Figure 9-1162b (Link Info field format).
17
18
19 The Key ID and BIPN fields are as defined for the BIGTK subelement.
20
21 The Key field is the BIGTK being distributed for the AP operating on the link identified by the Link ID sub-
22 field.
23
24 NOTE 3—There might be multiple MLO GTK, multiple MLO IGTK, and multiple MLO BIGTK subelements if a group
25 rekeying is in process for one or more links when the non-AP MLD wakes up from WNM sleep mode. The Subelement
26 ID field and Link ID subfield identifies the key type and the link to which the key(s) apply.
27
28 NOTE 4—Management frame protection is used to provide confidentiality, replay, and integrity protection for MLO
29 GTK/IGTK/BIGTK update in WNM Sleep Mode Response frames.
30
31 9.6.18 Robust AV Streaming Action frame details
32
33
34 9.6.18.3 SCS Response frame format
35
36
37
Change Figure 9-1176 (SCS Response frame Action field format(#1977)) as follows:
38
39 SCS SCS
40 Category Robust Action Dialog Token
Status List Descriptor List
41
42 Octets: 1 1 1 variable variable
43
44 Figure 9-1176—SCS Response frame Action field format(#1977)
45
46
47 Insert the following paragraph after the 5th paragraph (“The SCS Status List field con-
48 tains...”):
49
50
51 (#5890)(#1977)The SCS Descriptor List field is optionally present when the SCS Response frame is sent
52 from an EHT STA to another EHT STA. If present, it contains zero or more SCS Descriptor elements, as
53 defined in 9.4.2.121 (SCS Descriptor element). Each SCS Descriptor element contains a (#4918)QoS Char-
54
acteristics element to describe the traffic characteristics and QoS expectations of traffic flows that belong to
55
56 this SCS stream identified by the SCSID field value in the same SCS Descriptor element. Zero or one SCS
57 Descriptor element is present for an SCSID included in the SCS Status List field when the Status Code field
58 value for that SCSID is equal to “Success” or “REJECTED_WITH_SUGGESTED_CHANGES” and no
59 SCS Descriptor element is present otherwise.
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 239

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Insert the following new subclause at the end of subclause 9.6:

2
3
4 9.6.34 EHT Action frame details(#1119)(#1488)
5
6 9.6.34.1 EHT Action field
7
8
9 An EHT Action field, in the octet immediately after the Category field, differentiates the EHT Action frame
10 formats. The EHT Action field values associated with each frame format within the EHT category are
11 defined in Table 9-623a (EHT Action field values).
12
13
14
15 Table 9-623a—EHT Action field values
16
17 Value Meaning
18
19 0 EHT Compressed Beamforming/CQI
20
21 1 EML Operating Mode Notification.
22
2–255 Reserved
23
24
25
26
9.6.34.2 EHT Compressed Beamforming/CQI frame format
27
28
29 The EHT Compressed Beamforming/CQI frame is an Action No Ack frame of category EHT. The Action
30 field of an EHT Compressed Beamforming/CQI frame contains the information shown in Table 9-623b
31 (EHT Compressed Beamforming/CQI frame Action field format(#6078)).
32
33
34
35 Table 9-623b—EHT Compressed Beamforming/CQI frame Action field format(#6078)
36
37
38 Order(#6078) Meaning
39
1 Category
40
41 2 EHT Action
42
43 3 EHT MIMO Control (see 9.4.1.70 (EHT MIMO Control field))
44 4 EHT Compressed Beamforming Report (see 9.4.1.71 (EHT
45 Compressed Beamforming Report field))
46
47 5 EHT MU Exclusive Beamforming Report (see 9.4.1.72 (EHT MU
48 Exclusive Beamforming Report field))
49
50 6 EHT CQI Report (see 9.4.1.73 (EHT CQI Report field))
51
52
53
54 The Category field is defined in Table 9-79 (Category values(#4007)(#4299)).
55
56 The EHT Action field is defined in Table 9-623a (EHT Action field values).
57
58
59 The presence and contents of the EHT Compressed Beamforming Report field, EHT MU Exclusive Beam-
60 forming Report field, and EHT CQI Report field are dependent on the values of the Feedback Type subfield
61 of the EHT MIMO Control field (see 9.4.1.71 (EHT Compressed Beamforming Report field), 9.4.1.72 (EHT
62 MU Exclusive Beamforming Report field), and 9.4.1.73 (EHT CQI Report field)).
63
64
65 A Vendor Specific element is not present in the EHT Compressed Beamforming/CQI frame.

240 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 9.6.34.3 EML Operating Mode Notification frame format

2
3
4 The EML Operating Mode Notification frame is used to indicate that a non-AP MLD with which the trans-
5 mitting STA is affiliated is changing its EML operation.
6
7
8 The Action field of the EML Operating Mode Notification frame contains the information shown in Table 9-
9 623c (EML Operating Mode Notification frame Action field format).
10
11
12
13 Table 9-623c—EML Operating Mode Notification frame Action field format
14
15 Order Information
16
17 1 Category
18
19 2 EHT Action
20
21 3 Dialog Token
22 4 EML Control (see 9.4.1.74 (EML Control field))
23
24
25
26
27
The Category field is defined in 9.4.1.11 (Action field).
28
29 The EHT Action field is defined in 9.6.34.1 (EHT Action field).
30
31
32 The Dialog Token field is set by a non-AP MLD to a nonzero value chosen by the non-AP MLD and is set
33
by an AP MLD to the value copied from the corresponding received EML Operating Mode Notification
34
35 frame.
36
37
38
9.6.35 Protected EHT Action frame details
39
40 9.6.35.1 Protected EHT Action field
41
42
43 A Protected EHT Action field, in the octet immediately after the Category field, differentiates the Protected
44
EHT Action frame formats. The Protected EHT Action field values associated with each frame format
45
46 within the EHT category are defined in Table 9-623d (Protected EHT Action field values(#1119)(#1488)).
47
48
49 Table 9-623d—Protected EHT Action field values(#1119)(#1488)
50
51
52 Value Meaning Time priority
53
54 0 TID-To-Link Mapping Request No
55 1 TID-To-Link Mapping Response No
56
57 2 TID-To-Link Mapping Teardown No
58
59 3 (#5284)EPCS Priority Access Enable Request No
60 4 (#5284)EPCS Priority Access Enable No
61 Response
62
63 5 (#5284)EPCS Priority Access Teardown No
64
65 6–255

Copyright © 2022 IEEE. All rights reserved. 241

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 9.6.35.2 TID-To-Link Mapping Request frame format

2
3
(#6026)An MLD uses the TID-to-link Mapping Request frame to negotiate a TID-to-link mapping for setup
4
5 links with a peer MLD. The Action field of the TID-to-link Mapping Request frame contains the informa-
6 tion shown in Table 9-623e (TID-To-Link Mapping Request frame Action field format).
7
8
9 Table 9-623e—TID-To-Link Mapping Request frame Action field format
10
11
12 Order Information
13
14 1 Category
15
16 2 (#5372)Protected EHT Action
17 3 Dialog Token
18
19 4 TID-To-Link Mapping (see 9.4.2.314 (TID-To-Link Mapping
20 element))
21
22
23
24 The Category field is defined in 9.4.1.11 (Action field).
25
26 (#5372)The Protected EHT Action field is defined in 9.6.35.1 (Protected EHT Action field).
27
28
29
The Dialog Token field (#6760)is a set to a nonzero value chosen by the STA sending the TID-To-Link
30 Mapping Request frame to identify the request/response transaction.
31
32 The TID-To-Link Mapping field contains one or two TID-To-Link Mapping elements as specified in
33 9.4.2.314 (TID-To-Link Mapping element). When it contains two TID-To-Link Mapping elements, the
34
35
Direction subfield in one of the TID-To-Link Mapping elements is set to 0(#6760) and the Direction sub-
36 field in the other of the TID-To-Link Mapping elements is set to 1(#6760).
37
38 9.6.35.3 TID-To-Link Mapping Response frame format
39
40
41 The TID-To-Link Mapping Response frame is sent by a STA (#6581)affiliated with an MLD in response to
42 a TID-To-Link Mapping Request frame to accept or reject a proposed TID-to-link mapping, or sent by a
43 STA (#6581)affiliated with an MLD to suggest a preferred TID-to-link mapping. The Action field of the
44 TID-To-Link Mapping Response frame contains the information shown in Table 9-623f (TID-To-Link
45 Mapping Response frame Action field format).
46
47
48
49 Table 9-623f—TID-To-Link Mapping Response frame Action field format
50
51
52 Order Information
53 1 Category
54
55 2 (#5372)Protected EHT Action
56
57 3 Dialog Token
58 4 Status Code
59
60 5 TID-To-Link Mapping (see 9.4.2.314 (TID-To-Link Mapping
61 element))
62
63
64
65 The Category field is defined in 9.4.1.11 (Action field).

242 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#5372)The Protected EHT Action field is defined in 9.6.35.1 (Protected EHT Action field).
2
3
4 When the TID-To-Link Mapping Response frame is transmitted as a response to a TID-To-Link Mapping
5 Request frame, the Dialog Token field is the value in the corresponding TID-To-Link Mapping Request
6 frame. When the TID-To-Link Mapping Response frame is transmitted as an unsolicited response, then the
7 Dialog token is set to 0.
8
9
10 The Status Code is defined in 9.4.1.9 (Status Code field).
11
12
13 The TID-To-Link Mapping field contains zero, one, or two TID-To-Link Mapping elements as specified in
14 9.4.2.314 (TID-To-Link Mapping element) in order to suggest a preferred mapping. It contains one or two
15 TID-To-Link Mapping elements if the Status Code is set to 134 (PREFERRED_TID_TO_LINK_MAP-
16
PING_SUGGESTED). Otherwise, it does not contain a TID-To-Link Mapping element. When it contains
17
18 two TID-To-Link Mapping elements, the Direction subfield in one of the TID-To-Link Mapping elements is
19 set to 0 (Downlink) and the Direction subfield in the other of the TID-To-Link Mapping elements is set to 1
20 (Uplink).
21
22
23 9.6.35.4 TID-To-Link Mapping Teardown frame format
24
25
26 The TID-to-link Mapping Teardown frame is sent by a STA (#6581)affiliated with an MLD to request the
27 teardown of an existing TID-to-link mapping that have been (#5895)negotiated with the peer MLD. The
28 Action field of the TID-to-link Mapping Teardown frame contains the information shown in Table 9-623g
29 (TID-To-Link Mapping Teardown frame Action field format).
30
31
32
33 Table 9-623g—TID-To-Link Mapping Teardown frame Action field format
34
35 Order Information
36
37 0 Category
38
39 1 (#5372)Protected EHT Action
40
41
42
43 The Category field is defined in 9.4.1.11 (Action field).
44
45
46 (#5372)The Protected EHT Action field is defined in 9.6.35.1 (Protected EHT Action field).
47
48
49 9.6.35.5 EPCS Priority Access Enable Request frame format(#5284)(#1119)(#1488)
50
51 (#5284)The EPCS Priority Access Enable Request frame is an Action frame of category Protected EHT. It is
52
53
transmitted by a requesting (#7538)MLD to request that EPCS priority access be(#5595) enabled. The
54 Action field of the EPCS Priority Access Enable Request frame contains the information shown in Table 9-
55 623h (EPCS Priority Access Enable Request frame Action field format(#5284)).
56
57
58 Table 9-623h—EPCS Priority Access Enable Request frame Action field format(#5284)
59
60
61 Order Meaning
62
63 1 Category
64
65 2 Protected EHT Action(4820)

Copyright © 2022 IEEE. All rights reserved. 243

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 9-623h—EPCS Priority Access Enable Request frame Action field format(#5284)
2
3
4 Order Meaning
5
6 3 Dialog Token
7 4 Priority Access Multi-Link
8 element(#4176)
9
10
11
12 The Category field is defined in 9.4.1.11 (Action field).
13
14
15 The Protected EHT Action field is defined in 9.6.35.1 (Protected EHT Action field).
16
17 The Dialog Token field is defined in 9.4.1.12 (Dialog Token field) and set by the requesting (#7538)MLD.
18
19
20 (#4176)The Priority Access Multi-Link field is defined in 9.4.2.312.6 (Priority Access Multi-Link ele-
21 ment(#4176)).
22
23
24 9.6.35.6 EPCS Priority Access Enable Response frame format(#5284)(#1119)(#1488)
25
26
27 (#5284)The EPCS Priority Access Enable Response frame is an Action frame of category Protected EHT. It
28 is transmitted in response to an EPCS Priority Access Enable Request frame. The Action field of the EPCS
29 Priority Access Enable Response frame contains the information shown in Table 9-623i (EPCS Priority
30 Access Enable Response frame Action field format(#5284)).
31
32
33
34 Table 9-623i—EPCS Priority Access Enable Response frame Action field format(#5284)
35
36
Order Meaning
37
38 1 Category
39
40 2 Protected EHT
41
42 3 Dialog Token
43 4(#5598) Status Code
44
45 5(#5598) Priority Access Multi-Link element(#4176)
46
47
48
49 The Category field is defined in 9.4.1.11 (Action field).
50
51
52 The Protected EHT Action field is defined in 9.6.35.1 (Protected EHT Action field).
53
54 The Dialog Token field value is copied from the Dialog Token field in the corresponding (#5284)EPCS Pri-
55
56 ority Access Enable Request frame.
57
58 The Status Code field values are defined in Table 9-78 (Status codes).
59
60
61 (#4176)The Priority Access Multi-Link field is defined in 9.4.2.312.6 (Priority Access Multi-Link ele-
62 ment(#4176)).
63
64
65

244 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 9.6.35.7 EPCS Priority Access Teardown frame details(#5284)(#1127)

2
3
4 (#5284)The EPCS Priority Access Teardown frame is an Action frame of category Protected EHT. It is
5 transmitted by an (#7538)MLD to disable EPCS priority access. The Action field of the EPCS Priority
6 Access Teardown frame contains the information shown in Table 9-623j (EPCS Priority Access Teardown
7 Action field format(#5284)).
8
9
10
11 Table 9-623j—EPCS Priority Access Teardown Action field format(#5284)
12
13 Order Meaning
14
15 1 Category
16
17 2 Protected EHT
18
19
20
21 The Category field is defined in 9.4.1.11 (Action field).
22
23 The Protected EHT Action field is defined in 9.6.35.1 (Protected EHT Action field).
24
25
26
27 9.7 Aggregate MPDU (A-MPDU)
28
29 9.7.1 A-MPDU format
30
31
32 Change the fourth paragraph as follows:
33
34 The EOF Padding field is shown in Figure 9-1204 (EOF Padding field format). This is present only in a
35 VHT, EDMG, S1G, (#4295)or HE, or EHT PPDU.
36
37
38 Change the sixth paragraph as follows:
39
40 In a VHT, EDMG, S1G, (#4295)or HE, or EHT PPDU, the following padding is present, as determined by
41
42 the rules in 10.12.6 (A-MPDU padding for VHT, HE, EHT or S1G PPDU):
43 — 0–3 octets in the Padding subfield of the final A-MPDU subframe (see Figure 9-1205 (A-MPDU
44 subframe format)) before any EOF padding subframes. The content of these octets is unspecified.
45
46 — Zero or more EOF padding subframes in the EOF Padding Subframes subfield.
47
48 — 0–3 octets in the EOF Padding Octets subfield. The content of these octets is unspecified.
49
50 Change the ninth paragraph as follows:
51
52
53 The maximum length of an A-MPDU in an HT PPDU is 65 535 octets. The maximum length of an A-
54 MPDU in a DMG PPDU is 262 143 octets. The maximum length of an A-MPDU pre-EOF padding in a
55 VHT PPDU is 1 048 575 octets. The maximum length of an A-MPDU pre-EOF padding in an HE PPDU is
56 6 500 631 octets. The maximum length of an A-MPDU in an EDMG PPDU is 4 194 303 octets. (#4295)The
57 maximum length of an A-MPDU pre-EOF padding in an EHT PPDU is 15 523 200 octets. The length of an
58
59 A-MPDU addressed to a particular STA can be further constrained as described in 10.12.2 (A-MPDU length
60 limit rules).
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 245

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Change Table 9-627 (MPDU delimiter fields) as follows:

2
3
4
Table 9-627—MPDU delimiter fields
5
6
7 Size
8 Field Description
(bits)
9
10 EOF/Tag 1 End of frame indication if the MPDU Length field is 0. Set to 1 in an A-
11 MPDU subframe that has 0 in the MPDU Length field and that is used to
12 pad the AMPDU in a (#4295)VHT, or HE, or EHT PPDU as described in
13 10.12.6 (A-MPDU padding for VHT, HE, EHT or S1G PPDU). Set to 1
14 in the MPDU delimiter of an S-MPDU as described in 10.12.7 (Setting
15 the EOF/Tag field of the MPDU delimiter).
16
17 Tagged/untagged indication if the MPDU Length field is nonzero. Set to
18 1 in an MPDU delimiter preceding a QoS Data frame or Management
19 frame soliciting an Ack frame or Per AID TID Info field with the Ack
20 Type field set to 1 in a Multi-STA BlockAck frame in a response that is
21 contained in an ack-enabled multi-TID A-MPDU as described in
22 26.6.3.4 (Ack-enabled multi-TID A-MPDU operation) and ack-enabled
23 single-TID A-MPDU as described in 26.6.3.2 (Ack-enabled single-TID
24 A-MPDU operation). Set to 0 otherwise.
25
26 In a DMG PPDU, this field is reserved. In an EDMG PPDU, it is set to 1
27 in EOF padding subframes and set to 0 otherwise (see 10.12.7 (Setting
28 the EOF/Tag field of the MPDU delimiter)).
29
30 Reserved 1
31
MPDU Length 14 Length of the MPDU in octets. Set to 0 if no MPDU is present. An A-
32
MPDU subframe with 0 in the MPDU Length field is used as defined in
33
10.12.3 (Minimum MPDU start spacing rules) to meet the minimum
34
MPDU start spacing requirement and also to pad the A-MPDU to fill the
35
available octets in a (#4295)VHT, or HE, or EHT PPDU as defined in
36
10.12.6 (A-MPDU padding for VHT, HE, EHT or S1G PPDU).
37
38 CRC 8 8-bit CRC of the preceding 16 bits.
39
40 Delimiter Signature 8 Pattern that can be used to detect an MPDU delimiter when scanning for
41 an MPDU delimiter. The unique pattern is 0x4E, which is the ASCII
42 value of the character “N”.
43
44
45
46 Change the 12th paragraph as follows:
47
48
49 The format of the MPDU Length field when transmitted by a non-DMG STA is shown in Figure 9-
50 1207 (MPDU Length field format (non-DMG)). The MPDU Length Low subfield contains the 12 low order
51
52 bits of the MPDU length. In a (#4295)VHT, or HE, or EHT PPDU, the MPDU Length High subfield con-
53 tains the two high order bits of the MPDU length. In an HT PPDU, the MPDU Length High subfield is
54 reserved.
55
56
57
Change equation Equation (9-13) as follows:
58
59
60
61  L low + L high  4096 for a VHT and HE PPDU
62 
63 L MPDU =  L low for an HT PPDU (9-13)
64 
65  L for a DMG and EDMG PPDU

246 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2  L low + L high  4096 for a VHT, HE, and EHT PPDU
3 
L MPDU =  L  for an HT PPDU (9-13)
4 low

5  L for a DMG and EDMG PPDU
6
7
8 Change the 15th paragraph as follows:
9
10 NOTE 2—The format of the MPDU Length field maintains a common encoding structure for (#4295)EHT, HE, VHT,
11 and HT PPDUs. For HT PPDUs, only the MPDU Length Low subfield is used, while for (#4295)VHT, and HE, and
12 EHT PPDUs, both subfields are used.
13
14 9.7.2 A-MPDU contents
15
16
17
Change the first paragraph as follows:
18
19 In a non-DMG PPDU, an A-MPDU is a sequence of A-MPDU subframes carried in a single PPDU with one
20 of the following combinations of RXVECTOR or TXVECTOR parameter values:
21
22 — The FORMAT parameter set to VHT
23
24
— The FORMAT parameter set to HT_MF or HT_GF and the AGGREGATION parameter set to 1
25 — The FORMAT parameter set to S1G, S1G_DUP_1M, or S1G_DUP_2M and the AGGREGATION
26 parameter set to 1.
27
28 — The FORMAT parameter set to HE_SU, HE_MU, HE_TB, or HE_ER_SU.
29
30 — (#4295)The FORMAT parameter set to EHT_MU or EHT_TB.
31
32 Change the sixth paragraph as follows:
33
34
35 The Duration/ID fields in the MAC headers of all MPDUs in an A-MPDU carry the same value. The Dura-
36 tion/ID fields in the MAC headers of the MPDUs in the A-MPDUs carried in a (#4295)VHT MU PPDU,
37 and an HE MU PPDU, and an EHT MU PPDU carry the same value.
38
39
40
Change the tenth paragraph as follows:
41
42 A VHT MU PPDU, S1G MU PPDU(#4295), and HE MU PPDU, and EHT MU PPDU do not carry more
43 than one A-MPDU that contains one or more MPDUs soliciting an immediate response if the immediate
44
response is carried in a PPDU that is not an HE TB PPDU (#4295)and is not an EHT TB PPDU. An HE MU
45
46 PPDU (#4295)and an EHT MU PPDU can carry more than one A-MPDU each of which contains one or
47 more MPDUs soliciting an immediate response if the immediate response is carried in an HE TB PPDU
48 (#4295)or an EHT TB PPDU.
49
50
51 Change the 12th paragraph as follows:
52 NOTE 4—If a STA supports A-MSDUs of 7935 octets (indicated by the Maximum A-MSDU Length field in the HT
53 Capabilities element), A-MSDUs transmitted by that TA within an A-MPDU carried in a PPDU with FORMAT HT_MF
54 or HT_GF or within an MPDU carried in a non-HT PPDU are constrained so that the length of the QoS Data frame car-
55 rying the A-MSDU is no more than 4095 octets. The 4095-octet MPDU length limit does not apply to A-MPDUs carried
56 in (#4295)VHT, HE, EHT or DMG PPDUs. The use of A-MSDU within A-MPDU might be further constrained as
57 described in 9.4.1.13 (Block Ack Parameter Set field) through the operation of the A-MSDU Supported field.
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 247

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Change Table 9-628 (A-MPDU contexts)as follows:

2
3
4
Table 9-628—A-MPDU contexts
5
6
7 Table defining
8 Name of Context Definition of Context
permitted contents
9
10 Non-HE Data The A-MPDU is transmitted outside a PSMP sequence by a Table 9-629 (A-MPDU
11 Enabled TXOP holder or an RD responder including potential contents in the non-HE
12 Immediate immediate responses. data enabled immediate
13 Response response context)
14
15 Data Enabled No The A-MPDU is transmitted outside a PSMP sequence by a Table 9-630 (A-MPDU
16 Immediate TXOP holder, TXOP responder when transmitted by an HE contents in the data
17 Response STA to another HE STA, and the A-MPDU does not include or enabled no immediate
18 solicit an immediate response. See NOTE. response context)
19
PSMP The A-MPDU is transmitted within a PSMP sequence. Table 9-631 (A-MPDU
20
contents in the PSMP
21
context)
22
23 Control Response The A-MPDU is transmitted by a STA that is neither a TXOP Table 9-632 (A-MPDU
24 holder nor an RD responder, or the A-MPDU is transmitted by contents in the control
25 an HE AP in response to an HE TB PPDU(#4295), or an EHT response context)
26 AP in response to an EHT TB PPDU, and the transmitter also
27 needs to transmit one of the following immediate response
28 frames:
29 — Ack frame
30 — BlockAck frame with a TID for which an HT-immediate
31 block ack agreement exists
32 — Multi-STA BlockAck frame for acknowledging multi-TID
33 A-MPDU
34
35 S-MPDU context The A-MPDU is transmitted within a VHT PPDU(#4295), or Table 9-633 (A-MPDU
36 an HE PPDU, or an EHT PPDU and contains an S-MPDU. contents in the S-MPDU
37 context)
38 HE Non-Ack- The A-MPDU is transmitted by a TXOP holder or TXOP Table 9-634 (A-MPDU
39 Enabled Single- responder in an HE PPDU and solicits block acknowledgment contents in the HE non-
40 TID Immediate for a single TID. ack-enabled single-TID
41 Response immediate response
42 context (#4295)or in the
43 EHT non-ack-enabled
44 single-TID immediate
45 response context)
46
47 HE Ack-Enabled The A-MPDU is transmitted by a TXOP holder or TXOP Table 9-635 (A-MPDU
48 Single-TID responder in an HE PPDU and solicits single acknowledgment. contents in the HE ack-
49 Immediate enabled single-TID
50 Response immediate response
51 context (#4295)or in the
52 EHT ack-enabled
53 single-TID immediate
54 response context)
55
56 HE Non-Ack The A-MPDU is transmitted by a TXOP holder or TXOP Table 9-636 (A-MPDU
57 Enabled Multi- responder in an HE PPDU, and solicits block acknowledgments contents in the HE non-
58 TID Immediate for multiple TIDs. ack-enabled multi-TID
59 Response immediate response
60 context (#4295)or in the
61 EHT non-ack-enabled
62 multi-TID immediate
63 response context)
64
65

248 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 9-628—A-MPDU contexts (continued)

2
3
4 Table defining
Name of Context Definition of Context
5 permitted contents
6
7 HE Ack-Enabled The A-MPDU is transmitted by a TXOP holder or TXOP Table 9-637 (A-MPDU
8 Multi-TID responder in an HE PPDU, and solicits at least one contents in the HE ack-
9 Immediate acknowledgment and zero or more block acknowledgments. enabled multi-TID
10 Response immediate response
11 context (#4295)or in the
12 EHT ack-enabled multi-
13 TID immediate
14 response context)
15 (#4295)EHT Non- The A-MPDU is transmitted by a TXOP holder or TXOP Table 9-634 (A-MPDU
16 Ack-Enabled responder in an EHT PPDU and solicits block acknowledgment contents in the HE non-
17 Single-TID for a single TID. ack-enabled single-TID
18 Immediate immediate response
19 Response context (#4295)or in the
20 EHT non-ack-enabled
21 single-TID immediate
22 response context)
23
24 (#4295)EHT Ack- The A-MPDU is transmitted by a TXOP holder or TXOP Table 9-635 (A-MPDU
25 Enabled Single- responder in an EHT PPDU and solicits single contents in the HE ack-
26 TID Immediate acknowledgment. enabled single-TID
27 Response immediate response
28 context (#4295)or in the
29 EHT ack-enabled
30 single-TID immediate
31 response context)
32
33 (#4295)EHT Non- The A-MPDU is transmitted by a TXOP holder or TXOP Table 9-636 (A-MPDU
34 Ack Enabled responder in an EHT PPDU, and solicits block contents in the HE non-
35 Multi-TID acknowledgments for multiple TIDs. ack-enabled multi-TID
36 Immediate immediate response
37 Response context (#4295)or in the
38 EHT non-ack-enabled
39 multi-TID immediate
40 response context)
41 (#4295)EHT Ack- The A-MPDU is transmitted by a TXOP holder or TXOP Table 9-637 (A-MPDU
42 Enabled Multi- responder in an EHT PPDU, and solicits at least one contents in the HE ack-
43 TID Immediate acknowledgment and zero or more block acknowledgments. enabled multi-TID
44 Response immediate response
45 context (#4295)or in the
46 EHT ack-enabled multi-
47 TID immediate
48 response context)
49
50 NOTE—This context includes cases when no response is generated.
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 249

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 9.8 MAC frame format for PV1 frames

2
3
4 9.8.2 General PV1 frame format
5
6 Change Table 9-632 (A-MPDU contents in the control response context) as follows:
7
8
9
10 Table 9-632—A-MPDU contents in the control response context
11
12 MPDU Conditions
13
14 Ack Ack frame transmitted in response to an
15 MPDU that requires an Ack frame.
16
17 BlockAck Compressed BlockAck frame with a TID that
18 corresponds to an HT-immediate block ack
19 agreement. See NOTE. One of Ack and compressed
20 BlockAck frame is present at the start
21 Multi-STA BlockAck frame if the preceding of the A-MPDU between two STAs
22 PPDU is either an HE (#4295)or EHT TB that are not both HE STAs; these are
23 PPDU that solicits an immediate response not present other than at the start of
24 (see 26.4.4.5 (Responding to an HE TB the A-MPDU.
25 PPDU with an SU PPDU)) or an HE
26 (#4295)or EHT PPDU that carries a multi- One of Ack, Compressed BlockAck,
27 TID A-MPDU or ack-enabled multi- TID A- and Multi-STA BlockAck frame is
28 MPDU (see 26.6.3 (Multi-TID AMPDU and present at the start of the A-MPDU
29 ack-enabled single-TID AMPDU)). between two HE STAs; these are not
30 present other than at the start of the A-
31 EDMG Multi-TID If the preceding PPDU that carried a multi- MPDU.
32 BlockAck TID A-MPDU contains an implicit or
33 explicit block ack requests for multiple TIDs
34 for which an HT-immediate block ack
35 agreement exists, one or several copies of the
36 same EDMG Multi-TID BlockAck frame.
37 Action No Ack In an A-MPDU between two STAs that are not both HE STAs:
38 BRP +HTC frames.
39 Action No Ack +HTC frames containing an explicit feedback response.
40 Action No Ack frames that are Flow Suspension frames or Flow Resumption frames.
41
42 In an A-MPDU between two HE STAs: Action No Ack frames.
43
44 QoS Null frame If sent to an HE STA. QoS Null frames with No Ack ack policy.
45 with No Ack ack
46 policy
47
NOTE—This condition is applicable for BlockAck variants established by block ack agreements and is not
48
applicable for the EDMG Multi-TID BlockAck where the condition depends on a preceding PPDU.
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

250 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 9.8.3 PV1 frame fields

2
3
4 9.8.3.1 Frame Control field
5
6
7 Change the title of Table 9-634 (A-MPDU contents in the HE non-ack-enabled single-TID
8 immediate response context (#4295)or in the EHT non-ack-enabled single-TID immediate
9
10
response context) as follows:
11
12
13 Table 9-634—A-MPDU contents in the HE non-ack-enabled single-TID immediate response
14 context (#4295)or in the EHT non-ack-enabled single-TID immediate response context
15
16
17 MPDU Conditions
18
19
20
21
22
23 Change the title of Table 9-635 (A-MPDU contents in the HE ack-enabled single-TID immedi-
24
25
ate response context (#4295)or in the EHT ack-enabled single-TID immediate response context)
26 as follows:
27
28
29 Table 9-635—A-MPDU contents in the HE ack-enabled single-TID immediate response con-
30 text (#4295)or in the EHT ack-enabled single-TID immediate response context
31
32
33 MPDU Conditions
34
35
36
37
38
39 Change the title of Table 9-636 (A-MPDU contents in the HE non-ack-enabled multi-TID
40
41 immediate response context (#4295)or in the EHT non-ack-enabled multi-TID immediate
42 response context) as follows:
43
44
45
Table 9-636—A-MPDU contents in the HE non-ack-enabled multi-TID immediate response
46
47 context (#4295)or in the EHT non-ack-enabled multi-TID immediate response context
48
49
MPDU Conditions
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 251

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Change the title of Table 9-637 (A-MPDU contents in the HE ack-enabled multi-TID immediate
2 response context (#4295)or in the EHT ack-enabled multi-TID immediate response context) as
3
4 follows:
5
6
7 Table 9-637—A-MPDU contents in the HE ack-enabled multi-TID immediate response con-
8 text (#4295)or in the EHT ack-enabled multi-TID immediate response context
9
10
11 MPDU Conditions
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

252 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 10. MAC sublayer functional description

2
3
4
5 10.1 Introduction
6
7 Change as follows:
8
9
10 The MAC functional description is presented in this clause. The architecture of the MAC sublayer, including
11 the distributed coordination function (DCF), the hybrid coordination function (HCF), the mesh coordination
12 function (MCF), the triggered UL access (TUA), and their coexistence in an IEEE 802.11 LAN are intro-
13
14
duced in 10.2 (MAC architecture). (#1737)These functions are expanded on in 10.3 (DCF), 10.23 (HCF),
15 10.24 (Mesh coordination function (MCF)), and 26.2 (HE channel access), 35.2 (Channel access), and
16 35.3.13 (Multi-link group addressed frame delivery and reception). Fragmentation and defragmentation are
17 defined in 10.4 (MSDU and MMPDU fragmentation) and 10.5 (MSDU and MMPDU defragmentation). Mul-
18 tirate support is addressed in 10.6 (Multirate support). A number of additional restrictions to limit the cases in
19
20
which MSDUs are reordered or discarded are described in 10.7 (MSDU transmission restrictions). Operation
21 across regulatory domains is defined in 10.22 (Operation across regulatory domains). The block ack mecha-
22 nism is described in 10.25 (Block acknowledgment (block ack)). The No Ack mechanism is described in
23 10.26 (No Acknowledgment (No Ack)). The protection mechanism is described in 10.27 (Protection mecha-
24 nisms). Rules for processing MAC frames are described in 10.28 (MAC frame processing).
25
26
27
28 10.2 MAC architecture
29
30 10.2.1 General
31
32
33 Change Figure 10-1 (Non-DMG non-CMMG non-S1G STA MAC architecture(#1737)) as
34 follows:
35
36 Required for
37 Required for Prioritized Controlled Mesh
Required for QoS Services Services
38 Parameterized Required for
39 QoS Services Triggered Uplink
40 Access
41
42 Mesh Coordination Function (MCF)
43
44
45 Hybrid Coordination Function (HCF)
Used for Contention
46 Services, basis for
47 PCF, HCF and MCF
48 HCF
HCF MCF Triggered
49 Conten-
Controlled Controlled Uplink
50 MAC Access
tion
Access Access
51 Access
extent (HCCA) (MCCA) (TUA)
52 (EDCA)
53
54
55 Distributed Coordination Function (DCF)
56
57
58 DSSS, OFDM, HR/DSSS, ERP, HT, VHT, TVHT, HE or EHT
59 PHY
60
61 Figure 10-1—Non-DMG non-CMMG non-S1G STA MAC architecture(#1737)
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 253

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 10.3 DCF
2
3
4 10.3.2 Procedures common to the DCF and EDCAF
5
6 10.3.2.9 CTS and DMG CTS procedure
7
8
9
Insert the following two paragraphs as the first and second paragraphs of the subclause:
10
11 (#5232)In this subclause, a STA is NSTR limited of all of the following conditions are true:
12
— the STA is affiliated with an MLD that has at least one NSTR link pair
13
14 — the STA has received the RTS on a link that is a member of one or more of the MLD’s NSTR link
15 pairs
16
17 — a STA of the MLD is a TXOP holder or TXOP responder on one of the other links that is a member
18 of at least one of the NSTR link pairs of which the link on which the RTS was received is a member
19
20 (#5232)If at least one of the above conditions is not true, then the STA is not NSTR limited.
21
22
23 Change the now-shifted third paragraph as follows:
24
25 A STA that receives an RTS frame addressed to it considers (#5232)whether the STA is NSTR limited and
26
considers the NAV in determining whether to respond with CTS, unless the NAV was set by a frame
27
28 originating from the STA sending the RTS frame (see 10.24.2.2 (EDCA backoff procedure)). In this
29 subclause for a non-S1G STA, “NAV indicates idle” means that the NAV count is 0 or that the NAV count
30 is nonzero but the nonbandwidth signaling TA obtained from the TA field of the RTS frame matches the
31 saved TXOP holder address. In an S1G STA, “NAV indicates idle” means that both NAV and RID counters
32
are 0 or that either NAV or RID counter is nonzero but the TA field of the RTS frame matches the saved
33
34 TXOP holder address.
35
36 Change the now-shifted fourth and fifth paragraphs as follows:
37
38
A VHT STA that is addressed by an RTS frame in a non-HT or non-HT duplicate PPDU that has a
39
40 bandwidth signaling TA and that has the RXVECTOR parameter DYN_BANDWIDTH_IN_NON_HT
41 equal to Static behaves as follows:
42 — If the NAV indicates idle, the STA is not NSTR limited and CCA has been idle for all secondary
43
44 channels (secondary 20 MHz channel, secondary 40 MHz channel, and secondary 80 MHz channel)
45 in the channel width indicated by the RTS frame’s RXVECTOR parameter
46 CH_BANDWIDTH_IN_NON_HT for a PIFS prior to the start of the RTS frame, then the STA shall
47 respond with a CTS frame carried in a non-HT or non-HT duplicate PPDU after a SIFS. The CTS
48 frame’s TXVECTOR parameters CH_BANDWIDTH and CH_BANDWIDTH_IN_NON_HT shall
49
50 be set to the same value as the RTS frame’s RXVECTOR parameter
51 CH_BANDWIDTH_IN_NON_HT.
52 • If all of the conditions in the previous paragraph are met, except for the condition “the STA is not
53
NSTR limited”, then the STA may respond with the CTS frame as described in that paragraph.
54
55 — Otherwise, the STA shall not respond with a CTS frame.
56
57 A VHT STA that is addressed by an RTS frame in a non-HT or non-HT duplicate PPDU that has a
58
59 bandwidth signaling TA and that has the RXVECTOR parameter DYN_BANDWIDTH_IN_NON_HT
60 equal to Dynamic behaves as follows:
61 — If the NAV indicates idle, and the STA is not NSTR limited, then the STA shall respond with a CTS
62
frame in a non-HT or non-HT duplicate PPDU after a SIFS. The CTS frame’s TXVECTOR
63
64 parameters CH_BANDWIDTH and CH_BANDWIDTH_IN_NON_HT shall be set to any channel
65 width for which CCA on all secondary channels has been idle for a PIFS prior to the start of the RTS

254 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 frame and that is less than or equal to the channel width indicated in the RTS frame’s RXVECTOR
2 parameter CH_BANDWIDTH_IN_NON_HT.
3
4 • If all of the conditions in the previous paragraph are met, except for the condition “the STA is not
5 NSTR limited”, then the STA may respond with the CTS frame as described in that paragraph.
6
7 — Otherwise, the STA shall not respond with a CTS frame.
8
9
10 Change the now-shifted ninth paragraph as follows:
11
12 A non-VHT and non-S1G STA that is addressed by an RTS frame or a VHT STA that is addressed by an
13
RTS frame carried in a non-HT or non-HT duplicate PPDU that has a nonbandwidth signaling TA or a VHT
14
15 STA that is addressed by an RTS frame in a format other than non-HT or non-HT duplicate behaves as
16 follows:
17
18 — If the NAV indicates idle, and the STA is not NSTR limited, the STA shall respond with a CTS
19 frame after a SIFS.
20
21 • If all of the conditions in the previous paragraph are met, except for the condition “the STA is not
22 NSTR limited”, then the STA may respond with the CTS frame as described in that paragraph.
23
24 — Otherwise, the STA shall not respond with a CTS frame.
25
26 Insert the following paragraphs at the end of the subclause:
27
28
29 (#1936)An EHT STA that is addressed by an RTS frame in a non-HT or non-HT duplicate PPDU that has a
30 bandwidth signaling TA and that has the RXVECTOR parameter DYN_BANDWIDTH_IN_NON_HT
31 equal to Static behaves as follows:
32
33 — If the NAV indicates idle, the STA is not NSTR limited, and CCA has been idle for all nonpunctured
34 nonprimary 20 MHz subchannels based on the rules defined in 36.3.20.6.4 (Per 20 MHz CCA sensi-
35 tivity) in the channel width indicated by the RTS frame’s RXVECTOR parameter CH_BAND-
36
37 WIDTH_IN_NON_HT for a PIFS prior to the start of the RTS frame, then the STA shall respond
38 with a CTS frame carried in a non-HT or non-HT duplicate PPDU after a SIFS. The CTS frame’s
39 TXVECTOR parameters CH_BANDWIDTH and CH_BANDWIDTH_IN_NON_HT shall be set to
40 the same value as the RTS frame’s RXVECTOR CH_BANDWIDTH_IN_NON_HT.
41
42 • If all of the conditions in the previous paragraph are met, except for the condition “the STA is not
43 NSTR limited”, then the STA may respond with the CTS frame as described in that paragraph.
44
45 — Otherwise, the STA shall not respond with a CTS frame.
46
47
48 An EHT STA that is addressed by an RTS frame in a non-HT or non-HT duplicate PPDU that has a band-
49 width signaling TA and that has the RXVECTOR DYN_BANDWIDTH_IN_NON_HT equal to Dynamic
50 behaves as follows:
51
52 — If the NAV indicates idle, and the STA is not NSTR limited, then the STA shall respond with a CTS
53 frame in a non-HT or non-HT duplicate PPDU after a SIFS. The CTS frame’s TXVECTOR parame-
54 ters CH_BANDWIDTH and CH_BANDWIDTH_IN_NOT_HT shall be set to any channel width for
55 which CCA on all nonpunctured secondary channels has been idle for a PIFS prior to the start of the
56
57 RTS frame based on the rules defined in 36.3.20.6.4 (Per 20 MHz CCA sensitivity) and that is less
58 than or equal to the channel width indicated in the RTS frame’s RXVECTOR parameter
59 CH_BANDWIDTH_IN_NON_HT.
60
61 • If all of the conditions in the previous paragraphs are met, except for the condition “the STA is
62 not NSTR limited”, then the STA may respond with the CTS frame as described in that para-
63 graph.
64
65 — Otherwise, the STA shall not respond with a CTS frame.

Copyright © 2022 IEEE. All rights reserved. 255

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 10.3.2.11 Acknowledgment procedure

2
3
4
Change the fifth paragraph as follows:
5
6 (#2100)(#2101)(#3147)Otherwise, upon reception of a frame that requires immediate acknowledgment and,
7 for an AP, with the To DS subfield equal to 1, a STA that is not NSTR limited shall transmit an Ack or Block-
8 Ack frame after a SIFS, without regard to the busy/idle state of the medium and a STA that is NSTR limited
9
may transmit an Ack or BlockAck frame after a SIFS, without regard to the busy/idle state of the medium.
10
11 (See Figure 10-12 (Individually addressed data/Ack/BlockAck frame)).
12
13 10.3.2.14 Duplicate detection and recovery
14
15
10.3.2.14.2 Transmitter requirements
16
17
18 Change the first paragraph as follows:
19
20 A STA maintains one or more sequence number spaces that are used when transmitting a frame to determine
21
the sequence number for the frame. (#2751)An MLD maintains one or more sequence number spaces that are
22
23 used when a STA(#4840) affiliated with the MLD transmits an individually addressed QoS Data frame to a
24 STA(#4840) affiliated with an associated MLD to determine the sequence number for the frame. (#2496)An
25 MLD with dot11QMFActivated equal to false maintains a single(#6679) sequence number space that is used
26 when a STA affiliated with the MLD transmits an individually addressed Management frame (except the
27
frames that are excluded in 35.3.14 (Multi-link device individually addressed Management frame deliv-
28
29 ery(#2496))) to a STA affiliated with another MLD to determine the sequence number for the frame. When
30 multiple sequence number spaces are supported, the appropriate sequence number space is determined by
31 information from the MAC control fields of the frame to be transmitted. Except as noted below, each sequence
32 number space is represented by a modulo 4096 counter, starting at 0 and incrementing by 1, for each MSDU or
33
MMPDU transmitted using that sequence number space. If dot11MACPrivacyActivated is true, the counter in
34
35 each sequence number space shall be set to a random number modulo 4096 when the STA’s MAC address is
36 changed.
37
38 Change the fourth paragraph as follows:
39
40
41 A transmitting STA shall support the applicable sequence number spaces defined in Table 10-5 (Transmitter
42 sequence number spaces). An MLD shall support the applicable sequence number spaces defined in
43 Table 10-5 (Transmitter sequence number spaces). (#2751)A STA affiliated with an MLD shall support
44 SNS9 maintained by the MLD(#6680) instead of SNS2 in Table 10-5 (Transmitter sequence number spaces)
45
to determine the sequence number of an individually addressed QoS Data frame that is transmitted to a STA
46
47 affiliated with the associated MLD. (#2496)A STA affiliated with an MLD shall support SNS10 maintained
48 by the MLD(#6681) instead of SNS1 in Table 10-5 (Transmitter sequence number spaces) to determine the
49 sequence number of an individually addressed Management frame (except the frames that are excluded in
50 35.3.14 (Multi-link device individually addressed Management frame delivery(#2496))) that is transmitted
51
to a STA affiliated with another MLD. (#6651)An AP affiliated with an AP MLD shall support SNS11
52
53 maintained at the MLD level, instead of SNS1 maintained at the link level, in Table 10-5 (Transmitter
54 sequence number spaces) to determine the sequence number of a group addressed Data frame that is trans-
55 mitted to a STA associated to the AP, where the same group addressed Data frame transmitted over multiple
56 links of the AP MLD shall use the same sequence number for transmission on each link. Applicability is
57
defined by the Applies to column. The Status column indicates the level of support that is required if the
58
59 Applies to column matches the transmission. The Multiplicity column indicates whether the sequence num-
60 ber space contains a single counter, or multiple counters and in the latter case identifies any indexes. The
61 Transmitter requirements column identifies requirements for the operation of this sequence number space.
62 The referenced requirements are defined at the end of the table.
63
64
65

256 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Insert two new rows to Table 10-5 (Transmitter sequence number spaces):.
2
3
4
Table 10-5—Transmitter sequence number spaces
5
6
7 Sequence
8 Sequence
number Transmitter
9 number Applies to Status Multiplicity
space requirements
10 space
identifier
11
12 SNS9(#27 Individually Any STA affiliated with an Mandatory Indexed by
13 51) addressed MLD transmitting an individ- <MLD MAC
14 QoS Data ually addressed QoS Data Address that
15 frame that is not a QoS(+) the STA iden-
16 Null frame to a STA affiliated tified by
17 with the associated Address 1 is
18 MLD.(#1162)(#2751) affiliated with,
19 TID> per
20 MLD
21
22 SNS10(#2 Individually Any STA affiliated with an Manda- Indexed by
23 496) addressed MLD transmitting an individ- tory(#2496) <MLD MAC
24 Management ually addressed Management Address that
25 frame (except frame (except the frames that the STA iden-
26 the frames are excluded in 35.3.14 tified by
27 that are (Multi-link device individu- Address 1 is
28 excluded in ally addressed Management affiliated
29 35.3.14 frame delivery(#2496))) to a with> per
30 (Multi-link STA affiliated with another MLD(#2496)
31 device indi- MLD.(#2496)
32 vidually
33 addressed
34 Management
35 frame deliv-
36 ery(#2496)))(
37 #2496)
38
39 SNS11(#6 Group Any AP affiliated with an AP Manda- Single
40 651) addressed MLD transmitting a group tory(#6651) instance per
41 data(#6651) addressed Data frame(#6651) AP
42 MLD(#6651)
43
44
45
46
10.3.2.14.3 Receiver requirements
47
48
49
50 Change the first paragraph as follows:
51
52
53 A STA maintains one or more duplicate detection caches. An MLD maintains one or more duplicate detection
54 caches. Table 10-6 (Receiver caches) defines the conditions under which a duplication detection cache is sup-
55 ported and the rules followed by the receiver for the cache. When a Data, Management or Extension frame is
56 received, a record of that frame is inserted in an appropriate cache. That record is identified by a sequence num-
57
58 ber and possibly other information from the MAC control fields of the frame. When a Data, Management or
59 Extension frame is received in which the Retry subfield of the Frame Control field is equal to 1, the appropriate
60 cache, if any, is searched for a matching frame. In DMG, when a group addressed frame is received the appro-
61 priate cache is searched for a matching frame. When a PV1 Data frame or PV1 Management frame is
62 received, the appropriate cache is searched for a matching frame, regardless of the presence of the Retry sub-
63
64 field of the Frame Control field. If the search is successful, the frame is considered to be a duplicate. Duplicate
65 frames are discarded.

Copyright © 2022 IEEE. All rights reserved. 257

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Change the third paragraph as follows:

2
3
4 A receiving STA shall implement the applicable receiver requirements defined in Table 10-6 (Receiver
5 caches) with Status indicated as Mandatory. An MLD shall implement the applicable receiver requirements
6 defined in Table 10-6 (Receiver caches) with Status indicated as Mandatory. (#2751)All STAs affiliated
7 with an MLD shall implement RC14(#6682), where the duplicate detection cache is maintained by the
8
MLD, instead of RC2 in Table 10-6 (Receiver caches) to assist the MLD in discarding duplicate individually
9
10 addressed QoS Data frames belonging to a TID without BA negotiation that are transmitted from the STAs
11 affiliated with the associated MLD. (#2496)All STAs affiliated with an MLD with dot11QMFActivated
12 equal to false shall implement RC15(#6683), where the duplicate detection cache is maintained by the MLD,
13 instead of RC1 in Table 10-6 (Receiver caches) to assist the MLD in discarding duplicate individually
14
addressed Management frame (except the frames that are excluded in 35.3.14 (Multi-link device individu-
15
16 ally addressed Management frame delivery(#2496))) that are transmitted from the STAs affiliated with the
17 associated MLD. (#6651)An MLD shall implement RC16 maintained at the MLD level, instead of RC1
18 maintained at the link level, in Table 10-6 (Receiver caches) to discard duplicate group addressed Data that
19 are delivered from the associated MLD. A group addressed Data frame received on any link shall be dis-
20
carded using an implementation specific duplicate detention mechanism. A receiving STA should imple-
21
22 ment the applicable receiver requirements defined in Table 10-6 (Receiver caches) with Status indicated as
23 Recommended. A receiving STA (#6651)and a receiving MLD may implement the applicable receiver
24 requirements defined in Table 10-6 (Receiver caches) with Status indicated as Optional. Applicability is
25 defined by the Applies to column. The Status column indicates the level of support that is required if the
26
Applies to column matches the received frame. The Multiplicity / Cache size column indicates the indexes
27
28 that identify a cache entry and the number of entries that shall be supported. The Receiver requirements col-
29 umn identifies requirements for the operation of this cache. The referenced requirements are defined at the
30 end of the table. The requirements relate to caching information that identifies a cache entry and discarding
31 duplicate MPDUs.
32
33
34 Change the existing rows RC1 and RC2, insert two new rows and a new footnote after RR6 to
35 Table 10-6 (Receiver caches):
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

258 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 10-6—Receiver caches

2
3
4 Receiver
Cache Multiplicity / Cache Receiver
5 cache Applies to Status
name size requirements
6 identifier
7
8 RC1 Not QoS A STA receiving frames Mandatory Indexed by: <Address 2, RR1
9 Data (individually or group sequence number, frag- RR2
10 addressed) that are not ment number>. RR5
11 QoS Data, excluding if
12 supported: At least the most recent
13 RC4 cache entry per
14 RC5 <Address 2>.
15 RC6
16 RC7
17 RC8
18 RC10
19 RC15(#2496)
20
21 RC2 QoS A STA receiving an (indi- Mandatory Indexed by: <Address 2, RR1
22 Data vidually or group TID, sequence number, RR5
23 addressed) QoS Data fragment number>.
24 frame, excluding RC3,
25 and if supported: At least the most recent
26 RC7, RC8, RC9, and cache entry per
27 RC10, and <Address 2, TID> pair
28 RC14(#1163)(#2751) in this cache.
29
30 RC14(#275 Individu Any STA affiliated with Mandatory Indexed by <MLD RR7(#2751)
31 1) ally an MLD receiving an MAC address that the
32 addresse individually addressed STA identified by
33 d QoS QoS Data frame that is Address 2 is affiliated
34 Data not a QoS(+) Null frame with, TID, sequence
35 from a STA affiliated number> per MLD.
36 with the associated
37 MLD.(#1163)(#2751) At least the most recent
38 cache entry per <MLD
39 MAC address that the
40 STA identified by
41 Address 2 is affiliated
42 with, TID> pair in this
43 cache.(#2751)
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 259

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 10-6—Receiver caches (continued)

2
3
4 Receiver
Cache Multiplicity / Cache Receiver
5 cache Applies to Status
name size requirements
6 identifier
7
8 RC15(#249 Individ- Any STA affiliated with Mandatory( Indexed by <MLD RR7(#2496)
9 6) ually an MLD with #2496) MAC address that the
10 addresse dot11QMFActivated STA identified by
11 d Man- equal to false receiving Address 2 is affiliated
12 age- an individually addressed with, sequence number>
13 ment Management frame per MLD. At least the
14 frame (except the frames that most recent cache entry
15 (except are excluded in 35.3.14 per MLD MAC address
16 the (Multi-link device that the STA identified
17 frames individually addressed by Address 2 is
18 that are Management frame affiliated with in this
19 exclude delivery(#2496))) from a cache.(#2496)
20 d in STA affiliated with
21 35.3.14 another MLD.(#2496)
22 (Multi-
23 link
24 device
25 individ-
26 ually
27 addresse
28 d Man-
29 age-
30 ment
31 frame
32 deliv-
33 ery(#24
34 96)))(#2
35 496)
36
37
38 RC16(#665 Group Any STA affiliated with Mandatory( Indexed by <MLD RR8(#6651)
39 1) addresse an MLD receiving a #6651) MAC Address that the
40 d group addressed Data STA identified by
41 Data(#6 frame(#6651) Address 2 is affiliated
42 651) with, sequence number>
43 per MLD. At least the
44 most recent cache entry
45 per MLD MAC address
46 that the STA identified
47 by Address 2 is
48 affiliated with in this
49 cache.(#6651)
50
51 (#2751)RR7: The MLD shall discard the frame if the Retry subfield of the Frame Control field is 1 and it matches
52 an entry in the cache.
53 (#6651)RR8: The MLD shall discard the frame based on an implementation specific duplicate detention
54 mechanism.
55
56
57
58
59
60
61
62
63
64
65

260 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 10.6 Multirate support

2
3
4 10.6.1 Overview
5
6 Change the fifth and sixth paragraphs as follows:
7
8
9 For specific PHYs, the value of the Duration/ID field is determined using the PLME-TXTIME.request
10 primitive and the PLME-TXTIME.confirm primitive. These specific PHYs are defined in:
11 — Clause 16 (High rate direct sequence spread spectrum (HR/DSSS) PHY specification) for HR/DSSS
12
13 — Clause 17 (Orthogonal frequency division multiplexing (OFDM) PHY specification) for OFDM
14
— Clause 18 (Extended Rate PHY (ERP) specification) for ERP
15
16 — Clause 19 (High-throughput (HT) PHY specification) for HT
17
18 — Clause 20 (Directional multi-gigabit (DMG) PHY specification) for DMG
19 — Clause 21 (Very high throughput (VHT) PHY specification) for VHT
20
21 — Clause 22 (Television very high throughput (TVHT) PHY specification) for TVHT
22 — Clause 24 (China directional multi-gigabit (CDMG) PHY specification) for CDMG
23
24 — Clause 25 (China millimeter-wave multi-gigabit (CMMG) PHY specification) for CMMG
25
— Clause 27 (High Efficiency (HE) PHY specification) for HE
26
27 — (#1141)Clause 36 (Extremely high throughput (EHT) PHY specification) for EHT
28
29
30
The two PLME-TXTIME primitives are defined in the respective PHY specifications:
31 — 16.3.4 (HR/DSSS TXTIME calculation) for HR TXTIME calculation
32
33 — 17.4.3 (OFDM TXTIME calculation) for OFDM TXTIME calculation
34 — 18.5.3.2 (ERP-OFDM TXTIME calculations) for ERP-OFDM TXTIME calculation
35
36 — 19.4.3 (TXTIME calculation) for HT TXTIME calculation
37 — 20.11.3 (TXTIME calculation) for DMG PLME TXTIME calculation
38
39 — 21.4.3 (TXTIME and PSDU_LENGTH calculation) for VHT PLME TXTIME calculation
40
41
— 22.4.3 (TXTIME and PSDU_LENGTH calculation) for TVHT PLME TXTIME calculation
42 — 25.14.3 (TXTIME calculation) for CMMG PLME TXTIME calculation
43
44 — 27.4.3 (TXTIME and PSDU_LENGTH calculation) for HE PLME TXTIME calculation
45 — (#1141)36.4.3 (TXTIME and PSDU_LENGTH calculation) for EHT PLME TXTIME calculation
46
47
48 10.6.6 Rate selection for Control frames
49
50 10.6.6.1 General rules for rate selection for Control frames
51
52
53 Change the last paragraph as follows:
54
55 An HE STA that transmits a Trigger frame, Multi-STA BlockAck frame or HE/VHT/HE NDP Announce-
56 ment frame(#1769) addressed to more than one STA shall use a rate, HT-MCS, <VHT-MCS, NSS> tuple or
57
58
<HE-MCS, NSS> tuple that is supported by all recipient STAs. An EHT STA shall use an <EHT_MCS,
59 NSS> tuple that is supported by all recipient STAs if the PPDU carrying any of these frames is an EHT
60 PPDU(#8303)(#1102)(#1740)(#1846)(#1916)(#2572)(#3363).
61
62 10.6.10 Modulation classes
63
64
65 Change Table 10-9 (Modulation classes(#1141)) as follows:

Copyright © 2022 IEEE. All rights reserved. 261

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 10-9—Modulation classes(#1141)

2
3
4 Condition that selects this modulation class
5
6 Clause 15 (DSSS
7 PHY
8 specification for
9 the 2.4 GHz band
10 designated for
11 ISM
12 applications) to
13 Clause 18 (Exten
14 ded Rate PHY
15 (ERP)
16 specification)
17 PHYs or
18 Clause 36
Description Clause 20 (Direct Clause 21 (Ver
19 Clause 19 (Hig Clause 27 (Hig (Extremely
of ional multi- y high
20 h-throughput h Efficiency high
modulation gigabit (DMG) throughput
21 (HT) PHY (HE) PHY throughput
PHY (VHT) PHY
22 specification) specification) (EHT) PHY
specification) specification)
23 PHY PHY specification)
PHY, or PHY
24 PHY
Clause 24 (China
25 directional multi-
26 gigabit (CDMG)
27 PHY
28 specification)
29 PHY, or
30 Clause 25 (China
31 millimeter-wave
32 multi-gigabit
33 (CMMG) PHY
34 specification)
35 PHY
36
37 DSSS and Clause 15 (DSSS FORMAT is N/A FORMAT is FORMAT is
38 HR/DSSS PHY specification NON_HT. NON_HT. NON_HT.
39 for the 2.4 GHz NON_HT_- NON_HT_- NON_HT_-
40 band designated MODULA- MODULA- MODULA-
41 for ISM applica- TION is ERP- TION is ERP- TION is ERP-
42 tions) or DSSS or ERP- DSSS or ERP- DSSS or ERP-
43 Clause 16 (High CCK. CCK. CCK.
44 rate direct
45 sequence spread
46 spectrum (HR/
47 DSSS) PHY speci-
48 fication) transmis-
49 sion
50
51 ERP-OFDM 18.4 (ERP operat- FORMAT is N/A FORMAT is FORMAT is
52 ing specifications NON_HT. NON_HT. NON_HT.
53 (general)) trans- NON_HT_- NON_HT_- NON_HT_-
54 mission MODULA- MODULA- MODULA-
55 TION is ERP- TION is ERP- TION is ERP-
56 OFDM. OFDM. OFDM.
57
58
59
60
61
62
63
64
65

262 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 10-9—Modulation classes(#1141)

2
3
4 Condition that selects this modulation class
5
6 Clause 15 (DSSS
7 PHY
8 specification for
9 the 2.4 GHz band
10 designated for
11 ISM
12 applications) to
13 Clause 18 (Exten
14 ded Rate PHY
15 (ERP)
16 specification)
17 PHYs or
18 Clause 36
Description Clause 20 (Direct Clause 21 (Ver
19 Clause 19 (Hig Clause 27 (Hig (Extremely
of ional multi- y high
20 h-throughput h Efficiency high
modulation gigabit (DMG) throughput
21 (HT) PHY (HE) PHY throughput
PHY (VHT) PHY
22 specification) specification) (EHT) PHY
specification) specification)
23 PHY PHY specification)
PHY, or PHY
24 PHY
Clause 24 (China
25 directional multi-
26 gigabit (CDMG)
27 PHY
28 specification)
29 PHY, or
30 Clause 25 (China
31 millimeter-wave
32 multi-gigabit
33 (CMMG) PHY
34 specification)
35 PHY
36
37 OFDM Clause 17 (Orthog FORMAT is FORMAT is FORMAT is FORMAT is
38 onal frequency NON_HT. NON_HT. NON_HT. NON_HT.
39 division multi- NON_HT_- NON_HT_- NON_HT_- NON_HT_-
40 plexing (OFDM) MODULA- MODULA- MODULA- MODULA-
41 PHY specifica- TION is OFDM TION is OFDM TION is OFDM TION is OFDM
42 tion) transmission or or or or
43 NON_HT_DUP NON_HT_DUP NON_HT_DUP NON_HT_DUP
44 _OFDM. _OFDM. _OFDM. _OFDM.
45
46 HT N/A FORMAT is FORMAT is FORMAT is FORMAT is
47 HT_MF or HT_MF or HT_MF or HT_MF or
48 HT_GF. HT_GF. HT_GF. HT_GF.
49
50 DMG Con- Clause 20 (Directi N/A N/A N/A N/A
51 trol onal multi-gigabit
52 (DMG) PHY spec-
53 ification) trans-
54 mission and MCS
55 is 0
56
57 DMG SC Clause 20 (Directi N/A N/A N/A N/A
58 onal multi-gigabit
59 (DMG) PHY spec-
60 ification) trans-
61 mission and
62 1  MCS  12.6
63
64
65

Copyright © 2022 IEEE. All rights reserved. 263

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 10-9—Modulation classes(#1141)

2
3
4 Condition that selects this modulation class
5
6 Clause 15 (DSSS
7 PHY
8 specification for
9 the 2.4 GHz band
10 designated for
11 ISM
12 applications) to
13 Clause 18 (Exten
14 ded Rate PHY
15 (ERP)
16 specification)
17 PHYs or
18 Clause 36
Description Clause 20 (Direct Clause 21 (Ver
19 Clause 19 (Hig Clause 27 (Hig (Extremely
of ional multi- y high
20 h-throughput h Efficiency high
modulation gigabit (DMG) throughput
21 (HT) PHY (HE) PHY throughput
PHY (VHT) PHY
22 specification) specification) (EHT) PHY
specification) specification)
23 PHY PHY specification)
PHY, or PHY
24 PHY
Clause 24 (China
25 directional multi-
26 gigabit (CDMG)
27 PHY
28 specification)
29 PHY, or
30 Clause 25 (China
31 millimeter-wave
32 multi-gigabit
33 (CMMG) PHY
34 specification)
35 PHY
36
37 DMG Low- Clause 20 (Directi N/A N/A N/A N/A
38 power SC onal multi-gigabit
39 (DMG) PHY spec-
40 ification) trans-
41 mission and
42 25  MCS  31
43
44 VHT N/A N/A FORMAT is FORMAT is FORMAT is
45 VHT. VHT. VHT.
46
47 CDMG Con- Clause 24 (China N/A N/A N/A N/A
48 trol directional multi-
49 gigabit (CDMG)
50 PHY specifica-
51 tion) transmission
52 and MCS is 0
53
54 CDMG SC Clause 24 (China N/A N/A N/A N/A
55 directional multi-
56 gigabit (CDMG)
57 PHY specifica-
58 tion) transmission
59 and
60 1  MCS  16
61
62
63
64
65

264 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 10-9—Modulation classes(#1141)

2
3
4 Condition that selects this modulation class
5
6 Clause 15 (DSSS
7 PHY
8 specification for
9 the 2.4 GHz band
10 designated for
11 ISM
12 applications) to
13 Clause 18 (Exten
14 ded Rate PHY
15 (ERP)
16 specification)
17 PHYs or
18 Clause 36
Description Clause 20 (Direct Clause 21 (Ver
19 Clause 19 (Hig Clause 27 (Hig (Extremely
of ional multi- y high
20 h-throughput h Efficiency high
modulation gigabit (DMG) throughput
21 (HT) PHY (HE) PHY throughput
PHY (VHT) PHY
22 specification) specification) (EHT) PHY
specification) specification)
23 PHY PHY specification)
PHY, or PHY
24 PHY
Clause 24 (China
25 directional multi-
26 gigabit (CDMG)
27 PHY
28 specification)
29 PHY, or
30 Clause 25 (China
31 millimeter-wave
32 multi-gigabit
33 (CMMG) PHY
34 specification)
35 PHY
36
37 CDMG  Clause 24 (China N/A N/A N/A N/A
38 Low-power directional multi-
39 SC gigabit (CDMG)
40 PHY specifica-
41 tion) transmission
42 and
43 17  MCS  23
44
45 CMMG Clause 25 (China N/A N/A N/A N/A
46 Control millimeter-wave
47 multi-gigabit
48 (CMMG) PHY
49 specification)
50 transmission and
51 MCS is 0
52
53 CMMG SC Clause 25 (China N/A N/A N/A N/A
54 millimeter-wave
55 multi-gigabit
56 (CMMG) PHY
57 specification)
58 transmission and
59 1  MCS  8
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 265

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 10-9—Modulation classes(#1141)

2
3
4 Condition that selects this modulation class
5
6 Clause 15 (DSSS
7 PHY
8 specification for
9 the 2.4 GHz band
10 designated for
11 ISM
12 applications) to
13 Clause 18 (Exten
14 ded Rate PHY
15 (ERP)
16 specification)
17 PHYs or
18 Clause 36
Description Clause 20 (Direct Clause 21 (Ver
19 Clause 19 (Hig Clause 27 (Hig (Extremely
of ional multi- y high
20 h-throughput h Efficiency high
modulation gigabit (DMG) throughput
21 (HT) PHY (HE) PHY throughput
PHY (VHT) PHY
22 specification) specification) (EHT) PHY
specification) specification)
23 PHY PHY specification)
PHY, or PHY
24 PHY
Clause 24 (China
25 directional multi-
26 gigabit (CDMG)
27 PHY
28 specification)
29 PHY, or
30 Clause 25 (China
31 millimeter-wave
32 multi-gigabit
33 (CMMG) PHY
34 specification)
35 PHY
36
37 CMMG Clause 25 (China N/A N/A N/A N/A
38 OFDM millimeter-wave
39 multi-gigabit
40 (CMMG) PHY
41 specification)
42 transmission and
43 9  MCS  16
44
45 HE N/A N/A N/A FORMAT is FORMAT is
46 HE_SU, HE_SU,
47 HE_ER_SU, HE_ER_SU,
48 HE_MU or HE_MU or
49 HE_TB HE_TB
50
51 EHT N/A N/A N/A N/A FORMAT is
52 EHT_MU or
53 EHT_TB
54
55
56
57
58
59
60
61
62
63
64
65

266 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 10.6.11 Non-HT basic rate calculation

2
3
4 Change as follows:
5
6
7 (#1141)(#1142)This subclause defines how to convert an HT-MCS, a VHT-MCS, or an HE-MCS, or an EHT-
8 MCS to a non-HT basic rate for the purpose of determining the rate of the response frame. It consists of two
9 steps as follows:
10
11 a) (#1141)(#1142)Use the modulation and coding rate determined from the HT-MCS (defined in
12 19.5 (Parameters for HT-MCSs)), or VHT-MCS (defined in 21.5 (Parameters for VHT-MCSs)), or
13 HE-MCS (defined in 27.5 (Parameters for HE-MCSs) or EHT-MCS (defined in 36.5 (Parameters
14
15
for EHT-MCSs)) to locate a non-HT reference rate by lookup into Table 10-10 (Non-HT reference
16 rate).1 In the case of an MCS with UEQM, the modulation of stream 1 is used.
17
18 b) The non-HT basic rate is the highest rate in the BSSBasicRateSet that is less than or equal to this
19 non-HT reference rate.
20
21
22 Table 10-10—Non-HT reference rate
23
24
25 Coding rate Non-HT reference rate
26 Modulation
(R) (Mb/s)
27
28 BPSK 1/2 6
29
30 BPSK 3/4 9
31
32 QPSK 1/2 12
33
QPSK 3/4 18
34
35 16-QAM 1/2 24
36
37 16-QAM 3/4 36
38
39 64-QAM 1/2 48
40
41 64-QAM 2/3 48
42
64-QAM 3/4 54
43
44 64-QAM 5/6 54
45
46 256-QAM 3/4 54
47
48 256-QAM 5/6 54
49
50 1024-QAM 3/4 54
51
1024-QAM 5/6 54
52
53 (#1141)(#1142)4 3/4 54
54 096-QAM
55
56 (#1141)(#1142)4 5/6 54
57 096-QAM
58
59
60
61 (#1141)(#1142)NOTE 1—The selection of a non-HT basic rate for the frame sent in response to an HE or EHT PPDU is
62 not influenced by DCM encoding in the HE or EHT PPDU.
63
64 1
65 For example, if an HT PPDU transmission uses 64-QAM and coding rate of 3/4, the related non-HT reference rate is 54 Mb/s.

Copyright © 2022 IEEE. All rights reserved. 267

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 NOTE 2—In a TVWS band, the non-HT reference rate is scaled as described in 22.2.4 (Support for NON_HT and HT
2 formats).
3
4
5 10.8 HT Control field operation
6
7
8 Change the following entry of Table 10-12 (Conditions for including Control subfield variants)
9 (only relevant row shown):
10
11
12
13 Table 10-12—Conditions for including Control subfield variants
14
15
16 Control subfield
Condition
17 variant
18
19 ONES The transmitting STA may include a ONES Control subfield in an MPDU that is not
20 carried in an HE TB PPDU (see 26.5.2.4 (A-MPDU contents in an HE TB PPDU))
21 (#6483)or an EHT TB PPDU when there is nothing to report in A-Control subfield.
22
23
24
25 10.11 A-MSDU operation
26
27
28 Change the 23rd paragraph as follows:
29
30 The length of an A-MSDU transmitted in a VHT PPDU or HE PPDU (#6630)or EHT PPDU is limited by
31
the maximum MPDU size supported by the recipient STA (see 10.12.5 (Transport of A-MPDU by the PHY
32
33 data service)).
34
35
36 10.12 A-MPDU operation
37
38
39 10.12.2 A-MPDU length limit rules
40
41
42
Change the first paragraph as follows:
43
44 A STA indicates in the Maximum A-MPDU Length Exponent field in its HT Capabilities element the maxi-
45 mum A-MPDU length that it can receive in an HT PPDU. A STA indicates in the Maximum A-MPDU
46
47 Length Exponent field in its VHT Capabilities element the maximum length of the A-MPDU pre-EOF pad-
48 ding that it can receive in a VHT PPDU. A STA indicates in the Maximum A-MPDU Length Exponent field
49 in its S1G Capabilities element the maximum length of the A-MPDU pre-EOF padding that it can receive in
50 an S1G PPDU. A STA indicates in the Maximum A-MPDU Length Exponent field in its DMG Capabilities
51 element the maximum A-MPDU length that it can receive in a DMG PPDU. A STA indicates the maximum
52
53 length of the A-MPDU pre-EOF padding that it can receive in an HE PPDU in the Maximum A-MPDU
54 Length Exponent field in its HT Capabilities, VHT Capabilities, and HE 6 GHz Band Capabilities elements
55 (if present) and in the Maximum A-MPDU Length Exponent Extension field in its HE Capabilities element.
56 A STA indicates in the Maximum A-MPDU Length Exponent field in its EDMG Capabilities element the
57 maximum length of the A-MPDU that it can receive in an EDMG PPDU. (#4295)A STA indicates the max-
58
59 imum length of the A-MPDU pre-EOF padding that it can receive in an EHT PPDU in the Maximum A-
60 MPDU Length Exponent field in its HT Capabilities, VHT Capabilities, and (if present) HE 6 GHz Band
61 Capabilities elements, and in the Maximum A-MPDU Length Exponent Extension field in HE Capabilities
62 and EHT Capabilities elements.
63
64
65 Change the third paragraph as follows:

268 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Using the Maximum A-MPDU Length Exponent fields in the HT Capabilities, VHT Capabilities,
2 (#4295)HE Capabilities, and HE 6 GHz Band Capabilities elements (if present) and the Maximum A-
3
MPDU Length Exponent Extension fields in the HE Capabilities and EHT Capabilities elements, the STA
4
5 establishes at association the maximum length of an A-MPDU pre-EOF padding that can be sent to it. An
6 HT STA shall support receiving A-MPDUs of length up to the value indicated by the Maximum A-MPDU
7 Length Exponent field in its HT Capabilities element. A VHT STA shall support receiving A-MPDUs where
8 the A-MPDU pre-EOF padding length is up to the value indicated by the Maximum A-MPDU Length Expo-
9
nent field in its VHT Capabilities element. An S1G STA that sets the A-MPDU Supported subfield in the
10
11 S1G Capabilities element to 1 shall support receiving A-MPDUs where the A-MPDU pre-EOF padding
12 length is up to the value indicated by the Maximum A-MPDU Length Exponent field in its S1G Capabilities
13 element.
14
15
16 Insert the following paragraph after the fourth paragraph (“An HE STA shall support ...”):
17
18 (#4295)An EHT STA shall support receiving A-MPDUs where A-MPDU pre-EOF padding length is up to
19
the value indicated by the Maximum A-MPDU Length Exponent field in its HT Capabilities and VHT Capa-
20
21 bilities elements and the Maximum A-MPDU Length Exponent Extension field in its HE Capabilities and
22 EHT Capabilities elements in the 2.4 GHz or 5 GHz bands. An EHT STA shall support receiving A-MPDUs
23 where the A-MPDU pre-EOF padding length is up to value indicated by the Maximum A-MPDU Length
24 Exponent field in HE 6 GHz Band Capabilities and the Maximum A-MPDU Length Exponent Extension
25
field in the HE Capabilities and EHT Capabilities elements in the 6 GHz band.
26
27
28 Insert the following paragraph after the now-shifted seventh paragraph (“A STA shall not
29 transmit A-MPDU in an HE PPDU ...”):
30
31
32 (#4295)A STA shall not transmit an A-MPDU in an EHT PPDU where the A-MPDU pre-EOF padding
33 length is greater than the value indicated by the Maximum A-MPDU Length Exponent field in the HT Capa-
34 bilities and VHT Capabilities elements and the Maximum A-MPDU Length Exponent Extension field in its
35
HE Capabilities and EHT Capabilities elements received from the intended receiver in the 2.4 GHz or
36
37 5 GHz bands. A STA shall not transmit an A-MPDU in EHT PPDU where the A-MPDU pre-EOF padding
38 length is greater than the value indicated by the Maximum A-MPDU Length Exponent field in the HE
39 6 GHz Band Capabilities element and the Maximum A-MPDU Length Exponent Extension field in the HE
40 Capabilities and EHT Capabilities elements received from the intended receiver in the 6 GHz band.
41
42
43 10.12.3 Minimum MPDU start spacing rules
44
45
46 Change the first paragraph, including Equation (10-12), as follows:
47
48 If the intended receiver is a non-HE STA, a STA shall not start the transmission of more than one MPDU
49
within the time limit described in the Minimum MPDU Start Spacing field declared by the intended
50
51 receiver. If the intended receiver is an HE (#4295)or EHT STA, an HE or EHT STA shall not start the trans-
52 mission of more than one QoS Data frame, QoS Null frame, or Management frame within the time limit
53 described in the Minimum MPDU Start Spacing field declared by the intended receiver. To satisfy this
54 requirement, the number of octets between the start of two consecutive MPDUs in an A-MPDU, N, mea-
55
sured at the PHY SAP, shall meet the condition defined by Equation (10-12)(#4295).
56
57
58
59 
60  t MMSS  r  8 if the A-MPDU is not carried in an HE TB PPDU or EHT TB PPDU
N (10-12)
61  t MMSS  2 MMSF  r  8 if the A-MPDU is carried in an HE TB PPDU or EHT TB PPDU
62 
63
64
65 where

Copyright © 2022 IEEE. All rights reserved. 269

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 t MMSS is the time (in microseconds) defined in the Encoding column of Table 9-222 (Subfields of the
2
3 A-MPDU Parameters field) for an HT STA, of Table 9-342 (Subfields of the S1G Capabilities
4 Information field) for an S1G STA for the value of the Minimum MPDU Start Spacing field,
5 and of Table 9-288 (Subfields of the A-MPDU Parameters subfield) for a DMG STA for the
6 value of the Minimum MPDU Start Spacing field
7
8 MMSF is the value of the MPDU MU Spacing Factor subfield of the User Info field addressed to the
9 HE (#4295)or EHT STA in the Trigger frame soliciting the HE TB PPDU or the EHT TB
10 PPDU (see 9.3.1.22 (Trigger frame format))
11 r is the value of the PHY Data Rate (in megabits per second) defined in 19.5 (Parameters for
12
13 HT-MCSs) for HT PPDUs, in 21.5 (Parameters for VHT-MCSs) for VHT PPDUs, in
14 23.5 (Parameters for S1G-MCSs) for S1G PPDUs, and in Clause 20 (Directional multi-gigabit
15 (DMG) PHY specification) for a DMG STA
16
17
18
10.12.4 A-MPDU aggregation of group addressed Data frames
19
20 Change the third paragraph as follows:
21
22 (#4295)NOTE 2—As a VHT STA, and an HE STA, and an EHT STA are HT STAs, NOTE 1 also applies to VHT APs,
23 VHT mesh STAs, HE APs, and HE mesh STAs, EHT APs and EHT mesh STAs.
24
25 Change the last paragraph as follows:
26
27
28 When a STA transmits a PPDU containing at least one A-MPDU that contains MPDUs with an RA that is a
29 group address, the following shall apply:
30
31 — If the PPDU is an HT PPDU, the maximum A-MPDU length exponent value is the minimum value
32 in the Maximum A-MPDU Length Exponent subfield of the A-MPDU Parameters field of the HT
33 Capabilities element across all HT STAs associated with the transmitting AP or across all peer HT
34
mesh STAs.
35
36 — If the PPDU is a VHT PPDU, the maximum A-MPDU length exponent value is the minimum value
37 in the Maximum A-MPDU Length Exponent subfields of the VHT Capabilities elements across all
38
39
VHT STAs associated with the transmitting AP or across all peer VHT mesh STAs.
40 — If the PPDU is an HE PPDU sent in the 2.4 GHz or 5 GHz band, the maximum A-MPDU length
41 exponent value is the minimum value in the Maximum A-MPDU Length Exponent subfield of the
42
43 VHT Capabilities elements across all HE STAs associated with the transmitting AP or across all peer
44 HE mesh STAs.
45
— If the PPDU is an HE PPDU sent in the 6 GHz band, the maximum A-MPDU length exponent value
46
47 is the minimum value in the Maximum A-MPDU Length Exponent subfield of the HE 6 GHz Band
48 Capabilities elements across all HE STAs associated with the transmitting AP or across all peer HE
49 mesh STAs.
50
51 — (#4295)If the PPDU is an EHT PPDU sent in the 2.4 GHz or 5 GHz band, the maximum A-MPDU
52 length exponent value is the minimum value in the Maximum A-MPDU Length Exponent subfield
53 of the VHT Capabilities elements across all EHT STAs associated with the transmitting AP or across
54 all peer EHT mesh STAs.
55
56 — (#4295)If the PPDU is an EHT PPDU sent in the 6 GHz band, the maximum A-MPDU length expo-
57 nent value is the minimum value in the Maximum A-MPDU Length Exponent subfield of the HE
58 6 GHz Band Capabilities elements across all EHT STAs associated with the transmitting AP or
59
60 across all peer EHT mesh STAs.
61 — (#4295)If the PPDU is an EHT PPDU sent in the 2.4 GHz, 5 GHz or 6 GHz band, the maximum A-
62
MPDU length exponent extension value is the minimum value in the Maximum A-MPDU Length
63
64 Exponent Extension subfield of the HE Capabilities elements across all EHT STAs associated with
65 the transmitting AP or across all peer EHT mesh STAs.

270 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — If the PPDU is a VHT PPDU, the minimum MPDU start spacing value is the maximum value in the
2 Minimum MPDU Start Spacing subfields of the A-MPDU Parameters field of the HT Capabilities
3
elements across all VHT STAs associated with the transmitting AP or across all peer VHT mesh
4
5 STAs.
6 — If the PPDU is an HT PPDU transmitted by an AP, the minimum MPDU start spacing value is the
7
8 maximum value in the Minimum MPDU Start Spacing subfield of the A-MPDU Parameters field of
9 the HT Capabilities elements across all HT STAs associated with the transmitting AP or across all
10 peer HT mesh STAs.
11
12 — If the PPDU is an HE PPDU sent in the 2.4 GHz or 5 GHz band, the minimum MPDU start spacing
13 value is the maximum value in the Minimum MPDU Start Spacing subfield of the A-MPDU Param-
14 eters field of the HT Capabilities elements across all HE STAs associated with the transmitting AP or
15 across all peer HE mesh STAs.
16
17 — If the PPDU is an HE PPDU sent in the 6 GHz band, the minimum MPDU start spacing value is the
18 maximum value in the Minimum MPDU Start Spacing subfield of the HE 6 GHz Band Capabilities
19 elements across all HE STAs associated with the transmitting AP or across all peer HE mesh STAs.
20
21 — (#4295)If the PPDU is an EHT PPDU sent in the 2.4 GHz or 5 GHz band, the minimum MPDU start
22 spacing value is the maximum value in the Minimum MPDU Start Spacing subfield of the A-MPDU
23 Parameters field of the HT Capabilities elements across all EHT STAs associated with the transmit-
24
25 ting AP or across all peer EHT mesh STAs.
26 — (#4295)If the PPDU is an EHT PPDU sent in the 6 GHz band, the minimum MPDU start spacing
27
28
value is the maximum value in the Minimum MPDU Start Spacing subfield of the HE 6 GHz Band
29 Capabilities elements across all EHT STAs associated with the transmitting AP or across all peer
30 EHT mesh STAs.
31
32 — If the PPDU is a DMG PPDU, the maximum A-MPDU length exponent value is the minimum value
33 in the Maximum A-MPDU Length Exponent subfield of the A-MPDU Parameters field of the DMG
34 Capabilities element of all DMG STAs associated with the AP or PCP.
35
36 — If the PPDU is a DMG PPDU, the minimum MPDU start spacing value is the maximum value in the
37 Minimum MPDU Start Spacing subfield of the A-MPDU Parameters field of the DMG Capabilities
38 element of all DMG STAs associated with the AP or PCP.
39
40 — If the PPDU is an S1G PPDU, the maximum A-MPDU length exponent value is the minimum value
41 in the Maximum A-MPDU Length Exponent subfields of the S1G Capabilities Information field of
42 the S1G Capabilities elements across all S1G STAs associated with the transmitting AP.
43
44 — If the PPDU is an S1G PPDU, the minimum MPDU start spacing value is the maximum value in the
45 Minimum MPDU Start Spacing subfields of the S1G Capabilities Information field of the S1G Capa-
46 bilities elements across all S1G STAs associated with the transmitting AP.
47
48 — If the PPDU is an EDMG PPDU, the maximum A-MPDU length exponent value that applies is the
49 minimum value in the Maximum A-MPDU Length Exponent subfield of the A-MPDU Parameters
50 field of the EDMG Capabilities element of all EDMG STAs associated with the AP or PCP.
51
52 — If the PPDU is an EDMG PPDU, the minimum MPDU start spacing value that applies is the maxi-
53 mum value in the Minimum MPDU Start Spacing subfield of the A-MPDU Parameters field of the
54
EDMG Capabilities element of all EDMG STAs associated with the AP or PCP.
55
56
57 Change the title of subclause 10.12.6 as follows:
58
59
60 10.12.6 A-MPDU padding for VHT, HE, EHT or S1G PPDU
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 271

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 10.12.7 Setting the EOF/Tag field of the MPDU delimiter

2
3
4
Change the first paragraph as follows:
5
6 The EOF/Tag field may be set to 1 in an A-MPDU subframe carried in a VHT PPDU, HE PPDU,
7 (#4295)EHT PPDU or S1G PPDU if the subframe’s MPDU Length field is nonzero and the subframe is the
8 only subframe that has a nonzero MPDU Length field. The EOF/Tag field of each A-MPDU subframe with
9
an MPDU Length field with a nonzero value that is not the only A-MPDU subframe with MPDU Length
10
11 field with a nonzero value in the A-MPDU carried in a VHT PPDU or S1G PPDU shall be set to 0. The
12 EOF/Tag field shall be set to 0 in all A-MPDU subframes that are carried in an HT PPDU.
13
14
15 10.13 PPDU duration constraint
16
17 Insert the following paragraph at the end of the subclause:
18
19
20 (#4289)An EHT STA shall not transmit an EHT PPDU that has a duration (as determined by the PHY-
21 TXTIME.confirm primitive defined in 6.5.6 (PLME-TXTIME.confirm)) that is greater than aPPDUMax-
22 Time defined in Table 36-70 (EHT PHY characteristics).
23
24
25 10.15 Low-density parity check code (LDPC) operation
26
27
28 Insert the following paragraph at the end of the subclause:
29
30 (#4631)An EHT STA shall not transmit a frame in an EHT PPDU with TXVECTOR parameter FEC_COD-
31 ING set to LDPC_CODING unless the frame is addressed to an EHT STA for which the LDPC Coding In
32
33
Payload subfield in the HE Capabilities element received from that STA contained a value of 1 and
34 dot11HELDPCCodingInPayloadImplemented is true.
35
36
37 10.23 HCF
38
39 10.23.2 HCF contention based channel access (EDCA)
40
41
42 10.23.2.2 EDCA backoff procedure
43
44 Change the fourth paragraphs as follows:
45
46
(#2100)(#2101)(#3147)The backoff procedure shall be invoked by an EDCAF if any of the following events
47
48 occurs:
49 a) An MA-UNITDATA.request primitive is received or the transmit queues associated with that AC
50 have become nonempty due to the conditions in 35.3.16.4 (Nonsimultaneous transmit and receive
51
52 (NSTR) operation), either of whichthat causes an MPDU corresponding to the EDCAF’s AC to be
53 queued for transmission such that all of the following are true:
54 1) one of the transmit queues associated with that AC has now become non-empty
55
56 2) any other transmit queues associated with that AC are empty
57 3) the backoff counter has a value of 0 for that AC
58
59 4) the medium is busy on the primary channel as indicated by any of the following:
60 — physical CS
61
62 — virtual CS
63 — a nonzero TXNAV timer value
64
65 — for a mesh STA that has dot11MCCAActivated true, a nonzero RAV timer value.

272 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 b) For the EDCAF that is the TXOP holder, the transmission of the final PPDU transmitted by the
2 TXOP holder during the TXOP has completed and the TXNAV timer has expired, the PPDU does
3
not solicit an HE TB PPDU.
4
5 c) For the EDCAF that is the TXOP holder, the transmission of an MPDU in the initial PPDU of a
6 TXOP fails, as defined in this subclause, the PPDU does not solicit an HE TB PPDU.
7
8 d) A transmission attempt by the EDCAF collides internally with another EDCAF of an AC that has
9 higher priority, that is, two or more EDCAFs in the same STA are granted a TXOP at the same time.
10
e) The transmission of at least one MPDU in the final PPDU transmitted by the TXOP holder during
11
12 the TXOP for that AC has completed, the PPDU contains an MPDU that solicits an HE TB PPDU
13 and the TXNAV timer has expired.
14 f) The transmission of all MPDUs in the initial PPDU of a TXOP fails, as defined in this subclause,
15
16 and the PPDU contains an MPDU that solicits an HE TB PPDU.
17 g) If explicitly indicated, such as in 26.17.2.3.3 (Non-AP STA scanning behavior).
18
19 h) (#5290)If explicitly indicated as in 35.3.16.4 (Nonsimultaneous transmit and receive (NSTR) opera-
20 tion).
21
22 In addition, the backoff procedure may be invoked by an EDCAF if:
23
24 i) For the EDCAF that is the TXOP holder, the transmission by the TXOP holder of an MPDU in a
25 non-initial PPDU of a TXOP fails, as defined in this subclause, and an MPDU in the non-initial
26 PPDU does not solicit an HE TB PPDU.
27
28 j) The transmission by the TXOP holder of all MPDUS in a non-initial PPDU of a TXOP fails, as
29
30 defined in this subclause, and the PPDU contains an MPDU that solicits an HE TB PPDU.
31 NOTE 1—If the transmission by the TXOP holder of an MPDU in a non-initial PPDU of a TXOP failed, the STA can
32 perform either a PIFS recovery, as described in 10.23.2.8 (Multiple frame transmission in an EDCA TXOP), perform a
33 backoff as described in item e)i) above, or wait for the TXNAV timer to expire and invoke the backoff procedure per
34 item b) above. How it chooses among these options is implementation dependent.
35
36
37 A STA that performs a backoff within its existing TXOP per item e)i) above shall not extend the TXNAV timer
38 value (see 10.23.2.8 (Multiple frame transmission in an EDCA TXOP)).
39
40 NOTE 2—In other words, the backoff is a continuation of the TXOP, not the start of a new TXOP.
41
42 If the backoff procedure is invoked for reason a) or h) above, CW[AC] and QSRC[AC] shall be left
43 unchanged.
44
45
46 Change the title of the subclause 10.23.2.5 as follows:
47
48 10.23.2.5 EDCA channel access in a VHT, HE, EHT or TVHT BSS(#1936)
49
50
51 Insert items m) and n) to the fifth paragraph:
52 m) (#1936)Transmit an EHT MU PPDU if all of the 20 MHz subchannels that are not punctured were
53 idle during an interval of PIFS immediately preceding the start of the TXOP.
54
55 n) (#1936)Transmit a punctured non-HT duplicate PPDU if all of the 20 MHz subchannels that are not
56 punctured were idle during an interval of PIFS immediately preceding the start of the TXOP.
57
58
59 10.23.2.8 Multiple frame transmission in an EDCA TXOP
60
61 Change the first paragraph as follows:
62
63
64 A frame exchange, in the context of multiple frame transmission in an EDCA TXOP, may be one of the
65 following:

Copyright © 2022 IEEE. All rights reserved. 273

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — A frame not requiring immediate acknowledgment (such as a group addressed frame or a frame
2 transmitted with an ack policy that does not require immediate acknowledgment) or an A-MPDU
3
containing only such frames
4
5 — A frame requiring immediate acknowledgment (such as an individually addressed frame transmitted
6 with an ack policy that requires immediate acknowledgment) or an A-MPDU containing at least one
7
such frame, followed after SIFS by a corresponding acknowledgment frame
8
9 — (#2849)A triggering frame or an A-MPDU containing at least one such frame, followed after SIFS
10 by an HE TB PPDU or an EHT TB PPDU where the HE TB PPDU or the EHT TB PPDU is option-
11
ally followed after SIFS by an acknowledgment
12
13 — Either
14
15 — a VHT NDP Announcement frame followed after SIFS by a VHT NDP followed after SIFS by
16 an A-MPDU containing one or more VHT Compressed Beamforming frames, or
17 — a Beamforming Report Poll frame followed after SIFS by an A-MPDU containing one or more
18 VHT Compressed Beamforming frames, or
19
20 — an HE NDP Announcement frame followed after SIFS by an HE sounding NDP followed after
21 SIFS by a PPDU containing one or more HE Compressed Beamforming/CQI frames, or
22 — a broadcast HE NDP Announcement frame followed after SIFS by an HE sounding NDP
23 followed after SIFS by a BFRP Trigger frame followed by HE TB PPDUs, or
24
25 — a BFRP Trigger frame followed after SIFS by an HE TB PPDU containing one or more HE
26 Compressed Beamforming/CQI frames, or
27 — an EHT NDP Announcement frame followed after SIFS by an EHT sounding NDP followed
28 after SIFS by a PPDU containing one or more EHT Compressed Beamforming/CQI frames, or
29
30 — a broadcast EHT NDP Announcement frame followed after SIFS by an EHT sounding NDP
31 followed after SIFS by a BFRP Trigger frame followed after SIFS(#1103) by EHT TB PPDUs,
32 or
33 — a BFRP Trigger frame followed after SIFS by an EHT TB PPDU containing one or more EHT
34
35
Compressed Beamforming/CQI frames
36
37 10.23.2.9 TXOP limits
38
39
40
Change item d) of the third paragraph as follows:
41 d) Any frames required for beamforming as specified in 10.31 (Sounding PPDUs), 10.36.5 (VHT
42 sounding protocol), 26.7 (Sounding protocol), 35.7 (EHT sounding operation(#5853)(#8363)), and
43
44
10.42 (DMG beamforming).
45
46 Change the last item of the seventh paragraph as follows (not all items shown):
47
48
49
The TXOP holder may exceed the TXOP limit only if it does not transmit more than one Data or Management
50 frame in the TXOP, only if it does not transmit a DL-MU-MIMO PPDU in the TXOP, and only for the follow-
51 ing situations:
52
— Retransmission of an MPDU, not in an A-MPDU consisting of more than one MPDU
53
54 — ...
55
56 — Transmission of one of the following sequences, provided that the sequence fits within the TXOP
57 limit and it is only the response and the immediately preceding SIFS that causes the TXOP limit to
58 be exceeded:
59
60 • An HE NDP Announcement frame and HE sounding NDP
61 • An HE NDP Announcement frame and HE sounding NDP and BFRP Trigger frame
62 • A BFRP Trigger frame
63
64 • An EHT NDP Announcement frame and EHT sounding NDP
65 • An EHT NDP Announcement frame and EHT sounding NDP and BFRP Trigger frame

274 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 10.25 Block acknowledgment (block ack)

2
3
4 10.25.2 Setup and modification of the block ack parameters
5
6 Insert the following paragraph after the eleventh paragraph (“When a block ack agreement is
7 established ...”):
8
9
10 The extended buffer size in the ADDBA Request frame is advisory. When a block ack agreement is estab-
11 lished between two MLDs, the originator may change the size of its transmission window if the value in the
12 Extended Buffer Size field and the Buffer Size field of the ADDBA Response frame is larger than the value
13 in the ADDBA Request frame. If the value in the Extended Buffer Size field and the Buffer Size field of the
14 ADDBA Response frame is smaller than the value in the ADDBA Request frame, the originator shall
15
16 change the size of its transmission window (WinSizeO) so that it meets the following condition:
17 — Not greater than 1024 if the sender of the ADDBA Response frame is an EHT STA.
18
19
20 10.29 Reverse direction protocol
21
22
23 10.29.4 Rules for RD responder
24
25 Insert the following NOTE after the seventh paragraph (“If an AC Constraint subfield is equal
26 to 1 in the last frame ...”):
27
28 (#1648)NOTE—If the RD responder is (#6581)affiliated with an MLD and operates with a nondefault TID-to-link map-
29 ping (see 35.3.7.1 (TID-to-link mapping)), it might transmit Data frame of the AC only if the corresponding TIDs are
30 mapped to that link in the direction of the RD responder to the RD initiator.
31
32 Change the eighth paragraph as follows:
33
34
35 For a BlockAckReq or BlockAck frame, the AC is determined by examining the TID field. For a Management
36 frame, the AC is AC_VO. The RD initiator shall not transmit a +HTC or DMG MPDU with the RDG/More
37 PPDU subfield set to 1 from which the AC cannot be determined. If the AC Constraint subfield is equal to 0,
38 the RD responder may transmit Data frames of any TID(#1649), or if the RD responder is (#6581)affiliated
39 with an MLD, of any TID that is mapped to that link (see 35.3.7.1 (TID-to-link mapping)).
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 275

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

276 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 11. MLME
2
3
4 11.1 Synchronization(#1096)
5
6
7 11.1.4 Acquiring synchronization, scanning
8
9 11.1.4.3 Active scanning and probing procedures
10
11
12 11.1.4.3.4 Criteria for sending a response
13
14 Insert a new item in the list following item 3) of the fourth paragraph as follows (not all
15 paragraphs and items shown):
16
17
18 A FILS STA shall not respond to a Probe Request frame if any of the following criteria is met for a FILS
19 Request Parameters element contained in the Probe Request frame:
20
21 3b) (#1023)If the FILS Criteria field is present in the FILS Request Parameters element and the PHY
22 Support Criterion of the FILS Criteria field of the FILS Request Parameters element is 4 and the
23 responding STA is not EHT capable.
24
25
26 11.2 Power management
27
28
11.2.3 Power management in a non-DMG infrastructure network
29
30
31 11.2.3.1 General
32
33 Change the tenth paragraph as follows:
34
35
36 WNM sleep mode enables an extended power save mode for non-AP STAs in which a non-AP STA need not
37 listen for every DTIM Beacon frame, and need not perform GTK/IGTK/BIGTK updates. A STAs in WNM
38 sleep mode can wake up as infrequently as once every WNM sleep interval to check whether theits
39 corresponding TIM bit is set or group addressed traffic is pending. The WNM sleep interval advertised by a
40
41 STA of a non-AP MLD is applied at the MLD level and the WNM procedures described in this subclause and
42 in 11.2.3.16 (WNM sleep mode) are performed at the MLD level and apply to all the STAs affiliated with the
43 MLD.
44
45 11.2.3.5 Power management with APSD
46
47
48 11.2.3.5.1 Power management with APSD procedures
49
50 Insert the following paragraph after the tenth paragraph (“A STA may set an AC ...”):
51
52
53 If a STA is affiliated with a non-AP MLD, the non-AP MLD shall have the same U-APSD Flag value for each
54 AC across all setup links (see 35.3.5 (Multi-link (re)setup)).
55
56 11.2.3.6 AP operation
57
58
59 Change item k) in the second paragraph as follows:
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 277

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 k) When a (re)association is not for a multi-link (re)setup (35.3.5.1 (Multi-link (re)setup procedure)),
2 an An AP may delete buffered BUs for implementation dependent reasons (subject to 11.2.3.10 (AP
3
and AP MLD aging function)), including the use of an aging function and availability of buffers.
4
5 The AP may base the aging function on the listen interval indicated by the STA in its
6 (Re)Association Request frame or the WNM sleep interval specified by the non-AP STA in the
7 WNM Sleep Mode Request frame. In addition, the S1G AP may base the aging function on the
8 listen interval indicated by the AP in the (Re)Association Response frame.
9
10
11 11.2.3.7 Receive operation for STAs in PS mode
12
13 Change item a) in the second paragraph as follows:
14
15
16 The following rules describe operation of a STA in PS mode:
17 a) When a (re)association is not for a multi-link (re)setup (35.3.5.1 (Multi-link (re)setup procedure)),
18 the The STA with dot11NonTIMModeActivated equal to false shall wake up early enough to be
19
able to receive the first Beacon frame scheduled for transmission at the time corresponding to the
20
21 last TBTT or TSBTT for which the STA was awake plus the time interval indicated by the
22 ListenInterval parameter of the MLME-ASSOCIATE.request or MLME REASSOCIATE.request
23 primitive. The STA with dot11NonTIMModeActivated equal to true is not required to wake up to
24 receive a Beacon frame and shall transmit at least one PS-Poll or trigger frame that is individually
25
addressed to the associated AP every listen interval starting from the last known transition of the
26
27 S1G STA in non-TIM mode in doze state unless it follows the TWT or NDP Paging procedure.
28 NOTE—The STA might wake for a TBTT or TSBTT that is earlier than this deadline. In that case the previous
29 requirement is reset based on a new “last TBTT or TSBTT”.
30
31
32 11.2.3.9 STAs operating in active mode
33
34 Change as follows:
35
36
37 A STA operating in this mode shall have its receiver activated continuously, unless the STA is allowed to be
38 temporarily unavailable through the opportunistic power save mechanism defined in 26.14.3 (Opportunistic
39 power save)(#5034), or through the intra-PPDU power save mechanism defined in 26.14.1 (Intra-PPDU
40 power save for non-AP HE STAs), or 26.8.4.4 (TWT Information frame exchange for flexible wake time) or
41 35.13 (Intra-PPDU power save for non-AP EHT STAs(#5034)), through the enhanced multi-link single
42
43 radio operation defined in 35.3.17 (Enhanced multi-link single radio operation), or through the enhanced
44 multi-link multi-radio operation defined in 35.3.18 (Enhanced multi-link multi-radio operation); such STAs
45 do not need to interpret the TIM elements in Beacon frames.
46
47
48
Change the title of the subclause 11.2.3.10 as follows:
49
50 11.2.3.10 AP and AP MLD aging function
51
52 Insert the following paragraph as the second paragraph after the first paragraph (“Any AP
53
54 aging function...”):
55
56 Any AP MLD aging function shall not cause the buffered BU to be discarded after any period that is shorter
57 than that indicated by the non-AP MLD for which the BUs are buffered in the Listen Interval field of its
58
59 (Re)Association Request frame. The exact specification of the aging function is beyond the scope of this
60 standard.
61
62
63
64
65

278 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 11.2.3.15 TIM Broadcast

2
3
4 Change the twelve paragraph by splitting it into two and add an additional item as follows:
5
6 The AP shall increase the value (modulo 256) of the Check Beacon field in the next transmitted TIM
7 frame(s) when a critical update occurs to any of the elements inside the Beacon frame.
8
9
10 (#1071)The following events about the operational parameters of the AP shall classify as a critical update:
11 a) Inclusion of a Channel Switch Announcement element
12
13 b) Inclusion of an Extended Channel Switch Announcement element
14 c) Modification of the EDCA parameters element
15
16 d) Inclusion of a Quiet element
17 e) Modification of the DSSS Parameter Set
18
19 f) Modification of the HT Operation element
20 g) Inclusion of a Wide Bandwidth Channel Switch element
21
22 h) Inclusion of a Channel Switch Wrapper element
23 i) Inclusion of an Operating Mode Notification element
24
25 j) Inclusion of a Quiet Channel element
26 k) Modification of the VHT Operation element
27
28 l) Modification of the HE Operation element
29 m) Insertion of a Broadcast TWT element
30
31 n) Inclusion of the BSS Color Change Announcement element
32 o) Modification of the MU EDCA Parameter Set element
33
34 p) Modification of the Spatial Reuse Parameter Set element
35 q) Modification of the UORA Parameter Set element
36
37 r) Modification of the EHT Operation element(#1071)
38
39 11.2.3.16 WNM sleep mode
40
41
11.2.3.16.1 WNM sleep mode capability
42
43
44 Insert the following paragraph and NOTE at the end of the subclause:
45
46 (#6305)For MLO, WNM sleep mode enables extended power save mode between an AP MLD and a non-
47
48 AP MLD. The WNM Sleep Mode Request and Response frames are exchanged between the non-AP MLD
49 and AP MLD through an affiliated STA and an affiliated AP over a setup link.
50
(#6305)NOTE—Each STA affiliated with a non-AP MLD maintains its own power save state and power save mode (see
51
.35.3.12 (Multi-link power management)).
52
53
54 11.2.3.16.2 WNM sleep mode non-AP STA operation
55
56 Insert the following paragraph at the end of the subclause:
57
58
59 A non-AP MLD identifies the link to which the GTK/IGTK/BIGTK belongs based on the Link ID subfield
60 carried in the corresponding subelement of the Key Data field.
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 279

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 11.2.3.16.3 WNM sleep mode AP operation

2
3
4
Change the last paragraph as follows:
5
6 (#6305)(#8222)When the association is not an MLD association (see 11.3 (STA
7 authenticationAuthentication and association(#2277))) with RSN and a valid PTK is configured for the
8 STA:
9
10 — If RSN is used with management frame protection and a valid PTK is configuredis negotiated for the
11 STA, the current GTK, IGTK, and BIGTK shall be included in the WNM Sleep Mode Response
12 frame.
13
14 — If a GTK/IGTK/BIGTK update is in progress, the pending GTK, IGTK, and BIGTK shall be
15 included in the WNM Sleep Mode Response frame.
16
— If RSN is used without management frame protection and a valid PTK is configuredis not negotiated
17
18 for the STA, the current GTK shall be sent to the STA using a group key handshake (see 12.7.7
19 (Group key handshake)) immediately following the WNM Sleep Mode Response frame.
20
21 (#6305)(#8222)When the association is an MLD association (see 11.3 (STA authenticationAuthentication
22
and association(#2277))) with RSN and a valid PTK is configured for the non-AP MLD:
23
24 — If management frame protection is negotiated for the MLDs, the current GTK, IGTK, and BIGTK
25 for each setup link shall be included in the WNM Sleep Mode Response frame.
26
27 — If a GTK/IGTK/BIGTK update is in progress for one or more links, the pending GTK(s), IGTK(s),
28 and BIGTK(s) for each of the affected link(s) shall be included in the WNM Sleep Mode Response
29 frame. A non-AP MLD identifies the corresponding link to which the GTK/IGTK/BIGTK belongs
30 based on the value of the Link ID subfield included in the subelement of the Key Data field.
31
32 — If management frame protection is not negotiated for the MLDs, the current GTK for each setup link
33 shall be sent to the non-AP MLD using a group key handshake (see 12.7.7 (Group key handshake))
34 immediately following the WNM Sleep Mode Response frame.
35
36
37 Change the title of the subclause 11.3 as follows:
38
39
40 11.3 STA authenticationAuthentication and association(#2277)
41
42 Insert a new child subclause “General” at the beginning of this subclause:
43
44
45 11.3.1 General(#2278)
46
47 Insert the following two paragraphs as the first two paragraphs of the subclause:
48
49
50 In 11.3 (STA authenticationAuthentication and association(#2277)), the reference of a “STA” means that the
51 “STA” is not affiliated with an MLD unless specified otherwise.
52
53
In 11.3 (STA authenticationAuthentication and association(#2277)), when referring to MLD authentication,
54
55 MLD deauthentication, MLD (re)association, MLD disassociation, or MLD 4-way handshake, the reference
56 of “SME” means the entity that manages the MLD.
57
58
59
60
61
62
63
64
65

280 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 11.3.2 State variables

2
3
4
Insert the following paragraph after the now-shifted third paragraph (“A STA (local) for which
5 dot11OCBAActiviated ...”):
6
7 An MLD (local) keeps an enumerated state variable for each MLD (remote) with which direct
8 communication between two MLDs through affiliated STAs of the two MLDs(#2077) via the WM is
9
needed. In this context, direct communication between two MLDs through affiliated STAs of the two
10
11 MLDs(#2077) refers to the transmission of any Class 2 or Class 3 frame with an Address 1 field that
12 matches the MAC address of the STA affiliated with the remote MLD and an Address 2 field that matches
13 the MAC address of the STA affiliated with the local MLD.
14
15
16
Insert the following paragraph after the now-shifted seventh paragraph (“For nonmesh STAs,
17 this state variable ...”):
18
19 For MLDs, this state variable expresses the relationship between the local MLD and the remote MLD. It
20 takes on the following values:
21
22 — State 1: Initial start state for MLDs that perform IEEE 802.11 authentication. Unauthenticated and
23 unassociated.
24
— State 2: Authenticated but unassociated.
25
26 — State 3: Authenticated and associated (Pending RSNA Authentication). The IEEE 802.1X Controlled
27 Port is blocked.
28
29 — State 4: Authenticated and associated (RSNA Established or Not Required). The IEEE 802.1X
30 Controlled Port is unblocked, or not present.
31
32 Change the title of the subclause 11.3.3 as follows:
33
34
35 11.3.3 State transition diagram for nonmesh STAs or MLDs
36
37 Change the first two paragraphs and replace Figure 11-17 as follows:
38
39
40 Figure 11-20 (Relationship between state and services between a given pair of nonmesh STAs or nonmesh
41 MLDs) shows the state transition diagram for nonmesh STA states or nonmesh MLD states. Note that only
42 events causing state changes are shown. The state of the sending STA or sending MLD given by Figure 11-20
43 (Relationship between state and services between a given pair of nonmesh STAs or nonmesh MLDs) is with
44
respect to the intended receiving STA or the intended receiving MLD, respectively.
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 281

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 NOTE—A transition to State 1 might occur for other reasons such as no frames having been received from a STA or an
2 MLD for a period of time.
3
4 State 1
5
6 Unauthenticated,
7 Unassociated
8
9 Class 1 Frames
10
11 1. Successful (Re)Association –
12 No RSNA Required
Successful
13
IEEE Std 802.11 authentication or FILS authentication 2. Fast BSS Transition
14
15 Deauthentication
16 (except DMG STAs that 3. PBSS 4-way handshake
State 2 Successful
17 did not perform
18 IEEE Std 802.11 authentication) Authenticated (except DMG STAs that do
not perform IEEE Std 802.11 authentication, 4. FILS (Re)Association and Key
19 or FILS authentication
which are unauthenticated), Unassociated Confirmation
20
21
Class 1 & 2 Frames
22
23
24 Successful
25 1. Unsuccessful (Re)Association (Re)Association – RSNA Required
26 (Non-AP, non-AP MLD, and non-
27 PCP STA)
28 State 3
29 2. Disassociation Authenticated (except DMG STAs that did not
30 perform IEEE Std 802.11 authentication,
31 Deauthentication which are unauthenticated), Associated
32 (except DMG STAs that (Pending RSNA Authentication)
33 did not perform IEEE
34 Std 802.11 Class 1, 2 & 3 Frames
IEEE 802.1X Controlled Port Blocked
35 authentication)
36
37
38 4-way handshake Successful
1. Unsuccessful (Re)Association
39 (Non-AP, non-AP MLD, and non-
40 PCP STA)
41 State 4
42 2. Disassociation Authenticated (except DMG STAs that did not
43 perform IEEE Std 802.11 authentication,
44 which are unauthenticated), Associated
45 (RSNA Established or Not Required)
46 Deauthentication
47 (except DMG STAs that did not Class 1, 2, & 3 Frames
48 perform IEEE Std 802.11 IEEE 802.1X Controlled Port Unblocked
authentication)
49
50 Figure 11-20—Relationship between state and services between a given pair of nonmesh
51
52 STAs or nonmesh MLDs
53
54 Change the title of the subclause 11.3.4 as follows:
55
56
57 11.3.4 Frame filtering based on STA or MLD state
58
59 Change the first paragraph as follows:
60
61
62 The current state existing between the transmitter and receiver STAs determines the IEEE 802.11 frame
63 types that may be exchanged between that pair of STAs (see Clause 9 (Frame formats)). (#5635)When the
64 current state is State 1 or State 2, the current state existing between MLDs determines the IEEE 802.11 frame
65

282 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 types that may be exchanged through affiliated STAs between the pair of MLDs. When the current state is
2 State 3 or State 4, the current state existing between MLDs determines the IEEE 802.11 frame types that may
3
be exchanged on any setup links between that pair of MLDs subject to additional constraints (see 35.3.7 (Link
4
5 management)). A unique state exists for each pair of transmitter and receiver STAs or each pair of MLDs.
6 The allowed frame types are grouped into classes and the classes correspond to the STA state or the MLD
7 state. In State 1, only Class 1 frames are allowed. In State 2, only Class 1 or Class 2 frames are allowed. In
8 State 3 and State 4, all frames are allowed (Classes 1, 2, and 3). In the definition of frame classes, the
9
following terms are used:
10
11 — Within an infrastructure BSS: both the transmitting STA and the recipient STA participate in the
12 same infrastructure BSS
13
14 — Within a PBSS: both the transmitting STA and the recipient STA participate in the same PBSS
15 — Within an IBSS: both the transmitting STA and the recipient STA participate in the same IBSS
16
17 — dot11RSNAActivated: reference to the setting of dot11RSNAActivated at the STA or the MLD that
18 needs to determine whether a transmission or reception is permitted.
19
20 Change the description of the Data frames and Management frames of Class 3 frame in the
21
22
sixth paragraph as follows:
23
24 The frame classes are defined as follows:
25 c) Class 3 frames
26
27 1) Data frames
28 i) Data frames between STAs in an infrastructure BSS or in an MBSS
29
30 ii) Data frames between an AP MLD and a non-AP MLD associated with the AP MLD
31 2) Management frames
32
33 i) In an infrastructure BSS, an MBSS, or a PBSS, all Action and Action No Ack frames
34 except those that are declared to be Class 1 or Class 2 frames
35
36 ii) Between an AP MLD and a non-AP MLD associated with the AP MLD, all Action and
37 Action No Ack frames except those that are declared to be Class 1 or Class 2 frames
38
39 Insert the following paragraph after the eighth paragraph (“A STA shall not transmit Class 2
40
41
...”):
42
43 A STA affiliated with an MLD shall not transmit Class 2 frames unless the MLD is in State 2 or State 3 or
44 State 4.
45
46
47 Insert the following paragraphs after the now-shifted tenth paragraph (“A STA shall not
48 transmit Class 3 ...”):
49
50 A STA affiliated with an MLD shall not transmit Class 3 frames unless the MLD is in State 3 or State 4.
51
52 NOTE—Frames transmissions on a link between an AP MLD and a non-AP MLD associated with the AP MLD is
53 subject to additional constraints (see 35.3.7 (Link management)).
54
55 11.3.5 Authentication and deauthentication
56
57
58 11.3.5.1 General
59
60 Change the second and third paragraphs as follows:
61
62
63 Successful authentication sets the state for a STA or an MLD to State 2, if it was in State 1. Unsuccessful
64 authentication leaves the state for the STA or the MLD unchanged.
65

Copyright © 2022 IEEE. All rights reserved. 283

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Deauthentication notification sets the state for a STA or an MLD to State 1. Deauthentication notification when
2 in State 3 or 4 implies disassociation as well. A STA or an MLD may deauthenticate a peer STA or a peer
3
MLD, respectively, at any time, for any reason.
4
5
6 Change the fifth paragraph as follows:
7
8 Authentication is optional in an IBSS. Between an AP MLD and a non-AP MLD, authentication is required. In
9
a non-DMG infrastructure BSS, authentication is required. In a DMG infrastructure BSS and PBSS, the Open
10
11 System authentication algorithm is not used (see 12.3.3.1 (Overview(#2086)(#2283))). APs, AP MLDs, and
12 PCPs do not initiate authentication.
13
14 Change the title of the subclause 11.3.5.2 as follows:
15
16
17 11.3.5.2 Authentication—originating STA or MLD
18
19 Change the second paragraph as follows:
20
21
22 Upon receipt of an MLME-AUTHENTICATE.request primitive, the originating STA or MLD shall
23 authenticate with the indicated STA or MLD, respectively, using the following procedure:
24
a) If the STA is in an IBSS, the SME shall delete any PTKSA, GTKSA, IGTKSA and temporal keys
25
26 held for communication with the indicated STA by using the MLME-DELETEKEYS.request
27 primitive (see 12.6.18 (RSNA security association termination)).
28 b) The STA or the MLD shall execute one of the following:
29
30 1) For the Open System or Shared Key authentication algorithm, the authentication mechanism
31 described in 12.3.3.2 (Open System authentication) or 12.3.3.3 (Shared Key authentication),
32 respectively.
33
34 2) For the fast BSS transition (FT) authentication algorithm in an ESS, the authentication
35 mechanism described in 13.5 (FT protocol), or, if resource requests are included, 13.6 (FT
36 resource request protocol).
37
38 3) For SAE authentication between an AP MLD and a non-AP MLD or in an infrastructure BSS,
39 IBSS, or MBSS, the authentication mechanism described in 12.4 (Authentication using a
40 password).
41
42 4) For FILS authentication, the authentication mechanism described in 12.11 (Authentication for
43 FILS). An AP or PCP may provide estimated association response latency to a non-AP and
44 non-PCP STA using the Association Delay Info field in the Association Delay Info element
45 (9.4.2.174 (Future Channel Guidance element)). The value of the Association Delay Info field
46 shall be larger than dot11HLPWaitTime.
47
48 c) If the authentication was successful within the AuthenticateFailureTimeout, the state for the
49 indicated STA or MLD shall be set to State 2 if it was State 1; the state shall remain unchanged if it
50 was other than State 1.
51
52 d) The MLME shall issue an MLME-AUTHENTICATE.confirm primitive to inform the SME of the
53 result of the authentication.
54
55
56
57
58
59
60
61
62
63
64
65

284 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Change the title of the subclause 11.3.5.3 as follows:

2
3
4 11.3.5.3 Authentication—destination STA or MLD
5
6 Change the first two paragraphs as follows:
7
8 Upon receipt of an Authentication frame with authentication transaction sequence number equal to 1, the
9
10 destination STA or MLD shall authenticate with the originating STA or MLD, respectively, using the
11 following procedure:
12 a) If Open System or Shared Key authentication algorithm is being used, the STA or the MLD shall
13
execute the procedure described in 12.3.3.2 (Open System authentication) or 12.3.3.3 (Shared Key
14
15 authentication) respectively. These result in the generation of an MLME-
16 AUTHENTICATE.indication primitive to inform the SME of the authentication request.
17 b) If FT authentication is being used, the MLME shall issue an MLME-AUTHENTICATE.indication
18
19 primitive to inform the SME of the authentication request, including the FT Authentication
20 Elements, and the SME shall execute the procedure as described in 13.5 (FT protocol) or 13.6 (FT
21 resource request protocol).
22
c) If SAE authentication is being used between an AP MLD and a non-AP MLD or in an infrastructure
23
24 BSS, IBSS, or MBSS, the MLME shall issue an MLME-AUTHENTICATE.indication primitive to
25 inform the SME of the authentication request, including the SAE authentication elements, and the
26 SME shall execute the procedure as described in 12.4 (Authentication using a password).
27
28 d) If FILS authentication is being used, the MLME shall issue an MLME-
29 AUTHENTICATE.indication primitive to inform the SME of the authentication request, and the
30 SME shall execute the procedure described in 12.11 (Authentication for FILS).
31
e) If the STA is in an IBSS and management frame protection was not negotiated when the PTKSA(s)
32
33 were created, the SME shall delete any PTKSA, GTKSA, IGTKSA and temporal keys held for
34 communication with the originating STA by using the MLME-DELETEKEYS.request primitive
35 (see 12.6.18 (RSNA security association termination)).
36
37 f) Upon receipt of an MLME-AUTHENTICATE.response primitive, if the ResultCode is not
38 SUCCESS, the MLME shall transmit an Authentication frame with the corresponding status code,
39 as defined in 9.4.1.9 (Status Code field), and the state for the originating STA or MLD shall be left
40 unchanged. The Authentication frame is constructed using the appropriate procedure in 12.3.3.2
41 (Open System authentication), 12.3.3.3 (Shared Key authentication), 13.5 (FT protocol) or 13.6 (FT
42
43 resource request protocol).
44 g) Upon receipt of an MLME-AUTHENTICATE.response primitive, if the ResultCode is SUCCESS,
45 the MLME shall transmit an Authentication frame that is constructed using the appropriate
46
procedure in 12.3.3.2 (Open System authentication), 12.3.3.3 (Shared Key authentication), 13.5 (FT
47
48 protocol) or 13.6 (FT resource request protocol), with a status code of SUCCESS, and the state for
49 the originating STA or MLD shall be set to State 2 if it was in State 1; the state shall remain
50 unchanged if it was other than State 1.
51
52 NOTE—If management frame protection was negotiated, the SME does not change the state for the originating STA or
53 originating MLD and does not delete any of the previously created SAs or temporal keys as a part of this authentication
54 procedure.
55
56 Insert the following paragraph at the end of the subclause:
57
58
59 (#1664)For a destination MLD, an Authentication frame that is constructed using the appropriate procedure
60 to complete the authentication procedure shall have the Address 1 field equal to the MAC address of the
61 STA affiliated with the originating MLD that sends the Authentication frame with authentication transaction
62 sequence number equal to 1.
63
64
65

Copyright © 2022 IEEE. All rights reserved. 285

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Change the title of the subclause 11.3.5.4 as follows:

2
3
4 11.3.5.4 Deauthentication—originating STA or MLD
5
6 Change as follows:
7
8
The originating STA or MLD shall deauthenticate with the indicated STA or MLD, respectively, using the
9
10 following procedure:
11 a) The SME shall generate an MLME-DEAUTHENTICATE.request primitive containing the
12 appropriate reason code for the STA or MLD deauthentication, as defined in Table 9-49 (Reason
13
14 codes) of 9.4.1.7 (Reason Code field).
15 b) On receipt of the MLME-DEAUTHENTICATE.request primitive, if the state for the indicated STA
16 or MLD is State 2, State 3, or State 4, the MLME shall generate a Deauthentication frame to be
17
transmitted to the indicated STA or MLD, respectively.
18
19 NOTE—As the Deauthentication frame is a bufferable MMPDU, the transmission of this frame might be
20 delayed by the operation of a power saving protocol. The AID and the PTKSA are maintained (when
21 applicable) until the frame is acknowledged or attempts to transmit the frame are abandoned.
22
23
c) The state for the indicated STA or MLD shall be set to State 1.
24
25 d) Once the Deauthentication frame is acknowledged or attempts to transmit the frame are abandoned,
26 the MLME shall issue an MLME-DEAUTHENTICATE.confirm primitive to inform the SME of the
27 deauthentication.
28
29 e) The SME, upon receipt of an MLME-DEAUTHENTICATE.confirm primitive, shall delete any
30 PTKSA, GTKSA, IGTKSA, BIGTKSA, WIGTKSA and temporal keys held for communication
31 with the indicated STA or MLD by using the MLME-DELETEKEYS.request primitive (see
32
12.6.18 (RSNA security association termination)) and by generating an MLME-
33
34 SETPROTECTION.request(None) primitive.
35 f) If the STA is contained within an AP or PCP, its SME, upon receipt of an MLME-
36 DEAUTHENTICATE.confirm primitive, shall release the AID assigned for the indicated STA, if
37
38 the state for the indicated STA was State 3 or State 4.
39 f1) If the MLD is an AP MLD, its SME(#2825), upon receipt of an MLME-
40 DEAUTHENTICATE.confirm primitive, shall release the AID assigned for the indicated non-AP
41
MLD, if the state for the indicated MLD was State 3 or State 4.
42
43 g) If the STA is contained within an AP, its SME shall inform the DS of the disassociation, if the state
44 for the indicated STA was State 3 or State 4.
45
46 g1) If the MLD is an AP MLD, its SME(#2825) shall inform the DS of the disassociation, if the state for
47 the indicated non-AP MLD was State 3 or State 4.
48 h) If the STA is a mesh STA, its SME shall inform the mesh peering instance controller (see
49
50 14.3.4 (Mesh peering instance controller)) of the deauthentication.
51
52 Change the title of the subclause 11.3.5.5 as follows:
53
54
11.3.5.5 Deauthentication—destination STA or MLD
55
56
57 Change the second paragraph as follows:
58
59 Otherwise, upon receipt of a Deauthentication frame from a STA or an MLD for which the state is State 2,
60
State 3, or State 4, the destination STA or MLD, respectively, shall deauthenticate with the originating STA or
61
62 MLD, respectively, using the following procedure:
63 a) If management frame protection was not negotiated when the PTKSA(s) were created, or if
64 management frame protection is in use and the frame is not discarded per management frame
65

286 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 protection processing, the MLME shall issue an MLME-DEAUTHENTICATE.indication primitive

2 to inform the SME of the deauthentication, and set the state for the originating STA or the
3
originating MLD to State 1.
4
5 b) Upon receiving an MLME-DEAUTHENTICATE.indication primitive, the SME shall
6
1) Delete any PTKSA, GTKSA, IGTKSA, BIGTKSA, WIGTKSA and temporal keys held for
7
8 communication with the originating STA or the originating MLD by using the MLME-
9 DELETEKEYS.request primitive (see 12.6.18 (RSNA security association termination)) and
10 by generating an MLME-SETPROTECTION.request(None) primitive.
11
12 2) If the STA is contained within an AP or PCP, release the AID assigned for the indicated STA.
13 2a If the MLD is an AP MLD, release the AID assigned for the indicated MLD(#2883).
14
15 3) If the STA is contained within an AP, inform the DS of the disassociation, if the state for the
16 originating STA was State 3 or State 4.
17 3a) If the MLD is an AP MLD, inform the DS of the disassociation, if the state for the originating
18
non-AP MLD was State 3 or State 4.
19
20 4) If the STA is a mesh STA, inform the mesh peering instance controller (see 14.3.4 (Mesh
21 peering instance controller)) of the deauthentication.
22
23
24 11.3.6 Association, reassociation, and disassociation
25
26 11.3.6.1 General
27
28 Change the third, fourth, and fifth paragraphs as follows:
29
30
31 Successful association enables a STA to exchange Class 3 frames. (#1810)Successful association enables an
32 MLD to exchange Class 3 frames on any setup links subject to additional constraints (see 35.3.7 (Link
33 management)). Successful association sets the state for a non-FILS STA or a non-FILS MLD to State 3 or State
34 4. Successful association sets the state for FILS STAs to State 4.
35
36
37 Successful reassociation enables a STA or an MLD to exchange Class 3 frames. Unsuccessful reassociation
38 when not in State 1 leaves the state for a STA state unchanged (with respect to the AP or PCP that was sent the
39 Reassociation Request (which may be the current STA)) or for a non-AP MLD state unchanged (with respect
40 to the AP MLD that was sent the Reassociation Request). Successful reassociation sets the state for a non-FILS
41
42 STA to State 3 or State 4 (with respect to the AP or PCP that was sent the Reassociation Request frame) or for
43 a non-FILS non-AP MLD to State 3 or State 4 (with respect to the AP MLD that was sent the Reassociation
44 Request frame). Successful reassociation when not in State 1 sets the state for a STA to State 2 (with respect to
45 the current AP or PCP, if this is not the AP or PCP that was sent the Reassociation Request frame) or for a non-
46 AP MLD to State 2 (with respect to the current AP MLD, if this is not the AP MLD that was sent the
47
48 Reassociation Request frame). Successful reassociation sets the state for a FILS STA to State 4 (with respect to
49 the AP or PCP that was sent the Reassociation Request frame) and enables it to exchange Class 3 frames.
50 Reassociation shall be performed only if the originating STA or non-AP MLD is already associated in the same
51 ESS.
52
53
54 Disassociation notification when not in State 1 sets the state for a non-FILS STA or a non-FILS MLD to State
55 2. Disassociation notification when not in State 1 sets the state for a FILS STA to State 1. The STA or MLD
56 shall become associated again prior to sending Class 3 frames. A STA or an MLD may disassociate a peer STA
57 or a peer MLD, respectively, at any time, for any reason.
58
59
60 Change the last paragraph as follows:
61
62 Association is not applicable in an IBSS. In an infrastructure BSS, association is required. Between an AP
63 MLD and a non-AP MLD, association is required. In a PBSS, association is optional. APs, AP MLDs, and
64 PCPs do not initiate association.
65

Copyright © 2022 IEEE. All rights reserved. 287

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Change the title of the subclause 11.3.6.2 as follows:

2
3
4 11.3.6.2 Non-AP STA, non-AP MLD, and non-PCP STA association initiation procedures
5
6 Insert the following paragraph after the first paragraph (“The SME shall delete ...”):
7
8 The (#8305)SME shall delete any PTKSA, GTKSA, IGTKSA, BIGTKSA and temporal keys held for
9
10 communication with the AP MLD by using MLME-DELETEKEYS.request primitive (see 12.6.18 (RSNA
11 security association termination)) before invoking MLME-ASSOCIATE.request primitive.
12
13 Insert the following two paragraphs after the now-shifted fifth paragraph (“Upon receipt of an
14
15
MLME-ASSOCIATE.request primitive that is ...”):
16
17 For a non-AP MLD associated with an AP MLD, a non-AP STA affiliated with the non-AP MLD shall not
18 send an Association Request frame without (#8308)Basic Multi-Link element.
19
20 (#8308)NOTE—A non-AP MLD can disassociate from the associated AP MLD to allow a non-AP STA that was
21 affiliated with the non-AP MLD to send an Association Request frame without Basic Multi-Link element to perform
22 regular STA association, i.e., non-MLD association.
23
24 Change the now-shifted eighth paragraph as follows:
25
26
27 Upon receipt of an MLME-ASSOCIATE.request primitive, a non-AP, non-AP MLD, and non-PCP STA shall
28 associate with an AP, AP MLD, or PCP, respectively, using the following procedure:
29 a) If the state for the AP, AP MLD, or PCP is State 1, the MLME shall inform the SME of the failure of
30
the association by issuing an MLME-ASSOCIATE.confirm primitive, and this procedure ends.
31
32 b) All the states, agreements and allocations listed in both numbered lists in 11.3.6.4 (Non-AP, non-AP
33 MLD, and non-PCP STA reassociation initiation procedures) item c) are deleted or reset to initial
34 values.
35
36 c) (#2894)(#1211)The MLMEnon-AP STA shall transmit an Association Request frame to the AP or
37 PCP or a non-AP STA affiliated with the non-AP MLD shall transmit an Association Request frame
38 with (#6700)Basic Multi-Link element (#8309)to an AP affiliated with the AP MLD. The RSNE
39
contained in the MLME-ASSOCIATE.request primitive shall be included in the Association
40
41 Request frame. The RSNE shall specify exactly one pairwise cipher suite and exactly one AKM
42 suite. If the MLME-ASSOCIATE.request primitive contained the EmergencyServices parameter
43 equal to true, an Interworking element with the UESA field set to 1 shall be included in the
44 Association Request frame.
45
46 d) If an Association Response frame is received with a status code of SUCCESS, a DMG STA shall
47 write to each of the following MIB attributes the corresponding subfield of the DMG BSS Parameter
48 Configuration field of the DMG Operation element received from the AP or PCP to which it
49 requested association:
50
51 1) dot11PSRequestSuspensionInterval from the PSRequestSuspensionInterval subfield
52 2) dot11MinBHIDuration from the MinBHIDuration subfield
53
54 3) dot11BroadcastSTAInfoDuration from the BroadcastSTAInfoDuration subfield
55 4) dot11AssocRespConfirmTime from the AssocRespConfirmTime subfield
56
57 5) dot11MinPPDuration from the MinPPDuration subfield
58 6) dot11SPIdleTimeout from the SPIdleTimeout subfield
59
60 7) dot11MaxLostBeacons from the MaxLostBeacons subfield
61
62
63
64
65

288 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 e) If an Association Response frame is received with a status code of SUCCESS, the state for the AP,
2 AP MLD, or PCP shall be set to State 4 or, if dot11RSNAActivated is true, State 3. The state for any
3
other AP, AP MLD, or PCP which is State 3 or State 4 prior to the association request shall be set to
4
5 State 2, and the MLME shall issue an MLME-ASSOCIATE.confirm primitive to inform the SME of
6 the successful completion of the association.
7 f) If an Association Response frame is received with a status code of SUCCESS at an MM-SME
8
9 coordinated STA and the Single AID field within the MMS element is equal to 1, then
10 — For each of its MAC entities advertised within the MMS element and for which
11 dot11RSNAActivated is true, the state is set to State 3. Progress from State 3 to State 4 occurs
12
independently in each such MAC entity.
13
14 — For each of its MAC entities advertised within the MMS element and for which
15 dot11RSNAActivated is false, the state is set to State 4.
16
17 — For each of its MAC entities advertised within the MMS element the state for any other AP or
18 PCP which is State 3 or State 4 prior to the association request shall be set to State 2.
19 g) If an Association Response frame is received with a status code other than SUCCESS or the
20
21 association fails to complete within dot11AssociationResponseTimeout the state for the AP, AP
22 MLD, or PCP shall be set to State 2, and the MLME shall issue an MLME-ASSOCIATE.confirm
23 primitive to inform the SME of the failure of the association. The status code returned in the
24 Association Response frame indicates the cause of the failed association attempt. Any
25 misconfiguration or parameter mismatch, e.g., data rates required as basic rates that the STA or a
26
27 non-AP STA affiliated with the non-AP MLD did not indicate as supported in the STA’s Supported
28 Rates and BSS Membership Selectors element, shall be corrected before the SME issues an MLME-
29 ASSOCIATE.request primitive for the same AP, AP MLD, or PCP. If the status code indicates the
30 association failed because of a reason that is not related to configuration (e.g., the AP, AP
31 MLD,(#1851) or PCP is unable to support additional associations) and the Association Response
32
33 frame does not include a Timeout Interval element with Timeout Interval Type equal to 3 the SME
34 shall not issue an MLME-ASSOCIATE.request primitive for the same AP, AP MLD, or PCP until a
35 period of at least 2 s has elapsed. If the status code indicates the association failed and the
36 Association Response frame contains a Timeout Interval element with Timeout Interval Type equal
37 to 3, the SME shall not issue an MLME-ASSOCIATE.request primitive for the same AP, AP MLD,
38
39 or PCP until the period specified in the Timeout Interval element has elapsed.
40 h) If an MLME-ASSOCIATE.confirm primitive is received with a ResultCode of SUCCESS, and
41 RSNA is required, and FILS authentication was not used, then the SME shall perform a 4-way
42
handshake to establish an RSNA with the STA or the AP MLD. As a part of a successful 4-way
43
44 handshake, the SME shall enable protection by generating an MLME-
45 SETPROTECTION.request(Rx_Tx) primitive. If an MLME-ASSOCIATE.confirm primitive is
46 received with a ResultCode of SUCCESS, and FILS authentication was used, then the SME shall
47 enable protection by generating an MLME-SETPROTECTION.request(Rx_Tx) primitive.
48
49 i) Upon receipt of the MLME-SETPROTECTION.request(Rx_Tx) primitive, the MLME shall set the
50 state of the STA or the AP MLD to State 4.
51
52 Change the title of the subclause 11.3.6.3 as follows:
53
54
55 11.3.6.3 AP, AP MLD, or PCP association receipt procedures
56
57 Insert the following paragraph as the first paragraph of the subclause:
58
59
60 For a non-AP MLD associated with an AP MLD, if an AP affiliated with the AP MLD receives an
61 Association Request frame without (#8308)Basic Multi-Link element from a non-AP STA affiliated with the
62 non-AP MLD, then the AP shall reject the association request with a status code of
63
DENIED_STA_AFFILIATED_WITH_MLD_WITH_EXISTING_MLD_ASSOCIATION.
64
65

Copyright © 2022 IEEE. All rights reserved. 289

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Change the remaining paragraphs of the subclause as follows:

2
3
4 (#1166)(#1211)The following procedure shall be used by an AP or PCP Uupon receipt of an Association
5 Request frame from a STA the AP or PCP shall use the following procedure or by an AP MLD after an AP
6 affiliated with the AP MLD receives an Association Request frame with (#6700)Basic Multi-Link element
7 from a non-AP STA affiliated with a non-AP MLD:
8
9 a) The MLME shall issue an MLME-ASSOCIATE.indication primitive to inform the SME of the
10 association request. The SME shall issue an MLME-ASSOCIATE.response primitive addressed to
11 the STA or MLD identified by the PeerSTAAddress parameter of the MLME-
12 ASSOCIATE.indication primitive. If the association is not successful, the SME shall indicate a
13
specific reason for the failure to associate in the ResultCode parameter. Upon receipt of the MLME-
14
15 ASSOCIATE.response primitive, the MLME shall transmit an Association Response frame.
16 b) If the state for the STA is 1 and the STA is a non-DMG STA or the state of the non-AP MLD is 1,
17 the SME shall refuse the association request by issuing an MLME-ASSOCIATE.response primitive
18
19 with ResultCode NOT_AUTHENTICATED.
20 c) AP with dot11InterworkingServiceActivated true only: If the MLME-ASSOCIATE.indication
21 primitive has the EmergencyServices parameter set to true and the RSN parameter does not include
22
an RSNE, the SME shall not reject the association request on the basis that dot11RSNAActivated is
23
24 true, thereby granting access, using unprotected frames (see 9.2.4.1.9 (Protected Frame subfield)), to
25 the network for emergency services purposes.
26 d) Otherwise, in an RSNA the SME shall check the values received in the RSN parameter to see
27
28 whether the values received match the security policy. If they do not, the SME shall refuse the
29 association by issuing an MLME-ASSOCIATE.response primitive with a ResultCode indicating the
30 security policy mismatch.
31
e) Otherwise, if the state for the STA or the non-AP MLD is 4, the STA or the non-AP MLD has a
32
33 valid security association, the STA or the non-AP MLD has negotiated management frame
34 protection, the STA or the non-AP MLD has not performed a successful SAE authentication after
35 the current association was established, and there has been no earlier, timed out SA Query procedure
36 with the STA or the non-AP MLD (which would have allowed a new association process to be
37
started, without an additional SA Query procedure):
38
39 1) The SME shall refuse the association request by issuing an MLME-ASSOCIATE.response
40 primitive with ResultCode REFUSED_TEMPORARILY and TimeoutInterval containing a
41 Timeout Interval element with the Timeout Interval Type field set to 3 (Association Comeback
42
43 time). If the SME is in an ongoing SA Query with the STA or the non-AP MLD, the Timeout
44 Interval Value field shall be set to the remaining SA Query period, otherwise it shall be set to
45 dot11AssociationSAQueryMaximumTimeout or dot11MLDAssociationSAQueryMaximum-
46 Timeout.
47
48 2) The state for the STA or the non-AP MLD shall be left unchanged.
49 3) Following this, if the SME is not in an ongoing SA Query with the STA or the non-AP MLD,
50 the SME shall issue one MLME-SA-QUERY.request primitive addressed to the STA or the
51
52 non-AP MLD every dot11AssociationSAQueryRetryTimeout TUs until an MLME-SA-
53 QUERY.confirm primitive for the STA or the non-AP MLD is received or
54 dot11AssociationSAQueryMaximumTimeout TUs or
55 dot11MLDAssociationSAQueryMaximumTimeout TUs from the beginning of the SA Query
56 procedure have passed. The SME shall increment the TransactionIdentifier by 1 for each
57
58 MLME-SA-QUERY.request primitive, rolling it over the value to 0 after the maximum
59 allowed value is reached.
60 4) If no MLME-SA-QUERY.confirm primitive for the STA or the non-AP MLD is received
61
within the dot11AssociationSAQueryMaximumTimeout period or the
62
63 dot11MLDAssociationSAQueryMaximumTimeout period, the SME shall allow a subsequent
64 association process with the STA or the non-AP MLD to be started without starting an
65

290 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 additional SA Query procedure, except that the SME may deny a subsequent association
2 process with the STA or the non-AP MLD if an MSDU was received from the STA or any
3
affiliated STA of the non-AP MLD within this period.
4
5 NOTE 1—Reception of an MSDU implies reception of a valid protected frame, which obviates the need
6 for the SA Query procedure.
7
8
f) (#1025)The SME shall refuse an association request from a STA that does not support all of the
9
10 rates in the BSSBasicRateSet parameter and all of the membership selectors in the
11 BSSMembershipSelectorSet parameter in the MLME-START.request primitive.
12 g) (#1025)The SME shall refuse an association request from an HT STA that does not support all of the
13
14 MCSs in the Basic HT-MCS Set field of the HT Operation parameter in the MLME-START.request
15 primitive.
16 h) (#1025)The SME shall refuse an association request from a VHT STA that does not support all of
17
the <VHT-MCS, NSS> tuples indicated by the Basic VHT-MCS And NSS Set field of the VHT
18
19 Operation parameter in the MLME-START.request primitive.
20 h1) (#1025)The SME shall refuse an association request from a HE STA that does not support all of the
21 <HE-MCS, NSS> tuples indicated by the Basic HE-MCS And NSS Set field of the HE Operation
22
23 parameter in the MLME-START.request primitive.
24 i) An AP or PCP may refuse GLK association based on local policy and, if so, shall return the
25 GLK_NOT_AUTHORIZED ResultCode.
26
27 NOTE 2—For example, there might be a list of authorized GLK peers or clients or a limit on the number of
28 GLK peers or clients and the peer or client is not on that list or its acceptance would exceed the limit.
29
30 j) The SME shall generate an MLME-ASSOCIATE.response primitive with the PeerSTAAddress
31
parameter set to the MAC address of the STA or the non-AP MLD identified by the
32
33 PeerSTAAddress parameter of the MLME-ASSOCIATE.indication primitive. If the ResultCode in
34 the MLME-ASSOCIATE.response primitive is SUCCESS, the SME has an existing SA with the
35 STA or the non-AP MLD, and an SA Query procedure with that STA or that non-AP MLD has
36 failed to receive a valid response (i.e., has not received an MLME-SA-QUERY.confirm primitive
37
within the dot11AssociationSAQueryMaximumTimeout period or the
38
39 dot11MLDAssociationSAQueryMaximumTimeout period), the SME shall issue an MLME-
40 DISASSOCIATE.request primitive addressed to the STA or the non-AP MLD with ReasonCode
41 INVALID_AUTHENTICATION.
42
43 NOTE 3—This MLME-DISASSOCIATE.request primitive generates a protected Disassociation frame. If the
44 association request was genuine, the STA has deleted the PTKSA by this point and so the protected
45 Disassociation frame is ignored. The purpose is to inform a STA which has for some reason failed to respond to
46 an SA Query procedure triggered by a forged association request.
47
48 k) If the ResultCode in the MLME-ASSOCIATE.response primitive is SUCCESS, all the states,
49 agreements and allocations pertaining to the associating STA or the associating non-AP MLD and
50
listed in both numbered lists in 11.3.6.4 (Non-AP, non-AP MLD, and non-PCP STA reassociation
51
52 initiation procedures) item c) are deleted or reset to initial values.
53 l) If the ResultCode in the MLME-ASSOCIATE.response primitive is SUCCESS, the SME shall
54 delete any PTKSA, GTKSA, IGTKSA, BIGTKSA, WIGTKSA and temporal keys held for
55
56 communication with the STA or non-AP MLD by using the MLME-DELETEKEYS.request
57 primitive (see 12.5.18 (RSNA security association termination)).
58 m) If the MLME-ASSOCIATE.indication primitive includes an MMS parameter, the AP or PCP shall
59
generate the MLME-ASSOCIATE.response primitive directed to the MLME of the STA identified
60
61 by the PeerSTAAddress parameter of the MLME-ASSOCIATE.request primitive and take the
62 following additional action, as appropriate:
63 1) If the Single AID field in the MMS parameter of the MLME-ASSOCIATE.indication primitive
64
65 is equal to 1, the AP or PCP may allocate a single AID for all of the STAs included in the MMS

Copyright © 2022 IEEE. All rights reserved. 291

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 element. If the AP or PCP allocates the same AID to each STA whose MAC address was
2 included in the MMS element, it shall include the MMS element received from the MM-SME
3
coordinated STA in the MLME-ASSOCIATE.response primitive.
4
5 2) If the Single AID field is 0, the AP or PCP shall allocate a distinct AID for each STA specified
6 in the MMS element.
7
8 NOTE 4—When the Single AID field is 0, a separate association request/response exchange is performed for
9 each STA specified in the MMS element, and this assigns the multiple AIDs for the STAs.
10
11 n) If an Association Response frame with a status code of SUCCESS is acknowledged by the STA or
12 the non-AP MLD, the state for the STA or for the non-AP MLD shall be set to State 4 or, if
13
14 dot11RSNAActivated is true, State 3.
15 o) If the ResultCode in the MLME-ASSOCIATE.response primitive is not SUCCESS and
16 management frame protection is in use the state for the STA or for the non-AP MLD shall be left
17
unchanged. If the ResultCode is not SUCCESS and management frame protection is not in use the
18
19 state for the STA or for the non-AP MLD shall be set to State 3 if it was State 4.
20 p) If the ResultCode in the MLME-ASSOCIATE.response primitive is SUCCESS and RSNA
21 establishment is required, and FILS authentication was not used, the SME shall attempt a 4-way
22
23 handshake with the STA or with the non-AP MLD. Upon a successful completion of the 4-way
24 handshake, the SME shall enable protection by issuing an MLME-
25 SETPROTECTION.request(Rx_Tx) primitive. If FILS authentication was used, the SME shall
26 enable protection by generating an MLME-SETPROTECTION.request(Rx_Tx) primitive. In either
27 case, upon receipt of the MLME-SETPROTECTION.request(Rx_Tx) primitive, the MLME shall
28
29 set the state for the STA or with the non-AP MLD to State 4.
30 q) AP or AP MLD only: The SME shall inform the DS of any changes in the state of the STA or of the
31 non-AP MLD.
32
33
34 Change the title of the subclause 11.3.6.4 as follows:
35
36 11.3.6.4 Non-AP, non-AP MLD, and non-PCP STA reassociation initiation procedures
37
38
39 Change the first paragraph as follows:
40
41 Except when the association is part of a fast BSS transition, the SME shall delete any PTKSA, GTKSA,
42 IGTKSA, BIGTKSA, WIGTKSA and temporal keys held for communication with the AP, AP MLD, or PCP
43
by using the MLME-DELETEKEYS.request primitive (see 12.6.18 (RSNA security association termination))
44
45 before invoking an MLME-REASSOCIATE.request primitive.
46
47 Insert the following paragraph after the fourth paragraph (“Upon receipt of an MLME-
48 REASSOCIATE.request primitive that is ...”):
49
50
51 For a non-AP MLD associated with an AP MLD, a non-AP STA that is affiliated with the non-AP MLD and
52 has MAC address not equal to the MLD MAC address of the non-AP MLD shall not send a Reassociation
53 Request frame without (#8308)Basic Multi-Link element to any AP affiliated with that AP MLD.
54
55
56
Change the now-shifted sixth paragraph as follows:
57
58 Upon receipt of an MLME-REASSOCIATE.request primitive, a non-AP, non-AP MLD, and non-PCP STA
59 shall reassociate with an AP, AP MLD, or PCP, respectively, using the following procedure:
60
61 a) If the STA (with respect to the AP or PCP) or non-AP MLD (with respect to the AP MLD) is not
62 associated in the same ESS or the state for the new AP, AP MLD, or PCP is State 1, the MLME shall
63 inform the SME of the failure of the reassociation by issuing an MLME-REASSOCIATE.confirm
64 primitive, and this procedure ends.
65

292 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 b) (#2896)(#1211)The MLMEnon-AP STA shall transmit a Reassociation Request frame to the new
2 AP or PCP or a non-AP STA affiliated with the non-AP MLD shall transmit a Reassociation
3
Request frame with (#6700)Basic Multi-Link element in the Reassociation Request frame to an AP
4
5 affiliated with the new AP MLD. The RSNE contained in the MLME-ASSOCIATE.request
6 primitive shall be included in the Reassociation Request frame. The RSNE shall specify exactly one
7 pairwise cipher suite and exactly one AKM suite. If the MLME-REASSOCIATE.request primitive
8 contained the EmergencyServices parameter equal to true, an Interworking element with the UESA
9
field set to 1 shall be included in the Reassociation Request frame.
10
11 c) If a Reassociation Response frame is received with a status code of SUCCESS, the state variable for
12 the new AP, AP MLD, or PCP shall be set to State 4 or to State 3 if dot11RSNAActivated is true and
13 the FT protocol is not used with respect to the new AP, AP MLD, or PCP and, unless the old AP, AP
14
15 MLD, or PCP and new AP, AP MLD, or PCP, respectively, are the same, to State 2 with respect to
16 the old AP, AP MLD, or PCP, and the MLME shall issue an MLME-REASSOCIATE.confirm
17 primitive to inform the SME of the successful completion of the reassociation.
18
If the MLME-REASSOCIATION.request primitive has the new AP’s, AP MLD’s, or PCP’s MAC
19
20 address in the CurrentAPAddress parameter (reassociation to the same AP, AP MLD, or PCP), the
21 following states, agreements and allocations shall be deleted or reset to initial values:
22 1) All EDCAF state
23
24 2) Any block ack agreements that are not GCR agreements
25 3) Sequence number
26
27 4) Packet number
28 5) Duplicate detection caches
29
30 6) Anything queued for transmission
31 7) Fragmentation and reassembly buffers
32
33 8) Power management mode
34 9) WNM sleep mode
35
36 10) TPKSAs established with any peers
37 11) TSPECs
38
39 12) DMG TSPECs
40 13) GLK-GCR agreement
41
42 14) MSCS
43 15) SCS
44
45 16) (#1848)TWT
46
47 If the reassociation is to the same AP (as described above), the following states, agreements and
48 allocations are not affected by the reassociation procedure:
49 1) PSMP sessions
50
51 2) Enablement/Deenablement
52 3) GDD enablement
53
54 4) TDLS agreements
55 5) MMSLs
56
57 6) GCR agreements that are not GLK-GCR agreements
58 7) DMS agreements
59
60 8) TFS agreements
61 9) FMS agreements
62
63 10) Triggered autonomous reporting agreements
64 11) FTM sessions
65

Copyright © 2022 IEEE. All rights reserved. 293

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 12) DMG SP and CBAP allocations

2
3 13) PTP TSPECs.
4 (#1849)In the case of reassociation to a different AP, AP MLD, or PCP (the CurrentAPAddress
5 parameter is not the new AP’s or PCP’s MAC address or the new AP MLD’s MAC address), all the
6
states, agreements and allocations listed above are deleted or reset to initial values.
7
8 d) If a Reassociation Response frame is received with a status code of SUCCESS, a DMG STA shall
9 write to each of the following MIB attributes the corresponding subfield of the DMG BSS Parameter
10 Configuration field of the DMG Operation element received from the AP or PCP to which it
11
12 requested reassociation:
13 1) dot11PSRequestSuspensionInterval from the PSRequestSuspensionInterval subfield
14
15 2) dot11MinBHIDuration from the MinBHIDuration subfield
16 3) dot11BroadcastSTAInfoDuration from the BroadcastSTAInfoDuration subfield
17
18 4) dot11AssocRespConfirmTime from the AssocRespConfirmTime subfield
19 5) dot11MinPPDuration from the MinPPDuration subfield
20
21 6) dot11SPIdleTimeout from the SPIdleTimeout subfield
22 7) dot11MaxLostBeacons from the MaxLostBeacons subfield
23
24 e) If an Association Response frame is received with a status code of SUCCESS at an MM-SME
25 coordinated STA and the Single AID field within the MMS element is equal to 1, then
26 — For each of its MAC entities advertised within the MMS element and for which
27
dot11RSNAActivated is true, the state is set to State 3. Progress from State 3 to State 4 occurs
28
29 independently in each such MAC entity.
30 — For each of its MAC entities advertised within the MMS element and for which
31 dot11RSNAActivated is false, the state is set to State 4.
32
33 — For each of its MAC entities advertised within the MMS element the state for any other AP or
34 PCP which is State 3 or State 4 prior to the association request shall be set to State 2.
35
36 f) If a Reassociation Response frame is received with a status code other than SUCCESS or the
37 reassociation fails to complete within dot11AssociationResponseTimeout:
38 1) Except when the association is part of a fast BSS transition, the state for the AP, AP MLD, or
39
PCP shall be set to State 2 with respect to the new AP, AP MLD, or PCP.
40
41 2) The MLME shall issue an MLME-REASSOCIATE.confirm primitive to inform the SME of
42 the failure of the reassociation. The ResultCode returned in the MLME-
43 REASSOCIATE.confirm primitive indicates the cause of the failed reassociation attempt. Any
44
45 misconfiguration or parameter mismatch, e.g., data rates required as basic rates that the STA
46 did not indicate as supported in the STA’s Supported Rates and BSS Membership Selectors
47 element, shall be corrected before the SME issues an MLME-REASSOCIATE.request
48 primitive for the same AP, AP MLD, or PCP. If the status code indicates the reassociation
49 failed because of a reason that is not related to configuration (e.g., the AP or PCP is unable to
50
51 support additional associations) and the Reassociation Response frame does not include a
52 Timeout Interval element with Timeout Interval Type equal to 3 the SME shall not issue an
53 MLME-REASSOCIATE.request primitive for the same AP, AP MLD, or PCP until a period of
54 at least 2 s has elapsed. If the status code indicates the reassociation failed and the
55 Reassociation Response frame contains a Timeout Interval element with Timeout Interval Type
56
57 equal to 3, the SME shall not issue an MLME-REASSOCIATE.request primitive for the same
58 AP, AP MLD, or PCP until the period specified in the Timeout Interval element has elapsed.
59 g) If an MLME-REASSOCIATE.confirm primitive is received with a ResultCode of SUCCESS, and
60
RSNA is required, and FILS authentication was not used, and the STA or the non-AP MLD is in
61
62 State 3, then the SME shall perform a 4-way handshake to establish an RSNA with the STA or the
63 AP MLD. As a part of a successful 4-way handshake, the SME shall enable protection by generating
64
65

294 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 an MLME-SETPROTECTION.request(Rx_Tx) primitive. If an MLME-REASSOCIATE.confirm

2 primitive is received with a ResultCode of SUCCESS, and FILS authentication was used, and the
3
STA is in State 3, then the SME shall enable protection by generating an MLME-
4
5 SETPROTECTION.request(Rx_Tx) primitive.
6 h) Upon receipt of the MLME-SETPROTECTION.request(Rx_Tx) primitive, the MLME shall set the
7 state of the STA or of the AP MLD to State 4.
8
9
10 Change the title of the subclause 11.3.6.5 as follows:
11
12 11.3.6.5 AP, AP MLD, or PCP reassociation receipt procedures
13
14
15 Insert the following paragraph as the first paragraph of the subclause:
16
17 For a non-AP MLD associated with an AP MLD, if an AP affiliated with the AP MLD receives (#6585)a
18
Reassociation Request frame without (#8308)Basic Multi-Link element from a non-AP STA that is affiliated
19
20 with the non-AP MLD and has MAC address not equal to the MLD MAC address of the non-AP MLD,
21 then the AP shall reject the reassociation request with a status code of
22 DENIED_STA_AFFILIATED_WITH_MLD_WITH_EXISTING_MLD_ASSOCIATION.
23
24
25 Change the remaining paragraphs of the subclause as follows:
26
27 (#2897)(#1211)The following procedure shall be used by an AP or PCP uUpon receipt of a Reassociation
28 Request frame from a STA the AP or PCP shall use the following procedure or by an AP affiliated with an AP
29
MLD upon receipt of a Reassociation Request frame with (#6700)Basic Multi-Link element from a non-AP
30
31 STA affiliated with a non-AP MLD:
32 a) The MLME shall issue an MLME-REASSOCIATE.indication primitive to inform the SME of the
33 reassociation request. The SME shall issue an MLME-REASSOCIATE.response primitive
34
35 addressed to the STA or the non-AP MLD identified by the PeerSTAAddress parameter of the
36 MLME-REASSOCIATE.indication primitive. If the reassociation is not successful, the SME shall
37 indicate a specific reason for the failure to reassociate in the ResultCode parameter. Upon receipt of
38 the MLME-REASSOCIATE.response primitive, the MLME shall transmit a Reassociation
39 Response frame.
40
41 b) If the state for the STA is 1 and the STA is a non-DMG STA or the state for the non-AP MLD is 1,
42 the SME shall refuse the reassociation request by issuing an MLME REASSOCIATE.response
43 primitive with ResultCode NOT_AUTHENTICATED.
44
45 c) AP with dot11InterworkingServiceActivated true only: If the MLME-REASSOCIATE.indication
46 primitive has the EmergencyServices parameter set to true and the RSN parameter does not include
47 an RSNE, the SME shall not reject the reassociation request on the basis that dot11RSNAActivated
48 is true and dot11PrivacyInvoked is true thereby granting access, using unprotected frames (see
49
50 9.2.4.1.9 (Protected Frame subfield)), to the network for emergency services purposes.
51 d) Otherwise, in an RSNA the SME shall check the values received in the RSN parameter to see
52 whether the values received match the security policy. If they do not, SME shall refuse the
53
reassociation by issuing an MLME-REASSOCIATE.response primitive with a ResultCode
54
55 indicating the security policy mismatch.
56 e) Otherwise, if the state for the STA or the non-AP MLD is 4, the STA or the non-AP MLD has a
57 valid security association, the STA or the non-AP MLD has negotiated management frame
58
59 protection, the reassociation is not a part of a fast BSS transition, the STA or the non-AP MLD has
60 not performed a successful SAE authentication after the current association was established, and
61 there has been no earlier, timed out SA Query procedure with the STA or the non-AP MLD (which
62 would have allowed a new reassociation process to be started, without an additional SA Query
63 procedure):
64
65

Copyright © 2022 IEEE. All rights reserved. 295

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 1) The SME shall refuse the reassociation request by issuing an MLME-REASSOCI-

2 ATE.response primitive with ResultCode REFUSED_TEMPORARILY and TimeoutInterval
3
containing a Timeout Interval element with the Timeout Interval Type field set to 3 (Associa-
4
5 tion Comeback time). If the SME is in an ongoing SA Query with the STA or the non-AP
6 MLD, the Timeout Interval Value field shall be set to the remaining SA Query period, other-
7 wise it shall be set to dot11AssociationSAQueryMaximumTimeout or dot11MLDAssociation-
8 SAQueryMaximumTimeout.
9
10 2) The state for the STA or the non-AP MLD shall be left unchanged.
11 3) Following this, if the SME is not in an ongoing SA Query with the STA or the non-AP MLD,
12
the SME shall issue one MLME-SA-QUERY.request primitive addressed to the STA or the
13
14 non-AP MLD every dot11AssociationSAQueryRetryTimeout TUs until an MLME-SA-
15 QUERY.confirm primitive for the STA or the non-AP MLD is received or
16 dot11AssociationSAQueryMaximumTimeout TUs or
17 dot11MLDAssociationSAQueryMaximumTimeout TUs from the beginning of the SA Query
18
procedure have passed. The SME shall increment the TransactionIdentifier by 1 for each
19
20 MLME-SA-QUERY.request primitive, rolling it over to 0 after the maximum allowed value is
21 reached.
22 4) If no MLME-SA-QUERY.confirm primitive for a STA or a non-AP MLD is received within
23
24 the dot11AssociationSAQueryMaximumTimeout period or the
25 dot11MLDAssociationSAQueryMaximumTimeout period, the SME shall allow a subsequent
26 reassociation process to be started without starting an additional SA Query procedure, except
27 that the SME may deny a subsequent reassociation process with the STA or the non-AP MLD
28 if an MSDU was received from the STA or any affiliated STA of the non-AP MLD within this
29
30 period.
31 NOTE 1—Reception of an MSDU implies reception of a valid protected frame, which obviates the need
32 for the SA Query procedure.
33
34
35 f) (#1025)The SME shall refuse a reassociation request from a STA that does not support all the rates
36 in the BSSBasicRateSet parameter and all of the membership selectors in the
37 BSSMembershipSelectorSet parameter in the MLME-START.request primitive.
38
g) (#1025)The SME shall refuse a reassociation request from an HT STA that does not support all of
39
40 the MCSs in the Basic HT-MCS Set field of the HT Operation parameter in the MLME-
41 START.request primitive.
42 h) (#1025)The SME shall refuse a reassociation request from a VHT STA that does not support all of
43
44 the <VHT-MCS, NSS> tuples indicated by the Basic VHT-MCS And NSS Set field of the VHT
45 Operation parameter in the MLME-START.request primitive.
46 h1) (#1025)The SME shall refuse a reassociation request from a HE STA that does not support all of the
47
<HE-MCS, NSS> tuples indicated by the Basic HE-MCS And NSS Set field of the HE Operation
48
49 parameter in the MLME-START.request primitive.
50 i) If the ResultCode in the MLME-REASSOCIATE.response primitive is SUCCESS, the SME has an
51 existing SA with the STA or the non-AP MLD, and an SA Query procedure with that STA or the
52
53 non-AP MLD has failed to receive a valid response (i.e., has not received an MLME-SA-
54 QUERY.confirm primitive within the dot11AssociationSAQueryMaximumTimeout period or the
55 dot11MLDAssociationSAQueryMaximumTimeout period), the SME shall issue an MLME-
56 DISASSOCIATE.request primitive addressed to the STA or the non-AP MLD with ReasonCode
57 INVALID_AUTHENTICATION.
58
59 NOTE 2—This MLME-DISASSOCIATE.request primitive generates a protected Disassociation frame. If the
60 reassociation request was genuine, the STA or the non-AP MLD has deleted the PTKSA by this point and so
61 the protected Disassociation frame is ignored. The purpose is to inform a STA which has for some reason failed
62 to respond to an SA Query procedure triggered by a forged reassociation request.
63
64
65

296 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 j) If the ResultCode in the MLME-REASSOCIATE.response primitive is SUCCESS and the

2 reassociation is not part of a fast BSS transition, the SME shall delete any PTKSA, GTKSA,
3
IGTKSA, BIGTKSA, WIGTKSA and temporal keys held for communication with the STA or the
4
5 non-AP MLD by using the MLME-DELETEKEYS.request primitive (see 12.5.18 (RSNA security
6 association termination)).
7 k) If the MLME-REASSOCIATE.indication primitive includes an MMS parameter, the AP or PCP
8
9 shall take the following additional action, as appropriate:
10 1) If the Single AID field in the MMS parameter of the MLME-REASSOCIATE.indication prim-
11 itive is equal to 1, the AP or PCP may allocate a single AID for all of the STAs included in the
12
MMS element. If the AP or PCP allocates the same AID to all STAs whose MAC address was
13
14 included in the MMS element, it shall include the MMS element received from the MM-SME
15 coordinated STA in the MLME-REASSOCIATE.response primitive.
16 2) If the Single AID field is 0, the AP or PCP shall allocate a distinct AID for each STA specified
17
18 in the MMS element.
19 NOTE 3—When the Single AID field is 0, a separate reassociation request/response exchange is performed for
20 each STA specified in the MMS element, and this assigns the multiple AIDs for the STAs.
21
22
23 l) If a Reassociation Response frame with a status code of SUCCESS is acknowledged by the STA or
24 a STA(#4840) affiliated with the non-AP MLD, the state for the STA or the non-AP MLD shall be
25 set to State 4, or to State 3 if dot11RSNAActivated is true and the reassociation is not part of a fast
26 BSS transition.
27
28 m) If the ResultCode in the MLME-REASSOCIATE.response primitive is not SUCCESS and
29 management frame protection is in use the state for the STA or the non-AP MLD shall be left
30 unchanged. If the ResultCode is not SUCCESS, management frame protection is not in use, and the
31 reassociation is part of a fast BSS transition, the state for the STA or the non-AP MLD shall be left
32
unchanged. If the ResultCode is not SUCCESS, management frame protection is not in use, and the
33
34 reassociation is not part of a fast BSS transition, the state for the STA or the non-AP MLD shall be
35 set to State 3 if it was State 4.
36 n) If the ResultCode in the MLME-REASSOCIATE.response primitive is SUCCESS, RSNA
37
38 establishment is required, and the reassociation is not part of a fast BSS transition, and FILS is not in
39 use, the SME shall attempt a 4-way handshake with the STA or with the non-AP MLD. Upon a
40 successful completion of a 4-way handshake, the SME shall enable protection by issuing an MLME-
41 SETPROTECTION.request(Rx_Tx) primitive. If FILS authentication was used, the SME shall
42 enable protection by generating an MLME-SETPROTECTION.request(Rx_Tx) primitive. In either
43
44 case, upon receipt of the MLME-SETPROTECTION.request(Rx_Tx) primitive, the MLME shall
45 set the state for the STA or the non-AP MLD to State 4.
46 o) AP or AP MLD only: The SME shall inform the DS of any changes in the state of the STA or the
47
non-AP MLD.
48
49 p) If the ResultCode in the MLME-REASSOCIATE.response primitive is SUCCESS and the
50 CurrentAPAddress parameter in the MLME-REASSOCIATION.indication primitive is this AP’s or
51 PCP’s MAC address (reassociation to the same AP or PCP), the AP or PCP shall match the non-AP
52
53 STA’s treatment of the listed agreements and allocations as described in 11.3.6.4 (Non-AP, non-AP
54 MLD, and non-PCP STA reassociation initiation procedures)item c). The AP or PCP deletes or
55 resets to initial values those items that the non-AP STA is required in 11.3.6.4 (Non-AP, non-AP
56 MLD, and non-PCP STA reassociation initiation procedures)item c) to delete or reset to initial
57 values, and the AP or PCP does not modify the states, agreements and allocations that are listed as
58
59 not affected by the reassociation procedure.
60 p1) If the ResultCode in the MLME-REASSOCIATE.response primitive is SUCCESS and the
61 CurrentAPAddress parameter in the MLME-REASSOCIATION.indication primitive is this AP
62
MLD’s (#8310)MLD MAC address (reassociation to the same AP MLD), the AP MLD shall match
63
64 the non-AP MLD’s treatment of the listed agreements and allocations as described in 11.3.6.4 (Non-
65 AP, non-AP MLD, and non-PCP STA reassociation initiation procedures) item c). The AP MLD

Copyright © 2022 IEEE. All rights reserved. 297

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 deletes or resets to initial values those items that the non-AP MLD is required in 11.3.6.4 (Non-AP,
2 non-AP MLD, and non-PCP STA reassociation initiation procedures) item c) to delete or reset to
3
initial values, and the AP MLD does not modify the states, agreements and allocations that are listed
4
5 as not affected by the reassociation procedure.
6 q) If the ResultCode in the MLME-REASSOCIATE.response primitive is SUCCESS and the
7 CurrentAPAddress parameter in the MLME-REASSOCIATION.indication primitive is not this
8
9 AP’s or PCP’s MAC address (reassociation to a different AP or PCP), all the states, agreements and
10 allocations pertaining to the associating STA and listed in both numbered lists in 11.3.6.4 (Non-AP,
11 non-AP MLD, and non-PCP STA reassociation initiation procedures) item c) are deleted or reset to
12 initial values.
13
14 q1) If the ResultCode in the MLME-REASSOCIATE.response primitive is SUCCESS and the
15 CurrentAPAddress parameter in the MLME-REASSOCIATION.indication primitive is not this AP
16 MLD’s (#8311)MLD MAC address (reassociation to a different AP MLD), all the states,
17 agreements and allocations pertaining to the associating non-AP MLD and listed in both numbered
18
lists in 11.3.6.4 (Non-AP, non-AP MLD, and non-PCP STA reassociation initiation procedures)
19
20 item c) are deleted or reset to initial values.
21
22 Change the title of the subclause 11.3.6.6 as follows:
23
24
25 11.3.6.6 Non-AP, non-AP MLD, and non-PCP STA disassociation initiation procedures
26
27 Change the second paragraph as follows:
28
29
Upon receipt of an MLME-DISASSOCIATE.request primitive, a non-AP, non-AP MLD, and non-PCP STA’s
30
31 MLME shall disassociate from an AP, AP MLD, or PCP, respectively, using the following procedure:
32 a) If the state for the AP, AP MLD, or PCP is State 3 or State 4, the MLME shall transmit a
33 Disassociation frame to the AP, AP MLD, or PCP.
34
35 b) The state for the AP, AP MLD, or PCP shall be set to State 2 if it was not State 1. In the case of an
36 MM-SME coordinated STA, the MLME shall perform this for each STA whose address was
37 included in the MMS parameter of the MLME-ASSOCIATE.request or MLME-
38
REASSOCIATE.request primitive that established the association.
39
40 c) The MLME shall issue an MLME-DISASSOCIATE.confirm primitive to inform the SME of the
41 successful completion of the disassociation.
42
43 d) Upon receiving an MLME-DISASSOCIATE.confirm primitive, the SME shall delete any PTKSA,
44 GTKSA, IGTKSA, BIGTKSA, WIGTKSA and temporal keys held for communication with the AP,
45 AP MLD, or PCP by using the MLME-DELETEKEYS.request primitive (see 12.6.18 (RSNA
46 security association termination)) and by invoking an MLME-SETPROTECTION.request(None)
47
primitive. In the case of an MM-SME coordinated STA, the MLME shall perform this for each STA
48
49 whose address was included in the MMS parameter of the MLME-ASSOCIATE.request or MLME-
50 REASSOCIATE.request primitive that established the association.
51
52 Change the title of the subclause 11.3.6.7 as follows:
53
54
55 11.3.6.7 Non-AP, non-AP MLD, and non-PCP STA disassociation receipt procedure
56
57 Change as follows:
58
59
60 Upon receipt of a Disassociation frame from an AP, AP MLD, or PCP for which the state is State 3 or State 4,
61 if management frame protection was not negotiated when the PTKSA(s) were created, or if management frame
62 protection is in use and the frame is not discarded per management frame protection processing, a non-AP,
63 non-AP MLD, and non-PCP STA, respectively, shall disassociate from the AP, AP MLD, or PCP using the
64
65 following procedure:

298 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 a) The state for the AP, AP MLD, or PCP shall be set to State 2.
2
3 b) The MLME shall issue an MLME-DISASSOCIATE.indication primitive to inform the SME of the
4 disassociation.
5 c) Upon receiving the MLME-DISASSOCIATE.indication primitive, the SME shall delete any
6
PTKSA, GTKSA, IGTKSA, BIGTKSA, WIGTKSA and temporal keys held for communication
7
8 with the AP, AP MLD, or PCP by using the MLME-DELETEKEYS.request primitive (see
9 12.6.18 (RSNA security association termination)) and by invoking an MLME-
10 SETPROTECTION.request(None) primitive. The MM-SME shall perform this process for each
11 STA whose address was included in the MMS parameter of the MLME-ASSOCIATE.request or
12
MLME-REASSOCIATE.request primitive that established the association.
13
14 d) If the reason code indicates a configuration or parameter mismatch as the cause of the
15 disassociation, the SME shall not attempt to associate or reassociate with the AP, AP MLD, or PCP
16 until the configuration or parameter mismatch has been corrected.
17
18 e) If the reason code indicates the STA (with respect to AP or PCP) or non-AP MLD (with respect to
19 the AP MLD), was disassociated for a reason other than configuration or parameter mismatch, the
20 SME shall not attempt to associate or reassociate with the AP, AP MLD, or PCP until a period of 2s
21
has elapsed.
22
23
24 Change the title of the subclause 11.3.6.8 as follows:
25
26 11.3.6.8 AP, AP MLD, or PCP disassociation initiation procedure
27
28
29 Change the second paragraph as follows:
30
31 Upon receipt of an MLME-DISASSOCIATE.request primitive, an AP, AP MLD, or PCP shall disassociate a
32
STA (with respect to the AP or PCP) or a non-AP MLD (with respect to the AP MLD) using the following
33
34 procedure:
35 a) If the state for the STA or the non-AP MLD is State 3 or State 4, the AP or PCP (with respect to the
36 STA) or AP MLD (with respect to the non-AP MLD) shall generate a Disassociation frame to be
37
38 transmitted to the indicated STA or an non-AP STA affiliated with the non-AP MLD.
39 NOTE—As the Disassociation frame is a bufferable MMPDU, the transmission of this frame might be delayed
40 by the operation of a power saving protocol. The AID and the PTKSA are maintained (when applicable) until
41 the frame is acknowledged or attempts to transmit the frame are abandoned.
42
43
44 b) The state for the STA or the non-AP MLD shall be set to State 2, if it was not State 1. The MM-SME
45 shall perform this process for each STA whose address was included in the MMS parameter of the
46 MLME-ASSOCIATE.request or MLME-REASSOCIATE.request primitive that established the
47 association.
48
49 c) Once the Disassociation frame is acknowledged or attempts to transmit the frame are abandoned, the
50 MLME shall issue an MLME-DISASSOCIATE.confirm primitive to inform the SME of the
51 disassociation.
52
53 d) Upon receiving an MLME-DISASSOCIATE.confirm primitive, the SME shall delete any PTKSA,
54 GTKSA, IGTKSA, BIGTKSA, WIGTKSA and temporal keys held for communication with the
55 STA or the non-AP MLD by using the MLME-DELETEKEYS.request primitive (see
56 12.6.18 (RSNA security association termination)) and by invoking an MLME-
57 SETPROTECTION.request(None) primitive. The MM-SME shall perform this process for each
58
59 STA whose address was included in the MMS parameter of the MLME-ASSOCIATE.request or
60 MLME-REASSOCIATE.request primitive that established the association.
61 e) Upon receiving an MLME-DISASSOCIATE.confirm primitive, the SME shall release the AID
62
assigned for the indicated STA or the indicated non-AP MLD, if the state for the indicated STA or
63
64 the indicated non-AP MLD was State 3 or State 4.
65

Copyright © 2022 IEEE. All rights reserved. 299

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 f) AP or AP MLD only: The SME shall inform the DS of the disassociation.

2
3
4
Change the title of the subclause 11.3.6.9 as follows:
5
6 11.3.6.9 AP, AP MLD, or PCP disassociation receipt procedure
7
8 Change as follows:
9
10
11 Upon receipt of a Disassociation frame from a STA or a non-AP MLD for which the state is State 3 or State 4,
12 if management frame protection was not negotiated when the PTKSA(s) were created, or if management frame
13 protection is in use and the frame is not discarded per management frame protection processing, the AP or PCP
14
(with respect to the STA) or AP MLD (with respect to the non-AP MLD) shall disassociate the STA or the non-
15
16 AP MLD using the following procedure:
17 a) The state for the STA or the non-AP MLD shall be set to State 2. The MM-SME shall perform this
18 process for each STA whose address was included in the MMS parameter of the MLME-
19
20 ASSOCIATE.request or MLME-REASSOCIATE.request primitive that established the association.
21 b) The MLME shall issue an MLME-DISASSOCIATE.indication primitive to inform the SME of the
22 disassociation.
23
24 c) Upon receiving an MLME-DISASSOCIATE.indication primitive the SME shall delete any PTKSA,
25 GTKSA, IGTKSA, BIGTKSA, WIGTKSA and temporal keys held for communication with the
26 STA or the non-AP MLD by using the MLME-DELETEKEYS.request primitive (see
27 12.6.18 (RSNA security association termination)) and by invoking an MLME-
28
29 SETPROTECTION.request(None) primitive. The MM-SME shall perform this process for each
30 STA whose address was included in the MMS parameter of the MLME-ASSOCIATE.request or
31 MLME-REASSOCIATE.request primitive that established the association.
32
d) AP or AP MLD only: The SME shall inform the DS of the disassociation.
33
34 e) The SME shall release the AID assigned for the indicated STA or the indicated non-AP MLD.
35
36
37 11.8 DFS procedures
38
39
11.8.3 Quieting channels for testing
40
41
42 Insert the following paragraph and note at the end of the subclause:
43
44 (#2132)(#2166)An EHT AP shall follow the rules defined in 9.4.2.22 (Quiet element) to set the fields in the
45
46 Quiet element and shall not schedule quiet intervals that would require a value higher than 127 in the Quiet
47 Count field.
48
(#2132)(#2166)NOTE—Quiet element carried in a per-STA profile of (#6700)Basic Multi-Link element corresponding
49
to a reported AP can have the Quiet Count field set to a value higher than 127 to indicate a quiet interval that the reported
50
AP has started in the past on the link on which the reported AP operates. The number of TBTTs in the past is computed
51
as defined in 9.4.2.22 (Quiet element).
52
53
54 11.13 SA Query procedures
55
56
57 Change the first three paragraphs follows:
58
59 If dot11RSNAProtectedManagementFramesActivated is true, then the STA or MLD shall support the SA
60
61 Query procedure.
62
63 To send an SA Query Request or SA Query Response frame to a peer STA or a peer MLD, the SME shall issue
64 an MLME-SA-QUERY.request or MLME-SA-QUERY.response primitive respectively. Reception of an SA
65

300 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Query Request or SA Query Response frame is signaled to the SME with an MLME-SA-QUERY.indication or
2 MLME-SA-QUERY.confirm primitive respectively.
3
4
5 A STA or a MLD that supports the SA Query procedure and receives an SA Query Request frame shall
6 respond with an SA Query Response frame if none of the following are true:
7 — the STA or the non-AP MLD is not currently associated to the STA or the AP MLD that sent the SA
8
9 Query Request frame
10 — the STA has sent a (Re)Association Request frame within dot11AssociationResponseTimeOut but
11 has not received a corresponding (Re)Association Response frame
12
13 — dot11RSNAOperatingChannelValidationActivated is true and the sending STA had indicated
14 OCVC capability in its association and either:
15
— OCI element is not present in the request
16
17 — Operating channel information indicated does not match the current channel information (see
18 12.2.9 (Requirements for Operating Channel Validation))
19
20
21 Insert the following paragraph after the eighth paragraph (“If a non-AP and non-PCP STA that
22 has ...”)
23
24
If an affiliated non-AP STA of a non-AP MLD that has an SA with its AP MLD for an association that
25
26 negotiated management frame protection receives an unprotected Deauthentication or Disassociation frame
27 with reason code INVALID_CLASS2_FRAME or INVALID_CLASS3_FRAME from the corresponding
28 affiliated AP of the AP MLD in a setup link, the non-AP MLD may use this as an indication that there might
29 be a mismatch in the association state between itself and the AP MLD. In such a case, the SME may initiate
30
the SA Query procedure with the AP MLD to verify the validity of the SA by issuing one
31
32 MLME-SA-QUERY.request primitive every dot11AssociationSAQueryRetryTimeout TUs until a matching
33 MLME-SA-QUERY.confirm primitive is received or dot11MLDAssociationSAQueryMaximumTimeout
34 TUs from the beginning of the SA Query procedure has passed. If the AP MLD responds to the SA Query
35 request with a valid SA Query response, the non-AP MLD should continue to use the SA. If no valid SA
36
Query response is received, the SME may delete the SA and temporal keys held for communication with the
37
38 AP MLD by issuing an MLME-DELETEKEYS.request primitive and the non-AP MLD may move into
39 State 1 with the AP MLD.
40
41
42 11.20 Tunneled direct-link setup
43
44 11.20.1 General
45
46
47 Change the 14th paragraph, including the addition of Table 11-13a (Frame type and their
48 pathway in a TDLS setup(#4032)), as follows:
49
50
51 TDLS frames shall use the formatting specified in 11.20.2 (TDLS payload) when they are transmitted
52 through the AP and when they are transmitted over the TDLS direct link. A STA shall not transmit a TDLS
53 Action field in a frame with the Type field of the frame set to Management. A received TDLS Action field in
54 a frame with the Type field equal to Management shall be discarded. Note that the TDLS Discovery
55
Response frame is not a TDLS frame but a Public Action frame. (#4032)Table 11-13a (Frame type and their
56
57 pathway in a TDLS setup(#4032)) shows the frame that can be exchanged between the TDLS peer STAs and
58 the path taken by each of them.
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 301

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 11-13a—Frame type and their pathway in a TDLS setup(#4032)

2
3
4 Frame Pathway (link) Frame type Description
5
6 TDLS Discovery Request frame Via AP Data frame See 11.20.3 (TDLS
7 Discovery).
8 TDLS Discovery Response frame Direct Public Action Can be sent unsolicited (i.e.,
9 (Management frame) without receiving a TDLS
10 Discovery Request frame). See
11 11.20.3 (TDLS Discovery).
12
13 TDLS Setup Request frame Via AP Data frame See 11.20.4 (TDLS direct-link
14 TDLS Setup Response frame establishment).
15 TDLS Setup Confirm frame
16
17 TDLS Teardown frame Direct or via AP Data frame The frame is sent via the AP if
18 the TDLS peer is not
19 reachable. See 11.20.5 (TDLS
20 direct-link teardown).
21 TDLS Channel Switch Request Direct Data frame See 11.20.6 (TDLS channel
22 frame switching).
23 TDLS Channel Switch Response
24 frame
25
26 TDLS Peer PSM Request frame Direct or via AP Data frame See 11.2.3.12 (TDLS peer
27 power save mode)
28 TDLS Peer PSM Response frame Direct
29 TDLS Peer Traffic Indication Via AP Data frame See 11.2.3.13 (TDLS peer U-
30 frame APSD (TPU))
31
32 TDLS Peer Traffic Response frame Direct
33
34 Data frame or Control frame Direct Data and Control frames
35 exchange after TDLS session is
36 successfully established.
37 GAS frame carrying TDLS Direct Public Action Discovery of TDLS peer STAs.
38 Capability ANQP-element (Management frame) See 11.22.3.3.10 (TDLS
39 Capability procedure),
40
41
42
43 Insert the following paragraphs as the last paragraph of the subclause:
44
45 (#1022)The EHT Operation element shall be present in a TDLS Setup Confirm frame when both STAs are
46
47 EHT capable.
48
49 (#7616)When a STA receives a TDLS Setup Request frame or TDLS Setup Response frame from a peer
50 STA that includes one or more elements among the HT Capabilities, VHT Capabilities, HE Capabilities, HE
51 6 GHz Band Capabilities, S1G Capabilities, or EHT Capabilities element, it shall ignore the fields that do
52
53 not apply to the TDLS direct link with the peer STA.
54
55
56 11.21 Wireless network management procedures
57
58 11.21.13 BSS max idle period management
59
60
61
Change the first paragraph, including splitting it into the three paragraphs as follows:
62
63
64
65

302 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 If dot11BssMaxIdlePeriod is nonzero or dot11MldMaxIdlePeriod is nonzero, an AP shall include the BSS

2 Max Idle Period element in the (Re)Association Response frame. Otherwise, the AP shall not include the BSS
3
Max Idle Period element in the (Re)Association Response frame.
4
5
6 (#1027)(#8222)When association is for an MLD association (see 11.3 (STA authenticationAuthentication
7 and association(#2277))), the values carried in the BSS Max Idle Period element apply at the MLD level and
8 the associated MLDs follow the MLD max idle period procedure defined in 35.3.12.3 (MLD max idle
9
period management). The rest of this subclause defines the procedure for the BSS max idle period when the
10
11 association is not for an MLD association (see 11.3 (STA authenticationAuthentication and
12 association(#2277))).
13
14 A non-S1G STA may send protected or unprotected keepalive frames, as indicated in the Idle Options field.
15
16
17 Change the now shifted seventh paragraph as follows:
18
19 (#3321)A STA may send at least one protected or unprotected keepalive frame (such as Data frame, PS-Poll
20 frame, or Management frame) per BSSMaxIdlePeriod, as indicated in the Idle Options field. When a STA
21
22 transmits an unprotected keepalive frame, it shall use a frame that has 48-bit TA and RA fields.
23
24 11.21.14 Proxy ARP service
25
26 Change the second, third, and fourth paragraphs as follows:
27
28
29 When the AP sets the Proxy ARP field to 1 in the Extended Capabilities element, the AP shall maintain a
30 Hardware Address to Internet Address mapping for each associated station, and shall update the mapping when
31 the Internet Address of the associated station changes. When the IPv4 address being resolved in the ARP
32
request (IETF RFC 826) is used by a non-AP STA currently associated to the BSS, the proxy ARP service shall
33
34 respond on behalf of the STA to an ARP request or an ARP probe (IETF RFC 5227). (#6715)When an AP
35 MLD supports proxy ARP (see 35.3.24 (Proxy ARP service in AP MLDs(#6715))), the AP MLD shall
36 maintain an MLD MAC address to Internet address mapping for each associated non-AP MLD, and shall
37 update the mapping when the Internet Address of the associated non-AP MLD changes. When the IPv4 address
38
being resolved in the ARP request (IETF RFC 826) is used by a non-AP MLD currently associated with the AP
39
40 MLD, the proxy ARP service shall respond on behalf of the non-AP MLD to an ARP request or ARP probe
41 (IETF RFC 5227).
42
43 When an AP receives an ARP request from one associated STA or from the DS with a target IP address that
44
corresponds to a second associated STA, the AP shall insert the second STA MAC address as the Sender’s
45
46 MAC Address in the ARP response packet. (#6715)When an AP affiliated with an AP MLD receives an ARP
47 request from one associated STA, or from a STA affiliated with a non-AP MLD that is associated with the AP
48 MLD, or from the DS, with a target IP address that corresponds to a second associated STA, the AP shall insert
49 the second STA MAC address as the Sender’s MAC Address in the ARP response packet. When an AP MLD
50
receives an ARP request from a STA associated with an affiliated AP, or from one associated non-AP MLD via
51
52 any affiliated AP, or from the DS, with a target IP address that corresponds to a second associated non-AP
53 MLD, the AP MLD shall insert the MLD MAC address of the second non-AP MLD as the Sender’s MAC
54 Address in the ARP response packet.
55
56
When an IPv6 address is being resolved, the Proxy ARP service shall respond with a Neighbor Advertisement
57
58 message (Section 4.4, IETF RFC 4861) on behalf of an associated STA (#6715)or an associated non-AP MLD
59 to an Internet Control Message Protocol version 6 (ICMPv6) Neighbor Solicitation message (Section 4.3, IETF
60 RFC 4861). When MAC address mappings change, the AP (#6715)or the AP MLD may send unsolicited
61 Neighbor Advertisement Messages on behalf of a STA (#6715)or a non-AP MLD, respectively.
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 303

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 11.22 WLAN interworking with external networks procedures

2
3
4 11.22.3 Interworking procedures: generic advertisement service (GAS)
5
6 11.22.3.3 ANQP procedures
7
8 11.22.3.3.10 TDLS Capability procedure
9
10
11 Insert the following NOTE at the end of the subclause:
12
13 (#4032)NOTE—The TA field of the frame carrying a TDLS Capability ANQP-element is the non-AP MLD’s MAC
14 address (see 35.3.21.2 (TDLS direct link over a single link)) when the STA transmitting the frame is affiliated with a
15 non-AP MLD.
16
17
18
11.24 Quality-of-service Management frame (QMF)
19
20 11.24.1 General
21
22 11.24.1.2 Default QMF policy
23
24
25 Insert a new row to Table 11-18 (Default QMF policy) as follows:.
26
27
28 Table 11-18—Default QMF policy
29
30
31 Management Frame Category value
32 Subtype value from from Table 9-79
33 QMF access
Description Table 9-1 (Valid (Category Action field
34 category
type and subtype values(#4007)(#42
35 combinations) 99))
36
37 (#5284)EPCS Priority 1101 35 1–2 AC_VO
38 Service
39
40
41
42 11.25 Robust AV streaming
43
44
11.25.2 SCS procedures
45
46
47 Change the fifth and sixth paragraphs as follows:
48
49 Each SCS stream is identified by an SCSID. (#1977)ThisThe SCSID is used by a non-AP STA to request
50
51 creation, modification, or deletion of an SCS stream. The SCSID is used by an AP to identify an SCS stream in
52 SCS responses.
53
54 Upon receipt of an SCS Request frame from an associated non-AP STA, the AP shall respond with a
55 corresponding SCS Response frame. A value of SUCCESS shall be set in the corresponding Status field of the
56
57 SCS Status duple in the SCS Response frame when the AP accepts the SCS request for the requested SCSID. A
58 value of REQUEST_DECLINED, REQUESTED_TCLAS_NOT_SUPPORTED_BY_AP, or
59 INSUFFICIENT_TCLAS_PROCESSING_RESOURCES shall be set in the corresponding SCS Status field of
60 the SCS Status duple in the SCS Response frame when (#1977)thea non-EHT AP denies the SCS request for
61 the requested SCSID.
62
63
64 Change the eight paragraph as follows:
65

304 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 If the requested SCS is accepted by (#1977)thea non-EHT AP, the AP shall process subsequent incoming
2 individually addressed MSDUs from the DS or WM that match the TCLAS elements and optional TCLAS
3
Processing element classifier specified in the SCS Descriptor element.
4
5
6 Insert the following paragraph as the ninth paragraph of the subclause:
7
8 (#5890)An SCS Response frame transmitted by a non-EHT STA does not contain any SCS Descriptor List
9
10 field.
11
12
13 11.49 Reduced neighbor report
14
15 Change the last paragraph as follows:
16
17
(#1018)A STA that receives a Neighbor AP Information field with a recognized TBTT Information Field
18
19 Type subfield but an unrecognized TBTT Information Length subfield shall ignore that Neighbor AP
20 Information field and continue to process remaining Neighbor AP Information fields. has twothree possible
21 ways of processing the received information: (1) ignore that Neighbor AP Information field and continue to
22 process the subsequent Neighbor AP Information fields or (2) process the first 13 octets of each TBTT
23
Information field of the Neighbor AP Information field as if the TBTT Information Length subfield had
24
25 value 13, ignore the remaining TBTT Information Length minus 13 octets of each TBTT Information field
26 of the Neighbor AP Information field, and continue to process the subsequent Neighbor AP Information
27 fields or (3) process the first 16 octets of each TBTT Information field of the Neighbor AP Information field
28 as if the TBTT Information Length subfield had value 16, ignore the remaining TBTT Information Length
29
minus 16 octets of each TBTT Information field of the Neighbor AP Information field, and continue to
30
31 process the subsequent Neighbor AP Information fields. If the unrecognized TBTT Information Length
32 value is less than or equal to 13, the STA shall follow alternative (1). If the unrecognized TBTT Information
33 Length value is greater than 13, an HE STA shall follow alternative (2) and a non-HE STA shall follow
34 either alternative (1) or (2). If the unrecognized TBTT information length value is greater than 16, an EHT
35
STA shall follow alternative (3) and a non-EHT STA shall follow either alternative (1) or (2) or (3).
36
37
38 Insert the following paragraphs at the end of this subclause:
39
40 (#1018)An EHT AP shall follow the procedure defined in 35.3.4 (Discovery of an AP MLD) for including a
41
Reduced Neighbor Report element in Beacon and Probe Response frames.
42
43
44 (#1018)An AP that reports in a Reduced Neighbor Report element multiple APs operating on the same
45 operating class/channel, some (#6581)affiliated with an AP MLD and some not (#6581)affiliated with an AP
46 MLD should include two Neighbor AP Information fields for the same operating class/channel, one for the
47
set of APs that are (#6581)affiliated with an AP MLD (for which the MLD Parameters subfield is included
48
49 in the TBTT Information field of a reported AP) and one for the set of APs that are not (#6581)affiliated
50 with an AP MLD (for which the MLD Parameters subfield is not included in the TBTT Information field of
51 a reported AP).
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 305

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

306 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 12. Security
2
3
4 12.1 Conventions
5
6
7 Insert the following paragraphs at the end of the subclause:
8
9 (#2086)(#2283)“STA” means that the “STA” is not affiliated with an MLD unless specified otherwise.
10
11
12 For MLO, the “SME” is the entity that manages the MLD.
13
14
15 12.2 Framework
16
17 12.2.4 RSNA establishment
18
19
20 Insert the following paragraph and NOTE at the end of the subclause:
21
22 (#2089)(#7442)When an RSNA is established between peer MLD SMEs, the MLD MAC address shall be
23 included in the frame body of Authentication, Association (see 9.4.2.312 (Multi-Link element)), and
24
25 EAPoL-key frames (see 12.7.2 (EAPOL-Key frames)).
26 (#7442)NOTE 4—These frames are transmitted by a STA affiliated with the MLD.
27
28
29 12.3 Pre-RSNA security methods
30
31
32 12.3.3 Pre-RSNA authentication
33
34 12.3.3.1 Overview(#2086)(#2283)
35
36
37 Change the now-shifted third and fourth paragraphs as follows:
38
39 In an infrastructure BSS, a non-DMG STA shall complete an IEEE 802.11 authentication exchange prior to
40 association. (#2086)(#2283)(#6040)For MLO a non-AP MLD and AP MLD shall complete IEEE 802.11
41
authentication exchange prior to association. The Authentication frames for MLO are transmitted between
42
43 the non-AP MLD and AP MLD through an affiliated STA and affiliated AP, respectively. A DMG STA not
44 in an IBSS shall complete an IEEE 802.11 authentication exchange prior to association when an
45 authentication algorithm other than the Open System authentication algorithm is requested. A DMG STA
46 shall not perform an IEEE 802.11 authentication exchange using the Open System authentication algorithm.
47
An IEEE 802.11 authentication exchange is optional in an IBSS.
48
49
50 All Authentication frames shall be individually addressed, as IEEE 802.11 authentication is performed
51 between pairs of STAs or MLDs, i.e., group addressed authentication is not allowed. Deauthentication frames
52 are advisory and may be sent as group addressed frames.
53
54
55 12.3.3.2 Open System authentication
56
57 12.3.3.2.1 General
58
59
60
Change the second, third, and fourth paragraphs as follows:
61
62 Any non-DMG STA or MLD requesting Open System authentication can be authenticated if
63 dot11AuthenticationAlgorithmsTable at the peer STA or MLD, respectively, includes an entry with
64
65

Copyright © 2022 IEEE. All rights reserved. 307

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 dot11AuthenticationAlgorithm equal to openSystem and dot11AuthenticationAlgorithmActivated equal to

2 true.
3
4
5 A STA or an MLD may decline to authenticate with another requesting STA or requesting MLD, respectively.
6 Open System authentication is the default authentication algorithm for a pre-RSNA STA or MLD.
7
8 Open System authentication utilizes a two-message authentication transaction sequence. The first message
9
asserts identity and requests authentication. The second message returns the authentication result. If the result is
10
11 “successful,” the STAs or MLDs shall be declared mutually authenticated.
12
13 Change the fifth paragraph, including the addition of a note and the split of the paragraph into
14 two as follows:
15
16
17 In the description in 12.3.3.2.2 (Open System authentication (first frame)) and 12.3.3.2.3 (Open System
18 authentication (final frame)), the STA or MLD initiating the authentication exchange is referred to as the
19 requester, and the STA or the MLD, respectively, to which the initial frame in the exchange is addressed is
20 referred to as the responder.
21
22 (#2087)NOTE—Open system authentication between the requester MLD and the responder MLD is completed through
23 frame exchanges between STAs affiliated with the MLDs, respectively.
24
25 The specific items in each of the messages described in the following subclauses are defined in 9.3.3.11
26
(Authentication frame format), Table 9-68 (Authentication frame body), and Table 9-41 (Presence of fields
27
28 and elements in Authentication frames).
29
30
31 12.4 Authentication using a password
32
33 12.4.1 SAE overview
34
35
36 Insert the following two paragraphs as the first two paragraphs of the subclause:
37
38 In 12.4 (Authentication using a password), the reference of a “STA” means that the “STA” is not affiliated with
39 an MLD unless specified otherwise.
40
41
42 In 12.4 (Authentication using a password), when referring to MLD authentication, the reference of “SME”
43 means the entity that manages the MLD.
44
45 Change the now-shifted third paragraph and split it into two paragraphs as follows:
46
47
48 (#2864)Two SAE entities STAs, both AP STAs and non-AP STAs, may authenticate each other by proving
49 possession of a password.
50
51
Authentication protocols that employ passwords need to be resistant to off-line dictionary attacks.
52
53
54 Change the now-shifted fifth paragraph as follows:
55
56 Simultaneous authentication of equals (SAE) is a variant of Dragonfly, a password-authenticated key exchange
57
based on a zero-knowledge proof. SAE is used by STAs SAE entities(#2487) to authenticate with a password;
58
59 it has the following security properties:
60 — The successful termination of the protocol results in a PMK shared between the two SAE
61 entities(#2487)STAs.
62
63
64
65

308 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — An attacker is unable to determine either the password or the resulting PMK by passively observing
2 an exchange or by interposing itself into the exchange by faithfully relaying messages between the
3
two SAE entities(#2487)STAs.
4
5 — An attacker is unable to determine either the password or the resulting shared key by modifying,
6 forging, or replaying frames to an honest, uncorrupted SAE entity(#2487)STA.
7
8 — An attacker is unable to make more than one guess at the password per attack. This implies that the
9 attacker cannot make one attack and then go offline and make repeated guesses at the password until
10 successful. In other words, SAE is resistant to dictionary attack.
11
12 — Compromise of a PMK from a previous run of the protocol does not provide any advantage to an
13 adversary attempting to determine the password or the shared key from any other instance.
14 — Compromise of the password does not provide any advantage to an adversary in attempting to
15
determine the PMK from the previous instance.
16
17
18 Change the now-shifted seventh paragraph as follows:
19
20 (#2487)The parties involved are called Entity-A and Entity-B STA-A and STA-B. They are identified by their
21
MAC addresses, denoted A-MAC and B-MAC. Between two MLDs, the MAC addresses of Entity-A and
22
23 Entity-B are their MLD MAC addresses. Between the two STAs, the MAC addresses of Entity-A and Entity-B
24 are their STA MAC addresses. STA-A-MAC and STA-B-MAC, respectively. Two SAE entities STAs begin
25 the protocol when they discover a peer by receiving Beacon or Probe Response frame(s), or when they receive
26 an Authentication frame indicating SAE authentication from a peer.
27
28
29 12.4.3 Representation of a password
30
31 Change as follows:
32
33
34 Passwords are used in SAE to deterministically compute a secret element in the negotiated group, called a
35 password element. The input to this process needs to be in the form of a binary string. For the protocol to
36 successfully terminate, it is necessary for each side to produce identical binary strings for a given password,
37 even if that password is in character format. There is no canonical binary representation of a character and
38 ambiguity exists when the password is a character string. To eliminate this ambiguity, (#2487)an SAE entity a
39
40 STA shall represent a character-based password as a UTF-8 string that is processed according to the
41 OpaqueString profile of IETF RFC 8265, the output of which is an octet string. The octet string representation
42 of the password, after being processed, is stored in the dot11RSNAConfigPasswordValueTable. When a
43 “password” is called for in the description of SAE that follows the credential from the
44 dot11RSNAConfigPasswordValueTable is used.
45
46
47 Similarly, to address ambiguity when identifying passwords, (#2487)an SAE entity a STA shall represent a
48 password identifier as a UTF-8 string that is processed according to the UsernameCasePreserved profile of
49 IETF RFC 8265, the output of which is an octet string that is stored in the
50 dot11RSNAConfigPasswordValueTable. When a “password identifier” is called for in the description of SAE
51
52 that follows, the identifier from the dot11RSNAConfigPasswordValueTable is used.
53
54 (#2284)In an infrastructure BSS for which an SAE AKM is indicated, the AP shall set the SAE Password
55 Identifiers In Use subfield of the Extended Capabilities field of the Extended Capabilities element to 1 if any
56 entry in the dot11RSNAConfigPasswordValueTable has a non-NULL dot11RSNAConfigPasswordIdentifier,
57
58 and shall set it to 0 otherwise. Similarly, an AP shall set the SAE Password Identifiers Used Exclusively
59 subfield of the Extended Capabilities field of the Extended Capabilities element to 1 if every entry in the
60 dot11RSNAConfigPasswordValueTable has a non-NULL dot11RSNAConfigPasswordIdentifier and shall set
61 it to 0 otherwise.
62
63
64 (#2284)For an AP MLD, the dot11RSNAConfigPasswordValueTable for all affiliated APs of the AP MLD
65 shall be identical to the dot11RSNAConfigPasswordValueTable for the AP MLD. Consequently, all

Copyright © 2022 IEEE. All rights reserved. 309

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 affiliated APs of the AP MLD shall advertise the same values for the SAE Password Identifiers In Use and
2 SAE Password Identifiers Used Exclusively subfields of the Extended Capabilities field of the Extended
3
Capabilities element.
4
5
6 12.4.4 Finite cyclic groups
7
8 12.4.4.1 General
9
10
11 Change the first two paragraphs as follows:
12
13 SAE uses discrete logarithm cryptography to achieve authentication and key agreement. Each party to the
14 exchange derives ephemeral public and private keys with respect to a particular set of domain parameters
15
16 that define a finite cyclic group. Groups may be based on either finite field cryptography (FFC) or on elliptic
17 curve cryptography (ECC). Each component of a group is referred to as an element. Groups are negotiated
18 using an identifying number from a repository maintained by IANA as “Group Description” attributes for
19 IETF RFC 2409 (IKE) [B14][B28]. The repository maps an identifying number to a complete set of domain
20 parameters for the particular group. Not all groups defined in this repository are suitable. Only FFC groups
21
22 whose prime is at least 3072 bits and ECC groups defined over a prime field whose prime is at least 256 bits
23 are suitable for use with SAE. ECC groups defined over a characteristic 2 finite field or ECC groups with a
24 co-factor greater than 1 shall not be used with SAE (see NIST Special Publication 800-57). For the purpose
25 of interoperability, (#2487)an SAE entity a STA shall implement support for group 19, an ECC group
26 defined over a 256-bit prime order field.
27
28
29 More than one group may be configured on (#2487)an SAE entity a STA for use with SAE by using the
30 dot11RSNAConfigDLCGroupTable. Configured groups are prioritized in ascending order of preference. If
31 only one group is configured, it is, by definition, the most preferred group.
32
33
34 12.4.4.2 Elliptic curve cryptography (ECC) groups
35
36 12.4.4.2.3 Hash-to-element generation of the password element with ECC groups
37
38 Change the first paragraph as follows:
39
40
41 (#2487)An SAE entity peer, e.g. a mesh STA or an AP, indicates support for direct hashing to obtain an ECC
42 password element by setting the SAE hash-to-element bit in the Extended RSN Capabilities field in all Beacon
43 and Probe Response frames. (#2487)An SAE entity A STA that uses a password identifier shall use the hash-
44
to-curve method. An SAE initiator that has identified a peer that supports this technique (through receipt of
45
46 Beacon or Probe Response frames) shall derive a secret element, PT, according to the following technique and
47 indicate this by setting the status code in the SAE Commit message to SAE_HASH_TO_ELEMENT. An SAE
48 initiator shall not indicate support for this form of element derivation unless its peer has already signalled
49 support for this method. If an SAE Commit message is received with status code equal to
50
SAE_HASH_TO_ELEMENT the peer shall generate the PWE using the following technique and reply with its
51
52 own SAE Commit message with status code set to SAE_HASH_TO_ELEMENT.
53
54 12.4.4.3 Finite field cryptography (FFC) groups
55
56
12.4.4.3.3 Direct Generation of the password element with FFC groups
57
58
59 Change the first paragraph as follows:
60
61 An SAE peer indicates support for direct hashing to obtain the FFC password element by setting the SAE hash-
62
63 to-element bit in the Extended RSN Capabilities field in all Beacon and Probe Response frames. (#2487)An
64 SAE entity A STA that uses a password identifier shall use the direct hashing technique. An SAE initiator that
65

310 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 has identified a peer that supports the following technique (through receipt of Beacon or Probe Response
2 frames) shall derive PT according to the following technique and indicate this by setting the status code in the
3
SAE Commit message to SAE_HASH_TO_ELEMENT. An SAE initiator shall not indicate support for this
4
5 form of PWE derivation unless its peer has already signalled support. If an SAE Commit message is received
6 with status code equal to SAE_HASH_TO_ELEMENT the peer shall generate the PWE using the following
7 technique and reply with its own SAE Commit message with status code set to SAE_HASH_TO_ELEMENT.
8
9
12.4.5 SAE protocol
10
11
12 12.4.5.2 PWE and secret generation
13
14 Change the second paragraph as follows:
15
16
17 (#2487)When an SAE entity a STA supports directly hashing to a group element (according to 12.4.4.2.3
18 (Hash-to-element generation of the password element with ECC groups) or 12.4.4.3.3 (Direct Generation of
19 the password element with FFC groups)) it computes a secret element, PT, offline at provisioning time for all
20 groups it wishes to support with that password. Prior to initiating SAE to (#2487)an SAE entity a STA which
21
also supports the direct form of hashing to a group element, or upon receipt of an SAE Commit message
22
23 indicating it was generated using a direct form of hashing to a group element, it shall generate the PWE by
24 hashing the two peer MAC addresses to produce a digest, reducing the digest modulo the order of the particular
25 group, r, interpreting the reduced digest as an integer and using it with the secret element to generate the PWE:
26
27 (#2487)val = H(0n, MAX(STA-A-MAC, STA-B-MAC) || MIN(STA-A-MAC, STA-B-MAC))
28 val = val modulo (r – 1) + 1
29 PWE = scalar-op(val, PT)
30
31 where 0n is a salt of all zeros whose length equals the length of the digest from the hash function used to
32 instantiate H() (see Table 12-1 (Hash algorithm based on length of prime)).
33
34 Change the fourth paragraph as follows:
35
36
37 After generation of the PWE, each (#2487)SAE entity STA shall generate a secret value, rand, and a
38 temporary secret value, mask, each of which shall be chosen randomly such that 1 < rand < r and 1 < mask < r
39 and (rand + mask) mod r is greater than 1, where r is the (prime) order of the group. If their sum modulo r is
40 not greater than 1, they shall both be irretrievably deleted and new values shall be randomly generated. The
41
values rand and mask shall be random numbers produced from a quality random number drawn from a uniform
42
43 distribution generator. These values shall never be reused on distinct protocol runs.
44
45 12.4.5.4 Processing of a peer’s SAE Commit message
46
47
48
Change the first two paragraphs as follows:
49
50 If the peer’s SAE Commit message contains a password identifier, the value of that identifier shall be used in
51 construction of the password element (PWE) for this exchange. If a password identifier is present in the peer’s
52 SAE Commit message and there is no password with the given identifier (#2487)an SAE entity a STA shall
53
54 fail authentication.
55
56 If the peer’s SAE Commit message contains a Rejected Groups element, the list of rejected groups shall be
57 checked to ensure that all of the groups in the list are groups that would be rejected. If any groups in the list
58 would not be rejected then processing of the SAE Commit message terminates and the (#2487)SAE entity STA
59
60 shall reject the peer’s authentication. While the rejected groups are appended to the Rejected Groups element
61 as they are rejected (see 12.4.7.4 (Encoding and decoding of SAE Commit messages)) there is no inherent
62 order to the groups in the list. The order in which they are sent and received shall be retained when deriving
63 keys.
64
65

Copyright © 2022 IEEE. All rights reserved. 311

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Change the fifth and sixth paragraphs as follows:

2
3
If either scalar validation or element validation fails, the (#2487)SAE entity STA shall reject the peer’s
4
5 authentication. If both the scalar and element from the peer’s SAE Commit message are successfully validated,
6 a shared secret element, K, shall be derived using the scalar and element (peer-commit-scalar and PEER-
7 COMMIT-ELEMENT, respectively) from the peer’s SAE Commit message and the (#2487)SAE entity’s
8 STA’s secret value.
9
10
11 K = scalar-op(rand, (elem-op(scalar-op(peer-commit-scalar, PWE), 
12 PEER-COMMIT-ELEMENT)))
13
14 If the shared secret element, K, is the identity element for the negotiated group (the value one for an FFC group
15
or the point-at-infinity for an ECC group) the (#2487)SAE entity STA shall reject the peer’s authentication.
16
17 Otherwise, a secret value, k, shall be computed as:
18
19 k = F(K)
20
21
12.4.6 Anti-clogging tokens
22
23
24 Change the first paragraph as follows:
25
26 (#2487)An SAE entity A STA is required to do a considerable amount of work upon receipt of an SAE
27
28 Commit message. This opens up the possibility of a distributed denial-of-service attack by flooding (#2487)an
29 SAE entity a STA with bogus SAE Commit messages from forged MAC addresses. To prevent this from
30 happening, (#2487)an SAE entity a STA shall maintain an Open counter in its SAE state machine indicating
31 the number of open and unfinished protocol instances (see 12.4.5.1 (Message exchanges)). When that counter
32 hits or exceeds dot11RSNASAEAntiCloggingThreshold, the (#2487)SAE entity STA shall respond to each
33
34 SAE Commit message with a rejection that includes an Anti-Clogging Token field statelessly bound to the
35 sender of the SAE Commit message. The sender of the SAE Commit message shall then include the Anti-
36 Clogging Token field in a subsequent SAE Commit message.
37
38 12.4.8 SAE finite state machine
39
40
41 12.4.8.3 Events and output
42
43 12.4.8.3.1 Parent process events and output
44
45
46 Change the fourth paragraph as follows:
47
48 (#2487)Receipt of frames containing SAE messages signals the following events to the SAE parent process:
49
50 — Authentication frame with Transaction Sequence number 1—This event indicates that an SAE
51 Commit message has been received from a peer STA.
52 — Authentication frame with Transaction Sequence number 2—This event indicates that an SAE
53
Confirm message has been received from a peer STA.
54
55
56
57
58
59
60
61
62
63
64
65

312 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 12.5 RSNA confidentiality and integrity protocols

2
3
4 12.5.3 CTR with CBC-MAC protocol (CCMP)
5
6 12.5.3.3 CCMP cryptographic encapsulation
7
8 12.5.3.3.1 General
9
10
11 Change the first paragraph and replace Figure 12-18 as follows:
12
13 The CCMP cryptographic encapsulation process is depicted in Figure 12-18 (CCMP encapsulation block
14
diagram).
15
16
17 MAC header
18
19
20 Construct
21 AAD
22 Plaintext MPDU
23
A2,
24 Priority
CCM Data, MIC
25 Construct Encrypted MPDU
encryption
26 nonce
||
27
28 Data
29 MLD MAC Address
30
TK
31
32 PN Increment
Construct
33 PN
CCMP
34 Key ID header
35
36 Figure 12-18—CCMP encapsulation block diagram
37
38 a) For secure PV0 MPDUs, CCMP encrypts the Frame Body field of a plaintext MPDU and
39 encapsulates the resulting cipher text using the following steps:
40
41 1) Increment the PN, to obtain a fresh PN for each MPDU, so that the PN never repeats for the
42 same temporal key.
43
NOTE—Retransmitted MPDUs are not modified on retransmission. (#2577)(#2578)For MLO, MPDUs
44 are not encapsulated with a new PN when retransmitted on another link.
45
46
2) Use the fields in the MPDU header to construct the additional authentication data (AAD) for
47
48 CCM. The CCM algorithm provides integrity protection for the fields included in the AAD.
49 MPDU header fields that may change when retransmitted are muted by being masked to 0 or
50 being set to a known value when calculating the AAD as described in 12.5.3.3.3 (Construct
51 AAD).
52
53 3) In case of a secure PV0 MPDU that is an individually addressed Data frame to be encrypted by
54 an MLD, construct the CCM nonce block as defined in 12.5.3.3.4 (Construct CCM nonce) from
55 the PN, transmitting MLD MAC address, and the priority value of the MPDU. Otherwise,
56 constructConstruct the CCM nonce block as defined in 12.5.3.3.4 (Construct CCM nonce)
57
58 from the PN, A2, and the priority value of the MPDU where A2 is MPDU Address 2. If the
59 Type field of the Frame Control field is 10 (Data frame) and there is a QoS Control field
60 present in the MPDU header, the priority value of the MPDU is equal to the value of the TID
61 subfield of the QoS Control field (bits 0 to 3 of the QoS Control field). If the Type field of the
62 Frame Control field is 00 (Management frame) and the frame is a QMF, the priority value of
63
64 the MPDU is equal to the value in the ACI subfield of the Sequence Number field. Otherwise,
65 the priority value of the MPDU is equal to the fixed value 0.

Copyright © 2022 IEEE. All rights reserved. 313

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 4) Construct the CCMP header as defined in 12.5.3.3.5 (Construct CCMP header for PV0
2 MPDUs).
3
4 5) Use the temporal key, AAD, nonce, and MPDU data to form the cipher text and the encrypted
5 MIC. This step is known as CCM originator processing.
6
6) Form the encrypted MPDU by combining the original MPDU header, the CCMP header, the
7
8 encrypted data and the encrypted MIC, as described in 12.5.3.2 (CCMP MPDU format)
9
10 12.5.3.3.2 PN processing
11
12
13
Insert the following paragraph after the first paragraph (“The PN is incremented by ...”):
14
15 If the MPDU is to be transmitted by a STA that is affiliated with an MLD and PTK is the temporal key, the
16 STAs in the MLD shall share a single PN space for all the links.
17
18
19 12.5.3.3.3 Construct AAD
20
21 Change the first paragraph as follows:
22
23 a) For PV0 MPDUs, the format of the AAD is shown in Figure 12-19 (AAD construction for PV0
24 MPDUs). The length of the AAD for PV0 varies depending on the presence or absence of the QC
25 and A4 fields and is shown in Table 12-3 (AAD length for PV0 MPDUs).
26
The AAD is constructed from the MPDU header. The AAD includes neither the Duration/ID field
27
28 nor the HT Control field because the contents of these fields might change during normal operation
29 (e.g., due to a rate change preceding retransmission). The HT Control field might also be inserted or
30 removed during normal operation (e.g., retransmission of an A-MPDU where the original A-MPDU
31 included an MRQ that has already generated a response). For similar reasons, several subfields in
32
the Frame Control field are masked to 0. For PV0 MPDUs, AAD construction is performed as fol-
33
34 lows:
35 1) FC – MPDU Frame Control field, with
36
37 i) Subtype subfield (bits 4 5 6) in a Data frame masked to 0
38 ii) Retry subfield (bit 11) masked to 0
39
40 iii) Power Management subfield (bit 12) masked to 0
41 iv) More Data subfield (bit 13) masked to 0
42
43 v) Protected Frame subfield (bit 14) always set to 1
44 vi) +HTC subfield (bit 15) as follows:
45
46 — Masked to 0 in all Data frames containing a QoS Control field
47 — Unmasked otherwise
48 vii) Other subfields are not modified
49
50 2) A1 – MPDU Address 1 field.If dot11MultiLinkActivated is true, for both the transmitter and
51 intended receiver of the MPDU, either of To DS or From DS subfields in the MAC header of
52 the MPDU is set to 1, and the MPDU is an individually addressed Data frame (#4924)between
53
an AP MLD and a non-AP MLD associated with the AP MLD, then A1 is set to:
54
55 — the MLD MAC address of the intended receiver MLD of the MPDU.
56
— otherwise, Al is set to MPDU Address 1 field.
57
58 3) A2 – MPDU Address 2 field.If dot11MultiLinkActivated is true, for both the transmitter and
59 intended receiver of the MPDU, either of To DS or From DS subfields in the MAC header of
60 the MPDU is set to 1, and the MPDU is an individually addressed Data frame (#4924)between
61
62 an AP MLD and a non-AP MLD associated with the AP MLD, then A2 is set to:
63 — the MLD MAC address of the transmitting MLD of the MPDU.
64
65 — otherwise, A2 is set to MPDU Address 2 field.

314 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 4) A3 – MPDU Address 3 field.If dot11MultiLinkActivated is true, MPDU Address 3 field is

2 BSSID and the MPDU is an individually addressed Data frame (#4924)between an AP MLD
3
and a non-AP MLD associated with the AP MLD, then:
4
5 — (#4924)A3 is set to the MLD MAC address of the AP MLD, where the corresponding AP
6 with the BSSID is affiliated with the AP MLD.
7
8 — (#4924)Otherwise, A3 is set to the MPDU Address 3 field.
9 5) SC – MPDU Sequence Control field, with the Sequence Number subfield (bits 4–15 of the
10 Sequence Control field) masked to 0. The Fragment Number subfield is not modified.
11
12 6) A4 – MPDU Address field, if present.A4, if present, is set as follows:
13 — if dot11MultiLinkActivated is true, MPDU Address 4 field is a BSSID, and the MPDU is
14
15 an individually addressed Data frame (#4924)between an AP MLD and a non-AP MLD
16 associated with the AP MLD, then A4 is set to the MLD MAC address of the AP MLD,
17 where the corresponding AP with the BSSID is affiliated with the AP MLD.
18
— otherwise A4, if present, is set to the MPDU Address 4 field.
19
20 7) QC – QoS Control field contains the MSDU priority, if present. The QC TID is used in the
21 construction of the AAD. When in a non-DMG BSS and both the STA and its peer have their
22 SPP A-MSDU Capable fields equal to 1, bit 7 (the A-MSDU Present field) is used in the
23
24 construction of the AAD. The remaining QC fields are masked to 0 for the AAD calculation
25 (bits 4 to 6, bits 8 to 15, and bit 7 when either the STA or its peer has the SPP A-MSDU
26 Capable field equal to 0). When in a DMG BSS, the A-MSDU Present bit 7 and A-MSDU
27 Type bit 8 are used in the construction of the AAD, and the remaining QC fields are masked to
28 0 for the AAD calculation (bits 4 to 6, bits 9 to 15).
29
30
31 12.5.3.3.4 Construct CCM nonce
32
33 Change Figure 12-21 (CCM nonce) as follows:
34
35
36 Nonce Flags STA Or MLD MAC Address Identified By A2 PN
37
38 Octets: 1 6 6
39
Figure 12-21—CCM nonce
40
41
42 Change the sixth paragraph as follows:
43
44
45 If dot11MultiLinkActivated is true, either To DS or From DS subfields in the MAC header of the MPDU are
46 set to 1, and the MPDU is an individually addressed Data frame, then the STA Or MLD MAC Address
47 Identified By A2 subfield shall contain the MLD MAC address of the transmitting MLD. Otherwise, theThe
48 STA Or MLD MAC Address Identified By A2 subfield shall contain the Address 2 field from the MAC header
49 for PV0 MPDUs and the MAC address identified by the A2 field in the MAC header for PV1 MPDUs (see
50
51 9.8.3.2 (Address fields)).
52
53 12.5.3.3.7 CCM originator processing
54
55 Change the fifth paragraph as follows:
56
57
58 The PN values sequentially number each MPDU. Each transmitter (#6044)STA that is not affiliated with an
59 MLD shall maintain a single PN (48-bit counter) for each PTKSA and GTKSA. Each MLD shall maintain a
60 single PN (48-bit counter) for each PTKSA. Each AP affiliated with an AP MLD shall maintain a single PN
61
(48-bit counter) for each GTKSA. Each transmitter STA that is affiliated with an MLD shall use the PN that is
62
63 maintained by the MLD. The PN shall be implemented as a 48-bit strictly increasing integer, initialized to 1
64 when the corresponding temporal key is initialized or refreshed.
65

Copyright © 2022 IEEE. All rights reserved. 315

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 12.5.3.4 CCMP decapsulation

2
3
12.5.3.4.1 General
4
5
6 Change item a) 1) in the first paragraph and replace Figure 12-23 as follows:
7
8 Figure 12-23 (CCMP decapsulation block diagram) depicts the CCMP decapsulation process.
9
10 MAC header
11
12
13 Construct
14 AAD
Encrypted MPDU
15 MIC
16 ||
A2,
17 Priority CCM Data
18 Construct decryption
PN nonce
19
20 Data
21 MLD MAC Address
22 Key
23
Plaintext
24 MPDU
Replay
25 Replay counter check
26
27
28 Figure 12-23—CCMP decapsulation block diagram
29 a) For secure PV0 MPDUs, CCMP decrypts the Frame Body field of a cipher text MPDU and
30
31 decapsulates a plaintext MPDU using the following steps:
32 1) The encrypted MPDU is parsed to construct the AAD (see 12.5.3.3.3 (Construct AAD)) and
33 nonce (see 12.5.3.3.4 (Construct CCM nonce)) values. In addition, if dot11MultiLinkActivated
34
is true, either or both of To DS or From DS subfields in the MAC header of the MPDU is set to
35
36 1, and the MPDU is an individually addressed Data frame transmitted by a STA affiliated with
37 an MLD, then the transmitter and receiver MLD MAC addresses are passed to construct the
38 AAD (see 12.5.3.3.3 (Construct AAD)) and nonce (see 12.5.3.3.4 (Construct CCM nonce))
39 values.
40
41
42 12.5.5 GCM protocol (GCMP)
43
44 12.5.5.1 GCMP overview
45
46
47
Change the first paragraph as follows:
48
49 Subclause 12.5.5 (GCM protocol (GCMP)) specifies the GCMP, which provides data confidentiality,
50 authentication, integrity, and replay protection. A DMG RSNA STA shall support GCMP-128. An EHT RSNA
51 STA shall support GCMP-256.
52
53
54
55
56
57
58
59
60
61
62
63
64
65

316 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 12.5.5.3 GCMP cryptographic encapsulation

2
3
12.5.5.3.1 General
4
5
6 Replace Figure 12-27 (GCMP encapsulation block diagram) as follows:
7
8 MAC header
9
10
Construct
11 AAD
12 Plaintext MPDU
13
14 A2
Data
GCM
15 Construct encryption Encrypted MPDU
||
16 nonce

17 Data
18 MLD MAC Address
19 TK
20
21 PN Increment
Construct
PN
22 Key ID
GCMP
header
23
24 Figure 12-27—GCMP encapsulation block diagram
25
26
27 Change the second paragraph as follows:
28
29 GCMP encrypts the Frame Body field of a plaintext MPDU and encapsulates the resulting cipher text using the
30 following steps:
31
32 a) Increment the PN, to obtain a fresh PN for each MPDU, so that the PN never repeats for the same
33 temporal key.
34
35 NOTE—Retransmitted MPDUs are not modified on retransmission. (#2577)(#2578)For MLO, MPDUs are not
36 encapsulated with a new PN when retransmitted on another link.
37
38 b) Use the fields in the MPDU header to construct the additional authentication data (AAD) for GCM.
39 The GCM algorithm provides integrity protection for the fields included in the AAD. MPDU header
40 fields that may change when retransmitted are muted by being masked to 0 or being set to known
41 value when calculating the AAD as described in 12.5.5.3.3 (Construct AAD).
42
43 c) Construct the GCM nonce block as defined in 12.5.3.3.4 (Construct CCM nonce) from the PN and
44 A2, where A2 is MPDU Address 2.
45
46
d) Construct the GCMP header as defined in 12.5.5.3.5 (Construct GCMP header).
47 e) Use the temporal key, AAD, nonce, and MPDU data to form the cipher text and the MIC. This step
48 is known as GCM originator processing.
49
50 f) Form the encrypted MPDU by combining the original MPDU header, the GCMP header, the
51 encrypted data and the MIC, as described in 12.5.5.2 (GCMP MPDU format).
52
53 12.5.5.3.4 Construct GCM nonce
54
55
56 Change the second paragraph as follows:
57
58 If dot11MultiLinkActivated is true, either To DS or From DS subfields in the MAC header of the MPDU are
59 set to 1, and the MPDU is an individually addressed Data frame, then the A2 subfield shall contain the MLD
60
61 MAC address of the transmitting MLD. Otherwise, theThe A2 subfield shall contain the Address 2 field
62 from the MAC header.
63
64
65

Copyright © 2022 IEEE. All rights reserved. 317

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 12.5.5.3.6 GCM originator processing

2
3
4
Change the sixth paragraph as follows:
5
6 The PN values sequentially number each MPDU. Each transmitter (#6046)STA that is not affiliated with an
7 MLD shall maintain a single PN (48-bit counter) for each PTKSA and GTKSA. Each MLD shall maintain a
8 single PN (48-bit counter) for each PTKSA. Each AP affiliated with an AP MLD shall maintain a single PN
9
10 (48-bit counter) for each GTKSA. Each transmitter STA that is affiliated with an MLD shall use the PN that is
11 maintained by the MLD. The PN shall be implemented as a 48-bit strictly increasing integer, initialized to 1
12 when the corresponding temporal key is initialized or refreshed.
13
14 12.5.5.4 GCMP decapsulation
15
16
17 12.5.5.4.1 General
18
19 Replace Figure 12-29 (GCMP decapsulation block diagram) as follows:
20
21 MAC header
22
23
24 Construct
AAD
25 Encrypted MPDU
MIC
26 ||
27
A2 GCM Data
28 Construct decryption
29 PN nonce

30 Data
31 MLD MAC Address
32 Key
33 Plaintext
34 Replay MPDU
35 Replay counter check
36
37 Figure 12-29—GCMP decapsulation block diagram
38
39
40 Change item a) of the second paragraph as follows:
41
42
43
GCMP decrypts the Frame Body field of a cipher text MPDU and decapsulates a plaintext MPDU using the
44 following steps:
45 a) The encrypted MPDU is parsed to construct the AAD (see 12.5.5.3.3 (Construct AAD)) and nonce
46 (see 12.5.5.3.4 (Construct GCM nonce)) values. In addition, if dot11MultiLinkActivated is true,
47
48 either or both To DS or From DS subfields in the MAC header of the MPDU is set to 1, and the
49 MPDU is an individually addressed Data frame transmitted by a STA affiliated with an MLD, then
50 the transmitter and receiver MLD MAC addresses are passed to construct the AAD (see
51 12.5.5.3.3 (Construct AAD)) and nonce (see 12.5.5.3.4 (Construct GCM nonce)) values.
52
53
54 12.6 RSNA security association management
55
56
57 12.6.1 Security associations
58
59 12.6.1.1 Security association definitions
60
61
62
12.6.1.1.2 PMKSA
63
64 Change the third paragraph as follows:
65

318 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 A PMKSA association is bidirectional. In other words, both parties use the information in the security
2 association for both sending and receiving. The PMKSA is used to create the PTKSA. PMKSAs have a certain
3
lifetime. For a non-AP MLD that is associated with an AP MLD, the PMKSA association is between the AP
4
5 MLD and the non-AP MLD. The PMKSA consists of the following:
6 — PMKID, as defined in 12.7.1.3 (Pairwise key hierarchy) or 12.7.1.6.3 (PMK-R0). The PMKID
7 identifies the security association.
8
9 — Authenticator’s or peer’s MAC address. For multi-band RSNA, the MAC address is associated with
10 the operating band in use when the PMKSA is established. For MLO, the Authenticator’s MAC
11 address is the MLD MAC address of the AP MLD(#7451).
12
13 — PMK; or if the PMKSA was established with an AKM suite type for which the Authentication type
14 column includes FT authentication (see Table 9-151 (AKM suite selectors)), MPMK (see
15 12.7.1.6.3 (PMK-R0)).
16
17 — Lifetime, as defined in 12.7.1.3 (Pairwise key hierarchy) or 12.7.1.6 (FT key hierarchy).
18 — AKMP.
19
20 — All authorization parameters specified by the AS or local configuration. This might include
21 parameters such as the STA’s authorized SSID.
22 — Cache Identifier, if advertised by the AP in FILS Indication element.
23
24
25 12.6.1.1.6 PTKSA
26
27 Change the first paragraph as follows:
28
29
30 The PTKSA results from a successful 4-way handshake, FT 4-way handshake, FT protocol, FT resource
31 request protocol, or FILS authentication. This security association is also bidirectional. PTKSAs have the same
32 lifetime as the PMKSA or PMK-R1 security Association, whichever comes first. Because the PTKSA is tied to
33 the PMKSA or to a PMK-R1 security association, it only has the additional information from the 4-way
34
handshake, or FT Protocol authentication, or FILS authentication. For the PTKSA derived as a result of the 4-
35
36 way handshake, there shall be only one PTKSA per band (see 12.6.19 (Protection of robust Management
37 frames)) or per MLD setup (see 35.3.5 (Multi-link (re)setup)) with the same Supplicant and Authenticator
38 MAC addresses. For the PTKSA derived as a result of an initial mobility domain association or fast BSS
39 transition, there shall be only one PTKSA with the same STA’s MAC address and BSSID.
40
41
42 Change the last paragraph as follows:
43
44 The PTKSA consists of the following:
45
46 — PTK, where the PTK includes the KDK when WUR frame protection is negotiated
47 — Pairwise cipher suite selector, and when WUR frame protection is negotiated, the cipher suite
48 selector 00-0F-AC:6 (BIP-CMAC-128) for individually addressed WUR Wake-up frames
49
50 — Supplicant MAC address or STA’s MAC address
51 — Authenticator MAC address or BSSID
52
53 — For MLO, the Authenticator’s MAC address is the MLD MAC address of the AP MLD and the
54 Supplicant’s MAC address is the MLD MAC address of the non-AP MLD
55
— Key ID
56
57 — If FT key hierarchy is used,
58
— R1KH-ID
59
60 — S1KH-ID
61
— PTKName
62
63 — If WUR frame protection is negotiated
64
— WTK
65

Copyright © 2022 IEEE. All rights reserved. 319

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 12.6.2 RSNA selection

2
3
4 Insert the following paragraph after the third paragraph (“A STA shall advertise the same RSNE
5 ...”):
6
7 (#1578)(#2482)All APs affiliated with an AP MLD shall advertise the same RSNE and RSNXE if included,
8
9 with the exception of the AKM Suite List field and the MFPR subfield of the RSN Capabilities field. All
10 APs affiliated with an AP MLD shall advertise (#6595)at least one common AKM suite selector in the AKM
11 Suite List field.
12
13 12.6.3 RSNA policy selection in an infrastructure BSS
14
15
16 Insert a new subclause General before the beginning of the first paragraph (“The requirements
17 in this subclause”):
18
19
20 12.6.3.1 General
21
22 Change the fourth paragraph as follows:
23
24
25 An SME initiating an association shall insert an RSNE into its (Re)Association Request via the MLME-
26 ASSOCIATE.request or MLME-REASSOCIATE.request primitive, when the targeted AP indicates RSNA
27 support. The initiating STA’s RSNE shall include one authentication and pairwise cipher suite from among
28 those advertised by the targeted AP in its Beacon and Probe Response frames. It shall also specify the group
29
cipher suite specified by the targeted AP. (#5919)For MLO, there shall be only one RSNE and RSNXE inserted
30
31 into the (Re)Association Request frame initiated by the non-AP MLD.
32
33 (#6596)(#1578)(#2482)For MLO, the initiating non-AP MLD’s RSNE shall include one AKM suite selector,
34 one pairwise cipher suite selector, and one group cipher suite selector that are common among those advertised
35
by the APs affiliated with the targeted AP MLD. A non-AP MLD would determine the appropriate AKM suite
36
37 selector and pairwise cipher suite selector during MLO discovery by monitoring Beacon frames transmitted by
38 APs affiliated with the AP MLD or performing basic probing with each AP affiliated with the AP MLD or by
39 performing ML probing with one or more APs affiliated with the AP MLD. If at least one RSNE field from the
40 AP’s RSNE fails to overlap with any value the STA supports, the STA shall decline to associate with that AP.
41
An HT STA shall eliminate TKIP as a choice for the pairwise cipher suite if CCMP-128 or CCMP-256 is
42
43 advertised by the AP or if the AP included an HT Capabilities element in its Beacon and Probe Response
44 frames. The elimination of TKIP as a choice for the pairwise cipher suite may result in a lack of overlap of the
45 remaining pairwise cipher suite choices, in which case the STA shall decline to create an RSN association with
46 that AP.
47
48
49 Insert two NOTEs after the now-shifted sixth paragraph (“If an AP receives a (Re)Association
50 Request frame ...”) as follows:
51
52 (#1578)(#2482)NOTE 1—APs affiliated with AP MLD indicate the same pairwise cipher suite list. Hence, any pairwise
53 cipher suite selected from an AP affiliated with the AP MLD will be common among those advertised by the APs affiliated
54 with the targeted AP MLD.
55
56 (#1578)(#2482)NOTE 2—For MLO, (Re)Association frames are transmitted between an affiliated STA and affiliated AP,
57 however the association takes place between the non-AP MLD and the AP MLD.
58
59
60
61
62
63
64
65

320 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Insert a new subclause after the end of 12.6.3.1 as follows:

2
3
12.6.3.2 RSNA policy selection for MLO(#1578)(#2482)
4
5
6 If an AP MLD Authenticator receives a (Re)Association Request frame that includes an RSNE and if it
7 chooses to accept the association as a secure association, then it shall use the AKM suite and pairwise cipher
8 suite in the (Re)Association Request frame to establish an RSNA with a non-AP MLD. (#6596)The AP MLD
9
manages the PTKSA while the affiliated APs manage the GTKSA.
10
11
12 12.6.10 RSNA authentication in an infrastructure BSS
13
14 12.6.10.2 Preauthentication and RSNA key management
15
16
17 Insert the following paragraph after the seventh paragraph (“An AP’s Authenticator that
18 receives ...”):
19
20
(#5183)For MLO, the non-AP MLD may initiate preauthentication by sending an EAPOL-Start frame with
21
22 the DA being the address of the AP MLD. The AP MLD Authenticator would receive an EAPOL-Start
23 frame via the DS and initiate IEEE 802.1X authentication with the non-AP MLD via the DS. The DS would
24 forward the messages between the non-AP MLD and AP MLD.
25
26
12.6.14 RSNA key management in an infrastructure BSS
27
28
29 Insert the following paragraph at the end of the subclause:
30
31 (#6583)For MLO, the AP MLD Authenticator and non-AP MLD Supplicant manage the PMK and pairwise
32
33 key derivation. Both the 4-way handshake and group key handshake take place between the AP MLD
34 Authenticator and the non-AP MLD Supplicant. The affiliated APs manage the group keys for their
35 respective links. When group key update is triggered, the affiliated AP distributes the group key to STAs
36 affiliated with a non-AP MLD through a group key handshake between the AP MLD and the non-AP MLD.
37
38
39 12.6.21 RSNA rekeying
40
41 Change the first paragraph as follows:
42
43
44 When a PTKSA is deleted, a non-AP and non-PCP STA may reassociate with the same AP or PCP and/or
45 establish a new RSNA with the AP or PCP. (#5919)When a PTKSA is deleted, a non-AP MLD may
46 reassociate with the same AP MLD and/or establish a new RSNA with the AP MLD. If the non-AP and non-
47 PCP STA has cached one or more PMKSAs, it may skip the PMKSA establishment and proceed with the
48 creation of a new PTKSA by using 4-way handshake, FT 4-way handshake, or FILS authentication using the
49
50 procedures defined in 12.6.10.3 (Cached PMKSAs and RSNA key management). When a GTKSA is
51 deleted, an originating STA may create a new GTKSA by using 4-way handshake or group key handshake.
52
53 Insert the following paragraph after the third paragraph of the subclause (“The IEEE 802.11
54
55 MAC shall issue an ...”):
56
57 (#6583)For MLO, the AP MLD authenticator manages packet number assignment for the PTKSA with a
58 non-AP MLD. For a given link, the affiliated AP authenticator manages packet number assignment for the
59
IGTKSA, GTKSA, or BIGTKSA. If an IGTKSA, GTKSA, or BIGTKSA update is triggered, the affiliated
60
61 AP updates group keys for the given link through a group key handshake between the AP MLD and non-AP
62 MLD.
63
64
65

Copyright © 2022 IEEE. All rights reserved. 321

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Change the now-shifted fifth paragraph as follows:

2
3
4 A PTKSA has a limited lifetime, either in absolute time or due to exhausting the PN space. To maintain an
5 uninterrupted security association, a STA (#5919)or MLD should establish a new PTKSA prior to the
6 expiration of the old PTKSA.
7
8
9 12.7 Keys and key distribution
10
11
12.7.1 Key hierarchy
12
13
14 12.7.1.1 General
15
16 Change the third paragraph as follows:
17
18
19 In an infrastructure BSS, the IEEE 802.1X Authenticator MAC address (AA) and the AP’s MAC address are
20 the same, and the Supplicant’s MAC address (SPA) and the STA’s MAC address are equal. (#5900)Between
21 an AP MLD and a non-AP MLD, the IEEE 802.1X Authenticator MAC address (AA) shall be set to the MLD
22 MAC address of the AP MLD, and the Supplicant’s MAC address (SPA) shall be set to the MLD MAC
23
24 address of the non-AP MLD. For the purposes of comparison in this standard, the MAC address is encoded as
25 6 octets, taken to represent an unsigned integer. The first octet of the MAC address shall be used as the most
26 significant octet. The bit numbering conventions in 9.2.2 (Conventions) shall be used within each octet. This
27 results in a sequence of 48 bits represented such that bit 0 is the first transmitted bit (Individual/Group bit) and
28 bit 47 is the last transmitted bit.
29
30
31 Insert the following paragraph after the fourth paragraph (“An RSNA STA shall support ...”):
32
33 An MLD shall support at least one pairwise key for any <transmitter_MLD MAC address, receiver_MLD
34
MAC address> pair for use with enhanced data cryptographic encapsulation mechanisms. The
35
36 <transmitter_MLD MAC address, receiver_MLD MAC address> identifies the pairwise key(#5900).
37
38 12.7.2 EAPOL-Key frames
39
40
41 Change item g) of the fifth paragraph as follows:
42 g) Key RSC. This field (#4696)contains the current receive sequence counter (RSC) for the GTK
43 being installed. It is used in message 3 of the 4-way handshake and message 1 of the group key
44
45 handshake, where it is used to synchronize the IEEE 802.11 replay state. It may also be used in the
46 Michael MIC Failure Report frame, to report the TSC field value of the frame experiencing a MIC
47 failure. It shall contain 0 in other messages. If the RSC is less than 8 octets in length, it is stored in
48 the first octets and the remaining octets are set to 0. The least significant octet of the RSC is in the
49 first octet of the Key RSC field. The RSC for TKIP is the TKIP sequence number (TSC); for CCMP
50
51 and GCMP it is the packet number (PN); see Table 12-8 (Key RSC field).
52 (#2290)For MLO, the Key RSC field is set to 0 in all messages.
53
54
55 Change the fifth item of the 20th paragraph as follows (not all items are shown):
56
57 The following EAPOL-Key frames are used to implement the three different exchanges:
58
59 — …
60 — Group key handshake message 1 is an EAPOL-Key frame with the Key Type subfield equal to 0.
61 (#1028)(#2505)(#2594)For non-MLO, theThe Key Data field shall contain a GTK KDE and shall be
62
encrypted. For MLO, the Key Data field may include one MLO GTK KDE, one MLO IGTK KDE,
63
64 and one MLO BIGTK KDE for each of the setup links and shall be encrypted.
65

322 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Insert the following news rows to Table 12-10 (KDE selectors) while maintaining the numerical
2 order and updating the reserved range:
3
4
5 Table 12-10—KDE selectors
6
7
8 OUI Data type Meaning
9
10 00-0F-AC 16 MLO GTK KDE
11 00-0F-AC 17 MLO IGTK KDE
12
13 00-0F-AC 18 MLO BIGTK KDE
14
15 00-0F-AC 19 MLO Link KDE(#2290)
16
17 00-0F-AC 1520–255 Reserved
18
19
20 Insert the following figure and paragraphs after the description on Figure 12-36 (GTK KDE
21 format) in the fifth paragraph:
22
23 The format of the MLO GTK KDE is shown in Figure 12-36a (MLO GTK KDE format(#2290)).
24
25
26 Key ID Tx Reserved LinkID PN GTK
27
28 Bits: 2 1 1 4 48 (Length – 11) × 8
29
30 Figure 12-36a—MLO GTK KDE format(#2290)
31
32 (#2290)The definitions of Key ID, Tx, and GTK fields are the same as in the GTK KDE described above.
33
34
35 The LinkID field contains the link identifier that corresponds to the link this GTK applies.
36
37 (#2290)The PN field contains the packet number and is formatted as described in Table 12-8 (Key RSC
38 field).
39
40
41 Insert the following figure and paragraph after the description on Figure 12-42 (IGTK KDE
42 format) in the sixth paragraph:
43
44
45 The format of the MLO IGTK KDE is shown in Figure 12-42a (MLO IGTK KDE format(#2290)).
46
47 Key ID IPN Reserved LinkID IGTK
48
49 Bits: 16 48 4 4 (Length – 13) × 8
50
51 Figure 12-42a—MLO IGTK KDE format(#2290)
52
53
(#2290)The definitions of Key ID, IPN, and IGTK fields are the same as in the IGTK KDE described above.
54
55
56 The LinkID field contains the link identifier that corresponds to the link this IGTK applies.
57
58 Change the seventh paragraph as follows:
59
60
61 The following EAPOL-Key frames are used to implement the three different exchanges:
62 — 4-way handshake message 1 is an EAPOL-Key frame with the Key Type subfield equal to 1. Use
63
64 of the Key Data field to indicate a PMKID when a cached PMKSA is being used in this key
65 derivation is defined in 12.6.10.3 (Cached PMKSAs and RSNA key management). When a cached

Copyright © 2022 IEEE. All rights reserved. 323

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 PMKSA is not being used, inclusion of the PMKID (if derived) is optional. (#2290)For MLO, the
2 Key Data field shall include the MAC Address KDE set to the MLD MAC address of the
3
Authenticator. The Key Data field need not be encrypted.
4
5 — 4-way handshake message 2 is an EAPOL-Key frame with the Key Type subfield equal to 1. The
6 Key Data field shall contain an RSNE, may contain an RSNXE, and need not be encrypted.
7 (#2290)For MLO, the Key Data field shall include the MAC Address KDE set to the MLD MAC
8
9 address of the Supplicant.
10 An ESS Supplicant’s SME shall insert the RSNE it sent in its (Re)Association Request frame, and
11 shall insert the RSNXE it sent in its (Re)Association Request frame if the RSNXE is present in the
12
(Re)Association Request frame it sent. The RSNE and the RSNXE are included as transmitted in the
13
14 Management frame. (#2290)For MLO, the non-AP MLD shall include a MLO Link KDE containing
15 the LinkID field and affiliated STA MAC address for each link included in the Association Request
16 frame. On receipt of message 2, the Authenticator’s SME shall validate the selected security config-
17 uration against the RSNE received in the (Re)Association Request frame, and shall validate the
18
RSNXE included in message 2 against the RSNXE received in the (Re)Association Request frame
19
20 from the Supplicant(#6050).
21 An IBSS Supplicant’s SME shall insert an RSNE containing a selected pairwise cipher suite. The
22 Authenticator’s SME shall validate that the pairwise cipher suite selected is one of its configured
23
24 cipher suites and that the group cipher suite and AKM are consistent.
25 — 4-way handshake message 3 is an EAPOL-Key frame with the Key Type subfield equal to 1. The
26 Key Data field shall contain one or two RSNEs, and may contain an RSNXE. If a group cipher has
27
been negotiated, this field shall also include a GTK. This field shall be encrypted if a GTK is
28
29 included. (#2290)For MLO, the Key Data field shall include the MAC Address KDE set to the MLD
30 MAC address of the Authenticator. When the Authenticator is an AP MLD and the Supplicant is a
31 non-AP MLD, this field shall include one MLO GTK for each setup link (see 35.3.5 (Multi-link
32 (re)setup)).
33
34 An Authenticator’s SME shall insert the RSNE it sent in its Beacon or Probe Response frame, and
35 shall insert the RSNXE it sent in its Beacon or Probe Response frame if the RSNXE is present in the
36 Beacon or Probe Response frame it sent. When this message 3 is part of a fast BSS transition initial
37 mobility domain association or an association started through the FT protocol, the PMKR1Name is
38
39 added in the PMKID List field of the RSNE. (#2290)For MLO, an Authenticator’s SME shall insert
40 a MLO Link KDE that includes the LinkID field, affiliated AP MAC address, RSNE, and RSNXE,
41 if it was present, for each affiliated AP link that was advertised in the Multi-Link element included
42 in Beacons, Probe Response, and ML Probe Response frames. The Supplicant’s SME shall validate
43 the selected security configuration against the RSNE received in message 3, and shall validate the
44
45 RSNXE included in message 3 against the RSNXE received in the Beacon or Probe Response frame
46 from the Authenticator. (#2290)For MLO, the Supplicant’s SME shall validate the security configu-
47 ration for each LinkID field, affiliated AP MAC address, RSNE, and RSNXE for each affiliated AP
48 link included in message 3 against the affiliated AP MAC address, RSNE, and RSNXE received
49 (#6053)for each link in Beacon, Probe Response that is not an ML probe response, or Probe
50
51 Response frame that is an ML probe response frame. (#6050)If the second optional RSNE is present,
52 the STA shall either use that cipher suite with its pairwise key or deauthenticate. In any of these
53 cases, if the values do not match, then the receiver shall consider the RSNE or the RSNXE modified
54 and shall use the MLME-DEAUTHENTICATE.request primitive to break the association. A secu-
55 rity error should be logged at this time.
56
57 It may happen, for example, that a Supplicant selects a pairwise cipher suite which is advertised by
58 an AP, but which policy disallows for this particular STA. An Authenticator may, therefore, insert a
59 second RSNE to overrule the STA’s selection. An Authenticator’s SME shall insert the second
60
RSNE, after the first RSNE, only for this purpose. The pairwise cipher suite in the second RSNE
61
62 included shall be one of the ciphers advertised by the Authenticator. All other fields in the second
63 RSNE shall be identical to the first RSNE.
64
65

324 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 A GTK shall be included and the unencrypted length of the GTK is six less than the length of the
2 GTK KDE in octets. The entire Key Data field shall be encrypted as specified by the Key Descriptor
3
Version.
4
5 — 4-way handshake message 4 is an EAPOL-Key frame with the Key Type subfield equal to 1. The
6 Key Data field can be empty. (#2290)For MLO, the Key Data field shall include the MAC Address
7 KDE set to the MLD MAC address of the Supplicant.
8
9 — Group key handshake message 1 is an EAPOL-Key frame with the Key Type subfield equal to 0.
10 The Key Data field shall contain a GTK KDE and shall be encrypted.
11
12 — Group key handshake message 2 is an EAPOL-Key frame with the Key Type subfield equal to 0.
13 The Key Data field can be empty.
14
15 Insert the following figure and paragraphs at the end of the subclause:
16
17
18 The format of the MLO BIGTK KDE is shown in Figure 12-48a (MLO BIGTK KDE(#2290)).
19
20 Key ID BIPN Reserved LinkID BIGTK
21
22 Bits: 16 48 4 4 (Length – 13) × 8
23
24 Figure 12-48a—MLO BIGTK KDE(#2290)
25
26
27 (#2290)The BIPN corresponds to the BIPN value that was carried in the MME of the last protected Beacon
28 frame corresponding to the LinkID field and it is used by the receiver as the initial value for the BIP replay
29 counter for the BIGTK.
30
31
The LinkID field contains the link identifier that corresponds to the link this BIGTK applies.
32
33
34 The format of the MLO Link KDE is shown in Figure 12-48b (MLO Link KDE(#2290)).
35
36
Link Information MAC Address RSNE RSNXE
37
38 Octets: 1 6 variable variable
39
40 Figure 12-48b—MLO Link KDE(#2290)
41
42
43 The Link Information field, which contains information identifying the presence of fields in the MLO Link
44 KDE, is shown in Figure 12-48c (Link Information field(#2290)(#6594)).
45
46
47 LinkID RSNEInfo RSNXEInfo Reserved
48 Bits 4 1 1 2
49
50 Figure 12-48c—Link Information field(#2290)(#6594)
51
52
53 The LinkID field contains the link identifier for the affiliated STA link.
54
55
56 (#6594)The RSNEInfo field indicates that the RSNE is present in the MLO Link KDE when its value is
57 equal to 1, otherwise the RSNE is not present.
58
59 The RSNXEInfo field indicates that the RSNXE is present in the MLO Link KDE when its value is set to 1.
60
61
62 The MAC Address field contains the MAC address of the affiliated STA for the link specified in the Link
63 Information field.
64
65

Copyright © 2022 IEEE. All rights reserved. 325

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The RSNE field contains the RSNE of the affiliated STA for the link specified in the Link Information field.
2
3 The RSNE is described in 9.4.2.24 (RSNE).
4
5 The RSNXE field contains the RSNE of the affiliated STA for the link specified in the Link Information
6 field. The RSNXE is described in 9.4.2.241 (RSNXE).
7
8
9 12.7.4 EAPOL-Key frame notation
10
11 Change as follows:
12
13
14 The following notation is used throughout the remainder of 12.7 (Keys and key distribution) and 13.4 (FT
15 initial mobility domain association) to represent EAPOL-Key frames:
16
17 EAPOL-Key(S, M, A, I, K, Reserved, KeyRSC, ANonce/SNonce, MIC, {Key Data})
18
19
20 where
21
22 S means the initial key exchange is complete. This is the Secure bit of the Key Informa-
23 tion field.
24 M means the MIC is available in message. This should be set in all messages except
25
26 message 1 of a 4-way handshake. This is the Key MIC bit of the Key Information
27 field. When the negotiated AKM is 00-0F-AC:14, 00-0F-AC:15, 00-0F-AC:16, or
28 00-0F-AC:17, this Key MIC bit is set to 0 regardless of the M parameter value.
29 A means a response is required to this message. This is used when the receiver should
30 respond to this message. This is the Key Ack bit of the Key Information field.
31
32 I is the Install bit: indicates whether to install (1) or not install (0) for the pairwise key.
33 This is the Install bit of the Key Information field.
34 K is the key type: P (Pairwise), G (Group). This is the Key Type bit of the Key Informa-
35 tion field.
36 Reserved reserved.
37
38 KeyRSC is the key RSC. This is the Key RSC field.
39 ANonce/SNonce is the Authenticator or Supplicant nonce, respectively. This is the Key Nonce field.
40 MIC is the integrity check, which is generated using the KCK. This is the Key MIC field.
41 When the negotiated AKM is 00-0F-AC:14, 00-0F-AC:15, 00-0F-AC:16, or 00-0F-
42 AC:17, this Key MIC field is not included regardless of the MIC parameter value.
43
44 {Key Data} is a sequence of zero or more elements and KDEs, concatenated and contained in the
45 Key Data field, where:
46 RSNE is described in 9.4.2.24 (RSNE).
47 RSNE[KeyName]is the RSNE, with the PMKID List field set to KeyName.
48 GTK[N] is the GTK, with the key identifier field set to N. The key identifier specifies
49
50 which index is used for this GTK. Index 0 shall not be used for GTKs,
51 except in mixed environments, as described in 12.7.1 (Key hierarchy).
52 MAC Address is the MLD MAC address of the MLD with which the transmitting STA is affili-
53 ated(#2290)
54 FTE is the Fast BSS Transition element, described in 9.4.2.47 (Fast BSS Transition
55
56 element (FTE))
57 MDE is the Mobility Domain element, described in 9.4.2.46 (Mobility Domain element
58 (MDE))
59 TIE[IntervalType]is a Timeout Interval element of type IntervalType, as described in
60 9.4.2.48 (Timeout Interval element (TIE)), containing e.g., for type Key-
61
62 Lifetime, the lifetime of the FT key hierarchy.
63 IGTK[M] is the IGTK, with key identifier field set to M.
64 IPN is the current IGTK replay counter value provided by the IGTK KDE
65

326 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 BIGTK[Q] is the BIGTK, with key identifier field set to Q

2 BIPN is the current BIGTK replay counter value provided by the BIGTK KDE
3
PMKID is of type PMKID KDE and is the key identifier used during 4-way PTK hand-
4
5 shake for PMK identification.
6 OCI KDE is a KDE containing operating channel information.
7 RSNXE is described in 9.4.2.241 (RSN Extension element (RSNXE)).
8 PMKID identifies the PMKSA selected by the Authenticator.
9
MLO GTK is the GTK for the AP affiliated with the AP MLD for the link specified by the
10
11 value in the LinkID field.(#2290)
12 MLO IGTK is the IGTK for the AP affiliated with the AP MLD for the link specified by the
13 value in the LinkID field.(#2290)
14 MLO BIGTK is the BIGTK for the AP affiliated with the AP MLD for the link specified by the
15
value in the LinkID field.(#2290)
16
17 MLO Link is the MAC address, RSNE, and RSNEX, if advertised, for the STA affiliated
18 with the MLD specified by the value of the LinkID field.(#2290)
19 “{a} or {b}” means that exactly one of either {a} or {b} is present as the {Key Data}.
20 “an” means that the KDE could occur multiple times in the field for n links.(#2290)
21
22
23 12.7.5 Nonce generation
24
25 Change the third paragraph as follows:
26
27
28 The local MAC address should be AA on the Authenticator and SPA on the Supplicant. When the
29 Authenticator is an AP MLD and the Supplicant is a non-AP MLD, the AA shall be the MLD MAC address
30 of the AP MLD and the SPA shall be the MLD address of the non-AP MLD.
31
32
33 12.7.6 4-way handshake
34
35 12.7.6.1 General
36
37 Change the first paragraph as follows:
38
39
40 RSNA defines a protocol using EAPOL-Key frames called the 4-way handshake. The handshake completes the
41 IEEE 802.1X authentication process. The information flow of the 4-way handshake is as follows:
42
Message 1: Authenticator  Supplicant: EAPOL-Key(0,0,1,0,P,0,0,ANonce,0,{} or {PMKID} or
43
44 {MAC Address}(#2290))
45 Message 2: Supplicant  Authenticator: EAPOL-Key(0,1,0,0,P,0,0,SNonce,MIC,{RSNE} or
46 {RSNE, OCI KDE} or {RSNE, RSNXE} or {RSNE, OCI KDE, RSNXE} or {RSNE,
47
48 MAC Address, MLO Linkn} or {RSNE, RSNXE, MAC Address, MLO Linkn}or
49 {RSNE, OCI KDE, RSNXE, MAC Address KDE, MLO Linkn}(#2290))
50 Message 3: AuthenticatorSupplicant: EAPOL-
51
Key(1,1,1,1,P,0,KeyRSC,ANonce,MIC,{RSNE,GTK[N]} or {RSNE, GTK[N], OCI
52
53 KDE} or {RSNE, GTK[N], RSNXE} or {RSNE, GTK[N], OCI KDE, RSNXE} or
54 {MAC Address, MLO Linkn, MLO GTKn, MLO IGTKn, MLO BIGTKn} or {OCI
55 KDE, MAC Address, MLO Linkn, MLO GTKn, MLO IGTKn, MLO
56 BIGTKn}(#2290))
57
58 Message 4: Supplicant  Authenticator: EAPOL-Key(1,1,0,0,P,0,0,0,MIC,{} or {MAC
59 Address}(#2290)).
60
61 Change the third paragraph as follows:
62
63
64 The following apply:
65

Copyright © 2022 IEEE. All rights reserved. 327

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — EAPOL-Key() denotes an EAPOL-Key frame conveying the specified argument list, using the
2 notation introduced in 12.7.4 (EAPOL-Key frame notation).
3
4 — ANonce is a nonce that the Authenticator contributes for PTK generation. ANonce has the same
5 value in message 1 and message 3.
6
— SNonce is a nonce from the Supplicant for PTK generation.
7
8 — P means the pairwise bit is set.
9
— The MIC is computed over the body of the EAPOL-Key frame (with the Key MIC field first zeroed
10
11 before the computation) using the KCK defined in 12.7.1.3 (Pairwise key hierarchy) for PTK
12 generation.
13 — RSNE represents the appropriate RSNEs. (#2290)(#6597)For AP MLD, the RSNE is present in the
14
15 MLO Link KDE.
16 — GTK[N] represents the GTK with its key identifier.
17
18 — OCI KDE contains the current operating channel information for the operating channel in which the
19 EAPOL-Key frame is sent. OCI KDE is present when
20 dot11RSNAOperatingChannelValidationActivated is true on the Supplicant in Message 2 and
21 Authenticator in Message 3. Otherwise it is absent.
22
23 — RSNXE, when included in message 2, contains the RSNXE that the Supplicant sent in its
24 (Re)Association Request frame, and when included in message 3, contains the RSNXE that the
25 Authenticator sent in its Beacon or Probe Response frame. RSNXE is present in message 2 if this
26 element is present in the (Re)Association Request frame that the Supplicant sent, and is present in
27
message 3 if this element is present in the Beacon or Probe Response frame that the Authenticator
28
29 sent. (#2290)(#6598)For AP MLD, the RSNXE is present in the MLO Link KDE.
30 — (#2290)For MLO, each message of the 4-way handshake contains an MAC Address KDE
31 containing the MLD MAC address of the Authenticator or Supplicant that is sending the message.
32
33 — (#2290)An MLO Link KDE is included for each affiliated STA link of an MLD. When included in
34 message 2, an MLO Link KDE is included for each link and contains the LinkId field and
35 corresponding affiliated STA MAC address received in the Multi-Link element by the AP MLD in
36
the (Re)Association Request frame. When included in message 3, an MLO Link KDE is included
37
38 for each affiliated AP link and contains the LinkId field, corresponding affiliated AP MAC address,
39 RSNE, and RSNXE for each affiliated AP that was sent by the Authenticator in Beacons, Probe
40 Response, and ML Probe Response frames.
41
42 — (#5919)For MLO, if RSNA has not been established, each message of the 4-way handshake shall be
43 sent on the same link used by the latest exchange of successful (Re)Association Request/Response
44 frame.
45
46 12.7.6.2 4-way handshake message 1
47
48
49 Change the first paragraph as follows:
50
51 Message 1 uses the following values for each of the EAPOL-Key frame fields:
52
53 Descriptor Type = N – see 12.7.2 (EAPOL-Key frames)
54 Key Information:
55
56 Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap
57 with HMAC-SHA-1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all other
58 cases 0
59
60 Key Type = 1 (Pairwise)
61 Reserved = 0
62
63 Install = 0
64 Key Ack = 1
65

328 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Key MIC = 0
2
3 Secure = 0
4 Error = 0
5
6 Request = 0
7 Encrypted Key Data = 0
8
9 Reserved = 0 – unused by this protocol version
10 Key Length = Cipher-suite dependent; see Table 12-7 (Cipher suite key lengths)
11
12 Key Replay Counter = n – to allow Authenticator or initiator STA to match the right message 2 from
13 Supplicant or peer STA
14 Key Nonce = ANonce
15
16 EAPOL-Key IV = 0
17 Key RSC = 0
18
19 Key MIC = 0
20 Key Data Length = length of Key Data field in octets
21
22 (#2290)Key Data =
23 — PMKID for the PMK being used during PTK generation
24
25 — For MLO, a MAC Address KDE containing the MLD MAC address of the Authenticator.
26
27 12.7.6.3 4-way handshake message 2
28
29
30 Change the first paragraph as follows:
31
32 Message 2 uses the following values for each of the EAPOL-Key frame fields:
33
34 Descriptor Type = N – see 12.7.2 (EAPOL-Key frames)
35 Key Information:
36
37 Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap
38 with HMAC-SHA-1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all other
39 cases 0 – same as message 1
40
Key Type = 1 (Pairwise) – same as message 1
41
42 Reserved = 0
43
Install = 0
44
45 Key Ack = 0
46
Key MIC = 0 when using an AEAD cipher or 1 otherwise
47
48 Secure = 0 – same as message 1
49
Error = 0 – same as message 1
50
51 Request = 0 – same as message 1
52
Encrypted Key Data = 1 when using an AEAD cipher or 0 otherwise
53
54 Reserved = 0 – unused by this protocol version
55
Key Length = 0
56
57 Key Replay Counter = n – to let the Authenticator or initiator STA know to which message 1 this
58 corresponds
59
60 Key Nonce = SNonce
61 EAPOL-Key IV = 0
62
63 Key RSC = 0
64
65

Copyright © 2022 IEEE. All rights reserved. 329

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Key MIC = Not present when using an AEAD cipher; otherwise, MIC(KCK, EAPOL) – MIC com-
2 puted over the body of this EAPOL-Key frame with the Key MIC field first initialized to 0
3
4 Key Data Length = length of Key Data field in octets
5 Key Data =
6
7 — included RSNE – the sending STA’s RSNE for PTK generation or peer RSNE for the
8 current operating band, and when this message 2 is part of a fast BSS transition initial
9 mobility domain association or an association started through the FT protocol, the
10 PMKR1Name calculated by the S1KH according to the procedures of 12.7.1.6.4 (PMK-
11
12 R1) is included in the PMKID List field of the RSNE and the FTE and MDE are also
13 included, or;
14 — The sending STA’s Multi-band element for PTK generation for a supported band other
15
than the current operating band if dot11MultibandImplemented is true, or;
16
17 — The sending STA’s RSNE and Multi-band element(s) for generating a single PTK for all
18 involved bands, if dot11MultibandImplemented is true and both the Authenticator and the
19 Supplicant use the same MAC address in the current operating band and the other
20
21 supported band(s); or;
22 — The sending STA’s RSNE and Multi-band element(s) for generating a different PTK for
23 each involved band, if dot11MultibandImplemented is true and the Joint Multi-band
24
RSNA subfield of the RSN capabilities field is 1 for both the Authenticator and the
25
26 Supplicant, and either the Authenticator or the Supplicant uses different MAC addresses
27 for different bands.
28 — Additionally, contains an OCI KDE when
29
30 dot11RSNAOperatingChannelValidationActivated is true on the Supplicant.
31 — The RSNXE that the Supplicant sent in its (Re)Association Request frame, if this element
32 is present in the (Re)Association Request frame that the Supplicant sent.
33
34 — (#2290)For MLO, a MAC Address KDE containing the MLD MAC address of the
35 Supplicant.
36
— (#2290)For MLO, an MLO Link KDE for each affiliated STA link containing the
37
38 affiliated STA MAC address included by the non-AP MLD in the Multi-Link element in
39 (Re)Association Request frame.
40
41 Change the last paragraph as follows:
42
43
44 Otherwise, the Authenticator:
45 a) Derives PTK.
46
47 b) Verifies the message 2 MIC or AEAD decryption operation result.
48 1) If the calculated MIC does not match the MIC that the Supplicant included in the EAPOL-Key
49
frame or the AEAD decryption operation returns failure, the Authenticator silently discards
50
51 message 2.
52 2) If the MIC or AEAD decryption is valid and this message 2 is part of a fast BSS transition
53 initial mobility domain association or an association started through the FT protocol, the
54
55 Authenticator checks that all fields of the RSNE other than the PMKID List field and, if
56 present, the RSNXE bitwise matches the fields from the (Re)Association Request frame and
57 that the FTE and MDE are the same as those provided in the AP’s (Re)Association Response
58 frame. If the MIC or AEAD decryption is valid and this message 2 is not part of a fast BSS
59 transition initial mobility domain association and this message 2 is not part of an association
60
61 started through the FT protocol, the Authenticator checks that the RSNE and, if present, the
62 RSNXE bitwise matches that from the (Re)Association Request frame. (#2290)For MLO,
63 validates that the affiliated STA MAC addresses are the same for each affiliated STA MAC
64 address included in the Multi-Link element in the (Re)Association Request frame.
65

330 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 i) If these are not exactly the same, the Authenticator uses MLME-DEAUTHENTI-
2 CATE.request primitive to terminate the association.
3
4 ii) If they do match bitwise, the Authenticator constructs message 3.
5 c) If management frame protection is being negotiated, the AP initializes the SA Query Transaction
6
Identifier to an implementation-specific non-negative integer value, valid for the current pairwise
7
8 security association.
9
10 12.7.6.4 4-way handshake message 3
11
12
13 Change the first paragraph as follows:
14
15 Message 3 uses the following values for each of the EAPOL-Key frame fields:
16
17 Descriptor Type = N – see 12.7.2 (EAPOL-Key frames)
18 Key Information:
19
20 Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap
21 with HMAC-SHA-1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all other
22 cases 0 – same as message 1
23
Key Type = 1 (Pairwise) – same as message 1
24
25 Reserved = 0
26
Install = 0/1 – For PTK generation, 0 only if the AP does not support key mapping keys, or if
27
28 the STA has the No Pairwise bit (in the RSN Capabilities field) equal to 1and only the
29 group key is used.
30 Key Ack = 1
31
32 Key MIC = 0 when using an AEAD cipher or 1 otherwise
33 Secure = 1 (keys installed)
34
35 Error = 0 – same as message 1
36 Request = 0 – same as message 1
37
38 Encrypted Key Data = 1
39 Reserved = 0 – unused by this protocol version
40
41 Key Length = Cipher-suite dependent; see Table 12-7 (Cipher suite key lengths)
42 Key Replay Counter = n+1
43
44 Key Nonce = ANonce – same as message 1
45 EAPOL-Key IV = 0 (Version 2) or random (Version 1)
46
47 Key RSC = (#1028)(#2505)(#2594)For PTK generation for non-MLO, starting TSC or PN that the
48 Authenticator’s STA uses in MPDUs protected by GTK. 0 for MLO.
49
50 Key MIC = Not present when using an AEAD cipher; or otherwise, MIC(KCK, EAPOL) or
51 MIC(SKCK, EAPOL) – MIC computed over the body of this EAPOL-Key frame with the Key
52 MIC field first initialized to 0
53
Key Data Length = length of Key Data field in octets
54
55 Key Data =
56
— For PTK generation for the current operating band, the AP’s Beacon/Probe Response
57
58 frame’s RSNE for the current operating band, and, optionally, a second RSNE that is the
59 Authenticator’s pairwise cipher suite assignment for the current operating band, and, if a
60 group cipher has been negotiated, the GTK and the GTK’s key identifier (see 12.7.2
61 (EAPOL-Key frames)) for the current operating band, and if management frame
62
protection is negotiated, the IGTK KDE, and if beacon protection is enabled, the BIGTK
63
64 KDE, and when this message 3 is part of a fast BSS transition initial mobility domain
65 association or an association started through the FT protocol, the PMKR1Name calculated

Copyright © 2022 IEEE. All rights reserved. 331

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 according to the procedures of 12.7.1.6.4 (PMK-R1) in the PMKID List field of the RSNE
2 and the FTE with the same contents as in the (Re)Association Response frame, the MDE
3
with the same contents as in the (Re)Association Response frame, the reassociation
4
5 deadline timeout set to the minimum of dot11FTReassociationDeadline and the key
6 lifetime in the TIE[ReassociationDeadline], and the PTK lifetime in the
7 TIE[KeyLifetime]; or
8
9 — (#2290)For MLO, the MLO GTK KDE for each setup link (see 35.3.5.1 (Multi-link
10 (re)setup procedure)). If management frame protection is negotiated, the MLO IGTK KDE
11 for each setup link. If beacon protection is enabled, the MLO BIGTK KDE for each setup
12 link. When this message 3 is part of a fast BSS transition initial mobility domain
13 association or an association started through the FT protocol, the PMKR1Name calculated
14
15 according to the procedures of 12.7.1.6.4 (PMK-R1) in the PMKID List field of the RSNE
16 and the FTE with the same contents as in the (Re)Association Response frame, the MDE
17 with the same contents as in the (Re)Association Response frame, the reassociation
18 deadline timeout set to the minimum of dot11FTReassociationDeadline and the key
19 lifetime in the TIE[ReassociationDeadline], and the PTK lifetime in the
20
21 TIE[KeyLifetime]; or
22 — For PTK generation for a supported band other than the current operating band, the
23 Authenticator’s Beacon/DMG Beacon/Announce/Probe Response/Information Response
24
frame’s Multi-band element associated with the supported band, and optionally a second
25
26 Multi-band element that indicates the Authenticator’s pairwise cipher suite assignment for
27 the supported band, and, if group cipher for the supported band is negotiated, the Multi-
28 band GTK KDE for the supported band if dot11MultibandImplemented is true, or;
29
30 — For generating a single PTK for all involved bands, the Authenticator’s Beacon/DMG
31 Beacon/Announce/Probe Response/Information Response frame’s RSNE and Multi-band
32 element(s), and optionally, additional RSNE and Multi-band element(s) that indicate the
33 Authenticator’s assignment of one pairwise cipher suite for all involved bands; if a group
34 cipher for all involved bands is negotiated, the GTK and the GTK’s key identifier for all
35
36 involved bands, if dot11MultibandImplemented is true and both the Authenticator and the
37 Supplicant use the same MAC address in the current operating band and the other
38 supported band(s), or;
39
— For generating different PTKs for the current operating band and other supported band(s),
40
41 the Authenticator’s Beacon/DMG Beacon/Announce/Probe Response/Information
42 Response frame’s RSNE and Multi-band element(s), and optionally, additional RSNE and
43 Multi-band elements that are the Authenticator’s pairwise cipher suite assignments for one
44 or more involved bands; if group ciphers for the involved bands are negotiated, the Multi-
45
band GTK KDEs for the involved bands, if dot11MultibandImplemented is true and the
46
47 Joint Multi-band RSNA subfield is 1 for both the Authenticator and Supplicant, and either
48 the Authenticator or the Supplicant uses different MAC addresses for different bands.
49 — Additionally, contains an OCI KDE when
50
51 dot11RSNAOperatingChannelValidationActivated is true on the Authenticator.
52 — The RSNXE that the Authenticator sent in its Beacon or Probe Response frame, if this
53 element is present in the Beacon or Probe Response frame that the Authenticator sent.
54
55 — (#2290)For MLO, a MAC Address KDE containing the MLD MAC address of the
56 Authenticator.
57
— (#2290)For MLO, a MLO Link KDE containing the LinkID field, the affiliated AP MAC
58
59 address, RSNE, and RSNXE for each affiliated AP that was sent by the Authenticator in
60 Beacons, Probe Response, and ML Probe Response frames.
61
62 Change the last paragraph as follows:
63
64
65 The Supplicant also:

332 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 a) Verifies the RSNE and, if present, the RSNXE. If this message 3 is part of a fast BSS transition
2 initial mobility domain association or an association started through the FT protocol, the Supplicant
3
verifies that the PMKR1Name in the PMKID List field of the RSNE is identical to the value it sent
4
5 in message 2 and verifies that all other fields of the RSNE are identical to the fields in the RSNE
6 present in the Beacon or Probe Response frames and verifies that the FTE and MDE are the same as
7 in the (Re)Association Response frame. Otherwise, the Supplicant verifies that the RSNE is
8 identical to that the STA received in the Beacon or Probe Response frame. If the RSNXE is present,
9
the Supplicant verifies that the RSNXE is identical to that the STA received in the Beacon or Probe
10
11 Response frame. If any of these verification steps indicates a mismatch, the STA shall disassociate
12 or deauthenticate. If a second RSNE is provided in the message, the Supplicant uses the pairwise
13 cipher suite specified in the second RSNE or deauthenticates.
14
15 b) (#6050)(#2290)For MLO, verifies the following:
16 • The affiliated AP MAC address and all fields in the RSNE, and the RSNXE if present, for each
17 requested link are identical to those as advertised by the corresponding affiliated APs of the AP
18
MLD in Beacon, Probe Response, and ML Probe Response frames.
19
20 • The affiliated AP MAC address and all fields in the RSNE and the RSNXE if present, of other
21 discovered links, if information is available are identical to those advertised by the affiliated APs
22 of the AP MLD in Beacon, Probe Response, and ML Probe Response frames.
23
24 If any of these verification steps includes a mismatch, the STA shall disassociate or deauthenticate.
25 If a second RSNE is provided in the message, the Supplicant deauthenticates.
26 c) Verifies the message 3 MIC or AEAD decryption operation result. If the calculated MIC does not
27
match the MIC that the Authenticator included in the EAPOL-Key frame or AEAD decryption
28
29 operation returns failure, the Supplicant silently discards message 3.
30 d) Updates the last-seen value of the Key Replay Counter field.
31
32 e) If the Extended Key ID for Individually Addressed Frames subfield of the RSN Capabilities field is
33 1 for both the Authenticator and Supplicant: Uses the MLME-SETKEYS.request primitive to
34 configure the IEEE 802.11 MAC to receive individually addressed MPDUs protected by the PTK
35 with the assigned Key ID.
36
37 f) Constructs message 4.
38 g) Sends message 4 to the Authenticator.
39
40 h) Uses the MLME-SETKEYS.request primitive to configure the IEEE 802.11 MAC to send and, if the
41 receive key has not yet been installed, to receive individually addressed MPDUs protected by the
42 PTK. The GTK is also configured by MLME-SETKEYS primitive.
43
44
45 12.7.6.5 4-way handshake message 4
46
47 Change the first paragraph as follows:
48
49
Message 4 uses the following values for each of the EAPOL-Key frame fields:
50
51 Descriptor Type = N – see 12.7.2 (EAPOL-Key frames)
52
Key Information:
53
54 Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap
55 with HMAC-SHA-1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all other
56 cases 0 – same as message 1
57
58 Key Type = 1 (Pairwise) – same as message 1
59 Reserved = 0
60
61 Install = 0
62 Key Ack = 0 – this is the last message
63
64 Key MIC = 0 when using an AEAD cipher or 1 otherwise
65

Copyright © 2022 IEEE. All rights reserved. 333

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Secure = 1
2
3 Error = 0
4 Request = 0
5
6 Encrypted Key Data = 1 when using an AEAD cipher or 0 otherwise
7 Reserved = 0 – unused by this protocol version
8
9 Key Length = 0
10 Key Replay Counter = n+1
11
12 Key Nonce = 0
13 EAPOL-Key IV = 0
14
15 Key RSC = 0
16 Key MIC = Not present when using an AEAD cipher; or otherwise, MIC(KCK, EAPOL) – MIC
17 computed over the body of this EAPOL-Key frame with the Key MIC field first initialized to 0
18
19 Key Data Length = length of Key Data field in octets
20 Key Data = (#2290)none requiredFor MLO, a MAC Address KDE containing the MLD MAC
21
address of the Supplicant, otherwise there is no Key Data.
22
23
24 12.7.7 Group key handshake
25
26 12.7.7.1 General
27
28
29 Change the first three paragraphs as follows:
30
31 The Authenticator uses the Group key handshake to send a new GTK and, if management frame protection is
32 negotiated, a new IGTK, and if beacon protection is enabled, a new BIGTK to the Supplicant.
33
34 (#1028)(#2505)(#2594)When the Authenticator is an AP MLD and the Supplicant is a non-AP MLD, the
35 Authenticator may also use the Group key handshake to send new GTK(s) for any of the setup links and, if
36 management frame protection is negotiated, new IGTK(s) for any of the setup links, and if beacon protection is
37 enabled, new BIGTK(s) for any of the setup links to the Supplicant.
38
39
40 The Authenticator may initiate the exchange when a Supplicant is disassociated or deauthenticated.
41 Message 1: Authenticator  Supplicant:
42
43 EAPOL-Key(1,1,1,0,G,0,Key RSC,0, MIC, {GTK[N], IGTK[M], BIGTK[Q]} or {MLO GTKn,
44 MLO IGTKn, MLO BIGTKn})(#1028)(#2505)(#2594)
45 Message 2: Supplicant  Authenticator: EAPOL-Key(1,1,0,0,G,0,0,0,MIC,{})
46
47
48 The following apply:
49 — Key RSC denotes the last TSC or PN sent using the GTK.
50
51 — GTK[N] denotes the GTK with its key identifier as defined in 12.7.2 (EAPOL-Key frames) using
52 the KEK defined in 12.7.1.3 (Pairwise key hierarchy) and associated IV.
53 — IGTK[M], when present, denotes the IGTK with its key identifier as defined in 12.7.2 (EAPOL-Key
54
55 frames) using the KEK defined in 12.7.1.3 (Pairwise key hierarchy) and associated IV.
56 — BIGTK[Q], when present, denotes the BIGTK with its key identifier as defined in 12.7.2 (EAPOL-
57 Key frames) using the KEK defined in 12.7.1.3 (Pairwise key hierarchy) and associated IV.
58
59 — The MIC is computed over the body of the EAPOL-Key frame (with the MIC field zeroed for the
60 computation) using the KCK defined in 12.7.1.3 (Pairwise key hierarchy).
61
— OCI KDE represents the current operating channel information using which the EAPOL-Key frame
62
63 is sent. OCI KDE is included when dot11RSNAOperatingC\hannelValidationActivated is true on
64 the STA sending the message.
65

334 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — (#1028)(#2505)(#2594)MLO GTKn, when present, denotes the GTK for the AP affiliated with the
2 AP MLD for the link specified by LinkID n as defined in 12.7.2 (EAPOL-Key frames).
3
4 — MLO IGTKn, when present, denotes the IGTK for the AP affiliated with the AP MLD for the link
5 specified by LinkID n as defined in 12.7.2 (EAPOL-Key frames).
6
— MLO BIGTKn, when present, denotes the GTK for the AP affiliated with the AP MLD for the link
7
8 specified by LinkID n as defined in 12.7.2 (EAPOL-Key frames).
9
10 12.7.7.2 Group key handshake message 1
11
12
13
Change as follows:
14
15 Message 1 uses the following values for each of the EAPOL-Key frame fields:
16
Descriptor Type = N – see 12.7.2 (EAPOL-Key frames)
17
18 Key Information:
19
Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap
20
21 with HMAC-SHA-1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all other
22 cases 0
23 Key Type = 0 (Group)
24
25 Install = 0
26 Key Ack = 1
27
28 Key MIC = 0 when using an AEAD cipher or 1 otherwise
29 Secure = 1
30
31 Error = 0
32 Request = 0
33
34 Encrypted Key Data = 1
35 Reserved = 0
36
37 Key Length = 0
38 Key Replay Counter = n+2
39
40 Key Nonce = 0
41 EAPOL-Key IV = 0 (Version 2) or random (Version 1)
42
43 Key RSC = last TSC or PN for the GTK for non-MLO. 0 for MLO.(#1028)(#2505)(#2594)
44 Key MIC = Not present when using an AEAD cipher; otherwise, MIC(KCK, EAPOL)
45
46 Key Data Length = length of Key Data field in octets
47 (#1028)(#2505)(#2594)Key Data = encrypted, encapsulated
48
49 — For non-MLO, GTK and the GTK’s key identifier (see 12.7.2 (EAPOL-Key frames))
50 — When present, IGTK, IGTK’s key identifier, and IPN (see 12.7.2 (EAPOL-Key frames))
51
52 — When present, BIGTK, BIGTK’s key identifier, and BIPN (see 12.7.2 (EAPOL-Key
53 frames))
54
55 — OCI KDE when dot11RSNAOperatingChannelValidationActivated is true on the
56 Authenticator
57 — For MLO, when present, the MLO GTK KDE (see 12.7.2 (EAPOL-Key frames)) for any
58
of the setup links
59
60 — For MLO, when present, the MLO IGTK KDE (see 12.7.2 (EAPOL-Key frames)) for any
61 of the setup links
62
63 — For MLO, when present, the MLO BIGTK KDE (see 12.7.2 (EAPOL-Key frames)) for
64 any of the setup links
65

Copyright © 2022 IEEE. All rights reserved. 335

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The Authenticator sends message 1 to the Supplicant.

2
3
On reception of message 1, the Supplicant:
4
5 a) Verifies that the Key Replay Counter field value has not yet been seen before, i.e., its value is
6 strictly larger than that in any other EAPOL-Key frame received thus far during this session.
7
8 b) If dot11RSNAOperatingChannelValidationActivated is true and Authenticator RSNE indicates
9 OCVC capability, the Supplicant silently discards message 1 if any of the following are true:
10 — OCI KDE is missing in the message
11
12 — Channel information in the OCI KDE does not match current operating channel parameters (see
13 12.2.9 (Requirements for Operating Channel Validation))
14
15 c) Verifies that the MIC is valid, i.e., it uses the KCK that is part of the PTK to verify that there is no
16 data integrity error, or that the AEAD decryption steps succeed.
17 d) (#1028)(#2505)(#2594)When the Supplicant is not an MLD, usesUses the MLME-
18
SETKEYS.request primitive to configure the temporal GTK and, the IGTK when present, and the
19
20 BIGTK if beacon protection is enabled, into the MAC. When the Supplicant is a non-AP MLD, uses
21 the MLME-SETKEYS.request primitive to configure the temporal GTK(s) when present and, the
22 IGTK(s) when present, and the BIGTK(s) when present for the indicated link(s) into the MAC of the
23 affiliated non-AP STA(s) operating on the indicated link(s).
24
25 e) Responds by creating and sending message 2 of the group key handshake to the Authenticator and
26 incrementing the replay counter.
27
28 NOTE—The Authenticator increments and uses a new Key Replay Counter field value on every message 1 instance,
29 even retries, because the message 2 responding to an earlier message 1 might have been lost. If the Authenticator did not
30 increment the replay counter, the Supplicant discards the retry, and no responding message 2 ever arrives.
31
32 12.7.8 TDLS PeerKey (TPK) security protocol
33
34 12.7.8.2 TPK handshake
35
36
37 Change the fourth paragraph as follows:
38
39 The TDLS initiator STA and the TDLS responder STA perform the following exchange to set up a TPK:
40
41 TDLS PMK handshake message 1: TDLS initiator STA → TDLS responder STA:
42 Link Identifier element, RSNE, Timeout Interval element, FTE(#4031), TDLS Multi-Link ele-
43
ment (optionally included if the transmitting STA is affiliated with a non-AP MLD (see 35.3.21
44
45 (TDLS procedure in multi-link operation(#4032))))
46 TDLS PMK handshake message 2: TDLS responder STA → TDLS initiator STA:
47
48 Link Identifier element, RSNE, Timeout Interval element, FTE(#4031), TDLS Multi-Link ele-
49 ment (optionally included if the transmitting STA is affiliated with a non-AP MLD (see 35.3.21
50 (TDLS procedure in multi-link operation(#4032))))
51
52 TDLS PMK handshake message 3: TDLS initiator STA → TDLS responder STA:
53 Link Identifier element, RSNE, Timeout Interval element, FTE(#4031), TDLS Multi-Link ele-
54 ment (optionally included if the transmitting STA is affiliated with a non-AP MLD (see 35.3.21
55
(TDLS procedure in multi-link operation(#4032))))
56
57
58 where
59 TDLS initiator STA Address field of the Link Identifier element is the MAC address of the TDLS initiator
60 STA
61
TDLS responder STA Address field of the Link Identifier element is the MAC address of the TDLS
62
63 responder STA
64 TimeoutIntervalType field of the Timeout Interval element is the key lifetime
65

336 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 PairwiseCipherSuite field of the RSNE identifies the cipher suite used to protect the Data frames sent over
2 the direct link
3
AKM suite list of the RSNE identifies which Authentication Method was used
4
5 SNonce field of the FTE is a 256 bit value randomly generated by the TDLS initiator STA
6 ANonce field of the FTE is a 256 bit value randomly generated by the TDLS responder STA (set
7 to 0 in message 1)
8 MIC field of the FTE is 0 for message 1 and computed as described in 12.7.8.4.3 (TPK
9
handshake message 2) and 12.7.8.4.4 (TPK handshake message 3) for
10
11 messages 2 and 3, respectively
12
13 Change the eighth paragraph, including adding an equation number (12-1), as follows:
14
15
16 The TPK shall be derived as follows (#4031)when the TDLS setup frames transmitted by at least one of the
17 participating STAs does not include the TDLS Multi-Link element carrying the AP MLD MAC Address:
18
19 TPK-Key-Input = Hash(min (SNonce, ANonce) || max (SNonce, ANonce))
20
21
22 TPK = KDF-Hash-Length(TPK-Key-Input, “TDLS PMK”, min (MAC_I, MAC_R) || max (MAC_I,
23 MAC_R) || BSSID) (12-1)
24
25 where
26 Hash is the hash algorithm specific to the negotiated AKM (see Table 9-188 (AKM
27 suite selectors))
28
KDF-Hash-Length is the key derivation function defined in 12.7.1.6.2 (Key derivation function
29
30 (KDF))
31 Length is TK_bits + 128
32 TK_bits is cipher-suite dependent and specified in Table 12-8 (Cipher suite key lengths)
33 MAC_I and MAC_R are the MAC addresses of the TDLS initiator STA and the TDLS responder STA,
34
respectively
35
36 SNonce and ANonce are the nonces generated by the TDLS initiator STA and TDLS responder STA,
37 respectively, for this instance of the TPK handshake. The BSSID is set to the
38 BSSID of the BSS of which the TDLS initiator STA is a member.
39 (#4031)BSSID is the BSSID of the BSS of which the TDLS initiator STA is a member
40
41
42 Insert the following paragraph after the eighth paragraph (“The TPK shall be derived as ...” ):
43
44 (#4031)The TPK shall be derived as follows when the TDLS setup frames transmitted by both peers include
45
the TDLS Multi-Link element carrying the AP MLD MAC Address and the setup is for a single link TDLS:
46
47
48 TPK-Key-Input = Hash(min (SNonce, ANonce) || max (SNonce, ANonce))
49
50 TPK = KDF-Hash-Length(TPK-Key-Input, “TDLS PMK”, min (MAC_I, MAC_R) || max (MAC_I,
51 MAC_R) || BSSID || AP MLD MAC) (12-2)
52
53
where
54
55 Hash, KDF-Hash-Length, Length, TK_bits, MAC_I, MAC_R, SNonce, ANonce and BSSID are as
56 defined above.
57 AP MLD MAC is the MLD MAC address of the AP MLD with which the initiating non-AP
58 MLD has per-formed multi-link setup.
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 337

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 12.7.8.4 TPK Security Protocol handshake messages

2
3
12.7.8.4.3 TPK handshake message 2
4
5
6 Change the first paragraph as follows:
7
8 If the TDLS responder STA validates the TPK handshake message 1 for this TDLS instance, the TDLS
9
10 responder STA may respond with TPK handshake message 2. To do so, the TDLS responder STA shall add
11 an RSNE, FTE, and Timeout Interval element to its TDLS Setup Response frame. The elements shall be
12 formatted as follows:
13
The RSNE shall include the following:
14
15 Include a pairwise cipher suite from one of those presented in RSNE of message 1 of this
16 sequence in the pairwise cipher suite list, and set the pairwise cipher suite count to 1.
17
18 The version number shall be the minimum of the maximum version supported by the TDLS
19 responder STA and the version number received in the RSNE of message 1.
20 All other RSNE fields shall be same as those received in message 1.
21
22 The Timeout Interval element shall be the same as that received in the TPK handshake message 1.
23 The FTE shall include the following:
24
25 ANonce shall be set to a value chosen randomly by the TDLS responder STA, see 12.7.5
26 (Nonce generation) for a recommended procedure.
27
28 SNonce shall be same as that received in message 1 of this sequence
29 The MIC shall be calculated on the concatenation, in the following order, of:
30
31 TDLS initiator STA MAC address (6 octets)
32 TDLS responder STA MAC address (6 octets)
33
34 Transaction Sequence number (1 octet) which shall be set to the value 2
35 Link Identifier element
36
37 RSNE
38 Timeout Interval element
39
40 FTE, with the MIC field of the FTE set to 0(#4031).
41 (#4031)TDLS Multi-Link element (when present).
42
43 The MIC shall be calculated using the TPK-KCK and the AES-128-CMAC algorithm. The out-
44 put of the AES-128-CMAC shall be 128 bits.
45 All other fields shall be set to 0.
46
47
48 12.7.8.4.4 TPK handshake message 3
49
50 Change the first paragraph as follows:
51
52
53 If the TDLS initiator STA responds to message 2 for this TDLS instance, the TDLS initiator STA shall add
54 an RSNE, FTE, and Timeout Interval element to its TDLS Setup Confirm frame. The elements shall be
55 formatted as follows:
56
The RSNE shall be the same as the RSNE received in message 2.
57
58 The Timeout Interval element shall be the same as that received in the TPK handshake message 2.
59
With the exception of the MIC field, the contents of the FTE shall be the same as the FTE receivedin
60
61 message 2.
62 The MIC shall be calculated on the concatenation, in the following order, of:
63
64 TDLS initiator STA MAC address (6 octets)
65

338 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 TDLS responder STA MAC address (6 octets)

2
3 Transaction Sequence number (1 octet), which shall be set to the value 3
4 Link Identifier element
5
6 RSNE
7 Timeout Interval element
8
9 FTE, with the MIC field of the FTE set to 0(#4031).
10 (#4031)TDLS Multi-Link element (when present).
11
12 The MIC shall be calculated using the TPK-KCK and the AES-128-CMAC algorithm. The output of
13 the AES-128-CMAC shall be 128 bits.
14 All other fields shall be set to 0.
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 339

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 13. Fast BSS transition

2
3
4
5
13.1 Overview
6
7 Change the first four paragraphs as follows:
8
9 Fast BSS transition seeks to reduce the length of time that connectivity is lost between a STA and the DS or
10
11
between an MLD and the DS during a BSS transition. The FT protocols are part of the reassociation service
12 and only apply to STA transitions between APs, or a STA or non-AP MLD transition to an AP MLD or a
13 non-AP MLD transition to an AP within the same mobility domain within the same ESS (see 4.5.3.2
14 (Mobility types)).
15
16
17
The FT protocols require information to be exchanged during the initial association (or a later reassociation)
18 between a STA [known as the FT Originator (FTO)] and AP (#5070)[known as the FT Responder (FTR)] or
19 between a non-AP MLD [known as the FT Originator (FTO)] and AP MLD [known as the FT Responder
20 (FTR)]. The initial exchange is referred to as the FT initial mobility domain association. Subsequent
21 reassociations to APs within the same mobility domain may make use of the FT protocols.
22
23
24 Two FT protocols are defined:
25 — FT protocol. This protocol is executed when an FTO makes a transition to a target AP or target AP
26 MLD and does not require a resource request prior to its transition.
27
28 — FT resource request protocol. This protocol is executed when an FTO requires a resource request
29 prior to its transition.
30
31
32
For an FTO to move from its current AP to a target AP or target AP MLD utilizing the FT protocols, the
33 message exchanges are performed using one of two methods:
34 — Over-the-Air. The FTO communicates directly with the target AP or target AP MLD using IEEE
35 802.11 authentication with the FT authentication algorithm.
36
37 — Over-the-DS. The FTO communicates with the target AP via the current AP. The communication
38 between the FTO and the target AP is carried in FT Action frames between the FTO and the current
39 AP. Between the current AP and target AP, communication is via an encapsulation method
40
41
described in 13.10.3 (Remote Request/Response frame definition). The current AP converts
42 between the two encapsulations.
43
44
45 13.2 Key holders
46
47 13.2.1 Introduction
48
49
50 Change the second paragraph as follows:
51
52 The R0KH and R1KH are part of AP’s or AP MLD’s SME RSNA key management. The computation of
53 PMK-R0 and PMK-R1, and all of the intermediate results in the computations, shall be restricted to the
54 R0KH. The computation of PTK, and all intermediate results in its computation, shall be restricted to the
55
56 R1KH.
57
58 13.2.2 Authenticator key holders
59
60
61 Change the seventh paragraph as follows:
62
63
64
65

340 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The R1KH shall meet the following requirements:

2
3 — The R1KH-ID shall be set to a MAC address of the physical entity that stores the PMK-R1 and uses
4 it to generate the PTK. That same MAC address shall be used to advertise the PMK-R1 identity to
5 the STA or non-AP MLD and the R0KH.
6
7 — The R1KH shall derive and distribute the GTK and IGTK to all connected STAs. If the R1KH
8 identifies an AP MLD, the R1KH shall distribute the GTKs and IGTKs for setup links to all
9 connected non-AP MLDs.
10
11
— If beacon protection is enabled, the R1KH shall derive and distribute the BIGTK and BIPN to all
12 connected STAs. If an R1KH identifies an AP MLD, the R1KH shall derive and distribute the
13 BIGTKs and BIPNs for setup links to all connected non-AP MLDs.
14 — When the PMK-R1 lifetime expires, the R1KH shall delete the PMK-R1 PMKSA and shall revoke
15
16 all PTKSAs derived from the PMK-R1 using the MLME-DELETEKEYS primitive.
17 — The R1KH shall not expose the PMK-R1 to other parties.
18
19
20
13.2.3 Supplicant key holders
21
22 Change the second paragraph as follows:
23
24 The S0KH interacts with the IEEE 802.1X functional block (see Figure 4-24 (Portion of the ISO/IEC basic
25
26
reference model covered in this standard) in 4.9 (Reference model)) to receive the MSK resulting from an
27 EAP authentication or the FILS-FT resulting from a FILS authentication. The S1KH interacts with the IEEE
28 802.1X entity to open the Controlled Port. Both the S0KH and S1KH interactions with the IEEE 802.1X
29 entity occur within the SME of a STA or a non-AP MLD.
30
31
32 13.3 Capability and policy advertisement
33
34
35 Insert the following paragraph after the first paragraph (“The FT capability is advertised in...”)
36 as follows:
37
38 All APs affiliated with an AP MLD shall advertise the same MDE and at least one common AKM for which
39 the Authentication type column indicates FT authentication.
40
41
42
43
13.4 FT initial mobility domain association
44
45 13.4.1 Overview
46
47 Change as follows:
48
49
50 The FT initial mobility domain association is the first (re)association in the mobility domain, where the
51 SME of the STA or non-AP MLD enables its future use of the FT procedures.
52
53 FT initial mobility domain association is typically the first association within the ESS. In addition to
54
55
Association Request and Response frames, Reassociation Request and Response frames are supported in the
56 initial mobility domain association to enable both FT and non-FT APs or AP MLDs to be present in a single
57 ESS.
58
59 NOTE—For MLO, the non-AP MLD and AP MLD include the (#6700)Basic Multi-Link element in all Authentication
60 and (Re)Association Request/Response frames. The (#6700)Basic Multi-Link element includes the MLD address for the
61 respective MLD and is used to establish the security association.
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 341

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 13.4.2 FT initial mobility domain association in an RSN

2
3
4 Change as follows (Figure 13-2 not shown):
5
6 A STA or a non-AP MLD indicates its support for the FT procedures by including the MDE in the
7 (Re)Association Request frame and indicates its support of security by including the RSNE. The AP or AP
8 MLD responds by including the FTE, MDE, and RSNE(s) in the (Re)Association Response frame. After a
9
10 successful IEEE 802.1X authentication (if needed) or SAE authentication, the STA and AP or the non-AP
11 MLD and the AP MLD perform an FT 4-way handshake. At the end of the sequence, the IEEE 802.1X
12 Controlled Port is opened, and the FT key hierarchy has been established. The message flow between a STA
13 and an AP is shown in Figure 13-2 (FT initial mobility domain association in an RSN).
14
15
16 A non-DMG STA or a non-AP MLD initiates the FT initial mobility domain association procedures by
17 performing an IEEE 802.11 authentication using the Open System authentication algorithm.
18 STAAP: Authentication-Request (Open System authentication algorithm)
19
20 APSTA: Authentication-Response (Open System authentication algorithm, Status)
21 non-AP MLDAP MLD:Authentication-Request (Open System authentication algorithm,
22
23
(#6700)Basic Multi-Link element)
24 AP MLDnon-AP MLD:Authentication-Response (Open System authentication algorithm, Status,
25 (#6700)Basic Multi-Link element)
26
27
28 A DMG STA initiates the FT initial mobility domain association procedures by performing an IEEE 802.11
29 authentication using the SAE algorithm.
30 STAAP: Authentication-Request (SAE algorithm)
31 APSTA: Authentication-Response (SAE algorithm, Status)
32
33
34 The SME of the STA or non-AP MLD initiates the authentication exchange, through the use of the MLME-
35 AUTHENTICATE.request primitive, and the SME of the AP or AP MLD, respectively, responds with
36 MLME-AUTHENTICATE.response primitive. See 11.3.5 (Authentication and deauthentication).
37
38 Upon successful IEEE 802.11 Open System or SAE authentication, if using a suite type for which the
39
40 Authentication type column indicates FT authentication (see Table 9-151 (AKM suite selectors)), the STA
41 shall send a (Re)Association Request frame to the AP that includes the MDE or a non-AP MLD shall send a
42 (Re)Association Request frame that includes the MDE through an affiliated non-AP STA to the AP MLD
43 through an affiliated AP. The contents of the MDE shall be the values advertised by the AP or any AP
44 affiliated with the AP MLD in its Beacon or Probe Response frames. Additionally, the STA or non-AP MLD
45
46 includes its security capabilities in the RSNE.
47 STAAP: (Re)Association Request (MDE, RSNE, RSNXE)
48
49 APSTA: (Re)Association Response (MDE, FTE[R1KH-ID, R0KH-ID], RSNXE)
50 non-AP MLDAP MLD: (Re)Association Request (MDE, RSNE, RSNXE, (#6700)Basic Multi-
51 Link element)
52
53 AP MLDnon-AP MLD: (Re)Association Response (MDE, FTE[R1KH-ID, R0KH-ID], RSNE,
54 RSNXE, (#6700)Basic Multi-Link element)
55
56 The SME of the STA or non-AP MLD initiates the (re)association through the use of the MLME-
57
58 ASSOCIATE.request or MLME-REASSOCIATE.request primitive. The SME of the AP or AP MLD
59 responds to the indication with MLME-ASSOCIATE.response or MLME-REASSOCIATE.response
60 primitive. See 11.3.6 (Association, reassociation, and disassociation).
61
62 If the contents of the MDE received by the AP do not match the contents advertised in the Beacon and Probe
63
64 Response frames, the AP shall reject the (Re)Association Request frame with status code
65 STATUS_INVALID_MDE. If an MDE is present in the (Re)Association Request frame and the contents of

342 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 the RSNE do not indicate a negotiated AKM for which the Authentication type column indicates FT
2 authentication (see Table 9-151 (AKM suite selectors)), the AP shall reject the (Re)Association Request
3
4 frame with status code STATUS_INVALID_AKMP.
5
6 For MLO, if the contents of the MDE received by the AP MLD do not match the contents advertised in the
7 Beacon and Probe Response frames of APs affiliated with the AP MLD, the AP MLD shall reject the
8 (Re)Association Request frame with status code STATUS_INVALID_MDE. If an MDE is present in the
9
10 (Re)Association Request frame and the contents of the RSNE do not indicate a negotiated AKM for which
11 the Authentication type column indicates FT authentication (see Table 9-151 (AKM suite selectors)), the AP
12 MLD shall reject the (Re)Association Request frame with status code STATUS_INVALID_AKMP.
13
14 The (Re)Association Response frame from the AP shall contain an MDE, with contents as presented in
15
16 Beacon and Probe Response frames. The (Re)Association Response frame from the AP MLD shall contain
17 an MDE, with contents as presented in Beacon and Probe Response frames of APs affiliated with the AP
18 MLD. The FTE shall include the key holder identities of the AP or the AP MLD, the R0KH-ID and R1KH-
19 ID, set to the values of dot11FTR0KeyHolderID and dot11FTR1KeyHolderID, respectively. The FTE shall
20 have a MIC element count of zero (i.e., no MIC present) and have ANonce, SNonce, and MIC fields set to 0.
21
22 The RSNXE Used subfield of the MIC Control field shall be set to 0.
23
24 On successful (re)association, the S0KH on the STA or the non-AP MLD and the R0KH on the AP or the AP
25 MLD, respectively, then proceed with an IEEE 802.1X authentication using EAPOL PDUs carried in IEEE
26 802.11 Data frames if SAE authentication was not performed (i.e., if the suite type is not 00-0F-AC:9). The
27
28 S0KH shall use the value of R0KH-ID as the endpoint identifier of the NAS Client (NAS-Identifier if
29 RADIUS is used) in the exchange as defined in IETF RFC 3748 [B37].
30
31 If IEEE 802.1X authentication was performed, then upon successful completion of authentication, the
32 R0KH receives the MSK and authorization attributes. If SAE authentication was performed, the R0KH
33
34 receives the PMK, resulting in the successful completion of SAE. If a key hierarchy already exists for this
35 STA or non-AP MLD belonging to the same mobility domain (i.e., having the same MDID), the R0KH shall
36 delete the existing PMK-R0 security association and PMK-R1 security associations. It then calculates the
37 PMK-R0, PMKR0Name, and PMK-R1 and makes the PMK-R1 available to the R1KH of the AP with
38 which the STA is associated or the AP MLD with which the non-AP MLD is associated.
39
40
41 If the SME of the STA or the non-AP MLD cannot authenticate the AS, then it shall disassociate with an
42 MLME-DISASSOCIATE.request primitive. If the AS signals the Authenticator that the STA or the non-AP
43 MLD cannot be authenticated, then the SME of the AP or the AP MLD, respectively, shall disassociate with
44 an MLME-DISASSOCIATE.request primitive.
45
46
47 If the MSK lifetime attribute is provided by the AS, the lifetime of the PMK-R0 shall not be more than the
48 lifetime of the MSK. If the MSK lifetime attribute is not provided, the PMK-R0 lifetime shall be
49 dot11FTR0KeyLifetime. For PSK, the PMK-R0 lifetime shall be dot11FTR0KeyLifetime. The lifetime of
50 the PMK-R1s and PTK shall be the same as the lifetime of PMK-R0. When the key lifetime expires, each
51
52 key holder shall delete its respective PMK-R0, PMK-R1, and PTK SAs.
53
54 The R1KH and S1KH then perform an FT 4-way handshake. The EAPOL-Key frame notation is defined in
55 12.7.4 (EAPOL-Key frame notation).
56
57
58 Between a STA and an AP, the FT 4-way handshake is as follows:
59 R1KHS1KH: EAPOL-Key(0, 0, 1, 0, P, 0, 0, ANonce, 0, {})
60
61 S1KHR1KH: EAPOL-Key(0, 1, 0, 0, P, 0, 0, SNonce, MIC, {RSNE[PMKR1Name], MDE, FTE,
62 RSNXE})
63 R1KHS1KH: EAPOL-Key(1, 1, 1, 1, P, 0, 0, ANonce, MIC, {RSNE[PMKR1Name], MDE,
64
65
GTK[N], IGTK[M], BIGTK[Q], FTE, TIE[ReassociationDeadline], TIE[KeyLifetime], RSNXE})

Copyright © 2022 IEEE. All rights reserved. 343

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 S1KHR1KH: EAPOL-Key(1, 1, 0, 0, P, 0, 0, 0, MIC, {})

2
3
4 Between a non-AP MLD and an AP MLD, the FT 4-way handshake is as follows:
5 R1KHS1KH: EAPOL-Key(0, 0, 1, 0, P, 0, 0, ANonce, 0, {MAC Address})
6
7 S1KHR1KH: EAPOL-Key(0, 1, 0, 0, P, 0, 0, SNonce, MIC, {RSNE[PMKR1Name], MDE, FTE,
8 RSNXE, MAC Address, MLO Linkn})
9 R1KHS1KH: EAPOL-Key(1, 1, 1, 1, P, 0, 0, ANonce, MIC, {MAC Address, MLO Linkn with
10
11
RSNE[PMKR1Name], MDE, MLO GTKn, MLO IGTKn, MLO BIGTKn, FTE, TIE[Reassociation-
12 Deadline], TIE[KeyLifetime]})
13 S1KHR1KH: EAPOL-Key(1, 1, 0, 0, P, 0, 0, 0, MIC, {MAC Address})
14
15
16 where MLO GTKn is the MLO GTK KDE for link n, MLO IGTKn is the MLO IGTK KDE for link n, and
17 MLO BIGTKn is the MLO BIGTK KDE for link n.
18
19 NOTE—MAC Address KDE is the MLD MAC address of the MLD with which the transmitting STA is affiliated. See
20 12.7.4 (EAPOL-Key frame notation).
21
22 (#5919)Between a non-AP MLD and an AP MLD, if RSNA has not been established, each message of the
23 FT 4-way handshake shall be sent on the same link used by the latest exchange of successful
24
25 (Re)Association Request/Response frame.
26
27 The message sequence is described in 12.7.6 (4-way handshake).
28
29 It is assumed by this standard that the reassociation deadline is administered consistently across the mobility
30
31 domain. The mechanism for such consistent administration is outside the scope of this standard.
32
33 The PTK shall be calculated by the R1KH and S1KH according to the procedures given in 12.7.1.6.5 (PTK).
34
35 Upon completion of a successful FT 4-way handshake, the IEEE 802.1X Controlled Port shall be opened on
36
37 both the non-AP STA and the AP or the non-AP MLD and the AP MLD. Subsequent EAPOL-Key frames
38 shall use the key replay counter to detect replayed messages.
39
40 Upon completion of a successful FT 4-way handshake, the PTK lifetime timer is initiated. The operation of
41 this timer prevents the PTKSA being used for longer than the value provided in the TIE[KeyLifetime] sent
42
43 in message 3.
44
45 Once the PTKSA key lifetime expires, as indicated by the TIE[KeyLifetime], to continue its association in
46 the mobility domain the STA or the non-AP MLD shall perform the FT initial mobility domain association
47 procedures. If the AP or the AP MLD sends a Deauthentication or Disassociation frame to the STA or the
48
49 non-AP MLD, respectively, with reason code INVALID_AUTHENTICATION, then to continue its
50 association in the mobility domain, the STA or the non-AP MLD shall perform the FT initial mobility
51 domain association procedures with any AP or any AP MLD, respectively, in the mobility domain. If the
52 Supplicant EAPOL state machines are triggered to send an EAPOL-Start frame after a successful initial
53 mobility domain association, the STA or the non-AP MLD shall perform the FT initial mobility domain
54
55 association procedures.
56
57 13.4.3 FT initial mobility domain association in a non-RSN
58
59 Change as follows (Figure 13-3 not shown):
60
61
62 In this sequence, the STA or non-AP MLD utilizes the FT procedures by including the MDE in the
63 (Re)Association Request frame. The AP or AP MLD responds by including the MDE in the (Re)Association
64
65

344 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Response frame. The message flow between a STA and an AP is shown in Figure 13-3 (FT initial mobility
2 domain association in a non-RSN).
3
4
5 The STA or non-AP MLD initiates the FT initial mobility domain association procedures by performing an
6 IEEE 802.11 authentication using the Open System authentication algorithm.
7
8
STAAP: Authentication-Request (Open System authentication algorithm)
9 APSTA: Authentication-Response (Open System authentication algorithm, Status)
10
11
non-AP MLDAP MLD: Authentication-Request (Open System authentication algorithm,
12 (#6700)Basic Multi-Link element)
13 AP MLDnon-AP MLD: Authentication-Response (Open System authentication algorithm, Sta-
14 tus, (#6700)Basic Multi-Link element)
15
16
17 The SME of the STA or the non-AP MLD initiates the authentication exchange through the use of the
18 primitive MLME-AUTHENTICATE.request primitive, and the SME of the AP or the AP MLD responds
19 with MLME-AUTHENTICATE.response primitive. See 11.3.5 (Authentication and deauthentication).
20
21
22 Upon successful IEEE 802.11 Open System authentication, the STA shall send a (Re)Association Request
23 frame to the AP and shall include the MDE or a STA affiliated with the non-AP MLD shall send a
24 (Re)Association Request frame to an AP affiliated with the AP MLD that includes the MDE. The contents
25 of the MDE shall be the values advertised by the AP or any AP affiliated with the AP MLD in its Beacon or
26 Probe Response frames.
27
28 STAAP: (Re)Association Request (MDE)
29 APSTA: (Re)Association Response (MDE)
30
31 non-AP MLDAP MLD: (Re)Association Request (MDE, (#6700)Basic Multi-Link element)
32 AP MLDnon-AP MLD: (Re)Association Response (MDE, (#6700)Basic Multi-Link element)
33
34
35 The SME of the STA or the non-AP MLD initiates the (re)association through the use of the MLME-
36 ASSOCIATE.request or MLME-REASSOCIATE.request primitive. The SME of the AP or the AP MLD
37 responds to the indication with MLME-ASSOCIATE.response or MLME-REASSOCIATE.response
38 primitive. See 11.3.6 (Association, reassociation, and disassociation).
39
40
41 If the contents of the MDE received by the AP do not match the contents advertised in the Beacon and Probe
42 Response frames, the AP shall reject the (Re)Association Request frame with status code
43 STATUS_INVALID_MDE.
44
45
46 The (Re)Association Response frame from the AP shall contain an MDE, with contents as presented in
47 Beacon and Probe Response frames.
48
49 If the contents of the MDE received by the AP MLD do not match the contents advertised in the Beacon and
50 Probe Response frames of APs affiliated with the AP MLD, the AP MLD shall reject the (Re)Association
51
52 Request frame with status code STATUS_INVALID_MDE.
53
54 The (Re)Association Response frame from the AP MLD shall contain an MDE, with contents as presented
55 in the Beacon and Probe Response frames of APs affiliated with the AP MLD.
56
57
58 On successful (re)association, the AP and the non-AP STA or the AP MLD and the non-AP MLD shall
59 transition to State 4 (as defined in 11.3 (STA authenticationAuthentication and association(#2277))) to
60 enable Data frame transmission.
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 345

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 13.5 FT protocol
2
3
4 13.5.1 Overview
5
6 Change as follows:
7
8
9
STAs (#5070)and MLDs with dot11FastBSSTransitionActivated equal to true shall support the FT protocol.
10
11 The FT protocol supports resource requests as part of the reassociation. The optional FT resource request
12 protocol (see 13.6 (FT resource request protocol)) supports resource requests prior to reassociation.
13
14
15
A (#5070)STAFTO shall not use any authentication algorithm except the FT authentication algorithm when
16 using the FT protocol.
17
18 To prevent key reinstallation attacks, the non-AP STA shall maintain a copy of the most recent GTK, IGTK,
19 and BIGTK when present installed as part of the FT protocol as if they were installed as a result of receipt of
20
21
EAPOL-Key frames (see 12.7.7.4 (Group key handshake implementation considerations)) and shall refuse
22 to update a GTK, IGTK, or a BIGTK when the key to be set matches (#5070)anyeither one of these two keys
23 (see 6.3.19 (SetKeys)).
24
25 13.5.2 Over-the-air FT protocol authentication in an RSN
26
27
28 Change (including Figure 13-5 (Over-the-air FT protocol in an RSN(#5070)(#6700))) as
29 follows:
30
31
32 The over-the-air FT protocol in an RSN is shown in Figure 13-5 (Over-the-air FT protocol in an
33 RSN(#5070)(#6700)).
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59 Figure 13-5—Over-the-air FT protocol in an RSN(#5070)(#6700)
60
61
62
63 The FTO and APFTR(#5070) use the FT authentication sequence to specify the PMK-R1 security
64 association and to provide values of SNonce and ANonce that enable a liveness proof, replay protection, and
65

346 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 PTK separation. This exchange enables a fresh PTK to be computed in advance of reassociation. The
2 PTKSA is used to protect the subsequent reassociation transaction, including the optional RIC-Request.
3
4
5 To perform an over-the-air fast BSS transition to a target APFTR(#5070), the FTO and target
6 APFTR(#5070) shall perform the following exchange:
7
8
FTOTarget APFTR(#5070): Authentication-Request (FTAA, 0, RSNE[PMKR0Name], MDE,
9 FTE[SNonce, R0KH-ID], Basic Multi-Link element(#6700)(#5070))
10 Target APFTR(#5070)FTO: Authentication-Response (FTAA, Status, RSNE[PMKR0Name],
11 MDE, FTE[ANonce, SNonce, R1KH-ID, R0KH-ID], Basic Multi-Link element(#6700)(#5070))
12
13
14 where the Basic Multi-Link element is included when the target FTR is an AP MLD(#6700)(#5070).
15
16 The SME of the FTO initiates the authentication exchange, through the use of the MLME-
17 AUTHENTICATE.request primitive, and the SME of the APFTR(#5070) responds with an MLME-
18
19 AUTHENTICATE.response primitive. See 11.3.5 (Authentication and deauthentication). The MLME
20 primitives for Authentication when the FT authentication algorithm is selected use only authentication
21 transaction sequence number values 1 and 2.
22
23 In the Authentication-Request frame (#5070)that does not include the (#6700)Basic Multi-Link element, the
24
25 SA field of the message header shall be set to the MAC address of the FTO, and the DA field of the message
26 header shall be set to the BSSID of the target AP’s BSS. (#5070)In the Authentication-Request frame that
27 includes the (#6700)Basic Multi-Link element, the Address 1 (RA) field and the Address 2 (TA) field of the
28 message header shall be set as defined in 35.3.3 (Multi-link device addressing).
29
30
31 The elements in the frame, and their required contents, shall be as given in 13.8.2 (FT authentication
32 sequence: contents of first message).
33
34 If the contents of the MDE received by the APFTR(#5070) do not match the contents advertised in the
35 Beacon and Probe Response frames (#5070)if the FTR is an AP or in the Beacon and Probe Response
36
37 frames of any AP affiliated with the FTR if the FTR is an AP MLD, the APFTR(#5070) shall reject the
38 authentication request with status code STATUS_INVALID_MDE. If the Authentication-Request frame
39 contains an authentication algorithm equal to FT authentication and the contents of the RSNE do not
40 indicate a negotiated AKM for which the Authentication type column indicates FT authentication (see
41 Table 9-151 (AKM suite selectors)), the APFTR(#5070) shall reject the authentication request with status
42
43 code STATUS_INVALID_AKMP. If the FTE in the FT Request frame contains an invalid R0KH-ID, the
44 APFTR(#5070) shall reject the FT Request frame with status code STATUS_INVALID_FTE. If the RSNE
45 in the Authentication-Request frame contains an invalid PMKR0Name and the APFTR(#5070) has
46 determined that it is an invalid PMKR0Name, the APFTR(#5070) shall reject the authentication request
47 with status code STATUS_INVALID_PMKID. If the requested R0KH is not reachable, the APFTR(#5070)
48
49 shall respond to the authentication request with status code R0KH_UNREACHABLE. If the FTO selects a
50 pairwise cipher suite in the RSNE that is different from the ones used in the Initial mobility domain
51 association, then the APFTR(#5070) shall reject the authentication request with status code
52 STATUS_INVALID_PAIRWISE_CIPHER. Subsequent to a rejection of an authentication request, the FTO
53 may retry the authentication request.
54
55
56 In the Authentication-Response frame (#5070)that does not include the (#6700)Basic Multi-Link element,
57 the SA field of the message header shall be set to the BSSID of the target AP’s BSS, and the DA field of the
58 message header shall be set to the MAC address of the FTO. (#5070)In the Authentication-Response frame
59 that includes the (#6700)Basic Multi-Link element, the Address 1 (RA) field and the Address 2 (TA) field of
60
61 the message header shall be set as defined in 35.3.3 (Multi-link device addressing).
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 347

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The Status Code field shall be a value from the options listed in 9.4.1.9 (Status Code field). The elements in
2 the frame, and their required contents, shall be as given in 13.8.3 (FT authentication sequence: contents of
3
4 second message).
5
6 The R1KH of the target APFTR(#5070) uses the value of PMKR0Name and other information in the frame
7 to calculate PMKR1Name. If the target APFTR(#5070) does not have the key identified by PMKR1Name, it
8 may retrieve that key from the R0KH identified by the FTO. See 13.2 (Key holders). Upon receiving a new
9
10 PMK-R1 for a STAFTO(#5070), the target APFTR(#5070) shall delete the prior PMK-R1 security
11 association and PTKSAs derived from the prior PMK-R1.
12
13 The FTO and the target APFTR(#5070) compute the PTK and PTKName using the PMK-R1,
14 PMKR1Name, ANonce, and SNonce, as specified in 12.7.1.6.5 (PTK). The PTKSA shall be deleted by the
15
16 target APFTR(#5070) if it does not receive a Reassociation Request frame from the FTO within the
17 reassociation deadline timeout value.
18
19 If the FTO does not receive a response to the Authentication-Request frame, it may reissue the request
20 following the restrictions given for Authentication frames in 11.3 (STA authenticationAuthentication and
21
22 association(#2277)). If the Status Code field value returned by the target APFTR(#5070) is SUCCESS, the
23 FTO and target APFTR(#5070) transition to State 2 (as defined in 11.3 (STA authenticationAuthentication
24 and association(#2277))); the FTO may continue with reassociation (13.7.1 (FT reassociation in an RSN)).
25 Handling of errors returned in the Status Code field shall be as specified in 11.3 (STA
26 authenticationAuthentication and association(#2277)).
27
28
29
30
13.7 FT reassociation
31
32 13.7.1 FT reassociation in an RSN
33
34
35
Change as follows:
36
37 If the FTO does not send a Reassociation Request frame to the target APFTR(#5070) within the
38 reassociation deadline interval received during the FT initial mobility domain association, the target
39 APFTR(#5070) may delete the PTKSA, and the FTO shall abandon this transition attempt.
40
41
42 The FTO shall perform a reassociation directly with the target APFTR(#5070) via the following exchange:
43 FTOTarget APFTR(#5070): Reassociation Request(RSNE[PMKR1Name], MDE, FTE[MIC,
44 ANonce, SNonce, R1KH-ID, R0KH-ID], RIC-Request, RSNXE, Basic Multi-Link ele-
45
46 ment(#6700)(#5070))
47 Target APFTR(#5070)FTO: Reassociation Response(RSNE[PMKR1Name], MDE, FTE[MIC,
48 ANonce, SNonce, R1KH-ID, R0KH-ID, GTK[N], IGTK[M], BIGTK[Q], MLO GTKn, MLO
49
50
IGTKn, MLO BIGTKn(#5070)], RIC-Response, RSNXE, Basic Multi-Link ele-
51 ment(#6700)(#5070))
52
53 (#5070)where
54
55 — MLO GTKn is MLO GTK subelement for link n, MLO IGTKn is MLO IGTK subelement for link n,
56 and MLO BIGTKn is MLO BIGTK subelement for link n.
57 — The GTK[N], IGTK[M], and BIGTK[Q] are present when the FTR is an AP.
58
59 — The MLO GTKn, MLO IGTKn, MLO BIGTKn, and the (#6700)Basic Multi-Link element are pres-
60 ent when the FTR is an AP MLD.
61
62 The SME of the FTO initiates the reassociation through the use of the MLME-REASSOCIATE.request
63
64 primitive. The SME of the APFTR(#5070) responds to the indication with MLME-
65 REASSOCIATE.response primitive. See 11.3.6 (Association, reassociation, and disassociation).

348 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 In the Reassociation Request frame (#5070)that does not include the (#6700)Basic Multi-Link element, the
2 SA field of the message header shall be set to the MAC address of the FTO, and the DA field of the message
3
4 header shall be set to the BSSID of the target AP’s BSS. (#5070)In the Reassociation Request frame that
5 includes the (#6700)Basic Multi-Link element, the Address 1 (RA) field and the Address 2 (TA) field of the
6 message header shall be set as defined in 35.3.3 (Multi-link device addressing).
7
8 The elements in the frame, the element contents, and the MIC calculation shall be as given in 13.8.4 (FT
9
10 authentication sequence: contents of third message).
11
12 The R1KH of the target APFTR(#5070) verifies the MIC in the FTE in the Reassociation Request frame and
13 shall discard the request if the MIC is incorrect.
14
15
16 If the target (#5070)APFTR is an AP that includes an RSNXE in its Beacon and Probe Response frames and
17 the RSNXE Used subfield of the MIC Control field of the FTE is set to 1 (#5070)or if the target FTR is an
18 AP MLD and any AP affiliated with the AP MLD includes an RSNXE in its Beacon and Probe Response
19 frames and the RSNXE Used subfield of the MIC Control field of the FTE is set to 1, but the Reassociation
20 Request frame does not include an RSNXE, the R1KH of the target APFTR(#5070) shall discard the
21
22 request.
23
24 If dot11RSNAOperatingChannelValidationActivated is true and the FTO indicates OCVC capability, the
25 target AP shall ensure that OCI subelement of the FTE matches by ensuring that all of the following are true:
26
27 — OCI subelement is present
28 — Channel information in the OCI matches current operating channel parameters (see
29 12.2.9 (Requirements for Operating Channel Validation)
30
31
32 Otherwise, the AP shall reject the Reassociation Request frame with status code STATUS_INVALID_FTE.
33
34 If the contents of the MDE received by the target APFTR(#5070) do not match the contents advertised in the
35 Beacon and Probe Response frames (#5070)if the FTR is an AP or in the Beacon and Probe Response
36
37 frames of any APs affiliated with the FTR if the FTR is an AP MLD, the target APFTR(#5070) shall reject
38 the Reassociation Request frame with status code STATUS_INVALID_MDE. If the FTE in the
39 Reassociation Request frame contains a different R0KH-ID, R1KH-ID, ANonce, or SNonce, the
40 APFTR(#5070) shall reject the Reassociation Request frame with status code STATUS_INVALID_FTE. If
41 the RSNE in the Reassociation Request frame contains an invalid PMKR1Name, the APFTR(#5070) shall
42
43 reject the Reassociation Request frame with status code STATUS_INVALID_PMKID.
44
45 In the Reassociation Response frame (#5070)that does not include the (#6700)Basic Multi-Link element, the
46 SA field of the message header shall be set to the BSSID of the target AP’s BSS, and the DA field of the
47 message header shall be set to the MAC address of the FTO. (#5070)In the Reassociation Response frame
48
49 that includes the (#6700)Basic Multi-Link element, the Address 1 (RA) field and the Address 2 (TA) field of
50 the message header shall be set as defined in 35.3.3 (Multi-link device addressing).
51
52 The Status Code field shall be a value from the options listed in 9.4.1.9 (Status Code field). The elements in
53 the frame, the element contents, and the MIC calculation shall be as given in 13.8.5 (FT authentication
54
55 sequence: contents of fourth message).
56
57 The S1KH of the FTO verifies the MIC in the FTE in the Reassociation Response frame and shall discard
58 the response if the MIC is incorrect.
59
60
61 If in the Reassociation Response frame the RSNE fields other than the PMKID Count field and the PMKID
62 List field are not identical to the corresponding RSNE fields in the Beacon and Probe Response frames
63 received from the target (#5070)APFTR if the FTR is an AP or if in the Reassociation Response frame the
64 RSNE fields other than the PMKID Count field and the PMKID List field of each link are not identical to the
65

Copyright © 2022 IEEE. All rights reserved. 349

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 corresponding RSNE fields of the link in the Beacon and Probe Response frames received from any AP
2 affiliated with the FTR if the FTR is an AP MLD, the S1KH of the FTO shall discard the response. If the
3
4 PMKID List field does not include the correct PMKR1Name value, the S1KH of the FTO shall discard the
5 response.
6
7 If the Beacon and Probe Response frames received from the target (#5070)APFTR if the FTR is an AP or
8 Beacon and Probe Response frames received from an AP affiliated with the target FTR if the FTR is an AP
9
10 MLD did not include an RSNXE, but the RSNXE Used subfield of the MIC Control field of the FTE is set to
11 1, the S1KH of the FTO shall discard the response.
12
13 If the Reassociation Response frame includes the RSNXE, the S1KH of the FTO shall verify that this
14 element matches information included in the Beacon and Probe Response frames received from the target
15
16 (#5070)APFTR if the FTR is an AP or in the Beacon and Probe Response frames received from any AP
17 affiliated with the target FTR if the FTR is an AP MLD. If those frames did not include the RSNXE or if the
18 contents of the RSNXE are not identical, the S1KH of the FTO shall discard the response.
19
20 If dot11RSNAOperatingChannelValidationActivated is true and the target AP indicates OCVC capability,
21
22 FTO shall ensure that OCI subelement of the FTE matches by ensuring that all of the following are true
23 — OCI subelement is present
24
25 — Channel information in the OCI matches current operating channel parameters (see
26 12.2.9 (Requirements for Operating Channel Validation))
27
28 Otherwise, the FTO (#5070)rejects the Reassociation Response frame by discarding the frame.
29
30
31 If an FTO is performing a reassociation exchange as part of the FT resource request protocol, then the FTO
32 shall not include the RIC-Request in the Reassociation Request frame, and the AP shall not include the RIC-
33 Response in the Reassociation Response frame. If the reassociation exchange is part of the FT resource
34 request protocol and the AP is unable to honor the resources that have been placed in the accepted state for
35 that FTO, then the AP shall reject the Reassociation Request frame and may use status code
36
37 DENIED_INSUFFICIENT_BANDWIDTH.
38
39 If the FTO did not utilize the FT resource request protocol, the FTO may make a request for resources by
40 including a RIC-Request (see 13.11 (Resource request procedures)) in the Reassociation Request frame. The
41 RIC-Request is generated by the procedures of 13.11.3.1 (FTO procedures), and the RIC-Response is
42
43 generated by the procedures of 13.11.3.2 (AP procedures).
44
45 If the Status Code field value returned by the target (#5070)APFTR in the response is
46 REFUSED_REASON_UNSPECIFIED, TRANSACTION_SEQUENCE_ERROR, or
47 REJECTED_SEQUENCE_TIMEOUT, then the FTO shall abandon this transition attempt. Handling of
48
49 other errors returned in the Status Code field shall be as specified in 11.3 (STA authenticationAuthentication
50 and association(#2277)).
51
52 Upon a successful reassociation, the PTKSA has been established and proven live. The SME of the
53 (#5070)APFTR shall open the IEEE 802.1X Controlled Port. The FTO shall transition to State 4 (as defined
54
55 in 11.3 (STA authenticationAuthentication and association(#2277))). If the target (#5070)APFTR is distinct
56 from the previous (#5070)APFTR, the FTO shall enter State 1 with respect to the previous (#5070)APFTR.
57
58 Upon a successful reassociation, the FTO shall delete any corresponding PTKSA with its previous
59 (#5070)APFTR. The SME of the FTO shall issue an MLME-DELETEKEYS.request primitive to delete the
60
61 pairwise keys with the previous (#5070)APFTR, and the FTO and the (#5070)APFTR shall issue an MLME-
62 SETKEYS.request primitive and MLME-SETPROTECTION.request primitive to install the pairwise keys.
63 The PTK lifetime timer shall be initialized with the value calculated as the difference between the
64
65

350 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 TIE[KeyLifetime] sent in message 3 of the FT initial mobility domain association and the time since the
2 completion of the FT 4-way handshake during the FT initial mobility domain association.
3
4
5 When the IEEE 802.1X Controlled Port is opened, the EAPOL-Key frame replay counter shall be initialized
6 to 0. The R1KH shall increment the key replay counter on each successive EAPOL-Key frame that it
7 transmits.
8
9
10 13.8 FT authentication sequence
11
12
13 13.8.1 Overview
14
15 Change (including Table 13-1 (FT authentication elements)) as follows:
16
17
18
The FT authentication sequence comprises four sets of FT elements. Each set of FT elements is referred to in
19 13.8 (FT authentication sequence) as a message. These messages are included in the FT Protocol frames or
20 FT Resource Request Protocol frames to initiate a fast BSS transition. The FT authentication sequence is
21 always initiated by the FTO and responded to by the target (#5070)APFTR.
22
23
24
In an RSN, the first two messages in the sequence allow the FTO and target (#5070)APFTR to provide
25 association instance identifiers, SNonce and ANonce, respectively. SNonce and ANonce are chosen
26 randomly or pseudorandomly and are used to generate a fresh PTK. The first two messages also enable the
27 target (#5070)APFTR to provision the PMK-R1 and the FTO and target (#5070)APFTR to compute the
28 PTK. The third and fourth messages demonstrate liveness of the peer, authenticate the elements, and enable
29
30
an authenticated resource request.
31
32 When an FTO invokes the FT protocol, then the first two messages of the sequence are both carried in
33 Authentication frames or both carried in Action frames, and these messages are described in 13.8.2 (FT
34 authentication sequence: contents of first message) and 13.8.3 (FT authentication sequence: contents of
35
36
second message). The third and fourth messages in the sequence are carried in the Reassociation Request
37 and Reassociation Response frames and are described in 13.8.4 (FT authentication sequence: contents of
38 third message) and 13.8.5 (FT authentication sequence: contents of fourth message).
39
40 When the FTO invokes the FT resource request protocol, then the first four messages of the sequence are all
41
42
carried in Authentication frames or all carried in Action frames, and these messages are described in 13.8.2
43 (FT authentication sequence: contents of first message) to 13.8.5 (FT authentication sequence: contents of
44 fourth message). The fifth and sixth frames of the FT resource request protocol are carried in the
45 Reassociation Request frame and Reassociation Response frame and are described in 13.8.4 (FT
46 authentication sequence: contents of third message) and 13.8.5 (FT authentication sequence: contents of
47
48
fourth message).
49
50 Regardless of the transport mechanism, the information contained in the FT authentication sequence
51 consists of the set of elements shown in Table 13-1 (FT authentication elements).
52
53
54
The first message is used by the FTO to initiate a fast BSS transition. When RSNA is enabled, the FTO shall
55 include the R0KH-ID and the SNonce in the FTE and the PMKR0Name in the RSNE. The target
56 (#5070)APFTR can use the PMKR0Name to derive the PMKR1Name, and if the target (#5070)APFTR does
57 not have the PMK-R1 identified by PMKR1Name, it may attempt to retrieve that key from the R0KH
58 identified by R0KH-ID. See 13.2 (Key holders). The FTO includes a fresh SNonce as its contribution to the
59
60
association instance identifier and to provide key separation of the derived PTK; it is selected randomly to
61 serve as a challenge that demonstrates the liveness of the peer in the fourth message.
62
63 The second message is used by the target (#5070)APFTR to respond to the requesting FTO. The target
64 (#5070)APFTR provides the key holder identifiers and key names used to generate the PTK. The target
65

Copyright © 2022 IEEE. All rights reserved. 351

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 13-1—FT authentication elements

2
3
4 Information Presence in Authentication Sequence messages Description
5
6 RSN The RSNE is present if dot11RSNAActivated is true. 9.4.2.24 (RSNE)
7
8 Mobility Domain The Mobility Domain element is present. 9.4.2.46 (Mobility
9 Domain element
10 (MDE))
11
12 Fast BSS Transition The Fast BSS Transition element is present if 9.4.2.47 (Fast BSS
13 dot11RSNAActivated is true. Transition element
14 (FTE))
15
Timeout Interval The Timeout Interval element is optionally present in the 9.4.2.48 (Timeout
16
(reassociation fourth message of the sequence if dot11RSNAActivated is not Interval element
17
deadline) true. (TIE))
18
19 RIC The RIC Data element is optionally present in the third and 9.4.2.49 (RIC Data
20 fourth messages. element (RDE))
21
22 RSNXE (#5070)The RSNXE is present in the third message if an 9.4.2.241 (RSN
23 RSNXE is present in a Beacon or Probe Response frame that Extension element
24 the FTO has received from the target AP or an AP affiliated (RSNXE))
25 with the target AP MLD and the FTO set to 1 any subfield,
26 except the Field Length subfield, of the Extended RSN
27 Capabilities field in this element, and is present in the fourth
28 message if an RSNXE was present in the third message and
29 the target AP or an AP affiliated with the target AP MLD set
30 to 1 any subfield, except the Field Length subfield, of the
31 Extended RSN Capabilities field in this element.
32
33
34
35 (#5070)APFTR also includes a fresh ANonce as its contribution to the association instance identifier and to
36 provide key separation of the derived PTK. The response includes a status code.
37
38 In an RSN, the third message is used by the FTO to assert to the target (#5070)APFTR that it has a valid
39
40 PTK. If no resources are required, then the FTO omits inclusion of the RIC.
41
42 The fourth message is used by the target (#5070)APFTR to respond to the requesting FTO. This message
43 serves as final confirmation of the transition, establishes that the (#5070)APFTR possesses the PMK-R1 and
44 is participating in this association instance, and protects against downgrade attacks. Note, however, that the
45
46 RIC is absent if no resources were requested in the third message. This also includes a status code and may
47 include a reassociation deadline.
48
49 (#5919)If the requesting FTO is an non-AP MLD, the target FTR is an AP MLD, and the first message is
50 sent over the air, the following apply:
51
52 — the third message sent over the air shall have the value of the Address 1 field equal to the value of the
53 Address 1 field of the first message and the value of the Address 2 field equal to the value of the
54 Address 2 field of the first message
55
56 — the second and fourth message sent over the air shall have the value of the Address 1 field equal to
57 the value of the Address 2 field of the first message and the value of the Address 2 field equal to the
58 value of the Address 1 field of the first message.
59
60
61 13.8.2 FT authentication sequence: contents of first message
62
63 Change as follows:
64
65

352 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 If present, the RSNE shall be set as follows:

2
3 — Version field shall be set to 1.
4 — PMKID Count field shall be set to 1.
5
6 — PMKID List field shall contain the PMKR0Name.
7 — All other fields shall be as specified in 9.4.2.24 (RSNE) and 12.6.3 (RSNA policy selection in an
8 infrastructure BSS).
9
10
11 The MDE shall contain the MDID field and the FT Capability and Policy field settings obtained from the
12 target AP (#5070)or any AP affiliated with the target AP MLD, as advertised by the target AP (#5070)or any
13 AP affiliated with the target AP MLD in Beacon and Probe Response frames. The MDID shall be identical
14 to that obtained during the FT initial mobility domain association exchange.
15
16
17 If present, the FTE shall be set as follows:
18 — R0KH-ID shall be the value of R0KH-ID obtained by the FTO during its FT initial mobility domain
19
20
association exchange.
21 — SNonce shall be set to a value chosen randomly by the FTO, see 12.7.5 (Nonce generation) for a
22 recommended procedure.
23
24 — All other fields shall be set to 0.
25
26 13.8.3 FT authentication sequence: contents of second message
27
28
29
Change as follows:
30
31 If the status code is SUCCESS, then the following rules apply.
32
33 If present, the (#5070)RSNE(s) shall be set as follows:
34
35 — Version field shall be set to 1.
36 — PMKID Count field shall be set to 1.
37
38 — PMKID List field shall be set to the value contained in the first message of this sequence.
39 — All other fields shall be identical to the contents of the RSNE advertised by the AP (#5070)or the AP
40
41
affiliated with the AP MLD in Beacon and Probe Response frames.
42
43 The MDE shall contain the MDID and FT Capability and Policy fields. This element shall be the same as the
44 MDE advertised by the target AP (#5070)or any AP affiliated with the AP MLD in Beacon and Probe
45 Response frames.
46
47
48 If present, the FTE shall be set as follows:
49 — R0KH-ID shall be identical to the R0KH-ID provided by the FTO in the first message.
50
51 — R1KH-ID shall be set to the R1KH-ID of the target (#5070)APFTR, from dot11FTR1KeyHolderID.
52 — ANonce shall be set to a value chosen randomly by the target (#5070)APFTR, see 12.7.5 (Nonce
53 generation) for a recommended procedure.
54
55 — SNonce shall be set to the value contained in the first message of this sequence.
56 — All other fields shall be set to 0.
57
58
59 13.8.4 FT authentication sequence: contents of third message
60
61 Change as follows:
62
63
64 If present, the RSNE shall be set as follows:
65

Copyright © 2022 IEEE. All rights reserved. 353

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — Version field shall be set to 1.

2
3 — PMKID Count field shall be set to 1.
4 — PMKID List field shall contain the PMKR1Name.
5
6 — All other fields shall be as specified in 9.4.2.24 (RSNE) and 12.6.3 (RSNA policy selection in an
7 infrastructure BSS).
8
9 The MDE shall contain the MDID and FT Capability and Policy fields. This element shall be identical to the
10
11
MDE contained in the first message of this sequence.
12
13 If present, the FTE shall be set as follows:
14 — ANonce, SNonce, R0KH-ID, and R1KH-ID shall be set to the values contained in the second
15
16 message of this sequence.
17 — The Element Count subfield of the MIC Control field shall be set to the number of elements
18 protected in this frame (variable).
19
20 — The RSNXE Used subfield of the MIC Control field shall be set to 1 if the FTO set to 1 any subfield,
21 except the Field Length subfield, of the Extended RSN Capabilities field in the RSNXE; otherwise
22 this subfield shall be set to 0.
23
24 — When the negotiated AKM is 00-0F-AC:3, 00-0F-AC:4, or 00-0F-AC:9, the MIC shall be calculated
25 using the KCK and the AES-128-CMAC algorithm. The output of the AES-128-CMAC shall be 128
26 bits.
27
28 — When the negotiated AKM is 00-0F-AC:13, the MIC shall be calculated using the KCK and the
29 HMAC-SHA-384 algorithm. The output of the HMAC-SHA-384 shall be truncated to 192 bits.
30 — When the negotiated AKM is 00-0F-AC:16, the MIC shall be calculated using the KCK2 and the
31
32
AES-128-CMAC algorithm. The output of the AES-128-CMAC shall be 128 bits.
33 — When the negotiated AKM is 00-0F-AC:17, the MIC shall be calculated using the KCK2 and the
34 HMAC-SHA-384 algorithm. The output of the HMAC-SHA-384 shall be truncated to 192 bits.
35
36 — If dot11RSNAOperatingChannelValidationActivated is true and Authenticator indicates OCVC
37 capability, the supplicant shall include FT OCI subelement in FTE.
38 — The MIC shall be calculated on the concatenation of the following data, in the order given here:
39
40 — FTO’s MAC address (6 octets)
41 — Target (#5070)AP’sFTR’s MAC address (6 octets)
42
43 — Transaction sequence number (1 octet), which shall be set to the value 5 if this is a
44 Reassociation Request frame and, otherwise, set to the value 3
45
46 — RSNE
47 — MDE
48
49 — FTE, with the MIC field of the FTE set to 0
50 — Contents of the RIC-Request (if present)
51
52 — RSNXE (if present)
53 — (#5070)Non-AP STA MAC address corresponding to all the requested links in increasing
54 order of link ID if (#6700)Basic Multi-Link element is included in the Reassociation Request
55
56
frame
57 — All other fields shall be set to 0.
58
59 If resources are being requested by the FTO, then a sequence of elements forming the RIC-Request shall be
60
61 included.
62
63 The RSNXE shall be present if an RSNXE was present in a Beacon or Probe Response frame that the FTO
64 has received from the target (#5070)APFTR if the FTR is an AP or an AP affiliated with the target FTR if
65

354 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 the FTR is an AP MLD and the FTO set to 1 any subfield, except the Field Length subfield, of the Extended
2 RSN Capabilities field in this element.
3
4
5 13.8.5 FT authentication sequence: contents of fourth message
6
7 Change as follows:
8
9
10 If the status code is SUCCESS, then the following rules apply.
11
12 If present, the (#5070)RSNE(s) shall be set as follows:
13
14
— Version field shall be set to 1.
15 — PMKID Count field shall be set to 1.
16
17
— PMKID List field shall contain the PMKR1Name
18 — All other fields shall be identical to the contents of the RSNE advertised by the target
19 (#5070)APFTR if the FTR is an AP or an AP affiliated with the target FTR if the FTR is an AP
20 MLD in Beacon and Probe Response frames.
21
22
23 The MDE shall contain the MDID and FT Capability and Policy fields. This element shall be identical to the
24 MDE contained in the second message of this sequence.
25
26 If present, the FTE shall be set as follows:
27
28 — ANonce, SNonce, R0KH-ID, and R1KH-ID shall be set to the values contained in the second
29 message of this sequence.
30
31 — The Element Count subfield of the MIC Control field shall be set to the number of elements
32 protected in this frame (variable).
33 — The RSNXE Used subfield of the MIC Control field shall be set to 1 if the target AP (#5070)or an
34
35
AP affiliated with the target AP MLD includes an RSNXE in its Beacon and Probe Response
36 frames; otherwise this subfield shall be set to 0.
37 — If dot11RSNAOperatingChannelValidationActivated is true and Supplicant indicates OCVC
38 capability, the Authenticator shall include FT OCI subelement in FTE.
39
40 — When this message of the authentication sequence appears in a Reassociation Response frame, the
41 Optional Parameter(s) field in the FTE may include the GTK, IGTK and BIGTK subelements
42 (#5070)or MLO GTK, MLO IGTK, and MLO BIGTK subelements. If a GTK, an IGTK(#5070), or
43
44
a BIGTK, an MLO GTK, an MLO IGTK, or an MLO BIGTK are included, the Key field of the
45 subelement shall be wrapped using KEK or KEK2 and the appropriate key wrap algorithm, as
46 specified in Table 12-10 (Integrity and key wrap algorithms) and 12.7.2 (EAPOL-Key frames). The
47 padding consists of appending a single octet 0xdd followed by zero or more 0x00 octets. When
48 processing a received message, the receiver shall ignore this trailing padding. Addition of padding
49
50
does not change the value of the Key Length field. Note that the length of the encrypted Key field
51 can be determined from the length of the GTK, IGTK(#5070), or BIGTK, MLO GTK, MLO IGTK,
52 or MLO BIGTK subelement.
53 — When the negotiated AKM is 00-0F-AC:3, 00-0F-AC:4, or 00-0F-AC:9, the MIC shall be calculated
54
55 using the KCK and the AES-128-CMAC algorithm. The output of the AES-128-CMAC algorithm
56 shall be 128 bits.
57 — When the negotiated AKM is 00-0F-AC:13, the MIC shall be calculated using the KCK and the
58
59
HMAC-SHA-384 algorithm. The output of the HMAC-SHA-384 shall be truncated to 192 bits.
60 — When the negotiated AKM is 00-0F-AC:16, the MIC shall be calculated using the KCK2 and the
61 AES-128-CMAC algorithm. The output of the AES-128-CMAC shall be 128 bits.
62
63 — When the negotiated AKM is 00-0F-AC:17, the MIC shall be calculated using the KCK2 and the
64 HMAC-SHA-384 algorithm. The output of the HMAC-SHA-384 shall be truncated to 192 bits.
65

Copyright © 2022 IEEE. All rights reserved. 355

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — The MIC shall be calculated on the concatenation of the following data, in the order given here:
2
3 — FTO’s MAC address (6 octets)
4 — Target (#5070)AP’sFTR’s MAC address (6 octets)
5
6 — Transaction sequence number (1 octet), which shall be set to the value 6 if this is a
7 Reassociation Response frame or, otherwise, set to the value 4
8 — RSNE (#5070)(#6700)if Basic Multi-Link element is not included in the Reassociation
9
10 Response frame
11 — (#5070)(#6700)RSNEs corresponding to all (#5920)requested links in increasing order of link
12 ID if Basic Multi-Link element is included in the Reassociation Response frame
13
14 — MDE
15 — FTE, with the MIC field of the FTE set to 0
16
17 — Contents of the RIC-Response (if present)
18 — RSNXE (if present) (#5070)(#6700)if Basic Multi-Link element is not included in the
19
20
Reassociation Response frame
21 — (#5070)(#6700)RSNXEs (if present) corresponding to all (#5920)requested links in increasing
22 order of link ID if Basic Multi-Link element is included in the Reassociation Response frame
23
24 — (#5070)(#6700)AP MAC address corresponding to all (#5920)requested links in increasing
25 order of link ID if Basic Multi-Link element is included in the Reassociation Response frame
26 — All other fields shall be set to 0.
27
28
29 If this message is other than a Reassociation Response frame and dot11RSNAActivated is false, a TIE may
30 appear. If this message is other than a Reassociation Response frame, includes a RIC-Response, and
31 dot11RSNAActivated is false, then a timeout interval shall appear. If it appears, it shall be set as follows:
32
33 — Timeout Interval Type field shall be set to 1 (reassociation deadline)
34 — Timeout Interval Value field shall be set to the reassociation deadline time.
35
36
37 If resources were requested by the FTO, then a RIC-Response shall be included.
38
39 The RSNXE shall be present if an RSNXE was present in the third message and the target (#5070)APFTR if
40 the FTR is an AP or an AP affiliated with the target FTR if the FTR is an AP MLD set to 1 any subfield,
41 except the Field Length subfield, of the Extended RSN Capabilities field in this element.
42
43
44
45
13.9 FT security architecture state machines
46
47 13.9.1 Introduction
48
49 Change as follows:
50
51
52 The interactions between the R0KH and IEEE Std 802.1X, between the R1KH and IEEE Std 802.1X, and
53 between the S1KH and IEEE Std 802.1X occur within the SME. At both the target (#5070)APFTR and at
54 the FTO, the R1KH and S1KH initialize the IEEE 802.1X EAPOL state machines in the respective SMEs.
55 The Controlled Port is opened without an EAP exchange when the reassociation completes.
56
57
58 13.9.5 S1KH state machine
59
60 13.9.5.3 S1KH state machine variables
61
62
63
Change the third item of the first paragraph as follows (not all items shown):
64
65

356 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The following list summarizes the variables used by the S1KH state machine:
2
3 — …
4 — Init – This variable is set to true to initialize the S1KH state machine. In addition, this variable is
5 used to restart the state machine when transitioning to a new (#5070)APFTR.
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 357

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 17. Orthogonal frequency division multiplexing (OFDM) PHY specification

2
3
4
5
17.2 OFDM PHY specific service parameter list
6
7 17.2.2 TXVECTOR parameters
8
9 17.2.2.1 General
10
11
12 Change Table 17-1 (TXVECTOR parameters) as follows:
13
14
15 Table 17-1—TXVECTOR parameters
16
17
18 Parameter Associated primitive Value
19
20 CH_BANDWIDTH_ PHY-TXSTART.request Not present if neither dot11VHTOptionImplemented nor
21 IN_NON_HT (TXVECTOR) dot11HEOptionImplemented is present or equal to true.
22
23 Optionally present (see 9.3.1 (Control frames)) if at least one
24 of dot11VHTOptionImplemented and
25 dot11HEOptionImplemented is present and equal to true.
26
27 If dot11EHTOptionImplemented is not present or equal to
28 false, then the allowed values areIf present, CBW20,
29 CBW40, CBW80, CBW160, or CBW80+80.
30
31 If dot11EHTOptionImplemented is equal to true and the
32 STA is not a STA 6G or the STA is a STA 6G without
33 320 MHz bandwidth support, then the allowed values are
34 CBW20, CBW40, CBW80, or CBW160.
35
36 If dot11EHTOptionImplemented is equal to true and the
37 STA is a STA 6G with 320 MHz bandwidth support, then the
38 allowed values are CBW20, CBW40, CBW80, CBW160, or
39 CBW320.
40
41 DYN_BANDWIDTH PHY-TXSTART.request If present, Static or Dynamic
42 _IN_NON_HT (TXVECTOR)
43 Not present if neither dot11VHTOptionImplemented nor
44 dot11HEOptionImplemented is present or equal to true.
45
46 Optionally present (see 9.3.1 (Control frames)) if at least one
47 of dot11VHTOptionImplemented and
48 dot11HEOptionImplemented is present and equal to true,
49 then the allowed values are Static or Dynamic.
50
51
52
53 17.2.2.7 TXVECTOR CH_BANDWIDTH_IN_NON_HT
54
55 Change the first paragraph as follows.
56
57
58
If present, the allowed values for CH_BANDWIDTH_IN_NON_HT are CBW20, CBW40, CBW80,
59 CBW160, and CBW80+80, and CBW320. If present, this parameter is used to modify the first 7 bits of the
60 scrambling sequence and B7 of the SERVICE field for CBW320 in the 6 GHz band(#4893) to indicate the
61 bandwidth of the non-HT duplicate PPDU.
62
63
64
65

358 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 17.2.3 RXVECTOR parameters

2
3
4 17.2.3.1 General
5
6 Change Table 17-2 (RXVECTOR parameters) as follows:
7
8
9 Table 17-2—RXVECTOR parameters
10
11
12 Parameter Associated primitive Value
13
14 CH_BANDWIDTH PHY-RXSTART.request Not present if neither dot11VHTOptionImplemented nor
15 _IN_NON_HT (RXVECTOR) dot11HEOptionImplemented is present or equal to true.
16
17 Present if at least one of dot11VHTOptionImplemented
18 and dot11HEOptionImplemented is present and equal to
19 true.
20
21 If dot11EHTOptionImplemented is not present or equal
22 to false, then the allowed values areIf present, CBW20,
23 CBW40, CBW80, CBW160, or CBW80+80.
24
25 If dot11EHTOptionImplemented is equal to true and the
26 STA is not a STA 6G(#4147), then the allowed values
27 are CBW20, CBW40, CBW80, or CBW160.
28
29 If dot11EHTOptionImplemented is equal to true and the
30 STA is a STA 6G(#4147), then the allowed values are
31 CBW20, CBW40, CBW80, CBW160, or CBW320.
32
33 DYN_BANDWIDTH PHY-RXSTART.request If present, Static or Dynamic
34 _IN_NON_HT (RXVECTOR)
35 Not present if neither dot11VHTOptionImplemented nor
36 dot11HEOptionImplemented is present or equal to true.
37
38 Present if at least one of dot11VHTOptionImplemented
39 and dot11HEOptionImplemented is present and equal to
40 true, then the allowed values are Static or Dynamic.
41
42
43
44 17.3 OFDM PHY
45
46
47
17.3.5 DATA field
48
49 17.3.5.2 SERVICE field
50
51
52
Change the paragraph and replace Figure 17-6 (SERVICE field bit assignment) as follows:
53
54 The SERVICE field has 16 bits, which shall be denoted as bits 0–15. The bit 0 shall be transmitted first in
55 time. The bits from 0–6 of the SERVICE field, which are transmitted first, are set to 0s and are used to
56 synchronize the descrambler in the receiver. If the CH_BANDWIDTH_IN_NON_HT parameter in the
57
58
TXVECTOR primitive is not present or is present and is equal to CBW20, CBW40, CBW80, CBW160, or
59 CBW80+80, then bit 7 of the SERVICE field is set to 0. If the CH_BANDWIDTH_IN_NON_HT parameter
60 in the TXVECTOR primitive is present and is equal to CBW320, then bit 7 of the SERVICE field is set to 1.
61 The remaining 98 bits (78–15) of the SERVICE field shall be reserved for future use. All reserved bits shall
62 be set to 0 on transmission and ignored on reception. Refer to Figure 17-6 (SERVICE field bit assignment).
63
64
65

Copyright © 2022 IEEE. All rights reserved. 359

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2
3
4 Condition Scrambler initialization Remaining SERVICE bits
5
6 A “0” “0” “0” “0” “0” “0” “0” R R R R R R R R R
7
B If TX:
8
Bit 2 of
9
CBINH
10
If RX:
11
Bit 2 of
12
CBINHI
13
14 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
15
16 Transmit order 
17
18 R: reserved
19
20 CBINH: CH_BANDWIDTH_ IN_NON_HT
21
22
CBINHI: CH_BANDWIDTH_ IN_NON_HT_INDICATOR
23
24
25 A: All cases except those that match condition B
26
27 B: CH_BANDWIDTH_ IN_NON_HT is present, dot11EHTOptionImplemented is equal to true and the STA is a STA
28 6G with 320 MHz bandwidth support
29
30
31
32
33
34 Figure 17-6—SERVICE field bit assignment
35
36
37 17.3.5.5 PHY DATA scrambler and descrambler
38
39 Change the fifth paragraph, Table 17-7 (Contents of the first 7 bits of the scrambling sequence),
40
41 Table 17-8 (TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT values), and Table 17-9
42 (RXVECTOR parameter CH_BANDWIDTH_IN_NON_HT values for a VHT or HE STA) as
43 follows:
44
45
46 During reception by a VHT STA, HE(#5549) STA, or EHT STA that is not a STA 6G(#4147), RXVECTOR
47 parameter CH_BANDWIDTH_IN_NON_HT shall be determined from selected bits in the scrambling
48 sequence as shown in Table 17-7 (Contents of the first 7 bits of the scrambling sequence) and Table 17-9
49 (RXVECTOR parameter CH_BANDWIDTH_IN_NON_HT values for a VHT or HE STA).
50
51
52 (#5549)During reception by an EHT STA that is a STA 6G(#4147), the RXVECTOR parameter
53 CH_BANDWIDTH_IN_NON_HT shall be determined from selected bits in the scrambling sequence as
54 shown in Figure 17-6 (SERVICE field bit assignment), Table 17-7 (Contents of the first 7 bits of the
55 scrambling sequence), and Table 17-9a (RXVECTOR parameter CH_BANDWIDTH_IN_NON_HT values
56 for an EHT STA).
57
58
59
60
61 During reception by a VHT STA, HE STA or EHT STA(#5549), the RXVECTOR parameter
62 DYN_BANDWIDTH_IN_NON_HT shall be set to selected bits in the scrambling sequence as shown in
63
64 Table 17-7 (Contents of the first 7 bits of the scrambling sequence). The fields shall be interpreted as being
65 sent LSB-first.

360 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 17-7—Contents of the first 7 bits of the scrambling sequence

2
3
4 First 7 bits of scrambling sequence
5
6 B0 B3 B4 B5 B6
7 Parameter Condition
8
9 Transmit order
10
11 TXVECTOR CH_BANDWIDTH_I 5-bit pseudorandom nonzero integer if Bits 0 and 1 of
12 N_NON_HT is CH_BANDWIDTH_IN_NON_HT equals CBW20 CH_BANDWIDTH_
13 present and or CBW320 and a 5-bit pseudorandom integer IN_NON_HT
14 DYN_BANDWIDTH otherwise
15 _IN_NOT_HT is not
16 present in
17 TXVECTOR
18
19 TXVECTOR CH_BANDWIDTH_I 4-bit pseudorandom DYN_BANDWIDTH
20 N_NON_HT is nonzero integer if _IN_NON_HT
21 present and CH_BANDWIDTH_IN_
22 DYN_BANDWIDTH NON_HT equals CBW20
23 _IN_NOT_HT is or CBW320 and
24 present in DYN_BANDWIDTH_IN
25 TXVECTOR _NON_HT equals Static,
26 and a 4-bit pseudorandom
27 integer otherwise
28
29 RXVECTOR CH_BANDWIDTH_I — DYN_BANDWIDTH Bits 0 and 1 of
30 N_NON_HT and _IN_NON_HT CH_BANDWIDTH_
31 DYN_BANDWIDTH IN_NON_HT_INDI
32 _IN_NOT_HT are CATOR (see
33 present in Table 17-9
34 RXVECTOR (RXVECTOR
35 parameter
36 CH_BANDWIDTH_
37 IN_NON_HT values
38 for a VHT or HE
39 STA)).
40
41
42 Table 17-8—TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT values
43
44
45 Value in bits 0 and
46 Value in bit 2 of
1 of
47 Enumerated value Value CH_BANDWIDT
CH_BANDWIDT
48 H_IN_NON_HT
H_IN_NON_HT
49
50 CBW20 0 0 0
51
52 CBW40 1 1 0
53
54 CBW80 2 2 0
55
56 CBW160 or CBW80+80 3 3 0
57
CBW320 4 0 1
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 361

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 17-9—RXVECTOR parameter CH_BANDWIDTH_IN_NON_HT values for a VHT or HE

2 STA
3
4
5 CH_BANDWIDTH_IN_NO
6 N_HT_INDICATOR field dot11CurrentChannelCenter RXVECTOR parameter
7 of first 7 bits of scrambling FrequencyIndex1 CH_BANDWIDTH_IN_NON_HT
8 sequence
9
10 0 0 CBW20
11
12 1 0 CBW40
13
14 2 0 CBW80
15
16 3 0 CBW160
17
3 1 to 200 CBW80+80
18
19
20
21 Insert the following paragraph and Table 17-9a after the fifth paragraph (“During reception by
22
23 a VHT...”):
24
25
26 Table 17-9a—RXVECTOR parameter CH_BANDWIDTH_IN_NON_HT values for an EHT STA
27
28
29 Bits 0 and 1 of
Bit 2 of
30 CH_BANDWIDTH_IN_NO
CH_BANDWIDTH_IN_NO RXVECTOR parameter
31 N_HT_INDICATOR field
N_HT_INDICATOR field CH_BANDWIDTH_IN_NON_HT
32 of first 7 bits of scrambling
(B7 in SERVICE field)
33 sequence
34
35 0 0 CBW20
36
37 1 0 CBW40
38
2 0 CBW80
39
40 3 0 CBW160
41
42 0 1 CBW320
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

362 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 26. High efficiency (HE) MAC specification

2
3
4 26.2 HE channel access
5
6
7 26.2.6 MU-RTS Trigger/CTS frame exchange procedure
8
9
26.2.6.3 CTS frame response to an MU-RTS Trigger frame
10
11
12 Change the first two paragraphs as follows:
13
14
15
If a non-AP STA receives an MU-RTS Trigger frame, the non-AP STA shall commence the transmission of
16 a CTS frame response at the SIFS time boundary after the end of a received PPDU (#7778)whenif the non-
17 AP STA is not NSTR limited and all of the following conditions are met:
18
19
— The MU-RTS Trigger frame has one of the User Info fields addressed to the non-AP STA. The User
20 Info field is addressed to a non-AP STA if the AID12 subfield is equal to the 12 LSBs of the AID of
21 the STA and the MU-RTS Trigger frame is sent by the AP with which the non-AP STA is associated
22 or by the AP corresponding to the transmitted BSSID if the non-AP STA is associated with an AP
23 corresponding to a nontransmitted BSSID and has indicated support for receiving Control frames
24
25
with TA field set to the transmitted BSSID by setting the Rx Control Frame To MultiBSS subfield to
26 1 in the HE Capabilities element that the non-AP STA transmits.
27 — The UL MU CS condition indicates that the medium is idle (see 26.5.2.5 (UL MU CS mechanism)).
28
29
30 (#7778)If the non-AP STA is NSTR limited and the conditions above are met, then the non-AP STA may
31 commence transmission of a CTS frame response at the SIFS time boundary after the end of the received
32 PPDU.
33
34
35 (#7778)If the conditions above are not met, thenOtherwise, the non-AP STA shall not send a CTS frame
36 response.
37
38
26.2.7 EDCA operation using MU EDCA parameters
39
40
41 Change NOTE 3 as follows:
42
43 NOTE 3—A non-AP STA does not update its state variables to the values contained in the MU EDCA Parameter Set
44 element if any of the following applies:
45
a) (#5708)The Trigger frame addressed to the STA is notneither a Basic Trigger frame nor an MU-RTS TXS Trig-
46
47 ger frame (see 35.2.1.2 (Triggered TXOP sharing procedure)).
48 b) The STA does not include QoS Data frames in the HE TB PPDU response sent in response to the Basic Trigger
49 frame.
50
51 c) The STA transmits the HE TB PPDU in response to a Basic Trigger frame following the rules defined in 26.5.4
52 (UL OFDMA-based random access (UORA)).
53 d) (#5708)The STA does not include QoS Data frames in the non-TB PPDU response sent to its associated AP in
54 response to the MU-RTS TXS Trigger frame.
55
56
57 26.5 MU operation
58
59
60 26.5.1 HE DL MU operation
61
62 26.5.1.1 General
63
64
65 Delete the fourth paragraph as follows:

Copyright © 2022 IEEE. All rights reserved. 363

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 An AP shall not transmit an HE MU PPDU with an RU that is narrower than the PPDU bandwidth and that
2 is allocated to more than one STA (DL MU-MIMO), unless the AP has received from each STA an HE
3
Capabilities element with the Partial Bandwidth DL MU-MIMO subfield in the HE PHY Capabilities Infor-
4
5 mation field equal to 1.
6
7 Delete the last paragraph as follows:
8
9
10 An AP shall not transmit an HE MU PPDU where the number of OFDM symbols in the HE-SIG-B field is
11 greater than 16 to a non-AP STA with a 20 MHz operating channel width.
12
13
14 Insert the following subclause after subclause 26.5.1.1 (General):
15
16
26.5.1.1a Additional rules on an HE MU PPDU(#1087)
17
18
19 An AP shall not transmit an HE MU PPDU with an RU that is narrower than the PPDU bandwidth and that
20 is allocated to more than one STA (DL MU-MIMO), unless the AP has received from each STA an HE
21
22
Capabilities element with the Partial Bandwidth DL MU-MIMO subfield in the HE PHY Capabilities Infor-
23 mation field equal to 1.
24
25 An AP shall not transmit an HE MU PPDU where the number of OFDM symbols in the HE-SIG-B field is
26
27 greater than 16 to a non-AP STA with a 20 MHz operating channel width.
28
29 26.5.1.3 RU allocation in an HE MU PPDU
30
31
32 Delete the last paragraph as follows:
33
34
35
An HE MU PPDU shall have a sufficient number of RUs allocated to users such that all of the following
36 conditions are satisfied:
37
a) At least N  4  26 subcarriers are modulated by the allocated RUs within the entire PPDU, where N
38
39 is the number of 20 MHz subchannels that are not preamble punctured in the PPDU.
40 b) For each 20 MHz subchannel S within the bandwidth of the HE MU PPDU, at least 2  26 subcarri-
41
42 ers are modulated by the allocated RUs in the 20 MHz subchannel S if all of the following are true:
43 1) At least one RU is allocated in the 20 MHz subchannel S.
44
45 2) Transmitter is an AP.
46
47 3) The AP is operating in an operating class for which the behavior limits set listed in Annex E
48 includes the DFS_50_100_Behavior.
49
50 4) The AP has received at least one Beacon frame from OBSS B within the past dot11ObssNbRu-
51 ToleranceTime in the current operating channel in which any of the following are true:
52
53 i) The Extended Capabilities element is not present.
54
55 ii) The OBSS Narrow Bandwidth RU In OFDMA Tolerance Support field in the Extended
56 Capabilities element is not present.
57
58
iii) The OBSS Narrow Bandwidth RU In OFDMA Tolerance Support field in the Extended
59 Capabilities element is 0.
60
5) The 20 MHz subchannel S overlaps with the operating bandwidth of the OBSS B.
61
62 c) At least one RU is allocated in the primary 20 MHz.
63
64
65 Insert the following subclause after subclause 26.5.1.3 (RU allocation in an HE MU PPDU):

364 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 26.5.1.3a Minimum RU allocation in an HE MU PPDU(#1087)

2
3
An HE MU PPDU shall have a sufficient number of RUs allocated to users such that all of the following
4
5 conditions are satisfied:
6 a) At least N  4  26 subcarriers are modulated by the allocated RUs within the entire PPDU, where N
7 is the number of 20MH z subchannels that are not preamble punctured in the PPDU.
8
9 b) For each 20 MHz subchannel S within the bandwidth of the HE MU PPDU, at least 2  26 subcarri-
10 ers are modulated by the allocated RUs in the 20 MHz subchannel S if all of the following are true:
11
12 1) At least one RU is allocated in the 20 MHz subchannel S.
13 2) Transmitter is an AP.
14
15 3) The AP is operating in an operating class for which the behavior limits set listed in Annex E
16 includes the DFS_50_100_Behavior.
17 4) The AP has received at least one Beacon frame from OBSS B within the past dot11ObssNbRu-
18
19 ToleranceTime in the current operating channel in which any of the following are true:
20 i) The Extended Capabilities element is not present.
21
22 ii) The OBSS Narrow Bandwidth RU In OFDMA Tolerance Support field in the Extended
23 Capabilities element is not present.
24 iii) The OBSS Narrow Bandwidth RU In OFDMA Tolerance Support field in the Extended
25
26 Capabilities element is 0.
27 5) The 20 MHz subchannel S overlaps with the operating bandwidth of the OBSS B.
28
29 c) At least one RU is allocated in the primary 20 MHz.
30
31 26.5.2 UL MU operation
32
33
34
26.5.2.2 Rules for soliciting UL MU frames
35
36 26.5.2.2.1 General
37
38 Delete the first five paragraphs:
39
40
41 An HE AP shall not allocate an RU for a 40 MHz HE TB PPDU to a 20 MHz operating non-AP HE STA in
42 the 2.4 GHz band, unless the AP has received from the 20 MHz operating non-AP HE STA an HE Capabili-
43 ties element with the 20 MHz In 40 MHz HE PPDU In 2.4 GHz Band subfield in the HE PHY Capabilities
44 Information field in its HE Capabilities element equal to 1.
45
46
47 An HE AP shall not allocate an RU for an 160 MHz or 80+80 MHz HE TB PPDU to a 20 MHz operating
48 non-AP HE STA, unless the AP has received from the 20 MHz operating non-AP HE STA an HE Capabili-
49 ties element with the 20 MHz In 160/80+80 MHz HE PPDU in the HE PHY Capabilities Information field
50 equal to 1.
51
52
53 An AP shall not allocate to a 20 MHz operating non-AP HE STA a 242-tone RU for a 40 MHz, 80 MHz,
54 160 MHz, or 80+80 MHz HE TB PPDU transmission.
55
56 An AP shall not transmit a Trigger frame soliciting an HE TB PPDU that uses UL MU-MIMO within an RU
57
58 that does not span the entire PPDU bandwidth to a non-AP STA from which it has not received an HE Capa-
59 bilities element with the Partial Bandwidth UL MU-MIMO subfield of the HE PHY Capabilities Informa-
60 tion field equal to 1.
61
62
An AP shall not transmit a Trigger frame soliciting an HE TB PPDU that uses UL MU-MIMO within an RU
63
64 that spans the full bandwidth to a non-AP STA from which it has not received an HE Capabilities element
65 with the Full Bandwidth UL MU-MIMO subfield of the HE PHY Capabilities Information field equal to 1.

Copyright © 2022 IEEE. All rights reserved. 365

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Delete the seventh paragraph:

2
3
4 An AP shall not send a frame that carries a TRS Control subfield that allocates a 2996-tone RU to a non-
5 AP STA or a Trigger frame with a User Info field that allocates a 2996-tone RU to a non-AP STA, unless
6 the AP has received from the non-AP STA an HE MAC Capabilities element with the UL 2996-tone RU
7 Support subfield in the MAC Capabilities Information field equal to 1.
8
9
10 Insert the following new subclause at the end of 26.5.2.2.1 (General):
11
12 26.5.2.2.1a Additional rules for soliciting UL MU frames(#1088)
13
14
15 An HE AP shall not allocate an RU for a 40 MHz HE TB PPDU to a 20 MHz operating non-AP HE STA in
16 the 2.4 GHz band, unless the AP has received from the 20 MHz operating non-AP HE STA an HE Capabili-
17 ties element with the 20 MHz In 40 MHz HE PPDU In 2.4 GHz Band subfield in the HE PHY Capabilities
18
Information field in its HE Capabilities element to 1.
19
20
21 An HE AP shall not allocate an RU for an 160 MHz or 80+80 MHz HE TB PPDU to a 20 MHz operating
22 non-AP HE STA, unless the AP has received from the 20 MHz operating non-AP HE STA an HE Capabili-
23 ties element with the 20 MHz In 160/80+80 MHz HE PPDU in the HE PHY Capabilities Information field
24
25 equal to 1.
26
27 An AP shall not allocate to a 20 MHz operating non-AP HE STA a 242-tone RU for a 40 MHz, 80 MHz,
28 160 MHz, or 80+80 MHz HE TB PPDU transmission.
29
30
31 An AP shall not transmit a Trigger frame soliciting an HE TB PPDU that uses UL MU-MIMO within an RU
32 that does not span the entire PPDU bandwidth to a non-AP STA from which it has not received an HE Capa-
33 bilities element with the Partial Bandwidth UL MU-MIMO subfield of the HE PHY Capabilities Informa-
34
35 tion field equal to 1.
36
37 An AP shall not transmit a Trigger frame soliciting an HE TB PPDU that uses UL MU-MIMO within an RU
38 that spans the full bandwidth to a non-AP STA from which it has not received an HE Capabilities element
39
40
with the Full Bandwidth UL MU-MIMO subfield of the HE PHY Capabilities Information field equal to 1.
41
42 An AP shall not send a frame that carries a TRS Control subfield that allocates a 2996-tone RU to a non-
43 AP STA or a Trigger frame with a User Info field that allocates a 2996-tone RU to a non-AP STA, unless
44
the AP has received from the non-AP STA an HE MAC Capabilities element with the UL 2996-tone RU
45
46 Support subfield in the HE MAC Capabilities Information field equal to 1.
47
48
49 26.10 Spatial reuse operation
50
51
26.10.2 OBSS PD-based spatial reuse operation
52
53
54 26.10.2.2 General operation with non-SRG OBSS PD level
55
56
57 Change the first two paragraphs as follows:
58
59 If the PHY of a STA issues a PHY-CCA.indication(BUSY) followed by a PHY-RXSTART.indication due
60 to a PPDU reception, then the STA’s MAC sublayer
61
62 a) May issue a PHY-CCARESET.request primitive before the end of the PPDU and not update its
63 basic NAV timer based on the PPDU, or
64
65 b) May not update its basic NAV timer based on the PPDU if all the following conditions are met:

366 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 1) The STA has not set the TXVECTOR parameter SPATIAL_REUSE to the value
2 PSR_AND_NON_SRG_OBSS_PD_PROHIBITED in any (#6174)(#5776)HE PPDU that has
3
a TXVECTOR parameter SPATIAL_REUSE present and that the STA it has transmitted in the
4
5 current beacon period and in the previous beacon period.
6 2) The most recently received Spatial Reuse Parameter Set element from its associated AP had the
7
Non-SRG OBSS PD SR Disallowed subfield equal to 0, or the non-AP STA has not received a
8
9 Spatial Reuse Parameter Set element from its associated AP, or the STA is an AP and its most
10 recently transmitted Spatial Reuse Parameter Set element had the Non-SRG OBSS PD SR Dis-
11 allowed subfield equal to 0, or the STA is an AP and has not transmitted a Spatial Reuse
12 Parameter Set element.
13
14 3) The received PPDU is an inter-BSS PPDU (see 26.2.2 (Intra-BSS and inter-BSS PPDU classi-
15 fication)), and the received PPDU is not a non-HT PPDU carrying a response frame (Ack,
16 BlockAck, or CTS frame); or the received PPDU contains a CTS, a PHY-CCA.indication tran-
17
sition from BUSY to IDLE occurred within the PIFS time immediately preceding the received
18
19 CTS, and that transition corresponded to the end of an inter-BSS PPDU that contained an RTS
20 that was ignored following this procedure.
21
22
4) The STA is operating with an SRG OBSS PD level as described in 26.10.2.3 (General opera-
23 tion with SRG OBSS PD level), and the received PPDU is not an SRG PPDU; or the STA is
24 not operating with an SRG OBSS PD level.
25
26
5) The (#6174)(#5776)RXVECTOR parameter SPATIAL_REUSE subfield in the HE-SIG-A
27 field (if present) of the received PPDU is not set to PSR_AND_NON_SRG_OBSS_PD_PRO-
28 HIBITED.
29
30
6) The received signal strength level, which is measured from the L-STF or L-LTF fields of the
31 PPDU or the PHY SYNC field, shortSYNC field, or Long PHY SYNC field, whichever exists
32 and is used to determine PHY-CCA.indication, is below the non-SRG OBSS PD level. The
33 non-SRG OBSS PD level is defined in 26.10.2.4 (Adjustment of OBSS PD and transmit
34 power). If the STA has dot11HEPSROptionImplemented set to true, it also follows the rules
35
36
defined in 26.10.4 (Interaction of OBSS PD and PSR-based spatial reuse) to determine non-
37 SRG OBSS PD level.
38 7) The PPDU is not one of the following:
39
40 i) A non-HE PPDU that carries a frame where the RA field is equal to the STA MAC
41 address
42
43 ii) A non-HE PPDU that carries a Public Action frame
44 iii) A non-HE PPDU that carries (#6174)(#4195)an a VHT/HE NDP Announcement frame or
45
46 Fine Timing Measurement frame
47 iv) A non-HE NDP
48
49 NOTE 1—A STA cannot perform SR over (#4195)a an HE sounding NDP or HE TB feedback NDP (see
50 26.11.6 (SPATIAL_REUSE)).
51
52 26.10.2.3 General operation with SRG OBSS PD level
53
54
55 Change the first two paragraphs as follows:
56
57
58 If the PHY of a STA issues a PHY-CCA.indication(BUSY) followed by a PHY-RXSTART.indication due
59 to a PPDU reception, then the STA’s MAC sublayer
60 a) May issue a PHY-CCARESET.request primitive before the end of the PPDU and not update its
61
62 basic NAV timer based on the PPDU, or
63 b) May not update its basic NAV timer based on the PPDU if all the following conditions are met:
64
65 1) The received PPDU is an SRG PPDU (see 26.2.3 (SRG PPDU identification))

Copyright © 2022 IEEE. All rights reserved. 367

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 2) The received signal strength level, which is measured from the L-STF or L-LTF fields of the
2 PPDU or the PHY SYNC field, shortSYNC field, or Long PHY SYNC field, whichever exists
3
and is used to determine PHY-CCA.indication, is below the SRG OBSS PD level. The SRG
4
5 OBSS PD level is defined in 26.10.2.4 (Adjustment of OBSS PD and transmit power). If the
6 STA has dot11HEPSROptionImplemented set to true, it also follows the rules defined in
7 26.10.4 (Interaction of OBSS PD and PSR-based spatial reuse) to determine SRG OBSS PD
8 level.
9
10 3) The PPDU is not one of the following:
11 i) A non-HE PPDU that carries a frame where the RA field is equal to the STA MAC
12
address
13
14 ii) A non-HE PPDU that carries a Public Action frame
15
iii) A non-HE PPDU that carries (#6174)(#4195)an a VHT/HE NDP Announcement frame or
16
17 Fine Timing Measurement frame
18 iv) A non-HE NDP
19
20 NOTE 1—A STA cannot perform SR over (#4195)a an HE sounding NDP or HE TB feedback NDP (see
21 26.11.6 (SPATIAL_REUSE)).
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

368 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Insert new Clauses 35 and 36 following Clause 34 as follows:

2
3
4
5 35. Extremely high throughput (EHT) MAC specification
6
7
8 35.1 Introduction
9
10 (#3173)An EHT STA shall set dot11EHTBaseLineFeaturesImplementedOnly to true.
11
12
13 An EHT STA supports the MAC and MLME functions defined in Clause 35 (Extremely high throughput
14 (EHT) MAC specification) in addition to the MAC functions defined in Clause 26 (High efficiency (HE)
15 MAC specification) and Clause 10 (MAC sublayer functional description), the MLME functions defined in
16 Clause 11 (MLME), and the security functions defined in Clause 12 (Security) except when the functions in
17
18 Clause 35 (Extremely High Throughput (EHT) MAC specification) supersede the functions in Clause 10
19 (MAC sublayer functional description), Clause 11 (MLME), Clause 12 (Security), or Clause 26 (High
20 efficiency (HE) MAC specification).
21
22 (#2239)(#2720)(#3410)(#3417)A reference model for MLO is described in 4.9.5 (Reference model for
23
24 multi-link operation (MLO)(#2239)(#2720)(#3410)(#3417)).
25
26
27 35.2 Channel access
28
29 35.2.1 TXOP
30
31
35.2.1.1 Bandwidth signaling
32
33
34 An EHT STA transmitting a (#1476)Control frame in non-HT duplicate format with a bandwidth signaling
35 TA addressed to an EHT STA shall set the TXVECTOR parameters CH_BANDWIDTH_IN_NON_HT
36 according to Table 36-1 (TXVECTOR and RXVECTOR parameters).
37
38
39 35.2.1.2 Triggered TXOP sharing procedure
40
41 35.2.1.2.1 General
42
43
The Triggered TXOP sharing procedure allows an AP to allocate a portion of the time within an obtained
44
45 TXOP to only an associated non-AP EHT STA(#8315) for transmitting one or more non-TB PPDUs(#6530).
46
47 An EHT STA with dot11EHTTXOPSharingTFOptionImplemented equal(#6393) to true shall set
48 (#4918)either of the following two bits in the EHT Capabilities element to 1: the Triggered TXOP Sharing
49
Mode 1 Support subfield or the Triggered TXOP Sharing Mode 2 Support subfield.
50
51
52 An EHT STA with dot11EHTTXOPSharingTFOptionImplemented equal to 1 shall follow the rules defined
53 in 35.2.2 (MU-RTS trigger/CTS frame exchange procedure for EHT STAs) when transmitting or responding
54 to (#6394)an MU-RTS TXS Trigger frame and the additional rules defined in 35.2.1.2.2 (AP behavior) and
55
35.2.1.2.3 (Non-AP STA behavior).
56
57
58 An EHT STA that uses information from a received MU-RTS TXS Trigger frame as the most recent basis to
59 update its NAV should not reset its NAV after the NAVTimeout has expired (see 10.3.2.4 (Setting and
60 resetting the NAV)) unless the STA receives a CF-End frame that satisfies the conditions in
61
26.2.5 (Truncation of TXOP)(#4184).
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 369

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 35.2.1.2.2 AP behavior
2
3
An EHT AP may allocate time within an obtained TXOP (see 10.23.2.4 (Obtaining an EDCA
4
5 TXOP))(#4185) to an associated non-AP EHT STA(#8315) by transmitting an MU-RTS TXS Trigger frame
6 as defined in 9.3.1.22.5 (MU-RTS Trigger frame format) parametrized as follows:
7 — (#7409)The MU-RTS TXS Trigger frame, if transmitted by an AP with
8
9 dot11EHTBaseLineFeaturesImplementedOnly equal to true, shall have one User Info field that is not
10 a Special User Info field. The User Info field shall be addressed to an associated non-AP STA (i.e.,
11 AID12 subfield is set to a value between 1 and 2006). The MU-RTS TXS Trigger frame may contain
12 a Special User Info field as defined in 9.3.1.22.5 (MU-RTS Trigger frame format).
13
14
15 The number of User Info fields that is addressed to a non-AP EHT STA in an MU-RTS TXS Trigger frame
16 transmitted by an EHT AP with dot11EHTBaseLineFeaturesImplementedOnly equal to true shall be
17 1(#4187).
18
19 An EHT AP shall not send (#6394)an MU-RTS TXS Trigger frame (#7588)with TXOP Sharing Mode
20
21 subfield equal to 1 and with the User Info field that is addressed to an associated non-AP STA from which it
22 has not received an EHT Capabilities element with (#7588)the Triggered TXOP Sharing Mode 1 Support
23 subfield (#5960)equal to 1.
24
25 (#7588)An EHT AP shall not send an MU-RTS TXS Trigger frame with TXOP Sharing Mode subfield
26
27 equal to 2 and with the User Info field that is addressed to an associated non-AP STA from which it has not
28 received an EHT Capabilities element with the Triggered TXOP Sharing Mode 2 Support subfield
29 (#5960)equal to 1.
30
31 If the EHT AP receives a CTS frame in response to its transmitted MU-RTS TXS Trigger frame to a non-AP
32
33 EHT STA with the TXOP Sharing Mode subfield equal to 1, then the AP shall not transmit any PPDU within
34 the allocated time specified in the MU-RTS TXS Trigger frame unless:
35 — The PPDU carries an immediate response that is solicited by the non-AP STA(#4188).
36
37 — The CS mechanism indicates that the medium is idle at the TxPIFS slot boundary after the end of
38 either the transmission of (#7714)an immediate response frame sent to that STA or the reception of
39 (#7714)a frame from that STA that did not require an immediate response.
40
41
42 If the EHT AP receives a CTS frame in response to its transmitted MU-RTS TXS Trigger frame to a non-AP
43 EHT STA(#8315) with the TXOP Sharing Mode subfield equal to 2, then the AP shall not transmit any
44 PPDU(#7328) within the allocated time specified in the MU-RTS TXS Trigger frame unless the PPDU
45 carries an immediate response that is solicited by the non-AP STA(#4190)(#5152).
46
47
48 If in response to a transmitted MU-RTS TXS Trigger frame the EHT AP receives a CTS frame from the non-
49 AP STA that was allocated time in that Trigger frame, then the AP may transmit a PPDU after the end of the
50 allocated time and before its TXNAV timer has expired if any of the following conditions are satisfied:
51
— The medium is determined to be idle by the CS mechanism at the end of the allocated time in which
52
53 case it may transmit (#7809)a PIFS after the end of the allocated time.
54 — The last PPDU transmission by the AP ended less than aSIFSTime before the end of the allocated
55 time in which case it may transmit (#7810)a SIFS after the end of the last PPDU transmission.
56
57 — The medium is determined to be busy by the CS mechanism at the end of the allocated time in which
58 case it may transmit after the CS mechanism (see 10.3.2.1 (CS mechanism)) indicates that the
59 medium is idle at the TxPIFS slot boundary.
60
61
62 If in response to a transmitted MU-RTS TXS Trigger frame the EHT AP receives a CTS frame from the non-
63 AP STA that was allocated time in that Trigger frame and the CS mechanism indicates that the medium is
64 busy at the end of the allocated time, then the AP might transmit at TxPIFS slot boundary as described above
65

370 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 or invoke the backoff procedure as described in 10.23.2.2 (EDCA backoff procedure) or wait for the
2 TXNAV timer to expire and invoke the backoff procedure.
3
4
5 Figure 35-1 (Example of MU-RTS TXS Trigger frame with TXOP Sharing Mode subfield value equal to 1
6 soliciting UL PPDU(#5153)(#5518)) shows an example of the exchange of MU-RTS TXS Trigger frame
7 with TXOP Sharing Mode subfield value equal to 1 and transmission of UL non-TB PPDUs by a scheduled
8 STA within the allocated time.
9
10
11
12
MU‐RTS TXS
13 TF (TXOP Block Block
14 CTS‐to‐
Sharing Ack to Ack to PIFS
DATA to another
AP self non‐AP STA
15 Mode =1) to STA 1 STA 1
STA 1
16
17
18
19
20 CTS DATA to AP DATA to AP
21 Non‐AP response in a non‐TB in a non‐TB
22 STA 1 to AP PPDU PPDU
23
24 Time allocated in MU‐RTS TXS TF
25
TXOP
26
27
28
29
30
31 Figure 35-1—Example of MU-RTS TXS Trigger frame with TXOP Sharing Mode subfield
32 value equal to 1 soliciting UL PPDU(#5153)(#5518)
33
34
35 Figure 35-2 (Example of MU-RTS TXS Trigger frame with TXOP Sharing Mode subfield value equal to
36 2(#5153)(#8324)) shows an example of the exchange of MU-RTS TXS Trigger frame with TXOP Sharing
37 Mode subfield value equal to 2 and transmission of PPDUs by a scheduled STA to another STA within the
38
39 allocated time.
40
41
42
MU‐RTS TXS
43 TF (TXOP DATA to
CTS‐to‐ PIFS
44 self
Sharing
Block Ack
to STA 1
another
non‐AP
45 AP Mode =2) to STA
STA 1
46
47 Non‐AP CTS
DATA to AP in
response DATA to STA 2
48 STA 1 to AP
non‐TB PPDU
49
Block
50 Non‐AP Ack to
51 STA 2 STA 1
52
53 Time allocated in MU‐RTS TXS TF
54
55
56 TXOP
57
58
59
60 Figure 35-2—Example of MU-RTS TXS Trigger frame with TXOP Sharing Mode subfield
61 value equal to 2(#5153)(#8324)
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 371

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 35.2.1.2.3 Non-AP STA behavior

2
3
After a non-AP EHT STA(#8315) receives an MU-RTS TXS Trigger frame from its associated AP that
4
5 contains a User Info field that is addressed to it, the STA may(#4194) transmit one or more non-TB PPDUs
6 within the time allocation signaled in the MU-RTS TXS Trigger frame. The first PPDU of the exchange
7 shall be a CTS frame transmitted per the rules defined in 26.2.6.3 (CTS frame response to an MU-RTS
8 Trigger frame).
9
10
11 The time allocation shall start when the PHY-RXEND.indication primitive of the PPDU that contains the
12 MU-RTS TXS Trigger frame has occurred.
13
14 During the time allocated by an associated AP, the non-AP EHT STA may transmit non-TB PPDUs to the
15
AP or another STA if the TXOP Sharing Mode subfield value is 2(#6530)(#7331).
16
17 NOTE 1—For example, the other STA can be a peer STA of a peer-to-peer link.
18
19
During the time allocated by an associated AP, the non-AP EHT STA may transmit non-TB PPDUs and only
20
21 to its associated AP if the TXOP Sharing Mode subfield value is 1(#6530)(#7331).
22
23 A non-AP STA addressed by a User Info field in the MU-RTS TXS Trigger frame shall ensure that its PPDU
24 transmission(s) and any expected responses fit entirely within the allocated time.
25
26
27 (#5708)A non-AP EHT STA that receives a MU-RTS TXS Trigger frame from its associated AP that
28 contains a User Info field addressed to the STA shall update its CWmin[AC], CWmax[AC], AIFSN[AC],
29 and MUEDCATimer[AC] state variables to the values contained in the dot11MUEDCATable, for all the
30 ACs from which at least one QoS Data frame was transmitted successfully in a non-TB PPDU to the AP
31
within the time allocated in the Trigger frame. A QoS Data frame is transmitted successfully by the STA for
32
33 an AC if it requires immediate acknowledgment and the STA receives an immediate acknowledgment for
34 that frame, or if the QoS Data frame does not require immediate acknowledgment.
35
36 (#5708)The updated MUEDCATimer[AC] shall start at the end of the immediate response if a non-TB
37
PPDU transmitted to its associated AP within the time allocated in an MU-RTS TXS Trigger frame contains
38
39 at least one QoS Data frame for that AC that requires immediate acknowledgment, and shall start at the end
40 of the non-TB PPDU if the transmitted non-TB PPDU to its associated AP does not contain any QoS Data
41 frames for that AC that requires immediate acknowledgment.
42
43
(#5141)After sending the CTS solicited by MU-RTS TXS from the associated AP, the STA that sends the
44
45 responding CTS shall ignore the NAV that is set by the AP within the time allocation signaled in the MU-
46 RTS TXS Trigger frame.
47
48 (#5903)After sending the CTS solicited by MU-RTS TXS, the STA shall set the Duration field of its frame
49
to peer-to-peer (P2P) peer STA with the value that indicates the time no later than the ending time of the
50
51 PPDU carrying MU-RTS TXS plus the Allocation Duration field in soliciting MU-RTS TXS. Within the
52 allocated time by an MU-RTS TXS Trigger frame with TXOP Sharing Mode subfield equal to 2, the
53 addressed STA by the MU-RTS TXS Trigger frame may transmit QoS Data frames, Management frames
54 and the frames that assists the transmission of QoS Data frames and Management frames, e.g., RTS frame,
55
the frames for sounding.
56
57 (#5903)NOTE 2—With the Duration rule defined here, the basic NAV of a STA in the same BSS as the AP will become
58 0 if the basic NAV timer is set per the P2P transmission frames during the allocated time period, so the STA can do the
59 transmission in the remain TXOP that after allocated time period due to a nonzero basic NAV value.
60
61
(#6979)A non-AP STA addressed by an MU-RTS TXS Trigger frame shall not transmit non-TB PPDUs
62
63 occupying subchannels that are not used for responding the CTS frame to the MU-RTS TXS Trigger frame
64 during the time allocated by an associated AP.
65

372 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#6979)A non-AP STA addressed by an MU-RTS TXS Trigger frame shall set the TXVECTOR parameter
2 CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT of a non-TB PPDU to be the same or narrower
3
than the TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT of the CTS frame that it has responded
4
5 to the MU-RTS TXS Trigger frame.
6
7 (#6979)If a 20 MHz subchannel is indicated as a punctured subchannel in the most recently exchanged
8 Disabled Subchannel Bitmap field in the EHT Operation element, the corresponding bit in the TXVECTOR
9
parameter INACTIVE_SUBCHANNELS shall be set to 1 and the punctured 20 MHz subchannel shall not
10
11 be used by the non-TB PPDU(s) that is transmitted during the time allocated by an associated AP.
12
13 35.2.2 MU-RTS trigger/CTS frame exchange procedure for EHT STAs
14
15
35.2.2.1 MU-RTS Trigger frame transmission
16
17
18 An EHT AP shall follow the rules defined in 26.2.6.2 (MU-RTS Trigger frame transmission) and the
19 following additional rules to transmit an MU-RTS Trigger frame.
20
21
If any non-AP EHT STA is addressed in an MU-RTS Trigger frame from an EHT AP and any of the
22
23 following conditions is met, the User Info field addressed to an EHT STA in the MU-RTS Trigger frame
24 shall be an EHT variant User Info field:
25 — The bandwidth of the PPDU carrying the MU-RTS Trigger frame is 320 MHz.
26
27 — The PPDU carrying the MU-RTS Trigger frame is punctured.
28
29 Otherwise, the EHT AP may decide whether the User Info field in the MU-RTS Trigger frame is an HE
30
variant User Info field or an EHT variant User Info field.
31
32
33 (#5514)If the B55 in the Common Info field is equal to 0 in an MU-RTS Trigger frame, an EHT AP shall not
34 set the B54 in the Common Info field to 1.
35
36 NOTE—Refer to 9.3.1.22.1.2 (User Info List field) on valid combinations of B54 and B55 in the Common Info field,
37 B39 in the User Info field, and User Info field variant.
38
39 An MU-RTS Trigger frame shall not solicit a CTS frame from an HE STA within a bandwidth that is
40 indicated by UL BW field in the Common Info field of the MU-RTS Trigger frame and that contains any
41
punctured 20 MHz subchannel. If all the User Info fields in the MU-RTS Trigger frame are HE variant, the
42
43 PPDU carrying the MU-RTS Trigger frame or any responding CTS frame is not punctured.
44
45 An MU RTS Trigger frame may be carried in an EHT MU PPDU if the intended recipient(s) are non-AP
46 EHT STA(s). If the MU-RTS Trigger frame is carried in an EHT MU PPDU, then the EHT AP shall set the
47
TXVECTOR parameter EHT_PPDU_TYPE of the EHT MU PPDU to 1.
48
49
50 An EHT AP with dot11EHTBaseLineFeaturesImplementedOnly equal to true that transmits a PPDU
51 carrying an MU-RTS Trigger frame shall not puncture other subchannels in addition to those indicated in the
52 Disabled Subchannel Bitmap field in the EHT Operation element.
53
54
55 35.2.2.2 CTS frame response to an MU-RTS Trigger frame
56
57 An non-AP EHT STA shall follow the rules defined in 35.5.2.2.4 (Allowed settings of the Trigger frame
58 fields and TRS Control subfield) to determine whether the EHT STA is addressed by the HE variant User
59
Info field or an EHT variant User Info field in an MU-RTS Trigger frame.
60
61
62 If an EHT STA is addressed by an HE variant User Info field in an MU-RTS Trigger frame, the EHT STA
63 shall follow the rules defined in 26.2.6 (MU-RTS Trigger/CTS frame exchange procedure) in transmitting a
64 response.
65

Copyright © 2022 IEEE. All rights reserved. 373

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 If the EHT STA is addressed by an EHT variant User Info field in the MU-RTS Trigger frame, the EHT
2 STA shall follow the rules defined in 26.2.6 (MU-RTS Trigger/CTS frame exchange procedure) in
3
transmitting a response, except that UL MU CS condition shall be determined based on the rules defined in
4
5 35.5.2.4 (UL MU CS mechanism for EHT STAs). The CTS frame in response to the MU-RTS Trigger frame
6 shall be sent in the RU indicated by the EHT variant User Info field, excluding any punctured 20 MHz
7 subchannel indicated in the Disabled Subchannel Bitmap field in the EHT Operation element.
8
9
35.2.3 Intra-BSS and inter-BSS PPDU classification for EHT STA(#4287)
10
11
12 An EHT STA shall follow the rules defined in 26.2.2 (Intra-BSS and inter-BSS PPDU classification) to
13 classify intra-BSS and inter-BSS PPDU, except that a STA shall classify a received PPDU as an inter-BSS
14 PPDU if the PPDU is an EHT MU PPDU with the RXVECTOR parameter UPLINK_FLAG equal to 0, and
15
the STA is an AP.
16
17
18
19
35.3 Multi-link operation
20
21 35.3.1 General
22
23 MLO enables a non-AP MLD to discover, authenticate, associate, and set up multiple links with an AP
24
25 MLD. Each link enables channel access and frame exchanges between the non-AP MLD and the AP MLD
26 based on the supported capabilities exchanged during association.
27
28 (#1057)(#2319)A STA, which is affiliated with an MLD, may select and manage its (#6601)capabilities and
29 operating parameters independently from the other STA(s) affiliated with the same MLD, unless specified
30
31 otherwise.
32 (#1057)(#2319)NOTE 1—For example, each AP, which is affiliated with an AP MLD, may select its BSS color
33 corresponding to the BSS that the AP generates differently.
34
35
(#5606)NOTE 2—Examples of operating parameters that are selected at the MLD level (i.e., not independently selected
36
by affiliated STAs) are the listen interval (see 35.3.12.6 (Operation for MLD listen interval)) and the WNM sleep
37
interval (see 11.2.3.1 (General)).
38
39
40 (#6967)An AP MLD or an NSTR mobile AP MLD shall correct the clock drift to be within ±30 µs between
41 TSF timers of any two APs affiliated with the AP MLD or the NSTR mobile AP MLD.
42
43 An EHT AP shall have dot11MultiLinkActivated set to true and shall be affiliated with an AP MLD. The
44
45 EHT AP and its affiliated AP MLD follow the rules defined in 35.3 (Multi-link operation).
46
47 35.3.2 Advertisement of multi-link information in Multi-Link element(#2294)
48
49 35.3.2.1 General
50
51
52 (#2241)(#1154)(#2850)(#2450)(#3366)(#3152)(#1716)(#2898)(#1155)(#1414)(#2581)(#3367)(#3359)(#28
53 59)(#2295)An AP affiliated with an AP MLD shall follow the rules defined in 35.3.4.4 (Multi-Link element
54 usage rules in the context of discovery) for including a (#6700)Basic Multi-Link element in a Beacon frame
55 that it transmits or in a Probe Response frame, which is not an ML probe response, that it transmits.
56
57
58 (#1155)(#1414)(#2581)(#3367)(#3359)(#2859)(#2295)An AP affiliated with an AP MLD shall follow the
59 rules in 35.3.4.2 (Use of ML probe request and response(#2583)(#3360)) for including a (#6700)Basic
60 Multi-Link element in a Probe Response frame, which is an ML probe response, that it transmits.
61
62
63
64
65

374 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#2295)An AP affiliated with an AP MLD shall follow the rules in 35.3.5.4 (Usage and rules of Basic Multi-
2 Link element in the context of multi-link (re)setup(#6700)) for including a (#6700)Basic Multi-Link element
3
in (#1494)a (Re)Association Response frame and in an Authentication frame that it transmits.
4
5
6 (#1183)(#1777)(#1918)(#2414)(#2582)(#3211)(#3249)(#3368)(#2182)(#2295)A STA affiliated with a non-
7 AP MLD shall follow the rules in 35.3.4.2 (Use of ML probe request and response(#2583)(#3360)) for
8 including a (#6701)Probe Request Multi-Link element in a Probe Request frame that it transmits.
9
10
11 (#7715)(#2295)A STA affiliated with a non-AP MLD shall follow the rules in 35.3.5.4 (Usage and rules of
12 Basic Multi-Link element in the context of multi-link (re)setup(#6700)) for including a (#6700)Basic Multi-
13 Link element in (#1494)a (Re)Association Request frame and in an Authentication frame that it transmits.
14
15
(#6864)(#1776)The value carried in the Link ID subfield of the Per-STA Profile subelement carried in a
16
17 (#6700)Basic Multi-Link element is unique to every AP affiliated with an AP MLD and is a representation
18 of the tuple consisting of Operating Class, Operating Channel, and BSSID of the AP affiliated with the AP
19 MLD (see also 35.3.4.4 (Multi-Link element usage rules in the context of discovery)).
20
21 (#6864)NOTE 1—When a STA affiliated with a non-AP MLD includes a (#6700)Basic Multi-Link element in a
22 (Re)Association Request frame, the Link ID subfield of the STA Control field contained in a Per-STA Profile
23 subelement identifies the link requested for multi-link (re)setup. When a STA affiliated with a non-AP MLD includes a
24 (#6701)Probe Request Multi-Link element in an ML probe request, the Link ID subfield of the STA Control field
25 contained in a Per-STA Profile subelement identifies the AP whose information is requested in the ML probe request.
26
27 (#7716)(#7365)(#5737)(#1895)(#2295)A STA affiliated with an MLD may include Link Info field in the
28 (#6700)Basic Multi-Link element that it transmits to provide complete or partial profile of another STA
29
affiliated with the same MLD as the STA defined in 35.3.2.2 (Advertisement of complete or partial per-link
30
31 information(#1859))(#1034)(#2149)(#1861)(#1833)(#2831).
32
33 (#5736)An AP affiliated with an AP MLD shall not include a Neighbor Report element, a Reduced
34 Neighbor Report element, a Multiple BSSID element or another (#6700)Basic Multi-Link element in the
35
Per-STA Profile subelement of the (#6700)Basic Multi-Link element for a reported AP.
36
37
38 (#4248)A STA affiliated with a non-AP MLD shall not include a Basic Multi-Link element in the Per-STA
39 Profile subelement of the Basic Multi-Link element corresponding to a reported STA.
40
41
(#5738)(#6700)The Basic Multi-Link element when carried in the Neighbor Report element shall not
42
43 include a Link Info field(#5322), except as described in 35.3.25 (BSS transition management for
44 MLDs(#5322)).
45
46 (#5043)A STA affiliated with an MLD that receives a frame carrying a (#6700)Basic Multi-Link element
47
shall determine the length of the Common Info field based on the Common Info Length subfield of the
48
49 Common Info field.
50
51 (#5044)A STA affiliated with an MLD that receives a frame carrying a (#6700)Basic Multi-Link element
52 that carries a Per-STA Profile subelement shall determine the length of the STA Info field based on the STA
53
Info Length subfield of the STA Info field.
54
55
56 (#4112)(#4461)(#6404)(#7461)(#7818)(#6208)A STA affiliated with a non-AP MLD shall follow the
57 procedure (if any) applicable to a field carried in a (Re)Association Response frame, a Beacon frame or a
58 Probe Response frame received on another link as if it had received that field in the corresponding frame
59
transmitted by its associated AP, only if all of the following conditions are satisfied:
60
61 — The field is carried within a Per-STA Profile subelement of a Basic Multi-Link element,
62 corresponding to the STA’s associated AP (reported AP)
63
64 — The corresponding frame is received by another STA affiliated with the same non-AP MLD
65

Copyright © 2022 IEEE. All rights reserved. 375

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — The corresponding frame is transmitted by an AP affiliated with the same AP MLD as the reported
2 AP and is associated with the STA that received the frame.
3
4
(#4112)(#3254)NOTE 2—The fields can be included in elements in the corresponding frame.
5
6
7 35.3.2.2 Advertisement of complete or partial per-link information(#1859)
8
9 (#5737)(#2241)(#2295)(#1035)If a reporting STA affiliated with an MLD transmits a frame that carries a
10
(#6700)Basic Multi-Link element, which includes a Per-STA Profile subelement that carries the complete
11
12 profile for a reported STA, then the STA shall set the Complete Profile subfield of the STA Control field in
13 that Per-STA Profile subelement to 1. Otherwise the reporting STA shall set the Complete Profile subfield
14 of the STA Control field in the Per-STA Profile subelement to 0 and the profile of the reported STA is
15 defined as partial profile(#6871)(#5736)(#4246).
16
17
18 (#8329)(#5737)(#2241)The complete profile of a reported STA consists of all the elements and fields
19 (subject to exceptions discussed later in this subclause) that would be included in a Management frame , that
20 is of the same subtype as that transmitted by the reporting STA carrying the Basic Multi-Link element, if the
21 reported STA were to transmit the frame.
22
23 (#8329)NOTE 1—Only Management frames belonging to subtypes (Re)Association Request, (Re)Association
24 Response, or Probe Response that is an ML probe response can carry complete profile of a reported STA.
25
26 (#5737)NOTE 2—The above definition of complete profile applies only to a (#6700)Basic Multi-Link element.
27
28
(#4035)(#1034)(#2149)(#1861)(#2831)An AP affiliated with an AP MLD shall not include a complete
29
30 profile of a reported AP affiliated with the same AP MLD in the Beacon frame or a Probe Response frame
31 that is not an ML probe response that it transmits.
32
33 (#4035)NOTE 3—See 35.3.11 (Multi-link procedures for channel switching, extended channel switching, and channel
34 quieting(#4112)(#2324)(#2600)) for conditions when a Beacon or a Probe Response frame that is not an ML probe
35 response frame transmitted by an AP affiliated with an AP MLD carries a partial profile of reported AP(s).
36
37 (#1034)(#1833)(#2149)(#1861)(#2831)An AP affiliated with an AP MLD may include either the complete
38 profile or the partial profile of a reported AP affiliated with the same AP MLD in a Probe Response frame,
39 which is an ML probe response frame that it transmits, as defined in 35.3.4.2 (Use of ML probe request and
40
response(#2583)(#3360)).
41
42
43 (#4362)(#6567)(#7365)(#2585)(#3210)(#6191)When a STA affiliated with a non-AP MLD transmits a
44 (Re)Association Request frame, it shall include complete profile(s) of other STAs affiliated with the same
45 non-AP MLD as the transmitting STA, that are capable of operating on the links which the non-AP MLD is
46
requesting to be part of a multi-link setup (also see 35.3.5.4 (Usage and rules of Basic Multi-Link element in
47
48 the context of multi-link (re)setup(#6700))).
49
50 (#4362)(#4377)(#5250)(#6568)(#7365)(#2584)(#2295)(#6192)When an AP affiliated with an AP MLD
51 transmits a (Re)Association Response frame, it shall include complete profile(s) of other APs affiliated with
52
the same AP MLD as the transmitting AP, that are operating on the links which are requested as part of a
53
54 multi-link setup (also see 35.3.5.4 (Usage and rules of Basic Multi-Link element in the context of multi-link
55 (re)setup(#6700))).
56
57 (#4248)(#6396)(#6570)(#7514)(#1860)Each Per-STA Profile subelement of the Basic Multi-Link element
58
that is included in a Management frame transmitted by a STA affiliated with an MLD and that carries a
59
60 complete profile shall consist of the STA Control field to identify the link on which the reported STA
61 operates on and to carry the presence indicators for the subfield(s) within the STA Info field, the STA Info
62 field, and the STA Profile field containing fields and elements based on the following rules:
63
64 — (#1036)(#1864)(#2451)(#2964)(#2586)(#1184)If the reporting STA is an AP, the STA Profile field
65 corresponding to the reported AP:

376 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 • carries fields and elements in the same order and subject to the conditions as in:
2 • Table 9-67 (Probe Response frame body(#1004)(#2246)(#3359)) if the frame is an ML
3
probe response.
4
5 • Table 9-63 (Association Response frame body(#1004)(#2246)(#3354)) if the frame is an
6 Association Response frame.
7 • Table 9-65 (Reassociation Response frame body(#1004)(#2246)(#3356)) if the frame is a
8 Reassociation Response frame.
9
• is subject to inheritance rules defined in 35.3.2.3.1 (Inheritance in the per-STA profile of Basic
10
11 Multi-Link element(#6700)(#2416))) and exceptions specified in 35.3.2.1 (General).
12 • does not include the Timestamp field, Beacon Interval field, AID field, SSID element, TIM ele-
13 ment, and BSS Max Idle Period element.
14
15 — (#1035)If the reporting STA is a non-AP STA, the STA Profile field corresponding to the reported
16 non-AP STA:
17 • carries fields and elements in the same order and subject to conditions as in:
18
• Table 9-62 (Association Request frame body(#1004)(#2246)(#3353)) if the frame is an
19
20 Association Request frame.
21 • Table 9-64 (Reassociation Request frame body(#1004)(#2246)(#3355)) if the frame is an
22 Reassociation Request frame.
23 • is subject to inheritance rules defined in 35.3.2.3.1 (Inheritance in the per-STA profile of Basic
24
Multi-Link element(#6700)(#2416)) and exceptions specified in 35.3.2.1 (General).
25
26 • does not include the Listen Interval field and Current AP Address field.
27 • (#3315)Optionally, a Non-Inheritance element appears as the last element in the STA Profile
28 field and carries a list of elements that are not inherited by the reported STA from the reporting
29 STA (see 35.3.2.3.1 (Inheritance in the per-STA profile of Basic Multi-Link ele-
30
ment(#6700)(#2416))).
31
32
33 (#1860)(#1184)(#1185)(#2866)(#3335)(#2309)(#2964)(#6700)An example of a Basic Multi-Link element,
34 carried in an Association Request frame, containing a complete per-STA profile is shown in Figure 35-3
35 (Example of Basic Multi-Link element in an Association Request
36
frame(#4248)(#6700)(#1050)(#1778)(#2165)).
37
38
39 Common Info field Link Info field
40
41 Element ID Element ID Multi‐Link MLD MAC ...
Length Per‐STA Profile x Per‐STA Profile y
42 (=255) Extension Control Address
43
44
45
46 Type = 0 Presence Bitmap Subelement
Length Data
47 ID (=0)
48 MAC
49 Link Complete
Address ...
50 ID Profile (=1) Present = 1
51
52
53 STA Control STA MAC Capability
Non‐Inheritance
...
54 field Address Information
Element 1 ... Element n element
55 (optional)
56 Field and Element order as defined in Table 9‐34 Last element
57 STA Control STA Info (subject to inheritance)
58 STA Profile
59
60
61 Figure 35-3—Example of Basic Multi-Link element in an Association Request
62 frame(#4248)(#6700)(#1050)(#1778)(#2165)
63
64
65

Copyright © 2022 IEEE. All rights reserved. 377

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#1184)(#1185)(#2866)(#3335)(#2309)(#2964)In Figure 35-3 (Example of Basic Multi-Link element in an

2 Association Request frame(#4248)(#6700)(#1050)(#1778)(#2165)), a STA affiliated with a non-AP MLD
3
transmits an Association Request frame which includes (#6700)Basic Multi-Link element that carries the
4
5 complete profile of two other STAs affiliated with its non-AP MLD (STA x and STA y). The figure expands
6 the Per-STA profile for one of the reported STAs. The Type subfield of the Multi-Link Control field is set to
7 0 to indicate that the Multi-Link element is a (#6700)Basic Multi-Link element. The Common Info field
8 carries information that applies to the MLD level as described in 9.4.2.312.2 (Basic Multi-Link
9
element(#6700)). In this example, only the MLD MAC Address field is shown. However, there can be other
10
11 fields present in the common info portion whose presence is signaled via the subfields in the Multi-Link
12 Control field. Each Per-STA Profile subelement in the Link Info field carries the complete profile, with
13 inheritance applied, of a reported STA affiliated with the non-AP MLD. (#6878)Each Per-STA Profile
14 subelement carries the STA Control field followed by the STA Info field and the STA Profile field. In this
15
example, only the STA MAC Address field is shown. However, there can be other fields present in the STA
16
17 info portion whose presence is signaled via the subfields in the STA Control field. The STA Profile field
18 carries variable number of fields and elements in the order defined in Table 9-62 (Association Request
19 frame body(#1004)(#2246)(#3353)) with inheritance applied (see 35.3.2.3 (Inheritance in a per-STA
20 profile)).
21
22
23 35.3.2.3 Inheritance in a per-STA profile
24
25 35.3.2.3.1 Inheritance in the per-STA profile of Basic Multi-Link element(#6700)(#2416)
26
27
(#5737)(#5739)(#5047)(#2472)It is possible for STAs affiliated with an MLD to have similar capabilities
28
29 and operational parameters on different links. (#6536)As a result, an element that is applicable to a reported
30 STA might have the same value as the corresponding element applicable to the reporting STA and carried in
31 the frame outside the (#6700)Basic Multi-Link element. To reduce the frame size, when a Per-STA Profile
32 subelement carries complete profile for a reported STA, it inherits the elements from the reporting STA
33
based on the rules defined in this subclause.
34
35
36 (#5737)(#1862)(#2167)The inheritance mechanism described in this subclause shall apply only when the
37 Per-STA Profile subelement of the (#6700)Basic Multi-Link element carries complete profile of the reported
38 STA (i.e., the Complete Profile subfield in the STA Control field of the subelement is set to 1). (#4249)When
39
a Per-STA Profile subelement of the (#6700)Basic Multi-Link element carries partial profile for a reported
40
41 STA, the transmitting STA shall not apply the inheritance mechanism described in this subclause.
42
43 (#3021)(#3212)(#3369)(#3370)A STA that transmits a Management frame carrying the (#6700)Basic Multi-
44 Link element shall include an element that is specific to the reported STA in the complete profile of the
45
reported STA carried in the (#6700)Basic Multi-Link element. (#7812)(#5968)An element, identified by an
46
47 Element ID and Element ID Extension (if applicable), is considered specific to a reported STA if any of the
48 following conditions are satisfied:
49 — (#7812)at least one element with the same Element ID and Extended Element ID (if applicable) is
50
51 present in the frame that carried the Basic Multi-Link element but the contents of the Information
52 field is not the same for the reported STA (#7812)if the reported STA were to transmit the same
53 Management frame subtype.
54
— the reported STA satisfies the condition for that element to be included in the (#7812)same
55
56 Management subtype as the frame that carries the (#6700)Basic Multi-Link element while the
57 reporting STA does not satisfy the corresponding condition.
58
59 (#7812)NOTE 1—For example, when there exists one or more Vendor Specific elements carried in a Management frame
60 that includes the Basic Multi-Link element containing a per-STA profile for a reported STA, and the contents of the
61 Information field for at least one of the Vendor Specific elements are not the same as that of at least one Vendor Specific
62 element that applies to the reported STA, then each Vendor Specific element that applies to the reported STA is included
63 in its Per-STA Profile subelement.
64
65

378 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 NOTE 2—The conditions to include an element in a particular Management frame are as specified in 9.3.3 ((PV0)
2 Management frames). For example, Table 9-63 (Association Response frame body(#1004)(#2246)(#3354)) specifies the
3 conditions for an element to be included in an Association Response frame.
4
5 (#7812)If an element, identified by an Element ID and Element ID Extension (if applicable), is carried in a
6
Management frame transmitted by the reporting STA, and there is no element having the same Element ID
7
8 and Element ID Extension (if applicable) in a complete profile of a reported STA, then the element is
9 considered to be part of the reported STA’s profile and the value to use is the same as that of the
10 corresponding element carried in the reporting STA’s frame (#6536)unless any of the following are true:
11
12 — the complete profile carries the Non-Inheritance element (see 9.4.2.240 (Non-Inheritance element))
13 and the element is listed in the Non-Inheritance element(#1860).
14 — the element is excluded from being included in the Per-STA Profile subelement as described in
15
35.3.2.1 (General) and 35.3.2.2 (Advertisement of complete or partial per-link information(#1859)).
16
17
18 (#7812)Otherwise, the STA receiving the Management frame shall not consider the element to be part of the
19 reported STA’s profile.
20
21 (#7812)NOTE 3—The above rules do not apply for the case when the Basic Multi-Link element is carried in a
22 nontransmitted BSSID profile. See 35.3.20 (Multi-link operation in a multiple BSSID set or co-hosted BSSID
23 set(#1095)(#2292)(#2540)) for inheritance rules when the Basic Multi-Link element is carried in a Multiple BSSID
24 element.
25
26 (#7812)A Fragment element (see 9.4.2.188 (Fragment element)) is considered under the same context as the
27 element that is being fragmented. Therefore, when an element that is fragmentable (see Table 9-128
28
(Element IDs(#1009)(#1121)) and 10.28.11 (Element fragmentation)) is inherited (or not inherited), the
29
30 Fragment element(s) (if present) corresponding to that element shall also be inherited (or not inherited).
31
32 (#5737)(#3021)(#3212)Figure 35-4 (Example of inheritance in a complete per-STA
33 profile(#6700)(#8331)(#5907)(#3021)) illustrates inheritance when a per-STA profile carries complete
34
profile. The example shows a Management frame transmitted by a reporting STA that is affiliated with an
35
36 MLD. The Management frame carries several elements with their corresponding element IDs shown in
37 parenthesis. The frame also carries a (#6700)Basic Multi-Link element which is carrying (#8331)two Per-
38 STA Profile subelements corresponding to STA 1 and STA 2. In this example, the profile for STA 1, which
39 is a complete profile is expanded to show the details of inheritance. The contents of the profile for STA 2 are
40
not shown in this illustration. The per-STA profile for STA 1 includes element with ID B since the element
41
42 has a value different from the corresponding elements carried in the frame. The profile also includes element
43 with ID D and ID Y that are specific to STA 1. In addition, elements with ID C and ID F are inherited and
44 are not carried in the profile for STA 1. The values for these two elements are the same as that carried in the
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 379

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 frame. Furthermore, elements with ID A and ID E are not applicable to STA 1 as their corresponding
2 (Extended) Element IDs are listed in the Non-Inheritance element.
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28 Figure 35-4—Example of inheritance in a complete per-STA pro-
29 file(#6700)(#8331)(#5907)(#3021)
30
31
32 35.3.2.3.2 Inheritance in the per-STA profile of Probe Request Multi-Link ele-
33 ment(#2416)(#6700)
34
35 (#5737)If a non-AP STA affiliated with a non-AP MLD requests the same partial profile for an AP to which
36 it sends an ML probe request and for another AP affiliated with the same AP MLD as the AP and that is
37
38 requested in the ML probe request (see 35.3.4.2 (Use of ML probe request and response(#2583)(#3360))),
39 the non-AP STA may include the (Extended) Request element only in the Probe Request frame body, and
40 this element will be inherited for the other requested AP even if it is not carried in the Per-STA Profile
41 subelement corresponding to the other requested AP, following the rules defined in 35.3.4.2 (Use of ML
42 probe request and response(#2583)(#3360)).
43
44
45 Figure 35-5 (Example of inheritance in a Request element for ML probe request(#6701)(#2416)) illustrates a
46 ML probe request transmitted by a non-AP STA that is affiliated with a non-AP MLD. (#5737)The non-AP
47 STA requests partial profile for three APs and complete profile for one AP, where all APs are affiliated with
48 the same AP MLD. The non-AP STA includes a Request element in the Probe Request frame body
49
50 requesting the element with element ID “a” for the AP to which the Probe Request frame is sent. The frame
51 carries a (#6701)Probe Request Multi-Link element that includes three Per-STA Profile subelements
52 requesting information for AP x, AP y, AP z.
53
54 For AP x, the non-AP STA requests the element with element ID “a”, which is the same as the element
55
56 requested for the AP. Hence, the Complete Profile subfield for the per-STA profile x is set to 0 and the per-
57 STA profile does not include the Request element in the STA Profile field by inheritance rule. For AP y, the
58 non-AP STA requests the element with element ID “b”, which is not requested for the AP. Hence, the
59 Complete Profile subfield for the per-STA profile y is set to 0 and the per-STA profile includes the Request
60 element in the STA Profile field. (#5737)The non-AP STA requests the complete profile for AP z. The
61
62
63
64
65

380 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Complete Profile subfield for the per-STA profile z is set to 1 and the per-STA profile does not include any
2 elements in the STA Profile field.
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28 Figure 35-5—Example of inheritance in a Request element for ML probe
29 request(#6701)(#2416)
30
31
32 35.3.3 Multi-link device addressing
33
34 An MLD has an MLD MAC address that singly identifies the MLD.
35
36 (#4250)(#2374)Each STA affiliated with an MLD shall have a different MAC address.
37
38 (#2759)NOTE 1—The MLD MAC address of an MLD might be the same as the MAC address of one affiliated STA or
39 different from the MAC address of any affiliated STA.
40
41 (#8227)For an individually addressed frame sent on a link between two MLDs, the following applies:
42
43 — (#8230)(#1158)the value of the Address 2 (TA) field (if present) in the MAC header of the frame
44 shall be the MAC address of the transmitting STA affiliated with the MLD corresponding to that link
45 except for(#2474) the Individual/Group bit, which is set to 1 when the TA field value is a bandwidth
46
signaling TA and set to 0 otherwise.
47
48 — (#8227)the value of the Address 1 (RA) field in the MAC header of the frame shall be the MAC
49 address of the receiving STA affiliated with the MLD corresponding to that link.
50
51 — (#6185)(#8228)(#1670)the value of the Address 3 field and the Address 4 field (if present) in the
52 MAC header of a data frame shall be set based on Table 9-30 (Address field contents) and the
53 settings of the To DS and From DS bits, where the BSSID is the MAC address of the AP affiliated
54 with the AP MLD corresponding to that link.
55
56 (#4032)NOTE 2—For frames sent over a direct path in a single link TDLS direct link, by a STA affiliated with a non-AP
57 MLD, the value of the Address 2 (TA) field is set to the MLD MAC address of the non-AP MLD as described in
58 35.3.21.2 (TDLS direct link over a single link).
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 381

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 35.3.4 Discovery of an AP MLD

2
3
35.3.4.1 AP behavior
4
5
6 (#2854)(#2299)(#1866)(#2968)(#2512)(#1865)If an AP is affiliated with(#6398) an AP MLD and does not
7 correspond to a nontransmitted BSSID, then the Beacon and Probe Response frames transmitted by the AP
8 shall include a TBTT Information field in a Reduced Neighbor Report element with the Neighbor AP TBTT
9
Offset subfield, the BSSID subfield, the Short-SSID subfield, the BSS Parameters subfield, the 20 MHz
10
11 PSD subfield(#1186), and the MLD Parameters subfield, for each of the other APs affiliated with(#6398) the
12 same AP MLD.
13
14 (#6398)(#5971)(#5970)If an AP (AP 1) is affiliated with an AP MLD (AP MLD 1) and corresponds to a
15
nontransmitted BSSID, then the Beacon and Probe Response frames transmitted by the AP (AP 2)
16
17 corresponding to the transmitted BSSID of the same multiple BSSID set as the AP (AP 1) shall include a
18 TBTT Information field in a Reduced Neighbor Report element with the Neighbor AP TBTT Offset subfield,
19 the BSSID subfield, the Short-SSID subfield, the BSS Parameters subfield, the 20 MHz PSD
20 subfield(#1186), and the MLD Parameters subfield, for each of the other APs affiliated with the same AP
21
MLD (AP MLD 1)(#1671)(#1418)(#1039)(#1780)(#1781)(#2298).
22
23
24 (#4252)(#2589)(#2867)If all the following conditions are true:
25 — (#6194)a reporting AP is affiliated with an AP MLD (AP MLD 1) and is in the same co-located AP
26
27 set as APs affiliated with another AP MLD (AP MLD 2)
28 — the other AP MLD (AP MLD 2) has no affiliated APs operating on the same channel as the reporting
29 AP
30
31 — one AP affiliated with the other AP MLD (AP MLD 2) is in the same multiple BSSID set as an AP
32 affiliated with the AP MLD (AP MLD 1) of the reporting AP
33
34 then each AP of the other AP MLD (AP MLD 2) shall be reported in a TBTT Information field with the
35
36 Neighbor AP TBTT Offset subfield, the BSSID subfield, the Short-BSSID subfield, the BSS Parameters
37 subfield, the 20 MHz PSD subfield, and the MLD Parameters subfield in the Reduced Neighbor Report
38 element that is included in the Beacon frames and broadcast Probe Response frames transmitted by the
39 reporting AP, unless the APs of the other AP MLD (AP MLD 2) are already reported in Beacon frames and
40 broadcast Probe Response frames transmitted by an AP in the same co-located AP set as the reporting AP
41
42 and operating on the same channel as the reporting AP.
43
44 (#2295)(#2972)(#3361)(#1041)(#1923)(#1973)(#1924)(#1925)(#1068)(#5603)If a reporting AP reports an
45 AP affiliated with an MLD in a Reduced Neighbor Report element with the MLD Parameters subfield
46 present in the TBTT Information field for that AP, then the reporting AP shall set the MLD ID, the link ID,
47
48 and the BSS Parameters Change Count subfields as described in 9.4.2.170.2 (Neighbor AP Information
49 field). (#5123)(#8164)If an AP is affiliated with an AP MLD, it shall not have a BSSID index set to 255.
50
(#8231)(#2820)NOTE—The MLD ID subfield in the Reduced Neighbor Report element is used to determine the AP
51
MLD with which the reported AP is affiliated, especially when multiple AP MLDs are reported in the same frame.
52
53
54 (#6970)The TBTT offset between two APs affiliated with the same AP MLD shall never be larger than 254
55 TUs. An AP affiliated with an AP MLD shall not set the Neighbor AP TBTT Offset subfield to 255 for an
56 AP affiliated with the same AP MLD, except under the rules defined in 35.3.11 (Multi-link procedures for
57 channel switching, extended channel switching, and channel quieting(#4112)(#2324)(#2600)).
58
59
60 35.3.4.2 Use of ML probe request and response(#2583)(#3360)
61
62 (#2583)(#3360)(#1187)An ML probe request is a Probe Request frame that is sent outside the context of
63 active scanning that is used to discover an AP:
64
65

382 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — (#1045)(#1187)(#1673)(#2150)with the Address 1 field set to the broadcast address and the
2 Address 3 field set to the BSSID of an AP, or with the Address 1 field set to the BSSID of an AP’s
3
BSS.
4
5 — (#6262)(#6237)(#6238)with the MLD ID subfield (if present) set to the MLD ID that identifies the
6 targeted AP MLD with which the requested AP(s) are affiliated.
7
8 — (#1808)(#2124)(#3217)and that includes a (#6701)Probe Request Multi-Link element defined in
9 9.4.2.312.3 (Probe Request Multi-Link element(#6701)).
10
11 (#6262)(#6237)(#6238)If either the Address 1 field or the Address 3 field of the ML probe request is set to
12
the MAC address of the AP affiliated with an AP MLD that corresponds to the nontransmitted BSSID, then
13
14 the MLD ID subfield shall not be present in the Probe Request Multi-Link element of the ML probe request
15 and the AP MLD is the targeted AP MLD.
16
17 (#6262)(#6237)(#6238)If either the Address 1 field or the Address 3 field of the ML probe request is set to
18
the MAC address of the responding AP that operates on the same link where the ML probe request is sent,
19
20 then the MLD ID subfield shall be present in the Probe Request Multi-Link element of the ML probe request
21 and the targeted AP MLD is identified by the MLD ID subfield.
22
23 (#1046)(#2151)(#2583)(#3360)(#1675)An ML probe request allows a non-AP STA to request an AP to
24
include the complete or partial set of capabilities, parameters and operation elements of
25
26 (#6262)(#6237)(#6238)the AP(s) affiliated with the targeted AP MLD in the response frame. An AP
27 affiliated with the targeted AP MLD is a requested AP if one of the following conditions is met:
28 — the Probe Request Multi-Link element in the Probe Request frame does not include any per-STA
29
30 profile.
31 — (#1420)the link ID of the AP is equal to the value in the Link ID field in a Per-STA Profile
32 subelement in the Probe Request Multi-Link element in the Probe Request frame.
33
34
35 (#5737)(#1744)(#1047)The complete profile of a requested AP is defined in 35.3.2.2 (Advertisement of
36 complete or partial per-link information(#1859)).
37
38 (#5737)(#2416)The partial profile of a requested AP sent by a reporting AP consists of one or more elements
39
that are requested in the (Extended) Request element carried in the ML probe request.
40
41
42 (#5737)(#2416)If a STA affiliated with a non-AP MLD sends an ML probe request to an AP to retrieve
43 partial profile for AP(s) affiliated with the (#6262)(#6237)(#6238)targeted AP MLD, the STA shall include
44 the (Extended) Request element in the Probe Request frame body and/or a Per-STA Profile subelement in a
45
(#6701)Probe Request Multi-Link element carried in the Probe Request frame. In this case, the Complete
46
47 Profile subfield of the STA Control field in the Per-STA Profile subelement shall be set to 0. (#5737)The
48 (Extended) Request element carried in the per-STA profile corresponding to the requested AP that requests
49 the same partial profile as the AP can be inherited from the (Extended) Request element in the frame body,
50 subject to the rules defined in 35.3.2.3.2 (Inheritance in the per-STA profile of Probe Request Multi-Link
51
element(#2416)(#6700)).
52
53
54 (#5737)(#2416)An ML probe request allows a non-AP STA to request an AP to include the complete profile
55 of all APs affiliated with the (#6262)(#6237)(#6238)targeted AP MLD if the Probe Request frame does not
56
57
include the (Extended) Request element in the frame body and the (#6701)Probe Request Multi-Link
58 element in the Probe Request frame does not include any per-STA profile.
59
60 (#5737)(#2416)An ML probe request allows a non-AP STA to request an AP to include the same requested
61 partial profile for all APs affiliated with the (#6262)(#6237)(#6238)targeted AP MLD if the Probe Request
62
frame includes the (Extended) Request element in frame body and the (#6701)Probe Request Multi-Link
63
64 element in the Probe Request frame does not include any per-STA profile.
65

Copyright © 2022 IEEE. All rights reserved. 383

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#1155)(#1414)(#2581)(#3367)(#3359)(#2859)An ML probe response is a Probe Response frame:

2
3 — that is transmitted in response to receiving an ML probe request
4 — and that includes (#6700)Basic Multi-Link element which can carry complete or partial per-STA
5 profile(s), based on the soliciting request, for each of the requested AP(s) of the
6
(#6262)(#6237)(#6238)targeted AP MLD.
7
8
9 (#5737)(#2416)(#2583)(#3360)(#1422)If an AP that is affiliated with an AP MLD receives an ML probe
10 request from a non-AP STA requesting complete profile, it shall respond with an ML probe response, which
11 is a Probe Response frame that includes a (#6700)Basic Multi-Link element with (#2419)a per-STA profile
12
with complete profile for each of the APs that are affiliated (#6262)(#6237)(#6238)with the targeted AP
13
14 MLD and that are requested by the ML probe request, subject to the rules defined in 11.1.4.3.4 (Criteria for
15 sending a response)(#1048). (#5737)If it receives an ML probe request from a non-AP STA requesting
16 partial profile, it shall respond with an ML probe response that includes a (#6700)Basic Multi-Link element
17 with (#2419)a per-STA profile with at least the elements requested from the (Extended) Request element for
18
each of the APs that are affiliated (#6262)(#6237)(#6238)with the targeted AP MLD and that are requested
19
20 by the ML probe request, unless the elements requested are not part of the complete profile for each of the
21 APs and subject to the rules defined in 11.1.4.3.4 (Criteria for sending a response)(#1048).
22
23 (#5737)(#2583)(#3360)(#1423)If an AP that is operating in the 2.4 GHz band or the 5 GHz band that is part
24
of an AP MLD receives an ML probe request requesting complete profile and responds with an ML probe
25
26 response (per 11.1.4.3.4 (Criteria for sending a response)), the Address 1 field of the Probe Response frame
27 may be set to the broadcast address unless the AP is not including its actual SSID in the SSID element of its
28 Beacon frames.
29
30 (#1049)(#1926)(#2421)(#2592)(#2858)NOTE—An AP operating in 6 GHz sets the Address 1 field of the Probe
31 Response frame to broadcast address as defined in 26.17.2.3.2 (AP behavior for fast passive scanning).
32
33 (#5737)(#1676)(#1042)(#1044)None of the non-AP STAs of a non-AP MLD shall send an ML probe
34 request to an AP of the AP MLD in the corresponding link if any non-AP STA of the same non-AP MLD has
35
already received a ML probe response including complete profile from any of the AP of the AP MLD in any
36
37 link, since the MLME-SCAN.request primitive with ScanType parameter indicating an active scan was
38 issued.
39
40 35.3.4.3 Non-AP MLD behavior(#6687)(#1010)(#1020)
41
42
43 A non-AP MLD shall be able to discover an AP MLD when it receives a (#6700)Basic Multi-Link element
44 carried in a Beacon frame or Probe Response frame, that is not an ML probe response, transmitted by an AP
45 affiliated with the AP MLD or by the AP corresponding to the transmitted BSSID in the same multiple
46 BSSID set as at least one of the APs affiliated with the AP MLD.
47
48
49 A non-AP MLD shall be able to discover an AP MLD and the capabilities and operational parameters of one
50 or more APs affiliated with an AP MLD (#4740)when its affiliated STA receives an ML probe response
51 from an AP affiliated with the AP MLD or the AP corresponding to the transmitted BSSID in the same
52 multiple BSSID set as at least one of the APs affiliated with the AP MLD and the ML probe response carries
53
a (#6700)Basic Multi-Link element with a complete profile of the reported AP.
54
55
56 A non-AP MLD shall be able to discover an AP (#4741)(reported AP) as an AP affiliated with an AP MLD
57 when its affiliated STA receives a Beacon or Probe Response frame transmitted by an AP (reporting AP) and
58 the frame carries a Reduced Neighbor Report element that includes the MLD Parameters subfield in the
59
TBTT Information field corresponding to the reported AP. A non-AP MLD shall be able to infer the
60
61 relationship between the reported AP and the reporting AP by decoding the MLD ID subfield of the MLD
62 Parameters subfield in the Reduced Neighbor Report element and following the rules described in 35.3.4.1
63 (AP behavior).
64
65

384 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 A non-AP MLD may use the information it gathers from a Reduced Neighbor Report element and a
2 (#6700)Basic Multi-Link element to decide whether to perform multi-link setup with an AP MLD.
3
4
5 A non-AP MLD shall be able to discover an AP MLD when it receives a Neighbor Report element carried in
6 a Management frame. If the (#6700)Basic Multi-Link element is present in the Neighbor Report element for
7 a reported AP, then the reported AP is affiliated with an AP MLD. The non-AP MLD shall be able to obtain,
8 based on the contents of the Common Info field of the (#6700)Basic Multi-Link element, the MLD
9
information for the AP MLD with which the reported AP is affiliated. A non-AP MLD may use the
10
11 information it receives from a Neighbor Report element to make a decision on performing multi-link
12 (re)setup (see 35.3.5 (Multi-link (re)setup)) or BSS transition (see 4.5.3.2 (Mobility types)). A non-AP MLD
13 shall be able to determine that two or more APs reported in different Neighbor Report elements (#4046)that
14 include the Basic Multi-Link subelement are affiliated with the same AP MLD if the values carried in MLD
15
MAC Address field of the Common Info field of the Basic Multi-Link element of the reported APs are the
16
17 same.
18
19 35.3.4.4 Multi-Link element usage rules in the context of discovery
20
21
(#6267)(#3016)(#1005)(#1896)(#1155)(#1414)(#2581)(#3367)(#3359)(#2859)(#2241)(#2295)If an AP
22
23 affiliated with an AP MLD is not in a multiple BSSID set or the AP corresponds to a transmitted BSSID in a
24 multiple BSSID set, the AP shall include, in a Beacon frame or a Probe Response frame, which is not an ML
25 probe response, only the Common Info field of the (#6700)Basic Multi-Link element for the AP MLD as
26 defined in 9.4.2.312 (Multi-Link element) unless conditions in 35.3.11 (Multi-link procedures for channel
27
switching, extended channel switching, and channel quieting(#4112)(#2324)(#2600)) are satisfied.
28
29
30 (#6267)If an AP affiliated with an AP MLD corresponds to a nontransmitted BSSID in a multiple BSSID
31 set, then the AP that corresponds to the transmitted BSSID in the same multiple BSSID set shall include, in
32 the nontransmitted BSSID profile corresponding to the nontransmitted BSSID in a Beacon frame or a Probe
33
Response frame, which is not an ML probe response, only the Common Info field of the Basic Multi-Link
34
35 element for the AP MLD as defined in 9.4.2.312 (Multi-Link element) unless conditions in 35.3.11 (Multi-
36 link procedures for channel switching, extended channel switching, and channel
37 quieting(#4112)(#2324)(#2600)) are satisfied.
38
39
(#4048)The Common Info field of the Basic Multi-Link element carried in the Beacon frame or Probe
40
41 Response frame, which is not an ML probe response, shall include MLD MAC address, the Link ID Info, the
42 BSS Parameters Change Count, and the MLD Capabilities subfields, and may include the EML Capabilities
43 subfield as defined in 35.3.18 (Enhanced multi-link multi-radio operation).
44
45
(#2583)(#3360)A Probe Request frame that is not an ML probe request shall not include a Multi-Link
46
47 element of any type.
48
49 (#1192)(#2581)(#3367)(#6700)A Probe Request frame that is an ML probe request shall include a Probe
50 Request Multi-Link element and shall not include other variant Multi-Link element.
51
52
53 (#2494)(#5051)An AP affiliated with an AP MLD shall have a unique link ID that (#6604)is advertised to
54 the non-AP MLDs and shall not change during the lifetime (#4256)of each of the BSSes that are setup by the
55 AP MLD. The Link ID field in the per-STA profile corresponding to this AP in the Multi-Link element
56 corresponding to this AP MLD shall be set to the unique link ID value of this AP.
57
58
59 35.3.4.5 Active scanning for a non-AP EHT STA
60
61 If a non-AP EHT STA is sending a Probe Request frame:
62
63 — it shall include the SSID element,
64
65

Copyright © 2022 IEEE. All rights reserved. 385

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — it may include, if the conditions in 9.3.3.9 (Probe Request frame format) are met, the Request
2 element, the SSID List element, the Extended Request element, the FILS Request Parameters
3
element, the Short SSID List element, Vendor Specific elements, the (#6701)Probe Request Multi-
4
5 Link element, and the Known BSSID element,
6 — in the context of active scanning, it shall not include the other elements listed in 9.3.3.9 (Probe
7 Request frame format),
8
9 — outside the context of active scanning, it may include the other elements listed in 9.3.3.9 (Probe
10 Request frame format).
11
12
35.3.5 Multi-link (re)setup
13
14
15 35.3.5.1 Multi-link (re)setup procedure
16
17 Before a non-AP MLD performs multi-link (re)setup with an AP MLD, the non-AP MLD and AP MLD
18
shall follow MLD authentication procedure as described in 11.3 (STA authenticationAuthentication and
19
20 association(#2277)).
21
22 For a non-AP MLD to perform multi-link (re)setup with an AP MLD, the non-AP MLD and the AP MLD
23 shall exchange (Re)Association Request/Response frames and shall follow the MLD (re)association
24
procedure as described in 11.3 (STA authenticationAuthentication and association(#2277)). (#1027)A
25
26 (Re)Association Request/Response frame exchange is for a multi-link setup if both the frames carried
27 (#6700)Basic Multi-Link element. Otherwise, the (Re)Association Request/Response frame
28 exchange(#6271) is not for a multi-link setup.
29
30
(#2063)In the (Re)Association Request frame, the non-AP MLD indicates the links that are requested for
31
32 (re)setup (#1805)and the capabilities and operational parameters of the requested links as described in
33 35.3.5.4 (Usage and rules of Basic Multi-Link element in the context of multi-link (re)setup(#6700)).
34 (#2475)The non-AP MLD may request to (re)set up(#6452) links with a subset of APs affiliated with the AP
35 MLD.
36
37 (#1847)NOTE—The links that are requested for resetup and the capability and operation parameters of each link that are
38 requested for resetup are independent of the existing setup links with an associated AP MLD and the capability and
39 operation parameters of each setup link with an associated AP MLD.
40
41 In the (Re)Association Response frame, the AP MLD shall indicate(#6272) the requested links that are
42
accepted and the requested links that are rejected for (re)setup (#1805)and the capabilities and operational
43
44 parameters of the requested links as described in 35.3.5.4 (Usage and rules of Basic Multi-Link element in
45 the context of multi-link (re)setup(#6700))(#5255). (#2475)The AP MLD may not accept all the links that
46 are requested for (re)setup. The AP MLD may accept a subset of the links that are requested for
47 (re)setup(#5299)(#2593). The (Re)Association Response frame shall be sent to the non-AP STA affiliated
48
with the non-AP MLD that sent the (Re)Association Request frame.
49
50
51 (#1025)The AP MLD shall not accept a link that is requested for (re)setup if any of the following condition
52 is true:
53
54 — The non-AP STA affiliated with the non-AP MLD corresponding to the link does not support all of
55 the rates in the BSSBasicRateSet parameter and all of the membership selectors in the
56 BSSMembershipSelectorSet parameter of the AP affiliated with the AP MLD corresponding to the
57 link in the MLME-START.request primitive.
58
59 — The non-AP STA affiliated with the non-AP MLD corresponding to the link does not support all of
60 the MCSs in the Basic HT-MCS Set field of the HT Operation parameter in of the AP affiliated with
61 the AP MLD (if present) corresponding to the link in the MLME-START.request primitive.
62
63 — The non-AP STA affiliated with the non-AP MLD corresponding to the link does not support all of
64 the <VHT-MCS, NSS> tuples indicated by the Basic VHT-MCS And NSS Set field of the VHT
65

386 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Operation parameter of the AP affiliated with the AP MLD (if present) corresponding to the link in
2 the MLME-START.request primitive.
3
4 — The non-AP STA affiliated with the non-AP MLD corresponding to the link does not support all of
5 the <HE-MCS, NSS> tuples indicated by the Basic HE-MCS And NSS Set field of the HE Operation
6 parameter of the AP affiliated with the AP MLD corresponding to the link in the MLME-
7 START.request primitive.
8
9 — The non-AP STA affiliated with the non-AP MLD corresponding to the link does not support all of
10 the <EHT-MCS, NSS> tuples indicated by the Basic EHT-MCS And NSS Set field of the EHT
11 Operation parameter of the AP affiliated with the AP MLD corresponding to the link in the MLME-
12
START.request primitive.
13
14
15 (#1656)An MLD that requests or accepts multi-link (re)setup for any two links ensures that each link is
16 located on different nonoverlapping channels.
17
18
(#6499)(#4066)(#4392)An AP MLD shall assign a single AID to a non-AP MLD upon successful multi-link
19
20 setup. All the STAs of the non-AP MLD shall have the same AID as the one assigned to the non-AP MLD
21 during multi-link setup.
22
23 After successful multi-link (re)setup between a non-AP MLD and an AP MLD, the non-AP MLD and the
24
AP MLD set up(#6452) links for multi-link operation (#1783)(see 35.3 (Multi-link operation) and the rest of
25
26 the subclause 35.3 (Multi-link operation)), and the non-AP MLD is (re)associated with the AP MLD (i.e., in
27 State 3 or State 4, see 11.3.2 (State variables))(#5298).
28
29 For each setup link, the corresponding non-AP STA affiliated with the non-AP MLD is in the same
30
associated state as the non-AP MLD and is associated with the corresponding AP affiliated with the AP
31
32 MLD, without providing the corresponding non-AP STA to the corresponding AP mapping to the
33 DS(#6112). For each setup link, the functionalities between a non-AP STA and its associated AP are enabled
34 unless the functionalities have been extended to (#1442)the MLD level and specified otherwise.
35
36
An example of multi-link setup is shown in Figure 35-6 (Example of multi-link setup(#2899)).
37
38
39
AP 1 AP 2 AP 3 AP 1 AP 2 AP 3
40 AP MLD
2.4 GHz 5 GHz 6 GHz
AP MLD
2.4 GHz 5 GHz 6 GHz
41 Successful
42 multi-link setup
Link 1 Link 2 Link 3
43 Association
Request
2.4
GHz
Association
Response
5
GHz
6
GHz
2.4 5 6
44 frame WM frame WM WM
GHz
WM
GHz
WM
GHz
WM
45
46
Non-AP Non-AP Non-AP Non-AP Non-AP Non-AP
47 Non-AP MLD
STA 1 STA 2 STA 3
Non-AP MLD
STA 1 STA 2 STA 3
48
49
50 Figure 35-6—Example of multi-link setup(#2899)
51
52
53 (#1052)In this example, (#2042)the AP MLD has three affiliated APs: AP 1 operates in the 2.4 GHz band,
54 AP 2 operates in the 5 GHz band, and AP 3 operates in the(#7366) 6 GHz band. (#2899)Non-AP MLD
55
56 initiates the multi-link setup procedure and non-AP STA 1 affiliated with the non-AP MLD sends an
57 Association Request frame to AP 1 affiliated with the AP MLD, i.e., the TA field of the Association Request
58 frame is set to the MAC address of the non-AP STA 1 and the RA field of the Association Request frame is
59 set to the MAC address of the AP 1. (#5737)The Association Request frame includes (#6273)(#1053)a Basic
60 Multi-Link element(#6700) that indicates the MLD MAC address of the non-AP MLD and complete
61
62 information of non-AP STA 1 (in the frame body of the Association Request frame), non-AP STA 2 (in a
63 Per-STA Profile subelement carried in the Basic Multi-Link element), and non-AP STA 3 (in a Per-STA
64 Profile subelement carried in the Basic Multi-Link element) to request three links to be setup (one link
65

Copyright © 2022 IEEE. All rights reserved. 387

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 between AP 1 and non-AP STA 1, one link between AP 2 and non-AP STA 2, and one link between AP 3
2 and non-AP STA 3). (#2899)AP MLD then responds to the requested multi-link setup, and AP 1 affiliated
3
with the AP MLD sends an Association Response frame to non-AP STA 1 affiliated with the non-AP MLD,
4
5 i.e., the TA field of the Association Response frame is set to the MAC address of the AP 1 and the RA field
6 of the Association Response frame is set to the MAC address of the non-AP STA 1, to indicate successful
7 multi-link setup. The Association Response frame includes a (#6273)(#1785)(#6700)Basic Multi-Link
8 element that indicates the MLD MAC address of the AP MLD and complete information of AP 1 (in the
9
frame body of the Association Request frame), AP 2 (in a Per-STA Profile subelement carried in the Basic
10
11 Multi-Link element), and AP 3 (in a Per-STA Profile subelement carried in the Basic Multi-Link element).
12 After successful multi-link setup between the non-AP MLD and AP MLD, three links are setup (link 1
13 between AP 1 and non-AP STA 1, link 2 between AP 2 and non-AP STA 2, and link 3 between AP 3 and
14 non-AP STA 3).
15
16
17 35.3.5.2 Multi-link security
18
19 (#2476)(#3133)After a successful multi-link (re)setup between a non-AP MLD and an AP MLD, a PMKSA
20 and PTKSA are established between the non-AP MLD and the AP MLD (see Clause 12 (Security)). The
21
PTKSA is used for cryptographic encapsulation across all setup links as described in 12.5.3.3 (CCMP
22
23 cryptographic encapsulation) and 12.5.5.3 (GCMP cryptographic encapsulation).
24
25 Different links use different GTK/IGTK/BIGTK and each link has its own PN space. The
26 GTK/IGTK/BIGTK of each setup links are delivered to the non-AP MLD using a single 4-way handshake as
27
defined in 12.7.6 (4-way handshake). (#2594)When a GTK/IGTK/BIGTK update is triggered for an AP
28
29 affiliated with the AP MLD, the updated GTK/IGTK/BIGTK may be delivered to the non-AP MLD using
30 the Group key handshake over any enabled link as defined in 12.7.7 (Group key handshake).
31
32 35.3.5.3 Multi-link tear down procedure
33
34
35 (#2377)For an MLD to tear down the setup links between the MLD and an associated peer MLD, one of the
36 STAs affiliated with the MLD shall send (#6274)a Disassociation frame to the STA affiliated with the peer
37 MLD on the corresponding link that is enabled (see 35.3.7.1.1 (General)), (#1055)and the MLD and the peer
38 MLD shall follow the MLD disassociation procedure as described in 11.3 (STA
39
authenticationAuthentication and association(#2277)).
40
41
42 After multi-link teardown, all the non-AP STAs affiliated with the non-AP MLD and the non-AP MLD are
43 in the unassociated state (see 11.3.2 (State variables))(#6276).
44
45
35.3.5.4 Usage and rules of Basic Multi-Link element in the context of multi-link
46
47 (re)setup(#6700)
48
49 (#6752)(#8234)(#6360)A non-AP MLD may initiate a multi-link setup with an AP MLD to (#2478)(re)set
50 up more than one link with a set of APs that are affiliated with the AP MLD. When a non-AP MLD initiates
51
a multi-link (re)setup with an AP MLD, a STA that is affiliated with the non-AP MLD shall transmit an
52
53 (Re)Association Request frame on the link that it desires to use as part of the multi-link (re)setup(#3153).
54 An AP that is affiliated with the AP MLD shall transmit an (Re)Association Response frame on the link on
55 which it received the (Re)Association Request frame.
56
57
(#5982)A STA affiliated with a non-AP MLD that initiates a multi-link (re)setup with an AP MLD shall
58
59 include a (#6700)Basic Multi-Link element in an (Re)Association Request frame it transmits.
60
61 The (#6700)Basic Multi-Link element carried in the (Re)Association Request frame shall include the
62 Common Info field and the Link Info field.
63
64
65

388 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#1747)(#1789)(#2348)The Common info field of the (#6700)Basic Multi-Link element carried in the
2 (Re)Association Request frame shall include the MLD MAC address, the MLD Capabilities, and the EML
3
Capabilities subfields, and shall not include the Link ID Info, the BSS Parameters Change Count, and the
4
5 Medium Synchronization Delay Information subfields.
6 (#1747)(#1789)(#2348)NOTE—The presence of the subfields in the Common Info field is signaled via the Multi-Link
7 Control field of the (#6700)Basic Multi-Link element as defined in 9.4.2.312.2 (Basic Multi-Link element(#6700)).
8
9
10 (#2125)(#2479)For each requested link in addition to the link on which the (Re)Association Request frame
11 is transmitted, the Link Info field (#6729)of the Basic Multi-Link element carried in the (Re)Association
12 Request frame shall contain the corresponding Per-STA Profile subelement(s). For each Per-STA Profile
13 subelement included in the Link Info field, the Complete Profile subfield of the STA Control field shall be
14
set to 1 (see 35.3.2.2 (Advertisement of complete or partial per-link information(#1859))).
15
16
17 (#1035)The Link ID subfield of the STA Control field of the Per-STA Profile subelement for the
18 corresponding non-AP STA that requests a link for multi-link (#6752)(re)setup with the AP MLD is set to
19 the link ID (#6753)of the AP affiliated with the AP MLD that is operating on that link. The link ID is
20
obtained during (#6399)multi-link discovery (#8235)(see 35.3.4 (Discovery of an AP MLD)).
21
22
23 (#7815)The AP that is affiliated with the AP MLD and that responds to an (Re)Association Request frame
24 that carries a (#6700)Basic Multi-Link element shall include a Basic Multi-Link element in the
25 (Re)Association Response frame that it transmits.
26
27
28 The (#6700)Basic Multi-Link element carried in the (Re)Association Response frame shall include the
29 Common Info field and the Link Info field.
30
31 (#1747)(#1789)(#2348)The Common info field of the (#6700)Basic Multi-Link element carried in the
32
(Re)Association Response frame shall include the MLD MAC address, the MLD Capabilities, the EML
33
34 Capabilities, the Link ID Info, and the BSS Parameters Change Count subfields.
35
36 (#1747)(#1789)(#2348)NOTE—The presence of the subfields in the Common Info field is signaled via the Multi-Link
37 Control field of the (#6700)Basic Multi-Link element as defined in 9.4.2.312.2 (Basic Multi-Link element(#6700)).
38
39 (#2125)For each requested link in addition to the link on which the (Re)Association Response frame is
40
41 transmitted, the Link Info field (#6729)of the Basic Multi-Link element carried in the (Re)Association
42 Request frame shall contain the corresponding Per-STA Profile subelement(s). For each Per-STA Profile
43 subelement included in the Link Info field, the Complete Profile subfield of the STA Control field shall be
44 set to 1 (see 35.3.2.2 (Advertisement of complete or partial per-link information(#1859))) and the Status
45 Code field included in the STA Profile subfield of the Per-STA Profile subelement shall indicate SUCCESS
46
47 if the link is accepted or the failure cause if the link is not accepted. (#6729)The Status Code field in the
48 (Re)Association Response frame body shall indicate, as defined in 9.4.1.9 (Status Code field), whether the
49 link on which the (Re)Association Request frame is received is accepted or not.
50
51 (#3220)If the link on which the (Re)Association Request frame was received cannot be accepted by the AP
52
53 MLD, the AP MLD shall treat the multi-link (re)setup as a failure and shall not accept any requested links.
54
55 (#6400)(#1035)The Link ID subfield of the STA Control field of the Per-STA Profile subelement for the AP
56 corresponding to a link is set to the link ID of the AP affiliated with the AP MLD that is operating on that
57 link.
58
59
60 (#4248)(#2044)A STA affiliated with an MLD shall include a (#4002)(#6700)Basic Multi-Link element in
61 an Authentication frame that it transmits with the following rules:
62
— the STA shall include the MLD MAC address of the MLD with which the STA is affiliated in the
63
64 Common Info field of the element
65

Copyright © 2022 IEEE. All rights reserved. 389

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — the STA shall set all subfields in the Presence Bitmap subfield of the Multi-Link Control field of the
2 element to 0
3
4 — the STA shall not include the Link Info field of the element.
5
6 35.3.6 Multi-Link reconfiguration(#4659)
7
8
9 35.3.6.1 General
10
11 Multi-link reconfiguration (ML reconfiguration, or reconfiguration for short) refers to a set of procedures
12 through which an AP MLD can add one or more affiliated APs to the AP MLD, or remove one or more
13 affiliated APs from the AP MLD.
14
15
16 35.3.6.2 Adding or removing affiliated APs
17
18 35.3.6.2.1 Adding new affiliated APs
19
20
21 An AP MLD may add new affiliated APs anytime. A new affiliated APs shall be announced through the
22 Basic Multi-Link element (by changing the Maximum Number Of Simultaneous Links field of the MLD
23 Capabilities field), and through the Reduced Neighbor Report element (by including a TBTTT Information
24 field for the new AP) in the Beacon and Probe Response frames.
25
26 NOTE—The MAC address of any new co-hosted AP is assumed to be within the address space defined by the value of
27 the Max Co-Hosted BSSID Indicator field (see 9.4.2.249 (HE Operation element) and 26.17.7 (Co-hosted BSSID set)).
28 Similarly, the MAC address of any new nontransmitted BSSID is assumed to be within the address space defined by the
29 value of the MaxBSSID Indicator (see 9.4.2.45 (Multiple BSSID element) and 11.1.3.8 (Multiple BSSID procedure)).
30
31 35.3.6.2.2 Removing affiliated APs
32
33
34 An AP MLD may remove one or more of its affiliated APs. The AP MLD shall announce the removal of any
35 affiliated AP through a Reconfiguration Multi-Link element (see 9.4.2.312.4 (Reconfiguration Multi-Link
36 element(#4659))) transmitted in all Beacon frames of all its affiliated APs, as well as all Probe Response
37 frames it transmits, until the affiliated AP has been removed.
38
39
40 For each affiliated AP that the AP MLD intends to remove, the Reconfiguration Multi-Link element shall
41 include a Per-STA Profile subelement with the subfields of the Per-STA Control field set as following: The
42 Link ID subfield shall identify the AP, the Complete Profile subfield shall be set to 0, the Delete Timer
43 Present subfield shall be set to 1, and the Delete Timer subfield shall be set to the number of TBTTs of that
44 affiliated AP before it is removed. The initial value of the Delete Timer subfield shall be longer than the
45
46 MLD max idle period. The Per-STA Profile subelement shall not include a STA Profile field.
47
48 Additionally, in order to terminate the BSS a to-be-removed affiliated AP belongs to (see 6.3.12 (Stop)), the
49 SME of that affiliated AP shall perform the following,
50
51 1) It shall follow the procedure in 11.21.7.3 (BSS transition management request) to notify all associ-
52 ated STAs that support BTM of the BSS termination, with the BSS Transition Management Request
53 frame fields set as follows:
54
55 — The Disassociation Imminent, BSS Termination Included, and Link Removal Imminent sub-
56 fields of the Request Mode field are set to 1; other subfields of the Request Mode field are
57 reserved.
58 — The Disassociation Timer field is set to the number of TBTTs of the affiliated AP before it
59 transmits a Disassociation frame to the STA(s) receiving the BSS Transition Management
60
61 Request frame. The Disassociation Timer field value shall point to a TBTT at or later than the
62 TBTT pointed to by the value of the Delete Timer field of the Reconfiguration Multi-Link ele-
63 ment in transmitted beacons.
64
65

390 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — The BSS Termination Duration field shall be present and contain a BSS Termination Duration
2 subelement (see 9.4.2.36 (Neighbor Report element)), with the BSS Termination TSF field of
3
the subelement set to the value of the TSF timer when the BSS the affiliated AP belongs to will
4
5 be terminated. The BSS Termination TSF field value shall indicate a time that is later than the
6 TBTT the Disassociation Timer field value points to.
7 — No other optional fields shall be present in the BSS Transition Management Request frame.
8
9 2) It shall start a disassociation timer with the initial value set to the value of the Disassociation Timer
10 field, and shall decrement the timer by one after transmitting each Beacon frame, until the timer has
11 the value of 0. The Disassociation Timer field in all subsequent transmitted BSS Transition Manage-
12 ment Request frames shall be set to the value of this timer.
13
14 3) Once the disassociation timer reaches a value of 0, and before the TSF indicated by the BSS Termi-
15 nation TSF field, it shall follow the procedure in 11.3.6.8 (AP, AP MLD, or PCP disassociation initi-
16 ation procedure) to transmit Disassociation frames to all associated STAs that are not affiliated with
17 a non-AP MLD. The affiliated AP shall not transmit Disassociation frames until the disassociation
18
timer has a value of 0.
19
20
21 At the TBTT indicated by the value of the Delete Timer subfield in transmitted Reconfiguration Multi-Link
22 elements, an associated non-AP MLD shall consider the link corresponding to the removed AP nonexistent,
23 and the SME of the affiliated STA associated with the removed affiliated AP shall delete any information
24
maintained for that link.
25
26
27 35.3.7 Link management
28
29 35.3.7.1 TID-to-link mapping
30
31
32 35.3.7.1.1 General
33
34 (#5244)The TID-to-link mapping mechanism allows an AP MLD and a non-AP MLD that performed or are
35 performing multi-link setup to determine how UL and DL Qos traffic corresponding to TID values between
36
0 and 7 will be assigned to the setup links for the non-AP MLD.
37
38
39 By default, all TIDs shall be mapped to all setup links for (#2068)both DL and UL (see 35.3.7.1.2 (Default
40 mapping mode)). When both MLDs have explicitly negotiated a TID-to-link mapping by following the
41 procedure defined in 35.3.7.1.3 (Negotiation of TID-to-link mapping), (#7060)a TID can be mapped to a
42
link set(#2908), which is a subset of setup links, spanning from only one setup link to all the setup links,
43
44 with restrictions defined in 35.3.7.1.3 (Negotiation of TID-to-link mapping).
45
46 (#8237)A setup link is defined as enabled for a non-AP MLD if at least one TID is mapped to that link either
47 in DL or in UL and is defined as disabled if no TIDs are mapped to that link both in DL and UL. At any
48
point in time, a TID shall always be mapped to at least one setup link both in DL and UL,
49
50 (#4051)(#6577)which means that a TID-to-link mapping change is only valid and successful if it will not
51 result in having a single TID for which the link set is made of zero setup links. (#4050)By default, all setup
52 links shall be enabled (see 35.3.7.1.2 (Default mapping mode)).
53
54
(#1496)(#5365)If a link is enabled for a non-AP MLD, it may be used for individually addressed frame
55
56 exchange, subject to the power state of the non-AP STA operating on that link and only MSDUs or A-
57 MSDUs with TIDs mapped to that link may be transmitted on that link between the corresponding STA and
58 AP of the non-AP MLD and AP MLD in the direction (DL/UL) corresponding to the TID-to-link mapping.
59 Individually addressed Management frames and Control frames may be sent on any enabled links between
60
the corresponding STA and AP of the non-AP MLD and AP MLD (#8237)both in DL and UL.
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 391

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#5365)(#6281)If a link is disabled for a non-AP MLD, it shall not be used for individually addressed frame
2 exchange between the corresponding STA and AP of the non-AP MLD and AP MLD, including
3
Management frames.
4
5 (#5365)NOTE 1—Group addressed frames delivery procedure is defined in 35.3.15 (Multi-link group addressed frame
6 delivery and reception).
7
8
If a TID is mapped in UL to a set of enabled links for a non-AP MLD, then the non-AP MLD may use any
9
10 link within this set of enabled links to transmit (#5365)individually addressed MSDUs or A-MSDUs
11 (#4451)corresponding to that TID.
12
13 (#4052)If a TID is mapped in DL to a set of enabled links for a non-AP MLD, then:
14
15 — (#1226)The non-AP MLD may retrieve (#5365)individually addressed buffered BUs buffered at the
16 AP MLD that are MSDUs or A-MSDUs corresponding to that TID on any link within this set of
17 enabled links.
18
19 — The AP MLD may use any link within this set of enabled links to transmit (#5365)individually
20 addressed MSDUs or A-MSDUs (#4451)corresponding to that TID, subject to the power state of the
21 non-AP STA on each of these links.
22
23 (#1788)(#1680)(#4053)NOTE 2—If the default mode is used, the non-AP MLD can retrieve BUs buffered by the AP
24 MLD on any setup link but the AP MLD can recommend a link as defined in 35.3.12.4 (Traffic indication).
25
26 (#4052)A non-AP MLD may retrieve buffered BUs that are MMPDUs buffered at the AP MLD on any
27 enabled link. An AP MLD may use any enabled links to transmit individually addressed bufferable
28
management frames that are not measurement MMPDUs, subject to the power state of the non-AP STA on
29
30 each of the links.
31
32 (#5753)If a STA affiliated with a non-AP MLD is in active mode on a link with a set of TIDs mapped for DL
33 transmission, its associated AP affiliated with the AP MLD shall transmit to the STA:
34
35 — MSDUs/A-MSDUs with that set of negotiated TIDs for the non-AP MLD, and
36 — MMPDUs that are not measurement MMPDUs for the non-AP MLD or its affiliated STAs,
37
38
39 unless it is transmitted to another STA affiliated with the same non-AP MLD and in active mode.
40 (#5753)NOTE 3—Operation with STAs affiliated with a non-AP MLD in power save mode are defined in 35.3.12.4
41 (Traffic indication).
42
43
44 35.3.7.1.2 Default mapping mode
45
46 (#1790)(#2427)(#2907)(#3377)(#3027)(#2908)Under this mode, all TIDs are mapped to all setup links for
47 DL and UL, and all setup links are enabled. A non-AP MLD and an AP MLD that performed multi-link
48
setup shall operate under this mode if a TID-to-link mapping negotiation for a different mapping did not
49
50 occur or was unsuccessful or torn down.
51
52 35.3.7.1.3 Negotiation of TID-to-link mapping
53
54
An MLD may support TID-to-link mapping negotiation. An MLD that supports TID-to-link mapping
55
56 negotiation has dot11TIDtoLinkMappingActivated equal to true and shall set to a nonzero value the TID-to-
57 link Mapping Negotiation Supported subfield in the MLD Capabilities field of the (#6700)Basic Multi-Link
58 element that it transmits. Otherwise it shall set the TID-to-link Mapping Negotiation Supported subfield to
59 0. If the TID-to-link Mapping Negotiation Supported subfield value received from a peer MLD is equal to 2,
60
the MLD shall send to the peer MLD only the TID-to-link Mapping element where all TIDs are mapped to
61
62 the same link set.
63
64
65

392 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 In a multi-link (re)setup procedure, a non-AP MLD may initiate a TID-to-link mapping negotiation by
2 including the TID-to-link Mapping element in the (Re)Association Request frame if an AP MLD has
3
indicated a support of TID-to-link mapping negotiation.
4
5
6 After receiving the (Re)Association Request frame containing the TID-To-Link Mapping element, the AP
7 MLD shall reply to the (Re)Association Request frame according to 11.3.5.3 (AP, AP MLD, or PCP
8 association receipt procedures), 11.3.5.5 (AP, AP MLD, or PCP reassociation receipt procedures), and
9
35.3.5 (Multi-link (re)setup), with the following additional rules:
10
11 — The AP MLD can accept the requested TID-to-link mapping in the TID-to-link Mapping element in
12 the received (Re)Association Request frame only if it accepts the multi-link (re)setup for all links on
13 which at least one TID is requested to be mapped. In this case, it shall not include in the
14
15 (Re)Association Response frame the TID-to-link Mapping element.
16 — Otherwise, it shall indicate rejection of the proposed TID-to-link mapping by including in the
17 (Re)Association Response frame the TID-to-link Mapping element that suggests a preferred TID-to-
18
link mapping.
19
20
21 After the multi-link (re)setup is successful (#5919)and 4-way handshake is complete (if RSNA is required),
22 to negotiate a new TID-to-link mapping, an initiating MLD with dot11TIDtoLinkMappingActivated equal
23 to true shall send an individually addressed TID-to-link Mapping Request frame to a responding MLD that
24
has indicated support of TID-to-link mapping negotiation.
25
26
27 After receiving the individually addressed TID-to-link Mapping Request frame, the responding MLD shall
28 send an individually addressed TID-to-link Mapping Response frame to the initiating MLD according to the
29 following rules:
30
31 — If the responding MLD accepts the requested TID-to-link mapping in the TID-to-link Mapping
32 element in the received TID-to-link Mapping Request frame, it shall set to 0 (SUCCESS) the Status
33 Code in the TID-to-link Mapping Response frame.
34
35 — Otherwise, the responding MLD shall indicate rejection of the proposed TID-to-link mapping by
36 setting to either 133 (DENIED_TID_TO_LINK_MAPPING) or
37 134 (PREFERRED_TID_TO_LINK_MAPPING_SUGGESTED) the Status Code in the TID-to-link
38 Mapping Response frame. The responding MLD may suggest a preferred TID-to-link mapping by
39
setting 134 (PREFERRED_TID_TO_LINK_MAPPING_SUGGESTED) the Status Code in the
40
41 TID-to-link Mapping Response frame and including the TID-to-link Mapping element in the TID-to-
42 link Mapping Response frame.
43
44 An MLD may suggest a preferred TID-to-link mapping to a peer MLD by sending an unsolicited TID-to-
45
link Mapping Response frame that includes the TID-to-link Mapping element and sets the Status Code to
46
47 134 (PREFERRED_TID_TO_LINK_MAPPING_SUGGESTED). An MLD shall not send an unsolicited
48 TID-to-link Mapping Response frame that includes the TID-to-link Mapping element and sets the Status
49 Code to 0 (SUCCESS).
50
51
If indicated by a peer MLD, an MLD should take into account the preferred TID-to-link mapping when it
52
53 initiates a new TID-to-link mapping. In addition, an AP MLD should take into account the traffic flow(s)
54 affiliated with the non-AP MLD and the capabilities and constraints (if any) of the non-AP MLD.
55
56 NOTE 1—A non-AP MLD can indicate its constraints (such as single radio) during multi-link setup.
57
58 A multi-link multi-radio (MLMR) non-AP MLD should accept a TID-to-link mapping initiated by its
59 associated AP MLD.
60
61
When two MLDs have negotiated a TID-to-link mapping, either MLD may teardown the negotiated TID-to-
62
63 link mapping by sending an individually addressed TID-to-link Mapping Teardown frame. After teardown,
64 the MLDs shall operate in default mapping mode (see 35.3.7.1.2 (Default mapping mode)).
65

Copyright © 2022 IEEE. All rights reserved. 393

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 If an MLD has successfully negotiated the TID-to-link mapping with a peer MLD, both the MLD and the
2 peer MLD shall update an uplink and/or downlink TID-to-link mapping information according to the
3
negotiated the TID-to-link mapping. In case that a TID-to-link mapping of specific TID is missing in the
4
5 negotiation, the most recent TID-to-link mapping of this TID remains unchanged and valid.
6 NOTE 2—If there is no successfully negotiated TID-to-link mapping for missing TID, the default mapping is applied to
7 this TID.
8
9
10 When an MLD has successfully negotiated with a peer MLD an uplink and/or downlink TID-to-link
11 mapping in which the bit position i of the Link Mapping Of TID field in the TID-to-link Mapping element is
12 set to 0, the TID n shall not be mapped to the link associated with the link ID i in an uplink and/or downlink.
13
14
When an MLD has successfully negotiated with a peer MLD an uplink and/or downlink TID-to-link
15
16 mapping in which the bit position i of the Link Mapping Of TID n field in the TID-to-link Mapping element
17 is set to 1, the TID n shall be mapped to the link associated with the link ID i in an uplink and/or downlink.
18
19 35.3.7.1.4 Power state after enablement
20
21
22 (#1791)When a link becomes enabled for a STA that is affiliated with a non-AP MLD after successful MLD
23 association(#6608) with (Re)Association Request/Response frames transmitted on that link, the initial
24 power management mode of the STA, immediately after the acknowledgement of the (Re)Association
25 Response frame, is active mode.
26
27
28 (#2340)(#1062)(#3028)(#2851)When a link transitions to being enabled for a STA that is affiliated with a
29 non-AP MLD after successful MLD association(#6608) with (Re)Association Request/Response frames
30 transmitted on another link or after successful TID-to-link mapping negotiation with TID-To-Link Mapping
31 Request/Response frames transmitted on another link, the initial power management mode of the STA,
32
immediately after the acknowledgement of the (Re)Association Response frame or of the TID-To-Link
33
34 Mapping Response frame, is power save mode, and its power state is doze.
35
36 35.3.7.1.5 Power state after disablement(#5778)
37
38
When a link becomes disabled for a non-AP MLD:
39
40 — The TWT agreements and APSD scheduled SPs of the STA affiliated with the non-AP MLD and
41 operating on the link shall be deleted.
42
43 — The STA affiliated with the non-AP MLD and operating on the link may not maintain a power state
44 and power management mode.
45 — The AP associated to the STA affiliated with the non-AP MLD and operating on the link may not
46
47 maintain a power management status that indicates in which power management mode the STA is
48 currently operating.
49
50 A STA of a non-AP MLD that has transmitted a frame to the AP affiliated with its associated AP MLD on a
51 disabled link, if allowed by the rules defined in 35.3.7.1.1 (General) and from which it expects a response,
52
53 shall remain in the awake state until such a response is received or until the procedure has timed out.
54
55 35.3.7.1.6 Use of More Data subfield by an MLD
56
57 (#1195)(#1444)(#1882)An AP affiliated with an AP MLD uses the More Data subfield as defined in
58
59 9.2.4.1.8 (More Data subfield) to indicate to a non-AP STA in PS mode affiliated with the non-AP MLD that
60 more individually addressed BUs are buffered for that non-AP MLD. The indicated buffered BUs (not
61 including the BU currently being transmitted) are buffered at the AP MLD for the non-AP MLD and
62 correspond to Data frames with TIDs that are mapped to this link by the most recent DL TID-to-link
63 mapping (negotiated TID-to-link mapping or default mode mapping, see 35.3.7.1 (TID-to-link mapping)) or
64
65 Management frames that are not measurement MMPDUs (see 35.3.12.4 (Traffic indication)).

394 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 An AP affiliated with an AP MLD shall follow the procedure defined in 11.2.3.6 (AP operation) for setting
2 the More Data subfield and the EOSP subfield, except that in individually addressed frames the More Data
3
subfield is used to indicate the presence of more BUs at the AP MLD for a non-AP MLD, as defined above.
4
5
6 When a STA is affiliated with a non-AP MLD operating with default mapping (see 35.3.7.1.2 (Default
7 mapping mode)) receives an individually addressed MPDU from its associated AP affiliated with the
8 associated AP MLD with the More Data subfield set to 1, then at least one of any non-AP STA affiliated
9
with the non-AP MLD shall follow the procedure defined in 11.2.3.7 (Receive operation for STAs in PS
10
11 mode) and 11.2.3.8 (Receive operation using APSD) and may send PS-Poll frames or UAPSD trigger
12 frames to retrieve buffered BUs buffered at the AP MLD.
13
14 When a STA that is affiliated with a non-AP MLD operating with a negotiated non-default TID-to-link
15
mapping (see 35.3.7.1.3 (Negotiation of TID-to-link mapping)) receives an individually addressed MPDU
16
17 from its associated AP with the More Data subfield set to 1, then at least one of any STA affiliated with the
18 non-AP MLD that is operating on a link that is mapped to any of the TIDs that is also mapped to the link on
19 which the individually addressed MPDU with the more data bit set to 1 is sent (as specified by the most
20 recent DL TID-to-link mapping) shall follow the procedures defined in 11.2.3.7 (Receive operation for STAs
21
in PS mode) and 11.2.3.8 (Receive operation using APSD) and may send PS-Poll frames or UAPSD trigger
22
23 frames with any TID that is mapped to this operating link to retrieve the buffered BUs buffered at the AP
24 MLD.
25
26 35.3.7.2 Dynamic link transitions
27
28
29 A non-AP MLD may use the power states of its non-AP STAs to dynamically change the link(s) on which it
30 operates. Figure 35-7 (Example of operation of a single radio non-AP MLD with default mapping (all TIDs
31 mapped to all setup links), where the non-AP MLD transitions from operating on link 1 with STA 1 to
32 operating on link 2 with STA 2) provides an illustration of operation of a single radio non-AP MLD with
33
default mapping (all TIDs mapped to all setup links), where the non-AP MLD transitions from operating on
34
35 link 1 with STA 1 to operating on link 2 with STA 2.
36
37 AP MLD PPDU transmission carrying BUs from
the AP MLD to the non‐AP MLD
Non‐AP MLD
38
39 AP1
STA1 awake STA1 awake STA1 awake
STA1
40 Link1
41
42 AP2
STA2 awake STA2 awake STA2 awake
STA2
Link2
43
44
45 Link3
AP3 STA3
46
47
48
49 Figure 35-7—Example of operation of a single radio non-AP MLD with default mapping (all
50 TIDs mapped to all setup links), where the non-AP MLD transitions from operating on link 1
51 with STA 1 to operating on link 2 with STA 2
52
53
54 While operating on link 1:
55
56 — STA 1 of the non-AP MLD may use active mode or power save mode with the awake state to
57 retrieve BUs from the AP MLD and may use power save mode with doze state to save power.
58
— STA 2 and STA 3 stay in doze state.
59
60
61 While operating on link 2:
62 — STA 2 of the non-AP MLD may use active mode or power save mode with the awake state to
63
64 retrieve BUs from the AP MLD and may use power save mode with doze state to save power.
65

Copyright © 2022 IEEE. All rights reserved. 395

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — STA 1 and STA 3 stay in doze state.

2
3
35.3.8 Block ack procedures in Multi-link operation(#4111)
4
5
6 (#7602)An originator MLD shall maintain a single transmit buffer control that uses WinStartO and WinSizeO
7 for each block ack agreement negotiated with the recipient MLD to submit MPDUs for transmission across
8
links subject to TID-to-Link mapping restriction (see 35.3.7 (Link management)). An originator MLD shall
9
10 release transmit buffer associated with an successful received MPDU upon receiving BlockAck frame
11 containing the reception status for that MPDU.
12
13 (#1751)An MLD shall follow the mechanisms defined in 11.5 (Block ack operation) and 35.4 (EHT
14
acknowledgment procedure(#4111)(#5167)) with additional rules as defined in this subclause for
15
16 performing block ack operation.
17
18 (#1684)(#3029)For each TID, there shall not be more than one block ack agreement established between
19 two MLDs and the agreement shall apply to all the links to which the TID is mapped to (i.e., there are no
20
independent block ack agreements for each TID on a per-link basis).
21
22
23 (#2870)(#2871)In this subclause, the MLD with data to send using the block ack mechanism is referred to as
24 the originator MLD, and the receiver of that data as the recipient MLD. To setup a block ack agreement
25 between two MLDs, a STA affiliated with the originator MLD (#1930)shall send an ADDBA Request frame
26
(#1931)to the corresponding STA affiliated with the recipient MLD, on any enabled link, indicating the TID
27
28 for which the block ack agreement is being set up. (#1199)The Buffer Size, Extended Buffer Size, and Block
29 Ack Timeout fields in the ADDBA Request frame are advisory. (#1932)(#1686)(#1446)(#1427)Upon
30 receiving an ADDBA Request frame, the recipient MLD shall respond, on any enabled link, with an
31 ADDBA Response frame subject to the power states of the STAs operating on the link. The recipient MLD
32
has the option of accepting or rejecting the request. If the recipient MLD accepts the request, then a block
33
34 ack agreement is established between the originator MLD and the recipient MLD for the TID specified in
35 the ADDBA frames as defined in 10.25.2 (Setup and modification of the block ack parameters).
36
37 NOTE 1—An originator MLD can attempt a retransmission of an ADDBA Request frame on any enabled link. A
38 recipient MLD can attempt a retransmission of an ADDBA Response frame on any enabled link.
39
40 (#1065)If an MLD has established a block ack agreement with another MLD, then QoS Data frames for the
41 TID associated with the block ack agreement may be exchanged between the two MLDs on any link to
42 which the TID is mapped by following the procedure described in 35.3.7.1 (TID-to-link mapping) and
43
35.3.12 (Multi-link power management)(#1064).
44
45
46 (#3339)A STA affiliated with a recipient MLD shall provide, to the STA affiliated with the originator MLD
47 that is operating on the same link, the reception status for any MPDU, with ACK policy other than No Ack,
48 that is received on the link on which the STA affiliated with the recipient MLD is operating on.
49
(#2353)(#3340)(#2837)When a TID is mapped to more than one link, a STA affiliated with a recipient MLD
50
51 may provide (if available), to the STA affiliated with the originator MLD that is operating on the same link,
52 reception status indicating successful reception of any MPDU, which belongs to that TID and has an ACK
53 policy other than No Ack, that is received by a STA affiliated with the recipient MLD that is operating on a
54 different link.
55
56
57 An originator MLD shall update the reception status of an MPDU corresponding to a block ack agreement if
58 the received status indicates successful reception.
59
60 An originator MLD shall not update the reception status of an MPDU corresponding to a block ack
61
agreement that has already been acknowledged as successful.
62
63
64
65

396 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 A recipient MLD shall maintain a single common receive reordering buffer for each <peer MLD, TID>
2 tuple under a block ack agreement, independent of the number of links that are setup. The receive reordering
3
buffer shall be responsible for reordering MSDUs or A-MSDUs so that MSDUs or A-MSDUs are eventually
4
5 passed up to the next MAC process in the order of received sequence number. It shall also be responsible for
6 identifying and discarding duplicate frames (i.e., frames that have the same sequence number as a currently
7 buffered frame) that are part of this block ack agreement. It shall maintain its own state independent of the
8 scoreboard context control to perform this reordering as specified in 10.25.6.6 (Receive reordering buffer
9
control operation). Each received MPDU shall be analyzed by the scoreboard context control as well as by
10
11 the receive reordering buffer control.
12 (#1689)NOTE 2—A peer MLD is identified based on its MLD MAC address.
13
14
15 35.3.9 Fragmentation in multi-link operation
16
17 A STA affiliated with an MLD shall not use the nondynamic fragmentation procedure described in
18 10.4 (MSDU, A-MSDU, and MMPDU fragmentation).
19
20
21 35.3.10 BSS parameter critical update procedure
22
23 If an AP affiliated with an AP MLD is not in a multiple BSSID set or corresponds to a transmitted BSSID in
24 a multiple BSSID set, the AP shall
25
26 — (#1083)(#1231)(#4453)include in Beacon, Probe Response, and (Re)Association frames it transmits
27 a BSS Parameters Change Count subfield for each of all APs affiliated with the same AP MLD as the
28 AP.
29
30 • (#1070)(#1201)(#1202)The BSS Parameters Change Count subfield value for each AP is initial-
31 ized to 0, and shall be incremented (modulo 256) when a critical update occurs to the operational
32 parameters for that AP as defined in 11.2.3.15 (TIM Broadcast).
33 • (#1068)(#6255)In Beacon and Probe Response frames, the BSS Parameters Change Count sub-
34
field for each of the other AP(s) affiliated with the AP MLD shall be carried in the MLD Param-
35
36 eters subfield in the TBTT Information field of the Reduced Neighbor Report element
37 corresponding to that AP where each of the other AP(s) is identified by the Link ID subfield of
38 the MLD Parameters subfield.
39 • (#4453)(#4457)In the (Re)Association Response frame, the BSS Parameters Change Count sub-
40
field for each of the other AP(s) affiliated with the AP MLD shall be carried in the STA Info sub-
41
42 field in the Per-STA Profile subelement of Basic Multi-link element corresponding to that AP
43 where each of the other AP(s) is identified by the Link ID subfield of the STA Control field of
44 the Per-STA Profile subelement
45 • (#1067)(#1068)(#1691)The BSS Parameters Change Count subfield for the AP shall be carried
46
in the Common Info field of the (#6700)Basic Multi-Link element (#6255)where the AP is iden-
47
48 tified by the Link ID subfield of the Common Info field.
49 — (#5756)set the Critical Update Flag subfield of the Capability Information field to 1 in Beacon and
50 Probe Response frames up to and including the next DTIM Beacon frame on the link on which the
51
52 AP is operating if there is a change to a value carried in the BSS Parameters Change Count subfield
53 of the MLD Parameters field in the Reduced Neighbor Report element for any AP (#4456)affiliated
54 with the same AP MLD as the AP or a value carried in the BSS Parameters Change Count subfield in
55 the Common Info field of the (#6700)Basic Multi-Link element. Otherwise set the Critical Update
56 Flag subfield of the Capability Information field to 0.
57
58 — (#4064)(#5528)(#6639)For each reported AP affiliated with the same AP MLD as the AP, set the All
59 Updates Included subfield in the MLD Parameters subfield in the TBTT Information field of the
60 Reduced Neighbor Report element corresponding to the reported AP if the updated elements that
61
correspond to the latest critical update that generated a change to the value carried in the BSS
62
63 Parameters Change Count subfield for the reported AP are included in the frame carrying the
64 Reduced Neighbor Report element.
65

Copyright © 2022 IEEE. All rights reserved. 397

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#6296)The Critical Update Flag subfield of the Capability Information field in Beacon and Probe Response
2 frames shall also be set to 1 if a new affiliated AP is added to the AP MLD with which the reporting AP is
3
affiliated following the procedure defined in 35.3.6.2.1 (Adding new affiliated APs) or if a Reconfiguration
4
5 Multi-Link element is included by the reporting AP affiliated with an AP MLD, following the procedure
6 defined in 35.3.6.2.2 (Removing affiliated APs).
7
8 If an AP affiliated with an AP MLD is a nontransmitted BSSID in a multiple BSSID set, then the AP that
9
corresponds to the transmitted BSSID in the same multiple BSSID set shall
10
11 — (#1231)include in (#4457)Beacon and Probe Response frames it transmits a BSS Parameters Change
12 Count subfield for each of all APs affiliated with the same AP MLD as the AP corresponding to the
13 non-transmitted BSSID
14
15 • (#1070)(#1201)(#1202)The BSS Parameters Change Count subfield value for each AP is initial-
16 ized to 0, and shall be incremented (modulo 256) when a critical update occurs to the operational
17 parameters for that AP as defined in 11.2.3.15 (TIM Broadcast).
18
• The BSS Parameters Change Count subfield for each of the other AP(s) affiliated with the AP
19
20 MLD shall be carried in the MLD Parameters subfield in the TBTT Information field of the
21 Reduced Neighbor Report element corresponding to that AP (#6256)where each of the other
22 AP(s) is identified by the Link ID subfield of the MLD Parameters subfield.
23 • (#1067)(#1691)The BSS Parameters Change Count subfield for the nontransmitted BSSID shall
24
be carried in the (#6256)Common Info field in the (#6700)Basic Multi-Link element carried in
25
26 Nontransmitted BSSID Profile subelement of the Multiple BSSID element where the AP is iden-
27 tified by the Link ID subfield of the Common Info field in the Basic Multi-Link element.
28 — (#5756)set the Critical Update Flag subfield of the Capability Information field in the
29
30 Nontransmitted BSSID Capability element (for that nontransmitted BSSID) to 1 in Beacon and
31 Probe Response frames up to and including the next DTIM Beacon frame of the nontransmitted
32 BSSID if there is a change to a value carried in the BSS Parameters Change Count subfield of the
33 MLD Parameters field in the Reduced Neighbor Report element for any AP (#4460)affiliated with
34 the same AP MLD as the AP corresponding to the nontransmitted BSSID or a value carried in the
35
36 BSS Parameters Change Count subfield in the Common Info field of the (#6700)Basic Multi-Link
37 element in the Nontransmitted BSSID Profile corresponding to the nontransmitted BSSID.
38 Otherwise set the Critical Update Flag subfield of the Capability Information field to 0.
39
— (#4064)(#5528)(#6639)For each reported AP affiliated with the same AP MLD as the AP
40
41 corresponding to the nontransmitted BSSID, set the All Updates Included subfield to 1 in the MLD
42 Parameters subfield in the TBTT Information field of the Reduced Neighbor Report element
43 corresponding to the reported AP if all the updated elements that correspond to the latest critical
44 update that generated a change to the value carried in the BSS Parameters Change Count subfield for
45
the reported AP are included in the frame carrying the Reduced Neighbor Report element, and set to
46
47 0 otherwise.
48 — (#4064)(#5528)(#6639)Set the Nontransmitted BSSIDs Critical Update Flag subfield of the
49 Capability Information field to 1 in a Beacon frame and a Probe Response frame it transmits if the
50
51 Critical Update Flag subfield of the Nontransmitted BSSID Capability field is set to 1 in at least one
52 nontransmitted BSSID profile in the Multiple BSSID element in the same frame. Otherwise, set the
53 Nontransmitted BSSIDs Critical Update Flag subfield to 0. The flag is set to 1 until and including the
54 later of the DTIM Beacon frame amongst the nontransmitted BSSIDs having the Critical Update
55 Flag subfield of the Nontransmitted BSSID Capability field is set to 1.
56
57
58 (#6296)The Critical Update Flag subfield of the Capability Information field in the Nontransmitted BSSID
59 Capability element in Beacon and Probe Response frames shall also be set to 1 if a new affiliated AP is
60 added to the AP MLD with which the nontransmitted BSSID is affiliated following the procedure defined in
61 35.3.6.2.1 (Adding new affiliated APs) or if a Reconfiguration Multi-Link element is included by the
62
63 reporting AP in the Nontransmitted BSSID Profile corresponding to the nontransmitted BSSID affiliated
64 with an AP MLD, following the procedure defined in 35.3.6.2.2 (Removing affiliated APs).
65

398 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#3225)(#1069)(#1070)(#3030)(#2131)(#3240)(#3319)(#1068)A non-AP MLD shall maintain a record of

2 the most recently received BSS Parameters Change Count subfield value for each AP in the AP MLD
3
(#6608)with a setup link after multi-link setup (#5689)on each setup link.
4
5
6 (#4453)(#4457)An AP affiliated with an AP MLD corresponding to a nontransmitted BSSID in a multiple
7 BSSID set shall include in the (Re)Association Response frame it transmits a BSS Parameters Change Count
8 subfield for each of all APs affiliated with the AP MLD.
9
10 — The BSS Parameters Change Count subfield for each of the other AP(s) affiliated with the AP MLD
11 shall be carried in the STA Info subfield in the Per-STA Profile subelement of Basic Multi-link
12 element corresponding to that AP where each of the other AP(s) is identified by the Link ID subfield
13 of the STA Control field of the Per-STA Profile subelement.
14
15 — The BSS Parameters Change Count subfield for the nontransmitted BSSID shall be carried in the
16 Common Info field in the Basic Multi-Link element carried in Nontransmitted BSSID Profile
17 subelement of the Multiple BSSID element where the AP is identified by the Link ID subfield of the
18
Common Info field in the Basic Multi-Link element
19
20
21 (#6257)When a STA affiliated with a non-AP MLD receives a BSS Parameter Change Count subfield for a
22 certain AP that is affiliated with an AP MLD with which the non-AP MLD has performed multi-link setup
23 and the value of the BSS Parameter Change Count subfield for the AP is different from the previously
24
received value, then the non-AP MLD shall follow one of the following mechanisms:
25
26 — The STA affiliated with the non-AP MLD that is associated with the AP attempts to receive a
27 Beacon frame or a Probe Response frame from the AP.
28
29 — Any STA affiliated with the non-AP MLD attempts to send a Probe Request frame to its associated
30 AP soliciting information of the AP.
31
32 (#4064)(#5528)(#6639)Except that if the value in the BSS Parameter Change Count subfield is equal to the
33
most recently received value recorded by the non-AP MLD for that AP plus 1 and if the All Updates
34
35 Included subfield in the MLD Parameters subfield in the TBTT Information field of the Reduced Neighbor
36 Report element corresponding to the AP is set to 1, no further action is needed from the non-AP MLD as the
37 updated elements are included in the received frame.
38
39 (#6257)NOTE—The Probe Request frame can be either ML probe request or a Probe Request frame that is not ML
40 probe request.
41
42 (#5066)(#4079)The AP affiliated with an NSTR mobile AP MLD and that is operating on the nonprimary
43 link does not send a Beacon frame or respond to Probe Request frame. The BSS Parameter Change Count
44
subfield for the AP operating on nonprimary link shall only be advertised on the primary link in the MLD
45
46 Parameters subfield in the TBTT Information field of the Reduced Neighbor Report element corresponding
47 to that AP.
48
49 35.3.11 Multi-link procedures for channel switching, extended channel switching, and
50
channel quieting(#4112)(#2324)(#2600)
51
52
53 (#4463)(#4385)(#7854)If an (affected) AP (#4462)affiliated with an AP MLD includes any of the following
54 elements for itself in the Beacon frame or Probe Response frame it transmits:
55
56 — Channel Switch Announcement element
57 — (#2749)Extended Channel Switch Announcement element
58
59 — Max Channel Switch Time element
60 — (#2215)Quiet element corresponding to quiet intervals other than quiet intervals scheduled to protect
61 r-TWT SPs (see 35.9.4.2 (Quieting STAs during r-TWT service periods(#2215)))
62
63 — Quiet Channel element
64
65

Copyright © 2022 IEEE. All rights reserved. 399

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#4463)(#4385)(#7854)then one of the followings shall apply:

2
3 — Another AP (reporting AP) (#4462)affiliated with the same AP MLD and not corresponding to a
4 nontransmitted BSSID shall carry the corresponding element(s) in the STA Profile field of the Per-
5 STA Profile subelement corresponding to the affected AP contained in the Basic Multi-Link element
6 included in the Beacon frame and Probe Response frame that it transmits.
7
8 — An AP corresponding to the transmitted BSSID in the same multiple BSSID set as a nontransmitted
9 BSSID (reporting AP) that is (#4462)affiliated with the same AP MLD as the affected AP shall carry
10 the corresponding element(s) in the STA Profile field of the Per-STA Profile subelement
11 corresponding to the affected AP contained in the Basic Multi-Link element corresponding to the AP
12
MLD in the nontransmitted BSSID profile corresponding to the reporting AP in the Multiple BSSID
13
14 element included in the Beacon frame and Probe Response frame that it transmits.
15
16 and
17
18 — The timing fields in the Channel Switch Announcement element, the (#2749)Extended Channel
19 Switch Announcement element, the Quiet element, and the Quiet Channel element shall be applied
20 in reference to the most recent TBTT and BI indicated in the corresponding element(s) of the
21 (#7854)affected AP and not to the TBTT and BI of the reporting AP.
22
23 (#4463)(#4385)(#7854)NOTE—The affected AP can correspond to a transmitted BSSID in a multiple BSSID set or an
24 AP with dot11MultiBSSIDImplemented equal to false. The case where the affected AP corresponds to nontransmitted
25 BSSID in a multiple BSSID set is covered in the next paragraph.
26
27 (#4463)If an AP corresponding to the transmitted BSSID in a multiple BSSID set includes any of the
28 following elements in the nontransmitted BSSID profile corresponding to an affected AP in the Multiple
29
30 BSSID element in the Beacon frame or Probe Response frame it transmits, or if any of these elements is
31 inherited for the affected AP in these frames:
32 — Channel Switch Announcement element
33
34 — Extended Channel Switch Announcement element
35 — Max Channel Switch Time element
36
37 — Quiet element corresponding to quiet intervals other than quiet intervals scheduled to protect r-TWT
38 SPs (see 35.9.4.2 (Quieting STAs during r-TWT service periods(#2215)))
39
— Quiet Channel element
40
41
42 and if the affected AP corresponding to a nontransmitted BSSID in the same multiple BSSID set is affiliated
43 with an AP MLD, then one of the followings shall apply:
44
45 — Another AP (reporting AP) (#4462)affiliated with the same AP MLD and not corresponding to a
46 nontransmitted BSSID shall carry the corresponding element(s) in the STA Profile field of the Per-
47 STA Profile subelement corresponding to the affected AP contained in the Basic Multi-Link element
48 included in a Beacon frame and Probe Response frame that it transmits.
49
50 — An AP corresponding to the transmitted BSSID in the same multiple BSSID set as a nontransmitted
51 BSSID (reporting AP) that is (#4462)affiliated with the same AP MLD as the affected AP shall carry
52 the corresponding element(s) in the STA Profile field of the Per-STA Profile subelement
53 corresponding to the affected AP contained in the Basic Multi-Link element carried in the
54
Nontransmitted BSSID Profile subelement in the Multiple BSSID element included in a Beacon
55
56 frame and Probe Response frame that it transmits.
57
58 and
59
60 — The timing fields in the Channel Switch Announcement element, the Extended Channel Switch
61 Announcement element, the Quiet element, and the Quiet Channel element shall be applied in
62 reference to the most recent TBTT and BI included in the corresponding element(s) of the affected
63 AP and not with respect to the TBTT and BI of the reporting AP.
64
65

400 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#4385)If an AP (#4462)affiliated with an AP MLD is switching channel, the Channel Switch

2 Announcement element, the Extended Channel Switch Announcement element, and the Max Channel
3
Switch Time element will be included in every Beacon and Probe Response frames on all links of the AP
4
5 MLD from right after the time the AP includes the elements in the Beacon frame it transmits until the
6 intended channel switch time. The Max Channel Switch Time element, if used for this channel switch, shall
7 be included in the per-STA profile of the affected AP in every Beacon and Probe Response frames on all
8 links of the AP MLD until the affected AP resumes BSS operation on the new channel. The value carried in
9
the Switch Time field indicates the estimated time of the first Beacon frame in the new channel.
10
11
12 (#5035)(#4385)(#7854)(#2295)When an AP (affected AP) (#4462)affiliated with an MLD is switching from
13 an initial operating class/channel to a target operating class/channel at a target switch time using channel
14 switch announcement procedure or extended channel switch announcement procedure, then:
15
16 — (#2295)another AP (reporting AP) (#4462)affiliated with the AP MLD shall set the
17 (#1430)Operating Class and Channel Number fields corresponding to the affected AP that is
18 reported in the Reduced Neighbor Report element in Beacon and Probe Response frames it transmits
19 (or that the transmitted BSSID in the same multiple BSSID set as the reporting AP transmits if the
20
21 reporting AP corresponds to a nontransmitted BSSID) before the target switch time to the initial
22 operating class/channel,
23 — (#2295)another AP (reporting AP) (#4462)affiliated with the AP MLD shall set the
24
(#1431)Operating Class and Channel Number fields corresponding to the affected AP that is
25
26 reported in the Reduced Neighbor Report element in Beacon and Probe Response frames it transmits
27 (or that the transmitted BSSID in the same multiple BSSID set as the reporting AP transmits if the
28 reporting AP corresponds to a nontransmitted BSSID) (#3320)at and after the target switch time to
29 the target operating class/channel.
30
31 — (#4385)Between the target switch time and the time at which the AP will start beaconing in the target
32 operating class/channel, the Neighbor AP TBTT Offset subfield for the corresponding AP in the
33 Reduced Neighbor Report element shall be set to 255.
34
35
36 (#1074)If an AP (affected/reported AP) of an AP MLD is switching from an initial operating class/channel
37 to a target operating class/channel at a target switch time using channel switch announcement or extended
38 channel switch announcement procedure and includes a Max Channel Switch Time element in the Beacon
39 and Probe Response frames it sends, and another AP (reporting AP) of the AP MLD receives a
40 (Re)Association Request frame to perform multi-link setup with the AP MLD with the AP (affected/
41
42 reported AP) as a requested link, then the other AP (reporting AP) shall include the complete profile for the
43 AP indicating the target operating class/channel and a Max Channel Switch Time element in the per-STA
44 profile corresponding to the AP (affected/reported AP) in the (#6700)Basic Multi-link element included in
45 the (Re)Association Response frame it sends in response to indicate the time at which the AP (affected/
46 reported AP) will start beaconing, if the (Re)Association Response frame is sent between the last beacon on
47
48 the initial operating class/channel and the first beacon on the target operating class/channel. Otherwise, the
49 other AP (reporting AP) shall not include a Max Channel Switch Time element or (Extended) Channel
50 Switch Announcement element in (Re)Association Response frames.
51
52 (#1074)When an AP (affected/reported AP) of an AP MLD has announced quiet intervals using Quiet
53
54 element and optionally Quiet Channel element, and another AP (reporting AP) of the same AP MLD
55 receives a (Re)Association Request frame to perform multi-link setup with the AP MLD with the AP
56 (affected/reported AP) as a requested link, then the other AP (reporting AP) shall include the corresponding
57 Quiet element and Quiet Channel element (if present) in the per-STA profile corresponding to the AP
58 (affected/reported AP) in the (#6700)Basic Multi-link element included in the (Re)Association Response
59
60 frame it sends in response. Otherwise, the other AP (reporting AP) shall not include a Quiet element and
61 Quiet Channel element in (Re)Association Response frames.
62
63 For the example shown in Figure 35-8 (Example of an AP carrying a Quiet element to signal channel
64 quieting on another link (#1073)), AP 1 and AP 2 are two APs affiliated with an AP MLD that operate on
65

Copyright © 2022 IEEE. All rights reserved. 401

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Link 1 and Link 2, respectively. The Beacon frame transmitted by AP 1 includes a Quiet element to indicate
2 a scheduled quiet interval on Link 1 (the affected link). From this point onward and until the quiet interval
3
begins on Link 1, AP 2, which operates on Link 2 (the reporting link), includes a Quiet element in the Per-
4
5 STA Profile subelement corresponding to AP 1 in the (#6700)Basic Multi-Link element carried in its
6 Beacon frames. Although not shown in the figure, Quiet element will also be included in the Per-STA Profile
7 subelement of the (#6700)Basic Multi-Link element corresponding to AP 1 carried in the Probe Response
8 frames transmitted by AP 2. The values of the Quiet Count field, Quiet Offset field, and the Quiet Duration
9
field of the Quiet element carried on Link 2 are set by AP 2 with reference to Link 1. As the value of the
10
11 Beacon Interval for AP 2 is greater than the value of beacon interval for AP 1, the Quiet Count field of the
12 Quiet element is decremented at a faster rate (i.e., 2 in this example) in every subsequent beacon transmitted
13 by AP1. In Figure 35-8 (Example of an AP carrying a Quiet element to signal channel quieting on another
14 link (#1073)), a STA affiliated with a non-AP MLD, which is capable of operating on Link 2, transmits a
15
(Re-)Association Request frame to AP 2, in order to perform multi-link setup. The multi-link setup includes
16
17 Link 1 as one of the links. Since the (Re)Association Response frame is transmitted by AP 2 after the quiet
18 interval has started on Link 1, AP 2 includes the Quiet element in the per-STA profile corresponding to AP 1
19 in the (Re)Association Response frame it transmits. The value of the Quiet Count field of the Quiet element
20 carried in the (Re )Association Response frame is set to 129 to indicate that the quiet interval on Link 1
21
started in the beacon interval that occurred 2 TBTTs in the past on Link 1.
22
23
Quiet Quiet Quiet Quiet
24 Count =4 Count =3 Count =2 Count =1
25
26 Affected Quiet Duration
27 link
28
Link 1
29 (AP1)
30 Quiet Quiet
Quiet
Count =3 Count =1
31 Count =128
32
33 Reporting
link
34 Link 2
35 (Re)Association Response
(AP2)
Change Sequence for
36 AP1 incremented
frame includes Quiet element
37
38 Beacon (Re)Association
39 frames Response frame
40
41 Figure 35-8—Example of an AP carrying a Quiet element to signal channel quieting on
42
43 another link (#1073)
44
45 For the example shown in Figure 35-9 (Example of an AP carrying a Channel Switch Announcement
46 element to signal channel switching on another link (#1073)), AP 1 and AP 2 are two APs affiliated with an
47
48
AP MLD that operate on Link 1 and Link 2, respectively. The Beacon frame transmitted by AP 1 includes a
49 Channel Switch Announcement element to indicate that the channel on Link 1 (the affected link) will be
50 switched. From this point onward and until the channel on Link 1 switches, AP 2, which operates on Link 2
51 (the reporting link), includes a Channel Switch Announcement element in the per-STA profile
52 corresponding to AP 1 in the (#6700)Basic Multi-Link element carried in the Beacon frame it transmits.
53
54
When AP 1 begins to include the Channel Switch Announcement element in its Beacon frames, the Change
55 Sequence subfield in the TBTT Information field corresponding to AP 1 in the Reduced Neighbor Report
56 element carried in AP 2’s Beacon frames is incremented by 1. The values of the Channel Switch Count field
57 of the Channel Switch Announcement element carried on Link 2 are set by AP 2 with reference to Link 1.
58 As the value of the beacon interval for AP 2 is twice the value of beacon interval for AP 1, the Channel
59
60
Switch Count field of the Channel Switch Announcement element is decremented by 2 in every subsequent
61 beacon transmitted by AP 1. If AP 1 carries the Extended Channel Switch Announcement element and the
62 Max Channel Switch Time element in the Beacon frame its transmits, AP 2 also includes the Extended
63 Channel Switch Announcement element and the Max Channel Switch Time element in the per-STA profile
64 corresponding to AP 1 in the (#6700)Basic Multi-Link element in the Beacon frames it transmits. Although
65

402 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 not shown in the figure, the Channel Switch Announcement element, Extended Channel Switch
2 Announcement element (if included by AP 1), and Max Channel Switch Time element (if included by AP 1)
3
will also be included in the Per-STA Profile subelement of the (#6700)Basic Multi-Link element
4
5 corresponding to AP 1 carried in the Probe Response frames transmitted by AP 2. In Figure 35-9 (Example
6 of an AP carrying a Channel Switch Announcement element to signal channel switching on another link
7 (#1073)), a STA affiliated with a non-AP MLD, that operates on Link 2, transmits a (Re)Association
8 Request frame to AP 2 requesting Link 1 as one of the links for multi-link setup. Since the (Re)Association
9
Response frame is transmitted by AP 2 after the last Beacon frame on the initial operating class/channel on
10
11 Link 1 and before the first beacon on the initial operating class/channel is transmitted, AP 2 includes the
12 Max Channel Switch Time element in the per-STA profile corresponding to AP 1 in the (Re)Association
13 Response frame it transmits. The value carried in Max Channel Switch Time element provides an estimate
14 of time until the first TBTT on the new channel on Link 1. The STA affiliated with the non-AP MLD
15
operating on Link 1 does not transmit a frame until it hears the first Beacon frame from AP 1 on Link 1.
16
17
Channel Channel Channel
18 Channel
Switch Switch Switch
Switch
19 Count =4 Count =3 Count =2 Count =1
20
21 Affected Max Channel Switch Time
22 link
23
Link 1
24 Channel Channel Last Beacon on initial First Beacon on new (AP1)
25 Switch Switch operating class/channel operating class/channel
26 Count =3 Count =1
27
28 Reporting
29 link
30 Link 2
31 Change Sequence for (Re)Association Response frame includes (AP2)
32 AP1 incremented Max Channel Switch Time element
33
34 Beacon (Re)Association
35 frames Response frame
36
37 Figure 35-9—Example of an AP carrying a Channel Switch Announcement element to
38 signal channel switching on another link (#1073)
39
40 35.3.12 Multi-link power management
41
42
43 35.3.12.1 General
44
45 (#4465)Each STA affiliated with a non-AP MLD that is operating on an enabled link shall maintain its own
46 power management mode and power states as defined in 11.2 (Power management) and 10.47 (Target wake
47
time (TWT)). Frame exchanges on an enabled link are possible when the STA affiliated with the non-AP
48
49 MLD operating on that link is in the awake state (see 11.2.3 (Power management in a non-DMG
50 infrastructure network))(#4465)(#3255).
51
52 (#2325)Figure 35-10 (Each STA affiliated with a non-AP MLD maintains its own power
53
state(#4386)(#4387)(#6134)(#2325)) illustrates the power save operation for each STA affiliated with a non-
54
55 AP MLD during multi-link operation. (#4386)As depicted in the figure, during the initial portion of the
56 illustration, both STAs affiliated with the non-AP MLD are in active mode and are involved in frame
57 exchange with the respective APs on the links. (#5260)Each AP affiliated with the non-AP MLD indicates
58 that it is in active mode by setting to 0 the Power Management subfield (namely PM bit in the figure) in the
59
Frame Control field of a transmitted frame. (#8342)(#5260)At some point in time, STA 2 affiliated with the
60
61 non-AP MLD operating on Link 2 indicates to AP 2 that it is entering power save mode (i.e., sets PM bit to
62 1) and transitions to doze state. STA 2 remains in doze state for the rest of the illustration.
63 (#7725)(#5260)After a period of time, STA 1 enters power save mode (i.e., sets PM bit to 1).
64 (#6211)(#6134)While operating in power save mode, STA 1 wakes up to receive the Beacon frame
65

Copyright © 2022 IEEE. All rights reserved. 403

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 transmitted by AP 1 and determines that AP MLD has BUs belonging to TID(s) mapped to Link 1. Based on
2 this determination, STA 1 indicates to AP 1 that it has transitioned to awake state by transmitting a PS-Poll
3
or U-APSD trigger frame on Link 1. STA 1 participates in frame exchange with AP 1 while in awake state.
4
5
6
7 ...
8 AP 1
Link 1 ... ... ... ... Link 1
9 Doze state Doze state STA 1
PM=1
10
11 PM=0 Awake state Awake state
PM=0
Awake state
12 Active mode Power‐save Mode Active mode
13
14
15
AP 2
16 Link 2 ... Link 2
17 ...
PM=1
Doze state STA 2
18
19 PM=0
Awake state
20 Active mode Power Save Mode
21 AP MLD Non‐AP
Data frame Beacon
22 Active Doze ... PS‐Poll
ACK MLD
exchange frame frame
23 mode state
24
25 Figure 35-10—Each STA affiliated with a non-AP MLD maintains its own power
26 state(#4386)(#4387)(#6134)(#2325)
27
28
29 35.3.12.2 Basic BSS operation
30
31
32
(#1167)(#4467)A non-AP MLD shall be able to perform basic operations (such as receiving a traffic
33 indication, time synchronization, receiving BSS parameter updates) by monitoring Beacon frames on one or
34 more enabled links. This is in addition to mechanisms such as individual TWT agreement(#2601).
35 (#7415)(#7416)With these mechanisms, a non-AP MLD can receive basic information about the AP MLD
36 and all the APs affiliated with the AP MLD on a single link while the other STA(s) affiliated with the non-
37
38
AP MLD are in doze state.
39
40 (#1695)(#3031)(#1168)(#2252)(#3032)(#4066)(#4392)The traffic indication for a non-AP MLD shall be
41 consistent across the Beacon frames transmitted by APs affiliated with an AP MLD, that are operating on the
42 links that are part of the multi-link setup.
43
44 (#1695)(#3031)(#2295)NOTE—Each AP affiliated with an MLD provides a critical updates indication when there is an
45 update to the BSS parameters for another AP affiliated with the AP MLD (see 35.3.10 (BSS parameter critical update
46 procedure)).
47
48 35.3.12.3 MLD max idle period management
49
50
51 (#1027)(#1818)(#1696)(#3203)(#2295)During multi-link setup, if the AP affiliated with an MLD includes a
52 BSS Max Idle Period element in the (Re)Association Response frame, then the value carried in the Max Idle
53 Period field is applied at the MLD level. The AP MLD shall use this timeout value for making disassociation
54 decisions. An AP MLD may provide different BSS Max Idle Period values for different non-AP MLDs.
55
56
57 (#3321)(#1635)At least one STA affiliated with a non-AP MLD (#7061)shall send at least one keepalive
58 frame (such as Data frame, PS-Poll frame, or Management frame) per BSS Max Idle Period if the non-AP
59 MLD (#7061)intends to avoid getting disassociated from the AP MLD due to nonreceipt of frames. A
60 keepalive frame shall be protected or unprotected as indicated in the Idle Options subfield.
61
62
63 (#3203)(#4067)A non-AP MLD is considered inactive if the AP MLD has not received a Data frame, PS-
64 Poll frame, or Management frame (protected or unprotected as specified in this paragraph) or a frame
65

404 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 exchange sequence initiated by the non-AP MLD on any enabled link for a time period greater than or equal
2 to the time specified by the Max Idle Period subfield of the BSS Max Idle Period element. (#7417)An AP
3
MLD may disassociate a non-AP MLD if:
4
5 — the Idle Options subfield of the BSS Max Idle Period element requires periodic keepalive frames and
6 no protected frames are received from any STA affiliated with the non-AP MLD for a duration of the
7 BSS Max Idle Period.
8
9 — the Idle Options subfield allows unprotected or protected keepalive frames and no protected or
10 unprotected frames are received from any STA affiliated with the non-AP MLD for a duration of the
11 BSS Max Idle Period.
12
13 (#2090)(#1108)NOTE—The AP MLD can disassociate or deauthenticate the non-AP MLD at any time for other reasons
14 even if the non-AP MLD satisfies the keepalive frame transmission requirements.
15
16 35.3.12.4 Traffic indication
17
18
19 (#6499)(#4392)(#6254)An AP affiliated with an AP MLD where the AP is not in a multiple BSSID set shall
20 indicate pending buffered traffic for a non-AP MLD associated with that AP MLD using the partial virtual
21 bitmap of the TIM element as described in 9.4.2.5 (TIM element) and by following the rules described in this
22 subclause.
23
24
25 (#6254)An AP affiliated with an AP MLD where the AP corresponds to a transmitted BSSID in a multiple
26 BSSID set shall indicate pending buffered traffic for a non-AP MLD associated with any AP MLD that has an
27 affiliated AP in the same multiple BSSID set as the AP using the partial virtual bitmap of the TIM element as
28 described in 9.4.2.5 (TIM element), 11.1.3.8.5 (Traffic advertisement in a multiple BSSID set), and by
29
following the rules described in this subclause.
30
31
32 An AP MLD may recommend a non-AP MLD to use one or more enabled links to retrieve individually
33 addressed buffered BU(s)(#3256)(#3322). The AP’s indication may be carried in a broadcast or a unicast
34 frame(#1697)(#2153).
35
36
37 (#2302)An AP MLD shall buffer a BU with a TID at the AP MLD if the TID is not mapped to any link on
38 which the corresponding STA of a non-AP MLD is in active mode, and it shall set the bit in the partial
39 virtual bitmap of the TIM element that corresponds to the AID of the non-AP MLD to 1.
40
41
TPC Request and Link Measurement Request frames are Measurement MMPDUs.
42
43
44 (#2302)An AP MLD (#8238)shall buffer an MMPDU that is not a Measurement MMPDU and intended for
45 receipt by a STA affiliated with a non-AP MLD in the AP MLD when all STAs affiliated with the non-AP
46 MLD are in power save mode. In this case, the bit in the partial virtual bitmap of the TIM element that
47
corresponds to the AID of the non-AP MLD shall be set to 1. (#5761)An AP MLD shall not buffer a
48
49 Measurement MMPDU.
50
51 (#1432)(#1697)(#2136)(#2153)(#2341)(#2342)(#3149)An AP affiliated with an AP MLD shall include the
52 (#4107)Multi-Link Traffic Indication element (see 9.4.2.315 (Multi-Link Traffic Indication
53
element(#4107)(#2341))) in a Beacon frame it transmits if at least one of the associated non-AP MLD has
54
55 successfully negotiated a TID-to-link mapping (see 35.3.7.1.3 (Negotiation of TID-to-link mapping)) with
56 the AP MLD (#8037)for DL or bidirectional traffic and the AP MLD has buffered BU(s) for the non-AP
57 MLD. The (#4107)Multi-Link Traffic Indication element includes Per-Link Traffic Indication Bitmap
58 subfield(s) (#4469)in the Per-Link Traffic Indication Bitmap List field. The Per-Link Traffic Indication
59
Bitmap subfield(s) corresponds to the AID(s) of the non-AP MLD(s) (#6733)(#5148)or STA(s), starting
60
61 from the bit number k of the traffic indication virtual bitmap(#4469). The AID Offset subfield of the
62 (#4107)Multi-Link Traffic Indication Control field of the (#4107)Multi-Link Traffic Indication element
63 contains the value k. The order of the Per-Link Traffic Indication Bitmap subfield(s) follows the order of the
64 bits that are set to 1 in the Partial Virtual Bitmap subfield of the TIM element that corresponds to the AID(s)
65

Copyright © 2022 IEEE. All rights reserved. 405

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 of the non-AP MLD(s) (#6733)(#5148)or STA(s). If a non-AP MLD has successfully negotiated a TID-to-
2 link mapping with an AP MLD with a nondefault mapping, the bit position i of the Per-Link Traffic
3
Indication Bitmap subfield that corresponds to the link with the link ID equals to i on which a STA of the
4
5 non-AP MLD is operating shall be set to 1 if the AP MLD has buffered BU(s) with TID(s) that are mapped
6 to that link or MMPDU(s) for that non-AP MLD, otherwise the bit shall be set to 0. If a non-AP MLD is in
7 the default mapping mode (see 35.3.7.1.2 (Default mapping mode)), the bit position i of the Per-Link Traffic
8 Indication Bitmap subfield that corresponds to the link with the link ID (#7821)equals to i on which a STA
9
affiliated with the non-AP MLD is operating may be set to 1 to indicate to the non-AP MLD a link on which
10
11 buffered BU(s) should be retrieved. An example of the construction of the (#4107)Multi-Link Traffic
12 Indication element is shown in Figure 35-11 (Example of Multi-Link Traffic Indication element
13 construction(#8180)(#4107)). (#5041)A non-AP MLD that successfully negotiated a TID-to-link mapping
14 with an AP MLD with a nondefault mapping shall determine which AP has buffered BU(s) with TID(s) or
15
MMPDU(s) by interpreting a Multi-Link Traffic Indication element.
16
17
18 AIDs assigned
AIDs assigned to Pre‐EHT STAs or Non‐AP MLDs
to Non‐AP MLDs
19 (default mapping)
(non‐default mapping)
20

(N+1)x8‐1
21

Nx8 = k
Nx8‐1
(N‐1)x8

Nx8+1
Traffic indication virtual bitmap
22 AID: 0 1 2 3 4 5 6 7 8 15
23
… …
24 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
(zeros)
0 0 1 0 1 0 0 1 1 1 0 1 0 0 0 0
(zeros)
25 Octet 0 1 N‐1 N
26 number: (even)

Nx8 = k
27

Nx8+1

Nx8+3
28 bits: B0 B1 B7
29
Partial Virtual Bitmap in TIM 0 Bitmap Offset = (N‐1)/2 0 0 1 0 1 0 0 1 1 1 0 1 0 0 0 0
30
31 Bitmap Control Partial Virtual Bitmap
32
33 Link ID: 0 1 2 0 1 2 0 1 2
34 bits: B0 B3 B4 B14 B15 B0 B1 B2 B0 B1 B2 B0 B1 B2
Bitmap Size
35 Multi‐link Traffic Indication
(m+1), AID Offset = k
Reserved
0 1 0 0 1 0 1 1 0 0s
element (0)
36 m=2
37 Multi‐link Traffic Multi‐link Traffic Multi‐link Multi‐link
Padding
(7 bits)
38 Indication Control Indication Bitmap 1 Traffic Traffic
(Link ID = 1 is Indication Indication
39 recommended link) Bitmap 2 Bitmap 3
40
41 Figure 35-11—Example of Multi-Link Traffic Indication element construction(#8180)(#4107)
42
43
44
45 When a non-AP MLD that is in the default mapping mode (see 35.3.7.1.2 (Default mapping mode)) detects
46 that the bit corresponding to its AID is 1 in the TIM element, any STA affiliated with the non-AP MLD may
47 issue a PS-Poll frame, or a U-APSD trigger frame if the STA is using U-APSD and all ACs are delivery
48 enabled, to retrieve buffered BU(s) (#8239)from the AP MLD.
49
50
51 When a non-AP MLD that is in the default mapping mode (see 35.3.7.1.2 (Default mapping mode)) detects
52 that the bit corresponding to its AID is 1 in the TIM element and the Multi-Link Traffic element is present in
53 a Beacon frame (#8181)and the Multi-Link Traffic Indication element includes a Per-Link Traffic Indication
54 Bitmap subfield that corresponds to the non-AP MLD, any STA affiliated with the non-AP MLD that
55 operates on the link(s) indicated as 1 in the Per-Link Traffic Indication Bitmap subfield should issue a PS-
56
57 Poll frame, or a U-APSD trigger frame if the STA is using U-APSD and all ACs are delivery enabled, to
58 retrieve buffered BU(s) (#8239)from the AP MLD.
59
60 When a non-AP MLD that has successfully negotiated TID-to-link mapping (see 35.3.7.1.3 (Negotiation of
61 TID-to-link mapping)) detects that the bit corresponding to its AID is equal to 1 in the TIM element and any
62
63 bit of the Per-Link Traffic Indication Bitmap subfield that corresponds to a link on which a STA affiliated
64 with the non-AP MLD is operating is equal to 1 in the Multi-Link Traffic element, the STA affiliated with
65

406 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 the non-AP MLD that operates on that link may issue a PS-Poll frame, or a U-APSD trigger frame if the
2 STA is using U-APSD and all ACs are delivery enabled, to retrieve buffered BU(s) from the AP MLD.
3
4
5 When an AP affiliated with an AP MLD receives a PS-Poll frame or a U-APSD trigger frame from a STA
6 affiliated with an associated non-AP MLD that is in power save mode, it shall transmit buffered BU(s) to the
7 STA, if one is available and not discarded for implementation dependent reasons, otherwise it may transmit
8 a QoS Null frame.
9
10
11 If a buffered BU is an MMPDU that is intended for one STA affiliated with a non-AP MLD and that is not a
12 Measurement MMPDU, and if it is transmitted on a link where another STA affiliated with the same non-AP
13 MLD is operating on, following the procedure above, the frame shall carry information to determine the
14 intended destination STA affiliated with the non-AP MLD.
15
16
17 (#8264)An AP MLD shall set dot11MultiLinkTIMActivated to true if dot11TIDtoLinkMappingActivated is
18 true and if any of the following conditions is met and otherwise shall set to false:
19 — At least one of the associated non-AP MLD(s) has successfully negotiated a TID-to-link mapping
20
21 (see 35.3.7.1.3 (Negotiation of TID-to-link mapping)) with the AP MLD and not all TIDs are
22 mapped to all the enabled links and the AP MLD has buffered BU(s) for that non-AP MLD
23 — The AP MLD intends to provide link recommendations to at least one of the associated non-AP
24
MLD(s) that has successfully negotiated a TID-to-link mapping with the AP MLD and all TIDs are
25
26 mapped to all the enabled links and the AP MLD has buffered BU(s) for that non-AP MLD
27 — The AP MLD intends to provide link recommendations to at least one of the associated non-AP
28 MLD(s) that is in the default mapping mode (see 35.3.7.1.2 (Default mapping mode)) and the AP
29
30 MLD has buffered BU(s) for that non-AP MLD.
31
32 35.3.12.5 WNM sleep mode in multi-link operation
33
34 An MLD that implements WNM sleep mode shall indicate its capability by setting the WNM Sleep Mode
35
36 field to 1 in the Extended Capabilities element that is transmitted by its affiliated STAs. (#4114)(#2295)All
37 STAs affiliated with an MLD shall advertise the same WNM Sleep Mode capability.
38
39 A STA affiliated with a non-AP MLD may transmit a WNM Sleep Mode Request frame (see
40 9.6.13.19 (WNM Sleep Mode Request frame format)) to an AP affiliated with an AP MLD that has
41
42 indicated support for WNM sleep mode capability.
43
44 (#2295)(#4468)An AP affiliated with an AP MLD shall send a WNM Sleep Mode Response frame in
45 response to a WNM Sleep Mode Request frame received from a STA affiliated with a non-AP MLD. An AP
46 affiliated with an AP MLD may send this frame without solicitation upon the AP MLD’s deletion of all
47
48 traffic filter sets established according to the traffic filtering agreement between the AP MLD and the non-
49 AP MLD (see 9.6.13.20 (WNM Sleep Mode Response frame format)).
50
51 The WNM sleep state is maintained at the MLD level and WNM sleep mode procedures defined in 11.2.3
52 (Power management in a non-DMG infrastructure network) and 11.2.3.16 (WNM sleep mode) are
53
54 performed at the MLD level and apply to all the STAs affiliated with the MLD.
55
56 35.3.12.6 Operation for MLD listen interval
57
58 During multi-link (re)setup, the value carried in Listen Interval field in the (Re)Association Request frame
59
60 sent by a non-AP STA affiliated with a non-AP MLD to an AP affiliated with an AP MLD is requested at the
61 MLD level. (#5693)(#5263)The value of the Listen Interval field shall be in units of the maximum value of
62 beacon intervals corresponding to the links that the non-AP MLD intends to setup in the (Re)Association
63 Request frame (see 9.4.1.6 (Listen Interval field)). (#6374)The AP affiliated with the AP MLD may reject
64 the (#6768)multi-link (re)setup because the listen interval requested by the non-AP MLD is too large. After
65

Copyright © 2022 IEEE. All rights reserved. 407

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 successful multi-link (re)setup, the AP MLD shall use the listen interval in determining the lifetime of
2 frames that it buffers for the non-AP MLD.
3
4
5 The AP MLD may delete buffered BUs for the implementation dependent reasons (subject to 11.2.3.10 (AP
6 and AP MLD aging function)), including the use of an aging function and availability of buffers where the
7 aging function is based on the listen interval indicated by the non-AP MLD in its (Re)Association Request
8 frame or the WNM sleep interval specified by the non-AP MLD in the WNM Sleep Mode Request frame.
9
10
11 (#8198)(#8240)If all STAs affiliated with the non-AP MLD and operating on enabled links are in power
12 save mode, at least one of these STAs shall wake up to receive at least one Beacon frame scheduled for
13 transmission within the interval of duration equal to the listen interval indicated by the non-AP MLD in its
14 (Re)Association Request frame, starting from the last TBTT for which another STA or the same STA
15
affiliated with the (#8241)non-AP MLD was awake.
16
17
18 An example of operation for MLD listen interval is shown in Figure 35-12 (Example of operation for MLD
19 listen interval).
20
21
The AP MLD has DL BU The AP MLD may discard DL
22 of the non-AP MLD BU of the non-AP MLD
23
24 Beacon
25
300 ms
26
27
28
29 Link 1 Link 1 is accepted as
30 a setup link
31 Beacon
32
33 200 ms
34
35
36 Link 2 Link 2 is accepted as
37 a setup link

38 Beacon
39
70 ms
40
41
42
Link 3
43 Link 3 is accepted as
a setup link
44
45 T1 T2

46
47 Figure 35-12—Example of operation for MLD listen interval
48
49
50
51 In this example, AP MLD has three affiliated APs: AP 1 operates on link 1, AP 2 operates on link 2, and
52 AP 3 operates on link 3. The beacon intervals of link 1, link 2, and link 3 are 300 ms, 200 ms, and 70 ms,
53 respectively. Non-AP STA 1 affiliated with the non-AP MLD sends an Association Request frame to AP 1
54
55 affiliated with the AP MLD. The non-AP STA 1 requests three links to be setup (link 1 between AP 1 and
56 non-AP STA 1, link 2 between AP 2 and non-AP STA 2, and link 3 between AP 3 and non-AP STA 3) and
57 set the value of Listen Interval field carried in the Association Request frame to 1 (#5263)and the value of
58 Listen Interval field in units of 300 ms. Therefore, the listen interval requested by the non-AP MLD is
59 300 ms. AP 1 affiliated with the AP MLD accepts the three links for this multi-link setup (link 1 between
60
61 AP 1 and non-AP STA 1, link 2 between AP 2 and non-AP STA 2, and link 3 between AP 3 and non-AP
62 STA 3) by sending an Association Response frame to non-AP STA 1 affiliated with the non-AP MLD. After
63 the successful multi-link setup, (#5264)non-AP STA 2 and non-AP STA 3 enter in power save mode. A little
64 later, non-AP STA 1 enters power save mode (i.e., signals PM = 1). In this case, the AP MLD shall buffer
65

408 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 the DL BUs to the non-AP MLD at least for 300 ms. At T1, the non-AP STA 1 receives a Beacon frame on
2 link 1, then a non-AP STA (#6375)affiliated with the non-AP MLD is required to wake up to receive at least
3
one Beacon frame before T2 where T2 = T1 + 300 ms, for example, the non-STA 1 receives the second
4
5 Beacon frame on link 1 (at T1 + 300 ms), or the non-AP STA 2 receives the second Beacon frame on link 2
6 (at T1 + 200 ms), or the non-AP STA 3 receives the fourth Beacon frame on link 3 (at T1 + 280 ms). The
7 figure was simplified to show the first Beacon frames on all links as aligned. In real deployment, the first
8 TBTTs on all links may not be aligned.
9
10
11 Another example of operation for MLD listen interval is shown in Figure 35-13 (Another example of
12 operation for MLD listen interval).
13
14
The AP MLD has DL BU The AP MLD may discard DL
15 of the non-AP MLD BU of the non-AP MLD
16
17 Beacon
18
19 300 ms

20
21
22 Link 1 Link 1 is not accepted
23 as a setup link

24 Beacon
25
26 200 ms
27
28
Link 2
29 Link 2 is accepted as
a setup link
30
Beacon
31
32 70 ms
33
34
35 Link 3 Link 3 is accepted as
36 a setup link
37 T2
T1
38
39
40 Figure 35-13—Another example of operation for MLD listen interval
41
42
43
44 In this example, AP MLD has three affiliated APs: AP 1 operates on link 1, AP 2 operates on link 2, and
45 AP 3 operates on link 3. The beacon intervals of link 1, link 2, and link 3 are 300 ms, 200 ms, and 70 ms,
46 respectively. (#5195)Non-AP STA 2 affiliated with the non-AP MLD sends an Association Request frame to
47 AP 2 affiliated with the AP MLD. The non-AP STA 1 requests three links to be setup (link 1 between AP 1
48 and non-AP STA 1, link 2 between AP 2 and non-AP STA 2, and link 3 between AP 3 and non-AP STA 3)
49
50 and sets the value of Listen Interval field carried in the Association Request frame to 1 (#5263)and the value
51 of Listen Interval field in units of 300 ms. (#5195)AP 2 affiliated with the AP MLD accepts the two links for
52 this multi-link setup (link 2 between AP 2 and non-AP STA 2, and link 3 between AP 3 and non-AP STA 3)
53 by sending an Association Response frame to non-AP STA 2 affiliated with the non-AP MLD, the listen
54 interval requested by the non-AP MLD is still 300 ms and it is not changed along with the accepted links in
55
56 the multi-link setup procedure. After the successful multi-link setup, (#5264)non-AP STA 3 enters in power
57 save mode. A little later, non-AP STA 2 enters power save mode (i.e., signal PM = 1). In this case, the AP
58 MLD shall buffer the DL BUs to the non-AP MLD at least for 300 ms. At T1, the non-AP STA 2 receives a
59 Beacon frame on link 2, then either non-AP STA 2 or non-AP STA 3 is required to wake up to receive at
60 least one Beacon frame before T2 where T2 = T1 + 300 ms, for example, the non-AP STA 2 receives the
61
62 second Beacon frame on link 2 (which occurs at T1 + 200 ms in this example) or the non-AP STA 3 receives
63 the fourth Beacon frame on link 3 (which occurs at T1 + 280 ms). The figure was simplified to show the first
64 Beacon frames on all links as aligned. In real deployment, the first TBTTs on all links may not be aligned.
65

Copyright © 2022 IEEE. All rights reserved. 409

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 35.3.13 Multi-link device individually addressed data delivery without block ack negotiation
2
3
An MLD may deliver individually addressed QoS Data frames belonging to a TID without block ack
4
5 negotiation to an associated MLD on the setup links subject to additional constraints in 35.3.7 (Link
6 management).
7
8 An MLD shall follow the rules described in 10.3.2.14.2 (Transmitter requirements) to determine the
9
sequence number of an individually addressed QoS Data frame belonging to a TID that is delivered to the
10
11 associated MLD.
12
13 An MLD shall follow the rules as described in 10.3.2.14.3 (Receiver requirements) to discard duplicate
14 individually addressed QoS Data frames belonging to a TID without block ack negotiation that are delivered
15
from the associated MLD.
16
17
18 (#2328)An MLD shall maintain a transmit MSDU timer for each MSDU passed to the MAC. The transmit
19 MSDU timer shall be started when the MSDU is passed to the MAC. STAs affiliated with an MLD shall
20 have the same dot11EDCATableMSDULifetime.
21
22
23 (#6377)When A-MSDU aggregation is used, the MLD maintains a single timer for the whole A-MSDU. The
24 timer is restarted each time an MSDU is added to the A-MSDU. The result of this procedure is that no
25 MSDU in the A-MSDU is discarded before a period of dot11EDCATableMSDULifetime has elapsed.
26
27
(#6377)For an MLD, the frame retry count and retry limit for each MSDU or A-MSDU that belongs to a TC
28
29 that requires acknowledgment is implementation specific.
30
31 (#2328)An MLD shall continue to deliver the failed individually addressed QoS Data frame belonging to a
32 TID without block ack negotiation to an associated MLD on the setup links subject to additional constraints
33
(see 35.3.7 (Link management)) until any of the following conditions occurs(#8244):
34
35 — The retry limit is met.
36
— The transmit MSDU timer for the MSDU exceeds dot11EDCATableMSDULifetime.
37
38 — The individually addressed QoS Data frame is successfully delivered.
39
40 (#1174)A STA affiliated with the MLD shall not transmit other individually addressed QoS Data frames
41
42 belonging to the TID without block ack negotiation to another STA affiliated with the associated MLD
43 while the current individually addressed QoS Data frame belonging to the TID without block ack negotiation
44 has not yet completed to the point of success, (#8201)failed due to retry limit, or other MAC discard (e.g.,
45 lifetime expiration).
46
47
48 35.3.14 Multi-link device individually addressed Management frame delivery(#2496)
49
50 The following individually addressed Management frames are excluded from the rules defined in this
51 subclause.
52
53 — CSI frame
54 — Noncompressed Beamforming frame
55
56 — Compressed Beamforming frame
57 — VHT Compressed Beamforming frame
58
59 — HE Compressed Beamforming/CQI frame
60 — EHT Compressed Beamforming/CQI frame
61
62 — Probe Response frame
63 — LMR frame
64
65 — FTM frame

410 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 An MLD with dot11QMFActivated equal to false shall follow the rules described in 10.3.2.14.2 (Transmitter
2 requirements) to determine the sequence number of an individually addressed Management frame (except
3
the frames that are excluded above) that is delivered to the associated MLD.
4
5
6 An MLD with dot11QMFActivated equal to false shall follow the rules as described in 10.3.2.14.3 (Receiver
7 requirements) to discard duplicate individually addressed Management frames (except the frames that are
8 excluded above) that are delivered from the associated MLD.
9
10
11 An MLD with dot11QMFActivated equal to false shall maintain a transmit MMPDU timer for each
12 MMPDU (except the frames that are excluded above). The transmit MMPDU timer shall be started when the
13 MMPDU is passed to the MAC.
14
15
(#6377)For an MLD with dot11QMFActivated equal to false, the frame retry counter and retry limit for each
16
17 MMPDU that belongs to a TC that requires acknowledgment is implementation specific.
18
19 An MLD with dot11QMFActivated equal to false shall continue to deliver the failed individually addressed
20 Management frame (except the frames that are excluded above) to an associated MLD on the setup links
21
subject to additional constraints (see 35.3.7 (Link management))) until any of the following conditions
22
23 occurs(#8244):
24 — The retry limit is met.
25
26 — The transmit MMPDU timer for the MMPDU exceeds dot11EDCATableMSDULifetime.
27 — The individually addressed Management frame is successfully delivered.
28
29
30 A STA affiliated with the MLD with dot11QMFActivated equal to false shall not transmit other individually
31 addressed Management frames (except the frames that are excluded above) to another STA affiliated with
32 the associated MLD while the current individually addressed Management frame (except the frames that are
33 excluded above) has not yet completed to the point of success, (#8203)failed due to retry limit, or other MAC
34 discard (e.g., lifetime expiration).
35
36
37 35.3.15 Multi-link group addressed frame delivery and reception
38
39 35.3.15.1 Group addressed frame delivery
40
41
42 Each AP affiliated with an AP MLD shall schedule for transmission buffered group addressed frames
43 immediately after every DTIM beacon except that a TWT scheduling AP affiliated with that AP MLD shall
44 schedule for transmission the buffered group addressed frames during the broadcast TWT SPs located
45 within the beacon interval during which the DTIM Beacon frame is transmitted (see 26.8.3.2 (Rules for
46 TWT scheduling AP)).
47
48
49 (#4305)(#1809)An AP MLD that broadcasts the group addressed MPDU received from an associated non-
50 AP MLD shall set the SA field of the broadcast group addressed MPDU to the MLD MAC address of the
51 non-AP MLD.
52
53
54 Each AP affiliated with an AP MLD shall schedule:
55 — the transmission of the buffered group addressed Management frames independently from the
56 transmission of buffered group addressed Management frames of other AP(s) affiliated with the
57
same AP MLD.
58
59 — the transmission of the buffered group addressed (#4115)Data frames that are expected to be
60 received by a non-AP MLD in all the (#6644)(#8245)enabled links setup with the non-AP MLD.
61
62
63 If an AP affiliated with an AP MLD is not part of a multiple BSSID set or the AP corresponds to a
64 transmitted BSSID in a multiple BSSID set, then the AP shall indicate if each of the other AP(s) affiliated
65

Copyright © 2022 IEEE. All rights reserved. 411

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 with the same AP MLD has buffered group addressed frames by using a bit in the Partial Virtual Bitmap
2 field of the TIM element after the last bit corresponding to a nontransmitted BSSID (if any) (maximum
3
possible number of BSSIDs – 1) which is in the same multiple BSSID as the AP.
4
5 — The indication is in the DTIM beacon sent by the AP and is based on the latest information about the
6 other APs that the AP has when the AP schedules the DTIM beacon.
7
8 — These bits in the Partial Virtual Bitmap field of the TIM element for the other AP(s) affiliated with
9 the same AP MLD shall be contiguous.
10
11 NOTE—The AP indicates the presence of its buffered group addressed frames following 11.2.3.6 (AP operation).
12
13 If an AP affiliated with an AP MLD is a nontransmitted BSSID in a multiple BSSID set, then the AP that
14 corresponds to the transmitted BSSID in the same multiple BSSID set shall indicate if each of the other
15 AP(s) affiliated with the same AP MLD as the (#6376)nontransmitted BSSID has buffered group addressed
16
frames by using a bit in the Partial Virtual Bitmap field of the TIM element after the last bit corresponding to
17
18 the nontransmitted BSSID (if any) (maximum possible number of BSSIDs – 1) which is in the same multiple
19 BSSID as the AP.
20 — The indication is in the DTIM beacon corresponding to that nontransmitted BSSID sent by the
21
22 transmitted BSSID of the same multiple BSSID set as the nontransmitted BSSID and is based on the
23 latest information about the other APs affiliated with the AP MLD that the transmitted BSSID has
24 when it schedules the DTIM beacon.
25
— These bits in the Partial Virtual Bitmap field of the TIM element for the other AP(s) affiliated with
26
27 the same AP MLD shall be contiguous.
28
29 35.3.15.2 Group addressed frame reception
30
31
A non-AP STA affiliated with a non-AP MLD shall follow the item (e) defined in 11.2.3.7 (Receive
32
33 operation for STAs in PS mode) to receive the group addressed BUs sent by (#8246)its associated AP
34 affiliated with the associated AP MLD.
35
36 If an indication of buffered group addressed frames in the TIM element about an AP affiliated with an AP
37
MLD is received by any STA affiliated with a non-AP MLD, the STA affiliated with the non-AP MLD that
38
39 is associated with the AP and that stays awake to receive group addressed BUs shall elect to receive all
40 group addressed frames that are scheduled for delivery in (#8247)the link that the STA is operating on.
41
42 (#4305)(#1809)A non-AP MLD shall filter out the group addressed MPDU with the SA field set to the MLD
43
MAC address of the non-AP MLD.
44
45 (#4280)(#8044)NOTE 1—Duplicate group addressed Data frames detection is performed by a non-AP STA affiliated
46 with a non-AP MLD according to 10.3.2.14.3 (Receiver requirements).
47
48 (#4278)NOTE 2—Additional and exceptional rules of group addressed frame delivery and reception for NSTR mobile
49 AP MLD are defined in 35.3.19 (NSTR mobile AP MLD operation(#5386)).
50
51
52 35.3.16 Multi-link channel access
53
54 35.3.16.1 General
55
56
(#4840)A STA, which is affiliated with an MLD, (#4214)shall contend for the WM on its link independently
57
58 from the other STA(s) affiliated with the same MLD, unless explicitly stated otherwise in the
59 (#4214)subclauses below.
60
61 35.3.16.2 Multi-link device capability signaling(#4752)(#4116)
62
63
64 (#2139)(#1465)(#1796)(#4076)(#5764)(#6312)(#4403)(#8248)(#6856)(#6857)(#6983)An AP MLD shall
65 set the Maximum Number Of Simultaneous Links subfield in the (#6700)Basic Multi-Link element to the

412 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 number of affiliated APs minus 1, in which the number of affiliated APs in the AP MLD shall be greater
2 than 1.
3
4
5 (#6313)(#7342)(#6137)(#7343)(#7630)(#7728)If dot11EHTBaseLineFeaturesImplementedOnly is equal to
6 true, an NSTR mobile AP MLD shall set the Maximum Number of Simultaneous Links subfield of the
7 (#6700)Basic Multi-Link element carried in transmitted Management frames to 1.
8
9
(#2139)(#1465)(#1796)A single radio non-AP MLD shall set the Maximum Number Of Simultaneous Links
10
11 subfield in the (#6700)Basic Multi-Link element (#4404)carried in transmitted Management frames to 0.
12
13 (#7623)An non-AP MLD with dot11EHTEMLSROptionImplemented equal to true shall set the Maximum
14 Number Of Simultaneous Links subfield in the (#6700)Basic Multi-Link element to 0.
15
16
17 (#2139)(#1465)(#1796)A multi-radio non-AP MLD shall set the Maximum Number Of Simultaneous Links
18 subfield in the (#6700)Basic Multi-Link element (#4404)carried in transmitted Management frames to a
19 value equal to or larger than 1.
20
21
A multi-radio non-AP MLD shall announce each pair of links formed by links that requested
22
23 (#6858)(#4830)a multi-link setup as STR or NSTR in a transmitted (Re)Association Request
24 frame(#1466)(#1656)(#4831).
25
26 (#1078)(#1475)(#2981)An MLD shall set the MLD Capabilities Present subfield in the Multi-Link Control
27
field of the (#6700)Basic Multi-Link element to 1 when carried in a (Re)Association Request frame or
28
29 (Re)Association Response frame(#4002).
30
31 An MLD shall set the NSTR Link Pair Present subfield value to 1 in a STA Control field that corresponds to
32
link ID i (where 0  i  15 ) only if it is a multi-radio MLD and contains at least one NSTR link pair formed
33
34 by the link with link ID i; otherwise it shall set the subfield value to 0. (#6314)(#8206)An NSTR mobile AP
35 MLD shall set the NSTR Link Pair Present subfield value to 1 in the STA Control field that corresponds to
36 link ID i. (#5386)An AP MLD that is not an NSTR mobile AP MLD shall set the NSTR Link Pair Present
37 subfield value in each STA Control field to 0.
38
39
40 An MLD shall set to 0 every bit in the NSTR Indication Bitmap subfield of the (#6700)Basic Multi-Link
41 element(#6769) that corresponds to a link pair where one of the STAs in the link pair operates in the
42 2.4 GHz band and the other STA operates in the 5 GHz or 6 GHz band.
43
44
45 A non-AP MLD may set the Frequency Separation For STR subfield to a nonzero value if it intends to
46 indicate the minimum frequency separation that is recommended between two links for the non-AP MLD
47 for STR operation; otherwise the non-AP MLD shall set the Frequency Separation For STR subfield to 0.
48
49 An AP MLD might take into account the information provided by associated non-AP MLDs in the
50
51 Frequency Separation For STR subfield in their transmitted Multi-Link elements when the AP MLD intends
52 to set up BSSs in the future referring to the information provided by those non-AP MLDs(#7627) or switch
53 the BSS operating channel of one or more of the setup links with those non-AP MLDs. How the AP MLD
54 uses the information provided by the Frequency Separation For STR subfield is out of scope of the
55 standard(#7856).
56
57 NOTE 1—The non-AP MLD ensures that the minimum frequency separation indicated in the Frequency Separation For
58 STR subfield starts from the frequency edge of the maximum supported bandwidth indicated by the Supported Channel
59 Width Set subfield in the HE Capabilities element and the Support For 320 MHz in 6 GHz subfield(#7628) in the EHT
60 Capabilities element of each link.
61
62 The ability of a non-AP MLD to perform STR operation(#4474) on a pair of setup links may change after
63
64 multi-link setup. The non-AP MLD may use a Management frame on any enabled link to inform the AP
65 MLD about the ability change to perform STR operation(#4474).

Copyright © 2022 IEEE. All rights reserved. 413

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 NOTE 2—The ability might change due to an AP switching BSS operating channels of one or more of the setup links
2 with the non-AP MLD(#6313)(#6314).
3
4
5 35.3.16.3 Simultaneous transmit and receive (STR) operation
6
7 (#1215)(#1433)(#2748)When a pair of links on which an MLD operates is an STR link pair, a STA that is
8 affiliated with the MLD and that is operating on a link in that STR link pair shall access the WM on that link
9 by following the rules defined in 10.3 (DCF) and 10.23.2 (HCF contention based channel access (EDCA))
10
11 regardless of any activity occurring on the other link within that STR link pair, except as specified in
12 35.3.16.4 (Nonsimultaneous transmit and receive (NSTR) operation).
13
14 (#1698)(#1794)(#5386)All pairs of links where an AP MLD that is not an NSTR mobile AP MLD operates
15 shall be STR link pairs.
16
17
18 (#1699)(#1794)(#1083)A non-AP MLD shall announce whether each pair of links where the MLD operates
19 is the STR link pair or the NSTR link pair if there exists at least on NSTR link pair as defined in 35.3.16.2
20 (Multi-link device capability signaling(#4752)(#4116)).
21
22
23 (#2138)(#2553)(#1175)Figure 35-14 (Channel access of two MLDs over an STR link
24 pair(#6493)(#2553)(#1175)) shows an example of an AP MLD and a non-AP MLD that are operating over
25 an STR link pair and that are contending for access to the WM and subsequent frame exchanges between
26 two MLDs on those links. After the AP MLD has (#6309)performed a multi-link setup with the non-AP
27 MLD to set up link 1 and link 2 successfully and the links are enabled, then AP 2 may receive data frames
28
29 from STA 2 on link 2, while AP 1 contends for the WM and then transmits data frames to STA 1 on link 1
30 (#4725)after it obtains a TXOP.
31
32
AP MLD Non‐AP MLD
33 AP 1 Data
34
35 Link 1
AP 1 STA 1 Ack STA 1
36
37
38 AP 2 Ack
39 AP 2 Link 2 STA 2
40 STA 2 Data
41
42
43 Figure 35-14—Channel access of two MLDs over an STR link pair(#6493)(#2553)(#1175)
44
45
46
47 35.3.16.4 Nonsimultaneous transmit and receive (NSTR) operation
48
49 (#1700)(#1701)A pair of links that is not indicated as an NSTR pair is an STR pair.
50
51 (#2100)(#2101)(#3147)An AP (#4473)affiliated with an MLD that has gained the right to initiate
52
53 transmission of a frame of an AC on a link through the rules for EDCA backoff in 10.23.2.4 (Obtaining an
54 EDCA TXOP) (#7823)may choose to not transmit any frame from the transmission queue for that AC due to
55 expected NSTR based interference (#4726)at the intended recipient MLD and lack of availability of an
56 alternative frame in the queue that would not (#4217)introduce the opportunity for such interference.
57
58
59 A non-AP STA (#4473)affiliated with an MLD that has gained the right to initiate transmission of a frame of
60 an AC on a link through the rules for EDCA backoff in 10.23.2.4 (Obtaining an EDCA TXOP) (#7823)may
61 choose to not transmit any frame corresponding to that AC due to expected NSTR based interference at
62 another STA within the MLD and lack of availability of an alternative frame in the queue that would not
63 (#4217)introduce the opportunity for such interference.
64
65

414 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 An AP or non-AP STA (#4219)that has gained the right to initiate transmission of a frame as described in
2 10.23.2.4 (Obtaining an EDCA TXOP) for an AC but (#7785)does not transmit any frame corresponding to
3
that AC for the reasons stated above may:
4
5 — (#5290)invoke a backoff for the EDCAF associated with that AC as allowed per item h) of 10.23.2.2
6 (EDCA backoff procedure)
7
8 — consider the (#4828)transmit queue for that AC as empty until any frame exists in the queue
9 (#4829)which if transmitted, the transmitter determines, will not cause an unacceptable level of
10 NSTR interference, at which time the queue is considered to have become nonempty and
11 (#6958)backoff is invoked per the procedure described in item a) of 10.23.2.2 (EDCA backoff
12
procedure) regardless of whether if the medium is busy or not.
13
14
15 An AP MLD should not transmit a frame that solicits an immediate response to a STA that is affiliated with
16 a non-AP MLD on a link that is a member of one or more NSTR link pairs for that non-AP MLD, if the
17 immediate response is expected to overlap in time with group addressed MPDUs scheduled (#4222)on a link
18
that is a member of any of those NSTR link pairs and (#4223)any of the other STA(s) affiliated with the non-
19
20 AP MLD is expected to be receiving those group addressed MPDUs.
21
22 If a STA that is affiliated with a non-AP MLD successfully obtains a TXOP on one link of one of its NSTR
23 link pairs before the TBTT of the other link of the NSTR link pair, then it should end its TXOP before the
24
TBTT of the other link (#6855)if the other STA affiliated with the same non-AP MLD intends to receive
25
26 (#4224)the Beacon frame scheduled at that TBTT on that link.
27 NOTE—The STA might not do so if it is not aware of the TSF of the other link.
28
29
30 35.3.16.5 PPDU end time alignment
31
32 35.3.16.5.1 General(#4229)
33
34
In this subclause “simultaneously transmit” means more than one PPDU is transmitted on more than one
35
36 link, where each PPDU is transmitted over one link, and those transmissions overlap in time. Likewise,
37 “simultaneously trigger” means more than one HE or EHT TB PPDU is triggered on more than one link,
38 where each PPDU is triggered over one link, and those transmissions overlap in time. If (#7555)an NSTR
39 MLD that is receiving a PPDU on a first link simultaneously transmits another PPDU on a second link, then
40
the NSTR MLD might fail to receive the PPDU on the first link because of the interference caused by its
41
42 transmission on the second link. This subclause specifies a mechanism to align the end time of PPDUs that
43 are simultaneously transmitted to the same NSTR non-AP MLD, which helps reduce the chances of the
44 occurrence of such self-interference among STAs (#6581)affiliated with the same NSTR MLD.
45
46
When an AP MLD simultaneously transmits more than one PPDU to the same NSTR non-AP MLD and at
47
48 least one of the PPDUs carries a frame that is a QoS data soliciting an immediate response, then
49 — The AP shall align the end time of the PPDUs soliciting an immediate response per the rules defined
50 in this subclause, except if the PPDU carries a high priority frame.
51
52 NOTE 1— In this way the response PPDU to any of the PPDUs transmitted by the AP will not overlap with any of these
53 PPDUs.
54
55 When an AP MLD is required to align the end time of simultaneously transmitted PPDUs, it shall satisfy the
56
57 following conditions:
58 — The AP MLD shall ensure that the difference between the end times of simultaneously transmitted
59 PPDUs is less than or equal to 8 μs (see NOTE 2), where the end time of the PPDU is the time of the
60
end of the last OFDM symbol or the time of the end of the packet extension if present, whichever is
61
62 later.
63
64
65

Copyright © 2022 IEEE. All rights reserved. 415

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — The AP MLD shall ensure that the end time of one or more PPDUs that carries a frame soliciting an
2 immediate response frame is at most 4 μs (see NOTE 3) earlier than the end time of any of PPDUs
3
containing a Trigger frame with the CS Required subfield set to 1.
4
5 NOTE 2—The difference between the end times of transmitting PPDUs needs to be less than SIFS minus a timing
6 margin, so that the response PPDU to any of the PPDUs transmitted by the AP will not overlap with any of these PPDUs.
7 To balance the implementation complexity at a transmitter side and a receiver side, the timing margin is set to half of
8 SIFS.
9
10 NOTE 3—The value of 4 μs is derived from aRxTxTurnaroundTime being equal to 4 μs for the purpose of this
11 requirement.
12
13
14 An AP MLD may use any type of padding to align the end time of transmitted PPDUs, such as using the
15 Padding field in a Trigger frame, post-EOF A-MPDU padding, aggregating other MPDUs in the A-MPDU,
16 or a packet extension.
17
18
When an AP MLD simultaneously solicits one or more HE or EHT TB PPDUs from the same NSTR
19
20 non-AP MLD, each AP (#6581)affiliated with the AP MLD shall independently solicit an HE or EHT TB
21 PPDU following the mechanisms defined in 26.5.2 (UL MU operation) with the following exceptions:
22 — An AP (#6581)affiliated with the AP MLD shall not transmit a Trigger frame with the CS Required
23
24 subfield set to 1 to a STA (#6581)affiliated with (#7555)an NSTR non-AP MLD, when at least one
25 PPDU from other STAs (#6581)affiliated with the same NSTR non-AP MLD is scheduled for
26 transmission before a timer with a value of 12 μs (see NOTE 4) has expired after the PPDU
27 containing the Trigger frame.
28
29 — If the AP MLD allows the frames in the TB PPDUs to solicit control response frames from the AP
30 MLD, then the UL Length subfield values in the soliciting Basic Trigger frames shall be set to the
31 same value.
32
33 NOTE 4—12 μs is derived from aSIFSTime + aSignalExtension – aRxTxTurnaroundTime, where
34 aRxTxTurnaroundTime is equal to 4 μs for the purpose of this calculation.
35
36 The relationship between the end times of DL PPDUs sent over link 1, link 2, and link 3 between an AP
37 MLD and a STA MLD is shown in Figure 35-15 (PPDU end time alignment timing relationships). An AP in
38
the AP MLD operating on link 1 solicits an HE or EHT TB PPDU requiring the carrier sense from a STA in
39
40 the STA MLD. In this case the difference between the end time of the soliciting DL PPDU sent on link 1 and
41 the starting time of the first solicited PPDU (in the figure, Ack frame on link 2) that is sent from any STA in
42 the same STA MLD immediately after the soliciting DL PPDU is greater than or equal to 12 μs.
43 Accordingly, the end time of the soliciting PPDU sent on link 2 cannot be more than 4 μs earlier than the end
44
time of the soliciting PPDU sent on link 1. To avoid overlapping in time between any of the DL PPDUs and
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

416 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 the response PPDU to any of the DL PPDUs, the difference between the end times of the DL PPDUs on
2 link 2 and link 3 cannot be greater than 8 μs.
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20 Figure 35-15—PPDU end time alignment timing relationships
21
22
23
24 35.3.16.5.2 End time alignment of response PPDUs using SRC Control field(#4229)
25
26 An AP that is affiliated with an AP MLD shall set the SRS Support subfield in the Common Info field of the
27 (#6700)Basic Multi-Link element it transmits to 1 if its dot11SRSOptionImplemented is true; otherwise the
28
29 AP shall set it to 0.
30
31 (#4230)(#4411)(#5927)A non-AP STA affiliated with an NSTR non-AP MLD shall not transmit a PPDU
32 carrying an MPDU with SRS Control subfield to an AP unless a STA affiliated with the non-AP MLD has
33 received from the AP MLD a (#6700)Basic Multi-Link element with the SRS Support subfield equal to 1. A
34
35 non-AP STA shall not transmit a TB PPDU carrying an MPDU with SRS Control subfield.
36
37 An AP shall not transmit a PPDU (#4230)carrying an MPDU with SRS Control subfield to a STA.
38
39 NOTE 5—If the received SRS Support subfield from an AP is equal to 0, a non-AP STA might not be able to perform
40 multiple frame transmission in a TXOP over NSTR link pair(s) with the AP, unless the expected duration of solicited
41 PPDU transmitted on NSTR link pair(s) are the same.
42
43 (#4231)(#4481)(#7807)(#7808)If STAs affiliated with an NSTR non-AP MLD simultaneously transmit
44 PPDUs to the respective APs affiliated with an AP MLD that has dot11SRSOptionImplemented equal to
45 true, the transmitted PPDUs solicit control response frames and the NSTR non-AP MLD intends to align the
46
47 end times of the PPDUs sent in response by the peer APs, then at least one of the PPDUs soliciting a control
48 response frame shall carry an MPDU with SRS Control subfield. The STA shall set the PPDU Response
49 Duration subfield of the SRS Control subfield to a value that is equal to or longer than the maximum of the
50 expected duration of the response PPDUs on all links, where the expected duration of the response PPDU is
51 calculated based on the following parameters:
52
53 — PPDU format that includes HE SU PPDU, or EHT MU PPDU,
54 — Bandwidth that is equal to the bandwidth of the soliciting PPDU,
55
56 — NSS and number of LTFs that are equal to one,
57 — GI that is equal to the longest mandatory GI value (3.2 µs),
58
59 — MCS that is selected following the rate selection rules defined in 10.6.6.5 (Rate selection for control
60 response frames), 26.17.1 (Basic HE BSS operation), 26.15.3 (MCS, NSS, BW and DCM selection),
61 and 35.16 (EHT BSS operation),
62
63 — (#5995)(#5928)A PSDU length that is equal to or greater than the length of the Multi-STA BlockAck
64 frame expected in response to the soliciting PPDU.
65

Copyright © 2022 IEEE. All rights reserved. 417

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 An EHT AP affiliated with an AP MLD that transmits a PPDU in response to a frame containing an SRS
2 Control subfield shall:
3
4 — Have the duration of the PPDU to be equal to the duration that is specified in the PPDU Response
5 Duration subfield of the soliciting SRS Control subfield.
6
— Use at least the HE SU PPDU format or the EHT MU PPDU format addressed to a single STA for
7
8 the PPDU transmission. If the PSDU carried in the response PPDU contains an A-MPDU then the
9 contents of the A-MPDU shall be as defined in Table 9-533 (A-MPDU contents in the control
10 response context).
11
12 NOTE 6—If the PPDU carrying the response is an HE SU PPDU or an EHT MU PPDU addressed to one non-AP STA,
13 then the AP might use any type of padding to ensure that the duration of the PPDU is equal to the duration that is
14 specified in the PPDU Response Duration subfield of the soliciting SRS Control subfield.
15
16 35.3.16.6 Start time sync PPDUs medium access
17
18
(#1797)(#3323)(#2142)(#2434)(#2718)(#1772)(#3141)Each STA of an MLD operating on a pair of NSTR
19
20 links for that MLD that aligns the start times of the PPDUs scheduled for transmission on more than one link
21 shall ensure that the EDCA rules on each link permit access to the medium on all the links at the time of
22 issuance of the PHY-TXSTART.request for each link.
23
24 NOTE 1—The backoff counters for each link count down as specified in 10.23.2.4 (Obtaining an EDCA TXOP).
25
26 (#3398)(#2435)(#2718)(#1772)A STA of an MLD operating on a link that is part of an NSTR link pair for
27 that MLD shall follow the channel access procedure described below:
28
29 1) (#1510)The STA may initiate transmission on a link when the medium is idle as indicated by
30 the physical and virtual CS mechanism and one of the following conditions is met:
31
a) (#1757)The STA obtained an EDCA TXOP following the procedure in
32
33 10.23.2.4 (Obtaining an EDCA TXOP).
34 b) (#1757)The backoff counter of the STA is already zero, and the STA operating on the
35 other link of NSTR link pair of the affiliated MLD obtains an EDCA TXOP following the
36
37 procedure in 10.23.2.4 (Obtaining an EDCA TXOP).
38 2) When the backoff counter of the STA reaches zero, it may choose to not transmit and keep its
39 backoff counter at zero.
40
41 3) (#1349)(#1509)If the backoff counter of the STA has already reached zero, it may perform a
42 new backoff procedure following deferral procedures as described in 10.23.2.4 (Obtaining an
43 EDCA TXOP) and 10.3.4.3 (Backoff procedure for DCF). CW[AC] and QSRC[AC] are left
44 unchanged.
45
46 (#3399)NOTE 2—A STA with backoff counter that has already reached zero and there is a frame available for
47 transmission performs a new backoff procedure before being allowed to initiate a link following condition a).
48
49 (#1501)(#1502)(#1512)(#2211)A STA that chooses not to transmit after the backoff counter reached zero on
50
51 a link of NSTR link pair may have one or more EDCAF backoff counters with value zero on that link. The
52 STA that initiates transmission on that link following condition a) or b), and has one or more EDCAF
53 backoff counters that already reached zero shall choose only one implementation specific EDCAF for the
54 transmission.
55
56
57 (#1511)(#3205)A STA with backoff counter that has already reached zero on a link and has a frame
58 available for transmission shall follow channel access procedures described in 10.23.2.4 (Obtaining an
59 EDCA TXOP).
60
61 (#2211)(#2741)The STA with backoff counter that has already reached zero and is initiating transmission
62
63 following condition b) is not mandated to initiate transmission on a slot boundary of the link on which the
64 STA operates. The STA that is initiating transmission following condition b) shall commence the
65

418 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 transmission no later than 4 µs following slot boundary of the link on which the other STA whose backoff
2 counter reaches zero operates.
3
4
5 35.3.16.7 Error recovery on a NSTR link pair within PIFS(#8196)
6
7 After two PPDUs with end time alignment (and the PPDUs carrying the expected response frames also have
8 end time alignment) are transmitted by each STA affiliated with an MLD on two links that belong to a NSTR
9
link pair of the MLD, if the two STAs intend to transmit more PPDUs on both links in their respective
10
11 TXOPs, when a failure happens on at least one of the two links, the MLD conducts the procedures described
12 in this subclause.
13
14 If the MLD ensures that the difference between the end times of the two PPDUs carrying the expected
15
response frames is less than or equal to 4 µs, the MLD may use either SIFS or PIFS between the end time of
16
17 the PPDU carrying the response frame and the next PPDU sent in the same TXOP on the link where the
18 response frame is received correctly, regardless of the PPDU receive status of the other link of the NSTR
19 link pair.
20
21 NOTE 1—The value of 4 µs is derived from aRxTxTurnaroundTime used in 35.3.16.5 (PPDU end time alignment).
22
23 NOTE 2—It is stricter to maintain the difference between the end times of the two PPDUs carrying the expected
24 response frame be less than or equal to 4 µs, when compared with the requirement of PPDU end time alignment in
25 35.3.16.5 (PPDU end time alignment).
26
27 If the MLD ensures that the difference between the end times of the two PPDUs carrying the expected
28
response frames is less than or equal to 8 µs (see 35.3.16.5 (PPDU end time alignment)), after two PPDUs
29
30 with end time alignment (and the PPDUs carrying the expected response frames also have end time
31 alignment) are transmitted by STAs affiliated with the MLD on two links that belongs to a NSTR link pair of
32 the MLD, if PHY-RXSTART.indications are received on both links, but the response frames contained in the
33 corresponding PPDUs are not successfully received in at least one of the links of the NSTR link pair, then:
34
35 — On the link that the response frame ends last, if the response frame is successfully received, the time
36 from the end of the PPDU carrying the response frame to the next PPDU sent in the same TXOP
37 should be larger than or equal to SIFS and smaller than or equal to PIFS;
38
39 — On the link that the response frame ends last, if the response frame is not successfully received (i.e.,
40 FCS fails), the time from the end of the PPDU carrying the response frame to the next PPDU sent in
41 the same TXOP should be larger than or equal to PIFS - 4 µs and smaller than or equal to PIFS;
42
43 — On the link that the response frame ends first, the time from the end of the PPDU carrying the
44 response frame to the next PPDU sent in the same TXOP should be PIFS.
45
46 If the time from the end of the received PPDU carrying the response frame to the next PPDU sent in the
47 same TXOP is larger than SIFS and less than PIFS, then the STA affiliated with the MLD shall ensure that
48
49 the medium is idle through an ED-based CCA before the transmission of the next PPDU.
50
51 35.3.16.8 Medium access recovery procedure
52
53 35.3.16.8.1 General
54
55
56 A STA affiliated with a non-AP MLD that operates on (#7555)an NSTR link pair is considered to have lost
57 medium synchronization (see definition in 3.2 (Definitions specific to IEEE 802.11)(#8208)) when the other
58 STA, which is affiliated with the same MLD and operates on that link pair, transmits a PPDU, except when
59 both STAs ended a transmission at the same time(#4754).
60
61
62 A STA that has lost medium synchronization as described above shall start a MediumSyncDelay timer at the
63 end of that transmission if that transmission(#5450) is longer than aMediumSyncThreshold unless its
64 previous MediumSyncDelay timer has not expired(#4837). The STA may not (re)start the
65

Copyright © 2022 IEEE. All rights reserved. 419

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 MediumSyncDelay timer if the transmission event is shorter than or equal to aMediumSyncThreshold.

2 (#4234)The aMediumSyncThreshold is set to 72 µs.
3
4 (#4234)NOTE 1—The value of 72 µs is chosen to cover at least the PPDU lengths of RTS/CTS/ACK frames using non-
5 HT or non-HT duplicated PPDU format with 6 Mbps data rate, as well as the PPDU lengths of most typical BlockAck
6 frames.
7
8 (#6352)When a non-AP MLD is operating in the EMLSR mode, a STA affiliated with a non-AP MLD that is
9
operating on one of the EMLSR links is considered to have lost medium synchronization if it is not able to
10
11 perform CCA during frame exchanges that includes the link switch delays between an AP affiliated with an
12 AP MLD and one of the other STAs operating on the other EMLSR links, which are affiliated with the same
13 non-AP MLD. The STA that has lost medium synchronization shall start a MediumSyncDelay timer
14 immediately after returning to the listening operation if the duration of the loss of medium synchronization
15
is longer than aMediumSyncThreshold; otherwise, the STA may not start the MediumSyncDelay timer.
16
17 (#6352)NOTE 2—The link switch delays include the delay switching from the listening operation to the frame
18 exchanges and the delay switching from the frame exchanges to the listening operation.
19
20
The MediumSyncDelay timer is a single timer, shared by all EDCAFs within a non-AP STA, which is
21
22 initialized to aPPDUMaxTime defined in Table 36-70 (EHT PHY characteristics). A non-AP STA(#6775)
23 shall update its MediumSyncDelay timer with the value contained in the Medium Synchronization
24 Information field, if present, of the (#6700)Basic Multi-Link element in the most recent frame received from
25 its associated AP(#4414). In addition, the timer resets to zero when any of the following events occur:
26
27 — The STA receives a PPDU with a valid MPDU.
28 — The STA receives a PPDU whose corresponding RXVECTOR parameter TXOP_DURATION is not
29
UNSPECIFIED.
30
31
32 (#4837)If a non-AP STA that operates on a NSTR link pair has lost medium synchronization, due to
33 transmission by another STA that is affiliated with the same MLD and operates on that link pair, and its
34 previous MediumSyncDelay timer has not expired, then at the end of that transmission it shall continue the
35
previous MediumSyncDelay timer except that the STA shall update the timer value as described above if
36
37 that transmission is longer than aMediumSyncThreshold.
38
39 35.3.16.8.2 MediumSyncDelay OFDM ED based recovery procedure(#6352)
40
41
(#7781)(#5745)The CCA-ED of a non-AP STA that is capable of obtaining a TXOP while the
42
43 MediumSyncDelay timer has a nonzero value shall use dot11MSDOFDMEDthreshold instead of
44 dot11OFDMEDThreshold in order to detect a channel busy condition (see 27.3.20.6.2 (CCA sensitivity for
45 operating classes requiring CCA-ED)) if the MediumSyncDelay timer has a nonzero value.
46
47
(#4727)(#4235)If a non-AP STA is capable of obtaining a TXOP while the MediumSyncDelay timer has a
48
49 nonzero value, it shall perform the following when the timer has a nonzero value:
50 — Shall transmit an RTS frame to its associated AP as the initial frame an obtained
51 TXOP(#4235)(#4416).
52
53 — Shall not attempt to initiate more than MSD_TXOP_MAX TXOPs since the start of the
54 timer(#4417).
55
56
Otherwise, it shall perform CCA until the MediumSyncDelay timer has expired before it initiates a
57
58 transmission.
59
60 (#7779)A STA that has a nonzero MediumSyncDelay timer shall not transmit any PPDU using OBSS PD-
61 based spatial reuse operation.
62
63
64 An AP affiliated with an MLD may include the Medium Synchronization Delay Information field in a
65 (#6700)Basic Multi-Link element carried in an Association Response, Beacon, or Probe Response frame.

420 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#4002)A STA affiliated with a non-AP MLD shall not include the Medium Synchronization Delay
2 Information field in any (#6700)Basic Multi-Link element it transmits.
3
4
5 A non-AP STA shall initialize dot11MSDOFDMEDthreshold to –72 dBm and MSD_TXOP_MAX to 1,
6 respectively. A non-AP STA affiliated with a non-AP MLD shall set MSD_TXOP_MAX and
7 dot11MSDOFDMEDthreshold to the most recent values in the Medium Synchronization Maximum Number
8 Of TXOPs and Medium Synchronization OFDM ED Threshold subfields, respectively, if they are present in
9
a (#6700)Basic Multi-Link element received from its associated AP(#4414).
10
11 NOTE—If either the intra-BSS NAV or the Basic NAV(#5106) is nonzero in the non-AP STA affiliated with the non-AP
12 MLD when it starts the MediumSyncDelay timer, the non-AP STA does not initiate any TXOP and follow the same rules
13 as an HE STA to respond to any RTS or MU-RTS frame until both NAVs expire.
14
15
During the aCCAtime (see 36.3.20.6.3 (CCA sensitivity for occupying the primary 20 MHz channel))
16
17 immediately following the end of the transmission event that caused loss of medium synchronization and
18 subsequent initiation of the MediumSyncDelay timer at the non-AP STA, if the received signal strength
19 exceeds the CCA-ED threshold as given by dot11OFDMEDThreshold for the primary 20 MHz channel and
20 no start of a PPDU is detected, the STA should defer for EIFS beginning when the received signal strength
21
falls below the CCA-ED threshold.
22
23
24 35.3.16.8.3 AP assisted medium synchronization recovery procedure
25
26 (#6991)AP assisted medium synchronization recovery procedure is a service provided by an AP MLD to
27
help a non-AP STA affiliated with a non-AP MLD that has lost medium synchronization to transmit a frame
28
29 without causing the collision with the existing transmission.
30
31 (#6605)An AP affiliated with an AP MLD with dot11AAROptionImplemented equals to true shall set the
32 AAR Support subfield in the MLD Capabilities field in a Basic Multi-Link element it transmits to 1;
33
otherwise the AP shall set the AAR Support subfield to 0.
34
35
36 (#6605)(#4239)A STA affiliated with a non-AP MLD with dot11AAROptionImplemented equal to true and
37 that belongs to (#7555)an NSTR link pair shall transmit the AAR Control subfield in a frame that solicits an
38 immediate response to its associated AP affiliated with an AP MLD if it has received a Basic Multi-Link
39
element from the AP with the AAR Support subfield equal to 1 (#4755)and an assisted STA that belongs to
40
41 the NSTR link pair needs assistance in transmitting frames to its associated AP in the other link.
42
43 (#6926)The AAR Control subfield transmitted by the STA shall indicate the link identifier(s) of the other
44 assisting AP(s) affiliated with the same AP MLD operating on the enabled link(s) by setting the
45
corresponding bits to 1.
46
47
48 (#4240)Each of the other assisting AP(s) affiliated with the AP MLD should schedule for a transmission a
49 Trigger frame to the assisted STA that is associated with it and affiliated with the non-AP MLD to solicit an
50 UL frame(s) (#6926)(#4731)after the AP affiliated with the same AP MLD successfully received the AAR
51
Control subfield in a frame if it does not have frame exchanges already scheduled with another STA.
52
53 (#5707)NOTE—If the CS Required subfield in a Trigger frame is 1, then the non-AP STA uses CCA-ED threshold as
54 defined in 36.3.20.6 (CCA sensitivity) during the SIFS between the Trigger frame and the PPDU sent in response to the
55 Trigger frame.
56
57
A non-AP STA with dot11AAROptionImplemented equals to false shall not transmit a frame containing an
58
59 AAR Control subfield to its associated AP.
60
61 (#6991)A non-AP STA shall not transmit a frame containing an AAR Control subfield with a value of 1 in
62 the bit identifying the link identifier of the associated AP.
63
64
65 (#4239)An AP shall not transmit the AAR Control subfield in a frame to its associated non-AP STAs.

Copyright © 2022 IEEE. All rights reserved. 421

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 35.3.16.9 Multi-link retransmit procedures(#1064)(#2714)(#2598)(#2761)(#3381)

2
3
(#2909)If an MLD has (#6379)an established block ack agreement with another MLD for a TID, and the
4
5 transmission of a QoS Data frame of the TID on a link is unsuccessful, and if the frame is not a fragment, the
6 MLD may attempt retransmissions of the frame on any link (#4485)to which the TID is mapped, subject to
7 the applicable lifetime limit for that frame and subject to any other restrictions that apply to the link where
8 the retransmission is scheduled(#2714)(#2761).
9
10
11 (#3381)If an MLD does not have a block ack agreement with another MLD for a TID, then the (#6323)QoS
12 Data frames for that TID with failed transmission attempts are delivered following the rules defined in
13 35.3.13 (Multi-link device individually addressed data delivery without block ack negotiation).
14
15 (#2598)NOTE—A retransmitted (#6323)QoS Data frame is not encapsulated with a new PN when retransmitted on
16 another link.
17
18 (#6323)Individually addressed management frames with failed transmission attempts are delivered
19 following the rules defined in 35.3.14 (Multi-link device individually addressed Management frame
20
delivery(#2496)).
21
22
23 35.3.17 Enhanced multi-link single radio operation
24
25 (#4759)(#5766)(#6342)A non-AP MLD may operate in the EMLSR mode on a specified set of the enabled
26
links between the non-AP MLD and its associated AP MLD(#2332). The specified set of the enabled links
27
28 in which the EMLSR mode is applied is called EMLSR links. The EMLSR links shall be indicated in the
29 EMLSR Link Bitmap subfield of the EML Control field of the EML Operating Mode Notification frame by
30 setting the bit positions of the EMLSR Link Bitmap subfield to 1. For the EMLSR mode enabled in a single-
31 radio non-AP MLD, the STA(s) affiliated with the non-AP MLD that operates on the link(s) that
32
corresponds to the bit position(s) of the EMLSR Link Bitmap subfield set to 0 shall be in doze state if a STA
33
34 affiliated with the non-AP MLD that operates on one of the EMLSR links is in awake state.
35
36 (#6776)When a non-AP MLD with dot11EHTEMLSROptionImplemented equal to true (re)associates with
37 an AP MLD, the EMLSR mode is disabled by default.
38
39
40 (#2143)(#3206)An MLD with dot11EHTEMLSROptionImplemented equal to true shall set the EML
41 Capabilities Present subfield to 1 and shall set the EMLSR Support subfield of the Common Info field of the
42 (#6700)Basic Multi-Link element (9.4.2.312.2 (Basic Multi-Link element(#6700))) to 1(#2915)(#5058) in
43 all Management frames that include the Basic Multi-Link element except Authentication frames. (#6741)An
44
MLD with dot11EHTEMLSROptionImplemented equal to false and
45
46 dot11EHTEMLMROptionImplemented equal to true (see 35.3.18 (Enhanced multi-link multi-radio
47 operation)) shall set the EML Capabilities Present subfield to 1 and shall set the EMLSR Support subfield of
48 the EML Capabilities subfield to 0. (#6741)An MLD with dot11EHTEMLSROptionImplemented equal to
49 false and dot11EHTEMLMROptionImplemented equal to false shall set the EML Capabilities Present
50
subfield to 0.
51
52
53 (#5845)(#6340)(#6341)(#7834)(#8353)When a non-AP MLD with dot11EHTEMLSROptionImplemented
54 equal to true intends to operate in the EMLSR mode on the EMLSR links, a STA affiliated with the non-AP
55 MLD shall transmit an EML Operating Mode Notification frame with the EMLSR Mode subfield of the
56
EML Control field of the frame set to 1 to an AP affiliated with an AP MLD with
57
58 dot11EHTEMLSROptionImplemented equal to true. An AP affiliated with the AP MLD that received the
59 EML Operating Mode Notification frame from the STA affiliated with the non-AP MLD should transmit an
60 EML Operating Mode Notification frame to one of the STAs affiliated with the non-AP MLD within the
61 timeout interval indicated in the Transition Timeout subfield in the EML Capabilities subfield of the Basic
62
Multi-Link element starting at the end of the PPDU transmitted by the AP affiliated with the AP MLD as an
63
64 acknowledgement to the EML Operating Mode Notification frame transmitted by the STA affiliated with the
65 non-AP MLD. After the successful transmission of the EML Operating Mode Notification frame on one of

422 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 the EMLSR links by the STA affiliated with the non-AP MLD, the non-AP MLD shall operate in the
2 EMLSR mode and the STAs on the other links of the EMLSR links shall transition to active mode after the
3
transition delay indicated in the Transition Timeout subfield in the EML Capabilities subfield of the Basic
4
5 Multi-Link element or immediately after receiving an EML Operating Mode Notification frame from one of
6 the APs operating on the EMLSR links and affiliated with the AP MLD. A STA on one of the other links of
7 the EMLSR links shall not transmit a frame with the Power Management subfield set to 1 before receiving
8 the EML Operating Mode Notification frame from the AP affiliated with the AP MLD or before the end of
9
the timeout interval.
10
11
12 (#5845)(#6340)(#6341)(#7834)(#8353)When a non-AP MLD with dot11EHTEMLSROptionImplemented
13 equal to true intends to disable the EMLSR mode, a STA affiliated with the non-AP MLD shall transmit an
14 EML Operating Mode Notification frame with the EMLSR Mode subfield of the EML Control field of the
15
frame set to 0 to an AP affiliated with an AP MLD with dot11EHTEMLSROptionImplemented equal to
16
17 true. An AP affiliated with the AP MLD that received the EML Operating Mode Notification frame from the
18 STA affiliated with the non-AP MLD should transmit an EML Operating Mode Notification frame to one of
19 the STAs affiliated with the non-AP MLD within the timeout interval indicated in the Transition Timeout
20 subfield in the EML Capabilities subfield of the Basic Multi-Link element starting at the end of the PPDU
21
transmitted by the AP affiliated with the AP MLD as an acknowledgement to the EML Operating Mode
22
23 Notification frame transmitted by the STA affiliated with the non-AP MLD. After the successful
24 transmission of the EML Operating Mode Notification frame on one of the EMLSR links by the STA
25 affiliated with the non-AP MLD, the non-AP MLD shall disable the EMLSR mode and the STAs on the
26 other links of the EMLSR links shall transition to power save mode after the transition delay indicated in the
27
Transition Timeout subfield in the EML Capabilities subfield of the Basic Multi-Link element or
28
29 immediately after receiving an EML Operating Mode Notification frame from one of the APs operating on
30 the EMLSR links and affiliated with the AP MLD. A STA on one of the other links of the EMLSR links
31 shall not transmit a frame with the Power Management subfield set to 0 before receiving the EML Operating
32 Mode Notification frame from the AP affiliated with the AP MLD or before the end of the timeout interval.
33
34 (#5845)(#6340)(#6341)(#7834)(#8353)NOTE 1—Each of the STAs on the other links of the EMLSR links can transmit
35 a frame with the Power Management subfield set to 1 and transition to power save mode immediately after successful
36 transmission of the frame. (see 11.2.3.2 (Non-AP STA power management modes)).
37
38 When a non-AP MLD is operating in the EMLSR mode with an AP MLD supporting the EMLSR
39
mode(#8047), the following applies:
40
41 — (#4759)(#5766)(#6342)The non-AP MLD shall be able to listen on the EMLSR links, by having its
42 affiliated STA(s) corresponding to those links in awake state. The listening operation includes CCA
43 and receiving the initial Control frame of (#4758)frame exchanges that is initiated by the AP MLD.
44
45 — The initial Control frame of (#4758)frame exchanges shall be sent in the OFDM PPDU or non-HT
46 duplicate PPDU format using a rate of 6 Mbps, 12 Mbps, or 24 Mbps.
47
48 — The initial Control frame shall be an MU-RTS Trigger frame or a BSRP Trigger frame.
49 (#1582)Reception of MU-RTS and BSRP Trigger frames is mandatory for a non-AP MLD that is in
50 the EMLSR mode. The number of spatial streams for the response to the BSRP Trigger frame shall
51 be limited to one.
52
53 — (#2916)(#1773)(#3206)The non-AP MLD shall indicate (#7334)(#6325)the minimum MAC padding
54 duration of the Padding field of the initial Control frame in the (#6346)EMLSR Padding Delay
55 subfield of the EML Capabilities subfield in the Common Info field of the (#6700)Basic Multi-Link
56 element.
57
58 — (#4759)(#5766)(#6342)(#6350)An AP affiliated with the AP MLD that initiates frame exchanges
59 with the non-AP MLD on one of the EMLSR links shall begin the frame exchanges by transmitting
60 the initial Control frame to the non-AP MLD with the limitations specified above.
61
62 (#4698)NOTE 2—Whether to use the MU-RTS Trigger frame or the BSRP Trigger frame as the initial Control frame to
63 initiate the frame exchanges is implementation specific and out of scope of this standard.
64
65

Copyright © 2022 IEEE. All rights reserved. 423

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — (#4759)(#5766)(#6342)(#4758)After receiving the initial Control frame of frame exchanges

2 (#7336)(#5933)and transmitting an immediate response frame as a response to the initial Control
3
frame, a STA affiliated with the non-AP MLD that was listening on the corresponding link shall be
4
5 able to transmit or receive frames on the link in which the initial Control frame was received and
6 shall not transmit or receive on the other EMLSR link(s) until the end of the frame exchanges, and
7 subject to its spatial stream capabilities, operation mode, and link switch delay, the STA affiliated
8 with the non-AP MLD shall be capable of receiving a PPDU that is sent using more than one spatial
9
stream (#6658)on the link in which the initial Control frame was received a SIFS after the end of its
10
11 response frame transmission solicited by the initial Control frame. During the frame exchanges, the
12 other AP(s) affiliated with the AP MLD shall not transmit frames to the other STA(s) affiliated with
13 the non-AP MLD on the other EMLSR link(s)(#5222).
14
15 — (#5222)The non-AP MLD shall be switched back to the listening operation on the EMLSR links
16 after the time indicated in the EMLSR Transition Delay subfield of the EML Capabilities subfield in
17 the Common Info field of the Basic Multi-Link element if any of the following conditions is met and
18 this is defined as the end of the frame exchanges:
19
20 • The MAC of the STA affiliated with the non-AP MLD that received the initial Control frame
21 does not receive a PHY-RXSTART.indication primitive during a timeout interval of aSIFSTime
22 + aSlotTime + aRxPHYStartDelay starting at the end of the PPDU transmitted by the STA of the
23 non-AP MLD as a response to the most recently received frame from the AP affiliated with the
24
AP MLD or starting at the end of the reception of the PPDU containing a frame for the STA from
25
26 the AP affiliated with the AP MLD that does not require immediate acknowledgement.
27 • The MAC of the STA affiliated with the non-AP MLD that received the initial Control frame
28 receives a PHY-RXSTART.indication primitive during a timeout interval of aSIFSTime + aSlot-
29 Time + aRxPHYStartDelay starting at the end of the PPDU transmitted by the STA of the non-
30
AP MLD as a response to the most recently received frame from the AP affiliated with the AP
31
32 MLD or starting at the end of the reception of the PPDU containing a frame for the STA from the
33 AP affiliated with the AP MLD that does not require immediate acknowledgement and the STA
34 affiliated with the non-AP MLD does not detect, within the PPDU corresponding to the PHY-
35 RXSTART.indication any of the following frames:
36
- an individually addressed frame with the RA equal to the MAC address of the STA affili-
37
38 ated with the non-AP MLD
39 - a Trigger frame that has one of the User Info fields addressed to the STA affiliated with the
40 non-AP MLD
41 - a CTS-to-self frame with the RA equal to the MAC address of the AP affiliated with the AP
42
MLD
43
44 - a Multi-STA BlockAck frame that has one of the Per AID TID Info fields addressed to the
45 STA affiliated with the non-AP MLD
46 - a NDP Announcement frame that has one of the STA Info fields addressed to the STA affil-
47 iated with the non-AP MLD
48
• The STA affiliated with the non-AP MLD that received the initial Control frame does not
49
50 respond to the most recently received frame from the AP affiliated with the AP MLD that
51 requires immediate response after a SIFS.
52 — (#5222)The AP affiliated with the AP MLD should transmit before the TXNAV timer expires
53
54 another initial Control frame addressed to the STA affiliated with the non-AP MLD if the AP intends
55 to continue the frame exchanges with the STA and did not receive the response frame from this STA
56 for the most recently transmitted frame that requires an immediate response after a SIFS.
57
— (#6351)When a STA of the non-AP MLD initiates a TXOP the following applies:
58
59 • The non-AP MLD shall switch back to the listening operation on the EMLSR links after the time
60 duration indicated in the EMLSR Transition Delay subfield after the end of the TXOP.
61
62 — (#6777)Only one STA affiliated with the non-AP MLD that is operating on one of the EMLSR links
63 may initiate frame exchanges with the AP MLD.
64
65

424 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#6777)NOTE 3—A STA affiliated with a non-AP MLD operating in the EMLSR mode does not need to
2 transmit an initial Control frame to initiate frame exchanges with the AP MLD (#7831)(#7832)and follows the
3 rules defined in 10.3.2.4 (Setting and resetting the NAV) and in 10.23.2 (HCF contention based channel access
4 (EDCA)) to access the WM.
5
6 (#2346)(#3400)NOTE 4—A sounding sequence also follows the rules above.
7
8 (#6964)NOTE 5—When an AP affiliated with the AP MLD transmits an initial Control frame that initiates frame
9 exchanges with more than one non-AP MLD operating in the EMLSR mode, the AP ensures that the padding duration of
10 the Padding field of the initial Control frame is greater than or equal to the maximum of the values indicated in the
11 EMLSR Padding Delay subfield of the Basic Multi-Link element received from the non-AP MLDs with which the frame
12 exchanges are initiated.
13
14
15 (#7063)(#7337)An example of a frame exchange sequence that starts with the MU-RTS Trigger frame
16 between an AP affiliated with an AP MLD and a STA affiliated with a non-AP MLD that is in the EMLSR
17 mode is shown in Figure 35-16 (An example of a frame exchange sequence between an AP affiliated with an
18 AP MLD and a STA affiliated with a non-AP MLD that is in the EMLSR mode(#7063)(#7337)). An
19
example of a frame exchange sequence that starts with the BSRP Trigger frame between an AP (AP 1)
20
21 affiliated with an AP MLD and n STAs affiliated with n different non-AP MLDs that are in the EMLSR
22 mode is shown in Figure 35-17 (An example of a frame exchange sequence between an AP (AP 1) affiliated
23 with an AP MLD and n STAs affiliated with n different non-AP MLDs that are in the EMLSR
24 mode(#7063)(#7337)).
25
26
27
28 AP 1 affiliated
29 with AP MLD MU‐RTS A‐MPDU
30 SIFS SIFS SIFS
31 STA 1 affiliated
32 CTS BlockAck
33 with non‐AP MLD
34
35
36 Figure 35-16—An example of a frame exchange sequence between an AP affiliated with an
37
38
AP MLD and a STA affiliated with a non-AP MLD that is in the EMLSR mode(#7063)(#7337)
39
40
41
42
43 AP 1 affiliated BSRP EHT MU PPDU
44 with AP MLD Trigger SIFS SIFS with Trigger SIFS
45
46 STA 1 affiliated with EHT TB PPDU EHT TB PPDU 1 with
47 non‐AP MLD 1 1 with BSR acknowledgement
48 STA 1 affiliated with EHT TB PPDU EHT TB PPDU 2 with
49
non‐AP MLD 2 2 with BSR acknowledgement
50
51 : : :
52 : : :
53 : : :
54 STA 1 affiliated with EHT TB PPDU EHT TB PPDU n with
55 non‐AP MLD n n with BSR acknowledgement
56
57
58 Figure 35-17—An example of a frame exchange sequence between an AP (AP 1) affiliated
59 with an AP MLD and n STAs affiliated with n different non-AP MLDs that are in the EMLSR
60 mode(#7063)(#7337)
61
62
63
64 (#2346)(#3400)An example of an EHT non-TB sounding sequence with a single beamformee in the EMLSR
65 operation is shown in Figure 35-18 (An example of EHT non-TB sounding in the EMLSR operation). An

Copyright © 2022 IEEE. All rights reserved. 425

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 example of an EHT TB sounding sequence with a beamformee operating in the EMLSR mode (beamformee
2 1) and the other beamformees (beaformees 2, …, n) not operating in the (#5385)EMLSR mode is shown in
3
Figure 35-19 (An example of EHT TB sounding in the EMLSR operation (beamformee 1 is in the EMLSR
4
5 mode, the other beamformees are not in the EMLSR mode)). An example of an EHT TB sounding sequence
6 with beamformees operating in the EMLSR mode is shown in Figure 35-20 (An example of EHT TB
7 sounding in the EMLSR operation (BSRP is used as the initial Control frame)).
8
9
10
11 beamformer MU‐RTS
EHT NDP EHT sounding
12 SIFS SIFS Announcement SIFS NDP SIFS
13 beamformee CTS
EHT Compressed
14 Beamforming/CQI
15
16
17 Figure 35-18—An example of EHT non-TB sounding in the EMLSR operation
18
19
20
21
22
23 One or more sequences
24
25 EHT NDP EHT sounding BFRP
beamformer MU‐RTS
26 SIFS SIFS Announcement SIFS NDP SIFS Trigger SIFS
27 beamformee 1 CTS
EHT Compressed
28 Beamforming/CQI 1
29 beamformee 2
EHT Compressed
Beamforming/CQI 2
30 : :
31 : :
32 : :
EHT Compressed
33 beamformee n
Beamforming/CQI n
34
35
36 Figure 35-19—An example of EHT TB sounding in the EMLSR operation (beamformee 1 is
37 in the EMLSR mode, the other beamformees are not in the EMLSR mode)
38
39
40
41
42
One or more sequences
43
44
BSRP EHT NDP EHT sounding BFRP
45 beamformer
Trigger Announcement NDP Trigger
SIFS SIFS SIFS SIFS SIFS
46
EHT TB EHT Compressed
47 beamformee 1 PPDU 1 Beamforming/CQI 1
48
EHT TB EHT Compressed
49 beamformee 2
PPDU 2 Beamforming/CQI 2
50 : : :
51 : :
:
:
:
:
52 EHT TB EHT Compressed
53 beamformee n PPDU n Beamforming/CQI n
54
55
56 Figure 35-20—An example of EHT TB sounding in the EMLSR operation (BSRP is used as
57 the initial Control frame)
58
59
60 35.3.18 Enhanced multi-link multi-radio operation
61
62 A non-AP MLD may operate in the EMLMR mode on a specified set of the enabled links between the
63 non-AP MLD and its associated AP MLD. The specified set of the enabled links in which the EMLMR
64
mode is applied is called EMLMR links. (#4425)The EMLMR links shall be indicated in the EMLMR Link
65

426 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Bitmap subfield of the EML Control field of the EML Operating Mode Notification frame by setting the bit
2 positions of the EMLMR Link Bitmap subfield to 1.
3
4
5 An MLD with dot11EHTEMLMROptionImplemented equal to true shall set the EML Capabilities Present
6 subfield to 1 and shall set the EMLMR Support subfield of the Common Info field of transmitted Basic
7 Multi-Link elements to 1; otherwise, the MLD shall set the EMLMR Support subfield to 0.
8
9
(#4425)An MLD with dot11EHTEMLMROptionImplemented equal to true shall indicate the number of
10
11 spatial streams NSS that a non-AP MLD supports for reception and transmission during EMLMR operation
12 in the EMLMR Supported MCS And NSS Set subfield of the EML Control field of the EML Operating
13 Mode Notification frame.
14
15
16 (#4425)A STA affiliated with the non-AP MLD operating on any of EMLMR links shall not be a 20 MHz-
17 only non-AP EHT STA.
18
19 (#4425)The supported rates, HT-MCS, VHT-MCS, and HE-MCS for a bandwidth and NSS shall be the same
20
21 as the supported EHT-MCS for the corresponding bandwidth and NSS unless the corresponding MCS is not
22 defined. If the MCS is not defined in the corresponding PHY amendment, the highest MCS support is
23 implied.
24
25
26 If a non-AP MLD with dot11EHTEMLMROptionImplemented equal to true intends to switch EMLMR
27 mode after MLD association(#6608), then a non-AP STA affiliated with the non-AP MLD shall transmit an
28 EML Operating Mode Notification frame with EMLMR Mode subfield equal to 1 or 0 to enable or disable
29 EMLMR mode, respectively.
30
31
32 After successful transmission of the EML Operating Mode Notification frame from the non-AP STA
33 affiliated with the non-AP MLD to an AP affiliated with an AP MLD, the non-AP STA and the AP initialize
34 the transition timeout timer with the Transition Timeout subfield value in the EML Capabilities subfield of
35 the (#6700)Basic Multi-Link element received from the AP. The transition timeout timer begins counting
36 down from the end of the PPDU containing the immediate response to the EML Operating Mode
37
38 Notification frame. The AP should send an EML Operating Mode Notification frame to the non-AP STA
39 with EML Control field set to the same value as EML Control field in the received EML Operating Mode
40 Notification frame from the non-AP STA before the transition timeout expires.
41
42 The non-AP MLD shall transition to the indicated mode immediately after successfully receiving the EML
43
44 Operating Mode Notification frame from the AP or immediately after the transition timeout timer expires,
45 whichever comes first.
46
47 A non-AP MLD with dot11EHTEMLMROptionImplemented equal to true shall indicate the minimum
48 padding duration required for the non-AP MLD for EMLMR link switch in the EMLMR Delay subfield in
49
50 the Common Info field of transmitted (#6700)Basic Multi-Link elements.
51 NOTE—The link switching can happen during the transmission time of the initial response frame. However, the
52 duration of initial response frame can be different depending on the initial frame. The non-AP MLD might determine the
53 minimum padding duration such that it can be satisfied even when the shortest initial response frame is used on EMLMR
54 links (e.g., a CTS frame in non-HT PPDU with the highest rate in the BSSBasicRateSet parameters).
55
56
57 When an AP of an AP MLD transmits a PPDU that initiates a frame exchange with a non-AP MLD
58 operating in EMLMR mode, the AP shall ensure that the padding duration of the PPDU is longer than or
59 equal to the minimum padding duration value indicated by the EMLMR Delay field of the (#6700)Basic
60 Multi-Link element received from the non-AP MLD.
61
62
63 When a non-AP MLD operates in the EMLMR mode, after initial frame exchange subject to its per-link
64 spatial stream capabilities and operating mode on one of the EMLMR links, the non-AP MLD shall be able
65

Copyright © 2022 IEEE. All rights reserved. 427

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 to support the following until the end of the frame exchange sequence initiated by the initial frame
2 exchange:
3
4 — Receive PPDUs with the number of spatial streams up to the value as indicated in (#4425)the
5 EMLMR Supported MCS And NSS Set subfield of the EML Control field of the EML Operating
6 Mode Notification frame at a time on the link for which the initial frame exchange was made.
7
8 — Transmit PPDUs with the number of spatial streams up to the value as indicated in (#4425)the
9 EMLMR Supported MCS And NSS Set subfield of the EML Control field of the EML Operating
10 Mode Notification frame at a time on the link for which the initial frame exchange was made.
11
12
After the end of the frame exchange sequence, each STA of the non-AP MLD in the EMLMR mode shall be
13
14 able to transmit or receive PPDU, subject to its per-link spatial stream capabilities and operating mode and
15 subject to any switching delay indicated by the non-AP MLD.
16
17 35.3.19 NSTR mobile AP MLD operation(#5386)
18
19
20 35.3.19.1 General
21
22 (#5386)(#4207)An NSTR mobile AP MLD shall be an AP MLD which sets
23 (#5386)(#4206)dot11EHTNSTRMobileAPMLDImplemented to true. If
24
dot11EHTBaseLineFeaturesImplementedOnly is equal to true, an NSTR mobile AP MLD shall have one
25
26 NSTR pair of links and shall follow with the restrictions below:
27 — (#5386)Each AP affiliated with an NSTR mobile AP MLD is not required to support all the EHT AP
28 mandatory features
29
30 • (#5386)Support of MU operation is optional for the APs affiliated with an NSTR mobile AP
31 MLD
32 • (#5386)Support of two or more spatial streams is optional for the APs affiliated with a mobile
33
AP MLD(#4212)(#5268)
34
35 — (#5386)The NSTR mobile AP MLD is in a mobile device that is typically battery powered
36
37 (#5386)(#4210)(#6407)(#6501)(#6328)NOTE 1—Each AP (#6581)affiliated with an NSTR mobile AP MLD has
38 different MAC address
39
40 (#5386)(#4212)(#5268)An NSTR mobile AP MLD shall designate one link of an NSTR link pair as the
41 primary link. The NSTR mobile AP MLD shall schedule for transmissions of Beacon and Probe Response
42 frames and group addressed Data frames only on the primary link. The other link of the NSTR link pair is
43
44 the nonprimary link.
45
46 (#6967)TSF timers of all APs affiliated with an NSTR mobile AP MLD shall be the same.
47
48 (#6967)NOTE 2—A non-AP MLD that is associated with an NSTR mobile AP MLD follows the TSF timers of all APs
49 affiliated with an NSTR mobile AP MLD in each link. Since TSF timers of all APs affiliated with an NSTR mobile AP
50 MLD is the same, a non-AP MLD that is associated with an NSTR mobile AP MLD only needs to maintain one TSF
51 timer for all the links.
52
53 (#4081)(#5067)(#5268)A non-AP MLD shall perform frame exchanges during the authentication,
54 (re)association, and 4-way handshake procedures only on the primary link of the NSTR mobile AP MLD.
55
56 (#4081)(#5067)(#5268)NOTE 3—Any frames including management frames are disallowed to be transmitted on the
57 nonprimary link alone through EDCA channel access.
58
59 (#5386)STAs affiliated with a non-AP MLD that is associated with an NSTR mobile AP MLD and APs
60 affiliated with an NSTR mobile AP MLD shall follow the procedure defined in 35.3.16.6 (Start time sync
61
62 PPDUs medium access) when intending to transmit in the nonprimary link with the following additional
63 constraints(#4211):
64
65

428 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — (#5386)A STA affiliated with the non-AP MLD may initiate a PPDU transmission to its associated
2 AP affiliated with the NSTR mobile AP MLD in the nonprimary link only if the (#7425)other STA
3
affiliated with the same MLD in the primary link is also initiating the PPDU as a TXOP holder with
4
5 the same start time.
6 — (#5386)An AP affiliated with the NSTR mobile AP MLD may initiate a PPDU transmission to its
7 associated non-AP STA in the nonprimary link only if the (#7426)other AP affiliated with the same
8
9 NSTR mobile AP MLD in the primary link is also initiating the PPDU as a TXOP holder with the
10 same start time.
11
12 35.3.19.2 Discovery of an NSTR mobile AP MLD(#4079)
13
14
15 The discovery procedure for an NSTR mobile AP MLD is the same as the procedure described in 35.3.4
16 (Discovery of an AP MLD) with the following exceptions:
17 — An AP affiliated with an NSTR mobile AP MLD and that is operating on the primary link of an
18
NSTR link pair shall indicate that it is an NSTR mobile AP MLD by setting B7 of AP MLD Type
19
20 Indication subfield to 1 in MLD Capabilities field of Common Info field in the Basic Multi-Link
21 element.
22 — An AP affiliated with an NSTR mobile AP MLD and that is operating on the primary link of an
23
24 NSTR link pair shall include a Reduced Neighbor Report element with the MLD Parameters subfield
25 present in a TBTT Information field corresponding to a reported AP affiliated with the NSTR mobile
26 AP MLD and that is operating on the nonprimary link of the NSTR link pair in a Beacon and Probe
27 Response frames that it transmits. The Neighbor AP TBTT Offset subfield, the BSSID subfield, the
28 Short-BSSID subfield, the BSS Parameters subfield and the 20 MHz PSD subfield shall not be
29
30 present in the TBTT Information Field for that reported AP. The TBTT Information Field Type
31 subfield shall set to 1 to identify, together with the TBTT Information Length subfield, the format of
32 the TBTT Information field for the reported AP operating on the nonprimary link.
33
— A non-AP STA affiliated with a non-AP MLD shall not transmit a Probe Request frame to the AP
34
35 affiliated with the NSTR mobile AP MLD and that is operating on the nonprimary link of the NSTR
36 link pair. To request a complete profile of the AP operating on the nonprimary link, a non-AP STA
37 affiliated with a non-AP MLD may send an ML probe request frame to an AP affiliated with the
38 NSTR mobile AP MLD and that is operating on the primary link.
39
40
41 35.3.19.3 NSTR mobile AP MLD multi-link procedures for channel switching, extended
42 channel switching, and channel quieting(#4082)(#5699)(#6966)
43
44 Multi-link procedures for channel switching, extended channel switching, and channel quieting for an NSTR
45
mobile AP MLD follow the same rules defined in 35.3.11 (Multi-link procedures for channel switching,
46
47 extended channel switching, and channel quieting(#4112)(#2324)(#2600)) with the following exceptions:
48 — The timing fields in the Channel Switch Announcement element, the Extended Channel Switch
49 Announcement element, the Quiet element, and the Quiet Channel element shall be applied in
50
51 reference to the most recent TBTT and BI indicated in the corresponding element(s) of the AP
52 operating on the primary link.
53
54 35.3.20 Multi-link operation in a multiple BSSID set or co-hosted BSSID
55 set(#1095)(#2292)(#2540)
56
57
58 35.3.20.1 General
59
60 (#1096)(#2275)An AP MLD shall not have more than one affiliated AP amongst APs that are members of
61 the same multiple BSSID set.
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 429

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#1095)(#2292)(#2540)An AP MLD shall not have more than one affiliated AP amongst APs that are
2 members of the same co-hosted BSSID set.
3
4
5 (#1819)(#2295)Each AP affiliated with an (#4203)AP MLD shall be independently configured to operate as
6 a transmitted or as a nontransmitted BSSID in a multiple BSSID set, or as an AP belonging to a co-hosted
7 BSSID set, or as an AP that is (#4203)neither a member of a multiple BSSID set nor a member of a co-
8 hosted BSSID set. Annex AA provides example configurations. (#8253)Each AP MLD, that is affiliated
9
with APs belonging to a multiple BSSID set or a co-hosted BSSID set, shall independently assign a Link ID
10
11 to each of its affiliated APs.
12
13 (#4678)An AP affiliated with an AP MLD that is a member of a multiple BSSID set shall follow the
14 procedures described in 11.1.3.8 (Multiple BSSID Procedure). A non-AP STA affiliated with a non-AP
15
MLD shall follow the procedure described in 11.1.3.8 (Multiple BSSID Procedure) during discovery and
16
17 after association when the peer AP is a member of a multiple BSSID set. An AP affiliated with an AP MLD
18 that is a member of a co-hosted BSSID set shall follow the rules described in 26.17.7 (Co-hosted BSSID
19 set). A non-AP STA affiliated with a non-AP MLD shall follow the procedure described in 26.17.7 (Co-
20 hosted BSSID set) when the peer AP is a member of a co-hosted BSSID set.
21
22
23 (#3212)An AP corresponding to the transmitted BSSID shall not include a (#6700)Basic Multi-Link element
24 in the Nontransmitted BSSID Profile subelement of a Multiple BSSID element unless the corresponding
25 nontransmitted BSSID is affiliated with an AP MLD.
26
27
35.3.20.2 Inheritance in the per-STA profile of Basic Multi-Link element for an AP in a
28
29 multiple BSSID set(#3021)(#3212)(#6700)
30
31 When (#6700)Basic Multi-Link element is carried in a Nontransmitted BSSID Profile subelement in a
32 Multiple BSSID element, the value of an element, that is not present in the Per-STA Profile subelement of
33
the (#6700)Basic Multi-Link element for a reported AP, shall be the same as the corresponding element
34
35 value as that of the nontransmitted BSSID profile that carried the (#6700)Basic Multi-Link element or as the
36 element of the transmitted BSSID, present elsewhere in the frame, which is inherited by the nontransmitted
37 BSSID. The hierarchy of inheritance is from transmitted BSSID to the nontransmitted BSSID that carried
38 the (#6700)Basic Multi-Link element and from the nontransmitted BSSID to the AP reported in the per-STA
39
profile.
40
41
42 (#5737)Figure 35-21 (Example of inheritance in a complete per-STA profile for a multiple BSSID
43 scenario(#6700)) illustrates inheritance when a per-STA profile carries complete profile in a (#6700)Basic
44 Multi-Link element that is contained in a nontransmitted BSSID profile of a Multiple BSSID element. The
45
example shows a Management frame transmitted by an AP corresponding to the transmitted BSSID. The
46
47 Management frame carries several elements with their corresponding element IDs shown in parenthesis. The
48 frame also carries a Multiple BSSID element that includes profile for nontransmitted BSSID N. The
49 nontransmitted BSSID profile contains a (#6700)Basic Multi-Link element carrying complete profile for
50 AP x. The BSSID N is inheriting elements with IDs B, C, and E. Elements with ID D and ID F are specific
51
to BSSID N and appear in its nontransmitted BSSID profile. Further, the BSSID N does not inherit element
52
53 with ID A and the ID is listed in the Non-Inheritance element. Since the value of element F for BSSID N is
54 not the same as that advertised by the transmitted BSSID, the element is carried in the profile for BSSID N.
55 An element with ID Y is specific to the BSSID N and is included in its profile. AP x inherits elements with
56 IDs D and F directly from the BSSID N and element with ID C indirectly from the transmitted BSSID (via
57
the BSSID N’s inheritance). AP x does not inherit element A (same as nontransmitted BSSID). The
58
59 elements with IDs B and Y are specific to AP x and appear in its profile. Furthermore, AP x does not inherit
60
61
62
63
64
65

430 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 element E from the transmitted BSSID and the ID is listed in the Non-Inheritance element present in its
2 profile.
3
4
5 Frame Element Element Multiple BSSID Element Element Element
Duration ...
6 Control (ID=A) (ID=B) element (ID=71) (ID=C) (ID=E) (ID=F)

BSSID set on reporting Link

7

Info of AP(s) in multiple

8
9
Element MaxBSSID NonTxBSSID
10 ID (=71)
Length
Indicator Profile N
11
12
13
14
15 Nontransmitted
SSID Multiple Element Element Element Basic variant Non‐Inheritance
BSSID Capability BSSID‐Index
16 (ID=83) (ID=0) (ID=85) (ID=D) (ID=F) (ID=Y) Multi‐Link [ID = A]
17
18
19
20 Multi‐Link

Info of AP(s) on other Link(s)

21 Element
Length
Element ID
Control
Common Per‐STA
22 ID (=255) Extension Info field Profile x
(Type = 0)
23
24
25 Subelement
Length Data
26 ID (=0)
27
28
29
STA Control Element Element Non‐Inheritance
30 field
STA Info
(ID=B) (ID=Y) [ID = E]
31
32 STA Profile
33
34 Figure 35-21—Example of inheritance in a complete per-STA profile for a multiple BSSID
35 scenario(#6700)
36
37 35.3.21 TDLS procedure in multi-link operation(#4032)
38
39
40 35.3.21.1 General
41
42 (#4031)When the frames that are exchanged during TDLS discovery or setup do not include a TDLS Multi-
43 Link element or include a TDLS Multi-Link element containing only the Common Info field carrying only
44
45 the AP MLD MAC Address, then the TDLS direct link discovery or setup respectively, is for a single link. A
46 TDLS STA affiliated with a non-AP MLD that has dot11EHTBaseLineFeaturesImplementedOnly equal to
47 true shall only negotiate TDLS over a single link.
48
49 A non-AP MLD that intends to establish a single link TDLS direct link with a peer STA on one of its links
50
51 follows the procedures defined in 11.20 (Tunneled direct-link setup), with additional rules as defined in
52 35.3.21.2 (TDLS direct link over a single link).
53
54 35.3.21.2 TDLS direct link over a single link
55
56
57 When a non-AP MLD that has performed multi-link setup with an AP MLD establishes a single link TDLS
58 direct link on one of its links, it shall set the context (i.e., security, SN/PN, BA) for the TDLS direct link with
59 respect to the MLD MAC address of the non-AP MLD. For ease of description in the rest of this subclause,
60 the single link TDLS context is described with respect to a TDLS STA affiliated with the non-AP MLD. The
61 TDLS STA affiliated with the non-AP MLD shall be able to receive frames sent over the direct link with RA
62
63 field set to the MLD MAC address of the non-AP MLD. When a TDLS STA affiliated with the non-AP
64
65

Copyright © 2022 IEEE. All rights reserved. 431

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 MLD initiates TDLS discovery or TDLS setup, it shall set the TA field of frames sent over the TDLS direct
2 link to the MLD MAC address of the non-AP MLD.
3
4
5 TDLS discovery and setup between a non-AP MLD and a peer STA involves frames that are sent and
6 received via an intermediate AP (MLD) or sent and received through direct communication (see Table 11-
7 13a (Frame type and their pathway in a TDLS setup(#4032))). Frames that traverse the intermediate AP
8 (MLD) are sent or received by a STA affiliated with a non-AP MLD. Frames sent over the direct link are
9
sent or received by a TDLS STA affiliated with the non-AP MLD. The TDLS direct link, when successfully
10
11 established, is between the TDLS STA affiliated with the non-AP MLD and a TDLS peer STA at the other
12 end of the direct link.
13
14 If the TDLS initiator is a non-AP MLD, then the TDLS initiator STA Address field contained in the Link
15
Identifier element of the TDLS frames shall be set to the MLD MAC address of the non-AP MLD.
16
17
18 When a non-AP MLD initiates a TDLS discovery operation, it may need to transmit more than one TDLS
19 Discovery Request frame with the BSSID field of the Link Identifier element set to a different BSSID in
20 each attempt. In each instance, the attempted BSSID corresponds to a different AP affiliated with the AP
21
MLD. Since the TDLS Discovery Response frame is received over the direct link, the initiating non-AP
22
23 MLD shall be able to determine the link(s) on which the peer STA or non-AP MLD is operating on.
24
25 (#4031)When attempting to establish a TDLS direct link over a single link, a TDLS STA affiliated with a
26 non-AP MLD shall include a TDLS Multi-Link element containing only the Common Info field carrying
27
only the AP MLD MAC Address field (see 9.4.2.312.5 (TDLS Multi-Link element(#4031))) in the TDLS
28
29 Discovery Request frame and TDLS Discovery Response frame that it transmits. A TDLS STA affiliated
30 with a non-AP MLD shall not respond to a TDLS Discovery Request frame if the frame carries TDLS Multi-
31 Link element and the MLD MAC address carried in the AP MLD MAC Address field of the TDLS Multi-
32 Link element does not match the MLD MAC address of the AP MLD with which the non-AP MLD has
33
performed multi-link setup.
34
35 NOTE 1—Due to the nature of multi-link operation, when a Data frame traverses an AP MLD, it can be relayed on any
36 available link. Furthermore, when a frame that was transmitted by a STA of a non-AP MLD traverses an AP MLD, the
37 AP MLD sets the SA field to the transmitting STA’s non-AP MLD MAC address. Therefore, when an affiliated STA of a
38 non-AP MLD receives a frame from its corresponding associated AP that is affiliated with an AP MLD, it cannot
39 determine the link where the frame originated from and it cannot determine if the initiating STA is affiliated with a non-
40 AP MLD or not. Consequently, the non-AP MLD initiating a TDLS discovery does not know the BSSID of the link
41 where the intended peer STA is operating on.
42
43
After TDLS peer is successfully discovered, the non-AP MLD shall set the BSSID field contained in the
44
45 Link Identifier element of the subsequent TDLS frames to the BSSID of the corresponding AP affiliated
46 with the AP MLD that is operating on the link on which the TDLS direct link is established or being
47 established.
48
49
(#4031)When attempting to establish a TDLS direct link over a single link, a TDLS STA affiliated with a
50
51 non-AP MLD shall include the TDLS Multi-Link element containing only the Common Info field carrying
52 only the AP MLD MAC Address field (see 9.4.2.312.5 (TDLS Multi-Link element(#4031))) in the TDLS
53 Setup Request frame. A TDLS STA affiliated with a non-AP MLD shall not respond to a TDLS Setup
54 Request frame if the frame carries TDLS Multi-Link element and the MLD MAC address carried in the AP
55
MLD MAC Address field of the TDLS Multi-Link element does not match the MLD MAC address of the
56
57 AP MLD with which the non-AP MLD has performed multi-link setup. A TDLS STA affiliated with a non-
58 AP MLD shall include the TDLS Multi-Link element in the TDLS Setup Response frame if the soliciting
59 TDLS Setup Request frame included TDLS Multi-Link element. A TDLS STA affiliated with a non-AP
60 MLD shall not respond to a TDLS Setup Response frame if the frame carries TDLS Multi-Link element and
61
the MLD MAC address carried in the AP MLD MAC Address field of the TDLS Multi-Link element does
62
63 not match the MLD MAC address of the AP MLD with which the non-AP MLD has performed multi-link
64
65

432 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 setup. A TDLS STA affiliated with a non-AP MLD shall include the TDLS Multi-Link element in the TDLS
2 Setup Confirm frame if the preceding TDLS Setup Response frame included TDLS Multi-Link element.
3
4
5 (#4031)When both STAs that are involved in a single link TDLS setup include a TDLS Multi-Link element
6 carrying the AP MLD MAC Address field in the frames exchanged during the TDLS setup phase, the TDLS
7 TPK generation shall include the AP MLD MAC address in addition to the MAC address of the affiliated
8 AP where the TDLS direct link is being established, as defined in Equation (12-2). When at least one of the
9
STAs that are involved in a single link TDLS setup, does not include TDLS Multi-Link element, in the
10
11 frames exchanged during TDLS setup phase, the STAs shall derive the TPK as defined in Equation (12-1).
12
13 After a TDLS direct link is successfully established between the TDLS STA affiliated with a non-AP MLD
14 and a TDLS peer STA at the other end of the TDLS direct link, STAs affiliated with the non-AP MLD shall
15
cease transmitting MSDUs to the TDLS peer, at the other end, through their associated AP that is affiliated
16
17 with the AP MLD to which the non-AP MLD has performed multi-link setup.
18 NOTE 2—The STAs affiliated with the non-AP MLD can transmit/receive frames to/from other STAs or the DS via the
19 AP MLD.
20
21
22 Figure 35-22 (Example A of TDLS discovery initiated by a non-AP MLD(#4032)) and Figure 35-23
23 (Example B of TDLS discovery initiated by a non-AP MLD(#4032)) illustrate the scenario where the TDLS
24 discovery is initiated by a non-AP MLD (MLD_S). MLD_S has performed multi-link setup with an AP
25 MLD (MLD_A). MLD_S has two affiliated STAs, STA1 and STA2. STA3 is not capable of performing
26
multi-link operation and is not affiliated with a non-AP MLD. MLD_A has two affiliated APs, AP1 and
27
28 AP2, where AP1 operates on link 1 and AP2 operates on link 2. STA1 and STA3 operate on link 1 and are
29 associated with AP1. STA2 operates on link 2 and is associated with AP2. In the example, MLD_S initiates
30 TDLS discovery by transmitting two TDLS Discovery Request frames (which are Data frames) as it does
31 not know which link STA3 is operating on and whether STA3 is an MLD or a STA not affiliated with an
32
MLD. The first TDLS Discovery Request frame (shown in Figure 35-22 (Example A of TDLS discovery
33
34 initiated by a non-AP MLD(#4032))) has the BSSID field in the Link Identifier element set to the BSSID of
35 AP1 and the second TDLS Discovery Request frame has this field set to the BSSID of AP2 (shown in
36 Figure 35-23 (Example B of TDLS discovery initiated by a non-AP MLD(#4032))). Both the frames have
37 their A3 (DA) set to the STA3 MAC address and the To DS subfield of the Frame Control field set to 1. The
38
TDLS Discovery Request frame can be transmitted over either link 1 (through STA1 as represented by solid
39
40 line) or link 2 (through STA2 as represented by dotted line). When the TDLS Discovery Request frame is
41 received at the AP MLD (i.e., through AP1 or AP2), it routes the frame to STA3, through AP1 by setting the
42 From DS subfield of the Frame Control field to 1 and A3 (SA) to the non-AP MLD Address (i.e., MLD_S).
43 STA3 discards the TDLS Discovery Request frame that had the BSSID field of Link Identifier element set to
44
BSSID of AP2 as it does not recognize the BSSID. STA3 recognizes the BSSID set to AP1 and responds
45
46 with a TDLS Discovery Response frame, which is a Management frame, with the RA set to the MLD_S and
47 both To DS and From DS subfields set to 0. (#4031)STA3 ignores the TDLS Multi-Link element as it does
48 not recognize this element. The TDLS STA affiliated with MLD_S receives the TDLS Discovery Response
49 frame, which is sent on the TDLS direct link (see Table 11-13a (Frame type and their pathway in a TDLS
50
setup(#4032))). The TDLS initiator STA Address field and the TDLS responder STA Address field
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 433

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 contained in the Link Identifier element (denoted as LI in the figure) are carried in the TDLS Discovery
2 Request frame and in the TDLS Discovery Response frame and are set to MLD_S and STA3, respectively.
3
4
5
6 Mgmt frame [ TDLS Disc Resp
7 { A1 (RA)=MLD_S, A2 (TA)=STA3,
8 A3 (BSSID)=AP1 },
9 {LI (MLD_S, STA3, AP1)} ]
10
Link 1 Data frame [ TDLS Disc Req
11 Data frame [ TDLS Disc Req AP1
12 STA1 { A1 (RA)=AP1, A2 (TA)=STA1, { A1 (RA)=STA3, A2 (TA)=AP1,
13 A3 (DA) = STA3 }, A3 (SA)=MLD_S } , STA3
{ LI (MLD_S, STA3, AP1) } ] { LI (MLD_S, STA3, AP1) } ]
14
15
STA3 processes the frame since the value
16 Link 2 Data frame [ TDLS Disc Req carried in the BSSID field of Link Identifier
17 { A1 (RA)=AP2, A2 (TA)=STA2, element matches AP1 and TDLS responder STA
18 STA2 A3 (DA) = STA3 }, AP2 Address field matches STA3's MAC address
19 { LI (MLD_S, STA3, AP1) } ]
20 MLD_S MLD_A
21
22 A)
23
24 Figure 35-22—Example A of TDLS discovery initiated by a non-AP MLD(#4032)
25
26
27
28
29
30
31
32
33
34 Link 1 Data frame [ TDLS Disc Req Data frame [ TDLS Disc Req
X
35 AP1
STA1 { A1 (RA)=AP1, A2 (TA)=STA1, { A1 (RA)=STA3, A2 (TA)=AP1,
36 A3 (DA) = STA3 }, A3 (SA)=MLD_S } , STA3
37 { LI (MLD_S, STA3, AP2) } ] { LI (MLD_S, STA3, AP2) } ]
38
39
40 Link 2 Data frame [ TDLS Disc Req STA3 discards the frame since the
41
{ A1 (RA)=AP2, A2 (TA)=STA2, value carried in the BSSID field of Link
42
A3 (DA) = STA3 }, AP2 Identifier element doesn’t match AP1
43 STA2
44 { LI (MLD_S, STA3, AP2) } ]
45 MLD_S MLD_A
46
47
48 B)
49
50 Figure 35-23—Example B of TDLS discovery initiated by a non-AP MLD(#4032)
51
52
53
54 The same considerations apply for setting the fields in the Link Identifier element when the TDLS discovery
55 is initiated by STA3 to establish a single link TDLS direct link with the non-AP MLD. In this scenario, since
56 STA3 is not affiliated with a non-AP MLD and is not aware of MLD, the BSSID field of the Link Identifier
57
58 element is set to the BSSID of AP1 (#4031)and the TDLS Discovery Request frame does not carry a TDLS
59 Multi-Link element.
60
61 Due to the nature of multi-link operation, it is possible that a Data frame sent by a STA is relayed on a
62 different link when it traverses the AP MLD. As a result, it is possible that the TDLS Discovery Request
63
64 frame (which is a Data frame) sent by STA3 is received on link 2. Figure 35-24 (Example of TDLS
65 discovery initiated by a STA to a non-AP MLD(#4032)) illustrates this case. The capabilities of each device

434 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 are the same as described in Figure 35-22 (Example A of TDLS discovery initiated by a non-AP
2 MLD(#4032)) and Figure 35-23 (Example B of TDLS discovery initiated by a non-AP MLD(#4032)).
3
4
5
Mgmt. frame [TDLS Disc Resp
6
{ A1 (RA)=STA3, A2 (TA)=MLD_S,
7
A3 (BSSID)=AP1 },
8 { LI (BSSID=AP1) } ]
9 Link 1
10
11
Data frame [ TDLS Disc/Setup Req AP1 Data frame [ TDLS Disc/Setup Req
STA1 { A1 (RA)=STA1, A2 (TA)=AP1, { A1 (RA)=AP1, A2 (TA)=STA3, STA3
12 A3 (SA)=STA3}, A3 (DA)=MLD_S },
13 { LI (BSSID=AP1) } ] { LI (BSSID=AP1) } ]
14
15 Link 2
16
Data frame [ TDLS Disc/Setup Req
17
{ A1 (RA)=STA2, A2 (TA)=AP2,
18
STA2 A3 (SA)=STA3},
19
{ LI (BSSID=AP1) } ]
AP2
20
21 MLD_S MLD_A
22
23 Figure 35-24—Example of TDLS discovery initiated by a STA to a non-AP MLD(#4032)
24
25
26
27 In Figure 35-24 (Example of TDLS discovery initiated by a STA to a non-AP MLD(#4032)), the TDLS
28 Discovery Request frame transmitted by STA3 has the To DS subfield of the Frame Control field set to 1 and
29 A3 (DA) set to non-AP MLD address (MLD_S) since STA3 is only aware of MLD_S and not the link
30
31 addresses of STA1 or STA2 as the AP MLD sets the SA to non-AP MLD’s MAC address. In this example,
32 when the TDLS Discovery Request frame (which is a Data frame) is received by AP1 and routed to the non-
33 AP MLD, the AP MLD sets the From DS subfield of the Frame Control field to 1 and the A3 (SA) to STA3
34 and transmits the frame either on link 2 (solid line) or link 1 (dotted line). The non-AP MLD receives the
35 TDLS Request Discovery frame and identifies the intended TDLS direct link using the BSSID field of the
36
37 Link Identifier element. In this case, the BSSID is set to AP1 (i.e., link 1), so the non-AP MLD enables the
38 TDLS STA affiliated with the non-AP MLD on link 1. The TDLS STA affiliated with the non-AP MLD
39 responds by transmitting a TDLS Discovery Response frame on the direct link to STA3 with the To DS and
40 From DS subfields of the Frame Control field set to 0, and A1 set to STA3 (i.e., RA = STA3, TA = MLD_S,
41 A3 = AP1). In both the TDLS Discovery Request and TDLS Discovery Response frames, the BSSID, the
42
43 TDLS initiator STA Address, and the TDLS responder STA Address fields in the Link Identifier element
44 (represented as LI in the figure) are set to AP1, STA3, and MLD_S, respectively.
45
46 Figure 35-25 (Transmission of TDLS Setup Request frame between two STAs each affiliated with a
47 different non-AP MLD(#4032)) and Figure 35-26 (Transmission of TDLS Setup Response frame between
48
49 two STAs each affiliated with a different non-AP MLD(#4032)) illustrate the case where a single link TDLS
50 direct link is set up between two non-AP MLDs that have performed multi-link setup with the same AP
51 MLD. The example assumes that the two non-AP MLDs have performed TDLS discovery and that the
52 initiating non-AP MLD (in this example, MLD_S) has decided to perform single link TDLS setup for link 1.
53 As shown in the figures, the TDLS Setup Request frame is transmitted by the non-AP MLD, MLD_S,
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 435

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 through affiliated STA1 to MLD_R through affiliated STA3. The BSSID field in the Link Identifier element
2 identifies the intended link for establishing the TDLS direct link.
3
4
5 MLD_S MLD_A MLD_R
6
7
8 Data frame Data frame
9 [ TDLS Setup Req [ TDLS Setup Req
10 AP1 { A1 (RA)=STA3, A2 (TA)=AP1,
STA1 { A1 (RA)=AP1, A2 (TA)=STA1,
STA3
11 A3 (DA)=MLD_R }, A3 (SA) = MLD_S },
12 { LI (BSSID=AP1) } ] { LI (BSSID=AP1) } ]
13
14
15 Data frame Data frame
16 [ TDLS Setup Req [ TDLS Setup Req
17 STA2 { A1 (RA)=AP2, A2 (TA)=STA2, AP2 { A1 (RA)=STA4, A2 (TA)=AP2,
18 A3 (DA)=MLD_R }, A3 (SA) = MLD_S }, STA4
19 { LI (BSSID=AP1) } ] { LI (BSSID=AP1) } ]
20
21 TDLS Setup Request
22
23 Figure 35-25—Transmission of TDLS Setup Request frame between two STAs each affili-
24 ated with a different non-AP MLD(#4032)
25
26
27
28
29
30 MLD_S MLD_A MLD_R
31
32
33 Data frame Data frame
34 [ TDLS Setup Resp [ TDLS Setup Resp
35 AP1 { A1 (RA)=AP1, A2 (TA)=STA3,
STA1 { A1 (RA)=STA1, A2 (TA)=AP1,
STA3
36 A3 (SA)=MLD_R }, A3 (SA) = MLD_S },
{ LI (BSSID=AP1) } ] { LI (BSSID=AP1) } ]
37
38
39
40 Data frame Data frame
41 [ TDLS Setup Resp [ TDLS Setup Resp
42 STA2 { A1 (RA)=STA2, A2 (TA)=AP2, AP2 { A1 (RA)=AP2, A2 (TA)=STA4,
A3 (DA)=MLD_R }, A3 (SA) = MLD_S }, STA4
43 { LI (BSSID=AP1) } ]
{ LI (BSSID=AP1) } ]
44
45
46 TDLS Setup Response
47
48 Figure 35-26—Transmission of TDLS Setup Response frame between two STAs each affili-
49 ated with a different non-AP MLD(#4032)
50
51
52 Figure 35-27 (TDLS direct link involving a STA affiliated with a non-AP MLD and a STA that is not
53 affiliated with a non-AP MLD(#4032)) and Figure 35-28 (TDLS direct link involving STAs affiliated with
54 different non-AP MLDs(#4032)) provide examples of a single link TDLS direct link where at least one of
55 the peer STAs is a TDLS STA affiliated with a non-AP MLD. The TA field of Data frames transmitted by
56
57
58
59
60
61
62
63
64
65

436 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 the TDLS STA that is affiliated with an MLD over the direct link is set to its non-AP MLD’s MAC address.
2 The To DS and From DS subfields of the Frame Control field of the Data frame are set to 0.
3
4
5 MLD_S MLD_A
6
7 Data frame
8 { A1 (RA)=MLD_S,
9 A2 (TA)=STA3, A3
10 (BSSID)=AP1 }
AP1
11 STA1 Data frame
12 { A1 (RA)=STA3,
13 A2 (TA)=MLD_S,
14 A3 (BSSID)=AP1 }
15
16
17 AP2
18
STA2
19
20 Figure 35-27—TDLS direct link involving a STA affiliated with a non-AP MLD and a STA that
21 is not affiliated with a non-AP MLD(#4032)
22
23
24
25
26
27 MLD_S MLD_A MLD_R
28
29
30 Data frame
31 { A1 (RA)=MLD_S,
32 A2 (TA)=MLD_R,
33 A3 (BSSID)=AP1 } AP1
STA1 STA3
34 Data frame
35 {A1 (RA)=MLD_R,
36 A2 (TA)=MLD_S,
37 A3 (BSSID)=AP1}
38
39
40 STA2 AP2 STA4
41
42
43 Figure 35-28—TDLS direct link involving STAs affiliated with different non-AP MLDs(#4032)
44
45
46
47 35.3.22 Multi-link SCS procedure(#1977)
48
49 (#5890)The SCS procedure is used by a non-AP EHT STA to request an EHT AP to classify incoming
50 individually addressed MSDUs based on parameters provided by the non-AP STA and/or describe its traffic
51
52 characteristics to an EHT AP.
53
54 An EHT STA establishes SCS stream with an EHT AP, as defined in 11.25.2 (SCS procedures), subject to
55 the additional rules and restrictions defined in this subclause.
56
57
58 (#5890)A non-AP EHT STA with dot11SCSActivated equal to true that supports transmission of SCS
59 Request frames containing SCS Descriptor element with a (#4918)QoS Characteristics element shall set the
60 SCS Traffic Description Support subfield value in the EHT Capabilities element that it transmits to 1. An
61 EHT AP with dot11SCSActivated equal to true that supports transmission of SCS Response frames
62 containing SCS Description element with a (#4918)QoS Characteristics element shall set the SCS Traffic
63
64 Descriptor Support subfield value in the EHT Capabilities element that it transmits to 1. All STAs affiliated
65

Copyright © 2022 IEEE. All rights reserved. 437

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 with an MLD shall set the SCS Traffic Description Support subfield of the EHT Capabilities element that
2 they transmit to the same value.
3
4
5 A non-AP EHT STA may transmit an SCS Request frame with SCS Descriptor element(s) containing a
6 (#4918)QoS Characteristics element (#5890)if the Request Type field in the frame set to “Add” or
7 “Change”. The (#4918)QoS Characteristics element describes the traffic characteristics of the requested
8 SCS stream. A non-AP EHT STA shall not transmit an SCS Request frame with SCS Descriptor element(s)
9
containing a (#4918)QoS Characteristics element to an AP from which it has not received an EHT
10
11 Capabilities element with the SCS Traffic Description Support field equal to 1.
12
13 The MLDs maintain SCSIDs at MLD level, i.e., the SCSID used by a STA affiliated with a non-AP MLD in
14 an SCS Request frame transmitted to an AP affiliated with an AP MLD is unique across (#5890)all STAs
15
affiliated with the non-AP MLD.
16
17
18 All STAs affiliated with an MLD shall set the SCS field of the Extended Capabilities element that they
19 transmit to the same value. The SCSID is used by a non-AP MLD to request creation, modification, or
20 deletion of an SCS stream. The SCSID is used by an AP MLD to identify an SCS stream in SCS responses.
21
22
23 An SCS Request frame sent by a non-AP STA affiliated with a non-AP MLD to the AP of an AP MLD that
24 contains a (#4918)QoS Characteristics element in which the Direction subfield is set to uplink or
25 downlink(#4918) or one that does not contain a QoS Characteristics element(#5890) is interpreted as a
26 request for creation of an SCS stream that applies at the MLD level.
27
28
29 If the SCS Descriptor element contains a (#4918)QoS Characteristics element in which the Direction
30 subfield is equal to downlink(#4918), then the TCLAS Elements field shall be included in the SCS
31 Descriptor element and the TCLAS Processing Element field may be included in the SCS Descriptor
32 element. The TCLAS Elements and the TCLAS Processing Element fields, if present, describes the traffic
33
classification the non-AP STA requests the AP to apply to the corresponding stream.
34
35
36 An SCS Descriptor element contained in an SCS Request frame in which the QoS Characteristics
37 subelement is present and the Direction subfield in the (#4918)QoS Characteristics element is equal to direct
38 link or uplink shall not contain the TCLAS Elements and the TCLAS Processing Element fields.
39
40
41 A value of REQUEST_DECLINED, REQUEST_TCLAS_NOT_SUPPORTED_BY_AP,
42 REJECTED_WITH_SUGGESTED_CHANGES, or
43 INSUFFICIENT_TCLAS_PROCESSING_RESOURCES shall be set in the corresponding SCS Status field
44 of the SCS status duple in the SCS Response frame when an EHT AP denies the SCS request for the
45
requested SCSID.
46
47
48 (#5890)If the SCS Request frame with an SCS Description element containing a QoS Characteristics
49 element is rejected by an EHT AP by setting the Status field value to
50 REJECTED_WITH_SUGGESTED_CHANGES, the AP shall include an SCS Descriptor element
51
containing a (#4918)QoS Characteristics element in the SCS Response frame signaling the suggested
52
53 (#5890)QoS characteristics parameters for this SCS stream. (#5890)An AP shall include an SCS Descriptor
54 element containing a QoS Characteristics element in an SCS Response frame with the Status field value set
55 to SUCCESS or REJECTED_WITH_SUGGESTED_CHANGES only if the SCS Descriptor element in the
56 corresponding SCS Request frame contained a QoS Characteristics element.
57
58
59 (#5890)The SCS Descriptor element that is included in an SCS Response frame shall not contain any Intra-
60 Access Category Priority element, TCLAS Elements field or TCLAS Processing Element field. The Request
61 Type field value in the corresponding SCS Descriptor element is reserved. The following fields in the QoS
62 Characteristics element included in the corresponding SCS Descriptor element in the SCS Response frame
63
may differ from the corresponding values in the requested SCS stream: Minimum Service Interval,
64
65 Maximum Service Interval, Service Start Time, and Medium Time.

438 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#4918)A non-AP EHT STA with dot11EHTTXOPSharingTFOptionImplemented equal to true may send an
2 SCS request that contains a QoS Characteristics element whose Direction field is set to 2 (Direct Link) only
3
if the EHT AP sets the Triggered TXOP Sharing Mode 2 Support subfield in the EHT Capabilities element it
4
5 transmits to 1.
6
7 (#4918)The QoS Characteristics element is a reference for the EHT AP’s scheduling. An EHT AP should
8 schedule for transmission downlink frames such that the delay bound and minimum data rate requested are
9
met for the downlink Data frames if the Direction subfield of the QoS Characteristics element indicates
10
11 downlink. An EHT AP should enable the transmission of uplink frames from the EHT STA with an interval
12 that falls between the requested minimum and maximum service intervals and the AP should meet the
13 minimum data rate requested if the Direction subfield of the QoS Characteristics element indicates uplink.
14 An EHT AP should enable the transmission of direct link frames from the EHT STA to another STA on the
15
link specified in the LinkID subfield of the Control Info field with an interval that falls between the
16
17 requested minimum and maximum service intervals.
18
19 (#4918)The transmission of uplink Data frames should be enabled by using Basic Trigger frames or
20 alternatively by using MU-RTS TXS Trigger frames if both EHT STAs have
21
dot11EHTTXOPSharingTFOptionImplemented equal to true. The transmission of direct link frames should
22
23 be enabled by using MU-RTS TXS Trigger frames if both EHT STAs have set the Triggered TXOP Sharing
24 Mode 2 Support field in their transmitted EHT Capabilities elements to 1.
25
26 (#4918)If the EHT STA is a TWT scheduled STA or TWT requesting STA (see 26.8 (TWT operation)) and
27
there are negotiated TWT SPs for the TID specified in the QoS Characteristics element with the EHT AP,
28
29 the EHT AP should ensure that the selected interval aligns with negotiated TWT wake intervals.
30
31 (#4918)If the EHT STA is an r-TWT scheduled STA (see 35.9 (Restricted TWT (r-TWT))) and the
32 negotiated r-TWT SPs for the TID specified in the QoS Characteristics element are trigger-enabled r-TWTs,
33
the EHT AP should ensure that the trigger frames are scheduled at the start of the TWT SPs.
34
35
36 (#4918)The EHT AP may discard a downlink data frame if the lifetime of the frame has exceeded the value
37 specified by the MSDU Lifetime field.
38
39 (#4918)NOTE—A QoS Characteristics element provided by a non-AP EHT STA is used by a receiving EHT AP to
40 facilitate the creation of a schedule for contention based channel access (EDCA) or MU operation. How the AP uses the
41 information provided by the non-AP STA QoS Characteristics element that do not have corresponding normative
42 requirements is beyond the scope of the standard.
43
44 If the requested SCS is accepted by an EHT AP and the SCS Descriptor element either did not contain a
45 (#4918)QoS Characteristics element or contained a (#5890)QoS Characteristics element in which the
46
Direction subfield is equal to downlink(#4918), the AP shall process subsequent incoming individually
47
48 addressed MSDUs from the DS or WM that match the TCLAS Elements field and optional TCLAS
49 Processing Element field specified in the SCS Descriptor element as described in 11.25.2 (SCS procedures).
50
51 An SCS Response frame transmitted by an EHT AP that contains a value of “Terminate” in the Status field
52
of an SCS status duple shall not contain a (#4918)QoS Characteristics element.
53
54
55 35.3.23 Multi-link MSCS procedure(#4812)
56
57 The MSCS procedures, including setting up, updating of parameters and termination of an MSCS,
58
classification of MSDUs addressed to a non-AP EHT STA, and setting the UP of those MSDUs, defined in
59
60 11.25.3 (MSCS procedures) is performed at the MLD level and apply to all the STAs affiliated with the
61 MLD.
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 439

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 An MLD that implements MSCS procedure shall have each STA affiliated with that MLD set
2 dot11MSCSActivated to true, and shall indicate its capability by having each STA affiliated with that MLD
3
set the Mirrored SCS field of the Extended Capabilities elements that the STA transmits to 1.
4
5
6 All STAs affiliated with an MLD shall indicate the same support for MSCS procedure.
7
8 35.3.24 Proxy ARP service in AP MLDs(#6715)
9
10
11 Implementation of the proxy ARP service is optional for an AP MLD. When supported, an AP MLD
12 implements the proxy ARP service, as defined in 11.21.14 (Proxy ARP service), at the MLD level.
13
14 All APs affiliated with an AP MLD shall have the same setting of the Proxy ARP field in the Extended
15
Capabilities element. If an AP MLD supports Proxy ARP service, then all affiliated APs of the AP MLD
16
17 shall set the Proxy ARP field to 1 in their Extended Capabilities elements.
18 NOTE—For an associated STA that is not affiliated with an MLD, the Proxy ARP service is provided by the AP
19 affiliated with the AP MLD, with which the STA is associated, as defined in 11.21.14 (Proxy ARP service).
20
21
22 An example of the proxy ARP service provided by the AP MLD is shown in Figure 35-29 (Example of
23 proxy ARP service by an AP MLD(#6715)).
24
25 DS Ethernet
26 Channel 1
27 MLD1‐IPv4’s MAC Address?
28 Ethernet Channel 2
STA6 AP MLD
I/F
29 MLD1‐IPv4’s MAC Address = ARP Request / Neighbor
30 MLD1‐M AP1 AP2 Solicitation Message
31 ARP Response / Neighbor
32 Advertisement Message
33
34
35
36
37
38 STA5
STA3 STA4
39 STA5‐M STA1‐M STA1 STA2 STA2‐M
40 STA5‐IPv4 Non‐AP MLD2
41 Non‐AP MLD1
42
43 MLD1‐M
44 MLD1‐IPv4, MLD1‐IPv6
45
46 Figure 35-29—Example of proxy ARP service by an AP MLD(#6715)
47
48
49
50 In this example, the AP MLD has two affiliated APs: AP1 operates on channel 1 in the 5 GHz band an AP2
51 operates on channel 2 in the 6 GHz band. The AP MLD, AP1 and AP2, are connected to the DS, which is
52 connected to the LAN via a portal (e.g., via Ethernet interface(s)). Two non-AP MLDs, Non-AP MLD1 and
53 Non-AP MLD2, each with two affiliated STAs operating on channel 1 and channel 2, respectively, are
54
55 associated with the AP MLD. The MLD MAC address of Non-AP MLD1 is MLD1-M, while IPv4 address
56 MLD1-IPv4 and IPv6 address MLD1-IPv6 are assigned to Non-AP MLD1. STA5, which is a STA that is
57 not affiliated with a non-AP MLD, is associated with AP1. The MAC address of STA5 is STA5-M, while
58 IPv4 address STA5-IPv4 is assigned to STA5. STA6 is a device connected to the AP-MLD via the DS.
59 When the AP MLD receives from STA6, via the DS, an ARP request with the target IP address set as the
60
61 Non-AP MLD1’s IPv4 address, MLD1-IPv4, the proxy ARP service in AP MLD responds to STA6 with an
62 ARP response packet with the Sender’s MAC Address set as MLD1-M. When the AP MLD receives from
63 STA5, on channel 1, an ARP request with the target IP address set as MLD1-IPv4, the proxy ARP service in
64 AP MLD responds to STA5 with an ARP response packet with the Sender’s MAC Address set as MLD1-M.
65

440 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 When the AP MLD receives from Non-AP MLD2, on channel 2, a Neighbor Solicitation message with the
2 target IP address set as the Non-AP MLD1’s IPv6 address, MLD1-IPv6, the proxy ARP service in AP MLD
3
responds to Non-AP MLD2 with a Neighbor Advertisement message with the target link layer address set as
4
5 MLD1-M. It is not shown in the figure, but when an ARP request is received by AP1 from STA3 affiliated
6 with Non-AP MLD2, on channel 1, with the target IP address set as STA5’s IPv4 address, STA5-IPv4, the
7 proxy ARP service in AP1 responds to STA3 with an ARP response packet with the Sender’s MAC Address
8 set as STA5-M. However, if the ARP request with the target IP address set as STA5’s IPv4 address is
9
received by AP2 from STA4 affiliated with Non-AP MLD2, on channel 2, the ARP request is forwarded to
10
11 AP1 (e.g., via the DS) and the proxy ARP service in AP1 responds to STA4 (e.g., via the DS and AP2) with
12 an ARP response packet with the Sender’s MAC Address set as STA5-M.
13
14 35.3.25 BSS transition management for MLDs(#5322)
15
16
17 A STA affiliated with an MLD has dot11BSSTransitionActivated equal to true, following procedure defined
18 in 11.21.7.1 (BSS transition capability).
19
20 A STA affiliated with an MLD shall follow the procedure define in 11.21.7 (BSS transition management for
21
network load balancing), except that:
22
23 — the procedure is applied between the SMEs of an AP MLD and a non-AP MLD and not between the
24 SMEs of an AP and a STA.
25
26 — if the Neighbor Report element of an AP includes a Basic Multi-link element in the BSS Transition
27 Candidate List Entries field of a BSS Transition Management Query/Request or Response frame, it
28 describes the preference for a target AP MLD candidate and not for a target BSS candidate,
29 otherwise it describes the preference for a target BSS candidate.
30
31 — The Preference field value of a Neighbor Report element that includes a Multi-link element
32 describing an AP MLD provides the indication of preference for the given AP MLD, within the
33 given list at the given time.
34
35 — If an AP MLD intends to provide preference for a reported AP MLD without recommendation on
36 specific affiliated APs, it shall:
37 • include a Neighbor Report element for one of the APs affiliated with the AP MLD, and include a
38
39 Basic Multi-link element in the Neighbor Report.
40 • set to 0 all subfields of the Presence Bitmap field.
41 • not include any Per-STA Profile subelement in the Basic Multi-link element.
42
— If an AP MLD intends to provide preference for a reported AP MLD with only a subset of
43
44 recommended affiliated APs, it shall:
45 • include a Neighbor Report element for one of the recommended APs affiliated with the AP
46 MLD, and include a Basic Multi-link element in the Neighbor Report element.
47
48 • include a Link ID Info field in the Common Info field of the Basic Multi-link element with the
49 field value set to that corresponding to the AP reported in the Neighbor Report element.
50 • set to 0 all subfields of the Presence Bitmap field except the Link ID Info Present subfield.
51 • include a Per-STA Profile subfield only for each of the other recommended affiliated APs (if
52 any), and with all the fields set to 0 in the STA Control field, except the Link ID field. If multiple
53
54 Neighbor Report elements are used to report the same AP MLD with the same recommended
55 subset of affiliated APs, the Preference field value in these elements shall be the same. If multi-
56 ple Neighbor Report elements are used to report the same AP MLD with different recommended
57 subset of affiliated APs, the Preference field value in these elements may be different.
58
59 — When an AP affiliated with an AP MLD transmits a BSS Transition Management Request frame
60 with the Disassociation Imminent field set to 1 to a non-AP MLD, the Disassociation Timer field in
61 the BSS Transition Management Request frame shall be set to 0 or set to the number of TBTTs that
62 will occur prior to the AP MLD disassociating the non-AP MLD.
63
64
65

Copyright © 2022 IEEE. All rights reserved. 441

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — When an AP affiliated with an AP MLD transmits a BSS Transition Management Request frame
2 with the BSS Termination Included field set to 1 to a non-AP MLD, the BSS termination means that
3
the AP MLD is shutting down, and the non-AP MLD will be disassociated from the AP MLD.
4
5 NOTE—An AP MLD can use this protocol to recommend a non-AP MLD to do MLD (re)association with the same AP
6 MLD with a different set of links.
7
8
9 35.4 EHT acknowledgment procedure(#4111)(#5167)
10
11
12 35.4.1 Overview
13
14 The EHT acknowledgment procedure builds on the features defined for HT-immediate block ack (see
15 10.25.6 (HT-immediate block ack extensions)) and HE acknowledgement (see 26.4 (HE acknowledgment
16 procedure)), with the following extensions:
17
18 — Support for BlockAck Bitmap field lengths of 512 and 1024
19
20 An EHT AP shall not transmit a Multi-STA BlockAck frame that contains a BlockAck Bitmap field with
21
length equal to 512 or 1024 bits as a response to an HE TB PPDU generated by at least one HE STA(#5146),
22
23 except that an EHT AP may transmit a Multi-STA BlockAck frame that contains a BlockAck Bitmap field
24 with length equal to 512 or 1024 in an individually addressed RU.
25
26 35.4.2 Block ack bitmap lengths
27
28
29 Both the Compressed BlockAck frame and Multi-STA BlockAck frame allow different Block Ack Bitmap
30 subfield lengths. The length of the Block Ack Bitmap subfield is indicated in the Fragment Number subfield
31 of the Block Ack Starting Sequence Control field as defined in 9.3.1.8 (BlockAck frame format). The
32 allowed Block Ack Bitmap lengths for each of the negotiated buffer sizes are defined in Table 35-1
33
(Negotiated buffer size and Block Ack Bitmap subfield length).
34
35
36
37 Table 35-1—Negotiated buffer size and Block Ack Bitmap subfield length
38
39
40 Block Ack Bitmap subfield Block Ack Bitmap subfield
41 Negotiated buffer size length (bits) in a Compressed length (bits) in a Multi-STA
42 BlockAck frame BlockAck frame
43
44 1–64 64 32 or 64
45 65–128 64 or 256 32, 64, or 128
46
47 129–256 64 or 256 32, 64, 128, or 256
48
257–512 64, 256, or 512 32, 64, 128, 256, or 512
49
50 513–1024 64, 256, 512, or 1024 32, 64, 128, 256, 512, or 1024
51
52 NOTE—A 32-bit Block Ack Bitmap subfield length is not allowed unless the originator has set the
53 32-bit BA Bitmap Support field in the HE MAC Capabilities Information field in the HE Capabilities
54 element to 1.
55
56
57
58
59
60
61
62
63
64
65

442 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 35.5 MU operation
2
3
4 35.5.1 EHT DL MU operation(#1087)
5
6 35.5.1.1 General(#1087)
7
8 When transmitting or receiving an EHT MU PPDU, the rules defined in 26.5.1.1 (General), 26.5.1.2 (RU
9
10 addressing in an HE MU PPDU), and 26.5.1.3a (Minimum RU allocation in an HE MU PPDU(#1087)) that
11 apply to an HE MU PPDU shall also apply to an EHT MU PPDU. In cases where a rule in 26.5.1.1
12 (General), 26.5.1.2 (RU addressing in an HE MU PPDU) or 26.5.1.3a (Minimum RU allocation in an HE
13 MU PPDU(#1087)) refers to RUs in an HE MU PPDU, the rule (#7911)also applies to RUs and MRUs in an
14 EHT MU PPDU.
15
16
17 An EHT AP shall not transmit an EHT MU PPDU with an RU that is narrower than the PPDU bandwidth
18 and that is allocated to more than one STA (DL MU-MIMO) unless the AP has received from each STA an
19 EHT Capabilities element with the Partial Bandwidth DL MU-MIMO subfield in the EHT PHY Capabilities
20 Information field equal to 1.
21
22
23 35.5.1.2 RU allocation in an EHT MU PPDU(#1306)
24
25 (#1087)An EHT STA shall not transmit a 320 MHz EHT MU PPDU in the 6 GHz band with a 2996+484-
26 tone, 3996-tone, 3996+484-tone or 4996-tone RU or MRU allocated to the other EHT STA, unless the
27
28 EHT STA has received an EHT Capabilities element with the Support For 320 MHz In 6 GHz subfield in
29 the EHT PHY Capabilities Information field equals to 1 from the other EHT STA and the other EHT STA is
30 in 320 MHz operating bandwidth.
31
32 (#1087)A non-AP EHT STA with dot11EHTSupportFor242ToneRUInBWWiderThan20Implemented
33
34 equals to false shall set the Support For 242-tone RU In BW Wider Than 20 MHz subfield in the EHT PHY
35 Capabilities Information field in the EHT Capabilities element to 0.
36
37 (#1087)An AP shall not transmit a 40 MHz, 80 MHz, 160 MHz or 320 MHz EHT MU PPDU with a 242-
38 tone RU allocated to a 20 MHz operating non-AP EHT STA, unless the AP has received from the 20 MHz
39
40 operating non-AP EHT STA an EHT Capabilities element with the Support For 242-tone RU in BW Wider
41 Than 20 MHz subfield in the EHT Capabilities Information field equals to 1.
42
43 (#1087)(#4653)In a 40 MHz, 80 MHz, 160 MHz or 320 MHz EHT MU PPDU, an AP shall not allocate to a
44 20 MHz operating non-AP STA an RU or MRU that is not supported by the STA as indicated in 36.3.2.6
45
46 (RU and MRU restrictions for 20 MHz operation(#3276)). An AP shall follow the rules in 36.3.2.5 (20 MHz
47 operating non-AP EHT STAs(#1244)(#1254)), 36.3.2.7 (80 MHz operating non-AP EHT
48 STAs(#1244)(#1254)), and 36.3.2.8 (160 MHz operating non-AP EHT STAs(#1244)(#1254)) if allocating
49 RUs or MRUs to an non-AP EHT STA whose operating bandwidth is smaller than the BSS operating
50 channel width.
51
52
53 (#4649)(#6796)An EHT AP does not allocate an RU or MRU in the secondary 160 MHz channel of a
54 320 MHz EHT MU PPDU or EHT TB PPDU to an 80 MHz operating non-AP EHT STA. An EHT AP shall
55 not allocate an RU or MRU in the secondary 80 MHz channel of a 160 MHz or 320 MHz EHT MU or EHT
56 TB PPDU to an 80 MHz operating non-AP EHT STA, if the 80 MHz operating non-AP EHT STA has not
57
58 set up SST operation on the secondary 80 MHz channel with the EHT AP or there is an inactive 20 MHz
59 subchannel within the secondary 80 MHz channel.
60
61 (#4650)An EHT AP (#7172)with dot11EHTBaseLineFeaturesImplementedOnly equal to true shall not
62 allocate an RU or MRU on the secondary 160 MHz in a 320 MHz EHT MU PPDU or EHT TB PPDU to a
63
64 160 MHz operating non-AP EHT STA.
65

Copyright © 2022 IEEE. All rights reserved. 443

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 35.5.2 EHT UL MU operation(#1088)

2
3
35.5.2.1 General
4
5
6 EHT UL MU operation allows an AP to solicit simultaneous immediate response frames from one or more
7 non-AP EHT STAs. EHT UL MU operation expands the UL MU functionalities inherited from HE with the
8 additional capability of responding with EHT TB PPDUs, with bandwidths up to 320 MHz.
9
10
11 (#1088)An EHT STA that is a mesh STA shall not transmit or receive EHT TB PPDUs.
12
13 (#1088)An EHT STA with dot11EHTPartialBWULMUMIMOImplemented equal to true shall set the
14 Partial Bandwidth UL MU-MIMO subfield in the EHT PHY Capabilities Information field in the EHT
15
Capabilities element it transmits to 1. An EHT STA with dot11EHTPartialBWULMUMIMOImplemented
16
17 equal to false shall set the Partial Bandwidth UL MU-MIMO subfield in the EHT PHY Capabilities
18 Information field in the EHT Capabilities element it transmits to 0.
19
20 (#1088)An EHT AP shall not transmit a triggering frame in the 6 GHz band which allocates an RU/MRU
21
that occupies the secondary 160 MHz channel to a non-AP EHT STA, unless the AP has received from the
22
23 non-AP EHT STA an EHT Capabilities element with the Support For 320 MHz In 6 GHz subfield in the
24 EHT PHY Capabilities Information field equal to 1 and the non-AP EHT STA is in 320 MHz operating
25 bandwidth.
26
27
(#1088)A non-AP EHT STA with dot11HEDeviceClass equal to ClassA shall meet the Class A
28
29 requirements specified in 36.3.16 (Transmit requirements for PPDUs sent in response to a triggering frame)
30 when transmitting an EHT TB, non-HT or non-HT Duplicate PPDU in response to a triggering frame. A
31 non-AP EHT STA with dot11HEDeviceClass equal to ClassB shall meet the Class B requirements specified
32 in 36.3.16 (Transmit requirements for PPDUs sent in response to a triggering frame) when transmitting an
33
EHT TB, non-HT or non-HT Duplicate PPDU in response to a triggering frame.
34
35 (#1088)NOTE—A non-AP EHT STA uses the Device Class subfield in the HE PHY Capabilities Information field in
36 the HE Capabilities element it transmits to indicates its device class based on dot11HEDeviceClass. See
37 26.5.2.1 (General).
38
39
An EHT AP shall not set the UL EHT-MCS subfield of an EHT variant User Info field to 15 in a transmitted
40
41 Trigger frame if the RU assigned by that User Info field is used for UL MU MIMO transmission.
42
43 An EHT AP shall not set the UL EHT-MCS subfield of an EHT variant User Info field to 14 in a transmitted
44 Trigger frame.
45
46
35.5.2.2 Rules for soliciting UL MU frames
47
48
49 35.5.2.2.1 General(#1088)
50
51 An EHT STA shall follow the rules defined in 26.5.2.2.1 (General), where
52
53 — Rules related to HE STAs also apply to EHT STAs.
54 — Rules related to triggering frames also apply to triggering frames soliciting EHT TB PPDUs.
55
56 — Rules related to HE MU and HE TB PPDUs also apply to EHT MU and EHT TB PPDUs,
57 respectively.
58
59 (#7828)An EHT AP with dot11EHTBaseLineFeaturesImplementedOnly equal to true shall not transmit an
60
61 HE PPDU that carries a Trigger frame soliciting an EHT TB PPDU.
62
63 (#7828)An EHT AP with dot11EHTBaseLineFeaturesImplementedOnly equal to true shall not transmit an
64 EHT PPDU that carries a Trigger frame soliciting an HE TB PPDU.
65

444 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 An EHT AP shall not transmit a Trigger frame soliciting an OFDMA EHT TB PPDU that uses UL MU-
2 MIMO within an RU/MRU to a non-AP EHT STA from which the AP has not received an EHT Capabilities
3
element with the Partial Bandwidth UL MU-MIMO subfield of the EHT PHY Capabilities Information field
4
5 equal to 1.
6
7 (#4653)In a 40 MHz, 80 MHz, 160 MHz, or 320 MHz EHT TB PPDU, an AP shall not allocate to a 20 MHz
8 operating non-AP STA an RU/MRU that is not supported by the STA as indicated in 36.3.2.6 (RU and MRU
9
restrictions for 20 MHz operation(#3276)). An AP shall follow the rules defined in 36.3.2.5 (20 MHz
10
11 operating non-AP EHT STAs(#1244)(#1254)), 36.3.2.7 (80 MHz operating non-AP EHT
12 STAs(#1244)(#1254)), and 36.3.2.8 (160 MHz operating non-AP EHT STAs(#1244)(#1254)) when
13 assigning an RU/MRU to a non-AP EHT STA whose operating bandwidth is smaller than the BSS operating
14 channel width.
15
16
17 35.5.2.2.2 Requirements for allocating resources(#1088)
18
19 An EHT AP shall follow the requirements for allocating resources specified in 26.5.2.2.2 (Requirements for
20 allocating resources) where rules related to HE STAs also apply to EHT STAs, and rules related to HE TB
21
PPDUs also apply to EHT TB PPDUs, except that the negotiation of block ack bitmap lengths is additionally
22
23 defined in 35.4.2 (Block ack bitmap lengths).
24
25 35.5.2.2.3 Padding for a triggering frame(#1088)
26
27
An EHT AP shall ensure that there is sufficient padding in a triggering frame as specified in
28
29 26.5.2.2.3 (Padding for a triggering frame) if the triggering frame is neither an initial Control frame of a
30 frame exchange sequence with a non-AP MLD operating in the EMLSR mode, nor an initial frame of a
31 frame exchange sequence with a non-AP MLD operating in the EMLMR mode.
32
33
When an EHT AP of an AP MLD transmits an initial Control frame to initiate a frame exchange with a non-
34
35 AP MLD operating in the EMLSR mode, the AP shall ensure that the number of bits in the PSDU following
36 the last bit of User Info field addressed to the non-AP MLD is at least L PAD MAC defined in Equation (35-1).
37
38
39 L PAD MAC = N DBPS m PAD (35-1)
40
41 where
42
43  0 if EMLSR_DELAY is 0
44 m PAD =  EMLSR_DELAY + 2
45 2  Otherwise
46
47 EMLSR_DELAY is the value of the EMLSR Delay subfield in the EML Capabilities subfield in the
48 Multi-Link element.
49 N DBPS is defined in Table 17-4 (Modulation-dependent parameters).
50
51 NOTE—The initial Control frame of a frame exchange sequence to initiate a frame exchange with a non-AP MLD
52 operating in the EMLSR mode is sent using the non-HT or non-HT duplicate PPDU.
53
54
When an EHT AP of AP MLD transmits a triggering frame using non-HT or non-HT duplicate PPDU as an
55
56 initial frame to initiate a frame exchange with a non-AP MLD operating in EMLMR mode, the AP shall
57 ensure that the number of bits in the PSDU following the last bit of User Info field addressed to the non-AP
58 MLD is at least L PAD MAC defined in Equation (35-1)
59
60
61 where
62
63  0 if EMLMR_DELAY is 0
m PAD =  EMLMR_DELAY + 2
64 2  Otherwise
65

Copyright © 2022 IEEE. All rights reserved. 445

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 EMLMR_DELAY is the value of the EMLMR Delay subfield in the EML Capabilities subfield in the
2
3 Multi-Link element.
4 N DBPS is defined in Table 17-4 (Modulation-dependent parameters).
5
6 NOTE—The initial frame of a frame exchange sequence to initiate a frame exchange with a non-AP MLD operating in
7 EMLMR mode can be sent using the non-HT PPDU, non-HT duplicate PPDU, HT PPDU, VHT PPDU, HE PPDU, or
8 EHT PPDU. However, for HT PPDU, VHT PPDU, HE PPDU, or EHT PPDU, there are other methods to do the padding
9 for the initial frame, so the above padding method only applies to the case where the initial frame is sent using non-HT
10 or non-HT duplicate PPDU.
11
12 35.5.2.2.4 Allowed settings of the Trigger frame fields and TRS Control subfield
13
14
15 (#1088)An EHT AP may transmit a Trigger frame that solicits an EHT TB PPDU from an EHT STA subject
16 to the rules defined in 26.5.2.2 (Rules for soliciting UL MU frames) and the additional rules defined below.
17
18 (#6998)An EHT AP that includes the Special User Info field in a Trigger frame shall set all bits of the
19 Disregard In U-SIG-1 subfield and the four LSBs of the Disregard In U-SIG-2 subfield to 1, if
20
21 dot11EHTBaseLineFeaturesImplementedOnly is equal to true. The MSB of the Disregard In U-SIG-2
22 subfield is implementation specific and should be set to 0 if dot11EHTBaseLineFeaturesImplementedOnly
23 is equal to true.
24
25 (#7912)An EHT AP with dot11EHTBaseLineFeaturesImplementedOnly equal to true shall not transmit a
26
27 Trigger frame that solicits both an HE TB PPDU and an EHT TB PPDU. (#5201)The EHT AP shall not
28 transmit a Trigger frame that contains a User Info field whose AID12 subfield is equal to 0 or 2045 unless
29 both B54 and B55 in the Common Info field of the Trigger frame are equal to 1.
30
31 The AID12 subfield of the Special User Info field shall be set to 2007. An EHT AP that includes the Special
32
33 User Info field in a Trigger frame shall set Special User Info Field Flag(#4327) subfield to 0 and the Special
34 User Info field shall be placed immediately after the Common Info field. An EHT AP shall set the value of
35 B54 in the Common Info field of a Trigger frame to 1 if there exists any HE variant User Info field in the
36 Trigger frame. Otherwise, the EHT AP shall set the value of B54 in the Common Info field of the Trigger
37 frame to 0.
38
39
40 (#6743)A non-AP EHT STA that transmits a TB PPDU shall satisfy the conditions defined in 26.5.2.3 (Non-
41 AP STA behavior for UL MU operation).
42
43 (#7913)NOTE 1—An EHT AP does not assign an AID value of 2007 to any STA (see 35.16 (EHT BSS operation)).
44
45 An EHT AP shall set the UL Length subfield of a transmitted Trigger frame that solicits an EHT TB PPDU
46 to the value given by Equation (27-11) with m = 2 .
47
48 NOTE 2—This is the same rule as that of an AP that transmits a Trigger frame that solicits an HE TB PPDU (see
49 26.5.2.2.4 (Allowed settings of the Trigger frame fields and TRS Control field))(#1088).
50
51
35.5.2.2.5 AP access procedures for UL MU operation(#1088)
52
53
54 An EHT AP shall follow the AP access procedures for UL MU operation as specified in 26.5.2.2.5 (AP
55 access procedures for UL MU operation).
56
57
35.5.2.3 Non-AP STA behavior for UL MU operation
58
59
60 35.5.2.3.1 General(#1088)
61
62 A non-AP EHT STA that transmits a TB PPDU shall satisfy the conditions defined in 26.5.2.3.1 (General),
63 26.5.2.3.2 (Conditions for not responding with an HE TB PPDU), 26.5.2.3.5 (RA field for frames carried in
64
65 an HE TB PPDU), and 26.5.2.4 (A-MPDU contents in an HE TB PPDU) where rules related to HE TB

446 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 PPDUs also apply to EHT TB PPDUs. A User Info field that is addressed to a non-AP STA is either an HE
2 variant or EHT variant. The User Info field is an HE variant addressed to a non-AP STA if the B39 of the
3
User Info field is set to 0 and the B54 of Common Info field is set to 1 in the Trigger frame; otherwise, it is
4
5 an EHT variant.
6
7 If a non-AP EHT STA receives an EHT variant User Info field in a Trigger frame that is not MU-RTS
8 Trigger frame in which the AID12 subfield matches its AID, then (#7914)the STA shall respond with an
9
EHT TB PPDU. (#6514)If a non-AP EHT STA receives an HE variant User Info field in a Trigger frame that
10
11 is not MU-RTS Trigger frame in which the AID12 subfield matches its AID, then (#7914)the STA shall
12 respond with an HE TB PPDU.
13
14 (#7896)An EHT STA shall not transmit an EHT TB PPDU if the B55 of the Common Info field is set to 1.
15
16 (#6514)NOTE—A non-AP EHT STA is an HE STA, so the non-AP EHT STA might contend for an RA-RU and
17 transmit an HE TB PPDU, if the STA receives an HE variant User Info field that allocates RA-RU(s) in a Trigger frame
18 (see 26.5.4 (UL OFDMA-based random access (UORA))).
19
20 A non-AP EHT STA shall not send an EHT TB PPDU unless it is explicitly triggered by an AP (#4199)in
21
the operation modes described in 35.5.2.3.2 (TXVECTOR parameters for EHT TB PPDU response to
22
23 Trigger frame).
24
25 (#4200)An EHT AP shall not trigger a non-AP EHT STA to send an HE TB PPDU that covers the secondary
26 160 MHz.
27
28
29 A non-AP EHT STA shall not send an HE TB PPDU on the secondary 160 MHz.
30
31 35.5.2.3.2 TXVECTOR parameters for EHT TB PPDU response to Trigger frame
32
33
A non-AP EHT STA that responds to a Trigger frame that solicits an HE TB PPDU sets the TXVECTOR
34
35 parameters as defined in 26.5.2.3.3 (TXVECTOR parameters for HE TB PPDU response to Trigger frame).
36
37 A non-AP EHT STA that responds to a Trigger frame that solicits an EHT TB PPDU shall set the
38 TXVECTOR parameters below as follows:
39
40 — The FORMAT parameter is set to EHT_TB.
41 — The L_LENGTH parameter is set to the value indicated by the UL Length subfield in the Common
42
Info field of the Trigger frame.
43
44 — The NUM_STS parameter is set to the number of (#6079)spatial streams indicated by the Number Of
45 Spatial Streams subfield of the SS Allocation field of the EHT variant User Info field.
46
47 — The STARTING_STS_NUM parameter is set to the value of the Starting Spatial Stream subfield in
48 the SS Allocation field in the EHT variant User Info field of the Trigger frame.
49 — (#7915)The SPATIAL_REUSE_1 and SPATIAL_REUSE_2 parameters are set to the values of the
50
51 respective Spatial Reuse subfields in the Special User Info field of the eliciting Trigger frame.
52 — The CH_BANDWIDTH parameter is set to the value of the bandwidth of the EHT TB PPDU, and is
53 obtained from the combined value of the UL BW subfield in the Common Info field and (#7916)the
54
UL Bandwidth Extension subfield in the Special User Info field (see Table 9-53d (Mapping from
55
56 Special User Info field to U-SIG-1 and U-SIG-2 fields in the EHT TB PPDU(#4607))).
57 — (#4201)The RU_ALLOCATION parameter is set to the value indicated by the RU Allocation
58 subfield (#7915)and the PS160 subfield of the User Info subfield of the Trigger frame.
59
60 — (#5471)The TB_DISREGARD_IN_USIG1, TB_VALIDATE_IN_USIG2, and
61 TB_DISREGARD_IN_USIG2 parameters to the value of the Disregard In U-SIG-1, Validate in U-
62 SIG-2, and Disregard In U-SIG-2 subfields, respectively, in the U-SIG Disregard And Validate
63
subfield in the Special User Info field.
64
65

Copyright © 2022 IEEE. All rights reserved. 447

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 All other TXVECTOR parameters that are present are set as defined in 26.5.2.3.3 (TXVECTOR parameters
2 for HE TB PPDU response to Trigger frame).
3
4 NOTE—The DCM parameter is not present in an EHT variant User Info field.
5
6 35.5.2.3.3 Conditions for not responding with a TB PPDU(#4839)
7
8
9 If a non-AP EHT STA is solicited to send a TB PPDU by a Trigger frame and the combination of the B54
10 and B55 in the Common Info field, the B39 in the User Info field addressed to it(#7917) in the Trigger frame
11 does not match any of the combinations of the values specified in the rows in Table 9-50a (Valid
12 combinations of B54 and B55 in the Common Info field, B39 in the User Info field, and solicited TB PPDU
13
format), then the STA shall not respond with a TB PPDU to the Trigger frame. If B39 is equal to 1(#5558),
14
15 then the non-AP EHT STA shall not respond with an HE or EHT TB PPDU unless the bandwidth for the
16 solicited EHT TB PPDU is specified as 320 MHz in the Trigger frame.
17
18 35.5.2.4 UL MU CS mechanism for EHT STAs
19
20
21 An EHT STA shall follow the rules defined in 26.5.2.5 (UL MU CS mechanism), except that the EHT STA
22 shall use the rules defined in 36.3.20.6.4 (Per 20 MHz CCA sensitivity) instead of those defined in
23 27.3.20.6.5 (Per 20 MHz CCA sensitivity) when CCA is performed on any nonpunctured 20 MHz
24 subchannel in an EHT BSS.
25
26
27 Specifically, if the CS Required subfield in a Trigger frame is 1, then the non-AP STA shall consider the
28 status of the CCA (using energy detect defined in 36.3.20.6.4 (Per 20 MHz CCA sensitivity) and the virtual
29 carrier sense (NAV)) during the SIFS between the PPDU that contains the Trigger frame and the PPDU sent
30 in response to the Trigger frame. In this case, the non-AP STA shall sense the medium using energy detect
31
after receiving the PPDU that contains the Trigger frame (i.e., during the SIFS), and it shall perform the
32
33 energy detect at least in the subchannel that contains the non-AP STA’s UL allocation, where the sensed
34 subchannel consists of one or more occupied 20 MHz channels. The non-AP STA may transmit the solicited
35 PPDU if all the occupied 20 MHz channels containing the RUs allocated in the Trigger frame are considered
36 idle. If the non-AP STA detects that any of the occupied 20 MHz channels containing the allocated RUs is
37
not idle, then the non-AP STA shall not transmit.
38
39
40
41
35.6 A-MPDU operation in an EHT PPDU(#4295)
42
43 35.6.1 General
44
45 A-MPDU operation for an EHT PPDU follows the procedures defined in 10.12 (A-MPDU operation) and
46
47 the additional rules in this subclause.
48
49 An EHT STA that sends a Class 1 frame or a Class 2 frame in an EHT PPDU shall send the frame as an S-
50 MPDU (see Table 9-534 (A-MPDU contents in the S-MPDU context)).
51
52
53 An EHT STA shall not transmit an A-MPDU in an EHT PPDU to a STA that exceeds the maximum A-
54 MPDU length capability indicated in the EHT Capabilities element, HE Capabilities element, VHT
55 Capabilities element, and HT Capabilities element received from the recipient STA. If a VHT Capabilities
56 element is received from the recipient STA, then the maximum A-MPDU length capability is derived from
57 the Maximum A-MPDU Length Exponent Extension subfield in the HE Capabilities element and EHT
58
59 Capabilities element, and the Maximum A-MPDU Length Exponent subfield in the VHT Capabilities
60 element. Otherwise, the maximum A-MPDU length capability is derived from the Maximum A-MPDU
61 Length Exponent Extension subfield in the HE Capabilities element and EHT Capabilities element, and the
62 Maximum A-MPDU Length Exponent subfield in the HT Capabilities element or in the HE 6 GHz Band
63 Capabilities element.
64
65

448 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 An EHT STA that sends an EHT Capabilities element with Maximum A-MPDU Length Exponent
2 Extension subfield of 0 shall support in reception of an EHT PPDU with an A-MPDU pre-EOF padding with
3
maximum length as defined in 10.12.2 (A-MPDU length limit rules).
4
5
6 An EHT STA that sends a VHT Capabilities element, HE Capabilities element, and EHT Capabilities
7 element with Maximum A-MPDU Length Exponent Extension subfield greater than 0 shall support in
8 reception of an EHT PPDU with an A-MPDU pre-EOF padding with maximum length as defined in 10.12.2
9
(A-MPDU length limit rules), except that the maximum length for the A-MPDU pre-EOF padding shall be
10
 23 + Maximum A-MPDU Length Exponent Extension 
11 equal to min  2 – 1 15 523 200  . An EHT STA that sets the Maximum
12 A-MPDU Length Exponent Extension subfield in the EHT Capabilities element to a value greater than 0
13
14 shall set the Maximum A-MPDU Length Exponent subfield of the VHT Capabilities element to 7 and the
15 Maximum A-MPDU Length Exponent Extension subfield of the HE Capabilities element to 3.
16
NOTE—The value 15 523 200 is defined in Table 9-34 (Maximum data unit sizes (in octets) and durations (in
17
microseconds)) as the upper bound of PSDU size of EHT PPDU.
18
19
20 An EHT STA that sends an HE 6 GHz Band Capabilities element, an HE Capabilities element, and an EHT
21 Capabilities element with Maximum A-MPDU Length Exponent Extension subfield greater than 0 shall
22 support in reception of an EHT PPDU with an A-MPDU pre-EOF padding with maximum length as defined
23 in 10.12.2 (A-MPDU length limit rules), except that maximum length for the A-MPDU pre-EOF padding
24
 23 + Maximum A-MPDU Length Exponent Extension 
25 shall be equal to min  2 – 1 15 523 200  . An EHT STA that sets the
26 Maximum A-MPDU Length Exponent Extension subfield in the EHT Capabilities element to a value greater
27
28
than 0 shall set the Maximum A-MPDU Length Exponent subfield of the HE 6 GHz Band Capabilities
29 element to 7 and the Maximum A-MPDU Length Exponent Extension subfield of HE Capabilities element
30 to 3.
31
32
33 35.7 EHT sounding operation(#5853)(#8363)
34
35 35.7.1 General
36
37
38 Transmit beamforming and DL MU-MIMO require knowledge of the channel state to compute a steering
39 matrix that is applied to the transmit signal to optimize reception at one or more receivers. EHT STAs use
40 the EHT sounding protocol to determine the channel state information. The EHT sounding protocol provides
41 explicit feedback mechanisms, defined as EHT non-trigger-based (non-TB) sounding and EHT trigger-
42
43 based (TB) sounding, where the EHT beamformee measures the channel using a training signal (i.e., an EHT
44 sounding NDP) transmitted by the EHT beamformer and sends back a transformed estimate of the channel
45 state. The EHT beamformer uses this estimate to derive the steering matrix.
46
47 The EHT beamformee returns an estimate of the channel state in an EHT compressed beamforming/CQI
48
49 report carried in one or more EHT Compressed Beamforming/CQI frames. There are three types of EHT
50 compressed beamforming/CQI report:
51 — SU feedback: The EHT compressed beamforming/CQI report consists of an EHT Compressed
52
53
Beamforming Report field
54 — MU feedback: The EHT compressed beamforming/CQI report consists of an EHT Compressed
55 Beamforming Report field and EHT MU Exclusive Beamforming Report field
56
57 — CQI feedback: The EHT compressed beamforming/CQI report consists of an EHT CQI Report field
58 NOTE—Use of EHT TB sounding does not necessarily imply MU feedback. EHT TB sounding is also used to obtain
59 SU feedback and CQI feedback.
60
61
62 The EHT compressed beamforming/CQI report is carried in a single EHT Compressed Beamforming/CQI
63 frame if the resulting frame is less than or equal to 11454 octets in length (see 35.7.3 (Rules for EHT
64
65

Copyright © 2022 IEEE. All rights reserved. 449

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 sounding protocol sequences)). Otherwise, the EHT beamforming feedback is segmented and each segment
2 is carried in an EHT Compressed Beamforming/CQI frame.
3
4
5 An EHT beamformer shall support a maximum MPDU length for the EHT compressed beamforming/CQI
6 report that is the minimum of 11454 octets and the maximum length of the EHT compressed
7 beamforming/CQI report that the EHT beamformer intends to solicit from its EHT beamformees.
8
9
35.7.2 EHT sounding protocol
10
11
12 An SU beamformer is an EHT STA that sets the SU Beamformer subfield in the EHT PHY Capabilities
13 Information field in the EHT Capabilities element it transmits to 1.
14
15
An SU beamformee is an EHT STA that sets the SU Beamformee subfield in the EHT PHY Capabilities
16
17 Information field in the EHT Capabilities element it transmits to 1. A non-AP EHT STA shall set the SU
18 Beamformee subfield to 1. An EHT AP may set the SU Beamformee subfield to 1.
19
20 (#1120)An MU beamformer is an EHT AP that sets at least one of the following MU beamformer
21
subfields(#4488): MU Beamformer (BW ≤ 80 MHz), MU Beamformer (BW = 160 MHz), and MU
22
23 Beamformer (BW = 320 MHz) to 1 in the EHT PHY Capabilities Information field in the EHT Capabilities
24 element it transmits. A non-AP EHT STA shall set all three MU beamformer subfields, MU Beamformer
25 (BW ≤ 80 MHz), MU Beamformer (BW = 160 MHz), and MU Beamformer (BW = 320 MHz) subfields, to
26 0. An MU beamformer is also an SU beamformer and shall set the SU Beamformer subfield.
27
28 (#5559)NOTE 1—A non-AP STA might use the value of the MU Beamformer subfield in the EHT PHY Capabilities
29 Information field of the AP to determine the AP with which it will associate.
30
31 A non-AP EHT STA shall support operation as an MU beamformee. An EHT AP does not support operation
32
as an MU beamformee.
33
34
35 The term EHT beamformer refers to both the SU beamformer and MU beamformer. The term EHT
36 beamformee refers to both the SU beamformee and the MU beamformee.
37
38
39 The type of feedback (SU, MU, or CQI) solicited by an EHT beamformer from an EHT beamformee is
40 indicated in the Feedback Type And Ng and (#7674)Codebook Size subfields in the STA Info field
41 identifying the EHT beamformee in the EHT NDP Announcement frame as defined in Table 9-
42 29a (Feedback Type And Ng subfield and Codebook Size subfield encoding for HE TB sounding) and
43
Table 9-29b (Feedback Type And Ng subfield and Codebook Size subfield encoding for HE non-TB
44
45 sounding).
46
47 The bandwidth (partial or full) of the feedback solicited by an EHT beamformer from an EHT beamformee
48 depends on the Partial BW Info subfield in the STA Info field identifying the EHT beamformee in the EHT
49
NDP Announcement frame(#7919), the bandwidth of the EHT NDP Announcement frame, and the
50
51 operating bandwidth of the EHT beamformee. The bandwidth of the EHT NDP Announcement frame and
52 the EHT NDP frame shall be the same.
53
54 Full bandwidth SU, MU or CQI feedback refers to the feedback mode where the feedback RU/MRU size
55
indicated in the Partial BW Info subfield of the EHT NDP Announcement frame spans all the available
56
57 bandwidth within an EHT beamformee’s operating bandwidth. Partial bandwidth SU, MU or CQI feedback
58 refers to the feedback mode where the feedback RU/MRU size indicated in the Partial BW Info subfield of
59 the EHT NDP Announcement frame spans part of the available bandwidth within an EHT beamformee’s
60 operating bandwidth.
61
62 — If the EHT beamformee’s operating bandwidth is larger than or equal to the bandwidth of NDP
63 frame, the available bandwidth is the entire PPDU bandwidth of the NDP frame when puncture is not
64 applied and is the entire occupied PPDU bandwidth of the NDP frame when puncture is applied.
65

450 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — If the EHT beamformee’s operating bandwidth is smaller than the bandwidth of NDP frame, the
2 available bandwidth is the beamformee’s entire operating bandwidth when preamble puncturing is
3
not applied and is the entire occupied bandwidth within the beamformee’s operating bandwidth
4
5 when preamble puncturing is applied.
6 NOTE 2—For example, if a 160 MHz EHT NDP has a 20 MHz puncturing
7
8
9 • The available bandwidth is 140 MHz when the beamformee’s operating bandwidth is 160 MHz or
10 320 MHz.
11 • The available bandwidth is 80 MHz when the beamformee’s operating bandwidth is 80 MHz and 20 MHz
12 puncturing is not within the beamformee’s operating bandwidth.
13 • The available bandwidth is 60 MHz when the beamformee’s operating bandwidth is 80 MHz and 20 MHz
14 puncturing is within the beamformee’s operating bandwidth.
15
16
(#7920)An EHT beamformer shall set the Partial BW Info subfield in an EHT NDP Announcement frame to
17
18 a value that is listed in Table 9-42c (Settings for BW, Partial BW Info subfield in the EHT NDP
19 Announcement frame(#8157)).
20
21 An EHT NDP Announcement frame shall not request feedback on a 242-tone RU that is signaled as
22
punctured in the U-SIG field(#5657) of the NDP that follows the EHT NDP Announcement frame.
23
24
25 An EHT NDP Announcement frame shall not request partial BW feedback on a 242-tone RU outside of the
26 beamformee’s operating channel width.
27
28
An SU beamformer may solicit full bandwidth SU feedback from an SU beamformee in an EHT non-TB
29
30 sounding sequence. An SU beamformer shall not solicit partial bandwidth SU feedback from an SU
31 beamformee in an EHT non-TB sounding sequence. (#7793)In an EHT non-TB sounding sequence case, the
32 occupied subchannel(s) indicated by the BW and Puncturing Channel Information fields in the U-SIG field
33 of the NDP shall be the same as the requested subchannel(s) indicated in the Partial BW Info subfield of the
34
immediately preceding EHT NDP Announcement frame. Furthermore, the punctured subchannel(s)
35
36 indicated by the BW and Puncturing Channel Information fields in the U-SIG field of the NDP shall not
37 include other punctured subchannel(s) in addition to those indicated in the Disabled Subchannel Bitmap
38 field of the most recent EHT Operation element for non-TB sounding.
39
40 (#7793)NOTE 3—In the EHT TB sounding sequence, the punctured subchannel(s) indicated by the BW and Puncturing
41 Channel Information fields in the U-SIG field of the NDP might include other punctured subchannel(s) in addition to
42 those indicated in the Disabled Subchannel Bitmap field of the most recent EHT Operation element, following the rules
43 defined in 35.16.2 (Preamble puncturing operation(#1086)(#1667)(#2148)(#2147)).
44
45 An SU beamformer may solicit partial bandwidth or full bandwidth SU feedback from an SU beamformee in
46 an EHT TB sounding sequence if the SU beamformee indicates support by setting the Triggered SU
47
Beamforming Feedback subfield in the EHT PHY Capabilities Information field in the EHT Capabilities
48
49 element it transmits to 1.
50
51 An MU beamformer may solicit full bandwidth MU feedback from an MU beamformee in an EHT TB
52 sounding sequence. An MU beamformer may solicit partial bandwidth MU feedback from an MU
53
beamformee in an EHT TB sounding sequence if the MU beamformee indicates support by setting the
54
55 Triggered MU Beamforming Partial BW Feedback subfield in the EHT PHY Capabilities Information field
56 in the EHT Capabilities element it transmits to 1. An MU beamformer shall not solicit MU feedback in an
57 EHT non-TB sounding sequence.
58
59
An MU beamformer may solicit partial bandwidth or full bandwidth CQI feedback from an MU
60
61 beamformee in an EHT TB sounding sequence if the MU beamformee indicates support by setting the
62 Triggered CQI Beamforming Feedback subfield to 1.
63
64
65

Copyright © 2022 IEEE. All rights reserved. 451

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 An MU beamformer may solicit (#5561)full bandwidth CQI feedback from an MU beamformee in an EHT
2 non-TB sounding sequence if the MU beamformee indicates support by setting the Non-Triggered CQI
3
Beamforming Feedback subfield to 1.
4
5
6 An EHT beamformer shall not send an EHT NDP Announcement frame that initiates an EHT TB sounding
7 sequence with a STA Info field identifying an EHT beamformee if the STA Info field and the PHY
8 Capabilities Information field in the EHT Capabilities element most recently received from the EHT
9
beamformee meet any of the following conditions (see Table 9-29a (Feedback Type And Ng subfield and
10
11 Codebook Size subfield encoding for HE TB sounding)):
12 — The Feedback Type And Ng subfield(#7922) and Codebook Size subfield in the STA Info field
13 indicates SU and Ng = 16 , and the Ng = 16 SU Feedback subfield in the EHT PHY Capabilities
14
15 Information field is 0.
16 — The Feedback Type And Ng subfield(#7922) and Codebook Size subfield in the STA Info field
17 indicates MU and Ng = 16 , and the Ng = 16 MU Feedback subfield in the EHT PHY Capabilities
18
Information field is 0.
19
20 — The Feedback Type And Ng subfield(#7922) and Codebook Size subfield in the STA Info field
21 indicates SU, the Codebook Size subfield indicates codebook resolution     =  4 2  , and the
22 Codebook Size     =  4 2  SU Feedback subfield in the EHT PHY Capabilities Information
23
24 field is 0.
25 — The Feedback Type And Ng subfield(#7922) and Codebook Size subfield in the STA Info field
26 indicates MU, the Codebook Size subfield in the STA Info field indicates codebook resolution
27
    =  7 5  , and the Codebook Size     =  7 5  MU Feedback subfield in the EHT PHY
28
29 Capabilities Information field is 0.
30 — The Feedback Type And Ng subfield(#7922) and Codebook Size subfield in the STA Info field
31 indicates CQI and the Triggered CQI Beamforming Feedback subfield in the EHT PHY Capabilities
32
33 Information field is 0.
34 — The Feedback Type And Ng subfield(#7922) and Codebook Size subfield (#5803)in the STA Info
35 field indicate SU and the Triggered SU Beamforming Feedback subfield in the EHT PHY
36
Capabilities Information field is 0.
37
38
39 An EHT beamformee indicates the maximum number of spatial streams(#6838)(#8365) it can receive in a
40 20 MHz, 40 MHz, or 80 MHz EHT sounding NDP in the Beamformee SS (≤ 80 MHz)(#7924) subfield in
41 the EHT PHY Capabilities Information field in the EHT Capabilities element it transmits.
42
43
44 An EHT beamformee shall set the Beamformee SS (≤ 80 MHz)(#7924) subfield to indicate a maximum
45 number of spatial streams(#8366) of 4 or greater.
46
47 (#7923)An EHT beamformee shall set the Beamformee SS (= 160 MHz) subfield to indicate a maximum
48
number of spatial streams of 4 or greater.
49
50
51 (#7923)An EHT beamformee shall set the Beamformee SS (= 320 MHz) subfield to indicate a maximum
52 number of spatial streams of 4 or greater.
53
54
An EHT beamformee indicates the maximum number of spatial streams(#6839)(#8367) it can receive in a
55
56 160 MHz EHT sounding NDP in the Beamformee SS (= 160 MHz)(#7924) subfield in the EHT PHY
57 Capabilities Information field in the EHT Capabilities element it transmits.
58
59 An EHT beamformee indicates the maximum number of spatial streams(#6840)(#8368) it can receive in a
60
320 MHz EHT sounding NDP in the Beamformee SS (= 320 MHz)(#7924) subfield in the EHT PHY
61
62 Capabilities Information field in the EHT Capabilities element it transmits.
63
64
65

452 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 An EHT beamformer shall not transmit a 20 MHz, 40 MHz, or 80 MHz EHT sounding NDP with a
2 TXVECTOR parameter NUM_STS that is greater than the maximum number of spatial streams(#6841)
3
indicated in the Beamformee SS (≤ 80 MHz)(#7924) subfield of any STA identified by a STA Info field in
4
5 the preceding EHT NDP Announcement frame.
6
7 An EHT beamformer shall not transmit a 160 MHz EHT sounding NDP with a TXVECTOR parameter
8 NUM_STS that is greater than the maximum number of spatial streams(#6842) indicated in the Beamformee
9
SS( = 160 MHz)(#7924) subfield of any STA identified by a STA Info field in the preceding EHT NDP
10
11 Announcement frame.
12
13 An EHT beamformer shall not transmit a 320 MHz EHT sounding NDP with a TXVECTOR parameter
14 NUM_STS that is greater than the maximum number of spatial streams(#6843) indicated in the Beamformee
15
SS (= 320 MHz)(#7924) subfield of any STA identified by a STA Info field in the preceding EHT NDP
16
17 Announcement frame.
18
19 (#6850)(#6851)(#8364)An EHT beamformer shall not transmit an EHT sounding NDP with a TXVECTOR
20 parameter NUM_EHT_LTF that is greater than the maximum number of EHT-LTF symbols indicated in the
21
Maximum Number Of Supported EHT-LTFs subfield of any STA identified by a STA Info field in the
22
23 preceding EHT NDP Announcement frame.
24
25 An EHT beamformer indicates the maximum number of spatial streams(#6844) it might transmit in a
26 20 MHz, 40 MHz, or 80 MHz EHT sounding NDP in the Number Of Sounding Dimensions (≤ 80 MHz)
27
subfield.
28
29
30 An EHT beamformer indicates the maximum number of spatial streams(#6845) it might transmit in a
31 160 MHz EHT sounding NDP in the Number Of Sounding Dimensions (= 160 MHz) subfield.
32
33
An EHT beamformer indicates the maximum number of spatial streams(#6846) it might transmit in a
34
35 320 MHz EHT sounding NDP in the Number Of Sounding Dimensions (= 320 MHz) subfield.
36
37 An EHT beamformer shall not transmit a 20 MHz, 40 MHz, or 80 MHz EHT sounding NDP where the
38 number of spatial streams(#6847) exceeds the value indicated in the Number Of Sounding
39
Dimensions (≤ 80 MHz)(#7924) subfield.
40
41
42 An EHT beamformer shall not transmit a 160 MHz EHT sounding NDP where the number of spatial
43 streams(#6848) exceeds the value indicated in the Number Of Sounding Dimensions (= 160 MHz)(#7924)
44 subfield.
45
46
47 An EHT beamformer shall not transmit a 320 MHz EHT sounding NDP where the number of spatial
48 streams(#6849) exceeds the value indicated in the Number Of Sounding Dimensions (= 320 MHz)(#7924)
49 subfield.
50
51
An EHT beamformer may solicit partial BW feedback from one or more EHT beamformees with operating
52
53 channel width smaller than the bandwidth of the EHT NDP Announcement frame and sounding NDP.
54
55 (#5770)An EHT beamformee indicated the maximum supported data rate in the EHT TB PPDU carrying the
56 EHT compressed beamforming/CQI report in the TB Sounding Feedback Rate Limit subfield in the EHT
57
PHY Capabilities Information field in the EHT Capabilities element sent by the EHT beamformee.
58
59
60 (#5770)An EHT beamformer shall not solicit an EHT TB PPDU with a BFRP Trigger frame that indicates a
61 data rate greater than the data rate indicated by the EHT beamformee in the TB Sounding Feedback Rate
62 Limit subfield. The data rate indicated in the BFRP Trigger frame is computed based on the RU Allocation
63
subfield, PS160 subfield, UL EHT-MCS subfield, and SS Allocation/RA-RU Information subfield in the
64
65 EHT variant User Info field of the BFRP Trigger frame. The data rate is computed based on 1.6 µs GI.

Copyright © 2022 IEEE. All rights reserved. 453

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 A 320 MHz EHT beamformer shall not send a 320 MHz EHT NDP Announcement frame solicit partial BW
2 feedback from an EHT beamformee with 20 MHz operating channel width.
3
4
5 An EHT NDP Announcement frame of bandwidth larger than 40 MHz shall not include an EHT
6 beamformee with 40 MHz operating channel width.
7
8 In an EHT non-TB sounding sequence, a 20 MHz operating EHT beamformee shall support SU feedback for
9
242-tone RU solicited with an EHT NDP Announcement frame of bandwidth of 20 MHz.
10
11
12 In an EHT TB sounding sequence, a 20 MHz operating EHT beamformee may support SU feedback for
13 242-tone RU solicited with an EHT NDP Announcement frame of bandwidth of 20 MHz, 40 MHz, 80 MHz,
14 and 160 MHz.
15
16
17 A 20 MHz operating EHT beamformee shall support MU feedback for 242-tone RU solicited with an EHT
18 NDP Announcement frame of bandwidth of 20 MHz.
19
20 A 20 MHz operating EHT beamformee may support MU feedback for 242-tone RU solicited with an EHT
21
NDP Announcement frame of bandwidth of 40 MHz, 80 MHz, and 160 MHz.
22
23
24 In an EHT non-TB sounding sequence, a 40 MHz operating EHT beamformee shall support SU feedback for
25 the following combinations of RU size and NDP announcement bandwidth:
26
27 — 242-tone RU feedback solicited with an EHT NDP Announcement frame of bandwidth of 20 MHz.
28 — 484-tone RU feedback solicited with an EHT NDP Announcement frame of bandwidth of 40 MHz.
29
30
In an EHT TB sounding sequence, a 40 MHz operating EHT beamformee may support SU feedback for
31
32 242-tone and 484-tone RU solicited with an EHT NDP Announcement frame of bandwidth of 20 MHz and
33 40 MHz.
34
35 A 40 MHz operating EHT beamformee shall support MU feedback for the combinations of RU size and
36
NDP announcement bandwidth below:
37
38 — 242-tone RU feedback solicited with an EHT NDP Announcement frame of bandwidth of 20 MHz.
39
— 484-tone RU feedback solicited with an EHT NDP Announcement frame of bandwidth of 40 MHz.
40
41
42 A 40 MHz operating EHT beamformee may support MU feedback for 242-tone RU solicited with an EHT
43 NDP Announcement frame of bandwidth of 40 MHz.
44
45
In an EHT non-TB sounding sequence, an 80 MHz operating EHT beamformee shall support SU feedback
46
47 for the following combinations of RU/MRU size and NDP announcement bandwidth:
48 — 242-tone RU feedback solicited with an EHT NDP Announcement frame of bandwidth of 20 MHz.
49
50 — 484-tone RU feedback solicited with an EHT NDP Announcement frame of bandwidth of 40 MHz.
51 — 484+242-tone MRU feedback solicited with an EHT NDP Announcement frame of bandwidth of
52 80 MHz with 20 MHz puncturing.
53
54 — 996-tone RU feedback solicited with an EHT NDP Announcement frame of bandwidth of 80 MHz
55 without puncturing.
56
57
In an EHT TB sounding sequence, an 80 MHz operating EHT beamformee may support SU feedback for the
58
59 feedback RU/MRU size as shown in Table 9-42c (Settings for BW, Partial BW Info subfield in the EHT
60 NDP Announcement frame(#8157)) that are within its operating channel width and solicited with an EHT
61 NDP Announcement frame of bandwidth of 20 MHz, 40 MHz, 80 MHz, 160 MHz, and 320 MHz.
62
63
An 80 MHz operating EHT beamformee shall support MU feedback for the combinations of RU/MRU (if
64
65 the MRU is full bandwidth feedback) size and NDP announcement bandwidth below:

454 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — 242-tone RU feedback solicited with an EHT NDP Announcement frame of bandwidth of 20 MHz.
2
3 — 484-tone RU feedback solicited with an EHT NDP Announcement frame of bandwidth of 40 MHz.
4 — 996-tone RU and 484+242-tone MRU feedback solicited with an EHT NDP Announcement frame of
5 bandwidth of 80 MHz or 160 MHz.
6
7 — 996-tone RU feedback solicited with an EHT NDP Announcement frame of bandwidth of 320 MHz.
8
9 An 80 MHz operating EHT beamformee may support MU feedback for the combinations of RU/MRU (if
10 the MRU is partial bandwidth feedback) size and NDP announcement bandwidth below:
11
12 — 242-tone RU feedback solicited with an EHT NDP Announcement frame of bandwidth of 40 MHz.
13 — 242-tone and 484-tone RU, and 484+242-tone MRU feedback solicited with an EHT NDP
14
15 Announcement frame of bandwidth of 80 MHz or 160 MHz.
16 — 484-tone RU feedback solicited with an EHT NDP Announcement frame of bandwidth of 320 MHz.
17
18
In an EHT non-TB sounding sequence, a 160 MHz operating EHT beamformee shall support SU feedback
19
20 for the following combinations of RU/MRU size and NDP announcement bandwidth:
21 — 242-tone RU feedback solicited with an EHT NDP Announcement frame of bandwidth of 20 MHz.
22
23 — 484-tone RU feedback solicited with an EHT NDP Announcement frame of bandwidth of 40 MHz.
24 — 484+242-tone MRU solicited with an EHT NDP Announcement frame of bandwidth of 80 MHz
25 with 20 MHz puncturing.
26
27 — 996-tone RU feedback solicited with an EHT NDP Announcement frame of bandwidth of 80 MHz
28 — 996+484-tone MRU feedback solicited with an EHT NDP Announcement frame of bandwidth of
29
30 160 MHz with 40 MHz puncturing.
31 — 996+484+242-tone MRU feedback solicited with an EHT NDP Announcement frame of bandwidth
32 of 160 MHz with 20 MHz puncturing.
33
34 — 2996-tone RU feedback solicited with an EHT NDP Announcement frame of bandwidth of
35 160 MHz without puncturing.
36
37 In an EHT TB sounding sequence, a 160 MHz operating EHT beamformee may support SU feedback for the
38
39 feedback RU/MRU size as shown in Table 9-42c (Settings for BW, Partial BW Info subfield in the EHT
40 NDP Announcement frame(#8157)) that are within its operating channel width and solicited with an EHT
41 NDP Announcement frame of bandwidth of 20 MHz, 40 MHz, 80 MHz, 160 MHz, and 320 MHz.
42
43 A 160 MHz operating EHT beamformee shall support MU feedback for the combinations of RU/MRU (if
44
45 the MRUs are full bandwidth feedback) size and NDP announcement bandwidth below:
46 — 242-tone RU feedback solicited with an EHT NDP Announcement frame of bandwidth of 20 MHz.
47
48 — 484-tone RU feedback solicited with an EHT NDP Announcement frame of bandwidth of 40 MHz.
49 — 996-tone RU and 484+242-tone MRU feedback solicited with an EHT NDP Announcement frame of
50 bandwidth of 80 MHz.
51
52 — 2996-tone RU, 996+484-tone and 996+484+242-tone MRU feedback solicited with an EHT NDP
53 Announcement frame of bandwidth of 160 MHz.
54
— 2996-tone RU and 996+484-tone MRU feedback solicited with an EHT NDP Announcement frame
55
56 of bandwidth of 320 MHz.
57
58 A 160 MHz operating EHT beamformee may support MU feedback for the combinations of RU/MRU (if
59 the MRUs are full bandwidth feedback) size and NDP announcement bandwidth below:
60
61 — 242-tone RU feedback solicited with an EHT NDP Announcement frame of bandwidth of 40 MHz.
62 — 242-tone and 484-tone RU, and 484+242-tone MRU feedback solicited with an EHT NDP
63
Announcement frame of bandwidth of 80 MHz.
64
65

Copyright © 2022 IEEE. All rights reserved. 455

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — 242-tone, 484-tone, and 996-tone RU, and 484+242-tone and 996+484-tone MRU feedback solicited
2 with an EHT NDP Announcement frame of bandwidth of 160 MHz.
3
4 — 484-tone and 996-tone RU, and 996+484-tone MRU feedback solicited with an EHT NDP
5 Announcement frame of bandwidth of 320 MHz.
6
7 In an EHT non-TB sounding sequence, a 320 MHz operating EHT beamformee shall support SU feedback
8
9 for the following combinations of RU/MRU size and NDP announcement bandwidth:
10 — 242-tone RU feedback solicited with an EHT NDP Announcement frame of bandwidth of 20 MHz
11
12 — 484-tone RU feedback solicited with an EHT NDP Announcement frame of bandwidth of 40 MHz
13 — 484+242-tone MRU solicited with an EHT NDP Announcement frame of bandwidth of 80 MHz
14 with 20 MHz puncturing
15
16 — 996-tone RU feedback solicited with an EHT NDP announcement frame of bandwidth of 80 MHz
17 — 996+484-tone MRU feedback solicited with an EHT NDP Announcement frame of bandwidth of
18
160 MHz with 40 MHz puncturing.
19
20 — 996+484+242-tone MRU feedback solicited with an EHT NDP Announcement frame of bandwidth
21 of 160 MHz with 20 MHz puncturing.
22
23 — 2996-tone RU feedback solicited with an EHT NDP Announcement frame of bandwidth of
24 160 MHz.
25 — 2996+484-tone MRU feedback solicited with an EHT NDP Announcement frame of bandwidth of
26
27 320 MHz with 80+40 MHz puncturing.
28 — 3996-tone MRU feedback solicited with an EHT NDP Announcement frame of bandwidth of
29 320 MHz with 80 MHz puncturing.
30
31 — 3996+484-tone MRU feedback solicited with an EHT NDP Announcement frame of bandwidth of
32 320 MHz with 40 MHz puncturing.
33
— 4996-tone RU feedback solicited with an EHT NDP Announcement frame of bandwidth of
34
35 320 MHz without puncturing.
36
37 In an EHT TB sounding sequence, a 320 MHz operating EHT beamformee may support SU feedback for the
38 feedback RU/MRU size as shown in Table 9-42c (Settings for BW, Partial BW Info subfield in the EHT
39
NDP Announcement frame(#8157)) that are within its operating channel width and solicited with an EHT
40
41 NDP Announcement frame of bandwidth of 20 MHz, 40 MHz, 80 MHz, 160 MHz, and 320 MHz.
42
43 A 320 MHz operating EHT beamformee shall support MU feedback for the combinations of RU/MRU (if
44 the MRUs are full bandwidth feedback) size and NDP announcement bandwidth below:
45
46 — 242-tone RU feedback solicited with an EHT NDP Announcement frame of bandwidth of 20 MHz.
47 — 484-tone RU feedback solicited with an EHT NDP Announcement frame of bandwidth of 40 MHz.
48
49 — 996-tone RU and 484+242-tone MRU feedback solicited with an EHT NDP Announcement frame of
50 bandwidth of 80 MHz.
51
— 2996-tone RU, 996+484-tone and 996+484+242-tone MRU feedback solicited with an EHT NDP
52
53 Announcement frame of bandwidth of 160 MHz.
54 — 4996-tone RU and 2996+484-tone, 3996-tone, and 3996+484-tone MRU feedback solicited
55 with an EHT NDP Announcement frame of bandwidth of 320 MHz.
56
57
58 A 320 MHz operating EHT beamformee may support MU feedback for the combinations of RU/MRU (if
59 the MRUs are full bandwidth feedback) size and NDP announcement bandwidth below:
60
— 242-tone RU feedback solicited with an EHT NDP Announcement frame of bandwidth of 40 MHz.
61
62 — 242-tone and 484-tone RU, and 484+242-tone MRU feedback solicited with an EHT NDP
63 Announcement frame of bandwidth of 80 MHz.
64
65

456 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — 242-tone, 484-tone, and 996-tone RU, and 484+242-tone and 996+484-tone MRU feedback solicited
2 with an EHT NDP Announcement frame of bandwidth of 160 MHz.
3
4 — 484-tone, 996-tone, and 2996-tone RU, and 996+484-tone, 2996+484-tone, 3996-tone, and
5 3996+484-tone MRU feedback solicited with an EHT NDP Announcement frame of bandwidth of
6 320 MHz.
7
8
9 Table 35-2 (Informative summary of supported RU/MRU sizes for sounding feedback) summarizes the
10 supported sounding bandwidth for the various sounding modes and feedback types.
11
12
13 Table 35-2—Informative summary of supported RU/MRU sizes for sounding feedback
14
15
16 Operating Bandwidth of PPDU containing the EHT NDP Announcement frame (MHz)
17 channel
Sounding
18 width of the
feedback
19 EHT
modes 20 40 80 160 320
20 beamformee
21 (MHz)
22
23 20 Mandatory for
24 SU feedback
25 (non-TB
26 sounding)
27
Optional for
28
CQI feedback
29 242 N/A
(non-TB
30
sounding)
31
– NOTE 1
32
33 Mandatory for
34 MU feedback
35 (TB sounding)
36
37 Optional for
38 MU feedback
N/A 242 242 242 242
39 (TB sounding)
40 – NOTE 2
41
Optional for
42
SU feedback
43
(TB sounding)
44
– NOTE 3
45 242 242 242 242 242
46 Optional for
47 CQI feedback
48 (TB sounding)
49 – NOTE 4
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 457

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 35-2—Informative summary of supported RU/MRU sizes for sounding feedback (con-
2
3
4 Operating Bandwidth of PPDU containing the EHT NDP Announcement frame (MHz)
5 channel
Sounding
6 width of the
feedback
7 EHT
modes 20 40 80 160 320
8 beamformee
9 (MHz)
10
11 40 Mandatory for
12 SU feedback
13 (non-TB
14 sounding)
15 Optional for
16 CQI feedback
17 242 484 N/A
(non-TB
18 sounding)
19 – NOTE 1
20
21 Mandatory for
22 MU feedback
23 (TB sounding)
24
25 Optional for
26 MU feedback
N/A 242 N/A
27 (TB sounding)
28 – NOTE 2
29 Optional for
30 SU feedback
31 (TB sounding)
32 – NOTE 3
33 242,
242 N/A
34 Optional for 484
35 CQI feedback
36 (TB sounding)
37 – NOTE 4
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

458 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 35-2—Informative summary of supported RU/MRU sizes for sounding feedback (con-
2
3
4 Operating Bandwidth of PPDU containing the EHT NDP Announcement frame (MHz)
5 channel
Sounding
6 width of the
feedback
7 EHT
modes 20 40 80 160 320
8 beamformee
9 (MHz)
10
11 80 Mandatory for
12 SU feedback
13 (non-TB
14 sounding)
15 484+242 (F),
Optional for 242 484 N/A
16 996
CQI feedback
17 (non-TB
18 sounding)
19 – NOTE 1
20
21 Mandatory for
22 484+242 (F),
MU feedback 242 484 484+242 (F), 996 996
23 996
(TB sounding)
24
25 Optional for
26 MU feedback 242, 484, 242, 484,
N/A 242 484
27 (TB sounding) 484+242 (P) 484+242 (P)
28 – NOTE 2
29 Optional for
30 SU feedback
31 (TB sounding)
32 – NOTE 3 242, 484,
33 242, 242, 484,
242 484+242, 484, 996
34 Optional for 484 484+242, 996
996
35 CQI feedback
36 (TB sounding)
37 – NOTE 4
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 459

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 35-2—Informative summary of supported RU/MRU sizes for sounding feedback (con-
2
3
4 Operating Bandwidth of PPDU containing the EHT NDP Announcement frame (MHz)
5 channel
Sounding
6 width of the
feedback
7 EHT
modes 20 40 80 160 320
8 beamformee
9 (MHz)
10
11 160 Mandatory for
12 SU feedback
13 (non-TB
14 sounding) 996+484 (F),
15 484+242 (F),
Optional for 242 484 996+484+242 (F), N/A
996
16 CQI feedback 2996
17 (non-TB
18 sounding)
19 – NOTE 1
20
21 Mandatory for 996+484 (F),
22 484+242 (F), 996+484 (F),
MU feedback 242 484 996+484+242 (F),
996 2996
23 (TB sounding) 2996
24
25 Optional for
242, 484, 996,
26 MU feedback 242, 484, 484, 996,
N/A 242 484+242 (P),
27 (TB sounding) 484+242 (P) 996+484(P)
996+484 (P)
28 – NOTE 2
29 Optional for
30 SU feedback
31 (TB sounding) 242, 484, 996,
32 – NOTE 3 242, 484, 484+242,
33 242, 484, 996,
242 484+242, 996+484,
34 Optional for 484 996+484, 2996
996 996+484+242,
35 CQI feedback 2996
36 (TB sounding)
37 – NOTE 4
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

460 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 35-2—Informative summary of supported RU/MRU sizes for sounding feedback (con-
2
3
4 Operating Bandwidth of PPDU containing the EHT NDP Announcement frame (MHz)
5 channel
Sounding
6 width of the
feedback
7 EHT
modes 20 40 80 160 320
8 beamformee
9 (MHz)
10
11 320 Mandatory for
12 SU feedback
13 (non-TB
14 sounding) 2x996+484 (F),
996+484 (F),
15 484+242 (F), 3x996 (F),
242 484 996+484+242 (F),
Optional for 996 3996+484 (F),
16 2996
17
CQI feedback 4996
(non-TB
18 sounding)
19 – NOTE 1
20
21 2996+484 (F),
Mandatory for 996+484 (F),
22 484+242 (F), 3996 (F),
MU feedback 242 484 996+484+242 (F),
23 996 3996+484 (F),
(TB sounding) 2996
24 4996
25
26 484, 996,
Optional for
27 242, 484, 996, 996+484, 2996,
MU feedback 242, 484,
28 N/A 242 484+242 (P), 2996+484 (P),
(TB sounding) 484+242 (P)
29 996+484 (P) 3996+484 (P),
– NOTE 2
30 3996 (P)
31 Optional for
32 SU feedback
33 484, 996,
(TB sounding) 242, 484, 996,
34 996+484, 2996,
– NOTE 3 242, 484, 484+242,
35 242, 2996+484,
242 484+242, 996+484,
36 Optional for 484 3996,
996 996+484+242,
3996+484,
37 CQI feedback 2996
38 (TB sounding) 4996
39 – NOTE 4
40
41 NOTE 1—Supported if the Non-Triggered CQI Feedback subfield in the EHT PHY Capabilities Information field in
42 the EHT Capabilities element is set to 1.
43
44 NOTE 2—Supported if the Triggered MU Beamforming Partial bandwidth Feedback subfield in the EHT PHY
45 Capabilities Information field in the EHT Capabilities element is set to 1.
46
47 NOTE 3—Supported if the Triggered SU Beamforming Feedback subfield in the EHT PHY Capabilities Information
48 field in the EHT Capabilities element is set to 1.
49
50 NOTE 4—Supported if the Triggered CQI Feedback subfield in the EHT PHY Capabilities Information field in the
51 EHT Capabilities element is set to 1.
52
53
NOTE 5—“(F)” right after the MRU indicates MRU sizes where the feedback represents full bandwidth feedback.
54
“(P)” right after the MRU indicates MRU sizes where the feedback represents partial bandwidth feedback. If no
55
explicit indication is added, both (F) and (P) are implied where possible.
56
57
58 NOTE 6—Each value in the table only indicates the size of a feedback RU/MRU, not the location of the RU/MRU.
59 This includes all possible feedback RU/MRUs of the same size within the beamformee’s operating bandwidth.
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 461

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 35.7.3 Rules for EHT sounding protocol sequences

2
3
An EHT non-TB sounding sequence is initiated by an EHT beamformer with an individually addressed EHT
4
5 NDP Announcement frame comprising exactly one STA Info field, followed after SIFS by an EHT sounding
6 NDP. The EHT beamformee responds after SIFS with an EHT Compressed Beamforming/CQI
7 frame(#7073).
8
9
An example of an EHT non-TB sounding sequence with a single EHT beamformee is shown in Figure 35-30
10
11 (An illustration of EHT non-TB sounding).
12
13
14
15 EHT beamformer EHT NDP EHT sounding
16 Announcement SIFS NDP SIFS
17 EHT Compressed
18 EHT beamformee Beamforming/CQI
19
20
21 Figure 35-30—An illustration of EHT non-TB sounding
22
23
24
25 An EHT beamformer that initiates the EHT non-TB sounding sequence shall transmit the EHT NDP
26 Announcement frame with a single STA Info field, the STA Info field having a value in the AID11 field
27
28
other than 2047 and with the AID11 field in that STA Info field set to the AID of the STA identified by
29 (#5563)the RA field or to 0 if the STA identified by the RA field is an associated AP, mesh STA or IBSS
30 STA.
31
32 An EHT beamformer may initiate an EHT non-TB sounding sequence with an EHT beamformee to solicit
33
34
SU or CQI feedback.
35
36 (#1103)An EHT TB sounding sequence is initiated by an EHT beamformer with a broadcast EHT NDP
37 Announcement frame with two or more STA Info fields, followed after a SIFS by an EHT sounding NDP
38 followed after a SIFS by a BFRP Trigger frame. Each EHT beamformee responds after a SIFS with an EHT
39
40
TB PPDU containing one or more EHT Compressed Beamforming/CQI frames(#7079).
41
42 An example of an EHT TB sounding sequence with more than one EHT beamformee is shown in Figure 35-
43 31 (An illustration of EHT TB sounding(#7079)).
44
45 EHT beamformer
EHT NDP EHT sounding BFRP BFRP
46 Announcement SIFS NDP SIFS Trigger SIFS SIFS Trigger SIFS

47 EHT beamformee 1
EHT Compressed
Beamforming/CQI 1
48
EHT Compressed
49 EHT beamformee 2
Beamforming/CQI 2
50 : :
51 : :
:
:
52 EHT beamformee k EHT Compressed
53 Beamforming/CQI k
54
EHT Compressed
55 EHT beamformee k+1
Beamforming/CQI k+1
56 : :
57 : :
:
:
58 EHT Compressed
EHT beamformee n
59 Beamforming/CQI n
60
61 Figure 35-31—An illustration of EHT TB sounding(#7079)
62
63
64
65

462 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 An EHT beamformer that initiates an EHT TB sounding sequence shall transmit the EHT NDP
2 Announcement frame with two or more STA Info fields and the RA field set to the broadcast address.
3
4
5 (#4428)An EHT beamformer may initiate an EHT TB sounding sequence to solicit SU, MU, or CQI
6 feedback variant.
7
8 An EHT beamformer may initiate an EHT TB sounding sequence to solicit a feedback variant only if the
9
feedback variant is computed based on parameters supported by the EHT beamformee; otherwise the EHT
10
11 beamformer shall not solicit a feedback variant computed based on parameters not supported by the EHT
12 beamformee (see 35.7.2 (EHT sounding protocol)).
13
14 An EHT AP with dot11MultiBSSIDImplemented equal to true shall not send an EHT NDP Announcement
15
frame with the TA field set to the transmitted BSSID to a non-AP STA that is associated with an AP
16
17 corresponding to a nontransmitted BSSID in the multiple BSSID set unless the AP has received from the
18 non-AP STA an HE Capabilities element with the Rx Control Frame To MultiBSS subfield in the HE MAC
19 Capabilities Information field equal to 1.
20
21
An AP that transmits an EHT NDP Announcement frame identifying EHT STAs shall set the TA field of the
22
23 frame to the MAC address of the AP, unless dot11MultiBSSIDImplemented is true and the EHT NDP
24 Announcement frame identifies STAs from at least two different BSSs of the multiple BSSID set, in which
25 case, the AP shall set the TA field of the frame to the transmitted BSSID. If the EHT NDP Announcement
26 frame is transmitted in a non-HT duplicate PPDU then the TA field of the EHT NDP Announcement frame
27
is a bandwidth signaling TA (see 10.6.6.6 (Channel Width selection for Control frames)).
28
29
30 An EHT beamformer that transmits an EHT NDP Announcement frame to an EHT beamformee that is an
31 AP, TDLS peer STA, mesh STA, or IBSS STA, shall include one STA Info field in the EHT NDP
32 Announcement frame and shall set the AID11 field in the STA Info field of the frame to 0.
33
34
35 (#7078)When an EHT beamformer is an AP and EHT beamformees are non-AP STAs, the EHT beamformer
36 that transmits an EHT NDP Announcement frame to one or more EHT beamformees shall set the AID11
37 subfield to 11 LSBs of the AID of each EHT beamformee.
38
39
An EHT NDP Announcement frame shall not include multiple STA Info fields that have the same value in
40
41 the AID11 subfield.
42
43 In an EHT TB sounding sequence, a STA Info field in the EHT NDP Announcement frame that solicits SU
44
or MU feedback indicates the subcarrier grouping, Ng , codebook size and the number of columns, Nc , to
45
46 be used by the EHT beamformee identified by the STA Info field for the generation of the SU or MU
47 feedback.
48
49 In an EHT non-TB sounding sequence where the STA Info field in the EHT NDP Announcement frame
50
51 solicits SU feedback, the subcarrier grouping, Ng, codebook size and the number of columns, Nc , used for
52 the generation of the SU feedback are determined by the EHT beamformee(#7927).
53
54
In an EHT TB sounding sequence, a STA Info field in the EHT NDP Announcement frame that solicits CQI
55
56 feedback indicates the Nc to be used by the EHT beamformee identified by the STA Info field for the
57 generation of the CQI feedback.
58
59
60 In an EHT non-TB sounding sequence where the STA Info field in the EHT NDP Announcement frame
61 solicits CQI feedback, the Nc used for the generation of the CQI feedback is determined by the EHT
62 beamformee.
63
64
65

Copyright © 2022 IEEE. All rights reserved. 463

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 An EHT beamformer that transmits an EHT NDP Announcement frame as part of an EHT TB sounding
2 sequence shall set the Nc Index subfield(#1639) of the STA Info field to indicate a value less than or equal to
3
the minimum of:
4
5 — (#1120)The maximum number of supported receive spatial streams according to the corresponding
6 EHT beamformee’s EHT-MCS Map (20 MHz-Only Non-AP STA(#5872)), EHT-MCS Map
7 (BW ≤ 80 MHz, Except 20 MHz-Only Non-AP STA(#5872)), EHT-MCS Map (BW = 160 MHz),
8
9 and EHT-MCS Map (BW = 320 MHz) subfields in the Supported EHT-MCS And NSS Set field in
10 the EHT Capabilities element sent by the EHT beamformee.
11 — (#1120)The maximum number of supported receive spatial streams according to the Rx NSS
12
indicated in the most recently received Operating Mode Notification frame, Operating Mode
13
14 Notification element with the Rx NSS Type subfield equal to 0, or OM Control subfield if EHT OM
15 Control subfield is not present in the same A-Control field, or EHT OM Control subfield together
16 with the OM Control subfield sent by the corresponding EHT beamformee (see 35.10 (Operating
17 mode indication)).
18
19 — (#8369)The maximum supported Nc indicated by the Max Nc subfield in the EHT PHY Capabilities
20 Information field in the EHT Capabilities element sent by the EHT beamformee.
21
22 An EHT beamformer that transmits an EHT NDP Announcement frame shall set the Partial Bandwidth Info
23
24 subfield in a STA Info field to indicate the feedback subcarrier indices of the solicited EHT compressed
25 beamforming/CQI report (see 9.3.1.19 (VHT/HE/Ranging/EHT NDP Announcement frame format)).
26
27 The EHT beamformer shall set the TXVECTOR parameter CH_BANDWIDTH or
28 CH_BANDWIDTH_IN_NON_HT, the Partial BW Info subfield of the EHT NDP Announcement frame,
29
30 depending on the operating channel width, as defined in Table 9-42c (Settings for BW, Partial BW Info
31 subfield in the EHT NDP Announcement frame(#8157)).
32
33 The EHT beamformer shall use the lowest scidx  0  , which is the lower bound of the scidx  0  indicated
34
35 by the Partial BW Info subfield of a STA Info field that is equal to the maximum of:
36 — (#1120)The minimum subcarrier index located within the channel width indicated in the VHT
37 Operation Information field of either the HE Operation element or the VHT Operation element,
38
39 whichever is present, or within the channel width indicated in the HT Operation element, if present,
40 or 6 GHz Operation Information field of the HE Operation element, if present (#8214)(see
41 9.4.2.249 (HE Operation element) and 9.4.2.311 (EHT Operation element)).
42
— (#1120)The minimum subcarrier index located within the channel width indicated in the most
43
44 recently received Operating Mode Notification frame, Operating Mode Notification element with the
45 Rx NSS Type subfield equal to 0, or OM Control subfield if EHT OM Control subfield is not present
46 in the same A-Control field, or EHT OM Control subfield together with the OM Control subfield
47 sent by the corresponding EHT beamformee (see 35.10 (Operating mode indication)).
48
49
50 The EHT beamformer shall use the highest scidx  Ns – 1  , which is the upper bound of the scidx  Ns – 1 
51 indicated by the Partial BW Info subfield of a STA Info field that is equal to the minimum of:
52
53 — (#1120)The maximum subcarrier index located within the channel width indicated in the VHT
54 Operation Information field of either the HE Operation element or the VHT Operation element,
55 whichever is present, or within the channel width indicated in the HT Operation element, if present,
56 or 6 GHz Operation Information field of the HE Operation element, if present (#8215)(see
57
9.4.2.249 (HE Operation element) and 9.4.2.311 (EHT Operation element)).
58
59 — (#1120)The maximum subcarrier index located within the channel width indicated in the most
60 recently received Operating Mode Notification frame, Operating Mode Notification element with the
61 Rx NSS Type subfield equal to 0, or OM Control subfield if EHT OM Control subfield is not present
62
63 in the same A-Control field, or EHT OM Control subfield together with the OM Control subfield
64 sent by the corresponding EHT beamformee (see 35.10 (Operating mode indication)).
65

464 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 In an EHT non-TB sounding sequence soliciting SU feedback, B26 (in the Feedback Type And Ng
2 subfield), the Codebook Size subfield, and the Nc Index subfield(#1639) in the STA Info field of the EHT
3
NDP Announcement frame are reserved.
4
5
6 In an EHT non-TB sounding sequence soliciting CQI feedback, the Nc Index subfield(#1639) in an EHT
7 NDP Announcement frame is reserved.
8
9
(#7072)(#7079)An EHT beamformer that has initiated an EHT TB sounding sequence shall transmit a BFRP
10
11 Trigger frame to solicit feedback and may send additional BFRP Trigger frame(s) in the same TXOP, with
12 any STA being triggered only once within the TXOP. Figure 35-31 (An illustration of EHT TB
13 sounding(#7079)) shows an example with two BFRP Trigger frames. The EHT beamformer uses the
14 additional BFRP Trigger frames to solicit EHT compressed beamforming/CQI reports from EHT
15
beamformees not addressed in a previous BFRP Trigger frame. An EHT beamformer shall not transmit a
16
17 BFRP Trigger frame that identifies a STA identified in the EHT NDP Announcement frame of an EHT TB
18 sounding sequence unless it is in the same TXOP as the EHT TB sounding sequence.
19
20 (#7072)An EHT beamformer that sends a BFRP Trigger frame shall set the Feedback Segment
21
Retransmission Bitmap fields of the BFRP Trigger frame to all 1s.
22
23 (#7072)NOTE 1—The BFRP Trigger frame contains one or more User Info fields, each of which identifies an EHT
24 beamformee.
25
26
An EHT beamformee that receives an EHT NDP Announcement frame soliciting SU feedback as part of an
27
28 EHT non-TB sounding sequence shall generate an EHT compressed beamforming/CQI report for SU
29 feedback with Nc in the range 1 to 8, Ng = 4 or Ng = 16 , and codebook size     =  4 2  or
30
31     =  6 4  . The EHT beamformee shall transmit the EHT compressed beamforming/CQI report a
32 SIFS after the EHT sounding NDP.
33
34 An EHT beamformee that receives an EHT NDP Announcement frame soliciting CQI feedback as part of an
35
EHT non-TB sounding sequence shall generate an EHT compressed beamforming/CQI report for CQI
36
37 feedback with Nc determined by the EHT beamformee.
38
39 An EHT beamformee that receives an EHT NDP Announcement frame soliciting CQI feedback as part of an
40
41 EHT TB sounding sequence shall generate an EHT compressed beamforming/CQI report for CQI feedback
42 with Nc determined by the EHT beamformer.
43
44
(#7929)(#7930)An EHT beamformee that receives an EHT NDP Announcement frame as part of an EHT
45
46 non-TB sounding sequence shall transmit its EHT compressed beamforming/CQI report a SIFS after the
47 EHT sounding NDP. The TXVECTOR parameter CH_BANDWIDTH for the PPDU containing the EHT
48 compressed beamforming/CQI report shall be set to indicate a bandwidth not wider than that indicated by
49 the RXVECTOR parameter CH_BANDWIDTH of the EHT sounding NDP.
50
51
52 An EHT beamformee that receives an EHT NDP Announcement frame as part of an EHT TB sounding
53 sequence with a STA Info field identifying it soliciting SU or MU feedback shall generate an EHT
54 compressed beamforming/CQI report using the feedback type, Ng , codebook size, and Nc indicated in the
55
56 STA Info field. (#1120)If the EHT beamformee then receives a BFRP Trigger frame with a matching STA
57 Info field, the EHT beamformee transmits an EHT TB PPDU containing the EHT compressed
58 beamforming/CQI report following the rules defined in 35.5.2.3 (Non-AP STA behavior for UL MU
59 operation). If the EHT NDP Announcement frame has the TA field set to the transmitted BSSID, and the
60 EHT beamformee is a non-AP STA associated with an AP corresponding to a nontransmitted BSSID that
61
62 supports receiving Control frames with TA field set to the transmitted BSSID, then the EHT compressed
63 beamforming/CQI report sent in response shall have the RA field set to as defined in 26.5.2.3.5 (RA field for
64 frame carried in an HE TB PPDU).
65

Copyright © 2022 IEEE. All rights reserved. 465

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 NOTE 2—A non-AP EHT beamformee that transmits an OM Control subfield with the UL MU Disable field set to 1
2 does not respond to BFRP Trigger frames (see 35.10 (Operating mode indication)).
3
4 (#7931)An EHT beamformee that transmits an EHT Compressed Beamforming/CQI Report frame sets the
5
Partial BW Info subfield of the EHT MIMO Control field to indicate the range of subcarriers for which
6
7 compressed beamforming/CQI information is provided. The Partial BW Info subfield shall be set to the
8 value of the Partial BW Info subfield of the NDP Announcement frame for the EHT beamformee.
9
10 An EHT beamformee that transmits EHT compressed beamforming feedback shall include neither the EHT
11
compressed beamforming report information nor the EHT MU exclusive beamforming report information if
12
13 the transmission duration of the PPDU carrying the EHT compressed beamforming report information and
14 any EHT MU exclusive beamforming report information would exceed the maximum PPDU duration
15 (#4430)(see Table 9-34 (Maximum data unit sizes (in octets) and durations (in microseconds))).
16
17
The Sounding Dialog Token Number field in the EHT MIMO Control field shall be set to the same value as
18
19 the Sounding Dialog Token Number field in the corresponding EHT NDP Announcement frame.
20
21 (#1120)The SNR per subcarrier computation should be done on at least four subcarriers in a 26-tone RU.
22
23
35.7.4 Rules for generating segmented feedback
24
25
26 If the EHT compressed beamforming/CQI report solicited by the EHT beamformer would result in an EHT
27 Compressed Beamforming/CQI frame that exceeds 11454 octets in length, then the EHT compressed
28 beamforming/CQI report shall be split into up to eight feedback segments. Each feedback segment shall be
29
included in a separate EHT Compressed Beamforming/CQI frame and shall contain successive portions of
30
31 the EHT compressed beamforming/CQI report. Each feedback segment shall be of equal length except the
32 last feedback segment that may be smaller. Each EHT Compressed Beamforming/CQI frame that includes a
33 feedback segment that is not the last feedback segment shall have a length of 11454 octets. Each feedback
34 segment is identified by the value of the Remaining Feedback Segments subfield and the First Feedback
35
Segment subfield in the EHT MIMO Control field as defined in 9.4.1.70 (EHT MIMO Control field). The
36
37 other nonreserved subfields of the EHT MIMO Control field shall be the same for all feedback segments.
38 All feedback segments shall be sent in a single A-MPDU contained in a PPDU and shall be included in the
39 A-MPDU in the descending order of the values of the Remaining Feedback Segments subfield.
40
41
An EHT beamformer, which sends a BFRP Trigger frame to retrieve an EHT compressed beamforming/CQI
42
43 report from an EHT beamformee, shall solicit all possible feedback segments by setting all of the bits in the
44 Feedback Segment Retransmission Bitmap subfield to 1 in the User Info field identifying the EHT
45 beamformee.
46
47
An EHT beamformer, which fails to receive some or all of the feedback segments of the EHT compressed
48
49 beamforming/CQI report from the EHT beamformee, shall not use a BFRP Trigger frame to request
50 retransmission of the feedback segments. In this case, the EHT beamformer may repeat the entire sounding
51 sequence.
52
53
35.7.5 EHT sounding NDP transmission
54
55
56 The TXVECTOR parameters for an EHT sounding NDP shall be set as follows:
57 — FORMAT is set to EHT_MU.
58
59 — APEP_LENGTH is set to 0.
60 — EHT_LTF_TYPE is set to either 2 EHT-LTF or 4 EHT-LTF (if supported)(#7081).
61
62 — If EHT_LTF_TYPE is 2 EHT-LTF, then GI_TYPE is set to either 0.8 µs GI or 1.6 µs GI.
63 — If EHT_LTF_TYPE is 4 EHT-LTF, then GI_TYPE is set to 3.2 µs GI.
64
65

466 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — NUM_STS indicates two or more spatial streams if the Feedback Type And Ng and Codebook Size
2 subfields in the preceding EHT NDP Announcement frame(#7933) indicates either SU or MU, or
3
one or more spatial streams if the Feedback Type and Ng Codebook Size subfields in the preceding
4
5 EHT NDP Announcement frame(#7933) indicates CQI. See below for additional constraints on
6 NUM_STS.
7 — CH_BANDWIDTH is set to the same value as the TXVECTOR parameter CH_BANDWIDTH or
8
9 CH_BANDWIDTH_IN_NON_HT of the preceding PPDU carrying the EHT NDP Announcement
10 frame(#7934).
11 — SPATIAL_REUSE is set to PSR_AND_NON_SRG_OBSS_PD_PROHIBITED (see 35.12.2
12
(SPATIAL_REUSE(#6799))).
13
14 — BSS_COLOR is set to the value indicated in the BSS Color subfield of the HE Operation element
15 received or transmitted by the EHT AP.
16
17 — TXOP_DURATION set to either 127 or a value defined in Equation (35-2).
18
19 D EHT_NDPA – SIFS – TXTIME D EHT_NDPA – SIFS – TXTIME
20 max  min  8 --------------------------------------------------------------------------
-  504  min  128 --------------------------------------------------------------------------
-  8448  (35-2)
  8 128
21
22
23 where
24
25
D EHT_NDPA is the value of the Duration/ID field in the MAC header of the preceding EHT NDP
26 Announcement frame.
27 TXTIME is the transmission time of an EHT sounding NDP defined in Equation (36-110)
28
29
30 The Supported EHT-MCS and NSS Set field in the EHT Capabilities element transmitted by the transmitter
31 and the receiver of the EHT sounding NDP do not affect the values used for the NUM_STS parameter for
32 the TXVECTOR of an EHT sounding NDP.
33
34
35 (#7935)The destination of an EHT sounding NDP is the STA(s) addressed by the STA Info field(s) in the
36 immediately preceding EHT NDP Announcement frame.
37
38 The source of an EHT sounding NDP is equal to the TA of the immediately preceding EHT NDP
39 Announcement frame.
40
41
42
43
35.8 TWT operation
44
45 35.8.1 General(#4767)(#6410)
46
47 A TWT STA shall follow the rules as described in 26.8 (TWT operation) in general. In addition, within
48
49
trigger-enabled SPs, the trigger frame may be an MU RTS TXS Trigger frame and the procedure follows
50 35.2.1.2 (Triggered TXOP sharing procedure).
51
52 35.8.2 Individual TWT agreements
53
54
55
A STA affiliated with an MLD may negotiate individual TWT agreements with another STA affiliated with
56 another MLD as defined in 10.47.1 (TWT overview) and 26.8.2 (Individual TWT agreements) except the
57 following:
58 — The STA affiliated with the MLD may indicate the link(s) that are requested for setting up TWT
59
60 agreement(s) in the Link ID Bitmap subfield, if present, of a TWT element in the TWT request.
61 • If only one link is indicated in the Link ID Bitmap subfield of the TWT element, then a single
62 TWT agreement is requested on behalf of the STA affiliated with the same MLD and that is
63
64
operating on the indicated link. The Target Wake Time field of the TWT element shall be in ref-
65 erence to the TSF time of the link indicated by the TWT element.

Copyright © 2022 IEEE. All rights reserved. 467

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — A STA affiliated with a peer MLD that receives a TWT request that contains a Link ID Bitmap
2 subfield in a TWT element shall respond with a TWT response that may indicate the link(s) in the
3
Link ID Bitmap field of a TWT element. The link(s), if present, in the TWT element in the TWT
4
5 response, shall be the same as the link(s) indicated in the TWT element of the soliciting TWT
6 request.
7
8 During the negotiation of TWT agreements, a TWT requesting STA affiliated with an MLD and a TWT
9
responding STA affiliated with another MLD may include multiple TWT elements where each of the Link
10
11 ID Bitmap subfields in each TWT element indicates different link(s) in the same TWT Setup frame. The
12 TWT parameters provided by each TWT element shall be applied and be in reference to the respective link
13 that is indicated in the TWT element.
14
15
An example of TWT agreements negotiated for multiple links is shown in Figure 35-32 (Example of TWT
16
17 agreements negotiation across multiple links).
18
19
AP 1 AP 2 AP 3 AP 1 AP 2 AP 3
20 AP MLD
2.4 GHz 5 GHz 6 GHz
AP MLD
2.4 GHz 5 GHz 6 GHz
21 Successful TWT
agreement setup
22
23
TWT Link 1 Link 2 Link 3
24 request
TWT
response
25
TWT agreements setup on link 1, link 2 and link3
26
27
28 Non-AP MLD
Non-AP
STA 1
Non-AP
STA 2
Non-AP
STA 3
Non-AP MLD
Non-AP
STA 1
Non-AP
STA 2
Non-AP
STA 3
29
30
31 Figure 35-32—Example of TWT agreements negotiation across multiple links
32
33
34
35 In this example, an AP MLD has three affiliated APs: AP 1 operates on 2.4 GHz band, AP 2 operates on
36 5 GHz band, and AP 3 operates on 6 GHz band. Non-AP STA 1 affiliated with the non-AP MLD sends three
37 TWT elements in a TWT request to AP 1 affiliated with the AP MLD. These three TWT elements indicate
38 the links of AP 1, AP 2, and AP 3 requesting three links to be setup TWT agreements, respectively, have
39 different TWT parameters, such as target wake up time, and all are with a value of Request TWT in the
40
41 TWT Setup Command field. AP 1 sends three TWT elements in a TWT response to non-AP STA 1 and
42 these three TWT elements indicate the links of AP 1, AP 2, and AP 3 respectively; and they are all with a
43 value of Accept TWT in the TWT Setup Command field. After successful TWT agreements setup on the
44 three links, three TWT SPs with different TWT parameters exist on these three links (Link 1 between AP 1
45 and non-AP STA 1, Link 2 between AP 2 and non-AP STA 2, and Link 3 between AP 3 and non-AP
46
47 STA 3), respectively. For these three TWT agreements, the Target Wake Time field of the TWT element
48 that indicates Link 1 is in reference to the TSF time of Link 1, the Target Wake Time field of the TWT
49 element that indicates Link 2 is in reference to the TSF time of Link 2 and the Target Wake Time field of the
50 TWT element that Link 3 is in reference to the TSF time of Link 3.
51
52
53 35.9 Restricted TWT (r-TWT)
54
55
56 35.9.1 General
57
58 Traffic originating from many real time applications has stringent latency requirements (e.g., very low
59 average latency and worst case latency of the order of a few to tens of milliseconds, and small jitter, all of
60
61
which can have certain reliability constraints as well). Such traffic is referred to as latency sensitive traffic in
62 this subclause. r-TWT operation described in this subclause allows an AP to use enhanced medium access
63 protection and resource reservation mechanisms to provide more predictable latency, reduced worst case
64 latency, and/or reduced jitter, with higher reliability for latency sensitive traffic.
65

468 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 An EHT STA that supports r-TWT operation shall set dot11RestrictedTWTOptionImplemented to true and
2 the Restricted TWT Support subfield in transmitted EHT Capabilities elements to 1; otherwise, the STA
3
shall set dot11RestrictedTWTOptionImplemented to false and the Restricted TWT Support subfield in
4
5 transmitted EHT Capabilities elements to 0.
6
7 A non-AP EHT STA establishes membership for one or more r-TWT schedules with its associated EHT AP
8 by following the rules defined in 26.8.3 (Broadcast TWT operation) with the additional rules defined in
9
35.9.2 (r-TWT agreement setup). An EHT AP that has dot11RestrictedTWTOptionImplemented equal to
10
11 true may announce one or more r-TWT SPs as described in 35.9.3 (r-TWT service periods announcement).
12 EHT STAs that support r-TWT operation follow the rules as defined in 26.8.3 (Broadcast TWT operation)
13 and the additional rules and restrictions that are defined in 35.9.4 (Channel access rules for r-TWT service
14 periods) if the EHT AP has announced r-TWT SPs.
15
16
17 35.9.2 r-TWT agreement setup
18
19 35.9.2.1 Latency sensitive traffic differentiation
20
21
This subclause defines a mechanism that differentiates latency sensitive traffic from other types of traffic.
22
23
24 35.9.2.2 The setup procedure(#2920)
25
26 An r-TWT agreement is established using the same procedure used to set up a broadcast TWT agreement as
27
described in 26.8.3 (Broadcast TWT operation) except that the TWT setup frames contain a broadcast TWT
28
29 element that includes a Restricted TWT Parameter Set field as described in 9.4.2.199 (TWT element).
30
31 An r-TWT scheduling AP is an EHT AP that supports r-TWT operation and sets the Restricted TWT
32 Support subfield in transmitted EHT Capabilities elements to 1.
33
34
35 An r-TWT scheduled STA is a non-AP EHT STA that supports r-TWT operation and sets the Restricted
36 TWT Support subfield in transmitted EHT Capabilities elements to 1.
37
38 When included in an individually addressed TWT Setup frame transmitted by an r-TWT scheduling AP or r-
39
TWT scheduled STA, the Restricted TWT Traffic Info Present subfield of the Broadcast TWT Info field
40
41 shall be set to 1.
42
43 (#4782)An r-TWT scheduling AP that includes a Restricted TWT Parameter Set field in a broadcast TWT
44 element shall set the Restricted TWT Traffic Info Present subfield of the Restricted TWT Parameter Set field
45
to 0 if the Negotiation Type subfield of the TWT element is equal to 2.
46
47
48 (#5954)The r-TWT scheduling AP should indicate in the Restricted TWT DL TID Bitmap and Restricted
49 TWT UL TID Bitmap subfields only the TIDs that are mapped to the link on which the r-TWT membership
50 is being set up (see 35.3.7.1 (TID-to-link mapping)).
51
52
53 (#5954)The r-TWT scheduled STA should indicate in the Restricted TWT DL TID Bitmap and Restricted
54 TWT UL TID Bitmap subfields only the TIDs that are mapped to the link on which the r-TWT membership
55 is being set up (see 35.3.7.1 (TID-to-link mapping)).
56
57
(#4767)(#4775)The TID(s) that are specified in the Restricted TWT DL TID Bitmap subfield or Restricted
58
59 TWT UL TID Bitmap subfield with the corresponding DL or UL TID Bitmap Valid subfield set to 1 in a
60 TWT Response frame that indicates Accept TWT are referred to as r-TWT DL TID(s) or r-TWT UL TID(s),
61 and collectively as r-TWT TID(s), in the following subclauses.
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 469

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 35.9.3 r-TWT service periods announcement

2
3
If there is any r-TWT agreement set up, the EHT AP shall announce the r-TWT SP schedule information in
4
5 the modified broadcast TWT element contained in transmitted Management frames, which are specified in
6 26.8.3 (Broadcast TWT operation).
7
8 (#6414)An r-TWT scheduling AP, while advertising an r-TWT schedule, shall indicate whether or not the
9
schedule is available for accommodating any new membership. If the Restricted TWT Schedule Full
10
11 subfield in the Broadcast TWT Info subfield in a Restricted TWT Parameter Set field is set to 1, it indicates
12 that the corresponding r-TWT schedule is not available for accommodating any new membership;
13 otherwise, it is available for new membership. A STA should not request to establish membership in an r-
14 TWT schedule advertised by the r-TWT scheduling AP with Restricted TWT Schedule Full subfield set to 1.
15
16
17 35.9.4 Channel access rules for r-TWT service periods
18
19 35.9.4.1 TXOP rules for r-TWT SPs(#6950)(#2215)
20
21
A non-AP EHT STA with dot11RestrictedTWTOptionImplemented set to true as a TXOP holder shall
22
23 ensure (#6950)the TXOP ends before the start time of any r-TWT SPs advertised by the associated AP.
24
25 35.9.4.2 Quieting STAs during r-TWT service periods(#2215)
26
27
(#4157)An r-TWT scheduling AP may schedule (#6336)at most one quiet interval that overlaps with a r-
28
29 TWT SP. Each such (#4706)quiet interval, referred to as an overlapping (#4706)quiet interval in this
30 subclause, if scheduled, shall have a duration of 1 TU, and shall start at the same time as the corresponding
31 r-TWT SP.
32
33
Overlapping quiet intervals may be scheduled by including one or more Quiet elements in the Beacon and
34
35 Probe Response frames that the EHT AP transmits. (#4159)(#4117)An EHT AP affiliated with an AP MLD
36 shall not include in its transmitted Beacon (#4088)or Probe Response frames any Quiet elements that
37 correspond to overlapping quiet intervals that are scheduled and advertised by other APs affiliated with the
38 same AP MLD (see 35.3.11 (Multi-link procedures for channel switching, extended channel switching, and
39
channel quieting(#4112)(#2324)(#2600))).
40
41 NOTE—Unless specified otherwise (e.g., through the rules in this subclause), the channel access and transmission rules
42 during quiet intervals are defined in 11.8.3 (Quiet channels for testing), (#4160)26.17.1 (Basic HE BSS operation), and
43 26.17.2 (HE BSS operation in the 6 GHz band). AP can still use quiet intervals for channel testing by managing or
44 avoiding the overlap between r-TWT SPs and quiet intervals that it schedules.
45
46
Non-AP EHT STAs may behave as if overlapping quiet intervals do not exist.
47
48
49 35.9.5 Traffic delivery(#4775)
50
51 An r-TWT scheduling AP or a member r-TWT scheduled STA that has initiated or participated in a frame
52
exchange during a restricted TWT SP shall ensure QoS Data frames of r-TWT TID(s) to be first delivered
53
54 during the r-TWT SPs. In a trigger-enabled restricted TWT SP, when scheduling the transmission of Trigger
55 frames, the r-TWT scheduling AP shall first trigger member r-TWT scheduled STAs to facilitate them to
56 first deliver their QoS Data frames of r-TWT UL TID(s), if any.
57
58 NOTE—The r-TWT scheduling AP might still include the 12 LSB of the AID of a STA that is not a member of this r-
59 TWT SP in Trigger frame(s) transmitted in trigger-enabled SPs.
60
61
62
63
64
65

470 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 35.10 Operating mode indication

2
3
4 (#6576)(#7936)(#4162)An EHT AP that supports 320 MHz shall set dot11EHTOMIOptionImplemented to
5 true.
6
7 An EHT STA with dot11EHTOMIOptionImplemented (#7085)equal to true shall set the EHT OM Control
8 Support subfield in the EHT MAC Capabilities Information field in the EHT Capabilities element it
9
10 transmits to 1; otherwise the EHT STA shall set the EHT OM Control Support subfield to 0.
11
12 An EHT STA with dot11EHTOMIOptionImplemented (#7086)equal to true shall set
13 dot11OMIOptionImplemented to true.(#4090)(#4162)
14
15
16 An EHT STA that transmits a frame with an A-Control subfield of HE variant HT Control field, which
17 includes an EHT OM Control subfield shall concatenate the OM Control subfield within the same A-Control
18 subfield after the EHT OM Control field. An EHT STA shall not include an EHT OM Control field in an A-
19 Control field unless the OM Control field is present in the same A-Control field.
20
21 NOTE 1—An EHT STA is an HE STA and as such inherits all the functionalities defined in 26.9 (Operating mode
22 indication).
23
24 NOTE 2—Based on the requirement to concatenate the OM Control subfield after an EHT OM Control subfield and the
25 definition of OMI initiator and OMI responder in 26.9 (Operating mode indication), an EHT STA that transmits a frame
26 including an EHT OM Control subfield is an OMI initiator, and an EHT STA with dot11EHTOMIOptionImplemented to
27 true that receives a frame including an EHT OM Control subfield is an OMI responder.
28
29 For an EHT STA that is an OMI initiator or an OMI responder, the rule described in 26.9.3 (Transmit
30
31 operating mode (TOM) indication) that applies to HE TB PPDU shall (#7937)also apply to EHT TB PPDU.
32
33 An OMI initiator that transmits a frame including an EHT OM Control subfield and (#6573)an OMI
34 responder that receives a frame including an EHT OM Control field shall follow the rules defined in
35
36 26.9 (Operating mode indication), except that the N SS , (#6574)the N STS , and/or the maximum operating
37 channel width shall be calculated by (#6574)the EHT OM Control subfield (#6574)combined with the OM
38 Control subfield as defined in 9.2.4.7.8 (EHT OM Control).
39
40
41 (#6082)NOTE—EHT PHY does not support STBC. The terms “space-time stream” and “spatial stream” are equivalent
42 in EHT.
43
44 (#6606)If the operating channel width of the STA is greater than 80 MHz, then the maximum number of
45 spatial streams that the STA supports in reception for a given EHT-MCS as a function of the received EHT
46 PPDU bandwidth BW at an EHT STA transmitting only an OM Control subfield or an EHT OM Control
47
48 subfield combined with an OM Control subfield is defined in Equation (35-3).
49
50
51 floor  Rx-NSS-from-OMI   Max-EHT-NSS-at-BW  Max-EHT-NSS-at-80   (35-3)
52
53
54 where
55 Rx-NSS-from-OMI is NSS indicated by the Rx NSS subfield in the OM Control subfield (see 9.2.4.6a.2
56
57 (OM Control)) or indicated by the Rx NSS Extension subfield in the EHT OM Control subfield
58 combined with the Rx NSS subfield in the OM Control subfield (see 9.2.4.7.8 (EHT OM
59 Control)).
60
Max-EHT-NSS-at-BW is the maximum NSS among all EHT-MCS at BW MHz from the Supported
61
62 EHT-MCS And NSS Set field (9.4.2.313.4 (Supported EHT-MCS And NSS Set field(#1126)))
63 transmitted by the STA.
64
65

Copyright © 2022 IEEE. All rights reserved. 471

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Max-EHT-NSS-at-80 is the maximum NSS among all EHT-MCS at 80 MHz from the Supported EHT-
2
3 MCS And NSS Set field (9.4.2.313.4 (Supported EHT-MCS And NSS Set field(#1126)))
4 transmitted by the STA.
5
6
7 35.11 EHT Spatial reuse operation(#5444)
8
9 35.11.1 General
10
11
12 An EHT STA follows the rules defined in 26.10 (Spatial reuse operation) with different rules defined as
13 below.
14
15 (#5776)An EHT STA follows the rules defined in 26.2.3 (SRG PPDU identification) and the following rule:
16
17 — A received EHT PPDU that is an inter-BSS PPDU is an SRG PPDU if the bit in the SRG BSS Color
18 Bitmap field indexed by the value of the RXVECTOR parameter BSS_COLOR is 1 (see
19 9.4.2.252 (Spatial Reuse Parameter Set element)).
20
21
22 (#5776)An EHT STA follows the rules defined in 35.2.3 (Intra-BSS and inter-BSS PPDU classification for
23 EHT STA(#4287)).
24
25 35.11.2 OBSS PD-based spatial reuse operation(#5776)
26
27
28 An EHT STA follows the rules defined in 26.10.2.2 (General operation with non-SRG OBSS PD level) and
29 26.10.2.3 (General operation with SRG OBSS PD level) and the following rules:
30 — The PHY-CCARESET.request primitive shall be issued at the end of the PPDU if the PPDU is an
31
EHT MU PPDU addressed to a single STA and the RXVECTOR parameter SPATIAL_REUSE
32
33 indicates SR_DELAYED.
34 — If the PHY-CCARESET.request primitive is issued before the end of the received PPDU, and a
35 TXOP is initiated within the duration of the received PPDU, then the TXOP and the duration of the
36
37 transmitted PPDU within that TXOP shall be limited to the duration of the received PPDU if the
38 received PPDU is an EHT MU PPDU addressed to multiple STAs and the RXVECTOR parameter
39 SPATIAL_REUSE indicates SR_RESTRICTED.
40
— The received signal strength level used to determine if it is below the non-SRG OBSS PD level or
41
42 SRG OBSS PD level is measured in dBm/20 MHz from the L-STF or L-LTF fields in at least one of
43 the nonpunctured 20 MHz subchannels of the PPDU or the PHY SYNC field, shortSYNC field or
44 Long PHY SYNC field, whichever exists and which is used to determine PHY-CCA.indication. It is
45 implementation specific on which 20 MHz subchannels the received signal strength level is
46
measured.
47
48
49 An EHT STA follows the rules defined in 26.10.2.4 (Adjustment of OBSS PD and transmit power), except
50 that the following applies:
51
52 — If using OBSS PD-based spatial reuse, an EHT STA shall maintain an OBSS PD level and may
53 adjust this OBSS PD level in conjunction with its transmit power. The adjustment shall be made in
54 accordance with Equation (35-4).
55
56
57 OBSS_PD level  max  OBSS PDmin min  OBSS PD max OBSS PDmin +  TX PWR ref – TX PWR    (35-4)
58
59 where OBSS PD , OBSS PD , TW PWR , and TWPWR are defined in 26.10.2.4 (Adjustment of OBSS
min max ref
60 PD and transmit power).
61
62
63
64
65

472 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 35.11.3 EHT PSR-based spatial reuse operation(#5444)

2
3
35.11.3.1 EHT PSR-based spatial reuse initiation(#5444)
4
5
6 An EHT STA identifies an PSR opportunity if the following two conditions are met:
7 1) The EHT STA receives a PHY-RXSTART.indication corresponding to the reception of a PSRR
8
9 PPDU that is identified as an inter-BSS PPDU (see 26.2.2 (Intra-BSS and inter-BSS PPDU classifi-
10 cation)).
11 2) An PSRT PPDU is queued for transmission and the intended transmit power of the PSRT PPDU in
12
dBm shall meet the following condition:
13
14
15 TxPower PSRT total – 10  log 10 N PSRT nonpunc  PSR min – RPL PSRR 20MHz (35-5)
16
17
18 where
19 N PSRT nonpunc is the number of nonpunctured 20 MHz subchannels of the PSRT PPDU
20
21 RPLPSRR 20MHz is the received signal power measured in dBm/20 MHz. It shall be measured in
22 at least one 20 MHz channel in which the preamble of PSRR PPDU is present. The measure-
23 ment method is implementation specific.
24
PSR min is equal to PSR value if there exists one PSR value within the bandwidth of PSRT
25
26 PPDU or equal to the minimum of multiple PSR values if there exist multiple PSR values
27 within the bandwidth of PSRT PPDU. Each PSR is specified per 20 MHz. The PSR value is
28 based on at least one of the following:
29
30 a) The value of the UL Spatial Reuse field in the Common Info field of the Trigger frame of
31 the PSRR PPDU if an HE TB PPDU follows the PSRR PPDU, or
32 b) Special User Info field of the Trigger frame of the PSRR PPDU if an EHT TB PPDU
33
follows the PSRR PPDU, or
34
35 c) The value of the RXVECTOR parameter Spatial Reuse of the TB PPDU that follows the
36 PSRR PPDU.
37
38
39 35.12 Rules related to the PHY interface of an EHT STA(#4627)(#4633)
40
41
42 35.12.1 Setting TXVECTOR parameters for an EHT PPDU
43
44 35.12.1.1 STA_ID
45
46
For an individually addressed RU that is addressed to an associated non-AP STA the parameter STA_ID
47
48 shall be set to 11 LSBs of the AID of the STA receiving the PSDU contained in that RU. If an RU is
49 intended for an AP (i.e., the TXVECTOR parameter UPLINK_FLAG is 1), then the parameter STA_ID
50 shall contain only one element that is set to the 11 LSBs of the AID of the non-AP STA transmitting the
51 PPDU.
52
53
54 35.12.1.2 POWER_BOOST_FACTOR(#4630)
55
56 The power boost factor POWER_BOOST_FACTOR for the r-th occupied RU or MRU in an OFDMA EHT
57
58 MU PPDU in the TXVECTOR shall be in the range of  1  2 2  if the Power Boost Factor Support
59 subfield of the EHT PHY Capabilities Information field in the EHT Capabilities element from any recipient
60 STA of the PPDU equals 0; and otherwise shall be in the range of [0.5, 2]. For a non-OFDMA EHT MU
61 PPDU transmitted to a single user, POWER_BOOST_FACTOR shall be set to 1.
62
63
64 Subject to these constraints, the value of POWER_BOOST_FACTOR is otherwise implementation specific.
65

Copyright © 2022 IEEE. All rights reserved. 473

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 35.12.2 SPATIAL_REUSE(#6799)
2
3
The contents of the Spatial Reuse fields are carried in the TXVECTOR parameter SPATIAL_REUSE for an
4
5 EHT PPDU indicating spatial reuse information. The behavior of STAs upon reception of an EHT PPDU
6 with different SPATIAL_REUSE values is described in 26.10.2 (OBSS PD-based spatial reuse operation)
7 and 35.11.3 (EHT PSR-based spatial reuse operation(#5444)). The different values that may be indicated in
8 the SPATIAL_ REUSE parameter of the TXVECTOR are listed in Table 27-22 (Spatial Reuse field
9
encoding for an HE SU PPDU, HE ER SU PPDU, and HE MU PPDU) that is applied to EHT MU PPDU
10
11 and Table 27-23 (Spatial Reuse field encoding for an HE TB PPDU) that is applied to EHT TB PPDU. The
12 value PSR_DISALLOW is used to prohibit PSR-based spatial reuse during the transmission of the
13 corresponding PPDU. The value PSR_AND_NON_SRG_ OBSS_PD_PROHIBITED is used to prohibit
14 both PSR-based spatial reuse and non-SRG OBSS PD-based spatial reuse during the transmission of the
15
corresponding PPDU. The interpretation of other values are described in this subclause and in 35.11 (EHT
16
17 Spatial reuse operation(#5444)) and 26.10 (Spatial reuse operation). The conditions for a STA to set the
18 SPATIAL_REUSE parameter to its different values are described in this subclause.
19
20 For a PPDU with a value of EHT_TB for the TXVECTOR parameter FORMAT, the SPATIAL_REUSE
21
parameter contains an array of one to two values, depending on the TXVECTOR parameter
22
23 CH_BANDWIDTH. If the TXVECTOR parameter CH_BANDWIDTH is CBW20, the value is the
24 SPATIAL_REUSE parameter that applies to the 20 MHz subband. If the TXVECTOR parameter
25 CH_BANDWIDTH is CBW40, the first value in the array is the SPATIAL_REUSE parameter that applies
26 to the first lowest 20 MHz subband, and the second value is the SPATIAL_REUSE parameter that applies to
27
the second lowest 20 MHz subband. If the TXVECTOR parameter CH_BANDWIDTH is CBW80, the first
28
29 value in the array is the SPATIAL_REUSE parameter that applies to each 20 MHz subchannel of the first
30 lowest 40 MHz subband, and the second value applies to each 20 MHz subchannel of the second lowest
31 40 MHz subband. If the TXVECTOR parameter CH_BANDWIDTH is CBW160, the first value in the array
32 is the SPATIAL_REUSE parameter that applies to each 20 MHz subchannel of the first lowest 80 MHz
33
subband, and the second value applies to each 20 MHz subchannel of the second lowest 80 MHz subband. If
34
35 the TXVECTOR parameter CH_BANDWIDTH is CBW320-1 or CBW320-2, the first value in the array is
36 the SPATIAL_REUSE parameter that applies to each 20 MHz subchannel of the first lowest 160 MHz
37 subband, and the second value applies to each 20 MHz subchannel of the second lowest 160 MHz subband.
38
39
An EHT STA that transmits an EHT TB PPDU sets the TXVECTOR parameter SPATIAL_REUSE as
40
41 defined in 35.5.2.3 (Non-AP STA behavior for UL MU operation).
42
43 A non-AP STA with dot11HEPSROptionImplemented set to true that transmits an EHT MU PPDU may set
44 the TXVECTOR parameter SPATIAL_REUSE, when permitted by other conditions, to
45
PSR_AND_NON_SRG_OBSS_PD_PROHIBITED if the HESIGA_Spatial_reuse_value15_allowed
46
47 subfield of the SR Control field of the most recently received Spatial Reuse Parameter Set element from its
48 associated AP is equal to 1. Otherwise, the non-AP STA shall set it to PSR_DISALLOW.
49
50 An EHT STA that transmits an EHT TB PPDU determines the value of the TXVECTOR parameter
51
SPATIAL_REUSE according to 35.5.2.3 (Non-AP STA behavior for UL MU operation).
52
53
54 An EHT AP with dot11HEPSROptionImplemented set to true that transmits an EHT MU PPDU may set the
55 TXVECTOR parameter SPATIAL_REUSE to PSR_DISALLOW to disallow OBSS STAs from performing
56 (#5444)EHT PSR-based SR transmission during the duration of the corresponding PPDU.
57
58
59 An EHT STA with dot11HEPSROptionImplemented set to false may set the TXVECTOR parameter
60 SPATIAL_REUSE to PSR_DISALLOW for any PPDU that is not an EHT TB PPDU, an EHT sounding
61 NDP, a PPDU containing an EHT NDP Announcement frame, or a PPDU containing a response to an HE
62 NDP Announcement frame.
63
64
65

474 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 A STA shall set the TXVECTOR parameter SPATIAL_REUSE of an EHT PPDU to PSR_DISALLOW or,
2 if permitted by the other rules in this subclause, to PSR_AND_NON_SRG_OBSS_PD_PROHIBITED, if
3
the STA is a non-AP EHT STA and the PSR Disallowed subfield of the SR Control field of the most recently
4
5 received Spatial Reuse Parameter Set element from its associated AP is equal to 1.
6
7 An EHT STA shall set the TXVECTOR parameter SPATIAL_REUSE to
8 PSR_AND_NON_SRG_OBSS_PD_ PROHIBITED for an EHT sounding NDP.
9
10
11 An EHT STA shall set the TXVECTOR parameter SPATIAL_REUSE to
12 PSR_AND_NON_SRG_OBSS_PD_ PROHIBITED for a PPDU containing an NDP Announcement frame
13 and in any frame that is transmitted as a response to an NDP Announcement frame.
14
15
A non-AP EHT STA may set the TXVECTOR parameter SPATIAL_REUSE of an EHT PPDU to
16
17 PSR_AND_NON_SRG_OBSS_PD_PROHIBITED if the HESIGA_Spatial_reuse_value15_allowed
18 subfield of the SR Control field of the most recently received Spatial Reuse Parameter Set element from its
19 associated AP is equal to 1. If the HESIGA_Spatial_reuse_value15_allowed subfield of the SR Control field
20 of the most recently received Spatial Reuse Parameter Set element from its associated AP is equal to 0, or if
21
STA has not received a Spatial Reuse Parameter Set element from its associated AP, the STA shall not set the
22
23 TXVECTOR parameter SPATIAL_REUSE of any EHT PPDU to PSR_AND_NON_SRG_OBSS_PD_
24 PROHIBITED, unless the EHT PPDU contains an NDP, an NDP Announcement frame or is a frame that is
25 transmitted as a response to an NDP Announcement frame.
26
27
An AP EHT STA may set the TXVECTOR parameter SPATIAL_REUSE of an EHT PPDU to
28
29 PSR_AND_NON_SRG_OBSS_PD_PROHIBITED if the HESIGA_Spatial_reuse_value15_allowed
30 subfield of the SR Control field of the most recently transmitted Spatial Reuse Parameter Set element is
31 equal to 1. If the HESIGA_Spatial_reuse_value15_allowed subfield of the SR Control field of the most
32 recently transmitted Spatial Reuse Parameter Set element is equal to 0, or if the AP has not transmitted a
33
Spatial Reuse Parameter Set element, the AP shall not set the TXVECTOR parameter SPATIAL_REUSE of
34
35 any EHT PPDU to PSR_AND_NON_SRG_OBSS_PD_PROHIBITED.
36
37 An EHT AP that transmits an EHT MU PPDU that contains a Trigger frame and is configured for a single
38 user should set the TXVECTOR parameter SPATIAL_REUSE to SR_DELAYED.
39
40
41 An EHT STA that transmits an EHT MU PPDU configured for more than one user shall not set the
42 TXVECTOR parameter SPATIAL_REUSE to SR_DELAYED.
43
44 An EHT STA that transmits an EHT MU PPDU configured for a single user shall not set the TXVECTOR
45
parameter SPATIAL_REUSE to SR_RESTRICTED.
46
47
48 An EHT AP that transmits an EHT MU PPDU that contains a Trigger frame and is configured for more than
49 one user should set the TXVECTOR parameter SPATIAL_REUSE to SR_RESTRICTED.
50
51
An EHT STA that transmits a PPDU that does not contain a Trigger frame shall not set the TXVECTOR
52
53 parameter SPATIAL_REUSE to SR_DELAYED or SR_RESTRICTED.
54
55 35.12.3 Contents of the EHT PHY Capabilities Information field and Supported EHT-MCS
56 And NSS Set field(#4627)
57
58
59 The EHT MAC determines the capabilities of its EHT PHY by using the PLME-GET primitive to read the
60 EHT PHY MIB attributes (see Table 36-69 (EHT PHY MIB attributes(#7281))). The subfields in the EHT
61 PHY Capabilities Information field in the EHT Capabilities element shall be set as follows:
62
63 — Support For 320 MHz In 6 GHz = b2int(dot11EHTSupportFor320MHzImplemented)
64
65

Copyright © 2022 IEEE. All rights reserved. 475

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — Support for 242-tone RU In BW Wider Than 20 MHz =

2 b2int(dot11EHTSupportFor242ToneRUInBWWiderThan20Implemented)
3
4 — NDP With 4 EHT-LTF And 3.2 µs GI =
5 b2int(dot11EHTNDPwith4xEHTLTFand3point2GIImplemented)
6
— Partial Bandwidth UL MU-MIMO = b2int(dot11EHTPartialBWULMUMIMOImplemented)
7
8 — SU Beamformer = b2int(dot11EHTSUBeamformerImplemented)
9
— SU Beamformee = b2int(dot11EHTSUBeamformeeImplemented)
10
11 — Beamformee SS (≤ 80 MHz) = dot11EHTBeamformeeSSLessThanOrEqualTo80 – 1
12
— Beamformee SS (= 160 MHz) = dot11EHTBeamformeeSSEqualTo160 – 1
13
14 — Beamformee SS (= 320 MHz) = dot11EHTBeamformeeSSEqualTo320 – 1
15
— Number Of Sounding Dimensions (≤ 80 MHz) =
16
17 dot11EHTNumberSoundingDimensionsLessThanOrEqualTo80 – 1
18 — Number Of Sounding Dimensions (= 160 MHz) =
19 dot11EHTNumberSoundingDimensionsEqualTo160 – 1
20
21 — Number Of Sounding Dimensions (= 320 MHz) =
22 dot11EHTNumberSoundingDimensionsEqualTo320 – 1
23
24 — Ng = 16 SU Feedback = b2int(dot11EHTNG16SUFeedbackImplemented)
25 — Ng = 16 MU Feedback = b2int(dot11EHTNG16MUFeedbackImplemented)
26
27 — Codebook Size     =  4 2  SU
28 Feedback = b2int(dot11EHTCodebookSizePhi4Psi2SUFeedbackImplemented)
29 — Codebook Size     =  7 5  MU
30
Feedback = b2int(dot11EHTCodebookSizePhi7Psi5MUFeedbackImplemented)
31
32 — Triggered SU Beamforming Feedback =
33 b2int(dot11EHTTriggeredSUBeamformingFeedbackImplemented)
34
35 — Triggered MU Beamforming Partial BW Feedback =
36 b2int(dot11EHTTriggeredMUBeamformingPartialBWFeedbackImplemented)
37 — Triggered CQI Feedback = b2int(dot11EHTTriggeredCQIFeedbackImplemented)
38
39 — Partial Bandwidth DL MU-MIMO = b2int(dot11EHTPartialBWDLMUMIMOImplemented)
40 — EHT PSR-Based SR Support = b2int(dot11EHTPSRBasedSRImplemented)
41
42 — Power Boost Factor Support = b2int(dot11EHTPowerBoostFactorImplemented)
43 — EHT MU PPDU With 4 EHT-LTF And 0.8 µs GI =
44
45 b2int(dot11EHTMUPPDUwith4xEHTLTFand0point8usecGIImplemented)
46 — Max Nc = dot11EHTMaxNc – 1
47
48 — Non-Triggered CQI Feedback = b2int(dot11EHTNonTriggeredCQIFeedbackImplemented)
49 — Tx 1024-QAM And 4096-QAM < 242-tone RU Support =
50 b2int(dot11EHTTx1024QAMand4096QAMLessThan242ToneRUImplemented)
51
52 — Rx 1024-QAM And 4096-QAM < 242-tone RU Support =
53 b2int(dot11EHTRx1024QAMand4096QAMLessThan242ToneRUImplemented)
54
— Maximum Number Of Supported EHT-LTFs = b2int(dot11EHTExtraLTFsImplemented) +
55
56 2  (dot11EHTMaxNumberOfSupportedEHTLTFsForSU – 1) +
57 8  (dot11EHTMaxNumberOfSupportedEHTLTFsForMUandND) – 1)
58 — Support Of MCS 15 = b2int(dot11EHTMCS15For52p26and106p26MRUImplemented) +
59
60 2 × b2int(dot11EHTMCS15For484p242MRUImplemented) +
61 4 × b2int(dot11EHTMCS15For996p484and996p484p242MRUImplemented) +
62 8 × b2int(dot11EHTMCS15For3x996MRUImplemented)
63
— Support Of EHT DUP (MCS 14) In 6 GHz = b2int(dot11EHTDupImplemented)
64
65

476 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — Support For 20 MHz Operating STA Receiving NDP With Wider Bandwidth =
2 b2int(dot11EHT20MHzOperatingSTARxNDPwithWiderBWImplemented)
3
4 — Non-OFDMA UL MU-MIMO (BW ≤ 80 MHz) =
5 b2int(dot11EHTNonOFDMAULMUMIMOLessThanOrEqualto80Implemented)
6
— Non-OFDMA UL MU-MIMO (BW = 160 MHz) =
7
8 b2int(dot11EHTNonOFDMAULMUMIMOEqualto160Implemented)
9 — Non-OFDMA UL MU-MIMO (BW = 320 MHz) =
10 b2int(dot11EHTNonOFDMAULMUMIMOEqualto320Implemented)
11
12 — MU Beamformer (BW ≤ 80 MHz) =
13 b2int(dot11EHTMUBeamformerLessThanOrEqualTo80Implemented)
14
15 — MU Beamformer (BW = 160 MHz) = b2int(dot11EHTMUBeamformerEqualTo160Implemented)
16 — MU Beamformer (BW = 320 MHz) = b2int(dot11EHTMUBeamformerEqualTo320Implemented)
17
18
The function b2int returns 1 if the input is true and 0 if the input is false.
19
20
21 Table 9-401l (Subfield of the EHT PHY Capabilities Information field) defines constraints on certain fields
22 which in turn are constraints on the associated PHY MIB variables.
23
24
The EHT-MCS Map (20 MHz-Only Non-AP STA) field in the Supported EHT-MCS And NSS Set field in
25
26 the EHT Capabilities element, if present, shall be set to
27 dot11EHTSupportedEhtMcsAndNssSet20MhzOnlyStaImplemented.
28
29 The EHT-MCS Map (BW ≤ 80 MHz, Except 20 MHz-Only Non-AP STA) field in the Supported EHT-MCS
30
And NSS Set field in the EHT Capabilities element, if present, shall be set to the first three octets of
31
32 dot11EHTSupportedEhtMcsAndNssSetImplemented. The EHT-MCS Map (BW = 160 MHz) field in the
33 Supported EHT-MCS And NSS Set field in the EHT Capabilities element, if present, shall be set to the
34 second three octets of dot11EHTSupportedEhtMcsAndNssSetImplemented. The EHT-MCS Map (BW =
35 320 MHz) field in the Supported EHT-MCS And NSS Set field in the EHT Capabilities element, if present,
36
shall be set to the third three octets of dot11EHTSupportedEhtMcsAndNssSetImplemented.
37
38
39 35.12.4 CENTER_FREQUENCY_SEGMENT(#4633)
40
41 A 20 MHz operating non-AP EHT STA shall issue a PHY-CONFIG.request primitive with the
42
CENTER_FREQUENCY_SEGMENT parameter in the PHYCONFIG_VECTOR set to the center
43
44 frequency of the primary 20 MHz channel except when the 20 MHz operating non-AP EHT STA sets
45 dot11HESubchannelSelectiveTransmissionImplemented equal to true in which case the 20 MHz operating
46 non-AP EHT STA may issue a PHY-CONFIG.request primitive with the
47 CENTER_FREQUENCY_SEGMENT parameter in the PHYCONFIG_VECTOR set to the center
48
frequency of any 20 MHz channel within the BSS bandwidth of 40 MHz, 80 MHz or 160 MHz by following
49
50 the procedure in 26.8.7 (HE subchannel selective transmission). The 20 MHz operating non-AP EHT STA
51 may also issue a PHY-CONFIG.request primitive with the CENTER_FREQUENCY_SEGMENT parameter
52 in the PHYCONFIG_VECTOR set to the center frequency of any 20 MHz channel within the primary
53 160 MHz when the BSS bandwidth is 320 MHz (#6930)by following the procedure in 26.8.7 (HE
54
subchannel selective transmission).
55
56
57 An 80 MHz operating non-AP EHT STA shall issue a PHY-CONFIG.request primitive with the
58 CENTER_FREQUENCY_SEGMENT parameter in the PHYCONFIG_VECTOR set to the center
59 frequency of the primary 80 MHz channel except when the 80 MHz operating non-AP EHT STA sets
60
dot11HESubchannelSelectiveTransmissionImplemented equal to true and parks on an 80 MHz channel
61
62 without preamble puncturing. In this exceptional case, the 80 MHz operating non-AP EHT STA may issue a
63 PHY-CONFIG.request primitive with the CENTER_FREQUENCY_SEGMENT parameter in the
64
65

Copyright © 2022 IEEE. All rights reserved. 477

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 PHYCONFIG_VECTOR set to the center frequency of any 80 MHz channel within the primary 160 MHz of
2 the BSS bandwidth by following the procedure in 26.8.7 (HE subchannel selective transmission).
3
4
5 35.12.5 INACTIVE_SUBCHANNELS(#6686)
6
7 (#3151)(#3120)(#2180)(#1086)(#2541)An EHT STA shall not transmit on any 20 MHz subchannel that is
8 punctured as indicated in the TXVECTOR parameter INACTIVE_SUBCHANNELS (see Table 36-1
9
(TXVECTOR and RXVECTOR parameters)).
10
11
12 (#3151)(#3120)(#2180)(#1086)(#2147)The indication of which subchannels are punctured in a non-HT
13 duplicate PPDU or EHT PPDU is conveyed from the MAC to the PHY through the TXVECTOR parameter
14 INACTIVE_SUBCHANNELS (see Table 36-1 (TXVECTOR and RXVECTOR parameters)). The
15
parameter INACTIVE_SUBCHANNELS may be present in the TXVECTOR of a non-HT duplicate PPDU
16
17 or EHT PPDU.
18
19
20 35.13 Intra-PPDU power save for non-AP EHT STAs(#5034)
21
22 A non-AP EHT STA that operates in intra-PPDU power save mode shall follow the rules defined in
23 26.14.1 (Intra-PPDU power save for non-AP HE STAs) and with the following additions:
24
25 — The conditions that apply to an HE MU PPDU shall also apply to an EHT MU PPDU, and
26 — The conditions that apply to an HE TB PPDU shall also apply to an EHT TB PPDU.
27
28
29 35.14 Nominal packet padding values selection rules
30
31
32 35.14.1 General(#7735)
33
34 An EHT STA with dot11EHTPPEThresholdsRequired set to false may set the PPE Thresholds Present
35
subfield in the EHT Capabilities element that it transmits to 0.
36
37
38 An EHT STA with (#6154)dot11EHTPPEThresholdsRequired set to true shall set the PPE Thresholds
39 Present subfield in the EHT Capabilities element that it transmits to 1.
40
41
35.14.2 PPET not present in both HE and EHT(#7735)
42
43
44 An EHT STA that sets the PPE Thresholds Present subfield to 0 in both the EHT and HE Capabilities
45 elements, and the Common Nominal Packet Padding subfield to 0 in the EHT Capabilities element that it
46 transmits has a nominal packet padding of 0 µs for all constellations, (#7737)NSS and large size RU
47
48 allocations that it supports.
49
50 An EHT STA that sets the PPE Thresholds Present subfield to 0 in both the EHT and HE Capabilities
51 elements, and the Common Nominal Packet Padding subfield to 1 in the EHT Capabilities element that it
52
transmits has a nominal packet padding of 8 µs for all constellations, (#7737)NSS and large size RU
53
54 allocations that it supports.
55
56 An EHT STA that sets the PPE Thresholds Present subfield to 0 in both the EHT and HE Capabilities
57 elements, and the Common Nominal Packet Padding subfield to 2 in the EHT Capabilities element that it
58
59 transmits has a nominal packet padding of 16 µs for all constellations, (#7737)NSS and large size RU
60 allocations that it supports.
61
62 An EHT STA that sets the PPE Thresholds Present subfield to 0 in both the EHT and HE Capabilities
63
64 elements, and the Common Nominal Packet Padding subfield to 3 in the EHT Capabilities element that it
65 transmits has a nominal packet padding of 16 µs for all modes with constellation order up to 1024-QAM,

478 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 N SS less than or equal to 8, and large size RU or MRU size less than or equal to 2996, and a nominal packet
2
3 padding of 20 µs for all the other modes with a large size RU or MRU that the STA supports.
4
5 An EHT STA that sets the PPE Thresholds Present subfield to 0 in both the EHT and HE Capabilities
6 elements has a nominal packet padding of 0 µs for a small size RU or MRU (#6812)(see 36.3.2.2
7 (Subcarriers and resource allocation for multiple RUs)), if 4096-QAM is not used for the RU or MRU; or if
8
9 the RU size is 106 or the MRU size is 106+26 and EHT-MCS 15 is not applied to them. An EHT STA that
10 sets the PPE Thresholds Present subfield to 0 in both the EHT and HE Capabilities elements has a nominal
11 packet padding value indicated by the Common Nominal Packet Padding subfield in the EHT Capabilities
12 element for a small size RU or MRU, if 4096-QAM is used for the RU or MRU, or if the RU size is 106 or
13 the MRU size is 106+26 and EHT-MCS 15 is applied to the RU or MRU. (#7738)For example, in the case of
14
15 the Common Nominal Packet Padding subfield set to 3, the nominal packet padding of 20 µs is used for the
16 small size RU/MRU modulated with 4096-QAM, and the nominal packet padding of 16 µs is used if the RU
17 size is 106 or the MRU size is 106+26 and EHT-MCS 15 is applied to the RU or MRU.
18
19 The rule to select the EHT nominal packet padding value, in the case of the PPE Thresholds Present subfield
20
21 set to 0 in both the EHT and HE Capabilities elements, is described in Table 35-3 (EHT nominal packet
22 padding indication when the PPE Thresholds Present subfield is set to 0 in both the EHT and HE
23 Capabilities elements(#7942)).
24
25
26 Table 35-3—EHT nominal packet padding indication when the PPE Thresholds Present sub-
27
28 field is set to 0 in both the EHT and HE Capabilities elements(#7942)
29
30
RU/MRU size 106-tone RU and RU/MRU size
31 EHT-MCS
< 106 tones 106+26-tone MRU ≥ 242 tones
32
33 0–11 0 µs 0 µs EHT common nominal
34 packet padding value
35
36 12 and 13 EHT common nominal EHT common nominal EHT common nominal
37 packet padding value packet padding value packet padding value
38
39 14 — — EHT common nominal
40 packet padding value
41 15 0 µs EHT common nominal EHT common nominal
42 packet padding value packet padding value
43
44 NOTE—EHT common nominal packet padding value is the value conveyed by the Common
45 Nominal Packet Padding subfield in the EHT PHY Capabilities Information field in the EHT
46 Capabilities element.
47
48
49
50 35.14.3 PPET not present in EHT but present in HE(#7735)
51
52 An EHT STA that sets the PPE Thresholds Present subfield to 0 in the EHT Capabilities element, and sets it
53 to 1 in the HE Capabilities element that it transmits, indicates that the nominal packet padding requirement
54
55 for an EHT transmission of NSSn, RUb and constellation index less than 6, is the same as for the
56 corresponding HE transmission if the modes are covered in the PPE Thresholds field in the HE Capabilities
57 element. These modes consist of N SS indicated by the NSTS subfield (0 to the NSTS indicated in the NSTS
58
59
subfield) and the RU sizes indicated by the RU Index Bitmask subfield ([242, 484, 996, 2996]) in the HE
60 Capabilities element, including the modes with an RU corresponding to 0 in the RU Index Bitmask subfield
61 in the HE Capabilities element. The nominal packet padding for EHT-MCS 14 or 15 for a large size RU of
62 size 2996 or smaller is the same as that for HE-MCS 0 with DCM = 1 for the same RU size. The nominal
63 packet padding is 0 µs for a small size RU or MRU, except for the following cases: 4096-QAM is used for
64
65
the RU or MRU, or EHT-MCS 15 is used for an RU of size 106 or MRU of size 106+26. The nominal packet

Copyright © 2022 IEEE. All rights reserved. 479

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 padding for EHT-MCS 15 for an RU of size 106 or MRU of size 106+26 is the same as that of HE-MCS 0
2 with DCM = 1 for RU size 106. The nominal packet padding for the following modes shall follow the rules
3
indicated by the Common Nominal Packet Padding subfield in the EHT Capabilities element:
4
5 — For all modes with N SS greater than (NSTS + 1), the corresponding nominal packet padding shall
6 follow the rules indicated by the Common Nominal Packet Padding subfield.
7
8 — For all modes with RU size greater than 2996, the corresponding nominal packet padding shall
9 follow the rules indicated by the Common Nominal Packet Padding subfield.
10 — For all modes with 4096-QAM, the corresponding nominal packet padding shall follow the rules
11
12 indicated by the Common Nominal Packet Padding subfield.
13
14 The nominal packet padding values for 484+242-tone MRU are the same as for 996-tone RU derived above,
15 and the nominal packet padding values for 996+484-tone MRU and 996+484+242-tone MRU are the same
16 as for 2996-tone RU derived above(#4977), in the case of the PPE Thresholds Present subfield set to 0 in
17
18 the EHT Capabilities element and 1 in the HE Capabilities element. The nominal packet padding indicated
19 by the Common Nominal Packet Padding subfield in the EHT Capabilities element shall be greater than or
20 equal to the largest nominal packet padding values among all the modes indicated in the PPE Thresholds
21 field in the HE Capabilities element.
22
23
24 The inheritance rule to select the EHT nominal packet padding value for N SS  NSTS + 1 and RU/MRU ≤
25 2996, in the case of the PPE Thresholds Present subfield set to 0 in the EHT Capabilities element and 1 in
26 the HE Capabilities element, is described in Table 35-4 (EHT nominal packet padding indication for NSS ≤
27
28
NSTS+1 when the PPE Thresholds Present subfield is set to 0 in the EHT Capabilities element and 1 in the
29 HE Capabilities element(#7942)).
30
31
32 Table 35-4—EHT nominal packet padding indication for NSS ≤ NSTS+1 when the PPE
33 Thresholds Present subfield is set to 0 in the EHT Capabilities element and 1 in the HE
34
35
Capabilities element(#7942)
36
37 242 tones
38 RU/MRU size 106-tone RU and RU/MRU size
EHT-MCS ≤ RU/MRU size
39 < 106 tones 106+26-tone MRU > 2996 tones
≤ 2996 tones
40
41 0–11 0 µs (see NOTE 1) 0 µs (see NOTE 1) HE nominal packet EHT nominal packet
42 padding value padding value
43
44 12 and 13 EHT nominal packet EHT nominal packet EHT nominal packet EHT nominal packet
45 padding value padding value padding value padding value
46 14 — — HE nominal packet EHT nominal packet
47 padding value for padding value
48 HE-MCS 0 + DCM (see NOTE 4)
49 (see NOTE 4)
50
51 15 0 µs (see NOTE 1) HE nominal packet HE nominal packet EHT nominal packet
52 padding value for padding value for padding value
53 HE-MCS 0 + DCM HE-MCS 0 + DCM
54
55 NOTE 1—The nominal packet padding value conveyed by the PPE Thresholds field in the HE Capabilities
56 element is 0 µs in these cases.
57
58 NOTE 2—HE nominal packet padding value is the value conveyed by the PPE Thresholds field in the HE
59 Capabilities element.
60
61 NOTE 3—EHT common nominal packet padding value is the value conveyed by the Common Nominal Packet
62 Padding subfield in the EHT PHY Capabilities Information field in the EHT Capabilities element.
63
64 NOTE 4—MCS 14 only applies to RU size of the 996, 2996, and 4996.
65

480 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 35.14.4 PPE threshold present in EHT(#7735)

2
3
An EHT STA that sets the PPE Thresholds Present subfield to 1 in the EHT Capabilities element that it
4
5 transmits shall indicate its nominal packet padding per constellation, NSS and RU allocation by setting the
6 subfields of the EHT PPE Thresholds field according to (#7943)9.4.2.313.5 (EHT PPE Thresholds field) and
7 using the corresponding values from dot11EHTPPEThresholdsMappingsTable. The nominal packet padding
8 values for an EHT STA that sets the PPE Thresholds Present subfield to 1 in the EHT Capabilities element
9
that it transmits are only determined by the EHT PPE Thresholds field.
10
11
12 (#7736)After receiving the EHT PPE Thresholds field from a second STA, the first STA uses the
13 combination of the PPETmax NSSn RUb subfield and PPET8 NSSn RUb subfield values to determine the
14 nominal packet padding for EHT PPDUs that are transmitted to the second STA using NSS = n and an RU
15
allocation corresponding to RU allocation index b, for each value of NSS and RU specified by the field. The
16
17 nominal packet padding is used in computing the PE field duration (see 36.3.14 (Packet extension)).
18 NOTE—If the pre-FEC padding factor is 4, then the value of nominal T PE is equal to the nominal packet padding (see
19 Table 36-61 (Nominal TPE values)).
20
21
22 The nominal packet padding as a function of the PPE thresholds, the number of spatial streams and the RU
23 allocation index is described in Table 35-5 (PPE thresholds per PPET8 and PPETmax(#7736)).
24
25
26 Table 35-5—PPE thresholds per PPET8 and PPETmax(#7736)
27
28
29 Result of comparison of the Result of comparison of the
30 Nominal packet padding for an
constellation index c of an EHT constellation index c of an EHT
31 EHT PPDU transmitted to this
PPDU with NSS value n and RU PPDU with NSS value n and RU
32 STA using the constellation index
allocation size that corresponds to allocation size that corresponds to
33 = c, NSS = n and RU allocation
the RU allocation index = (b + the RU allocation index = value (b
34 size that corresponds to the RU
DCM) to the PPET8 NSSn RU(b + + DCM) to the PPETmax NSSn
35 allocation index = (b + DCM)
DCM) value RU(b + DCM) value
36
37 c greater than or equal to PPET8 c less than PPETmax or PPETmax 8 µs
38 equal to None
39
40 c greater than PPET8 or PPET8 c greater than or equal to PPETmax 16 µs if c ≤ 5 and (b + DCM) ≤ 3
41 equal to None and n ≤ 8
42 20 µs if c = 6, or (b + DCM) = 4 or n
43 >8
44
45 All other cases with PPET8 and PPETmax values defined 0 µs
46
47 NOTE 1—DCM = 1 if b is less than 3 and EHT-MCS 14 or EHT-MCS 15 is used; DCM = 0 otherwise.
48
49 NOTE 2—If there exists one or more 0s before the first 1 in the bitmask sequence in the RU Index Bitmask subfield,
50 the nominal packet padding is 0 µs for each RU allocation index corresponding to these 0s.
51
52 NOTE 3—(#7736)If there exists one or more 0s after the first 1 in the bitmask sequence in the RU Index Bitmask
53 subfield, the PPETmax and PPET8 values for each RU allocation index corresponding to these 0s shall be the same
54 as the PPETmax and PPET8 values for the closest smaller RU allocation index with the bitmask value equal to 1 in
55 the RU Index Bitmask subfield.
56
57 NOTE 4—(#7736)The nominal packet padding value is 16 µs for all supported RU/MRU sizes and constellations if
58 the number of spatial streams of the EHT PPDU transmission is greater than (NSS_PE + 1) and less than or equal to
59 8, where NSS_PE is the value in the NSS_PE subfield.
60
61
62
63 In Table 35-5 (PPE thresholds per PPET8 and PPETmax(#7736)), “RU Allocation index = (b + DCM)”
64 means the following. With the exception of an RU or MRU indicated by the RU allocation index equal to 3
65

Copyright © 2022 IEEE. All rights reserved. 481

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 or 4, if EHT-MCS 14 or EHT-MCS 15 is applied in a given RU, the nominal packet padding value is based
2 on the next larger RU allocation index (RU allocation index + 1). For example, if EHT-MCS 15 is applied to
3
a 242-tone RU then the nominal packet padding value for a 484-tone RU is used. If EHT-MCS 15 is applied
4
5 to a 106-tone RU or a 106+26-tone MRU then the nominal packet padding value for a 242-tone RU is used.
6 (#7734)If EHT-MCS 15 is applied to an RU or MRU indicated by the RU allocation index equal to 3 or 4,
7 then the nominal packet padding value for the same RU or MRU is used. If EHT-MCS 14 is applied, the RU
8 allocation indices (b + DCM) for the 80 MHz, 160 MHz, and 320 MHz PPDUs are equal to 3, 3, and 4,
9
respectively.
10
11
12 (#7736)The PPETmax and PPET8 subfields for RU allocation index k are present in the PPE Thresholds
13 Info field only if bit k of the RU Index Bitmask subfield (bit 4 + k of the EHT PPE Thresholds field) is 1.
14 When there exists one or more 0s before the first 1 in the bitmask sequence in the RU Index Bitmask
15
subfield, the PPETmax and PPET8 subfields for each RU allocation index corresponding to these 0s are not
16
17 present, and the nominal packet padding value is 0 µs for these RUs/MRUs. For example, if the bitmask
18 sequence of RU Index Bitmask subfield is [0 0 1 1 1], the nominal packet padding value is 0 µs for the 242-
19 tone RU and 484-tone RU.
20
21
(#7736)When there exists one or more 0s after the first 1 in the bitmask sequence in the RU Index Bitmask
22
23 subfield, the PPETmax and PPET8 subfields for each RU allocation index corresponding to these 0s are not
24 present, but the PPETmax and PPET8 values are present, and the values shall be the same as the PPETmax
25 and PPET8 values for the closest smaller RU allocation index with the bitmask value equal to 1 in the RU
26 Index Bitmask subfield. For example, if the bitmask sequence of RU Index Bitmask subfield is [1 0 0 1 1],
27
the PPETmax and PPET8 values for 484-tone RU, 484+242-tone MRU, and 996-tone RU are the same as
28
29 for the 242-tone RU.
30
31 (#7736)The PPETmax and PPET8 subfields for an NSS value n are present only if n is less than or equal to
32 (NSS_PE + 1), where NSS_PE is the value in the NSS_PE subfield in the EHT PPE Thresholds field of the
33
EHT Capabilities element. When the number of spatial streams of the EHT PPDU transmission is greater
34
35 than (NSS_PE + 1) and less than or equal to 8, the nominal packet padding value is 16 µs for all supported
36 RU/MRU sizes and constellations.
37
38 An EHT STA that sets the PPE Thresholds Present subfield to 1 in the EHT Capabilities element has a
39
nominal packet padding of 0 µs for a small size RU or MRU, if 4096-QAM is not used for the RU or MRU,
40
41 or if the RU size is 106 or the MRU size is 106+26 and EHT-MCS 15 is not applied to the RU or MRU. An
42 EHT STA that sets the PPE Thresholds Present subfield to 1 in the EHT Capabilities element has a nominal
43 packet padding value the same as the value for the 242-tone RU, if 4096-QAM is used for the RU or MRU,
44 or if the RU size is 106 or the MRU size is 106+26 and EHT-MCS 15 is applied to the RU or MRU.
45
46
47 35.14.5 STA behavior related to nominal packet padding(#7735)
48
49 A STA transmitting an (#7944)EHT MU PPDU provides the nominal packet padding in the TXVECTOR
50 parameter NOMINAL_PACKET_PADDING for the minimal PE calculation (see 36.3.14 (Packet
51
extension)).
52
53
54 The nominal packet padding value for a (#6147)broadcast RU/MRU contained in an EHT PPDU that a STA
55 transmits shall be set to 20 µs if the RU/MRU is modulated with 4096-QAM, or the RU/MRU is greater than
56 2996, or more than eight spatial streams are transmitted on the RU/MRU, and shall be set to 16 µs for all
57
other modes. A STA transmitting an EHT PPDU that carries a broadcast frame shall not set the value of the
58
59 TXVECTOR parameter NOMINAL_PACKET_PADDING to a value that is less than that required for any
60 of the recipients and the (#6147)broadcast RU/MRU. A STA transmitting an EHT PPDU that carries a group
61 addressed, but not broadcast, frame shall not set the value of the TXVECTOR parameter
62 NOMINAL_PACKET_PADDING to a value that is less than that required for any of the recipients in the
63
group.
64
65

482 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#7946)If a STA A is transmitting an EHT MU PPDU to a STA B, where the STA A has not received a
2 frame including the EHT Capabilities element from the STA B, then the STA A shall set the value of the
3
TXVECTOR parameter NOMINAL_PACKET_PADDING to:
4
5 — 20 µs if the RU/MRU is modulated with 4096-QAM, the RU/MRU size is greater than 2996-tone,
6 or the RU/MRU uses more than eight spatial streams.
7
8 — 16 µs otherwise.
9 (#7946)NOTE—One such situation is an AP transmitting to a nonassociated STA. Another such situation is a
10 nonassociated STA transmitting to an AP without having received a management frame including an EHT Capabilities
11 element from the AP, such as a Beacon or Probe Response frame.
12
13
14 A STA transmitting an (#7944)EHT MU PPDU to a receiving STA shall include post-FEC padding
15 determined by the pre-FEC padding factor (see 36.3.13 (Data field)) and after including the post-FEC
16 padding, the transmitting STA shall include a packet extension with (#7945)a duration computed based on
17 the TXVECTOR parameter NOMINAL_PACKET_PADDING (see 36.3.14 (Packet extension)).
18
19
20 35.15 PPDU format, BW, MCS, NSS, and DCM selection rules(#1752)
21
22
23 35.15.1 General
24
25 An EHT STA can transmit different PPDU formats, with different transmit parameters, such as channel
26 width, MCS, NSS, and DCM. This subclause defines the rules followed by an EHT STA for selecting these
27
28 parameters depending on the capabilities of the intended receiver(s) and other considerations.
29
30 35.15.2 PPDU format selection
31
32 An EHT STA shall send Control frames following the rules defined in 10.6.6 (Rate selection for Control
33
34 frames) and 26.15.2 (PPDU format selection) with the following additional exception:
35 — An EHT STA may transmit a BlockAck frame in an HE SU PPDU or (#2756)(#2838)in an EHT MU
36 PPDU directed to a single (#1752)EHT STA if the PPDU duration of the HE SU PPDU or EHT MU
37
PPDU (respectively) is less than the PPDU duration of a non-HT PPDU containing the Control
38
39 frame sent at the primary rate (see 10.6.6.5.2 (Selection of a rate or MCS)).
40
41
42 35.16 EHT BSS operation
43
44 35.16.1 Basic EHT BSS operation(#7913)
45
46
47 (#6645)If the peer AP is operating as an EMA AP, an EHT non-AP STA should follow the procedure
48 described in 11.1.3.8.3 (Discovery of a nontransmitted BSSID profile) for efficient discovery during
49 scanning and to save power after association.
50
51 An EHT AP shall not assign an AID value of 2007 to any STA.
52
53
54 (#2852)(#4167)An EHT AP may announce (#7861)a BSS operating channel width that is different from the
55 BSS operating channel width that it announces to non-AP EHT STAs if the EHT BSS operating channel
56 width includes at least one punctured 20 MHz subchannel and/or if the announced EHT BSS operating
57 channel width is not supported by an HE BSS.
58
59
60 (#4167)An EHT AP shall announce the BSS operating channel width in the HE Operation element with the
61 following restriction:
62
— The announced BSS operating channel width in the HE Operation element is the (#7364)maximum
63
64 width (#5111)including the primary channel without covering any punctured 20 MHz subchannels
65

Copyright © 2022 IEEE. All rights reserved. 483

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#4169)indicated in the Disabled Subchannel Bitmap field in the EHT Operation element as defined
2 in 35.16.2 (Preamble puncturing operation(#1086)(#1667)(#2148)(#2147)).
3
4
5 The announced BSS operating channel width in HE Operation element is no more than the BSS operating
6 channel width in the EHT Operation element (#4168)and the corresponding BSS shall not operate as an
7 80+80 MHz BSS.
8
9
(#7443)An EHT AP shall have dot11BeaconProtectionEnabled set to 1.
10
11
12 (#6630)The Beacon frames generated within an EHT BSS contain an EHT Operation element.
13
14 (#6630)An EHT STA has dot11EHTOptionImplemented equal to true.
15
16
17 (#6630)In the 2.4 GHz band, an EHT STA shall not transmit an EHT PPDU to a recipient EHT STA that
18 carries a frame that is not an EHT Compressed Beamforming/CQI frame (see 35.7.3 (Rules for EHT
19 sounding protocol sequences)) and that exceeds the maximum MPDU length capability indicated in the EHT
20 Capabilities element last received from the recipient EHT STA.
21
22
23 (#6630)In the 5 GHz band, an EHT STA shall not transmit an EHT PPDU to a recipient EHT STA that
24 carries a frame that is not an EHT Compressed Beamforming/CQI frame (see 35.7.3 (Rules for EHT
25 sounding protocol sequences)) and that exceeds the maximum MPDU length capability indicated in the
26 VHT Capabilities element last received from the recipient STA.
27
28
29 (#6630)In the 6 GHz band, an EHT STA shall not transmit an EHT PPDU to a recipient EHT STA that
30 carries a frame that is not an EHT Compressed Beamforming/CQI frame (see 35.7.3 (Rules for EHT
31 sounding protocol sequences)) and that exceeds the maximum MPDU length capability indicated in the HE
32 6 GHz Band Capabilities element last received from the recipient EHT STA.
33
34
35 (#6630)In the 2.4 GHz band, an EHT STA shall not transmit an HE PPDU to a recipient EHT STA that
36 carries a frame that is not an HE Compressed Beamforming/CQI frame (see 26.7.3 (Rules for HE sounding
37 protocol sequences)) and that exceeds the maximum MPDU length capability indicated in the EHT
38 Capabilities element last received from the recipient EHT STA.
39
40
41 (#4509)An EHT STA shall set the Supported Channel Width Set subfield in the HT Capabilities element,
42 Supported Channel Width Set and the Extended NSS BW Support subfields in the VHT Capabilities
43 element, Supported Channel Width Set subfield in the HE Capabilities element, and the Support For
44 320 MHz in 6 GHz subfield in the EHT Capabilities element it transmits as shown in Table 35-6 (Indication
45
of supported channel widths by an EHT STA(#6930)(#4509)) to include the channel widths it is capable of
46
47 supporting.
48
49
50 Table 35-6—Indication of supported channel widths by an EHT STA(#6930)(#4509)
51
52
53 Supported
54 Channel Width Support For
Supported Supported
55 Maximum Set and Extended 320 MHz in
Channel Width Channel Width
56 Operating supported NSS BW Support 6 GHz subfield in
Set subfield in the Set subfield in the
57 band channel subfields in the the EHT
HT Capabilities HE Capabilities Capabilities
58 width VHT Capabilities
element element element
59 element (see
60 Table 9-311)
61
62 2.4 GHz 20 MHz 0 N/A Set B0 to 0 0
63 2.4 GHz 40 MHz 1 N/A Set B0 to 1 0
64
65

484 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 35-6—Indication of supported channel widths by an EHT STA(#6930)(#4509) (contin-

2
3
4 Supported
5 Channel Width Support For
Supported Supported
6 Maximum Set and Extended 320 MHz in
Channel Width Channel Width
7 Operating supported NSS BW Support 6 GHz subfield in
Set subfield in the Set subfield in the the EHT
8 band channel subfields in the
HT Capabilities HE Capabilities Capabilities
9 width VHT Capabilities
element element element
10 element (see
11 Table 9-311)
12
13 5 GHz 20 MHz 0 Set to indicate Set B1 to 0, 0
14 (See NOTE) support for up to B2 to 0, B3 to 0
15 80 MHz
16 5 GHz 80 MHz 1 Set to indicate Set B1 to 1, 0
17 support for up to B2 to 0, B3 to 0
18 80 MHz
19
20 5 GHz 160 MHz 1 Set to indicate Set B1 to 1, 0
21 support for up to B2 to 1
22 160 or
23 80+80 MHz
24
25 6 GHz 20 MHz N/A N/A Set B1 to 1, 0
26 (See NOTE) B2 to 0, B3 to 0
27 6 GHz 80 MHz N/A N/A Set B1 to 1, 0
28 B2 to 0, B3 to 0
29
30 6 GHz 160 MHz N/A N/A Set B1 to 1, 0
31 B2 to 1
32
33 6 GHz 320 MHz N/A N/A Set B1 to 1, 1
34 B2 to 1
35 NOTE—This corresponds to the 20 MHz only non-AP EHT STA. An EHT AP does not use this setting.
36
37
38
39 35.16.2 Preamble puncturing operation(#1086)(#1667)(#2148)(#2147)
40
41 An EHT AP may add the Disabled Subchannel Bitmap field in the EHT Operation element it includes in
42
43
transmitted Management frames. The AP shall set the Disabled Subchannel Bitmap Present subfield to 1 and
44 include the Disabled Subchannel Bitmap field in the EHT Operation element if the AP punctures any
45 subchannel for the BSS. Otherwise, the AP shall set the Disabled Subchannel Bitmap Present subfield to 0
46 and not include the Disabled Subchannel Bitmap field in the EHT Operation element. The puncturing
47 pattern indicated in the Disabled Subchannel Bitmap field of the EHT Operation element shall be one of the
48
49
non-OFDMA puncturing patterns defined in Table 36-30 (Definition of the Punctured Channel Information
50 field in the U-SIG for an EHT MU PPDU using non-OFDMA transmissions(#8011)(#2402)) for the PPDU
51 bandwidth that is equal to the operating channel width of the BSS. The AP may set each bit in the Disabled
52 Subchannel Bitmap field to a value subject to the following constraints:
53
54 — The resulting puncturing pattern is one of the puncturing patterns selected above.
55 — A bit in the bitmap that corresponds to a 20 MHz subchannel outside the BSS bandwidth shall be set
56 to 1.
57
58 — The bit in the bitmap that corresponds to the primary 20 MHz subchannel shall be set to 0.
59
60 In an EHT BSS set up by an EHT AP that has included the Disabled Subchannel Bitmap field in the EHT
61 Operation element, an EHT STA shall set the TXVECTOR parameter INACTIVE_SUBCHANNELS of an
62
63 HE, EHT, or non-HT duplicate PPDU based on the value indicated in the most recently exchanged Disabled
64 Subchannel Bitmap field in the EHT Operation element for that BSS. If a 20 MHz subchannel is indicated as
65

Copyright © 2022 IEEE. All rights reserved. 485

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 a punctured subchannel in the Disabled Subchannel Bitmap field in the EHT Operation element, the
2 corresponding bit in the TXVECTOR parameter INACTIVE_SUBCHANNELS shall be set to 1 and the
3
punctured 20 MHz subchannel shall not be used by any PPDU that is transmitted within the operating
4
5 channel of the EHT AP to a member of the EHT BSS.
6
7 In an EHT MU PPDU or a non-HT duplicate PPDU, an EHT STA may puncture other subchannels in
8 addition to those indicated in the Disabled Subchannel Bitmap field in the EHT Operation element. In this
9
case, the EHT STA shall assign an RU or MRU within the nonpunctured subchannel set to a responding
10
11 EHT STA if the EHT STA uses a triggering frame to solicit a response in a TB PPDU from the responding
12 EHT STA.
13
14 NOTE—Since the parameter INACTIVE_SUBCHANNELS is not present in the RXVECTOR as defined in Table 36-1
15 (TXVECTOR and RXVECTOR parameters), a responding EHT STA cannot learn the additionally punctured
16 subchannels.
17
18 Regardless if the EHT AP has included the Disabled Subchannel Bitmap field in the EHT Operation
19 element, an EHT STA may use EHT MU PPDU preamble puncturing modes as defined in 36.3.12.11 (EHT
20 preamble of preamble punctured EHT MU PPDU(#1952)) or EHT TB PPDU in which not all the 20 MHz
21
subchannels are assigned.
22
23
24
25
35.17 EPCS priority access(#5284)
26
27 35.17.1 General
28
29 (#5284)(#4170)(#1467)EPCS priority access is a mechanism that provides prioritized access to the wireless
30
31 medium for authorized users to increase their probability of successful communication during periods of
32 network congestion.
33
34 (#7523)(#4171)(#1504)(#3038)(#5284)An EPCS AP MLD or an EPCS non-AP MLD is an MLD that has a
35 value of true for dot11EHTEPCSPriorityAccessActivated. A STA affiliated with an EPCS MLD shall set to
36
37 1 the EPCS Priority Access Supported subfield of the EHT Capabilities element that it transmits.
38 (#7524)(#4170)A STA affiliated with an MLD that is not an EPCS AP MLD or an EPCS non-AP MLD shall
39 set to 0 the EPCS Priority Access Supported subfield of the EHT Capabilities element that it transmits.
40
41 (#2305)(#5284)During the (re)association process, the AP MLD obtains information required to verify the
42
43 authority of the non-AP MLD(#4171) to use EPCS priority access. An AP MLD that has
44 dot11SSPNInterfaceActivated equal to true may use the interworking procedures described in
45 11.22.5 (Interworking procedures: interactions with SSPN) to retrieve permission for a non-AP
46 MLD(#4171) to use the EPCS priority access from an EPCS service provider via the SSPN interface during
47 association by the non-AP MLD(#4171). To support this exchange, an EPCS non-AP MLD(#7533)(#4171)
48
49 shall provide the home realm information of the EPCS provider and necessary authentication parameters as
50 described in 11.22.5 (Interworking procedures: interactions with SSPN). Other methods of obtaining this
51 authorization information are outside the scope of this standard(#5618).
52
53 (#5284)An AP MLD that successfully obtains permission for a (#7358)non-AP MLD to use EPCS priority
54
55 access shall update the (#4172)dot11EPCSPriorityAccessAuthorized for the (#7358)non-AP MLD in the
56 dot11InterworkingEntry. The authorization information included in the dot11InterworkingEntry is passed
57 from the prior AP MLD to the new AP MLD in the same ESS during reassociation as described in
58 11.22.5.3 (Reporting and session control with SSPN).
59
60
61
62
63
64
65

486 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 35.17.2 EPCS priority access operation(#5284)

2
3
35.17.2.1 General(#4173)
4
5
6 (#4174)(#5284)EPCS priority access is established at the MAC by the initiation of the SME. (#5856)The
7 EPCS priority access between an AP MLD and its associated (#7358)non-AP MLD can be in one of the
8 following two states: enabled state or torn down state. The protocols to (#4174)(#5856)enable and tear down
9
EPCS priority access are described in this subclause.
10
11
12 (#4175)(#1472)(#1505)(#5284)A non-AP STA affiliated with (#7358)a non-AP MLD shall not send EPCS
13 Priority Access Enable Request and EPCS Priority Access Teardown frames to an AP affiliated with the
14 associated AP MLD unless RSNA with management frame protection (see 12.2.7 (Requirements for
15
management frame protection) and 12.6 (RSNA security association management)) has been successfully
16
17 negotiated and are capable of invoking EPCS priority access.
18
19 (#4175)(#5284)An AP affiliated with an AP MLD shall not send EPCS Priority Access Request and EPCS
20 Priority Access Teardown frames to a non-AP STA affiliated with the associated (#7358)non-AP MLD
21
unless RSNA with management frame protection (see 12.2.7 (Requirements for management frame
22
23 protection) and 12.6 (RSNA security association management)) has been successfully negotiated and are
24 capable of invoking EPCS priority access.
25
26 35.17.2.2 Setup procedures for EPCS priority access(#5284)
27
28
29 35.17.2.2.1 General
30
31 (#5861)(#5284)EPCS priority access shall be in a torn down state upon the completion of successful multi-
32 link setup procedure (i.e., when non-AP MLD associates with an AP MLD)(#7358).
33
34
35 (#1127)The procedures for enabling and tearing down the (#5284)EPCS priority access are described
36 (#4173)in the following subclauses. The procedure for enabling (#5284)EPCS priority access is illustrated
37 in Figure 35-33 (Enabling EPCS priority access(#5284)(#5856)(#4436)(#1127)(#7358)).
38
39
40 Originator Recipient
41
42
MLD SME MLD MAC MLD MAC MLD SME
43
44
45
46
47 MLME-
EPCSPRIACCESSENABLE.request
48
49
EPCS Priority Access Enable Request
50 frame
51 MLME-
52 EPCSPRIACCESSENABLE.indication
53
54 MLME-
55 EPCSPRIACCESSENABLE.response
EPCS Priority Access Enable Response
56 frame
57 MLME-
58 EPCSPRIACCESSENABLE.confirm
59
60
61
62 Figure 35-33—Enabling EPCS priority access(#5284)(#5856)(#4436)(#1127)(#7358)
63
64
65

Copyright © 2022 IEEE. All rights reserved. 487

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#5284)(#4436)As illustrated in Figure 35-33 (Enabling EPCS priority

2 access(#5284)(#5856)(#4436)(#1127)(#7358)), (#7358)an MLD supporting EPCS priority access capability
3
invokes EPCS priority access on demand when instructed to do so by a higher layer function. After
4
5 successful invocation of EPCS priority access, both the originator and the responder apply the priority
6 access treatment to EPCS traffic. The AP MLD and non-AP MLD may send a request on any enabled link
7 between them and, if authorized, EPCS priority access treatment will be applied on all enabled links
8 between the MLDs.
9
10
11 35.17.2.2.2 Procedures at the originating non-AP MLD(#4173)
12
13 (#5284)When instructed to do so by a higher layer function and upon receipt of an
14 MLME-EPCSPRIACCESSENABLE.request primitive, (#7533)an EPCS (#7358)non-AP MLD with EPCS
15
priority access (#5856)in the torn down state shall follow the procedure below to request a change for the
16
17 EPCS priority access state to enabled.
18 a) (#4437)(#1119)(#1488)(#1472)(#5284)A non-AP STA that is operating on an enabled link and is
19 affiliated with the initiating (#7358)non-AP MLD shall transmit an EPCS Priority Access Enable
20
21 Request frame (9.6.35.5 (EPCS Priority Access Enable Request frame
22 format(#5284)(#1119)(#1488))) to the corresponding AP affiliated with the associated
23 (#7541)EPCS AP MLD.
24
(#4438)(#5284)The destination of the EPCS Priority Access Enable Request frame is the MAC
25
26 address of the AP with which the initiating non-AP EHT STA is associated or the MAC address of
27 the AP that is affiliated with the AP MLD with which the initiating non-AP MLD is associated and
28 that is operating on the same link on which the EPCS Priority Access Enable Request frame is trans-
29 mitted.
30
31 b) (#4439)(#1119)(#1488)(#5284)If a non-AP STA affiliated with the initiating (#7358)non-AP MLD
32 receives an EPCS Priority Access Enable Response frame (9.6.35.6 (EPCS Priority Access Enable
33 Response frame format(#5284)(#1119)(#1488))) with a matching dialog token and a value of
34 SUCCESS in the Status Code field, then the initiating (#7358)non-AP MLD shall issue an MLME-
35
36 EPCSPRIACCESSENABLE.confirm primitive with a value of SUCCESS in the Status Code field
37 indicating (#5856)that EPCS priority access is in an enabled state. The initiating (#7358)non-AP
38 MLD shall enable EPCS priority access so that subsequently transmitted traffic receives EPCS
39 priority access treatment using the procedure defined in 35.17.3 (EPCS priority access
40 procedure(#5284)).
41
42 c) (#4440)(#1119)(#1488)(#1708)(#5284)If a non-AP STA affiliated with the initiating (#7358)non-
43 AP MLD receives an EPCS Priority Access Enable Response frame (9.6.35.6 (EPCS Priority
44 Access Enable Response frame format(#5284)(#1119)(#1488))) with a matching dialog token and a
45
value not equal to SUCCESS in the Status Code field, then the initiating (#7358)non-AP MLD shall
46
47 issue an MLME-EPCSPRIACCESSENABLE.confirm primitive with the status code from the
48 response frame indicating the failure to (#5856)change EPCS priority access to an enabled state.
49 (#4441)In this case, the initiating (#7358)non-AP MLD shall not apply the EPCS priority access
50 procedure. The higher layer function that triggers the EPCS priority access is responsible for
51
managing reattempts after receiving responses with a value other than SUCCESS.
52
53
54 (#5284)When instructed to do so by a higher layer function and upon receipt of an
55 MLME-EPCSPRIACCESSTEARDOWN.request primitive, (#7533)an EPCS (#7358)non-AP MLD with
56 EPCS priority access (#5856)in an enabled state shall use the following procedure for changing the EPCS
57
priority access to a torn down state.
58
59 (#5284)(#5227)NOTE—A non-AP MLD can initiate the teardown procedure regardless of whether the AP MLD or the
60 non-AP MLD initiated the process to enable EPCS priority access.
61
62
a) (#4442)(#1127)(#5284)A non-AP STA affiliated with the tearing down (#7358)non-AP MLD shall
63
64 transmit an EPCS Priority Access Teardown frame (9.6.35.7 (EPCS Priority Access Teardown
65 frame details(#5284)(#1127)))(#5863) to an AP affiliated with the associated (#7541)EPCS AP

488 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 MLD. (#4438)The destination of the EPCS Priority Access Teardown frame is the MAC address of
2 the AP with which the tearing down non-AP EHT STA is associated or the MAC address of the AP
3
that is affiliated with the AP MLD with which the tearing down non-AP MLD is associated and that
4
5 is operating on the same link on which the EPCS Priority Access Teardown Request frame is
6 transmitted. (#5856)The tearing down (#7358)non-AP MLD shall change the EPCS priority access
7 to the torn down state so that subsequently transmitted traffic does not receive EPCS priority access
8 treatment.
9
10
11 35.17.2.2.3 Procedures at the originating AP MLD(#4173)(#1706)
12
13 (#5620)(#5862)(#5284)When instructed to do so by a higher layer function triggered via an external
14 interface, and upon receipt of an MLME-EPCSPRIACCESSENABLE.request primitive, an AP MLD that
15
supports this functionality (#5864)(#5856)shall follow the procedure below to request the change of the
16
17 EPCS priority access for an associated (#7358)non-AP MLD to the enabled state.
18 NOTE 1—The definition of the external interface is out of the scope of this standard.
19
20
21 a) (#5865)(#5284)An AP MLD with dot11SSPNInterfaceActivated equal to true shall verify if the
22 (#4172)dot11EPCSPriorityAccessAuthorized for the (#7358)non-AP MLD in the
23 dot11InterworkingEntry is set to true.
24
25 (#5284)(#5865)NOTE 2—Successful verification is defined when the
26 (#4172)dot11EPCSPriorityAccessAuthorized for the (#7358)non-AP MLD in the dot11InterworkingEntry is set
27 to true. The verification by an AP MLD with dot11SSPNInterfaceActivated equal to false is out of scope of this
28 standard.
29
30 b) (#5865)(#1119)(#1488)(#1472)(#5284)If the verification is successful (see NOTE 2 above),
31 (#4443)an AP that is operating on an enabled link and is affiliated with the initiating AP MLD shall
32
transmit an EPCS Priority Access Enable Request frame (9.6.35.5 (EPCS Priority Access Enable
33
34 Request frame format(#5284)(#1119)(#1488))) to the corresponding non-AP STA affiliated with an
35 associated (#7358)(#7533)EPCS non-AP MLD, with EPCS priority access in the torn down state for
36 that (#7358)non-AP MLD. The destination of the EPCS Priority Access Enable Request frame is
37 (#4444)the non-AP EHT STA indicated by the value of the PeerSTAAddress parameter in the
38
MLME-EPCSPRIACCESSENABLE.request primitive or the MAC address of the non-AP STA that
39
40 is operating on the same link on which the EPCS Priority Access Enable Request frame is
41 transmitted and is affiliated with the non-AP MLD whose MAC address value is indicated by the
42 value of the PeerSTAAddress parameter in the MLME-EPCSPRIACCESSENABLE.request
43 primitive.
44
45 c) (#4445)(#1119)(#1488)(#5284)If an AP affiliated with the initiating AP MLD receives an EPCS
46 Priority Access Enable Response frame (9.6.35.6 (EPCS Priority Access Enable Response frame
47 format(#5284)(#1119)(#1488))) with a matching dialog token and a value of SUCCESS in the
48 Status Code field, then the initiating AP MLD shall issue an MLME-
49
50 EPCSPRIACCESSENABLE.confirm primitive with a value of SUCCESS in the Status Code field
51 indicating successful (#5856)transition of EPCS priority access to the enabled state. The initiating
52 AP MLD shall (#5856)change EPCS priority access to the enabled state so that subsequently
53 transmitted traffic receives EPCS priority access treatment using the procedure defined in 35.17.3
54 (EPCS priority access procedure(#5284)).
55
56 i) (#5621)The initiating EPCS AP MLD may include the Priority Access Multi-Link
57 element in the EPCS Priority Access Enable request frame to allow the destination EPCS
58 non-AP MLD to employ priority access using the included EDCA parameter set and/or
59
MU EDCA parameter set on the corresponding links.
60
61 d) (#4446)(#1119)(#1488)(#1708)(#5284)If an AP affiliated with the initiating AP MLD receives an
62 EPCS Priority Access Enable Response frame (9.6.35.6 (EPCS Priority Access Enable Response
63 frame format(#5284)(#1119)(#1488))) with a matching dialog token and a value not equal to
64
65 SUCCESS in the Status Code field, then the initiating AP MLD shall issue an MLME-

Copyright © 2022 IEEE. All rights reserved. 489

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 EPCSPRIACCESSENABLE.confirm primitive with the status code from the response frame
2 indicating the failure to (#5856)change EPCS priority access to the enabled state. The initiating AP
3
MLD shall not apply the EPCS priority access procedure. The external interface that triggers the
4
5 EPCS priority access is responsible for managing reattempts after receiving responses with a value
6 other than SUCCESS.
7
8 (#5856)(#5622)(#5284)When triggered via an external interface, and upon receipt of an MLME-
9
EPCSPRIACCESSTEARDOWN.request primitive, (#7541)an EPCS AP MLD shall use the following
10
11 procedure for changing the EPCS priority access state to torn down.
12
13 (#5284)(#5227)NOTE 3—An AP MLD can initiate the teardown procedure regardless of whether the AP MLD or the
14 non-AP MLD initiated the process to enable EPCS priority access.
15
16 (#5284)(#5866)(#4447)(#1127)An AP affiliated with the tearing down AP MLD shall transmit an EPCS
17
18 Priority Access Teardown frame (9.6.35.7 (EPCS Priority Access Teardown frame details(#5284)(#1127)))
19 to a non-AP STA affiliated with an associated (#7358)(#7533)EPCS non-AP MLD. (#4444)The destination
20 of the EPCS Priority Access Teardown frame is the non-AP EHT STA indicated by the value of the
21 PeerSTAAddress parameter in the MLME-EPCSPRIACCESSTEARDOWN.request primitive or the MAC
22 address of the non-AP STA that is operating on the same link on which the EPCS Priority Teardown frame is
23
24 transmitted and is affiliated with the non-AP MLD whose MAC address value indicated by the value of the
25 PeerSTAAddress parameter in the MLME-EPCSPRIACCESSTEARDOWN.request primitive. (#5856)The
26 tearing down AP MLD shall change the EPCS priority access state to torn down(#5626).
27
28 (#5866)NOTE 4—The definition of the external interface is out of scope of this standard.
29
30 35.17.2.2.4 Procedure at the receiving AP MLD(#4173)
31
32 (#1119)(#1488)(#5284)Upon receipt of an EPCS Priority Access Enable Request frame (9.6.35.5 (EPCS
33
34 Priority Access Enable Request frame format(#5284)(#1119)(#1488))), an (#7541)EPCS AP MLD
35 (#5623)shall use the following procedure to enable EPCS priority access for the requesting non-AP MLD.
36 a) (#5284)The receiving AP MLD shall issue an MLME-EPCSPRIACCESSENABLE.indication
37
primitive.
38
39 b) (#5284)Upon receipt of the MLME-EPCSPRIACCESSENABLE.response primitive, the receiving
40 AP MLD shall reply to the initiating (#7358)non-AP MLD with an EPCS Priority Access Enable
41 Response frame (9.6.35.6 (EPCS Priority Access Enable Response frame
42
43 format(#5284)(#1119)(#1488))) using the following procedure:
44 1) (#5867)(#5284)For an AP MLD with dot11SSPNInterfaceActivated equal to true, if the
45 (#4172)dot11EPCSPriorityAccessAuthorized for the requesting (#7358)non-AP MLD in the
46
dot11InterworkingEntry is set to true indicating the requesting (#7358)non-AP MLD is verified
47
48 for EPCS priority access, the AP MLD shall set the Status Code field to a value of SUCCESS.
49 2) (#5867)(#5284)For an AP MLD with dot11SSPNInterfaceActivated equal to true, if the
50 (#4172)dot11EPCSPriorityAccessAuthorized for the requesting (#7358)non-AP MLD in the
51
52 dot11InterworkingEntry is set to false, the AP MLD shall set the Status Code field to a value of
53 EPCS_DENIED_UNAUTHORIZED.
54 3) (#5284)If the receiving AP MLD cannot support EPCS priority access for the initiating
55
(#7358)non-AP MLD for any other reason, the receiving AP MLD shall set the Status Code
56
57 field with a value of EPCS_DENIED_OTHER_REASON as defined in 9.4.1.9 (Status Code
58 field).
59
60 (#5867)NOTE 4—The verification for AP MLD with dot11SSPNInterfaceActivated equal to false is out
61 of scope of this standard.
62
63
64
65

490 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 c) (#5284)If the Status Code in the MLME-EPCSPRIACCESSENABLE.response primitive is equal to

2 SUCCESS, the receiving AP MLD STA shall (#5623)set the state of the EPCS priority access to
3
enabled for the requesting (#7358)non-AP MLD.
4
5 i) (#5624)The receiving AP MLD may include the Priority Access Multi-Link element in
6 the EPCS Priority Access Enable response frame to allow the requesting non-AP MLD to
7 employ priority access using the included EDCA parameter set and/or MU EDCA
8
9 parameter set on the corresponding links.
10 d) (#5284)If the Status Code in the MLME-EPCSPRIACCESSENABLE.response primitive is equal to
11 a value other than SUCCESS, the receiving AP MLD shall (#5623)keep EPCS priority access in the
12
torn down state for the requesting (#7358)(#5624)non-AP MLD.
13
14
15 (#5284)(#1127)Upon receipt of an EPCS Priority Access Teardown frame (9.6.35.7 (EPCS Priority Access
16 Teardown frame details(#5284)(#1127))), an (#7533)EPCS AP MLD with EPCS priority access enabled
17 (#5658)state shall use the following procedure to tear down EPCS priority access.
18
19 a) (#5284)The receiving AP MLD shall issue an MLME-EPCSPRIACCESSTEARDOWN.indication
20 primitive.
21
b) (#5284)The receiving AP MLD shall (#5625)change the EPCS priority access (#5623)(#5856)state
22
23 to torn down for the requesting (#7358)(#5624)non-AP MLD.
24
25 35.17.2.2.5 Procedures at the receiving non-AP MLD(#4173)(#1707)
26
27
(#1119)(#1488)(#5284)Upon receipt of an EPCS Priority Access Enable Request frame (9.6.35.5 (EPCS
28
29 Priority Access Enable Request frame format(#5284)(#1119)(#1488))), a (#7358)(#7533)EPCS non-AP
30 MLD with EPCS priority access (#5856)in the torn down state shall use the following procedure to enable
31 EPCS priority access.
32
33 a) (#5284)The receiving (#7358)non-AP MLD shall issue an MLME-
34 EPCSPRIACCESSENABLE.indication primitive.
35 b) (#1469)(#1471)(#1707)(#5284)Upon receipt of the MLME-EPCSPRIACCESSENABLE.response
36
primitive, (#4448)a non-AP STA affiliated with the receiving (#7358)non-AP MLD shall reply to
37
38 the initiating AP MLD with an EPCS Priority Access Enable Response frame (9.6.35.6 (EPCS
39 Priority Access Enable Response frame format(#5284)(#1119)(#1488))). The receiving (#7358)non-
40 AP MLD should set the Status Code field to a value of SUCCESS (#5869)unless, if the (#7358)non-
41 AP MLD is unable to support EPCS priority access, the (#7358)non-AP MLD shall set the Status
42
Code field with a value of EPCS_DENIED_OTHER_REASON as defined in 9.4.1.9 (Status Code
43
44 field).
45 c) (#5284)If the (#7544)Status Code in the MLME-EPCSPRIACCESSENABLE.response primitive is
46 equal to SUCCESS, the receiving (#7358)non-AP MLD shall (#5856)change the state of the EPCS
47
48 priority access to enabled so that subsequently transmitted traffic receives EPCS priority access
49 treatment using the procedure defined in 35.17.3 (EPCS priority access procedure(#5284)).
50 d) (#5284)If the (#7545)Status Code in the MLME-EPCSPRIACCESSENABLE.response primitive is
51
equal to a value other than SUCCESS, the receiving (#7358)non-AP MLD shall (#5856)keep the
52
53 torn down state of the EPCS priority access so it does not only apply to subsequently transmitted
54 traffic.
55
56 (#1127)(#5284)Upon receipt of an EPCS Priority Access Teardown frame (9.6.35.7 (EPCS Priority Access
57
Teardown frame details(#5284)(#1127))), a (#7358)(#7533)EPCS non-AP MLD with EPCS priority access
58
59 enabled shall use the following procedure to (#5856)tear down EPCS priority access.
60 a) (#5284)The receiving (#7358)non-AP MLD shall issue an MLME-
61 EPCSPRIACCESSTEARDOWN.indication primitive.
62
63 b) (#5284)The receiving (#7358)non-AP MLD shall (#5856)change the EPCS priority access state to
64 torn down so that subsequently transmitted traffic does not receive EPCS priority access treatment.
65

Copyright © 2022 IEEE. All rights reserved. 491

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 35.17.3 EPCS priority access procedure(#5284)

2
3
35.17.3.1 General(#1709)
4
5
6 (#1470)(#2306)(#1709)(#2171)(#5284)(#4176)(#4450)(#5870)EPCS priority access procedure allows
7 EPCS non-AP MLDs with priority access in the enabled state to gain priority access to medium. If the
8 negotiation to enable EPCS priority access between an EPCS AP MLD and an EPCS non-AP MLD is
9
successful, then the STA affiliated with the non-AP MLD applies EPCS priority access to its EPCS traffic on
10
11 all enabled links using the procedure described below.
12
13 (#5284)(#5627)An EPCS non-AP MLD shall apply EPCS priority access procedures only when its EPCS
14 priority access state is set to enabled. An EPCS AP MLD may apply EPCS priority access to EPCS traffic
15
using the procedure described below prior to completion of the negotiation to enable EPCS priority
16
17 access(#7523).
18
19 (#4449)An EPCS AP MLD is an AP MLD with dot11EHTEPCSPriorityAccessActivated set to true.
20
21
(#4450)(#5871)An EPCS non-AP MLD is a non-AP MLD with dot11EHTEPCSPriorityAccessActivated set
22
23 to true.
24
25 35.17.3.2 EDCA operation using EPCS EDCA parameters(#5284)(#1709)(#2171)
26
27
(#5284)As part of the EPCS priority access procedure, a STA affiliated with an (#5626)EPCS non-AP MLD
28
29 shall manage its EDCA parameter sets as follows:
30 — (#5284)During the process of enabling EPCS priority access, (#7863)the STA affiliated with the
31 EPCS non-AP MLD shall
32
33 • update its CWmin[AC], CWmax[AC], AIFSN[AC], and (#4338)TXOP Limit [AC] state vari-
34 ables of (#6516)(#4177)each access category to
35 • (#5626)(#5619)(#4176)the values carried in the EDCA Parameters Set element in the
36
Per-STA Profile corresponding to the AP to which the STA is associated in Priority
37
38 Access Multi-Link element contained in an EPCS Priority Access Enable action frame
39 sent by the EPCS AP MLD, if the corresponding Per-STA Profile is present and contains
40 an EDCA Parameters Set element or,
41 • the default EDCA parameter values found in Table 9-155 (Default EDCA Parameter Set
42
element parameter values if dot11OCBActivated is false or the STA is a non-sensor
43
44 STA) otherwise.
45 • (#4178)update the dot11MUEDCATable to respective values that correspond to fields in the MU
46 EDCA Parameter Set element in the Per-STA Profile corresponding to the AP to which the STA
47 is associated in Priority Access Multi-Link element contained in an EPCS Priority Access
48
Enable action frame sent by the EPCS AP MLD, if the corresponding Per-STA Profile is present
49
50 and contains an MU EDCA Parameter Set element.
51 — While EPCS priority access is enabled, each STA affiliated with an EPCS non-AP MLD shall,
52
53 • (#5626)(#5619)(#4176)use the latest EDCA parameter set, corresponding to the Link ID in the
54 Priority Access Multi-Link element contained in a EPCS Priority Access Enable action frame
55 sent by the EPCS AP MLD, if the Per-STA Profile corresponding to the AP to which the STA is
56 associated is included in the Priority Access Multi-Link element, and
57
• (#4178)ignore the part of the procedures defined in 10.2.3.2 (HCF contention based channel
58
59 access (EDCA)) that concerns the update of the EDCA parameters and the part of the procedures
60 defined in 26.2.7 (EDCA operation using MU EDCA parameters) that concerns the update of the
61 MU EDCA parameters that are sent by the corresponding AP in its Beacon and Probe Response
62 frames
63
• follow the rules defined in 26.2.7 (EDCA operation using MU EDCA parameters), except that
64
65

492 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 • (#4178)update the dot11MUEDCATable to respective values that correspond to fields in

2 the MU EDCA Parameter Set element in the Per-STA Profile corresponding to the AP to
3
which the STA is associated in Priority Access Multi-Link element contained in an
4
5 EPCS Priority Access Enable action frame sent by the EPCS AP MLD, if the corre-
6 sponding Per-STA Profile is present and contains an MU EDCA Parameter Set element.
7 • (#4178)if the MUEDCATimer[AC] of the STA reaches 0, either by counting down or
8 due to a reset following the reception of an MU EDCA Reset frame, the STA shall
9
update CWmin[AC], CWmax[AC], and AIFSN[AC] to the values that are contained in
10
11 the EDCA Parameters Set element in the Per-STA Profile corresponding to its associated
12 AP in the Priority Access Multi-Link element, if the corresponding per-STA profile is
13 contained in an EPCS Priority Access Enable action frame sent by the EPCS AP MLD
14 and the Per-STA Profile contains an EDCA Parameter Set element.
15
16
17 (#5626)(#5619)(#5284)After the EPCS priority access is torn down, each STA affiliated with an EPCS non-
18 AP MLD
19 — shall update its CWmin[AC], CWmax[AC], AIFSN[AC], and (#4338)TXOP Limit [AC] state
20
21 variables following the procedures in 10.2.3.2 (HCF contention based channel access (EDCA)).
22 — (#4178)shall update the dot11MUEDCATable following the procedures in 26.2.7 (EDCA operation
23 using MU EDCA parameters).
24
25
26 (#4178)(#5621)An AP affiliated with an EPCS AP MLD manages the EDCA parameter set and the MU
27 EDCA parameter set for EPCS non-AP MLD with the EPCS priority access in the enabled state and non-
28 EPCS non-AP MLDs as follows:
29
30 — (#5629)If the EPCS priority access state is in the enabled state by at least one associated EPCS non-
31 AP MLD, then
32 • (#6747)(#5628)if the EDCA parameters previously sent out by an AP affiliated with an EPCS
33
AP MLD in Management frames it transmits (see 10.2.3.2 (HCF contention based channel
34
35 access (EDCA))) do not result in higher priority for STAs that are affiliated with EPCS non-AP
36 MLDs in the enabled state, that AP shall announce EDCA parameters in Management frames
37 that result in higher priority for those STAs with EPCS priority access in the enabled state;
38
39 — Otherwise,
40 • (#5629)an AP affiliated with an EPCS AP MLD with its EPCS priority access state set to the
41 torn down state for all its associated STAs announces the EDCA parameter set corresponding to
42
the link in Management frames (e.g., Beacon or Probe Response) that it transmits following the
43
44 procedure in 10.2.3.2 (HCF contention based channel access (EDCA)).
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 493

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

494 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 36. Extremely high throughput (EHT) PHY specification

2
3
4 36.1 Introduction
5
6
7 36.1.1 Introduction to the EHT PHY
8
9 Clause 36 (Extremely high throughput (EHT) PHY specification) specifies the PHY entity for an extremely
10 high throughput (EHT) orthogonal frequency division multiplexing (OFDM) system. In addition to the
11
12 requirements in Clause 36 (Extremely high throughput (EHT) PHY specification), an EHT STA shall be
13 capable of transmitting and receiving PPDUs that are compliant with the mandatory requirements of
14 Clause 27 (High Efficiency (HE) PHY specification), (#7094)which specifies support of the mandatory
15 requirements of Clause 17 (Orthogonal frequency division multiplexing (OFDM) PHY specification),
16 Clause 19 (High Throughput (HT) PHY specification), and Clause 21 (Very High Throughput (VHT) PHY
17
18 specification)(#3160).
19
20 For 2.4 GHz band operation, the EHT PHY is based on HE PHY defined in Clause 27 (High Efficiency
21 (HE) PHY specification), which is based on the HT PHY defined in Clause 19 (High Throughput (HT) PHY
22 specification), which is based on the OFDM PHY defined in (#7948)Clause 16 (High rate direct sequence
23
24 spread spectrum (HR/DSSS) PHY specification) and Clause 18 (Extended Rate PHY (ERP) specification).
25
26 For 5 GHz band operation, the EHT PHY is based on the HE PHY defined in Clause 27 (High Efficiency
27 (HE) PHY specification), which is based on the VHT PHY defined in Clause 21 (Very High Throughput
28 (VHT) PHY specification), which is based on the HT PHY defined in Clause 19 (High Throughput (HT)
29
30 PHY specification), which is based on the OFDM PHY defined in Clause 17 (Orthogonal frequency division
31 multiplexing (OFDM) PHY specification).
32
33 For 6 GHz band operation, the EHT PHY is based on HE PHY defined in Clause 27 (High Efficiency (HE)
34 PHY specification), which is based on the OFDM PHY defined in Clause 17 (Orthogonal frequency division
35
36 multiplexing (OFDM) PHY specification).
37
38 The EHT PHY provides support for DL OFDMA, UL OFDMA, DL MU-MIMO, and UL MU-MIMO. Both
39 (#6462)DL MU-MIMO and UL MU-MIMO transmissions are supported on portions of the PPDU
40 bandwidth (on resource units greater than or equal to 242 tones). (#1239)(#7095)In an MU-MIMO resource
41
42 unit, there is support for up to eight users with up to four spatial streams per user with the total across all
43 users not exceeding eight spatial streams.
44
45 (#4613)The EHT PHY defines RUs comprising of 26, 52, 106, 242, 484, 996, 2996 or 4996 tones in
46 36.3.2.1 (Subcarriers and resource allocation in EHT PPDUs(#4636)), and MRUs comprising two or more
47
48 RUs in certain combinations in 36.3.2.2 (Subcarriers and resource allocation for multiple RUs).
49
50 The EHT PHY provides support of (#7096)multiple resource unit (MRU) assigned to a single STA. The
51 EHT PHY also supports preamble puncturing of EHT MU PPDU.
52
53
54 The EHT PHY provides support for 0.8 µs, 1.6 µs, and 3.2 µs guard interval durations.
55
56 The EHT PHY provides support for 3.2 µs (1), 6.4 µs (2), and 12.8 µs (4) EHT-LTF symbol durations,
57 excluding the GI duration.
58
59
60 (#6909)The EHT PHY supports a symbol duration, excluding GI, of 3.2 µs for the pre-EHT modulated
61 fields and 12.8 µs for the EHT modulated fields in an EHT PPDU.
62
63 (#6910)The EHT PHY data subcarrier frequency spacing is the same as the HE PHY data subcarrier
64 frequency spacing that is a quarter of the VHT PHY and HT PHY data subcarrier frequency spacing.
65

Copyright © 2022 IEEE. All rights reserved. 495

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#4894)The EHT PHY data subcarriers are modulated using BPSK, BPSK-DCM (EHT-MCS 15), QPSK,
2 16-QAM, 64-QAM, 256-QAM, 1024-QAM, and 4096-QAM (EHT-MCS 12 and 13). EHT-MCS 15 is only
3
used in single spatial stream non-MU-MIMO transmission. The EHT PHY introduces EHT DUP mode for
4
5 single user transmission with single spatial stream and LDPC coding in the 6 GHz band as EHT-MCS 14.
6 FEC coding (convolutional or LDPC coding) is used with coding rates of 1/2, 2/3, 3/4, and 5/6.
7
8 An EHT STA shall support the following features:
9
10 — (#1980)(#5454)Single user non-OFDMA transmission and reception of an EHT MU PPDU.
11 — (#7639)BCC coding (transmit and receive). BCC coding is supported for EHT PPDUs where all of
12
the following conditions are satisfied:
13
14 • The user is assigned an RU or MRU whose size is less than or equal to 242 tones.
15 • The number of spatial streams assigned to the user is less than or equal to 4.
16 • The user is assigned EHT-MCSs 0–9, 15.
17
18 BCC coding is not supported in EHT PPDUs where the above conditions are not all satisfied.
19 — (#7639)LDPC coding (transmit and receive) in all supported EHT PPDU types, RU and MRU sizes,
20
21 and number of spatial streams if a STA satisfies any of the following conditions:
22 • The STA supports transmitting and receiving in channel bandwidths greater than 20 MHz.
23 • The STA declares support for transmitting or receiving more than 4 spatial streams.
24
• The STA declares support for at least one of EHT-MCSs 10, 11, 12, and 13 (transmit and
25
26 receive).
27 — Single spatial stream EHT-MCSs 0 to 7 (transmit and receive) in all supported channel widths
28 (#5723)and RU and MRU sizes of EHT PPDU.
29
30 — (#3091)(#5723)Single spatial stream EHT-MCSs 8 and 9 (transmit and receive) in all supported
31 channel widths and RU and MRU sizes of EHT PPDU if the STA is not a 20 MHz-only non-AP
32 STA.
33
34 — (#3089)(#3090)(#7953)EHT-MCS 15 (transmit and receive) for
35 • 26-, 52-, 106-, and 242-tone RU for 20 MHz-only non-AP STA(#5872)
36
• 26-, 52-, 106-, 242-, 484-, and 996-tone RU if the STA declares support for larger than 20 MHz
37
38 PPDU
39 • 2996-tone RU if the STA declares support for larger than or equal to 160 MHz PPDU
40 • 4996-tone RU if the STA declares support for 320 MHz PPDU
41
42 — (#3262)Reception of the EHT-SIG field in an EHT MU PPDU at EHT-MCS 0, 1, 3, and 15.
43 — EHT MU PPDU with a 2 EHT-LTF and 0.8 µs GI duration on the EHT-LTF and Data field OFDM
44 symbols (transmit and receive for single user).
45
46 — EHT MU PPDU with a 2 EHT-LTF and 1.6 µs GI duration on the EHT-LTF and Data field OFDM
47 symbols (transmit and receive for single user).
48
— EHT MU PPDU with a 4 EHT-LTF and 3.2 µs GI duration on the EHT-LTF and Data field OFDM
49
50 symbols (transmit and receive for single user).
51 — 20 MHz channel width and all RU and MRU sizes and locations applicable to the 20 MHz channel
52 width (#7363)in the 2.4 GHz, 5 GHz, and 6 GHz bands (transmit and receive).
53
54 — Transmission and reception of a non-OFDMA EHT MU PPDU with any preamble puncturing
55 pattern listed in Table 36-30 (Definition of the Punctured Channel Information field in the U-SIG for
56 an EHT MU PPDU using non-OFDMA transmissions(#8011)(#2402)) for the PPDU bandwidth
57
supported by the STA(#7104)(#7963).
58
59
60 An EHT STA may support the following features:
61 — EHT-MCSs 10 to 13 (transmit and receive) if the STA is not a 20 MHz-only non-AP STA.
62
63 EHT-MCSs 8 to 13 (transmit and receive) if the STA is a 20 MHz-only non-AP STA.
64
65

496 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — (#7954)EHT-MCS 14 (transmit and receive) (#7362)in the 6 GHz nonpunctured transmission for
2 single user in 80 MHz, 160 MHz, and 320 MHz EHT MU PPDUs(#7955), if the STA declares
3
support for 80 MHz, 160 MHz, and 320 MHz PPDU, respectively.(#1082)(#1264)
4
5 — Single spatial stream EHT-MCS 15 (transmit and receive) in 52+26-, 106+26-, 484+242-,
6 996+484-, 996+484+242-, and 3996-tone MRUs.
7
8 (#1267)NOTE—EHT-MCS 15 is not defined for 2996+484- and 3996+484-tone MRUs.
9
10 — Two or more spatial streams (transmit and receive).
11
12 — Single user transmission using EHT MU PPDU with a 4 EHT-LTF and 0.8 µs GI duration on the
13 EHT-LTF and Data field OFDM symbols (transmit and receive)(#4562).
14 — (#4520)40 MHz channel width RU and MRU size larger than 242 tones in the 2.4 GHz band
15
16 (transmit and receive).
17 — (#4520)160 MHz channel width RU and MRU size larger than 996 tones in the 5 GHz band
18 (transmit and receive).
19
20 — (#4520)320 MHz channel width RU and MRU size larger than 996 tones in the 6 GHz band
21 (transmit and receive).
22
23 An EHT AP shall support the following features:
24
25 — (#7957)OFDMA transmission of an EHT MU PPDU where none of the RUs or MRUs utilize MU-
26 MIMO (DL OFDMA).
27
28 — Reception of an EHT TB PPDU where none of the RUs or MRUs utilize MU-MIMO (UL OFDMA).
29 — (#7958)Transmission of a non-OFDMA EHT MU PPDU utilizing MU-MIMO if the AP is capable
30 of transmitting four or more spatial streams.
31
32 — (#7960)(#2774)Reception of a non-OFDMA EHT TB PPDU utilizing MU-MIMO (UL MU-MIMO)
33 if the AP is capable of receiving four or more spatial streams(#7102).
34
— 40 MHz and 80 MHz channel widths and all RU and MRU sizes and locations applicable to the
35
36 40 MHz and 80 MHz channel widths (#7360)in the 5 GHz band (transmit and receive).
37 — 40 MHz, 80 MHz, and 160 MHz channel widths and all RU and MRU sizes and locations applicable
38 to the 40 MHz, 80 MHz, and 160 MHz channel widths (#7362)in the 6 GHz bands (transmit and
39
40 receive).
41 — Transmission of an EHT MU PPDU to multiple users with a 2 EHT-LTF and 0.8 µs GI duration on
42 the EHT-LTF and Data field OFDM symbols.
43
44 — Transmission of an EHT MU PPDU to multiple users with a 2 EHT-LTF and 1.6 µs GI duration on
45 the EHT-LTF and Data field OFDM symbols.
46
— Transmission of an EHT MU PPDU to multiple users with a 4 EHT-LTF and 3.2 µs GI duration on
47
48 the EHT-LTF and Data field OFDM symbols.
49 — (#7962)Reception of non-OFDMA EHT TB PPDUs from multiple users with a 1 EHT-LTF and
50 1.6 µs GI duration on the EHT-LTF and Data field OFDM symbols.
51
52 — Reception of an EHT TB PPDU with a 2 EHT-LTF and 1.6 µs GI duration on the EHT-LTF and
53 Data field OFDM symbols.
54
55 — Reception of an EHT TB PPDU with a 4 EHT-LTF and 3.2 µs GI duration on the EHT-LTF and
56 Data field OFDM symbols.(#4520)(#7641)
57 — Transmission of an OFDMA EHT MU PPDU with any preamble puncturing pattern listed in
58
Table 36-30 (Definition of the Punctured Channel Information field in the U-SIG for an EHT MU
59
60 PPDU using non-OFDMA transmissions(#8011)(#2402)) for the PPDU bandwidth supported by the
61 AP(#7963).
62
63 An EHT AP may support the following features:
64
65

Copyright © 2022 IEEE. All rights reserved. 497

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — (#7964)Transmission of a non-OFDMA EHT MU PPDU utilizing MU-MIMO (DL MU-MIMO)

2 when the AP is not capable of transmitting equal to or more than 4 spatial streams.
3
4 — MU-MIMO transmission on an RU or MRU in an EHT MU PPDU where there are multiple RUs or
5 MRUs(#3263) in the (#5089)entire PPDU bandwidth (DL MU-MIMO within OFDMA).
6
— MU-MIMO reception on an RU or MRU in an EHT TB PPDU where the RU or MRU is of size
7
8 larger than or equal to 242 tones in the supported bandwidth non-OFDMA transmission (UL MU-
9 MIMO) when the AP is (#7964)not capable of receiving equal to or more than 4 spatial streams.
10 — MU-MIMO reception on an RU or MRU in an EHT TB PPDU which consists of multiple
11
12 RUs or MRUs(#3264) in the entire PPDU bandwidth (UL MU-MIMO within OFDMA)(#4520).
13 — Transmission of an EHT MU PPDU to multiple users with a 4 EHT-LTF and 0.8 µs GI duration on
14 the EHT-LTF and Data field OFDM symbols.
15
16 — Transmission of an OFDMA EHT MU PPDU with any preamble puncturing pattern as specified in
17 36.3.12.11.2 (Preamble puncturing for EHT MU PPDUs in an OFDMA transmission(#7236))
18 excluding those preamble puncturing patterns listed in Table 36-30 (Definition of the Punctured
19 Channel Information field in the U-SIG for an EHT MU PPDU using non-OFDMA
20
21 transmissions(#8011)(#2402))(#7104)(#7963).
22 — Full bandwidth and partial bandwidth sounding as defined in 35.7.2 (EHT sounding
23 protocol)(#7105)(#2988).
24
25
26 A non-AP EHT STA shall support the following features:
27 — Reception of an EHT MU PPDU where the RU or MRU(#3265) allocated to the non-AP STA is not
28 utilizing MU-MIMO (DL OFDMA).
29
30 — Transmission of an EHT TB PPDU where the RU or MRU(#3266) allocated to the non-AP STA is
31 not utilizing MU-MIMO (UL OFDMA).
32
33 — (#7107)(#2774)(#1980)Reception of a non-OFDMA EHT MU PPDU utilizing MU-MIMO (DL
34 MU-MIMO) (#7106)in the supported bandwidth. The maximum number of spatial streams per user
35 the non-AP STA can receive in the DL MU-MIMO transmission shall be equal to min(n, 4), where n
36 is the maximum number of spatial streams supported for reception of a non-OFDMA EHT MU
37 PPDU sent to single non-AP STA. The non-AP STA shall be able to receive its intended spatial
38
39 streams in a DL MU-MIMO transmission with a total number of spatial streams across all users of at
40 least four.
41 — (#1980)MU-MIMO transmission in a non-OFDMA EHT TB PPDU (UL MU-MIMO). The non-AP
42
EHT STA shall support transmitting UL MU-MIMO where the total spatial streams summed across
43
44 all users is less than or equal to eight.
45 — (#4522)Responding with requested beamforming feedback in an EHT sounding procedure with at
46 least four spatial streams in the EHT sounding NDP.
47
48 — (#2678)Reception of 160 MHz EHT sounding NDP (#7361)in the 5 GHz and 6 GHz bands if the
49 non-AP EHT STA’s operating channel width is 80 MHz.
50
51 — (#2678)Reception of 320 MHz EHT sounding NDP (#7362)in the 6 GHz band if the non-AP EHT
52 STA’s operating channel width is 80 MHz or 160 MHz.(#7110)(#7972)
53 — 40 MHz and 80 MHz channel widths and all RU and MRU sizes and locations applicable to the
54
40 MHz and 80 MHz channel widths in the 5 GHz and 6 GHz band (transmit and receive) except for
55
56 20 MHz-only non-AP EHT STA(#7111).
57 — Reception of a 160 MHz EHT MU PPDU, or transmission of a 160 MHz EHT TB PPDU (#7361)in
58 the 5 GHz and 6 GHz bands where the assigned RU/MRU is in the primary 80 MHz channel if the
59
60 non-AP EHT STA is (#7973)operating with 80 MHz channel width.
61 — Reception of a 320 MHz EHT MU PPDU, or transmission of a 320 MHz EHT TB PPDU (#7362)in
62 the 6 GHz band where the assigned RU/MRU is in the primary 80 MHz channel if the non-AP EHT
63
STA is (#7973)operating with 80 MHz channel width.
64
65

498 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — Reception of a 320 MHz EHT MU PPDU, or transmission of a 320 MHz EHT TB PPDU (#7362)in
2 the 6 GHz band where the assigned RU/MRU is in the primary 160 MHz channel if the non-AP EHT
3
STA is (#7973)operating with 160 MHz channel width.
4
5 — Reception of an EHT MU PPDU to multiple users with a 2 EHT-LTF and 0.8 µs GI duration on the
6 EHT-LTF and Data field OFDM symbols.
7
8 — Reception of an EHT MU PPDU to multiple users with a 2 EHT-LTF and 1.6 µs GI duration on the
9 EHT-LTF and Data field OFDM symbols.
10 — Reception of an EHT MU PPDU to multiple users with a 4 EHT-LTF and 3.2 µs GI duration on the
11
12 EHT-LTF and Data field OFDM symbols.
13 — (#4523)Transmission of an EHT TB PPDU utilizing non-OFDMA UL MU-MIMO with a 1 EHT-
14 LTF and 1.6 µs GI duration on the EHT-LTF and Data field OFDM symbols.
15
16 — Transmission of an EHT TB PPDU with a 2 EHT-LTF and 1.6 µs GI duration on the EHT-LTF and
17 Data field OFDM symbols.
18
— Transmission of an EHT TB PPDU with a 4 EHT-LTF and 3.2 µs GI duration on the EHT-LTF and
19
20 Data field OFDM symbols(#2776).
21 — Full bandwidth sounding as defined in 35.7.2 (EHT sounding protocol)(#5090)(#2988).
22
23 — Reception of an OFDMA EHT MU PPDU with any preamble puncturing pattern as specified in
24 36.3.12.11.2 (Preamble puncturing for EHT MU PPDUs in an OFDMA
25 transmission(#7236))(#7104)(#7963).
26
27
A non-AP EHT STA may support the following(#4520):
28
29 — 160 MHz channel width and RU and MRU size larger than 996 tones in the 6 GHz band (transmit
30 and receive)(#2986)(#4520).
31
32 — (#7107)MU-MIMO reception on an RU or MRU in an EHT MU PPDU which consist of multiple
33 RUs and/or MRUs (DL MU-MIMO within OFDMA). The maximum number of spatial streams per
34 user in the DL MU-MIMO within OFDMA transmission that the non-AP STA can receive shall be
35 min(n, 4) where n is the maximum number of spatial streams supported for reception of non-
36
OFDMA EHT MU PPDU sent to that single non-AP STA. The total number of spatial streams
37
38 (across all users) in a DL MU-MIMO within OFDMA transmission that the non-AP STA can receive
39 shall be at least four.
40 — MU-MIMO transmission on an RU or MRU in an EHT TB PPDU which consist of multiple RUs
41
42 and/or MRUs in the entire PPDU bandwidth (UL MU-MIMO within OFDMA). If supported, then
43 the non-AP EHT STA shall support transmitting UL MU-MIMO where the total spatial streams
44 summed across all users is less than or equal to eight.
45
— Reception of an EHT MU PPDU to multiple users with a 4 EHT-LTF and 0.8 µs GI duration on the
46
47 EHT-LTF field and Data field OFDM symbols.
48 — Partial bandwidth sounding as defined in 35.7.2 (EHT sounding protocol)(#5090).
49
50
51 (#6930)A 20 MHz operating non-AP EHT STA shall support the following:
52 — 26-, 52-, and 106-tone RU sizes and 52+26-tone MRU size on locations allowed in 36.3.2.6 (RU and
53 MRU restrictions for 20 MHz operation(#3276)) in the primary 20 MHz channel (#6930)within
54
40 MHz PPDU in the 2.4 GHz band, and 40 MHz, 80 MHz, and 160 MHz PPDU(#1272) in the
55
56 5 GHz and 6 GHz bands, and 320 MHz PPDU in the 6 GHz band.
57
58 (#6930)A 20 MHz operating non-AP EHT STA may support the following:
59
60 — (#2679)Reception of 40 MHz EHT sounding NDP (#7363)(#6930)in the 2.4 GHz, 5 GHz, and
61 6 GHz bands.
62 — (#2679)Reception of 80 MHz and 160 MHz EHT sounding NDP (#7361)(#6930)in the 5 GHz and
63
6 GHz bands.
64
65

Copyright © 2022 IEEE. All rights reserved. 499

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — Reception of 242-tone RU in the primary 20 MHz channel (#6930)within 40 MHz PPDU in the 2.4
2 GHz band, and 40 MHz, 80 MHz, and 160 MHz PPDU(#1272) in the 5 GHz and 6 GHz bands, and
3
320 MHz PPDU in the 6 GHz band.
4
5 — 26-, 52-, 106-, and 242-tone RU sizes and 52+26-tone MRU size on locations allowed in 36.3.2.6
6 (RU and MRU restrictions for 20 MHz operation(#3276)) in any 20 MHz channel (#6930)except the
7 primary 20 MHz within 40 MHz channel width in the 2.4 GHz band if the 20 MHz operating non-
8
9 AP EHT STA supports the HE subchannel selective transmission operation described in 26.8.7 (HE
10 subchannel selective transmission).
11 — 26-, 52-, 106-, and 242-tone RU sizes and 52+26-tone MRU size on locations allowed in 36.3.2.6
12
(RU and MRU restrictions for 20 MHz operation(#3276)) in any 20 MHz channel (#6930)except the
13
14 primary 20 MHz within 40 MHz, 80 MHz, and 160 MHz PPDU(#1272) widths in the 5 GHz and
15 6 GHz bands if the 20 MHz operating non-AP EHT STA supports the HE subchannel selective
16 transmission operation described in 26.8.7 (HE subchannel selective transmission).
17
18 — (#6930)26-, 52-, 106-, and 242-tone RU sizes and 52+26-tone MRU size on locations allowed in
19 36.3.2.6 (RU and MRU restrictions for 20 MHz operation(#3276)) in any 20 MHz channel except
20 the primary 20 MHz within the primary 160 MHz when the BSS bandwidth is 320 MHz in the
21 6 GHz band if the 20 MHz operating non-AP EHT STA supports the HE subchannel selective
22 transmission operation described in 26.8.7 (HE subchannel selective transmission).
23
24 — (#4562)LDPC coding if the maximum number of spatial streams the STA is capable of transmitting
25 or receiving in an EHT MU PPDU is less than or equal to 4, (#6930)if the non-AP STA is a 20 MHz
26 only non-AP STA that does not support any of EHT-MCS 10, 11, 12 or 13.
27
28
29 36.1.2 Scope
30
31 The services provided to the MAC by the EHT PHY consist of the following protocol functions:
32
33 a) A function that maps the PSDU received from the MAC into a PPDU for transmission to one or
34 more receiving STAs.
35 b) A function that defines the characteristics and method of transmitting and receiving data through a
36
wireless medium between two or more STAs. Depending on the PPDU format, these STAs support
37
38 a mixture of EHT, Clause 27 (High efficiency (HE) PHY specification), Clause 21 (Very high
39 throughput (VHT) PHY specification), Clause 19 (High-throughput (HT) PHY specification),
40 Clause 18 (Extended Rate PHY (ERP) specification), Clause 17 (Orthogonal frequency division
41 multiplexing (OFDM) PHY specification), Clause 16 (High rate direct sequence spread spectrum
42
(HR/DSSS) PHY specification), and Clause 15 (DSSS PHY specification for the 2.4 GHz band
43
44 designated for ISM applications) PHYs.
45
46 36.1.3 EHT PHY functions
47
48
36.1.3.1 General
49
50
51 The EHT PHY contains two functional entities: the PHY function, and the physical layer management
52 function (i.e., the PLME). These functions are described in detail in 36.3 (EHT PHY) and 36.4 (EHT
53 PLME). The EHT PHY service is provided to the MAC through the PHY service primitives defined in
54
Clause 8 (PHY service specification). The EHT PHY service interface is described in 36.2 (EHT PHY
55
56 service interface).
57
58 36.1.3.2 PHY management entity (PLME)
59
60
The PLME performs management of the local PHY functions in conjunction with the MLME.
61
62
63
64
65

500 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 36.1.3.3 Service specification method

2
3
The models represented by figures and state diagrams are intended to be illustrations of the functions
4
5 provided. It is important to distinguish between a model and a real implementation. The models are
6 optimized for simplicity and clarity of presentation.
7
8 The service of a layer is the set of capabilities that it offers to a user in the next higher layer. Abstract
9
services are specified here by describing the service primitives and parameters that characterize each
10
11 service. This definition is independent of any particular implementation.
12
13 36.1.4 PPDU formats
14
15 The structure of the PPDU transmitted by an EHT STA is determined by the TXVECTOR parameters as
16
17 defined in Table 36-1 (TXVECTOR and RXVECTOR parameters).
18
19 The FORMAT parameter determines the overall structure of the PPDU and can take on one of the following
20
values:
21
22 — Non-HT format (NON_HT), based on Clause 17 (Orthogonal frequency division multiplexing
23 (OFDM) PHY specification) or Clause 18 (Extended Rate PHY (ERP) specification), and including
24 non-HT duplicate format based on 36.3.15 (Non-HT duplicate transmission)(#2990).
25
26 — HT-mixed format (HT_MF) as specified in Clause 19 (High Throughput (HT) PHY specification).
27 — HT-greenfield format (HT_GF) as specified in Clause 19 (High Throughput (HT) PHY
28
specification).
29
30 — VHT format (VHT) as defined in Clause 21 (Very High Throughput (VHT) PHY specification).
31
— (#8083)HE SU PPDU format (HE_SU) as defined in Clause 27 (High Efficiency (HE) PHY
32
33 specification).
34 — (#8083)HE ER SU format (HE_ER_SU) as defined in Clause 27 (High Efficiency (HE) PHY
35 specification).
36
37 — (#8083)HE MU PPDU format (HE_MU) as defined in Clause 27 (High Efficiency (HE) PHY
38 specification).
39
40 — (#8083)HE TB PPDU format (HE_TB) as defined in Clause 27 (High Efficiency (HE) PHY
41 specification).
42 — (#7323)EHT MU PPDU format (EHT_MU) carries one or more PSDUs to one or more users as
43
defined in 36.3.4 (EHT PPDU formats).
44
45 — (#4981)(#7324)EHT TB PPDU format (EHT_TB) carries a single PSDU and is sent in response to a
46 PPDU that carries a triggering frame as defined in 36.3.4 (EHT PPDU formats).
47
48
49 36.2 EHT PHY service interface
50
51
52 36.2.1 Introduction
53
54 (#1260)(#7117)(#4525)The PHY provides an interface to the MAC through an extension of the generic PHY
55 service interface defined in 8.3.4 (Basic service and options). The interface includes TXVECTOR,
56
RXVECTOR, PHYCONFIG_VECTOR, and TRIG_VECTOR.
57
58
59 The MAC uses the TXVECTOR to supply the PHY with per-PPDU transmit parameters. The PHY uses the
60 RXVECTOR to inform the MAC of the received PPDU parameters. The MAC uses the
61 PHYCONFIG_VECTOR to configure the PHY for operation that is independent of frame transmission or
62
reception. The MAC uses the TRIG_VECTOR to configure the PHY to receive EHT TB PPDUs over each
63
64 assigned RU.
65

Copyright © 2022 IEEE. All rights reserved. 501

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 36.2.2 TXVECTOR and RXVECTOR parameters

2
3
(#3162)The parameters in Table 36-1 (TXVECTOR and RXVECTOR parameters) are defined as part of the
4
5 TXVECTOR parameter list in the PHY-TXSTART.request primitive for (#4643)PPDU transmitting and/or
6 as part of the RXVECTOR parameter list in the PHY-RXSTART.indication and PHY-RXEND.indication
7 primitives for (#4643)PPDU receiving.
8
9
10
Table 36-1—TXVECTOR and RXVECTOR parameters
11
12
13

RXVECTOR
TXVECTOR
Parameter

14
15
16 Condition Value
17
18
19
20 Determines the format of the PPDU.
21 Enumerated type:
22 NON_HT indicates Clause 15, Clause 16, Clause 17,
23 Clause 18, or non-HT duplicate PPDU format. In this case,
24 the modulation is determined by the NON_HT_MODULA-
25 TION parameter defined in Table 19-1 (TXVECTOR and
26 RXVECTOR parameters)(#1520)(#2016).
27
FORMAT

HT_MF indicates HT-mixed format.

28
29 HT_GF indicates HT-greenfield format. Y Y
30 VHT indicates VHT format.
31 HE_SU indicates HE SU PPDU format.
32
33 HE_MU indicates HE MU PPDU format.
34 HE_ER_SU indicates HE ER SU PPDU format.
35 HE_TB indicates HE TB PPDU format.
36
37 EHT_MU indicates EHT MU PPDU format.
38 EHT_TB indicates EHT TB PPDU format.
39
40 (#8085)Set to 0 to indicate a DL OFDMA transmission
41 (including non-MU-MIMO and MU-MIMO).
FORMAT is EHT_MU and Set to 1 to indicate a transmission to a single user or EHT
EHT_PPDU_TYPE

42 Y Y
(#1520)(#2016)

43 UPLINK_FLAG is 0 sounding NDP not addressed to an AP.

44 Set to 2 to indicate a DL MU-MIMO (non-OFDMA)
45 transmission.
46
(#8085)FORMAT is
47 (#8085)Set to 1 to indicate an UL transmission to a single user
EHT_MU and Y Y
48 or EHT sounding NDP.
UPLINK_FLAG is 1
49
50 FORMAT is EHT_TB (#8085)Set to 0. O O
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

502 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-1—TXVECTOR and RXVECTOR parameters (continued)

2
3
4

RXVECTOR
TXVECTOR
Parameter

5
6 Condition Value
7
8
9
10 Not present.
11
12 (#1521)NOTE—The LENGTH field of the L-SIG field for
13 EHT MU PPDU is defined in Equation (36-17) using the
FORMAT is EHT_MU TXTIME value defined in 36.4.3 (TXTIME and N N
14
15 PSDU_LENGTH calculation), which in turn depend on other
16 parameters including the TXVECTOR parameter
17 APEP_LENGTH.
L_LENGTH

18
19 (#1260)(#1521)Indicates the value used to calculate the
20 LENGTH field of the L-SIG field. See 36.3.12.5 (L-SIG) for
21 details.
22 FORMAT is EHT_TB Y N
23 The value of this parameter comes from the triggering frame to
24 which the EHT TB PPDU is (#7980)the response (see
25 9.3.1.22.1.1 (Common Info field) for details).
26 Otherwise See corresponding entry in Table 19-1 (TXVECTOR and RXVECTOR
27 parameters), Table 21-1 (TXVECTOR and RXVECTOR parameters), or
28 Table 27-1 (TXVECTOR and RXVECTOR parameters).
29
30 FORMAT is NON_HT See corresponding entry in Table 19-1 (TXVECTOR and Y Y
L_DATARATE

31 RXVECTOR parameters)
(#4643)

32
33
34 Data rate signaled in L-SIG field:
Otherwise Y N
35 6 Mb/s
36
37 FORMAT is EHT_MU or
Indicates the number of transmit chains. Y N
38 EHT_TB
N_TX

39
40 See corresponding entry in Table 21-1 (TXVECTOR and RXVECTOR
Otherwise
41 parameters) or Table 27-1 (TXVECTOR and RXVECTOR parameters).
42
43 (#1260)For each user, contains a vector in the number of all the
44 subcarriers in (#4656)an RU/MRU that is assigned to this user.
FORMAT is EHT_MU and MU
The vector for each subcarrier contains feedback matrices as
EXPANSION_MAT(#2621)

45 PSDU_LENGTH > 0 (#45 N

46 defined in 36.3.17.2 (EHT beamforming feedback matrix V)
(#4528) 28)
47 based on the channel measured during the training symbols of
48 previous EHT sounding NDPs, HE NDPs or VHT NDPs.
49 (#1260)Contains a vector in the number of selected subcarriers
50 containing feedback matrices as defined in 36.3.17.2 (EHT O
51 FORMAT is EHT_TB beamforming feedback matrix V) based on the channel (#45 N
52 measured during the training symbols of previous EHT 28)
53 sounding NDPs, HE NDPs or VHT NDPs.
54
55 See corresponding entry in Table 21-1 (TXVECTOR and RXVECTOR
56 Otherwise
parameters) or Table 27-1 (TXVECTOR and RXVECTOR parameters).
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 503

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-1—TXVECTOR and RXVECTOR parameters (continued)

2
3
4

RXVECTOR
TXVECTOR
Parameter

5
6 Condition Value
7
8
9
10 Contains a vector in the number of selected subcarriers
11 containing feedback matrices as defined in 36.3.17.2 (EHT
12 FORMAT is EHT_MU and
beamforming feedback matrix V) based on the channel N Y
13 PSDU_LENGTH is 0(#1260)
measured during the training symbols of (#5805)the currently
14
CHAN_MAT

received EHT sounding NDP.

15
16 FORMAT is EHT_TB, or
17 FORMAT is EHT_MU and
Not present(#7121).
18 PSDU_LENGTH is greater
19 than 0(#1260)
20
21 See corresponding entry in Table 21-1 (TXVECTOR and RXVECTOR
Otherwise
22 parameters) or Table 27-1 (TXVECTOR and RXVECTOR parameters).
23
24 Contains an array of delta SNR values as defined in 9.4.1.72
FORMAT is EHT_MU and
25 (EHT MU Exclusive Beamforming Report field) based on the
PSDU_LENGTH is 0 N Y
26 channel measured during the training symbols of the received
(#7649)(#1260)
27 EHT sounding NDP.
DELTA_SNR

28 FORMAT is EHT_TB, or
29 FORMAT is EHT_MU and
30 Not present(#7121).
PSDU_LENGTH is greater
31 than 0(#7649)
32
33 See corresponding entry in Table 21-1 (TXVECTOR and RXVECTOR
34 Otherwise parameters) or Table 27-1 (TXVECTOR and RXVECTOR
35 parameters).(#7981)
36
37 Indicates whether signal extension needs to be applied at the
38 end of transmission.
NO_SIG_EXTN

39 FORMAT is EHT_MU or Boolean: Y N

40 EHT_TB true indicates that no signal extension is present.
41
false indicates that a signal extension is present.
42
43 See corresponding entry in Table 21-1 (TXVECTOR and RXVECTOR
44 Otherwise
parameters) or Table 27-1 (TXVECTOR and RXVECTOR parameters).
45
46 Contains an array of average values of received SNR
47 measurements for each spatial stream. SNR indications of 8
48 N Y
FORMAT is EHT_MU and bits are supported. Average value of SNR shall be the sum of
49 (#76 (#76
PSDU_LENGTH is 0(#1260) the decibel values of SNR per subcarrier divided by the
50 49) 49)
number of subcarriers represented in each stream as described
51 in 9.4.1.71 (EHT Compressed Beamforming Report field).
52
SNR

53 FORMAT is EHT_TB, or
54 FORMAT is EHT_MU and
Not present(#7121).
55 PSDU_LENGTH is greater
56 than 0(#1260)
57
58 See corresponding entry in Table 19-1 (TXVECTOR and RXVECTOR
59 Otherwise parameters), Table 21-1 (TXVECTOR and RXVECTOR parameters), or
60 Table 27-1 (TXVECTOR and RXVECTOR parameters).
61
62
63
64
65

504 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-1—TXVECTOR and RXVECTOR parameters (continued)

2
3
4

RXVECTOR
TXVECTOR
Parameter

5
6 Condition Value
7
8
9
10 Contains an array of received per-RU average SNRs for each
11 FORMAT is EHT_MU and spatial stream, where each per-RU average SNR is the
12 PSDU_LENGTH is 0(#1260) arithmetic mean of the SNR in decibels over a 26-tone RU as N Y
13 described in 9.4.1.73 (EHT CQI Report field).
14
15 FORMAT is EHT_TB, or
CQI

16 FORMAT is EHT_MU and

Not present(#7121).
17 PSDU_LENGTH is greater
18 than 0(#1260)
19
20 See corresponding entry in Table 27-1 (TXVECTOR and RXVECTOR
Otherwise
21 parameters).(#1240)(#1522)
22
23 (#1260)(#1523)Indicates the length of the GI for the EHT-LTF
24 and Data fields.
25 Enumerated type:
26 FORMAT is EHT_MU or 0u8s_GI indicates 0.8 µs.
1u6s_GI indicates 1.6 µs. Y Y
EHT_TB
GI_TYPE

27
28 3u2s_GI indicates 3.2 µs.
29 NOTE—The length of GI for pre-EHT modulated fields is
30 0.8 µs
31
32 See corresponding entry in Table 21-1 (TXVECTOR and RXVECTOR
33 Otherwise parameters) or Table 27-1 (TXVECTOR and RXVECTOR
34 parameters).(#3162)(#1274)(#8086)
35
36 Indicates the FEC encoding used.
FEC_CODING

37 FORMAT is EHT_MU or Enumerated type:

38 MU MU
EHT_TB BCC_CODING indicates BCC coding.
39 LDPC_CODING indicates LDPC coding.
40
41 See corresponding entry in Table 21-1 (TXVECTOR and RXVECTOR
42 Otherwise
parameters) or Table 27-1 (TXVECTOR and RXVECTOR parameters).
43
44 Indicates the presence of the LDPC extra symbol segment in
45 an EHT TB PPDU.
LDPC_EXTRA_SYMBOL

46 Integer:
47 FORMAT is EHT_TB 1 indicates that an LDPC extra symbol segment is present. Y N
48 0 indicates that an LDPC extra symbol segment is not pres-
49
ent.
50
51 (#4581)FORMAT is Not present(#7121).
52 EHT_MU
53
54 See corresponding entry in Table 27-1 (TXVECTOR and RXVECTOR
55 Otherwise
parameters).
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 505

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-1—TXVECTOR and RXVECTOR parameters (continued)

2
3
4

RXVECTOR
TXVECTOR
Parameter

5
6 Condition Value
7
8
9
10 The allowed values for the TXPWR_LEVEL_INDEX
11 parameter are in the range from 1 to numberOfOctets
LEVEL_INDEX

12 FORMAT is EHT_MU or (dot11TxPowerLevelExtended)/2. This parameter is used to

Y N
TXPWR_

13 EHT_TB indicate which of the available (#6914)transmit power levels

14 defined in dot11TxPowerLevelExtended shall be used for the
15 current transmission.
16
17 See corresponding entry in Table 21-1 (TXVECTOR and RXVECTOR
Otherwise
18 parameters) or Table 27-1 (TXVECTOR and RXVECTOR parameters).
19
20 The allowed values for the RSSI parameter are in the range 0
21 to 255 inclusive. This parameter is a measure by the PHY of
22 FORMAT is EHT_MU or the power observed at the antennas used to receive the current
N Y
23 EHT_TB PPDU measured during the reception of the EHT-LTF field.
RSSI

24 RSSI is intended to be used in a relative manner, and it is a

25 monotonically increasing function of the received power.
26
27 See corresponding entry in Table 21-1 (TXVECTOR and RXVECTOR
Otherwise
28 parameters) or Table 27-1 (TXVECTOR and RXVECTOR parameters).
29 The allowed values for the RSSI_LEGACY parameter are in
30 the range 0 to 255 inclusive. This parameter is a measure by
31
RSSI_LEGACY

the PHY of the power observed at the antennas used to receive

32 FORMAT is EHT_MU or
the current PPDU measured during the reception of non-EHT N Y
33 EHT_TB
portion of the EHT PPDU preamble. RSSI_LEGACY is
34 intended to be used in a relative manner, and it is a
35 monotonically increasing function of the received power.
36
37 See corresponding entry in Table 27-1 (TXVECTOR and RXVECTOR
38 Otherwise
parameters).
39
40 (#6924)Indicates the modulation and coding schemes used in
FORMAT is EHT_MU or
41 the transmission of the Data field of the PPDU. MU MU
EHT_TB
42 Integer: range 0 to 15(#1524).
MCS

43
44 See corresponding entry in Table 19-1 (TXVECTOR and RXVECTOR
45 Otherwise parameters), Table 21-1 (TXVECTOR and RXVECTOR parameters), or
46 Table 27-1 (TXVECTOR and RXVECTOR parameters).(#1260)
47
48 Indicates the modulation and coding scheme used for the
49 EHT_SIG field.
MCS_EHT_SIG

50 Integer: N
FORMAT is
51 0 indicates EHT-MCS 0. Y (#71
EHT_MU(#5808)
52 1 indicates EHT-MCS 1. 23)
53 2 indicates EHT-MCS 3.
54 3 indicates EHT-MCS 15.(#1525)
55 Otherwise Not present.
56
57 FORMAT is EHT_MU Indicates the EHT-MCS that the receiver recommends. N O
REC_MCS

58
59 FORMAT is EHT_TB Not present(#7121).
60
61 See corresponding entry in Table 21-1 (TXVECTOR and RXVECTOR
Otherwise
62 parameters) or Table 27-1 (TXVECTOR and RXVECTOR parameters).
63
64
65

506 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-1—TXVECTOR and RXVECTOR parameters (continued)

2
3
4

RXVECTOR
TXVECTOR
Parameter

5
6 Condition Value
7
8
9
10 Indicates the channel width of the PPDU.
11 Enumerated type:
12 CBW20 for 20 MHz.
CH_BANDWIDTH

13 FORMAT is EHT_MU or CBW40 for 40 MHz.

14 Y Y
EHT_TB(#1526) CBW80 for 80 MHz.
15 CBW160 for 160 MHz.
16 CBW320-1 for 320 MHz-1.
17 CBW320-2 for 320 MHz-2.
18
19 See corresponding entry in Table 19-1 (TXVECTOR and RXVECTOR
20 Otherwise parameters), Table 21-1 (TXVECTOR and RXVECTOR parameters), or
21 Table 27-1 (TXVECTOR and RXVECTOR parameters).
22
23 Indicates the 20 MHz subchannels that are punctured.
INACTIVE_SUBCHANNELS

24 FORMAT is EHT_MU, or
25 FORMAT is NON_HT and A bitmap indexed by the 20 MHz subchannels in ascending
26 NON_HT_MODULATION is order with the LSB indicating the lowest frequency 20 MHz
27 NON_HT_DUP_ subchannel. A bit is set to 1 to indicate that the corresponding
Y N
28 OFDM, or FORMAT is 20 MHz subchannel is punctured and set to 0 to indicate the
29 EHT_TB(#7984)(#4532)(#32 corresponding 20 MHz subchannel is not punctured.
30 39)(#3077)(#2146)(#1527)(#
31 3126) (#8087)See 35.12.5 (INACTIVE_SUBCHANNELS(#6686))
32 for details.
33
34 See corresponding entry in Table 27-1 (TXVECTOR and RXVECTOR
Otherwise
35 parameters).(#2016)(#1528)
36 FORMAT is EHT_MU or Not present(#7121).
37 EHT_TB
38
39 In TXVECTOR, if present, indicates the channel width of the
40 transmitted PPDU, which is signaled via the scrambling
41 sequence and SERVICE field.
42
CH_BANDWIDTH_IN_NON_HT

43 In RXVECTOR, if valid, indicates the channel width of the

44 received PPDU, which is signaled via the scrambling sequence
45 and SERVICE field.
46
47 FORMAT is NON_HT and (#8088)Enumerated type:
48 NON_HT_MODULATION is CBW20 for 20 MHz, O Y
49 NON_HT_DUP_OFDM(#79 CBW40 for 40 MHz
50 85)(#3162)(#1529) CBW80 for 80 MHz,
51 CBW160 for 160 MHz,
52 CBW320 for 320 MHz–1 and 320 MHz–2.
53
54
55 NOTE—In the RXVECTOR, the validity of this parameter is
56 determined by the MAC based on the contents of the currently
57 received MPDU (e.g., RTS) or the previous MPDU in an
58 exchange (e.g., the RTS preceding a CTS).
59
60 Otherwise Not present.(#3162)(#1530)(#7121)
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 507

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-1—TXVECTOR and RXVECTOR parameters (continued)

2
3
4

RXVECTOR
TXVECTOR
Parameter

5
6 Condition Value
7
8
9
10 (#1260)Integer.
11
APEP_LENGTH

12 If 0 and FORMAT is EHT_MU, indicates an EHT sounding N

13 FORMAT is EHT_MU or
NDP. Otherwise, indicates the number of octets in the range 1 MU (#79
14 EHT_TB
to aPSDUMaxLength in the A-MPDU pre-EOF padding (see 86)
15 Table 36-70 (EHT PHY characteristics)) that is carried in the
16 PSDU.
17
18 See corresponding entry in Table 21-1 (TXVECTOR and RXVECTOR
Otherwise
19 parameters) or Table 27-1 (TXVECTOR and RXVECTOR parameters).
20
21 (#1260)Indicates the number of octets in the PSDU in the
PSDU_LENGTH

22 FORMAT is EHT_MU or range 0 to aPSDUMaxLength octets (see Table 36-70 (EHT

N Y
23 EHT_TB PHY characteristics)). A value of 0 indicates an EHT sounding
24 NDP.
25
26 See corresponding entry in Table 21-1 (TXVECTOR and RXVECTOR
27 Otherwise parameters) or Table 27-1 (TXVECTOR and RXVECTOR
28 parameters).(#3162)
29 (#1531)Indicates the number of spatial streams. (#7987)Note
30 that the terms “space-time stream” and “spatial streams” are
31 equivalent because the EHT PHY does not support STBC.
32 Integer in the range:
33
34 FORMAT is EHT_MU 1–4 per user per MU-MIMO RU in the TXVECTOR. MU Y
35 1–4 per MU-MIMO RU in the RXVECTOR.
36 1–8 per RU assigned to no more than 1 user in the TXVEC-
37 TOR and RXVECTOR.
NUM_STS

38
39 NUM_STS summed over all users per RU is not greater than 8.
40 (#1531)Indicates the number of spatial streams.
41 Integer in the range:
42
43 FORMAT is EHT_TB (#7095)1–4 for an MU-MIMO RU. Y N
44 1–8 for an RU assigned to no more than 1 user.
45 NUM_STS summed over all users per RU is not greater than 8.
46
47 See corresponding entry in Table 21-1 (TXVECTOR and RXVECTOR
48 Otherwise parameters) or Table 27-1 (TXVECTOR and RXVECTOR
49 parameters).(#3162)
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

508 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-1—TXVECTOR and RXVECTOR parameters (continued)

2
3
4

RXVECTOR
TXVECTOR
Parameter

5
6 Condition Value
7
8
9
10 (#1532)Indicates the TXOP duration.
11 Enumerated type or integer:
12 UNSPECIFIED indicates no NAV value specified.
13 0–8448 indicates a value in units of 1 µs that is used to
14 update the NAV for this TXOP (see 26.2.4 (Updating two
15 NAVs)).
16
17 (#7988)The TXOP subfield in U-SIG is computed from the
18 TXVECTOR parameter TXOP_DURATION as follows:
19 TXOP_DURATION = UNSPECIFIED: TXOP = 127.
TXOP_DURATION

20 TXOP_DURATION < 512:

21 FORMAT is EHT_MU or
TXOP = 2  floor(TXOP_DURATION/8). Y Y
22 EHT_TB
(#7988)Otherwise: TXOP = 2  floor((TXOP_DURATION –
23 512)/128) + 1.
24
25 (#7988)The RXVECTOR parameter TXOP_DURATION is
26 computed from the value of the TXOP subfield in U-SIG as
27 follows:
28 TXOP = 127: TXOP_DURATION = UNSPECIFIED.
29 TXOP is an even number:
30 TXOP_DURATION = 8  TXOP/2.
31 (#7988)Otherwise:
32 TXOP_DURATION = 512 + 128  (TXOP – 1)/2.
33
34 See corresponding entry in Table 27-1 (TXVECTOR and RXVECTOR
Otherwise
35 parameters).
36
37 (#4897)Indicates the spatial reuse parameter value. There is
38 one value of the parameter for an EHT MU PPDU. See the
39 Spatial Reuse field definition 36.3.12.8.3 (Common field for
40 FORMAT is OFDMA transmission) and 36.3.12.8.4 (Common field for
Y Y
41 EHT_MU(#1260) non-OFDMA transmission).
42
43 (#4897)See 35.11 (EHT Spatial reuse operation(#5444)) and
SPATIAL_REUSE

44 35.12.2 (SPATIAL_REUSE(#6799)).
45
46 (#4897)Indicates the spatial reuse parameter value. There are
47 one to two values of the parameter for an EHT TB PPDU, with
48 the number of values present dependent on the bandwidth of
49 the PPDU. See the Spatial Reuse field definition in 36.3.12.7.2
FORMAT is EHT_TB(#1260) Y Y
50 (Content).
51
52 (#4897)See 35.11 (EHT Spatial reuse operation(#5444)) and
53 35.12.2 (SPATIAL_REUSE(#6799)).
54 See corresponding entry in Table 27-1 (TXVECTOR and RXVECTOR
55 Otherwise
parameters).(#1533)(#1260)(#3162)
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 509

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-1—TXVECTOR and RXVECTOR parameters (continued)

2
3
4

RXVECTOR
TXVECTOR
Parameter

5
6 Condition Value
7
8
9
10 For the TXVECTOR, indicates the 9-bit RU Allocation-1 and
11 RU Allocation-2 (if present) subfields in the Common field for
12 a DL OFDMA transmission.
13
14 9 bits for a 20 MHz PPDU;
15 18 bits for a 40 MHz PPDU;
16 36 bits for a 80 MHz PPDU;
17 72 bits for a 160 MHz PPDU;
18 144 bits for a 320 MHz-1 or 320 MHz-2 PPDU.
19 FORMAT is EHT_MU and
20 EHT_PPDU_TYPE is equal Y Y
21 to 0(#7125)(#1534)(#1535)
See 36.3.12.8.3 (Common field for OFDMA transmission) for
22 details.
23
24 (#5461)For the RXVECTOR, 9 bits using the same encoding
25 of PS160 (B39) and RU Allocation (B12–B19) subfields in the
26 EHT variant User Info field are used to indicate the
27 (#8089)RU/MRU allocated to the user in the whole band.
28
29
RU_ALLOCATION

See 9.3.1.22 (Trigger frame format) for details.

30
31 FORMAT is EHT_MU and
32 EHT_PPDU_TYPE is not Not present(#7121).
33 equal to 0(#1534)(#1535)
34
35 9 bits are used to indicate the (#8089)RU/MRU allocated to
36 the user in the whole band.
FORMAT is EHT_TB Y N
37
38 See 9.3.1.22 (Trigger frame format) for details.
39
40 FORMAT is NON_HT, For the TXVECTOR, indicates the active (#8089)RUs/MRUs.
41 NON_HT_MODULATION is
42 NON_HT_DUP_OFDM, and 36 bits for an 80 MHz PPDU;
43 CH_BANDWIDTH is not 72 bits for a 160 MHz PPDU;
44 CBW20 or 144 bits for a 320 MHz PPDU.
45 CBW40(#1534)(#1535) O
46 (#4898)For each 9 bits, only the following values are allowed: (#49 N
47 26 (000011010 in binary representation) 82)
48 64 (001000000 in binary representation)
49
50 See 36.3.12.8.3 (Common field for OFDMA transmission)
51 (#4898)and 36.3.15 (Non-HT duplicate transmission) for
52 details.
53 See corresponding entry in Table 27-1 (TXVECTOR and RXVECTOR
54 Otherwise
parameters).
55
56
57
58
59
60
61
62
63
64
65

510 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-1—TXVECTOR and RXVECTOR parameters (continued)

2
3
4

RXVECTOR
TXVECTOR
Parameter

5
6 Condition Value
7
8
9
10 FORMAT is EHT_MU and For an RU or MRU with no more than 1 user allocated, set to 1
11 APEP_LENGTH is not if a beamforming steering matrix is applied to this non-MU MU O
12 0(#1260)(#1536) MIMO allocation and set to 0 otherwise.
13
BEAMFORMED

14 FORMAT is EHT_MU and Set to 1 if a beamforming steering matrix is applied to the EHT
15 APEP_LENGTH is modulated fields and set to 0 otherwise. Y O
16 0(#1260)(#1536)
17
18 For an RU or MRU with no more than 1 user allocated, set to 1
FORMAT is
19 if a beamforming steering matrix is applied to this non-MU Y O
EHT_TB(#1260)(#1536)
20 MIMO allocation and set to 0 otherwise.
21
22 See corresponding entry in Table 21-1 (TXVECTOR and RXVECTOR
Otherwise
23 parameters) or Table 27-1 (TXVECTOR and RXVECTOR parameters).
24 Indicates the type of EHT-LTF.
25
EHT_LTF_TYPE

Enumerated type:
26 FORMAT is EHT_MU or 1EHT-LTF indicates an 1 EHT-LTF.
27 Y Y
EHT_TB 2EHT-LTF indicates a 2 EHT-LTF.
28 4EHT-LTF indicates a 4 EHT-LTF.
29 See 36.3.12.10 (EHT-LTF).
30
31 Otherwise Not present.(#1537)(#2777)(#1260)
32
33 (#1260)Indicates the number of OFDM symbols in the EHT-
34 LTF field.
NUM_EHT_LTF

35
36 FORMAT is EHT_MU or See Table 36-33 (Common field for OFDMA transmission),
Y N
37 EHT_TB Table 36-36 (Common field for non-OFDMA transmission to
38 a single user and non-OFDMA transmission to multiple users),
39 Table 36-37 (Common field for EHT sounding NDP), and
40 36.3.12.10 (EHT-LTF).
41
42 Otherwise Not present.
43
Set to the starting spatial stream number minus 1 (spatial
STARTING_STS_NUM

44
45 FORMAT is EHT_TB(#2778) streams in a given PPDU transmission are numbered starting Y N
46 from 1)
47 FORMAT is
48 Not present(#7121).
EHT_MU(#2778)
49
50
51 See corresponding entry in Table 27-1 (TXVECTOR and RXVECTOR
Otherwise
52 parameters).
53
54 The nominal packing padding as defined in 9.4.2.295c.5 (EHT
PACKET_PADDING

55 FORMAT is PPE Thresholds field).

MU N
NOMINAL_

56 EHT_MU(#1538)
57 Possibles values are 0 µs, 8 µs, 16 µs, and 20 µs.
58
FORMAT is EHT_TB(#1538) Not present(#7121).
59
60 See corresponding entry in Table 27-1 (TXVECTOR and RXVECTOR
61 Otherwise
parameters).
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 511

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-1—TXVECTOR and RXVECTOR parameters (continued)

2
3
4

RXVECTOR
TXVECTOR
Parameter

5
6 Condition Value
7
8
9
10 (#1260)Indicates the method used to trigger this (#7654)EHT
11 TB PPDU transmission.
12 FORMAT is EHT_TB Enumerated type: Y N
TRIGGER_

13
METHOD

TRIGGER_FRAME for Trigger frame.

14 TRS for TRS Control subfield.
15
16 FORMAT is EHT_MU Not present(#7121).
17
18 See corresponding entry in Table 27-1 (TXVECTOR and RXVECTOR
Otherwise
19 parameters).
20
21 (#1260)When TRIGGER_METHOD is TRS, indicates the
duration of the PE field to be transmitted. A value 0, 4, 8, 12,
DEFAULT_PE_

22 FORMAT is EHT_TB Y N
16 or 20(#7991) indicating the PE field duration in µs.
DURATION

23
24 Otherwise not present.
25 FORMAT is EHT_MU Not present(#7121).
26
27 See corresponding entry in Table 27-1 (TXVECTOR and RXVECTOR
28 Otherwise
parameters).
29
30 (#1260)Set to a value in the range of 0 to 63 (see 35.10 (Rules
BSS_COLOR

FORMAT is EHT_MU or
31 for setting some TXVECTOR parameters for PPDUs Y Y
EHT_TB
32 transmitted by an EHT STA)).
33
34 See corresponding entry in Table 27-1 (TXVECTOR and RXVECTOR
Otherwise
35 parameters).
36
(#1260)Set to 1 if the PPDU is addressed to an AP.
UPLINK_FLAG

37 FORMAT is EHT_MU Y Y
38 Set to 0 otherwise.
39 FORMAT is EHT_TB Not present(#7121).
40
41 See corresponding entry in Table 27-1 (TXVECTOR and RXVECTOR
42 Otherwise
parameters).
43
44 (#1260)Indicates the list of STA-IDs for an EHT MU PPDU Y
45 FORMAT is EHT_MU (see 35.10 (Rules for setting some TXVECTOR parameters for MU (#71
46 PPDUs transmitted by an EHT STA)). 27)
STA_ID

47
48 FORMAT is EHT_TB Not present(#7121).
49
50 See corresponding entry in Table 27-1 (TXVECTOR and RXVECTOR
Otherwise
51 parameters).(#1260)
52 FORMAT is EHT_TB (#1260)When TRIGGER_METHOD is TRIGGER_FRAME,
PADDING_FACTOR

53
EHT_PRE_FEC_

indicates the pre-FEC padding factor used by the EHT TB Y N

54 PPDU transmission. Otherwise not present.
55
56 FORMAT is EHT_MU Not present(#7121).
57
58 Otherwise See corresponding entry in Table 27-1 (TXVECTOR and RXVECTOR
59 parameters).
60
61
62
63
64
65

512 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-1—TXVECTOR and RXVECTOR parameters (continued)

2
3
4

RXVECTOR
TXVECTOR
Parameter

5
6 Condition Value
7
8
9
10 FORMAT is EHT_TB and (#1260)Indicates PE disambiguity for the EHT TB PPDU
DISAMBIGUITY

11
EHT_TB_PE_

TRIGGER_METHOD is transmission.
12 Y N
TRIGGER_FRAME Set to 0 to indicate no PE disambiguity
13 Set to 1 to indicate PE disambiguity
14
15
16 Otherwise Not present(#7121).
17
18 FORMAT is EHT_TB Indicates the value to be set for the Disregard field in U-SIG-1. Y N
TB_DISREGARD_
IN_USIG1(#5471)

19
20
21
22 Otherwise Not present(#7121).
23
24
25
26 FORMAT is EHT_TB Indicates the value to be set for the Validate field in U-SIG-2. Y N
IN_USIG2(#5471)
TB_VALIDATE_

27
28
29
30 Otherwise Not present(#7121).
31
32
33
34 FORMAT is EHT_TB Indicates the value to be set for the Disregard field in U-SIG-2. Y N
TB_DISREGARD_
IN_USIG2(#5471)

35
36
37
38
39 Otherwise Not present(#7121).
40
41
42
43 FORMAT is EHT_MU For an RU or MRU, set to the power boost factor of the RU or
_FACTOR(#4630)
POWER_BOOST

44 MRU respectively in the range of 0.5 to 2 (see 35.12.1.2 MU N

45 (POWER_BOOST_FACTOR(#4630))).
46
47
48 Otherwise Not present(#7121).
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 513

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-1—TXVECTOR and RXVECTOR parameters (continued)

2
3
4

RXVECTOR
TXVECTOR
Parameter

5
6 Condition Value
7
8
9
10 The first 11 bits of the scrambling sequence (the eleven LSB
INITIAL_VALUE(#7741)

11 bits of the Scrambler Initialization field prior to descrambling),

12 FORMAT is EHT_MU N Y
with the first bit of the scrambling sequence being the LSB of
SCRAMBLER_

13 SCRAMBLER_INITIAL_VALUE.
14
15 FORMAT is EHT_TB Not present
16
17
18 See corresponding entry in Table 27-1 (TXVECTOR and RXVECTOR
Otherwise
19 parameters).
20
21 (#3162)(#4643)Further TXVECTOR and RXVECTOR parameters for transmitting or receiving a DSSS, HR/DSSS,
22 OFDM, ERP, HT, VHT or HE PPDU, as determined by the FORMAT and NON_HT_MODULATION parameters, are
23 defined in:
24 — DSSS PPDU: Table 15-1 (TXVECTOR parameters) and Table 15-2 (RXVECTOR parameters), excepting the
25 LENGTH and DATARATE parameters
26
27 — HR/DSSS PPDU: Table 16-5 (Parameter vectors), excepting the LENGTH and DATARATE parameters
28 — OFDM PPDU: Table 17-1 (TXVECTOR parameters) and Table 17-2 (RXVECTOR parameters), excepting the
29 LENGTH and DATARATE parameters
30 — ERP PPDU: Table 18-1 (TXVECTOR parameters) and Table 18-3 (RXVECTOR parameters), excepting the
31
LENGTH and DATARATE parameters
32
33 — HT PPDU: Table 19-1 (TXVECTOR and RXVECTOR parameters)
34 — VHT PPDU: Table 21-1 (TXVECTOR and RXVECTOR parameters)
35 — HE PPDU: Table 27-1 (TXVECTOR and RXVECTOR parameters)
36
37 NOTE—In the “TXVECTOR” and “RXVECTOR” columns, the following apply:
38
Y = Present; N = Not present; O = Optional;
39
40 (#7650)MU is only present in the TXVECTOR column for an EHT MU PPDU and indicates that the TXVECTOR
41 parameter is present per user. Parameters specified to be present per user are conceptually supplied as an array of values
42 indexed by u, where u takes values 0 to the number of users minus 1.
43
44
45
46 36.2.3 TRIGVECTOR parameters
47
48 The TRIGVECTOR is carried in a PHY-TRIGGER.request primitive and provides the PHY of the AP with
49 the parameters needed to receive an EHT TB PPDU over each assigned RU (#5809)or MRU. The
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

514 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 parameters in Table 36-2 (TRIGVECTOR parameters(#1539)) are defined as part of the TRIGVECTOR
2 parameter list in the PHY-TRIGGER.request primitive.
3
4
5
6 Table 36-2—TRIGVECTOR parameters(#1539)
7
8
9 Parameter Value
10
11 CH_BANDWIDTH (#5810)Indicates the bandwidth in the U-SIG of the expected EHT TB
12 PPDU(s).
13 Enumerated type:
14 CBW20 for 20 MHz.
15 CBW40 for 40 MHz.
16 CBW80 for 80 MHz.
17 CBW160 for 160 MHz.
18 CBW320-1 for 320-1 MHz.
19 CBW320-2 for 320-2 MHz.
20 UL_LENGTH Indicates the value of the L-SIG LENGTH field of the expected EHT TB
21 PPDU(s).
22
23 (#6825)NOTE—The UL_LENGTH in TRIGVECTOR is equal to the value of
24 the UL LENGTH subfield in a Trigger frame plus 2.
25
26 GI_AND_EHT_LTF_TYPE (#5715)Indicates the EHT-LTF type and GI duration combination of the
27 expected EHT TB PPDU(s).
28 Enumerated type:
29 1EHT-LTF + 1.6 µs GI.
30 2EHT-LTF + 1.6 µs GI.
31 4EHT-LTF + 3.2 µs GI.
32
33 NUM_EHT_LTF_SYMBOLS Indicates the number of OFDM symbols present in the EHT-LTF field of the
34 expected EHT TB PPDU(s).
35 Set to 0 for 1 OFDM symbol.
36 Set to 1 for 2 OFDM symbols.
37 Set to 2 for 4 OFDM symbols.
38 Set to 3 for 6 OFDM symbols.
39 Set to 4 for 8 OFDM symbols.
40 LDPC_EXTRA_SYMBOL Indicates the status of the LDPC extra symbol segment in the expected EHT
41 TB PPDU(s).
42 Set to 1 if LDPC extra symbol segment is present.
43 Set to 0 otherwise.
44
45 PRE_FEC_PADDING_FACTOR Indicates the pre-FEC padding factor for the expected EHT TB PPDU.
46 Value range:
47 Set to 0 to indicate a pre-FEC padding factor of 4.
48 Set to 1 to indicate a pre-FEC padding factor of 1.
49 Set to 2 to indicate a pre-FEC padding factor of 2.
50 Set to 3 to indicate a pre-FEC padding factor of 3.
51
52 PE_DISAMBIGUITY Indicates the PE disambiguity of the expected EHT TB PPDU.
53 Value range:
54 Set to 0 to indicate no PE disambiguity.
55 Set to 1 to indicate PE disambiguity.
56
57 AID12_LIST Each entry of AID12_LIST is (12-bit) AID of the corresponding EHT TB
58 PPDU.
59 See the AID12 subfield description in 9.3.1.22.1.2.2 (EHT variant User Info
60 field) and Table 9-51 (AID12 subfield encoding) for more information of each
61 entry.
62
63 RU_ALLOCATION_LIST 9 bits are used per STA to indicate the RU allocated in the whole bandwidth.
64 See the RU Allocation subfield description in 9.3.1.22.1.2.2 (EHT variant User
65 Info field) for more information of each entry.

Copyright © 2022 IEEE. All rights reserved. 515

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-2—TRIGVECTOR parameters(#1539) (continued)

2
3
4 Parameter Value
5
6 FEC_CODING_LIST Each entry of FEC_CODING_LIST indicates the coding type of the
7 corresponding EHT TB PPDU from an EHT STA. See the UL FEC Coding
8 Type subfield description in 9.3.1.22.1.2.2 (EHT variant User Info field) for
9 more information of each entry
10
11 EHT_MCS_LIST Each entry of EHT_MCS_LIST indicates the EHT-MCS of the corresponding
12 EHT TB PPDU from an EHT STA. See the UL EHT-MCS subfield description
13 in 9.3.1.22.1.2.2 (EHT variant User Info field) for more information of each
14 entry.
15
16 SS_ALLOCATION_LIST Each entry of SS_ALLOCATION_LIST indicates the spatial streams of the
17 corresponding EHT TB PPDU from an EHT STA. See the SS Allocation
18 subfield description in 9.3.1.22.1.2.2 (EHT variant User Info field) for more
19 information of each entry.
20
21
22 36.2.4 PHY CONFIG_VECTOR
23
24
25 The PHYCONFIG_VECTOR carried in a PHY-CONFIG.request primitive for an EHT PHY contains an
26 OPERATING_CHANNEL parameter, which identifies the operating or primary channel. The PHY shall set
27 dot11CurrentPrimaryChannel to the value of this parameter.
28
29
The PHYCONFIG_VECTOR carried in a PHY-CONFIG.request primitive for an EHT PHY contains a
30
31 CHANNEL_WIDTH parameter, which identifies the operating channel width and takes one of the values
32 20 MHz, 40 MHz, 80 MHz, 160 MHz, and 320 MHz. (#4624)The PHY shall set
33 dot11EHTCurrentChannelWidth to the value of this parameter.
34
35
The PHYCONFIG_VECTOR carried in a PHY-CONFIG.request primitive for an EHT PHY contains a
36
37 CENTER_FREQUENCY_SEGMENT_0 parameter, which identifies the center frequency of the channel
38 and takes a value between 1 and 255. The PHY shall set dot11EHTCurrentChannelCenterFrequencyIndex0
39 to the value of this parameter.
40
41
(#4627)The PHYCONFIG_VECTOR carried in a PHY-CONFIG.request primitive for an EHT PHY
42
43 contains a DISABLED_SUBCHANNEL_BITMAP parameter, which identifies the 20 MHz subchannels
44 that are punctured in an EHT BSS. The PHY shall set dot11EhtDisabledSubchannelBitmap to the value of
45 this parameter.
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

516 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 36.2.5 Effect of CH_BANDWIDTH parameter on PPDU format

2
3
Table 36-3 (Interpretation of FORMAT, NON_HT_MODULATION, and CH_BANDWIDTH parameters)
4
5 shows the valid combinations of the FORMAT, NON_HT_MODULATION, and CH_BANDWIDTH
6 parameters and the corresponding PPDU format. Other combinations are reserved.
7
8
9 Table 36-3—Interpretation of FORMAT, NON_HT_MODULATION, and CH_BANDWIDTH
10
parameters
11
12
13 NON_HT_
14 FORMAT CH_BANDWIDTH PPDU format
MODULATION
15
16 EHT_MU, N/A CBW20 The STA transmits an EHT PPDU of 20 MHz
17 EHT_TB bandwidth. If the BSS bandwidth is wider than
18 20 MHz, then the transmission shall use the primary
19 20 MHz channel.
20
21 EHT_MU, N/A CBW40 The STA transmits an EHT PPDU of 40 MHz
22 EHT_TB bandwidth. If the BSS bandwidth is wider than
23 40 MHz, then the transmission shall use the primary
24 40 MHz channel.
25
26 EHT_MU, N/A CBW80 The STA transmits an EHT PPDU of 80 MHz
27 EHT_TB bandwidth. If the BSS bandwidth is wider than
28 80 MHz, then the transmission shall use the primary
29 80 MHz channel.
30
31 EHT_MU, N/A CBW160 The STA transmits an EHT PPDU of 160 MHz
32 EHT_TB bandwidth. If the BSS bandwidth is wider than
33 160 MHz, then the transmission shall use the
34 primary 160 MHz channel.
35
36 EHT_MU, N/A (#5718)CBW320-1 The STA transmits an EHT PPDU of 320 MHz
37 EHT_TB CBW320-2 bandwidth.
38 (#5718)NOTE—The CH_BANDWIDTH of
39 CBW320-1 and CBW320-2 is interpreted as
40 CBW320 for the transmission of an EHT PPDU of
41 320 MHz bandwidth.
42
43 NON_HT OFDM CBW20 See Table 21-2 (Interpretation of FORMAT,
44 NON_HT_MODULATION, CH_BANDWIDTH,
45 and CH_OFFSET parameters).
46
47 NON_HT NON_HT_DUP_ CBW40 See Table 21-2 (Interpretation of FORMAT,
48 OFDM NON_HT_MODULATION, CH_BANDWIDTH,
49 and CH_OFFSET parameters).
50
51 NON_HT NON_HT_DUP_ CBW80 If INACTIVE_SUBCHANNELS is not present, see
52 OFDM Table 21-2 (Interpretation of FORMAT,
53 NON_HT_MODULATION, CH_BANDWIDTH,
54 and CH_OFFSET parameters).
55
56 If INACTIVE_SUBCHANNELS is present (see
57 35.12.5 (INACTIVE_SUBCHANNELS(#6686))
58 and 26.11.7 (INACTIVE_SUBCHANNELS and
59 RU_ALLOCATION)), the STA transmits a
60 punctured NON-HT PPDU of 80 MHz bandwidth.
61 If the BSS bandwidth is wider than 80 MHz, then
62 the transmission shall use the primary 80 MHz
63 channel. Primary 20 MHz is not punctured.
64
65

Copyright © 2022 IEEE. All rights reserved. 517

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-3—Interpretation of FORMAT, NON_HT_MODULATION, and CH_BANDWIDTH

2 parameters (continued)
3
4
5 NON_HT_
6 FORMAT CH_BANDWIDTH PPDU format
MODULATION
7
8 NON_HT NON_HT_DUP_ CBW160 If INACTIVE_SUBCHANNELS is not present, see
9 OFDM Table 21-2 (Interpretation of FORMAT,
10 NON_HT_MODULATION, CH_BANDWIDTH,
11 and CH_OFFSET parameters).
12
13 If INACTIVE_SUBCHANNELS is present (see
14 35.12.5 (INACTIVE_SUBCHANNELS(#6686))
15 and 26.11.7 (INACTIVE_SUBCHANNELS and
16 RU_ALLOCATION)), the STA transmits a
17 punctured NON-HT PPDU of 160 MHz bandwidth.
18 If the BSS bandwidth is wider than 160 MHz, then
19 the transmission shall use the primary 160 MHz
20 channel. Primary 20 MHz is not punctured.
21
22 NON_HT NON_HT_DUP_ CBW320 If INACTIVE_SUBCHANNELS is not present, the
23 OFDM STA transmits a NON-HT PPDU of 320 MHz
24 bandwidth using sixteen adjacent 20 MHz channels
25 as defined in 36.3.15 (Non-HT duplicate
26 transmission).
27
28 If INACTIVE_SUBCHANNELS is present (see
29 35.12.5 (INACTIVE_SUBCHANNELS(#6686))),
30 the STA transmits a punctured NON-HT PPDU of
31 320 MHz bandwidth. Primary 20 MHz is not
32 punctured.
33
34 HT_MF, See Table 27-3 (Interpretation of FORMAT, NON_HT_MODULATION and CH_BANDWIDTH
35 HT_GF, parameters), Table 21-2 (Interpretation of FORMAT, NON_HT_MODULATION,
36 VHT, CH_BANDWIDTH, and CH_OFFSET parameters), and Table 19-2 (Interpretation of FORMAT,
37 HE_SU, CH_BANDWIDTH, and CH_OFFSET parameters).
38 HE_MU,
39 HE_ER_SU,
40 HE_TB
41
42
43
36.2.6 Support for non-HT, HT, VHT, and HE formats
44
45
46 36.2.6.1 General
47
48 (#1276)When an EHT STA is working on a frequency band that is applicable to a PHY clause, the EHT STA
49
logically contains Clause 15 (DSSS PHY specification for the 2.4 GHz band designated for ISM
50
51 applications), Clause 16 (High rate direct sequence spread spectrum (HR/DSSS) PHY specification),
52 Clause 17 (Orthogonal frequency division multiplexing (OFDM) PHY specification), Clause 18 (Extended
53 Rate PHY (ERP) specification), Clause 19 (High Throughput (HT) PHY specification), Clause 21 (Very
54 High Throughput (VHT) PHY specification), Clause 27 (High Efficiency (HE) PHY specification), and
55
Clause 36 (Extremely high throughput (EHT) PHY specification) PHYs. The MAC interacts with the PHYs
56
57 via the Clause 36 (Extremely high throughput (EHT) PHY specification) PHY service interface, which in
58 turn interacts with the Clause 15 (DSSS PHY specification for the 2.4 GHz band designated for ISM
59 applications), Clause 16 (High rate direct sequence spread spectrum (HR/DSSS) PHY specification),
60 Clause 17 (Orthogonal frequency division multiplexing (OFDM) PHY specification), Clause 18 (Extended
61
Rate PHY (ERP) specification), Clause 19 (High Throughput (HT) PHY specification), Clause 21 (Very
62
63 High Throughput (VHT) PHY specification), and Clause 27 (High Efficiency (HE) PHY specification) PHY
64 service interfaces when applicable as shown in Figure 36-1 (PHY interaction on transmit for various PPDU
65

518 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 formats(#7992)), Figure 36-2 (PHY interaction on receive for various PPDU formats(#7992)), and
2 Figure 36-3 (PHY-CONFIG and CCA interaction with various PPDU formats(#7992)).
3
4 Clause 36 PHY-TXSTART.request(TXVECTOR)
Clause 36
5 PHY-TXSTART.confirm
PHY-DATA.request

6 PHY-DATA.confirm
PHY-TXEND.request
PHY-TXEND.confirm
7 FORMAT = HE_SU, HE_ER_SU, FORMAT = VHT FORMAT = HT FORMAT = NON_HT FORMAT = NON_HT
FORMAT = EHT_MU
8 HE_MU and HE_TB NON_HT_MODULATION
NON_HT_DUP_OFDM
and EHT_TB

9
10
11 36.2.6.5 36.2.6.4 36.2.6.3 36.2.6.2
Clause 36
transmit
T T
12 Clause 27
PHY-TXSTART.confirm Clause 27
Clause 21
PHY-TXSTART.confirm Clause 21
Clause 19
PHY-TXSTART.confirm Clause 19
Clause 15, 16, 17, 18
PHY-TXSTART.confirm
Clause 17
PHY-TXSTART.confirm
X
V
procedure X
V
PHY-DATA.request
13 PHY-DATA.confirm
PHY-TXEND.request
PHY-TXSTART.request
(TXVECTOR)
PHY-DATA.request
PHY-DATA.confirm
PHY-TXSTART.request
(TXVECTOR)
PHY-DATA.request
PHY-DATA.confirm
PHY-TXSTART.request
(TXVECTOR)
PHY-DATA.request
PHY-DATA.confirm
Clause 15, 16, 17, 18 PHY-DATA.request
PHY-DATA.confirm
E
C
E
C
PHY-TXEND.request PHY-TXEND.request PHY-TXEND.request PHY-TXSTART.request PHY-TXEND.request
14 PHY-TXEND.confirm PHY-TXEND.confirm PHY-TXEND.confirm PHY-TXEND.confirm (TXVECTOR) PHY-TXEND.confirm T
O
T
O

15 R R

16
17
18
Clause 21 transmit procedure Clause 19 transmit procedure Clause 17 transmit procedure;
Clause 27 transmit procedure (a 20MHz-only non-AP EHTSTA supports VHT (a 20MHz-only non-AP EHTSTA supports Clause 15, 16, 17, 18 transmit procedure 36.3.13 Non-HT Duplicate Clause 36 EHTPPDU
transmissiononlyon MHz channel width) HTtransmission on MHz channel width) PPDU
19
20
21
22
Figure 36-1—PHY interaction on transmit for various PPDU formats(#7992)
23
24
25
26
27 Clause 36 PHY-RXSTART.indication(RXVECTOR)

28
Clause 36
PHY-DATA.indication
PHY-RXEND.indication

29
30
31
32 Clause 15, Clause 16, Clause 17,
Clause 18
Clause 19
PHY-DATA.indication
Clause 21
PHY-DATA.indication
Clause 27
PHY-DATA.indication
33
36.2.6.2 PHY-DATA.indication 36.2.6.3 36.2.6.4 36.2.6.5
PHY-RXEND.indication PHY-RXEND.indication PHY-RXEND.indication PHY-RXEND.indication

34 Clause 15, Clause 16, Clause 17,

Clause 18
PHY-RXSTART.indication
Clause 15, Clause 16,
Clause 17, Clause 18
Clause 19
PHY-RXSTART.indication
Clause 19
receive procedure
(a 20 MHz-only non-AP EHT STA
Clause 21
PHY-RXSTART.indication
Clause 21
receive procedure
(a 20 MHz-only non-AP EHT STA
Clause 27
PHY-RXSTART.indication Clause 27
Clause 36
receive procedure

35 receive procedure (RXVECTOR) supports HT PPDU reception only on 20 (RXVECTOR) supports VHT PPDU reception only on receive procedure
(RXVECTOR) (RXVECTOR)
MHz channel width) 20 MHz channel width)

36 NON_HT
HT VHT HE EHT

37
38
Format Detection

39 NOTE—Not all parameters are shown

40
41 Figure 36-2—PHY interaction on receive for various PPDU formats(#7992)
42
43
44
45
46 Clause 36 PHY-CCARESET.request
47 Clause 36 PHY-CONFIG.request (PHYCONFIG_VECTOR) Clause 36 PHY-CONFIG.confirm PHY-CCARESET.confirm
PHY-CCA.indication
48
49
50 Configure all PHYs Confirm configuration of all PHYs

51 36.2.6.2 36.2.6.3 36.2.6.4 36.2.6.5

The PHY-CCA and PHY-CCARESET primitives from
Clause 15, Clause 16, Clause 17, Clause 18, Clause

52 Clause 15, Clause 16, Clause 19 PHY Clause 21 PHY Clause 27 PHY Clause 15, Clause 16,
19, Clause 21 and Clause 27 are unused (CCA
requirements are defined in Clause 36 instead).
CONFIG.request CONFIG.request Clause 19 PHY Clause 21 PHY
53 CONFIG.request Clause 27 PHY
Clause 17, Clause 18 PHY
CONFIG.request Clause 17, Clause 18 PHY
(PHYCONFIG_ (PHYCONFIG_ (PHYCONFIG_ Clause 36 Clause 36
(PHYCONFIG_

54 VECTOR
VECTOR VECTOR VECTOR
CONFIG.confirm CONFIG.confirm CONFIG.confirm CONFIG.confirm

55
56 Figure 36-3—PHY-CONFIG and CCA interaction with various PPDU formats(#7992)
57
58 (#1276)NOTE—Figure 36-1 (PHY interaction on transmit for various PPDU formats(#7992)), Figure 36-2 (PHY
59 interaction on receive for various PPDU formats(#7992)), and Figure 36-3 (PHY-CONFIG and CCA interaction with
60 various PPDU formats(#7992)) show all possible PHY clauses, not all of which are applicable to any given band.
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 519

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 36.2.6.2 Support for non-HT format

2
3
The behavior of the EHT PHY on receipt of a PHY-TXSTART.request(TXVECTOR) primitive with the
4
5 FORMAT parameter equal to NON_HT and the NON_HT_MODULATION parameter not equal to
6 NON_HT_DUP_OFDM is defined in Clause 15 (DSSS PHY specification for the 2.4 GHz band designated
7 for ISM applications), Clause 16 (High rate direct sequence spread spectrum (HR/DSSS) PHY
8 specification), Clause 17 (Orthogonal frequency division multiplexing (OFDM) PHY specification), and
9
Clause 18 (Extended Rate PHY (ERP) specification) and depends on the parameter
10
11 NON_HT_MODULATION. If the parameter NON_HT_MODULATION is OFDM or
12 NON_HT_DUP_OFDM, then the following additional requirements apply:
13 — The requirements in 21.3.9.1 (Transmission of 20 MHz NON_HT PPDUs with more than one
14
15 transmit chain)
16 — The requirements in 21.3.17.1 (Transmit spectrum mask) (#4645)and 36.3.19.1 (Transmit spectral
17 mask) instead of the requirements in 17.3.9.3 (Transmit spectrum mask)
18
19 — The requirements in (#4645)36.3.19.3 (Transmit center frequency and symbol clock frequency
20 tolerance) instead of the requirements in (#4645)17.3.9.5 (Transmit center frequency tolerance) and
21 17.3.9.6 (Symbol clock frequency tolerance)
22
23 — (#4645)The requirements in 36.3.19.4.2 (Transmit center frequency leakage) instead of the
24 requirements in 17.3.9.7.2 (Transmitter center frequency leakage)
25 — (#4645)The requirements in 36.3.19.2 (Spectral flatness) and the requirements in
26
27 17.3.9.7.3 (Transmitter spectral flatness)
28 — (#1278)(#2991)(#3040)The requirements in 36.3.19.1.3 (Additional restrictions of preamble
29 puncturing for non-HT duplicate PPDU)
30
31
32 The modulation equation for non-HT duplicate transmission is defined in 36.3.15 (Non-HT duplicate
33 transmission).
34
35 The EHT (#4634)TXVECTOR parameters in Table 36-1 (TXVECTOR and RXVECTOR parameters) are
36
mapped to Clause 15 (DSSS PHY specification for the 2.4 GHz band designated for ISM applications),
37
38 Clause 16 (High rate direct sequence spread spectrum (HR/DSSS) PHY specification),
39 Clause 17 (Orthogonal frequency division multiplexing (OFDM) PHY specification), and
40 Clause 18 (Extended Rate PHY (ERP) specification) TXVECTOR parameters according to Table 36-4
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

520 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (Mapping of the EHT PHY parameters for non-HT operation). The EHT PHY parameters not listed in the
2 table are not present.
3
4
5
6 Table 36-4—Mapping of the EHT PHY parameters for non-HT operation
7
8
9 5 GHz and
2.4 GHz
10 2.4 GHz 6 GHz operation
operation defined
11 operation defined 2.4 GHz defined by
by Clause 15
12 by Clause 16 operation defined Clause 17
(DSSS PHY
13 EHT PHY (High rate direct by Clause 18 (Orthogonal Parameter
specification for
14 parameter sequence spread (Extended Rate frequency list
the 2.4 GHz band
15 spectrum (HR/ PHY (ERP) division
designated for
16 DSSS) PHY specification) multiplexing
ISM
17 specification) (OFDM) PHY
applications)
18 specification)
19
20 TXVECTOR/
L_LENGTH LENGTH LENGTH LENGTH LENGTH
21 RXVECTOR
22 TXVECTOR/
23 L_DATARATE DATARATE DATARATE DATARATE DATARATE
RXVECTOR
24
25 TXPWR_LEV TXPWR_LEVEL TXPWR_LEVEL TXPWR_LEVEL TXPWR_LEVEL
26 TXVECTOR
EL_INDEX _INDEX _INDEX _INDEX _INDEX
27
28 RSSI RSSI RSSI RSSI RSSI RXVECTOR
29
30 TXVECTOR/
SERVICE SERVICE SERVICE SERVICE SERVICE
31 RXVECTOR
32
33 RCPI RCPI RCPI RCPI RCPI RXVECTOR
34 CH_BANDWI
35 CH_BANDWIDT CH_BANDWIDT TXVECTOR/
DTH_IN_NON discard discard
36 H_IN_NON_HT H_IN_NON_HT RXVECTOR
_HT
37
38 DYN_BANDW
39 DYN_BANDWID DYN_BANDWID TXVECTOR/
IDTH_IN_NO discard discard
40 TH_IN_NON_HT TH_IN_NON_HT RXVECTOR
N_HT
41
42 OPERATING_ OPERATING_ PHYCONFIG
discard discard discard
43 CHANNEL CHANNEL _VECTOR
44
45
46
47 The behavior of the EHT PHY on receipt of a PHY-TXSTART.request(TXVECTOR) primitive with the
48 FORMAT parameter equal to NON_HT and the NON_HT_MODULATION parameter equal to
49 NON_HT_DUP_OFDM is defined in 36.3.15 (Non-HT duplicate transmission).
50
51
52 To support the non-HT format, the EHT PHY, on receipt of a
53 PHY-CONFIG.request(PHYCONFIG_VECTOR) primitive, behaves as if it were a Clause 15 (DSSS PHY
54 specification for the 2.4 GHz band designated for ISM applications), Clause 16 (High rate direct sequence
55 spread spectrum (HR/DSSS) PHY specification), Clause 17 (Orthogonal frequency division multiplexing
56
(OFDM) PHY specification), or Clause 18 (Extended Rate PHY (ERP) specification) PHY that had received
57
58 a PHY-CONFIG.request(PHYCONFIG_VECTOR) primitive but without the PHYCONFIG_VECTOR
59 parameters (#4624)CHANNEL_WIDTH and CENTER_FREQUENCY_SEGMENT_0.
60
61 As defined in 36.3.22 (EHT receive procedure), once a PPDU is received and detected as a non-HT PPDU,
62
the behavior of the EHT PHY is defined in Clause 15 (DSSS PHY specification for the 2.4 GHz band
63
64 designated for ISM applications), Clause 16 (High rate direct sequence spread spectrum (HR/DSSS) PHY
65 specification), Clause 17 (Orthogonal frequency division multiplexing (OFDM) PHY specification), or

Copyright © 2022 IEEE. All rights reserved. 521

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Clause 18 (Extended Rate PHY (ERP) specification) depending on the PPDU format. The RXVECTOR
2 parameters from the Clause 15 (DSSS PHY specification for the 2.4 GHz band designated for ISM
3
applications), Clause 16 (High rate direct sequence spread spectrum (HR/DSSS) PHY specification),
4
5 Clause 17 (Orthogonal frequency division multiplexing (OFDM) PHY specification), and
6 Clause 18 (Extended Rate PHY (ERP) specification) are mapped to the EHT (#4634)RXVECTOR
7 parameters as defined in Table 36-4 (Mapping of the EHT PHY parameters for non-HT operation). The
8 EHT PHY parameters not listed in the table are not present.
9
10
11 36.2.6.3 Support for HT format
12
13 The behavior of an EHT PHY on receipt of a PHY-TXSTART.request(TXVECTOR) primitive with the
14 TXVECTOR parameter FORMAT equal to HT_MF or HT_GF is defined in Clause 19 (High Throughput
15
(HT) PHY specification) with the following additional requirements:
16
17 — The requirements in 21.3.9.2 (Transmission of HT PPDUs with more than four transmit chains)
18
— The requirements in 36.3.19.3 (Transmit center frequency and symbol clock frequency tolerance)
19
20 instead of the requirements in 19.3.18.4 (Transmit center frequency tolerance)
21
22 The EHT (#4634)TXVECTOR parameters in Table 36-1 (TXVECTOR and RXVECTOR parameters) are
23 mapped directly to Clause 19 (High Throughput (HT) PHY specification) TXVECTOR parameters in
24
Table 19-1 (TXVECTOR and RXVECTOR parameters). The EHT PHY parameters not listed in
25
26 Table 19-1 (TXVECTOR and RXVECTOR parameters) are not present. The PHY shall use a value of
27 CH_OFFSET in the Clause 19 (High Throughput (HT) PHY specification) TXVECTOR that is consistent
28 with Table 36-3 (Interpretation of FORMAT, NON_HT_MODULATION, and CH_BANDWIDTH
29 parameters). A 20 MHz-only non-AP EHT STA supports HT transmission only on 20 MHz channel width.
30
31
32 On receipt of a PHY-CONFIG.request(PHYCONFIG_VECTOR) primitive, the EHT PHY behaves, for the
33 purposes of HT PPDU transmission and reception, as if it were a Clause 19 (High Throughput (HT) PHY
34 specification) PHY that had received PHY-CONFIG.request(PHYCONFIG_VECTOR) primitive but
35 without the PHYCONFIG_VECTOR parameters (#4624)CHANNEL_WIDTH and
36
CENTER_FREQUENCY_SEGMENT_0 and with the PHYCONFIG_VECTOR parameter
37
38 SECONDARY_CHANNEL_OFFSET set to SECONDARY_CHANNEL_NONE if
39 dot11CurrentChannelWidth indicates 20 MHz, to SECONDARY_CHANNEL_ABOVE if f P20 idx  fS20 idx ,
40 or to SECONDARY_CHANNEL_BELOW otherwise.
41
42
43 As defined in 36.3.22 (EHT receive procedure), once a PPDU is received and detected as an HT PPDU, the
44 behavior of the EHT PHY is defined in Clause 19 (High Throughput (HT) PHY specification). The
45 RXVECTOR parameters in Table 19-1 (TXVECTOR and RXVECTOR parameters) are mapped directly to
46
the RXVECTOR parameters in Table 36-1 (TXVECTOR and RXVECTOR parameters). The EHT PHY
47
48 parameters not listed in Table 19-1 (TXVECTOR and RXVECTOR parameters) are not present. A
49 20 MHz-only non-AP EHT STA supports HT reception only on 20 MHz channel width.
50
51 36.2.6.4 Support for VHT format
52
53
54 The behavior of an EHT PHY on receipt of a PHY-TXSTART.request(TXVECTOR) primitive with the
55 TXVECTOR parameter FORMAT equal to VHT is defined in Clause 21 (Very High Throughput (VHT)
56 PHY specification) except that the requirements in 36.3.19.3 (Transmit center frequency and symbol clock
57 frequency tolerance) apply instead of the requirements in 21.3.17.4.2 (Transmit center frequency tolerance).
58
59
60 The EHT (#4634)TXVECTOR parameters in Table 36-1 (TXVECTOR and RXVECTOR parameters) are
61 mapped directly to the Clause 21 (Very High Throughput (VHT) PHY specification) TXVECTOR
62 parameters in Table 21-1 (TXVECTOR and RXVECTOR parameters). The EHT PHY parameters not listed
63 in Table 21-1 (TXVECTOR and RXVECTOR parameters) are not present. The 20 MHz-only non-AP EHT
64
STA supports VHT transmission only on 20 MHz channel width.
65

522 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 On receipt of a PHY-CONFIG.request(PHYCONFIG_VECTOR) primitive, the EHT PHY behaves, for the

2 purposes of VHT PPDU transmission and reception, as if it were a Clause 21 (Very High Throughput (VHT)
3
PHY specification) PHY that received the PHY-CONFIG.request(PHYCONFIG_VECTOR) primitive
4
5 (#4624)except that:
6 — the CHANNEL_WIDTH parameter, if it is equal to 320 MHz, is replaced by 160 MHz
7
8 — the CENTER_FREQUENCY_SEGMENT_0 parameter, if the CHANNEL_WIDTH parameter is
9 equal to 320MHz, is replaced by the center of the primary 160 MHz channel.
10
11 As defined in 36.3.22 (EHT receive procedure), once a PPDU is received and detected as an VHT PPDU,
12
the behavior of the EHT PHY is defined in Clause 21 (Very High Throughput (VHT) PHY specification).
13
14 The RXVECTOR parameters in Table 21-1 (TXVECTOR and RXVECTOR parameters) are mapped
15 directly to the RXVECTOR parameters in Table 36-1 (TXVECTOR and RXVECTOR parameters). The
16 EHT PHY parameters not listed in Table 21-1 (TXVECTOR and RXVECTOR parameters) are not present.
17 A 20 MHz-only non-AP EHT STA supports VHT reception only on 20 MHz channel width.
18
19
20 36.2.6.5 Support for HE format
21
22 The behavior of an EHT PHY on receipt of a PHY-TXSTART.request(TXVECTOR) primitive with the
23 TXVECTOR parameter FORMAT equal to HE_SU, HE_ER_SU, HE_MU, or HE_TB is defined in
24
Clause 27 (High Efficiency (HE) PHY specification) except that the requirements in 36.3.19.3 (Transmit
25
26 center frequency and symbol clock frequency tolerance) apply instead of the requirements in
27 27.3.19.3 (Transmit center frequency and symbol clock frequency tolerance).
28
29 (#7992)The (#4634)TXVECTOR parameters in Table 36-1 (TXVECTOR and RXVECTOR parameters) are
30
mapped directly to the Clause 27 (High Efficiency (HE) PHY specification) TXVECTOR parameters in
31
32 Table 27-1 (TXVECTOR and RXVECTOR parameters). The (#4634)TXVECTOR parameters not listed in
33 Table 27-1 (TXVECTOR and RXVECTOR parameters) are not present.
34
35 On receipt of a PHY-CONFIG.request(PHYCONFIG_VECTOR) primitive, the EHT PHY behaves, for the
36
purposes of HE PPDU transmission and reception, as if it were a Clause 27 (High Efficiency (HE) PHY
37
38 specification) PHY that received the PHY-CONFIG.request(PHYCONFIG_VECTOR) primitive
39 (#4624)except that:
40 — the CHANNEL_WIDTH parameter, if it is equal to 320 MHz, is replaced by 160 MHz
41
42 — the CENTER_FREQUENCY_SEGMENT_0 parameter, if the CHANNEL_WIDTH parameter is
43 equal to 320 MHz, is replaced by the center of the primary 160 MHz channel.
44
45
As defined in 36.3.22 (EHT receive procedure), once a PPDU is received and detected as an HE PPDU, the
46
47 behavior of the EHT PHY is defined in Clause 27 (High Efficiency (HE) PHY specification). (#7992)The
48 RXVECTOR parameters in Table 27-1 (TXVECTOR and RXVECTOR parameters) are mapped directly to
49 the RXVECTOR parameters in Table 36-1 (TXVECTOR and RXVECTOR parameters). The
50 (#4634)RXVECTOR parameters not listed in Table 27-1 (TXVECTOR and RXVECTOR parameters) are
51
not present.
52
53
54
55
36.3 EHT PHY
56
57 36.3.1 Introduction
58
59 (#1241)This subclause provides the procedure by which PSDUs are converted to and from (#7131)PPDUs.
60
61
62 (#1241)During transmission, a PSDU (in the SU case) or one or more PSDUs (in the MU case) are
63 processed (i.e., scrambled and coded) and appended to the PHY preamble to create the PPDU. At the
64 receiver, the PHY preamble is processed to aid in the detection, demodulation, and delivery of the PSDU.
65

Copyright © 2022 IEEE. All rights reserved. 523

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 36.3.2 Subcarrier and resource allocation

2
3
36.3.2.1 Subcarriers and resource allocation in EHT PPDUs(#4636)
4
5
6 (#1958)The EHT PHY subcarrier frequency spacing is identical to HE PHY subcarrier frequency spacing
7 defined in Clause 27 (High Efficiency (HE) PHY specification).
8
9
The EHT tone plan and RU locations for a 20 MHz PPDU and 40 MHz PPDU are identical to those of HE
10
11 PHY defined in 27.3.2 (Subcarrier and resource allocation)(#1542). The EHT tone plan and RU locations
12 for an 80 MHz PPDU (#4638)are given in Figure 36-4 (RU locations in an 80 MHz EHT PPDU(#1984)).
13 (#1279)An EHT PPDU spanning 160 MHz or wider is composed of multiple 80 MHz subblocks.
14 (#4637)The tone plan and RU allocations for each of the 80 MHz subblocks are identical to those of an
15
80 MHz EHT PPDU. (#1242)(#1282)(#2691)(#2944)(#2945)(#3163)If an 80 MHz subblock in (#6782)a
16
17 160 MHz or 320 MHz EHT PPDU is nonpunctured and the entire 80 MHz subblock is used as part of an RU
18 or MRU, the 80 MHz subblock uses a 996-tone RU as shown in Figure 36-4 (RU locations in an 80 MHz
19 EHT PPDU(#1984)). (#7132)(#4637)If an 80 MHz subblock contains RUs smaller than 996 tones or if parts
20 of the 80 MHz subblock are punctured, the 80 MHz subblock uses the tone plan and RU allocations as
21
shown in Figure 36-4 (RU locations in an 80 MHz EHT PPDU(#1984)) excluding the 996-tone RU.
22
23
24 Null Subcarriers Null Subcarriers
25 12 Guard 11 Guard
26
27 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 23 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26
28 DC

29 52 52 26 52 52 52 52 26 52 52 23 52 52 26 52 52 52 52 26 52 52
30 DC

31 106 26 106 106 26 106 23 106 26 106 106 26 106

32 DC

33 242 242 23 242 242

34 DC

35 484 23
DC
484
36 5 null 5 null

37 996

38 5 DC

39
Figure 36-4—RU locations in an 80 MHz EHT PPDU(#1984)
40
41
42 (#6782)(#3094)(#1283)NOTE—For an EHT PPDU using non-OFDMA transmission, the tone plan (#4637)and RU
43 allocations of (#5401)a nonpunctured 80 MHz EHT MU PPDU in EHT DUP mode (described in 36.3.5 (EHT DUP
44 transmission(#7637))) are identical to those of a DL-OFDMA transmission comprising two 484-tone RUs as shown in
45 Figure 36-4 (RU locations in an 80 MHz EHT PPDU(#1984)). (#5463)(#4637)The tone plan and RU allocations of a
46 nonpunctured 80 MHz EHT PPDU that is not an EHT MU PPDU in EHT DUP mode are defined by a 996-tone RU as
47 shown in Figure 36-4 (RU locations in an 80 MHz EHT PPDU(#1984)).
48
49 The locations of the RUs are fixed as defined in Table 36-5 (Data and pilot subcarrier indices for RUs in an
50
51 80 MHz EHT PPDU), Table 36-6 (Data and pilot subcarrier indices for RUs in a 160 MHz EHT PPDU), and
52 Table 36-7 (Data and pilot subcarrier indices for RUs in a 320 MHz EHT PPDU) (#7133)for an 80 MHz,
53 160 MHz, and 320 MHz EHT PPDU, respectively. In these tables, the subcarrier index of 0 corresponds to
54 the DC tone. Negative subcarrier indices correspond to subcarriers with frequency lower than the DC tone,
55 and positive subcarrier indices correspond to subcarriers with frequency higher than the DC tone.
56
57 (#5403)DC subcarriers shown in Figure 36-4 (RU locations in an 80 MHz EHT PPDU(#1984)) are the
58 subcarriers with zero energy, which include the DC tone and the subcarrier indices adjacent to the subcarrier
59 index 0. Guard subcarriers are the subcarriers with zero energy, which are located at the edge of the OFDM
60
61
62
63
64
65

524 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 symbol in the frequency domain. The number of DC subcarriers and guard subcarriers is defined in 36.3.10
2 (Timing-related parameters). (#4790)Null subcarriers are defined in 36.3.2.3 (Null subcarriers(#1606)).
3
4
5
6 Table 36-5—Data and pilot subcarrier indices for RUs in an 80 MHz EHT PPDU
7
8
9 RU type RU index and subcarrier range
10
11 26-tone RU 1 RU 2 RU 3 RU 4 RU 5
12 RU [–499: –474] [–473: –448] [–445: –420] [–419: –394] [–392: –367]
13 RU 6 RU 7 RU 8 RU 9
14 [–365: –340] [–339: –314] [–311: –286] [-–285: –260]
15
16 RU 10 RU 11 RU 12 RU 13 RU 14
17 [–252: –227] [–226: –201] [–198: –173] [–172: –147] [–145: –120]
18
19 RU 15 RU 16 RU 17 RU 18 RU 19
20 [–118: –93] [–92: –67] [–64: –39] [–-38: –13] [not defined]
21
22 RU 20 RU 21 RU 22 RU 23 RU 24
23 [13: 38] [39: 64] [67: 92] [93: 118] [120: 145]
24
25 RU 25 RU 26 RU 27 RU 28
26 [147: 172] [173: 198] [201: 226] [227: 252]
27 RU 29 RU 30 RU 31 RU 32 RU 33
28 [260: 285] [286: 311] [314: 339] [340: 365] [367: 392]
29
30 RU 34 RU 35 RU 36 RU 37
31 [394: 419] [420: 445] [448: 473] [474: 499]
32
33 52-tone RU 1 RU 2 RU3 RU 4
34 RU [–499: –448] [–445: –394] [–365: –314] [–311: –260]
35
36 RU 5 RU 6 RU 7 RU 8
37 [–252: –201] [–198: –147] [–118: –67] [–64: –13]
38
39 RU 9 RU 10 RU 11 RU 12
40 [13: 64] [67: 118] [147: 198] [201: 252]
41 RU 13 RU 14 RU 15 RU 16
42 [260: 311] [314: 365] [394: 445] [448: 499]
43
44 106-tone RU 1 RU 2 RU 3 RU 4
45 RU [–499: –394] [–365: –260] [–252: –147] [–118: –13]
46
47 RU 5 RU 6 RU 7 RU 8
48 [13: 118] [147: 252] [260: 365] [394: 499]
49
50 242-tone RU 1 RU 2 RU 3 RU 4
51 RU [–500: –259] [–253: –12] [12: 253] [259: 500]
52
53 484-tone RU 1 RU 2
54 RU [–500: –259, [12: 253,
55 –253: –12] 259: 500]
56 996-tone RU 1
57 RU [–500: –3,
58 3: 500]
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 525

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-6—Data and pilot subcarrier indices for RUs in a 160 MHz EHT PPDU
2
3
4 RU type RU index and subcarrier range
5
6 26-tone RU 1 RU 2 RU 3 RU 4 RU 5
7 RU [–1011: –986] [–985: –960] [–957: –932] [–931: –906] [–904: –879]
8
9 RU 6 RU 7 RU 8 RU 9
10 [–877: –852] [–851: –826] [–823: –798] [–797: –772]
11
12 RU 10 RU 11 RU 12 RU 13 RU 14
13 [–764: –739] [–738: –713] [–710: –685] [–684: –659] [–657: –632]
14 RU 15 RU 16 RU 17 RU 18 RU 19
15 [–630: –605] [–604: –579] [–576: –551] [–-550: –525] [not defined]
16
17 RU 20 RU 21 RU 22 RU 23 RU 24
18 [–499: –474] [–473: –448] [–445: –420] [–419: –394] [–392: –367]
19
20 RU 25 RU 26 RU 27 RU 28
21 [–365: –340] [–339: –314] [–311: –286] [–285: –260]
22
23 RU 29 RU 30 RU 31 RU 32 RU 33
24 [–252: –227] [–226: –201] [–198: –173] [–172: –147] [–145: –120]
25
26 RU 34 RU 35 RU 36 RU 37
27 [–118: –93] [–92: –67] [–64: –39] [–38: –13]
28 RU 38 RU 39 RU 40 RU 41 RU 42
29 [13: 38] [39: 64] [67: 92] [93: 118] [120: 145]
30
31 RU 43 RU 44 RU 45 RU 46
32 [147: 172] [173: 198] [201: 226] [227: 252]
33
34 RU 47 RU 48 RU 49 RU 50 RU 51
35 [260: 285] [286: 311] [314: 339] [340: 365] [367: 392]
36
37 RU 52 RU 53 RU 54 RU 55 RU 56
38 [394: 419] [420: 445] [448: 473] [474: 499] [not defined]
39
40 RU 57 RU 58 RU 59 RU 60 RU 61
41 [525: 550] [551: 576] [579: 604] [605: 630] [632: 657]
42 RU 62 RU 63 RU 64 RU 65
43 [659: 684] [685: 710] [713: 738] [739: 764]
44
45 RU 66 RU 67 RU 68 RU 69 RU 70
46 [772: 797] [798: 823] [826: 851] [852: 877] [879: 904]
47
48 RU 71 RU 72 RU 73 RU 74
49 [906: 931] [932: 957] [960: 985] [986: 1011]
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

526 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-6—Data and pilot subcarrier indices for RUs in a 160 MHz EHT PPDU (continued)
2
3
4 RU type RU index and subcarrier range
5
6 52-tone RU 1 RU 2 RU 3 RU 4
7 RU [–1011: –960] [–957: –906] [–877: –826] [–823: –772]
8
9 RU 5 RU 6 RU 7 RU 8
10 [–764: –713] [–710: –659] [–630: –579] [–576: –525]
11
12 RU 9 RU 10 RU 11 RU 12
13 [–499: –448] [–445: –394] [–365: –314] [–311: –260]
14 RU 13 RU 14 RU 15 RU 16
15 [–252: –201] [–198: –147] [–118: –67] [–64: –13]
16
17 RU 17 RU 18 RU 19 RU 20
18 [13: 64] [67: 118] [147: 198] [201: 252]
19
20 RU 21 RU 22 RU 23 RU 24
21 [260: 311] [314: 365] [394: 445] [448: 499]
22
23 RU 25 RU 26 RU 27 RU 28
24 [525: 576] [579: 630] [659: 710] [713: 764]
25
26 RU 29 RU 30 RU 31 RU 32
27 [772: 823] [826: 877] [906: 957] [960: 1011]
28 106-tone RU 1 RU 2 RU 3 RU 4
29 RU [–1011: –906] [–877: –772] [–764: –659] [–630: –525]
30
31 RU 5 RU 6 RU 7 RU 8
32 [-499: –394] [–365: –260] [–252: –147] [–118: –13]
33
34 RU 9 RU 10 RU 11 RU 12
35 [13: 118] [147: 252] [260: 365] [394: 499]
36
37 RU 13 RU 14 RU 15 RU 16
38 [525: 630] [659: 764] [772: 877] [906: 1011]
39
40 242-tone RU 1 RU 2 RU 3 RU 4
41 RU [–1012: –771] [–765: –524] [–500: –259] [–253: –12]
42 RU 5 RU 6 RU 7 RU 8
43 [12: 253] [259: 500] [524: 765] [771: 1012]
44
45 484-tone RU 1 RU 2 RU 3 RU 4
46 RU [–1012: –771, [–500: –259, [12: 253, [524: 765,
47 –765: –524] –253: –12] 259: 500] 771: 1012]
48
49 996-tone RU 1 RU 2
50 RU [–1012: –515, [12: 509,
51 –509: –12] 515: 1012]
52
53 2996- RU 1
54 tone RU [–1012: –515,
55 –509: –12,
56 12: 509,
57 515: 1012]
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 527

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-7—Data and pilot subcarrier indices for RUs in a 320 MHz EHT PPDU
2
3
4 RU type RU index and subcarrier range
5
6 26-tone RU 1 RU 2 RU 3 RU 4 RU 5
7 RU [–2035: –2010] [–2009: –1984] [–1981: –1956] [–1955: –1930] [–1928: –1903]
8
9 RU 6 RU 7 RU 8 RU 9
10 [–1901: –1876] [–1875: –1850] [–1847: –1822] [–1821: –1796]
11
12 RU 10 RU 11 RU 12 RU 13 RU 14
13 [–1788: –1763] [–1762: –1737] [–1734: –1709] [–1708: –1683] [–1681: –1656]
14 RU 15 RU 16 RU 17 RU 18 RU 19
15 [–1654: –1629] [–1628: –1603] [–1600: –1575] [–1574: –1549] [not defined]
16
17 RU 20 RU 21 RU 22 RU 23 RU 24
18 [–1523: –1498] [–1497: –1472] [–1469: –1444] [–1443: –1418] [–1416: –1391]
19
20 RU 25 RU 26 RU 27 RU 28
21 [–1389: –1364] [–1363: –1338] [–1335: –1310] [–1309: –1284]
22
23 RU 29 RU 30 RU 31 RU 32 RU 33
24 [–1276: –1251] [–1250: –1225] [–1222: –1197] [–1196: –1171] [–1169: –1144]
25
26 RU 34 RU 35 RU 36 RU 37
27 [–1142: –1117] [–1116: –1091] [–1088: –1063] [–1062: –1037]
28 RU 38 RU 39 RU 40 RU 41 RU 42
29 [–1011: –986] [–985: –960] [–957: –932] [–931: –906] [–904: –879]
30
31 RU 43 RU 44 RU 45 RU 46
32 [–877: –852] [–851: –826] [–823: –798] [–797: –772]
33
34 RU 47 RU 48 RU 49 RU 50 RU 51
35 [–764: –739] [–738: –713] [–710: –685] [–684: –659] [–657: –632]
36
37 RU 52 RU 53 RU 54 RU 55 RU 56
38 [–630: –605] [–604: –579] [–576: –551] [–550: –525] [not defined]
39
40 RU 57 RU 58 RU 59 RU 60 RU 61
41 [–499: –474] [–473: –448] [–445: –420] [–419: –394] [–392: –367]
42 RU 62 RU 63 RU 64 RU 65
43 [–365: –340] [–339: –314] [–311: –286] [–285: –260]
44
45 RU 66 RU 67 RU 68 RU 69 RU 70
46 [–252: –227] [–226: –201] [–198: –173] [–172: –147] [–145: –120]
47
48 RU 71 RU 72 RU 73 RU 74
49 [–118: –93] [–92: –67] [–64: –39] [–38: –13]
50
51 RU 75 RU 76 RU 77 RU 78 RU 79
52 [13: 38] [39: 64] [67: 92] [93: 118] [120: 145]
53
54 RU 80 RU 81 RU 82 RU 83
55 [147: 172] [173: 198] [201: 226] [227: 252]
56 RU 84 RU 85 RU 86 RU 87 RU 88
57 [260: 285] [286: 311] [314: 339] [340: 365] [367: 392]
58
59 RU 89 RU 90 RU 91 RU 92 RU 93
60 [394: 419] [420: 445] [448: 473] [474: 499] [not defined]
61
62 RU 94 RU 95 RU 96 RU 97 RU 98
63 [525: 550] [551: 576] [579: 604] [605: 630] [632: 657]
64
65

528 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-7—Data and pilot subcarrier indices for RUs in a 320 MHz EHT PPDU (continued)
2
3
4 RU type RU index and subcarrier range
5
6 26-tone RU 99 RU 100 RU 101 RU 102
7 RU [659: 684] [685: 710] [713: 738] [739: 764]
8
9 RU 103 RU 104 RU 105 RU 106 RU 107
10 [772: 797] [798: 823] [826: 851] [852: 877] [879: 904]
11
12 RU 108 RU 109 RU 110 RU 111
13 [906: 931] [932: 957] [960: 985] [986: 1011]
14 RU 112 RU 113 RU 114 RU 115 RU 116
15 [1037: 1062] [1063: 1088] [1091: 1116] [1117: 1142] [1144: 1169]
16
17 RU 117 RU 118 RU 119 RU 120
18 [1171: 1196] [1197: 1222] [1225: 1250] [1251: 1276]
19
20 RU 121 RU 122 RU 123 RU 124 RU 125
21 [1284: 1309] [1310: 1335] [1338: 1363] [1364: 1389] [1391: 1416]
22
23 RU 126 RU 127 RU 128 RU 129 RU 130
24 [1418: 1443] [1444: 1469] [1472: 1497] [1498: 1523] [not defined]
25
26 RU 131 RU 132 RU 133 RU 134 RU 135
27 [1549: 1574] [1575: 1600] [1603: 1628] [1629: 1654] [1656: 1681]
28 RU 136 RU 137 RU 138 RU 139
29 [1683: 1708] [1709: 1734] [1737: 1762] [1763: 1788]
30
31 RU 140 RU 141 RU 142 RU 143 RU 144
32 [1796: 1821] [1822: 1847] [1850: 1875] [1876: 1901] [1903: 1928]
33
34 RU 145 RU 146 RU 147 RU 148
35 [1930: 1955] [1956: 1981] [1984: 2009] [2010: 2035]
36
37 52-tone RU 1 RU 2 RU 3 RU 4
38 RU [–2035: –1984] [–1981: –1930] [–1901: –1850] [–1847: –1796]
39
40 RU 5 RU 6 RU 7 RU 8
41 [–1788: –1737] [–1734: –1683] [–1654: –1603] [–1600: –1549]
42 RU 9 RU 10 RU 11 RU 12
43 [–1523: –1472] [–1469: –1418] [–1389: –1338] [–1335: –1284]
44
45 RU 13 RU 14 RU 15 RU 16
46 [–1276: –1225] [–1222: –1171] [–1142: –1091] [–1088: –1037]
47
48 RU 17 RU 18 RU 19 RU 20
49 [–1011: –960] [–957: –906] [–877: –826] [–823: –772]
50
51 RU 21 RU 22 RU 23 RU 24
52 [–764: –713] [–710: –659] [–630: –579] [–576: –525]
53
54 RU 25 RU 26 RU 27 RU 28
55 [–499: –448] [–445: –394] [–365: –314] [–311: –260]
56 RU 29 RU 30 RU 31 RU 32
57 [–252: –201] [–198: –147] [–118: –67] [–64: –13]
58
59 RU 33 RU 34 RU 35 RU 36
60 [13: 64] [67: 118] [147: 198] [201: 252]
61
62 RU 37 RU 38 RU 39 RU 40
63 [260: 311] [314: 365] [394: 445] [448: 499]
64
65

Copyright © 2022 IEEE. All rights reserved. 529

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-7—Data and pilot subcarrier indices for RUs in a 320 MHz EHT PPDU (continued)
2
3
4 RU type RU index and subcarrier range
5
6 52-tone RU 41 RU 42 RU 43 RU 44
7 RU [525: 576] [579: 630] [659: 710] [713: 764]
8
9 RU 45 RU 46 RU 47 RU 48
10 [772: 823] [826: 877] [906: 957] [960: 1011]
11
12 RU 49 RU 50 RU 51 RU 52
13 [1037: 1088] [1091: 1142] [1171: 1222] [1225: 1276]
14 RU 53 RU 54 RU 55 RU 56
15 [1284: 1335] [1338: 1389] [1418: 1469] [1472: 1523]
16
17 RU 57 RU 58 RU 59 RU 60
18 [1549: 1600] [1603: 1654] [1683: 1734] [1737: 1788]
19
20 RU 61 RU 62 RU 63 RU 64
21 [1796: 1847] [1850: 1901] [1930: 1981] [1984: 2035]
22
23 106-tone RU 1 RU 2 RU 3 RU 4
24 RU [–2035: –1930] [–1901: –1796] [–1788: –1683] [–1654: –1549]
25
26 RU 5 RU 6 RU 7 RU 8
27 [–1523: –1418] [–1389: –1284] [–1276: –1171] [–1142: –1037]
28 RU 9 RU 10 RU 11 RU 12
29 [–1011: –906] [–877: –772] [–764: –659] [–630: –525]
30
31 RU 13 RU 14 RU 15 RU 16
32 [–499: –394] [–365: –260] [–252: –147] [–118: –13]
33
34 RU 17 RU 18 RU 19 RU 20
35 [13: 118] [147: 252] [260: 365] [394: 499]
36
37 RU 21 RU 22 RU 23 RU 24
38 [525: 630] [659: 764] [772: 877] [906: 1011]
39
40 RU 25 RU 26 RU 27 RU 28
41 [1037: 1142] [1171: 1276] [1284: 1389] [1418: 1523]
42 RU 29 RU 30 RU 31 RU 32
43 [1549: 1654] [1683: 1788] [1796: 1901] [1930: 2035]
44
45 242-tone RU 1 RU 2 RU 3 RU 4
46 RU [–2036: –1795] [–1789: –1548] [–1524: –1283] [–1277: –1036]
47
48 RU 5 RU 6 RU 7 RU 8
49 [–1012: –771] [–765: –524] [–500: –259] [–253: –12]
50
51 RU 9 RU 10 RU 11 RU 12
52 [12: 253] [259: 500] [524: 765] [771: 1012]
53
54 RU 13 RU 14 RU 15 RU 16
55 [1036: 1277] [1283: 1524] [1548: 1789] [1795: 2036]
56 484-tone RU 1 RU 2 RU 3 RU 4
57 RU [–2036: –1795, [–1524: –1283, [–1012: –771, [–500: –259,
58 –1789: –1548] –1277: –1036] –765: –524] –253: –12]
59
60 RU 5 RU 6 RU 7 RU 8
61 [12: 253, [524: 765, [1036: 1277, [1548: 1789,
62 259: 500] 771: 1012] 1283: 1524] 1795: 2036]
63
64
65

530 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-7—Data and pilot subcarrier indices for RUs in a 320 MHz EHT PPDU (continued)
2
3
4 RU type RU index and subcarrier range
5
6 996-tone RU 1 RU 2 RU 3 RU 4
7 RU [–2036: –1539, [–1012: –515, [12: 509, [1036: 1533,
8 –1533: –1036] –509: –12] 515: 1012] 1539: 2036]
9
10 2996- RU 1 RU 2
11 tone RU [–2036: –1539, [12: 509,
12 –1533: –1036, 515: 1012,
13 –1012: –515, 1036: 1533,
14 –509: –12] 1539: 2036]
15
16 4996- RU 1
17 tone RU [–2036: –1539,
18 –1533: –1036,
19 –1012: –515,
20 –509: –12,
21 12: 509,
22 515: 1012,
23 1036: 1533,
24 1539: 2036]
25
26
27 Multiple RUs can be assigned to an EHT STA (see 36.3.2.2 (Subcarriers and resource allocation for multiple
28
RUs)). The subcarrier indices of an MRU(#1959) consist of the indices of the corresponding RUs shown in
29
30 Table 36-5 (Data and pilot subcarrier indices for RUs in an 80 MHz EHT PPDU), Table 36-6 (Data and pilot
31 subcarrier indices for RUs in a 160 MHz EHT PPDU), and Table 36-7 (Data and pilot subcarrier indices for
32 RUs in a 320 MHz EHT PPDU) from which the MRU is built and are defined in 36.3.2.2 (Subcarriers and
33 resource allocation for multiple RUs).
34
35
36 36.3.2.2 Subcarriers and resource allocation for multiple RUs
37
38 36.3.2.2.1 General
39
40
(#7019)(#2783)(#1245)(#1290)The EHT PHY supports the usage of multiple resource unit (MRU) in an
41
42 EHT PPDU. (#1959)(#7134)An MRU consists of selected combinations of multiple RUs of 26-tone RU,
43 52-tone RU, 106-tone RU, 242-tone RU, 484-tone RU, 996-tone RU, (#7019)(#5405)and 2996-tone RU.
44 The tone indices of the various RUs for different EHT PPDU bandwidths are defined in 36.3.2.1
45 (Subcarriers and resource allocation in EHT PPDUs(#4636)).
46
47
48 (#7746)RUs that are the same size as or larger than 242-tone RUs are defined as large size RUs and RUs that
49 are smaller than 242-tones RUs are defined as small size RUs(#1315).
50
51 Small size RUs can only be combined with small size RUs to form small size MRUs. The supported small
52
size MRUs are defined in 36.3.2.2.2 (Small size MRUs(#2024)).
53
54
55 Large size RUs can only be combined with large size RUs to form large size MRUs. The supported large
56 size MRUs are defined in 36.3.2.2.3 (Large size MRUs(#2025)).
57
58
36.3.2.2.2 Small size MRUs(#2024)
59
60
61 (#1293)The small size MRUs defined for DL and UL OFDMA transmissions are as follows: 52+26-tone
62 MRU and 106+26-tone MRU.
63
64
65

Copyright © 2022 IEEE. All rights reserved. 531

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#1294)The 52+26-tone MRU is obtained by a certain combination of a 52-tone RU and an adjacent 26-tone
2 RU that both fall (#7135)within the same 20 MHz channel(#2694). The data subcarriers of a 52+26-tone
3
MRU (#7136)consist of the union of the data subcarriers of the 52-tone and 26-tone RUs that make up the
4
5 52+26-tone MRU. The pilot subcarriers of a 52+26-tone MRU (#7136)consist of the union of the pilot
6 subcarriers of the 52-tone and 26-tone RUs that make up the 52+26-tone MRU.
7
8 (#1294)The 106+26-tone MRU is obtained by a certain combination of a 106-tone RU and an adjacent 26-
9
tone RU that both fall (#7137)within the same 20 MHz channel boundary. The data subcarriers of a 106+26-
10
11 tone MRU (#7136)consist of the union of the data subcarriers of the 106-tone and 26-tone RUs that make up
12 the 106+26-tone MRU. The pilot subcarriers of a 106+26-tone MRU (#7136)consist of the union of the pilot
13 subcarriers of the 106-tone and 26-tone RUs that make up the 106+26-tone MRU.
14
15
(#3272)The allowed 52+26-tone MRUs in an OFDMA 20 MHz EHT PPDU are shown in Figure 36-5
16
17 (Allowed 52+26-tone MRUs in an OFDMA 20 MHz EHT PPDU(#8092)(#3270)).
18
19 Null Null
DC
20 Subcarriers Subcarriers

21
26-tone
22 RUs
23
24
25 52-tone
26 RUs

27
28 52+26-tone MRU 1 52+26-tone MRU 3

29
30 52+26-tone
31 MRUs 52+26-tone MRU 2

32
33
34
35 Figure 36-5—Allowed 52+26-tone MRUs in an OFDMA 20 MHz EHT PPDU(#8092)(#3270)
36
37
38 (#3272)(#6425)The allowed 52+26-tone MRUs in an OFDMA 40 MHz EHT PPDU are shown in
39
40
Figure 36-6 (Allowed 52+26-tone MRUs in an OFDMA 40 MHz EHT PPDU(#8092)(#3270)).
41
Null Null
42 Subcarriers Subcarriers
DC
43
44 26-tone
45 RUs
46
47
48 52-tone
49 RUs

50
52+26-toneMRU 1 52+26-toneMRU 3 52+26-toneMRU 4 52+26-toneMRU 6
51
52
53 52+26-tone
54 MRUs 52+26-toneMRU 2 52+26-toneMRU 5

55
56
57
58 Figure 36-6—Allowed 52+26-tone MRUs in an OFDMA 40 MHz EHT PPDU(#8092)(#3270)
59
60
61 (#3272)(#6426)The allowed 52+26-tone MRUs in each 80 MHz frequency subblock of an OFDMA
62 80 MHz, 160 MHz, or 320 MHz EHT PPDU are shown in Figure 36-7 (Allowed 52+26-tone MRUs in
63 each 80 MHz frequency subblock of an OFDMA 80 MHz, 160 MHz, or 320 MHz EHT
64
65
PPDU(#8092)(#1279)(#3270)). (#4983)For 160 MHz and 320 MHz EHT PPDU, MRU indices are different

532 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 in each 80 MHz frequency subblock and defined in Table 36-11 (Indices for small size MRUs in an OFDMA
2 160 MHz EHT PPDU) and Table 36-12 (Indices for small size MRUs in an OFDMA 320 MHz EHT
3
PPDU).
4
5 Null Null
Subcarriers DC
6 Subcarriers

7 26-tone
RUs
8
9 52-tone
RUs
10
11 52+26-tone MRU 3 52+26-tone MRU 4 52+26-tone MRU 9

12 52+26-tone
52+26-tone MRU 2 52+26-tone MRU 5 52+26-tone MRU 8
MRUs
13
14
15 Figure 36-7—Allowed 52+26-tone MRUs in each 80 MHz frequency subblock of an OFDMA
16
17 80 MHz, 160 MHz, or 320 MHz EHT PPDU(#8092)(#1279)(#3270)
18
19 (#3272)The allowed 106+26-tone MRUs in an OFDMA 20 MHz EHT PPDU are shown in Figure 36-8
20 (Allowed 106+26-tone MRUs in an OFDMA 20 MHz EHT PPDU(#8092)(#3270)).
21
22 Null Null
DC
23 Subcarriers Subcarriers

24
26-tone
25 RUs
26
27
28 106-tone
RUs
29
30
106+26-tone MRU 1
31
32
33 106+26-tone
106+26-tone MRU 2
MRUs
34
35
36
37
38 Figure 36-8—Allowed 106+26-tone MRUs in an OFDMA 20 MHz EHT PPDU(#8092)(#3270)
39
40
41 (#3272)The allowed 106+26-tone MRUs in an OFDMA 40 MHz EHT PPDU are shown in Figure 36-9
42 (Allowed 106+26-tone MRUs in an OFDMA 40 MHz EHT PPDU(#8092)(#3270)).
43
44 Null Null
45 Subcarriers DC Subcarriers
46
47 26-tone
RUs
48
49
50 106-tone
51 RUs
52
106+26-tone MRU 1 106+26-tone MRU 3
53
54
55 106+26-tone 106+26-tone MRU 2 106+26-tone MRU 4
MRUs
56
57
58
59
60 Figure 36-9—Allowed 106+26-tone MRUs in an OFDMA 40 MHz EHT PPDU(#8092)(#3270)
61
62
63 (#3272)The allowed 106+26-tone MRUs in each 80 MHz frequency subblock of an OFDMA 80 MHz,
64 160 MHz, or 320 MHz EHT PPDU are shown in Figure 36-10 (Allowed 106+26-tone MRUs in each
65

Copyright © 2022 IEEE. All rights reserved. 533

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 80 MHz frequency subblock of an OFDMA 80 MHz, 160 MHz, or 320 MHz EHT
2 PPDU(#8092)(#1279)(#3270)). (#4984)For 160 MHz and 320 MHz EHT PPDU, MRU indices are different
3
in each 80 MHz frequency subblock and defined in Table 36-11 (Indices for small size MRUs in an OFDMA
4
5 160 MHz EHT PPDU) and Table 36-12 (Indices for small size MRUs in an OFDMA 320 MHz EHT
6 PPDU).
7 Null Null
8 Subcarriers DC Subcarriers

9 26-tone
10 RUs

11
106-tone
12 RUs
13
106+26-tone MRU 1 106+26-tone MRU 4 106+26-tone MRU 5 106+26-tone MRU 8
14 106+26-tone
MRUs
15
16
17 Figure 36-10—Allowed 106+26-tone MRUs in each 80 MHz frequency subblock of an
18
19 OFDMA 80 MHz, 160 MHz, or 320 MHz EHT PPDU(#8092)(#1279)(#3270)
20
21 The location of the small size MRUs are fixed as defined in Table 36-8 (Indices for small size MRUs in an
22 OFDMA 20 MHz EHT PPDU), Table 36-9 (Indices for small size MRUs in an OFDMA 40 MHz EHT
23 PPDU), Table 36-10 (Indices for small size MRUs in an OFDMA 80 MHz EHT PPDU), Table 36-11
24
25 (Indices for small size MRUs in an OFDMA 160 MHz EHT PPDU), and Table 36-12 (Indices for small size
26 MRUs in an OFDMA 320 MHz EHT PPDU) (#7141)for 20 MHz, 40 MHz, 80 MHz, 160 MHz, and
27 320 MHz, respectively.
28
29 For Table 36-8 (Indices for small size MRUs in an OFDMA 20 MHz EHT PPDU), the indices for MRUs
30
31 are defined based on the indices for RUs in Table 27-7 (Data and pilot subcarrier indices for RUs in a 20
32 MHz HE PPDU and in a non-OFDMA 20 MHz HE PPDU).
33
34
35 Table 36-8—Indices for small size MRUs in an OFDMA 20 MHz EHT PPDU
36
37
38 MRU type MRU index MRU combination
39
40 52+26-tone MRU 1 52-tone RU 2 + 26-tone RU 2
41 MRU
42 MRU 2 52-tone RU 2 + 26-tone RU 5
43
44 MRU 3 52-tone RU 3 + 26-tone RU 8
45
46 106+26-tone MRU 1 106-tone RU 1 + 26-tone RU 5
47 MRU
MRU 2 106-tone RU 2 + 26-tone RU 5
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

534 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 For Table 36-9 (Indices for small size MRUs in an OFDMA 40 MHz EHT PPDU), the indices for MRUs are
2 defined based on the indices for RUs in (#6427)Table 27-8 (Data and pilot subcarrier indices for RUs in a 40
3
MHz HE PPDU and in a non-OFDMA 40 MHz HE PPDU).
4
5
6
7 Table 36-9—Indices for small size MRUs in an OFDMA 40 MHz EHT PPDU
8
9
10 MRU type MRU index MRU combination
11
12 52+26-tone MRU 1 52-tone RU 2 + 26-tone RU 2
13 MRU
14 MRU 2 52-tone RU 2 + 26-tone RU 5
15 MRU 3 52-tone RU 3 + 26-tone RU 8
16
17 MRU 4 52-tone RU 6 + 26-tone RU 11
18
19 MRU 5 52-tone RU 6 + 26-tone RU 14
20
21 MRU 6 52-tone RU 7 + 26-tone RU 17
22
23 106+26-tone MRU 1 106-tone RU 1 + 26-tone RU 5
24 MRU
MRU 2 106-tone RU 2 + 26-tone RU 5
25
26 MRU 3 106-tone RU 3 + 26-tone RU 14
27
28 MRU 4 106-tone RU 4 + 26-tone RU 14
29
30
31
32 For Table 36-10 (Indices for small size MRUs in an OFDMA 80 MHz EHT PPDU), the indices for MRUs
33 are defined based on the indices for RUs in Table 36-5 (Data and pilot subcarrier indices for RUs in an
34 80 MHz EHT PPDU).
35
36
37
38 Table 36-10—Indices for small size MRUs in an OFDMA 80 MHz EHT PPDU
39
40
41 MRU type MRU index MRU combination
42
43 52+26-tone MRU 1 Not defined
44 MRU
MRU 2 52-tone RU 2 + 26-tone RU 5
45
46 MRU 3 52-tone RU 3 + 26-tone RU 8
47
48 MRU 4 52-tone RU 6 + 26-tone RU 11
49
50 MRU 5 52-tone RU 6 + 26-tone RU 14
51
52 MRU 6 Not defined
53 MRU 7 Not defined
54
55 MRU 8 52-tone RU 10 + 26-tone RU 24
56
57 MRU 9 52-tone RU 11 + 26-tone RU 27
58
59 MRU 10 52-tone RU 14 + 26-tone RU 30
60
61 MRU 11 52-tone RU 14 + 26-tone RU 33
62 MRU 12 Not defined
63
64
65

Copyright © 2022 IEEE. All rights reserved. 535

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-10—Indices for small size MRUs in an OFDMA 80 MHz EHT PPDU (continued)
2
3
4 MRU type MRU index MRU combination
5
6 106+26-tone MRU 1 106-tone RU 1 + 26-tone RU 5
7 MRU
8 MRU 2 Not defined
9
10 MRU 3 Not defined
11 MRU 4 106-tone RU 4 + 26-tone RU 14
12
13 MRU 5 106-tone RU 5 + 26-tone RU 24
14
15 MRU 6 Not defined
16
17 MRU 7 Not defined
18
19 MRU 8 106-tone RU 8 + 26-tone RU 33
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

536 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 For Table 36-11 (Indices for small size MRUs in an OFDMA 160 MHz EHT PPDU), the indices for
2 MRUs are defined based on the indices for RUs in Table 36-6 (Data and pilot subcarrier indices for RUs
3
4 in a 160 MHz EHT PPDU).
5
6
7 Table 36-11—Indices for small size MRUs in an OFDMA 160 MHz EHT PPDU
8
9
10 MRU type MRU index MRU combination
11
12 52+26-tone MRU 1 Not defined
13 MRU
14 MRU 2 52-tone RU 2 + 26-tone RU 5
15
16 MRU 3 52-tone RU 3 + 26-tone RU 8
17 MRU 4 52-tone RU 6 + 26-tone RU 11
18
19 MRU 5 52-tone RU 6 + 26-tone RU 14
20
21 MRU 6 Not defined
22
23 MRU 7 Not defined
24
25 MRU 8 52-tone RU 10 + 26-tone RU 24
26 MRU 9 52-tone RU 11 + 26-tone RU 27
27
28 MRU 10 52-tone RU 14 + 26-tone RU 30
29
30 MRU 11 52-tone RU 14 + 26-tone RU 33
31
32 MRU 12 Not defined
33
34 MRU 13 Not defined
35 MRU 14 52-tone RU 18 + 26-tone RU 42
36
37 MRU 15 52-tone RU 19 + 26-tone RU 45
38
39 MRU 16 52-tone RU 22 + 26-tone RU 48
40
41 MRU 17 52-tone RU 22 + 26-tone RU 51
42
43 MRU 18 Not defined
44 MRU 19 Not defined
45
46 MRU 20 52-tone RU 26 + 26-tone RU 61
47
48 MRU 21 52-tone RU 27 + 26-tone RU 64
49
50 MRU 22 52-tone RU 30 + 26-tone RU 67
51
52 MRU 23 52-tone RU 30 + 26-tone RU 70
53 MRU 24 Not defined
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 537

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-11—Indices for small size MRUs in an OFDMA 160 MHz EHT PPDU (continued)
2
3
4 MRU type MRU index MRU combination
5
6 106+26-tone MRU 1 106-tone RU 1 + 26-tone RU 5
7 MRU
8 MRU 2 Not defined
9
10 MRU 3 Not defined
11 MRU 4 106-tone RU 4 + 26-tone RU 14
12
13 MRU 5 106-tone RU 5 + 26-tone RU 24
14
15 MRU 6 Not defined
16
17 MRU 7 Not defined
18
19 MRU 8 106-tone RU 8 + 26-tone RU 33
20 MRU 9 106-tone RU 9 + 26-tone RU 42
21
22 MRU 10 Not defined
23
24 MRU 11 Not defined
25
26 MRU 12 106-tone RU 12 + 26-tone RU 51
27
28 MRU 13 106-tone RU 13 + 26-tone RU 61
29 MRU 14 Not defined
30
31 MRU 15 Not defined
32
33 MRU 16 106-tone RU 16 + 26-tone RU 70
34
35
36
37 For Table 36-12 (Indices for small size MRUs in an OFDMA 320 MHz EHT PPDU), the indices for MRUs
38 are defined based on the indices for RUs in Table 36-7 (Data and pilot subcarrier indices for RUs in a
39 320 MHz EHT PPDU).
40
41
42
Table 36-12—Indices for small size MRUs in an OFDMA 320 MHz EHT PPDU
43
44
45 MRU type MRU index MRU combination
46
47 52+26-tone MRU 1 Not defined
48 MRU
49 MRU 2 52-tone RU 2 + 26-tone RU 5
50
51 MRU 3 52-tone RU 3 + 26-tone RU 8
52
53 MRU 4 52-tone RU 6 + 26-tone RU 11
54
55 MRU 5 52-tone RU 6 + 26-tone RU 14
56 MRU 6 Not defined
57
58 MRU 7 Not defined
59
60 MRU 8 52-tone RU 10 + 26-tone RU 24
61
62 MRU 9 52-tone RU 11 + 26-tone RU 27
63
64 MRU 10 52-tone RU 14 + 26-tone RU 30
65

538 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-12—Indices for small size MRUs in an OFDMA 320 MHz EHT PPDU (continued)
2
3
4 MRU type MRU index MRU combination
5
6 MRU 11 52-tone RU 14 + 26-tone RU 33
7
8 MRU 12 Not defined
9
10 MRU 13 Not defined
11 MRU 14 52-tone RU 18 + 26-tone RU 42
12
13 MRU 15 52-tone RU 19 + 26-tone RU 45
14
15 MRU 16 52-tone RU 22 + 26-tone RU 48
16
17 MRU 17 52-tone RU 22 + 26-tone RU 51
18
19 MRU 18 Not defined
20 MRU 19 Not defined
21
22 MRU 20 52-tone RU 26 + 26-tone RU 61
23
24 MRU 21 52-tone RU 27 + 26-tone RU 64
25
26 MRU 22 52-tone RU 30 + 26-tone RU 67
27
28 MRU 23 52-tone RU 30 + 26-tone RU 70
29 MRU 24 Not defined
30
31 MRU 25 Not defined
32
33 MRU 26 52-tone RU 34 + 26-tone RU 79
34
35 MRU 27 (#6783)52-tone RU 35 + 26-tone RU 82
36
37 MRU 28 52-tone RU 38 + 26-tone RU 85
38 MRU 29 52-tone RU 38 + 26-tone RU 88
39
40 MRU 30 Not defined
41
42 MRU 31 Not defined
43
44 MRU 32 52-tone RU 42 + 26-tone RU 98
45
46 MRU 33 52-tone RU 43 + 26-tone RU 101
47 MRU 34 52-tone RU 46 + 26-tone RU 104
48
49 MRU 35 52-tone RU 46 + 26-tone RU 107
50
51 MRU 36 Not defined
52
53 MRU 37 Not defined
54
55 MRU 38 52-tone RU 50 + 26-tone RU 116
56 MRU 39 52-tone RU 51 + 26-tone RU 119
57
58 MRU 40 52-tone RU 54 + 26-tone RU 122
59
60 MRU 41 52-tone RU 54 + 26-tone RU 125
61
62 MRU 42 (#6784)Not defined
63
64 MRU 43 (#6784)Not defined
65

Copyright © 2022 IEEE. All rights reserved. 539

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-12—Indices for small size MRUs in an OFDMA 320 MHz EHT PPDU (continued)
2
3
4 MRU type MRU index MRU combination
5
6 MRU 44 52-tone RU 58 + 26-tone RU 135
7
8 MRU 45 52-tone RU 59 + 26-tone RU 138
9
10 MRU 46 52-tone RU 62 + 26-tone RU 141
11 MRU 47 52-tone RU 62 + 26-tone RU 144
12
13 MRU 48 Not defined
14
15 106+26-tone MRU 1 106-tone RU 1 + 26-tone RU 5
16 MRU
17 MRU 2 Not defined
18
19 MRU 3 Not defined
20 MRU 4 106-tone RU 4 + 26-tone RU 14
21
22 MRU 5 106-tone RU 5 + 26-tone RU 24
23
24 MRU 6 Not defined
25
26 MRU 7 Not defined
27
28 MRU 8 106-tone RU 8 + 26-tone RU 33
29 MRU 9 106-tone RU 9 + 26-tone RU 42
30
31 MRU 10 Not defined
32
33 MRU 11 Not defined
34
35 MRU 12 106-tone RU 12 + 26-tone RU 51
36
37 MRU 13 106-tone RU 13 + 26-tone RU 61
38 MRU 14 Not defined
39
40 MRU 15 Not defined
41
42 MRU 16 106-tone RU 16 + 26-tone RU 70
43
44 MRU 17 106-tone RU 17 + 26-tone RU 79
45
46 MRU 18 Not defined
47 MRU 19 Not defined
48
49 MRU 20 106-tone RU 20 + 26-tone RU 88
50
51 MRU 21 106-tone RU 21 + 26-tone RU 98
52
53 MRU 22 Not defined
54
55 MRU 23 Not defined
56 MRU 24 106-tone RU 24 + 26-tone RU 107
57
58 MRU 25 106-tone RU 25 + 26-tone RU 116
59
60 MRU 26 Not defined
61
62 MRU 27 Not defined
63
64 MRU 28 106-tone RU 28 + 26-tone RU 125
65

540 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-12—Indices for small size MRUs in an OFDMA 320 MHz EHT PPDU (continued)
2
3
4 MRU type MRU index MRU combination
5
6 MRU 29 106-tone RU 29 + 26-tone RU 135
7
8 MRU 30 Not defined
9
10 MRU 31 Not defined
11 MRU 32 106-tone RU 32 + 26-tone RU 144
12
13
14
15 It is mandatory for a non-AP STA to support the transmission and reception of 52+26-tone and 106+26-tone
16 MRUs in an OFDMA EHT PPDU(#1293) except for a 20 MHz operating non-AP STA(#4985).
17
18
19 (#4985)For a 20 MHz operating non-AP STA, the transmission and reception of 52+26-tone and 106+26-
20 tone MRUs that are allowed in 36.3.2.6 (RU and MRU restrictions for 20 MHz operation(#3276)) shall be
21 supported.
22
23
36.3.2.2.3 Large size MRUs(#2025)
24
25
26 36.3.2.2.3.1 Large size MRUs for non-OFDMA(#6428)(#2787)
27
28 (#1990)The large size MRUs defined for DL and UL non-OFDMA transmissions are as follows:
29
484+242-tone MRU, 996+484-tone MRU, 996+484+242-tone MRU, 2996+484-tone MRU, 3996-tone
30
31 MRU, and 3996+484-tone MRU.
32
33 (#1296)(#7145)The 484+242-tone MRU is allowed when a 20 MHz subchannel is punctured in a non-
34 OFDMA 80 MHz EHT PPDU. The 484+242-tone MRU is obtained by combining a 484-tone RU and a 242-
35
tone RU in a non-OFDMA 80 MHz EHT PPDU. The data subcarriers of a 484+242-tone MRU
36
37 (#7136)consist of the union of the data subcarriers of the 484-tone and 242-tone RUs that make up the
38 484+242-tone MRU. The pilot subcarriers of a 484+242-tone MRU (#7136)consist of the union of the pilot
39 subcarriers of the 484-tone and 242-tone RUs that make up the 484+242-tone MRU. The four allowed
40 484+242-tone MRUs in a non-OFDMA 80 MHz EHT PPDU are shown in Figure 36-11 (Allowed 484+242-
41
tone MRUs in a non-OFDMA 80 MHz EHT PPDU(#4791)(#1296)).
42
43 Null
sub carriers
DC
Null
sub carriers
44
45 242‐tone RUs 242 242 242 242
46
47 484‐tone RUs 484 484
48
49
50
51
484+242‐tone MRU 1 242 484
52
53 484+242‐tone MRU 2 242 484
54
55 484+242‐tone MRU 3 484 242
56
57
58 484+242‐tone MRU 4 484 242
59
60 Figure 36-11—Allowed 484+242-tone MRUs in a non-OFDMA 80 MHz EHT
61 PPDU(#4791)(#1296)
62
63 (#1296)(#7145)The 996+484-tone MRU is allowed when a 40 MHz subchannel is punctured in a non-
64 OFDMA 160 MHz EHT PPDU. The 996+484-tone MRU is obtained by combining a 996-tone RU and a
65

Copyright © 2022 IEEE. All rights reserved. 541

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 484-tone RU in a non-OFDMA 160 MHz EHT PPDU. The data subcarriers of a 996+484-tone MRU
2 (#7136)consist of the union of the data subcarriers of the 996-tone and 484-tone RUs that make up the
3
996+484-tone MRU. The pilot subcarriers of a 996+484-tone MRU (#7136)consist of the union of the
4
5 pilot subcarriers of the 996-tone and 484-tone RUs that make up the 996+484-tone MRU. The four
6 allowed 996+484-tone MRUs in a non-OFDMA 160 MHz EHT PPDU are shown in Figure 36-12
7 (Allowed 996+484-tone MRUs in a non-OFDMA 160 MHz EHT PPDU(#4792)(#1296)).
8
9 Null Null
10 subcarriers subcarriers
DC
11
12 484‐tone RUs 484 484 484 484
13
14
15 996‐tone RUs 996 996
16
17
18
19
996+484‐tone MRU 1 484 996
20
21 996+484‐tone MRU 2 484 996
22
23 996+484‐tone MRU 3
24 996 484
25
26 996+484‐tone MRU 4 996 484
27
28
29 Figure 36-12—Allowed 996+484-tone MRUs in a non-OFDMA 160 MHz EHT
30 PPDU(#4792)(#1296)
31
32
33 (#1296)(#7145)The 996+484+242-tone MRU is allowed when a 20 MHz subchannel is punctured in a
34 non-OFDMA 160 MHz EHT PPDU. The 996+484+242-tone MRU is obtained by combining a 996-tone
35 RU, a 484-tone RU, and a 242-tone RU in a non-OFDMA 160 MHz EHT PPDU. The data subcarriers of
36 a 996+484+242-tone MRU (#7136)consist of the union of the data subcarriers of the 996-tone, 484-tone,
37
38 and 242-tone RUs that make up the 996+484+242-tone MRU. The pilot subcarriers of a 996+484+242-
39 tone MRU (#7136)consist of the union of the pilot subcarriers of the 996-tone, 484-tone, and 242-tone
40 RUs that make up the 996+484+242 tone MRU. The eight allowed 996+484+242-tone MRUs in a non-
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

542 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 OFDMA 160 MHz EHT PPDU are shown in Figure 36-13 (Allowed 996+484+242-tone MRUs in a non-
2 OFDMA 160 MHz EHT PPDU(#4793)(#1296)).
3
4 Null Null
5 subcarriers subcarriers
DC
6
7 242 242 242 242 242 242 242 242
242‐tone RUs
8
9
10 484‐tone RUs 484 484 484 484
11
12 996‐tone RUs 996 996
13
14
15
16 996+484+242‐tone MRU 1 242 484 996
17
18 996+484+242‐tone MRU 2 242 484 996
19
20
21
996+484+242‐tone MRU 3 484 242 996
22
23 996+484+242‐tone MRU 4 484 242 996
24
25 996+484+242‐tone MRU 5 996 242 484
26
27 996+484+242‐tone MRU 6 996 242 484
28
29
30 996+484+242‐tone MRU 7 996 484 242
31
32 996+484+242‐tone MRU 8 996 484 242
33
34 Figure 36-13—Allowed 996+484+242-tone MRUs in a non-OFDMA 160 MHz EHT
35
36
PPDU(#4793)(#1296)
37
38 (#1296)(#7145)The 2996+484-tone MRU is allowed when either the first or the fourth 996-tone RU in a
39 non-OFDMA 320 MHz EHT PPDU is punctured and any one of the 40 MHz subchannels in the
40 remaining 240 MHz is punctured. The 2996+484-tone MRU is obtained by combining two 996-tone
41 RUs and a 484-tone RU in a non-OFDMA 320 MHz EHT PPDU. The data subcarriers of a 2996+484-
42
43 tone MRU (#7136)consist of the union of the data subcarriers of the two 996-tone RUs and 484-tone RU
44 that make up the 2996+484-tone MRU. The pilot subcarriers of a 2996+484-tone MRU (#7136)consist
45 of the union of the pilot subcarriers of the two 996-tone RUs and 484-tone RU that make up the
46 2996+484-tone MRU. The twelve allowed 2996+484-tone MRUs in a non-OFDMA 320 MHz EHT
47 PPDU are shown in Figure 36-14 (Allowed 2×996+484-tone MRUs in a non-OFDMA 320 MHz EHT
48
49 PPDU(#4794)(#1296)). (#4675)The fourth 80 MHz shall be punctured if any one of the 2996+484-tone
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 543

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 MRU 1 to the 2996+484-tone MRU 6 exists. The first 80 MHz shall be punctured if any one of the
2 2996+484-tone MRU 7 to the 2996+484-tone MRU 12 exists.
3
4 Null Null

5 subcarriers
DC
subcarriers

6
7 484‐tone RUs 484 484 484 484 484 484 484 484
8
9 996‐tone RUs 996 996 996 996
10
11 2×996+484‐tone MRU 1 484 996 996
12
13 2×996+484‐tone MRU 2 484 996 996
14
15 2×996+484‐tone MRU 3 996 484 996
16
17 2×996+484‐tone MRU 4 996 484 996
18
19 2×996+484‐tone MRU 5 996 996 484
20
21 2×996+484‐tone MRU 6 996 996 484
22
23 2×996+484‐tone MRU 7 484 996 996
24
25
2×996+484‐tone MRU 8 484 996 996
26 2×996+484‐tone MRU 9 996 484 996
27
28 2×996+484‐tone MRU 10 996 484 996
29
30 2×996+484‐tone MRU 11 996 996 484
31
32 2×996+484‐tone MRU 12 996 996 484
33
34
35 Figure 36-14—Allowed 2×996+484-tone MRUs in a non-OFDMA 320 MHz EHT
36 PPDU(#4794)(#1296)
37
38
39 (#1296)(#7145)The 3996-tone MRU is allowed when an 80 MHz subchannel is punctured in a non-
40 OFDMA 320 MHz EHT PPDU. The 3996-tone MRU is obtained by combining three 996-tone RUs in a
41 non-OFDMA 320 MHz EHT PPDU. The data subcarriers of a 3996-tone MRU (#7136)consist of the
42 union of the data subcarriers of the three 996-tone RUs that make up the 3996-tone MRU. The pilot
43
44 subcarriers of a 3996-tone MRU (#7136)consist of the union of the pilot subcarriers of the three 996-tone
45 RUs that make up the 3996-tone MRU. The four allowed 3996-tone MRUs in a non-OFDMA
46 320 MHz EHT PPDU are shown in Figure 36-15 (Allowed 3×996-tone MRUs in a non-OFDMA 320 MHz
47 EHT PPDU(#4795)(#1296)).
48
49 Null Null
50 subcarriers
DC
subcarriers

51
52 996‐tone RUs 996 996 996 996
53
54 3×996‐tone MRU 1 996 996 996
55
56 3×996‐tone MRU 2 996 996 996
57
58 3×996‐tone MRU 3 996 996 996
59
60 3×996‐tone MRU 4 996 996 996
61
62
63 Figure 36-15—Allowed 3×996-tone MRUs in a non-OFDMA 320 MHz EHT
64 PPDU(#4795)(#1296)
65

544 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#1296)(#7145)The 3996+484-tone MRU is allowed when a 40 MHz subchannel is punctured in a non-

2 OFDMA 320 MHz EHT PPDU. The 3×996+484-tone MRU is obtained by combining three 996-tone
3
RUs and a 484-tone RU in a non-OFDMA 320 MHz EHT PPDU. The data subcarriers of a 3996+484-
4
5 tone MRU (#7136)consist of the union of the data subcarriers of the three 996-tone RUs and 484-tone RU
6 that make up the 3996+484-tone MRU. The pilot subcarriers of a 3996+484-tone MRU (#7136)consist
7 of the union of the pilot subcarriers of the three 996-tone RUs and 484-tone RU that make up the
8 3996+484-tone MRU. The eight allowed 3996+484-tone MRUs in a non-OFDMA 320 MHz EHT
9
PPDU are shown in Figure 36-16 (Allowed 3×996+484-tone MRUs in a non-OFDMA 320 MHz EHT
10
11 PPDU(#4796)(#1296)).
12
13 Null
subcarriers
Null
subcarriers
DC
14
15 484‐tone RUs 484 484 484 484 484 484 484 484
16
17 996‐tone RUs 996 996 996 996
18
19
20 3×996+484‐tone MRU 1 484 996 996 996
21
22 3×996+484‐tone MRU 2 484 996 996 996
23
24 3×996+484‐tone MRU 3 996 484 996 996
25
26 3×996+484‐tone MRU 4 996 484 996 996
27
28 3×996+484‐tone MRU 5 996 996 484 996
29
30 3×996+484‐tone MRU 6 996 996 484 996
31
32
3×996+484‐tone MRU 7 996 996 996 484
33 3×996+484‐tone MRU 8 996 996 996 484
34
35
36 Figure 36-16—Allowed 3×996+484-tone MRUs in a non-OFDMA 320 MHz EHT
37 PPDU(#4796)(#1296)
38
39 (#1297)(#1298)(#1299)It is mandatory for a STA to support the transmission and reception of a 484+242-
40
41 tone MRU in a non-OFDMA 80 MHz EHT PPDU, 996+484-tone and 996+484+242-tone MRUs in a non-
42 OFDMA 160 MHz EHT PPDU, 2996+484-tone, 3996-tone, and 3996+484-tone MRUs in a non-
43 OFDMA 320 MHz EHT PPDU unless the MRU size is larger than STA’s supported bandwidth.
44
45 36.3.2.2.3.2 Large size MRUs for OFDMA(#6429)(#2787)
46
47
48 (#1991)The large size MRU defined for DL and UL OFDMA transmissions are as follows: 484+242-tone
49 MRU, 996+484-tone MRU, 2×996+484-tone MRU, 3×996-tone MRU, and 3×996+484-tone MRU.
50
51 (#1296)The 484+242-tone MRU is allowed in OFDMA 80 MHz, 160 MHz, and 320 MHz EHT PPDU.
52
53 (#6785)The 484+242-tone MRU is obtained by combining a 484-tone RU and a 242-tone RU within an 80
54 MHz frequency subblock. The data subcarriers of a 484+242-tone MRU (#7136)consist of the union of the
55 data subcarriers of the 484-tone and 242-tone RUs that make up the 484+242-tone MRU. The pilot
56 subcarriers of a 484+242-tone MRU (#7136)consist of the union of the pilot subcarriers of the 484-tone
57 and 242-tone RUs that make up the 484+242-tone MRU. For an OFDMA 80 MHz EHT PPDU, the four
58
59 allowed 484+242-tone MRUs (#4681)are the same as for a non-OFDMA 80 MHz EHT PPDU as shown
60 in Figure 36-11 (Allowed 484+242-tone MRUs in a non-OFDMA 80 MHz EHT PPDU(#4791)(#1296)).
61
62 (#1296)(#1279)For OFDMA transmission in 160 MHz and 320 MHz, the allowed combinations for a
63 484+242-tone MRU in an OFDMA 80 MHz EHT PPDU are allowed in each 80 MHz frequency subblock
64
65 of OFDMA 160 MHz and 320 MHz EHT PPDU.

Copyright © 2022 IEEE. All rights reserved. 545

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#1296)The 996+484-tone MRU is allowed in OFDMA 160 MHz and 320 MHz EHT PPDU. (#6786)The
2 996+484-tone MRU is obtained by combining a 996-tone RU and a 484-tone RU in adjacent 80 MHz
3
frequency subblocks of a 160 MHz channel. The data subcarriers of a 996+484-tone MRU (#7136)consist of
4
5 the union of the data subcarriers of the 996-tone and 484-tone RUs that make up the 996+484-tone MRU.
6 The pilot subcarriers of a 996+484-tone MRU (#7136)consist of the union of the pilot subcarriers of the 996-
7 tone and 484-tone RUs that make up the 996+484-tone MRU. For an OFDMA 160 MHz EHT PPDU, the
8 four allowed 996+484-tone MRUs (#4682)are the same as for a non-OFDMA 160 MHz EHT PPDU as
9
shown in Figure 36-12 (Allowed 996+484-tone MRUs in a non-OFDMA 160 MHz EHT
10
11 PPDU(#4792)(#1296)).
12
13 (#2605)For OFDMA transmission in 320 MHz, the (#5812)four allowed combinations for a 996+484-tone
14 MRU are within the primary 160 MHz channel or secondary 160 MHz channel(#1300).
15
16
17 (#1296)The 2×996+484-tone MRU is allowed in an OFDMA 320 MHz EHT PPDU. The 2×996+484-tone
18 MRU is obtained by combining two 996-tone RUs and 484-tone RU. The data subcarriers of a 2×996+484-
19 tone MRU (#7136)consist of the union of the data subcarriers of the two 996-tone RUs and 484-tone RU that
20 make up the 2×996+484-tone MRU. The pilot subcarriers of a 2×996+484-tone MRU (#7136)consist of the
21
union of the pilot subcarriers of the two 996-tone RUs and 484-tone RU that make up the 2×996+484 tone
22
23 MRU. The twelve allowed 2×996+484-tone MRUs in an OFDMA 320 MHz EHT PPDU (#4683)are the
24 same as for a non-OFDMA 320 MHz EHT PPDU as shown in Figure 36-14 (Allowed 2×996+484-tone
25 MRUs in a non-OFDMA 320 MHz EHT PPDU).
26
27
(#1296)The 3×996-tone MRU is allowed in an OFDMA 320 MHz EHT PPDU. The 3×996-tone MRU is
28
29 obtained by combining three 996-tone RUs. The data subcarriers of a 3×996-tone MRU (#7136)consist of
30 the union of the data subcarriers of the three 996-tone RUs that make up the 3×996-tone MRU. The pilot
31 subcarriers of a 3×996-tone MRU (#7136)consist of the union of the pilot subcarriers of the three 996-
32 tone RUs that make up the 3×996-tone MRU. The four allowed 3×996-tone MRUs in an OFDMA
33
320 MHz EHT PPDU (#4684)are the same as for a non-OFDMA 320 MHz EHT PPDU as shown in
34
35 Figure 36-15 (Allowed 3×996-tone MRUs in a non-OFDMA 320 MHz EHT PPDU(#4795)(#1296)).
36
37 (#1296)The 3×996+484-tone MRU is allowed in an OFDMA 320 MHz EHT PPDU. The 3×996+484-
38 tone MRU is obtained by combining three 996-tone RUs and a 484-tone RU. The data subcarriers of a
39
3×996+484-tone MRU (#7136)consist of the union of the data subcarriers of the three 996-tone RUs and
40
41 484-tone RU that make up the 3×996+484-tone MRU. The pilot subcarriers of a 3×996+484-tone MRU
42 (#7136)consist of the union of the pilot subcarriers of the three 996-tone RUs and 484-tone RU that make
43 up the 3×996+484-tone MRU. The eight allowed 3×996+484-tone MRUs in an OFDMA 320 MHz EHT
44 PPDU (#7155)are the same as for a non-OFDMA 320 MHz EHT PPDU as shown in Figure 36-16
45
(Allowed 3×996+484-tone MRUs in a non-OFDMA 320 MHz EHT PPDU(#4796)(#1296)).
46
47
48 (#6788)It is mandatory for a non-AP STA to support the transmission and reception of 484+242-tone MRU
49 in each 80 MHz subblock, 996+484-tone MRU in the primary 160 MHz channel and the secondary 160
50 MHz channel, 2×996+484-tone MRU, 3×996-tone MRU, and 3×996+484-tone MRU in 320 MHz channel
51
for an OFDMA 80/160/320 MHz EHT PPDU unless the MRU size is larger than its supported bandwidth
52
53 provided the entire MRU is located within the non-AP STA’s operating bandwidth
54
55 36.3.2.2.3.3 Location of large size MRUs(#6430)(#2787)
56
57
The location of the large size MRUs are fixed as defined in Table 36-13 (Indices for large size MRUs in an
58
59 OFDMA 80 MHz EHT PPDU and in a non-OFDMA 80 MHz EHT PPDU(#5466)(#4903)(#2398)),
60 Table 36-14 (Indices for large size MRUs in an OFDMA 160 MHz EHT PPDU and in a non-OFDMA
61 160 MHz EHT PPDU(#5466)(#4903)(#2398)), and Table 36-15 (Indices for large size MRUs in an
62 OFDMA 320 MHz EHT PPDU and in a non-OFDMA 320 MHz EHT
63
PPDU(#4989)(#5466)(#4903)(#2398)) for 80 MHz, 160 MHz and 320 MHz respectively.
64
65

546 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 For Table 36-13 (Indices for large size MRUs in an OFDMA 80 MHz EHT PPDU and in a non-OFDMA
2 80 MHz EHT PPDU(#5466)(#4903)(#2398)), the indices for MRUs are defined based on the indices for
3
RUs in Table 36-5 (Data and pilot subcarrier indices for RUs in an 80 MHz EHT PPDU).
4
5
6
7 Table 36-13—Indices for large size MRUs in an OFDMA 80 MHz EHT PPDU and in a non-
8 OFDMA 80 MHz EHT PPDU(#5466)(#4903)(#2398)
9
10
11 MRU type MRU index Combinations
12
13 484+242-tone MRU 1 484-tone RU 2 + 242-tone RU 2; [(gap-242-tone RU) - 242-tone RU -
14 MRU 484-tone RU]
15
16 MRU 2 484-tone RU 2 + 242-tone RU 1; [242-tone RU - (gap-242-tone RU) -
17 484-tone RU]
18
19 MRU 3 484-tone RU 1 + 242-tone RU 4; [484-tone RU - (gap-242-tone RU) -
20 242-tone RU]
21 MRU 4 484-tone RU 1 + 242-tone RU 3; [484-tone RU - 242-tone RU - (gap-242-
22 tone RU)]
23
24 NOTE 1—“Gap-242/484/996-tone RU” is not part of a MRU and is used to indicate the size of a gap between RUs
25 that form the MRU.
26
27 NOTE 2—In non-OFDMA transmission, “gap-242/484/996-tone RU” indicates that one or more 20 MHz
28 subchannels corresponding to “gap-242/484/996-tone RU” are punctured and is to help indicate the frequency order
29 of the MRU in an 80/160/320 MHz PPDU.
30
31
32 NOTE 3—In OFDMA transmission, “gap-242/484/996-tone RU” indicates that one or more 20 MHz subchannels
33 corresponding to “gap-242/484/996-tone RU” are punctured or unassigned or used for data transmission by
34 assigning one or multiple RU/MRU and is to help indicate the frequency order of the MRU within an 80/160/240/
35 320 MHz subband.
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 547

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 For Table 36-14 (Indices for large size MRUs in an OFDMA 160 MHz EHT PPDU and in a non-
2 OFDMA 160 MHz EHT PPDU(#5466)(#4903)(#2398)), the indices for MRUs are defined based on the
3
indices for RUs in Table 36-6 (Data and pilot subcarrier indices for RUs in a 160 MHz EHT PPDU).
4
5
6
7 Table 36-14—Indices for large size MRUs in an OFDMA 160 MHz EHT PPDU and in a non-
8 OFDMA 160 MHz EHT PPDU(#5466)(#4903)(#2398)
9
10
11 MRU type MRU index Combinations
12
13 484+242-tone MRU 1 484-tone RU 2 + 242-tone RU 2; [(gap-242-tone RU) - 242-tone RU -
14 MRU 484-tone RU] in lower 80 MHz channel
15
16 MRU 2 484-tone RU 2 + 242-tone RU 1; [242-tone RU - (gap-242-tone RU) -
17 484-tone RU] in lower 80 MHz channel
18
19 MRU 3 484-tone RU 1 + 242-tone RU 4; [484-tone RU - (gap-242-tone RU) -
20 242-tone RU] in lower 80 MHz channel
21 MRU 4 484-tone RU 1 + 242-tone RU 3; [484-tone RU - 242-tone RU - (gap-242-
22 tone RU)] in lower 80 MHz channel
23
24 MRU 5 484-tone RU 4 + 242-tone RU 6; [(gap-242-tone RU) - 242-tone RU -
25 484-tone RU] in upper 80 MHz channel
26
27 MRU 6 484-tone RU 4 + 242-tone RU 5; [242-tone RU - (gap-242-tone RU) -
28 484-tone RU] in upper 80 MHz channel
29
30 MRU 7 484-tone RU 3 + 242-tone RU 8; [484-tone RU - (gap-242-tone RU) -
31 242-tone RU] in upper 80 MHz channel
32
33 MRU 8 484-tone RU 3 + 242-tone RU 7; [484-tone RU - 242-tone RU - (gap-242-
34 tone RU)] in upper 80 MHz channel
35 996+484-tone MRU 1 996-tone RU 2 + 484-tone RU 2; [(gap-484-tone RU) - 484-tone RU -
36 MRU 996-tone RU]
37
38 MRU 2 996-tone RU 2 + 484-tone RU 1; [484-tone RU - (gap-484-tone RU) -
39 996-tone RU]
40
41 MRU 3 996-tone RU 1 + 484-tone RU 4; [996-tone RU - (gap-484-tone RU) -
42 484-tone RU]
43
44 MRU 4 996-tone RU 1 + 484-tone RU 3; [996-tone RU - 484-tone RU - (gap-484-
45 tone RU)]
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

548 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-14—Indices for large size MRUs in an OFDMA 160 MHz EHT PPDU and in a non-
2 OFDMA 160 MHz EHT PPDU(#5466)(#4903)(#2398) (continued)
3
4
5 MRU type MRU index Combinations
6
7 996+484+242- MRU 1 996-tone RU 2 + 484-tone RU 2 + 242-tone RU 2; [(gap-242-tone RU) -
8 tone MRU (only 242-tone - RU 484-tone RU - 996-tone RU]
9 for non-
10 OFDMA) MRU 2 996-tone RU 2 + 484-tone RU 2 + 242-tone RU 1; [242-tone RU - (gap-
11 242-tone RU) - 484-tone RU - 996-tone RU]
12
13 MRU 3 996-tone RU 2 + 484-tone RU 1 + 242-tone RU 4; [484-tone RU - (gap-
14 242-tone RU) - 242-tone RU - 996-tone RU]
15
16 MRU 4 996-tone RU 2 + 484-tone RU 1 + 242-tone RU 3; [484-tone RU - 242-
17 tone RU - (gap-242-tone RU) - 996-tone RU]
18 MRU 5 996-tone RU 1 + 484-tone RU 4 + 242-tone RU 6; [996-tone RU - (gap-
19 242-tone RU) - 242-tone RU - 484-tone RU]
20
21 MRU 6 996-tone RU 1 + 484-tone RU 4 + 242-tone RU 5; [996-tone RU - 242-
22 tone RU - (gap-242-tone RU) - 484-tone RU]
23
24 MRU 7 996-tone RU 1 + 484-tone RU 3 + 242-tone RU 8; [996-tone RU - 484-
25 tone RU - (gap-242-tone RU) - 242-tone RU]
26
27 MRU 8 996-tone RU 1 + 484-tone RU 3 + 242-tone RU 7; [996-tone RU - 484-
28 tone RU - 242-tone RU - (gap-242-tone RU)]
29
30 NOTE 1—“Gap-242/484/996-tone RU” is not part of a MRU and is used to indicate the size of a gap between RUs
31 that form the MRU.
32
33 NOTE 2—In non-OFDMA transmission, “gap-242/484/996-tone RU” indicates that one or more 20 MHz
34 subchannels corresponding to “gap-242/484/996-tone RU” are punctured and is to help indicate the frequency order
35 of the MRU in an 80/160/320 MHz PPDU.
36
37 NOTE 3—In OFDMA transmission, “gap-242/484/996-tone RU” indicates that one or more 20 MHz subchannels
38 corresponding to “gap-242/484/996-tone RU” are punctured or unassigned or used for data transmission by
39 assigning one or multiple RU/MRU and is to help indicate the frequency order of the MRU within an 80/160/240/
40 320 MHz subband.
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 549

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 For Table 36-15 (Indices for large size MRUs in an OFDMA 320 MHz EHT PPDU and in a non-OFDMA
2 320 MHz EHT PPDU(#4989)(#5466)(#4903)(#2398)), the indices for MRUs are defined based on the
3
indices for RUs in Table 36-7 (Data and pilot subcarrier indices for RUs in a 320 MHz EHT PPDU).
4
5
6
7 Table 36-15—Indices for large size MRUs in an OFDMA 320 MHz EHT PPDU and in a non-
8 OFDMA 320 MHz EHT PPDU(#4989)(#5466)(#4903)(#2398)
9
10
11 MRU type MRU index Combinations
12
13 484+242-tone MRU 1 484-tone RU 2 + 242-tone RU 2; [(gap-242-tone RU) - 242-tone RU -
14 MRU 484-tone RU] in lower 80 MHz channel in lower 160 MHz
15
16 MRU 2 484-tone RU 2 + 242-tone RU 1; [242-tone RU - (gap-242-tone RU) -
17 484-tone RU] in lower 80 MHz channel in lower 160 MHz
18
19 MRU 3 484-tone RU 1 + 242-tone RU 4; [484-tone RU - (gap-242-tone RU) -
20 242-tone RU] in lower 80 MHz channel in lower 160 MHz
21 MRU 4 484-tone RU 1 + 242-tone RU 3; [484-tone RU - 242-tone RU - (gap-242-
22 tone RU)] in lower 80 MHz channel in lower 160 MHz
23
24 MRU 5 484-tone RU 4 + 242-tone RU 6; [(gap-242-tone RU) - 242-tone RU -
25 484-tone RU] in upper 80 MHz channel in lower 160 MHz
26
27 MRU 6 484-tone RU 4 + 242-tone RU 5; [242-tone RU - (gap-242-tone RU) -
28 484-tone RU] in upper 80 MHz channel in lower 160 MHz
29
30 MRU 7 484-tone RU 3 + 242-tone RU 8; [484-tone RU - (gap-242-tone RU) -
31 242-tone RU] in upper 80 MHz channel in lower 160 MHz
32
33 MRU 8 484-tone RU 3 + 242-tone RU 7; [484-tone RU - 242-tone RU - (gap-242-
34 tone RU)] in upper 80 MHz channel in lower 160 MHz
35 MRU 9 484-tone RU 6 + 242-tone RU 10; [(gap-242-tone RU) - 242-tone RU -
36 484-tone RU] in lower 80 MHz channel in upper 160 MHz
37
38 MRU 10 484-tone RU 6 + 242-tone RU 9; [242-tone RU - (gap-242-tone RU) -
39 484-tone RU] in lower 80 MHz channel in upper 160 MHz
40
41 MRU 11 484-tone RU 5 + 242-tone RU 12; [484-tone RU - (gap-242-tone RU) -
42 242-tone RU] in lower 80 MHz channel in upper 160 MHz
43
44 MRU 12 484-tone RU 5 + 242-tone RU 11; [484-tone RU - 242-tone RU - (gap-
45 242-tone RU)] in lower 80 MHz channel in upper 160 MHz
46
47 MRU 13 484-tone RU 8 + 242-tone RU 14; [(gap-242-tone RU) - 242-tone RU -
48 484-tone RU] in upper 80 MHz channel in upper 160 MHz
49 MRU 14 484-tone RU 8 + 242-tone RU 13; [242-tone RU - (gap-242-tone RU) -
50 484-tone RU] in upper 80 MHz channel in upper 160 MHz
51
52 MRU 15 484-tone RU 7 + 242-tone RU 16; [484-tone RU - (gap-242-tone RU) -
53 242-tone RU] in upper 80 MHz channel in upper 160 MHz
54
55 MRU 16 484-tone RU 7 + 242-tone RU 15; [484-tone RU - 242-tone RU - (gap-
56 242-tone RU)] in upper 80 MHz channel in upper 160 MHz
57
58 996+484-tone MRU 1 996-tone RU 2 + 484-tone RU 2; [(gap-484-tone RU) - 484-tone RU -
59 MRU 996-tone RU] in lower 160 MHz
60
61 MRU 2 996-tone RU 2 + 484-tone RU 1; [484-tone RU - (gap-484-tone RU) -
62 996-tone RU] in lower 160 MHz
63 MRU 3 996-tone RU 1 + 484-tone RU 4; [996-tone RU - (gap-484-tone RU) -
64 484-tone RU] in lower 160 MHz
65

550 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-15—Indices for large size MRUs in an OFDMA 320 MHz EHT PPDU and in a non-
2 OFDMA 320 MHz EHT PPDU(#4989)(#5466)(#4903)(#2398) (continued)
3
4
5 MRU type MRU index Combinations
6
7 MRU 4 (#6789)996-tone RU 1 + 484-tone RU 3; [996-tone RU - 484-tone RU -
8 (gap-484-tone RU)] in lower 160 MHz
9
10 MRU 5 996-tone RU 4 + 484-tone RU 6; [(gap-484-tone RU) - 484-tone RU -
11 996-tone RU] in upper 160 MHz
12
13 MRU 6 996-tone RU 4 + 484-tone RU 5; [484-tone RU - (gap-484-tone RU) -
14 996-tone RU] in upper 160 MHz
15
16 MRU 7 996-tone RU 3 + 484-tone RU 8; [996-tone RU - (gap-484-tone RU) -
17 484-tone RU] in upper 160 MHz
18 MRU 8 996-tone RU 3 + 484-tone RU 7; [996-tone RU - 484-tone RU - (gap-484-
19 tone RU)] in upper 160 MHz
20
21 2×996+484-tone MRU 1 996-tone RU 2 + 996-tone RU 3 + 484-tone RU 2; [(gap-484-tone RU) -
22 MRU 484-tone RU - 996-tone RU - 996-tone RU - (gap-996-tone RU)]
23
24 MRU 2 996-tone RU 2 + 996-tone RU 3 + 484-tone RU 1; [484-tone RU - (gap-
25 484-tone RU) - 996-tone RU - 996-tone RU - (gap-996-tone RU)]
26
27 MRU 3 996-tone RU 1 + 996-tone RU 3 + 484-tone RU 4; [996-tone RU - (gap-
28 484-tone RU) - 484-tone RU - 996-tone RU - (gap-996-tone RU)]
29
30 MRU 4 996-tone RU 1 + 996-tone RU 3 + 484-tone RU 3; [996-tone RU - 484-
31 tone RU - (gap-484-tone RU) - 996-tone RU - (gap-996-tone RU)]
32 MRU 5 996-tone RU 1 + 996-tone RU 2 + 484-tone RU 6; [996-tone RU - 996-
33 tone RU - (gap-484-tone RU) - 484-tone RU - (gap-996-tone RU)]
34
35 MRU 6 996-tone RU 1 + 996-tone RU 2 + 484-tone RU 5; [996-tone RU - 996-
36 tone RU - 484-tone RU - (gap-484-tone RU) - (gap-996-tone RU)]
37
38 MRU 7 996-tone RU 3 + 996-tone RU 4 + 484-tone RU 4; [(gap-996-tone RU) -
39 (gap-484-tone RU) - 484-tone RU - 996-tone RU - 996-tone RU]
40
41 MRU 8 996-tone RU 3 + 996-tone RU 4 + 484-tone RU 3; [(gap-996-tone RU) -
42 484-tone RU - (gap-484-tone RU) - 996-tone RU - 996-tone RU]
43
44 MRU 9 996-tone RU 2 + 996-tone RU 4 + 484-tone RU 6; [(gap-996-tone RU) -
45 996-tone RU - (gap-484-tone RU) - 484-tone RU - 996-tone RU]
46 MRU 10 996-tone RU 2 + 996-tone RU 4 + 484-tone RU 5; [(gap-996-tone RU) -
47 996-tone RU - 484-tone RU - (gap-484-tone RU) - 996-tone RU]
48
49 MRU 11 996-tone RU 2 + 996-tone RU 3 + 484-tone RU 8; [(gap-996-tone RU) -
50 996-tone RU - 996-tone RU - (gap-484-tone RU) - 484-tone RU]
51
52 MRU 12 996-tone RU 2 + 996-tone RU 3 + 484-tone RU 7; [(gap-996-tone RU) -
53 996-tone RU - 996-tone RU - 484-tone RU - (gap-484-tone RU)]
54
55 3×996-tone MRU 1 996-tone RU 2 + 996-tone RU 3 + 996-tone RU 4; [(gap-996-tone RU) -
56 MRU 996-tone RU - 996-tone RU - 996-tone RU]
57
58 MRU 2 996-tone RU 1 + 996-tone RU 3 + 996-tone RU 4; [996-tone RU - (gap-
59 996-tone RU) - 996-tone RU - 996-tone RU]
60 MRU 3 996-tone RU 1 + 996-tone RU 2 + 996-tone RU 4; [996-tone RU - 996-
61 tone RU - (gap-996-tone RU) - 996-tone RU]
62
63 MRU 4 996-tone RU 1 + 996-tone RU 2 + 996-tone RU 3; [996-tone RU - 996-
64 tone RU - 996-tone RU - (gap-996-tone RU)]
65

Copyright © 2022 IEEE. All rights reserved. 551

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-15—Indices for large size MRUs in an OFDMA 320 MHz EHT PPDU and in a non-
2 OFDMA 320 MHz EHT PPDU(#4989)(#5466)(#4903)(#2398) (continued)
3
4
5 MRU type MRU index Combinations
6
7 3×996+484-tone MRU 1 996-tone RU 2 + 996-tone RU 3 + 996-tone RU 4 + 484-tone RU 2; [(gap-
8 MRU 484-tone RU) - 484-tone RU - 996-tone RU - 996-tone RU - 996-tone
9 RU]
10
11 MRU 2 996-tone RU 2 + 996-tone RU 3 + 996-tone RU 4 + 484-tone RU 1; [484-
12 tone RU - (gap-484-tone RU) - 996-tone RU - 996-tone RU - 996-tone
13 RU]
14
15 MRU 3 996-tone RU 1 + 996-tone RU 3 + 996-tone RU 4 + 484-tone RU 4; [996-
16 tone RU - (gap-484-tone RU) - 484-tone RU - 996-tone RU - 996-tone
17 RU]
18
19 MRU 4 996-tone RU 1 + 996-tone RU 3 + 996-tone RU 4 + 484-tone RU 3; [996-
20 tone RU - 484-tone RU - (gap-484-tone RU) - 996-tone RU - 996-tone
21 RU]
22 MRU 5 996-tone RU 1 + 996-tone RU 2 + 996-tone RU 4 + 484-tone RU 6; [996-
23 tone RU - 996-tone RU - (gap-484-tone RU) - 484-tone RU - 996-tone
24 RU]
25
26 MRU 6 996-tone RU 1 + 996-tone RU 2 + 996-tone RU 4 + 484-tone RU 5; [996-
27 tone RU - 996-tone RU - 484-tone RU - (gap-484-tone RU) - 996-tone
28 RU]
29
30 MRU 7 996-tone RU 1 + 996-tone RU 2 + 996-tone RU 3 + 484-tone RU 8; [996-
31 tone RU - 996-tone RU - 996-tone RU - (gap-484-tone RU) - 484-tone
32 RU]
33
34 MRU 8 996-tone RU 1 + 996-tone RU 2 + 996-tone RU 3 + 484-tone RU 7; [996-
35 tone RU - 996-tone RU - 996-tone RU - 484-tone RU - (gap-484-tone
36 RU)]
37
38 NOTE 1—“Gap-242/484/996-tone RU” is not part of a MRU and is used to indicate the size of a gap between RUs
39 that form the MRU.
40
41 NOTE 2—In non-OFDMA transmission, “gap-242/484/996-tone RU” indicates that one or more 20 MHz
42 subchannels corresponding to “gap-242/484/996-tone RU” are punctured and is to help indicate the frequency order
43 of the MRU in an 80/160/320 MHz PPDU.
44
45 NOTE 3—In OFDMA transmission, “gap-242/484/996-tone RU” indicates that one or more 20 MHz subchannels
46 corresponding to “gap-242/484/996-tone RU” are punctured or unassigned or used for data transmission by
47 assigning one or multiple RU/MRU and is to help indicate the frequency order of the MRU within an 80/160/240/
48 320 MHz subband.
49
50
51
52 36.3.2.3 Null subcarriers(#1606)
53
54 There are null subcarriers between the 26- and 52-tone RU locations for 20 MHz, 26-, 52-, and 106-tone RU
55 locations for 40 MHz, and 26-, 52-, 106-, 242-, and 484-tone RU locations for 80 MHz as illustrated in
56
Figure 27-5 (RU locations in a 20 MHz HE PPDU), Figure 27-6 (RU locations in a 40 MHz HE PPDU) and
57
58 Figure 36-4 (RU locations in an 80 MHz EHT PPDU(#1984)), respectively. The null subcarriers are located
59 near the DC or edge tones to provide protection from transmit center frequency leakage, receiver DC offset,
60 and interference from neighboring RUs or MRUs. The null subcarriers have zero energy. The indices of the
61 null subcarriers for 20 MHz and 40 MHz are enumerated in Table 27-10 (Null subcarrier indices). The
62
63
64
65

552 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 indices of the null subcarriers for 80 MHz, 160 MHz, and 320 MHz are enumerated in Table 36-16 (Null
2 subcarrier indices for 80 MHz, 160 MHz, and 320 MHz).
3
4
5
6 Table 36-16—Null subcarrier indices for 80 MHz, 160 MHz, and 320 MHz
7
8
9 Channel width RU size Null subcarrier indices
10
11 80 MHz 26, 52, 106 {null subcarrier indices in 40 MHz – 256,
12 null subcarrier indices in 40 MHz + 256,
13 ±254, ±255, ±256, ±257, ±258}
14 242, 484 ±254, ±255, ±256, ±257, ±258
15
16 996 None
17
18 160 MHz 26, 52, 106, {null subcarrier indices in 80 MHz – 512,
19 242, 484 null subcarrier indices in 80 MHz + 512,
20 ±501, ±502, ±503, ±504, ±505, ±506, ±507, ±508, ±509, ±510,
21 ±511, ±512, ±513, ±514, ±515, ±516, ±517, ±518, ±519, ±520,
22 ±521, ±522, ±523}
23
24 996, 2 ±510, ±511, ±512, ±513, ±514
25
26 320 MHz 26, 52, 106, {null subcarrier indices in 160 MHz – 1024,
27 242, 484, 996, null subcarrier indices in 160 MHz + 1024,
28 2 ±1013, ±1014, ±1015, ±1016, ±1017, ±1018, ±1019, ±1020,
29 ±1021, ±1022, ±1023, ±1024, ±1025, ±1026, ±1027, ±1028,
30 ±1029, ±1030, ±1031, ±1032, ±1033, ±1034, ±1035}
31 4 ±510, ±511, ±512, ±513, ±514, ±1013, ±1014, ±1015, ±1016,
32 ±1017, ±1018, ±1019, ±1020, ±1021, ±1022, ±1023, ±1024,
33 ±1025, ±1026, ±1027, ±1028, ±1029, ±1030, ±1031, ±1032,
34 ±1033, ±1034, ±1035, ±1534, ±1535, ±1536, ±1537, ±1538
35
36
37
38 (#7157)The indices of the null subcarriers for MRUs are determined by the size and the location of each
39
component RU in each bandwidth.
40
41
42 36.3.2.4 Pilot subcarriers
43
44 Pilot subcarriers are present in the Data field, and may be present in the EHT-LTF field. The pilot subcarrier
45
indices for the Data field OFDM symbols are defined in 36.3.13.11 (Pilot subcarriers).
46
47
48 (#1301)One of three EHT-LTF types is used in the EHT-LTF field of an EHT PPDU: 1 EHT-LTF, 2 EHT-
49 LTF, and 4 EHT-LTF. (#1251)(#2606)(#3042)(#4685)For an EHT TB PPDU with 1 EHT-LTF, pilots are
50 not used (see 36.3.12.10 (EHT-LTF)). For an EHT PPDU with a 4 EHT-LTF or 2 EHT-LTF, the pilot
51
subcarrier locations in the EHT-LTF field are the same as the pilot subcarrier locations in the Data field.
52
53
54 36.3.2.5 20 MHz operating non-AP EHT STAs(#1244)(#1254)
55
56 (#1285)(#2766)A 20 MHz operating non-AP EHT STA is a non-AP EHT STA (#7160)that is operating in a
57
20 MHz channel width, such as a 20 MHz-only non-AP EHT STA or a non-AP EHT STA that reduces its
58
59 operating channel width to 20 MHz (see 36.1.1 (Introduction to the EHT PHY)).
60
61 (#4626)The operating channel width of a non-AP EHT STA is identified by a CHANNEL_WIDTH
62 parameter contained in the PHYCONFIG_VECTOR carried in a PHY-CONFIG.request primitive (see
63
36.2.4 (PHY CONFIG_VECTOR)).
64
65

Copyright © 2022 IEEE. All rights reserved. 553

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#4626)NOTE 1—The supported channel width of a non-AP EHT STA is indicated in the Supported Channel Width
2 subfield in the HE PHY Capabilities Information field (see 9.4.2.248.3 (HE PHY Capabilities Information field)) and the
3 Support For 320 MHz In 6 GHz subfield in the EHT Capabilities element (see 9.4.2.313.3 (EHT PHY Capabilities
4 Information field))(#7159).
5
6 (#4626)NOTE 2—The operating channel width may be updated by Operating Mode Notification frame, Operating
7 Mode Notification element with the Rx NSS Type subfield equal to 0, or Channel Width subfield in the OM Control
8 subfield (see 9.2.4.6a.2 (OM Control)) if the EHT OM Control subfield (9.2.4.7.8 (EHT OM Control)) is not present in
9 the same A-Control field, or the Channel Extension subfield in the EHT OM Control subfield together and with the OM
10 Control subfield sent by the EHT STA(#7160)(#4537).
11
12
A 20 MHz operating non-AP EHT STA shall (#4537)support the transmission and reception of 26-tone RU,
13
14 52-tone RU, 106-tone RU, 242-tone RU, 52+26-tone MRU, and 106+26-tone MRU in a 20 MHz EHT
15 PPDU (see Table 27-7 (Data and pilot subcarrier indices for RUs in a 20 MHz HE PPDU and in a non-
16 OFDMA 20 MHz HE PPDU) and Table 36-8 (Indices for small size MRUs in an OFDMA 20 MHz EHT
17 PPDU)). An EHT AP shall be able to allocate an RU (see Table 27-7 (Data and pilot subcarrier indices for
18
RUs in a 20 MHz HE PPDU and in a non-OFDMA 20 MHz HE PPDU)) or MRU (see Table 36-8 (Indices
19
20 for small size MRUs in an OFDMA 20 MHz EHT PPDU)) in a 20 MHz EHT PPDU(#4537) to a 20 MHz
21 operating non-AP EHT STA.
22
23 (#2359)(#3095)(#2781)A 20 MHz operating non-AP EHT STA shall support (#4537)the transmission and
24
reception of 26-tone RU, 52-tone RU, 106-tone RU, and 52+26-tone MRU in locations allowed in 36.3.2.6
25
26 (RU and MRU restrictions for 20 MHz operation(#3276)) within its operating channel for (#6930)a
27 40 MHz, 80 MHz, 160 MHz, and 320 MHz OFDMA EHT PPDU. A 20 MHz operating non-AP EHT STA
28 may support (#4537)the reception of 242-tone RU within its operating channel for (#6930)a 40 MHz,
29 80 MHz, 160 MHz, and 320 MHz OFDMA EHT PPDU (see 36.3.2.6 (RU and MRU restrictions for
30
20 MHz operation(#3276))). (#3165)An EHT AP with an operating channel width greater than 20 MHz
31
32 shall be able to allocate an RU (see 36.3.2.1 (Subcarriers and resource allocation in EHT PPDUs(#4636))) or
33 MRU (see 36.3.2.2 (Subcarriers and resource allocation for multiple RUs)) on a 20 MHz channel within the
34 BSS bandwidth in (#6930)a 40 MHz, 80 MHz, 160 MHz or 320 MHz (#4537)OFDMA EHT PPDU to a
35 20 MHz operating non-AP EHT STA depending on the AP’s operating channel width. The AP’s operating
36
channel (#7164)width is the same as the BSS channel width. When an EHT AP assigns an RU or MRU to a
37
38 20 MHz operating non-AP EHT STA, the EHT AP shall follow the restrictions for 20 MHz operation in
39 36.3.2.6 (RU and MRU restrictions for 20 MHz operation(#3276))(#4537).
40
41 (#4633)NOTE 3—As defined in 35.12.4 (CENTER_FREQUENCY_SEGMENT(#4633)), a 20 MHz operating non-AP
42 EHT STA operates in the primary 20 MHz channel except when the 20 MHz operating non-AP EHT STA sets
43 dot11HESubchannelSelectiveTransmissionImplemented equal to true(#7165) in which case the 20 MHz operating non-
44 AP EHT STA might operate in any 20 MHz channel within the BSS bandwidth of (#5525)40 MHz, 80 MHz or
45 160 MHz. (#6930)The 20 MHz operating non-AP EHT STA might also operate in any 20 MHz channel within the
46 primary 160 MHz when the BSS bandwidth is 320 MHz.
47
48 An EHT AP shall not allocate an RU or MRU outside of the primary 20 MHz in (#5526)a 40 MHz, 80 MHz,
49 160 MHz, or 320 MHz EHT MU or EHT TB PPDU to an 20 MHz operating non-AP EHT STA if the
50 20 MHz operating non-AP EHT STA has not set up SST operation on the nonprimary 20 MHz channel with
51
the EHT AP.
52
53
54 36.3.2.6 RU and MRU restrictions for 20 MHz operation(#3276)
55
56 (#1302)(#3276)For a 20 MHz operating non-AP EHT STA receiving a 40 MHz, 80 MHz, 160 MHz, or
57
320 MHz EHT MU PPDU, or transmitting a 40 MHz, 80 MHz, 160 MHz, or 320 MHz EHT TB PPDU,
58
59 (#5467)it is noteworthy that the 20 MHz RU or MRU tone mapping (see 36.3.2 (Subcarrier and resource
60 allocation)) is not aligned with the 40 MHz, 80 MHz, 160 MHz, or 320 MHz RU or MRU tone mapping
61 (see 36.3.2.1 (Subcarriers and resource allocation in EHT PPDUs(#4636))).
62
63
(#1553)(#3276)(#3080)(#4653)A 20 MHz operating non-AP EHT STA does not support the following RUs
64
65 or MRUs where the RU indices are defined in Table 27-8 (Data and pilot subcarrier indices for RUs in a

554 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 40 MHz HE PPDU and in a non-OFDMA 40 MHz HE PPDU) and the MRU indices are defined in Table 36-
2 9 (Indices for small size MRUs in an OFDMA 40 MHz EHT PPDU):
3
4 — 26-tone RU 5 and 14 of a 40 MHz EHT MU PPDU (receive) and EHT TB PPDU (transmit)
5 — (#2992)(#3277)52+26-tone MRU 2 and 5 of a 40 MHz EHT MU PPDU (receive) and EHT TB
6
PPDU (transmit)
7
8
9 (#1553)(#3276)(#3080)(#4653)A 20 MHz operating non-AP EHT STA does not support the following RUs
10 or MRUs where the RU indices are defined in Table 36-5 (Data and pilot subcarrier indices for RUs in an
11 80 MHz EHT PPDU) and the MRU indices are defined in Table 36-10 (Indices for small size MRUs in an
12
OFDMA 80 MHz EHT PPDU):
13
14 — 26-tone RU 5, 14, 24, and 33 of an 80 MHz EHT MU PPDU (receive) and EHT TB PPDU (transmit)
15
— (#2992)(#3277)52+26-tone MRU 2, 5, 8, and 11 of an 80 MHz EHT MU PPDU (receive) and EHT
16
17 TB PPDU (transmit)
18
19 (#1553)(#3276)(#3080)(#4653)A 20 MHz operating non-AP EHT STA does not support the following RUs
20 or MRUs where the RU indices are defined in Table 36-6 (Data and pilot subcarrier indices for RUs in a
21
160 MHz EHT PPDU) and the MRU indices are defined in Table 36-11 (Indices for small size MRUs in an
22
23 OFDMA 160 MHz EHT PPDU):
24 — 26-tone RU 5, 14, 24, 33, 42, 51, 61, and 70 of a 160 MHz EHT MU PPDU (receive) and EHT TB
25 PPDU (transmit)
26
27 — (#2992)(#3277)52+26-tone MRU 2, 5, 8, 11, 14, 17, 20, and 23 of a 160 MHz EHT MU PPDU
28 (receive) and EHT TB PPDU (transmit)
29
30
(#1553)(#3276)(#3080)(#4653)A 20 MHz operating non-AP EHT STA does not support the following RUs
31
32 or MRUs where the RU indices are defined in Table 36-7 (Data and pilot subcarrier indices for RUs in a
33 320 MHz EHT PPDU) and the MRU indices are defined in Table 36-12 (Indices for small size MRUs in an
34 OFDMA 320 MHz EHT PPDU):
35
36 — 26-tone RU 5, 14, 24, 33, 42, 51, 61, 70, 79, 88, 98, 107, 116, 125, 135, and 144 of a 320 MHz EHT
37 MU PPDU (receive) and EHT TB PPDU (transmit)
38 — (#2992)(#3277)52+26-tone MRU 2, 5, 8, 11, 14, 17, 20, 23, 26, 29, 32, 35, 38, 41, 44, and 47 of a
39
320 MHz EHT MU PPDU (receive) and EHT TB PPDU (transmit)
40
41
42 (#1304)(#3277)(#4653)A 20 MHz operating non-AP EHT STA does not support any 106+26-tone MRUs
43 for 40 MHz, 80 MHz, 160 MHz, and 320 MHz EHT MU PPDU (receive) and EHT TB PPDU (transmit).
44
45
(#1252)(#1304)(#4653)A 20 MHz operating non-AP EHT STA does not support any 242-tone RUs for
46
47 40 MHz, 80 MHz, 160 MHz, and 320 MHz EHT TB PPDU (transmit).
48 (#4653)NOTE 1—As defined in 35.5.1.2 (RU allocation in an EHT MU PPDU(#1306)), an EHT AP does not assign an
49 RU or MRU to a STA that does not support the RU or MRU.
50
51
52 (#1305)A 20 MHz operating non-AP EHT STA may support reception of a 242-tone RU for 40 MHz EHT
53 MU PPDU (see Table 27-8 (Data and pilot subcarrier indices for RUs in a 40 MHz HE PPDU and in a non-
54 OFDMA 40 MHz HE PPDU)) in the 2.4 GHz, 5 GHz, and 6 GHz bands, 80 MHz and 160 MHz EHT MU
55 PPDU (see Table 36-5 (Data and pilot subcarrier indices for RUs in an 80 MHz EHT PPDU) and Table 36-6
56
(Data and pilot subcarrier indices for RUs in a 160 MHz EHT PPDU)) in the 5 GHz and 6 GHz bands, and
57
58 320 MHz EHT MU PPDU (see Table 36-7 (Data and pilot subcarrier indices for RUs in a 320 MHz EHT
59 PPDU)) in the 6 GHz band. (#1306)This PHY capability is indicated to the MAC sublayer by
60 dot11EHTSupportFor242ToneRUInBWWiderThan20Implemented.
61
62 (#1306)NOTE 2—The STA advertises the value of dot11EHTSupportFor242ToneRUInBWWiderThan20Implemented
63 in the Support For 242-tone RU In BW Wider Than 20 MHz subfield in the EHT PHY Capabilities Information field in
64 the EHT Capabilities element (see 9.4.2.313.3 (EHT PHY Capabilities Information field)).
65

Copyright © 2022 IEEE. All rights reserved. 555

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 36.3.2.7 80 MHz operating non-AP EHT STAs(#1244)(#1254)

2
3
An 80 MHz operating non-AP EHT STA is a non-AP EHT STA (#4651)that supports an operating channel
4
5 width up to 80 MHz in the current operating mode (see 36.1.1 (Introduction to the EHT PHY)).
6 (#4538)NOTE 1—The indication of the supported channel width (#4651)defined in the Supported Channel Width Set
7 subfield in the HE Capabilities element and the Supported For 320 MHz In 6 GHz subfield in the EHT Capabilities
8 element and the operating channel width (#4651)identified by the CHANNEL_WIDTH parameter contained in the
9 PHYCONFIG_VECTOR of a non-AP EHT STA are described in 36.3.2.5 (20 MHz operating non-AP EHT
10 STAs(#1244)(#1254)).
11
12
13 (#3268)An 80 MHz operating non-AP EHT STA shall be able to participate in 80 MHz, 160 MHz, and
14 320 MHz EHT DL and UL OFDMA transmissions, and (#6794)in 80 MHz EHT DL and UL non-OFDMA
15 transmissions. (#3165)An EHT AP (#4651)with a CHANNEL_WIDTH parameter equal to or greater than
16 80 MHz shall be able to allocate an RU (see 36.3.2.1 (Subcarriers and resource allocation in EHT
17
PPDUs(#4636)) or MRU (see 36.3.2.2 (Subcarriers and resource allocation for multiple RUs)) within the 80
18
19 MHz operating bandwidth of the non-AP EHT STA in an 80 MHz, 160 MHz or 320 MHz EHT MU or EHT
20 TB PPDU(#4539).
21
22 (#4633)NOTE 2—As defined in 35.12.4 (CENTER_FREQUENCY_SEGMENT(#4633)), an 80 MHz operating non-
23 AP EHT STA operates in the primary 80 MHz channel (#6795)and might operate in the secondary 80 MHz channel
24 (#7169)that does not include any inactive 20 MHz subchannel when the 80 MHz operating non-AP EHT STA sets
25 dot11HESubchannelSelectiveTransmissionImplemented to true.
26
27 (#4649)NOTE 3—As defined in 35.5.1.2 (RU allocation in an EHT MU PPDU(#1306)), (#6796)an EHT AP does not
28 allocate an RU or MRU in the secondary 160 MHz of a 320 MHz EHT MU or EHT TB PPDU to an 80 MHz operating
29 non-AP EHT STA. An EHT AP does not allocate an RU or MRU in the secondary 80 MHz channel of a 160 MHz or
30 320 MHz EHT MU or EHT TB PPDU to an 80 MHz operating non-AP EHT STA, if the 80 MHz operating non-AP
31 EHT STA has not set up SST operation (#5567)by following the procedure in 26.8.7 (HE subchannel selective
32 transmission) on the secondary 80 MHz channel with the EHT AP or if there is an (#7169)inactive 20 MHz subchannel
33 within the secondary 80 MHz channel.
34
35 An 80 MHz operating non-AP EHT STA shall support all RU and MRU sizes within its operating 80 MHz
36 channel when participating in (#6794)80 MHz EHT DL and UL non-OFDMA transmissions and 80 MHz,
37
160 MHz or 320 MHz EHT DL and UL OFDMA transmissions.
38
39
40 An 80 MHz operating non-AP EHT STA shall be able to transmit the preamble and data in the allocated RU
41 or MRU within its operating 80 MHz channel in (#6794)an 80 MHz, 160 MHz or 320 MHz EHT TB PPDU.
42
43
(#3096)An 80 MHz operating non-AP EHT STA shall be able to support the reception of the preamble and
44
45 data in the allocated RU or MRU within its operating 80 MHz channel in (#6794)an 80 MHz, 160 MHz or
46 320 MHz EHT MU PPDU.
47
48 36.3.2.8 160 MHz operating non-AP EHT STAs(#1244)(#1254)
49
50
51 A 160 MHz operating non-AP EHT STA is a non-AP EHT STA (#4651)that supports an operating channel
52 width up to 160 MHz in the current operating mode (see 36.1.1 (Introduction to the EHT PHY)). The
53 indications of the supported channel width defined in the Supported Channel Width Set subfield in the HE
54 Capabilities element and the Support For 320 MHz In 6 GHz subfield in the EHT Capabilities element, and
55
the operating channel width identified by the CHANNEL_WIDTH parameter contained in the
56
57 PHYCONFIG_VECTOR of a 160 MHz operating non-AP EHT STA are described in 36.3.2.5 (20 MHz
58 operating non-AP EHT STAs(#1244)(#1254)).
59
60 A 160 MHz operating non-AP EHT STA shall be able to participate in (#4651)320 MHz EHT DL and UL
61
OFDMA transmissions. (#3165)An EHT AP with CHANNEL_WIDTH parameter (#6797)greater than or
62
63 equal to 160 MHz shall be able to allocate an RU or MRU on the primary 160 MHz channel in a 160 MHz
64 or 320 MHz EHT MU or EHT TB PPDU to a 160 MHz operating non-AP EHT STA.
65

556 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#4650)NOTE—As defined in 35.5.1.2 (RU allocation in an EHT MU PPDU(#1306)), an EHT AP (#7172)with

2 dot11EHTBaseLineFeaturesImplementedOnly equal to true, can allocate an RU or MRU only on the primary 160 MHz
3 in a 320 MHz EHT MU or EHT TB PPDU, to a 160 MHz operating non-AP EHT STA.
4
5 A 160 MHz operating non-AP EHT STA shall support all RU and MRU sizes within the primary 160 MHz
6
channel when participating in 320 MHz EHT DL and UL OFDMA transmissions.
7
8
9 A 160 MHz operating non-AP EHT STA shall be able to transmit the preamble and data in the allocated RU
10 or MRU on the primary 160 MHz channel in a 320 MHz EHT TB PPDU.
11
12
(#3097)A 160 MHz operating non-AP EHT STA shall be able to support the reception of the preamble and
13
14 data in the allocated RU or MRU on the primary 160 MHz channel (#6987)in a 320 MHz EHT MU PPDU.
15
16 36.3.3 MU-MIMO
17
18
36.3.3.1 DL MU-MIMO
19
20
21 36.3.3.1.1 Supported RU/MRU sizes in DL MU-MIMO(#2699)
22
23 A STA that sets the Partial Bandwidth DL MU-MIMO subfield of the EHT PHY Capabilities Information
24
field in the EHT Capabilities element that it transmits to 1(#4627), where, as defined in 35.12.3 (Contents of
25
26 the EHT PHY Capabilities Information field and Supported EHT-MCS And NSS Set field(#4627)), this
27 subfield is determined in turn by dot11EHTPartialBWDLMUMIMOImplemented, shall support receiving
28 an RU/MRU in an EHT PPDU where MU-MIMO is employed in the RU/MRU, the RU/MRU size being
29 greater than or equal to 242 tones, and where there are multiple RUs/MRUs within the PPDU bandwidth.
30
31
32 36.3.3.1.2 Maximum number of spatial streams in an EHT MU PPDU
33
34 An EHT STA shall support the reception of non-OFDMA DL MU-MIMO transmissions with a maximum
35
number of spatial streams (per user) that (#7969)is min  N  ss max rx SU  4  where N  ss max rx SU  is the
36 tx tx
37 maximum number of spatial streams supported for reception of an EHT MU PPDU that is sent to that STA
38
as an SU transmission. The maximum number of spatial streams supported for reception of an EHT MU
39
40 PPDU when sent to a STA as part of an SU transmission is indicated for various bandwidths in the
41 Supported EHT-MCS And NSS Set field in the EHT Capabilities element(#4627), where, as defined in
42 35.12.3 (Contents of the EHT PHY Capabilities Information field and Supported EHT-MCS And NSS Set
43 field(#4627)), this field is determined in turn by
44
dot11EHTSupportedEhtMcsAndNssSet20MhzOnlyStaImplemented for a 20 MHz-only non-AP STA and
45
46 by dot11EHTSupportedEhtMcsAndNssSetImplemented for other STAs. (#7970)The maximum number of
47 spatial streams supported for reception of an EHT MU PPDU when sent to a STA as part of an SU
48 transmission can also be limited by either an operating mode notification, or the operating mode indication
49 (OMI) procedure.
50
51
52 (#1307)(#1554)(#4802)(#7748)For EHT MU PPDUs using a bandwidth less than or equal to 80 MHz, equal
53 to 160 MHz, or equal to 320 MHz, a non-AP EHT STA shall support the reception of (#4993)non-OFDMA
54 DL MU-MIMO transmissions with the total number of spatial streams (across all users) that is supported for
55 the reception of an EHT MU PPDU up to the value indicated by the Beamformee SS (≤ 80 MHz),
56
Beamformee SS (= 160 MHz), or Beamformee SS (= 320 MHz) subfield, respectively, in the EHT PHY
57
58 Capabilities Information field in the EHT Capabilities element(#4627), where, as defined in 35.12.3
59 (Contents of the EHT PHY Capabilities Information field and Supported EHT-MCS And NSS Set
60 field(#4627)), this subfield is determined in turn by dot11EHTBeamformeeSSLessThanOrEqualTo80,
61 dot11EHTBeamformeeSSLessThanOrEqualTo160, or dot11EHTBeamformeeSSLessThanOrEqualTo320,
62
respectively.
63
64
65

Copyright © 2022 IEEE. All rights reserved. 557

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#4627)If dot11EHTSUBeamformeeImplemented is true, the minimum value for each of the Beamformee
2 SS (≤ 80 MHz), Beamformee SS (= 160 MHz), and Beamformee SS (= 320 MHz) subfields is 3, because
3
the minimum value of each of dot11EHTBeamformeeSSLessThanOrEqualTo80,
4
5 dot11EHTBeamformeeSSEqualTo160, and dot11EHTBeamformeeSSEqualTo320 is 4.
6
7 (#4627)(#1329)The support by an EHT AP of EHT non-OFDMA DL MU-MIMO transmission on an RU or
8 MRU size greater than or equal to 242 tones in a bandwidth up to 80 MHz, 160 MHz or 320 MHz is
9
indicated in the respective MU beamformer (BW ≤ 80 MHz), (BW = 160 MHz) or (BW = 320 MHz)
10
11 subfield in the EHT PHY Capabilities Information field in the EHT Capabilities element, where each of
12 these subfields is determined in turn by dot11EHTMUBeamformerLessThanOrEqualTo80Implemented,
13 dot11EHTMUBeamformerEqualTo160Implemented, or
14 dot11EHTMUBeamformerEqualTo320Implemented, respectively (see 35.12.3 (Contents of the EHT PHY
15
Capabilities Information field and Supported EHT-MCS And NSS Set field(#4627))). The number of spatial
16
17 streams that an EHT AP supports for transmission from a single STA in an EHT PPDU with bandwidth up to
18 80 MHz, 160 MHz or 320 MHz is determined from the transmit-related subfields for the respective
19 bandwidth in the Supported EHT-MCS And NSS Set field in the EHT Capabilities element sent by the AP,
20 where this field is determined in turn by dot11EHTSupportedEhtMcsAndNssSetmplemented. An EHT AP
21
shall set dot11EHTMUBeamformerLessThanOrEqualTo80Implemented,
22
23 dot11EHTMUBeamformerEqualTo160Implemented, and
24 dot11EHTMUBeamformerEqualTo320Implemented to true if the AP supports at least four spatial streams
25 for the transmission to a single STA in a bandwidth of up to 80 MHz, 160 MHz or 320 MHz, the MU
26 beamformer (BW ≤ 80 MHz), (BW = 160 MHz) or (BW = 320 MHz), respectively; and accordingly the
27
MU beamformer (BW ≤ 80 MHz), (BW = 160 MHz) or (BW = 320 MHz) subfield indicates support of the
28
29 EHT non-OFDMA DL MU-MIMO transmission in the respective bandwidth.
30
31 All of the aforementioned requirements in this subclause on the per user and total number of spatial streams
32 are also applicable to an MU-MIMO transmission on an RU/MRU in an EHT PPDU which consists of more
33
than one RU/MRU within the PPDU bandwidth (#7174)if the STA indicates support for this feature.
34
35
36 36.3.3.2 UL MU-MIMO
37
38 36.3.3.2.1 Introduction
39
40
41 UL MU-MIMO is a technique to allow multiple STAs to transmit simultaneously over the same frequency
42 resource to the receiver. The concept is very similar to SU-MIMO where multiple spatial streams are
43 transmitted simultaneously over the same frequency resource utilizing spatial multiplexing through multiple
44 antennas at the transmitter and receiver. The key difference from SU-MIMO is that in UL MU-MIMO, the
45
transmitted streams originate from multiple STAs.
46
47
48 36.3.3.2.2 Supported RU/MRU sizes in UL MU-MIMO(#4591)
49
50 An AP that sets the Partial Bandwidth UL MU-MIMO subfield of the EHT PHY Capabilities Information
51
field in the EHT Capabilities element that it transmits to 1 (#4627)where, as defined in 35.12.3 (Contents of
52
53 the EHT PHY Capabilities Information field and Supported EHT-MCS And NSS Set field(#4627)), this
54 subfield is determined in turn by dot11EHTPartialBWULMUMIMOImplemented, shall support receiving
55 an RU/MRU in an EHT TB PPDU where MU-MIMO is employed in an RU/MRU, the RU/MRU size being
56 greater than or equal to 242 tones, and where there are multiple RUs/MRUs within the PPDU bandwidth.
57
58
59 (#2788)(#3279)(#4627)The support by an EHT AP of EHT non-OFDMA UL MU-MIMO reception of an
60 RU or MRU size greater than or equal to 242 tones in a bandwidth up to 80 MHz, 160 MHz or 320 MHz is
61 indicated in the respective Non-OFDMA UL MU-MIMO (BW ≤ 80 MHz), (BW = 160 MHz) or
62 (BW = 320 MHz) subfield in the EHT PHY Capabilities Information field in the EHT Capabilities element,
63
where each of these subfields is determined in turn by
64
65 dot11EHTNonOFDMAULMUMIMOLessThanOrEqualto80Implemented,

558 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 dot11EHTNonOFDMAULMUMIMOEqualto160Implemented, or
2 dot11EHTNonOFDMAULMUMIMOEqualto320Implemented, respectively (see 35.12.3 (Contents of the
3
EHT PHY Capabilities Information field and Supported EHT-MCS And NSS Set field(#4627))). The
4
5 number of spatial streams that an EHT AP supports for reception from a single STA in an EHT PPDU with
6 bandwidth up to 80 MHz, 160 MHz or 320 MHz is determined from the receive-related subfields for the
7 respective bandwidth in the Supported EHT-MCS And NSS Set field in the EHT Capabilities element sent
8 by the AP, where this field is determined in turn by dot11EHTSupportedEhtMcsAndNssSetmplemented. An
9
EHT AP shall set dot11EHTNonOFDMAULMUMIMOLessThanOrEqualto80Implemented,
10
11 dot11EHTNonOFDMAULMUMIMOEqualto160Implemented, and
12 dot11EHTNonOFDMAULMUMIMOEqualto320Implemented to true if the AP supports the reception of at
13 least four spatial streams from a single STA in a bandwidth of up to 80 MHz, 160 MHz or 320 MHz; and
14 accordingly the Non-OFDMA UL MU-MIMO (BW ≤ 80 MHz), (BW = 160 MHz) or (BW = 320 MHz)
15
subfield indicates support of EHT non-OFDMA UL MU-MIMO reception in the respective bandwidth.
16
17
18 A non-AP STA that sets the Partial Bandwidth UL MU-MIMO subfield of the EHT PHY Capabilities
19 Information field in the EHT Capabilities element that it transmits to 1(#4627), where, as defined in 35.12.3
20 (Contents of the EHT PHY Capabilities Information field and Supported EHT-MCS And NSS Set
21
field(#4627)), this subfield is determined by dot11EHTPartialBWULMUMIMOImplemented, shall support
22
23 transmitting an RU/MRU in an EHT TB PPDU where UL MU-MIMO is employed in the RU/MRU, the
24 RU/MRU size being greater than or equal to 242 tones, and where there are multiple RUs/MRUs within the
25 PPDU bandwidth.
26
27
A non-AP STA shall support non-OFDMA UL MU-MIMO transmission on all RU/MRU sizes greater than
28
29 or equal to 242 tones in the supported bandwidths.
30
31 36.3.3.2.3 UL MU-MIMO EHT-LTF mode
32
33
A non-AP STA shall support, for UL MU-MIMO transmissions in an EHT TB PPDU, transmission of
34
35 1 EHT-LTFs(#5400) without pilots and transmission of 2 and 4 EHT-LTFs(#5400) with single stream
36 pilots.
37
38 36.3.3.2.4 Maximum number of spatial streams in UL MU-MIMO
39
40
41 A non-AP STA shall support transmitting an EHT TB PPDU using MU-MIMO where:
42 — The number of spatial streams allocated to the non-AP STA ranges from 1 to N, (#7969)where N is
43 min  N  ss max SU  4  , where N  ss max SU  is the maximum number of spatial streams supported
44 tx tx
45 by the non-AP STA for SU transmissions.
46
47 (#3155)(#7176)The total number of spatial streams for the EHT TB PPDU summed across all the scheduled
48 users using MU-MIMO is less than or equal to 8. (#5092)For the non-AP STA that supports the partial
49 bandwidth based UL MU-MIMO, the total number of spatial streams (summed over all users) for RU/MRU
50
51 of an EHT TB PPDU across all scheduled users using MU-MIMO is less than or equal to 8.
52
53 The maximum number of spatial streams supported by a STA for SU transmissions is indicated in the
54 Supported EHT-MCS And NSS Set field in the EHT Capabilities element(#4627), where, as defined in
55 35.12.3 (Contents of the EHT PHY Capabilities Information field and Supported EHT-MCS And NSS Set
56
57 field(#4627)), this field is determined in turn by the maximum number of spatial streams supported among
58 the transmit-related subfields of dot11EHTSupportedEhtMcsAndNssSet20MhzOnlyImplemented for a 20
59 MHz-only non-AP STA and by the maximum number of spatial streams supported among the transmit-
60 related subfields of dot11EHTSupportedEhtMcsAndNssSetmplemented for other STAs.
61
62
63 (#7178)All the requirements in this subclause on the per user and total number of spatial streams are
64 applicable to both
65

Copyright © 2022 IEEE. All rights reserved. 559

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — non-OFDMA UL MU-MIMO transmissions, and

2
3 — UL MU-MIMO(#2767) transmissions in an EHT TB PPDU which consists of more than one RU/
4 MRU within the PPDU bandwidth if the STA indicates support for this feature.
5
6 36.3.3.3 Maximum number of users in MU-MIMO
7
8
9 The maximum number of EHT STAs that can be multiplexed using MU-MIMO on an RU/MRU is 8, both
10 for DL and UL. This is applicable to both non-OFDMA MU-MIMO transmissions as well as to MU-MIMO
11 transmissions in an EHT PPDU which consists of more than one RU/MRU within the PPDU bandwidth.
12
13 36.3.4 EHT PPDU formats
14
15
16 Two EHT PPDU formats are defined: EHT MU PPDU and EHT TB PPDU(#2660).
17
18 (#7179)The format of the EHT MU PPDU is defined in Figure 36-17 (EHT MU PPDU
19 format(#1309)(#1963)(#3156)). (#5470)This format is used for transmission to one or more users. The
20
21 PPDU is not a response to a triggering frame. In the EHT MU PPDU, the EHT-SIG field is present.
22
23 EHT-LTF symbol duration depends on the GI + LTF size
24 8μs:4μs per 4μs per
25 8μs 8μs 4μs 4μs symbol symbol 4μs
EHT-
26 L-STF L-LTF L-SIG RL-SIG U-SIG EHT-SIG
STF
EHT-LTF  EHT-LTF Data PE

27
28 Figure 36-17—EHT MU PPDU format(#1309)(#1963)(#3156)
29
30
31 (#1255)(#1310)(#7179)The format of the EHT TB PPDU is defined in Figure 36-18 (EHT TB PPDU
32 format(#1309)(#1964)(#3156)). This format is used for a transmission that is a response to a triggering
33 frame from an AP. In the EHT TB PPDU, the EHT-SIG field is not present and the duration of the EHT-STF
34 field is twice the duration of the EHT-STF field in the EHT MU PPDU.
35
36 EHT-LTF symbol duration depends on the GI + LTF size
37 8μs: 4μs per
symbol
38 8μs 8μs 4μs 4μs 8μs

39 L-STF L-LTF L-SIG RL-SIG U-SIG EHT-STF EHT-LTF  EHT-LTF Data PE

40
41 Figure 36-18—EHT TB PPDU format(#1309)(#1964)(#3156)
42
43
44 The fields of the EHT PPDU formats are summarized in Table 36-17 (EHT PPDU fields).
45
46
47 Table 36-17—EHT PPDU fields
48
49
50 Field Description
51
52 L-STF Non-HT Short Training field
53
54 L-LTF Non-HT Long Training field
55
56 L-SIG Non-HT SIGNAL field
57
RL-SIG Repeated Non-HT SIGNAL field
58
59 U-SIG Universal SIGNAL field
60
61 EHT-SIG EHT SIGNAL field
62
63 EHT-STF EHT Short Training field
64
65

560 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-17—EHT PPDU fields (continued)

2
3
4 Field Description
5
6 EHT-LTF EHT Long Training field
7
8 Data The Data field carrying the PSDU(s)
9
10 PE Packet extension field
11
12
13 (#4663)The RL-SIG, U-SIG, EHT-STF, EHT-LTF, and PE fields are present in the two EHT PPDU formats.
14
The EHT-SIG field is present only in the EHT MU PPDU. The PE field is defined in 36.3.14 (Packet
15
16 extension).
17
18 The L-STF, L-LTF, L-SIG, RL-SIG, U-SIG, and EHT-SIG fields are referred to as pre-EHT modulated
19 fields, (#3157)while the EHT-STF, EHT-LTF, Data, and PE fields are referred to as the EHT modulated
20
fields.
21
22
23 (#1311)(#2762)(#3158)(#5399)In the EHT TB PPDU, the pre-EHT modulated fields, which include L-STF,
24 L-LTF, L-SIG, RL-SIG, and U-SIG fields, are sent only on the 20 MHz channels where the STA’s EHT
25 modulated fields are present. If the STA’s EHT modulated fields occupy more than one 20 MHz channel, the
26
pre-EHT modulated fields are duplicated over multiple 20 MHz channels(#2947).
27
28
29 (#3168)A signal extension as described in 10.3.8 (Signal extension) shall be present in a transmitted PPDU
30 if the TXVECTOR parameter NO_SIG_EXTN is false and one of the following conditions applies:
31
32 — The TXVECTOR parameter FORMAT is EHT, HE, HT_MF, or HT_GF.
33 — The TXVECTOR parameter FORMAT is NON_HT and the TXVECTOR parameter
34 NON_HT_MODULATION is ERP-OFDM or NON_HT_DUP_OFDM.
35
36
37 A signal extension shall be assumed to be present (for the purpose of timing of PHY-RXEND.indication and
38 PHY-CCA.indication primitives, as described below and in 36.3.22 (EHT receive procedure)) in a received
39 PPDU if one of the following conditions applies:
40
41 — The RXVECTOR parameter FORMAT is EHT, HE, HT_MF, or HT_GF.
42 — The RXVECTOR parameter FORMAT is NON_HT and the RXVECTOR parameter
43 NON_HT_MODULATION is ERP-OFDM or NON_HT_DUP_OFDM.
44
45
46 A PPDU containing a signal extension is called a signal extended PPDU. When transmitting a signal
47 extended PPDU, the PHY-TXEND.indication primitive shall be emitted a period of aSignalExtension after
48 the end of the actual ending time of the PPDU. When receiving a signal extended PPDU, the
49 PHY-RXEND.indication primitive shall be emitted a period of aSignalExtension after the end of the actual
50
ending time of the PPDU.
51
52
53 36.3.5 EHT DUP transmission(#7637)
54
55 (#7181)EHT duplicate (EHT DUP) transmission is a mode wherein the transmitted data in the payload
56
portion of the PPDU is duplicated in frequency.
57
58
59 EHT DUP mode is an optional mode that is applicable only in the 6 GHz band. EHT DUP mode is
60 applicable only (#7311)for non-OFDMA transmission to (#4851)a single user in an EHT MU PPDU. EHT
61 DUP mode shall only be used with bandwidth 80/160/320 MHz and without preamble puncturing.
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 561

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 EHT DUP mode is applicable only in conjunction with BPSK-DCM modulation, (#7182)rate-1/2 LDPC
2 coding and N SS = 1 .
3
4
5 EHT DUP mode is signaled by setting the PPDU Type And Compression Mode subfield in the U-SIG
6 field(#7005)(#5657) (Table 36-28 (U-SIG field of an EHT MU PPDU)) to 1 to indicate an EHT transmission
7 to (#4851)a single user, and setting the MCS subfield of the User field in EHT-SIG (Table 36-40 (User field
8
9 format for a non-MU-MIMO allocation)) to 14.
10
11 (#7971)In EHT DUP mode, the encoding and modulation are described as follows:
12
13
— For an 80 MHz EHT MU PPDU transmitted in EHT DUP mode, encoding and BPSK-DCM
14 modulation are done for the lower 484-tone RU, and then the lower 484-tone RU is duplicated to the
15 higher 484-tone RU along with a partial sign change to reduce PAPR.
16 — For a 160 MHz EHT MU PPDU transmitted in EHT DUP mode, encoding and BPSK-DCM
17
18 modulation are done for the lower 996-tone RU, and then the lower 996-tone RU is duplicated to the
19 higher 996-tone RU along with a partial sign change to reduce PAPR.
20 — For a 320 MHz EHT MU PPDU transmitted in (#7950)EHT DUP mode, encoding and BPSK-DCM
21
22
modulation are done for the lower 2996-tone RU, and then the lower 2996-tone RU is duplicated
23 to the higher 2996-tone RU along with a partial sign change to reduce PAPR.
24
25 The above frequency domain duplication occurs after LDPC tone mapping (36.3.13.8 (LDPC tone
26 mapper(#3115))) and segment deparsing operations (36.3.13.9 (Segment deparser(#2993))). The details of
27
28
the duplication and partial sign change operations are described in 36.3.13.10 (Frequency domain
29 duplication).
30
31 The EHT-STF, EHT-LTF, and pilot subcarriers for an 80 MHz EHT MU PPDU transmitted in EHT DUP
32 mode are constructed in an identical manner to those of an (#4652)(#6432)80 MHz OFDMA transmission
33
34
using EHT MU PPDU with 484-tone RU1 and RU2 occupied.
35
36 The EHT-STF, EHT-LTF, and pilot subcarriers for a 160/320 MHz EHT MU PPDU transmitted in EHT
37 DUP mode are constructed in an identical manner to those of a 160/320 MHz (#4652)(#6432)non-OFDMA
38 transmission using EHT MU PPDU.
39
40
41 36.3.6 Transmitter block diagram
42
43 The generation of each field in an EHT PPDU uses many of the following blocks:
44
45 a) Pre-FEC PHY padding
46 b) Scrambler
47
48 c) FEC (BCC or LDPC) encoders
49 d) Post-FEC PHY padding
50
51 e) Stream parser
52 f) Segment parser (for RU/MRU size larger than 996 tones(#7184))
53
54 g) BCC interleaver
55 h) Constellation mapper
56
57 i) DCM tone mapper
58 j) Pilot insertion
59
60 k) Replication over multiple 20 MHz (for bandwidth greater than 20 MHz)(#3100)
61 l) LDPC tone mapper
62
63 m) Segment deparser
64 n) Frequency domain duplication if EHT-MCS equals 14(#3101)
65

562 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 o) CSD per spatial stream insertion

2
3 p) Spatial mapper
4 q) Frequency mapping
5
6 r) IDFT
7 s) CSD per chain insertion
8
9 t) GI insertion
10 u) Windowing
11
12
Figure 36-19 (Transmitter block diagram for the L-SIG, RL-SIG, and U-SIG fields for an EHT MU PPDU)
13
14 to Figure 36-26 (Transmitter block diagram for the Data field of an EHT single user transmission in RU/
15 MRU size larger than 996 tones with LDPC encoding) show example transmitter block diagrams. The actual
16 structure of the transmitter is implementation dependent.
17
18
In particular, Figure 36-19 (Transmitter block diagram for the L-SIG, RL-SIG, and U-SIG fields for an EHT
19
20 MU PPDU) shows the transmit process for the L-SIG, RL-SIG, and U-SIG fields of an EHT MU PPDU
21 using one 80 MHz subblock(#7183)(#1279). These transmit blocks are also used to generate the L-STF and
22 L-LTF fields of the EHT MU PPDU with the following exceptions:
23
24 — The BCC encoder and interleaver as well as constellation mapper are not used when generating the
25 L-STF and L-LTF fields.
26
NOTE—For an EHT MU PPDU, the duplication on 20 MHz channels is subject to the availability of 20 MHz channels
27
in the case of preamble puncturing. The U-SIG field(#5657) contents may be different in different 80 MHz
28
subblocks(#1279) for PPDU bandwidth(#1313) greater than 80 MHz.
29
30 Insert GI
31 Analog
and
and RF
32 Window
33
34
20 MHz if BW > 20 MHz

CSD Insert GI
Duplicate over multiple
Constellation Mapper

35 Analog
per and
BCC Interleaver

36 and RF
BCC Encoder

chain Window
37
IDFT

38
39
...

40
41
42
CSD Insert GI
43 Analog
per and
44 chain Window
and RF
45
46
Single Spatial Stream
47
48 NTX Transmit Chains
49
50 Figure 36-19—Transmitter block diagram for the L-SIG, RL-SIG, and U-SIG fields for an
51 EHT MU PPDU
52
53
54 Figure 36-20 (Transmitter block diagram for the L-SIG, RL-SIG, and U-SIG fields of an EHT TB PPDU)
55 shows the transmit process for the L-SIG, RL-SIG, and U-SIG fields of an EHT TB PPDU(#4691).
56
57
(#4904)These transmit blocks are also used to generate the L-STF and L-LTF fields of the EHT TB PPDU
58 with the following exception:
59 — The BCC encoder, interleaver, and constellation mapper are not used when generating the L-STF
60 and L-LTF fields.
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 563

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#1945)The L-SIG, RL-SIG, and U-SIG fields (#4905)are duplicated over multiple 20 MHz if the EHT
2 modulated fields are allocated in an RU/MRU > 242 tones.
3
4
Insert GI
5 Analog
and

Sent only on the 20 MHz channels where

6 Window
and RF

the EHT modulated fields are located

7
8
9 CSD Insert GI

Constellation Mapper
Analog
per and
10
BCC Interleaver
and RF
BCC Encoder

chain Window
11

IDFT
12
13

...
14
15
16
17 CSD Insert GI
Analog
18 per and
and RF
chain Window
19
20
21
22 Single Spatial Stream NTX Transmit Chains
23
24 Figure 36-20—Transmitter block diagram for the L-SIG, RL-SIG, and U-SIG fields of an
25
26 EHT TB PPDU
27
28 Figure 36-21 (Transmitter block diagram for the EHT-SIG field for an EHT MU PPDU(#4543)) shows the
29
30 transmit process for the EHT-SIG field of an EHT MU PPDU(#4542). This block diagram is for
31 transmitting EHT-SIG in one 20 MHz subchannel. Refer to 36.3.12.8.2 (EHT-SIG content channels) for the
32 methods of transmitting EHT-SIG in 40 MHz, 80 MHz, 160 MHz, and 320 MHz. The DCM tone mapper,
33 which is defined in 36.3.13.7 (Constellation mapping(#3115)), is applied only if the (#8097)EHT-SIG MCS
34 field in the U-SIG field (#7393)equals 3 (i.e., indicates an EHT-MCS 15)(#1555).
35
36
37 Insert GI
Analog
38 and
and RF
39 Window
40
41 CSD Insert GI
Pre-FEC PHY Padding

Constellation Mapper

Analog
42 per and
BCC Interleaver

and RF
BCC Encoder

43 chain Window
44
IDFT

45
46
...

47
48
49 CSD Insert GI
50 per and
Analog
51 and RF
chain Window
52 Single Spatial Stream
53
54
55 NTX Transmit Chains
56
57 Figure 36-21—Transmitter block diagram for the EHT-SIG field for an EHT MU PPDU(#4543)
58
59
60 Figure 36-22 (Transmitter block diagram for the UL transmission or DL non-MU-MIMO transmission of a
61 Data field with BCC encoding on an RU/MRU that is the same size as or smaller than a 242-tone
62 RU(#7750)(#1315)) shows the transmitter blocks for the UL transmission or DL non-MU-MIMO
63
transmission of a Data field with BCC encoding on (#1315)an RU/MRU smaller than or equal to 242 tone if
64
65 the number of spatial streams is less than or equal to 4. Figure 36-22 (Transmitter block diagram for the UL

564 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 transmission or DL non-MU-MIMO transmission of a Data field with BCC encoding on an RU/MRU that is
2 the same size as or smaller than a 242-tone RU(#7750)(#1315)) applies to the Data field of an EHT MU
3
PPDU that is transmitted on an RU/MRU allocated to a single user and the Data field of an EHT TB PPDU
4
5 (whether or not it is spatially multiplexed with other users).
6
7 A subset of these transmitter blocks consisting of the (#4544)CSD blocks, as well as the blocks to the right
8 of, and including, the spatial mapping block, are also used to generate the EHT-LTF and EHT-STF fields.
9
10
11

Constellation
Interleaver
Insert GI

mapper
12 Analog

BCC
IDFT and
and RF
13 Window
14

Spatial and Frequency Mapping

15
Pre-FEC PHY

Post-FEC PHY
BCC Encoder

Constellation
16
Scrambler

Insert GI

Interleaver
Padding

Stream Parser
Padding

Analog

mapper
CSD per IDFT and
17 BCC
SS Window
and RF
18
19

...
20
...

...
21
22
Constellation

Insert GI
Interleaver

23 Analog
mapper

CSD per IDFT and

BCC

and RF
24 SS Window
25
26
27
28 NSS (≤4) Spatial Streams NTX Transmit Chains
29
30
31 Figure 36-22—Transmitter block diagram for the UL transmission or DL non-MU-MIMO
32 transmission of a Data field with BCC encoding on an RU/MRU that is the same size as
33 or smaller than a 242-tone RU(#7750)(#1315)
34
35
36 Figure 36-23 (Transmitter block diagram for the UL transmission or DL non-MU-MIMO transmission of a
37 Data field with LDPC encoding on an RU/MRU that is the same size or smaller than a 996-tone RU(#1315))
38 shows the transmitter blocks for the UL transmission or DL non-MU-MIMO transmission of a Data field
39 with LDPC encoding on (#1315)an RU/MRU that is the same size or smaller than a 996-tone RU(#4994).
40
41 Figure 36-23 (Transmitter block diagram for the UL transmission or DL non-MU-MIMO transmission of a
42 Data field with LDPC encoding on an RU/MRU that is the same size or smaller than a 996-tone RU(#1315))
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 565

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 applies to the Data field of an EHT MU PPDU that is transmitted on an RU/MRU allocated to a single user
2 and the Data field of an EHT TB PPDU (whether or not it is spatially multiplexed with other users).
3
4

Constellation

LDPC Tone
5 Insert GI

Mapper
Analog

mapper
IDFT and
6 Window
and RF
7

Spatial and Frequency Mapping

8
9
LDPC Encoder
Pre-FEC PHY

Post-FEC PHY

Constellation

LDPC Tone
Insert GI
Scrambler

10

Stream Parser
Padding

Analog

Padding

mapper

Mapper
CSD per IDFT and
11 SS and RF
Window
12
13

...
...
...
14
15

Constellation

LDPC Tone
16 Insert GI
Analog

mapper

Mapper
CSD per IDFT and
17 SS Window
and RF
18
19
20
21
22 NTX Transmit Chains
NSS(≤8) Spatial Streams
23
24
25 Figure 36-23—Transmitter block diagram for the UL transmission or DL non-MU-
26 MIMO transmission of a Data field with LDPC encoding on an RU/MRU that is the
27 same size or smaller than a 996-tone RU(#1315)
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

566 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Figure 36-24 (Transmitter block diagram for the DL MU-MIMO transmission of a Data field with BCC
2 encoding on a 242-tone RU) shows the transmitter blocks for the transmission, in an EHT MU PPDU, of the
3
Data field with BCC encoding on a 242-tone RU/MRU allocated to more than one user.
4
5
6
7

Constellation
Interleaver
8

mapper
BCC
9
10

Post-FEC PHY Padding

11
Pre-FEC PHY Padding

12

Stream Parser
BCC Encoder

Constellation
13
Scrambler

Interleaver

mapper
14 CSD

BCC
15 per SS

Spatial and Frequency Mapping

16

...
...
17

...
18

Constellation
Interleaver
19

mapper
CSD
BCC
20
per SS
21
22 User 0

...
23
...

24

Constellation

...
Interleaver
25

mapper
BCC

26 CSD
PHY Padding
Pre-FEC PHY

27 per SS
Stream Parser
BCC Encoder

Post-FEC
Scrambler
Padding

28
...
...

...
29
Constellation

30
Interleaver

mapper

31 CSD
BCC

32 per SS
33 User Nuser,total-1
34
35
Insert GI
36 Analog
and IDFT
37 and RF
Window
38
39
40
41
...
42 Analog
Insert GI
43 and RF
and IDFT
44 Window
45
46 Insert GI
Analog
47 and RF
and IDFT
48 Window
49
50 Figure 36-24—Transmitter block diagram for the DL MU-MIMO transmission of a Data field
51
52 with BCC encoding on a 242-tone RU
53
54
Figure 36-25 (Transmitter block diagram for the DL MU-MIMO transmission of a Data field with LDPC
55
56 encoding on a 242-, 484-, 484+242-, or 996-tone RU or MRU(#1946)) shows the transmitter blocks for the
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 567

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 transmission, in an EHT MU PPDU, of the Data field with LDPC encoding on a 242-, 484-, 484+242-, or
2 996-tone RU/MRU allocated to more than one user.
3
4
5
6
7

Constellation
8 LDPC

mapper
tone
9 mapper
10

Post-FEC PHY Padding

11
Pre-FEC PHY Padding

12

Stream Parser
LDPC Encoder

Constellation
13
Scrambler

LDPC

mapper
CSD
14 tone per SS
15

Spatial and Frequency Mapping

mapper
16

...
...

...
17

Constellation
18

mapper
19 LDPC
CSD
20 tone
per SS
mapper
21
22 User 0

...
23
...

Constellation
24

...
mapper
25 LDPC
CSD
26 tone
PHY Padding
Pre-FEC PHY

per SS
Stream Parser

27 mapper
Post-FEC
Scrambler
Padding

Encoder

...
LDPC

28

...
29
Constellation

30
mapper

LDPC
CSD
31 tone
per SS
32 mapper
33 User Nuser,total-1
34
35 Analog
Insert GI
36 and RF
and IDFT
37 Window
38

...
39
40
41
Insert GI
42 Analog
and IDFT
43 and RF
Window
44
45
Insert GI
46 Analog
and IDFT
47 and RF
Window
48
49
50
Figure 36-25—Transmitter block diagram for the DL MU-MIMO transmission of a Data field
51 with LDPC encoding on a 242-, 484-, 484+242-, or 996-tone RU or MRU(#1946)
52
53
54
55
56
57
58
59
60
61
62
63
64
65

568 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Figure 36-26 (Transmitter block diagram for the Data field of an EHT single user transmission in RU/MRU
2 size larger than 996 tones with LDPC encoding) shows the transmitter blocks used to generate the Data field
3
of a single-user EHT transmission in RU/MRU size larger than 996 tone with LDPC encoding.
4
5
6 Constellation LDPC tone
7

Segment
mapper mapper

Parser
Segment
8 Interleaver
Constellation
LDPC tone
mappermapper
Deparser

9
10
Pre-FEC PHY

LDPC Encoder

Post-FEC PHY

Spatial Mapping
11
Scrambler
Padding

Stream Parser
Padding
12
13
14
15
16 Constellation LDPC tone
Segment
mapper mapper CSD
Parser
17 Segment
Deparser per SS
Constellation LDPC tone
18 mapper mapper
19
20
21 Analog
Insert GI
and IDFT
and RF
22 Window

23
24
25 Insert GI
Analog
26 and RF
and IDFT
Window
27
28
29 Figure 36-26—Transmitter block diagram for the Data field of an EHT single user trans-
30 mission in RU/MRU size larger than 996 tones with LDPC encoding
31
32
33
34 (#1966)Figure 36-27 (Transmitter block diagram for the transmission of a Data field with EHT-MCS 14 in
35 80 MHz or 160 MHz PPDU(#4906)(#1966)) shows the transmit blocks used to generate the Data field of
36 80 MHz or 160 MHz PPDU if EHT-MCS 14 is used.
37
38
Insert GI
39 IDFT and
Analog
and RF
40 Window
41
42 Insert GI
Constellation mapper

Frequency domain

Analog
LDPC tone mapper

IDFT and
43
Post-FEC PHY
LDPC Encoder

Stream Parser

Spatial Mapper
Pre-FEC PHY

(BPSK+DCM)

and RF
duplication

Window
Scrambler

(Nss = 1)
Padding

Padding

44
45
...

46
47
48 Insert GI
Analog
49 IDFT and
and RF
Window
50
51
52 NTX Transmit Chains
Single Spatial Stream
53
54
Figure 36-27—Transmitter block diagram for the transmission of a Data field with EHT-
55
56 MCS 14 in 80 MHz or 160 MHz PPDU(#4906)(#1966)
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 569

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#1966)Figure 36-28 (Transmitter block diagram for the transmission of a Data field with EHT-MCS 14 in
2 320 MHz PPDU(#4907)(#1966)) shows the transmit blocks used to generate the Data field of 320 MHz
3
PPDU if EHT-MCS 14 is used.
4
5

Constellation mapper
6

LDPC tone mapper

(BPSK+DCM)
7
8
Insert GI
9 IDFT and
Analog
and RF
10 Window
11
12 Insert GI

Frequency domain
Analog

Segment deparser
IDFT and
13
Post-FEC PHY
LDPC Encoder

Segment parser
Stream Parser
Pre-FEC PHY

Spatial Mapper
and RF

duplication
Window
Scrambler

(Nss = 1)
Padding

Padding

14
15

...
16
17
18 Insert GI
Analog
Constellation mapper
19

LDPC tone mapper

IDFT and
and RF
20 (BPSK+DCM) Window

21
22
NTX Transmit Chains
23
24
25
26 Single Spatial Stream
27
28 Figure 36-28—Transmitter block diagram for the transmission of a Data field with EHT-
29 MCS 14 in 320 MHz PPDU(#4907)(#1966)
30
31
32 36.3.7 Overview of the PPDU encoding process
33
34
35 36.3.7.1 General
36
37 This subclause provides an overview of the EHT PPDU encoding process.
38
39
40 36.3.7.2 Construction of L-STF
41
42 Construct the L-STF field as defined in 36.3.12.3 (L-STF) with the following highlights:
43
a) Determine the channel bandwidth from the TXVECTOR parameter CH_BANDWIDTH.
44
45 b) Sequence generation: Generate the L-STF sequence over the channel bandwidth as described in
46 36.3.12.3 (L-STF).
47
48 c) Phase rotation: Apply appropriate phase rotation for each 20 MHz subchannel as described in
49 36.3.11 (Mathematical description of signals) and 36.3.11.4 (Transmitted signal).
50 d) IDFT: Compute the inverse discrete Fourier transform.
51
52 e) CSD per chain: Apply CSD per chain for each transmit chain(#4546) as described in 36.3.12.2.1
53 (Cyclic shift for pre-EHT modulated fields).
54
55 f) Insert GI and apply windowing: Prepend a GI  T GI Pre-EHT  and apply windowing as described in
56 36.3.11 (Mathematical description of signals).
57
58 g) Analog and RF: Upconvert the resulting complex baseband waveform associated with each transmit
59 chain to an RF signal according to the center frequency of the desired channel and transmit. Refer to
60 36.3.11 (Mathematical description of signals) and 36.3.12 (EHT preamble) for details.
61
62
63
64
65

570 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 36.3.7.3 Construction of L-LTF

2
3
Construct the L-LTF field as defined in 36.3.12.4 (L-LTF) with the following highlights:
4
5 a) Determine the channel bandwidth from the TXVECTOR parameter CH_BANDWIDTH.
6
b) Sequence generation: Generate the L-LTF sequence over the channel bandwidth as described in
7
8 36.3.12.4 (L-LTF).
9 c) Phase rotation: Apply appropriate phase rotation for each 20 MHz subchannel as described in
10 36.3.11 (Mathematical description of signals) and 36.3.11.4 (Transmitted signal).
11
12 d) IDFT: Compute the inverse discrete Fourier transform.
13 e) CSD per chain: Apply CSD per chain for each transmit chain(#4546) as described 36.3.12.2.1
14
15 (Cyclic shift for pre-EHT modulated fields).
16 f) Insert GI and apply windowing: Prepend a GI  TGI L-LTF  and apply windowing as described in
17
18 36.3.11 (Mathematical description of signals).
19 g) Analog and RF: Upconvert the resulting complex baseband waveform associated with each transmit
20 chain to an RF signal according to the carrier frequency of the desired channel and transmit. Refer to
21
22
36.3.11 (Mathematical description of signals) and 36.3.12 (EHT preamble) for details.
23
24 36.3.7.4 Construction of L-SIG
25
26 (#1321)Construct the L-SIG field as defined in 36.3.12.5 (L-SIG) with the following highlights:
27
28 a) (#1321)Set the RATE subfield in the L-SIG field to 6 Mb/s. Set the LENGTH, Parity, and Tail fields
29 in the L-SIG field as described in 36.3.12.5 (L-SIG).
30
31 b) (#1321)BCC encoder: Encode the L-SIG field by a convolutional encoder at the rate of R = 1  2 as
32 described in 36.3.13.3.2 (BCC coding).
33
34
c) BCC interleaver: Interleave as described in 17.3.5.7 (Data interleavers).
35 d) Constellation Mapper: BPSK modulate as described in 36.3.13.7 (Constellation mapping(#3115)).
36
37
e) Pilot insertion: Insert pilots as described in 36.3.12.5 (L-SIG).
38 f) Extra subcarrier insertion: Four extra subcarriers are inserted at k   – 28 – 27 27 28  for channel
39
40 estimation purpose and the values on these four extra subcarriers are  – 1 – 1 – 1 1 , respectively.
41 g) Duplication and phase rotation: Duplicate the L-SIG field over each occupied 20 MHz subchannel
42
43 of the channel bandwidth. Apply appropriate phase rotation for each occupied 20 MHz subchannel
44 as described in 36.3.11 (Mathematical description of signals) and 36.3.11.4 (Transmitted signal).
45 h) IDFT: Compute the inverse discrete Fourier transform.
46
47 i) CSD per chain: Apply CSD per chain for each transmit chain(#4546) as described in 36.3.12.2.1
48 (Cyclic shift for pre-EHT modulated fields).
49
50 j) Insert GI and apply windowing: Prepend a GI  T GI Pre-EHT  and apply windowing as described in
51 36.3.11 (Mathematical description of signals).
52
53
k) Analog and RF: Upconvert the resulting complex baseband waveform associated with each transmit
54 chain. Refer to 36.3.11 (Mathematical description of signals) and 36.3.12 (EHT preamble) for
55 details.
56
57 36.3.7.5 Construction of RL-SIG
58
59
60 (#1321)Construct the RL-SIG field as defined in 36.3.12.6 (RL-SIG) with the following highlights:
61 a) (#1321)Set the RATE subfield in the RL-SIG field to 6 Mb/s. Set the LENGTH, Parity, and Tail
62 fields in the RL-SIG field as described in 36.3.12.6 (RL-SIG).
63
64
65

Copyright © 2022 IEEE. All rights reserved. 571

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 b) (#1321)BCC encoder: Encode the RL-SIG field by a convolutional encoder at the rate of R = 1  2
2
3 as described in 36.3.13.3.2 (BCC coding).
4 c) BCC interleaver: Interleave as described in 17.3.5.7 (Data interleavers).
5
6 d) Constellation Mapper: BPSK modulate as described in 36.3.13.7 (Constellation mapping(#3115)).
7 e) Pilot insertion: Insert pilots as described in 36.3.12.6 (RL-SIG).
8
9 f) Extra subcarrier insertion: Four extra subcarriers are inserted at k   – 28 – 27 27 28  for the
10 purpose of channel estimation(#1316) and the values on these four extra subcarriers are
11
 – 1 – 1 – 1 1  , respectively.
12
13 g) Duplication and phase rotation: Duplicate the RL-SIG field over each occupied 20 MHz subchannel
14 of the channel bandwidth. Apply appropriate phase rotation for each occupied 20 MHz subchannel
15
as described in 36.3.11 (Mathematical description of signals) and 36.3.11.4 (Transmitted signal).
16
17 h) IDFT: Compute the inverse discrete Fourier transform.
18
i) CSD per chain: Apply CSD per chain for each transmit chain(#4546) as described in 36.3.12.2.1
19
20 (Cyclic shift for pre-EHT modulated fields).
21 j) Insert GI and apply windowing: Prepend a GI  T GI Pre-EHT  and apply windowing as described in
22
23 36.3.11 (Mathematical description of signals).
24 k) Analog and RF: Upconvert the resulting complex baseband waveform associated with each transmit
25 chain. Refer to 36.3.11 (Mathematical description of signals) and 36.3.12 (EHT preamble) for
26
27 details.
28
29 36.3.7.6 Construction of U-SIG
30
31 Construct the U-SIG field as defined in 36.3.12.7 (U-SIG) with the following highlights:
32
33
34 (#2763)(#8094)Steps a) to f) apply for each frequency subblock:
35 a) (#5471)Obtain the U-SIG field values from the TXVECTOR. (#1353)(#1355)(#3280)(#7187)Set
36
37
the values of the Disregard and Validate fields as defined in Table 36-28 (U-SIG field of an EHT
38 MU PPDU) in case of EHT MU PPDU. Append the calculated CRC and then append the N tail tail
39 bits as described in 36.3.12.7 (U-SIG). This results in 52 uncoded bits.
40
41 (#5471)NOTE 1—The values of the Disregard and Validate fields in an EHT TB PPDU is specified in the TXVECTOR.
42
43
44
b) BCC encoder: Encode the data by a convolutional encoder at the rate of R = 1  2 as described in
45 17.3.5.6 (Convolutional encoder).
46 c) BCC interleaver: Interleave as described in 27.3.12.8 (BCC interleavers) for HE-SIG-A/HE-SIG-B.
47
48 d) Constellation mapper: BPSK modulate the first 52 interleaved bits as described in
49 17.3.5.8 (Subcarrier modulation mapping) to form the first OFDM symbol of U-SIG field(#5657).
50 BPSK modulate the second 52 interleaved bits to form the second OFDM symbol of U-SIG
51 field(#5657).
52
53 e) Pilot insertion: Insert pilots as described in 17.3.5.9 (Pilot subcarriers).
54 f) (#2763)Duplicate: Duplicate the U-SIG OFDM symbols over each occupied 20 MHz subchannel of
55
56 the frequency subblock.
57 NOTE 2—20, 40, and 80 MHz EHT PPDUs have one 20, 40, and 80 MHz frequency subblocks, respectively. 160 and
58 320 MHz EHT PPDUs have two and four 80 MHz frequency subblocks, respectively.
59
60
61 NOTE 3—U-SIG field(#5657) content may vary between 80 MHz frequency subblocks(#4842) in a 160 or 320 MHz
62 EHT MU PPDU with the PPDU Type And Compression Mode field equal to 0 and the UL/DL field equal to 0 in the U-
63 SIG field(#5657) (DL OFDMA)(#4843). For all other cases, U-SIG field(#5657) content is the same for all frequency
64 subblocks. See 36.3.12.7 (U-SIG).
65

572 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 g) (#2763)Phase rotation: Apply the appropriate phase rotation for each occupied 20 MHz subchannel
2 as described in 36.3.11 (Mathematical description of signals) and 36.3.11.4 (Transmitted signal).
3
4 h) IDFT: Compute the inverse discrete Fourier transform.
5 i) CSD per chain: Apply CSD per chain for each transmit chain(#4546) as described in 36.3.12.2.1
6
(Cyclic shift for pre-EHT modulated fields).
7
8 j) Insert GI and apply windowing: Prepend a GI ( T GI Pre-EHT ) and apply windowing as described in
9
10
36.3.11 (Mathematical description of signals).
11 k) Analog and RF: Upconvert the resulting complex baseband waveform associated with each transmit
12 chain to an RF signal according to the center frequency of the desired channel and transmit. Refer to
13 36.3.11 (Mathematical description of signals) and 36.3.12 (EHT preamble) for details.
14
15
16 36.3.7.7 Construction of EHT-SIG
17
18 For an EHT MU PPDU, construct the EHT-SIG field as defined in 36.3.12.8 (EHT-SIG) with the following
19 highlights:
20
21 a) (#4547)Obtain the EHT-SIG subfield values from the TXVECTOR. (#3281)Add the Disregard
22 fields. For each encoding block, append the calculated CRC and then append the N tail tail bits as
23
24 shown in 36.3.12.8 (EHT-SIG). Append padding bits if needed.
25 b) BCC encoder: Encode each code block by a convolutional encoder as described in 27.3.12.5.1 (BCC
26 coding and puncturing).
27
28 c) BCC interleaver: Interleave as described in 27.3.12.8 (BCC interleavers) for HE-SIG-A/HE-SIG-B.
29 d) Constellation mapper: Obtain MCS_EHT_SIG from the TXVECTOR and use it to modulate the
30
31 interleaved bits as described in 36.3.13.7 (Constellation mapping(#3115)) to form the EHT-SIG
32 OFDM symbols.
33 e) Pilot insertion: Insert pilots as described in 17.3.5.9 (Pilot subcarriers).
34
35 f) Duplicate and phase rotation: Duplicate EHT-SIG OFDM symbols as described in 36.3.12.8.6
36 (Encoding and modulation). Apply the appropriate phase rotation for each 20 MHz subchannel as
37 described in 36.3.11 (Mathematical description of signals) and 36.3.11.4 (Transmitted signal).
38
39 g) IDFT: Compute the inverse Fourier transform.
40 h) CSD per chain: Apply CSD per chain for each transmit chain(#4546) as described in 36.3.12.2.1
41 (Cyclic shift for pre-EHT modulated fields).
42
43 i) Insert GI and apply windowing: Prepend a GI ( T GI Pre-EHT ) and apply windowing as described in
44
45
36.3.11 (Mathematical description of signals).
46 j) Analog and RF: Upconvert the resulting complex baseband waveform associated with each transmit
47 chain to an RF signal according to the center frequency of the desired channel and transmit. Refer to
48 36.3.11 (Mathematical description of signals) and 36.3.12 (EHT preamble) for details.
49
50
51 36.3.7.8 Construction of EHT-STF
52
53 Construct the EHT-STF field as defined in 36.3.12.9 (EHT-STF) with the following highlights:
54
55 a) Sequence generation: Generate the EHT-STF in the frequency domain over the bandwidth indicated
56 by the TXVECTOR parameter CH_BANDWIDTH as described in 36.3.12.9 (EHT-STF).
57 b) CSD: Apply CSD for each spatial stream(#4546) as described in 36.3.12.2.2 (Cyclic shift for EHT
58
59 modulated fields).
60 c) Spatial mapping: Apply the Q matrix as described in 36.3.12.9 (EHT-STF).
61
62 d) IDFT: Compute the inverse discrete Fourier transform.
63
64
65

Copyright © 2022 IEEE. All rights reserved. 573

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 e) Insert GI and apply windowing: (#7476)Prepend a GI of 0.8 µs and 1.6 µs GI for EHT MU PPDU
2 and EHT TB PPDU, respectively. Apply windowing as described in 36.3.11 (Mathematical
3
description of signals).
4
5 f) Analog and RF: Upconvert the resulting complex baseband waveform associated with each transmit
6 chain to an RF signal according to the center frequency of the desired channel and transmit. Refer to
7 36.3.11 (Mathematical description of signals) and 36.3.12 (EHT preamble) for details.
8
9
10 36.3.7.9 Construction of EHT-LTF
11
12 Construct the EHT-LTF field as defined in 36.3.12.10 (EHT-LTF) with the following highlights:
13
14 a) Sequence generation: Generate the EHT-LTF sequence in frequency domain over the bandwidth
15 indicated by CH_BANDWIDTH as described in 36.3.12.10 (EHT-LTF).
16
17 b) A EHT-LTF matrix mapping: Apply the P EHT-LTF matrix to the data tones of the EHT-LTF sequence and
18 apply the R EHT-LTF matrix to pilot subcarriers of the EHT-LTF sequence (#5527)except for an UL
19
20
MU-MIMO transmission using 1EHT-LTF as described in 36.3.12.10 (EHT-LTF).
21 c) CSD: Apply CSD for each spatial stream(#4546) as described in 36.3.12.2.2 (Cyclic shift for EHT
22 modulated fields).
23
24 d) Spatial mapping: Apply the Q matrix as described in 36.3.12.10 (EHT-LTF).
25 e) IDFT: Compute the inverse discrete Fourier transform.
26
27 f) Insert GI and apply windowing: Prepend a GI indicated by the TXVECTOR parameter GI_TYPE
28 and apply windowing as described in 36.3.11 (Mathematical description of signals).
29 g) Analog and RF: Upconvert the resulting complex baseband waveform associated with each transmit
30
31 chain to an RF signal according to the center frequency of the desired channel and transmit. Refer to
32 36.3.11 (Mathematical description of signals) and 36.3.12 (EHT preamble) for details.
33
34 36.3.7.10 Construction of Data field in an EHT PPDU
35
36
37 Construct the Data field as defined in 36.3.13 (Data field) with the following highlights:
38
39 For each user,
40
41
a) Construct the SERVICE field as described in 36.3.13.1 (SERVICE field) and append the PSDU to
42 the SERVICE field.
43 b) Pre-FEC padding: Append the pre-FEC padding bits(#2994) as described in 36.3.13 (Data field). If
44 the user is using BCC, then add tail bits.
45
46 c) Scrambler: Scramble the pre-FEC padded data as described in 36.3.13.2 (EHT PHY DATA
47 scrambler and descrambler)(#2995).
48
49 d) Encoder: If the user is using BCC, then BCC encode (#4617)and, if EHT-MCS 15 is used in a 106-
50 tone RU, 242-tone RU, or 106+26-tone MRU, insert a padding bit after every 2  N DBPS u coded bits
51 as described in 36.3.13.3.2 (BCC coding). If the user is using LDPC, then LDPC encode as
52
53 described in 36.3.13.3.3 (LDPC coding).
54 e) Post-FEC padding: Append the post-FEC padded bits as described in 36.3.13 (Data field) and the PE
55 field as described in 36.3.14 (Packet extension)(#2996).
56
57 f) Stream parser: Rearrange the output of encoder into blocks as described in 36.3.13.4 (Stream
58 parser).
59
60
g) Segment parser: In a 2996-tone RU, 4996-tone RU, 996+484-tone MRU, 996+484+242-tone
61 MRU, 2996+484-tone MRU, 3996-tone MRU, or 3996+484-tone MRU (#4549)using EHT-
62 MCS 0 to 13 or 15, divide each spatial stream output from(#7189) the stream parser into multiple
63 frequency subblocks as described in 36.3.13.5 (Segment parser). This block is bypassed for RUs or
64 MRUs of other sizes (#4549)when using EHT-MCS 0 to 13 or 15. In a 320 MHz EHT MU PPDU
65

574 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 using EHT-MCS 14, the output of the stream parser is divided into two frequency subblocks as
2 described in 36.3.13.5 (Segment parser). Segment parser is bypassed in an 80 MHz or 160 MHz
3
EHT MU PPDU using EHT-MCS 14.
4
5 h) BCC interleaver: If the user is using BCC, interleave as described in 36.3.13.6 (BCC interleavers).
6 This block is bypassed if the user is using LDPC.
7
8 i) Constellation mapper: Map to BPSK, BPSK-DCM(#3261)(#3284), QPSK, 16-QAM, 64-QAM,
9 256-QAM, 1024-QAM, or 4096-QAM constellation points as described in 36.3.13.7 (Constellation
10 mapping(#3115))
11
12 j) LDPC tone mapper: If the user is using LDPC, the LDPC tone mapping is performed on all LDPC
13 encoded streams as described in 36.3.13.8 (LDPC tone mapper(#3115)). This block is bypassed if
14 the user is using BCC.
15
k) Segment deparser: In a 2996-tone RU, 4996-tone RU, 996+484-tone MRU, 996+484+242-tone
16
17 MRU, 2996+484-tone MRU, 3996-tone MRU, or 3996+484-tone MRU (#4549)using EHT-
18 MCS 0 to 13 or 15, merge the multiple frequency subblocks into one frequency segment as
19 described in 36.3.13.9 (Segment deparser(#2993)). This block is bypassed for RUs or MRUs of
20 other sizes (#4549)when using EHT-MCS 0 to 13 or 15. In a 320 MHz EHT MU PPDU using EHT-
21
MCS 14, merge the two frequency subblocks into one frequency segment as described in 36.3.13.9
22
23 (Segment deparser(#2993)). Segment deparser is bypassed in an 80 MHz or 160 MHz EHT MU
24 PPDU using EHT-MCS 14.
25 l) Frequency domain duplication: For an EHT MU PPDU transmitted to a single user with
26
27 EHT-MCS 14, perform frequency domain duplication as described in 36.3.13.10 (Frequency
28 domain duplication). This block is bypassed for all other cases.
29 m) Pilot insertion: Insert pilots following the steps described in 36.3.13.11 (Pilot subcarriers).
30
31 n) CSD: Apply CSD for each spatial stream(#4546) as described in 36.3.12.2.2 (Cyclic shift for EHT
32 modulated fields).
33
34 (#4548)After steps a) to n) performed for all users in the PPDU,
35
36 o) Spatial mapping: Apply the Q matrix as described in 36.3.13.12 (OFDM modulation). Signal from
37 all users in each RU is combined in this block.
38
39 p) IDFT: Compute the inverse discrete Fourier transform.
40 q) Insert GI and apply windowing: Prepend a GI determined by the TXVECTOR parameter GI_TYPE
41 and apply windowing as described in 36.3.11 (Mathematical description of signals).
42
43 r) Analog and RF: Upconvert the resulting complex baseband waveform with each transmit chain to an
44 RF signal according to the center frequency of the desired channel and transmit. Refer to 36.3.11
45 (Mathematical description of signals) for details(#2998).
46
47
48 36.3.8 EHT modulation and coding schemes (EHT-MCSs)
49
50 The EHT-MCS is a compact representation of the modulation and coding used in the Data field of the
51 PPDU. For an EHT MU PPDU, it is carried per user in the User Specific field of the EHT-SIG field. For an
52 EHT TB PPDU, it is carried in the User Info field of the Trigger frame soliciting the EHT TB PPDU.
53
54
55 Rate dependent parameters for the full set of EHT-MCSs are shown in 36.5 (Parameters for EHT-MCSs).
56
57 EHT-MCS 14 and EHT-MCS 15 enable DCM on top of EHT-MCS 0. EHT-MCS 14 and EHT-MCS 15 are
58 supported only with (#6832)one spatial stream.
59
60
61 36.3.9 EHT-SIG modulation and coding schemes (EHT-SIG-MCSs)
62
63 The EHT-SIG-MCS is a compact representation of the modulation and coding used in the EHT-SIG field of
64 the EHT MU PPDU. The EHT-SIG modulation and coding scheme is carried in the (#8097)EHT-SIG MCS
65

Copyright © 2022 IEEE. All rights reserved. 575

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 field of the U-SIG field in the EHT MU PPDU and supports EHT-MCS 0, EHT-MCS 1, EHT-MCS 3, and
2 EHT-MCS 15.
3
4
5 36.3.10 Timing-related parameters
6
7 Refer to Table 19-6 (Timing-related constants), Table 21-5 (Timing-related constants), and Table 27-
8 12 (Timing related constants) for timing-related parameters for non-EHT PPDU formats.
9
10
11 Table 36-18 (Timing-related constants) defines the timing-related parameters for EHT PPDU format.
12
13
14 Table 36-18—Timing-related constants
15
16
17 Parameter Value Description
18
19 Subcarrier frequency spacing for the pre-
 F Pre-EHT 312.5 kHz
20 EHT modulated fields
21
22 Subcarrier frequency spacing for the EHT
 F EHT 78.125 kHz
23 modulated fields
24
25 IDFT/DFT period for the pre-EHT
T DFT Pre-EHT 3.2 µs
26 modulated fields
27 T DFT EHT 12.8 µs IDFT/DFT period for the EHT Data field
28
29 Guard interval duration for the pre-EHT
30 T GI Pre-EHT 0.8 µs modulated fields (#5813)excluding the L-
31 LTF field
32
33 T GI L-LTF
1.6 µs Guard interval duration for the L-LTF field
34 (#1317)
35
36 Base guard interval duration for the Data
T GI1 Data 0.8 µs
37 field
38
39 Double guard interval duration for the Data
T GI2 Data 1.6 µs
40 field
41 Quadruple guard interval duration for the
42 T GI4 Data 3.2 µs Data field
43
44 T GI1 Data , T GI2 Data or T GI4 Data depending on Guard interval duration for the Data field
45 T GI Data
46 the GI used for the Data field(#1319)(#1318)
47
Guard interval duration for the EHT-LTF
48 T GI EHT-LTF T GI Data (#7190)
field, same as T GI Data
49
50 OFDM symbol duration with base GI
51 13.6 µs = T DFT EHT + T GI1 Data =
T SYM1
52 1.0625  T DFT EHT
53
54 14.4 µs = T DFT EHT + T GI2 Data = OFDM symbol duration with double GI
55 T SYM2
56 1.125  T DFT EHT
57
58 16 µs = T DFT EHT + T GI4 Data = OFDM symbol duration with quadruple GI
59 T SYM4
60 1.25  T DFT EHT
61
62 T SYM1 , T SYM2 or T SYM4 depending on the GI OFDM symbol interval for EHT Data
63 T SYM fields(#1320).
64 used for EHT Data fields(#4657)
65

576 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-18—Timing-related constants (continued)

2
3
4 Parameter Value Description
5
6 TL-STF 8 µs = 10  T DFT Pre-EHT / 4 Non-HT Short Training field duration
7
8 TL-LTF 8 µs = 2  T DFT Pre-EHT + T GI LTF (#4550) Non-HT Long Training field duration
9
10 TL-SIG Non-HT SIGNAL field duration
4 µs
11
12 TRL-SIG Repeated non-HT SIGNAL field duration
4 µs
13
14 TU-SIG U-SIG field duration in an EHT PPDU
8 µs = 2 4 µs
15
16 U-SIG field duration in an EHT ER
17 TU-SIG-R 16 µs = 4 4 µs preamble(#1256)(#2609)
18
19 Duration of each OFDM symbol in the EHT-
TEHT-SIG 4 µs = T DFT Pre-EHT + T GI Pre-EHT
20 SIG field
21
22 EHT-STF field duration for an EHT TB
TEHT-STF-T 8 µs = 5  µs PPDU
23
24 EHT-STF field duration for an EHT MU
25 TEHT-STF-NT 4 µs = 5  µs PPDU(#5815)
26
27 Duration of each 1 EHT-LTF OFDM
TEHT-LTF-1X 3.2 µs
28 symbol without GI
29
30 Duration of each 2 EHT-LTF OFDM
TEHT-LTF-2X 6.4 µs
31 symbol without GI
32 Duration of each 4 EHT-LTF OFDM
33 TEHT-LTF-4X 12.8 µs symbol without GI
34
35 TEHT-LTF-1X, TEHT-LTF-2X or TEHT-LTF-4X Duration of each OFDM symbol without GI
36 TEHT-LTF
depending upon the EHT-LTF duration used in the EHT-LTF field
37
38
T EHT-LTF + T GI EHT-LTF Duration of each OFDM symbol including
39 TEHT-LTF-SYM GI in the EHT-LTF field
40
41 Nservice 16 Number of bits in the SERVICE field
42
43 Ntail, Ntail,u 6 for BCC encoder, 0 for LDPC encoder Number of tail bits per encoder (for user u)
44
45 OFDM symbol duration including GI in the
TSYML 4 µs
46 pre-EHT modulated fields(#6925)(#1323)
47
48 0, 4 µs, 8 µs, 12 µs, 16 µs or 20 µs
49 TPE depending on the actual packet extension Duration of the PE field
50
duration used(#1324)
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 577

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-19 (Subcarrier allocation related constants for the EHT-modulated fields in a nonpunctured non-
2 OFDMA EHT PPDU(#8100)) defines tone allocation related parameters for a (#8100)nonpunctured non-
3
OFDMA EHT PPDU.
4
5
6
7 Table 36-19—Subcarrier allocation related constants for the EHT-modulated fields in a non-
8 punctured non-OFDMA EHT PPDU(#8100)
9
10
11 CBW80 CBW80
12 (non-EHT- (EHT-
Parameter CBW20 CBW40 CBW160 CBW320 Description
13 MCS 14) MCS 14)
14 (#1611) (#1611)
15
16 Total number of
NSD,total
17 234 468 980 936 1 960 3 920 data subcarriers
(#7658)
18 (#1257)(#7658)
19
20 Number of pilot
NSP 8 16 16 32 32 64
21 subcarriers(#1257)
22
23 Total number of
NST 242 484 996 968 1 992 3 984
24 subcarriers(#1257)
25 Highest data
26 NSR 122 244 500 500 1 012 2 036 subcarrier
27 index(#1257)
28
29 Number of null
30 NDC 3 5 5 23 23 23 subcarriers at
31 DC(#1257)
32
33 Number of low
34 NGuard,Left 6 12 12 12 12 12 frequency guard
35 subcarriers
36
37 Number of high
38 NGuard,Right 5 11 11 11 11 11 frequency guard
39 subcarriers
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

578 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-20 (Subcarrier allocation related constants for the EHT-modulated fields in a punctured non-
2 OFDMA EHT PPDU) defines tone allocation related parameters for a punctured non-OFDMA EHT PPDU.
3
4
5
6 Table 36-20—Subcarrier allocation related constants for the EHT-modulated fields in a
7 punctured non-OFDMA EHT PPDU
8
9
10 CBW80 CBW160 CBW160 CBW320 CBW320 CBW320
11 with with with with with with
12 20 MHz 40 MHz 20 MHz 120 MHz 80 MHz 40 MHz
13 puncturi puncturi puncturi puncturi puncturi puncturi
14 Parameter ng ng ng ng ng ng Description
15 484+ 242- 996+ 484- 996+484+ 2996+ 3996- 3996+
16 tone tone 242-tone 484-tone tone 484-tone
17 MRU(#32 MRU(#32 MRU(#32 MRU(#32 MRU(#32 MRU(#32
18 85) 85) 85) 85) 85) 85)
19
20 Total number of
NSD,total
21 702 1 448 1 682 2 428 2 940 3 408 data subcarriers
(#7658)
22 (#1257)(#7658)
23
24 Number of pilot
25 NSP 24 32 40 48 48 64 subcarriers(#125
26 7)
27 Total number of
28 NST 726 1 480 1 722 2 476 2 988 3 472 subcarriers(#125
29 7)
30
31 Highest data
32 NSR 500 1 012 1 012 2 036 2 036 2 036 subcarrier
33 index(#1257)
34
35 Number of null
23
36 NDC 23 23 23 23 23 subcarriers at
(#4996)
37 DC(#1257)
38
39 Number of low
40 NGuard,Left 12 12 12 12 12 12 frequency guard
41 subcarriers
42
43 Number of high
44 NGuard,Right 11 11 11 11 11 11 frequency guard
45 subcarriers
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 579

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-21 (Subcarrier allocation related constants for RUs in an OFDMA EHT PPDU) defines tone
2 allocation related parameters for an OFDMA EHT PPDU.
3
4
5
6 Table 36-21—Subcarrier allocation related constants for RUs in an OFDMA EHT PPDU
7
8 RU size (subcarriers)(#1258)
9
Parameter Description
10 26 52 106 242 484 996 2996 4996
11
12 Total number of data
13 NSD,total
24 48 102 234 468 980 1 960 3 920 subcarriers per
14 (#7658)
RU(#7658)
15
16 Number of pilot
17 NSP 2 4 4 8 16 16 32 64
subcarriers per RU
18
19 Total number of
NST 26 52 106 242 484 996 1 992 3 984
20 subcarriers per RU
21
22 (#7658)NOTE—NST = NSD,total + NSP
23
24
25
26 Table 36-22 (Subcarrier allocation related constants for MRUs in an OFDMA EHT PPDU) defines tone
27 allocation related parameters for an OFDMA EHT PPDU.
28
29
30 Table 36-22—Subcarrier allocation related constants for MRUs in an OFDMA EHT PPDU
31
32
33 MRU size (subcarriers)
34
35 Parameter Description
2996 3996
36 52+26 106+26 484+242 996+484 3996
+484 +484
37
38 Total number
39 NSD,total of data
40 72 126 702 1 448 2 428 2 940 3 408
(#7658) subcarriers per
41 MRU(#7658)
42
43 Number of
44 pilot
45 NSP 6 6 24 32 48 48 64
subcarriers per
46 MRU
47
48 Total number
49 NST 78 132 726 1 480 2 476 2 988 3 472 of subcarriers
50 per MRU
51
52 (#7658)NOTE—NST = NSD,total + NSP
53
54
55
56
57
58
59
60
61
62
63
64
65

580 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-23 (Frequently used parameters) defines parameters used frequently in Clause 36 (Extremely high
2 throughput (EHT) PHY specification).
3
4
5
6 Table 36-23—Frequently used parameters
7
8
9 Symbol Explanation
10
11 For pre-EHT modulated fields, N RU = 1 .
12 N RU For EHT modulated fields, N RU represents the number of occupied RUs or MRUs in the
13 transmission.
14
15 For pre-EHT modulated fields, N user r = 1 .
16 N user r For EHT modulated fields, N user r represents the total number of users in the r-th
17 occupied RU or MRU of the transmission.
18
19 Total number of users in all occupied RUs or MRUs of an EHT transmission, i.e.,
20 N RU – 1
21 N user total
22
N user total =  N user r .
r=0
23
24
25
N CBPS u Number of coded bits per OFDM symbol for user u, u = 0 1  N user total – 1 .
26
27 Effective number of data tones carrying unique data.
28 N SD (#7856) (#4568)NOTE—The N SD value with DCM (when applicable) is half of the N SD value
29 without DCM, for each RU/MRU size.
30
31 Effective number of data tones carrying unique data for user u,
N SD total (#7856)
32 u = 0 1  N user total – 1 .
33
34 Number of coded bits per OFDM symbol per spatial stream for user u,
35 N CBPSS u
u = 0 1  N user total – 1 .
36
37
38 N CBPSS l u (#7312)Number of coded bits per OFDM symbol per spatial stream for user u,
39 u = 0 1  N user total – 1 , and in the l-th 80 MHz frequency block,
40 (#7294) l = 0 1  L – 1 . (#7289)L is the number of 80 MHz frequency subblocks.
41
42 Number of data bits per OFDM symbol for user u, u = 0 1  N user total – 1 .
43 N DBPS u
44 (#7192)(#1328)NOTE—For LDPC coding, this is the number of data bits per OFDM
45 symbol based on the LDPC coding rate for the MCS.
46
47 Number of coded bits per subcarrier per spatial stream for user u,
N BPSCS u
48 u = 0 1  N user total – 1 .
49
50
N BPSCS l u Number of coded bits per subcarrier per spatial stream for user u,
51
u = 0 1  N user total – 1 , and in the l-th 80 MHz frequency block,
52 (#7312) l = 0 1  L – 1 . L is the number of 80 MHz frequency subblocks.
53
54
55 N RX Number of receive chains.
56
57 Number of spatial streams. For the Data field, N SS r u is the number of spatial streams at
58 N SS r u , N SS u , r-th RU or MRU for user u, u = 0 1  N user r – 1 , and N SS u is the number of spatial
59 streams for user u, u = 0 1  N user total – 1 .
60 N SS
N RU – 1
61 For the Data field of an EHT PPDU, N SS = max r = 0 N SS r total .
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 581

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-23—Frequently used parameters (continued)

2
3
4 Symbol Explanation
5
6 For EHT modulated fields, N SS r total is the total number of spatial streams at r-th RU or
7
N user r – 1
8
9 N SS r total
MRU in a PPDU: N SS r total =  N SS r u .
10 u=0
11
12 For pre-EHT modulated fields, N SS r total is undefined.
13
14 N TX Number of transmit chains.
15
16
N EHT-LTF The number of OFDM symbols in the EHT-LTF field (see 36.3.12.10 (EHT-LTF)).
17
18
19 N EHT-SIG The number of OFDM symbols in the EHT-SIG field (see 36.3.12.8 (EHT-SIG)).
20
21 Kr Set of used subcarrier indices in the r-th occupied RU or MRU.
22
23 Ru (#7193)Coding rate for user u, u = 0 1  N user total – 1 .
24
25 The sum of the number of spatial streams of users prior to user u in RU or MRU r. For
26
27 pre-EHT modulated fields, M r u = 0 . For EHT modulated fields, M r 0 = 0 for u = 0
28 M r u u–1
29 and Mr u =  N SS r u' , for u = 1 2  N user r – 1 .
30 u' = 0
31
32
33
34 36.3.11 Mathematical description of signals
35
36 36.3.11.1 Notation
37
38 For a description of the conventions used for the mathematical description of the signals, see
39
40 17.3.2.5 (Mathematical conventions in the signal descriptions). In addition, the following notational
41 conventions are used in Clause 36 (Extremely high throughput (EHT) PHY specification):
42 —  Q m n indicates the element in row m and column n of matrix, where 1  m  N row and 1  n  N col
43
44 — N row and N col are the number of rows and columns, respectively, of the matrix Q.
45 —  Q m:n indicates a matrix consisting of columns m to n of the matrix Q.
46
47
48 36.3.11.2 Subcarrier indices in use
49
50 For a description on subcarrier indices over which the signal is transmitted for non-HT, HT, and VHT
51 PPDUs, see 21.3.7 (Mathematical description of signals). For a description on subcarrier indices over which
52
the signal is transmitted for HE PPDUs, see 27.3.10 (Mathematical description of signals).
53
54
55 (#1330)(#2611)For a 20 MHz EHT PPDU transmission, the 20 MHz is divided into 256 subcarriers for the
56 EHT modulated fields. For a 20 MHz non-OFDMA EHT PPDU transmission, the signal of each EHT
57 modulated field is transmitted on subcarriers –122 to –2 and 2 to 122, with 0 being the center subcarrier. For
58
a 20 MHz OFDMA EHT PPDU transmission, the signal of each EHT modulated field is transmitted on all
59
60 or a subset of the subcarriers –122 to –4 and 4 to 122, with 0 being the center subcarrier.
61
62 (#1330)(#2611)For a 40 MHz EHT PPDU transmission, the 40 MHz is divided into 512 subcarriers for the
63 EHT modulated fields. For a 40 MHz non-OFDMA EHT PPDU transmission, the signal of each EHT
64
modulated field is transmitted on subcarriers –244 to –3 and 3 to 244, with 0 being the center subcarrier. For
65

582 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 a 40 MHz OFDMA EHT PPDU transmission, the signal of each EHT modulated field is transmitted on all
2 or a subset of subcarriers –244 to –3 and 3 to 244, with 0 being the center subcarrier.
3
4
5 (#1330)(#2611)For an 80 MHz EHT PPDU transmission, the 80 MHz is divided into 1024 subcarriers for
6 the EHT modulated fields. For an 80 MHz nonpunctured non-OFDMA EHT PPDU that is not in EHT DUP
7 mode, the signal of each EHT modulated field is transmitted on subcarriers –500 to –3 and 3 to 500, with 0
8 being the center subcarrier. For an 80 MHz nonpunctured non-OFDMA EHT PPDU in EHT DUP mode, the
9
signal of each EHT modulated field is transmitted on subcarriers –500 to –259, –253 to –12, 12 to 253, and
10
11 259 to 500, with 0 being the center subcarrier. For an 80 MHz OFDMA EHT PPDU or punctured non-
12 OFDMA EHT PPDU transmission, the signal of each EHT modulated field is transmitted on all or a subset
13 of the subcarriers –500 to –259, –253 to –12, 12 to 253, and 259 to 500, with 0 being the center subcarrier.
14
15
(#1330)(#2611)For a 160 MHz EHT PPDU transmission, each half 80 MHz bandwidth is divided into 1024
16
17 subcarriers for EHT modulated fields, and the subcarriers on which the signal is transmitted in each 80 MHz
18 bandwidth is identical to an 80 MHz EHT PPDU transmission, depending on whether it is nonpunctured
19 non-OFDMA, (#4997)punctured non-OFDMA, or OFDMA transmission within the corresponding 80 MHz.
20
21
(#1330)(#2611)For a 320 MHz EHT PPDU transmission, each half 160 MHz bandwidth is divided into
22
23 2048 subcarriers for EHT modulated fields, and the subcarriers on which the signal is transmitted in each
24 160 MHz bandwidth is identical to a 160 MHz EHT PPDU transmission, depending on whether it is
25 nonpunctured non-OFDMA, (#4997)punctured non-OFDMA, or OFDMA transmission within the
26 corresponding 160 MHz.
27
28
29 36.3.11.3 Channel frequencies
30
31 Let(#1331)(#4624)
32
33
34 f c idx0 = dot11EHTCurrentChannelCenterFrequencyIndex0 (36-1)
35
36 f P20 idx = dot11CurrentPrimaryChannel (36-2)
37
38
39 f CH start = dot11ChannelStartingFactor  500 kHz (36-3)
40
41
42
where (#4624)dot11EHTCurrentChannelCenterFrequencyIndex0 and dot11CurrentPrimaryChannel are
43 defined in Table 36-24 (Fields to specify EHT channels)(#4693), and dot11ChannelStartingFactor denotes
44 channel starting frequency.
45
46
47 Table 36-24—Fields to specify EHT channels
48
49
50 Field Meaning
51
52 (#4625)dot11EHTCurrentChannelWidth Channel width.
53 Possible values represent 20 MHz, 40 MHz, 80 MHz, 160 MHz,
54 and 320 MHz channels.
55
56 (#4624)dot11EHTCurrentChannelCenterFreq For a 20 MHz, 40 MHz, 80 MHz, 160 MHz, or 320 MHz channel,
57 uencyIndex0 it denotes the location of the channel center frequency.
58 (#6807)Valid range is 1 to 13 for 2.4 GHz band,
59 1 to 200 for 5 GHz band, and 1 to (#2612)233 for 6 GHz band.
60
61 dot11CurrentPrimaryChannel Denotes the location of the primary 20 MHz channel.
62 (#6807)Valid range is 1 to 13 for 2.4 GHz band, 1 to 200 for
63 5 GHz band, and 1 to (#2612)233 for 6 GHz band.
64
65

Copyright © 2022 IEEE. All rights reserved. 583

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 When (#4625)(#4998)dot11EHTCurrentChannelWidth is 20 MHz, f P20 idx = f c idx0 . When

2
3 dot11EHTCurrentChannelWidth is 40 MHz, 80 MHz, or 160 MHz, the relationship between f P20 idx and
4
5 f c idx0 is specified in Equation (21-5) in 21.3.7.3 (Channel frequencies)
6
7
8
When (#4625)dot11EHTCurrentChannelWidth is 320 MHz, f P20 idx and f c idx0 shall have the relationship
9 specified in Equation (36-4).
10
11
N 20MHz
12 f P20 idx = f c idx0 – 4   ----------------
- – n P20 + 2 (36-4)
13  2 
14
15
where
16
17 N 20MHz = 16 .
18 (#1259) n P20 is an integer indicating the primary 20 MHz channel location corresponding to
19
20 dot11EHTCurrentChannelCenterFrequencyIndex0 and dot11EHTCurrentChannelWidth
21 values(#4624), with possible range 0  n P20  N 20MHz – 1 .
22
23
24 When (#4625)(#4999)dot11EHTCurrentChannelWidth is 40 MHz, 80 MHz, 160 MHz, or 320 MHz, the
25 relationship between f P20 idx and f S20 idx is specified in Equation (21-6) in 21.3.7.3 (Channel frequencies).
26
27
28 When (#4625)(#4999)dot11EHTCurrentChannelWidth is 80 MHz, 160 MHz, or 320 MHz, the relationship
29 between f P40 idx and f c idx0 is specified in Equation (21-7), and the relationship between f P40 idx and f S40 idx
30
31 is specified in Equation (21-8) in 21.3.7.3 (Channel frequencies).
32
33 When (#4625)(#4999)dot11EHTCurrentChannelWidth is 160 MHz or 320 MHz, the relationship between
34
35 f P80 idx and fc idx0 are specified in Equation (21-9), and the relationship between f P80 idx and f S80 idx are
36 specified in Equation (21-10) in 21.3.7.3 (Channel frequencies).
37
38
When (#4625)dot11EHTCurrentChannelWidth is 320 MHz,
39
40 — The primary 160 MHz channel is the channel with 160 MHz bandwidth centered at
41 fCH start + 5  fP160 idx MHz, where fP160 idx is given in Equation (36-5).
42
43 — The secondary 160 MHz channel is the channel with 160 MHz bandwidth centered at
44 fCH start + 5  fS160 idx MHz, where fS160 idx is given in Equation (36-6).
45
46
N 20MHz
47 f P160 idx = f c idx0 – 32   ----------------
- – n P160 + 16 (36-5)
48  16 
49
50
51  f P160 idx + 32 if n P160 is even
52 f S160 idx =  (36-6)
53  f P160 idx – 32 if n P160 is odd
54
55 n P20 .
56 where n P160 = ----------
57 8
58
59 36.3.11.4 Transmitted signal
60
61
62 The transmitted signal is described in complex baseband signal notation. The actual transmitted signal on
63 transmit chain iTX is related to the complex baseband signal by the relation shown in Equation (36-7).
64
65

584 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 i TX i TX
2 r RF  t  = Re  r PPDU  t   exp  j2f c t  , i TX = 1 N TX (36-7)
3
4 where
5 i
6
TX
r PPDU  t  represents the complex baseband signal of transmit chain iTX .
7
8 fc represents the center frequency of the transmitted PPDU. Table 36-25 (Center frequency of the
9 transmitted PPDU) shows fc as a function of the channel starting frequency,
10
11 (#4625)dot11EHTCurrentChannelWidth and CH_BANDWIDTH, where fCH start , fc idx0 ,
12 fP20 idx , f P40 idx , f P80 idx , and f P160 idx are described in 36.3.11.3 (Channel frequencies).
13
14
15
16 Table 36-25—Center frequency of the transmitted PPDU
17
18
19 f c = f CH Start + 5  f  0 
(#4625)dot11EHTCur
20 CH_BANDWIDTH
rentChannelWidth
21 f 0 
22
23 20 MHz CBW20 f c idx0
24
25 CBW20 f P20 idx
26 40 MHz
27 CBW40 f c idx0
28
CBW20 f P20 idx
29
30 80 MHz CBW40 f P40 idx
31
32 CBW80 f c idx0
33
34 CBW20 f P20 idx
35
36 CBW40 f P40 idx
37 160 MHz
CBW80 f P80 idx
38
39 CBW160 f c idx0
40
41 CBW20 f P20 idx
42
43 CBW40 f P40 idx
44
45 CBW80 f P80 idx
320 MHz
46
CBW160 f P160 idx
47
48 CBW320, CBW320-1,
49 f c idx0
CBW320-2(#5717)
50
51
52
53 The transmitted RF signal is derived by upconverting the complex baseband signal, which consists of
54 several fields. The timing boundaries for the various fields are shown in Figure 36-29 (Timing boundaries
55
56 for EHT PPDU fields(#1968)(#6808)), where N EHT-LTF is the number of EHT-LTF symbols and is defined in
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 585

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-23 (Frequently used parameters), N EHT-SIG is the number of OFDM symbols in the EHT-SIG field
2
3 present in an EHT MU PPDU, and N SYM is the number of OFDM symbols in the Data field(#1332).
4
5 EHT portion
Non‐EHT portion
6
pre‐EHT modulated fields EHT modulated fields
7
8 EHT‐LTF Data
9 EHT‐LTF EHT‐LTF …... EHT‐LTF
10 L‐STF L‐LTF L‐SIG RL‐SIG U‐SIG EHT‐SIG EHT‐STF Data symbol …... Data symbol PE
symbol symbol symbol
11
12 EHT ‐SIG EHT ‐LTF
0
13 L ‐LTF L ‐SIG RL ‐SIG U ‐SIG EHT ‐SIG EHT ‐STF EHT ‐LTF EHT ‐Data EHT‐PE

14 Figure 36-29—Timing boundaries for EHT PPDU fields(#1968)(#6808)

15
16
17
18 The time offset, tField , determines the starting time of the corresponding field relative to the start of L-STF
19 ( t = 0 ).
20
21
22 The signal transmitted on transmit chain iTX shall be as shown in Equation (36-8).
23
24
i
25 TX
r PPDU t = (36-8)
26 i TX i TX i TX
27 r L-STF  t  + r L-LTF  t – t L-LTF  + r L-SIG  t – t L-SIG  +
28 i TX i TX i TX
r RL-SIG  t – t RL-SIG  + r U-SIG  t – t U-SIG  + r EHT-SIG  t – t EHT-SIG  +
29 i TX i TX i TX i
30 r EHT-STF  t – t EHT-STF  + r EHT-LTF  t – t EHT-LTF  + r EHT-Data  t – t EHT-Data 
TX
+ r EHT-PE  t – t EHT-PE 
31
32
33 where
34 i
35
TX
r EHT-SIG  t – tEHT-SIG  is only applicable to an EHT MU PPDU.
36
37 1  i TX  N TX
38 t L-LTF = T L-STF
39
40 t L-SIG = t L-LTF + TL-LTF
41 t RL-SIG = tL-SIG + T L-SIG
42
43 t U-SIG = t RL-SIG + TRL-SIG
44
45  tU-SIG + T U-SIG for an EHT MU PPDU
46 t EHT-SIG = 
47  undefined otherwise
48
49  tU-SIG + T U-SIG for an EHT TB PPDU
t EHT-STF = 
50
 tEHT-SIG + N EHT-SIG T EHT-SIG for an EHT MU PPDU
51
52
53  tEHT-STF + T EHT-STF-T for an EHT TB PPDU
t EHT-LTF = 
54  tEHT-STF + T EHT-STF-NT for an EHT MU PPDU
55
56 t EHT-Data = t EHT-LTF + N EHT-LTF TEHT-LTF-SYM
57
58 t EHT-PE = t EHT-Data + N SYM T SYM
59
60 (#1339)(#1341)In the remainder of this subclause, Field is used as a generic name to represent one of the
61
62
valid EHT PPDU fields in all the mathematical symbols with Field as subscript or superscript.
63
64
65

586 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 i
2
TX
In an EHT MU PPDU, for each field excluding the PE field, r Field  t  is defined as the summation of one or
3 i
4
TX
more subfields. Each subfield, r Subfield  t  , is defined to be an inverse Fourier transform in Equation (36-9).
5
6
7 i
8
TX
r Subfield t = (#7994) (36-9)
9
10 N RU – 1 Field N user r – 1 N SS r u
11 r r
12
w TSubfield  t   ---------------------
N norm r
-   
r=0 k  Kr u=0 m=1
13
14 m
15  Q k u  i m  k BW X k r u exp  j2k F Field  t – T GI Field – T CS EHT  M r u + m   
TX
16
17
18
19 i
 r u  t  , is
TX
20
In an EHT TB PPDU, transmitted by user u in the r-th occupied RU or MRU, each subfield, r Subfield
21 defined in Equation (36-10)(#1337).
22
23 Field N SS r u
24 i TX r
25 r Subfield r u  t  = w T Subfield  t  ----------------------  Pre-EHT   (36-10)
26 N norm r kK m=1
r
27
28  Q k u  i
m
 k BW X k r u exp  j2k F Field  t – T GI Field – T CS EHT  M r u + m   
29 TX m
30
31
32 (#3170)For an EHT MU PPDU, the total power of the time domain EHT modulated field signals summed
33 over all transmit chains should not exceed the total power of the time domain pre-EHT modulated field
34 signals summed over all transmit chains.
35
36
37 For an EHT TB PPDU, the total power of the time domain EHT modulated field signals summed over all
38 transmit chains may exceed the total power of the time domain pre-EHT modulated field signals summed
39 over all transmit chains by up to 3 dB (#6810)only if the size of the assigned RU or MRU is the same or
40 smaller than 242 tones. Otherwise, the total power of the time domain EHT modulated field signals summed
41
42 over all transmit chains should not exceed the total power of the time domain pre-EHT modulated field
43 signals summed over all transmit chains.
44
45 For notational simplicity, the parameter bandwidth(#1313) is omitted from some bandwidth dependent
46 terms.
47
48
49 In Equation (36-9) and Equation (36-10), the following notations are used:
50 w TSubfield  t  is a windowing function. An example function, w TSubfield  t  , is given in 17.3.2.5 (Mathematical
51
52 conventions in the signal descriptions). (#1336) TSubfield is T L-STF for L-STF, T L-LTF for L-LTF,
53
54
TL-SIG for L-SIG, T RL-SIG for RL-SIG, (#7947) T SYML for U-SIG field(#5657), T EHT-SIG for
55 EHT-SIG, TEHT-STF-NT for EHT-STF of EHT MU PPDU, T EHT-STF-T for EHT-STF of EHT TB
56
57 PPDU, TEHT-LTF-SYM for EHT-LTF, or T SYM for EHT-Data.
58 N RU is defined in Table 36-23 (Frequently used parameters).
59
60 N Norm r For pre-EHT modulated fields, N Norm r = N TX . For EHT modulated fields, N Norm r = N SS r total
61 for an EHT MU PPDU, and N Norm r = N SS r u for an EHT TB PPDU, where N SS r total and
62
63 N SS r u are given in Table 36-23 (Frequently used parameters).
64
65

Copyright © 2022 IEEE. All rights reserved. 587

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 r (#4630)is the power boost factor of the r-th occupied RU or MRU in an EHT MU PPDU and is
2
3 determined by the POWER_BOOST_FACTOR parameter in the TXVECTOR.
4 (#4630)NOTE—  r is constrained as defined in 35.12.1.2 (POWER_BOOST_FACTOR(#4630)), i.e., for an OFDMA
5 EHT MU PPDU, r is in the range of  1  2 2  if the Power Boost Factor Support subfield of the EHT PHY
6 Capabilities Information field in the EHT Capabilities element from any recipient STA of the PPDU equals 0; and
7 otherwise  r is in the range of [0.5, 2]. For a non-OFDMA EHT MU PPDU transmitted to a single user(#1334),  r
8 equals 1.
9
10
11 Kr (#1335)For pre-EHT modulated fields, K r is the set of subcarriers indices for all the tones in
12 the corresponding 20 MHz channels where EHT modulated fields are located for the r-th
13 occupied RU or MRU. For EHT modulated fields in a nonpunctured non-OFDMA EHT PPDU
14
15 that is not in EHT DUP mode, K r is the set of subcarriers indices from – N SR to N SR as defined
16 in Table 36-19 (Subcarrier allocation related constants for the EHT-modulated fields in a
17 nonpunctured non-OFDMA EHT PPDU(#8100)) excluding DC subcarriers. For EHT
18
19 modulated fields in a nonpunctured non-OFDMA EHT MU PPDU transmitted in EHT DUP
20 mode, K r is the set of subcarriers indices for the tones in the r-th RU. For EHT modulated
21
22 fields in a punctured non-OFDMA EHT PPDU and an OFDMA EHT PPDU, K r is the set
23 of subcarriers indices for the tones in the r-th RU or MRU. Data and pilot subcarrier indices for
24 RUs are defined in Table 27-7 (Data and pilot subcarrier indices for RUs in a 20 MHz HE
25 PPDU and in a non-OFDMA 20 MHz HE PPDU), Table 27-8 (Data and pilot subcarrier
26
27 indices for RUs in a 40 MHz HE PPDU and in a non-OFDMA 40 MHz HE PPDU), Table 36-
28 5 (Data and pilot subcarrier indices for RUs in an 80 MHz EHT PPDU), Table 36-6 (Data and
29 pilot subcarrier indices for RUs in a 160 MHz EHT PPDU), and Table 36-7 (Data and pilot
30 subcarrier indices for RUs in a 320 MHz EHT PPDU). Data and pilot subcarrier indices for
31 MRUs consist of the data and pilot subcarrier indices of all component RUs.
32
Field
33 r (#1339)(#1341)is the power normalization factor of the corresponding field in the r-th
34 occupied RU or MRU and is defined in Equation (36-11)(#1339)(#1341)(#5818).
35
36
37  Field
 -----------------------------------------
- for pre-EHT modulated fields
38  Tone 
39  N Field  -------------------
20MHz
-
40  N 20MHz
41 
42  ---------------
1
43  Field- for EHT modulated fields in an EHT TB PPDU
Field  r
44 r =  (36-11)
45  Kr
46  -----------
-
47  r
Field

48  --------------------------------- otherwise
49  NRU – 1
 2
50   r Kr
51  r=0
52
53
54
55
56
57
58
59
60
61
62
63
64
65

588 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Tone
2
N Field (#1339)(#1341)is the number of tones in the corresponding field. Table 36-26 (Number of
3 modulated subcarriers and guard interval duration values for EHT PPDU fields) summarizes
4 Tone
5
the various values of N Field as a function of bandwidth(#3119).
6
7
8 Table 36-26—Number of modulated subcarriers and guard interval duration values for EHT
9 PPDU fields
10
11
12 Tone
N Field as a function of bandwidth Guard
13 Field interval
14 duration
20 MHz 40 MHz 80 MHz 160 MHz 320 MHz
15
16
L-STF 12 24 48 96 192 —
17
18 L-LTF 52 104 208 416 832 T GI L-LTF
19
20 L-SIG in an EHT PPDU 56 112 224 448 896
21
L-SIG in a non-HT T GI Pre-EHT
22 — 104 208 416 832
23 duplicate PPDU
24
RL-SIG 56 112 224 448 896 T GI Pre-EHT
25
26 T GI Pre-EHT
U-SIG 56 112 224 448 896
27
28 EHT-SIG 56 112 224 448 896 T GI Pre-EHT
29
30 NON_HT_DUP_OFD T GI Pre-EHT
31 — 104 208 416 832
M-Data (see NOTE)
32
33 NOTE—For notational convenience, NON_HT_DUP_OFDM-Data is used as a label for the Data field of a
34 NON_HT PPDU with format type NON_HT_DUP_OFDM.
35
36
37
38 1 if CH_BANDWIDTH is CBW20

39  2 if CH_BANDWIDTH is CBW40
40 
41 N 20MHz =  4 if CH_BANDWIDTH is CBW80, (#5717)(#1559)
42 
43  8 if CH_BANDWIDTH is CBW160,
44  16 if CH_BANDWIDTH is CBW320, CBW320-1, CBW320-2
45  20MHz is a set of 20 MHz channels where pre-EHT modulated fields are located. The set of 20 MHz
46
47 channels contains one or more values in the range 0 to N 20MHz – 1 for an EHT MU PPDU with
48 preamble puncturing, or an EHT TB PPDU, and it contains all values in the range 0 to
49
50 N 20MHz – 1 for an EHT MU PPDU without preamble puncturing.
51  20MHz is the cardinality of the set of 20 MHz channels  20MHz .
52
53  Field (#1339)(#1341)is the power deboosting factor of the corresponding pre-EHT modulated field
54 relative to the L-SIG field defined as:
55
56  Tone
57  N L-LTF
-
 ---------------- for the L-STF and L-LTF fields
58  Field =  N ToneL-SIG
59 
 1 otherwise
60 
61
62 Kr is the cardinality of the set of subcarriers K r .
63
64
65

Copyright © 2022 IEEE. All rights reserved. 589

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Field
r (#1339)(#1341)equals the number of modulated subcarriers within K r (see Table 36-23
2
3 (Frequently used parameters)) for the EHT-STF and Data fields. For the EHT-LTF field, r
Field

4
5 is defined as below to ensure per tone power are the same for both EHT-LTF and Data fields,
6 regardless of 1, 2, or 4 EHT-LTF.
7
8
9  Kr  for a 4  EHT-LTF
10 EHT-LTF 
 r =  K r  2 for a 2  EHT-LTF
11

12  K r  4 for an 1  EHT-LTF
13
14  Pre-EHT (#2612)is the power scaling factor of a given field for an EHT TB PPDU. For the pre-EHT
15
1
16 modulated fields,  Pre-EHT is in the range of ------- 1 when the size of the r-th occupied RU or
17 2
18
19 MRU is the same or smaller than 242 tones(#1315); otherwise  Pre-EHT = 1 . The same  Pre-EHT
20 value applies to all pre-EHT modulated fields. For EHT modulated fields,
21
Pre-EHT = 1 (#7994).
22
23 Q k u is the spatial mapping matrix for user u on subcarrier k. For EHT modulated fields, Q k u is a
24
25 matrix with N TX rows and N SS r u columns. For pre-EHT modulated fields, Q k u is a column
26 i i
27 vector with N TX elements, with element iTX being exp  – j2k F Pre-EHT T CS
TX
 , where T CS
TX

28 represents the cyclic shift for the transmitter chain whose value is defined in 36.3.12.2.1
29 (Cyclic shift for pre-EHT modulated fields).
30
31  F Field (#1339)(#1341)is the subcarrier frequency spacing of the corresponding field. For pre-EHT
32 modulated fields,  F Field =  F Pre-EHT given in Table 36-18 (Timing-related constants). For
33
34 EHT modulated fields,  F Field =  F EHT given in Table 36-18 (Timing-related constants).
35 M r u is given in Table 36-23 (Frequently used parameters).
36
37 m
X k r u is the frequency-domain symbol assigned for subcarrier k of user u in the r-th RU or MRU for
38
39 the m-th spatial stream. Some of the X mk r u within – N SR  k  N SR have a value of zero.
40 Examples of such cases include the DC tones, guard tones on each side of the transmit
41 spectrum, the null subcarriers in an EHT OFDMA PPDU, as well as the unmodulated tones of
42
43 L-STF, EHT-STF, and EHT-LTF fields.
44 T GI Field (#1339)(#1341)is the guard interval duration used for each OFDM symbol in the
45 corresponding field. The value of guard interval duration for each EHT PPDU field is defined
46
47
in Table 36-18 (Timing-related constants).
48 T CS EHT  l  For pre-EHT modulated fields, T CS EHT  l  = 0 . For EHT modulated fields, TCS EHT  l 
49 represents the cyclic shift per spatial stream, whose value is defined in 36.3.12.2.2 (Cyclic shift
50
51
for EHT modulated fields).
52  k BW is used to represent a phase rotation applied to the k-th subcarrier for a given bandwidth BW,
53 which is determined by the TXVECTOR parameter CH_BANDWIDTH as defined in
54
Table 36-27 (CH_BANDWIDTH and phase rotation for a given bandwidth for pre-EHT
55
56 modulated fields(#1560)(#4846)). For EHT modulated fields, k BW = 1 for all subcarriers.
57
For pre-EHT modulated fields,  k BW is defined as in 21.3.7.5 (Definition of tone rotation) for
58
59 20 MHz, 40 MHz, 80 MHz, and 160 MHz PPDU transmission, and in Equation (36-12) for a
60 320 MHz PPDU transmission,
61
62
63
64
65

590 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2  1 k  – 448
3 
 – 1 – 448  k  – 256
4  
5  1 – 256  k  – 192
6  –  – 192  k  0
7  1
 k 320 =  (36-12)
  2 0  k  64
8
9  – 
10  2 64  k  256
11   256  k  320
12  3
13  –  k  320
14  3
15
16 where  1 2 3 are implementation dependent per 80 MHz subblock rotation coefficient with
17
18 value of +1 and –1. Two examples of such 320 MHz phase rotations are given in
19 (#4621)Equation (36-13), where 1 = 1 ,  2 = – 1 , and 3 = – 1 , and Equation (36-14),
20
21 where  1 = 1 , 2 = 1 , and 3 = –1 .
22
23
24  1 k  – 448
25  – 1 – 448  k  – 256
26 
27  1 – 256  k  – 192

28  – 1 – 192  k  0
29  k 320 =  (36-13)
30  – 1 0  k  64
31  1 64  k  256
32 
33  – 1 256  k  320

34  1 k  320
35
36
37
 1 k  – 448
38  – 1 – 448  k  – 256
39 
40  1 – 256  k  – 192
41 
42  – 1 – 192  k  0
 k 320 =  (36-14)
43
 1 0  k  64
44  – 1 64  k  256
45 
46  – 1 256  k  320
47 
48  1 k  320
49
50
51
52
53
54 Table 36-27—CH_BANDWIDTH and phase rotation for a given bandwidth for pre-EHT mod-
55 ulated fields(#1560)(#4846)
56
57
58 CH_BANDWIDTH  k BW
59
60 CBW20  k 20
61
62 CBW40  k 40
63
64
65

Copyright © 2022 IEEE. All rights reserved. 591

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-27—CH_BANDWIDTH and phase rotation for a given bandwidth for pre-EHT mod-
2 ulated fields(#1560)(#4846) (continued)
3
4
5 CH_BANDWIDTH  k BW
6
7 CBW80  k 80
8
9
10 CBW160  k 160
11
12 CBW320, CBW320-1,
 k 320
13 CBW320-2(#5717)
14
15
16
17 36.3.12 EHT preamble
18
19 36.3.12.1 Introduction
20
21
The EHT preamble consists of pre-EHT modulated fields and EHT modulated fields. The pre-EHT
22
23 modulated fields for the two EHT PPDU formats are the following:
24 — L-STF, L-LTF, L-SIG, RL-SIG, and U-SIG fields of an EHT TB PPDU
25
26 — L-STF, L-LTF, L-SIG, RL-SIG, U-SIG, and EHT-SIG fields of an EHT MU PPDU
27
28 (#1342)The EHT modulated fields in the preamble for the two EHT PPDU formats are the EHT-STF and
29 EHT-LTF fields.
30
31
32 (#1380)(#1381)(#2173)(#4552)For an EHT STA with operating bandwidth larger than 80 MHz, the pre-
33 EHT modulated field design ensures that an EHT STA is required to process only one 80 MHz frequency
34 subblock of the pre-EHT modulated fields to get all the assignment information for itself. (#7196)For an
35 EHT PPDU with bandwidth larger than 80 MHz, an EHT STA can get all required information from
36
processing the primary 80 MHz or the 80 MHz in which the STA is operating in and does not need to
37
38 process other 80 MHz frequency subblocks.
39
40 (#5421)The pre-EHT modulated fields (see Figure 36-29 (Timing boundaries for EHT PPDU
41 fields(#1968)(#6808))) are not transmitted in 20 MHz subchannels in which the preamble is punctured.
42
43
44 36.3.12.2 Cyclic shift
45
46 36.3.12.2.1 Cyclic shift for pre-EHT modulated fields
47
48 i
TX
49 The cyclic shift value T CS for the L-STF, L-LTF, L-SIG, RL-SIG, U-SIG, and EHT-SIG fields of the PPDU
50
51 for transmit chain i TX out of a total of N TX are defined in Table 21-10 (Cyclic shift values for L-STF, L-
52 LTF, L-SIG, and VHT-SIG-A fields of the PPDU)(#3045). In UL MU transmission,(#7995) the cyclic shift
53 i
TX
54 value T CS is based on the local transmit chain indices at each STA.
55
56 36.3.12.2.2 Cyclic shift for EHT modulated fields
57
58
59 Throughout the EHT modulated fields of the preamble, cyclic shifts are applied to prevent unintended
60 beamforming when correlated signals are transmitted in multiple spatial streams. The same cyclic shifts are
61 also applied to these streams during the transmission of the Data field of the EHT PPDU. For the r-th RU,
62
63 the cyclic shift value TCS EHT  n  for the EHT modulated fields for spatial stream n out of N SS r total total
64
65

592 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 spatial streams is shown in (#4847)(#7906)Table 21-11 (Cyclic shift values for the VHT modulated fields of
2 a PPDU)(#2027) when N SS r total is less than or equal to 8.
3
4
5 36.3.12.3 L-STF
6
7
8 The time domain representation of the L-STF field, transmitted on transmit chain i TX shall be as specified in
9 Equation (36-15). (#1343)(#7197)The equation applies to all signals up to 320 MHz bandwidth PPDU with
10 or without preamble puncturing.
11
12
26
13 i TX 
14
15
r L-STF  t  = ---------------------------------------------------------- w TL-STF  t  Pre-EHT
 20MHz
  (36-15)
Tone  
16 N TX  N L-STF  -------------------- i BW 20MHz k = – 26
N 20MHz
17
18 i TX
19    k – KShift  iBW   BW S k 20 exp  j2  k – K Shift  i BW   F Pre-EHT  t – T CS   
20
21
22
23 where
24
25 Tone
N L-LTF
26  is a power scaling factor with the value  = ----------------
Tone
-.
27 N L-SIG
28  Pre-EHT is defined (#4579)in Equation (36-10).
29
30 K Shift  i  =  N 20MHz – 1 – 2i   32
31 TXi
32 T CS represents the cyclic shift for transmit chain i TX with a value as described in 36.3.12.2.1
33 (Cyclic shift for pre-EHT modulated fields)(#3082)(#3000).
34 Tone
35 N L-STF is the value given in Table 36-26 (Number of modulated subcarriers and guard interval
36 duration values for EHT PPDU fields).
37
38  20MHz is a set of 20 MHz channels where pre-EHT modulated fields are located. The set of 20 MHz
39 channels contains one or more values in the range 0 to N 20MHz – 1 for an EHT TB PPDU or
40
41 EHT MU PPDU with preamble puncturing, and it contains all values in the range 0 to
42 N 20MHz – 1 for an EHT MU PPDU without preamble puncturing(#2789).
43
1 if CH_BANDWIDTH is CBW20
44 
45  2 if CH_BANDWIDTH is CBW40
46 
47 N 20MHz =  4 if CH_BANDWIDTH is CBW80

48
 8 if CH_BANDWIDTH is CBW160
49  16
50 if CH_BANDWIDTH is CBW320
51 S k 20 is defined as S k , where S k is an element of S –26 26 for – 26  k  26 from Equation (19-
52
53 8)(#4577).
54 i BW is the index of 20 MHz channels, 0  iBW  N 20MHz – 1 .
55 Other variables in Equation (36-15) are defined in 36.3.10 (Timing-related parameters) and 36.3.11
56
57 (Mathematical description of signals)(#4665).
58
59 36.3.12.4 L-LTF
60
61
62
The time domain representation of the L-LTF field, transmitted on transmit chain iTX , shall be as specified in
63 Equation (36-16). (#7197)The equation applies to all signals up to 320 MHz bandwidth PPDU with or
64 without preamble puncturing.
65

Copyright © 2022 IEEE. All rights reserved. 593

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 26
2 i TX 
3
r L-LTF  t  = ----------------------------------------------------------- w T L-LTF  t  Pre-EHT
 20MHz
  (36-16)
Tone i BW   20MHz k = – 26
4 N TX  N L-LTF  ------------------- -
5 N 20MHz
6 i
7    k – KShift  iBW   BW L k 20 exp  j2  k – K Shift  i BW   F Pre-EHT  t – T GI L-LTF – T CS
TX

8
9
10
11
12 where
13 Tone
14 N
 is a power scaling factor with the value  = L-LTF
Tone
.
----------------
-
15 N L-SIG
16
17 T GI L-LTF is given in Table 36-18 (Timing-related constants).
18 K Shift  i  =  N 20MHz – 1 – 2i   32
19
i
20 TX
T CS represents the cyclic shift for transmit chain i TX with a value as described in 36.3.12.2.1
21
22 (Cyclic shift for pre-EHT modulated fields)(#3083)(#3000).
23 Tone
N L-LTF is the value given in Table 36-26 (Number of modulated subcarriers and guard interval
24
25 duration values for EHT PPDU fields).
26 L k 20 is defined as Lk , where L k is an element of L–26 26 for – 26  k  26 from Equation (17-
27
8)(#4578).
28
29 Other variables in Equation (36-16) are defined in 36.3.10 (Timing-related parameters) and 36.3.11
30 (Mathematical description of signals)(#4665).
31
32 36.3.12.5 L-SIG
33
34
35 The L-SIG field is used to communicate rate and length information. The structure of the L-SIG field is
36 defined in Figure 17-5 (SIGNAL field bit assignment).
37
38 In an EHT PPDU, the RATE field shall be set to the value representing 6 Mb/s in the 20 MHz channel
39
spacing column of Table 17-6 (Contents of the SIGNAL field). In a non-HT duplicate PPDU, the RATE
40
41 field is defined in 17.3.4.2 (RATE field) using the L_DATARATE parameter in the TXVECTOR.
42
43 (#7996)The LENGTH field in an EHT PPDU is set to a value satisfying the condition that the remainder is
44 zero when LENGTH is divided by 3. (#1346)(#1348)(#8103)This remainder is used to differentiate an EHT
45
PPDU from an HE PPDU.
46
47
48 For an EHT TB PPDU, the LENGTH field is set to the TXVECTOR parameter L_LENGTH + 2. For an
49 EHT MU PPDU, the LENGTH field is set to the value given by Equation (36-17).
50
51 (#4667)NOTE—The TXVECTOR parameter L_LENGTH field of an EHT TB PPDU has the same value as the UL
52 Length subfield of a Trigger frame. The UL Length subfield of a Trigger frame that solicits either an HE TB PPDU or an
53 EHT TB PPDU is set following (27-11) with m = 2 as defined in 35.5.2.2.4 (Allowed settings of the Trigger frame fields
54 and TRS Control subfield), then the nonzero m is reversed for EHT TB PPDU by adding 2 as above.
55
56 TXTIME – SignalExtension – 20  3 – 3
57 Length = ------------------------------------------------------------------------------------ (36-17)
4
58
59
60 where
61 TXTIME (in microseconds) is defined in 36.4.3 (TXTIME and PSDU_LENGTH calculation).
62
63 SignalExtension is defined in Table 27-54 (HE PHY characteristics).
64
65

594 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 In a non-HT duplicate PPDU, the LENGTH field is defined in 17.3.4.3 (PHY LENGTH field) using the
2 L_LENGTH parameter in the TXVECTOR.
3
4
5 The Reserved (R) field shall be set to 0.
6
7 The Parity (P) field has the even parity of bits 0–16.
8
9
The SIGNAL TAIL field shall be set to 0.
10
11
12 The L-SIG field shall be encoded, interleaved, and mapped following the steps described in
13 17.3.5.6 (Convolutional encoder), 17.3.5.7 (Data interleaving), and 17.3.5.8 (Subcarrier modulation
14 mapping). (#4569)The stream of 48 complex numbers generated by these steps is denoted by
15
16 d k k = 0 1  47 and is mapped to subcarriers  – 26 26  . In addition, values  – 1 – 1 – 1 1  are mapped
17 to the extra subcarriers  – 28 – 27 27 28  of the L-SIG field of a 20 MHz EHT PPDU. Subcarriers
18
19  – 28 – 27 27 28  are also BPSK modulated. Pilots shall be inserted as described in 17.3.5.9 (Pilot
20 subcarriers).
21
22
23 The time domain waveform of the L-SIG field, transmitted on transmit chain i TX , shall be as given by
24 Equation (36-18).
25
26
27 i
28
TX
r L-SIG t (36-18)
29
30
31 28
32 1
33
= ---------------------------------------------------------- w TL-SIG  t  Pre-EHT
 20MHz
 
Tone i BW   20MHz k = – 28
34 N TX  N L-SIG  ------------------- -
35 N 20MHz
36
i
37    k – K Shift  iBW   BW  D k 20 + p 0 P k exp  j2  k – K Shift  i BW   F Pre-EHT  t – T GI Pre-EHT – T CS
TX

38
39
40
41
42 where
43 T GI Pre-EHT is given in Table 36-18 (Timing-related constants).
44
45 K Shift  i  =  N 20MHz – 1 – 2i   32
46
47  0 k = 0  7  21

48  – 1 k = – 28  27
49 
D k 20 =  1
50  k = 28
51 
 d Mr20  k  otherwise
52 
53
54  k + 26 – 26  k  – 22
55  k + 25 – 20  k  – 8
56 
57 r  k + 24 –6  k  –1
M 20  k  = 
58
 k + 23 1k6
59  k + 22
60  8  k  20
61  k + 21 22  k  26
62
63 Pk is defined in 17.3.5.10 (OFDM modulation).
64 p0 is the first pilot value in the sequence defined in 17.3.5.10 (OFDM modulation)
65

Copyright © 2022 IEEE. All rights reserved. 595

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Tone
N L-SIG is defined in Table 36-26 (Number of modulated subcarriers and guard interval duration values
2
3 for EHT PPDU fields).
4 i
TX
5 T CS represents the cyclic shift for transmit chain i TX with a value given in 36.3.12.2.1 (Cyclic shift
6 for pre-EHT modulated fields)(#3000).
7 Other variables in Equation (36-18) are defined in 36.3.10 (Timing-related parameters) and 36.3.11
8
(Mathematical description of signals)(#4665).
9
10 r
NOTE— M 20  k  is a “reverse” function of the function M  k  defined in 17.3.5.10 (OFDM modulation)(#2689).
11
12
36.3.12.6 RL-SIG
13
14
15 The RL-SIG field is a repeat of the L-SIG field and is used to differentiate an EHT PPDU from a non-HT
16 PPDU, HT PPDU, and VHT PPDU.
17
18
19 The time domain waveform of the RL-SIG field, transmitted on transmit chain iTX , shall be as given by
20 Equation (36-19).
21
22
23 i
t =
TX
24 r RL-SIG (36-19)
25
26
27 28
28 1
29
------------------------------------------------------------- w T
 20MHz RL-SIG
 t  Pre-EHT  
Tone i BW   20MHz k = – 28
30 N TX  N RL-SIG  --------------------
31 N 20MHz
32
i
33    k – KShift  iBW   BW  D k 20 + p 1 P k exp  j2  k – K Shift  i BW   F Pre-EHT  t – T GI Pre-EHT – T CS
TX

34
35
36
37
38 where
39 p1 is the second pilot value in the sequence defined in 17.3.5.10 (OFDM modulation).
40
41 Other variables in Equation (36-19) are defined in 36.3.10 (Timing-related parameters) and 36.3.11
42 (Mathematical description of signals)(#4665).
43
44 (#5719)All the other parameters are described in the variable list of Equation (36-15).
45
46
47 36.3.12.7 U-SIG
48
49 36.3.12.7.1 General
50
51
52
The U-SIG field carries information necessary to interpret EHT PPDUs. The integer fields of the U-SIG
53 field are transmitted in unsigned binary format, LSB first, where the LSB is in the lowest numbered bit
54 position.
55
56 36.3.12.7.2 Content
57
58
59 (#1349)(#1350)(#3172)(#3286)The U-SIG field is designed to bring forward compatibility to the EHT
60 preamble via the introduction of version independent fields. (#3085)These are the fields that will be
61 consistent in location and interpretation across multiple IEEE 802.11 PHY clauses. The intent of the version
62 independent content is to achieve better coexistence among IEEE 802.11 PHY clauses that are defined for
63
64
2.4, 5, and 6 GHz spectrum from Clause 36 (Extremely high throughput (EHT) PHY specification) onwards.
65 In addition, the U-SIG field(#5657) can have some version dependent fields that are fields specific to an

596 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 IEEE 802.11 PHY clause. The U-SIG field(#5657) includes version independent bits followed by version
2 dependent bits. PHY Version Identifier field is one of the version independent fields in the U-SIG
3
field(#5657). The purpose of the PHY version identifier is to simplify autodetection for IEEE 802.11 PHY
4
5 clauses that are defined for 2.4, 5, and 6 GHz spectrum from Clause 36 (Extremely high throughput (EHT)
6 PHY specification) onwards, i.e., the value of this field is used to identify the exact PHY version starting
7 with EHT.
8
9
(#1349)(#1351)(#2791)(#2802)(#3182)(#2702)The length of the U-SIG field for EHT MU PPDU and EHT
10
11 TB PPDU is two OFDM symbols. For forward compatibility, (#7999)(#4944)EHT also defines the U-SIG
12 field of an ER preamble while not defining an ER PPDU (#5408)for an EHT STA with
13 dot11EHTBaseLineFeaturesImplementedOnly equal to true. (#4595)An EHT STA shall be able to decode
14 and interpret the version independent content in the U-SIG field(#5657) of an ER preamble that may be
15
introduced in IEEE 802.11 PHY clauses that are defined for 2.4, 5, and 6 GHz spectrum from Clause 36
16
17 (Extremely high throughput (EHT) PHY specification) onwards. Regardless of the value of the PHY
18 Version Identifier field in U-SIG field(#5657), (#4595)an EHT STA shall defer for the duration of the PPDU
19 as defined in 36.3.22 (EHT receive procedure), report the information from the version independent fields
20 within the RXVECTOR, and terminate the reception of the PPDU. The length of the U-SIG field for an ER
21
preamble is four OFDM symbols.
22
23
24 (#2704)(#2175)(#1353)(#1355)(#1969)(#1352)Reserved fields in the EHT preamble or reserved values of
25 the fields in the EHT preamble are divided into two categories: Validate and Disregard. (#8002)An EHT
26 STA shall set the Disregard fields and Validate fields in accordance with the requirements specified in this
27
subclause. Validate field values serve to indicate whether to continue reception of a PPDU at an EHT STA.
28
29 (#7199)(#8003)If an EHT STA encounters a PPDU where at least one Validate field in the preamble is not
30 set to the value specified in Clause 36 (Extremely high throughput (EHT) PHY specification), or at least one
31 field in the EHT preamble equals a value that is identified as Validate for the STA, the STA shall defer for
32 the duration of the PPDU as defined in 36.3.22 (EHT receive procedure) and report the information from the
33
version independent fields within the RXVECTOR. If an EHT STA sees any of the fields identified as
34
35 Disregard for the STA set to a value that is different from its specified value in this subclause or field values
36 of any field in the EHT preamble as being set to a value identified as Disregard for the STA in this subclause,
37 it shall ignore these field values and they will have (#4642)no impact on the STA’s continued reception of
38 the PPDU (i.e., reception at the STA can continue as usual). For further details on receive behavior when
39
encountered with Validate and Disregard fields or any field as being set to a value identified as Validate or
40
41 Disregard, (#3174)refer to 36.3.22 (EHT receive procedure).
42
43 (#8002)NOTE 1—Some of the Disregard or Validate fields might be redefined for EHT STAs with
44 dot11EHTBaseLineFeaturesImplementedOnly equal to false.
45
46 (#1371)For a 40 MHz EHT PPDU or ER preamble, the U-SIG field(#5657) content shall be identical in both
47
48 20 MHz subchannels. For an 80 MHz EHT PPDU or ER preamble, the U-SIG field(#5657) content shall be
49 identical in all nonpunctured 20 MHz subchannels. (#4692)For a 160/320 MHz EHT MU PPDU or ER
50 preamble, the U-SIG field(#5657) content shall be identical in all nonpunctured 20 MHz subchannels within
51 each 80 MHz (#6434)frequency subblock, and the U-SIG field(#5657) content in different 80 MHz
52 (#6434)frequency subblocks may be different. (#4692)For a 160/320 MHz EHT TB PPDU, the U-SIG
53
54 content shall be identical in all nonpunctured 20 MHz subchannels within the PPDU bandwidth if
55 dot11EHTBaseLineFeaturesImplementedOnly is equal to true.
56
(#8005)NOTE 2—An EHT MU PPDU with TXVECTOR parameter EHT_PPDU_TYPE equal to 1 or 2 has the same U-
57
SIG content for all nonpunctured 20 MHz subchannel for all PPDU bandwidths.
58
59
60 (#8005)NOTE 3—Only the Punctured Channel Information field might have different values between different 80 MHz
61 frequency subblocks in an EHT MU PPDU with TXVECTOR parameter EHT_PPDU_TYPE equal to 0.
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 597

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The U-SIG field for an EHT MU PPDU contains the fields listed in Table 36-28 (U-SIG field of an EHT
2 MU PPDU). The version independent bits are B0–B19 of U-SIG-1 field(#5657). The rest of the bits are
3
version dependent(#4641).
4
5
6
7 Table 36-28—U-SIG field of an EHT MU PPDU
8
9
10 Two parts Number
Bit Field Description
11 of U-SIG of bits
12
13 U-SIG-1 B0–B2 PHY Version Identifier 3 (#1349)Differentiate between different PHY
14 clauses.
15 Set to 0 for EHT.
16 Values 1–7 are Validate(#8006).
17
18 B3–B5 Bandwidth(#4655) 3 Set to 0 for 20 MHz.
19 Set to 1 for 40 MHz.
20 Set to 2 for 80 MHz.
21 Set to 3 for 160 MHz.
22 Set to 4 for 320 MHz-1.
23 Set to 5 for 320 MHz-2.
24 See definition of 320 MHz-1 and 320 MHz-2
25 in 36.3.23.2 (Channelization for 320 MHz
26 channel(#1577))(#2727).
27 Values 6 and 7 are Validate(#8006)(#2794).
28 B6 UL/DL 1 (#5410)Indicates whether the PPDU is sent in
29 UL or DL. (#4608)Set to the TXVECTOR
30 parameter UPLINK_FLAG.
31
32 A value of 1 indicates the PPDU is
33 addressed to an AP.
34 A value of 0 indicates the PPDU is
35 addressed to a non-AP STA.
36
37 B7–B12 BSS Color 6 An identifier of the BSS.
38 (#4608)Set to the TXVECTOR parameter
39 BSS_COLOR.
40
41 B13–B19 TXOP 7 (#8007)If the TXVECTOR parameter
42 TXOP_DURATION is UNSPECIFIED, set to
43 127 to indicate the absence of duraiton
44 information.
45 (#3176)(#1359)(#2628)If the TXVECTOR
46 parameter TXOP_DURATION is an integer
47 value, set to a value less than 127 to indicate
48 duration information for NAV setting and
49 protection of the TXOP as follows:
50 If the TXVECTOR parameter TXO-
51 P_DURATION is less than 512, set to
52 2  floor(TXOP_DURATION/8).
53 Otherwise, set to
54 2  floor((TXOP_DURATION – 512)/
55 128) + 1.
56
57 B20–B24 Disregard 5 Set to all 1s and treat as
58 Disregard(#7201)(#8006)(#2794).
59
60 B25 Validate 1 Set to 1 and treat as
61 Validate(#7201)(#8006)(#2794).
62
63
64
65

598 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-28—U-SIG field of an EHT MU PPDU (continued)

2
3
4 Two parts Number
Bit Field Description
5 of U-SIG of bits
6
7 U-SIG-2 B0–B1 PPDU Type And 2 (#1361)(#3177)(#2399)(#3187)(#1352)(#4599
8 Compression Mode )(#4946)If the UL/DL field is set to 0:
9 A value of 0 indicates a DL OFDMA
10 transmission.
11 A value of 1 indicates a transmission to a
12 single user or an EHT sounding NDP.
13 A value of 2 indicates a non-OFDMA DL
14 MU-MIMO transmission.
15 A value of 3 is Validate.
16
17 If the UL/DL field is set to 1:
18 A value of 1 indicates a transmission to a
19 single user or an EHT sounding NDP.
20 Values 2 and 3 are Validate.
21
22 NOTE—A value of 0 indicates a TB
23 PPDU. Refer to Table 36-31 (U-SIG field
24 of an EHT TB PPDU).
25
26 For further clarifications on all values of this
27 field, (#3178)refer to Table 36-29
28 (Combination of UL/DL and PPDU Type And
29 Compression Mode field(#1562)(#1352)).
30
31 B2 Validate 1 (#2796)Set to 1 and treat as
32 Validate(#7201)(#8006)(#2794).
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 599

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-28—U-SIG field of an EHT MU PPDU (continued)

2
3
4 Two parts Number
Bit Field Description
5 of U-SIG of bits
6
7 B3–B7 Punctured Channel 5 (#2400)(#1364)(#2797)(#1614)(#3179)(#5475
8 Information )If the PPDU Type And Compression Mode
9 field is set to 1 regardless of the value of the
10 UL/DL field, or the PPDU Type And
11 Compression Mode field is set to 2 and the
12 UL/DL field is 0:
13 (#8008)Indicates the puncturing
14 information of this non-OFDMA
15 transmission. See Table 36-30
16 (Definition of the Punctured Channel
17 Information field in the U-SIG for an
18 EHT MU PPDU using non-OFDMA
19 transmissions(#8011)(#2402))) for the
20 definition. Undefined values of this field
21 are Validate(#8006)(#2794).
22 (#5476)If the PPDU Type And Compression
23 Mode field is set to 0 and the UL/DL field is 0:
24 (#2179)(#2804)(#4789)(#4655)If the
25 Bandwidth field is set to a value between
26 2 and 5, which indicates an 80 MHz,
27 160 MHz or 320 MHz PPDU, then B3–
28 B6 is a 4-bit bitmap that indicates which
29 20 MHz subchannel is punctured in the
30 (#7202)80 MHz (#6434)frequency
31 subblock where U-SIG processing is
32 performed. The 4-bit bitmap is indexed
33 by the 20 MHz subchannels in ascending
34 order with B3 indicating the lowest
35 frequency 20 MHz subchannel. For each
36 of the bits B3–B6, a value of 0 indicates
37 that the corresponding 20 MHz channel
38 is punctured, and a value of 1 is used
39 otherwise. The following allowed
40 punctured patterns (B3–B6) are defined
41 for an 80 MHz (#6434)frequency
42 subblock: 1111 (no puncturing), 0111,
43 1011, 1101, 1110, 0011, 1100, and
44 1001(#2632). Any field values other than
45 the allowed punctured patterns are
46 Validate(#8006)(#2794). Field value
47 may be varied from one 80 MHz to the
48 other.
49 (#4655)If the Bandwidth field is set to 0
50 or 1, which indicates a 20/40 MHz
51 PPDU, B3–B6 are set to all 1s. Other
52 values are Validate (#8006).
53 B7 is set to 1 and Disregard(#8006).
54
55 B8 Validate 1 (#2796)Set to 1 and treat as
56 Validate(#7201)(#8006)(#2794).
57
58 B9–B10 EHT-SIG MCS 2 Indicates the MCS used for modulating the
59 EHT-SIG.
60 Set to 0 for EHT-MCS 0.
61 Set to 1 for EHT-MCS 1.
62 Set to 2 for EHT-MCS 3.
63 Set to 3 for EHT-MCS 15(#3001).
64
65

600 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-28—U-SIG field of an EHT MU PPDU (continued)

2
3
4 Two parts Number
Bit Field Description
5 of U-SIG of bits
6
7 B11–B15 Number Of EHT-SIG 5 (#2179)(#2804)Indicates the number of EHT-
8 Symbols SIG symbols. Set to a value that is the number
9 of EHT-SIG symbols minus 1. This value shall
10 be the same in every 80 MHz
11 (#6434)frequency subblock.
12
13 B16–B19 CRC 4 (#8105)CRC for bits 0–41 of the U-SIG field.
14 Bits 0–41 of the U-SIG field correspond to bits
15 0–25 of U-SIG-1 field followed by bits 0–15
16 of U-SIG-2 field(#5657). The CRC
17 computation uses the same polynomial as that
18 in 27.3.11.7.3 (CRC computation).
19
20 B20–B25 Tail 6 Used to terminate the trellis of the
21 convolutional decoder. Set to 0.
22
23
24
25
26
27
28 Table 36-29—Combination of UL/DL and PPDU Type And Compression Mode
29 field(#1562)(#1352)
30
31
32 U-SIG fields Description
33
34 Total number of
PPDU Type (#2706)E (#2750)RU
35 User fields in
And HT EHT-SIG Allocation
36 UL/DL MU PPDU or Note
Compression PPDU present? subfields
37 transmitters in
Mode format present?
38 TB PPDU
39
40 DL OFDMA (including
41 0 EHT MU Yes Yes 1 non-MU-MIMO and
42 MU-MIMO)
43
44 (#8009)Transmission to
45 a single user or NDP
46 that is not addressed to
47 1 for
an AP.
48 transmission to a
1 EHT MU Yes No
49 0 (DL) single user; 0 for
NOTE—One such case
50 NDP
is a downlink
51 transmission from an
52 AP to a non-AP STA.
53
54
55 DL MU-MIMO (non-
2 EHT MU Yes No > 1(#3180)
56 OFDMA).
57
58 3 — — — — Validate(#8006)(#2794)
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 601

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-29—Combination of UL/DL and PPDU Type And Compression Mode

2 field(#1562)(#1352) (continued)
3
4
5 U-SIG fields Description
6
7 Total number of
8 PPDU Type (#2706)E (#2750)RU
User fields in
9 And HT EHT-SIG Allocation
UL/DL MU PPDU or Note
10 Compression PPDU present? subfields
transmitters in
11 Mode format present?
TB PPDU
12
13
14 (#2444)UL OFDMA or
15 UL non-OFDMA
16 0 EHT TB No — 1 (including non-MU-
17 MIMO and MU-
18 MIMO).
19 1 (UL)
20 1 for (#8010)Transmission to
21 transmission to a a single user or NDP
1 EHT MU Yes No
22 single user; 0 for that is addressed to an
23 NDP AP.
24
25 2–3 — — — — Validate(#8006)(#2794)
26
27
28
29 (#1361)(#3177)(#2399)(#3187)If the PPDU Type And Compression Mode field is set to 1, the EHT MU
30 PPDU is a transmission to a single user or an EHT sounding NDP regardless of the value of the UL/DL
31 field. In addition to the PPDU Type And Compression Mode field being set to 1, if the EHT-SIG MCS field
32
is set to 0 and the Number Of EHT-SIG Symbols field is set to 0, it indicates an EHT sounding NDP.
33
34
35
36 Table 36-30—Definition of the Punctured Channel Information field in the U-SIG for an EHT
37 MU PPDU using non-OFDMA transmissions(#8011)(#2402)
38
39
40 PPDU Puncturing pattern
Cases Field value
41 bandwidth (RU or MRU Index)
42
43 [1](#5411)
44 20 MHz No puncturing 0
(242-tone RU 1)
45
46 [1 1](#5411)
47 40 MHz No puncturing 0
(484-tone RU 1)
48
49
50 [1 1 1 1]
No puncturing 0
51 (996-tone RU 1)
52
53 [x 1 1 1]
1
54 (484+242-tone MRU 1)
55
56 [1 x 1 1]
80 MHz 2
57 (484+242-tone MRU 2)
58 20 MHz puncturing
59 [1 1 x 1]
60 3
(484+242-tone MRU 3)
61
62 [1 1 1 x]
63 4
(484+242-tone MRU 4)
64
65

602 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-30—Definition of the Punctured Channel Information field in the U-SIG for an EHT
2 MU PPDU using non-OFDMA transmissions(#8011)(#2402) (continued)
3
4
5 PPDU Puncturing pattern
6 Cases Field value
bandwidth (RU or MRU Index)
7
8 [1 1 1 1 1 1 1 1]
9 No puncturing 0
(2996-tone RU 1)
10
11
12 [x 1 1 1 1 1 1 1]
1
13 (996+484+242-tone MRU 1)
14
15 [1 x 1 1 1 1 1 1]
2
16 (996+484+242-tone MRU 2)
17
18 [1 1 x 1 1 1 1 1]
3
19 (996+484+242-tone MRU 3)
20
21 [1 1 1 x 1 1 1 1]
22 4
(996+484+242-tone MRU 4)
23 20 MHz puncturing
24 [1 1 1 1 x 1 1 1]
25 5
(996+484+242-tone MRU 5)
26
27
28 [1 1 1 1 1 x 1 1]
160 MHz 6
29 (996+484+242-tone MRU 6)
30
31 [1 1 1 1 1 1 x 1]
7
32 (996+484+242-tone MRU 7)
33
34 [1 1 1 1 1 1 1 x]
8
35 (996+484+242-tone MRU 8)
36
37 [x x 1 1 1 1 1 1]
38 9
(996+484-tone MRU 1)
39
40 [1 1 x x 1 1 1 1]
41 10
(996+484-tone MRU 2)
42
40 MHz puncturing
43
44 [1 1 1 1 x x 1 1]
11
45 (996+484-tone MRU 3)
46
47 [1 1 1 1 1 1 x x]
12
48 (996+484-tone MRU 4)
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 603

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-30—Definition of the Punctured Channel Information field in the U-SIG for an EHT
2 MU PPDU using non-OFDMA transmissions(#8011)(#2402) (continued)
3
4
5 PPDU Puncturing pattern
6 Cases Field value
bandwidth (RU or MRU Index)
7
8 [1 1 1 1 1 1 1 1]
9 No puncturing 0
(4996-tone RU 1)
10
11
12 [x 1 1 1 1 1 1 1]
1
13 (3996+484-tone MRU 1)
14
15 [1 x 1 1 1 1 1 1]
2
16 (3996+484-tone MRU 2)
17
18 [1 1 x 1 1 1 1 1]
3
19 (3996+484-tone MRU 3)
20
21 [1 1 1 x 1 1 1 1]
22 4
(3996+484-tone MRU 4)
23 40 MHz puncturing
24 [1 1 1 1 x 1 1 1]
25 5
(3996+484-tone MRU 5)
26
27
28 [1 1 1 1 1 x 1 1]
320 MHz 6
29 (3996+484-tone MRU 6)
30
31 [1 1 1 1 1 1 x 1]
7
32 (3996+484-tone MRU 7)
33
34 [1 1 1 1 1 1 1 x]
8
35 (3996+484-tone MRU 8)
36
37 [x x 1 1 1 1 1 1]
38 9
(3996-tone MRU 1)
39
40 [1 1 x x 1 1 1 1]
41 10
(3996-tone MRU 2)
42
80 MHz puncturing
43
44 [1 1 1 1 x x 1 1]
11
45 (3996-tone MRU 3)
46
47 [1 1 1 1 1 1 x x]
12
48 (3996-tone MRU 4)
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

604 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-30—Definition of the Punctured Channel Information field in the U-SIG for an EHT
2 MU PPDU using non-OFDMA transmissions(#8011)(#2402) (continued)
3
4
5 PPDU Puncturing pattern
6 Cases Field value
bandwidth (RU or MRU Index)
7
8 [x x x 1 1 1 1 1]
9 13
(2996+484-tone MRU 7)
10
11
12 [x x 1 x 1 1 1 1]
14
13 (2996+484-tone MRU 8)
14
15 [x x 1 1 x 1 1 1]
15
16 (2996+484-tone MRU 9)
17
18 [x x 1 1 1 x 1 1]
16
19 (2996+484-tone MRU 10)
20
21 [x x 1 1 1 1 x 1]
22 17
(2996+484-tone MRU 11)
23
24 [x x 1 1 1 1 1 x]
25 18
(#1616)(#6466)Concurr (2996+484-tone MRU 12)
26
ent 80 MHz and
27
40 MHz puncturing [x 1 1 1 1 1 x x]
28 19
29 (2996+484-tone MRU 1)
30
31 [1 x 1 1 1 1 x x]
20
32 (2996+484-tone MRU 2)
33
34 [1 1 x 1 1 1 x x]
21
35 (2996+484-tone MRU 3)
36
37 [1 1 1 x 1 1 x x]
38 22
(2996+484-tone MRU 4)
39
40 [1 1 1 1 x 1 x x]
41 23
(2996+484-tone MRU 5)
42
43
44 [1 1 1 1 1 x x x]
24
45 (2996+484-tone MRU 6)
46
47
48
(#3181)In the puncturing patterns in the above table, a “1” denotes a nonpunctured subchannel and an “x”
49
50 denotes a punctured subchannel. The puncturing granularity for (#5411)20 MHz, 40 MHz, 80 MHz, and
51 160 MHz PPDU bandwidth is 20 MHz, and the puncturing granularity for 320 MHz PPDU bandwidth is
52 40 MHz. (#1369)Parameters from left to right refer to 20 MHz or 40 MHz subchannels in the order of
53 increasing frequency.
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 605

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The U-SIG field for an EHT TB PPDU contains the fields listed in Table 36-31 (U-SIG field of an EHT TB
2 PPDU). The version independent bits are B0–B19. The rest of the bits are version dependent.
3
4
5
6 Table 36-31—U-SIG field of an EHT TB PPDU
7
8
9 Two parts Number
Bit Field Description
10 of U-SIG of bits
11
12 U-SIG-1 B0–B2 PHY Version 3 (#1349)Differentiate between different PHY
13 Identifier(#3003) clauses.
14 Set to 0 for EHT.
15 Values 1–7 are Validate(#8006).
16 B3–B5 Bandwidth(#4655) 3 Set to 0 for 20 MHz.
17 Set to 1 for 40 MHz.
18 Set to 2 for 80 MHz.
19 Set to 3 for 160 MHz.
20 Set to 4 for 320 MHz-1.
21 Set to 5 for 320 MHz-2.
22 See definition of 320 MHz-1 and 320 MHz-2
23 in 36.3.23.2 (Channelization for 320 MHz
24 channel(#1577))(#2727).
25 Values 6 and 7 are Validate(#8006)(#2794).
26
27 B6 UL/DL 1 Set to 1 to indicate that the PPDU is addressed
28 to the AP.
29 (#5477)A value of 0 is Validate.
30
31 B7–B12 BSS Color 6 An identifier of the BSS.
32 (#4608)Set to the TXVECTOR parameter
33 BSS_COLOR.
34
35 B13–B19 TXOP 7 (#8007)If the TXVECTOR parameter
36 TXOP_DURATION is UNSPECIFIED, set to
37 127 to indicate the absence of duration
38 information.
39 (#3176)(#1359)(#2628)If the TXVECTOR
40 parameter TXOP_DURATION is an integer
41 value, set to a value less than 127 to indicate
42 duration information for NAV setting and
43 protection of the TXOP as follows:
44 If the TXVECTOR parameter TXO-
45 P_DURATION is less than 512, set to
46 2  floor(TXOP_DURATION/8).
47
Otherwise, set to
48
2  floor((TXOP_DURATION – 512)/
49
128) + 1.
50
51 B20–B25 Disregard 6 (#5471)(#8012)(#4607)((#1563)(#2794)Set to
52 the value of the TXVECTOR parameter
53 TB_DISREGARD_IN_USIG1 and treat as
54 Disregard(#7201)(#8006). See Table 9-53d
55 (Mapping from Special User Info field to U-
56 SIG-1 and U-SIG-2 fields in the EHT TB
57 PPDU(#4607)).
58
59
60
61
62
63
64
65

606 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-31—U-SIG field of an EHT TB PPDU (continued)

2
3
4 Two parts Number
Bit Field Description
5 of U-SIG of bits
6
7 U-SIG-2 B0–B1 PPDU Type And 2 (#8012)(#1352)(#4599)(#5820)If the UL/DL
8 Compressed Mode field is set to 1:
9 Set to 0 for a TB PPDU.
10 Values of 2 and 3 are Validate.
11
12 NOTE—A value of 1 indicates a
13 transmission to a single user or an EHT
14 sounding NDP. Refer to Table 36-28 (U-
15 SIG field of an EHT MU PPDU).
16
17 For further clarification on all values of this
18 field, (#3178)refer to Table 36-29
19 (Combination of UL/DL and PPDU Type And
20 Compression Mode field(#1562)(#1352)).
21 (#3291)
22
23 B2 Validate 1 (#5471)(#8012)(#4607)(#1563)(#2794)(#2796
24 )Set to the value of the TXVECTOR
25 parameter TB_VALIDATE_IN_USIG2 and
26 treat as Validate(#7201)(#8006). See Table 9-
27 53d (Mapping from Special User Info field to
28 U-SIG-1 and U-SIG-2 fields in the EHT TB
29 PPDU(#4607)). The default value is 1.
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 607

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-31—U-SIG field of an EHT TB PPDU (continued)

2
3
4 Two parts Number
Bit Field Description
5 of U-SIG of bits
6
7 B3–B6 Spatial Reuse 1 4 (#1618)Indicates whether or not specific
8 spatial reuse modes are allowed in a subband
9 of the PPDU during the transmission of this
10 PPDU, and if PSR spatial reuse is allowed,
11 indicates a value that is used to determine a
12 limit on the transmit power of the PSRT
13 PPDU.
14 If the Bandwidth field indicates 20 MHz
15 or 40 MHz, then this field applies to
16 (#8013)the lowest 20 MHz subband in
17 frequency.
18 If the Bandwidth field indicates 80 MHz,
19 then this field applies to each 20 MHz
20 subchannel of (#8013)the lowest
21 40 MHz subband in frequency within the
22 80 MHz operating band.
23 If the Bandwidth field indicates
24 160 MHz, then this field applies to each
25 20 MHz subchannel of (#8013)the
26 lowest 80 MHz subband in frequency
27 within the 160 MHz operating band.
28 If the Bandwidth field indicates
29 320 MHz-1 or 320 MHz-2, then this
30 field applies to each 20 MHz subchannel
31 of (#8013)the lower 160 MHz subband
32 in frequency within the 320 MHz
33 operating band.
34 Set to the value of the SPATIAL_REUSE(1)
35 parameter of the TXVECTOR, which contains
36 a value from Table 27-23 (Spatial Reuse field
37 encoding for an HE TB PPDU). (#6799)Note
38 that Table 27-23 (Spatial Reuse field encoding
39 for an HE TB PPDU) is also applied for an
40 EHT TB PPDU (see 35.12.2
41 (SPATIAL_REUSE(#6799)) and 35.11 (EHT
42 Spatial reuse operation(#5444))).
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

608 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-31—U-SIG field of an EHT TB PPDU (continued)

2
3
4 Two parts Number
Bit Field Description
5 of U-SIG of bits
6
7 B7–B10 Spatial Reuse 2 4 (#1618)Indicates whether or not specific
8 spatial reuse modes are allowed in a subband
9 of the PPDU during the transmission of this
10 PPDU, and if PSR spatial reuse is allowed,
11 indicates a value that is used to determine a
12 limit on the transmit power of the PSRT
13 PPDU.
14 If the Bandwidth field indicates 20 MHz,
15 this field is set to the same value as the
16 Spatial Reuse 1 field, and
17 Disregard(#8006).
18 If the Bandwidth field indicates 40 MHz,
19 this field applies to (#8013)the upper
20 20 MHz subband in frequency. If
21 operating in the 2.4 GHz band, this field
22 is set to the same value as the Spatial
23 Reuse 1 field.
24 If the Bandwidth field indicates 80 MHz,
25 then this field applies to each 20 MHz
26 subchannel of (#8013)the upper 40 MHz
27 subband in frequency within the 80 MHz
28 operating band.
29 If the Bandwidth field indicates
30 160 MHz, then this field applies to each
31 20 MHz subchannel of (#8013)the upper
32 80 MHz subband in frequency within the
33 160 MHz operating band.
34 If the Bandwidth field indicates
35 320 MHz-1 or 320 MHz-2, then this field
36 applies to each 20 MHz subchannel of
37 (#8013)the upper 160 MHz subband in
38 frequency within the 320 MHz operating
39 band.
40 (#2634)Set to the value of the
41 SPATIAL_REUSE(2) parameter of the
42 TXVECTOR, which contains a value from
43 Table 27-23 (Spatial Reuse field encoding for
44 an HE TB PPDU). (#6799)Note that Table 27-
45 23 (Spatial Reuse field encoding for an HE TB
46 PPDU) is also applied for an EHT TB PPDU
47 (see 35.12.2 (SPATIAL_REUSE(#6799)) and
48 35.11 (EHT Spatial reuse operation(#5444))).
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 609

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-31—U-SIG field of an EHT TB PPDU (continued)

2
3
4 Two parts Number
Bit Field Description
5 of U-SIG of bits
6
7 B11–B15 Disregard 5 (#5471)(#8012)(#4607)(#1563)(#2794)Set to
8 the value of the TXVECTOR parameter
9 TB_DISREGARD_IN_USIG2 and treat as
10 Disregard(#7201)(#8006). See Table 9-53d
11 (Mapping from Special User Info field to U-
12 SIG-1 and U-SIG-2 fields in the EHT TB
13 PPDU(#4607)).
14
15 B16–B19 CRC 4 (#8105)CRC for bits 0–41 of the U-SIG field.
16 Bits 0–41 of the U-SIG field correspond to bits
17 0–25 of U-SIG-1 field followed by bits 0–15
18 of U-SIG-2 field(#5657). The CRC
19 computation uses the same polynomial as that
20 in 27.3.11.7.3 (CRC computation).
21
22 B20–B25 Tail 6 Used to terminate the trellis of the
23 convolutional decoder. Set to 0.
24
25
26
27 The U-SIG field for an ER preamble contains the fields listed in Table 36-32 (U-SIG field of an ER
28 preamble). The version independent bits are B0–B19. The rest of the bits are version dependent(#8105).
29
30
31 Table 36-32—U-SIG field of an ER preamble
32
33
34 Two parts Number
35 Bit Field Description
of U-SIG of bits
36
37 U-SIG-1 B0–B2 PHY Version 3 (#1349)(#3182)(#2802)Differentiate between
38 Identifier(#3002) different PHY clauses
39 Set to 0 for EHT.
40 Values 1–7 are Validate(#8006).
41
42 B3–B5 Bandwidth(#4655) 3 Set to 0 for 20 MHz.
43 Set to 1 for 40 MHz.
44 Set to 2 for 80 MHz.
45 Set to 3 for 160 MHz.
46 Set to 4 for 320 MHz-1.
47 Set to 5 for 320 MHz-2.
48 See definition of 320 MHz-1 and 320 MHz-2
49 in 36.3.23.2 (Channelization for 320 MHz
50 channel(#1577))(#2727).
51 Values 6 and 7 are Validate(#8006)(#2794).
52
53 B6 UL/DL 1 (#2769)Indicates whether the PPDU is sent in
54 UL or DL.
55 (#4608)A value of 1 indicates the PPDU
56 is addressed to an AP.
57 (#4608)A value of 0 indicates that
58 PPDU is addressed to a non-AP STA.
59
60 B7–B12 BSS Color 6 An identifier of the BSS(#4608).
61
62
63
64
65

610 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-32—U-SIG field of an ER preamble (continued)

2
3
4 Two parts Number
Bit Field Description
5 of U-SIG of bits
6
7 B13–B19 TXOP 7 (#8007)Indicates a scaled version of the TXOP
8 duration. The TXOP duration could be derived
9 as follows:
10 If TXOP = 127, the TXOP duration is
11 unspecified.
12
13 If TXOP is an even number, the TXOP
14 duration is 8  TXOP/2 µs.
15 Otherwise, the TXOP duration is
16 512 + 128 (TXOP – 1)/2 µs.
17 B20–B25 Disregard 6 Set to all 1s and treat as
18 Disregard(#7201)(#5412)(#8006)(#1620)(#27
19 94).
20
21 U-SIG-2 B0–B15 Disregard 16 Set to all 1s and treat as
22 Disregard(#7201)(#5412)(#8006)(#1621)(#27
23 94).
24
25 B16–B19 CRC 4 (#8105)CRC for bits 0–41 of the U-SIG field.
26 Bits 0–41 of the U-SIG field correspond to bits
27 0–25 of U-SIG-1 field followed by bits 0–15
28 of U-SIG-2 field(#5657). The CRC
29 computation uses the same polynomial as that
30 in 27.3.11.7.3 (CRC computation).
31
32 B20–B25 Tail 6 Used to terminate the trellis of the
33 convolutional decoder. Set to 0.
34
35
36
37 36.3.12.7.3 Encoding and modulation
38
39 (#2179)(#2804)(#1372)(#1373)For an EHT MU PPDU and EHT TB PPDU, the U-SIG field is composed of
40
two parts, U-SIG-1 and U-SIG-2 fields(#5657), each containing 26 data bits. U-SIG-1 field(#5657) is
41
42 transmitted before U-SIG-2 field(#5657). The data bits of the U-SIG OFDM symbols shall be BCC encoded
43 at (#5413)rate R = 1  2 , interleaved, mapped to a BPSK constellation, and have pilots inserted following
44 the steps described in 17.3.5.6 (Convolutional encoder), 27.3.12.8 (BCC interleavers), 17.3.5.8 (Subcarrier
45
46 modulation mapping), and 17.3.5.9 (Pilot subcarriers), respectively. This process happens on a per-80 MHz
47 (#6434)frequency subblock basis as U-SIG field may have different contents in different 80 MHz
48 (#6434)frequency subblocks, while always having identical content in every 20 MHz subchannel of a given
49 80 MHz (#6434)frequency subblock. For every 80 MHz (#6434)frequency subblock in the EHT PPDU, the
50 first and second half of the stream of 104 (#7208)BPSK constellation points generated by these steps (before
51
52 pilot insertion) is divided into two groups of 52 (#7208)BPSK constellation points, where respectively, the
53 first 52 (#7208)BPSK constellation points form the first OFDM symbol of U-SIG field(#5657) (denoted as
54 U-SIG-sym-1) and the second 52 (#7208)BPSK constellation points form the second OFDM symbol of U-
55 SIG field(#5657) (denoted as U-SIG-sym-2).
56
57
58 (#2635)(#2179)(#2804)(#5414)For U-SIG field(#5657) in 80 MHz frequency subblock i80FS , the
59 i
60 (#7208)BPSK constellation point assigned to the k-th data subcarrier of the n-th symbol is denoted as dk80FS
n .
61 The time domain waveform for the U-SIG field of an EHT MU PPDU, transmitted on transmit chain i TX ,
62
63 shall be as specified in Equation (36-20).
64
65

Copyright © 2022 IEEE. All rights reserved. 611

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1  i TX 
2 r U-SIG  t  = (36-20)
3
4
5
6 1 28
1
7 ----------------------------------------------------------  w T  t – nT SYML   
8 Tone  20MHz n = 0 SYML i   k = – 28
N TX  N U-SIG  -------------------- BW 20MHz
9 N 20MHz
10
11 i TX
12    k – KShift  iBW   BW  D k n iBW + p n + 2 P k exp  j2  k – K Shift  i BW   F Pre-EHT  t – nT SYML – T GI Pre-EHT – T CS   
13
14
15
16 where
17 T SYML is given in Table 36-18 (Timing-related constants).
18
19 K Shift is defined in 36.3.12.5 (L-SIG).(#2635)
20
21  0 k = 0  7  21
D k n i =  i 4 (#4850)(#2635)
22  d Mr20  k  n otherwise
BW BW

23
 k + 28 – 28  k  – 22
24
25
 k + 27 – 20  k  – 8
26 
27 r  k + 26 –6  k  –1
28 M 20  k  = 
29  k + 25 1k6
30  k + 24 8  k  20
31 
 k + 23 22  k  28
32
33 P k and p n are defined in 17.3.5.10 (OFDM modulation).
34
Tone
35 N U-SIG is defined in Table 36-26 (Number of modulated subcarriers and guard interval duration values
36 for EHT PPDU fields).
37
i
38 TX
T CS represents the cyclic shift for transmit chain i TX with a value given in 36.3.12.2.1 (Cyclic shift
39
40 for pre-EHT modulated fields).
41
42 (#2635)The time domain waveform for the U-SIG field of an EHT TB PPDU, transmitted on transmit chain
43 iTX , shall be as specified in Equation (36-21).
44
45
46
47 i 
t =
TX
r U-SIG
48
49 1 28 (36-21)
50 1
51 ----------------------------------------------------------  w T  t – nT SYML  Pre-EHT  
52 Tone  20MHz SYML
i BW   20MHz k = – 28
N TX  N U-SIG  ------------------- -n = 0
53 N 20MHz
54
55 i
   k – KShift  iBW   BW  D k n iBW + p n + 2 P k exp  j2  k – K Shift  i BW   F Pre-EHT  t – nT SYML – T GI Pre-EHT – T CS 
TX

56
57
58
59 where
60
61  Pre-EHT is the power scale factor of the pre-EHT modulated fields within an OFDM symbol for an EHT
62 TB PPDU defined in 36.3.11 (Mathematical description of signals).
63 Other variables in Equation (36-20) and Equation (36-21) are defined in 36.3.10 (Timing-related
64 parameters) and 36.3.11 (Mathematical description of signals)(#4665).
65

612 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#8015)(#1372)(#1373)For an ER preamble, the length of the U-SIG field is four OFDM symbols. The first
2 two OFDM symbols carry the same coded bits, and the last two OFDM symbols also carry the same coded
3
bits. For better frequency diversity, the encoded bits in the first and third OFDM symbols are interleaved,
4
5 while the encoded bits in the second and fourth OFDM symbols are not interleaved. The constellation
6 mapping of the U-SIG field in an ER preamble is the same as that of the HE-SIG-A field in an HE ER SU
7 PPDU, and is shown in Figure 36-30 (Data subcarrier constellation of U-SIG
8 symbols(#8015)(#1372)(#1373)). The QBPSK constellation on the data subcarriers in the second OFDM
9
symbol of the U-SIG field is used to differentiate an ER preamble from an EHT MU PPDU or an EHT TB
10
11 PPDU. The U-SIG field is composed of two parts, i.e., U-SIG-1 and U-SIG-2 fields(#5657), each containing
12 26 data bits. U-SIG-1 is transmitted before U-SIG-2. The data bits of U-SIG-1 and U-SIG-2 fields(#5657)
13 shall be BCC encoded at rate R = 1  2 to form total 104 encoded bits, following the steps described in
14
15 17.3.5.6 (Convolutional encoder). To form the first and third OFDM symbols of the U-SIG field, the
16 encoded bits are further interleaved, mapped to a BPSK constellation, and have pilots inserted, following the
17 steps described in 27.3.12.8 (BCC interleavers), 17.3.5.8 (Subcarrier modulation mapping), and
18 17.3.5.9 (Pilot subcarriers), respectively. The first and second half of the stream of 104 BPSK constellation
19 points generated by these steps (before pilot insertion) is divided into two groups of 52 BPSK constellation
20
21 points, where respectively, the first 52 BPSK constellation points form the first OFDM symbol of the U-SIG
22 field (denoted as U-SIG-sym-1) and the second 52 BPSK constellation points form the third OFDM symbol
23 of the U-SIG field (denoted as U-SIG-sym-2) for the ER preamble. To form the second OFDM symbol of
24 the U-SIG field (denoted as U-SIG-sym-1-R) for the ER preamble, the first 52 encoded bits shall be mapped
25 to a QBPSK constellation without interleaving and have pilots inserted following the steps described in
26
27 17.3.5.8 (Subcarrier modulation mapping) and 17.3.5.9 (Pilot subcarriers), respectively. To form the fourth
28 OFDM symbole of the U-SIG field (denoted as U-SIG-sym-2-R) for the ER preamble, the second 52
29 encoded bits shall be mapped to a BPSK constellation without interleaving and have pilots inserted
30 following the steps described in 17.3.5.8 (Subcarrier modulation mapping) and 17.3.5.9 (Pilot subcarriers),
31 respectively. This process happens on a per-80 MHz frequency subblock basis as the U-SIG field may have
32
33 different contents in different 80 MHz frequency subblocks, while always having identical content in every
34 20 MHz subchannel of a given 80 MHz frequency subblock.
35
36
37 EHT MU PPDU U-SIG-sym-1 U-SIG-sym-2
38 and EHT TB PPDU
39 Q Q
40
41
42 I I
-1 +1 -1 +1
43
44
45
46 ER Preamble U-SIG-sym-1 U-SIG-sym-1-R U-SIG-sym-2 U-SIG-sym-2-R
47
48 Q Q Q Q
49
50 +1
51 I I I I
52 -1 +1 -1 +1 -1 +1
-1
53
54
55 Figure 36-30—Data subcarrier constellation of U-SIG symbols(#8015)(#1372)(#1373)
56
57
58 (#3047)(#2636)The time domain waveform for the U-SIG field of an EHT ER preamble, transmitted on
59
60 transmit chain iTX , shall be as specified in Equation (36-22)(#2638)(#5005).
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 613

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2  i TX 
r U-SIG  t  = (36-22)
3
4
5
6 3
1
7 ----------------------------------------------------------  w T  t – nT SYML 
8 Tone  20MHz SYML

9 N TX  N U-SIG  ------------------- -n = 0
N 20MHz
10 28
11
12     k – KShift  iBW  BW  R n D k n i
BW
+ pn + 2 Pk 
13 i BW   20MHz k = – 28
14
15
16 i TX
17  exp  j2  k – K Shift  i BW   F Pre-EHT  t – nT SYML – T GI Pre-EHT – T CS   
18
19
20
21 where
22 Rn is a phase rotation vector defined as  1 j 1 1  .
23
24 Other variables in Equation (36-22) are defined in 36.3.10 (Timing-related parameters) and 36.3.11
25 (Mathematical description of signals)(#4665).
26
27 36.3.12.8 EHT-SIG
28
29
30 36.3.12.8.1 General
31
32 (#1374)(#3184)(#8018)The EHT-SIG field provides additional signaling to the U-SIG field for STAs to
33 interpret an EHT MU PPDU. In an EHT MU PPDU, the EHT-SIG field contains U-SIG overflow bits that
34
are common to all users. The EHT-SIG field further contains resource allocation information to allow the
35
36 STAs to look up the corresponding resources to be used in the EHT modulated fields of the PPDU. The
37 integer fields of the EHT-SIG field are transmitted in unsigned binary format, LSB first, where the LSB is in
38 the lowest numbered bit position.
39
40
36.3.12.8.2 EHT-SIG content channels
41
42
43 (#1379)(#2172)(#2732)(#2681)The EHT-SIG field of a 20 MHz EHT MU PPDU contains one EHT-SIG
44 content channel. For OFDMA transmission and for non-OFDMA transmission to multiple users, the EHT-
45 SIG field of an EHT MU PPDU that is 40 MHz or 80 MHz contains two EHT-SIG content channels. For
46
OFDMA transmission and for non-OFDMA transmission to multiple users, the EHT-SIG field of an MU
47
48 PPDU that is 160 MHz or wider contains two EHT-SIG content channels per 80 MHz. The EHT-SIG content
49 channels per 80 MHz are allowed to carry different information when EHT MU PPDU bandwidth for
50 OFDMA transmission is wider than 80 MHz. The EHT-SIG field of an EHT MU PPDU sent to a single user
51 and the EHT-SIG field of an EHT sounding NDP contains one EHT-SIG content channel and it is duplicated
52
in each nonpunctured 20 MHz(#8019) when the EHT PPDU is equal to or wider than 40 MHz(#1380).
53
54
55 (#1993)The EHT-SIG content channel format is shown in Figure 36-31 (EHT-SIG content channel format
56 for OFDMA transmission if bandwidth is 20/40/80 MHz(#5485)(#3295)(#1383)(#1384)(#1390)),
57 Figure 36-32 (EHT-SIG content channel format for OFDMA transmission if bandwidth is
58
160 MHz(#5485)(#3295)(#1383)(#1384)(#1390)), Figure 36-33 (EHT-SIG content channel format for
59
60 OFDMA transmission if bandwidth is 320 MHz(#5485)(#3295)(#1383)(#1384)(#1390)), Figure 36-34
61 (EHT-SIG content channel format for non-OFDMA transmission to a single user(#5485)(#1390)(#2174)),
62 Figure 36-35 (EHT-SIG content channel format for EHT sounding NDP(#5485)(#1390)(#2174)), and
63 Figure 36-36 (EHT-SIG content channel format for non-OFDMA transmission to multiple
64
users(#5485)(#1390)(#1393)(#2174)(#3159)). For an EHT MU PPDU except for an EHT sounding
65

614 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 NDP(#1382), each EHT-SIG content channel(#8020) consists of a Common field followed by a User
2 Specific field. For an EHT sounding NDP, the User Specific field is not present and the EHT-SIG content
3
channel consists of only a Common field.
4
5
EHT-SIG content channel
6
7
8
Common field
9 User Specific field
10
11
U-SIG overflow + 1 or 2 RU
12 2 User fields + CRC 2 User fields + CRC 1 or 2 User fields Padding
Allocation-1 subfields + CRC + ···
13 Tail
+ Tail + Tail + CRC + Tail (if present)
14 The common encoding block 1st user 2nd user Final user
15 encoding block encoding block encoding block
16 Figure 36-31—EHT-SIG content channel format for OFDMA transmission if bandwidth is
17
18
20/40/80 MHz(#5485)(#3295)(#1383)(#1384)(#1390)
19
20
21
22 EHT-SIG content channel
23
24
25 Common field User Specific field
26
27
28 U-SIG overflow + 2 RU 2 RU Allocation-2
2 User fields + CRC 2 User fields + CRC 1 or 2 User fields Padding
29 Allocation-1 subfields
+ CRC + Tail
subfields + CRC +
+ Tail + Tail
···
+ CRC + Tail (if present)
Tail
30 1st common 2nd common 1st user 2nd user Final user
31 encoding block encoding block encoding block encoding block encoding block
32
33 Figure 36-32—EHT-SIG content channel format for OFDMA transmission if bandwidth is
34 160 MHz(#5485)(#3295)(#1383)(#1384)(#1390)
35
36
37
38
39 EHT-SIG content channel
40
41
42 Common field User Specific field
43
44
45 U-SIG Overflow + 2 6 RU Allocation-2
2 User fields + CRC 2 User fields + CRC 1 or 2 User fields Padding
46 RU Allocation-1 subfields + CRC +
+ Tail + Tail
···
+ CRC + Tail (if present)
subfields + CRC + Tail Tail
47
1st common 2nd common 1st user 2nd user Final User
48 encoding block encoding block encoding block encoding block encoding block
49
50 Figure 36-33—EHT-SIG content channel format for OFDMA transmission if bandwidth is
51 320 MHz(#5485)(#3295)(#1383)(#1384)(#1390)
52
53
54 For OFDMA transmission, the Common field of an EHT-SIG content channel contains information
55 regarding the resource unit allocation such as the RU assignment to be used in the EHT modulated fields of
56 the PPDU, the RUs allocated for MU-MIMO and the number of users in MU-MIMO allocations.
57
58 (#3186)The Common field for OFDMA transmission is defined in 36.3.12.8.3 (Common field for OFDMA
59 transmission). (#5485)The Common field is organized into one or two common encoding blocks.
60
61 (#1391)(#2808)In non-OFDMA transmission, the Common field of the EHT-SIG content channel does not
62 contain the (#6152)RU Allocation subfield. For non-OFDMA transmission except for EHT sounding NDP,
63
64 the Common field of the EHT-SIG content channel is encoded together with the first User field and
65

Copyright © 2022 IEEE. All rights reserved. 615

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#5485)(#1390)this encoding block contains a CRC and Tail(#4853), referred to as a common encoding
2 block.
3
4
5 (#1391)For EHT sounding NDP, the Common field of the EHT-SIG content channel consists of U-SIG
6 overflow information, CRC, and Tail. The Common field for non-OFDMA transmission is defined in
7 36.3.12.8.4 (Common field for non-OFDMA transmission). (#5485)The Common field is organized into
8 one common encoding block.
9
10
11 The union of the User Specific fields in the EHT-SIG content channels contains information for all users in
12 the PPDU on how to decode their payload. As shown in Figure 36-31 (EHT-SIG content channel format for
13 OFDMA transmission if bandwidth is 20/40/80 MHz(#5485)(#3295)(#1383)(#1384)(#1390)), Figure 36-32
14 (EHT-SIG content channel format for OFDMA transmission if bandwidth is
15
160 MHz(#5485)(#3295)(#1383)(#1384)(#1390)), and Figure 36-33 (EHT-SIG content channel format for
16
17 OFDMA transmission if bandwidth is 320 MHz(#5485)(#3295)(#1383)(#1384)(#1390)), the User Specific
18 field is organized into (#5485)user encoding blocks that in turn contain User fields in OFDMA transmission.
19 (#1393)(#1394)As shown in Figure 36-34 (EHT-SIG content channel format for non-OFDMA transmission
20 to a single user(#5485)(#1390)(#2174)), in the non-OFDMA transmission to single user, the User Specific
21
field contains one User field but there exists (#5485)no user encoding block. As shown in Figure 36-35
22
23 (EHT-SIG content channel format for EHT sounding NDP(#5485)(#1390)(#2174)), EHT-SIG content
24 channel for EHT sounding NDP does not contain the User Specific field. (#4668)As shown in Figure 36-36
25 (EHT-SIG content channel format for non-OFDMA transmission to multiple
26 users(#5485)(#1390)(#1393)(#2174)(#3159)), in the non-OFDMA transmission to multiple users, the User
27
Specific field is organized into (#5485)user encoding blocks that in turn contain User fields except for the
28
29 first User field. (#2734)The contents of the User Specific field are described in 36.3.12.8.5 (User Specific
30 field).
31
32 EHT-SIG content channel
33
34
35 Common field User Specific field
36
37
38 U-SIG Overflow +
39 1 User field + CRC Padding
Number of Non-
40 OFDMA Users + Tail (if present)
41 The common encoding block
42
43 Figure 36-34—EHT-SIG content channel format for non-OFDMA transmission to a single
44 user(#5485)(#1390)(#2174)
45
46
47
48
49 EHT-SIG content
50 channel
51
52 Common field
53
54
55
56 U-SIG Overflow + CRC +
Tail
57
58 The common
59 encoding block
60 Figure 36-35—EHT-SIG content channel format for EHT sounding
61
NDP(#5485)(#1390)(#2174)
62
63
64
65

616 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2
3 EHT-SIG content channel
4
5
6 Common field User Specific field
7
8 U-SIG Overflow +
9 1 User field + CRC 2 User fields + CRC 2 User fields + CRC 1 or 2 User fields Padding
Number of Non- ···
+ Tail + Tail + Tail + CRC + Tail (if present)
10 OFDMA Users
The common encoding block user encoding block user encoding block Final user
11 (if present) (if present) encoding block
12 (if present)
13
14 Figure 36-36—EHT-SIG content channel format for non-OFDMA transmission to multiple
15 users(#5485)(#1390)(#1393)(#2174)(#3159)
16
17
18 (#3055)(#7212)Examples of EHT-SIG are shown in Annex Z.
19
20 36.3.12.8.3 Common field for OFDMA transmission
21
22
23 The Common field for OFDMA transmission is defined in Table 36-33 (Common field for OFDMA
24 transmission).
25
26
27 Table 36-33—Common field for OFDMA transmission
28
29
30 Number of Number of
31 Bit Subfield subfields bits per Description
32 (#1392) subfield
33
34 B0–B3 Spatial Reuse 1 4 Indicates whether or not spatial reuse modes
35 are allowed during the transmission of this
36 PPDU.
37 Set to a value from Table 27-22 (Spatial
38 Reuse field encoding for an HE SU PPDU,
39 HE ER PPDU, and HE MU PPDU). Note
40 that Table 27-22 (Spatial Reuse field
41 encoding for an HE SU PPDU, HE ER
42 PPDU, and HE MU PPDU) also applies to
43 EHT MU PPDU. See 35.12.2
44 (SPATIAL_REUSE(#6799)) and 35.11
45 (EHT Spatial reuse
46 operation(#5444))(#4671).
47
48
B4–B5 GI+LTF Size 1 2 Indicates the GI duration and EHT-LTF size:
49
Set to 0 to indicate 2 LTF + 0.8 µs GI.
50
Set to 1 to indicate 2 LTF + 1.6 µs GI.
51
Set to 2 to indicate 4 LTF + 0.8 µs GI.
52
Set to 3 to indicate 4 LTF + 3.2 µs GI.
53
(#3188)
54
55
56 B6–B8 Number Of EHT- 1 3 Indicate the number of EHT-LTF symbols:
57 LTF Symbols Set to 0 to indicate 1 EHT-LTF symbol.
58 Set to 1 to indicate 2 EHT-LTF symbols.
59 Set to 2 to indicate 4 EHT-LTF symbols.
60 Set to 3 to indicate 6 EHT-LTF symbols.
61 Set to 4 to indicate 8 EHT-LTF symbols.
62 Other values are Validate if
63 dot11EHTBaseLineFeaturesImplementedOn
64 ly equals true.(#2735)(#3188)(#5416)
65

Copyright © 2022 IEEE. All rights reserved. 617

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-33—Common field for OFDMA transmission (continued)

2
3
4 Number of Number of
5 Bit Subfield subfields bits per Description
6 (#1392) subfield
7
8 B9 LDPC Extra Symbol 1 1 Indicates the presence of the LDPC extra
9 Segment symbol segment:
10 Set to 1 if an LDPC extra symbol segment is
11 present.
12 Set to 0 if an LDPC extra symbol segment is
13 not present.(#3188)
14
15 B10–B11 Pre-FEC Padding 1 2 Indicates the pre-FEC padding factor:
16 Factor Set to 0 to indicate a pre-FEC padding factor
17 of 4.
18 Set to 1 to indicate a pre-FEC padding factor
19 of 1.
20 Set to 2 to indicate a pre-FEC padding factor
21 of 2.
22 Set to 3 to indicate a pre-FEC padding factor
23 of 3.(#3188)
24
25
26 B12 PE Disambiguity 1 1 Indicates PE disambiguity as defined in
27 36.3.14 (Packet extension).(#3188)
28
29 B13–B16 Disregard 1 4 Set to all 1s. Disregard if
30 dot11EHTBaseLineFeaturesImplementedOn
31 ly equals true(#5416).
32
33 B17– RU Allocation-1 N 9 (#8110)N RU Allocation-1 subfields are
34 B16+9N present in an EHT-SIG content channel,
35 where:
36 N is set to 1 if the Bandwidth field in the U-
37 SIG field is equal to 0 or 1.
38 N is set to 2 if the Bandwidth field in the U-
39 SIG field is equal to 2, 3, 4, or 5(#3189).
40
41 (#1394)(#1395)(#1279)(#8110)Each RU
42 Allocation-1 subfield in an EHT-SIG content
43 channel corresponding to a 20 MHz
44 frequency subchannel indicates the RU or
45 MRU assignment, including the size of the
46 RU(s) or MRU(s) and their placement in the
47 frequency domain, to be used in the EHT
48 modulated fields of the EHT MU PPDU in
49 the frequency domain, where the subcarrier
50 indices of the RU(s) meet the conditions in
51 Table 36-35 (RUs associated with each RU
52 Allocation subfield for each EHT-SIG
53 content channel and PPDU bandwidth). Each
54 RU Allocation-1 subfield also indicates
55 information needed to compute the number
56 of users allocated to each of these RU(s) or
57 MRU(s).
58
59 B17+9N CRC(#2683) 1 4 The CRC is calculated over bits 0 to 16+9N.
60 –B20+9N The CRC computation uses the same
61 polynomial as that in 27.3.11.7.3 (CRC
62 computation).(#2683)
63
64
65

618 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-33—Common field for OFDMA transmission (continued)

2
3
4 Number of Number of
5 Bit Subfield subfields bits per Description
6 (#1392) subfield
7
8 B21+9N Tail(#2683) 1 6 Used to terminate the trellis of the
9 –B26+9N convolutional decoder. Set to 0.
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 619

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-33—Common field for OFDMA transmission (continued)

2
3
4 Number of Number of
5 Bit Subfield subfields bits per Description
6 (#1392) subfield
7
8 B27+9N RU Allocation-2 M 9 (#2810)(#5528)(#8110)M RU Allocation-2
9 – subfields are present in an EHT-SIG content
10 B26+9N+9M channel if the Bandwidth subfield in the U-
11 SIG field indicates a 160 MHz, 320 MHz-1,
12 or 320 MHz-2 EHT MU PPDU where M is
13 equal to 2 or 6 as follows:
14 M is set to 2 if the Bandwidth field in the U-
15 SIG field is 3.
16 M is set to 6 if the Bandwidth field in the U-
17 SIG field is 4 or 5(#3189).
18 The subfields are not present otherwise (i.e.,
19 M is equal to 0).
20
21 (#1394)(#1395)(#1279)(#8110)Each RU
22 Allocation-2 subfield in an EHT-SIG content
23 channel corresponding to a 20 MHz
24 frequency subchannel indicates the RU or
25 MRU assignment, including the size of the
26 RU(s) or MRU(s) and their placement in the
27 frequency domain, to be used in the EHT
28 modulated fields of the EHT MU PPDU in
29 the frequency domain, where the subcarrier
30 indices of the RU(s) meet the conditions in
31 Table 36-35 (RUs associated with each RU
32 Allocation subfield for each EHT-SIG
33 content channel and PPDU bandwidth). Each
34 RU Allocation-2 subfield also indicates
35 information needed to compute the number
36 of users allocated to each of these RU(s) or
37 MRU(s).
38
39 B27+9N+9M CRC(#2683) 0 or 1 4 (#2683)The CRC subfield is present if the
40 – Bandwidth subfield in the U-SIG field
41 B30+9N+9M indicates a 160 MHz, 320 MHz-1, or
42 320 MHz-2 EHT MU PPDU and not present
43 otherwise.
44
45 (#1397)(#2683)If present, the CRC is
46 calculated over bits 27+9N to 26+9N+9M.
47 The CRC computation uses the same
48 polynomial as that in 27.3.11.7.3 (CRC
49 computation).
50
51 (#2683)NOTE—N=2 when the CRC subfield
52 exists.
53
54
55
56
57
58
59
60
61
62
63
64
65

620 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-33—Common field for OFDMA transmission (continued)

2
3
4 Number of Number of
5 Bit Subfield subfields bits per Description
6 (#1392) subfield
7
8 B31+9N+9M Tail(#2683) 0 or 1 6 (#2683)The Tail subfield is present if the
9 – Bandwidth subfield in the U-SIG field
10 B36+9N+9M indicates a 160 MHz, 320 MHz-1, or
11 320 MHz-2 EHT MU PPDU and not present
12 otherwise.
13
14 (#2683)If present, then it is used to terminate
15 the trellis of the convolutional decoder. Set to
16 0.
17
18 (#2683)NOTE—N=2 when the Tail subfield
19 exists.
20
21
22
23 B0–B16 of Table 36-33 (Common field for OFDMA transmission) are U-SIG Overflow bits for OFDMA
24 transmission and are duplicated in each content channel.
25
26 (#3295)B0–B26+9N of Table 36-33 (Common field for OFDMA transmission) composes the
27
(#5485)(#1390)first common encoding block. B27+9N–B36+9N+9M composes the second common
28
29 encoding block(#1390) if present(#7213).
30
31 (#3060)If a single RU/MRU in an 80 MHz PPDU overlaps more than one of the subcarrier ranges [–500: –
32 259], [–253: –12], [12: 253], or [259: 500], the corresponding RU Allocation subfields in the respective
33
content channels shall all refer to the same RU/MRU.
34
35
36 (#3060)If a single RU/MRU in a 160 MHz PPDU overlaps more than one of the subcarrier ranges [–1012: –
37 771], [–765: –524], [–500: –259], [–253: –12], [12: 253], [259: 500], [524: 765], or [771: 1012], the
38 corresponding RU Allocation subfields in the respective content channels shall all refer to the same
39
RU/MRU.
40
41
42 (#3060)If a single RU/MRU in a 320 MHz PPDU overlaps more than one of the subcarrier ranges [–2036: –
43 1795], [–1789: –1548], [–1524: –1283], [–1277: –1036], [–1012: –771], [–765: –524], [–500: –259], [–253:
44 –12], [12: 253], [259: 500], [524: 765], [771: 1012], [1036: 1277], [1283: 1524], [1548: 1789], or [1795:
45
2036], the corresponding RU Allocation subfields in the respective content channels shall all refer to the
46
47 same RU/MRU.
48
49 (#3190)(#6467)An RU Allocation subfield shall not indicate an RU or MRU which (#8022)occupies all
50 nonpunctured 20 MHz channels within the PPDU bandwidth.
51
52 (#3301)(#3190)NOTE—For example, a 4996-tone RU cannot be indicated by the RU Allocation subfield. A 996-tone
53 RU cannot be indicated by the RU Allocation subfield in an 80 MHz EHT MU PPDU. A 3996+484-tone RU cannot be
54 indicated in a 320 MHz EHT MU PPDU with 40 MHz puncturing indicated in the U-SIG field(#5657).
55
56 (#1398)(#2404)A 3-tone MRU is referred to by seven RU Allocation subfields per EHT-SIG
57
content channel, for both EHT-SIG content channels. The seven RU Allocation subfields per EHT-SIG
58
59 content channel are labeled from the first RU Allocation subfield to the seventh RU Allocation subfield in an
60 increasing frequency order.
61
62 (#1398)(#2405)A 3-tone MRU is referred to by six RU Allocation subfields per EHT-SIG content
63
channel, for both EHT-SIG content channels. The six RU Allocation subfields per EHT-SIG content channel
64
65

Copyright © 2022 IEEE. All rights reserved. 621

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 are labeled from the first RU Allocation subfield to the sixth RU Allocation subfield in an increasing
2 frequency order.
3
4
5 (#1398)(#2406)A 2-tone MRU is referred to by five RU Allocation subfields per EHT-SIG
6 content channel, for both EHT-SIG content channels. The five RU Allocation subfields per EHT-SIG
7 content channel are labeled from the first RU Allocation subfield to the fifth RU Allocation subfield in an
8 increasing frequency order.
9
10
11 (#1398)A 2-tone RU is referred to by four consecutive RU Allocation subfields per EHT-SIG content
12 channel, for both EHT-SIG content channels. The four RU Allocation subfields per EHT-SIG content
13 channel are labeled from the first RU Allocation subfield to the fourth RU Allocation subfield in an
14 increasing frequency order.
15
16
17 (#1398)(#2407)A 996484-tone MRU is referred to by three RU Allocation subfields per EHT-SIG content
18 channel, for both EHT-SIG content channels. The three RU Allocation subfields per EHT-SIG content
19 channel are labeled from the first RU Allocation subfield to the third RU Allocation subfield in an increasing
20 frequency order.
21
22
23 (#1398)A 996-tone RU is referred to by two consecutive RU Allocation subfields per EHT-SIG content
24 channel, for both EHT-SIG content channels. The two consecutive RU Allocation subfields per EHT-SIG
25 content channel are labeled the first RU Allocation subfield and the second RU Allocation subfield in an
26 increasing frequency order.
27
28
29 (#1398)(#2408)A 484242-tone MRU is referred to by two RU allocation subfields in the EHT-SIG content
30 channel that overlaps with the 242-tone RU and one RU Allocation subfield(#6153) in the other EHT-SIG
31 content channel. The two RU Allocation subfields in the EHT-SIG content channel (with two RU Allocation
32 subfields) are labeled the first RU Allocation subfield and the second RU Allocation subfield in an
33
increasing frequency order.
34
35
36 (#3056)A 484-tone RU is referred to by a single RU Allocation subfield per EHT-SIG content channel, for
37 both EHT-SIG content channels.
38
39
(#2409)RU/MRU of size smaller than or equal to 242-tone RU is referred to by a single RU Allocation
40
41 subfield in a single EHT-SIG content channel.
42
43 (#5420)The mapping from the 9-bit RU Allocation subfield to the RU assignment and the number of User
44 fields per RU or MRU contributed to the User Specific field in the same EHT-SIG content channel as the RU
45
Allocation subfield is defined in Table 36-34 (RU Allocation subfield).
46
47
48
49 Table 36-34—RU Allocation subfield
50
51
52 RU Allocation subfield
Number
53 (B8 B7 B6 B5 B4 B3 B2 1 2 3 4 5 6 7 8 9
of entries
54 B1 B0)
55
56 0 (000000000) 26 26 26 26 26 26 26 26 26 1
57
58 1 (000000001) 26 26 26 26 26 26 26 52 1
59 2 (000000010) 26 26 26 26 26 52 26 26 1
60
61 3 (000000011) 26 26 26 26 26 52 52 1
62
63 4 (000000100) 26 26 52 26 26 26 26 26 1
64
65

622 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-34—RU Allocation subfield (continued)

2
3
4 RU Allocation subfield
Number
5 (B8 B7 B6 B5 B4 B3 B2 1 2 3 4 5 6 7 8 9
of entries
6 B1 B0)
7
8 5 (000000101) 26 26 52 26 26 26 52 1
9
10 6 (000000110) 26 26 52 26 52 26 26 1
11
12 7 (000000111) 26 26 52 26 52 52 1
13 8 (000001000) 52 26 26 26 26 26 26 26 1
14
15 9 (000001001) 52 26 26 26 26 26 52 1
16
17 10 (000001010) 52 26 26 26 52 26 26 1
18
19 11 (000001011) 52 26 26 26 52 52 1
20
21 12 (000001100) 52 52 26 26 26 26 26 1
22 13 (000001101) 52 52 26 26 26 52 1
23
24 14 (000001110) 52 52 26 52 26 26 1
25
26 15 (000001111) 52 52 26 52 52 1
27
28 16 (000010000) 26 26 26 26 26 106 1
29
30 17 (000010001) 26 26 52 26 106 1
31 18 (000010010) 52 26 26 26 106 1
32
33 19 (000010011) 52 52 26 106 1
34
35 20 (000010100) 106 26 26 26 26 26 1
36
37 21 (000010101) 106 26 26 26 52 1
38
39 22 (000010110) 106 26 52 26 26 1
40 23 (000010111) 106 26 52 52 1
41
42 24 (000011000) 52 52 — 52 52 1
43
44 25 (000011001) 106 26 106 1
45
46 26 (000011010) Punctured 242-tone RU 1
47
48 27 (000011011) Unassigned 242-tone RU 1
49 242-tone RU; contributes zero User fields to the User Specific field in
50 28 (000011100) the same EHT-SIG content channel as this RU Allocation subfield and 1
51 is not unallocated.
52
53 484-tone RU; contributes zero User fields to the User Specific field in
54 29 (000011101) the same EHT-SIG content channel as this RU Allocation subfield and 1
55 is not unallocated.
56
57 996-tone RU; contributes zero User fields to the User Specific field in
58 30 (000011110) the same EHT-SIG content channel as this RU Allocation subfield and 1
59 is not unallocated.
60
61 31 (000011111) Validate 1
62
63 32 (000100000) 26 26 26 26 26 52+26 26 1
64 33 (000100001) 26 26 52 26 52+26 26 1
65

Copyright © 2022 IEEE. All rights reserved. 623

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-34—RU Allocation subfield (continued)

2
3
4 RU Allocation subfield
Number
5 (B8 B7 B6 B5 B4 B3 B2 1 2 3 4 5 6 7 8 9
of entries
6 B1 B0)
7
8 34 (000100010) 52 26 26 26 52+26 26 1
9
10 35 (000100011) 52 52 26 52+26 26 1
11
12 36 (000100100) 26 52+26 26 26 26 26 26 1
13 37 (000100101) 26 52+26 26 26 26 52 1
14
15 38 (000100110) 26 52+26 26 52 26 26 1
16
17 39 (000100111) 26 52+26 26 52 52 1
18
19 40 (000101000) 26 26 26 26 106+26 1
20
21 41 (000101001) 26 26 52 106+26 1
22 42 (000101010) 52 26 26 106+26 1
23
24 43 (000101011) 52 52 106+26 1
25
26 44 (000101100) 106+26 26 26 26 26 1
27
28 45 (000101101) 106+26 26 26 52 1
29
30 46 (000101110) 106+26 52 26 26 1
31 47 (000101111) 106+26 52 52 1
32
33 48 (000110000) 106+26 106 1
34
35 49 (000110001) 106+26 52+26 26 1
36
37 50 (000110010) 106 106+26 1
38
39 51 (000110011) 26 52+26 106+26 1
40 52 (000110100) 106 26 52+26 26 1
41
42 53 (000110101) 26 52+26 26 106 1
43
44 54 (000110110) 26 52+26 26 52+26 26 1
45
46 55 (000110111) 52 52+26 52 52 1
47
48 56–63
Validate 8
49 (000111000–000111111)
50 64–71 (001000y2y1y0) 242 8
51
52 72–79 (001001y2y1y0) 484 8
53
54 80–87 (001010y2y1y0) 996 8
55
56 88–95 (001011y2y1y0) 2996 8
57
58 96–103 (001100y2y1y0) (#1400)(#4672)MRU of []-242-484, (#7217)specifically 484+242-tone 8
59 MRU-1, 5, 9, and 13 within the first, second, third, and fourth 80 MHz
60 subblock in increasing frequency order, respectively
61 (#1400)(#4672)MRU of 242-[]-484, (#7217)specifically 484+242-tone
62 104–111 (001101y2y1y0) MRU-2, 6, 10, and 14 within the first, second, third, and fourth 80 MHz 8
63 subblock in increasing frequency order, respectively
64
65

624 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-34—RU Allocation subfield (continued)

2
3
4 RU Allocation subfield
Number
5 (B8 B7 B6 B5 B4 B3 B2 1 2 3 4 5 6 7 8 9
of entries
6 B1 B0)
7
8 112–119 (001110y2y1y0) (#1400)(#4672)MRU of 484-[]-242, (#7217)specifically 484+242-tone 8
9 MRU-3, 7, 11, and 15 within the first, second, third, and fourth 80 MHz
10 subblock in increasing frequency order, respectively
11
12 120–127 (001111y2y1y0) (#1400)(#4672)MRU of 484-242-[], (#7217)specifically 484+242-tone 8
13 MRU-4, 8, 12, and 16 within the first, second, third, and fourth 80 MHz
14 subblock in increasing frequency order, respectively
15
16 128–135 (010000y2y1y0) (#1400)(#4672)MRU of []-484-996, (#7217)specifically 996+484-tone 8
17 MRU-1 and 5 within the first and second 160 MHz subblock in
18 increasing frequency order, respectively
19 136–143 (010001y2y1y0) (#1400)(#4672)MRU of 484-[]-996, (#7217)specifically 996+484-tone 8
20 MRU-2 and 6 within the first and second 160 MHz subblock in
21 increasing frequency order, respectively
22
23 144–151 (010010y2y1y0) (#1400)(#4672)MRU of 996-[]-484, (#7217)specifically 996+484-tone 8
24 MRU-3 and 7 within the first and second 160 MHz subblock in
25 increasing frequency order, respectively
26
27 152–159 (010011y2y1y0) (#1400)(#4672)MRU of 996-484-[], (#7217)specifically 996+484-tone 8
28 MRU-4 and 8 within the first and second 160 MHz subblock in
29 increasing frequency order, respectively
30
31 160–167 (010100y2y1y0) (#1400)MRU of []-996-996-996, (#7217)specifically 3996-tone 8
32 MRU-1
33
34 168–175 (010101y2y1y0) (#1400)MRU of 996-[]-996-996, (#7217)specifically 3996-tone 8
35 MRU-2
36 176–183 (010110y2y1y0) (#1400)MRU of 996-996-[]-996, (#7217)specifically 3996-tone 8
37 MRU-3
38
39 184–191 (010111y2y1y0) (#1400)MRU of 996-996-996-[], (#7217)specifically 3996-tone 8
40 MRU-4
41
42 192–199 (011000y2y1y0) (#1400)MRU of []-484-996-996-996, (#7217)specifically 3996+484- 8
43 tone MRU-1
44
45 200–207 (011001y2y1y0) (#1400)MRU of 484-[]-996-996-996, (#7217)specifically 3996+484- 8
46 tone MRU-2
47
48 208–215 (011010y2y1y0) (#1400)MRU of 996-[]-484-996-996, (#7217)specifically 3996+484- 8
49 tone MRU-3
50 216–223 (011011y2y1y0) (#1400)MRU of 996-484-[]-996-996, (#7217)specifically 3996+484- 8
51 tone MRU-4
52
53 224–231 (011100y2y1y0) (#1400)MRU of 996-996-[]-484-996, (#7217)specifically 3996+484- 8
54 tone MRU-5
55
56 232–239 (011101y2y1y0) (#1400)MRU of 996-996-484-[]-996, (#7217)specifically 3996+484- 8
57 tone MRU-6
58
59 240–247 (011110y2y1y0) (#1400)MRU of 996-996-996-[]-484, (#7217)specifically 3996+484- 8
60 tone MRU-7
61
62 248–255 (011111y2y1y0) (#1400)MRU of 996-996-996-484-[], (#7217)specifically 3996+484- 8
63 tone MRU-8
64
65

Copyright © 2022 IEEE. All rights reserved. 625

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-34—RU Allocation subfield (continued)

2
3
4 RU Allocation subfield
Number
5 (B8 B7 B6 B5 B4 B3 B2 1 2 3 4 5 6 7 8 9
of entries
6 B1 B0)
7
8 256–263 (100000y2y1y0) (#1400)(#4672)MRU of []-484-996-996, (#7217)specifically 8
9 2996+484-tone MRU-1 and 7 within the 240 MHz subblock
10 composed of the first, second, and third 80 MHz subblock and the
11 240 MHz subblock composed of the second, third, and fourth 80 MHz
12 subblock in increasing frequency order, respectively
13
14 264–271 (100001y2y1y0) (#1400)(#4672)MRU of 484-[]-996-996, (#7217)specifically 8
15 2996+484-tone MRU-2 and 8 within the 240 MHz subblock
16 composed of the first, second, and third 80 MHz subblock and the
17 240 MHz subblock composed of the second, third, and fourth 80 MHz
18 subblock in increasing frequency order, respectively
19
20 272–279 (100010y2y1y0) (#1400)(#4672)MRU of 996-[]-484-996, (#7217)specifically 8
21 2996+484-tone MRU-3 and 9 within the 240 MHz subblock
22 composed of the first, second, and third 80 MHz subblock and the
23 240 MHz subblock composed of the second, third, and fourth 80 MHz
24 subblock in increasing frequency order, respectively
25 280–287 (100011y2y1y0) (#1400)(#4672)MRU of 996-484-[]-996, (#7217)specifically 8
26 2996+484-tone MRU-4 and 10 within the 240 MHz subblock
27 composed of the first, second, and third 80 MHz subblock and the
28 240 MHz subblock composed of the second, third, and fourth 80 MHz
29 subblock in increasing frequency order, respectively
30
31 288–295 (100100y2y1y0) (#1400)(#4672)MRU of 996-996-[]-484, (#7217)specifically 8
32 2996+484-tone MRU-5 and 11 within the 240 MHz subblock
33 composed of the first, second, and third 80 MHz subblock and the
34 240 MHz subblock composed of the second, third, and fourth 80 MHz
35 subblock in increasing frequency order, respectively
36
37 296–303 (100101y2y1y0) (#1400)(#4672)MRU of 996-996-484-[], (#7217)specifically 8
38 2996+484-tone MRU-6 and 12 within the 240 MHz subblock
39 composed of the first, second, and third 80 MHz subblock and the
40 240 MHz subblock composed of the second, third, and fourth 80 MHz
41 subblock in increasing frequency order, respectively
42
43 304–511 (100110y2y1y0– Disregard 268
44 111111y2y1y0)
45
46 (#7216)For an RU Allocation subfield with value greater than or equal to 64, y2y1y0 = 000–111 indicates the number
47 of User fields in the EHT-SIG content channel that contains the corresponding 9-bit RU Allocation subfield. The
2 1
48 binary vector y2y1y0 indicates N user  r c  = 2  y2 + 2  y1 + y0 + 1 User fields in the EHT-SIG content channel
49 that contains the corresponding 9-bit RU Allocation subfield.
50 (#1400)[] indicates one or multiple RU/MRUs that are not overlapped with the RU or MRU indicated by the 9-bit RU
51 Allocation subfield and is to help indicate the frequency order of the MRU within an 80/160/240/320 MHz subband.
52
53
54
55 “Punctured 242-tone RU (value 26 of RU Allocation field)”(#8118)(#7218) shall be used when the
56
preamble portion of corresponding 20 MHz is punctured. In this case, the corresponding 242-tone RU shall
57
58 not be used for data transmission.
59
60 “Unassigned 242-tone RU (value 27 of RU Allocation field)”(#8118)(#7219) shall be used when the
61 preamble portion of corresponding 20 MHz is not punctured and when the corresponding 242-tone RU is
62
not used for data transmission.
63
64
65

626 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#3059)(#1352)(#8024)An EHT STA shall skip N user  r c  User fields indicated by the field value and
2
3 continue to process the EHT-SIG if the RU Allocation subfield has a value designated to be Disregard.
4
5 (#3060)(#1402)In Table 36-34 (RU Allocation subfield), (#1401)the Number of entries column refers to the
6 number of RU Allocation subfield values that refer to the same RU assignment to be used in the frequency
7 domain but differ in the number of User fields indicated by this EHT-SIG content channel per RU. The
8
9 number of User fields per RU indicated by the RU Allocation subfields of an EHT-SIG content channel
10 indicate the number of User fields in the User Specific field of the EHT-SIG content channel.
11
12 (#6468)(#8115)For an RU or MRU that is referred to (#8023)by the first or single RU Allocation subfield in
13 an EHT-SIG content channel, the RU Allocation subfield encodes the number of User fields per RU
14
15 contributed to the User Specific field in the same EHT-SIG content channel as the RU Allocation subfield.
16 This number is labeled N user  r c  for RU r and EHT-SIG content channel c as described in Table 36-34 (RU
17 Allocation subfield).
18
19
20 (#6468)For an RU or MRU that is referred to by two or more RU Allocation subfields in an EHT-SIG
21 content channel (e.g., a 996-tone RU in a 160 MHz PPDU), the RU Allocation subfield other than the first
22 one in the EHT-SIG content channel encodes zero additional User fields per RU or MRU contributed to the
23 User Specific field in the same EHT-SIG content channel as the RU Allocation subfield.
24
25
26 (#6468)In an EHT MU PPDU, an RU or MRU that is not allocated to a user can be indicated as follows:
27 — The RU Allocation subfield in the EHT-SIG Common field is set to 26 or 27 (see Table 36-34 (RU
28
29
Allocation subfield)).
30 — The STA-ID subfield in the EHT-SIG User field is set to 2046 (#1399)for RUs or MRUs with fewer
31 than 242 tones (see 35.12.1.1 (STA_ID) and 36.3.12.8.5 (User Specific field)).
32
33 — The RU Allocation subfield in the EHT-SIG Common field is set to 24 (see Table 36-34 (RU
34 Allocation subfield)). In this case, the middle 26-tone RU is not allocated.
35
36 If an RU/MRU is an unallocated RU/MRU, zero users are allocated to it. Otherwise, the number of users
37
38 allocated to RU/MRU r is determined from the RU size and N user  r c  as follows:
39 — If RU/MRU r is a 26-tone, 52-tone RU, 106-tone RU, 52+26-tone MRU, or 106+26-tone MRU, then
40
41 one user is allocated to the RU/MRU.
42 — If RU r is 242-tone RU, then the number of users allocated to the RU is N user  r c  .
43
44 — If RU/MRU r is a 484-tone or larger RU/MRU, then the number of users allocated to the RU/MRU
45 equals the number of User fields for the RU/MRU summed across both EHT-SIG content channels,
46 i.e., N user  r 1  + N user  r 2  .
47
48 NOTE 1—The exact dynamic split of User fields between the two content channels, N user  r 1  and N user  r 2  ,
49 is not specified and might be used to reduce any disparity in the number of User fields between content channels.
50
51 NOTE 2—If the number of users per RU/MRU is greater than one, then the users in the RUs/MRUs are multiplexed
52 using MU-MIMO.
53
54 (#2410)(#3057)For the EHT-SIG content channel that includes one or more User fields associated with
55 (#1315)an RU/MRU larger than 484-tone, the first RU Allocation subfield(#3192) referring to the RU/MRU
56
57 may use values in the range 80–303 (001010y2y1y0–100101y2y1y0 in binary representation) as in Table 36-
58 34 (RU Allocation subfield) with y2y1y0 indicating the number of User fields signaled in the corresponding
59 content channel, while the remaining 9-bit RU Allocation subfields referring to the RU/MRU shall be set as
60
61 follows:
62 — (#2410)(#6439)The RU Allocation subfield corresponding to 242-tone RU in large-size MRU
63 combinations of 484+242-tone MRU is set to 28 (000011100 in binary representation), which
64
encodes zero additional User fields in the corresponding content channel.
65

Copyright © 2022 IEEE. All rights reserved. 627

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — (#2410)The RU Allocation subfield corresponding to 484-tone RU in large-size MRU combinations

2 of 484+242-tone MRU, 996+484-tone MRU, 2996+484-tone MRU, and 3996+484-tone MRU is
3
set to 29 (000011101 in binary representation), which encodes zero additional User fields in the
4
5 corresponding content channel.
6 — (#2410)The RU Allocation subfield corresponding to 996-tone RU in large-size MRU combinations
7 of 996+484-tone MRU, 2996+484-tone MRU, 3996+484-tone MRU, 3996-tone MRU, and in
8
9 RUs of 996-tone RU and 2996-tone RU is set to 30 (000011110 in binary representation), which
10 encodes zero additional User fields in the corresponding content channel.
11
12
13 Table 36-35—RUs associated with each RU Allocation subfield for each EHT-SIG content
14 channel and PPDU bandwidth
15
16
17 RUs in the subcarrier range,
18 PPDU or overlapping with the
19 RU Allocation subfield
bandwidth subcarrier range if the RU is
20 larger than a 242-tone RU
21
22 The RU Allocation subfield in a single EHT-SIG content channel
20 MHz [–122: 122]
23
24
40 MHz The RU Allocation subfield in EHT-SIG content channel 1 (#1396)[–244: –3]
25
26
27 The RU Allocation subfield in EHT-SIG content channel 2 [3: 244]
28
29 80 MHz The first RU Allocation subfield in EHT-SIG content channel 1 [–500: –259]
30
31 The first RU Allocation subfield in EHT-SIG content channel 2 [–253: –12]
32
33 The second RU Allocation subfield in EHT-SIG content channel 1 [12: 253]
34
35
The second RU Allocation subfield in EHT-SIG content channel 2 [259: 500]
36
37
38 160 MHz The first RU Allocation subfield in EHT-SIG content channel 1 [–1012: –771]
39
40 The first RU Allocation subfield in EHT-SIG content channel 2 [–765: –524]
41
42 The second RU Allocation subfield in EHT-SIG content channel 1 [–500: –259]
43
44 The second RU Allocation subfield in EHT-SIG content channel 2 [–253: –12]
45
46
The third RU Allocation subfield in EHT-SIG content channel 1 [12: 253]
47
48
49 The third RU Allocation subfield in EHT-SIG content channel 2 [259: 500]
50
51 The fourth RU Allocation subfield in EHT-SIG content channel 1 [524: 765]
52
53 The fourth RU Allocation subfield in EHT-SIG content channel 2 [771: 1012]
54
55
56
57
58
59
60
61
62
63
64
65

628 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-35—RUs associated with each RU Allocation subfield for each EHT-SIG content
2 channel and PPDU bandwidth (continued)
3
4
5 RUs in the subcarrier range,
6 PPDU or overlapping with the
7 RU Allocation subfield
bandwidth subcarrier range if the RU is
8 larger than a 242-tone RU
9
10 320 MHz The first RU Allocation subfield in EHT-SIG content channel 1 [–2036: –1795]
11
12 The first RU Allocation subfield in EHT-SIG content channel 2
13 [–1789: –1548]
14
15 The second RU Allocation subfield in EHT-SIG content channel 1 [–1524: –1283]
16
17 The second RU Allocation subfield in EHT-SIG content channel 2 [–1277: –1036]
18
19 The third RU Allocation subfield in EHT-SIG content channel 1 [–1012: –771]
20
21 The third RU Allocation subfield in EHT-SIG content channel 2 [–765: –524]
22
23 The fourth RU Allocation subfield in EHT-SIG content channel 1
24 [–500: –259]
25
26 The fourth RU Allocation subfield in EHT-SIG content channel 2 [–253: –12]
27
28 The fifth RU Allocation subfield in EHT-SIG content channel 1 [12: 253]
29
30 The fifth RU Allocation subfield in EHT-SIG content channel 2 [259: 500]
31
32 The sixth RU Allocation subfield in EHT-SIG content channel 1 [524: 765]
33
34 The sixth RU Allocation subfield in EHT-SIG content channel 2
35 [771: 1012]
36
37 The seventh RU Allocation subfield in EHT-SIG content channel 1 [1036: 1277]
38
39 The seventh RU Allocation subfield in EHT-SIG content channel 2 [1283: 1524]
40
41 The eighth RU Allocation subfield in EHT-SIG content channel 1 [1548: 1789]
42
43 The eighth RU Allocation subfield in EHT-SIG content channel 2 [1795: 2036]
44
45
46
47 (#3062)(#1403)For an MU-MIMO allocation of RU/MRU size greater than 242 subcarriers in an OFDMA
48
transmission, the dynamic split of User fields between EHT-SIG content channel 1 and EHT-SIG content
49
50 channel 2 is decided by the AP (on a per case basis) and signaled by the AP using the RU Allocation
51 subfields in each EHT-SIG content channel. The dynamic split of User fields can be different in each
52 80 MHz subblock if the Bandwidth of the PPDU is greater than or equal to 160 MHz.(#7220)(#1279).
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 629

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 36.3.12.8.4 Common field for non-OFDMA transmission

2
3
The Common field for non-OFDMA transmission to a single user, and non-OFDMA transmission to
4
5 multiple users is defined in Table 36-36 (Common field for non-OFDMA transmission to a single user and
6 non-OFDMA transmission to multiple users).
7
8
9 Table 36-36—Common field for non-OFDMA transmission to a single user and non-OFDMA
10
transmission to multiple users
11
12
13 Bit Subfield Number of bits Description
14
15 B0–B3 Spatial Reuse 4
16 Indicates whether or not spatial reuse modes
17 are allowed during the transmission of this
18 PPDU.
19 Set to a value from Table 27-22 (Spatial Reuse
20 field encoding for an HE SU PPDU, HE ER
21 PPDU, and HE MU PPDU). Note that
22 Table 27-22 (Spatial Reuse field encoding for
23 an HE SU PPDU, HE ER PPDU, and HE MU
24 PPDU) also applies to EHT MU PPDU. See
25 35.12.2 (SPATIAL_REUSE(#6799)) and
26 35.11 (EHT Spatial reuse
27 operation(#5444))(#4671).
28
29 B4–B5 GI+LTF Size 2 Indicates the GI duration and EHT-LTF size:
30 Set to 0 to indicate 2 LTF + 0.8 µs GI.
31 Set to 1 to indicate 2 LTF + 1.6 µs GI.
32 Set to 2 to indicate 4 LTF + 0.8 µs GI.
33 Set to 3 to indicate 4 LTF + 3.2 µs
34 GI.(#3188)
35
36 B6–B8 Number Of EHT-LTF Symbols 3 Indicate the number of EHT-LTF symbols:
37 Set to 0 to indicate 1 EHT-LTF symbol.
38 Set to 1 to indicate 2 EHT-LTF symbols.
39 Set to 2 to indicate 4 EHT-LTF symbols.
40 Set to 3 to indicate 6 EHT-LTF symbols.
41 Set to 4 to indicate 8 EHT-LTF symbols.
42 Other values are Validate if
43 dot11EHTBaseLineFeaturesImplementedOnly
44 equals true.(#2736)(#3188)(#5416)
45
46 B9 LDPC Extra Symbol Segment 1 Indicates the presence of the LDPC extra
47 symbol segment:
48 Set to 1 if an LDPC extra symbol segment is
49 present.
50 Set to 0 if an LDPC extra symbol segment is
51 not present.(#3188)
52
53 B10–B11 Pre-FEC Padding Factor 2 Indicates the pre-FEC padding factor:
54 Set to 0 to indicate a pre-FEC padding factor
55 of 4.
56 Set to 1 to indicate a pre-FEC padding factor
57 of 1.
58 Set to 2 to indicate a pre-FEC padding factor
59 of 2.
60 Set to 3 to indicate a pre-FEC padding factor
61 of 3.(#3188)
62
63
64
65

630 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-36—Common field for non-OFDMA transmission to a single user and non-OFDMA
2 transmission to multiple users (continued)
3
4
5 Bit Subfield Number of bits Description
6
7 B12 PE Disambiguity 1 Indicates PE disambiguity as defined in
8 36.3.14 (Packet extension).(#3188)
9
10 B13–B16 Disregard 4
11 Set to all 1s. Disregard if
12 dot11EHTBaseLineFeaturesImplementedOnly
13 equals true(#5416).
14
15 B17–B19 Number Of Non-OFDMA 3 (#3004)Indicates the total number of non-
16 Users OFDMA users. Set to n to indicate n+1 non-
17 OFDMA users. Set to 0 for non-OFDMA
18 transmission to a single user and set to a value
19 larger than 0 for non-OFDMA transmission to
20 multiple users. Other values are Validate if
21 dot11EHTBaseLineFeaturesImplementedOnly
22 equals true(#5416).
23
24
25
26 B0–B16 of Table 36-36 (Common field for non-OFDMA transmission to a single user and non-OFDMA
27 transmission to multiple users) are U-SIG Overflow bits for non-OFDMA transmission to a single user and
28 non-OFDMA transmission to multiple users. Both the U-SIG Overflow bits and Number Of Non-OFDMA
29 Users subfields are duplicated in each content channel.
30
31
32 (#4670)For non-OFDMA transmission to a single user, if BCC is applied, (#1404)then the LDPC Extra
33 Symbol Segment field is set to 0 to indicate an LDPC extra symbol segment is not present.
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 631

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#1405)The Common field for an EHT sounding NDP is defined in Table 36-37 (Common field for EHT
2 sounding NDP).
3
4
5
6 Table 36-37—Common field for EHT sounding NDP
7
8
9 Number of bits
Bit Subfield Description
10 per subfield
11
12 B0–B3 Spatial Reuse 4 Indicates whether or not spatial reuse modes
13 are allowed during the transmission of this
14 PPDU.
15 Set to 15 from Table 27-22 (Spatial Reuse
16 field encoding for an HE SU PPDU, HE ER
17 SU PPDU, and HE MU PPDU). Note that
18 Table 27-22 (Spatial Reuse field encoding
19 for an HE SU PPDU, HE ER PPDU, and HE
20 MU PPDU) also applies to EHT MU PPDU.
21 See 35.12.2 (SPATIAL_REUSE(#6799))
22 and 35.11 (EHT Spatial reuse
23 operation(#5444))(#4671).
24
25 B4–B5 GI+LTF Size 2 Indicates the GI duration and EHT-LTF size:
26 Set to 0 to indicate 2 LTF + 0.8 µs GI.
27 Set to 1 to indicate 2 LTF + 1.6 µs GI.
28 Value 2 is Validate if
29 dot11EHTBaseLineFeaturesImplementedOn
30 ly equals true(#5416).
31 Set to 3 to indicate 4 LTF + 3.2 µs
32 GI.(#3188)(#2737)
33
34 B6–B8 Number Of EHT-LTF Symbols 3 Indicate the number of EHT-LTF symbols:
35 Set to 0 to indicate 1 EHT-LTF symbol.
36 Set to 1 to indicate 2 EHT-LTF symbols.
37 Set to 2 to indicate 4 EHT-LTF symbols.
38 Set to 3 to indicate 6 EHT-LTF symbols.
39 Set to 4 to indicate 8 EHT-LTF symbols.
40 Other values are Validate if
41 dot11EHTBaseLineFeaturesImplementedOn
42 ly equals true.(#2737)(#3188)(#5416)
43
44 B9–B12 NSS 4 (#3081)Indicates the number of spatial
45 streams of the EHT sounding NDP:
46 Set to the number of spatial streams minus 1
47 for up to 8 spatial streams.
48 Other values are Validate if
49 dot11EHTBaseLineFeaturesImplementedOn
50 ly equals true.(#2737)(#5416)
51
52 B13 Beamformed 1
53 Set to 1 if a beamforming steering matrix is
54 applied to the EHT modulated fields.
55 Set to 0 otherwise.(#3194)
56
57
58
59
60
61
62
63
64
65

632 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-37—Common field for EHT sounding NDP (continued)

2
3
4 Number of bits
Bit Subfield Description
5 per subfield
6
7 B14–B15 Disregard 2 Set to both 1s. Disregard if
8 dot11EHTBaseLineFeaturesImplementedOn
9 ly equals true(#5416).
10
11 B16–B19 CRC 4 CRC for bits 0–15 of the EHT-SIG field. The
12 CRC is calculated over bits B0–B15. The
13 CRC computation uses the same polynomial
14 as that in 27.3.11.7.3 (CRC computation).
15
16 B20–B25 Tail 6
17 Used to terminate the trellis of the
18 convolutional decoder. Set to 0.
19
20
21
B0–B15 of Table 36-37 (Common field for EHT sounding NDP) are U-SIG Overflow bits for EHT
22
23 sounding NDP and are duplicated in each content channel.
24
25 (#3194)If the Beamformed field in EHT-SIG of an EHT sounding NDP is 1, then the receiver of the EHT
26 sounding NDP should not perform channel smoothing when generating the compressed beamforming
27
feedback report(#4670).
28
29
30 36.3.12.8.5 User Specific field
31
32 (#1407)The User Specific field of an EHT-SIG content channel consists of zero or more (#5485)user
33
encoding blocks followed by padding (if present) as shown in Figure 36-31 (EHT-SIG content channel
34
35 format for OFDMA transmission if bandwidth is 20/40/80 MHz(#5485)(#3295)(#1383)(#1384)(#1390)),
36 Figure 36-32 (EHT-SIG content channel format for OFDMA transmission if bandwidth is
37 160 MHz(#5485)(#3295)(#1383)(#1384)(#1390)), Figure 36-33 (EHT-SIG content channel format for
38 OFDMA transmission if bandwidth is 320 MHz(#5485)(#3295)(#1383)(#1384)(#1390)), Figure 36-34
39
(EHT-SIG content channel format for non-OFDMA transmission to a single user(#5485)(#1390)(#2174)),
40
41 and Figure 36-36 (EHT-SIG content channel format for non-OFDMA transmission to multiple
42 users(#5485)(#1390)(#1393)(#2174)(#3159)). There is no User Specific field for EHT sounding NDP as
43 shown in Figure 36-35 (EHT-SIG content channel format for EHT sounding NDP(#5485)(#1390)(#2174)).
44
45
(#1407)(#8018)(#5485)For a DL OFDMA transmission (in the U-SIG field, the UL/DL field is set to 0, and
46
47 the PPDU Type And Compression Mode field is set to 0), the number of user fields is indicated by the RU
48 Allocation subfields. Each nonfinal user encoding block is made up of two user fields that contain
49 information for two STAs that are used to decode their payloads. The final user encoding block contains
50 information for one or two users depending on the number of users in the EHT-SIG content channel.
51
52
53 (#1407)(#8018)For a non-OFDMA transmission to a single user (in the U-SIG field, the UL/DL field is set
54 to either 0 or 1, the PPDU Type And Compression Mode field is set to 1, and the EHT-SIG MCS field and
55 the Number of EHT-SIG Symbols field are not set to 0 at the same time), and a DL non-OFDMA
56 transmission to multiple users (in the U-SIG field, the UL/DL field is set to 0, and the PPDU Type And
57
Compression Mode field is set to 2), the number of user fields is indicated by the Number Of Non-OFDMA
58
59 Users subfield. The Common field of the EHT-SIG content channel is encoded together with the first User
60 field in the same content channel(#5423). (#1390)(#5485)This common encoding block contains a CRC and
61 a Tail. The content of the common encoding block(#1390) in the EHT-SIG field for a non-OFDMA
62 transmission to a single user and multiple users is defined in Table 36-38 (The common encoding block in an
63
EHT-SIG field for non-OFDMA transmission to a single user and multiple users(#5485)(#8018)(#1390)). In
64
65 the case of a non-OFDMA transmission to multiple users, the remaining user fields (if present) in each

Copyright © 2022 IEEE. All rights reserved. 633

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 content channel(#5424) are grouped into(#5425)(#7221)(#5485) user encoding blocks using the same
2 method as the OFDMA transmission.
3
4
5
6 Table 36-38—The common encoding block in an EHT-SIG field for non-OFDMA transmis-
7 sion to a single user and multiple users(#5485)(#8018)(#1390)
8
9
10 Number of bits
Bit Subfield Description
11 per subfield
12
13 B0–B19 Common field for non- 20 The Common field for non-OFDMA
14 OFDMA transmission to a transmission to a single user and non-
15 single user and non-OFDMA OFDMA transmission to multiple users is
16 transmission to multiple users defined in Table 36-36 (Common field for
17 non-OFDMA transmission to a single user
18 and non-OFDMA transmission to multiple
19 users).
20
21 B20–B41 User field 22 The User field format for a non-MU-MIMO
22 allocation is defined in Table 36-40 (User
23 field format for a non-MU-MIMO
24 allocation). (#7095)The User field format for
25 an MU-MIMO allocation is defined in
26 Table 36-41 (User field format for an MU-
27 MIMO allocation(#7095)).
28
29 B42–B45 CRC 4 The CRC is calculated over bits 0 to 41. The
30 CRC computation uses the same polynomial
31 as that in 27.3.11.7.3 (CRC computation).
32
33 B46–B51 Tail 6 Used to terminate the trellis of the
34 convolutional decoder. Set to 0.
35
36
37
38 (#8018)For an EHT sounding NDP (in the U-SIG field, the UL/DL field is set to either 0 or 1, the PPDU
39
Type And Compression Mode field is set to 1, the EHT-SIG MCS field is set to 0, and the Number Of EHT-
40
41 SIG Symbols field is set to 0), there is no User field.
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

634 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#5485)The user encoding block is defined in Table 36-39 (The user encoding block(#5485)). (#5425)For
2 non-OFDMA transmission to multiple users, the user encoding block is present if there are more than one
3
User fields in the corresponding content channel.
4
5
6
7 Table 36-39—The user encoding block(#5485)
8
9
10 Number of Number of bits
Bit(#8122) Subfield Description
11 subfields per subfield
12
13 B0– User field N 22 N User fields are present, where:
14 B22N-1 (#5485)N = 1 if it is the final user encoding
15 block, and if there is only one user in the
16 final user encoding block.
17 N = 2 otherwise.
18 The User field format for a non-MU-MIMO
19 allocation is defined in Table 36-40 (User field
20 format for a non-MU-MIMO allocation).
21 (#7095)The User field format for an MU-
22 MIMO allocation is defined in Table 36-41
23 (User field format for an MU-MIMO
24 allocation(#7095)).
25
26 B22N– CRC 1 4 (#2670)(#2411)(#5485)The CRC is calculated
27 B22N+3 over bits 0 to 21 for a user encoding block that
28 contains one User field, and bits 0 to 43 for a
29 user encoding block that contains two User
30 fields. The CRC computation uses the same
31 polynomial as that in 27.3.11.7.3 (CRC
32 computation).
33
34 B22N+4– Tail 1 6 Used to terminate the trellis of the
35 B22N+9 convolutional decoder. Set to 0.
36
37
38
39
The contents of the User field differ depending on whether the field addresses a user in a non-MU-MIMO
40
41 allocation in an RU or a user in an MU-MIMO allocation in an RU. For EHT MU PPDU sent to a single
42 user, the User field format for a non-MU-MIMO allocation is used.
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 635

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The User field format for a non-MU-MIMO allocation is defined in Table 36-40 (User field format for a
2 non-MU-MIMO allocation).
3
4
5
6 Table 36-40—User field format for a non-MU-MIMO allocation
7
8
9 Number
Bit Subfield Description
10 of bits
11
12 B0–B10 STA-ID 11 (#2198)(#7222)Set to a value of the TXVECTOR
13 parameter STA-ID (see 35.12.1.1 (STA_ID)).
14
15 B11–B14 MCS 4 (#5426)If the STA-ID subfield is not equal to 2046,
16 this subfield indicates the following modulation and
17 coding scheme:
18 Set to n for EHT-MCS n, where n = 0 1  15 .
19 Set to an arbitrary value if the STA-ID subfield is equal
20 to 2046.
21
22 (#5426)If the value of STA-ID subfield matches the
23 user’s STA-ID and if
24 dot11EHTBaseLineFeaturesImplementedOnly equals
25 true, the value of EHT-MCS 14 or EHT-MCS 15 is
26 Validate if the condition described in 36.1.1
27 (Introduction to the EHT PHY) is not met. If the value
28 of STA-ID subfield does not match the user’s STA-ID
29 and if dot11EHTBaseLineFeaturesImplementedOnly
30 equals true, all values are Disregard.
31
32 B15 Reserved 1 Reserved and set to 1.
33 (#1353)(#1355)(#5426)If the value of STA-ID subfield
34 matches the user’s STA-ID and if
35 dot11EHTBaseLineFeaturesImplementedOnly equals
36 true, the Reserved subfield is Validate. If the value of
37 STA-ID subfield does not match the user’s STA-ID
38 and if dot11EHTBaseLineFeaturesImplementedOnly
39 equals true, the Reserved subfield is Disregard.
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

636 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-40—User field format for a non-MU-MIMO allocation (continued)

2
3
4 Number
Bit Subfield Description
5 of bits
6
7 B16–B19 NSS 4 (#1566)(#2644)(#5426)If the STA-ID subfield is not
8 equal to 2046, it indicates the number of spatial
9 streams for up to eight spatial streams.
10
11 (#5426)Set to the number of spatial streams minus 1.
12
13 (#5426)Set to an arbitrary value if the STA-ID subfield
14 is equal to 2046.
15
16 (#5426)If the value of STA-ID subfield matches the
17 user’s STA-ID and if
18 dot11EHTBaseLineFeaturesImplementedOnly equals
19 true, other values are Validate. If the value of STA-ID
20 subfield does not match the user’s STA-ID and if
21 dot11EHTBaseLineFeaturesImplementedOnly equals
22 true, all values are Disregard.
23
24 B20 Beamformed 1 (#7225)If the STA-ID subfield is not 2046, this
25 subfield is used to indicate transmit beamforming:
26 Set to 1 if a beamforming steering matrix is applied to
27 the waveform in a non-MU-MIMO allocation.
28 Set to 0 otherwise.
29
30 Set to an arbitrary value if the STA-ID subfield is
31 2046.
32
33 B21 Coding 1 (#5426)If the STA-ID subfield is not equal to 2046,
34 this subfield indicates whether BCC or LDPC is used:
35 Set to 0 for BCC.
36 Set to 1 for LDPC.
37
38 Set to an arbitrary value if the STA-ID subfield is
39 2046.
40
41 (#5426)If the value of STA-ID subfield does not match
42 the user’s STA-ID and if
43 dot11EHTBaseLineFeaturesImplementedOnly equals
44 true, all values are Disregard.
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 637

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The User field format for an MU-MIMO allocation is defined in Table 36-41 (User field format for an MU-
2 MIMO allocation(#7095)).
3
4
5
6 Table 36-41—User field format for an MU-MIMO allocation(#7095)
7
8
9 Number
Bit Subfield Description
10 of bits
11
12 B0–B10 STA-ID 11 (#2198)(#7222)Set to a value of the TXVECTOR
13 parameter STA-ID (see 35.12.1.1 (STA_ID)).
14
15 B11–B14 MCS 4 (#5426)If the STA-ID subfield is not equal to 2046,
16 this subfield indicates the following modulation and
17 coding scheme:
18 (#1567)Set to n for EHT-MCS n, where
19 n = 0 1  13 .
20
21 (#5426)Set to an arbitrary value if the STA-ID subfield
22 is equal to 2046.
23
24 (#1567)(#5426)If the value of STA-ID subfield
25 matches the user’s STA-ID and if
26 dot11EHTBaseLineFeaturesImplementedOnly equals
27 true, other values are Validate. If the value of STA-ID
28 subfield does not match the user’s STA-ID and if
29 dot11EHTBaseLineFeaturesImplementedOnly equals
30 true, all values are Disregard.
31
32 B15 Coding 1 (#5426)If the STA-ID subfield is not equal to 2046,
33 this subfield indicates whether BCC or LDPC is used:
34 Set to 0 for BCC.
35 Set to 1 for LDPC.
36
37 (#1353)(#1355)(#5426)If the RU size is larger than
38 242, this bit is reserved and set to 1.
39
40 (#5426)Set to an arbitrary value if the STA-ID subfield
41 is equal to 2046.
42
43 (#5426)If the value of STA-ID subfield matches the
44 user’s STA-ID and if
45 dot11EHTBaseLineFeaturesImplementedOnly equals
46 true, the Reserved subfield is Validate. If the value of
47 STA-ID subfield does not match the user’s STA-ID
48 and if dot11EHTBaseLineFeaturesImplementedOnly
49 equals true, the Reserved subfield is Disregard.
50
51 B16–B21 Spatial Configuration 6 Indicates the number of spatial streams for a user in an
52 MU-MIMO allocation (see Table 36-42 (Spatial
53 Configuration subfield encoding(#5483))).
54
55 (#5484)If STA-ID matches, the values that are
56 reserved or do not exist in Table 36-42 (Spatial
57 Configuration subfield encoding(#5483)) are Validate
58 if dot11EHTBaseLineFeaturesImplementedOnly
59 equals true.
60 (#5484)If STA-ID does not match, all values are
61 Disregard if
62 dot11EHTBaseLineFeaturesImplementedOnly equals
63 true.
64
65

638 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#8018)(#8125)For a DL non-OFDMA transmission to multiple users when the bandwidth of the PPDU is
2 greater than or equal to 40 MHz, an equitable split is defined as the split of User fields across the EHT-SIG
3
content channels, i.e., a User field k of a K-user non-OFDMA MU-MIMO transmission is carried in an
4
5 EHT-SIG content channel c, where c is defined in Equation (36-23).
6
7
8  1 if k  1 2  K  2
c =  (36-23)
9  2 if k  K  2 + 1  K
10
11
12 A User field for an MU-MIMO allocation includes a 6-bit Spatial Configuration subfield that indicates the
13 number of spatial streams for each user and the total number of spatial streams in the MU-MIMO allocation.
14 The subfield shown in Table 36-42 (Spatial Configuration subfield encoding(#5483)) is constructed by using
15
16 the entries corresponding to the value of the number of users  N user  multiplexed using MU-MIMO in an
17 RU.
18
19
20
(#3065)For OFDMA transmission when MU-MIMO is used in an RU of size greater than 242 subcarriers,
21 the AP performs a dynamic split of the User fields corresponding to the same MU-MIMO allocations as
22 described in 36.3.12.8.3 (Common field for OFDMA transmission) into two EHT-SIG content channels and
23 the number of users  N user  is computed as the sum of the number of User fields indicated for the RU by the
24
25 9-bit RU Allocation subfield in each EHT-SIG content channel.
26
27 (#3065)For OFDMA transmission when MU-MIMO is used in an RU of size equal to 242 subcarriers, the
28 number of users in the RU is equal to the number of User fields signaled for the RU in the associated RU
29
30
Allocation subfield of the Common field in the same EHT-SIG content channel.
31
32 The positions of the User field within an RU are defined to be logically continuous: the last User field
33 corresponding to an RU in EHT-SIG content channel 1 is immediately followed by the first User field
34 corresponding to the same RU in EHT-SIG content channel 2.
35
36
37 For a given value of N user , the six bits of the Spatial Configuration subfield are used as follows: A STA with
38 a STA-ID that matches the 11-bit ID signaled in the User field for an MU-MIMO allocation derives the
39
number of spatial streams allocated to it using the row corresponding to the signaled 6-bit Spatial
40
41 Configuration subfield and the column corresponding to the position of the User field in the User Specific
42 field. The starting stream index for the user is computed by summing the N SS in the columns prior to the
43
column indicated by the position of the user’s User field.
44
45
46
47 Table 36-42—Spatial Configuration subfield encoding(#5483)
48
49
50 NSS NSS NSS NSS NSS NSS NSS NSS Total Total
Nuser B5…B0
51 [1] [2] [3] [4] [5] [6] [7] [8] NSS entries
52
53 000000–
1–4 1 2–5
54 000011
55
56 000100–
2–4 2 4–6
57 2 000110 10
58 000111–
59 3–4 3 6–7
001000
60
61 001001 4 4 8
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 639

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-42—Spatial Configuration subfield encoding(#5483) (continued)

2
3
4 NSS NSS NSS NSS NSS NSS NSS NSS Total Total
Nuser B5…B0
5 [1] [2] [3] [4] [5] [6] [7] [8] NSS entries
6
7 000000–
8 1–4 1 1 3–6
000011
9
10 000100–
11 2–4 2 1 5–7
000110
12
13
14 000111–
3–4 3 1 7–8
15 001000
16 3 13
17 001001 Reserved
18
19 001010–
2–4 2 2 6–8
20 001100
21
22 001101 3 3 2 8
23
24 001110–
25 Reserved
010011
26
27 000000–
28 1–4 1 1 1 4–7
000011
29
30 000100–
31 2–4 2 1 1 6–8
000110
32
33 000111 3 3 1 1 8
34
35 001000–
Reserved
36 001001
37 4 11
38 001010–
2–3 2 2 1 7–8
39 001011
40 001100–
41 Reserved
010011
42
43 010100 2 2 2 2 8
44
45 010101–
Reserved
46 100010
47
48 000000–
1–4 1 1 1 1 5–8
49 000011
50
51 000100–
2–3 2 1 1 1 7–8
52 000101
53 5 000110– 7
54 Reserved
001001
55
56 001010 2 2 2 1 1 8
57
58 001011–
Reserved
59 110000
60
61
62
63
64
65

640 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-42—Spatial Configuration subfield encoding(#5483) (continued)

2
3
4 NSS NSS NSS NSS NSS NSS NSS NSS Total Total
Nuser B5…B0
5 [1] [2] [3] [4] [5] [6] [7] [8] NSS entries
6
7 000000–
1–3 1 1 1 1 1 6–8
8 000010
9
10 000011 Reserved
11 6 4
12 000100 2 2 1 1 1 1 8
13 000101–
14 Reserved
110101
15
16 000000–
17 1–2 1 1 1 1 1 1 7–8
000001
18 7 2
19 000010–
Reserved
20 110001
21
22 000000 1 1 1 1 1 1 1 1 8
23 8 1
24 000001–
Reserved
25 011010
26
27
28 (#5483)NOTE—Total entries do not include the reserved entries.
29
30
31 The user ordering identified by the column headers N SS  s  s = 1 2 3  in Table 36-42 (Spatial
32 Configuration subfield encoding(#5483)) shall be the same as the user index u, u = 0 1 2  in
33
34 Equation (36-35), Equation (36-44), and Equation (36-82), i.e., u = s – 1 .
35
36 The total number of spatial streams (total N SS ) is computed by summing all columns for the row signalled
37
38 by the Spatial Configuration field and is indicated in Table 36-42 (Spatial Configuration subfield
39 encoding(#5483)) under the column Total N SS .
40
41
42 36.3.12.8.6 Encoding and modulation
43
44 (#3066)(#5485)For OFDMA transmission, the Common field of each EHT-SIG content channel is included
45 into one or two common encoding blocks. For EHT sounding NDP, the Common field of each EHT-SIG
46
47 content channel is included in a single common encoding block. Each common encoding block shall be
48 BCC encoded at rate R = 1  2 . For EHT-SIG for non-OFDMA transmission to a single user or non-
49 OFDMA transmission to multiple users, the Common field of each EHT-SIG content channel, together with
50
51
the only User field or the first User field of the User Specific field, is included into a single common
52 encoding block, which shall be BCC encoded at rate R = 1  2 .
53
54 For EHT-SIG for OFDMA transmission and non-OFDMA transmission to multiple users, each (#5485)user
55
56 encoding block OFDMA transmission, if the number of User fields in an EHT-SIG content channel is odd,
57 there is a single User field in the final (#5485)user encoding block. For non-OFDMA transmission, the first
58 User field is encoded together with the Common field of the EHT-SIG. If the number of User fields in an
59 EHT-SIG content channel is even, there is a single User field in the final (#5485)user encoding block. CRC
60 and tail bits are added immediately after the last User field in each (#5485)user encoding block.
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 641

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Padding bits are appended immediately after the tail bits corresponding to the final (#5485)user encoding
2 block in each EHT-SIG content channel to round up to the next multiple of number of data bits per EHT-SIG
3
OFDM symbol.
4
5
6 The padding bits may be set to any value. Further padding bits are appended to each EHT-SIG content
7 channel so that the number of OFDM symbols after encoding and modulation in different 20 MHz
8 subchannels is the same and equal to the number of EHT-SIG symbols signaled in the Number Of EHT-SIG
9
Symbol subfield in U-SIG field(#5657). (#5485)For the common encoding block and each user encoding
10
11 block, the information bits, tail bits and padding bits (if present) are BCC encoded at rate R = 1  2 using
12 the encoder described in 17.3.5.6 (Convolutional encoder)(#4959).
13
14
15 The coded bits are interleaved as described in 36.3.13.6 (BCC interleavers). The interleaved bits are mapped
16 to constellation points from the EHT-SIG-MCS specified in U-SIG field(#5657) and have pilots inserted
17 following the steps described in 17.3.5.8 (Subcarrier modulation mapping) and 17.3.5.9 (Pilot subcarriers),
18 respectively. Each EHT-SIG OFDM symbol shall have 52 data tones.
19
20
21 The guard interval used for each EHT-SIG OFDM symbol shall be 0.8 µs.
22
23 The number of OFDM symbols in the EHT-SIG field, denoted N sym EHT-SIG , shall be indicated in the Number
24
25
Of EHT-SIG Symbols field in the U-SIG field of an EHT MU PPDU (see 36.3.12.7.2 (Content)).
26
27 (#7227)In EHT-SIG for OFDMA transmission, d lk n c denotes the complex number assigned to the k-th data
28
29 subcarrier of the n-th symbol in the EHT-SIG content channel c (c = 1 to 2) and 80 MHz frequency subblock
30 l(#1279). In EHT-SIG for non-OFDMA transmission to multiple users, d k n c denotes the complex number
31
32
assigned to the k-th data subcarrier of the n-th symbol in the EHT-SIG content channel c. In EHT-SIG for
33 non-OFDMA transmission to a single user or EHT sounding NDP(#5429), d k n denotes the complex
34 number assigned to the k-th data subcarrier of the n-th symbol in the single EHT-SIG content channel.
35
36
37 (#7228)The time domain waveform for the EHT-SIG field, transmitted on transmit chain i TX , is given by
38 Equation (36-24)(#3067).
39
40
41
i
42 TX
r EHT-SIG t (36-24)
43
44
45
46 N sym EHT-SIG – 1
1
47
48
= ----------------------------------------------------------------
Tone  20MHz
 w TEHT-SIG  t – nT SYML 
49
N TX  N EHT-SIG  ---------------- - n=0
N 20MHz
50
51 28

52     k – K Shift  iBW   BW
53 i BW   20MHz k = – 28
54
55
56
 
i
  Mr + p n + 4 P k exp  j2  k – K Shift  i BW   F Pre-EHT  t – nT SYML – T GI Pre-EHT – T CS
TX
57 D
20  k  k n i BW 
58
59
60
61
where
62
Tone
63 N EHT-SIG is given in Table 36-26 (Number of modulated subcarriers and guard interval duration values
64
for EHT PPDU fields).
65

642 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 M r k is the phase rotation value for EHT-SIG field PAPR reduction. If the EHT-SIG field is
2 20

3 modulated with (#8097)EHT-SIG MCS field set to 3 (EHT-MCS 15), Mr = 1 . For all the
4 20  k 

5 other modulation schemes:

6
7  1 r
0  M 20  k   26

8  Mr =  r
20  k   M 20  k  r
9
  –1   26  M 20  k   52
10
11 K Shift  iBW  is defined in 36.3.12.5 (L-SIG).
12
13  0 k = 0  7  21

14 D k n iBW =  i BW  4 for EHT-SIG for OFDMA transmission.
15 d M r  k  n  i mod 2  + 1
 otherwise
16  20 BW

17
 0 k = 0  7  21
18 
19 D k n iBW = d  otherwise for EHT-SIG for non-OFDMA transmission to
 Mr20  k  n  i BW mod 2  + 1
20 
21
22 multiple users.
23  0
24  k = 0  7  21
D k n iBW =  for EHT-SIG for non-OFDMA transmission to a single
25 d Mr 20  k  n
 otherwise
26 
27 user or EHT sounding NDP.
28
29  k + 28 – 28  k  – 22
30  k + 27 – 20  k  – 8
31 
32 r  k + 26 – 6  k  – 1
M 20  k  = 
33
 k + 25 1  k  6
34  k + 24 8  k  20
35 
36  k + 23 22  k  28
37
38 P k and p n are defined in 17.3.5.10 (OFDM modulation).
39
N sym EHT-SIG is the number of OFDM symbols in the EHT-SIG field.
40
41 Other variables in Equation (36-24) are defined in 36.3.10 (Timing-related parameters) and 36.3.11
42 (Mathematical description of signals)(#4665).
43
44
(#3108)For OFDMA transmission and non-OFDMA transmission to multiple users, a 20 MHz PPDU
45
46 contains one EHT-SIG content channel as shown in Figure 36-37 (EHT-SIG content channel for a 20 MHz
47 PPDU for OFDMA transmission and non-OFDMA transmission to multiple users) according to
48 Equation (36-24) and 36.3.12.8.2 (EHT-SIG content channels).
49
50 Common field User Specific field
51 U-SIG Overflow and RU Allocation subfield for RUs EHT-SIG
52 overlapping tone range –122:122 (if present) and User fields for RUs signaled in Common field content
53 Number of Non-OFDMA Users (if present) channel 1
54
55
56
Figure 36-37—EHT-SIG content channel for a 20 MHz PPDU for OFDMA transmission and
57 non-OFDMA transmission to multiple users
58
59
60 (#3108)For OFDMA transmission and non-OFDMA transmission to multiple users, a 40 MHz PPDU
61 contains two EHT-SIG content channels, each occupying a 20 MHz frequency subchannel(#1279) as shown
62 in Figure 36-38 (EHT-SIG content channel for a 40 MHz PPDU for OFDMA transmission and non-
63
64
65

Copyright © 2022 IEEE. All rights reserved. 643

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 OFDMA transmission to multiple users) according to Equation (36-24) and 36.3.12.8.2 (EHT-SIG content
2 channels).
3
4 Common field User Specific field
5
Low to high sub-
U-SIG Overflow and RU Allocation subfield for EHT-SIG
carrier index
6 RUs overlapping tone range 3:244 (if present) and User fields for RUs signaled in Common field content
7 Number of Non-OFDMA Users (if present) channel 2
8 U-SIG Overflow and RU Allocation subfield for EHT-SIG
9 RUs overlapping tone range –244:–3 (if present) User fields for RUs signaled in Common field content
10 and Number of Non-OFDMA Users (if present) channel 1
11
12 Figure 36-38—EHT-SIG content channel for a 40 MHz PPDU for OFDMA transmission and
13 non-OFDMA transmission to multiple users
14
15
(#3108)For OFDMA transmission and non-OFDMA transmission to multiple users, an 80 MHz PPDU
16
17 contains two EHT-SIG content channels each of which is duplicated as shown in Figure 36-39 (EHT-SIG
18 content channels and their duplication in an 80 MHz PPDU for OFDMA transmission and non-OFDMA
19 transmission to multiple users) according to Equation (36-24) and 36.3.12.8.2 (EHT-SIG content channels).
20
21 Common field User Specific field
22 U-SIG Overflow and RU Allocation subfields for RUs EHT-SIG
23 overlapping with tone ranges –253:–12 and 259:500 (if User fields for RUs signaled in Common field content
present) and Number of Non-OFDMA Users (if present) channel 2
24
Low to high sub-carrier index

25 U-SIG Overflow and RU Allocation subfields for RUs EHT-SIG

26 DUP
overlapping with tone ranges –500:–259 and 12:253 (if User fields for RUs signaled in Common field content
present) and Number of Non-OFDMA Users (if present) channel 1
27
28
29 DUP
U-SIG Overflow and RU Allocation subfields for RUs
overlapping with tone ranges –253:–12 and 259:500 (if User fields for RUs signaled in Common field
EHT-SIG
content
30 present) and Number of Non-OFDMA Users (if present) channel 2
31
32 U-SIG Overflow and RU Allocation subfields for RUs
overlapping with tone ranges –500:–259 and 12:253 (if User fields for RUs signaled in Common field
EHT-SIG
content
33 present) and Number of Non-OFDMA Users (if present) channel 1
34
35
36 Figure 36-39—EHT-SIG content channels and their duplication in an 80 MHz PPDU for
37 OFDMA transmission and non-OFDMA transmission to multiple users
38
39 If (#1315)an RU or MRU for an allocation in an 80 MHz PPDU overlaps more than one of the subcarrier
40
41 ranges [–500: –259], [–253: –12], [12: 253], or [259: 500], the corresponding RU Allocation subfields in the
42 respective content channels shall all refer to the same RU or MRU.
43
44 (#3307)(#4655)If the Bandwidth subfield and Punctured Channel Indication subfield in the U-SIG field of
45 an EHT MU PPDU (see Table 36-28 (U-SIG field of an EHT MU PPDU)) indicates 80 MHz and preamble
46
47 is punctured, the mapping of the EHT-SIG content channels to 20 MHz subchannels shall be the same as for
48 an 80 MHz PPDU (see Figure 36-39 (EHT-SIG content channels and their duplication in an 80 MHz PPDU
49 for OFDMA transmission and non-OFDMA transmission to multiple users), with the exception that
50 punctured 20 MHz subchannels shall be excluded.
51
52
53 (#2813)(#3108)For OFDMA transmission and non-OFDMA transmission to multiple users, a 160 MHz
54 PPDU contains two EHT-SIG content channels for each of the two 80 MHz subblocks(#1279), each of
55 which is duplicated as shown in Figure 36-40 (EHT-SIG content channels and their duplication in a
56 160 MHz PPDU for OFDMA transmission and non-OFDMA transmission to multiple users) according to
57 Equation (36-24) and 36.3.12.8.2 (EHT-SIG content channels). EHT-SIG content channels with (#8126)the
58
59 same index c may carry different information in different 80 MHz subblocks for EHT-SIG for OFDMA
60
61
62
63
64
65

644 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 transmission but shall carry the same information in different 80 MHz subblocks(#1279) for EHT-SIG for
2 non-OFDMA transmission to multiple users.
3
4 Common field User Specific field
5 U-SIG Overflow and RU Allocation subfields for RUs overlapping with tone EHT-SIG
content
ranges –765:–524, –253:–12, 259:500 and 771:1012 (if present) and User fields for RUs signaled in Common field
6 Number of Non-OFDMA Users (if present) channel 2
7
80MHz frequency subblock 2

8 U-SIG Overflow and RU Allocation subfields for RUs overlapping with tone EHT-SIG
ranges –1012:–771, –500:–259, 12:253 and 524:765 (if present) and User fields for RUs signaled in Common field content
9 DUP Number of Non-OFDMA Users (if present) channel 1
10
11 EHT-SIG
U-SIG Overflow and RU Allocation subfields for RUs overlapping with tone
12 DUP
ranges –765:–524, –253:–12, 259:500 and 771:1012 (if present) and User fields for RUs signaled in Common field content
13 Number of Non-OFDMA Users (if present) channel 2

14
Low to high sub-carrier index

U-SIG Overflow and RU Allocation subfields for RUs overlapping with tone
15 ranges –1012:–771, –500:–259, 12:253 and 524:765 (if present) and User fields for RUs signaled in Common field
EHT-SIG
content
16 Number of Non-OFDMA Users (if present) channel 1
17
18 U-SIG Overflow bits and RU Allocation subfields for RUs overlapping with EHT-SIG
content
19 tone ranges –765:–524, –253:–12, 259:500 and 771:1012 (if present) and
Number of Non-OFDMA Users (if present)
User fields for RUs signaled in Common field
channel 2
20
80MHz frequency subblock 1

21 U-SIG Overflow and RU Allocation subfields for RUs overlapping with tone EHT-SIG
content
22 DUP
ranges –1012:–771, –500:–259, 12:253 and 524:765 (if present) and
Number of Non-OFDMA Users (if present)
User fields for RUs signaled in Common field
channel 1
23
24 EHT-SIG
U-SIG Overflow and RU Allocation subfields for RUs overlapping with tone
25 DUP ranges –765:–524, –253:–12, 259:500 and 771:1012 (if present) and User fields for RUs signaled in Common field content
26 Number of Non-OFDMA Users (if present) channel 2

27
28 U-SIG Overflow and RU Allocation subfields for RUs overlapping with tone EHT-SIG
ranges –1012:–771, –500:–259, 12:253 and 524:765 (if present) and User fields for RUs signaled in Common field content
29 Number of Non-OFDMA Users (if present) channel 1
30
31 Figure 36-40—EHT-SIG content channels and their duplication in a 160 MHz PPDU for
32
33
OFDMA transmission and non-OFDMA transmission to multiple users
34
35 If (#1315)an RU or MRU for an allocation in a 160 MHz PPDU overlaps more than one of the subcarrier
36 ranges [–1012: –771], [–765: –524], [–500: –259], [–253: –12], [12: 253], [259: 500], [524: 765], or [771:
37
38 1012], the corresponding RU Allocation subfields in the respective content channels shall all refer to the
39 same RU or MRU.
40
41 (#3308)(#4655)If the Bandwidth subfield and Punctured Channel Indication subfield in the U-SIG field of
42 an EHT MU PPDU (see Table 36-28 (U-SIG field of an EHT MU PPDU)) indicates 160 MHz and preamble
43
44 is punctured, the mapping of the EHT-SIG content channels to 20 MHz subchannels shall be the same as for
45 a 160 MHz PPDU (see Figure 36-40 (EHT-SIG content channels and their duplication in a 160 MHz PPDU
46 for OFDMA transmission and non-OFDMA transmission to multiple users)), with the exception that
47 punctured 20 MHz subchannels shall be excluded.
48
49
50 (#3108)(#1279)For OFDMA transmission and non-OFDMA transmission to multiple users, a 320 MHz
51 PPDU contains two EHT-SIG content channels for each of the four 80 MHz subblocks, each of which is
52 duplicated as shown in Figure 36-41 (EHT-SIG content channels and their duplication in a 320 MHz PPDU
53 for OFDMA transmission and non-OFDMA transmission to multiple users) according to Equation (36-24)
54 and 36.3.12.8.2 (EHT-SIG content channels). EHT-SIG content channels with (#8127)the same index c may
55
56 carry different information in different 80 MHz subblocks for EHT-SIG for OFDMA transmission but shall
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 645

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 carry the same information in different 80 MHz subblocks for EHT-SIG for non-OFDMA transmission to
2 multiple users.
3
4 Common field User Specific field
U-SIG Overflow and RU Allocation subfields for RUs overlapping with tone ranges EHT-SIG
5 –1789:–1548, –1277:–1036, -765:–524, –253:–12, 259:500, 771:1012, 1283:1524 and 1795:2036 User fields for RUs signaled in Common field content
channel 2
6 (if present) and Number of Non-OFDMA Users (if present)
80MHz frequency subblock 4

7 U-SIG Overflow and RU Allocation subfields for RUs overlapping with tone ranges
–2036:–1795, –1524:–1283, –1012:–771, –500:–259, 12:253, 524:765, 1036:1277 and 1548:1789 User fields for RUs signaled in Common field
EHT-SIG
content
8 DUP (if present) and Number of Non-OFDMA Users (if present) channel 1

9 U-SIG Overflow and RU Allocation subfields for RUs overlapping with tone ranges EHT-SIG
10 DUP –1789:–1548, –1277:–1036, -765:–524, –253:–12, 259:500, 771:1012, 1283:1524 and 1795:2036
(if present) and Number of Non-OFDMA Users (if present)
User fields for RUs signaled in Common field content
channel 2
11
12 U-SIG Overflow and RU Allocation subfields for RUs overlapping with tone ranges
–2036:–1795, –1524:–1283, –1012:–771, –500:–259, 12:253, 524:765, 1036:1277 and 1548:1789 User fields for RUs signaled in Common field
EHT-SIG
content
13 (if present) and Number of Non-OFDMA Users (if present) channel 1

14 U-SIG Overflow and RU Allocation subfields for RUs overlapping with tone ranges EHT-SIG
–1789:–1548, –1277:–1036, -765:–524, –253:–12, 259:500, 771:1012, 1283:1524 and 1795:2036 User fields for RUs signaled in Common field
15 (if present) and Number of Non-OFDMA Users (if present)
content
channel 2
16
80MHz frequency subblock 3

U-SIG Overflow and RU Allocation subfields for RUs overlapping with tone ranges EHT-SIG

17 DUP
–2036:–1795, –1524:–1283, –1012:–771, –500:–259, 12:253, 524:765, 1036:1277 and 1548:1789
(if present) and Number of Non-OFDMA Users (if present)
User fields for RUs signaled in Common field content
channel 1

18
19 DUP
U-SIG Overflow and RU Allocation subfields for RUs overlapping with tone ranges
–1789:–1548, –1277:–1036, -765:–524, –253:–12, 259:500, 771:1012, 1283:1524 and 1795:2036 User fields for RUs signaled in Common field
EHT-SIG
content

20 (if present) and Number of Non-OFDMA Users (if present) channel 2

Low to high sub-carrier index

21 U-SIG Overflow and RU Allocation subfields for RUs overlapping with tone ranges EHT-SIG

22 –2036:–1795, –1524:–1283, –1012:–771, –500:–259, 12:253, 524:765, 1036:1277 and 1548:1789

(if present) and Number of Non-OFDMA Users (if present)
User fields for RUs signaled in Common field content
channel 1

23
EHT-SIG
24 U-SIG Overflow and RU Allocation subfields for RUs overlapping with tone ranges
–1789:–1548, –1277:–1036, -765:–524, –253:–12, 259:500, 771:1012, 1283:1524 and 1795:2036 User fields for RUs signaled in Common field content

25 (if present) and Number of Non-OFDMA Users (if present) channel 2

80MHz frequency subblock 2

26 U-SIG Overflow and RU Allocation subfields for RUs overlapping with tone ranges
–2036:–1795, –1524:–1283, –1012:–771, –500:–259, 12:253, 524:765, 1036:1277 and 1548:1789 User fields for RUs signaled in Common field
EHT-SIG
content
27 DUP (if present) and Number of Non-OFDMA Users (if present) channel 1

28 U-SIG Overflow and RU Allocation subfields for RUs overlapping with tone ranges EHT-SIG
29 DUP –1789:–1548, –1277:–1036, -765:–524, –253:–12, 259:500, 771:1012, 1283:1524 and 1795:2036
(if present) and Number of Non-OFDMA Users (if present)
User fields for RUs signaled in Common field content
channel 2
30
31 U-SIG Overflow and RU Allocation subfields for RUs overlapping with tone ranges
–2036:–1795, –1524:–1283, –1012:–771, –500:–259, 12:253, 524:765, 1036:1277 and 1548:1789 User fields for RUs signaled in Common field
EHT-SIG
content
32 (if present) and Number of Non-OFDMA Users (if present) channel 1

33 U-SIG Overflow and RU Allocation subfields for RUs overlapping with tone ranges EHT-SIG

34 –1789:–1548, –1277:–1036, -765:–524, –253:–12, 259:500, 771:1012, 1283:1524 and 1795:2036

(if present) and Number of Non-OFDMA Users (if present)
User fields for RUs signaled in Common field content
channel 2
80MHz frequency subblock 1

35 U-SIG Overflow and RU Allocation subfields for RUs overlapping with tone ranges EHT-SIG

36 DUP
–2036:–1795, –1524:–1283, –1012:–771, –500:–259, 2:253, 524:765, 1036:1277 and 1548:1789
(if present) and Number of Non-OFDMA Users (if present)
User fields for RUs signaled in Common field content
channel 1
37
38 DUP
U-SIG Overflow and RU Allocation subfields for RUs overlapping with tone ranges
–1789:–1548, –1277:–1036, -765:–524, –253:–12, 259:500, 771:1012, 1283:1524 and 1795:2036 User fields for RUs signaled in Common field
EHT-SIG
content

39 (if present) and Number of Non-OFDMA Users (if present) channel 2

40 U-SIG Overflow and RU Allocation subfields for RUs overlapping with tone ranges EHT-SIG

41 –2036:–1795, –1524:–1283, –1012:–771, –500:–259, 12:253, 524:765, 1036:1277 and 1548:1789

(if present) and Number of Non-OFDMA Users (if present)
User fields for RUs signaled in Common field content
channel 1

42
43 Figure 36-41—EHT-SIG content channels and their duplication in a 320 MHz PPDU for
44
45 OFDMA transmission and non-OFDMA transmission to multiple users
46
47 If (#1315)an RU or MRU for an allocation in a 320 MHz PPDU overlaps more than one of the subcarrier
48 ranges [–2036: –1795], [–1789: –1548], [–1524: –1283], [–1277: –1036], [–1012: –771], [–765: –524], [–
49
50 500: –259], [–253: –12], [12: 253], [259: 500], [524: 765], [771: 1012], [1036: 1277], [1283, 1524], [1548,
51 1789], or [1795: 2036], the corresponding RU Allocation subfields in the respective content channels shall
52 all refer to the same RU or MRU.
53
54 (#3311)(#4655)If the Bandwidth subfield and the Punctured Channel Indication subfield in the U-SIG field
55
56 of an EHT MU PPDU (see Table 36-28 (U-SIG field of an EHT MU PPDU)) indicates 320 MHz and
57 preamble is punctured, the mapping of the EHT-SIG content channels to 20 MHz subchannels shall be the
58 same as for a 320 MHz PPDU (see Figure 36-41 (EHT-SIG content channels and their duplication in a
59 320 MHz PPDU for OFDMA transmission and non-OFDMA transmission to multiple users)), with the
60 exception that punctured 20 MHz subchannels shall be excluded.
61
62
63
64
65

646 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 For EHT-SIG for non-OFDMA transmission to a single user or EHT sounding NDP, an EHT MU PPDU has
2 a single EHT-SIG content channel regardless of the PPDU bandwidth, which is duplicated on every 20 MHz
3
subchannel.
4
5
6 For EHT-SIG for non-OFDMA transmission to a single user or EHT sounding NDP, a 20 MHz PPDU
7 contains one EHT-SIG content channel as shown in Figure 36-42 (EHT-SIG content channel for a 20 MHz
8 PPDU for non-OFDMA transmission to a single user or EHT sounding NDP(#1629)).
9
10
Common field User Specific field
11
12 U-SIG Overflow and Number of Non-OFDMA Users one User field for non-OFDMA transmission to a single
EHT-SIG
13 content
(if present) user or zero User field for EHT sounding NDP
channel 1
14
15
Figure 36-42—EHT-SIG content channel for a 20 MHz PPDU for non-OFDMA transmission
16
17 to a single user or EHT sounding NDP(#1629)
18
19 For EHT-SIG for non-OFDMA transmission to a single user or EHT sounding NDP, a 40 MHz PPDU
20
contains one EHT-SIG content channel as shown in Figure 36-43 (EHT-SIG content channel for a 40 MHz
21
22 PPDU for non-OFDMA transmission to a single user or EHT sounding NDP(#1629)).
23
24 Common field User Specific field
Low to high sub-

25 EHT-SIG
carrier index

U-SIG Overflow and Number of Non- one User field for non-OFDMA transmission to a single
26 content
OFDMA Users (if present) user or zero User field for EHT sounding NDP
channel 1
27 DUP
EHT-SIG
28 U-SIG Overflow and Number of Non- one User field for non-OFDMA transmission to a single content
29 OFDMA Users (if present) user or zero User field for EHT sounding NDP channel 1
30
31 Figure 36-43—EHT-SIG content channel for a 40 MHz PPDU for non-OFDMA transmission
32 to a single user or EHT sounding NDP(#1629)
33
34
35 For EHT-SIG for non-OFDMA transmission to a single user or EHT sounding NDP, an 80 MHz PPDU
36 contains on EHT-SIG content channel as shown in Figure 36-44 (EHT-SIG content channel for an 80 MHz
37 PPDU for non-OFDMA transmission to a single user or EHT sounding NDP(#1629)).
38
39 Common field User Specific field
40
one User field for non-OFDMA transmission to a EHT-SIG
41 U-SIG Overflow and Number of Non-OFDMA Users (if
single user or zero User field for EHT sounding content
42 present)
NDP channel 1
43
Low to high sub-carrier index

DUP
44 one User field for non-OFDMA transmission to a EHT-SIG
U-SIG Overflow and Number of Non-OFDMA Users (if
45 present)
single user or zero User field for EHT sounding content
46 NDP channel 1
47 DUP
48 one User field for non-OFDMA transmission to a EHT-SIG
49 U-SIG Overflow and Number of Non-OFDMA Users (if
single user or zero User field for EHT sounding content
present)
50 NDP channel 1
51 DUP

52 U-SIG Overflow and Number of Non-OFDMA Users (if

one User field for non-OFDMA transmission to a EHT-SIG
53 single user or zero User field for EHT sounding content
present)
NDP channel 1
54
55
56 Figure 36-44—EHT-SIG content channel for an 80 MHz PPDU for non-OFDMA transmission
57
58 to a single user or EHT sounding NDP(#1629)
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 647

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 For EHT-SIG for non-OFDMA transmission to a single user or EHT sounding NDP, a 160 MHz PPDU
2 contains one EHT-SIG content channel as shown in Figure 36-45 (EHT-SIG content channel for a 160 MHz
3
PPDU for non-OFDMA transmission to a single user or EHT sounding NDP(#1629)).
4
5 Common field User Specific field
6 one User field for non-OFDMA transm ission to a EHT-SIG
7 U-SIG Overflow and Number of Non-OFDMA Users (if content
single user or zero User field for EHT sounding
present) channel 1
8 NDP
9
80MHz frequency subblock 2

DUP
one User field for non-OFDMA transmission to a EHT-SIG
10 U-SIG Overflow and Number of Non-OFDMA Users (if
single user or zero User field for EHT sounding content
11 present)
NDP channel 1
12 DUP
13 EHT-SIG
one User field for non-OFDMA transmission to a
14 U-SIG Overflow and Number of Non-OFDMA Users (if
single user or zero User field for EHT sounding content
present)
15 NDP channel 1
16
Low to high sub-carrier index

DUP
17 U-SIG Overflow and Number of Non-OFDMA Users (if
one User field for non-OFDMA transm ission to a EHT-SIG
single user or zero User field for EHT sounding content
18 present)
NDP channel 1
19
DUP
20 one User field for non-OFDMA transmission to a EHT-SIG
21 U-SIG Overflow and Number of Non-OFDMA Users (if
single user or zero User field for EHT sounding content
present)
22 NDP channel 1
80MHz frequency subblock 1

23 DUP
one User field for non-OFDMA transm ission to a EHT-SIG
24 U-SIG Overflow and Number of Non-OFDMA Users (if
single user or zero User field for EHT sounding content
25 present) channel 1
NDP
26
27 DUP
one User field for non-OFDMA transm ission to a EHT-SIG
U-SIG Overflow and Number of Non-OFDMA Users (if
28 present)
single user or zero User field for EHT sounding content
29 NDP channel 1

30
DUP
31 U-SIG Overflow and Number of Non-OFDMA Users (if
one User field for non-OFDMA transm ission to a EHT-SIG
single user or zero User field for EHT sounding content
32 present)
channel 1
NDP
33
34
35 Figure 36-45—EHT-SIG content channel for a 160 MHz PPDU for non-OFDMA transmission
36 to a single user or EHT sounding NDP(#1629)
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

648 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 For EHT-SIG for non-OFDMA transmission to a single user or EHT sounding NDP, a 320 MHz PPDU
2 contains one EHT-SIG content channel as shown in Figure 36-46 (EHT-SIG content channel for a 320 MHz
3
PPDU for non-OFDMA transmission to a single user or EHT sounding NDP(#1629)).
4
5 User Specific field
6 U-SIG Overflow and Number of Non-OFDMA Users (if
one User field for non-OFDMA transm ission to a EHT-SIG
7 DUP
present)
single user or zero User field for EHT sounding
NDP
content
channel 1
8
80MHz frequency subblock 4

9 U-SIG Overflow and Number of Non-OFDMA Users (if

one User field for non-OFDMA transmission to a
single user or zero User field for EHT sounding
EHT-SIG
content
10 DUP
present)
NDP channel 1
11
12 U-SIG Overflow and Number of Non-OFDMA Users (if
one User field for non-OFDMA transm ission to a EHT-SIG
single user or zero User field for EHT sounding content
13 DUP
present)
NDP channel 1
14
one User field for non-OFDMA transm ission to a
15 U-SIG Overflow and Number of Non-OFDMA Users (if
single user or zero User field for EHT sounding
EHT-SIG
content
present)
16 DUP
NDP channel 1
17
one User field for non-OFDMA transm ission to a
18 U-SIG Overflow and Number of Non-OFDMA Users (if
single user or zero User field for EHT sounding
EHT-SIG
content
present)
19 DUP
NDP channel 1
80MHz frequency subblock 3

20 one User field for non-OFDMA transm ission to a EHT-SIG

U-SIG Overflow and Number of Non-OFDMA Users (if
21 present)
single user or zero User field for EHT sounding content
channel 1
NDP
22 DUP

23 one User field for non-OFDMA transm ission to a EHT-SIG

U-SIG Overflow and Number of Non-OFDMA Users (if
24 present)
single user or zero User field for EHT sounding content
NDP channel 1
25 DUP

26 one User field for non-OFDMA transm ission to a EHT-SIG

U-SIG Overflow and Number of Non-OFDMA Users (if
27 present)
single user or zero User field for EHT sounding content
NDP channel 1
28 DUP

29 one User field for non-OFDMA transm ission to a EHT-SIG

U-SIG Overflow and Number of Non-OFDMA Users (if
30 present)
single user or zero User field for EHT sounding content
NDP channel 1
31 DUP
80MHz frequency subblock 2

32 U-SIG Overflow and Number of Non-OFDMA Users (if

one User field for non-OFDMA transmission to a EHT-SIG
single user or zero User field for EHT sounding content
33 present)
NDP channel 1
34 DUP

35 U-SIG Overflow and Number of Non-OFDMA Users (if

one User field for non-OFDMA transm ission to a EHT-SIG
36 present)
single user or zero User field for EHT sounding
NDP
content
channel 1
37 DUP

38 U-SIG Overflow and Number of Non-OFDMA Users (if

one User field for non-OFDMA transm ission to a
single user or zero User field for EHT sounding
EHT-SIG
content
39 present)
NDP channel 1
40 DUP

41 U-SIG Overflow and Number of Non-OFDMA Users (if

one User field for non-OFDMA transm ission to a
single user or zero User field for EHT sounding
EHT-SIG
content
42 present)
NDP channel 1
80MHz frequency subblock 1

DUP
43 one User field for non-OFDMA transm ission to a EHT-SIG
44 U-SIG Overflow and Number of Non-OFDMA Users (if
present)
single user or zero User field for EHT sounding content
NDP channel 1
45
DUP
46 one User field for non-OFDMA transm ission to a EHT-SIG
47 U-SIG Overflow and Number of Non-OFDMA Users (if
present)
single user or zero User field for EHT sounding content
NDP channel 1
48
DUP
49 one User field for non-OFDMA transm ission to a EHT-SIG
50 U-SIG Overflow and Number of Non-OFDMA Users (if
present)
single user or zero User field for EHT sounding content
NDP channel 1
51
52
53 Figure 36-46—EHT-SIG content channel for a 320 MHz PPDU for non-OFDMA transmission
54 to a single user or EHT sounding NDP(#1629)
55
56
57 36.3.12.9 EHT-STF
58
59 The main purpose of the EHT-STF field is to improve automatic gain control estimation in a MIMO
60 transmission. The EHT-STF field is positioned immediately after the EHT-SIG field for EHT MU PPDU.
61
62 The EHT-STF field is positioned immediately after the U-SIG field for EHT TB PPDU. The duration of the
63 EHT-STF field for EHT MU PPDU is T EHT-STF-NT (periodicity of 0.8 µs with 5 periods as given in Table 36-
64
65
18 (Timing-related constants)) and the duration of the EHT-STF field for EHT TB PPDU is T EHT-STF-T

Copyright © 2022 IEEE. All rights reserved. 649

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (periodicity of 1.6 µs with 5 periods as given in Table 36-18 (Timing-related constants)). For the EHT-STF
2 field, the M sequence is defined by Equation (27-22).
3
4
5 For a 20 MHz transmission, the frequency domain sequence for EHT MU PPDU is given by Equation (36-
6 25).
7
8
9 EHTS – 112:16:112 = HES – 112:16:112 (36-25)
10
11
12 where EHTSa:b:c means coefficients of the EHT-STF on every b subcarrier indices from a to c subcarrier
13
14 indices and coefficients on other subcarrier indices are set to zero and HES–112:16:112 is defined in
15 Equation (27-23).
16
17
18 For a 40 MHz transmission, the frequency domain sequence for EHT MU PPDU is given by Equation (36-
19 26).
20
21
22 EHTS – 240:16:240 = HES – 240:16:240 (36-26)
23
24
25 where HES–240:16:240 is defined in Equation (27-24).
26
27
28 For an 80 MHz transmission, the frequency domain sequence for EHT MU PPDU is given by Equation (36-
29 27).
30
31
32 EHTS – 496:16:496 = HES – 496:16:496 (36-27)
33
34
35
36 where HES–496:16:496 is defined in Equation (27-25).
37
38 For a 160 MHz transmission, the frequency domain sequence for EHT MU PPDU is given by Equation (36-
39
40
28).
41
42
43 EHTS –1008:16:1008 = HES – 1008:16:1008 (36-28)
44
45
46 where HES–1008:16:1008 is defined in Equation (27-26).
47
48
49 For a 320 MHz transmission, the frequency domain sequence for EHT MU PPDU is given by Equation (36-
50 29).
51
52
53 EHTS – 2032:16:2032 (36-29)
54 = { M 1 – M 0 – M 1 – M 0 M 1 – M 0 – M 1 – M 0
55
– M – 1 M 0 M – 1 M 0 – M – 1 M 0 M – 1 M    1 + j    2 
56
57
58 For a 20 MHz transmission, the frequency domain sequence for EHT TB PPDU is given by Equation (36-
59 30).
60
61
62 EHTS –120:8:120 = HES –120:8:120 (36-30)
63
64
65

650 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 where HES–120:8:120 is defined in Equation (27-28).

2
3
4 For a 40 MHz transmission, the frequency domain sequence for EHT TB PPDU is given by Equation (36-
5 31).
6
7
8 EHTS –248:8:248 = HES –248:8:248 (36-31)
9
10
11
12
where HES–248:8:248 is defined in Equation (27-30).
13
14 For an 80 MHz transmission, the frequency domain sequence for EHT TB PPDU is given by Equation (36-
15 32).
16
17
18
EHTS –504:8:504 = HES –504:8:504 (36-32)
19
20
21
22 where HES–504:8:504 is defined in Equation (27-32).
23
24 For a 160 MHz transmission, the frequency domain sequence for EHT TB PPDU is given by Equation (36-
25
26 33).
27
28
29 EHTS – 1016:8:1016 = HES –1016:8:1016 (36-33)
30
31
32 where HES–1016:8:1016 is defined in Equation (27-34).
33
34
35 For a 320 MHz transmission, the frequency domain sequence for EHT TB PPDU is given by Equation (36-
36 34).
37
38
39 EHTS – 2040:8:2040 (36-34)
40 = { M – 1 M – 1 – M – 1 M 0 – M 1 M 1 – M 1 – M 0 M – 1 M – 1 – M – 1
41
42 M 0  – M  1  M 1  – M  1  – M  0  – M  1  – M 1  M  1  – M 0  M  – 1  – M  – 1 
43 M – 1 M 0 – M 1 – M 1 M 1 – M 0 M – 1 – M – 1 M – 1 M    1 + j    2 
44
45 The values of the EHT-STF sequence at indices ±8, ±1016, ±1032, and ±2040 (#4571)are
46
47 EHTS8 = EHTS1016 = EHTS 1032 = EHTS 2040 = 0 .
48
49 (#8025)The coefficients in Equation (36-25) to Equation (36-34) are set to zero if those values are
50
51 corresponding to subcarrier indices that are not modulated in the Data field, such as subcarriers falling
52 within RUs that have no users assigned to them in OFDMA or subcarriers that are punctured.
53
54 (#2815)The time domain representation of the signal for EHT MU PPDU on transmit chain i TX shall be as
55
56 specified in Equation (36-35).
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 651

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2 i 
3
TX
r EHT-STF t (36-35)
4
5 N RU – 1
r r
6
7
= w EHT-STF-NT  t   --------------------------
N SS r total
-
r=0
8
N user – 1 N SS r u
9
10      Qk i
TX M r u + m EHTS k  exp  j2k F EHT  t – T CS EHT  M r u + m    
11 k  Kr u = 0 m=1
12
13 where
14
15 r is defined in 36.3.11.4 (Transmitted signal).
16
 Kr 
17  -------------------------- 
18  K EHT-STF 
19 r is the per-RU(#3111) power normalization factor and defined by r r
= ------------------------------------------- .
20  N RU – 1 2 
21

  r K r 
22  r=0 
23 Kr is the cardinality of the set of subcarriers K r as defined in 36.3.11 (Mathematical description
24
25 of signals).
26 EHT-STF
Kr is the set of subcarriers that have nonzero values within K r in the EHT-STF field(#3112).
27
28 T CS EHT  Mr u + m  represents the cyclic shift for spatial stream M r u + m as defined in 36.3.12.2.2 (Cyclic
29 shift for EHT modulated fields).
30
31 Qk is defined in 36.3.11 (Mathematical description of signals).
32 w TEHT-STF-NT is the windowing function for EHT-STF field in the EHT MU PPDU.
33
34 Kr
EHT-STF
is the cardinality of the set of subcarriers K r
EHT-STF
.
35
36 N RU N SS r total  N user r , and N SS r u are defined in Table 36-23 (Frequently used parameters).
37
38
39 (#3113)The time domain representation of the signal for an EHT TB PPDU transmitted by user u in the r-th
40 RU on transmit chain iTX shall be as specified in Equation (36-36).
41
42
43  i TX  1
 r u  t  = ---------------------------------------------------- w EHT-STF-T  t 
44 r EHT-STF (36-36)
45 EHT-STF
Kr N SS r total
46
47 N SS r u
48
49
    Q k u  i TX m EHTS k
 exp  j2 F EHT  t – T CS EHT  M r u + m    
k  Kr m = 1
50
51
52
53 where
54 w EHT-STF-T is the windowing function for EHT-STF field in the EHT TB PPDU.
55
56 Q k u is defined in 36.3.11 (Mathematical description of signals)(#3113).
57 Other variables in Equation (36-35) and Equation (36-36) are defined in 36.3.10 (Timing-related
58
59 parameters) and 36.3.11 (Mathematical description of signals)(#4665).
60
61 (#2662)It is recommended that the spatial mapping matrix applied to EHT-STF and beyond is chosen such
62 that it preserves the smoothness of the physical channel, achieved by limiting the variation of each element's
63 real and imaginary values in the spatial mapping matrix across successive tones within one RU.
64
65

652 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 36.3.12.10 EHT-LTF
2
3
The EHT-LTF field provides a means for the receiver to estimate the MIMO channel between the set of
4
5 constellation mapper outputs and the receive chains. In an EHT MU PPDU, the transmitter provides training
6 for N SS r total spatial streams used for the transmission of the PSDU(s) in the r-th RU/MRU. In an EHT TB
7
8 PPDU, the transmitter of user u in the r-th RU/MRU provides training for N SS r u spatial streams used for
9 the transmission of the PSDU. For each subcarrier in the r-th RU/MRU, the MIMO channel that can be
10 estimated is an N RX  N SS r total matrix. An EHT transmission has a preamble that contains EHT-LTF
11
12 symbols, where the data tones of each EHT-LTF symbol are multiplied by entries belonging to a matrix
13 PEHT-LTF , to enable channel estimation at the receiver. (#5473)When single stream pilots are used in 2or 4
14
15 EHT-LTF, the pilot subcarriers of each EHT-LTF symbol are multiplied by the entries of a matrix R EHT-LTF
16 to allow receivers to track phase and/or frequency offset during MIMO channel estimation using the EHT-
17 LTF. Single stream pilots shall be used for all spatial multiplexing modes (both UL and DL) defined in EHT
18
19 except when 1 EHT-LTF is used. P EHT-LTF is defined such that each modulated spatial stream in an
20 RU/MRU is active on all subcarriers in that RU/MRU for which the EHT-LTF sequence takes a nonzero
21 value(#1630).
22
23
24 In an EHT MU PPDU, N EHT-LTF is indicated in the EHT-SIG field. (#7045)In a non-OFDMA EHT MU
25
26
PPDU or EHT sounding NDP, the initial number of EHT-LTF symbols, initial N EHT-LTF , is a function of the
27 total number of spatial streams N SS as shown in Table 36-43 (Initial number of EHT-LTFs required for
28
29
different number of spatial streams(#4953)).
30
31
32 Table 36-43—Initial number of EHT-LTFs required for different number of spatial
33 streams(#4953)
34
35
36 N SS Initial N EHT-LTF
37
38 1 1
39
40 2 2
41
42 3–4 4
43
44 5–6 6
45
46 7–8 8
47
48
49
50 (#7045)In order to improve the MIMO channel estimation for the reception of non-OFDMA EHT MU
51 PPDU or EHT sounding NDP, the number of EHT-LTFs may be larger than the initial number of EHT-LTFs
52 determined by the total number of spatial streams. If additional EHT-LTFs are used, then the total number of
53 EHT-LTFs (which is signaled separately from N SS ) shall be no more than twice the initial number of EHT-
54
55 LTFs determined by the number of spatial streams as shown in Table 36-43 (Initial number of EHT-LTFs
56 required for different number of spatial streams(#4953)), and chosen from the set [2 4 8]. Supporting
57 additional EHT-LTFs is optional for the receiver, which is indicated by (#4954)the Maximum Number Of
58 Supported EHT-LTFs subfield of the EHT PHY Capabilities Information field.
59
60
61 In an EHT MU PPDU, N EHT-LTF is indicated in the EHT-SIG field. (#7045)In an OFDMA EHT MU PPDU,
62
63
N EHT-LTF may take a value that is greater than or equal to the maximum value of the initial number of EHT-
64 LTF symbols for each RU/MRU, where the initial number of EHT-LTF symbols is calculated as a function
65

Copyright © 2022 IEEE. All rights reserved. 653

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 of N SS r total (where r is the index of the RU/MRU) based on Table 36-43 (Initial number of EHT-LTFs
2
3 required for different number of spatial streams(#4953)).
4
5 (#2939)In an EHT TB PPDU, N EHT-LTF is indicated in the Trigger frame that triggers the transmission of the
6
7 PPDU. For an EHT TB PPDU, N EHT-LTF may be greater than or equal to the maximum value of the initial
8 number of EHT-LTF symbols for each RU/MRU r, which is calculated as a function of N SS r total , separately
9
10 based on Table 36-43 (Initial number of EHT-LTFs required for different number of spatial streams(#4953)).
11
12 An EHT PPDU supports three EHT-LTF types: 1× EHT-LTF, 2× EHT-LTF, and 4× EHT-LTF. Table 36-44
13 (EHT-LTF type and GI duration combinations for various EHT PPDU formats) defines whether a particular
14
15 EHT-LTF type and GI duration combination is (#4864)mandatory, optional, or not supported for each EHT
16 PPDU format.
17
18
19 Table 36-44—EHT-LTF type and GI duration combinations for various EHT PPDU formats
20
21
22 EHT-LTF type and GI
23 EHT MU PPDU EHT sounding NDP EHT TB PPDU
duration combination
24
25 1× EHT-LTF and 1.6 µs GI N/A N/A M
26
27 2× EHT-LTF and 0.8 µs GI M M N/A
28
29 2× EHT-LTF and 1.6 µs GI M M M
30
31 4× EHT-LTF and 0.8 µs GI O N/A N/A
32
33 4× EHT-LTF and 3.2 µs GI M O M
34
35 M = Mandatory
36 O = Optional
37 N/A = Not supported by the PPDU format
38 NOTE—1× EHT-LTF and 1.6 µs GI only for (#7230)UL non-OFDMA transmission for two or more users.
39
40 If a STA does not support transmission or reception of a particular PPDU format, then the M/O designation is
41 not applicable for the transmission or reception, respectively, of that PPDU format.
42
43
44
45 In an EHT MU PPDU, the combination of EHT-LTF type and GI duration is indicated in (#6836)EHT-SIG
46
field. In an EHT TB PPDU, the combination of EHT-LTF type and GI duration is indicated in the Trigger
47
48 frame that triggers the transmission of the PPDU. If an EHT PPDU is an EHT sounding NDP, the
49 combinations of EHT-LTF types and GI durations are listed in 36.3.18 (EHT sounding NDP).
50
51
The duration of each EHT-LTF symbol excluding GI is T EHT-LTF , defined in Equation (36-37).
52
53
54
55  T EHT-LTF-1X if 1  EHT-LTF

56 T EHT-LTF =  T EHT-LTF-2X if 2  EHT-LTF (36-37)
57 
58  T EHT-LTF-4X if 4  EHT-LTF
59
60
61 where T EHT-LTF-1X , T EHT-LTF-2X , and TEHT-LTF-4X are defined in Table 36-18 (Timing-related constants).
62
63
64
65

654 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 In a 20 MHz transmission, the 1 EHT-LTF sequence transmitted on subcarriers [–122: 122] is given by
2 Equation (27-41) with HELTF–122 122 replaced by EHTLTF–122 122 .
3
4
5 In a 20 MHz transmission, the 2 EHT-LTF sequence transmitted on subcarriers [–122: 122] is given by
6 Equation (27-42) with HELTF–122 122 replaced by EHTLTF–122 122 .
7
8
9 In a 20 MHz transmission, the 4 EHT-LTF sequence transmitted on subcarriers [–122: 122] is given by
10 Equation (27-43) with HELTF–122 122 replaced by EHTLTF–122 122 .
11
12
13 In a 40 MHz transmission, the 1 EHT-LTF sequence transmitted on subcarriers [–244: 244] is given by
14 Equation (27-44) with HELTF–244 244 replaced by EHTLTF–244 244 .
15
16
17 In a 40 MHz transmission, the 2 EHT-LTF sequence transmitted on subcarriers [–244: 244] is given by
18 Equation (27-45) with HELTF–244 244 replaced by EHTLTF–244 244 .
19
20
21 In a 40 MHz transmission, the 4 EHT-LTF sequence transmitted on subcarriers [–244: 244] is given by
22 Equation (27-46) with HELTF–244 244 replaced by EHTLTF–244 244 .
23
24
25 In an 80 MHz transmission, the 1 EHT-LTF sequence transmitted on subcarriers [–500: 500] is given by
26 Equation (27-47) with HELTF–500 500 replaced by EHTLTF–500 500 .
27
28
29 In an 80 MHz transmission, the 2 EHT-LTF sequence transmitted on subcarriers [–500: 500] is given by
30 Equation (27-48) with HELTF–500 500 replaced by EHTLTF–500 500 .
31
32
33 In an 80 MHz transmission, the 4 EHT-LTF sequence transmitted on subcarriers [–500: 500] is given by
34 Equation (27-49) with HELTF–500 500 replaced by EHTLTF–500 500 .
35
36
37 In a 160 MHz transmission using a 1 EHT-LTF, where the 1 EHT-LTF sequence is given by Equation (27-
38 50) with HELTF–1012 1012 replaced by EHTLTF–1012 1012 .
39
40
41 In a 160 MHz transmission using a 2 EHT-LTF, where the 2 EHT-LTF sequence is given by Equation (27-
42 51) with HELTF–1012 1012 replaced by EHTLTF–1012 1012 .
43
44
45 In a 160 MHz transmission using a 4 EHT-LTF, where the 4 EHT-LTF sequence is given by
46 Equation (27-52) with HELTF–1012 1012 replaced by EHTLTF–1012 1012 .
47
48
49 In a 320 MHz transmission using a 1 EHT-LTF, where the 1 EHT-LTF sequence is given by Equation (36-
50 38)(#1998).
51
52
53 EHTLTF – 2036 2036 = (36-38)
54  LTF 80MHz_1st_1x 0 23 LTF 80MHz_2nd_1x 0 23 LTF 80MHz_3rd_1x 0 23 LTF 80MHz_4th_1x 
55
56 where
57
58 0 23 means 23 consecutive 0s.
59 LTF 80MHz_1st_1x =  LTF 80MHz_left_1x 0 LTF 80MHz_right_1x 
60
61 LTF 80MHz_2nd_1x =  LTF 80MHz_left_1x 0 LTF 80MHz_right_1x 
62 LTF 80MHz_3rd_1x =  –L TF80MHz_left_1x 0 – L TF 80MHz_right_1x 
63
64 LTF 80MHz_4th_1x =  – L TF 80MHz_left_1x 0 –L TF80MHz_right_1x 
65

Copyright © 2022 IEEE. All rights reserved. 655

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 LTF 80MHz_left_1x and LTF 80MHz_right_1x are defined in 27.3.11.10 (HE-LTF).

2
3
4 In a 320 MHz transmission using a 2 EHT-LTF, where the 2 EHT-LTF sequence is given by Equation (36-
5 39)(#1998).
6
7
8 EHTLTF –2036,2036 = (36-39)
9 {LTF 80MHz_2x  1:245  LTF 80MHz_2x  246:500  0 LTF 80MHz_2x  502:756  LTF 80MHz_2x  757:1001  0 23
10 LTF 80MHz_2x  1:245  – L TF 80MHz_2x  246:500  0 LTF 80MHz_2x  502:756  – L TF 80MHz_2x  757:1001  0 23
11 LTF 80MHz_2x  1:245  – L TF 80MHz_2x  246:500  0 – L TF 80MHz_2x  502:756  LTF 80MHz_2x  757:1001  0 23
12 LTF 80MHz_2x  1:245  LTF 80MHz_2x  246:500  0 – L TF 80MHz_2x  502:756  – L TF 80MHz_2x  757:1001  
13
14
15 where(#6093)
16 LTF 80MHz_2x = [+1, 0, +1, 0, +1, 0, –1, 0, –1, 0, +1, 0, –1, 0, +1, 0, +1, 0, +1, 0, +1, 0, –1, 0, +1, 0, –1, 0,
17
18 +1, 0, +1, 0, –1, 0, –1, 0, +1, 0, –1, 0, –1, 0, –1, 0, –1, 0, –1, 0, +1, 0, –1, 0, +1, 0, –1, 0, +1, 0,
19 +1, 0, –1, 0, –1, 0, +1, 0, –1, 0, +1, 0, +1, 0, +1, 0, +1, 0, –1, 0, +1, 0, –1, 0, –1, 0, –1, 0, +1, 0,
20 +1, 0, –1, 0, +1, 0, +1, 0, +1, 0, +1, 0, +1, 0, –1, 0, +1, 0, –1, 0, –1, 0, –1, 0, –1, 0, –1, 0, +1, 0,
21 +1, 0, –1, 0, +1, 0, +1, 0, –1, 0, –1, 0, +1, 0, +1, 0, +1, 0, –1, 0, –1, 0, +1, 0, +1, 0, –1, 0, +1, 0,
22 –1, 0, –1, 0, –1, 0, –1, 0, +1, 0, –1, 0, +1, 0, –1, 0, –1, 0, +1, 0, +1, 0, –1, 0, +1, 0, +1, 0, +1, 0,
23
24 +1, 0, +1, 0, –1, 0, +1, 0, –1, 0, –1, 0, +1, 0, +1, 0, –1, 0, –1, 0, +1, 0, –1, 0, +1, 0, +1, 0, +1, 0,
25 +1, 0, –1, 0, +1, 0, –1, 0, –1, 0, –1, 0, +1, 0, +1, 0, –1, 0, +1, 0, +1, 0, +1, 0, +1, 0, +1, 0, –1, 0,
26 +1, 0, –1, 0, –1, 0, –1, 0, +1, 0, +1, 0, +1, 0, +1, 0, –1, 0, –1, 0, +1, 0, –1, 0, +1, 0, +1, 0, +1, 0,
27 +1, 0, –1, 0, +1, 0, +1, 0, +1, 0, +1, 0, –1, 0, –1, 0, +1, 0, –1, 0, –1, 0, –1, 0, –1, 0, –1, 0, +1, 0,
28 –1, 0, +1, 0, +1, 0, +1, 0, +1, 0, –1, 0, –1, 0, +1, 0, –1, 0, +1, 0, +1, 0, +1, 0, +1, 0, –1, 0, +1, 0,
29
30 –1, 0, –1, 0, –1, 0, +1, 0, +1, 0, –1, 0, +1, 0, +1, 0, +1, 0, +1, 0, +1, 0, –1, 0, +1, 0, –1, 0, +1, 0,
31 +1, 0, +1, 0, –1, 0, +1, 0, –1, 0, +1, 0, +1, 0, +1, 0, –1, 0, –1, 0, +1, 0, –1, 0, +1, 0, +1, 0, +1, 0,
32 –1, 0, –1, 0, +1, 0, –1, 0, +1, 0, +1, 0, +1, 0, +1, 0, –1, 0, +1, 0, +1, 0, +1, 0, +1, 0, –1, 0, –1, 0,
33 +1, 0, –1, 0, –1, 0, –1, 0, –1, 0, –1, 0, +1, 0, –1, 0, +1, 0, –1, 0, –1, 0, –1, 0, +1, 0, +1, 0, –1, 0,
34 +1, 0, –1, 0, –1, 0, –1, 0, –1, 0, +1, 0, –1, 0, +1, 0, +1, 0, +1, 0, –1, 0, –1, 0, +1, 0, –1, 0, –1, 0,
35
36 –1, 0, –1, 0, –1, 0, +1, 0, –1, 0, +1, 0, +1, 0, –1, 0, –1, 0, +1, 0, 0, 0, 0, 0, 0, 0, –1, 0, –1, 0, –1,
37 0, –1, 0, –1, 0, –1, 0, –1, 0, +1, 0, +1, 0, –1, 0, +1, 0, –1, 0, –1, 0, –1, 0, –1, 0, +1, 0, –1, 0, +1,
38 0, –1, 0, –1, 0, +1, 0, +1, 0, –1, 0, +1, 0, +1, 0, +1, 0, +1, 0, +1, 0, –1, 0, +1, 0, –1, 0, +1, 0, –1,
39 0, –1, 0, +1, 0, +1, 0, –1, 0, +1, 0, –1, 0, –1, 0, –1, 0, –1, 0, +1, 0, –1, 0, +1, 0, +1, 0, +1, 0, –1,
40 0, –1, 0, +1, 0, –1, 0, –1, 0, –1, 0, –1, 0, –1, 0, +1, 0, –1, 0, +1, 0, –1, 0, –1, 0, –1, 0, –1, 0, –1,
41
42 0, +1, 0, –1, 0, +1, 0, +1, 0, –1, 0, –1, 0, +1, 0, +1, 0, –1, 0, –1, 0, –1, 0, +1, 0, +1, 0, –1, 0, +1,
43 0, –1, 0, –1, 0, –1, 0, –1, 0, +1, 0, –1, 0, +1, 0, –1, 0, –1, 0, +1, 0, +1, 0, –1, 0, +1, 0, +1, 0, +1,
44 0, +1, 0, +1, 0, –1, 0, +1, 0, –1, 0, –1, 0, +1, 0, +1, 0, –1, 0, –1, 0, +1, 0, –1, 0, +1, 0, +1, 0, +1,
45 0, +1, 0, –1, 0, +1, 0, –1, 0, –1, 0, –1, 0, +1, 0, +1, 0, –1, 0, +1, 0, +1, 0, +1, 0, +1, 0, +1, 0, –1,
46 0, +1, 0, –1, 0, +1, 0, +1, 0, +1, 0, +1, 0, +1, 0, +1, 0, –1, 0, –1, 0, +1, 0, –1, 0, +1, 0, +1, 0, +1,
47
48 0, +1, 0, –1, 0, +1, 0, +1, 0, +1, 0, +1, 0, –1, 0, –1, 0, +1, 0, –1, 0, –1, 0, –1, 0, –1, 0, –1, 0, +1,
49 0, –1, 0, +1, 0, +1, 0, +1, 0, +1, 0, –1, 0, –1, 0, +1, 0, –1, 0, +1, 0, +1, 0, +1, 0, +1, 0, –1, 0, +1,
50 0, –1, 0, –1, 0, –1, 0, +1, 0, +1, 0, –1, 0, +1, 0, +1, 0, +1, 0, +1, 0, +1, 0, –1, 0, +1, 0, –1, 0, +1,
51 0, +1, 0, –1, 0, –1, 0, +1, 0, +1, 0, +1, 0, –1, 0, –1, 0, –1, 0, +1, 0, –1, 0, +1, 0, –1, 0, –1, 0, –1,
52 0, +1, 0, +1, 0, –1, 0, +1, 0, –1, 0, –1, 0, –1, 0, –1, 0, +1, 0, –1, 0, –1, 0, –1, 0, –1, 0, +1, 0, +1,
53
54 0, –1, 0, +1, 0, +1, 0, +1, 0, +1, 0, +1, 0, –1, 0, +1, 0, +1, 0, +1, 0, +1, 0, +1, 0, –1, 0, –1, 0, +1,
55 0, –1, 0, +1, 0, +1, 0, +1, 0, +1, 0, –1, 0, +1, 0, –1, 0, –1, 0, –1, 0, +1, 0, +1, 0, –1, 0, +1, 0, +1,
56 0, +1, 0, +1, 0, +1, 0, –1, 0, +1, 0, +1].
57 0 23 means 23 consecutive 0s.
58
59
60 In a 320 MHz transmission using a 4 EHT-LTF, where the 4 EHT-LTF sequence is given by Equation (36-
61 40)(#1998).
62
63
64
65

656 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 EHTLTF – 2036 2036 = (#5722) (36-40)

2  LTF 80MHz_sublock_left_4x 0 5 LTF 80MHz_subblock_right_4x 0 23
3
4 LTF 80MHz_subblock_left_4x 0 5 – L TF 80MHz_subblock_right_4x 0 23
5 – L TF 80MHz_subblock_left_4x 0 5 – L TF 80MHz_subblock_right_4x 0 23
6 – L TF 80MHz_subblock_left_4x 0 5 LTF 80MHz_subblock_right_4x 
7
8 where
9
10 LTF 80MHz_subblock_left_4x = [+1, –1, –1, –1, –1, +1, –1, –1, +1, –1, –1, –1, +1, +1, –1, –1, –1, +1, –1, –1, +1,
11 –1, +1, +1, +1, –1, +1, –1, +1, –1, –1, –1, –1, +1, +1, +1, +1, +1, –1, –1, +1, –1, +1, –1, –1, –1,
12 +1, +1, –1, –1, +1, –1, –1, –1, +1, +1, +1, –1, –1, +1, +1, –1, –1, +1, –1, +1, +1, –1, +1, –1, +1,
13
14 +1, +1, –1, +1, –1, +1, +1, +1, +1, +1, +1, –1, –1, –1, +1, –1, +1, –1, –1, –1, +1, –1, –1, +1, +1,
15 +1, +1, +1, +1, –1, +1, –1, +1, +1, –1, +1, –1, +1, –1, +1, –1, +1, –1, –1, +1, +1, +1, +1, –1,
16 –1, –1, –1, –1, –1, –1, –1, +1, –1, –1, +1, –1, –1, +1, +1, +1, –1, +1, –1, –1, –1, +1, +1, +1, –1,
17 +1, +1, –1, –1, +1, –1, –1, –1, +1, +1, +1, +1, –1, +1, +1, +1, +1, +1, +1, –1, +1, –1, –1, +1,
18 –1, +1, –1, –1, +1, +1, +1, +1, +1, –1, +1, +1, –1, –1, +1, +1, +1, –1, +1, +1, –1, +1, +1, –1,
19
20 –1, +1, +1, –1, –1, –1, –1, +1, +1, +1, +1, +1, –1, +1, +1, +1, +1, +1, –1, +1, –1, +1, –1, –1, +1,
21 –1, –1, –1, –1, –1, +1, –1, –1, –1, +1, +1, –1, +1, –1, +1, –1, –1, –1, –1, –1, +1, +1, +1, +1, –1,
22 +1, –1, –1, +1, +1, –1, –1, –1, +1, +1, +1, +1, +1, –1, +1, –1, +1, –1, –1, +1, +1, +1, –1, +1, +1,
23 +1, +1, +1, –1, +1, +1, –1, +1, –1, +1, –1, –1, –1, –1, –1, +1, –1, –1, –1, –1, –1, +1, +1, +1, +1,
24 –1, –1, +1, +1, –1, –1, +1, –1, –1, +1, –1, –1, –1, +1, +1, –1, –1, +1, –1, –1, –1, –1, –1, +1, +1,
25
26 –1, +1, –1, +1, +1, –1, +1, –1, –1, –1, –1, –1, –1, +1, –1, –1, –1, –1, +1, +1, +1, –1, +1, +1, –1,
27 –1, +1, –1, –1, –1, +1, +1, +1, –1, +1, –1, +1, –1, –1, –1, +1, –1, +1, –1, +1, –1, –1, –1, +1, –1,
28 –1, +1, –1, +1, +1, –1, –1, –1, +1, +1, –1, –1, –1, –1, +1, –1, +1, +1, –1, +1, –1, +1, +1, +1, +1,
29 +1, +1, –1, –1, +1, –1, –1, –1, +1, –1, +1, –1, –1, –1, +1, +1, +1, +1, +1, +1, –1, +1, –1, +1, +1,
30 +1, –1, +1, –1, +1, +1, –1, +1, –1, –1, +1, +1, –1, –1, +1, +1, +1, –1, –1, –1, +1, –1, –1, +1, +1,
31
32 –1, –1, –1, +1, –1, +1, –1, –1, +1, +1, +1, +1, +1, –1, –1, –1, –1, +1, –1, +1, –1, +1, +1, +1, –1,
33 +1, –1, –1, +1, –1, –1, –1, +1, +1, –1, –1, –1, +1, –1, –1, +1, –1, –1, –1, –1, +1, –1, +1, +1, –1,
34 –1, –1, +1, –1, –1].
35 LTF 80MHz_subblock_right_4x = [–1, –1, +1, –1, +1, +1, +1, +1, +1, +1, –1, –1, –1, –1, +1, –1, –1, +1, –1, –1, –1,
36
37 +1, +1, –1, –1, –1, +1, –1, –1, +1, –1, +1, +1, +1, –1, +1, –1, +1, –1, –1, –1, –1, +1, +1, +1, +1,
38 +1, –1, –1, +1, –1, +1, –1, –1, –1, +1, +1, –1, –1, +1, –1, –1, –1, +1, +1, +1, –1, –1, +1, +1, –1,
39 –1, +1, –1, +1, +1, –1, +1, –1, +1, +1, +1, –1, +1, –1, +1, +1, +1, +1, +1, +1, –1, –1, –1, +1,
40 –1, +1, –1, –1, –1, +1, –1, –1, +1, +1, +1, +1, +1, +1, –1, +1, –1, +1, +1, –1, +1, –1, –1, –1, –1,
41
42 +1, +1, –1, –1, –1, +1, +1, –1, +1, –1, –1, +1, –1, –1, –1, +1, –1, +1, –1, +1, –1, –1, –1, +1, –1,
43 +1, –1, +1, +1, +1, –1, –1, –1, +1, –1, –1, +1, +1, –1, +1, +1, +1, –1, –1, –1, –1, +1, –1, –1, –1,
44 –1, –1, –1, +1, –1, +1, +1, –1, +1, –1, +1, +1, –1, –1, –1, –1, –1, +1, –1, –1, +1, +1, –1, –1, –1,
45 +1, –1, –1, +1, –1, –1, +1, +1, –1, –1, +1, +1, +1, +1, –1, –1, –1, –1, –1, +1, –1, –1, –1, –1, –1,
46 +1, –1, +1, –1, +1, +1, –1, +1, +1, +1, +1, +1, –1, +1, +1, +1, –1, –1, +1, –1, +1, –1, +1, +1, +1,
47
48 +1, +1, –1, –1, –1, +1, +1, –1, –1, –1, –1, –1, –1, –1, –1, +1, +1, +1, +1, +1, –1, +1, –1, +1, –1,
49 –1, +1, +1, +1, –1, +1, +1, +1, +1, +1, –1, +1, +1, –1, +1, –1, +1, –1, –1, –1, –1, –1, +1, –1, –1,
50 –1, –1, –1, +1, +1, +1, +1, –1, –1, +1, +1, –1, –1, +1, –1, –1, +1, –1, –1, –1, +1, +1, –1, –1, +1,
51 –1, –1, –1, –1, –1, +1, +1, –1, +1, –1, +1, +1, –1, +1, –1, –1, –1, –1, –1, –1, +1, –1, –1, –1, –1,
52 +1, +1, +1, –1, +1, +1, –1, –1, +1, –1, –1, –1, +1, +1, +1, –1, +1, –1, –1, –1, +1, +1, –1, +1, +1,
53
54 –1, +1, +1, +1, +1, +1, +1, +1, +1, –1, –1, –1, –1, +1, +1, –1, +1, –1, +1, –1, +1, –1, +1, –1, –1,
55 +1, –1, +1, –1, –1, –1, –1, –1, –1, +1, +1, –1, +1, +1, +1, –1, +1, –1, +1, +1, +1, –1, –1, –1, –1,
56 –1, –1, +1, –1, +1, –1, –1, –1, +1, –1, +1, –1, –1, +1, –1, +1, +1, –1, –1, +1, +1, –1, –1, –1, +1,
57 +1, +1, –1, +1, +1, –1, –1, +1, +1, +1, –1, +1, –1, +1, +1, –1, –1, –1, –1, –1, +1, +1, +1, +1, –1,
58 +1, –1, +1, –1, –1, –1, +1, –1, +1, +1, –1, +1, +1, +1, –1, –1, +1, +1, +1, –1, +1, +1, –1, +1, +1,
59
60 +1, +1, –1].
61 05 means 5 consecutive 0s.
62
63
0 23 means 23 consecutive 0s.
64
65

Copyright © 2022 IEEE. All rights reserved. 657

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#1584)For a non-OFDMA transmission when preamble puncturing is applied, a single large size MRU
2 spans the nonpunctured portions of the PPDU bandwidth. In the puncturing case, the values of the EHT-LTF
3
sequence (defined in Equation (27-41) to Equation (27-52) and Equation (36-38) to Equation (36-40)) are
4
5 replaced by zero for subcarriers that fall outside the aforementioned single large size MRU. This is also
6 applicable to an EHT sounding NDP with preamble puncturing. The mapping of the non-OFDMA
7 puncturing pattern signaled in the U-SIG field(#5657) the corresponding large size MRU is defined in
8 Table 36-30 (Definition of the Punctured Channel Information field in the U-SIG for an EHT MU PPDU
9
using non-OFDMA transmissions(#8011)(#2402)).
10
11
12 (#1584)For an OFDMA transmission, the values of the EHT-LTF sequence (defined in Equation (27-41) to
13 Equation (27-52) and Equation (36-38) to Equation (36-40)) are replaced by zero, for all subcarriers that
14 belong to unassigned RUs as well as for DC tones or null subcarriers.
15
16
17 The generation of the time domain EHT-LTF symbols in Figure 36-47 (Generation of EHT-LTF symbols in
18 an EHT MU PPDU and EHT TB PPDU), where AkEHT-LTF is given by Equation (36-41).
19
20
 AEHT  LTF 1,n
k
21
22
23 EHT-LTFk × IDFT
24
25
26

...
27
...

...

CSD QEHT-LTF
k

1: N ss ,r ,total
28
29
30
31 × IDFT
32
33
 AEHT
k

 LTF  N
34 SS ,r ,total , n

35
36 Figure 36-47—Generation of EHT-LTF symbols in an EHT MU PPDU and EHT TB PPDU
37
38
39
40 k  R EHT-LTF if k  K Pilot and EHT-LTF with single stream pilot is used
41 A EHT-LTF =  (#5530) (36-41)
42  P EHT-LTF otherwise
43
44 where
45
46 K Pilot is the set of subcarrier indices for the pilot subcarriers as defined in 36.3.2.4 (Pilot subcarriers).
47 R EHT-LTF is a N EHT-LTF  N EHT-LTF matrix whose elements are defined in Equation (36-42).
48
49
50  R EHT-LTF  m n =  P EHT-LTF  1 n 1  m n  N EHT-LTF (36-42)
51
52
53 P EHT-LTF is defined in Equation (36-43).
54
55
56  P 4  4 N EHT-LTF = 1 2 4
57 
58 P EHT-LTF =  P 6  6 N EHT-LTF = 6 (36-43)
59 
60  P 8  8 N EHT-LTF = 8
61
62 where P 4  4 , P 6  6 , and P 8  8 are defined in Equation (19-27), Equation (21-44), and Equation (21-45),
63
64 respectively.
65

658 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The generation of the time domain symbols of (#4580)a 1 EHT-LTF is equivalent to modulating every four
2 subcarriers in an OFDM symbol of 12.8 µs excluding GI, and then transmitting only the first one-fourth of
3
the OFDM symbol in the time domain as shown in Figure 36-48 (Generation of 1× EHT-LTF symbols).
4
5
6 Trucate ¼ of Insert GI Analog
7 IDFT and
Modulate every 4 tone
time symbol Window and RF
8

Spatial Mapping
9 AEHT-LTF Insert GI
CSD per Trucate ¼ of Analog
10 SS
IDFT time symbol
and
Window and RF
11

...
12
...

...

...

...

...
13 CSD per Trucate ¼ of Insert GI Analog
IDFT and
14 SS time symbol Window and RF

15
16 Figure 36-48—Generation of 1× EHT-LTF symbols
17
18
19
20 (#4865)There are no pilot subcarriers in the EHT-LTF field when 1 EHT-LTF is used.
21
22 The generation of the time domain symbols of a 2 EHT-LTF is equivalent to modulating every two
23
24
subcarriers in an OFDM symbol of 12.8 µs excluding GI, and then transmitting only the first half of the
25 OFDM symbol in the time domain as shown in Figure 36-49 (Generation of 2× EHT-LTF symbols).
26
27 Trucate ½ of Insert GI
Analog
IDFT and
Modulate every 2 tone

28 time symbol Window and RF

Spatial Mapping

29
AEHT-LTF

30 CSD per Trucate ½ of Insert GI Analog

IDFT and
31 SS time symbol Window
and RF

32
...

...
...

...

...

...
33
34 CSD per
IDFT
Trucate ½ of Insert GI
and Analog
SS time symbol and RF
35 Window

36
37
38
Figure 36-49—Generation of 2× EHT-LTF symbols
39
40
41 (#4865)In an EHT MU PPDU, the time domain representation of the waveform transmitted on the transmit
42
chain iTX shall be as described in Equation (36-44).
43
44
45 N EHT-LTF – 1 N RU – 1
46  i TX  1 k Kr
47 r EHT-LTF  t  = ---------------------------------  w TEHT-LTF  t – nT EHT-LTF   ---------------------------------------------------
EHT-LTF
- (36-44)
48 N RU – 1
2
n=0 r=0 N SS r total K r
49  k Kr
50 r=0
51
N user r – 1 N SS r u
52 k
53    (  Qk i
TX  M r u + m   A EHT-LTF   M r u + m   n + 1  EHT-LTF k u m
54 k  Kr u=0 m=1
55
56
57 exp  j2k F EHT  t – nT EHT-LTF-SYM – T GI EHT-LTF – T CS EHT  M r u + m   )
58
59
60 In an EHT TB PPDU, the time domain representation of the waveform of user u in the r-th RU transmitted
61
on the transmit chain iTX shall be as described in Equation (36-45).
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 659

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 N EHT-LTF – 1
2  i TX  1
3 r EHT-LTF  r u  t  = ----------------------------------------------------
EHT-LTF  w TEHT-LTF  t – nT EHT-LTF  (36-45)
4 N SS r total K r n=0
5 N SS r u
6 k
7   (  Q k u  i
TX m  A EHT-LTF   M r u + m   n + 1  EHT-LTF k u m
k  Kr m = 1
8
9
10
exp  j2k F EHT  t – nT EHT-LTF-SYM – T GI EHT-LTF – T CS EHT  M r u + m   )
11
12
13
14 In Equation (36-44) and Equation (36-45), the following notations are used.
15 N user r is the number of EHT MU PPDU recipients (see Table 36-23 (Frequently used parameters)) in
16
17
RU r.
18 EHT-LTF k u m is the EHT-LTF sequence applied on subcarrier k for spatial stream m of user u.
19
EHT-LTF k u m = EHT-LTFk for all values of u and m(#7233).
20
21 r is defined in 36.3.11 (Mathematical description of signals).
22
23 N EHT-LTF is the number of OFDM symbols in the EHT-LTF field.
24 T CS EHT  Mr u + m  represents the cyclic shift for the spatial stream M r u + m as defined in 36.3.12.2.2
25
26 (Cyclic shift for EHT modulated fields)(#7234).
27 Q k and Q k u are defined in 36.3.11 (Mathematical description of signals).
28 k
29 A EHT-LTF is defined in Equation (36-41).
30
31
M r u is given in Table 36-23 (Frequently used parameters) for (#6471)EHT MU PPDU. For an EHT
32 TB PPDU, it is given by the TXVECTOR parameter STARTING_STS_NUM.
33 Kr is the set of subcarrier indices for the tones in the RU r as defined in 36.3.11 (Mathematical
34
35 description of signals).
36 K r and K r
EHT-LTF
are defined in 36.3.11.4 (Transmitted signal).
37
EHT-LTF
38 K r is the cardinality of the set of modulated subcarriers within K r for the EHT-LTF field as
39
40
defined in 27.3.10 (Mathematical description of signals).
41 Other variables in Equation (36-45) and Equation (36-46) are defined in 36.3.10 (Timing-related
42 parameters) and 36.3.11 (Mathematical description of signals)(#4665).
43
44 36.3.12.11 EHT preamble of preamble punctured EHT MU PPDU(#1952)
45
46
47 36.3.12.11.1 General
48
49 (#7235)(#7236)Preamble puncturing refers to the transmission of a PPDU in which no signal is present in at
50 least one of the 20 MHz subchannels within the PPDU bandwidth(#1313).
51
52
53 (#7236)Preamble puncturing might be the result of the unavailability of 20 MHz subchannel(s) within the
54 PPDU bandwidth, such as a busy channel indicated by the CCA or the setting of the Disabled Subchannel
55 Bitmap field in the EHT Operations element (see 9.4.2.311 (EHT Operation element)).
56
57
58
(#1585)(#6442)(#7236)Preamble puncturing may exist in an EHT MU PPDU transmitted in the DL or the
59 UL and in an EHT TB PPDU transmitted by a non-AP STA in the UL. (#7751)For an EHT MU PPDU, the
60 U-SIG (#5657) and the EHT-SIG fields include information on preamble puncturing.
61
62 (#4685)(#7236)The preamble puncturing resolution shall be 20 MHz for an EHT MU PPDU using OFDMA
63
64
transmission for a bandwidth larger than 40 MHz and using non-OFDMA transmission for 80 MHz and
65 160 MHz PPDU bandwidths. In other words, puncturing a subchannel smaller than a 242-tone RU is not

660 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 allowed in the cases above. The preamble puncturing resolution shall be 40 MHz for an EHT MU PPDU
2 using non-OFDMA transmission for a 320 MHz PPDU bandwidth. In other words, puncturing a subchannel
3
smaller than a 484-tone RU is not allowed in a 320 MHz PPDU bandwidth.
4
5
6 (#2709)(#7317)Preamble puncturing shall not be applied in the primary 20 MHz channel (#7236)of an EHT
7 MU PPDU.
8
9
(#7236)Transmission of an EHT PPDU with preamble puncturing is subject to the restrictions defined in
10
11 36.3.19.1 (Transmit spectral mask).
12
13 36.3.12.11.2 Preamble puncturing for EHT MU PPDUs in an OFDMA transmission(#7236)
14
15
Preamble puncturing may exist in PPDUs transmitted to one or more users using OFDMA transmission.
16
17 (#7236)The U-SIG (#5657) and EHT-SIG fields include information on the preamble puncturing of the
18 PPDU.
19
20 (#7236)The U-SIG field(#5657) contains signaling of the punctured 20 MHz channels in the 80 MHz
21
frequency subblock(#6443)(#1279) where it belongs (see Table 36-28 (U-SIG field of an EHT MU PPDU)).
22
23
24 (#1586)(#8130)The following (#7236)punctured patterns are defined for an 80 MHz frequency
25 subblock(#6443): 1111, 0111, 1011, 1101, 1110, 0011, 1100, and 1001. The puncturing pattern may vary for
26 different 80 MHz frequency subblocks. In these patterns (#7007)a “1” denotes a nonpunctured 20 MHz
27
subchannel and a “0” denotes a punctured 20 MHz subchannel.
28
29
30 (#8130)(#7236)The EHT-SIG field contains an indication of the punctured channels in the entire bandwidth
31 of the PPDU by using the “Punctured 242-tone RU” entry in the RU Allocation subfield (see Table 36-34
32 (RU Allocation subfield)).
33
34
35 (#5488)The puncturing pattern “0000” represents a fully unoccupied 80 MHz frequency subblock(#6443)
36 and is also a valid pattern, however contrary to the other puncturing patterns, there is no signaling in such an
37 80 MHz frequency subblock(#6443).
38
39
36.3.12.11.3 Preamble puncturing for EHT MU PPDUs in a non-OFDMA transmission(#7236)
40
41
42 (#7237)(#7236)In the preamble puncturing of a non-OFDMA transmission, at least one 20 MHz subchannel,
43 in the pre-EHT modulated fields, is not occupied and the EHT modulated fields consist of a single large size
44 MRU that occupies all the nonpunctured 20 MHz channel within the PPDU bandwidth. The supported
45
MRUs for non-OFDMA transmission are defined in 36.3.2.2.3 (Large size MRUs(#2025)) and signaled in
46
47 the U-SIG field(#7008)(#5657) by setting the Punctured Channel Information field to the puncturing pattern
48 of the large size MRU corresponding to the punctured subchannel (see Table 36-30 (Definition of the
49 Punctured Channel Information field in the U-SIG for an EHT MU PPDU using non-OFDMA
50 transmissions(#8011)(#2402)))(#2616).
51
52 NOTE—(#7236)A non-OFDMA transmission includes PPDUs to a single user, PPDUs to multiple users using MU-
53 MIMO, and an EHT sounding NDP.
54
55 36.3.12.11.4 Preamble puncturing for EHT TB PPDUs(#7236)
56
57
58 A non-AP EHT STA transmitting an EHT TB PPDU occupies the 20 MHz subchannels that are overlapped
59 with its assigned RU or MRU and has no knowledge on whether the unassigned 20 MHz subchannels are
60 due to puncturing or not, unless indicated as inactive in the Disabled Subchannel Bitmap field in 9.4.2.311
61 (EHT Operations element). There is no indication about preamble puncturing in the EHT TB PPDU.
62
63
64 For mask compliance purpose, the non-AP EHT STA shall treat all the subchannels, indicated as inactive in
65 the Disabled Subchannel Bitmap field in 9.4.2.311 (EHT Operation element), as punctured subchannels

Copyright © 2022 IEEE. All rights reserved. 661

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 which are subject to the additional restrictions as defined in 36.3.19.1.2 (Additional restrictions for
2 puncturing in EHT PPDU). Any other unoccupied subcarriers outside of the assigned RU or MRU shall
3
meet the transmitter modulation accuracy requirements for unoccupied subcarriers defined in 36.3.19.4.4
4
5 (Transmitter modulation accuracy (EVM) test).
6
7 36.3.13 Data field
8
9
36.3.13.1 SERVICE field
10
11
12 The SERVICE field of (#7009)the EHT DATA field is shown in Table 36-45 (SERVICE field).
13
14
15 Table 36-45—SERVICE field
16
17
18 Bits Field Description
19
20 B0–B10 Scrambler Initialization Set to 0
21
22
23 B11–B15 Reserved Set to 0
24
25
26
27 36.3.13.2 EHT PHY DATA scrambler and descrambler
28
29 The DATA field, composed of SERVICE, PSDU, Tail (if BCC is used), and pre-FEC pad parts(#2664), shall
30 be scrambled with a length-2047 PPDU-synchronous scrambler. The octets of the PSDU are placed in the
31
transmit serial bit stream, bit 0 first and bit 7 last. The PPDU synchronous scrambler uses the generator
32
33 polynomial S  x  as shown in Equation (36-46) and is illustrated in Figure 36-50 (Data scrambler(#3070)).
34
35 11 9
36 Sx = x + x + 1 (36-46)
37
38
39
40 During bits 0-10 of
Scrambling Sequence
41
42 11 Initialization bits
43
44
45 Data In

46
47
48 X 11 X 10 X9 X8 X7 X6 X5 X4 X3 X2 X1
49
Scrambled Data
50 Out
51
52 Figure 36-50—Data scrambler(#3070)
53
54
55 (#7240)(#1971)NOTE—When the TXVECTOR parameter SCRAMBLER_INITIAL_VALUE is 2047 (all 1s), the
56 2047-bit sequence generated repeatedly by the scrambler is (leftmost used first)
57 111111111110000000001100000001111000001100110001111111101100000010111000010010110010110011110011
58 111001111000111100110110011111011111000101000110100010111001010010111000110010110111110011010001
59 111100101100011100111011011110101101001000110011010111111100010000011010100011100001011011001001
60 101111011110100101001001100011011111011101000101010010100000110001000111101010110010000011110100
61 011001001011111011001000101111010100100100001101101001110110011101011111010001000100101010101100
62 000000111000000110110000111011100110101011111000001000110001010111101000010010010010110110110011
63 011011111101101000010110010010011110110111001011010111001100010111111010010000100110100101111001
64 100100111111101110000010101100010000111010100110100001111001001100111011111110101000001000010001
65

662 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 010010101000110000010111100010010011010110111100011010011011100111101011110010001001110101011101
2 000001010010001000110101010111000000010110000010011100010111011010010101100110000111111100110000
3 011111100011000011011110011101001111010011100100111011101110101010101000000000010000000010100000
4 010001000010101010010000000110100000111001000110111010111010100010100001010001001000101011010100
5 001100001001111001011100111001011110111001001010111011000010101110010000101110100100101001101100
6 011110111011001010101111000000100110000101111100100100011101101011010110001100011101111011010100
7 101100001100111001111110111100001010011001000111111010110000100011100101011011100001101011001110
8 001111101101100010110111010011010100111100001110011001101111111110100000001001000001011010001001
9 100101011111100001000011001010011111000111000110110110111011011010101101100000110111000111010110
10 110100011011001011101111001010100111000001110110001101011101110001010101101000000110010000111110
11 100110001001111101011100010001011010101001100000011111000011000110011110111111001010000111000100
12 110110101111011000100101110101100101000111100010110011010011111100111000011110110011001011111111
13 001000000111010000110100100111001101110111110101010001000000101010000100000100101000101100010100
14 1110100011101001011010011001100.
15
16 (#2665)The same scrambler is used to scramble transmit data and to descramble receive data. When
17
transmitting, the first eleven bits of scrambling sequence, (#7753)which are also used to set the state of the
18
19 scrambler for the subsequent scrambling bits, shall be set to a pseudorandom nonzero state. During reception
20 by an EHT STA, the initial state can be estimated from the eleven LSBs of the scrambled service field.
21
22 When (#7004)a MU-RTS frame is transmitted using an EHT PPDU, (#7241)the first seven initialization bits
23
(B0–B6) as shown in Figure 36-50 (Data scrambler(#3070)), equivalent to the seven LSB bits of the
24
25 SERVICE field after scrambling, shall not be set to all zeros.
26
27 36.3.13.3 Coding
28
29
36.3.13.3.1 General
30
31
32 The Data field shall be encoded using either BCC defined in 36.3.13.3.2 (BCC coding) or the LDPC code
33 defined in 36.3.13.3.3 (LDPC coding). For an EHT MU PPDU, the coding type is selected by the Coding
34 subfield in the User field of EHT-SIG, as defined in 36.3.12.8 (EHT-SIG). For an EHT TB PPDU, the coding
35
type is selected by the UL FEC Coding Type subfield in User Info field in the soliciting Trigger frame, or the
36
37 RU size indicated in RU Allocation subfield in the soliciting frame carrying a TRS Control subfield, as
38 defined in 9.3.1.22 (Trigger frame format) and 35.5.2.3.2 (TXVECTOR parameters for EHT TB PPDU
39 response to Trigger frame), respectively(#5489).
40
41
(#2642)When conducting BCC FEC encoding for an EHT PPDU, the number of encoders is always 1 per
42
43 STA(#7242).
44
45 36.3.13.3.2 BCC coding
46
47
(#2647)Support for BCC coding is limited to less than or equal to four spatial streams per user, EHT-
48
49 MCSs 0 to 9, EHT-MCS 15 (BPSK-DCM(#3261) with N SS u = 1 ), and RU or MRU that is the same size or
50 smaller than a 242-tone RU. BCC support is mandatory (for both transmit and receive) for RU or MRU that
51
is the same size or smaller than a 242-tone RU(#1315).
52
53
54 BCC encoding process is described in 27.3.12.5.1 (BCC coding and puncturing).
55
56 (#2647)If EHT-MCS 15 (BPSK-DCM(#3261) with N SS u = 1 ) is used in a 106-tone RU, 242-tone RU, or
57
58 106+26-tone MRU with BCC coding, then after every 2  N DBPS u coded bits, one padding bit is added. The
59 padding bit may be set to any value.
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 663

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 36.3.13.3.3 LDPC coding

2
3
LDPC is the only FEC coding scheme in the EHT PPDU Data field for RUs or MRUs with more than 242
4
5 tones(#1292). LDPC is the only FEC coding scheme in the EHT PPDU Data field for EHT-MCSs 10 to
6 14(#2648)(#4631). Support for LDPC coding (for both transmit and receive) is mandatory (#4627)for an
7 EHT STA that supports at least one of:
8
9 — EHT 40/80/160/320 MHz PPDU bandwidths for SU transmission,
10 — more than four spatial streams,
11
12 — any EHT-MCS from 10 to 13, or
13 — EHT-MCS 14.
14
15
Otherwise, support of LDPC coding for either transmit or receive is optional. (#4627)fAn EHT STA
16
17 supports the transmission and reception of LDPC encoded EHT PPDUs if the STA sets the LDPC Coding In
18 Payload subfield of the (#4631)HE Capabilities element (see 9.4.2.248 (HE Capabilities element)) to 1,
19 where, as defined in 35.12.3 (Contents of the EHT PHY Capabilities Information field and Supported EHT-
20 MCS And NSS Set field(#4627)), this subfield is determined in turn by
21
dot11HELDPCCodingInPayloadImplemented.
22
23
24 36.3.13.3.4 EHT PPDU padding process
25
26 A two-step padding process is applied to an EHT PPDU. A pre-FEC padding process including both
27
pre-FEC MAC and pre-FEC PHY padding is applied before conducting FEC coding, and a post-FEC PHY
28
29 padding process is applied on the FEC encoded bits.
30
31 Four pre-FEC padding boundaries partition the last OFDM symbol of an EHT PPDU into four symbol
32 segments. The pre-FEC padding may pad toward one of the four possible boundaries. The four pre-FEC
33
padding boundaries are represented by a pre-FEC padding factor parameter a(#8131).
34
35
36 Figure 36-51 (EHT PPDU padding process in the last OFDM-symbol if a = 1 for the u-th user) illustrates
37 these four possible symbol segments in the last OFDM symbol, and the general padding process assuming
38 the desired pre-FEC padding boundary, represented by the pre-FEC padding factor, is 1.
39
40
Excess information bits Pre‐FEC padding bits
41
42
43
44
Scrambler
45
46
47 FEC post‐FEC padding bits
48
49
50 FEC output bits
51
52 Bit stream in the last
a=1 OFDM symbol
53
NCBPS,LAST,u bits
54
55 NCBPS,u bits
56
57 Figure 36-51—EHT PPDU padding process in the last OFDM-symbol if a = 1 for the u-th
58 user
59
60 36.3.13.3.5 Encoding process for an EHT MU PPDU
61
62
63 (#2653)The encoding process described in this subclause applies to both transmission of an EHT MU PPDU
64 to a single user and transmission of an EHT MU PPDU to multiple users.
65

664 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 For an EHT MU PPDU, all the users shall use a common value of pre-FEC padding factor a and a common
2 value of N SYM . The padding process is described as follows.
3
4
5 In an EHT MU PPDU transmission, the transmitter first computes the number of (#7244)data bits left in the
6 last OFDM symbol for user u as in Equation (36-47)(#6805)(#7398).
7
8
9 N Excess u =  8  APEP_LENGTH u + N tail u + N service  mod N DBPS u (36-47)
10
11 where
12
13 APEP_LENGTHu is the TXVECTOR parameter APEP_LENGTH for the u-th user(#1388).
14 N tail u is the number of tails bits per encoder for user u(#6805) as defined in Table 36-18 (Timing-
15
16 related constants).
17 N service is the number of bits in the SERVICE field as defined in Table 36-18 (Timing-related
18
constants).
19
20 N DBPS u is the number of data bits per OFDM symbol for the u-th user as defined in Table 36-23
21 (Frequently used parameters).
22
23
24 Based on N Excess u , the transmitter then computes the initial number of symbol segments in the last OFDM
25 symbol, i.e., initial pre-FEC padding factor value a init u as shown Equation (36-48), and the initial number
26
27 of OFDM symbols, N SYM init u , for user u using Equation (36-49)(#6805).
28
29
30  4 if N Excess u = 0
31 
32 a init u =   N Excess u -  4  otherwise (36-48)
33  min  ------------------------------
N DBPS short u 
34 
35
36
37
38 8  APEP_LENGTH u + N tail u + N service
N SYM init u = ------------------------------------------------------------------------------------------------- (36-49)
39 N DBPS u
40
41
42
43 where
44 N DBPS short u = N CBPS short u  R u , in which R u is the coding rate for the u-th user
45
46 N CBPS short u = N SD short u  N SS u  N BPSCS u , in which N SD short u is the N SD short value corresponding to the
47 occupied RU or MRU size of the u-th user, N SS u and N BPSCS u are defined in Table 36-23
48
49 (Frequently used parameters).
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 665

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The parameter N SD short values for different RU and MRU sizes are shown in Table 36-46 (NSD,short
2
3 values for EHT-MCS values from 0 to 13 and 15) and Table 36-47 (NSD,short values for EHT-MCS 14).
4
5
6 Table 36-46—NSD,short values for EHT-MCS values from 0 to 13 and 15
7
8
9 N SD short
10 RU/MRU size
11 MCS   0 13  MCS = 15
12
13 26-tone 6 2
14
15 52-tone 12 6
16
17 52+26-tone 18 8
18
19 106-tone 24 12
20
21 106+26-tone 30 14
22
23 242-tone 60 30
24
25 484-tone 120 60
26
484+242-tone 180 90
27
28 996-tone 240 120
29
30 996+484-tone 360 180
31
32 996+484+242-tone 420 210
33
34 2996-tone 492 246
35
36 2996+484-tone 612 (#2649)N/A
37
38 3996-tone 732 366
39
40 3996+484-tone 852 (#2649)N/A
41
42 4996-tone 984 492
43
(#2649)NOTE—EHT-MCS 15 is not supported for transmit and
44
receive over MRU 2996+484 and MRU 3996+484 (See 36.1.1
45
(Introduction to the EHT PHY)).
46
47
48
49 Table 36-47—NSD,short values for EHT-MCS 14
50
51
52 Bandwidth N SD short
53
54 80 MHz 60
55
56 160 MHz 120
57
58 320 MHz 246
59
60
61
62 Among all the users, (#6906)derive the set of the user indices S, with the longest encoded packet duration as
63 in Equation (36-50), and select one value from the set as u max .
64
65

666 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 N – 1 a init u
user total
2 S = arg max u = 0 N SYM init u – 1 + -------------
- (36-50)
3
 4 
4
5 where(#2950)
6
7
arg max f  x  :=  x   0 N user total – 1  : f  y   f  x  for all y   0 N user total – 1  
8
9 Then the common a init and N SYM init values among all the users are derived (#7247)using Equation (36-51).
10
11
12 N SYM init = N SYM init umax
13 (36-51)
14 a init = a init umax
15
16
17
Next calculate each user’s initial number of data bits and initial number of coded bits in its last OFDM
18 symbol as shown in Equation (36-52) and Equation (36-53).
19
20
21 a init  N DBPS short u  if a init  4
N DBPS last init u =  (36-52)
22
23
 N DBPS u if a init = 4
24
25
26 a init  N CBPS short u  if a init  4
N CBPS last init u =  (36-53)
27  N CBPS u if a init = 4
28
29
30 For each user with LDPC encoding, the parameters N pld u and N avbits u are computed using Equation (36-
31
54) and Equation (36-55), respectively.
32
33
34 N pld u =  N SYM init – 1 N DBPS u + N DBPS last init u (36-54)
35
36
37 N avbits u =  N SYM init – 1 N CBPS u + N CBPS last init u (36-55)
38
39 For each user with LDPC encoding(#7246), continue LDPC encoding process as in 19.3.11.7.5 (LDPC
40
41 PPDU encoding process) starting with the parameters N pld u and N avbits u . If there is at least one user with
42 LDPC encoding for which the following condition in step d) of LDPC encoding process as described in
43 19.3.11.7.5 (LDPC PPDU encoding process) is met(#2650):
44
45
46 Ru 
 N punc u  0.1  N CW u  L LDPC u   1 – R u   AND  N shrt u  1.2  N punc u  --------------
- is true OR if
47  1 – R u
48
49 N punc u  0.3  N CW u  L LDPC u   1 – R u  is true,
50
51
52 where N punc u , N CW u , L LDPC u , and N shrt u are the LDPC encoding parameters for user u, as defined in
53 19.3.11.7.5 (LDPC PPDU encoding process), and R u is the coding rate of user u, then the LDPC Extra
54
55 Symbol Segment field of EHT-SIG shall be set to 1, and all users with LDPC encoding shall increment
56 N avbits and recompute N punc , using Equation (36-56) and Equation (36-57).
57
58
59  N avbits u + N CBPS u – 3N CBPS short u if a init = 3
60 N avbits u =  (36-56)
61  N avbits u + N CBPS short u otherwise
62
63
64 N punc c = max  0  N CW u  L LDPC u  – N avbits u – N shrt u  (36-57)
65

Copyright © 2022 IEEE. All rights reserved. 667

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Then update the common pre-FEC padding factor a and N SYM values for all users (#7247)using
2
3 Equation (36-58).
4
5
6  N SYM = N SYM init + 1 and a = 1 if a init = 4
 (36-58)
7  N SYM = N SYM init and a = a init + 1 otherwise
8
9
10 If none of the users with LDPC encoding for which the condition mentioned above in step d) of LDPC
11 encoding process as described in 19.3.11.7.5 (LDPC PPDU encoding process) is met, or if all the users
12 scheduled in the EHT MU PPDU are BCC encoded, then the LDPC Extra Symbol Segment field of
13
14 EHT-SIG shall be set to 0, and the common pre-FEC padding factor a and N SYM values for all users shall be
15 updated by Equation (36-59)(#2651).
16
17
18 N SYM = N SYM init
19 (36-59)
20
a = a init
21
22 For the users with LDPC encoding,
23
24
25 N DBPS last u = N DBPS last init u (36-60)
26
27 For the users with BCC encoding, update N DBPS of the last OFDM symbol as
28
29
30
31  a  N DBPS short u if a  4
N DBPS last u =  (36-61)
32  N DBPS u if a = 4
33
34
35 For each user with either LDPC or BCC encoding, update N CBPS of the last OFDM symbol as
36
37
38  a  N CBPS short u if a  4
39 N CBPS last u =  (36-62)
40  N CBPS u if a = 4
41
42
43
(#7245)For each user with LDPC encoding, the number of pre-FEC padding bits for the u-th user is
44 computed as in Equation (36-63).
45
46 N PAD Pre-FEC u =  N SYM init – 1 N DBPS u + N DBPS last init u – 8  APEP_LENGTH u – N service (36-63)
47
48
49 For the users with BCC encoding, the number of pre-FEC padding bits is shown in Equation (36-
50 64)(#6805).
51
52
53 N PAD Pre-FEC u =  N SYM – 1 N DBPS u + N DBPS last u – 8  APEP_LENGTH u – N tail u – N service (36-64)
54
55 For each user with either LDPC or BCC encoding, the number of post-FEC padding bits in the last symbol is
56 computed as in Equation (36-65). (#4958)The values of the post-FEC padding bits are not specified and are
57
58
left up to implementation.
59
60 N PAD Post-FEC u = N CBPS u – N CBPS last u (36-65)
61
62
63 Among the pre-FEC padding bits, the MAC delivers a PSDU that fills the available octets in the Data field
64 of the EHT PPDU, toward the desired initial pre-FEC padding boundary represented by a init for users
65

668 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 encoded by LDPC, and toward the desired pre-FEC padding boundary represented by a for users encoded by
2 BCC, in the last OFDM symbol. The PHY then determines the number of padding bits to add and appends
3
them to the PSDU. The number of pre-FEC padding bits added by PHY will always be 0 to 7. The procedure
4
5 is defined in Equation (36-66) and Equation (36-67).
6
7 N PAD Pre-FEC u
8 N PAD Pre-FEC MAC u = 8  ---------------------------------
- (36-66)
9 8
10
11 N PAD Pre-FEC PHY u = N PAD Pre-FEC u mod 8 (36-67)
12
13
14 36.3.13.3.6 Encoding process for an EHT TB PPDU
15
16 For an EHT TB PPDU sent in response to a Trigger frame, the AP indicates the UL Length, GI And
17 EHT-LTF Type, Number Of EHT-LTF Symbols, Pre-FEC Padding Factor, LDPC Extra Symbol Segment,
18
19 and PE Disambiguity fields in the Trigger frame. The common values T PE and N SYM are derived by non-AP
20 STAs as shown in Equation (36-92) and Equation (36-93)(#8132), respectively. The AP shall set the LDPC
21 Extra Symbol Segment field in the Common Info field of the Trigger frame to 1 if (#8134)the condition in
22
23
step d) of LDPC encoding process described in 36.3.13.3.5 (Encoding process for an EHT MU PPDU) is
24 met for at least one LDPC encoded user solicited by the AP for an EHT TB PPDU transmission.
25
NOTE—The AP might set the LDPC Extra Symbol Segment field to 1 regardless of the value derived from the
26
calculations. The AP might select a value for the Pre-FEC Padding Factor field that differs from that derived from the
27
calculations described in (#8134)36.3.13.3.5 (Encoding process for an EHT MU PPDU).
28
29
30 For an EHT TB PPDU sent in response to a frame containing a TRS Control subfield, the parameters used to
31 derive the common values T PE and N SYM are described in 35.5.2.3.2 (TXVECTOR parameters for EHT TB
32
33 PPDU response to Trigger frame).
34
35 For an EHT TB PPDU with BCC encoding, follow the EHT MU padding and encoding process as described
36 in 36.3.13.3.5 (Encoding process for an EHT MU PPDU) with initial parameters as follows:
37
38 — If the TXVECTOR parameter TRIGGER_METHOD is TRIGGER_FRAME, the initial parameters
39 are N SYM init = N SYM and a init = a , where a is the pre-FEC padding factor indicated in the
40 Pre-FEC Padding Factor subfield of the Common Info field in the Trigger frame, and N SYM is the
41 common number of data OFDM symbols derived from the UL Length and Number Of EHT-LTF
42
43
Symbols subfields of the Common Info field in the Trigger frame.
44 — If the TXVECTOR parameter TRIGGER_METHOD is TRS, the initial parameters are set to
45 N SYM init = F VAL + 1 and a init = 4 , where F VAL is the value of the UL Data Symbol subfield of
46 the TRS Control subfield.
47
48
49 For an EHT TB PPDU with LDPC encoding, follow the EHT MU padding and encoding process as
50 described in 36.3.13.3.5 (Encoding process for an EHT MU PPDU) with initial parameters as follows:
51
52
— If the TXVECTOR parameter TRIGGER_METHOD is TRIGGER_FRAME and the LDPC Extra
53 Symbol Segment field in the Trigger frame is 1, set the initial parameter using Equation (36-68).
54
55
56  a init = 4 and N SYM init = N SYM – 1 if a = 1
 (36-68)
57
 a init = a – 1 and N SYM init = N SYM otherwise
58
59
60 Then continue with the LDPC encoding process as in 36.3.13.3.5 (Encoding process for an EHT
61 MU PPDU), during which N avbits u is always incremented as in Equation (36-56), and N punc u is
62 always recomputed as in Equation (36-57).
63
64
65

Copyright © 2022 IEEE. All rights reserved. 669

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 — If the TXVECTOR parameter TRIGGER_METHOD is TRIGGER_FRAME and the LDPC Extra

2 Symbol Segment field in the Trigger frame is 0, set initial parameters to N SYM init = N SYM and
3
a init = a . Then continue with the LDPC encoding process as in 36.3.13.3.5 (Encoding process for
4
5 an EHT MU PPDU), during which N avbits u and N punc u are not changed.
6 — If the TXVECTOR parameter TRIGGER_METHOD is TRS, then the parameter
7 LDPC_EXTRA_SYMBOL is 1, and initial parameters are set to N SYM init = F VAL + 1 and
8
9 a init = 3 , where F VAL is the value of the UL Data Symbols subfield of the TRS Control subfield.
10 Then continue with the LDPC encoding process as in 36.3.13.3.5 (Encoding process for an EHT MU
11 PPDU), during which N avbits u is always incremented as in Equation (36-56), and N punc u is always
12 recomputed as in Equation (36-57).
13
14
15 36.3.13.4 Stream parser
16
17 After scrambling, coding, puncturing and post-FEC padding, the data bits are parsed into spatial stream(s) as
18 described in 27.3.12.6 (Stream parser).
19
20
21 36.3.13.5 Segment parser
22
23 (#4646)The segment parser operation is applied to each 80 MHz frequency subblock.
24
25 (#7288)Segment parsing shall be performed for RU or MRU of size 2×996-, 996+484-, 996+484+242-,
26
27 2996+484-, 3996-, 3996+484-, or 4996-tone. For a 26-, 52-, 52+26-, 106-, 106+26-, 242-, 484-,
28 484+242-, and 996-tone RU or MRU, the segment parser is bypassed and the output bits are as specified in
29 Equation (36-69).
30
31
32 y k l u = x k u (36-69)
33
34 where
35 x k u is bit k of a block of N CBPSS u bits, k = 0 to N CBPSS u – 1 .
36
37 l is the frequency subblock index.
38 y k  l u is bit k of the frequency subblock l for user u(#7291).
39
40 u is the user index, u = 0 1  N user – 1 .
41
42 (#7657)NOTE—For MCS 14, the RU size refers to the RU size before duplication. Specifically, this means that segment
43 parsing with MCS 14 is only required using 320 MHz.
44
45 For a 160 MHz and 320 MHz transmission with a 2×996-, 996+484-, 996+484+242-, 2996+484-, 3996-,
46 3996+484-, or 4996-tone RU/MRU, the output bits of each stream parser are provided in blocks of
47
48 N CBPSS u bits. The segment parser further divides each block into L blocks of N CBPSS l u bits respectively for
49 L–1
50 l = 0 1  L – 1 , such that  NCBPSS l u = N CBPSS u . (#7289)L is the number of frequency subblocks in
51 l=0
52
53
54
55
56
57
58
59
60
61
62
63
64
65

670 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 the RU or MRU. The values for N CBPSS l u are given in Table 36-48 (Values of (#7294)) for various RU and
2
3 MRU cases.
4
5
6 Table 36-48—Values of N CBPSS l u (#7294)
7
8
9 RU order
RU/ Is DCM
10
MRU
(low to high L
used?
N CBPSS 0 u N CBPSS 1 u N CBPSS 2 u N CBPSS 3 u
11 frequency)
12
13 No 468  N BPSCS u 980  NBPSCS u
14 484+996
15 Yes 234 490
16 996+484
17 No 980  N BPSCS u 468  NBPSCS u
996+484
18 Yes 490 234
19 2
20 No 702  N BPSCS u 980  NBPSCS u
21 (242+484)+996
22 996+484 Yes 351 490
23 +242
24 No 980  N BPSCS u 702  NBPSCS u
25 996+(242+484)
26 Yes 490 351
27 484+996+996 No 468  N BPSCS u 980  NBPSCS u 980  N BPSCS u
28
29 2996
996+484+996 3 No 980  N BPSCS u 468  NBPSCS u 980  N BPSCS u
30 +484
31 996+996+484 No 980  N BPSCS u 980  NBPSCS u 468  N BPSCS u
32
33 484+996+996+996 No 468  N BPSCS u 980  NBPSCS u 980  N BPSCS u 980  N BPSCS u
34
35 3996 996+484+996+996 No 980  N BPSCS u 468  NBPSCS u 980  N BPSCS u 980  N BPSCS u
4
36 +484 996+996+484+996 No 980  N BPSCS u 980  NBPSCS u 468  N BPSCS u 980  N BPSCS u
37
38 996+996+996+484 No 980  N BPSCS u 980  NBPSCS u 980  N BPSCS u 468  N BPSCS u
39
40 No 980  N BPSCS u 980  NBPSCS u
41 2996 996+996 2
42 Yes 490 490
43
44 No 980  N BPSCS u 980  NBPSCS u 980  N BPSCS u
3996 996+996+996 3
45 Yes 490 490 490
46
47 No 980  N BPSCS u 980  NBPSCS u 980  N BPSCS u 980  N BPSCS u
48 4996 996+996+996+996 4
49 Yes 490 490 490 490
50
51
52
53 The segment parser bit distribution sequence starts from the lowest frequency location to the highest
54 frequency.
55
56
57 The bits in each block of N CBPSS l u bits are determined by the segment parser as shown in Equation (36-
58 70)(#2672)(#4575).
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 671

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 y k l u = x m u
2
3 L – 1  l–1 (36-70)
k +
m =   m i  ----
4
5  i = 0  ml
-  m i +  k mod m l 
i=0
6
7
8 where
9 k = 0 1   N CBPSS l u – n l  44  N BPSCS u – 1  when DCM is not used and
10
11 k = 0 1   N CBPSS l u – n l  22  N BPSCS u – 1  when DCM is used(#7298)(#1411).
12 L–1 L–1
13
14
x m u is bit m of a block  N CBPSS i u bits and m = 0 1   NCBPSS i u – 1 .
i=0 i=0
15
16 m l m i are the number of bits assigned to a block of output bits for each round of the round robin
17 parser. Values are given in Table 36-49 (Segment parser parameters(#7293)(#1411)). The
18 values have proportional ratios to the number of occupied data subcarriers in each 80 MHz
19
20 frequency subblock(#6827).
21 l is the frequency subblock index, l = 0 1  L – 1 .
22
23
L is the number of frequency subblocks. L = 2 for 996+484-, 996+484+242-, 2996-tone RU/
24 MRU; L = 3 for 2996+484- and 3996-tone MRU; L = 4 for 3996+484- and 4996-tone
25 RU/MRU.
26
27 y k  l u is bit k of the frequency subblock (or RU in 80 MHz subblock(#1279)) l for user u(#7291).
28 nl n l = 1 for subblock l with nonzero leftover bits, n l = 0 otherwise.
29
30 u is the user index, u = 0 1  N user – 1
31 l–1
32  m i = 0 for frequency subblock l = 0 (#2952)(#3072).
33 i=0
34
35
36
Table 36-49—Segment parser parameters(#7293)(#1411)
37
38
39 Leftover bits
40 RU order Is DCM
RU/MRU L m0 m1 m2 m3 per frequency
41 (low to high frequency) used?
subblock
42
43 No 44  N BPSCS u
44 484+996 s 2s
45 Yes 22
46 996+484
47 No 44  N BPSCS u
48 996+484 2s s
49 Yes 22
50 2
51 No 44  N BPSCS u
(242+484)+996 3s 4s
52 Yes 22
53 996+484+242
54 No 44  N BPSCS u
55 996+(242+484) 4s 3s
56 Yes 22
57
58 484+996+996 No s 2s 2s 44  N BPSCS u
59
60 2996+484 996+484+996 3 No 2s s 2s 44  N BPSCS u
61 996+996+484 No 2s 2s s 44  N BPSCS u
62
63
64
65

672 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-49—Segment parser parameters(#7293)(#1411) (continued)

2
3
4 Leftover bits
RU order Is DCM
5 RU/MRU L m0 m1 m2 m3 per frequency
(low to high frequency) used?
6 subblock
7
8 484+996+996+996 No s 2s 2s 2s 44  N BPSCS u
9
10 996+484+996+996 No 2s s 2s 2s 44  N BPSCS u
11 3996+484 4
12 996+996+484+996 No 2s 2s s 2s 44  N BPSCS u
13 996+996+996+484 No 2s 2s 2s s 44  N BPSCS u
14
15 No
16 2996 996+996 2 s s 0
17 Yes
18
19 No
20 3996 996+996+996 3 s s s 0
21 Yes
22 No
23 4996 996+996+996+996 4 s s s s 0
24 Yes
25
26
27
28 N BPSCS u
29 In Table 36-49 (Segment parser parameters(#7293)(#1411)), s = max  1 ------------------
- .
 2 
30
31
32 (#7300)(#7010)If the RU or MRU contains a frequency subblock that is not fully occupied (i.e., the
33 frequency subblock consists of 484 or 484+242 occupied tones), that frequency subblock will reach its full
34
35 value N CBPSS l  u before the other frequency subblocks. At that point, no further bits are outputted by the
0

36 segment parser for that subblock. For the other frequency subblocks, the number of leftover bits as defined
37 in Table 36-49 (Segment parser parameters(#7293)(#1411)) not equal to 0, and proportional round robin
38
39 parser will (#7301)continue to process the leftover bits as Equation (36-71)(#2443)(#5494).
40
41
42  L – 1  N CBPSS l  u  L–1  k'- +
l–1
m =   m i  -------------------------
0
- +   m i  ----  mi +  k mod m l  (36-71)
43 i = 0  m l0  i = 0 i  l  m l
44 0 i = 0 i  l0

45
46 where
47
48 k =  N CBPSS l u – n l  44  N BPSCS u   N CBPSS l u – 1 (#2442) when DCM is not used and
49 k =  N CBPSS l u – n l  22  N BPSCS u   N CBPSS l u – 1 when DCM is used(#7298)(#1411).
50
51 k  = k –  N CBPSS l u – n l  44  N BPSCS u  when DCM is not used and
52 k  = k –  N CBPSS l u – n l  22  N BPSCS u  when DCM is used(#7298)(#1411).
53
54 l0 is the subblock index with n l0 = 0 (i.e., the subblock without leftover bits).
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 673

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Illustration of the proportional round robin parser with leftover bits processing is shown in Figure 36-52
2 (Illustration of the proportional round robin parser with leftover bits processing(#7303)).
3
4 To 1st RU996 To 2nd RU996
5
6
7 m0 m1 m2 m0 m1 m2 m0 m1 m2 m1 m2 m1 m2 m1 m2
8
9 Proportional round robin parser processing based on Equation (36-70)
Leftover bits processing based on Equation (36-
71)
10
11 Figure 36-52—Illustration of the proportional round robin parser with leftover bits
12
13 processing(#7303)
14
15 Illustration of the segment parser for 996+484-tone MRU and 996+484+242-tone MRU are shown in
16 Figure 36-53 (Illustration of the segment parser for 996+484-tone RU(#7304)) and Figure 36-54
17
18 (Illustration of the segment parser for 996+484+242-tone RU), respectively.
19 RU484
20
constellation LDPC tone
21 1st stream mapper mapper
22
23 Segment Segment
24 Parser (1s:2s) Deparser
25
26 constellation LDPC tone
27 mapper mapper
28 Stream RU996
29 Parser
30
31
32 RU484
33 constellation LDPC tone
34 mapper mapper
35 Segment
36 Segment
Parser (1s:2s) Deparser
37
38 n_th stream
constellation LDPC tone
39 mapper mapper
40 RU996
41
42 Figure 36-53—Illustration of the segment parser for 996+484-tone RU(#7304)
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

674 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2
3 Joint tone mapper with
4 RU(242+484) Dtm=18 for RU(242+484)
5 constellation LDPC tone RU(242+484)
6 1st stream mapper mapper
7 Segment Segment
8 Parser (3s:4s) Deparser
9
10 constellation LDPC tone RU996
11 mapper mapper
12 Stream RU996 Dtm=20
13 Parser
14
15 Joint tone mapper with
16 RU(242+484) Dtm=18 for RU(242+484)
17 constellation LDPC tone RU(242+484)
18 mapper mapper
19
20 Segment Segment
21 Parser (3s:4s) Deparser
22
23 n_th stream constellation LDPC tone RU996
24 mapper mapper
25 RU996 Dtm=20
26
27 Figure 36-54—Illustration of the segment parser for 996+484+242-tone RU
28
29
30 36.3.13.6 BCC interleavers
31
32 BCC is applicable only to an RU or an MRU of size no larger than 242 tones, with number of spatial streams
33 less than or equal to 4 and with one of the following modulations: BPSK, QPSK, 16-QAM, 64-QAM, or
34
35
256-QAM.
36
37 (#2657)A BCC encoder can be applied to small size RUs and MRUs. The BCC encoded bits are interleaved
38 over the RU or the whole MRU. The interleaver parameters for BCC encoded RUs are shown in Table 27-
39 35 (BCC interleave parameters), and the interleaver parameters for BCC encoded MRUs are shown in
40
41
Table 36-50 (Joint BCC interleaver parameters for small size MRUs). (#6092)The interleaver parameters for
42 U-SIG and EHT-SIG are the same as the interleaver parameters for HE-SIG-A/HE-SIG-B as shown in
43 Table 27-35 (BCC interleave parameters). Since DCM is applied only to the BPSK and single stream case,
44 N ROT is not applicable and N ROW is determined without N BPSCS .
45
46
47
48 Table 36-50—Joint BCC interleaver parameters for small size MRUs
49
50
51 MRU size
52 DCM Parameter
53 52+26 106+26
54
55 N SD 72 126
56
57
N COL 18 21
58
59 Not used
60 N ROW 4  N BPSCS 6  N BPSCS
61
62 N ROT 18 31
63
64
65

Copyright © 2022 IEEE. All rights reserved. 675

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-50—Joint BCC interleaver parameters for small size MRUs (continued)
2
3
4 MRU size
5 DCM Parameter
6 52+26 106+26
7
8 N SD
9 36 63
10
11 N COL 12 21
12 Used
13 N ROW 3 3
14
15 N ROT N/A N/A
16
17
18
19 36.3.13.7 Constellation mapping(#3115)
20
21
22
The mapping between the input bits of the constellation mapper and complex constellation points for BPSK,
23 QPSK, 16-QAM, 64-QAM, 256-QAM, and 1024-QAM is defined in 27.3.12.9 (Constellation mapping).
24
25 For 4096-QAM, each constellation point encodes 12 bits (B0–B11). (#7248)B0B1B2B3B4B5 determine the I
26
value and B6B7B8B9B10B11 determine the Q value, as illustrated in Table 36-51 (4096-QAM encoding
27
28 table).
29
30
31 Table 36-51—4096-QAM encoding table
32
33
34 Input bits (B0 B1 B2 B3 B4 B5) I-out Input bits (B6 B7 B8 B9 B10 B11) Q-out
35
36 000000 –63 000000 –63
37
38 000001 –61 000001 –61
39
40 000011 –59 000011 –59
41
42 000010 –57 000010 –57
43
44 000110 –55 000110 –55
45
46 000111 –53 000111 –53
47
48 000101 –51 000101 –51
49
000100 –49 000100 –49
50
51 001100 001100
52 –47 –47
53 001101 001101
–45 –45
54
55 001111 –43 001111 –43
56
57 001110 –41 001110 –41
58
59 001010 –39 001010 –39
60
61 001011 –37 001011 –37
62
63 001001 –35 001001 –35
64
65

676 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-51—4096-QAM encoding table (continued)

2
3
4 Input bits (B0 B1 B2 B3 B4 B5) I-out Input bits (B6 B7 B8 B9 B10 B11) Q-out
5
6 001000 –33 001000 –33
7
8 011000 –31 011000 –31
9
10 011001 –29 011001 –29
11
12 011011 –27 011011 –27
13
14 011010 –25 011010 –25
15
011110 –23 011110 –23
16
17 011111 011111
18 –21 –21
19 011101 011101
–19 –19
20
21 011100 –17 011100 –17
22
23 010100 –15 010100 –15
24
25 010101 –13 010101 –13
26
27 010111 –11 010111 –11
28
29 010110 –9 010110 –9
30
31 010010 –7 010010 –7
32
010011 –5 010011 –5
33
34 010001 010001
35 –3 –3
36 010000 010000
–1 –1
37
38 110000 1 110000 1
39
40 110001 3 110001 3
41
42 110011 5 110011 5
43
44 110010 7 110010 7
45
46 110110 9 110110 9
47
48 110111 11 110111 11
49
50 110101 13 110101 13
51
110100 15 110100 15
52
53 111100 111100
54 17 17
55 111101 111101
19 19
56
57 111111 21 111111 21
58
59 111110 23 111110 23
60
61 111010 25 111010 25
62
63 111011 27 111011 27
64
65

Copyright © 2022 IEEE. All rights reserved. 677

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-51—4096-QAM encoding table (continued)

2
3
4 Input bits (B0 B1 B2 B3 B4 B5) I-out Input bits (B6 B7 B8 B9 B10 B11) Q-out
5
6 111001 29 111001 29
7
8 111000 31 111000 31
9
10 101000 33 101000 33
11
12 101001 35 101001 35
13
14 101011 37 101011 37
15
101010 39 101010 39
16
17 101110 101110
18 41 41
19 101111 101111
43 43
20
21 101101 45 101101 45
22
23 101100 47 101100 47
24
25 100100 49 100100 49
26
27 100101 51 100101 51
28
29 100111 53 100111 53
30
31 100110 55 100110 55
32
100010 57 100010 57
33
34 100011 100011
35 59 59
36 100001 100001
61 61
37
38 100000 63 100000 63
39
40
41
42 The normalization factor K mod for 4096-QAM is 1  2730 .
43
44
45 DCM is a modulation scheme that is applied to EHT-MCSs 14 and 15. It only applies to BPSK and
46 N SS = 1 .
47
48
49 (#4909)When DCM is employed for a 996-tone or smaller RU or MRU, bit sequences are mapped to pairs
50 of symbols  d' k d' q  k   where k is in the range of 0  k  N SD – 1 and q  k  is in the range of
51
52 N SD  k  2N SD – 1 . For RU and MRU equal to or smaller than 996 tones, q  k  = k + N SD . N SD values for
53 use with DCM for each RU and MRU equal to or smaller than 996 tones are given in Table 36-71 (EHT-
54
55
MCSs for 26-tone RU, NSS,u = 1) to Table 36-79 (EHT-MCSs for 996-tone RU, NSS,u = 1) for EHT-
56 MCS 15 (column N SD u ) and in the first two rows of Table 36-87 (EHT-MCS 14 for EHT DUP mode, NSS,u
57 = 1(#4909)) for EHT-MCS 14.
58
59
60 (#4909)For BPSK modulation with DCM on RU or MRU equal to or smaller than 996 tones, the input bits
61 of the constellation mapper are broken into groups of N CBPS bits  B 0 B 1  B NCBPS u  . N CBPS values for use
62
63 with DCM for each RU and MRU equal to or smaller than 996 tones are given in Table 36-71 (EHT-MCSs
64 for 26-tone RU, NSS,u = 1) to Table 36-79 (EHT-MCSs for 996-tone RU, NSS,u = 1) for EHT-MCS 15
65

678 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (column N CBPS u ) and in the first two rows of Table 36-87 (EHT-MCS 14 for EHT DUP mode, NSS,u =
2
3 1(#4909)) for EHT-MCS 14. Each bit B k is BPSK modulated to a sample d' k . This generates the samples for
4 the lower half of the data subcarriers ( k = 0 1  N SD – 1 ). For the upper half of the data subcarriers, the
5
j  k + N SD 
6 samples are generated as d' k + NSD = d' k e , k = 0 1  N SD – 1 . Lower half and upper half of the
7
8 data subcarriers refer to the first N SD used data subcarriers and the next N SD used data subcarriers,
9
respectively.
10
11
12 (#4909)For RU or MRU sizes larger than 996 tones, DCM is performed on the segment parser output for
13 each 80 MHz subblock. For each subblock, DCM mapping is performed as if that subblock consists of an
14 RU or MRU of size equal to or smaller than 996 tones, as described above.
15
16
17 36.3.13.8 LDPC tone mapper(#3115)
18
19 The LDPC tone mapping shall be performed on all LDPC encoded streams mapped in an RU/MRU as
20 described in this subclause. LDPC tone mapping shall not be performed on streams that are encoded using
21
22 BCC. (#4618)If DCM is applied to LDPC encoded streams, D TM_DCM shall be applied on both the lower half
23 data subcarriers in an RU/MRU and the upper half data subcarriers of the RU/MRU. The LDPC tone
24
mapping distance parameters D TM and D TM_DCM are constant for each RU/MRU size and the values for
25
26 different RU/MRU sizes are given in Table 36-52 (LDPC tone mapping distance for each RU/MRU size
27 within an 80 MHz subblock(#2658)).
28
29
30
Table 36-52—LDPC tone mapping distance for each RU/MRU size within an 80 MHz
31
32 subblock(#2658)
33
34
35 RU/MRU size (tones)
36 Parameter
37 484+
26 52 52+26 106 106+26 242 484 996
38 242
39
40 D TM 1 3 4 6 6 9 12 18 20
41
42 D TM_DCM 1 1 3 3 3 9 9 9 14
43
44
45
For an RU or MRU that spans multiple 80 MHz subblocks(#1279), LDPC tone mapping is performed
46
47 separately in each subblock on the portion of the RU/MRU falling within that subblock. The values of tone
48 mapping parameters D TM_l and D TM_DCM_l (#2954) for the portion of the RU/MRU falling within the l-th
49 subblock(#1279) shall be determined as in Table 36-52 (LDPC tone mapping distance for each RU/MRU
50
51 size within an 80 MHz subblock(#2658)).
52
53 For an EHT PPDU without DCM, the LDPC tone mapping for the LDPC encoded stream for user u in the
54 portion of r-th RU/MRU located in the l-th 80 MHz subblock is done by permuting the stream of complex
55 numbers generated by the constellation mappers (see 36.3.13.7 (Constellation mapping(#3115))) as defined
56
57 by Equation (36-72).
58
59  
60
d t  k l  i n l r u = d k i n l r u (36-72)
61
62 where
63 k = 0 1  N SD_l – 1 for a 26-, 52-, 52+26-, 106-, 106+26-, 242-, 484-, 484+242-, and 996-tone
64
65 RU/MRU in the l-th subblock.

Copyright © 2022 IEEE. All rights reserved. 679

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 i = 1 2  N SS r u
2
3 n = 0 1  N SYM – 1
4 for a 26-, 52-, 52+26-, 106-, 106+26-, 242-,484-,
5  0
6  484+242-, and 996-tone RU/MRU
7 
l =  0 1 for a 996+484-, 996+484+242-, and 2  996-tone RU/MRU
8 
9  0 1 2 for a 2  996+484- and 3  996-tone MRU
10  0 1 2 3 for a 3  996+484- and 4  996-tone RU/MRU
11
12 u = 0 1  N user r – 1
13
r = 0 1  N RU/MRU – 1
14
15 N SD_l is the number of data tones in the portion of r-th RU/MRU located in the l-th subblock.
16
N SD_l  D TM_l (#2954)
17 t  k l  = D TM_l  k mod ----------------
- + k
------------------------
-
18  D TM_l  N SD_l
19
20 D TM_l is the LDPC tone mapping distance for the portion of r-th RU/MRU located in l-th subblock if
21 DCM is not applied, defined in Table 36-52 (LDPC tone mapping distance for each RU/MRU
22 size within an 80 MHz subblock(#2658))(#2954).
23
24
25 For an EHT PPDU with DCM applied to the Data field, the LDPC tone mapping for the LDPC encoded
26 stream corresponding to user u in the portion of r-th RU/MRU located in the l-th 80 MHz subblock is done
27 by permuting the stream of complex numbers generated by the constellation mappers (see 36.3.13.7
28 (Constellation mapping(#3115))) as defined by Equation (36-73).
29
30
31  
d t  k l  i n l r u = d k i n l r u (36-73)
32
33
34 where
35 k = 0 1  2N SD_l – 1 for the portion of an RU/MRU in the l-th subblock that corresponds to 26-, 52-,
36
37
52+26-, 106-, 106+26-, 242-, 484-, 484+242-, and 996-tone.
38 i = 1 2  N SS r u
39
n = 0 1  N SYM – 1
40
41 for a 26-, 52-, 52+26-, 106-, 106+26-, 242-,484-,
42
 0
 484+242-, and 996-tone RU/MRU
43 
44 l =  0 1 for a 996+484-, 996+484+242-, and 2  996-tone RU/MRU
45 
46  0 1 2 for a 2  996+484- and 3  996-tone MRU
47  0 1 2 3 for a 3  996+484- and 4  996-tone RU/MRU
48
49 u = 0 1  N user r – 1
50 r = 0 1  N RU/MRU – 1
51
52 N SD_l is the number of data tones in the portion of r-th RU/MRU located in the l-th subblock if DCM
53 is applied.(#2954)(#1972)
54
55  N SD_l  k  D TM_DCM_l 
56  D TM_DCM_l  k mod ----------------------------
+ ------------------------------------
- for k  N SD_l
 D TM_DCM_l N SD_l
57 t  k l  = 
58 D N SD_l   k – N SD_l   D TM_DCM_l + N  for k  N

59  TM_DCM_l   k – N SD_l  mod ---------------------------
D TM_DCM_l
- + -----------------------------------------------------------------
N SD_l
- SD_l SD_l
60 
61
62 D DCM_TM_l is the LDPC tone mapping distance for the portion of r-th RU/MRU located in l-th subblock if
63 DCM is applied, defined in Table 36-52 (LDPC tone mapping distance for each RU/MRU size
64 within an 80 MHz subblock(#2658))(#2954).
65

680 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 LDPC tone mapper for a 26-, 52-, 52+26-, 106-, 106+26-, 242-, 484-, and 996-tone RU/MRU is defined as
2 one subblock. LDPC tone mapping is performed separately for each 80 MHz frequency subblock.
3
4
5 Since LDPC tone mapping is not performed on BCC coded streams, for BCC coded spatial streams,
6 Equation (36-74) applies(#3116).
7
8  
9 d k i n l r u = d k i n l r u (36-74)
10
11 where
12
13 k = 0 1  N SD_l – 1 for a 26-, 52-, 52+26-, 106-, 106+26-, and 242-tone RU/MRU in the l-th
14 subblock.
15 i = 1 2  N SS r u
16
17 n = 0 1  N SYM – 1
18
19 l = 0 for a 26-, 52-, 52+26-, 106-, 106+26-, and 242-tone RU/MRU.
20 u = 0 1  N user r – 1
21
22 r = 0 1  N RU/MRU – 1
23
24 36.3.13.9 Segment deparser(#2993)
25
26
27 (#4647)The segment deparser combines 80 MHz frequency subblocks from the output of the LDPC tone
28 mapper into a single frequency segment.
29
30 For a 26-, 52-, 52+26-, 106-, 106+26-, 242-, 484-, 484+242-, (#8139)and 996-tone RU or MRU, the
31
segment deparsing is not performed and is specified in Equation (36-75).
32
33
34 
d k i n r u = d k i n 0 r u if 0  k  N SD – 1 (36-75)
35
36
37 For a 996+484-, 996+484+242-, 2996-, 2996+484-, 3996-, 3996+484-, and 4996-tone RU or MRU in
38 EHT PPDU, the frequency subblocks at the output of the LDPC tone mapper are combined into one
39 frequency segment as specified in Equation (36-76).
40
41
42 l–1 l

43
44
d k i n r u = d k – l – 1 N
 SD_q i n  l r  u if  N SD_q  k   N SD_q – 1 (36-76)
q=0 q=0 q=0
45
46
47 where
48 l   0 L – 1  .
49
50 l–1
51  NSD_q = 0 for (#5096)frequency subblock l = 0 .
52 q=0
53
54 36.3.13.10 Frequency domain duplication
55
56
57 For an EHT PPDU that is not encoded with EHT-MCS 14, frequency domain duplication is not performed
58 and d̃ k m n r u is specified in Equation (36-77).
59
60
61 d̃ k m n r u = d k m n r u (36-77)
62
63
64 where
65

Copyright © 2022 IEEE. All rights reserved. 681

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 k = 0 1  N SD u – 1
2
3 m = 1 2  N SS r u
4 n = 0 1  N SYM – 1
5
6 r = 0 1 N RU – 1
7
8 u = 0 1  N user r – 1
9 N SD u is the number of data subcarriers at the r-th RU or MRU for the user u,
10
11 u = 0 1  N user r – 1 (#4910)
12
13 For an EHT MU PPDU transmitted to a single user with EHT-MCS 14, the output of the segment deparser is
14
15
further duplicated to map to two RUs according to Equation (36-78) and Equation (36-79)(#6830)(#6831).
16
17 d̃ k m n r u = d k m n r u  0  k  2N SD u – 1 (36-78)
18
19
20
 – d k m n r u  0  k  N SD u – 1
21 d̃ k m n r + 1 u =  (36-79)
22  d k m n r u  N SD u  k  2N SD u – 1
23
24
25 where
26 m = 1 since N SS r u = 1 for EHT-MCS 14.
27
28 n = 0 1  N SYM – 1
29 r = 0 , since EHT-MCS 14 is only supported for transmission to a single user(#7012).
30
31 u = 0 , since EHT-MCS 14 is only supported for transmission to a single user(#7012).
32
33
34 Here, d̃ k m n r u maps to data subcarriers in RU1 and d̃ k m n r + 1 u maps to data subcarriers in RU2, where
35 RU1 and RU2 correspond to:
36
37
— 484-tone RUs for an 80 MHz PPDU (defined in Table 36-5 (Data and pilot subcarrier indices for
38 RUs in an 80 MHz EHT PPDU)),
39 — 996-tone RUs for a 160 MHz PPDU (defined in Table 36-6 (Data and pilot subcarrier indices for
40 RUs in a 160 MHz EHT PPDU)),
41
42 — 2996-tone RUs for a 320 MHz PPDU (defined in Table 36-7 (Data and pilot subcarrier indices for
43 RUs in a 320 MHz EHT PPDU)).
44
45
46
36.3.13.11 Pilot subcarriers
47
48 (#5013)(#7250)(#7314)For a user transmitting on the i-th 26-, 52-, 106-, 242-, and 484-tone RU in a 20
49 MHz or 40 MHz PPDU bandwidth (see Table 27-7 (Data and pilot subcarrier indices for RUs in a 20 MHz
50 HE PPDU and in a non-OFDMA 20 MHz HE PPDU) and Table 27-8 (Data and pilot subcarrier indices for
51
52
RUs in a 40 MHz HE PPDU and in a non-OFDMA 40 MHz HE PPDU))(#1313), the pilot subcarriers
53 defined in 27.3.12.13 (Pilot subcarriers) shall be used.
54
55 (#5014)(#7250)(#7249)For a user transmitting on the i-th 26-tone RU in an 80 MHz, a 160 MHz, or a
56 320 MHz PPDU bandwidth (see Table 36-5 (Data and pilot subcarrier indices for RUs in an 80 MHz EHT
57
58
PPDU), Table 36-6 (Data and pilot subcarrier indices for RUs in a 160 MHz EHT PPDU), and Table 36-7
59 (Data and pilot subcarrier indices for RUs in a 320 MHz EHT PPDU))(#1313), the pilot subcarriers shall be
60
61
62
63
64
65

682 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 inserted at subcarriers k  K R26i , where K R26i is given by the i-th pilot index set in the row of given PPDU
2
3 bandwidth(#1313) of Table 36-53 (Pilot indices for a 26-tone RU transmission).
4
5
6 Table 36-53—Pilot indices for a 26-tone RU transmission
7
8
9 PPDU bandwidth
10 (#1313)(#1590)
K R26i
11
12 {–494, –480}, {–468, –454}, {–440, –426}, {–414, –400}, {–386, –372}, {–360, –346},
13 {–334, –320}, {–306, –292}, {–280, –266}, {–246, –232}, {–220, –206}, {–192, –178},
14 {–166, –152}, {–140, –126}, {–112, –98}, {–86, –72}, {–58, –44}, {–32, –18},
15 80 MHz, i = 1:37
{not defined}, {18, 32}, {44, 58}, {72, 86}, {98, 112}, {126, 140}, {152, 166},
16 {178, 192}, {206, 220}, {232, 246}, {266, 280}, {292, 306}, {320, 334}, {346, 360},
17 {372, 386}, {400, 414}, {426, 440}, {454, 468},{480, 494}
18
19 160 MHz, i = 1:74 {pilot subcarrier indices in 80 MHz – 512, pilot subcarrier indices in 80 MHz + 512}
20
21 320 MHz, i = 1:148 {pilot subcarrier indices in 160 MHz – 1024, pilot subcarrier indices in 160 MHz + 1024}
22
23
24
25 k
(#7478)The pilot mapping P n for the subcarrier k for symbol n shall be as specified in Equation (27-101) in
26
27 27.3.12.13 (Pilot subcarriers).
28
29 (#5014)(#7250)(#7249)For a user transmitting on the i-th 52-tone RU in an 80 MHz, a 160 MHz, or a
30 320 MHz PPDU bandwidth (see Table 36-5 (Data and pilot subcarrier indices for RUs in an 80 MHz EHT
31
32 PPDU), Table 36-6 (Data and pilot subcarrier indices for RUs in a 160 MHz EHT PPDU), and Table 36-7
33 (Data and pilot subcarrier indices for RUs in a 320 MHz EHT PPDU))(#1313), the pilot subcarriers shall be
34 inserted at subcarriers k  K R52i , where K R52i is given by the i-th pilot index set in the row of given PPDU
35
36 bandwidth(#1313) of Table 36-54 (Pilot indices for a 52-tone RU transmission).
37
38
39 Table 36-54—Pilot indices for a 52-tone RU transmission
40
41
42 PPDU bandwidth
43 (#1313)(#1590)
K R52i
44
45 {–494, –480, –468, –454}, {–440, –426, –414, –400}, {–360, –346, –334, –320},
46 {–306, –292, –280, –266}, {–246, –232, –220, –206}, {–192, –178, –166, –152},
47 80 MHz, i = 1:16 {–112, –98, –86, –72}, {–58, –44, –32, –18}, {18, 32, 44, 58}, {72, 86, 98, 112},
48 {152, 166, 178, 192}, {206, 220, 232, 246}, {266, 280, 292, 306}, {320, 334, 346, 360},
49 {400, 414, 426, 440}, {454, 468, 480, 494}
50
51
160 MHz, i = 1:32 {pilot subcarrier indices in 80 MHz – 512, pilot subcarrier indices in 80 MHz + 512}
52
53
54 320 MHz, i = 1:72 {pilot subcarrier indices in 160 MHz – 1024, pilot subcarrier indices in 160 MHz + 1024}
55
56
57
k
58 (#7478)The pilot mapping P n for the subcarrier k for symbol n shall be as specified in Equation (27-102) in
59
60 27.3.12.13 (Pilot subcarriers).
61
62 (#5014)(#7250)(#7249)For a user transmitting on the i-th 106-tone RU in an 80 MHz, a 160 MHz, or a
63 320 MHz PPDU bandwidth (see Table 36-5 (Data and pilot subcarrier indices for RUs in an 80 MHz EHT
64 PPDU), Table 36-6 (Data and pilot subcarrier indices for RUs in a 160 MHz EHT PPDU), and Table 36-7
65

Copyright © 2022 IEEE. All rights reserved. 683

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (Data and pilot subcarrier indices for RUs in a 320 MHz EHT PPDU))(#1313), the pilot subcarriers shall be
2 inserted at subcarriers k  K R106i , where K R106i is given by the i-th pilot index set in the row of given PPDU
3
4 bandwidth(#1313) of Table 36-55 (Pilot indices for a 106-tone RU transmission).
5
6
7 Table 36-55—Pilot indices for a 106-tone RU transmission
8
9
10 PPDU bandwidth
11 (#1313)(#1590)
K R106i
12
13
14 {–494, –468, –426, –400}, {–360, –334, –292, –266}, {–246, –220, –178, –152},
15 80 MHz, i = 1:8 {–112, –86, –44, –18}, {18, 44, 86, 112}, {152, 178, 220, 246}, {266, 292, 334, 360},
16 {400, 426, 468, 494}
17
18 160 MHz, i = 1:16 {pilot subcarrier indices in 80 MHz – 512, pilot subcarrier indices in 80 MHz + 512}
19 320 MHz, i = 1:32 {pilot subcarrier indices in 160 MHz – 1024, pilot subcarrier indices in 160 MHz + 1024}
20
21
22
23 k
24 (#7478)The pilot mapping P n for the subcarrier k for symbol n shall be as specified in Equation (27-103) in
25 27.3.12.13 (Pilot subcarriers).
26
27 (#5014)(#7250)(#7249)For a user transmitting on the i-th 242-tone RU in an 80 MHz, a 160 MHz, or a
28
29 320 MHz PPDU bandwidth (see Table 36-5 (Data and pilot subcarrier indices for RUs in an 80 MHz EHT
30 PPDU), Table 36-6 (Data and pilot subcarrier indices for RUs in a 160 MHz EHT PPDU), and Table 36-7
31 (Data and pilot subcarrier indices for RUs in a 320 MHz EHT PPDU))(#1313), the pilot subcarriers shall be
32 inserted at subcarriers k  K R242i , where K R242i is given by the i-th pilot index set in the row of given PPDU
33
34 bandwidth(#1313) of Table 36-56 (Pilot indices for a 242-tone RU transmission).
35
36
37 Table 36-56—Pilot indices for a 242-tone RU transmission
38
39
40 PPDU bandwidth
41 (#1313)(#1590)
K R242i
42
43
{–494, –468, –426, –400, –360, –334, –292, –266},
44
80 MHz, i = 1:4 {–246, –220, –178, –152, –112, –86, –44, –18}, {18, 44, 86, 112, 152, 178, 220, 246},
45
{266, 292, 334, 360, 400, 426, 468, 494}
46
47
48 160 MHz, i = 1:8 {pilot subcarrier indices in 80 MHz – 512, pilot subcarrier indices in 80 MHz + 512}
49
50 320 MHz, i = 1:16 {pilot subcarrier indices in 160 MHz – 1024, pilot subcarrier indices in 160 MHz + 1024}
51
52
53
54 k
(#7478)The pilot mapping P n for the subcarrier k for symbol n shall be as specified in Equation (27-104) in
55
56 27.3.12.13 (Pilot subcarriers).
57
58 (#5014)(#7250)(#7249)For a user transmitting on the i-th 484-tone RU in an 80 MHz, a 160 MHz, or a
59 320 MHz PPDU bandwidth (see Table 36-5 (Data and pilot subcarrier indices for RUs in an 80 MHz EHT
60
61 PPDU), Table 36-6 (Data and pilot subcarrier indices for RUs in a 160 MHz EHT PPDU), and Table 36-7
62 (Data and pilot subcarrier indices for RUs in a 320 MHz EHT PPDU))(#1313), the pilot subcarriers shall be
63
64
65

684 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 inserted in subcarriers k  K R484i , where K R484i is given by the i-th pilot index set in the row of given PPDU
2
3 bandwidth(#1313) of Table 36-57 (Pilot indices for a 484-tone RU transmission).
4
5
6 Table 36-57—Pilot indices for a 484-tone RU transmission
7
8
9 PPDU bandwidth
10 (#1313)(#1590)
K R484i
11
12 {–494, –468, –426, –400, –360, –334, –292, –266, –246, –220, –178, –152, –112, –86, –44,
13 80 MHz, i = 1:2
–18}, {18, 44, 86, 112, 152, 178, 220, 246, 266, 292, 334, 360, 400, 426, 468, 494}
14
15
16 160 MHz, i = 1:4 {pilot subcarrier indices in 80 MHz – 512, pilot subcarrier indices in 80 MHz + 512}
17
18 320 MHz, i = 1:8 {pilot subcarrier indices in 160 MHz – 1024, pilot subcarrier indices in 160 MHz + 1024}
19
20
21
22 k
(#7478)The pilot mapping P n for the subcarrier k for symbol n shall be as specified in Equation (27-105) in
23
24 27.3.12.13 (Pilot subcarriers).
25
26 (#5014)(#7250)(#7249)For a user transmitting on the i-th 996-tone RU in an 80 MHz, a 160 MHz, or a
27 320 MHz PPDU bandwidth (see Table 36-5 (Data and pilot subcarrier indices for RUs in an 80 MHz EHT
28 PPDU), Table 36-6 (Data and pilot subcarrier indices for RUs in a 160 MHz EHT PPDU), and Table 36-7
29
30 (Data and pilot subcarrier indices for RUs in a 320 MHz EHT PPDU))(#1313), the pilot subcarriers shall be
31 inserted at subcarriers k  K R996i , where K R996i is given by the i-th pilot index set in the row of given PPDU
32
33 bandwidth(#1313) of Table 36-58 (Pilot indices for a 996-tone RU transmission).
34
35
36 Table 36-58—Pilot indices for a 996-tone RU transmission
37
38
39 PPDU bandwidth
K R996i
40 (#1313)(#1590)
41
42 80 MHz, i = 1 {–468, –400, –334, –266, –220, –152, –86, –18, 18, 86, 152, 220, 266, 334, 400, 468}
43
44 160 MHz, i = 1:2
45 {pilot subcarrier indices in 80 MHz – 512}, {pilot subcarrier indices in 80 MHz + 512}
(#1996)
46
47
320 MHz, i = 1:4
48 {pilot subcarrier indices in 160 MHz – 1024},{pilot subcarrier indices in 160 MHz + 1024}
(#1996)(#1591)
49
50
51
52
k
53 (#7478)The pilot mapping Pn for the subcarrier k for symbol n shall be specified in Equation (27-106) in
54 27.3.12.13 (Pilot subcarriers).
55
56
57 (#5015)(#7250)(#7249)For a user transmitting on the i-th 2×996-tone RU in a 160 MHz or a 320 MHz
58 PPDU bandwidth (see Table 36-6 (Data and pilot subcarrier indices for RUs in a 160 MHz EHT PPDU), and
59 Table 36-7 (Data and pilot subcarrier indices for RUs in a 320 MHz EHT PPDU))(#1313), the pilot
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 685

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 subcarriers shall be inserted in subcarriers k  K R2  996i , where K R2  996i is given by the i-th pilot index set in
2
3 the row of given PPDU bandwidth(#1313) of Table 36-59 (Pilot indices for a 2×996-tone RU transmission).
4
5
6 Table 36-59—Pilot indices for a 2×996-tone RU transmission
7
8
9 PPDU bandwidth
10 K R2  996i
(#1313)(#1590)
11
12 {–980, –912, –846, –778, –732, –664, –598, –530, –494, –426, –360, –292, –246, –178,
13 160 MHz, i = 1
–112, –44, 44, 112, 178, 246, 292, 360, 426, 494, 530, 598, 664, 732, 778, 846, 912, 980}
14
15 320 MHz, i = 1:2
{pilot subcarrier indices in 160 MHz – 1024},{pilot subcarrier indices in 160 MHz + 1024}
16 (#1996)(#1997)
17
18
19
20 k
The pilot mapping P n for the subcarrier k for symbol n shall be as specified in Equation (27-107) in
21
22 27.3.12.13 (Pilot subcarriers).
23
24 (#7251)(#7250)(#7249)For a user transmitting on a 4×996-tone RU in a 320 MHz PPDU bandwidth (see
25 Table 36-7 (Data and pilot subcarrier indices for RUs in a 320 MHz EHT PPDU))(#1313), the pilot
26
27 subcarriers shall be inserted at subcarriers k  K R4  996i , where K R4  996i is given by the pilot index set in the
28 row of given PPDU bandwidth(#1313) of Table 36-60 (Pilot indices for a 4×996-tone RU transmission).
29
30
31
32 Table 36-60—Pilot indices for a 4×996-tone RU transmission
33
34
PPDU bandwidth
35
(#1313)(#1590)
K R4  996i
36
37
{–2004, –1936, –1870, –1802, –1756, –1688, –1622, –1554, –1518, –1450, –1384, –1316,
38
–1270, –1202, –1136, –1068, –980, –912, –846, –778, –732, –664, –598, –530, –494, –426,
39
320 MHz(#7251) –360, –292, –246, –178, –112, –44, 44, 112, 178, 246, 292, 360, 426, 494, 530, 598, 664,
40
732, 778, 846, 912, 980, 1068, 1136, 1202, 1270, 1316, 1384, 1450, 1518, 1554, 1622,
41
1688, 1756, 1802, 1870, 1936, 2004}
42
43
44
45 k
46 The pilot mapping Pn for the subcarrier k for symbol n shall be as specified in Equation (36-80) and
47 Equation (36-81).
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

686 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 K R4  996
2 Pn i
= {  n mod 8   n + 1  mod 8   n + 2  mod 8   n + 3  mod 8   n + 4  mod 8   n + 5  mod 8 (36-80)
3
4   n + 6  mod 8   n + 7  mod 8   n + 8  mod 8   n + 9  mod 8   n + 10  mod 8   n + 11  mod 8
5
6   n + 12  mod 8   n + 13  mod 8   n + 14  mod 8   n + 15  mod 8  n mod 8   n + 1  mod 8   n + 2  mod 8
7
8   n + 3  mod 8   n + 4  mod 8   n + 5  mod 8   n + 6  mod 8   n + 7  mod 8   n + 8  mod 8
9
10   n + 9  mod 8   n + 10  mod 8   n + 11  mod 8   n + 12  mod 8   n + 13  mod 8   n + 14  mod 8
11
  n + 15  mod 8  n mod 8   n + 1  mod 8   n + 2  mod 8   n + 3  mod 8   n + 4  mod 8
12
13   n + 5  mod 8   n + 6  mod 8   n + 7  mod 8   n + 8  mod 8   n + 9  mod 8   n + 10  mod 8
14
15   n + 11  mod 8   n + 12  mod 8   n + 13  mod 8   n + 14  mod 8   n + 15  mod 8  n mod 8
16
17   n + 1  mod 8   n + 2  mod 8   n + 3  mod 8   n + 4  mod 8   n + 5  mod 8   n + 6  mod 8
18
19   n + 7  mod 8   n + 8  mod 8   n + 9  mod 8   n + 10  mod 8   n + 11  mod 8   n + 12  mod 8
20
21   n + 13  mod 8   n + 14  mod 8   n + 15  mod 8 }
22
23
24 k  K R4  996
i
25 Pn = 0 (36-81)
26
27 where
28
29 m is defined in Table 27-43 (The 8 pilot values in a 242-tone RU).
30
31 For a user transmitting on the MRUs, the pilot subcarriers, mapping and values of MRUs shall follow the
32
33
pilot subcarriers, mapping, and values of each component RU of the MRU except the following pilot
34 mapping and values(#5016).
35
36 k
37
For a user transmitting on the 52+26-tone MRU and 106+26-tone MRU, the pilot mapping P n for the
38 subcarrier k for symbol n and the pilot values(#5016) shall be as specified in from Equation (36-82) to
39 Equation (36-86)(#5017).
40
41
K R52 + 26
42 Pn
i
= {  n mod 6   n + 1  mod 6   n + 2  mod 6   n + 3  mod 6   n + 4  mod 6   n + 5  mod 6 } (36-82)
43
44
45 k  K R52 + 26
i
46 Pn = 0 (36-83)
47
48 K R106 + 26
49 Pn
i
= {  n mod 6   n + 1  mod 6   n + 2  mod 6   n + 3  mod 6   n + 4  mod 6   n + 5  mod 6 } (36-84)
50
51
52 k  K R106 + 26
i
53 Pn = 0 (36-85)
54
55 where
56
57
58  0 = 1  1 = 1  2 = 1  3 = – 1  4 = – 1  5 = 1 (36-86)
59
60 K R52 + 26 and K R106 + 26 are the pilot subcarrier index sets for the i-th 52+26-tone MRU and i-th 106+26-
61 i i

62 tone MRU, respectively (see Table 36-8 (Indices for small size MRUs in an OFDMA 20 MHz
63 EHT PPDU) to Table 36-12 (Indices for small size MRUs in an OFDMA 320 MHz EHT
64 PPDU))(#5018).
65

Copyright © 2022 IEEE. All rights reserved. 687

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The above pilot mapping shall be copied to all spatial streams before the spatial stream cyclic shifts are
2 applied.
3
4
5 36.3.13.12 OFDM modulation
6
7 The time domain waveform of the Data field of an EHT PPDU that is not an EHT TB PPDU for transmit
8
chain iTX , 1  iTX  N TX , shall be as defined in Equation (36-87).
9
10
11
12  i TX 
13 r EHT-Data  t  = (36-87)
14
15
16
17 N SYM – 1 N RU – 1 N user r – 1 N SS r u
18 1 r
19
---------------------------------
N RU – 1
 w T EHT-Data  t – nT SYM   - 
--------------------------
N SS r total k  K
    Qk i
TX  M r u + m 
20 2
n=0 r=0 r u=0 m=1
21  r Kr
22 r=0
23
24 u k
 D k m n r + p n + 2 + NU-SIG + NEHT-SIG P n exp  j2k F EHT  t – nT SYM – T GI Data – T CS EHT  M r u + m    
25
26
27 where
28
29 T SYM is defined in Table 36-18 (Timing-related constants).
30 pn is defined in 17.3.5.10 (OFDM modulation).
31
k
32 Pn is defined based on the RU/MRU size. For any RU/MRU smaller than 4996, except 52+26-
33
34 tone MRU and 106+26-tone MRU, the value is defined for each component RU using
35 Equation (27-101) to Equation (27-107) in 27.3.12.13 (Pilot subcarriers). For 52+26-tone
36 MRU and 106+26-tone MRU, the value is defined from Equation (36-82) to Equation (36-85).
37 For 4996-tone MRU, the value is defined in Equation (36-80) in 36.3.13.11 (Pilot
38 subcarriers).
39
40 N U-SIG equals 2 for any EHT PPDU transmitted by an EHT STA with
41 dot11EHTBaseLineFeaturesImplementedOnly set to true(#7252).
42
43
T CS EHT  Mr u + m  represents the cyclic shift for spatial stream M r u + m as defined in 36.3.12.2.2 (Cyclic
44 shift for EHT modulated fields).
45 T GI Data is the guard interval duration as defined in Table 36-18 (Timing-related constants).
46
u
47 D k m n r is the transmitted constellation for user u in the r-th RU/MRU at subcarrier k, spatial stream m,
48
49
and Data field OFDM symbol n and is defined by Equation (36-88).
50
51
52 u  0 k  K Pilot
D k m n r =  (36-88)
53  d M r  k  m n r u otherwise
54
55
56 where
57 K Pilot is the set of pilot subcarrier indices for the Data field OFDM symbols as defined in 36.3.13.11
58
59 (Pilot subcarriers)
60 Mr  k  is defined in Equation (36-89).
61
62
63 M r  k  =  k': K r min  k'  k   K r – 1 –  k': K r min  k'  k   K Pilot (36-89)
64
65

688 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 where
2 K r min is the minimum value(#3117) of the set K r .
3
4  is the cardinality of a set  .
5
6 NOTE— M r  k  translates a subcarrier index  k  K r  into the index of data symbols in a transmission over RU/MRU
7 r,  0  M r  k   N SD total  (#7658). The subcarrier index k for the data subcarrier is first offset by the minimum value of
8 subcarrier index K r min (for the lower edge subcarrier) in this RU/MRU and number of the unoccupied tones, and then
9 subtracted by the number of pilot subcarriers falling in between the data subcarrier and the edge subcarrier.
10
11 The time domain waveform of the Data field of an EHT TB PPDU for user u in the r-th RU/MRU from
12
13
transmit chain iTX , 1  iTX  N TX , shall be as defined in Equation (36-90).
14
15
16  i TX 
17 r EHT-Data r u  t  = (36-90)
18
19 N SYM – 1 N SS r u
20 1 - 1
21
------------
Kr
 w TEHT-Data  t – nT SYM  -------------------- 
N SS r u k  K
   Q k u  i
TX m
n=0 m=1
22 r

23 u k
24  D k m n r + p n + 4 P n exp  j2k F EHT  t – nT SYM – T GI Data – T CS EHT  M r u + m    
25
26
27 where
28
29 Q k u is defined in 36.3.11 (Mathematical description of signals).
30 Other variables in Equation (36-87) and Equation (36-90) are defined in 36.3.10 (Timing-related
31 parameters) and 36.3.11 (Mathematical description of signals)(#4665).
32
33
34 36.3.13.13 Dual carrier modulation(#2993)
35
36 DCM modulates the same information on a pair of subcarriers. DCM is a modulation scheme for EHT-SIG
37 and Data fields, which is applied for EHT-MCSs 14 and 15(#5431). DCM is applicable only to BPSK, rate-
38 1/2 coding and single spatial stream non-MU-MIMO transmission.
39
40
41 The constellation mapper for DCM is defined in 36.3.13.7 (Constellation mapping(#3115)). The LDPC tone
42 mapper for DCM is defined in 36.3.13.8 (LDPC tone mapper(#3115)). The BCC interleaver for DCM is
43 defined in 36.3.13.6 (BCC interleavers). The segment parser for DCM is defined in 36.3.13.5 (Segment
44 parser).
45
46
47 36.3.14 Packet extension
48
49 A PE field of duration 0 µs, 4 µs, 8 µs, 12 µs, 16 µs, or 20 µs is present in an EHT PPDU. A PE field of
50 duration 20 µs is only allowed (#7253)in the following cases:
51
52 — an EHT MU PPDU with at least one participating STA being modulated with 4096-QAM,
53 — an EHT MU PPDU with more than eight spatial streams transmitted on at least one RU/MRU,
54
55 — a 320 MHz EHT MU PPDU if the size of one of the allocated RU or MRU is greater than 2996,
56 — an EHT TB PPDU
57
58
59 A non-AP EHT STA shall support transmission of an EHT TB PPDU with a PE field of duration up to 20 µs,
60 and reception of an EHT MU PPDU with a PE field of duration up to 20 µs. The PE field provides additional
61 receive processing time at the end of the EHT PPDU. (#7254)The PE field, if present, shall be transmitted
62 with the same average power as the Data field. Other than that, its content is arbitrary. The spectrum used by
63
64 the PE field shall be commensurate with the locations and sizes of the occupied RUs or MRUs in the Data
65 field to minimize power leakage outside of the spectrum used by the Data field. For example, for a 20 MHz

Copyright © 2022 IEEE. All rights reserved. 689

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 OFDMA EHT PPDU, if the occupied RU in the Data field is 106-tone RU, the PE would have a spectrum
2 that is approximately 10 MHz wide.
3
4
5 The duration of the PE field for an EHT MU PPDU is determined by both the pre-FEC padding factor value
6 in the last OFDM symbol of the Data field, and the TXVECTOR parameter
7 NOMINAL_PACKET_PADDING as described in 35.14 (Nominal packet padding values selection
8 rules)(#1954).
9
10
11 For an EHT MU PPDU, the nominal T PE value  T PE nominal  is given by Equation (36-91).
12
13
14 T PE nominal = max u T PE nominal u (36-91)
15
16 where
17
18
T PE nominal u is the nominal T PE value for user u and is also given by Table 36-61 (Nominal TPE values).
19 maxu f  u  is the maximum value of f  u  over all values of u.
20
21
22 In this case, a in Table 36-61 (Nominal TPE values) is given by either Equation (36-58) or Equation (36-
23 59).
24
25
26 Table 36-61—Nominal TPE values
27
28
29 TXVECTOR parameter NOMINAL_PACKET_PADDING[u] (EHT MU PPDU)
30 a
31 0 µs 8 µs 16 µs 20 µs
32
33 1 0 µs 0 µs 4 µs 8 µs
34
35 2 0 µs 0 µs 8 µs 12 µs
36
37 3 0 µs 4 µs 12 µs 16 µs
38
39 4 0 µs 8 µs 16 µs 20 µs
40
41
42
43 The duration of the PE field, T PE , may take values of 0 µs, 4 µs, 8 µs, 12 µs, 16 µs, or 20 µs. TPE for an
44
EHT MU PPDU shall not be less than T PE nominal . T PE for an EHT MU PPDU should be equal to T PE nominal
45
46 to minimize the packet extension overhead. Figure 36-55 (PE field duration of an EHT MU PPDU if the
47 maximum value of TXVECTOR parameters NOMINAL_PACKET_PADDING[u] is 8 µs and
48 TPE = TPE,nominal), Figure 36-56 (PE field duration of an EHT MU PPDU if the maximum value of
49
TXVECTOR parameters NOMINAL_PACKET_PADDING[u] is 16 µs and TPE = TPE,nominal), and
50
51 Figure 36-57 (PE field duration of an EHT MU PPDU if the maximum value of TXVECTOR parameters
52 NOMINAL_PACKET_PADDING[u] is 20 µs and TPE = TPE,nominal(#8140)) show examples of the PE
53 field duration in an EHT MU PPDU if the maximum value of TXVECTOR parameters
54 NOMINAL_PACKET_PADDING[u] is 8 µs,16 µs, and 20 µs, respectively, and T PE = T PE nominal .
55
56
57
58
59
60
61
62
63
64
65

690 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 TPE for an EHT sounding NDP is 4 µs if the PPDU bandwidth is less than or equal to 160 MHz and the
2
3 number of spatial streams of the EHT sounding NDP is less than or equal to 8. Otherwise, T PE for an EHT
4 sounding NDP is 8 µs.
5
6
OFDM
7 modulation
8 FEC output bits Post FEC padding bits Symbol
Symbol
9
10 Data field
a=1
11
12 OFDM
modulation
13 FEC output bits Post FEC padding bits Symbol
Symbol
14
15
Data field
16 a=2
4µs
17 OFDM
modulation
18 FEC output bits
Post FEC
Symbol
Symbol PE
padding bits
19
20
21 a=3
Data field

22 OFDM 8µs
23 modulation
FEC output bits Symbol
Symbol PE
24
25
26 a=4 Data field
27
28 Figure 36-55—PE field duration of an EHT MU PPDU if the maximum value of TXVECTOR
29 parameters NOMINAL_PACKET_PADDING[u] is 8 µs and TPE = TPE,nominal
30
31
32
33
34
35
36 OFDM 4µs
37 modulation
FEC output bits Post FEC padding bits Symbol
Symbol PE
38
39
40 Data field
41 a=1
OFDM 8µs
42 modulation
FEC output bits Post FEC padding bits Symbol PE
43 Symbol
44
45 Data field
46 a=2
12µs
OFDM
47 Post FEC modulation
48 FEC output bits
padding bits
Symbol
Symbol PE
49
50
Data field
51 a=3
52 OFDM 16µs
53 FEC output bits
modulation
Symbol PE
Symbol
54
55
56 a=4 Data field
57
58
59 Figure 36-56—PE field duration of an EHT MU PPDU if the maximum value of TXVECTOR
60 parameters NOMINAL_PACKET_PADDING[u] is 16 µs and TPE = TPE,nominal
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 691

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2
3 OFDM 8µs
4 modulation
FEC output bits Post FEC padding bits Symbol PE
5 Symbol

6
7 Data field
8 a=1
12µs
OFDM
9 modulation
10 FEC output bits Post FEC padding bits Symbol
Symbol PE
11
12 Data field
13 a=2
OFDM 16µs
14 modulation
Post FEC
15 FEC output bits
padding bits
Symbol
Symbol PE
16
17
Data field
18 a=3
19 OFDM 20µs
20 modulation
FEC output bits Symbol
Symbol PE
21
22
23 a=4 Data field
24
25
26
27
28 Figure 36-57—PE field duration of an EHT MU PPDU if the maximum value of TXVECTOR
29 parameters NOMINAL_PACKET_PADDING[u] is 20 µs and TPE = TPE,nominal(#8140)
30
31
32 If transmitting an EHT TB PPDU for which the TXVECTOR parameter TRIGGER_METHOD is
33
34 TRIGGER_FRAME, each transmitter of an EHT TB PPDU shall append a PE field with a duration T PE
35 calculated using Equation (36-92).
36
37
38  LENGTH +2+3
------------------------------------------  4 – T EHT-PREAMBLE – N SYM T SYM
39  3 
40 T PE = ----------------------------------------------------------------------------------------------------------------------------------  4 (36-92)
4
41
42
43 where
44 LENGTH is the value indicated by UL Length subfield of the Common Info field in the Trigger frame
45
(#2671).
46
47 T EHT-PREAMBLE is the value for an EHT TB PPDU in Equation (36-97).
48
49
50 LENGTH + 2 + 3-
-----------------------------------------  4 – T EHT-PREAMBLE
51 N SYM = 3
--------------------------------------------------------------------------------------------- – b PE-Disambiguity (36-93)
52 T SYM
53
54
55 b PE-Disambiguity is the value of the TXVECTOR parameter EHT_TB_PE_DISAMBIGUITY.
56
57 If transmitting an EHT TB PPDU for which the TXVECTOR parameter TRIGGER_METHOD is TRS,
58
59 each transmitter of the EHT TB PPDU shall append a PE field with the duration T PE equal to the value
60 specified in the TXVECTOR parameter DEFAULT_PE_DURATION.
61
62
63 The PE Disambiguity field of the EHT-SIG field for an EHT MU PPDU shall be set to 1 if the condition in
64 Equation (36-94) is met, otherwise it shall be set to 0.
65

692 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The PE Disambiguity subfield in the Common Info field of the Trigger frame shall be set to 1 if the
2 condition in Equation (36-94) is met for the EHT TB PPDU solicited by the Trigger frame. Otherwise, it
3
shall be set to 0.
4
5
6 TXTIME – SignalExtension – 20 
T PE + 4   TXTIME – SignalExtension – 20 –  ------------------------------------------------------------------------------------  T SYM (36-94)
7  ------------------------------------------------------------------------------------
4  4 
8
9
10 where
11 T PE is the PE field duration.
12
13 T SYM is the symbol duration of the Data field as defined in Table 36-18 (Timing-related constants).
14 TXTIME (in microseconds) is defined in 36.4.3 (TXTIME and PSDU_LENGTH calculation).
15
16 SignalExtension is 0 µs if TXVECTOR parameter NO_SIG_EXTN is true and is aSignalExtension as
17 defined in (#2674)Table 27-54 (HE PHY characteristics) if TXVECTOR parameter
18 NO_SIG_EXTN is false.
19
20
21 The receiver computes N SYM and T PE of the received EHT MU PPDU using Equation (36-95) and
22 Equation (36-96).
23
24
25 L_LENGTH + 3-
---------------------------------------  4 – T EHT-PREAMBLE
26 N SYM = 3
27
------------------------------------------------------------------------------------------- – b PE-Disambiguity (36-95)
T SYM
28
29
30  L_LENGTH + 3-
---------------------------------------  4 – T EHT-PREAMBLE – N SYM T SYM
31  3 
32 T PE = -------------------------------------------------------------------------------------------------------------------------------  4 (36-96)
33 4
34
35 where
36 L_LENGTH is the value indicated by the LENGTH field of the L-SIG field.
37
38
39
40 T EHT-PREAMBLE (36-97)
41
42
43  T RL-SIG + T U-SIG + T EHT-STF-T + N EHT-LTF T EHT-LTF-SYM for an EHT TB PPDU
44 = 
45  T RL-SIG + T U-SIG + N EHT-SIG T EHT-SIG + T EHT-STF-NT + N EHT-LTF T EHT-LTF-SYM for an EHT MU PPDU
46
47 T RL-SIG , T EHT-STF-T , TEHT-STF-NT , TEHT-LTF-SYM , T U-SIG , and T EHT-SIG are defined in Table 36-18 (Timing-
48
49 related constants).
50 N EHT-SIG and N EHT-LTF are defined in Table 36-23 (Frequently used parameters).
51
52 b PE-Disambiguity is the value indicated by the PE Disambiguity subfield of the EHT-SIG field for an EHT MU
53 PPDU, or the value indicated by the PE Disambiguity subfield in the Common Info field in the
54 Trigger frame for an EHT TB PPDU.
55
56
57 36.3.15 Non-HT duplicate transmission
58
59 If the TXVECTOR parameter FORMAT is NON_HT and the TXVECTOR parameter
60 NON_HT_MODULATION is NON_HT_DUP_OFDM, the transmitted PPDU is a (#5532)non-HT
61 duplicate PPDU. Non-HT duplicate transmission is used to transmit to non-HT STAs, HT STAs, VHT STAs,
62
63 HE STAs, and EHT STAs that may be present in a part of a 40 MHz, 80 MHz, 160 MHz, or 320 MHz
64
65

Copyright © 2022 IEEE. All rights reserved. 693

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 channel (see Table 36-3 (Interpretation of FORMAT, NON_HT_MODULATION, and CH_BANDWIDTH

2 parameters)). The RL-SIG, U-SIG, EHT-SIG, EHT-STF, EHT-LTF, and PE fields are not transmitted.
3
4
5 The L-STF and L-LTF fields shall be transmitted in the same way as in the EHT transmission. The L-SIG
6 field shall be transmitted in the same way as in the EHT transmission, with the following exceptions:
7 — The Rate and Length fields shall follow 17.3.4 (SIGNAL field)
8
9 — The four additional subcarriers at indices  27 and  28 are not modulated (no energy)
10
11 (#8141)NOTE—For a non-HT duplicate PPDU transmission that is a preamble punctured PPDU, the L-STF, L-LTF, and
12 L-SIG fields are not transmitted in each punctured 20 MHz subchannel.
13
14 In a 40 MHz non-HT duplicate transmission, the Data field shall be as defined by Equation (19-61).
15
16 In an 80 MHz or 160 MHz non-HT duplicate transmission, the Data field shall be as defined by
17
Equation (27-123).
18
19
20 In a 320 MHz non-HT duplicate transmission, the Data field shall be as defined by Equation (36-
21 98)(#3118).
22
23
24 i TX 1
25 r non-HT  BW  t  = ------------------------------------------------------------------------------------------ (36-98)
26 Tone  20MHz
27 N TX N NON_HT_DUP_OFDM-Data -------------------- -
N 20MHz
28
N SYM – 1 N 20MHz – 1
29 
30  w TSYM  t – nT SYM     1 – INACTIVE_SUBCHANNELS  i BW  

31 n=0 i BW = 0
32
33
i TX 
26
34
35    k – KShift  iBW   BW  D k n + p n + 1 P k  exp  j2  k – K Shift  i BW   F  t – nT SYM – T GI – T CS  

36 k = – 26
37
38
39 where
40
41 N 20MHz and K Shift  i  are defined in 36.3.12.3 (L-STF)(#5569).
42 P k and p n are defined in 17.3.5.10 (OFDM modulation).
43
44 D k n is defined in Equation (21-26).
45
46
 k BW is defined in Equation (36-12)(#4694).
47 i
TX
48
T CS represents the cyclic shift for transmit chain iTX with a value defined in 36.3.12.2.1 (Cyclic
49 shift for pre-EHT modulated fields).
50 Tone
51
N NON_HT_DUP_OFDM-Data has the value given in Table 36-26 (Number of modulated subcarriers and guard
52 interval duration values for EHT PPDU fields).
53 INACTIVE_SUBCHANNELS  x  is bit x of the TXVECTOR parameter INACTIVE_SUBCHANNELS
54
55 if present, and is 0 otherwise.
56  20MHz is, if the TXVECTOR parameter INACTIVE_SUBCHANNELS is present, equal to the
57 number of bits with value 0 in the TXVECTOR parameter INACTIVE_SUBCHANNELS.
58
59 Otherwise, it is equal to N 20MHz .
60 Other variables in Equation (36-98) are defined in 36.3.10 (Timing-related parameters) and 36.3.11
61 (Mathematical description of signals)(#4665).
62
63
64
65

694 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#1574)(#1576)(#3074)(#5019)For a non-HT duplicate PPDU transmission that is a preamble punctured

2 PPDU, each punctured 20 MHz subchannel is indicated as punctured by the value of 1 in the corresponding
3
bit of the TXVECTOR parameter INACTIVE_SUBCHANNELS. If the TXVECTOR parameter
4
5 RU_ALLOCATION is included when transmitting a non-HT duplicate PPDU, then RU_ALLOCATION
6 shall be set to the value of 26 (000011010 in binary representation) for any 242-tone RU aligned with the
7 punctured 20 MHz subchannel. Each 20 MHz subchannel that is not punctured is indicated as such by
8 including the value of 64 (001000000 in binary representation) in the 9 bits of the TXVECTOR parameter
9
RU_ALLOCATION corresponding to the 242-tone RU aligned with that 20 MHz subchannel.
10
11
12 36.3.16 Transmit requirements for PPDUs sent in response to a triggering frame
13
14 36.3.16.1 Introduction
15
16
17 An AP may solicit simultaneous EHT TB PPDU transmissions, or simultaneous non-HT or non-HT
18 duplicate PPDU transmissions from multiple non-AP STAs using a triggering frame. Since there are
19 multiple transmitters, transmission time, frequency, sampling symbol clock, and power pre-correction (in
20 the case of an EHT TB PPDU) by the non-AP STAs are necessary to mitigate synchronization and
21
interference issues at the AP. Frequency and sampling clock pre-corrections are needed to prevent
22
23 inter-carrier interference. Power pre-correction is necessary to control interference between EHT TB PPDU
24 transmissions from the non-AP STAs. An AP may solicit simultaneous EHT TB PPDU transmissions from
25 both Class A and Class B devices. A non-AP STA that supports EHT TB PPDU transmission shall support
26 power pre-correction as described in 36.3.16.2 (Power pre-correction) and shall meet the pre-correction
27
accuracy requirements described in 36.3.16.3 (Pre-correction accuracy requirements).
28
29
30 36.3.16.2 Power pre-correction
31
32 A STA transmits an EHT TB PPDU at the STA’s maximum transmit power for the assigned EHT-MCS if the
33
UL Target Receive Power subfield of the User Info field in the Trigger frame that solicits the EHT TB PPDU
34
35 or the UL Target Receive Power subfield of the TRS Control field of the frame that solicits a response in an
36 EHT TB PPDU indicates that the maximum transmit power is needed.
37
38 STA
39 Otherwise, the STA calculates the transmit power, Txpwr , of the EHT TB PPDU for the assigned EHT-MCS
40 using Equation (36-99).
41
42 STA
43 Tx pwr = PL DL + TargetRx pwr (36-99)
44
45
where
46
47 PLDL is the downlink pathloss.
48 TargetRx pwr is the expected receive signal power indicated in the UL Target Receive Power subfield in
49
50 the User Info field in the Trigger frame or the UL Target Receive Power subfield in the TRS
51 Control field.
52
53
54 The STA computes PL DL using Equation (36-100).
55
56 AP
57 PL DL = Tx pwr – Rx pwr (36-100)
58
59 where
60 AP
61 Tx pwr is the AP’s transmit power, normalized to 20 MHz and expressed in dBm(#7255), as indicated
62 by the AP Tx Power subfield of the Common Info field in the Trigger frame, the encoding of
63 which is specified in 9.3.1.22 (Trigger frame format), or the AP Tx Power subfield of the TRS
64
65 Control field, the encoding of which is specified in 9.2.4.6a.1 (TRS Control).

Copyright © 2022 IEEE. All rights reserved. 695

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Rx pwr is the receive signal power, normalized to 20 MHz and expressed in dBm(#7255), at the
2
3 antenna connector of the STA of the triggering PPDU. Rxpwr is an average of the receive
4 signal power over the antennas on which the average PLDL is being computed. If the triggering
5
6 PPDU is a HT-mixed, VHT, HE, or EHT PPDU, then the receive signal power is measured
7 from the fields prior to the HT-STF, VHT-STF, HE-STF, or EHT-STF, respectively.
8 AP STA
9 NOTE 1— Txpwr and Rxpwr are normalized to 20 MHz and expressed in dBm, while Txpwr and TargetRx pwr are
10 expressed in dBm without normalization(#7255).
11
12 A STA that applies beamforming in the UL should take the beamforming gain into account when calculating
13 the transmit power needed to meet the (#6142)UL target receive power.
14
AP
15 NOTE 2—An AP could account for its beamforming gain in Txpwr or TargetRxpwr (#6143) if the triggering PPDU
16 used beamforming.
17
18 The transmit power of the EHT TB PPDU is further subject to a STA’s minimum and maximum transmit
19 power limit due to hardware capability, regulatory requirements and local maximum transmit power levels
20
21 (see 11.7.5 (Specification of regulatory and local maximum transmit power levels)) as well as non-IEEE
22 802.11 in-device coexistence requirements.
23
24 A STA includes its UL power headroom in the EHT TB PPDU following the rules defined in
25 (#5570)26.5.2.4 (A-MPDU contents in an HE TB PPDU), where the rules related to HE TB PPDUs also
26
27 apply to EHT TB PPDUs. See 35.5.2.3 (Non-AP STA behavior for UL MU operation) for details.
28
29 36.3.16.3 Pre-correction accuracy requirements
30
31
32 A STA that transmits an EHT TB PPDU shall support per chain max  P – 32 – 10  dBm as the minimum
33 transmit power, where P is the maximum power, in dBm, that the STA can transmit at the antenna connector
34 of that chain using EHT-MCS 0 while meeting the transmit EVM and spectral mask requirements. A STA
35
transmitting at and above the minimum power, but below P max MCS7 , shall support the EVM requirements for
36
37 EHT-MCS 7 even if the EHT-MCS used for the transmission is lower than EHT-MCS 7, where Pmax MCS7 is
38
the maximum transmit power supported by the STA for EHT-MCS 7 in an EHT TB PPDU.
39
40
41 A STA that transmits an EHT TB PPDU shall support the absolute and relative transmit power requirements
42 and the RSSI measurement accuracy requirements defined in Table 36-62 (Transmit power and RSSI
43 measurement accuracy).
44
45
46
47 Table 36-62—Transmit power and RSSI measurement accuracy
48
49
50 Minimum requirement
51 Parameter Comments
52 Class A Class B
53
54 Absolute transmit power ±3 dB ±9 dB Accuracy of achieving a specified transmit power.
55 accuracy
56
57 RSSI measurement ±3 dB ±5 dB The difference between RSSI and the received power.
58 accuracy Requirements are valid from minimum receive to
59 maximum receive input power.
60 Relative transmit power N/A ±3 dB Accuracy of achieving a change in transmit power for
61 accuracy consecutive EHT TB PPDU.
62 The relative transmit power accuracy is applicable only
63 to Class B device.
64
65

696 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The absolute transmit power accuracy is applicable for the entire range of transmit power that the STA is
2 intending to use for the current band of operation. The RSSI accuracy requirements shall be applied to
3
receive signal level range from –82 dBm to –20 dBm in the 2.4 GHz band and –82 dBm to –30 dBm in the
4
5 5 GHz and 6 GHz bands. The requirements are for nominal (room) temperature conditions. The RSSI shall
6 be measured during the reception of the non-EHT portion of the EHT PPDU preamble.
7
8 A STA compensates for carrier frequency offset (CFO) error and symbol clock error with respect to the
9
corresponding triggering PPDU when transmitting the following types of PPDUs:
10
11 — EHT TB PPDU
12
— Non-HT or non-HT duplicate PPDU with the TXVECTOR parameter TRIGGER_RESPONDING
13
14 set to true
15 NOTE 3—The MU-RTS Trigger frame solicits transmission of a non-HT or non-HT duplicate PPDU and not an EHT
16 TB PPDU. The non-HT or non-HT duplicate PPDU transmitted as a response to an MU-RTS Trigger frame carries a
17 CTS frame.
18
19
20 After compensation, the absolute value of residual CFO error with respect to the corresponding triggering
21 PPDU shall not exceed the following levels when measured at the 10% point of the complementary
22 cumulative distribution function (CCDF) of CFO errors in AWGN at a received power of –60 dBm in the
23 primary 20 MHz:
24
25 — 350 Hz for the data subcarriers of an EHT TB PPDU
26 — 2 kHz for a non-HT PPDU or non-HT duplicate PPDU
27
28
29 The residual CFO error measurement on an EHT TB PPDU shall be made after the U-SIG field. The
30 residual CFO error measurement on the non-HT or non-HT duplicate PPDU shall be made after the L-STF
31 field. The symbol clock error shall be compensated by the same ppm amount as the CFO error.
32
33
A STA that transmits an EHT TB PPDU, non-HT PPDU, or non-HT duplicate PPDU in response to a
34
35 triggering PPDU shall ensure that the transmission start time of the EHT TB PPDU, non-HT PPDU, or
36 non-HT duplicate PPDU is within ±0.4 µs + 16 µs from the end, at the STA’s transmit antenna connector, of
37 the last OFDM symbol of the triggering PPDU (if it contains no PE field) or of the PE field of the triggering
38 PPDU (if the PE field is present).
39
40 NOTE 4—This end instant is before any signal extension, so this is equivalent to EHT TB PPDU transmission within
41 0.4 µs of SIFS after the end of the triggering PPDU including signal extension.
42
43 36.3.17 Beamforming
44
45
46 36.3.17.1 General
47
48 SU-MIMO and DL MU-MIMO beamforming are techniques used by a STA with multiple antennas (the
49 beamformer) to steer signals using knowledge of the channel to improve throughput. With SU-MIMO
50
beamforming all spatial streams in the transmitted signal are intended for reception at a single STA in an RU
51
52 or MRU. With DL MU-MIMO beamforming, disjoint subsets of the spatial streams are intended for
53 reception at different STAs in an RU of size greater than or equal to 242-tones.
54
55 For SU-MIMO and DL MU-MIMO beamforming in RU or MRU r, the receive signal vector in subcarrier k
56
57 (where subcarrier k is one of the subcarriers in RU or MRU r, k  K r ) at beamformee u,
58 T T T T T
59 y k u =  y k 0 y k 1  y k NRX – 1 , is shown in Equation (36-101), where x k =  x k 0 x k 1  x k Nuser r – 1 
u
60
61 denotes the transmit signal vector in subcarrier k for all N user r beamformees, with
62 T
63 x k u =  x k 0 x k 1  x k NSS r u – 1  being the transmit signal for beamformee u.
64
65

Copyright © 2022 IEEE. All rights reserved. 697

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 y k u = H k u   Q k 0 Q k 1  Q k Nuser r – 1   x k + n (36-101)
2
3
4 where
5 H k u is the channel matrix from the beamformer to beamformee u in subcarrier k with dimensions
6
7 N RXu  N TX .
8
9 N RXu is the number of receive RF chains at beamformee u(#1329).
10 Q k u is a steering matrix for beamformee u in subcarrier k with dimensions N TX  N SS r u .
11
12 N user r is the number of EHT MU PPDU recipients (see Table 36-23 (Frequently used parameters)) in
13 RU or MRU r.
14
15 n is a vector of additive noise and may include interference.
16
17 The DL MU-MIMO steering matrix Q k =  Q k 0 Q k 1  Q k Nuser r – 1  can be determined by the
18
19 beamformer using the beamforming feedback for subcarrier k from beamformee u, where
20 u = 0 1  N user r – 1 . The feedback report format is described in 9.4.1.71 (EHT Compressed
21
22 Beamforming Report field) and 9.4.1.72 (EHT MU Exclusive Beamforming Report field). The steering
23 matrix that is computed (or updated) using new beamforming feedback from some or all of participating
24 beamformees might replace the existing steering matrix Q k for the next DL MU-MIMO data transmission.
25
26
27 For SU-MIMO beamforming, the steering matrix Q k can be determined from the beamforming feedback
28
29 matrix Vk that is sent back to the beamformer by the beamformee using the compressed beamforming
30 feedback matrix format as defined in 19.3.12.3.6 (Compressed beamforming feedback matrix). The
31 feedback report format is described in 9.4.1.71 (EHT Compressed Beamforming Report field).
32
33
34 36.3.17.2 EHT beamforming feedback matrix V
35
36 Upon receipt of an EHT sounding NDP, the beamformee computes a set of matrices for feedback to the
37 beamformer as described in 27.3.16.2 (Beamforming feedback matrix V). The eligible beamformees shall
38
39 remove the spatial stream CSD in 36.3.12.2.2 (Cyclic shift for EHT modulated fields) from the measured
40 channel before computing a set of matrices for feedback to the beamformer.
41
42 The beamforming feedback matrix, V k u , found by the beamformee u for subcarrier k in RU or MRU r shall
43
44 be compressed in the form of angles using the method described in 19.3.12.3.6 (Compressed beamforming
45 feedback matrix). (#2219)The angles,   k u  and   k u  , are quantized according to Table 9-
46
47 74 (Quantization of angles) with b  and b  respectively, as defined by the Codebook Information field of
48 the EHT MIMO Control field (see 9.4.1.70 (EHT MIMO Control field)). The compressed beamforming
49 feedback matrix as defined in 19.3.12.3.6 (Compressed beamforming feedback matrix) is the only Clause 36
50 (Extremely high throughput (EHT) PHY specification) beamforming feedback matrix defined.
51
52
53 The beamformee shall generate the beamforming feedback matrices with the number of rows ( N r ) equal to
54
55 the N SS of the EHT sounding NDP.
56
57 After receiving the angle information,   k u  and   k u  , the beamformer reconstructs V k u using
58
59 Equation (19-79). For SU-MIMO beamforming, the beamformer uses Vk 0 , matrix to determine the steering
60
61
matrix Q k . For DL MU-MIMO beamforming, the beamformer may calculate a steering matrix
62 Q k =  Q k 0 Q k 1  Q k Nuser r – 1  using V k u and SNR k u , 0  u  N user r – 1 , in order to suppress the
63
64
65

698 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 crosstalk(#2220) between participating beamformees. The method used by the beamformer to calculate the
2 steering matrix Q k is implementation specific.
3
4
5 36.3.17.3 EHT CQI feedback
6
7 If the (#2028)EHT NDP Announcement frame requests CQI feedback, then upon receipt of the EHT
8
9 sounding NDP, the beamformee computes CQI feedback as described in 9.4.1.73 (EHT CQI Report
10 field)(#2029). The CQI feedback, CQI s r u , for beamformee u in RU r for spatial stream s shall be
11
12
estimated using the method described in 9.4.1.73 (EHT CQI Report field)(#2030). The CQI values to be fed
13 back are derived from quantized SNRs according to Table 9-91h (Average SNR of RU index k for space-
14 time stream i subfield)(#2031). The beamformee shall transmit the CQI feedback for spatial stream
15 1 2  N c for each of the RU indices for which the CQI report is being requested by the beamformer. The
16
17 beamformer may use the CQI feedback to determine the best range of RUs for a compressed beamforming/
18 CQI report or for RU assignment during a subsequent MU transmissions. The actual use is implementation
19 specific.
20
21
22
36.3.18 EHT sounding NDP
23
24 The EHT sounding NDP is a variant of the EHT MU PPDU. (#4786)In U-SIG field(#5657), if the PPDU
25 Type And Compression Mode field is set to 1, the EHT-SIG MCS field is set to 0 and the Number Of EHT-
26 SIG Symbols field is set to 0, it indicates an EHT sounding NDP. The format of an EHT sounding NDP is
27
28
defined in Figure 36-58 (EHT sounding NDP format(#7256)).
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45 Figure 36-58—EHT sounding NDP format(#7256)
46
47
48 NOTE—The number of EHT-LTF symbols in the EHT sounding NDP is indicated in the Number Of EHT-LTF Symbols
49 field of EHT-SIG.
50
51 The EHT sounding NDP (#4786)(#4912)is an EHT MU PPDU with a single EHT-SIG symbol encoded
52 using EHT-MCS 0 and no Data field. The EHT-SIG field only contains a Common field as defined in
53 Table 36-37 (Common field for EHT sounding NDP) and no User Specific field.
54
55
56 In the EHT sounding NDP, the 242-tone RUs overlapping the 20 MHz channels that are signaled as
57 punctured through the Punctured Channel Indication field of the U-SIG field(#5657) are punctured.
58 (#4786)(#4912)The allowed punctured patterns are given in Table 36-30 (Definition of the Punctured
59 Channel Information field in the U-SIG for an EHT MU PPDU using non-OFDMA
60 transmissions(#8011)(#2402)).
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 699

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 It is mandatory to support the 2 EHT-LTF with 0.8 µs GI and 2 EHT-LTF with 1.6 µs GI. It is optional to
2 support the 4 EHT-LTF with 3.2 µs GI. The other combinations of EHT-LTF type and GI duration are
3
disallowed.
4
5
6 (#4786)(#4912)(#5407)If the Beamformed subfield in EHT-SIG of an EHT sounding NDP is 1, then the
7 receiver of the EHT sounding NDP should not perform channel smoothing when generating the compressed
8 beamforming feedback report.
9
10
11 (#4786)(#4912)The EHT sounding NDP has a PE field that is given as follows:
12 — 4 µs when the PPDU bandwidth is less than or equal to 160 MHz and the number of spatial streams
13 is less than or equal to 8.
14
15 — 8 µs for all the other cases.
16
17 36.3.19 Transmit specification
18
19
20 36.3.19.1 Transmit spectral mask
21
22 36.3.19.1.1 General
23
24
The bandwidth of the spectral mask applied to an EHT MU PPDU and EHT TB PPDU shall be determined
25
26 by the bandwidth indicated in the Bandwidth subfield of the U-SIG field.
27 NOTE 1—In the presence of additional regulatory restrictions, the device has to meet both the regulatory requirements
28 and the mask defined in this subclause.
29
30
31 NOTE 2—Transmit spectral mask figures in this subclause are not drawn to scale.
32
33 NOTE 3—For rules regarding transmit center frequency leakage levels, see 36.3.19.4.2 (Transmit center frequency
34 leakage). The spectral mask requirements in this subclause do not apply to the RF local oscillator.
35
36 For a 20 MHz mask PPDU of EHT format, the interim transmit spectral mask shall have a 0 dBr (dB relative
37 to the maximum spectral density of the signal) bandwidth of 19.5 MHz, –20 dBr at 10.5 MHz frequency
38
offset, –28 dBr at 20 MHz frequency offset, and –40 dBr at 30 MHz frequency offset and above. The interim
39
40 transmit spectral mask for frequency offsets between 9.75 MHz and 10.5 MHz, 10.5 MHz and 20 MHz, and
41 20 MHz and 30 MHz shall be linearly interpolated in decibels domain from the requirements for 9.75 MHz,
42 10.5 MHz, 20 MHz, and 30 MHz frequency offsets. The transmit spectrum shall not exceed the maximum of
43 the interim transmit spectral mask and –53 dBm/MHz at any frequency offset in the 2.4 GHz band. The
44
transmit spectrum shall not exceed the maximum of the interim transmit spectral mask and –39 dBm/MHz at
45
46 any frequency offset in the 5 GHz and 6 GHz bands(#7743)(#5020). Figure 36-59 (Example transmit
47 spectral mask for a 20 MHz mask PPDU) shows an example of the resulting overall spectral mask when the
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

700 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 –40 dBr spectrum level is above –53 dBm/MHz in the 2.4 GHz band or when the –40 dBr spectrum level is
2 above –39 dBm/MHz in the 5 GHz and 6 GHz bands(#7743)(#5020).
3
4
5 PSD
6
7 0 dBr
8
9
10
11
12 -20 dBr
13
14 -28 dBr
15
16
17
18
19
20 -40 dBr
21 Freq [MHz]
22
23
-30 -20 -10.5 -9.75 9.75 10.5 20 30
24
25 Figure 36-59—Example transmit spectral mask for a 20 MHz mask PPDU
26
27
28 For a 40 MHz mask PPDU of EHT format, the interim transmit spectral mask shall have a 0 dBr (dB relative
29
to the maximum spectral density of the signal) bandwidth of 39 MHz, –20 dBr at 20.5 MHz frequency
30
31 offset, –28 dBr at 40 MHz frequency offset, and –40 dBr at 60 MHz frequency offset and above. The
32 interim transmit spectral mask for frequency offsets in between 19.5 MHz and 20.5 MHz, 20.5 MHz and
33 40 MHz, and 40 MHz and 60 MHz shall be linearly interpolated in decibels domain from the requirements
34 for 19.5 MHz, 20.5 MHz, 40 MHz, and 60 MHz frequency offsets. The transmit spectrum shall not exceed
35
the maximum of the interim transmit spectral mask and –56 dBm/MHz at any frequency offset
36
37 (#7743)(#5020)in the 2.4 GHz band. The transmit spectrum shall not exceed the maximum of the interim
38 spectral mask and –39 dBm/MHz at any frequency offset in the 5 GHz and 6 GHz bands. Figure 36-60
39 (Example transmit spectral mask for a 40 MHz mask PPDU) shows an example of the resulting overall
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 701

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 spectral mask when the –40 dBr spectrum level is above –56 dBm/MHz (#7743)(#5020)in the 2.4 GHz band
2 or when the –40 dBr spectrum level is above –39 dBm/MHz in the 5 GHz and 6 GHz bands.
3
4
5 PSD
6
7 0 dBr
8
9
10
11
12 -20 dBr
13
14 -28 dBr
15
16
17
18
19
20 -40 dBr
21
Freq [MHz]
22
23
-60 -40 -20.5 -19.5 19.5 20.5 40 60
24
25
26 Figure 36-60—Example transmit spectral mask for a 40 MHz mask PPDU
27
28
29 For an 80 MHz mask PPDU of EHT format, if the preamble puncturing is not applied, the interim transmit
30 spectral mask shall have a 0 dBr (dB relative to the maximum spectral density of the signal) bandwidth of
31 79 MHz, –20 dBr at 40.5 MHz frequency offset, –28 dBr at 80 MHz frequency offset, and –40 dBr at
32 120 MHz frequency offset and above. The interim transmit spectral mask for frequency offsets in between
33
39.5 MHz and 40.5 MHz, 40.5 MHz and 80 MHz, and 80 MHz and 120 MHz shall be linearly interpolated
34
35 in decibels domain(#5021) from the requirements for 39.5 MHz, 40.5 MHz, 80 MHz, and 120 MHz
36 frequency offsets. The transmit spectrum shall not exceed the maximum of the interim transmit spectrum
37 mask and –39 dBm/MHz(#7743)(#5020) at any frequency offset. Figure 36-61 (Example transmit spectral
38 mask for an 80 MHz mask PPDU) shows an example of the resulting overall spectral mask when the –
39
40 dBr spectrum level is above –39 dBm/MHz(#7743)(#5020).
40
41
42 For an 80 MHz mask PPDU of EHT format, if the preamble puncturing is applied, the
43 interim(#7743)(#5020) spectral mask is subject to the mask defined in Figure 36-61 (Example transmit
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

702 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 spectral mask for an 80 MHz mask PPDU) and the additional restrictions defined for preamble puncturing in
2 36.3.19.1.2 (Additional restrictions for puncturing in EHT PPDU).
3
4 PSD
5
6 0 dBr
7
8
9
10
11
-20 dBr
12
13
14 -28 dBr
15
16
17
18
19
20 -40 dBr
21 Freq [MHz]
22
23 -120 -80 -40.5 -39.5 39.5 40.5 80 120
24
25 Figure 36-61—Example transmit spectral mask for an 80 MHz mask PPDU
26
27
28 For a 160 MHz mask PPDU of EHT format, if the preamble puncturing is not applied, the interim transmit
29 spectral mask shall have a 0 dBr (dB relative to the maximum spectral density of the signal) bandwidth of
30 159 MHz, –20 dBr at 80.5 MHz frequency offset, –28 dBr at 160 MHz frequency offset, and –40 dBr at
31
32 240 MHz frequency offset and above. The interim transmit spectral mask for frequency offsets in between
33 79.5 MHz and 80.5 MHz, 80.5 MHz and 160 MHz, and 160 MHz and 240 MHz shall be linearly
34 interpolated in dB domain from the requirements for 79.5 MHz, 80.5 MHz, 160 MHz, and 240 MHz
35 frequency offsets. The transmit spectrum shall not exceed the maximum of the interim transmit spectrum
36 mask and –39 dBm/MHz(#7743)(#5020) at any frequency offset. Figure 36-62 (Example transmit spectral
37
38 mask for a 160 MHz mask PPDU) shows an example of the resulting overall spectral mask when the –
39 40 dBr spectrum level is above –39 dBm/MHz(#7743)(#5020).
40
41 For a 160 MHz mask PPDU of EHT format, if the preamble puncturing is applied, the
42 interim(#7743)(#5020) spectral mask is subject to the mask defined in Figure 36-62 (Example transmit
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 703

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 spectral mask for a 160 MHz mask PPDU) and the additional restrictions defined for preamble puncturing in
2 36.3.19.1.2 (Additional restrictions for puncturing in EHT PPDU).
3
4
5 PSD
6
7 0 dBr
8
9
10
11
12
-20 dBr
13
14
-28 dBr
15
16
17
18
19
20
-40 dBr
21
22 Freq [MHz]
23
24 -240 -160 -80.5 -79.5 79.5 80.5 160 240
25
26 Figure 36-62—Example transmit spectral mask for a 160 MHz mask PPDU
27
28
29 For a 320 MHz mask PPDU of EHT format, if the preamble puncturing is not applied, the interim transmit
30 spectral mask shall have a 0 dBr (dB relative to the maximum spectral density of the signal) bandwidth of
31 319 MHz, –20 dBr at 160.5 MHz frequency offset, –28 dBr at 320 MHz frequency offset, and –40 dBr at
32
33 480 MHz frequency offset and above. The interim transmit spectral mask for frequency offsets in between
34 159.5 MHz and 160.5 MHz, 160.5 MHz and 320 MHz, and 320 MHz and 480 MHz shall be linearly
35 interpolated in decibels domain from the requirements for 159.5 MHz, 160.5 MHz, 320 MHz, and 480 MHz
36 frequency offsets. The transmit spectrum shall not exceed the maximum of the interim transmit spectrum
37 mask and –39 dBm/MHz(#7743)(#5020) at any frequency offset. Figure 36-63 (Example transmit spectral
38
39 mask for a 320 MHz mask PPDU) shows hows an example of the resulting overall spectral mask when the –
40 40 dBr spectrum level is above –39 dBm/MHz(#7743)(#5020).
41
42
43
PSD

44 0dBr
45
46
47
48
49
50 ‐20dBr
51
52 ‐28dBr
53
54
55
56
57
58 ‐40dBr Freq [MHz]
59
‐159.5
‐160.5
‐480

159.5
160.5

60
‐320

320

480

61
62
63 Figure 36-63—Example transmit spectral mask for a 320 MHz mask PPDU
64
65

704 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 For a 320 MHz mask PPDU of EHT format, if the preamble puncturing is applied, the
2 interim(#7743)(#5020) spectral mask is subject to the interim mask defined in Figure 36-63 (Example
3
transmit spectral mask for a 320 MHz mask PPDU) and the additional restrictions defined for preamble
4
5 puncturing in 36.3.19.1.2 (Additional restrictions for puncturing in EHT PPDU).
6
7 For 320 MHz non-HT duplicate PPDU, if the preamble puncturing is not applied, the interim transmit
8 spectral mask shall have a 0 dBr (dB relative to the maximum spectral density of the signal) bandwidth of
9
318 MHz, –20 dBr at 161 MHz frequency offset, –28 dBr at 320 MHz frequency offset, and –40 dBr at
10
11 480 MHz frequency offset and above. The interim transmit spectral mask for frequency offsets in between
12 159 MHz and 161 MHz, 161 MHz and 320 MHz, and 320 MHz and 480 MHz shall be linearly interpolated
13 in decibels domain from the requirements for 159 MHz, 161 MHz, 320 MHz, and 480 MHz frequency
14 offsets. (#7743)The transmit spectrum shall not exceed the maximum of the interim transmit spectrum mask
15
and –39 dBm/MHz at any frequency offset. Figure 36-64 (Example transmit spectral mask for a 320 MHz
16
17 non-HT duplicate PPDU) shows an example of the resulting overall spectral mask when the –40 dBr
18 spectrum level is above –39 dBm/MHz.
19
20
21
22 PSD 0dBr
23
24
25
26
27
28 ‐20dBr
29
30 ‐28dBr
31
32
33
34
35
36 ‐40dBr Freq [MHz]
37
38
‐480

‐159
‐320

‐161

159
161

320

39
480

40
41 Figure 36-64—Example transmit spectral mask for a 320 MHz non-HT duplicate PPDU
42
43
44
45 For 320 MHz non-HT duplicate PPDU, if the preamble puncturing is applied, the spectral mask is subject to
46 the interim mask defined in Figure 36-64 (Example transmit spectral mask for a 320 MHz non-HT duplicate
47 PPDU) and the additional restrictions defined for preamble puncturing in 36.3.19.1.3 (Additional
48 restrictions of preamble puncturing for non-HT duplicate PPDU).
49
50
51 Measurements shall be made using a 100 kHz resolution bandwidth and a 7.5 kHz video bandwidth
52 (#6817)for EHT PPDU.
53
54 (#6817)Measurements shall be made using a 100 kHz resolution bandwidth and a 30 kHz video bandwidth
55 for non-HT duplicate PPDU.
56
57
58 36.3.19.1.2 Additional restrictions for puncturing in EHT PPDU
59
60 (#4639)(#7257)(#8142)For preamble puncturing in EHT MU PPDU, EHT TB PPDU, and non-HT
61 duplicated PPDU, the signal leakage from the occupied subchannels to the punctured subchannels shall
62
63 follow the restrictions as described below subject to the puncturing pattern in EHT MU PPDU, EHT TB
64 PPDU, and non-HT duplicated PPDU, respectively. The puncturing pattern in an EHT MU PPDU is
65

Copyright © 2022 IEEE. All rights reserved. 705

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 indicated by the punctured channel information in U-SIG field(#5657). The puncturing pattern in an EHT
2 TB PPDU and non-HT duplicated PPDU is determined by the Disabled Subchannel Bitmap field in the EHT
3
Operation element defined in 9.4.2.311 (EHT Operation element) (#4627)and signaled to the PHY via the
4
5 DISABLED_SUBCHANNEL_BITMAP parameter in the PHYCONFIG_VECTOR.
6
7 Case 1
8
9
When the lowest and/or the highest subchannel(s) are/is(#5097) punctured in a PPDU, the subchannel edge
10
11 mask as defined in Figure 36-65 (Preamble puncture mask for preamble puncturing at the edge of the EHT
12 PPDU) shall be applied at the lower edge of the lowest occupied subchannel and at the higher edge of the
13 highest occupied subchannel. M is the separation in MHz between the lower edge of the lowest occupied
14 subchannel and the higher edge of the highest occupied subchannel in the PPDU.
15
16
17 Occupied subchannel(s) Punctured subchannel(s)
18
19
20 0dBr
21
22
23
24
PSD

25
26
27 ‐20dBr
28
29
30
31 ‐28dBr
32 Frequency offset (MHz)
Relative to the edge of the punctured subchannel(s)
33
M/2
0.5
0

34
35
36 Figure 36-65—Preamble puncture mask for preamble puncturing at the edge of the EHT
37 PPDU
38
39
40 In this case, the overall spectral mask is constructed in the following manner. First, the interim spectral mask
41 (without preamble puncture) is applied according to the PPDU bandwidth. Second, the preamble puncture
42 mask in Figure 36-65 (Preamble puncture mask for preamble puncturing at the edge of the EHT PPDU) is
43 applied on the lower edge and higher edge of the occupied subchannel(s). Then for each frequency where
44
the interim spectral mask (without preamble puncture) has a value of 0 dBr but the preamble puncture mask
45
46 does not have a value (in the subchannels where preamble puncture is not applied), 0 dBr shall be taken as
47 the overall interim spectral mask value. For the other frequency where both the interim spectral mask
48 (without preamble puncture) and the preamble puncture mask have values greater than or equal to –40 dBr,
49 the lower value shall be taken as the overall interim spectral mask value.
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

706 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Figure 36-66 (Example for the construction of the overall interim spectral mask for 80 MHz EHT PPDU
2 with the lowest 20 MHz subchannel punctured) is an example for the construction of the overall interim
3
spectral mask for 80 MHz EHT PPDU with the lowest 20 MHz subchannel punctured.
4
5
6

PSD
PSD
7
0dBr 0dBr

Puncture mask at the lower edge Puncture mask at the higher edge
8 of the occupied subchannel(s) of the occupied subchannel(s)

9
10 ‐20dBr ‐20dBr

11 ‐28dBr ‐28dBr

12
13
14 ‐40dBr Freq [MHz] Freq [MHz]

15

‐20.5
‐39.5
‐40.5

‐20
‐80

39.5
‐120

40.5

40.5
‐50

70
40
80

120
16 80MHz Spectral mask without preamble puncture Preamble puncture mask
17
18
19
20

PSD
21 0dBr
Overall spectral mask (Bold line)
22
23
24 ‐20dBr
25 ‐28dBr
26
27
28 ‐40dBr Freq [MHz]
29
40
‐20.5
‐20
‐80

39.5
‐120

40.5
‐50

70

80

30
120
31
Figure 36-66—Example for the construction of the overall interim spectral mask for 80 MHz
32
33 EHT PPDU with the lowest 20 MHz subchannel punctured
34
35 Case 2
36
37 When there are two or more contiguous 20 MHz subchannels are punctured in a PPDU (#6094)and the
38
39 punctured channels are not at the edge of the PPDU, the subchannel edge mask as defined in Figure 36-67
40 (Preamble puncture mask for preamble puncturing in the EHT PPDU when the bandwidth of the punctured
41 subchannel is equal to or greater than 40 MHz and the punctured subchannel is not at the edge of the PPDU
42 bandwidth(#7262)) shall be applied at the lower edge of the lowest punctured subchannel(s) and at the
43 higher edge of the highest punctured subchannel(s). M is the contiguous occupied bandwidth in MHz
44
45 adjacent to the punctured subchannel(s). (#7261)Depending on the contiguous occupied bandwidth adjacent
46 to the lower edge of the punctured subchannel(s) and the contiguous occupied bandwidth adjacent to the
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 707

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 higher edge of the punctured subchannel(s), the mask applied at the lower edge and the mask applied at the
2 higher edge of the punctured subchannel can have different value of M.
3
4 Occupied subchannel(s) Punctured subchannel(s)
5
6
7 0dBr
8
9
10
11

PSD
12
13
14 ‐20dBr
15
16 ‐25dBr
17
18 Frequency offset (MHz)
19

M/2
Relative to the edge of the punctured subchannel(s)
0.5

20
0

21
22 Figure 36-67—Preamble puncture mask for preamble puncturing in the EHT PPDU when
23 the bandwidth of the punctured subchannel is equal to or greater than 40 MHz and the
24 punctured subchannel is not at the edge of the PPDU bandwidth(#7262)
25
26
27 In this case, the overall spectral mask is constructed in the following manner. First, the interim spectral mask
28 (without preamble puncture) is applied according to the PPDU bandwidth. Second, the preamble puncture
29
mask in Figure 36-67 (Preamble puncture mask for preamble puncturing in the EHT PPDU when the
30
31 bandwidth of the punctured subchannel is equal to or greater than 40 MHz and the punctured subchannel is
32 not at the edge of the PPDU bandwidth(#7262)) is applied on both the lower edge and higher edge of the
33 punctured subchannel(s). Note that for each frequency at which both the lower edge puncture mask and
34 higher edge puncture mask have value greater than –25 dBr and less than –20 dBr, the larger value of the
35
two masks shall be taken as the preamble puncture mask. Then for each frequency where the interim spectral
36
37 mask (without preamble puncture) has a value but the preamble puncture mask does not have a value (in the
38 subchannels where preamble puncture is not applied), the value of the interim spectral mask (without
39 preamble puncture) shall be taken as the overall interim spectral mask value. For the other frequency where
40 both the interim spectral mask (without preamble puncture) and the preamble puncture mask have values
41
greater than or equal to –25 dBr, the lower value shall be taken as the overall interim spectral mask value.
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

708 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Figure 36-68 (Example for the construction of the overall interim spectral mask for 160 MHz EHT PPDU
2 with the second lowest 40 MHz subchannel punctured) is an example for the construction of the overall
3
interim spectral mask for 160 MHz EHT PPDU with the second lowest 40 MHz subchannel punctured.
4
5
6

PSD
PSD
7 0dBr 0dBr

8
9 Puncture mask at the lower edge Puncture mask at the higher edge
of the punctured subchannel of the punctured subchannel
10
‐20dBr
11 ‐20dBr
‐25dBr

12 ‐28dBr

13
14
15
‐40dBr
16 Freq [MHz] Freq [MHz]

17
‐80.5
‐79.5
‐160
‐240

79.5
80.5

160

‐0.5
‐40
240

‐39.5

‐20
18
80MHz Spectral mask without preamble puncture Preamble puncture mask
19
20
21
22
23
PSD
24 0dBr
Overall spectral mask (Bold line)

25
26
27
28 ‐20dBr
‐25dBr
29 ‐28dBr
30
31
32
33 ‐40dBr Freq [MHz]

34
‐80.5
‐79.5
‐160
‐240

79.5
80.5
‐0.5
‐40

160

240
‐39.5

35
36
37 Figure 36-68—Example for the construction of the overall interim spectral mask for
38 160 MHz EHT PPDU with the second lowest 40 MHz subchannel punctured
39
40 Case 3
41
42
43 When the punctured subchannel is equal to 20 MHz and the punctured 20 MHz subchannel is not at the edge
44 of the PPDU, the mask in Figure 36-69 (Preamble puncture mask for preamble puncturing in the EHT PPDU
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 709

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 when the bandwidth of the punctured subchannel is equal to 20 MHz and the punctured subchannel is not at
2 the edge of the PPDU bandwidth(#7262)) shall be applied at the punctured 20 MHz subchannel.
3
4
5 Occupied subchannel(s) Punctured subchannel Occupied subchannel(s)

6
7
8
9
10
11
12 PSD
13
14
‐20dBr
15
‐23dBr
16
17
18
Frequency offset (MHz)
19 Relative to the edge of the punctured subchannel

19.5
20

10

20
0.5
0

21
22 Figure 36-69—Preamble puncture mask for preamble puncturing in the EHT PPDU when
23
24 the bandwidth of the punctured subchannel is equal to 20 MHz and the punctured sub-
25 channel is not at the edge of the PPDU bandwidth(#7262)
26
27 In this case, the overall spectral mask is constructed in the following manner. First, the interim spectral mask
28
29 (without preamble puncture) is applied according to the PPDU bandwidth. Second, the preamble puncture
30 mask in Figure 36-69 (Preamble puncture mask for preamble puncturing in the EHT PPDU when the
31 bandwidth of the punctured subchannel is equal to 20 MHz and the punctured subchannel is not at the edge
32 of the PPDU bandwidth(#7262)) is applied on the punctured 20 MHz subchannel. Then for each frequency
33 where the interim spectral mask (without preamble puncture) has a value but the preamble puncture mask
34
35 does not have a value (in the subchannels where preamble puncture is not applied), the value of the interim
36 spectral mask (without preamble puncture) shall be taken as the overall interim spectral mask value. For the
37 other frequency where both the interim spectral mask (without preamble puncture) and the preamble
38 puncture mask have values greater than or equal to –23 dBr, the lower value shall be taken as the overall
39 interim spectral mask value.
40
41
42 Figure 36-70 (Example for the construction of the overall interim spectral mask for 80 MHz EHT PPDU
43 with the second lowest 20 MHz subchannel punctured(#6149)) is an example for the construction of the
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

710 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 overall interim spectral mask for 80 MHz EHT PPDU with the second lowest 20 MHz subchannel
2 punctured.
3
4
5

PSD

PSD
0dBr 0dBr
6
7
8
9 ‐20dBr ‐20dBr
‐23dBr
10 ‐28dBr
11
12
13
14 ‐40dBr Freq [MHz] Freq [MHz]

15
‐39.5
‐40.5
‐80

39.5
‐120

40.5

‐0.5
‐20
80

120

‐19.5
16 80MHz Spectral mask without preamble puncture Preamble puncture mask for the punctured middle
17 20MHz subchannel

18
19
20

PSD
21 0dBr

22 Overall spectral mask (Bold line)

23
24 ‐20dBr
25 ‐23dBr

‐28dBr
26
27
28
29 ‐40dBr Freq [MHz]

30
‐40.5
‐39.5
‐120

‐80

39.5
40.5
‐0.5
‐20

70
80

120
‐19.5

31
32
33 Figure 36-70—Example for the construction of the overall interim spectral mask for 80 MHz
34 EHT PPDU with the second lowest 20 MHz subchannel punctured(#6149)
35
36
(#6816)Measurements shall be made using a 100 kHz resolution bandwidth and a 7.5 kHz video bandwidth.
37
38
39 36.3.19.1.3 Additional restrictions of preamble puncturing for non-HT duplicate PPDU
40
41 If preamble puncturing is applied to a non-HT duplicate PPDU, the signal leakage from the occupied
42
subchannels to the punctured subchannels shall also follow the restrictions in 36.3.19.1.2 (Additional
43
44 restrictions for puncturing in EHT PPDU) except the transition frequency width from 0 dBr to –20 dBr is
45 1 MHz instead of 0.5 MHz(#6148)(#7315). For the three cases defined in 36.3.19.1.2 (Additional
46 restrictions for puncturing in EHT PPDU), the preamble puncturing mask for non-HT duplicated PPDU are
47 shown in Figure 36-71 (Preamble puncture mask for preamble puncturing at the edge of the non-HT
48
duplicate PPDU), Figure 36-72 (Preamble puncture mask for preamble puncturing in the non-HT duplicate
49
50 PPDU when the bandwidth of the punctured subchannel is equal to or greater than 40 MHz and the
51 punctured subchannel is not at the edge of the PPDU bandwidth(#7262)), and Figure 36-73 (Preamble
52 puncture mask for preamble puncturing in the non-HT duplicate PPDU when the bandwidth of the
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 711

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 punctured subchannel is equal to 20 MHz and the punctured subchannel is not at the edge of the PPDU
2 bandwidth(#7262)(#1594)), respectively.
3
4
Punctured subchannel(s)
5 Occupied subchannel(s)

6
7 0dBr
8
9
10
11

PSD
12
13 ‐20dBr
14
15
16 ‐28dBr
17 Frequency offset (MHz)
Relative to the edge of the punctured subchannel(s)
18

M/2
0
1

19
20
21 Figure 36-71—Preamble puncture mask for preamble puncturing at the edge of the non-HT
22 duplicate PPDU
23
24
25 Occupied subchannel(s) Punctured subchannel(s)

26
27 0dBr
28
29
30
31
PSD

32
33 ‐20dBr
34
35 ‐25dBr
36
37 Frequency offset (MHz)
M/2

Relative to the edge of the punctured subchannel(s)

38
0
1

39
40
41 Figure 36-72—Preamble puncture mask for preamble puncturing in the non-HT duplicate
42 PPDU when the bandwidth of the punctured subchannel is equal to or greater than 40 MHz
43 and the punctured subchannel is not at the edge of the PPDU bandwidth(#7262)
44
45
46 Occupied subchannel(s) Punctured subchannel Occupied subchannel(s)

47
48
49
50
51
52
PSD

53
54 ‐20dBr
55 ‐23dBr
56
57
58 Frequency offset (MHz)
59 Relative to the edge of the punctured subchannel
10

19
20
0
1

60
61
62 Figure 36-73—Preamble puncture mask for preamble puncturing in the non-HT duplicate
63 PPDU when the bandwidth of the punctured subchannel is equal to 20 MHz and the punc-
64
tured subchannel is not at the edge of the PPDU bandwidth(#7262)(#1594)
65

712 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The rules of constructing the overall spectral mask for preamble punctured non-HT duplicate PPDU is the
2 same as the rules defined in 36.3.19.1.2 (Additional restrictions for puncturing in EHT PPDU) that are used
3
to construct the overall spectral mask for preamble punctured EHT PPDU. Figure 36-74 (Example for the
4
5 construction of the overall interim spectral mask for 320 MHz non-HT duplicated transmission with the
6 lowest 40 MHz subchannel punctured) is an example for the construction of the overall interim spectral
7 mask for 320 MHz non-HT duplicate PPDU with the lowest 40 MHz subchannel punctured.
8
9
10

PSD
0dBr
11 0dBr

12
13
14 ‐20dBr
15 ‐28dBr ‐28dBr
16
17
18
‐40dBr
19 Freq [MHz] Freq [MHz]

‐120
20

‐260

160
‐320

‐40.5

300
‐159
‐161
‐480

159
161

161
320

480

21 320MHz Spectral mask without preamble puncture Preamble puncture mask

22
23
24
25
26 0dBr

27 Overall spectral mask (Bold line)

28
29
30
31 ‐28dBr

32
33
34 ‐40dBr Freq [MHz]

35
161
160
‐121
‐320

‐120
‐260
‐480

300
320
159

480

36
37
38 Figure 36-74—Example for the construction of the overall interim spectral mask for
39 320 MHz non-HT duplicated transmission with the lowest 40 MHz subchannel punctured
40
41 NOTE—For non-HT duplicate 80 MHz and 160 MHz PPDUs, the mask defined in 21.3.17.1 (Transmit spectrum mask)
42 shall be used as the interim spectral mask (without preamble puncture) to construct the overall preamble puncturing
43 mask.
44
45 (#6817)Measurements shall be made using a 100 kHz resolution bandwidth and a 30 kHz video bandwidth.
46
47 36.3.19.2 Spectral flatness
48
49
50 Spectral flatness measurements shall be conducted using BPSK modulated EHT PPDUs. The EHT PPDUs
51 shall be demodulated using the following (or equivalent) procedure:
52
53 a) Start of PPDU shall be detected.
54 b) Transition from L-STF to L-LTF shall be detected and fine timing shall be established.
55
56 c) Coarse and fine frequency offsets shall be estimated.
57 d) Symbols in a PPDU shall be manipulated to account for both frequency error and sampling offset
58 drift.
59
60 e) For each EHT-LTF symbol, transform the symbol into subcarrier received values, estimate the
61 phase from the pilot subcarriers, and compensate the subcarrier values according to the estimated
62 phase.
63
64 f) For each of the data OFDM symbols: transform the symbol into subcarrier received values.
65

Copyright © 2022 IEEE. All rights reserved. 713

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The spectral flatness test shall be performed over at least 20 EHT PPDUs. The PPDUs under test shall be at
2 least 16 data OFDM symbols long.
3
4
5 Evaluate spectral flatness using the subcarrier received values or the magnitude of the channel estimation of
6 the occupied subcarriers of the transmission EHT PPDUs. Nonoccupied subcarriers of the transmitted EHT
7 PPDUs shall be ignored during averaging and testing. Resource unit power boosting and beamforming
8 should not be used when measuring spectral flatness.
9
10
11 Let E i avg denote the magnitude of the channel estimation on subcarrier i or the average constellation energy
12 of a BPSK modulated subcarrier i in an EHT data symbol. In a contiguous EHT transmission having a
13
14 bandwidth listed in Table 36-63 (Maximum transmit spectral flatness deviations for EHT PPDU), E i avg of
15 each of the subcarriers with indices listed as tested subcarrier indices shall not deviate by more than the
16 specified maximum deviation in Table 36-63 (Maximum transmit spectral flatness deviations for EHT
17
18 PPDU) from the average of E i avg over subcarrier indices listed as averaging subcarrier indices. Averaging
19 of Ei avg is done in the linear domain. For PPDU bandwidth equal to 80 MHz, 160 MHz, and 320 MHz, the
20
21 maximum deviation(#2667) is different depending on whether the preamble puncturing is applied or not.
22
23
24 Table 36-63—Maximum transmit spectral flatness deviations for EHT PPDU
25
26
27 Bandwidth Maximum deviation
Averaging Maximum deviation
28 of EHT Tested subcarrier (dB) without
subcarrier indices (dB) with preamble
29 transmission indices (inclusive) preamble
(inclusive) puncturing
30 (MHz) puncturing
31
32 20 –84 to –2 and –84 to –2 and ±4 N/A
33 +2 to +84 +2 to +84
34
35 –122 to –85 and +4/–6 N/A
36 +85 to +122
37
40 –168 to –3 and –168 to –3 and ±4 N/A
38
+3 to +168 +3 to +168
39
40 –244 to –169 and +4/–6 N/A
41 +169 to +244
42
43 80 –344 to –3 and –344 to –3 and ±4 +4/–6
44 +3 to +344 +3 to +344
45
46 –500 to –345 and +4/–6 +4/–6
47 +345 to +500
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

714 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-63—Maximum transmit spectral flatness deviations for EHT PPDU (continued)
2
3
4 Bandwidth Maximum deviation
Averaging Maximum deviation
5 of EHT Tested subcarrier (dB) without
subcarrier indices (dB) with preamble
6 transmission indices (inclusive) preamble
(inclusive) puncturing
7 (MHz) puncturing
8
9 160 –696 to –515, –696 to –515, ±4 +4/–6
10 –509 to –12, –509 to –12,
11 +12 to +509, and +12 to +509, and
12 +515 to +696 +515 to +696
13
14 –1012 to –697 and +4/–6 +4/–6
15 +697 to +1012
16
17 320 –1400 to –1036, –1400 to –1036, ±4 +4/–6
18 –1012 to –515, –1012 to –515,
19 –509 to –12, –509 to –12,
20 +12 to +509, +12 to +509,
21 +515 to +1012, and +515 to +1012, and
22 +1036 to +1400 +1036 to +1400
23 –2036 to –1539, +4/–6 +4/–6
24 –1533 to –1401,
25 +1401 to +1533,
26 and +1539 to +2036
27
28
29
30 In a contiguous non-HT duplicate transmission having a bandwidth listed in Table 36-64 (Maximum
31
transmit spectral flatness deviations for non-HT duplicate PPDU), E i avg of each of the subcarriers with
32
33 indices listed as tested subcarrier indices shall not deviate by more than the specified maximum deviation in
34 Table 36-64 (Maximum transmit spectral flatness deviations for non-HT duplicate PPDU) from the average
35 of E i avg over subcarrier indices listed as averaging subcarrier indices. Averaging of E i avg is done in the
36
37 linear domain. For PPDU Bandwidth equal to 80 MHz, 160 MHz, and 320 MHz, the maximum deviation is
38 different depending on whether the preamble puncturing is applied.
39
40
41 Table 36-64—Maximum transmit spectral flatness deviations for non-HT duplicate PPDU
42
43
44 Bandwidth Maximum deviation
45 Averaging Maximum deviation
of EHT Tested subcarrier (dB) without
46 subcarrier indices (dB) with preamble
transmission indices (inclusive) preamble
47 (inclusive) puncturing
(MHz) puncturing
48
49 40 –42 to –33, –42 to –33, ±4 N/A
50 –31 to –6, –31 to –6,
51 +6 to +31, and +6 to +31, and
52 +33 to +42 +33 to +42
53
54 –58 to –43 and +4/–6 N/A
55 +43 to +58
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 715

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-64—Maximum transmit spectral flatness deviations for non-HT duplicate PPDU
2
3
4 Bandwidth Maximum deviation
Averaging Maximum deviation
5 of EHT Tested subcarrier (dB) without
subcarrier indices (dB) with preamble
6 transmission indices (inclusive) preamble
(inclusive) puncturing
7 (MHz) puncturing
8
9 80 –84 to –70, –84 to –70, ±4 +4/–6
10 –58 to –33, –58 to –33,
11 –31 to –6, –31 to –6,
12 +6 to +31, +6 to +31,
13 +33 to +58, and +33 to +58, and
14 +70 to +84 +70 to +84
15
16 –122 to –97, +4/–6 +4/–6
17 –95 to –85,
18 +85 to +95, and
19 +97 to +122
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

716 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-64—Maximum transmit spectral flatness deviations for non-HT duplicate PPDU
2
3
4 Bandwidth Maximum deviation
Averaging Maximum deviation
5 of EHT Tested subcarrier (dB) without
subcarrier indices (dB) with preamble
6 transmission indices (inclusive) preamble
(inclusive) puncturing
7 (MHz) puncturing
8
9 160 –172 to –161, –172 to –161, ±4 +4/–6
10 –159 to –134, –159 to –134,
11 –122 to –97, –122 to –97,
12 –95 to –70, –95 to –70,
13 –58 to –44, –58 to –44,
14 +44 to +58, +44 to +58,
15 +70 to +95, +70 to +95,
16 +97 to +122, +97 to +122,
17 +134 to +159, and +134 to +159, and
18 +161 to +172 +161 to +172
19
20 –250 to –225, +4/–6 +4/–6
21 –223 to –198,
22 –186 to –173,
23 –43 to –33,
24 –31 to –6,
25 +6 to +31,
26 +33 to +43,
27 +173 to +186,
28 +198 to +223, and
29 +225 to +250
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 717

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-64—Maximum transmit spectral flatness deviations for non-HT duplicate PPDU
2
3
4 Bandwidth Maximum deviation
Averaging Maximum deviation
5 of EHT Tested subcarrier (dB) without
subcarrier indices (dB) with preamble
6 transmission indices (inclusive) preamble
(inclusive) puncturing
7 (MHz) puncturing
8
9 320 –348 to –326, –348 to –326, ±4 +4/–6
10 –314 to –300, –314 to –300,
11 –212 to –198, –212 to –198,
12 –186 to –161, –186 to –161,
13 –159 to –134, –159 to –134,
14 –122 to –97, –122 to –97,
15 –95 to –84, –95 to –84,
16 +84 to +95, +84 to +95,
17 +97 to +122, +97 to +122,
18 +134 to +159, +134 to +159,
19 +161 to +186, +161 to +186,
20 +198 to +212, +198 to +212,
21 +300 to +314, and +300 to +314, and
22 +326 to +348 +326 to +348
23
24 –506 to –481, +4/–6 +4/–6
25 –479 to –454,
26 –442 to –417,
27 –415 to –390,
28 –378 to –353,
29 –351 to –349,
30 –299 to –289,
31 –287 to –262,
32 –250 to –225,
33 –223 to –213,
34 –83 to –70,
35 –58 to –33,
36 –31 to –6,
37 +6 to +31,
38 +33 to +58,
39 +70 to +83,
40 +213 to +223,
41 +225 to +250,
42 +262 to +287,
43 +289 to +299,
44 +349 to +351,
45 +353 to +378,
46 +390 to +415,
47 +417 to +442,
48 +454 to +479, and
49 +481 to +506
50
51
52
53 For the spectral flatness test, the transmitting STA shall be configured to use a spatial mapping matrix Q k
54 (see 36.3.13.12 (OFDM modulation)) with flat frequency response. Each output port under test of the
55 transmitting STA shall be connected through a cable to one input port of the testing instrumentation. The
56 requirements shall apply to 20 MHz, 40 MHz, 80 MHz, 160 MHz, and 320 MHz contiguous transmissions.
57
58
59 36.3.19.3 Transmit center frequency and symbol clock frequency tolerance
60
61 Transmit center frequency and the symbol clock frequency for all transmit antennas(#4553) shall be derived
62 from the same reference oscillator. The symbol clock frequency and transmit center frequency tolerance
63
64 shall be ±20 ppm in the 5 GHz and 6 GHz bands and ±25 ppm in the 2.4 GHz band. EHT TB PPDU format
65

718 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 is subject to additional requirements as defined in (#4554)36.3.16 (Transmit requirements for PPDUs sent in
2 response to a triggering frame).
3
4
5 Transmit signals with TXVECTOR parameter CH_BANDWIDTH set to CBW320 may be generated using
6 two separate RF local oscillators, one for each of the lower and upper 160 MHz frequency portions.
7
8 NOTE—Although constrained by the requirements in 36.3.19.4 (Modulation accuracy), the signal phase of the two
9 160 MHz frequency portions might not be entirely correlated.
10
11 36.3.19.4 Modulation accuracy
12
13
36.3.19.4.1 Introduction to modulation accuracy tests
14
15
16 Transmit modulation accuracy specifications are described in 36.3.19.4.2 (Transmit center frequency
17 leakage) and 36.3.19.4.3 (Transmitter constellation error). The test method is described in 36.3.19.4.4
18 (Transmitter modulation accuracy (EVM) test).
19
20
21 36.3.19.4.2 Transmit center frequency leakage
22
23 For 20/40/80/160/320 MHz transmission, the power measured at the location of the RF local oscillator using
24 resolution bandwidth 78.125 kHz shall not exceed the maximum of –32 dB relative to the total transmit
25
26 power and –20 dBm, or equivalently max  P – 32 – 20  , where P is the transmit power per antenna in dBm.
27 The transmit center frequency leakage is specified per antenna.
28
29 36.3.19.4.3 Transmitter constellation error
30
31
32 The relative constellation RMS error in the test, calculated by first averaging over subcarriers, frequency
33 segments, EHT PPDUs, and spatial streams (see Equation (36-102)) as described in 36.3.19.4.4 (Transmitter
34 modulation accuracy (EVM) test)) shall not exceed a data-rate dependent value according to Table 36-65
35 (Allowed relative constellation error versus constellation size and coding rate). The number of spatial
36
37 streams under test shall be equal to the number of utilized transmitting STA physical antenna (output) ports
38 and also equal to the number of utilized testing instrumentation input ports(#1329). In the test, no
39 beamforming steering matrix shall be used. Each output port of the transmitting STA shall be connected
40 through a cable to one input port of the testing instrumentation. The requirements shall apply to 20 MHz,
41 40 MHz, 80 MHz, 160 MHz, and 320 MHz contiguous transmissions.
42
43
44
45 Table 36-65—Allowed relative constellation error versus constellation size and coding rate
46
47
48 Relative constellation Relative constellation
49 Relative error in an EHT TB PPDU error in an EHT TB PPDU
50 Coding constellation when transmit power is when transmit power is
Modulation
51 rate error in an EHT larger than the maximum less than or equal to the
52 MU PPDU (dB) power of EHT-MCS 7 maximum power of EHT-
53 (dB) MCS 7 (dB)
54
55 BPSK 1/2 –5 –13 –27
56
QPSK 1/2 –10 –13 –27
57
58 QPSK 3/4 –13 –13 –27
59
60 16-QAM 1/2 –16 –16 –27
61
62 16-QAM 3/4 –19 –19 –27
63
64 64-QAM 2/3 –22 –22 –27
65

Copyright © 2022 IEEE. All rights reserved. 719

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-65—Allowed relative constellation error versus constellation size and coding rate
2
3
4 64-QAM 3/4 –25 –25 –27
5
6 64-QAM 5/6 –27 –27 –27
7 256-QAM 3/4 –30 –30 –30
8
9 256-QAM 5/6 –32 –32 –32
10
11 1024-QAM 3/4 –35 –35 –35
12
13 1024-QAM 5/6 –35 –35 –35
14
15 4096-QAM 3/4 –38 –38 –38
16 4096-QAM 5/6 –38 –38 –38
17
18 BPSK- 1/2 –5 –13 –27
19 DCM(#3261)
20 (EHT-MCS 15)
21
22 BPSK-DCM 1/2 –5 N/A N/A
23 (EHT-MCS 14)
24
25 NOTE 1—The maximum power of EHT-MCS 7 can be measured by setting the UL Target Receive Power
26 subfield(#6143) as defined in Table 9-29j (UL Target Receive Power subfield in Trigger frame) in the Trigger frame
27 to 127 for the RU for which the EVM test is conducted.
28
29 NOTE 2—N/A = not supported by the PPDU format(#2956).
30
31
32
33 36.3.19.4.4 Transmitter modulation accuracy (EVM) test
34
35 The transmit modulation accuracy test shall be performed by instrumentation capable of converting the
36 transmitted signals into a stream of complex samples at sampling rate greater than or equal to the bandwidth
37
of the signal being transmitted.
38
39
40 (#4555)In this case, transmit modulation accuracy shall meet the required value in Table 36-65 (Allowed
41 relative constellation error versus constellation size and coding rate) using only the occupied data
42 subcarriers. For EHT TB PPDU transmission, two sets of EVM requirements are defined in Table 36-65
43
(Allowed relative constellation error versus constellation size and coding rate) for different transmission
44
45 power levels to assist AP in better managing the interference among multiple STAs responding to a Trigger
46 frame.
47
48 Local oscillator leakage that can potentially show up at the center frequency of the EHT PPDU tone plan and
49
within ±3 neighboring subcarriers shall be excluded from the computation of the transmitter modulation
50
51 accuracy test. The potential local oscillator leakage subcarriers for 20 MHz operating devices are the center
52 of primary 20 MHz of the EHT PPDU tone plan and ±3 subcarriers of it. The potential local oscillator
53 leakage subcarriers for 40 MHz operating devices are the center of the primary 40 MHz of the PPDU tone
54 plan and ±3 subcarriers. The potential local oscillator leakage subcarriers for 80 MHz operating devices are
55
the center of the primary 80 MHz of the PPDU tone plan and ±3 subcarriers of it. The potential local
56
57 oscillator leakage tones for 160 MHz operating devices are the center of the primary 160 MHz of the PPDU
58 tone plan and ±3 subcarriers of it. The potential local oscillator leakage tones for 320 MHz operating devices
59 are the center of the 320 MHz of the PPDU tone plan and ±3 subcarriers of it. For 40 MHz operating devices
60 that transmits 20 MHz, the potential local oscillator leakage subcarriers exist outside the PPDU bandwidth
61
and should not affect the transmitter modulation accuracy test. For 80 MHz operating devices that transmits
62
63 20 MHz or 40 MHz PPDU, the potential local oscillator leakage subcarriers exist outside the PPDU
64 bandwidth and should not affect the transmitter modulation accuracy test. For 160 MHz operating devices
65

720 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 that transmits 20 MHz or 40 MHz PPDU or 80 MHz PPDU, the potential local oscillator leakage subcarriers
2 exist outside the PPDU bandwidth and should not affect the transmitter modulation accuracy test. For
3
320 MHz operating devices that transmits 20 MHz or 40 MHz PPDU or 80 MHz PPDU or 160 MHz PPDU,
4
5 the potential local oscillator leakage subcarriers exist outside the PPDU bandwidth and should not affect the
6 transmitter modulation accuracy test.
7
8 The transmitter modulation accuracy test procedure for the occupied subcarriers of the PPDU is similar as in
9
steps of the transmit modulation accuracy test procedure defined in 27.3.19.4.4 (Transmitter modulation
10
11 accuracy (EVM) test) as follows.
12 a) Start of PPDU shall be detected.
13
14 b) Transition from L-STF to L-LTF shall be detected and fine timing shall be established.
15 c) Coarse and fine frequency offsets shall be estimated.
16
17 d) Symbols in a PPDU shall be derotated according to a single estimated frequency offset. Sampling
18 offset drift shall be also compensated.
19 e) For each EHT-LTF symbol, transform the symbol into subcarrier received values, estimate a single
20
21 phase from the pilot subcarriers, and derotate the subcarrier values according to the estimated phase.
22 f) Estimate the complex channel response coefficient for each of the subcarriers and each of the
23 transmit streams.
24
25 g) For each of the data OFDM symbols, transform the symbol into subcarrier received values, estimate
26 a single phase from the pilot subcarriers, and compensate the subcarrier values according to the
27 estimated phase, group the results from all of the receiver chains in each subcarrier to a vector, and
28 multiply the vector by a zero-forcing equalization matrix generated from the estimated channel.
29
30 h) For each data-carrying subcarrier in each spatial stream of RU under test, find the closest
31 constellation point and compute the Euclidean distance from it.
32
33 i) Compute the average across PPDUs of the RMS of all errors per PPDU as given by Equation (36-
34 102)(#7658).
35
36
37 Error RMS = (36-102)
38
39 N SYM N SS N SD total
40 2 2
41 Nf     I e  i f i s i ss i sc  – I 0  i f i s i ss i sc   +  Q e  i f i s i ss i sc  – Q 0  i f i s i ss i sc  
42 1- i s = 1 i ss = 1 i sc = 1
43 ----
Nf  ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
N SYM N SS N SD total P 0
44 if = 1
45
46
where
47
48 I0  if is iss i sc  Q 0  if is iss i sc  denotes the ideal symbol point in the complex plane in data
49
50 subcarrier i sc of the RU under test, spatial stream iss , and OFDM symbol is of frame
51 if .
52
53 Ie  if i s i ss isc  Q e  if is iss isc  denotes the equalized observed symbol point in the complex plane
54
of the data subcarrier isc of the RU under test, spatial stream iss , and OFDM symbol
55
56 is of frame i f .
57
58 P0 is the average power of constellation.
59 Nf is the number of tested frames.
60
61 N SD total is the total number of data tones of the occupied RU(#7658).
62 N SS is the number of spatial streams of the data.
63
64 N SYM is the number of data OFDM symbols.
65

Copyright © 2022 IEEE. All rights reserved. 721

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The test shall be performed over at least 20 PPDUs ( N f as defined in Equation (36-102)). If the occupied RU
2
3 has 26 tones, the PPDUs under test shall be at least 32 data OFDM symbols long. For occupied RUs that
4 have more than 26 tones, the PPDUs under test shall be at least 16 data OFDM symbols long. Random data
5 shall be used for the symbols.
6
7 For an EHT TB PPDU with an RU or MRU smaller than a 4996-tone RU, additional transmit modulation
8
9 accuracy test for the unoccupied subcarriers of the PPDU shall be performed. There are two cases, one with
10 a single RU or a contiguous MRU and the other with a noncontiguous MRU.
11
12 In case of a single RU or a contiguous MRU, the transmit modulation accuracy test procedure for the
13 unoccupied subcarriers of the PPDU is similar as in steps of the transmit modulation accuracy test procedure
14
15 for the unoccupied subcarriers of the PPDU defined in 27.3.19.4.4 (Transmitter modulation accuracy (EVM)
16 test) as follows.
17 a) Start of PPDU shall be detected.
18
19 b) Transition from L-STF to L-LTF shall be detected and fine timing shall be established.
20 c) Coarse and fine frequency offsets shall be estimated.
21
22 d) Symbols in a PPDU shall be derotated according to estimated frequency offset. Sampling offset drift
23 shall be also compensated.
24
25
e) For each of the data OFDM symbols, transform the symbol into subcarrier received values and
26 estimate the power of each subcarrier.
27 f) Compute the average unoccupied subcarrier error vector magnitude for each unoccupied 26-tone RU
28 and (#7263)average the RMS across PPDUs of all errors per PPDU as given by Equation (36-103).
29
30
31 N SYM
32 2 2
33 Nf    I u  i f i s i sc   +  Q u  i f i s i sc  
34 1 i s = 1 i sc   k
35 UnusedToneError RMS  k  = -----
Nf  -------------------------------------------------------------------------------------------------------
N SYM  26  P S
(36-103)
36 if = 1
37
38 where
39
40 I u  if is isc  Q u  i f i s isc  denotes unequalized observed symbol point in the complex plane in sub-
41 carrier isc of the unoccupied 26-tone RU and OFDM symbol is of frame if .
42
43
k is a set of subcarriers for k-th 26-tone RU as defined in Table 27-7 (Data and pilot
44 subcarrier indices for RUs in a 20 MHz HE PPDU and in a non-OFDMA 20 MHz HE
45 PPDU), Table 27-8 (Data and pilot subcarrier indices for RUs in a 40 MHz HE PPDU
46 and in a non-OFDMA 40 MHz HE PPDU), Table 36-5 (Data and pilot subcarrier
47 indices for RUs in an 80 MHz EHT PPDU), Table 36-6 (Data and pilot subcarrier
48
49
indices for RUs in a 160 MHz EHT PPDU), and Table 36-7 (Data and pilot subcarrier
50 indices for RUs in a 320 MHz EHT PPDU).
51 PS is the average data subcarrier power of the occupied RU under test and is given by
52 Equation (36-104)(#2772)(#7658).
53
54
55 N SYM N SD total
56 1 2 2
57
P S = ---------------------------------
N SYM N SD total    I u  i f i s i sc   +  Q u  i f i s i sc   (36-104)
58 i s = 1 i sc = 1
59
60 where
61
62 Nf is the number of tested frames.
63 N SYM is the number of data OFDM symbols.
64
65 N SD total is the total number of data subcarriers in the occupied RU(#7658).

722 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 g) For all EHT-MCSs, for an occupied RU bandwidth of r in units of a 26-tone RU as defined by

2 Equation (36-105)(#6445).
3
4
5  1 if 26-tone RU
6  2 if 52-tone RU
7 
8  3 if 52+26-tone MRU
9 
10  4 if 106-tone RU
 5 if 106+26-tone MRU
11 
12  9 if 242-tone RU
13 
14  18 if 484-tone RU
15 r =  (36-105)
16  28 if 484+242-tone MRU
 37 if 996-tone RU
17 
18  55 if 996+484-tone MRU
19 
20  74 if 2  996-tone RU
21 
22  92 if 2  996+484-tone MRU
 111 if 3  996-tone MRU
23 
24  129 if 3  996+484-tone MRU
25
26
27 The average unused subcarrier error vector magnitude for each unoccupied 26-tone RU as calculated in
28 step f) shall meet the staircase mask requirement in Equation (36-106) and Equation (36-107), where m
29 defines the gap in the units of 26-tone RU to the occupied RU from either side with m =  1 being the
30
31 adjacent 26-tone RUs.
32
33
34  max   – 2 – 38 dB  if – r  m  – 1

35  max   – 12 – 38 dB  if – 2r  m  – r – 1
36 UnusedToneError  i RU26 start + m    (36-106)
37  max   – 22 – 38 dB  if – 3r  m  – 2r – 1
38  – 38 dB otherwise
39 
40
41
42  max   – 2 – 38 dB  if 1  m  r
43 
44  max   – 12 – 38 dB  if r + 1  m  2r
UnusedToneError  i RU26 end + m    (36-107)
45  max   – 22 – 38 dB  if 2r + 1  m  3r
46  – 38 dB
47  otherwise
48
49
50 where
51 i RU26 start is equal to i RU if the occupied RU is a 26-tone RU, and is defined in Table 36-66 (iRU26, start
52 for RUs other than a 26-tone RU(#7265)) for other RU sizes. All the RUs with N/A in
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 723

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-66 (iRU26, start for RUs other than a 26-tone RU(#7265)) are for noncontiguous
2 MRU.
3
4
5
6 Table 36-66—iRU26, start for RUs other than a 26-tone RU(#7265)
7
8
9 52+ 106+ 484+ 996+ 2996 3996
52- 106- 242- 484- 996- 2996 3996
10 26- 26- 242- 484- +484- +484-
iRU tone tone tone tone tone -tone -tone
11 tone tone tone tone tone tone
RU RU RU RU RU RU MRU
12 MRU MRU MRU MRU MRU MRU
13
14 1 1 2 1 1 1 1 10 1 20 1 20 38 20
15
16 2 3 3 6 5 10 20 N/A 38 N/A 75 N/A N/A N/A
17
18 3 6 6 10 10 20 38 N/A 75 N/A N/A N/A N/A
19
4 8 11 15 14 29 57 1 112 1 N/A 1 N/A
20
21 5 10 12 20 20 38 75 47 94 N/A N/A
22
23 6 12 15 25 24 47 94 N/A N/A 1 N/A
24
25 7 15 21 29 29 57 112 N/A N/A 57 N/A
26
27 8 17 22 34 33 66 131 38 75 N/A 1
28
29 9 20 25 38 38 75 84 N/A
30
31 10 22 30 43 42 84 N/A N/A
32
33 11 25 31 47 47 94 N/A N/A
34
35 12 27 34 52 51 103 75 38
36
13 29 39 57 57 112 121
37
38 14 31 40 62 61 121 N/A
39
40 15 34 43 66 66 131 N/A
41
42 16 36 48 71 70 140 112
43
44 17 38 49 75 75
45
46 18 40 52 80 79
47
48 19 43 58 84 84
49
50 20 45 59 89 88
51
52 21 47 62 94 94
53
54 22 49 67 99 98
55
23 52 68 103 103
56
57 24 54 71 108 107
58
59 25 57 76 112 112
60
61 26 59 77 117 116
62
63 27 62 80 121 121
64
65

724 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-66—iRU26, start for RUs other than a 26-tone RU(#7265) (continued)
2
3
4 52+ 106+ 484+ 996+ 2996 3996
52- 106- 242- 484- 996- 2996 3996
5 26- 26- 242- 484- +484- +484-
iRU tone tone tone tone tone -tone -tone
6 tone tone tone tone tone tone
RU RU RU RU RU RU MRU
7 MRU MRU MRU MRU MRU MRU
8
9 28 64 85 126 125
10
11 29 66 86 131 131
12
13 30 68 89 136 135
14
15 31 71 95 140 140
16
17 32 73 96 145 144
18
19 33 75 99
20
21 34 77 104
22
35 80 105
23
24 36 82 108
25
26 37 84 113
27
28 38 86 114
29
30 39 89 117
31
32 40 91 122
33
34 41 94 123
35
36 42 96 126
37
38 43 99 132
39
44 101 133
40
41 45 103 136
42
43 46 105 141
44
45 47 108 142
46
47 48 110 145
48
49 49 112
50
51 50 114
52
53 51 117
54
55 52 119
56
57 53 121
58
54 123
59
60 55 126
61
62 56 128
63
64 57 131
65

Copyright © 2022 IEEE. All rights reserved. 725

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-66—iRU26, start for RUs other than a 26-tone RU(#7265) (continued)
2
3
4 52+ 106+ 484+ 996+ 2996 3996
52- 106- 242- 484- 996- 2996 3996
5 26- 26- 242- 484- +484- +484-
iRU tone tone tone tone tone -tone -tone
6 tone tone tone tone tone tone
RU RU RU RU RU RU MRU
7 MRU MRU MRU MRU MRU MRU
8
9 58 133
10
11 59 136
12
13 60 138
14
15 61 140
16
17 62 142
18
19 63 145
20
21 64 147
22
23
24 i RU26 end is equal to iRU26 start + r – 1 .
25
26 i RU is the index of the occupied RU or MRU.
27
N RU26 is the maximum number of 26-tone RUs for the given bandwidth of the EHT TB PPDU. N RU26
28
29 is 9, 18, 37, 74, and 148 for a 20 MHz, 40 MHz, 80 MHz, 160 MHz, and 320 MHz PPDU,
30 respectively(#7266).
31
 is the relative constellation error requirement for an occupied RU of an EHT TB PPDU as
32
33 defined in Table 36-65 (Allowed relative constellation error versus constellation size and
34 coding rate).
35
36 The valid range for m for Equation (36-106) is as follows(#7264):
37
38 — – i RU26 start + 1  m  – 1 for a 20 MHz, 40 MHz, 80 MHz, 160 MHz, or 320 MHz PPDU when
39 iRU26 start  1 , otherwise there is no valid m.
40
41
The valid range for m for Equation (36-107) is as follows(#7264):
42
43 — 1  m  N RU26 – iRU26 end for a 20 MHz, 40 MHz, 80 MHz, 160 MHz, or 320 MHz PPDU when
44 iRU26 start  N RU26 , otherwise there is no valid m.
45
46
47 The test shall be performed over at least 20 PPDUs ( N f as defined in Equation (36-102)). The PPDUs under
48 test shall be at least 16 data OFDM symbols long. The unequalized observed symbol of potential local
49 oscillator leakage subcarrier locations shall be treated as zero during unoccupied subcarriers transmit
50
51 modulation accuracy test. Random data shall be used for the symbols.
52
53 In case of a noncontiguous MRU, the transmit modulation accuracy test for the unoccupied subcarriers of
54 the PPDU is performed by constructing the overall relative constellation error staircase mask in the
55 following manner. First, treat noncontiguous MRU as a large RU/MRU that does not have an unmodulated
56
57 portion in between multiple RUs. For example, (#7268)a noncontiguous 2996+484-tone MRU is treated as
58 3996-tone MRU, and find the average unused subcarrier error vector magnitude for each unoccupied 26-
59 tone RU based on the large RU/MRU. Then, replace the unmodulated portion in between multiple RUs to
60 max   – 2 – 38  dB.
61
62
63
64
65

726 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 36.3.20 Receiver specification

2
3
36.3.20.1 General
4
5
6 For receiver minimum input sensitivity, adjacent channel rejection, nonadjacent channel rejection, receiver
7 maximum input level, and CCA sensitivity requirements described in this subclause, the input levels are
8 measured at the antenna connector and are referenced as the average power per receive antenna. The number
9
of spatial streams under test shall be equal to the number of utilized transmitting STA physical(#1329)
10
11 antenna (output) ports and also equal to the number of utilized Device Under Test input ports. Each output
12 port of the transmitting STA shall be connected through a cable to one input port of the Device Under Test.
13
14 NOTE—Additional test requirements and/or test methods may be needed to meet regulatory requirements.
15
16 The requirements on receiver minimum input sensitivity in 36.3.20.2 (Receiver minimum input sensitivity),
17 adjacent channel rejection in 36.3.20.3 (Adjacent channel rejection) and nonadjacent channel rejection in
18 36.3.20.4 (Nonadjacent channel rejection) apply to PPDUs that meet all the following conditions:
19
20 — 0.8 µs GI is used.
21 — If the PPDU bandwidth is 20 MHz and the EHT-MCS is less than 10 or equal(#6818) to 15, then
22
BCC is used. Otherwise, LDPC is used.
23
24 — The PPDU is an EHT MU PPDU (#5432)without puncturing and a PPDU Type And Compression
25 Mode field in U-SIG field(#5657) is equal to 1.
26
27
28 36.3.20.2 Receiver minimum input sensitivity
29
30 The PER shall be less than 10% for a PSDU with the rate-dependent input levels listed in Table 36-67
31 (Receiver minimum input level sensitivity). The PSDU length shall be 2048 octets for BPSK modulation
32 with DCM or 4096 octets for all other modulations.
33
34
35
36 Table 36-67—Receiver minimum input level sensitivity
37
38
39 Minimum Minimum Minimum
Minimum Minimum
40 sensitivity sensitivity sensitivity
Rate sensitivity sensitivity
41 Modulation (20 MHz (40 MHz (80 MHz
(R) (160 MHz (320 MHz
42 PPDU) PPDU) PPDU)
PPDU) (dBm) PPDU) (dBm)
43 (dBm) (dBm) (dBm)
44
45 BPSK 1/2 –82 –79 –76 –73 –70
46
QPSK 1/2 –79 –76 –73 –70 –67
47
48 QPSK 3/4 –77 –74 –71 –68 –65
49
50 16-QAM 1/2 –74 –71 –68 –65 –62
51
52 16-QAM 3/4 –70 –67 –64 –61 –58
53
54 64-QAM 2/3 –66 –63 –60 –57 –54
55
64-QAM 3/4 –65 –62 –59 –56 –53
56
57 64-QAM 5/6 –64 –61 –58 –55 –52
58
59 256-QAM 3/4 –59 –56 –53 –50 –47
60
61 256-QAM 5/6 –57 –54 –51 –48 –45
62
63 1024-QAM 3/4 –54 –51 –48 –45 –42
64
1024-QAM 5/6 –52 –49 –46 –43 –40
65

Copyright © 2022 IEEE. All rights reserved. 727

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-67—Receiver minimum input level sensitivity (continued)

2
3
4 4096-QAM 3/4 –49 –46 –43 –40 –37
5
6 4096-QAM 5/6 –46 –43 –40 –37 –34
7 BPSK-DCM 1/2 –82 –79 –76 –73 –70
8 (EHT-MCS 15)
9
10 BPSK-DCM-DUP 1/2 N/A N/A –78 –75 –72
11 (EHT-MCS 14)
12 (#5099)
13
14 NOTE—N/A = not supported by the PPDU format(#2957).
15
16
17
18 36.3.20.3 Adjacent channel rejection
19
20 Adjacent channel rejection for W MHz (where W is 20, 40, 80, 160, or 320) shall be measured by setting the
21 desired signal’s strength 3 dB above the rate-dependent sensitivity specified in Table 36-67 (Receiver
22
minimum input level sensitivity) and raising the power of the interfering signal of W MHz bandwidth until
23
24 10% PER is caused for a PSDU length of 2048 octets for BPSK modulation with DCM or 4096 octets for all
25 other modulations. The difference in power between the signals in the interfering channel and the desired
26 channel is the corresponding adjacent channel rejection. The center frequency of the adjacent channel shall
27 be placed W MHz away from the center frequency of the desired signal.
28
29
30 The interfering signal in the adjacent channel shall be a signal compliant with the EHT PHY,
31 unsynchronized with the signal in the channel under test, and shall have a minimum duty cycle of 50%. The
32 corresponding rejection shall be no less than specified in Table 36-68 (Minimum required adjacent and
33 nonadjacent channel rejection levels).
34
35
36
37 Table 36-68—Minimum required adjacent and nonadjacent channel rejection levels
38
39
40 Adjacent channel rejection (dB) Nonadjacent channel rejection (dB)
Rate
41 Modulation
(R)
42 20/40/80/160/320 MHz channel 20/40/80/160/320 MHz channel
43
44 BPSK 1/2 16 32
45
46 QPSK 1/2 13 29
47 QPSK 3/4 11 27
48
49 16-QAM 1/2 8 24
50
51 16-QAM 3/4 4 20
52
53 64-QAM 2/3 0 16
54
55 64-QAM 3/4 –1 15
56 64-QAM 5/6 –2 14
57
58 256-QAM 3/4 –7 9
59
60 256-QAM 5/6 –9 7
61
62 1024-QAM 3/4 –12 4
63
64 1024-QAM 5/6 –14 2
65

728 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-68—Minimum required adjacent and nonadjacent channel rejection levels (contin-
2
3
4 4096-QAM 3/4 –17 –1
5
6 4096-QAM 5/6 –20 –4
7 BPSK-DCM 1/2 16 32
8 (EHT-MCS 15)
9
10 BPSK-DCM-DUP 1/2 16 32
11 (EHT-MCS 14)
12 (#5100)
13
14
15
16 The measurement of adjacent channel rejection for 160 MHz and 320 MHz operation in regulatory domain
17 is required only if such a frequency band plan is permitted in the regulatory domain.
18
19
36.3.20.4 Nonadjacent channel rejection
20
21
22 Nonadjacent channel rejection for W MHz channels (where W is 20, 40, 80, 160, or 320) shall be measured
23 by setting the desired signal’s strength 3 dB above the rate-dependent sensitivity specified in Table 36-67
24 (Receiver minimum input level sensitivity), and raising the power of the interfering signal of W MHz
25
bandwidth until a 10% PER occurs for a PSDU length of 2048 octets for BPSK modulation with DCM or
26
27 4096 octets for all other modulations. The difference in power between the signals in the interfering channel
28 and the desired channel is the corresponding nonadjacent channel rejection. The nonadjacent channel
29 rejection shall be met with any nonadjacent channels located at least 2W MHz away from the center
30 frequency of the desired signal.
31
32
33 The interfering signal in the nonadjacent channel shall be a signal compliant with the EHT PHY,
34 unsynchronized with the signal in the channel under test, and shall have a minimum duty cycle of 50%. The
35 corresponding rejection shall be no less than specified in Table 36-68 (Minimum required adjacent and
36 nonadjacent channel rejection levels).
37
38
39 The measurement of nonadjacent channel rejection for 160 MHz and 320 MHz operation in regulatory
40 domain is required only if such a frequency band plan is permitted in the regulatory domain.
41
42 36.3.20.5 Receiver maximum input level
43
44
45 The receiver shall provide a maximum PER of 10% at a PSDU length of 2048 octets for BPSK modulation
46 with DCM or 4096 octets for all other modulations, for a maximum input level of –30 dBm in the 5 GHz and
47 6 GHz bands and –20 dBm in the 2.4 GHz band, measured at each physical antenna port(#1329) for any
48 baseband EHT modulation.
49
50
51 36.3.20.6 CCA sensitivity
52
53 36.3.20.6.1 General
54
55
The thresholds in this subclause are compared with the signal level at each receiving antenna.
56
57
58 36.3.20.6.2 CCA sensitivity for operating classes requiring CCA-ED
59
60 For the operating classes requiring CCA-Energy Detect (CCA-ED), the PHY shall indicate a medium busy
61
condition if CCA-ED detects a channel busy condition. For improved spectrum sharing, CCA-ED is
62
63 required in some bands. The behavior class indicating CCA-ED is given in Table D-2 (Behavior limits). The
64 operating classes requiring the corresponding CCA-ED behavior class are given in E.1 (Country information
65

Copyright © 2022 IEEE. All rights reserved. 729

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 and operating classes). The PHY of a STA that is operating within an operating class that requires CCA-ED
2 shall operate with CCA-ED.
3
4
5 CCA-ED shall detect a channel busy condition if the received signal strength exceeds the CCA-ED
6 threshold as given by (#6904)dot11OFDMEDThreshold for the primary 20 MHz channel and each
7 nonprimary 20 MHz subchannel (if present). The CCA-ED thresholds for the operating classes requiring
8 CCA-ED are subject to the criteria in D.2.5 (CCA-ED threshold).
9
10
11 For the EHT TB PPDU transmission, for each of 20 MHz subchannels that require CCA, CCA-ED shall
12 detect a channel busy condition if the received signal strength exceeds the CCA-ED threshold as given by
13 dot11OFDMEDThreshold. The CCA-ED thresholds for the operating classes requiring CCA-ED are subject
14 to the criteria in D.2.5 (CCA-ED threshold).
15
16
17 For transmissions that carry a frame that includes a BQR Control subfield (see 9.2.4.6a (Control subfield
18 variants of an A-Control subfield)), CCA-ED shall detect a channel busy condition if the received signal
19 strength exceeds the (#6905)CCA-ED threshold as given by dot11OFDMEDThreshold for primary 20 MHz
20 channel and for each nonprimary 20 MHz channel (if present). The CCA-ED thresholds for the operating
21
classes requiring CCA-ED are subject to the criteria in D.2.5 (CCA-ED threshold).
22
23 NOTE—The requirement to detect a channel busy condition as stated in 36.3.20.6.3 (CCA sensitivity for occupying the
24 primary 20 MHz channel) and 36.3.20.6.4 (Per 20 MHz CCA sensitivity) is a mandatory energy detect requirement on
25 all Clause 36 (Extremely high throughput (EHT) PHY specification) receivers. Support for CCA-ED is an additional
26 requirement that relates specifically to the sensitivities described in D.2.5 (CCA-ED threshold).
27
28
36.3.20.6.3 CCA sensitivity for occupying the primary 20 MHz channel
29
30
31 An EHT STA with a W MHz operating channel width shall detect, with greater than 90% probability, the
32 start of a PPDU that occupies at least the primary 20 MHz channel in an otherwise idle W MHz operating
33 channel width, and issue a PHY-CCA.indication with the STATUS parameter set to BUSY within a period of
34
aCCATime (see 21.4.4 (VHT PHY)) if one of the following conditions is met:
35
36 — The start of a non-HT PPDU as defined in 17.3.10.6 (CCA requirements) when operating in the
37 5 GHz or 6 GHz band and 18.4.6 (CCA performance) when operating in the 2.4 GHz band.
38
39 — The start of an HT PPDU as defined in 19.3.19.5 (CCA sensitivity).
40 — The start of a non-HT duplicate, VHT, HE, or EHT PPDU for which the power measured within the
41 primary 20 MHz channel is at or above –82 dBm.
42
43
44 The channel-list parameter is present and set to {primary} if the operating channel width is greater than
45 20 MHz. The CCA signal shall be held busy (not issue a PHY-CCA.indication primitive with the STATUS
46
47 parameter set to IDLE) for the duration of the PPDU, unless it receives a CCARESET.request primitive
48 before the end of the PPDU for instance during spatial reuse operation as described in 35.11 (EHT Spatial
49 reuse operation(#5444)).
50
51
52
The receiver shall issue a PHY-CCA.indication primitive with the STATUS parameter set to BUSY for any
53 signal that exceeds a threshold equal to 20 dB above the minimum modulation and coding rate sensitivity
54 (–82 + 20 = –62 dBm) in the primary 20 MHz channel within a period of aCCATime after the signal arrives
55 at the receiver’s antenna(s). If the operating channel width is greater than 20 MHz, then the channel-list
56 parameter is present and shall be set to {primary}. Following the indication and while the threshold
57
58
continues to be exceeded, the receiver shall not issue a PHY-CCA.indication primitive with the STATUS
59 parameter set to IDLE or with a change in the channel-list parameter.
60
61
62
63
64
65

730 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 36.3.20.6.4 Per 20 MHz CCA sensitivity

2
3
If the operating channel width is greater than 20 MHz and the PHY issues a PHY-CCA.indication primitive,
4
5 the PHY shall set the per20bitmap to indicate the busy/idle status of each 20 MHz subchannel. A 20 MHz
6 subchannel is busy if at least one of the following conditions is present:
7 — A signal is present on the 20 MHz subchannel at or above a threshold of –62 dBm at the receiver's
8
9 antenna(s). The PHY shall indicate that the 20 MHz subchannel is busy a period aCCATime after the
10 signal starts and shall continue to indicate the 20 MHz subchannel is busy while the threshold
11 continues to be exceeded.
12
— A non-HT, HT_MF, HT_GF, VHT, HE, or EHT PPDU for which the power measured within this
13
14 20 MHz subchannel is at or above max(–72 dBm, OBSS_PDlevel) at the receiver’s antenna(s). The
15 PHY shall indicate that the 20 MHz subchannel is busy with greater than 90% probability within a
16 period aCCAMidTime (see 36.3 (EHT PHY)).
17
18 NOTE—Following the receipt of a Trigger frame with the CS Required subfield in the Common Info field set to 1, the
19
EHT PHY is only required to detect a signal at the –62 dBm threshold since the other conditions require more time than
20
21 is available before the response is expected.
22
23 OBSS_PD level is defined in 35.9.4 (Adjustment of OBSS PD and transmit power) and applied in the
24
25
equations to define the detection level in this subclause if an EHT STA has ignored a 40 MHz, 80 MHz,
26 160 MHz, or 320 MHz inter-BSS PPDU following the procedure in 35.9.2 (General operation with non-
27 SRG OBSS PD level) or 35.9.3 (General operation with SRG OBSS PD level). It is applied to any secondary
28 channels within the PPDU bandwidth of the inter-BSS PPDU and during the RXTIME of the inter-BSS
29
30
PPDU. Otherwise, OBSS_PD level is not applied in the equations to define the detection level in this
31 subclause.
32
33 36.3.21 EHT transmit procedure
34
35
36 There are three paths for the transmit PHY procedure.
37
38 The first two paths, for which typical transmit procedures are shown in Figure 36-75 (PHY transmit
39 procedure for an EHT MU PPDU(#4913)) and Figure 36-76 (PHY transmit procedure for an EHT TB
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 731

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 PPDU(#7271)), are selected if the FORMAT field of the PHY-TXSTART.request(TXVECTOR) primitive is

2 equal to EHT_MU or EHT_TB, respectively.
3
4
5

PHY-TXSTART.confirm

PHY-TXEND.request
6
PHY-TXSTART.request

PHY-Data.request

PHY-Data.request
PHY-Data.confirm

PHY-Data.confirm
7

PHY-TXEND.confirm
…………..…………
8 (TXVECTOR)

9 MAC
10 A-MPDU including EOF padding
11
12 Pre-FEC PHY padding if needed
13 L-SIG U-SIG
EHT-
Service PSDU
Tail bits if needed
SIG
14 Post-FEC
padding if needed
15
16
17 PHY
18
19
20 Packet Extension &
U-SIG- U-SIG- EHT Training Data (Variable number of OFDM
21 L-STF L-LTF L-SIG RL-SIG
1 2
EHT-SIG
Symbols symbols)
Signal Extension (if
present)

22 Coded
OFDM
Coded
OFDM
Coded
OFDM
Coded
OFDM
Coded OFDM,
Coded OFDM, EHT-MCS indicated in
EHT-SIG
EHT-SIG-MCS
23 BPSK,
Rate½
BPSK,
Rate½
BPSK,
Rate½
BPSK,
Rate½
indicated in U-SIG

24
25
26 Figure 36-75—PHY transmit procedure for an EHT MU PPDU(#4913)
27
28
29
30
31
32
PHY-TXSTART.confirm

33
PHY-TXEND.request
PHY-TXSTART.request

PHY-Data.request

PHY-Data.request
PHY-Data.confirm

PHY-Data.confirm

34

PHY-TXEND.confirm
…………..…………
35
(TXVECTOR)

36 MAC
37
38 A-MPDU including EOF padding

39 Pre-FEC PHY padding if needed

40 L-SIG U-SIG Service PSDU Tail bits if needed
41 Post-FEC padding if needed
42
43
44 PHY
45
46
47
U-SIG- U-SIG- EHT Training Data (Variable number of OFDM Packet Extension &
48 L-STF L-LTF L-SIG RL-SIG
1 2 Symbols symbols)
Signal Extension (if
present)
49 Coded Coded
Coded OFDM,
OFDM OFDM
50 BPSK,
Rate ½
BPSK,
Rate ½
UL EHT-MCS indicated in the Trigger frame

51 Coded
OFDM
Coded
OFDM

52 BPSK,
Rate ½
BPSK,
Rate ½

53
54
55 Figure 36-76—PHY transmit procedure for an EHT TB PPDU(#7271)
56
57
58 The third path is to follow the transmit procedure in Clause 17 (Orthogonal frequency division multiplexing
59
60 (OFDM) PHY specification) if the FORMAT parameter of the PHY-TXSTART.request(TXVECTOR)
61 primitive is NON_HT and the NON_HT_MODULATION parameter is NON_HT_DUP_OFDM, except
62 that the signal is generated simultaneously on each of the 20 MHz channels identified by the
63 CH_BANDWIDTH parameter as defined in 36.3.12 (EHT preamble) and 36.3.15 (Non-HT duplicate
64 transmission).
65

732 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 NOTE 1—For an EHT MU PPDU the A-MPDU is per user in the MAC sublayer and the EHT training symbols, and
2 Data are per user in the PHY in Figure 36-75 (PHY transmit procedure for an EHT MU PPDU(#4913)).
3
4 NOTE 2—The (#7272)transmission of NON_HT, HT_MF, HT_GF, VHT, and HE formats is specified in 36.2.6
5 (Support for non-HT, HT, VHT, and HE formats).
6
7
In all options, in order to transmit data, the MAC generates a PHY-TXSTART.request primitive, which
8
9 causes the PHY entity to (#7273)respond with a PHY-TXSTART.confirm primitive and enter the transmit
10 state. Further, the PHY is set to operate at the appropriate frequency through station management via the
11 PLME, as specified in 36.4 (EHT PLME). Other transmit parameters, such as EHT-MCS, coding types, and
12 transmit power, are set via the PHY-SAP using the PHY-TXSTART.request(TXVECTOR) primitive, as
13
described in 36.2.2 (TXVECTOR and RXVECTOR parameters). After transmitting a PPDU that carries a
14
15 Trigger frame, the MAC sublayer issues a PHY-TRIGGER.request with a TRIGVECTOR parameter that
16 provides the PHY entity with the information needed to demodulate the expected EHT TB PPDU response.
17 The remainder of the subclause applies to the first two paths.
18
19
The PHY indicates the state of the primary channel and other channels (if any) via the PHY-CCA.indication
20
21 primitive (see 36.3.20.6 (CCA sensitivity) and 8.3.5.12 (PHY-CCA.indication)). Transmission of the PPDU
22 shall be initiated by the PHY after receiving the PHY-TXSTART.request(TXVECTOR) primitive. The
23 TXVECTOR parameters for the PHY-TXSTART.request primitive are specified in Table 36-1 (TXVECTOR
24 and RXVECTOR parameters).
25
26
27 After the PHY preamble transmission is started, the PHY entity immediately initiates (#7274)scrambling
28 and encoding of the SERVICE field and PSDU. The encoding method for the Data field is based on the
29 FEC_CODING, CH_BANDWIDTH, (#8145)NUM_STS, MCS, (#8146)RU_ALLOCATION, and STA_ID
30 parameters of the TXVECTOR, as described in 36.3.4 (EHT PPDU formats).
31
32
33 (#7274)The data shall be exchanged between the MAC and the PHY through a series of PHY-
34 DATA.request(DATA) primitives issued by the MAC, and PHY-DATA.confirm primitives issued by the
35 PHY. PHY padding bits are appended to the PSDU to make the number of bits in the coded PSDU an
36 integral multiple of the number of coded bits per OFDM symbol.
37
38
39 Transmission can be prematurely terminated by the MAC through the PHY-TXEND.request primitive.
40 PSDU transmission is terminated by receiving a PHY-TXEND.request primitive. Each
41 PHY-TXEND.request primitive is acknowledged with a PHY-TXEND.confirm primitive from the PHY.
42
43
A packet extension and/or a signal extension may be present in the PPDU. The PHY-TXEND.confirm
44
45 primitive is generated at the latest of the actual ending time of the PPDU, the end of the packet extension if
46 present, and the end of the signal extension if present.
47
48 In the PHY, the GI with GI duration indicated in the GI_TYPE parameter of the TXVECTOR is inserted in
49
every data OFDM symbol as a countermeasure against delay spread.
50
51
52 Once the PPDU transmission is completed the PHY entity enters the receive state.
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 733

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 A typical state machine implementation for the transmission of an EHT PPDU is shown in Figure 36-77
2 (PHY transmit state machine for an EHT PPDU). Request (.request) and confirmation (.confirm) primitives
3
are issued once per state as shown.
4
5
6 FORMAT =
NON_HT Refer TX PSDU OCTET
7 to Clause 17

8 FORMAT = HT_MF
or HT_GF Refer to Get octet from MAC,
9 Clause 19
FORMAT = VHT
scramble, encode and
buffer
PHY-DATA.request(DATA)

10 Set TX parameters Refer to Clause 21 PHY-data.confirm

11 FORMAT = HE
Refer to Clause 27
12 Buffer contains a
symbol’s worth of
13 FORMAT = EHT_MU or data or last octet otherwise &&
EHT_TRIG received from MAC PHY-DATA.request(DATA)
14
15
16 Last
Symbol?
17 TX L-STF Yes
18 TX L-LTF
TX L-SIG (BPSK)
19
PADDING & TAIL & Post-
20 No FEC padding

21
Add PHY
22 FORMAT = FORMAT =
padding bits,
scramble, encode,
EHT_TRIG
23 EHT_MU buffer, encode & buffer tail bits
(BCC only) & Post-FEC padding
if needed
24
25
TX SYMBOL
26 TX RL-SIG (BPSK)
TX RL-SIG (BPSK)
TX U-SIG-1 (BPSK)
TX U-SIG-1 (BPSK)
27 TX U-SIG-2 (BPSK)
TX U-SIG-2 (BPSK)
TX EHT-SIG
TX EHT Training Symbols
28 TX EHT Training Symbols

29
30 Decrement Symbol

31
32 Decrement symbol
count
Symbol count > 0

33
34 Use EHT-MCS and number of
Symbol count is 0

35 spatial streams set by

TXVECTOR
Wait TX_END

36 16-bit service field prepended,

padding and tail bits appended
37 to PSDU

38
Packet Extension?

39 no packet Add Packet Extension

40 extension
Wait for duration of
41 Packet Extension

42
PHY-TXSTART.confirm
43 Set symbol count to NSYM
Signal Extension?

44 Add Signal Extension

45 no signal Wait for duration of
46 extension Signal Extension

47
48 At any stage in the Switch RX state
above flow diagram, if a
49 A PHYTXEND.request is A
received.
50
51
52 Figure 36-77—PHY transmit state machine for an EHT PPDU
53
54
55
56
57
58
59
60
61
62
63
64
65

734 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 36.3.22 EHT receive procedure

2
3
Typical PHY receive procedures are shown in Figure 36-78 (PHY receive procedure for an EHT MU
4
5 PPDU) and Figure 36-79 (PHY receive procedure for an EHT TB PPDU(#8147)).
6
7 CS/CCA state RX state
8

PHY-RXSTART.indication
9

PHY-DATA.indication

PHY-RXEND.indication
PHY-DATA.indication

PHY-DATA.indication

(NoError, RXVECTOR)
PHY-CCA.indication

PHY-CCA.indication
10 (busy,primary)
…………..…………
11

(RXVECTOR)
12 MAC

(IDLE)
13 A-MPDU
14
15 Decoding Delay Pre-FEC padding
Measure RSSI_LEGACY

L-SIG U-SIG EHT-SIG PSDU (if present), tail

16 bits (if present)
and post-FEC Issue at the same time
17 Decoded and
descrambled
padding

18

Measure RSSI

Measure RCPI
PHY
19
20
21
22 L-STF L-LTF L-SIG RL-SIG
U-SIG- U-SIG-
EHT-SIG
EHT training Data (variable number of OFDM Packet extension Signal extension
1 2 symbols symbols) (if present) (if present)
23 Coded Coded Coded OFDM, EHT-MCS indicated in
24 OFDM
BPSK,
Rate ½
OFDM
BPSK,
Rate ½
Coded OFDM,
EHT-SIG

25 Coded
OFDM
BPSK,
Coded
OFDM
BPSK,
EHT-SIG-MCS indicated
in U-SIG

26 Rate ½ Rate ½

27
28 Figure 36-78—PHY receive procedure for an EHT MU PPDU
29
30
31
32
33
34
CS/CCA state RX state
35
PHY-RXSTART.indication

36
PHY-DATA.indication
PHY-DATA.indication

PHY-DATA.indication

37

PHY-CCA.indication (IDLE)
PHY-CCA.indication

PHY-RXEND.indication
(NoError, RXVECTOR)
38
(busy,primary)

(RXVECTOR)

…………..…………
39
MAC
40
41 A-MPDU

42
43 Decoding Delay Pre-FEC padding
Measure RSSI_LEGACY

L-SIG U-SIG PSDU (if present), tail

44 bits (if present)
and post-FEC Issue at the same time
45 Decoded and
descrambled
padding
Measure RCPI
Measure RSSI

46 PHY
47
48
49
50 L-STF L-LTF L-SIG RL-SIG
U-SIG-
1
U-SIG-
2
EHT training symbols
Data (variable number of OFDM
symbols)
Packet extension
(if present)
Signal extension
(if present)
51 Coded Coded
Coded OFDM,
52
OFDM OFDM
BPSK, BPSK, EHT-MCS is indicated in the PHY-
Rate ½ Rate ½ TRIGGER.request(TRIGVECTOR)
Coded Coded
53 OFDM
BPSK,
OFDM
BPSK,

54 Rate ½ Rate ½

55 Figure 36-79—PHY receive procedure for an EHT TB PPDU(#8147)

56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 735

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 A typical state machine implementation of the receive PHY is given in Figure 36-80 (PHY receive state
2 machine(#6819)(#3196)).
3
4
5 RX IDLE state

6 Auto detection
CS/CCA C
7 Set PHY_CCA.indication(BUSY,primary)

8 Detect HT‐GF
HT‐GF preamble
9 Determine whether QBPSK is
used in 1st symbol after LTF
Refer to 19.3.21

10 BPSK
11
12 Detect RL‐SIG Detect SIG for non‐
VHT preamble
Refer to 21.3.20
13 Rx and determine whether Repetition failed
HT, HT, VHT

14 1st and 2nd symbols after L‐

LTF are the same
Determine
preamble types
15
Non‐HT preamble and
NON_HT_MODULATION
Repetition detected Non‐HT preamble HT preamble parameter indicates
Parity check
16 fails: Set
Receive L‐SIG
Refer to 17.3.12 Refer to 19.3.21 other than OFDM and
NON_HT_DUP_OFDM

17 PHY_RXEND.in
dication(Forma
RATE
check
Refer to Clause 18
Data processing
18 E1 tViolation) Combine L‐SIG and RL‐SIG. Decode,
Parity check, RATE (6 Mb/s) check
failed

19 RATE&parity check pass

B
20 Evaluate LENGTH LENGTH HE preamble
21 Determine LENGTH mod 3
mod 3 ≠ 0 Refer to 27.3.22
Setup PSDU Reception
22 LENGTH mod 3 = 0 Set N_symbols = NSYM
The 2nd symbol of U‐SIG is
23 CRC Fail: Set Receive U‐SIG QBPSK and CRC passes
Parse the Version
E2
Set PHY_RXSTART.indication
(RXVECTOR)
independent information in
24 PHY_RXEND.indication
Evaluate the constellation the U‐SIG

25 E2 (FormatViolation)
of the 2nd symbol of U‐SIG
and test the CRC
Receive Symbol
26 The 2nd symbol of U‐SIG is
27 BPSK and CRC Passes
EHT Preamble parsing Rx termination Carrier lost Valid signal
28
Signal Not Valid Decode Symbol
29 No intended BSS color or Evaluate the Version
DL/Ul or Reserved‐ independent information in
E1 Set RxEndStatus = Decode and
30 Validate U‐SIG Indication
etc., PPDU is filtered out.
the U‐SIG
Determine if the PPDU is
(CarrierLost, Null) descramble symbol

31 filtered out or not based on End of Wait

N_symbol > 0
Version subfield, BSS color,
32 DL/UL, etc. Set PHY_CCA indication() in Decrement Time Decrement N_symbol
accordance with 36.3.20.6
33 PPDU is not
filtered out Wait for
PHY_DATA.indication(DATA)
34 Evaluate the PPDU Type and C intended end of
PSDU
(bit removing if needed)
compression mode subfield Decrement symbol count
35 and DL/UL subfield in U‐SIG E2
36 Determine the PPDU type. N_symbol = 0
End of Wait End of Wait
EHT_TRIG
37 EHT_MU
Check for packet
End of PSDU Receiption
Set RxEndStatus = (NoError,
38 Set PHY_CCA.indication(IDLE) when
predicted duration based on
extension
RXVECTOR); Check for packet
extension
39 B Receive EHT‐SIG
Receive EHT‐SIG based on the
RXTIME Defined in equation (36‐
109) has elapsed, unless PHY‐
40 EHT‐SIG‐MCS and Number of CCARESET.request received;
Packet Extension
extension
No packet

EHT‐SIG symbols indicated in If the RXTIME cannot be predicted

41 U‐SIG using equation (36‐109): set
PHY_CCA.indication(IDLE) when
Wait for duration of packet extension
42 Determine if a supported predicted duration based on
RXTIME Defined in equation (36‐
43 mode is indicated
108) has elapsed. Check for signal
extension
44 Based on EHT‐MCS, Nss, EHT‐
Signal Extension

45 LTF, STA‐ID, RU allocation, etc.

No signal
Wait for duration of
signal extension
extension
46 PPDU is not
47 Unsupported mode or
Reserved‐Validate EHT‐SIG Indication,
filtered out
End of Wait
48 E2 PPDU if filtered out
C
Set PHY_CCA.indication(IDLE)

49 B Set PHY‐RXEND.indication(RxEndStatus)

50
51 Figure 36-80—PHY receive state machine(#6819)(#3196)
52
53
54
If the detected format indicates a non-HT PPDU, refer to the receive procedure and state machine in
55 Clause 15 (DSSS PHY specification for the 2.4 GHz band designated for ISM applications), Clause 16
56 (High rate direct sequence spread spectrum (HR/DSSS) PHY specification), Clause 17 (Orthogonal
57 frequency division multiplexing (OFDM) PHY specification), and Clause 18 (Extended Rate PHY (ERP)
58 specification). If the detected format indicates an HT PPDU format, refer to the receive procedure and state
59
60
machine in Clause 19 (High Throughput (HT) PHY specification). If the detected format indicates a VHT
61 PPDU format, refer to the receive procedure and state machine in Clause 21 (Very High Throughput (VHT)
62 PHY specification). If the detected format indicates (#4666)an HE PPDU format, refer to the receive
63 procedure and state machine in Clause 27 (High Efficiency (HE) PHY specification). Through station
64 management (via the PLME), the PHY is set to the appropriate frequency as specified in 36.4 (EHT PLME).
65

736 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The PHY has also been configured with BSS identification information and STA identification information
2 (i.e., BSS color value and STA-ID) so that it can receive data intended for the STA in the specific BSS. Other
3
receive parameters, such as RSSI and indicated DATARATE, may be accessed via the PHY SAP.
4
5
6 Upon receiving the transmitted PHY preamble in a greater than or equal to 20 MHz BSS, the PHY measures
7 a receive signal strength. This activity is indicated by the PHY to the MAC via a PHY-CCA.indication
8 primitive. A PHY-CCA.indication(BUSY, channel-list) primitive is also issued as an initial indication of
9
reception of a signal as specified in 36.3.20.6 (CCA sensitivity). The channel-list parameter of the
10
11 PHY-CCA.indication primitive is absent when the operating channel width is 20 MHz. The channel-list
12 parameter is present when the operating channel width is 40 MHz, 80 MHz, 160 MHz, or 320 MHz.
13
14 The PHY shall not issue a PHY-RXSTART.indication primitive in response to a PPDU that does not overlap
15
the primary channel unless the PHY at an AP receives the EHT TB PPDU solicited by the AP. The PHY
16
17 shall issue a PHY-RXSTART.indication primitive for the EHT TB PPDU solicited by the AP.
18
19 The PHY includes the measured RSSI and RSSI_LEGACY values in the
20 PHY-RXSTART.indication(RXVECTOR) primitive issued to the MAC.
21
22
23 After the PHY-CCA.indication(BUSY, channel-list) primitive is issued, the PHY entity shall begin receiving
24 the training symbols and searching for L-SIG in order to set the maximum duration of the data stream. Then
25 the PHY will search for the preambles for non-HT, HT, VHT, HE, and EHT PPDUs, respectively. If the
26 constellation used in the first symbol after the first long training field is QBPSK, the PHY entity shall
27
continue to detect the received signal using the receive procedure for HT-GF depicted in Clause 19 (High
28
29 Throughput (HT) PHY specification). For detecting the EHT preamble, the PHY entity shall search for
30 RL-SIG and evaluate the LENGTH field. If RL-SIG is detected, the PHY entity should check the parity bit
31 and RATE fields in L-SIG and RL-SIG. If either the check of the parity bit is invalid or the RATE field is not
32 set to 6 Mb/s, a PHY-RXSTART.indication primitive is not issued. If the check of the parity bit is valid and
33
the RATE field indicates 6 Mb/s (#6908)but the LENGTH field value in L-SIG is a not a multiple of three, a
34
35 PHY-RXSTART.indication primitive is not issued. If the EHT preamble is not detected, the PHY should
36 continue to detect the received signal using non-HT, HT, VHT, and HE receive procedure in
37 Clause 17 (Orthogonal frequency division multiplexing (OFDM) PHY specification), Clause 19 (High
38 Throughput (HT) PHY specification), Clause 21 (Very High Throughput (VHT) PHY specification), and
39
Clause 27 (High Efficiency (HE) PHY specification), respectively.
40
41
42 (#3196)If a valid parity bit and the RATE with 6 Mb/s are indicated in L-SIG and RL-SIG and the LENGTH
43 field value in L-SIG and RL-SIG is a multiple of three, U-SIG field(#5657) is present after RL-SIG. PHY
44 entity shall begin receiving the U-SIG field and identify the PPDU version based on the (#8149)PHY
45
Version Identifier field in the U-SIG field(#5657). The PHY entity shall check the constellation of the
46
47 second symbol of the U-SIG field(#5657). If the constellation is QBPSK, the PHY entity shall receive the U-
48 SIG field and the repeated U-SIG field(#5657) (four symbols in total following the RL-SIG). If the
49 constellation is BPSK, the PHY entity shall receive the U-SIG field(#5657) (two symbols in total following
50 the RL-SIG). Then the PHY entity shall check the CRC of the U-SIG field (and the repeated U-SIG field if
51
present).
52
53 — If the U-SIG field indicates a valid CRC, the PHY entity shall report the version independent fields
54 in the U-SIG field(#5657) (e.g., TXOP, BSS color, and Bandwidth(#4655)) to the MAC entity.
55
56 — If the U-SIG field indicates a valid CRC, and the PHY version identifier or the BSS color or the
57 UL/DL does not contain an intended value, or the constellation of the second symbol of the U-SIG
58 field(#5657) is QBPSK, the PHY entity shall issue a PHY-RXSTART.indication(RXVECTOR) then
59 issue a PHY-RXEND.indication(Filtered).
60
61 — If the U-SIG field indicates a valid CRC and the U-SIG field indicates a Validate U-SIG indication,
62 the PHY shall issue the error condition PHY-RXEND.indication(FormatViolation) primitive and
63 maintain PHY-CCA.indication(BUSY, channellist) primitive for the predicted duration of the
64 transmitted PPDU derived from the LENGTH field in L-SIG as defined in Equation (36-108) unless
65

Copyright © 2022 IEEE. All rights reserved. 737

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 it receives a PHY-CCARESET.request primitive before the end of the PPDU for instance during
2 spatial reuse operation as described in 35.11 (EHT Spatial reuse operation(#5444))(#5495). A
3
Validate U-SIG indication is defined as a Validate field in the U-SIG field(#5657) being set to 0 or a
4
5 field value of a field in the U-SIG field(#5657) being set to a Validate state.
6 — (#1355)The PHY entity shall not process the Disregard field.
7
8 — If the U-SIG field indicates a valid CRC and the U-SIG field indicates a Disregard U-SIG indication,
9 the PHY entity shall continue processing the U-SIG. A Disregard U-SIG indication is defined as a
10 Disregard field in the U-SIG field(#5657) being set to any value or a field value of a field in the U-
11 SIG field(#5657) being set to a Disregard state.
12
13 — If the U-SIG field indicates an invalid CRC, the PHY shall issue the error condition
14 PHY-RXEND.indication(FormatViolation) primitive and maintain PHY-CCA.indication(BUSY,
15 channellist) primitive for the predicted duration of the transmitted PPDU derived from the LENGTH
16 field in L-SIG as defined in Equation (36-108) unless it receives a PHY-CCARESET.request
17
18 primitive before the end of the PPDU for instance during spatial reuse operation as described in
19 35.11 (EHT Spatial reuse operation(#5444))(#5495)(#3197).
20
21 LENGTH + 3
22 RXTIME  s  = ---------------------------------  4 + 20 + SignalExtension (36-108)
3
23
24
25 where
26 LENGTH is the value of the LENGTH field in L-SIG.
27 SignalExtension is defined in Table 27-54 (HE PHY characteristics).
28
29
30 If the CRC checks in U-SIG field (#5657)(#7276)is valid, and PHY version identifier, the BSS color, and the
31 UL/DL (#7277)all indicates an intended value, and a Validate U-SIG indication is not indicated, then the
32 PHY entity will parse the PPDU Type And Compression Mode subfield and the DL/UL subfield in the U-
33 SIG field(#5657) and identify the EHT PPDU type.
34
35
36 (#7278)If the received PPDU is EHT MU PPDU, the PHY entity shall begin receiving the EHT-SIG, EHT-
37 STF, and EHT-LTF for EHT MU PPDU as shown in Figure 36-78 (PHY receive procedure for an EHT MU
38 PPDU). The PHY entity shall check the CRC of the Common field of EHT-SIG.
39
40 — (#5485)If the CRCs protecting the Common field of EHT-SIG are valid, for all supported modes,
41 unsupported modes and Validate indication, the PHY entity shall maintain PHY-
42 CCA.indication(BUSY, channellist) primitive for the predicted duration of the transmitted PPDU, as
43 defined by RXTIME in Equation (36-109)(#7274)(#2624), unless it receives a PHY-
44 CCARESET.request primitive before the end of the PPDU for instance during spatial reuse
45
46 operation as described in 35.11 (EHT Spatial reuse operation(#5444))(#5495). A Validate EHT-SIG
47 indication is defined as (#7274)a field value of a subfield either in the EHT-SIG common field or in
48 the receiver’s own user field being set to a Validate state.
49
— (#5485)If the CRCs protecting the Common field of the EHT-SIG are valid, the PHY entity shall
50
51 search for intended STA-ID in each User field. If an intended STA-ID is detected in a user encoding
52 block(#7280) or in the common encoding block of EHT-SIG (STA-ID can be present in the common
53 encoding block of EHT-SIG only if the PPDU type and compression mode and UL/DL indicate a DL
54 non-OFDMA transmission) with valid CRC, and an unsupported mode or a Validate EHT-SIG
55
indication is not indicated, the PHY entity shall continue receiving the EHT-STF right after the
56
57 EHT-SIG.
58 — (#5485)If the CRCs protecting the Common field of the EHT-SIG are valid and no intended STA-ID
59 is detected in all the User fields, the PHY entity shall issue a PHY-
60
61 RXSTART.indication(RXVECTOR) then issue a PHY-RXEND.indication(Filtered).
62 — (#5485)If the CRCs protecting the Common field of the EHT-SIG are valid and an intended STA-ID
63 is detected, but an unsupported mode or a Validate EHT-SIG indication is indicated in EHT-SIG
64
65

738 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 field, the PHY shall issue a PHY-RXSTART.indication(RXVECTOR) then issue a PHY-

2 RXEND.indication(UnsupportedRate) primitive.
3
4 — (#5485)If the CRCs protecting the Common field of the EHT-SIG are not valid, the PHY shall issue
5 the error condition PHY-RXEND.indication(FormatViolation) primitive and maintain PHY-
6 CCA.indication(BUSY, channellist) primitive for the predicted duration of the transmitted PPDU
7 derived from the LENGTH field in L-SIG as defined in Equation (36-108)(#2625) unless it receives
8
9 a PHY-CCARESET.request primitive before the end of the PPDU for instance during spatial reuse
10 operation as described in 35.11 (EHT Spatial reuse operation(#5444))(#5495).
11
12 (#7279)If the received PPDU is EHT TB PPDU, the PHY entity shall continue receiving the EHT-STF and
13 EHT-LTF for an EHT TB PPDU shown in Figure 36-79 (PHY receive procedure for an EHT TB
14
15 PPDU(#8147)). If a STA receives an EHT TB PPDU and the TRIGVECTOR parameters are not present in
16 its PHY entity, the STA shall use Equation (36-108) to calculate the predicted duration of the EHT TB
17 PPDU.
18
19 If signal loss occurs during reception prior to completion of the PSDU reception, the error condition
20
21 PHY-RXEND.indication(CarrierLost) shall be reported to the MAC. After waiting for the end of the PPDU
22 as determined by Equation (36-109), the PHY shall set the PHY-CCA.indication(IDLE) primitive and return
23 to the RX IDLE state.
24
25
26 RXTIME  s  = 20 + T EHT_PREAMBLE + N SYM T SYM + T PE + SignalExtension (36-109)
27
28 where
29 T EHT_PREAMBLE , N SYM , and TPE are defined in Equation (36-97), Equation (36-95), and Equation (36-96),
30
31 respectively.
32 SignalExtension is defined in Table 27-54 (HE PHY characteristics).
33
34 Except in an EHT sounding NDP, a Data field follows the EHT-STF and EHT-LTF fields. The number of
35
36 symbols in the Data field and the packet extension duration are computed from Equation (36-95) and
37 Equation (36-96), respectively.
38
39 The received PSDU bits are assembled into octets, decoded, and present to the MAC using a series of
40 PHY-DATA.indication(DATA) primitive exchanges. Any final bits that cannot be assembled into a complete
41
42 octet are considered pad bits and discarded. After the reception of the final bit of the last PSDU octet, and
43 possible padding and tail bits, the PHY entity shall check whether packet extension and/or signal extension
44 is applied. If packet extension and/or signal extension is applied, the PHY entity shall wait until the packet
45 extension and/or signal extension expires (#7280)before issuing a PHY-RXEND.indication (NoError,
46 RXVECTOR) returning to the RX IDLE state, as shown in Figure 36-80 (PHY receive state
47
48 machine(#6819)(#3196)).
49
50 36.3.23 Channel numbering and channelization(#1577)
51
52 36.3.23.1 General
53
54
55 The STA may operate in the 2.4 GHz band, 5 GHz band, or 6 GHz band. The set of valid operating channel
56 numbers by regulatory domain is defined in Annex E. Channel allocation for each band is defined as
57 follows:
58
59 — In 19.3.15.2 (Channel allocation in the 2.4 GHz band) for the 2.4 GHz band
60 — In 19.3.15.3 (Channel allocation in the 5 GHz band) for the 5 GHz band
61
62 — In 27.3.23.2 (Channel allocation in the 6 GHz band) for the 6 GHz band
63
64
65

Copyright © 2022 IEEE. All rights reserved. 739

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 36.3.23.2 Channelization for 320 MHz channel(#1577)

2
3
The 320 MHz channel consists of any two adjacent 160 MHz channels in the 6 GHz band. Two type of
4
5 channelizations for 320 MHz channel are defined: 320 MHz-1 and 320 MHz-2. 320 MHz-1 is defined as
6 320 MHz channel with channel center frequency numbered 31, 95, and 159. 320 MHz-2 is defined as
7 320 MHz channel with channel center frequency numbered 63, 127, and 191.
8
9
36.3.24 Regulatory requirements
10
11
12 WLANs implemented in accordance with this standard are subject to equipment certification and operating
13 requirements established by regional and national regulatory administrations. The PHY specification
14 establishes minimum technical requirements for interoperability, based upon established regulations at the
15
time this standard was issued. These regulations are subject to revision or may be superseded. Requirements
16
17 that are subject to local geographic regulations are annotated within the PHY specification. Regulatory
18 requirements that do not affect interoperability are not addressed in this standard. Implementers are referred
19 to the regulatory sources in Annex D for further information. Operation in countries within defined
20 regulatory domains might be subject to additional or alternative national regulations.
21
22
23 36.4 EHT PLME
24
25
26 36.4.1 PLME_SAP sublayer management primitives
27
28 Table 36-69 (EHT PHY MIB attributes(#7281)) lists the MIB attributes that may be accessed by the PHY
29 entities and the intralayer of higher level LMEs. These attributes are accessed via the PLME-GET, PLME-
30
31 SET, PLME-RESET, and PLME-CHARACTERISTICS primitives defined in 6.5 (PLME SAP interface).
32
33 36.4.2 PHY MIB
34
35 (#7281)PHY MIB attributes for an EHT STA are defined in Annex C with specific values defined in Table
36
37 15-4 (MIB attribute default values/ranges), Table 16-3 (MIB attribute default values/ranges), Table 17-
38 20 (MIB attribute default values/ranges), Table 18-4 (MIB attribute default values/ranges), Table 19-24 (HT
39 PHY MIB attributes), Table 21-27 (VHT PHY MIB attributes), Table 27-53 (HE PHY MIB attributes), and
40 Table 36-69 (EHT PHY MIB attributes(#7281)). The “Operational semantics” column in Table 36-69 (EHT
41 PHY MIB attributes(#7281)) contains two types: static and dynamic.
42
43 — Static MIB attributes are fixed and cannot be modified for a given PHY implementation.
44
45 Dynamic MIB attributes are interpreted according to the MAX-ACCESS field of the MIB attribute. If
46
MAX-ACCESS is equal to read-only, the MIB attribute value may be updated by the PLME and read from
47
48 the MIB attribute by management entities. If MAX-ACCESS is equal to read-write, the MIB attribute may
49 be read and written by management entities.(#4635)
50
51
52 Table 36-69—EHT PHY MIB attributes(#7281)
53
54
55 Default value/ Operational
56 Managed object
range semantics
57
58 dot11PHYOperationTable
59
60 dot11PHYType eht Static
61
62 dot11PHYEHTTable
63
64 dot11EHTCurrentChannelWidth Implementation Dynamic
65 dependent

740 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-69—EHT PHY MIB attributes(#7281) (continued)

2
3
4 Default value/ Operational
Managed object
5 range semantics
6
7 dot11EHTSupportFor320MHzImplemented false/Boolean Static
8
9 dot11EHTNonOFDMAULMUMIMOLessThanOrEqualto80Implemented false/Boolean Static
10
11 dot11EHTNonOFDMAULMUMIMOEqualto160Implemented false/Boolean Static
12 dot11EHTNonOFDMAULMUMIMOEqualto320Implemented false/Boolean Static
13
14 dot11EHTPartialBWULMUMIMOImplemented false/Boolean Static
15
16 dot11EHTMUPPDUwith4xEHTLTFand0point8usecGIImplemented false/Boolean Static
17
18 dot11EHTPSRBasedSRImplemented false/Boolean Static
19
20 dot11EHTPowerBoostFactorImplemented false/Boolean Static
21 dot11EHTTx1024QAMand4096QAMLessThan242ToneRUImplemented false/Boolean Static
22
23 dot11EHTRx1024QAMand4096QAMLessThan242ToneRUImplemented false/Boolean Static
24
25 dot11EHTExtraLTFsImplemented false/Boolean Static
26
27 dot11EHTMaxNumberOfSupportedEHTLTFsForSU Implementation Static
28 dependent
29
30 dot11EHTMaxNumberOfSupportedEHTLTFsForMUandNDP Implementation Static
31 dependent
32 dot11EHTMCS15For52p26and106p26MRUImplemented false/Boolean Static
33
34 dot11EHTMCS15For484p242MRUImplemented false/Boolean Static
35
36 dot11EHTMCS15For996p484and996p484p242MRUImplemented false/Boolean Static
37
38 dot11EHTMCS15For3x996MRUImplemented false/Boolean Static
39
40 dot11EHTDupImplemented false/Boolean Static
41 (#1306)dot11EHTSupportFor242ToneRUInBWWiderThan20Implemente false/Boolean Static
42 d
43
44 dot11EHT20MHzOperatingSTARxNDPwithWiderBWImplemented false/Boolean Static
45
46 (#4624)dot11EHTCurrentChannelCenterFrequencyIndex0 Implementation Dynamic
47 dependent
48
49 (#4627)dot11EHTDisabledSubchannelBitmap 0/0...65 535 Dynamic
50
51 dot11EHTTransmitBeamformingConfigTable
52 dot11EHTSUBeamformerImplemented false/Boolean Static
53
54 dot11EHTSUBeamformeeImplemented false/Boolean Static
55
56 dot11EHTMUBeamformerLessThanOrEqualTo80Implemented false/Boolean Static
57
58 dot11EHTMUBeamformerEqualTo160Implemented false/Boolean Static
59
60 dot11EHTMUBeamformerEqualTo320Implemented false/Boolean Static
61 dot11EHTPartialBWDLMUMIMOImplemented false/Boolean Static
62
63 dot11EHTTriggeredSUBeamformingFeedbackImplemented false/Boolean Static
64
65

Copyright © 2022 IEEE. All rights reserved. 741

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table 36-69—EHT PHY MIB attributes(#7281) (continued)

2
3
4 Default value/ Operational
Managed object
5 range semantics
6
7 dot11EHTTriggeredMUBeamformingPartialBWFeedbackImplemented false/Boolean Static
8
9 dot11EHTTriggeredCQIFeedbackImplemented false/Boolean Static
10
11 dot11EHTNonTriggeredCQIFeedbackImplemented false/Boolean Static
12 dot11EHTBeamformeeSSLessThanOrEqualTo80 Implementation Static
13 dependent
14
15 dot11EHTBeamformeeSSEqualTo160 Implementation Static
16 dependent
17
18 dot11EHTBeamformeeSSEqualTo320 Implementation Static
19 dependent
20
21 dot11EHTNumberSoundingDimensionsLessThanOrEqualTo80 Implementation Static
22 dependent
23
24 dot11EHTNumberSoundingDimensionsEqualTo160 Implementation Static
25 dependent
26 dot11EHTNumberSoundingDimensionsEqualTo320 Implementation Static
27 dependent
28
29 dot11EHTNG16SUFeedbackImplemented false/Boolean Static
30
31 dot11EHTNG16MUFeedbackImplemented false/Boolean Static
32
33 dot11EHTCodebookSizePhi4Psi2SUFeedbackImplemented false/Boolean Static
34
35 dot11EHTCodebookSizePhi7Psi5MUFeedbackImplemented false/Boolean Static
36 dot11EHTMaxNc Implementation Static
37 dependent
38
39 dot11EHTNDPwith4xEHTLTFand3point2GIImplemented false/Boolean Static
40
41
42
43 36.4.3 TXTIME and PSDU_LENGTH calculation
44
45 The value of the TXTIME parameter returned by the PLME-TXTIME.confirm primitive shall be calculated
46
for an EHT PPDU using Equation (36-110).
47
48
49 TXTIME = 20 + T EHT-PREAMBLE + N SYM T SYM + T PE + SignalExtension (36-110)
50
51
52 where
53 T EHT-PREAMBLE is defined as in Equation (36-97).
54
55
SignalExtension takes the value of aSignalExtension as defined in Table 27-54 (HE PHY
56 characteristics).
57
58 For an EHT MU PPDU, the total number of data OFDM symbols, N SYM , is given in 36.3.13.3.5 (Encoding
59
60 process for an EHT MU PPDU).
61
62 For an EHT TB PPDU, the total number of data OFDM symbols, N SYM , is given in 36.3.13.3.6 (Encoding
63
64 process for an EHT TB PPDU).
65

742 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#4914)For an EHT sounding NDP, the total number of data OFDM symbols, N SYM , is 0.
2
3
4 TPE is given in 36.3.14 (Packet extension).
5
6
7 The value of the PSDU_LENGTH parameter for user u returned in the PLME-TXTIME.confirm primitive
8 for an EHT TB PPDU is calculated using Equation (36-111).
9
10  N SYM init – 1 N DBPS u + N DBPS last init u – N service – N tail u
11 PSDU_LENGTH u = ------------------------------------------------------------------------------------------------------------------------------------------------ (36-111)
12 8
13
14 where
15
16
N SYM init is given in 36.3.13.3.6 (Encoding process for an EHT TB PPDU).
17 N DBPS u is given in 36.5 (Parameters for EHT-MCSs).
18
19 N DBPS last init u is given by Equation (36-52), with a init given in 36.3.13.3.6 (Encoding process for an EHT
20 TB PPDU).
21
22
The value of the PSDU_LENGTH parameter for user u returned in the PLME-TXTIME.confirm primitive
23
24 for an EHT MU PPDU is calculated using Equation (36-112) and Equation (36-113) for users using BCC
25 and LDPC, respectively.
26
27
 N SYM – 1 N DBPS u + N DBPS last u – N service – N tail u
28 PSDU_LENGTH u = ------------------------------------------------------------------------------------------------------------------------------ (36-112)
29 8
30
31  N SYM init – 1 N DBPS u + N DBPS last init u – N service
32 PSDU_LENGTH u = --------------------------------------------------------------------------------------------------------------------------- (36-113)
33 8
34
35 where
36
N SYM init is given by Equation (36-51).
37
38 N DBPS u is given in Table 36-23 (Frequently used parameters).
39
40 N DBPS last u is given by Equation (36-61) for users using BCC and Equation (36-60) for users using
41 LDPC.
42 N DBPS last init u is given by Equation (36-52).
43
44
45 (#4557)The value of the PSDU_LENGTH parameter returned in the PLME-TIME.confirm primitive for an
46 EHT sounding NDP is 0.
47
48
49 For an EHT TB PPDU, the value of the PSDU_LENGTH parameter for user u returned in the RXVECTOR
50 is calculated using Equation (36-114).
51
52  N SYM RX u – 1 N DBPS u + N DBPS last RX u – N service – N tail u
53 PSDU_LENGTH u = -------------------------------------------------------------------------------------------------------------------------------------------------
- (36-114)
54 8
55
56 where
57
58
N SYM RX u is given by Equation (36-115).
59 N DBPS last RX u is given by Equation (36-116).
60
61 N DBPS u is defined in Table 36-23 (Frequently used parameters).
62 N service and N tail u are defined in Table 36-18 (Timing-related constants).
63
64
65

Copyright © 2022 IEEE. All rights reserved. 743

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2  if in the corresponding TRIGVECTOR,
3 
 the entry in the FEC_CODING_LIST for the user u is 1
4  N SYM – 1
5 N SYM RX u =  the LDPC_EXTRA_SYMBOL parameter is 1 and (36-115)
6  the PRE_FEC_PADDING_FACTOR parameter is 1
7 
8  N SYM otherwise
9 
10
11 where
12
N SYM is given by Equation (36-93).
13
14
15
16 N DBPS u if a RX = 4
N DBPS last RX u =  (36-116)
17 a RX u  N SD short u  N SS u  N BPSCS u  R u  otherwise
18
19
20 where
21 a RX u is given by Equation (36-117).
22
23 N SD short u is N SD short defined in Table 36-46 (NSD,short values for EHT-MCS values from 0 to 13 and
24 15) for user u.
25
26 N SS u N BPSCS u R u are defined in Table 36-23 (Frequently used parameters).
27
28
29  if in the corresponding TRIGVECTOR,
30 
 4 the entry in the FEC_CODING_LIST for the user u is 1
31
 the LDPC_EXTRA_SYMBOL parameter is 1 and
32 
33  a = 1
34 
35 a RX u =  if in the correspondingTRIGVECTOR, (36-117)
36 
 a – 1 the entry in the FEC_CODING_LIST for the user u is 1
37
 the LDPC_EXTRA_SYMBOL parameter is 1 and
38 
39  a1
40 
41  a otherwise
42
43 where
44
45 a is the pre-FEC padding factor (ranging from 1 to 4) indicated in TRIGVECTOR parameter
46 PRE_FEC_PADDING_FACTOR.
47
48
49
For an EHT MU PPDU, the value of the RXVECTOR parameter PSDU_LENGTH returned for user u is
50 calculated using Equation (36-118)(#7283).
51
52  N SYM RX u – 1 N DBPS u + N DBPS last RX u – N service – N tail u
53 PSDU_LENGTH u = -------------------------------------------------------------------------------------------------------------------------------------------------
- (36-118)
54 8
55
56 where
57 N SYM RX u is given by Equation (36-119).
58
59 N DBPS last RX u is given by Equation (36-120)
60
61 N DBPS u is defined in Table 36-23 (Frequently used parameters).
62 N service and N tail u are defined in Table 36-18 (Timing-related constants).
63
64
65

744 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2  if the user u is using LDPC coding,
3 
 N SYM – 1 the LDPC Extra Symbol Segment field in EHT-SIG is 1 and
4 N SYM RX u =  (36-119)
5  the Pre-FEC Padding Factor field in EHT-SIG is 1
6 N  otherwise
7  SYM
8
9 where
10
11 N SYM is given by Equation (36-95).
12
13
14  N DBPS u if a RX u = 4
15 N DBPS last RX u =  (36-120)
16  a RX u  N SD short u  N SS u  N BPSCS u  R u  otherwise
17
18 where
19
20 a RX u is given by Equation (36-121).
21 N SD short u is N SD short defined in Table 36-46 (NSD,short values for EHT-MCS values from 0 to 13 and
22
23 15) and Table 36-47 (NSD,short values for EHT-MCS 14) for user u.
24 N SS u , N BPSCS u , R u are defined in Table 36-23 (Frequently used parameters).
25
26
27  if the user u is using LDPC coding,
28  4 the LDPC Extra Symbol Segment field in EHT-SIG is 1 and
29 
30  a = 1
31 
a RX u =  if the user u is using LDPC coding, (36-121)
32  a – 1
33  the LDPC Extra Symbol Segment field in EHT-SIG is 1 and
34  a1
35 
36  a otherwise
37
38 where
39
a is the pre-FEC padding factor (ranging from 1 to 4) indicated in the Pre-FEC Padding Factor
40
41 field in the EHT-SIG.
42
43 36.4.4 EHT PHY
44
45
(#7284)The static EHT PHY characteristics are provided through the PLME-CHARACTERISTICS service
46
47 primitive. If listed in Table 36-70 (EHT PHY characteristics), then the static EHT PHY characteristics shall
48 be as shown in Table 36-70 (EHT PHY characteristics). Otherwise, if listed in Table 27-54 (HE PHY
49 characteristics), then the static EHT PHY characteristics shall be as shown in Table 27-54 (HE PHY
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 745

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 characteristics). Otherwise, the static EHT PHY characteristics shall be as shown in Table 19-25 (HT PHY
2 characteristics). The definitions for these characteristics are given in 6.5 (PLME SAP interface).
3
4
5
6 Table 36-70—EHT PHY characteristics
7
8
9 Characteristics Value
10
11 aPPDUMaxTime(#4289) 5.484 ms
12
13 aPSDUMaxLength 15 523 200 bytes
14
15 aRxPHYStartDelay 32 + 4  N EHT-SIG µs for EHT MU PPDUs
16 32 µs for EHT TB PPDUs
17
18 NOTE—This is the maximum length in octets for a single user transmission using the EHT MU PPDU with the
19 PPDU Type And Compression Mode field in the U-SIG field equal to 1, (#4289)EHT-SIG MCS 1, 320 MHz
20 bandwidth, EHT-MCS 13, 8 spatial streams, 0.8 µs GI duration, 2× EHT-LTF, PE field with 0 µs duration, pre-FEC
21 padding factor value of 4, and 396 Data field OFDM symbols (396 is the maximum number of Data field OFDM
22 symbols that fits within the aPPDUMaxTime of 5.484 ms(#4289). This is the maximum PSDU length an EHT PHY
23 could support assuming no restrictions in MAC. See 10.12.2 (A-MPDU length limit rules) and 9.2.4.7.1 (General) for
24 additional restrictions on the maximum number of octets the MAC could support.
25
26
27
28 36.5 Parameters for EHT-MCSs
29
30
The rate-dependent parameters for (#5823)various RU or MRU sizes using N SS u = 1 are provided in
31
32 Table 36-71 (EHT-MCSs for 26-tone RU, NSS,u = 1) through Table 36-86 (EHT-MCSs for 4×996-tone
33 RU, NSS,u = 1). The rate-dependent parameters for EHT DUP mode are provided in Table 36-87 (EHT-
34 MCS 14 for EHT DUP mode, NSS,u = 1(#4909)).
35
36
37 (#7285) N CBPS u for a given EHT-MCS M using N SS u (>1) can be obtained as the product of N SS u and
38 N CBPS u for EHT-MCS M using N SS u = 1 .
39
40
41 N DBPS u and data rate in megabits per second (D) are computed using Equation (36-122) and Equation (36-
42
43 123), respectively.
44
45 N DBPS u = N CBPS u  R u (36-122)
46
47
48 N DBPS u
49 D = -----------------------------------
- (36-123)
12.8 + T GI Data
50
51
52 where
53 Ru is the coding rate for user u, u = 0 1  N user total – 1 .
54
55 T GI Data is the GI duration for the Data field in microseconds.
56
57
58
EHT-MCSs 14 and 15 are supported only with N SS u = 1 .
59
60 EHT-MCSs 0–13 and 15 are defined for user u in SU transmission or MU transmission. EHT-MCS 14 is
61 defined for user u in SU transmission only, and for bandwidths 80 MHz, 160 MHz, and 320 MHz
62
63
only(#7286).
64
65

746 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 36.5.1 EHT-MCSs for 26-tone RU

2
3
The rate-dependent parameters for the 26-tone RU are provided in Table 36-71 (EHT-MCSs for 26-tone RU,
4
5 NSS,u = 1).
6
7
8 Table 36-71—EHT-MCSs for 26-tone RU, NSS,u = 1
9
10
11 EHT- Data rate (Mb/s)
12 MCS Modulation Ru NBPSCS,u NSD,u NCBPS,u NDBPS,u
13 index 0.8 µs GI 1.6 µs GI 3.2 µs GI
14
15 0 BPSK 1/2 1 24 12 0.9 0.8 0.8
16
17 1 1/2 24 1.8 1.7 1.5
18 QPSK 2 48
19 2 3/4 36 2.6 2.5 2.3
20
21 3 1/2 48 3.5 3.3 3.0
16-QAM 4 96
22 4 3/4 72 5.3 5.0 4.5
23
24 5 2/3 96 7.1 6.7 6.0
25
26 6 64-QAM 3/4 6 144 108 7.9 7.5 6.8
27 24
28 7 5/6 120 8.8 8.3 7.5
29
30 8 3/4 144 10.6 10.0 9.0
256-QAM 8 192
31 9 5/6 160 11.8 11.1 10.0
32
33 10 3/4 180 13.2 12.5 11.3
34 1024-QAM 10 240
35 11 5/6 200 14.7 13.9 12.5
36
37 12 3/4 216 15.9 15.0 13.5
38 4096-QAM 12 288
39 13 5/6 240 17.6 16.7 15.0
40 15 BPSK-DCM 1/2 1 12 12 6 0.4 0.4 0.4
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 747

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 36.5.2 EHT-MCSs for 52-tone RU

2
3
The rate-dependent parameters for the 52-tone RU are provided in Table 36-72 (EHT-MCSs for 52-tone RU,
4
5 NSS,u = 1).
6
7
8 Table 36-72—EHT-MCSs for 52-tone RU, NSS,u = 1
9
10
11 EHT- Data rate (Mb/s)
12 MCS Modulation Ru NBPSCS,u NSD,u NCBPS,u NDBPS,u
13 index 0.8 µs GI 1.6 µs GI 3.2 µs GI
14
15 0 BPSK 1/2 1 48 24 1.8 1.7 1.5
16
17 1 1/2 48 3.5 3.3 3.0
18 QPSK 2 96
19 2 3/4 72 5.3 5.0 4.5
20
21 3 1/2 96 7.1 6.7 6.0
16-QAM 4 192
22 4 3/4 144 10.6 10.0 9.0
23
24 5 2/3 192 14.1 13.3 12.0
25
26 6 64-QAM 3/4 6 288 216 15.9 15.0 13.5
27 48
28 7 5/6 240 17.6 16.7 15.0
29
30 8 3/4 288 21.2 20.0 18.0
256-QAM 8 384
31 9 5/6 320 23.5 22.2 20.0
32
33 10 3/4 360 26.5 25.0 22.5
34 1024-QAM 10 480
35 11 5/6 400 29.4 27.8 25.0
36
37 12 3/4 432 31.8 30.0 27.0
38 4096-QAM 12 576
39 13 5/6 480 35.3 33.3 30.0
40 15 BPSK-DCM 1/2 1 24 24 12 0.9 0.8 0.8
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

748 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 36.5.3 EHT-MCSs for 52+26-tone MRU

2
3
The rate-dependent parameters for the 52+26-tone MRU are provided in Table 36-73 (EHT-MCSs for
4
5 52+26-tone MRU, NSS,u = 1).
6
7
8 Table 36-73—EHT-MCSs for 52+26-tone MRU, NSS,u = 1
9
10
11 EHT- Data rate (Mb/s)
12 MCS Modulation Ru NBPSCS,u NSD,u NCBPS,u NDBPS,u
13 index 0.8 µs GI 1.6 µs GI 3.2 µs GI
14
15 0 BPSK 1/2 1 72 36 2.6 2.5 2.3
16
17 1 1/2 72 5.3 5.0 4.5
18 QPSK 2 144
19 2 3/4 108 7.9 7.5 6.8
20
21 3 1/2 144 10.6 10.0 9.0
16-QAM 4 288
22 4 3/4 216 15.9 15.0 13.5
23
24 5 2/3 288 21.2 20.0 18.0
25
26 6 64-QAM 3/4 6 432 324 23.8 22.5 20.3
27 72
28 7 5/6 360 26.5 25.0 22.5
29
30 8 3/4 432 31.8 30.0 27.0
256-QAM 8 576
31 9 5/6 480 35.3 33.3 30.0
32
33 10 3/4 540 39.7 37.5 33.8
34 1024-QAM 10 720
35 11 5/6 600 44.1 41.7 37.5
36
37 12 3/4 648 47.6 45.0 40.5
38 4096-QAM 12 864
39 13 5/6 720 52.9 50.0 45.0
40 15 BPSK-DCM 1/2 1 36 36 18 1.3 1.3 1.1
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 749

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 36.5.4 EHT-MCSs for 106-tone RU

2
3
The rate-dependent parameters for the 106-tone RU are provided in Table 36-74 (EHT-MCSs for 106-tone
4
5 RU, NSS,u = 1).
6
7
8 Table 36-74—EHT-MCSs for 106-tone RU, NSS,u = 1
9
10
11 EHT- Data rate (Mb/s)
12 MCS Modulation Ru NBPSCS,u NSD,u NCBPS,u NDBPS,u
13 index 0.8 µs GI 1.6 µs GI 3.2 µs GI
14
15 0 BPSK 1/2 1 102 51 3.8 3.5 3.2
16
17 1 1/2 102 7.5 7.1 6.4
18 QPSK 2 204
19 2 3/4 153 11.3 10.6 9.6
20
21 3 1/2 204 15.0 14.2 12.8
16-QAM 4 408
22 4 3/4 306 22.5 21.3 19.1
23
24 5 2/3 408 30.0 28.3 25.5
25
26 6 64-QAM 3/4 6 612 459 33.8 31.9 28.7
27 102
28 7 5/6 510 37.5 35.4 31.9
29
30 8 3/4 612 45.0 42.5 38.3
256-QAM 8 816
31 9 5/6 680 50.0 47.2 42.5
32
33 10 3/4 765 56.3 53.1 47.8
34 1024-QAM 10 1 020
35 11 5/6 850 62.5 59.0 53.1
36
37 12 3/4 918 67.5 63.8 57.4
38 4096-QAM 12 1 224
39 13 5/6 1 020 75.0 70.8 63.8
40 15 BPSK-DCM 1/2 1 51 51 25 1.8 1.7 1.6
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

750 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 36.5.5 EHT-MCSs for 106+26-tone MRU

2
3
The rate-dependent parameters for the 106+26-tone MRU are provided in Table 36-75 (EHT-MCSs for
4
5 106+26-tone MRU, NSS,u = 1),
6
7
8 Table 36-75—EHT-MCSs for 106+26-tone MRU, NSS,u = 1
9
10
11 EHT- Data rate (Mb/s)
12 MCS Modulation Ru NBPSCS,u NSD,u NCBPS,u NDBPS,u
13 index 0.8 µs GI 1.6 µs GI 3.2 µs GI
14
15 0 BPSK 1/2 1 126 63 4.6 4.4 3.9
16
17 1 1/2 126 9.3 8.8 7.9
18 QPSK 2 252
19 2 3/4 189 13.9 13.1 11.8
20
21 3 1/2 252 18.5 17.5 15.8
16-QAM 4 504
22 4 3/4 378 27.8 26.3 23.6
23
24 5 2/3 504 37.1 35.0 31.5
25
26 6 64-QAM 3/4 6 756 567 41.7 39.4 35.4
27 126
28 7 5/6 630 46.3 43.8 39.4
29
30 8 3/4 756 55.6 52.5 47.3
256-QAM 8 1 008
31 9 5/6 840 61.8 58.3 52.5
32
33 10 3/4 945 69.5 65.6 59.1
34 1024-QAM 10 1 260
35 11 5/6 1 050 77.2 72.9 65.6
36
37 12 3/4 1 134 83.4 78.8 70.9
38 4096-QAM 12 1 512
39 13 5/6 1 260 92.6 87.5 78.8
40 15 BPSK-DCM 1/2 1 63 63 31 2.3 2.2 1.9
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 751

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 36.5.6 EHT-MCSs for 242-tone RU

2
3
The rate-dependent parameters for the 242-tone RU are provided in Table 36-76 (EHT-MCSs for 242-tone
4
5 RU, NSS,u = 1).
6
7
8 Table 36-76—EHT-MCSs for 242-tone RU, NSS,u = 1
9
10
11 EHT- Data rate (Mb/s)
12 MCS Modulation Ru NBPSCS,u NSD,u NCBPS,u NDBPS,u
13 index 0.8 µs GI 1.6 µs GI 3.2 µs GI
14
15 0 BPSK 1/2 1 234 117 8.6 8.1 7.3
16
17 1 1/2 234 17.2 16.3 14.6
18 QPSK 2 468
19 2 3/4 351 25.8 24.4 21.9
20
21 3 1/2 468 34.4 32.5 29.3
16-QAM 4 936
22 4 3/4 702 51.6 48.8 43.9
23
24 5 2/3 936 68.8 65.0 58.5
25
26 6 64-QAM 3/4 6 1 404 1 053 77.4 73.1 65.8
27 234
28 7 5/6 1 170 86.0 81.3 73.1
29
30 8 3/4 1 404 103.2 97.5 87.8
256-QAM 8 1 872
31 9 5/6 1 560 114.7 108.3 97.5
32
33 10 3/4 1 755 129.0 121.9 109.7
34 1024-QAM 10 2 340
35 11 5/6 1 950 143.4 135.4 121.9
36
37 12 3/4 2 106 154.9 146.3 131.6
38 4096-QAM 12 2 808
39 13 5/6 2 340 172.1 162.5 146.3
40 15 BPSK-DCM 1/2 1 117 117 58 4.3 4.0 3.6
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

752 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 36.5.7 EHT-MCSs for 484-tone RU

2
3
The rate-dependent parameters for the 484-tone RU are provided in Table 36-77 (EHT-MCSs for 484-tone
4
5 RU, NSS,u = 1).
6
7
8 Table 36-77—EHT-MCSs for 484-tone RU, NSS,u = 1
9
10
11 EHT- Data rate (Mb/s)
12 MCS Modulation Ru NBPSCS,u NSD,u NCBPS,u NDBPS,u
13 index 0.8 µs GI 1.6 µs GI 3.2 µs GI
14
15 0 BPSK 1/2 1 468 234 17.2 16.3 14.6
16
17 1 1/2 468 34.4 32.5 29.3
18 QPSK 2 936
19 2 3/4 702 51.6 48.8 43.9
20
21 3 1/2 936 68.8 65.0 58.5
16-QAM 4 1 872
22 4 3/4 1 404 103.2 97.5 87.8
23
24 5 2/3 1 872 137.6 130.0 117.0
25
26 6 64-QAM 3/4 6 2 808 2 106 154.9 146.3 131.6
27 468
28 7 5/6 2 340 172.1 162.5 146.3
29
30 8 3/4 2 808 206.5 195.0 175.5
256-QAM 8 3 744
31 9 5/6 3 120 229.4 216.7 195.0
32
33 10 3/4 3 510 258.1 243.8 219.4
34 1024-QAM 10 4 680
35 11 5/6 3 900 286.8 270.8 243.8
36
37 12 3/4 4 212 309.7 292.5 263.3
38 4096-QAM 12 5 616
39 13 5/6 4 680 344.1 325.0 292.5
40 15 BPSK-DCM 1/2 1 234 234 117 8.6 8.1 7.3
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 753

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 36.5.8 EHT-MCSs for 484+242-tone MRU

2
3
The rate-dependent parameters for the 484+242-tone MRU are provided in Table 36-78 (EHT-MCSs for
4
5 484+242-tone MRU, NSS,u = 1).
6
7
8 Table 36-78—EHT-MCSs for 484+242-tone MRU, NSS,u = 1
9
10
11 EHT- Data rate (Mb/s)
12 MCS Modulation Ru NBPSCS,u NSD,u NCBPS,u NDBPS,u
13 index 0.8 µs GI 1.6 µs GI 3.2 µs GI
14
15 0 BPSK 1/2 1 702 351 25.8 24.4 21.9
16
17 1 1/2 702 51.6 48.8 43.9
18 QPSK 2 1 404
19 2 3/4 1 053 77.4 73.1 65.8
20
21 3 1/2 1 404 103.2 97.5 87.8
16-QAM 4 2 808
22 4 3/4 2 106 154.9 146.3 131.6
23
24 5 2/3 2 808 206.5 195.0 175.5
25
26 6 64-QAM 3/4 6 4 212 3 159 232.3 219.4 197.4
27 702
28 7 5/6 3 510 258.1 243.8 219.4
29
30 8 3/4 4 212 309.7 292.5 263.3
256-QAM 8 5 616
31 9 5/6 4 680 344.1 325.0 292.5
32
33 10 3/4 5 265 387.1 365.6 329.1
34 1024-QAM 10 7 020
35 11 5/6 5 850 430.1 406.3 365.6
36
37 12 3/4 6 318 464.6 438.8 394.9
38 4096-QAM 12 8 424
39 13 5/6 7 020 516.2 487.5 438.8
40 15 BPSK-DCM 1/2 1 351 351 175 12.9 12.2 10.9
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

754 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 36.5.9 EHT-MCSs for 996-tone RU

2
3
The rate-dependent parameters for the 996-tone RU are provided in Table 36-79 (EHT-MCSs for 996-tone
4
5 RU, NSS,u = 1).
6
7
8 Table 36-79—EHT-MCSs for 996-tone RU, NSS,u = 1
9
10
11 EHT- Data rate (Mb/s)
12 MCS Modulation Ru NBPSCS,u NSD,u NCBPS,u NDBPS,u
13 index 0.8 µs GI 1.6 µs GI 3.2 µs GI
14
15 0 BPSK 1/2 1 980 490 36.0 34.0 30.6
16
17 1 1/2 980 72.1 68.1 61.3
18 QPSK 2 1 960
19 2 3/4 1 470 108.1 102.1 91.9
20
21 3 1/2 1 960 144.1 136.1 122.5
16-QAM 4 3 920
22 4 3/4 2 940 216.2 204.2 183.8
23
24 5 2/3 3 920 288.2 272.2 245.0
25
26 6 64-QAM 3/4 6 5 880 4 410 324.3 306.3 275.6
27 980
28 7 5/6 4 900 360.3 340.3 306.3
29
30 8 3/4 5 880 432.4 408.3 367.5
256-QAM 8 7 840
31 9 5/6 6 533 480.4 453.7 408.3
32
33 10 3/4 7 350 540.4 510.4 459.4
34 1024-QAM 10 9 800
35 11 5/6 8 166 600.4 567.1 510.4
36
37 12 3/4 8 820 648.5 612.5 551.3
38 4096-QAM 12 11 760
39 13 5/6 9 800 720.6 680.6 612.5
40 15 BPSK-DCM 1/2 1 490 490 245 18.0 17.0 15.3
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 755

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 36.5.10 EHT-MCSs for 996+484-tone MRU

2
3
The rate-dependent parameters for the 996+484-tone MRU are provided in Table 36-80 (EHT-MCSs for
4
5 996+484-tone MRU, NSS,u = 1).
6
7
8 Table 36-80—EHT-MCSs for 996+484-tone MRU, NSS,u = 1
9
10
11 EHT- Data rate (Mb/s)
12 MCS Modulation Ru NBPSCS,u NSD,u NCBPS,u NDBPS,u
13 index 0.8 µs GI 1.6 µs GI 3.2 µs GI
14
15 0 BPSK 1/2 1 1 448 724 53.2 50.3 45.3
16
17 1 1/2 1 448 106.5 100.6 90.5
18 QPSK 2 2 896
19 2 3/4 2 172 159.7 150.8 135.8
20
21 3 1/2 2 896 212.9 201.1 181.0
16-QAM 4 5 792
22 4 3/4 4 344 319.4 301.7 271.5
23
24 5 2/3 5 792 425.9 402.2 362.0
25
26 6 64-QAM 3/4 6 8 688 6 516 479.1 452.5 407.3
27 1 448
28 7 5/6 7 240 532.4 502.8 452.5
29
30 8 3/4 8 688 638.8 603.3 543.0
256-QAM 8 11 584
31 9 5/6 9 653 709.8 670.3 603.3
32
33 10 3/4 10 860 798.5 754.2 678.8
34 1024-QAM 10 14 480
35 11 5/6 12 066 887.2 837.9 754.1
36
37 12 3/4 13 032 958.2 905.0 814.5
38 4096-QAM 12 17 376
39 13 5/6 14 480 1 064.7 1 005.6 905.0
40 15 BPSK-DCM 1/2 1 724 724 362 26.2 25.1 22.6
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

756 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 36.5.11 EHT-MCSs for 996+484+242-tone MRU

2
3
The rate-dependent parameters for the 996+484+242-tone MRU are provided in Table 36-81 (EHT-MCSs
4
5 for 996+484+242-tone MRU, NSS,u = 1).
6
7
8 Table 36-81—EHT-MCSs for 996+484+242-tone MRU, NSS,u = 1
9
10
11 EHT- Data rate (Mb/s)
12 MCS Modulation Ru NBPSCS,u NSD,u NCBPS,u NDBPS,u
13 index 0.8 µs GI 1.6 µs GI 3.2 µs GI
14
15 0 BPSK 1/2 1 1 682 841 61.8 58.4 52.6
16
17 1 1/2 1 682 123.7 116.8 105.1
18 QPSK 2 3 364
19 2 3/4 2 523 185.5 175.2 157.7
20
21 3 1/2 3 364 247.4 233.6 210.3
16-QAM 4 6 728
22 4 3/4 5 046 371.0 350.4 315.4
23
24 5 2/3 6 728 494.7 467.2 420.5
25
26 6 64-QAM 3/4 6 10 092 7 569 556.5 525.6 473.1
27 1 682
28 7 5/6 8 410 618.4 584.0 525.6
29
30 8 3/4 10 092 742.1 700.8 630.8
256-QAM 8 13 456
31 9 5/6 11 213 824.5 778.7 700.8
32
33 10 3/4 12 615 927.6 876.0 788.4
34 1024-QAM 10 16 820
35 11 5/6 14 016 1 030.6 973.3 876.0
36
37 12 3/4 15 138 1 113.1 1 051.3 946.1
38 4096-QAM 12 20 184
39 13 5/6 16 820 1 236.8 1 168.1 1 051.3
40 15 BPSK-DCM 1/2 1 841 841 420 30.9 29.2 26.3
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 757

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 36.5.12 EHT-MCSs for 2×996-tone RU

2
3
The rate-dependent parameters for the 2×996-tone RU are provided in Table 36-82 (EHT-MCSs for 2×996-
4
5 tone RU, NSS,u = 1).
6
7
8 Table 36-82—EHT-MCSs for 2×996-tone RU, NSS,u = 1
9
10
11 EHT- Data rate (Mb/s)
12 MCS Modulation Ru NBPSCS,u NSD,u NCBPS,u NDBPS,u
13 index 0.8 µs GI 1.6 µs GI 3.2 µs GI
14
15 0 BPSK 1/2 1 1 960 980 72.1 68.1 61.3
16
17 1 1/2 1 960 144.1 136.1 122.5
18 QPSK 2 3 920
19 2 3/4 2 940 216.2 204.2 183.5
20
21 3 1/2 3 920 288.2 272.2 245.0
16-QAM 4 7 840
22 4 3/4 5 880 432.4 408.3 367.5
23
24 5 2/3 7 840 576.5 544.4 490.0
25
26 6 64-QAM 3/4 6 11 760 8 820 648.5 612.5 551.3
27 1 960
28 7 5/6 9 800 720.6 680.6 612.5
29
30 8 3/4 11 760 864.7 816.7 735.0
256-QAM 8 15 680
31 9 5/6 13 066 960.7 907.4 816.6
32
33 10 3/4 14 700 1 080.9 1 020.8 918.8
34 1024-QAM 10 19 600
35 11 5/6 16 333 1 201.0 1 134.2 1 020.8
36
37 12 3/4 17 640 1 297.1 1 225.0 1 102.5
38 4096-QAM 12 23 520
39 13 5/6 19 600 1 441.2 1 361.1 1 225.0
40 15 BPSK-DCM 1/2 1 980 980 490 36.0 34.0 30.6
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

758 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 36.5.13 EHT-MCSs for 2×996+484-tone MRU

2
3
The rate-dependent parameters for the 2×996+484-tone MRU are provided in Table 36-83 (EHT-MCSs for
4
5 2×996+484-tone MRU, NSS,u = 1).
6
7
8 Table 36-83—EHT-MCSs for 2×996+484-tone MRU, NSS,u = 1
9
10
11 EHT- Data rate (Mb/s)
12 MCS Modulation Ru NBPSCS,u NSD,u NCBPS,u NDBPS,u
13 index 0.8 µs GI 1.6 µs GI 3.2 µs GI
14
15 0 BPSK 1/2 1 2 428 1 214 89.3 84.3 75.9
16
17 1 1/2 2 428 178.5 168.6 151.8
18 QPSK 2 4 856
19 2 3/4 3 642 267.8 252.9 227.6
20
21 3 1/2 4 856 357.1 337.2 303.5
16-QAM 4 9 712
22 4 3/4 7 284 535.6 505.8 455.3
23
24 5 2/3 9 712 714.1 674.4 607.0
25
26 6 64-QAM 3/4 6 14 568 10 926 803.4 758.8 682.9
27 2 428
28 7 5/6 12 140 892.6 843.1 758.8
29
30 8 3/4 14 568 1 071.2 1 011.7 910.5
256-QAM 8 19 424
31 9 5/6 16 186 1 190.1 1 124.0 1 011.6
32
33 10 3/4 18 210 1 339.0 1 264.6 1 138.1
34 1024-QAM 10 24 280
35 11 5/6 20 233 1 487.7 1 405.1 1 264.6
36
37 12 3/4 21 852 1 606.8 1 517.5 1 365.8
38 4096-QAM 12 29 136
39 13 5/6 24 280 1 785.3 1 686.1 1 517.5
40 15 BPSK-DCM Not valid
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 759

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 36.5.14 EHT-MCSs for 3×996-tone MRU

2
3
The rate-dependent parameters for the 3×996-tone MRU are provided in Table 36-84 (EHT-MCSs for
4
5 3×996-tone MRU, NSS,u = 1).
6
7
8 Table 36-84—EHT-MCSs for 3×996-tone MRU, NSS,u = 1
9
10
11 EHT- Data rate (Mb/s)
12 MCS Modulation Ru NBPSCS,u NSD,u NCBPS,u NDBPS,u
13 index 0.8 µs GI 1.6 µs GI 3.2 µs GI
14
15 0 BPSK 1/2 1 2 940 1 470 108.1 102.1 91.9
16
17 1 1/2 2 940 216.2 204.2 183.8
18 QPSK 2 5 880
19 2 3/4 4 410 324.3 306.3 275.6
20
21 3 1/2 5 880 432.4 408.3 367.5
16-QAM 4 11 760
22 4 3/4 8 820 648.5 612.5 551.3
23
24 5 2/3 11 760 864.7 816.7 735.0
25
26 6 64-QAM 3/4 6 17 640 13 230 972.8 918.8 826.9
27 2 940
28 7 5/6 14 700 1 080.9 1 020.8 918.8
29
30 8 3/4 17 640 1 297.1 1 225.0 1 102.5
256-QAM 8 23 520
31 9 5/6 19 600 1 441.2 1 361.1 1 225.0
32
33 10 3/4 22 050 1 621.3 1 531.3 1 378.1
34 1024-QAM 10 29 400
35 11 5/6 24 500 1 801.5 1 701.4 1 531.3
36
37 12 3/4 26 460 1 945.6 1 837.5 1 653.8
38 4096-QAM 12 35 280
39 13 5/6 29 400 2 161.8 2 041.7 1 837.5
40 15 BPSK-DCM 1/2 1 1 470 1 470 735 54.0 51.0 45.9
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

760 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 36.5.15 EHT-MCSs for 3×996+484-tone MRU

2
3
The rate-dependent parameters for the 3×996+484-tone MRU are provided in Table 36-85 (EHT-MCSs for
4
5 3×996+484-tone MRU, NSS,u = 1).
6
7
8 Table 36-85—EHT-MCSs for 3×996+484-tone MRU, NSS,u = 1
9
10
11 EHT- Data rate (Mb/s)
12 MCS Modulation Ru NBPSCS,u NSD,u NCBPS,u NDBPS,u
13 index 0.8 µs GI 1.6 µs GI 3.2 µs GI
14
15 0 BPSK 1/2 1 3 408 1 704 125.3 118.3 106.5
16
17 1 1/2 3 408 250.6 236.7 213.0
18 QPSK 2 6 816
19 2 3/4 5 112 375.9 355.0 319.5
20
21 3 1/2 6 816 501.2 473.3 426.0
16-QAM 4 13 632
22 4 3/4 10 224 751.8 710.0 639.0
23
24 5 2/3 13 632 1 002.4 946.7 852.0
25
26 6 64-QAM 3/4 6 20 448 15 336 1 127.6 1 065.0 958.5
27 3 408
28 7 5/6 17 040 1 252.9 1 183.3 1 065.0
29
30 8 3/4 20 448 1 503.5 1 420.0 1 278.0
256-QAM 8 27 264
31 9 5/6 22 720 1 670.6 1 577.8 1 420.0
32
33 10 3/4 25 560 1 879.4 1 775.0 1 597.5
34 1024-QAM 10 34 080
35 11 5/6 28 400 2 088.2 1 972.2 1 775.0
36
37 12 3/4 30 672 2 255.3 2 130.0 1 917.0
38 4096-QAM 12 40 896
39 13 5/6 34 080 2 505.9 2 366.7 2 130.0
40 15 BPSK-DCM 1/2 Not valid
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 761

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 36.5.16 EHT-MCSs for 4×996-tone RU

2
3
The rate-dependent parameters for the 4×996-tone RU are provided in Table 36-86 (EHT-MCSs for 4×996-
4
5 tone RU, NSS,u = 1).
6
7
8 Table 36-86—EHT-MCSs for 4×996-tone RU, NSS,u = 1
9
10
11 EHT- Data rate (Mb/s)
12 MCS Modulation Ru NBPSCS,u NSD,u NCBPS,u NDBPS,u
13 index 0.8 µs GI 1.6 µs GI 3.2 µs GI
14
15 0 BPSK 1/2 1 3 920 1 960 144.1 136.1 122.5
16
17 1 1/2 3 920 288.2 272.2 245.0
18 QPSK 2 7 840
19 2 3/4 5 880 432.4 408.3 367.5
20
21 3 1/2 7 840 576.5 544.4 490.0
16-QAM 4 15 680
22 4 3/4 11 760 864.7 816.7 735.0
23
24 5 2/3 15 680 1 152.9 1 088.9 980.0
25
26 6 64-QAM 3/4 6 23 520 17 640 1 297.1 1 225.0 1 102.5
27 3 920
28 7 5/6 19 600 1 441.2 1 361.1 1 225.0
29
30 8 3/4 23 520 1 729.4 1 633.3 1 470.0
256-QAM 8 31 360
31 9 5/6 26 133 1 921.5 1 814.8 1 633.3
32
33 10 3/4 29 400 2 161.8 2 041.7 1 837.5
34 1024-QAM 10 39 200
35 11 5/6 32 666 2 401.9 2 268.5 2 041.6
36
37 12 3/4 35 280 2 594.1 2 450.0 2 205.0
38 4096-QAM 12 47 040
39 13 5/6 39 200 2 882.4 2 722.2 2 450.0
40 15 BPSK-DCM 1/2 1 1 960 1 960 980 72.1 68.1 61.3
41
42
43
44 36.5.17 EHT-MCS 14 for EHT DUP mode
45
46
47 The rate-dependent parameters for EHT-MCS 14 are provided in Table 36-87 (EHT-MCS 14 for EHT DUP
48 mode, NSS,u = 1(#4909)).
49
50
51 Table 36-87—EHT-MCS 14 for EHT DUP mode, NSS,u = 1(#4909)
52
53
54 Data rate (Mb/s)
55
56 Modulation Bandwidth R NBPSCS NSD NCBPS NDBPS
0.8 µs 1.6 µs 3.2 µs
57 GI GI GI
58
59 BPSK-DCM 80 MHz 1/2 1 234 234 117 8.6 8.1 7.3
60
61 BPSK-DCM 160 MHz 1/2 1 490 490 245 18.0 17.0 15.3
62
63 BPSK-DCM 320 MHz 1/2 1 980 980 490 36.0 34.0 30.6
64
65

762 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 36.6 Parameters for EHT-SIG MCSs(#8097)

2
3
4 The EHT-SIG MCSs, defined in Table 36-88 (EHT-SIG MCSs(#8152)), are used for the EHT-SIG field
5 transmission in the EHT MU PPDU.
6
7
8 Table 36-88—EHT-SIG MCSs(#8152)
9
10
11 Value of the
12 EHT-MCS EHT-SIG
EHT-SIG Modulation R NBPSCS NSD NCBPS NDBPS
13 index rate (Mb/s)
MCS field
14
15 0 EHT-MCS 0 BPSK 1/2 1 52 52 26 6.6
16
17 1 EHT-MCS 1 QPSK 1/2 2 52 104 52 13.2
18
19 2 EHT-MCS 3 16-QAM 1/2 4 52 208 104 26.0
20
3 EHT-MCS 15 BPSK-DCM 1/2 1 26 26 13 3.3
21
22 NOTE—The parameters N SD , N CBPS , and N DBPS are used for the EHT-SIG field transmission in each 20 MHz
23 subchannel.
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 763

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

764 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2
Annex B
3
4 (normative)
5
6
7
8 Protocol Implementation Conformance Statement (PICS) pro-
9
10
forma
11
12
13
14 B.2 Abbreviations and special symbols
15
16
17 B.2.2 General abbreviations for Item and Support columns
18
19
20 Insert the following abbreviations (maintaining alphabetical order):
21
22 EHTM Extremely high throughput MAC(#6672)
23
24
25 EHTP Extremely high throughput PHY(#6672)
26
27
28
29 B.4 PICS proforma—IEEE Std 802.11-<year>
30
31
32 B.4.3 IUT configuration
33
34
35 Insert the following rows at the end of the table:
36
37
Item IUT configuration References Status Support
38
39 *CFEHT EHT operation Clause 36 O Yes  No 
40
41 *CFEHT2G4 EHT operation in the 2.4 GHz band Clause 36 CFEHT: O.10 Yes  No 
42 (#6672)
43 *CFEHT5G EHT operation in the 5 GHz band Clause 36 CFEHT: O.10 Yes  No 
44 (#6672)
45
46 *CFEHT6G EHT operation in the 6 GHz band Clause 36 CFEHT: O.10 Yes  No 
47 (#6672)
48 *CFEHT20 EHT operation as a 20 MHz-only non- Clause 36 CFIndepSTA Yes  No 
49 AP EHT STA AND CFEHT:
50 O.11
51
52 *CFEHT80 EHT operation with capability of Clause 36 CFAP AND Yes  No 
53 80 MHz or wider channel width CFEHT: M
54 CFIndepSTA
55 AND CFEHT:
56 O.11
57 *CFEHT- EHT MLD operation Clause 35 CFEHT AND Yes  No 
58 MLD CFAP: M
59 (#6672)
60 CFEHT AND
61 CFSTAofAP:
62
63 *CFEHTM- EHT AP MLD operation Clause 35 CFEHTMLD: Yes  No 
64 LDAP O.11
65 (#6672)

Copyright © 2022 IEEE. All rights reserved. 765

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2 Item IUT configuration References Status Support
3 *CFEHTM- EHT non-AP MLD operation Clause 35 CFEHTMLD: Yes  No 
4 LDnonAP O.11
5 (#6672)
6
7 *CFEHTN- NSTR mobile AP MLD operation Clause 35 CFEHTMLD: Yes  No 
8 STRMo- O.11
9 bileAP
10 (#6672)
11
12
13 B.4.4 MAC protocol
14
15
16 B.4.4.2 MAC frames
17
18
19 Insert the following rows at the end of the table (maintaining item order):
20
21
Item MAC frame References Status Support
22
23 Is transmission of the following MAC Clause 9
24 frames supported?
25
26 … … … … …
27 (#6672)FT74 EHT Action frames 9.6.34 CFEHT: O Yes  No  N/A 
28
29 FT74.1 EML Operating Mode Notification 9.6.34.3 EHTM9.10 Yes  No  N/A 
30 frame OR
31 EHTM9.11: M
32 FT75 Protected EHT Action frame 9.6.35 CFEHT: O Yes  No  N/A 
33
34 FT75.1 TID-To-Link Mapping Request frame 9.6.35.2 EHTM9.14: M Yes  No  N/A 
35 FT75.2 TID-To-Link Mapping Response frame 9.6.35.3 EHTM9.14: M Yes  No  N/A 
36
37 FT75.3 TID-To-Link Mapping Teardown frame 9.6.35.4 EHTM9.14: M Yes  No  N/A 
38 FT75.4 EPCS Priority Access Enable Request 9.6.35.5 EHTM5: M Yes  No  N/A 
39 frame
40
41 FT75.5 EPCS Priority Access Enable Response 9.6.35.6 EHTM5: M Yes  No  N/A 
42 frame
43 FT75.6 EPCS Priority Access Teardown frame 9.6.35.7 EHTM5: M Yes  No  N/A 
44
45 Is reception of the following MAC Clause 9
46 frames supported?
47 … … … … …
48
49 FR75 EHT Action frames 9.6.34 CFEHT: M Yes  No  N/A 
50 FR75.1 EML Operating Mode Notification EHTM9.10 Yes  No  N/A 
51 frame OR
52 EHTM9.11: M
53
54 FR76 Protected EHT Action frame 9.6.35 CFEHT: O Yes  No  N/A 
55 FR76.1 TID-To-Link Mapping Request frame 9.6.35.2 EHTM9.14: M Yes  No  N/A 
56
57 FR76.2 TID-To-Link Mapping Response frame 9.6.35.3 EHTM9.14: M Yes  No  N/A 
58 FR76.3 TID-To-Link Mapping Teardown frame 9.6.35.4 EHTM9.14: M Yes  No  N/A 
59
60 FR76.4 EPCS Priority Access Enable Request 9.6.35.5 EHTM5: M Yes  No  N/A 
61 frame
62 FR76.5 EPCS Priority Access Enable Response 9.6.35.6 EHTM5: M Yes  No  N/A 
63 frame
64
65 FR76.6 EPCS Priority Access Teardown frame 9.6.35.7 EHTM5: M Yes  No  N/A 

766 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Insert the following new subclause at the end of subclause B.4:

2
3
4 B.4.40 Extremely High Throughput (EHT) features
5
6
7 B.4.40.1 EHT PHY features
8
9
10
11 Item Protocol capability References Status Support
12
13 EHTP1 PHY operating modes
14
15 EHTP1.1 Operation according to Clause 17 Clause 17 CFEHT6G: M Yes  No  N/A 
16 (Orthogonal frequency division multi- CFEHT5G: M
17 plexing (OFDM) PHY specification) CFEHT2G4: M
18 EHTP1.2 Operation according to Clause 19 Clause 19 CFEHT5G AND Yes  No  N/A 
19 (High Throughput (HT) PHY specifi- CFEHT80: M
20 cation) CFEHT5G AND
21 CFEHT20: M
22 CFEHT2G4: M
23
24 EHTP1.3 Operation according to Clause 21 Clause 21 CFEHT5G AND Yes  No  N/A 
25 (Very High Throughput (VHT) PHY CFEHT80: M
26 specification) CFEHT5G AND
27 CFEHT20: M
28
29 EHTP1.4 Operation according to Clause 27 Clause 27 CFEHT5G AND Yes  No  N/A 
30 (High Efficiency (HE) PHY specifica- CFEHT80: M
31 tion) CFEHT5G AND
32 CFEHT20: M
33 CFEHT2G4: M
34 CFEHT6G: M
35
36 EHTP2 EHT PPDU formats
37
38 EHTP2.1 Single user transmission of an EHT 36.1.1 CFEHT: M Yes  No  N/A 
39 MU PPDU with single RU or MRU in
40 the entire PPDU bandwidth
41 EHTP2.2 Single user reception of an EHT MU 36.1.1 CFEHT: M Yes  No  N/A 
42 PPDU with single RU or MRU in the
43 entire PPDU bandwidth
44
45 EHTP2.3 Transmission of an EHT MU PPDU 36.1.1 CFEHT and Yes  No  N/A 
46 where none of the RUs or MRUs uti- CFAP: M
47 lize MU-MIMO (DL OFDMA)
48
49 EHTP2.4 Reception of an EHT MU PPDU 36.1.1 CFEHT AND Yes  No  N/A 
50 where the RU/MRU allocated to the CFSTAofAP: M
51 non-AP STA is not utilizing MU-
52 MIMO (DL OFDMA)
53
54 EHTP2.5 Transmission of an EHT MU PPDU 36.3.3.1.2 (#4558)CFEHT Yes  No  N/A 
55 consisting of a single RU or MRU and CFAP AND
56 spanning the entire PPDU bandwidth EHTP7.68: M
57 and utilizing MU-MIMO (DL MU-
58 MIMO)
59
60 EHTP2.6 Reception of an EHT MU PPDU con- 36.3.3.1.2 CFEHT AND Yes  No  N/A 
61 sisting of a single RU or MRU in the CFSTAofAP: M
62 entire PPDU bandwidth and utilizing
63 MU-MIMO (DL MU-MIMO)
64
65

Copyright © 2022 IEEE. All rights reserved. 767

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2 Item Protocol capability References Status Support
3
4 EHTP2.7 MU-MIMO transmission on an RU/ 36.3.3.1 CFEHT and Yes  No  N/A 
5 MRU in an EHT MU PPDU where CFAP: O
6 there are multiple RU/MRUs in the
7 PPDU bandwidth (DL MU-MIMO
8 within OFDMA)
9
10 *EHTP2.8 MU-MIMO reception on an RU/MRU 36.3.3.1.1 CFEHT AND Yes  No  N/A 
11 in an EHT MU PPDU where there are CFSTAofAP: O
12 multiple RU/MRUs in the PPDU
13 bandwidth (DL MU-MIMO within
14 OFDMA)
15 EHTP2.9 Transmission of an EHT TB PPDU 36.1.1 CFEHT AND Yes  No  N/A 
16 where the RU/MRU allocated to the CFSTAofAP: M
17 non-AP STA is not utilizing MU-
18 MIMO (UL OFDMA)
19
20 EHTP2.10 Reception of an EHT TB PPDU 36.1.1 CFEHT and Yes  No  N/A 
21 where none of the RUs or MRUs uti- CFAP: M
22 lize MU-MIMO (UL OFDMA)
23
24 EHTP2.11 Transmission of an EHT TB PPDU 36.3.3.2.4 CFEHT and Yes  No  N/A 
25 consisting of a single RU or MRU CFSTAofAP: M
26 spanning the entire PPDU bandwidth
27 and utilizing MU-MIMO (UL MU-
28 MIMO)
29
30 EHTP2.12 Reception of an EHT TB PPDU con- (#4558)36. (#4558)CFEHT Yes  No  N/A 
31 sisting of a single RU or MRU span- 3.3.2 and CFAP AND
32 ning the entire PPDU bandwidth and NOT EHTP7.69:
33 utilizing MU-MIMO (UL MU- O
34 MIMO) CFEHT and CFAP
35 AND EHTP7.69:
36 M
37
38 EHTP2.13 Transmission of an EHT TB PPDU 36.3.3.2 CFEHT and Yes  No  N/A 
39 where the RU/MRU allocated to the CFSTAofAP: O
40 non-AP STA is utilizing MU-MIMO
41 (UL MU-MIMO within OFDMA)
42 EHTP2.14 Reception of an EHT TB PPDU 36.3.3.2 (#4558)CFEHT Yes  No  N/A 
43 where RU/MRU allocated to a non- and CFAP: O
44 AP STA are utilizing MU-MIMO (UL
45 MU-MIMO within OFDMA)
46
47 EHTP3 BSS bandwidth
48
49 EHTP3.1 20 MHz operation 36.1.1 CFEHT: M Yes  No  N/A 
50
51 *EHTP3.2 40 MHz operation 36.1.1 CFEHT80 AND Yes  No  N/A 
52 CFEHT5G: M
53 CFEHT80 AND
54 CFEHT6G: M
55 CFEHT2G4: O
56 EHTP3.3: M
57
58 *EHTP3.3 80 MHz operation 36.1.1 CFEHT80 AND Yes  No  N/A 
59 CFEHT5G: M
60 CFEHT80 AND
61 CFEHT6G: M
62 EHTP3.4: M
63
64
65

768 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2 Item Protocol capability References Status Support
3
4 *EHTP3.4 160 MHz operation 36.1.1 CFEHT80 AND Yes  No  N/A 
5 CFEHT5G: O
6 CFAP AND CFE-
7 HT6G: M
8 CFSTAofAP AND
9 CFEHT6G: O
10 EHTP3.5: M
11
12 *EHTP3.5 320 MHz operation 36.1.1 CFEHT80 AND Yes  No  N/A 
13 CFEHT6G: O
14 EHTP3.6 Ability to participate in 40 MHz DL (#4561)36. CFEHT20: M Yes  No  N/A 
15 OFDMA 3.2.5
16
17 EHTP3.7 Ability to participate in 80 MHz DL (#4561)36. CFEHT20: M Yes  No  N/A 
18 OFDMA 3.2.5
19
20 EHTP3.8 Ability to participate in 160 MHz DL (#4561)36. CFEHT20: M Yes  No  N/A 
21 OFDMA 3.2.5, CFEHT80: M
22 36.3.2.7
23
24 EHTP3.9 Ability to participate in 320 MHz DL (#4561)36. CFEHT20: M Yes  No  N/A 
25 OFDMA 3.2.5, CFEHT80: M
26 36.3.2.7, EHTP3.4: M
27 36.3.2.8
28
29 EHTP3.10 Ability to participate in 40 MHz UL (#4561)36. CFEHT20: M Yes  No  N/A 
30 OFDMA 3.2.5
31 EHTP3.11 Ability to participate in 80 MHz UL (#4561)36. CFEHT20: M Yes  No  N/A 
32 OFDMA 3.2.5
33
34 EHTP3.12 Ability to participate in 160 MHz UL (#4561)36. CFEHT20: M Yes  No  N/A 
35 OFDMA 3.2.5, CFEHT80: M
36 36.3.2.7
37
38 EHTP3.13 Ability to participate in 320 MHz UL (#4561)36. CFEHT20: M Yes  No  N/A 
39 OFDMA 3.2.5, CFEHT80: M
40 36.3.2.7, EHTP3.4: M
41 36.3.2.8
42
43 EHTP4 EHT LTF formats
44
45 EHTP4.1 Single user transmission and reception 36.1.1 CFEHT: M Yes  No  N/A 
46 of an EHT MU PPDU with a 2 EHT-
47 LTF and 0.8 µs GI duration
48 EHTP4.2 Single user transmission and reception 36.1.1 CFEHT: M Yes  No  N/A 
49 of an EHT MU PPDU with a 2 EHT-
50 LTF and 1.6 µs GI duration
51
52 EHTP4.3 Single user transmission and reception 36.1.1 CFEHT: M Yes  No  N/A 
53 of an EHT MU PPDU with a 4 EHT-
54 LTF and 3.2 µs GI duration
55
56 EHTP4.4 Single user transmission and reception 36.1.1 CFEHT: O Yes  No  N/A 
57 of an EHT MU PPDU with a 4 EHT-
58 LTF and 0.8 µs GI duration
59
60 EHTP4.5 Multiple user transmission of an EHT 36.1.1 CFEHT and Yes  No  N/A 
61 MU PPDU with a 2 EHT-LTF and CFAP: M
62 0.8 µs GI duration
63
64
65

Copyright © 2022 IEEE. All rights reserved. 769

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2 Item Protocol capability References Status Support
3
4 EHTP4.6 Multiple user transmission of an EHT 36.1.1 CFEHT and Yes  No  N/A 
5 MU PPDU with a 2 EHT-LTF and CFAP: M
6 1.6 µs GI duration
7
8 EHTP4.7 Multiple user transmission of an EHT 36.1.1 CFEHT and Yes  No  N/A 
9 MU PPDU with a 4 EHT-LTF and CFAP: M
10 3.2 µs GI duration
11 EHTP4.8 Multiple user transmission of an EHT 36.1.1 CFEHT AND Yes  No  N/A 
12 MU PPDU with a 4 EHT-LTF and CFAP: O
13 0.8 µs GI duration
14
15 EHTP4.9 Reception of a non-OFDMA EHT TB 36.1.1 CFEHT AND Yes  No  N/A 
16 PPDU with a 1 EHT-LTF and 1.6 µs CFAP: M
17 GI duration on the EHT-LTF and Data
18 field OFDM symbols
19
20 EHTP4.10 Reception of an EHT TB PPDU with 36.1.1 CFEHT AND Yes  No  N/A 
21 a 2 EHT-LTF and 1.6 µs GI duration CFAP: M
22 on the EHT-LTF and Data field
23 OFDM symbols
24
25 EHTP4.11 Reception of an EHT TB PPDU with 36.1.1 CFEHT AND Yes  No  N/A 
26 a 4 EHT-LTF and 3.2 µs GI duration CFAP: M
27 on the EHT-LTF and Data field
28 OFDM symbols
29
30 EHTP4.12 Reception of an EHT MU PPDU to 36.1.1 CFEHT AND Yes  No  N/A 
31 multiple users with a 2 EHT-LTF and CFSTAofAP: M
32 0.8 µs GI duration on the EHT-LTF
33 and Data field OFDM symbols
34 EHTP4.13 Reception of an EHT MU PPDU to 36.1.1 CFEHT AND Yes  No  N/A 
35 multiple users with a 2 EHT-LTF and CFSTAofAP: M
36 1.6 µs GI duration on the EHT-LTF
37 and Data field OFDM symbols
38
39 EHTP4.14 Reception of an EHT MU PPDU to 36.1.1 CFEHT AND Yes  No  N/A 
40 multiple users with a 4 EHT-LTF and CFSTAofAP: M
41 3.2 µs GI duration on the EHT-LTF
42 and Data field OFDM symbols
43
44 EHTP4.15 Reception of an EHT MU PPDU to 36.1.1 CFEHT AND Yes  No  N/A 
45 multiple users with a 4 EHT-LTF and CFSTAofAP: O
46 0.8 µs GI duration on the EHT-LTF
47 and Data field OFDM symbols
48
49 EHTP4.16 Transmission of a non-OFDMA EHT 36.1.1 CFEHT AND Yes  No  N/A 
50 TB PPDU with a 1 EHT-LTF and CFSTAofAP: M
51 1.6 µs GI duration on the EHT-LTF
52 and Data field OFDM symbols
53
54 EHTP4.17 Transmission of an EHT TB PPDU 36.1.1 CFEHT AND Yes  No  N/A 
55 with a 2 EHT-LTF and 1.6 µs GI CFSTAofAP: M
56 duration on the EHT-LTF and Data
57 field OFDM symbols
58 EHTP4.18 Transmission of an EHT TB PPDU 36.1.1 CFEHT AND Yes  No  N/A 
59 with a 4 EHT-LTF and 3.2 µs GI CFSTAofAP: M
60 duration on the EHT-LTF and Data
61 field OFDM symbols
62
63 EHTP4.19 Support of extra EHT-LTF for non- 9.4.2.313.3 CFEHT: O Yes  No  N/A 
64 OFDMA transmissions
65

770 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2 Item Protocol capability References Status Support
3
4 EHTP5 RU support
5
6 EHTP5.1 (single) RU support in all applicable
7 locations
8 EHTP5.1.1 26-tone RU mapping 36.1.1 CFEHT: M Yes  No  N/A 
9
10 EHTP5.1.2 52-tone RU mapping 36.1.1 CFEHT: M Yes  No  N/A 
11
12 EHTP5.1.3 106-tone RU mapping 36.1.1 CFEHT: M Yes  No  N/A 
13
14 EHTP5.1.4 242-tone RU mapping 36.1.1 CFEHT: M Yes  No  N/A 
15
16 EHTP5.1.5 Support of 242-tone RU in wider BW 36.1.1 CFEHT20: O Yes  No  N/A 
17 OFDMA
18 EHTP5.1.6 484-tone RU mapping 36.1.1 CFEHT80: M Yes  No  N/A 
19 EHTP3.2: M
20
21 EHTP5.1.7 996-tone RU mapping 36.1.1 CFEHT80: M Yes  No  N/A 
22
23 EHTP5.1.8 2996-tone RU mapping 36.1.1 EHTP3.4: M Yes  No  N/A 
24 EHTP3.5: M
25
26 EHTP5.1.9 4996-tone RU mapping 36.1.1 EHTP3.5: M Yes  No  N/A 
27
28 EHTP5.2 Large M-RU support in all applicable
29 locations
30 EHTP5.2.1 484+242-tone RU in non-OFDMA 36.3.2.2.3 CFEHT80: M Yes  No  N/A 
31
32 EHTP5.2.2 996+484-tone RU in non-OFDMA 36.3.2.2.3 EHTP3.4: M Yes  No  N/A 
33
34 EHTP5.2.3 996+484+242-tone RU in non- 36.3.2.2.3 EHTP3.4: M Yes  No  N/A 
35 OFDMA
36
37 EHTP5.2.4 2996+484-tone RU in non-OFDMA 36.3.2.2.3 EHTP3.5: M Yes  No  N/A 
38
39 EHTP5.2.5 3996-tone RU in non-OFDMA 36.3.2.2.3 EHTP3.5: M Yes  No  N/A 
40 EHTP5.2.6 3996+484-tone RU in non-OFDMA 36.3.2.2.3 EHTP3.5: M Yes  No  N/A 
41
42 EHTP5.2.7 484+242-tone RU in OFDMA 36.3.2.2.3 CFEHT80 AND Yes  No  N/A 
43 CFSTAofAP: M
44 CFEHT AND
45 CFAP: O
46
47 EHTP5.2.8 996+484-tone RU in OFDMA 36.3.2.6 CFSTAofAP AND Yes  No  N/A 
48 EHTP3.4: M
49 CFAP AND
50 EHTP3.4: O
51
52 EHTP5.2.9 996+484+242-tone RU in OFDMA 36.3.3.1 CFSTAofAP AND Yes  No  N/A 
53 EHTP3.4: M
54 CFAP AND
55 EHTP3.4: O
56
57 EHTP5.2.10 2996+484-tone RU in OFDMA 36.3.3.1.2 CFSTAofAP AND Yes  No  N/A 
58 EHTP3.5: M
59 CFAP AND
60 EHTP3.5: O
61 EHTP5.2.11 3996 tone-RU in OFDMA 36.3.3.1.2 CFSTAofAP AND Yes  No  N/A 
62 EHTP3.5: M
63 CFAP AND
64 EHTP3.5: O
65

Copyright © 2022 IEEE. All rights reserved. 771

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2 Item Protocol capability References Status Support
3
4 EHTP5.2.12 3996+484-tone RU in OFDMA 36.3.3.1.2 CFSTAofAP AND Yes  No  N/A 
5 EHTP3.5: M
6 CFAP AND
7 EHTP3.5: O
8
9 EHTP5.3 Small MRU support in all applicable Yes  No  N/A 
10 locations
11 EHTP5.3.1 52+26-tone RU in OFDMA in a 36.3.2.2.2 CFEHT: M Yes  No  N/A 
12 20 MHz PPDU
13
14 EHTP5.3.2 52+26-tone RU in OFDMA in a 36.3.2.2.2 CFEHT80: M Yes  No  N/A 
15 40 MHz PPDU
16
17 EHTP5.3.3 52+26-tone RU in OFDMA in each 36.3.2.2.2 CFEHT80: M Yes  No  N/A 
18 80 MHz subblock(#1279)
19
20 EHTP5.3.4 106+26-tone RU in OFDMA in a 36.3.2.2.2 CFEHT: M Yes  No  N/A 
21 20 MHz PPDU
22
23 EHTP5.3.5 106+26-tone RU in OFDMA in a 36.3.2.2.2 CFEHT80: M Yes  No  N/A 
24 40 MHz PPDU
25 EHTP5.3.6 106+26-tone RU in OFDMA in each 36.3.2.2.2 CFEHT80: M Yes  No  N/A 
26 80 MHz subblock(#1279)
27
28 EHTP6 Coding
29
30 EHTP6.1 BCC coding 36.1.1 CFEHT: M Yes  No  N/A 
31
32 EHTP6.2 LDPC coding in all supported EHT 36.1.1 EHTP3.2: M Yes  No  N/A 
33 PPDU types, RU and MRU sizes and EHTP7.4: M
34 NSS EHTP7.29: M
35
36 EHTP6.3 (#4562)LDPC coding when the STA 36.1.1 (#4562)CFE- Yes  No  N/A 
37 supports less than or equal to 4 SS and HT20: O
38 does not support EHT-MCS 10, 11,
39 12, or 13
40 EHTP7 EHT MCS support
41
42 EHTP7.1 EHT-MCS 0–7 with N SS = 1 36.1.1 CFEHT: M Yes  No  N/A 
43
44 *EHTP7.2 EHT-MCS 8 with N SS = 1 36.1.1 CFEHT80: M Yes  No  N/A 
45 CFEHT20: O
46
47 *EHTP7.3 EHT-MCS 9 with N SS = 1 36.1.1 CFEHT80: M Yes  No  N/A 
48 CFEHT20 AND
49 EHTP7.2: O
50
51 *EHTP7.4 EHT-MCS 10 with N SS = 1 36.1.1 EHTP7.3: O Yes  No  N/A 
52 *EHTP7.5 EHT-MCS 11 with NSS = 1 36.1.1 EHTP7.4: O Yes  No  N/A 
53
54 *EHTP7.6 EHT-MCS 12 with N SS = 1 36.1.1 EHTP7.5: O Yes  No  N/A 
55
56 EHTP7.7 EHT-MCS 13 with N SS = 1 36.1.1 EHTP7.6: O Yes  No  N/A 
57
58 *EHTP7.8 EHT-MCS 0–7 with N SS = 2 36.1.1 CFEHT: O Yes  No  N/A 
59
60 *EHTP7.9 EHT-MCS 8 with N SS = 2 36.1.1 EHTP7.8: O Yes  No  N/A 
61 *EHTP7.10 EHT-MCS 9 with N SS = 2 36.1.1 EHTP7.9: O Yes  No  N/A 
62
63 *EHTP7.11 EHT-MCS 10 with N SS = 2 36.1.1 EHTP7.10: O Yes  No  N/A 
64
65

772 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2 Item Protocol capability References Status Support
3
4 *EHTP7.12 EHT-MCS 11 with NSS = 2 36.1.1 EHTP7.11: O Yes  No  N/A 
5
6 *EHTP7.13 EHT-MCS 12 with N SS = 2 36.1.1 EHTP7.12: O Yes  No  N/A 
7 EHTP7.14 EHT-MCS 13 with N SS = 2 36.1.1 EHTP7.13: O Yes  No  N/A 
8
9 *EHTP7.15 EHT-MCS 0–7 with N SS = 3 36.1.1 EHTP7.8: O Yes  No  N/A 
10
11 *EHTP7.16 EHT-MCS 8 with N SS = 3 36.1.1 EHTP7.15: O Yes  No  N/A 
12
13 *EHTP7.17 EHT-MCS 9 with N SS = 3 36.1.1 EHTP7.16: O Yes  No  N/A 
14
15 *EHTP7.18 EHT-MCS 10 with N SS = 3 36.1.1 EHTP7.17: O Yes  No  N/A 
16 *EHTP7.19 EHT-MCS 11 with N SS = 3 36.1.1 EHTP7.18: O Yes  No  N/A 
17
18 *EHTP7.20 EHT-MCS 12 with N SS = 3 36.1.1 EHTP7.19: O Yes  No  N/A 
19
20 EHTP7.21 EHT-MCS 13 with N SS = 3 36.1.1 EHTP7.20: O Yes  No  N/A 
21
22 *EHTP7.22 EHT-MCS 0–7 with N SS = 4 36.1.1 EHTP7.15: O Yes  No  N/A 
23
24 *EHTP7.23 EHT-MCS 8 with N SS = 4 36.1.1 EHTP7.22: O Yes  No  N/A 
25 *EHTP7.24 EHT-MCS 9 with N SS = 4 36.1.1 EHTP7.23: O Yes  No  N/A 
26
27 *EHTP7.25 EHT-MCS 10 with N SS = 4 36.1.1 EHTP7.24: O Yes  No  N/A 
28
29 *EHTP7.26 EHT-MCS 11 with NSS = 4 36.1.1 EHTP7.25: O Yes  No  N/A 
30
31 *EHTP7.27 EHT-MCS 12 with N SS = 4 36.1.1 EHTP7.26: O Yes  No  N/A 
32
33 EHTP7.28 EHT-MCS 13 with N SS = 4 36.1.1 EHTP7.27: O Yes  No  N/A 
34 *EHTP7.29 EHT-MCS 0–7 with N SS = 5 36.1.1 EHTP7.22: O Yes  No  N/A 
35
36 *EHTP7.30 EHT-MCS 8 with N SS = 5 36.1.1 EHTP7.29: O Yes  No  N/A 
37
38 *EHTP7.31 EHT-MCS 9 with N SS = 5 36.1.1 EHTP7.30: O Yes  No  N/A 
39
40 *EHTP7.32 EHT-MCS 10 with N SS = 5 36.1.1 EHTP7.31: O Yes  No  N/A 
41
42 *EHTP7.33 EHT-MCS 11 with NSS = 5 36.1.1 EHTP7.32: O Yes  No  N/A 
43 *EHTP7.34 EHT-MCS 12 with N SS = 5 36.1.1 EHTP7.33: O Yes  No  N/A 
44
45 EHTP7.35 EHT-MCS 13 with N SS = 5 36.1.1 EHTP7.34: O Yes  No  N/A 
46
47 *EHTP7.36 EHT-MCS 0–7 with N SS = 6 36.1.1 EHTP7.29: O Yes  No  N/A 
48
49 *EHTP7.37 EHT-MCS 8 with N SS = 6 36.1.1 EHTP7.36: O Yes  No  N/A 
50
51 *EHTP7.38 EHT-MCS 9 with N SS = 6 36.1.1 EHTP7.37: O Yes  No  N/A 
52 *EHTP7.39 EHT-MCS 10 with N SS = 6 36.1.1 EHTP7.38: O Yes  No  N/A 
53
54 *EHTP7.40 EHT-MCS 11 with NSS = 6 36.1.1 EHTP7.39: O Yes  No  N/A 
55
56 *EHTP7.41 EHT-MCS 12 with N SS = 6 36.1.1 EHTP7.40: O Yes  No  N/A 
57
58 EHTP7.42 EHT-MCS 13 with N SS = 6 36.1.1 EHTP7.41: O Yes  No  N/A 
59
60 *EHTP7.43 EHT-MCS 0–7 with N SS = 7 36.1.1 EHTP7.36: O Yes  No  N/A 
61 *EHTP7.44 EHT-MCS 8 with N SS = 7 36.1.1 EHTP7.43: O Yes  No  N/A 
62
63 *EHTP7.45 EHT-MCS 9 with N SS = 7 36.1.1 EHTP7.44: O Yes  No  N/A 
64
65

Copyright © 2022 IEEE. All rights reserved. 773

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2 Item Protocol capability References Status Support
3
4 *EHTP7.46 EHT-MCS 10 with N SS = 7 36.1.1 EHTP7.45: O Yes  No  N/A 
5
6 *EHTP7.47 EHT-MCS 11 with NSS = 7 36.1.1 EHTP7.46: O Yes  No  N/A 
7 *EHTP7.48 EHT-MCS 12 with N SS = 7 36.1.1 EHTP7.47: O Yes  No  N/A 
8
9 EHTP7.49 EHT-MCS 13 with N SS = 7 36.1.1 EHTP7.48: O Yes  No  N/A 
10
11 *EHTP7.50 EHT-MCS 0–7 with N SS = 8 36.1.1 EHTP7.43: O Yes  No  N/A 
12
13 *EHTP7.51 EHT-MCS 8 with N SS = 8 36.1.1 EHTP7.50: O Yes  No  N/A 
14
15 *EHTP7.52 EHT-MCS 9 with N SS = 8 36.1.1 EHTP7.51: O Yes  No  N/A 
16 *EHTP7.53 EHT-MCS 10 with N SS = 8 36.1.1 EHTP7.52: O Yes  No  N/A 
17
18 *EHTP7.54 EHT-MCS 11 with NSS = 8 36.1.1 EHTP7.53: O Yes  No  N/A 
19
20 *EHTP7.55 EHT-MCS 12 with N SS = 8 36.1.1 EHTP7.54: O Yes  No  N/A 
21
22 EHTP7.56 EHT-MCS 13 with N SS = 8 36.1.1 EHTP7.55: O Yes  No  N/A 
23
24 EHTP7.57 (#5724)EHT-MCS 15 with N SS = 1 36.1.1 CFEHT20: M Yes  No  N/A 
25 and RU ≤ 242 tones, excluding
26 MRUs, in non-MU-MIMO
27 EHTP7.58 (#5724)EHT-MCS 15 with N SS = 1 36.1.1 CFEHT80: M Yes  No  N/A 
28 and RU ≤ 996 tones, excluding
29 MRUs, in non-MU-MIMO
30
31 EHTP7.59 (#5724)EHT-MCS 15 with N SS = 1 36.1.1 EHTP3.4: M Yes  No  N/A 
32 and RU ≤ 2996 tones, excluding
33 MRUs, in non-MU-MIMO
34
35 EHTP7.60 (#5724)EHT-MCS 15 with N SS = 1 36.1.1 EHTP3.5: M Yes  No  N/A 
36 and RU ≤ 4996 tones, excluding
37 MRUs, in non-MU-MIMO
38
39 EHTP7.61 EHT-MCS 15 with N SS = 1 and RU 36.1.1 CFEHT: O Yes  No  N/A 
40 52+26
41
42 EHTP7.62 EHT-MCS 15 with N SS = 1 and RU 36.1.1 CFEHT: O Yes  No  N/A 
43 106+26
44 EHTP7.63 EHT-MCS 15 with N SS = 1 and RU 36.1.1 CFEHT80: O Yes  No  N/A 
45 484+242
46
47 EHTP7.64 EHT-MCS 15 with N SS = 1 and RU 36.1.1 EHTP3.4: O Yes  No  N/A 
48 996+484
49
50 EHTP7.65 EHT-MCS 15 with N SS = 1 and RU 36.1.1 EHTP3.4: O Yes  No  N/A 
51 996+484+242
52
53 EHTP7.66 EHT-MCS 15 with N SS = 1 and RU 36.1.1 EHTP3.5: O Yes  No  N/A 
54 3996 tones
55
56 EHTP7.67 EHT-MCS 14 with N SS = 1 36.1.1 CFEHT6G: O Yes  No  N/A 
57 (#4558)*EH Supports transmission of four or more 36.1.1 CFEHT: O Yes  No  N/A 
58 TP7.68 spatial streams
59
60 (#4558)*EH Supports reception of four or more 36.1.1 CFEHT: O Yes  No  N/A 
61 TP7.69 spatial streams
62
63 EHTP8 Preamble
64
65

774 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2 Item Protocol capability References Status Support
3
4 EHTP8.1 Reception of the EHT-SIG field in an 36.1.1 CFEHT: M Yes  No  N/A 
5 EHT MU PPDU at EHT-MCSs 0, 1,
6 3, and 15
7
8 EHTP8.2 Transmission and reception of a non- 36.1.1 (#4563)CFEHT: Yes  No  N/A 
9 OFDMA EHT MU PPDU with any M
10 preamble puncturing pattern needed to
11 support mandatory MRU for non-
12 OFDMA
13 EHTP8.3 Transmission of an OFDMA EHT 36.1.1 CFEHT AND Yes  No  N/A 
14 MU PPDU with any preamble punc- CFAP: M
15 turing pattern needed to support man-
16 datory MRU for non-OFDMA
17
18 EHTP8.4 Transmission of an OFDMA EHT 36.1.1 CFEHT AND Yes  No  N/A 
19 MU PPDU with any preamble punc- CFAP: O
20 turing pattern as specified in sub-
21 clause 36.3.12.11 but excluding any
22 pattern needed to support mandatory
23 MRU for non-OFDMA
24
25 (#4563)EHT Reception of an OFDMA EHT MU 36.1.1 CFEHT AND Yes  No  N/A 
26 P8.5 PPDU with any preamble puncturing CFSTAofAP: M
27 pattern
28
29 EHTP9 Sounding
30
31 (#4564)EHT Non-triggered SU beamforming feed- 35.7.2 CFEHT: M Yes  No  N/A 
32 P9.1 back (full bandwidth only)
33 (#4564)EHT Non-triggered CQI feedback (full 35.7.2 CFEHT: O Yes  No  N/A 
34 P9.2 bandwidth only)
35
36 (#4564)EHT Triggered MU beamforming full 35.7.2 CFEHT: M Yes  No  N/A 
37 P9.3 bandwidth feedback
38
39 (#4564)EHT Triggered MU beamforming partial 35.7.2 EHTP2.8: M Yes  No  N/A 
40 P9.4 bandwidth feedback CFEHT AND
41 NOT EHTP2.8: O
42
43 (#4564)EHT Triggered SU beamforming feedback 35.7.2 CFEHT: O Yes  No  N/A 
44 P9.5 (full and partial bandwidth)
45
46 (#4564)EHT Triggered CQI feedback (full and par- 35.7.2 CFEHT: O Yes  No  N/A 
47 P9.6 tial bandwidth)
48 EHTP9.7 Responding with requested beam- 35.7.3 CFEHT AND Yes  No  N/A 
49 forming feedback in an EHT sounding CFSTAofAP: M
50 procedure with the maximum number
51 of (#6081)spatial streams in the EHT
52 sounding NDP that the non-AP EHT
53 STA can respond to equal to at least 4
54
55 EHTP9.8 EHT sounding PPDU with 2 EHT- 36.3.18 CFEHT: M Yes  No  N/A 
56 LTF and 0.8 µs GI
57
58 EHTP9.9 EHT sounding PPDU with 2 EHT- 36.3.18 CFEHT: M Yes  No  N/A 
59 LTF and 1.6 µs GI
60
61 EHTP9.10 EHT sounding PPDU with 4 EHT- 36.3.18 CFEHT: O Yes  No  N/A 
62 LTF and 3.2 µs GI
63
64 EHTP9.11 Ng = 4 SU feedback 9.4.1.70 CFEHT: M Yes  No  N/A 
65

Copyright © 2022 IEEE. All rights reserved. 775

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2 Item Protocol capability References Status Support
3
4 EHTP9.12 Ng = 4 MU feedback 9.4.1.70 CFEHT: M Yes  No  N/A 
5
6 EHTP9.13 Ng = 16 SU feedback 9.4.1.70 CFEHT: O Yes  No  N/A 
7 EHTP9.14 Ng = 16 MU feedback 9.4.1.70 CFEHT: O Yes  No  N/A 
8
9 EHTP9.15 Codebook size     =  6 4  SU 9.4.1.70 CFEHT: M Yes  No  N/A 
10 feedback
11
12 EHTP9.16 Codebook size     =  4 2  SU 9.4.1.70 CFEHT: O Yes  No  N/A 
13 feedback
14
15 EHTP9.17 Codebook size     =  9 7  MU 9.4.1.70 CFEHT: M Yes  No  N/A 
16 feedback
17
18 EHTP9.18 Codebook size     =  7 5  MU 9.4.1.70 CFEHT: O Yes  No  N/A 
19 feedback
20 EHTP9.19 Receiving and NDP with bandwidth (#4565)35. CFEHT20: O Yes  No  N/A 
21 of 40, 80 or 160 MHz 7.2
22
23 (#4566)EHT Reception of 160 MHz EHT sounding 36.1.1 CFEHT AND Yes  No  N/A 
24 P9.20 NDP in 5 GHz and 6 GHz bands if the CFSTAofAP: M
25 non-AP EHT STA’s operating channel
26 width is 80 MHz
27
28 (#4566)EHT Reception of 320 MHz EHT sounding 36.1.1 CFEHT AND Yes  No  N/A 
29 P9.21 NDP in 6 GHz band if the non-AP CFSTAofAP AND
30 EHT STA’s operating channel is CFEHT6G: M
31 80 MHz or 160 MHz
32
33 EHTP10 Transmit beamforming
34
35 *EHTP10.1 SU beamformer capable if the sup- 36.1.1 CFEHT: O Yes  No  N/A 
36 ported maximum number of transmit
37 spatial streams is less than 4
38 *EHTP10.2 SU beamformer capable if the sup- 36.1.1 CFEHT: M Yes  No  N/A 
39 ported maximum number of transmit
40 spatial streams is greater than or equal
41 to 4
42
43 EHTP10.3 SU beamformee capable 36.1.1 (#4567)CFEHT Yes  No  N/A 
44 AND CFAP: O
45 CFEHT AND
46 CFSTAofAP: M
47
48 EHTP10.4 MU beamformer capable if the sup- 36.1.1 CFAP AND Yes  No  N/A 
49 ported maximum number of transmit EHTP10.1: O
50 spatial streams is less than 4
51
52 EHTP10.5 MU beamformer capable if the sup- 36.1.1 CFAP AND Yes  No  N/A 
53 ported maximum number of transmit EHTP10.2: M
54 spatial streams is greater than or equal
55 to 4
56
57 EHTP10.6 MU beamformee capable 36.1.1 CFEHT AND Yes  No  N/A 
58 CFSTAofAP: M
59 EHTP11 Spatial reuse
60
61 EHTP11.1 (#5444)EHT PSR-based SR support 35.9 CFEHT AND Yes  No  N/A 
62 CFSTAofAP: O
63
64 EHTP12 Power boost factor 36.3.11.4 CFEHT: O Yes  No  N/A 
65

776 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 B.4.40.2 EHT MAC features(#6672)

2
3
4
5 Item Protocol capability References Status Support
6
7 Are the following MAC protocol
8 features supported?
9
10 EHTM1 EHT capabilities signaling
11
12 EHTM1.1 EHT Capabilities element 9.4.2.313 CFEHT: M Yes  No  N/A 
13
14 EHTM1.2 Signaling of EHT STA capabilities in 9.3.3.5, CFEHT AND Yes  No  N/A 
15 Probe Request and (Re)Association 9.3.3.7, CFIndepSTA:M
16 Request frames 9.3.3.9,
17 9.4.2.313
18 EHTM1.3 Signaling of EHT STA capabilities 9.3.3.2, CFEHT AND Yes  No  N/A 
19 and EHT BSS capabilities in Beacon, 9.3.3.6, CFAP: M
20 Probe Response, and (Re)Association 9.3.3.8,
21 Response frames 9.3.3.10,
22 9.4.2.313
23
24 EHTM1.4 Signaling of MLD capabilities using 9.3.3.2, CFEHTMLD: M Yes  No  N/A 
25 MLD Capabilities subfield present in 9.3.3.5,
26 the Common Info field of the Basic 9.3.3.6,
27 Multi-Link element 9.3.3.7,
28 9.3.3.8,
29 9.3.3.10
30
31 EHTM2 Signaling of EHT operation 9.4.2.311 CFEHT AND Yes  No  N/A 
32 CFAP: M
33
34 EHTM3 HE variant HT Control field
35
36 EHTM3.1 EHT OM control 9.2.4.7.8 CFAP AND Yes  No  N/A 
37 EHTP3.5: M
38 CFEHT: O
39 EHTM3.2 SRS control 9.2.4.7.9 CFEHTMLD: O Yes  No  N/A 
40
41 EHTM3.3 AAR control 9.2.4.7.10 CFEHTMLD: O Yes  No  N/A 
42
43 EHTM4 Restricted TWT 35.9 CFEHT: O Yes  No  N/A 
44
45 *EHTM5 EPCS priority access 35.17 CFEHT: O Yes  No  N/A 
46
47 EHTM6 Triggered TXOP sharing procedure 35.2.1.2 CFEHT: O Yes  No  N/A 
48 EHTM7 EHT BSS operation
49
50 EHTM7.1 EHT BSS 6 GHz operation 35.16.1 CFEHT6G: M Yes  No  N/A 
51
52 EHTM7.2 Preamble puncturing operation 35.16.2 CFEHT AND Yes  No  N/A 
53 CFAP: M
54 CFEHT AND
55 CFSTAofAP: M
56
57 EHTM8 MU Beamforming capable
58
59 *EHTM8.1 MU beamformer capable if the MU 35.7.1 CFEHT AND Yes  No  N/A 
60 Beamformer (BW ≤ 80 MHz), MU CFAP: M
61 Beamformer (BW = 160 MHz), and
62 MU Beamformer (BW = 320 MHz),
63 any is at least set to 1
64
65

Copyright © 2022 IEEE. All rights reserved. 777

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2 Item Protocol capability References Status Support
3
4 *EHTM8.2 MU beamformer capable if the MU 35.7.1 CFEHT AND Yes  No  N/A 
5 Beamformer (BW ≤ 80 MHz), MU CFSTAofAP: M
6 Beamformer (BW = 160 MHz), and
7 MU Beamformer (BW = 320 MHz),
8 is 0
9
10 EHTM9 EHT MLD features
11 EHTM9.1 Multi-link discovery procedures 35.3.4 CFEHTMLD: M Yes  No  N/A 
12
13 EHTM9.2 Multi-link (re)setup procedure 35.3.5 CFEHTMLD: M Yes  No  N/A 
14
15 EHTM9.3 Block ack procedures in multi-link 35.3.8 CFEHTMLD: M Yes  No  N/A 
16 operation
17
18 EHTM9.4 Link management procedure with 35.3.7 CFEHTMLD: M Yes  No  N/A 
19 default TID-to-link mapping
20
21 EHTM9.5 Multi-link sequence number spaces 35.3.8 CFEHTMLD: M Yes  No  N/A 
22 EHTM9.6 BSS parameter critical update proce- 35.3.10 CFEHTMLD: M Yes  No  N/A 
23 dure
24
25 EHTM9.7 Multi-link power management 35.3.12 CFEHTMLD: M Yes  No  N/A 
26
27 EHTM9.7.1 Dynamic link transitions 35.3.7.2 CFEHTMLDAP: Yes  No  N/A 
28 M
29 CFEHTMLD-
30 nonAP: O
31 CFEHTMLDN-
32 STRmobileAP: M
33
34 EHTM9.7.2 MLD max idle period management 35.3.12.3 CFEHTMLD: M Yes  No  N/A 
35
36 EHTM9.7.3 WNM sleep mode in multi-link opera- 35.3.12.5 CFEHTMLD- Yes  No  N/A 
37 tion nonAP: O
38 *EHTM9.8 NSTR operation 35.3.16.4 CFEHTMLDN- Yes  No  N/A 
39 STRmobileAP:M
40 CFEHTMLD-
41 nonAP: O
42
43 EHTM9.8.1 PPDU end time alignment 35.3.16.5 EHTM9.8: M Yes  No  N/A 
44 CFEHTM-
45 LDAP:M
46
47 EHTM9.8.2 Start time sync PPDUs medium 35.3.16.6 EHTM9.8: O Yes  No  N/A 
48 access
49
50 EHTM9.8.3 Medium access recovery procedure 35.3.16.8 EHTM9.8: M Yes  No  N/A 
51 EHTM9.10: M
52 EHTM9.11: M
53
54 EHTM9.9 Multi-link group addressed frame 35.3.15 CFEHTMLD: M Yes  No  N/A 
55 delivery
56 *EHTM9.10 EMLSR mode 35.3.17 CFEHTMLD: O Yes  No  N/A 
57
58 EHTM9.10.1 EMLSR configuration 35.3.17 EHTM9.10: M Yes  No  N/A 
59
60 *EHTM9.11 EMLMR mode 35.3.18 CFEHTMLD: O Yes  No  N/A 
61
62
63
64
65

778 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2 Item Protocol capability References Status Support
3
4 EHTM9.12 STR operation 35.3.16.3 CFEHTMLDAP: Yes  No  N/A 
5 M
6 CFEHTMLD-
7 nonAP: O
8
9 EHTM9.13 NSTR mobile AP MLD operation 35.3.19 CFEHTNSTRMo- Yes  No  N/A 
10 bileAP: M
11 *EHTM9.14 TID-to-link mapping 35.3.7.1 CFEHTMLD: O Yes  No  N/A 
12
13 EHTM9.15 TDLS procedure in multi-link opera- 35.3.21 CFEHTMLD- Yes  No  N/A 
14 tion nonAP: O
15
16 EHTM9.16 Multi-link SCS procedure 35.3.22 CFEHTMLD: O Yes  No  N/A 
17
18 EHTM9.17 Proxy ARP service in AP MLDs 35.3.24 CFEHTMLDAP: Yes  No  N/A 
19 O
20 CFEHTNSTRMo-
21 bileAP: O
22
23 EHTM9.18 Multi-link MSCS procedure 35.3.23 CFEHTMLD: O Yes  No  N/A 
24 EHTM9.19 Multi-link procedures for channel 35.3.11 CFEHTMLDAP: Yes  No  N/A 
25 switching, extended channel switch- M
26 ing, and channel quieting CFEHTNSTRMo-
27 bileAP: O
28 CFEHTMLD-
29 nonAP: M
30
31 EHTM10 EHT sounding protocol
32
33 EHTM10.1 EHT sounding protocol as MU beam- 35.7 EHTM8.1: M Yes  No  N/A 
34 former
35
36 EHTM10.2 EHT sounding protocol as MU 35.7 EHTM8.2: M Yes  No  N/A 
37 beamformee
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 779

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

780 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2
Annex C
3
4 (normative)
5
6
7
8
ASN.1 encoding of the MAC and PHY MIB
9
10
11 C.3 MIB Detail
12
13
14 Change the comment list following the dot11smt definition as follows (not all lines shown):
15
16 -- **********************************************************************
17 -- * Major sections
18 -- **********************************************************************
19
20 -- Station ManagemenT (SMT) Attributes
21 -- DEFINED AS "The SMT object class provides the necessary support
22 -- at the station to manage the processes in the station such that
23 -- the station may work cooperatively as a part of an IEEE 802.11
24 -- network."
25
26 dot11smt OBJECT IDENTIFIER ::= { ieee802dot11 1 }(#1004)(#2246)
27 -- dot11smt GROUPS
28 -- ...
29 -- dot11GLKLinkMetricsTable ::= ( dot11smt 41 )
30 -- dot11EHTStationConfigTable ::= ( dot11smt 46 )
31 -- dot11EHTPPEThresholdsMappingsTable ::= ( dot11smt 47 )
32
33 Change the comment list following PHY GROUPS as follows (not all lines shown):
34
35 -- PHY Attributes
36 -- DEFINED AS "The PHY object class provides the necessary support
37
-- for required PHY operational information that may vary from PHY
38
-- to PHY and from STA to STA to be communicated to upper layers."
39
dot11phy OBJECT IDENTIFIER ::= { ieee802dot11 4 }
40
41
-- PHY GROUPS
42
-- dot11PhyOperationTable ::= { dot11phy 1 }
43
-- ...
44
-- dot11PhyEHTTable ::= { dot11phy 35 }
45
-- dot11EHTTransmitBeamformingConfigTable ::= { dot11phy 36 }
46
47
48 Change Dot11StationConfigEntry as follows (not all lines shown):
49
50 -- **********************************************************************
51 -- * dot11StationConfig TABLE
52 -- **********************************************************************
53
54 Dot11StationConfigEntry ::= SEQUENCE
55 {
56 dot11StationID MacAddress,
57 …
58 dot11BSSMaxIdlePeriodIndicationByNonAPSTA, TruthValue,
59 (#1004)(#2246)dot11EHTOptionImplemented, TruthValue,
60 (#3173)dot11EHTBaseLineFeaturesImplementedOnly, TruthValue,
61 (#4171)(#4183)dot11EHTTXOPSharingTFOptionImplemented TruthValue,
62 (#4206)dot11EHTNSTRMobileAPMLDImplemented TruthValue
63 }
64
65

Copyright © 2022 IEEE. All rights reserved. 781

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Insert the following after the dot11BSSMaxIdlePeriodIndicationByNonAPSTA OBJECT-TYPE

2 in the dot11StationConfig TABLE:
3
4 dot11EHTOptionImplemented OBJECT-TYPE(#1004)(#2246)
5 SYNTAX TruthValue
6 MAX-ACCESS read-only
7 STATUS current
8
DESCRIPTION
9
"This is a capability variable.
10
Its value is determined by device capabilities.
11
12
This attribute indicates whether the entity is EHT capable."
13
::= { dot11StationConfigEntry 205 }
14
15
dot11EHTBaseLineFeaturesImplementedOnly OBJECT-TYPE(#3173)
16
SYNTAX TruthValue
17
MAX-ACCESS read-only
18
19 STATUS current
20 DESCRIPTION
21 "This is a capability variable.
22 Its value is determined by device capabilities.
23
24 This attribute, when true, indicates that the EHT station has not imple-
25 mented any (#6118)EHT features which cannot be indicated in the EHT Capa-
26 bilities element."
27 ::= { dot11StationConfigEntry 206 }
28
29 (#3173)NOTE—Some (#6118)EHT features may be indicated in an element other than
30 the EHT Capabilities element.
31
32
33
(#4183)dot11EHTTXOPSharingTFOptionImplemented OBJECT-TYPE
34
SYNTAX TruthValue
35
MAX-ACCESS read-only
36
STATUS current
37
DESCRIPTION
38
"This is a capability variable.
39
Its value is determined by device capabilities.
40
41
This attribute, when true, indicates the ability of the EHT STA to support
42
the triggered TXOP sharing procedure. If the attribute is false, the sta-
43
tion does not support the triggered TXOP sharing procedure."
44
::= { dot11StationConfigEntry <Last assigned + 1> }
45
46
47 (#4206)dot11EHTNSTRMobileAPMLDImplemented OBJECT-TYPE
48 SYNTAX TruthValue
49 MAX-ACCESS read-only
50 STATUS current
51 DESCRIPTION
52 "This is a capability variable.
53 Its value is determined by device capabilities.
54
55 This attribute, when true, indicates the ability of the EHT STA to support
56 NSTR mobile AP multi-link operation. If the attribute is false, the sta-
57 tion does not support NSTR mobile AP multi-link operation."
58 ::= { dot11StationConfigEntry <Last assigned + 1> }
59
60 Change dot11WNMSleepModeImplemented as follows:
61
62 dot11WNMSleepModeImplemented OBJECT-TYPE
63 SYNTAX TruthValue
64 MAX-ACCESS read-only
65 STATUS current

782 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 DESCRIPTION
2 "This is a capability variable.
3 Its value is determined by device capabilities.
4
5 This attribute, when true, indicates that the station or non-AP MLD
6 implementation is capable of supporting WNM sleep mode when
7 dot11WirelessManagementImplemented is equal to true."
8 ::= { dot11WirelessMgmtOptionsEntry 10 }
9
10 Insert the following after the dot11STACivicLocationConfig TABLE:
11
12 -- **********************************************************************
13 -- * dot11EHTStationConfig TABLE
14 -- **********************************************************************
15
16 dot11EHTStationConfigTable OBJECT-TYPE
17 SYNTAX SEQUENCE OF Dot11HEStationConfigEntry
18 MAX-ACCESS not-accessible
19 STATUS current
20 DESCRIPTION
21 "Station Configuration attributes. In tabular form to allow for multiple
22 instances on an agent."
23 ::= { dot11smt 46 }
24
25 dot11EHTStationConfigEntry OBJECT-TYPE
26 SYNTAX Dot11HEStationConfigEntry
27 MAX-ACCESS not-accessible
28 STATUS current
29
DESCRIPTION
30
"An entry (conceptual row) in the dot11HEStationConfig Table.
31
32
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Inter-
33
face tables in this MIB module are indexed by ifIndex."
34
INDEX { ifIndex }
35
::= { dot11EHTStationConfigTable 1 }
36
37
38 Dot11EHTStationConfigEntry ::=
39 SEQUENCE {
40 dot11EHTPPEThresholdsRequired TruthValue,
41 dot11TIDtoLinkMappingActivated TruthValue,
42 (#5855)(#5284)dot11EHTEPCSPriorityAccessActivated TruthValue}
43
44 dot11EHTPPEThresholdsRequired OBJECT-TYPE
45 SYNTAX TruthValue
46 MAX-ACCESS read-only
47 STATUS current
48 DESCRIPTION
49 "This is a capability variable.
50 Its value is determined by device capabilities.
51
52 This attribute, when true, indicates that PPE thresholds exist and are
53 provided in dot11EHTPPEThresholdsTable."
54 DEFVAL { false }
55 ::= { dot11EHTStationConfigEntry 1 }
56
57 dot11TIDtoLinkMappingActivated OBJECT-TYPE
58 SYNTAX TruthValue
59 MAX-ACCESS read-write
60 STATUS current
61 DESCRIPTION
62 "This is a control variable.
63 It is written by an external management entity or the SME. Changes take
64 effect as soon as practical in the implementation.
65

Copyright © 2022 IEEE. All rights reserved. 783

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 This attribute, when true, indicates that TID-to-link mapping negotiation

2 is enabled. TID-to-link mapping negotiation is disabled otherwise."
3 DEFVAL { false }
4 ::= { dot11EHTStationConfigEntry 2 }
5
6 (#5855)(#5284)dot11EHTEPCSPriorityAccessActivated OBJECT-TYPE
7 SYNTAX TruthValue
8 MAX-ACCESS read-write(#6117)
9 STATUS current
10 DESCRIPTION
11 "This is a control variable.
12 It is written by an external management entity or the SME. Changes take
13 effect as soon as practical in the implementation.
14
15 This attribute, when true, indicates the ability of the MLD to support the
16 EPCS priority access capability. If the attribute is false, the MLD does
17 not support EPCS priority access capability."
18 DEFVAL { false }
19 ::= { dot11EHTStationConfigEntry 3 }
20
21 -- **********************************************************************
22 -- * End of dot11EHTStationConfig TABLE
23 -- **********************************************************************
24
25 -- **********************************************************************
26 -- * dot11EHTPPEThresholdsTable TABLE
27 -- **********************************************************************
28
29 dot11EHTPPEThresholdsMappingsTable OBJECT-TYPE
30 SYNTAX SEQUENCE OF Dot11EHTPPEThresholdsMappingsEntry
31
MAX-ACCESS not-accessible
32
STATUS current
33
DESCRIPTION
34
"(#7736)A conceptual table for EHT PPE thresholds mappings, which deter-
35
mines the nominal packet padding value as a function of the two PPE
36
thresholds, PPET8 and PPETmax, for an EHT PPDU of a particular RU alloca-
37
tion size and NSS value. The MIB supports the ability to share separate
38
PPE thresholds for each NSS/RU pair. The thresholds mappings table con-
39
tains one entry for each NSS/RU pair and contains two fields for each
40
entry: PPET8 and PPETmax."
41
REFERENCE "IEEE Std 802.11-<year>, 35.14 (Nominal packet padding values
42
selection rules)"
43
::= { dot11smt 47 }
44
45
46 dot11EHTPPEThresholdsMappingsEntry OBJECT-TYPE
47 SYNTAX Dot11EHTPPEThresholdsMappingsEntry
48 MAX-ACCESS not-accessible
49 STATUS current
50 DESCRIPTION
51 "An Entry (conceptual row) in the EHT PPE Thresholds Mappings Table.
52
53 ifIndex - Each IEEE Std 802.11 interface is represented by an ifEntry.
54 Interface tables in this MIB module are indexed by ifIndex."
55 INDEX { ifIndex, dot11EHTPPEThresholdsMappingIndex }
56 ::= { dot11EHTPPEThresholdsMappingsTable 1 }
57
58 Dot11EHTPPEThresholdsMappingsEntry ::=
59 SEQUENCE {
60 dot11EHTPPEThresholdsMappingIndex Unsigned32,
61 dot11EHTPPEThresholdsMappingNSS Unsigned32,
62 dot11EHTPPEThresholdsMappingRUIndex Unsigned32,
63 dot11EHTPPEThresholdsMappingPPET8 INTEGER,
64 dot11EHTPPEThresholdsMappingPPETmax(#7736) INTEGER,
65 dot11EHTPPEThresholdsMappingStatus RowStatus

784 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 }
2
3 dot11EHTPPEThresholdsMappingIndex OBJECT-TYPE
4 SYNTAX Unsigned32
5 MAX-ACCESS not-accessible
6 STATUS current
7 DESCRIPTION
8 "The auxiliary variable used to identify instances of the columnar objects
9 in the EHT PPE Thresholds Mappings Table."
10 ::= { dot11EHTPPEThresholdsMappingsEntry 1 }
11
12 dot11EHTPPEThresholdsMappingNSS OBJECT-TYPE
13 SYNTAX Unsigned32
14 MAX-ACCESS read-create
15 STATUS current
16 DESCRIPTION
17 "The NSS value portion of the NSS/RU pair for which the values from this
18 Thresholds mapping entry are to be used."
19 ::= { dot11EHTPPEThresholdsMappingsEntry 2 }
20
21 dot11EHTPPEThresholdsMappingRUIndex OBJECT-TYPE
22 SYNTAX Unsigned32
23 MAX-ACCESS read-create
24 STATUS current
25 DESCRIPTION
26 "The index of the RU value portion of the NSS/RU pair for which the values
27 from this thresholds mapping entry are to be used. The index values map to
28 an RU as follows: RU Index of 0 is 242 tones, 1 is 484 tones, 2 is 484+242/
29 996 tones, 3 is 996+484/996+484+242/2x996 tones, 4 is 2x996+484/3x996/
30 3x996+484/4x996."
31 ::= { dot11EHTPPEThresholdsMappingsEntry 3 }
32
33
dot11EHTPPEThresholdsMappingPPET8 OBJECT-TYPE
34
SYNTAX INTEGER{BPSK(0), QPSK(1), 16-QAM(2), 64-QAM(3), 256-QAM(4), 1024-
35
QAM(5), 4096-QAM(6), NONE(7)}
36
MAX-ACCESS read-create
37
STATUS current
38
DESCRIPTION
39
40 "An index that determines a constellation value at or above which a nomi-
41 nal packet padding value of at least 8 microseconds is required for the
42 given NSS/RU pair corresponding to the row of the entry."
43 ::= { dot11EHTPPEThresholdsMappingsEntry 4 }
44
45 (#7736)dot11EHTPPEThresholdsMappingPPETmax OBJECT-TYPE
46 SYNTAX INTEGER{BPSK(0), QPSK(1), 16-QAM(2), 64-QAM(3), 256-QAM(4), 1024-
47 QAM(5), 4096-QAM(6), NONE(7)}
48 MAX-ACCESS read-create
49 STATUS current
50 DESCRIPTION
51 "An index that determines a constellation value at or above which a nomi-
52 nal packet padding value of 16 microseconds or 20 microseconds is required
53 for the given NSS/RU pair corresponding to the row of the entry."
54 ::= { dot11EHTPPEThresholdsMappingsEntry 5 }
55
56 dot11EHTPPEThresholdsMappingStatus OBJECT-TYPE
57 SYNTAX RowStatus
58 MAX-ACCESS read-create
59 STATUS current
60 DESCRIPTION
61 "The status column used for creating, modifying, and deleting instances of
62 the columnar objects in the EHT PPE thresholds mapping table."
63 DEFVAL { active }
64 ::= { dot11EHTPPEThresholdsMappingsEntry 6 }
65

Copyright © 2022 IEEE. All rights reserved. 785

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 -- **********************************************************************
2 -- * End of dot11EHTPPEThresholdsTable TABLE
3 -- **********************************************************************
4
5 Change dot11PHYType as follows:
6
7 dot11PHYType OBJECT-TYPE
8 SYNTAX INTEGER {
9 fhss(1),
10 dsss(2),
11 irbaseband(3),
12 ofdm(4),
13 hrdsss(5),
14 erp(6),
15 ht(7)
16 dmg(8),
17 vht(9),
18 tvht(10),
19 s1g(11),
20 cdmg(12),
21 cmmg(13),
22 he (14),
23 edmg (15),
24 eht (<Last assigned + 1>)}
25 MAX-ACCESS read-only
26 STATUS current
27 DESCRIPTION
28 "This is a status variable.
29 It is written by the PHY.
30
31 This is an 8-bit integer value that identifies the PHY type supported by
32
the attached PLCP and PMD. Currently defined values and their correspond-
33
ing
34
35
PHY types are:
36
FHSS 2.4 GHz = 01, DSSS 2.4 GHz = 02, IR Baseband = 03,
37
OFDM = 04, HRDSSS = 05, ERP = 06, HT = 07, DMG = 08, VHT = 09,
38
TVHT = 10, S1G = 11, CDMG = 12, CMMG = 13, HE = 14, EDMG = 15,
39
EHT = <Last assigned + 1>."
40
::= { dot11PhyOperationEntry 1 }
41
42
43 Insert the following after the dot11 PHY CMMG Table:
44
45 -- **********************************************************************
46 -- * dot11 Phy EHT TABLE
47 -- **********************************************************************
48
49 dot11PhyEHTTable OBJECT-TYPE
50 SYNTAX SEQUENCE OF Dot11PhyEHTEntry
51 MAX-ACCESS not-accessible
52 STATUS current
53 DESCRIPTION
54 "Entry of attributes for Dot11PhyEHTTable. Implemented as a table indexed
55 on ifIndex to allow for multiple instances on an Agent."
56 ::= { dot11phy 35 }
57
58 dot11PhyEHTEntry OBJECT-TYPE
59 SYNTAX Dot11PhyEHTEntry
60 MAX-ACCESS not-accessible
61 STATUS current
62 DESCRIPTION
63 "An entry in dot11PhyEHTEntryTable. ifIndex - Each IEEE Std 802.11
64 interface is represented by an ifEntry. Interface tables in this MIB
65 module are indexed by ifIndex."

786 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 INDEX {ifIndex}
2 ::= { dot11PhyEHTTable 1 }
3
4 Dot11PhyEHTEntry ::=
5 SEQUENCE {
6 dot11EHTCurrentChannelWidth INTEGER,
7 dot11EHTSupportFor320MHzImplemented TruthValue,
8 dot11EHTNonOFDMAULMUMIMOLessThanOrEqualto80Implemented TruthValue,
9 dot11EHTNonOFDMAULMUMIMOEqualto160Implemented TruthValue,
10 dot11EHTNonOFDMAULMUMIMOEqualto320Implemented TruthValue,
11 dot11EHTPartialBWULMUMIMOImplemented TruthValue,
12 dot11EHTMUPPDUwith4xEHTLTFand0point8usecGIImplemented TruthValue,
13 dot11EHTPSRBasedSRImplemented TruthValue,
14 dot11EHTPowerBoostFactorImplemented TruthValue,
15 dot11EHTTx1024QAMand4096QAMLessThan242ToneRUImplemented TruthValue,
16 dot11EHTRx1024QAMand4096QAMLessThan242ToneRUImplemented TruthValue,
17 dot11EHTExtraLTFsImplemented TruthValue,
18 dot11EHTMaxNumberOfSupportedEHTLTFsForSU INTEGER,
19 dot11EHTMaxNumberOfSupportedEHTLTFsForMUandNDP INTEGER,
20 dot11EHTMCS15For52p26and106p26MRUImplemented TruthValue,
21 dot11EHTMCS15For484p242MRUImplemented TruthValue,
22 dot11EHTMCS15For996p484and996p484p242MRUImplemented TruthValue,
23 dot11EHTMCS15For3x996MRUImplemented TruthValue,
24 dot11EHTDupImplemented TruthValue,
25 dot11EHTSupportFor242ToneRUInBWWiderThan20Implemented TruthValue,
26 dot11EHT20MHzOperatingSTARxNDPwithWiderBWImplemented TruthValue,
27 (#7574)dot11MSOFDMEDthreshold Unsigned32,
28 (#4624)dot11EHTCurrentChannelCenterFrequencyIndex0 Unsigned32,
29 (#4627)dot11EHTSupportedEhtMcsAndNssSet20MhzOnlyStaImplemented
30 OCTET STRING,
31 (#4624)dot11EHTSupportedEhtMcsAndNssSet20MhzOnlyActivated OCTET STRING,
32
(#4624)dot11EHTSupportedEhtMcsAndNssSetImplemented OCTET STRING,
33
(#4624)dot11EHTSupportedEhtMcsAndNssSetActivated OCTET STRING,
34
(#4624)dot11EHTDisabledSubchannelBitmap Unsigned32
35
}
36
37
(#4624)dot11EHTCurrentChannelWidth OBJECT-TYPE
38
39 SYNTAX INTEGER { cbw20(0), cbw40(1), cbw80(2), cbw160(3), cbw320(4) }
40 MAX-ACCESS read-only
41 STATUS current
42 DESCRIPTION
43 "This is a status variable.
44 It is written by the PHY.
45
46 This attribute specifies the operating channel width for EHT."
47 DEFVAL { 0 }
48 ::= { dot11PhyEHTEntry 1 }
49
50 dot11EHTSupportFor320MHzImplemented OBJECT-TYPE
51 SYNTAX TruthValue
52 MAX-ACCESS read-only
53 STATUS current
54 DESCRIPTION
55 "This is a capability variable.
56 Its value is determined by device capabilities.
57
58 This attribute, when true, indicates that the STA is capable of transmit-
59 ting and receiving 320 MHz PPDUs when operating in the 6 GHz frequency
60 band.
61 This capability is disabled otherwise."
62 DEFVAL { false }
63 ::= { dot11PhyEHTEntry 2 }
64
65

Copyright © 2022 IEEE. All rights reserved. 787

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 dot11EHTNonOFDMAULMUMIMOLessThanOrEqualto80Implemented OBJECT-TYPE
2 SYNTAX TruthValue
3 MAX-ACCESS read-only
4 STATUS current
5 DESCRIPTION
6 "This is a capability variable.
7 Its value is determined by device capabilities.
8
9 (#4627)In an AP, this attribute, when true, indicates that the AP is capa-
10 ble of receiving non-OFDMA UL MU-MIMO in an EHT TB PPDU of bandwidth equal
11 to any one of 20, 40 or 80 MHz.
12 (#4627)Reserved for a non-AP STA.
13 This capability is disabled otherwise."
14 DEFVAL { false }
15 ::= { dot11PhyEHTEntry 3 }
16
17 dot11EHTNonOFDMAULMUMIMOEqualto160Implemented OBJECT-TYPE
18 SYNTAX TruthValue
19 MAX-ACCESS read-only
20 STATUS current
21 DESCRIPTION
22 "This is a capability variable.
23 Its value is determined by device capabilities.
24
25 (#4627)In an AP, this attribute, when true, indicates that the AP is capa-
26 ble of receiving non-OFDMA UL MU-MIMO in an EHT TB PPDU of bandwidth 160
27 MHz.
28 (#4627)Reserved for a non-AP STA.
29 This capability is disabled otherwise."
30 DEFVAL { false }
31
::= { dot11PhyEHTEntry 4 }
32
33
dot11EHTNonOFDMAULMUMIMOEqualto320Implemented OBJECT-TYPE
34
SYNTAX TruthValue
35
MAX-ACCESS read-only
36
37 STATUS current
38 DESCRIPTION
39 "This is a capability variable.
40 Its value is determined by device capabilities.
41
42 (#4627)In an AP, this attribute, when true, indicates that the AP is capa-
43 ble of receiving non-OFDMA UL MU-MIMO in an EHT TB PPDU of bandwidth 320
44 MHz.
45 (#4627)Reserved for a non-AP STA.
46 This capability is disabled otherwise."
47 DEFVAL { false }
48 ::= { dot11PhyEHTEntry 5 }
49
50 dot11EHTPartialBWULMUMIMOImplemented OBJECT-TYPE
51 SYNTAX TruthValue
52 MAX-ACCESS read-only
53 STATUS current
54 DESCRIPTION
55 "This is a capability variable.
56 Its value is determined by device capabilities.
57
58 This attribute, when true for an AP implementation, indicates that the AP
59 is capable of receiving EHT TB PPDUs in which MU-MIMO is employed in an
60 RU/MRU, and that RU/MRU does not span the entire nonpunctured portion of
61 the PPDU bandwidth.
62 This attribute, when true for a non-AP STA implementation, indicates that
63 the non-AP STA is capable of transmitting an EHT TB PPDU in which MU-MIMO
64 is employed in the RU/MRU assigned to the non-AP STA, and that RU/MRU does
65 not span the entire nonpunctured portion of the PPDU bandwidth.

788 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 This capability is disabled otherwise."

2 DEFVAL { false }
3 ::= { dot11PhyEHTEntry 6 }
4
5 dot11EHTMUPPDUwith4xEHTLTFand0point8usecGIImplemented OBJECT-TYPE
6 SYNTAX TruthValue
7 MAX-ACCESS read-only
8 STATUS current
9 DESCRIPTION
10 "This is a capability variable.
11 Its value is determined by device capabilities.
12
13 This attribute, when true, indicates that the STA is capable of receiving
14 EHT MU PPDUs using 4x EHT-LTF and 0.8 microseconds guard interval dura-
15 tion.
16 This capability is disabled otherwise."
17 DEFVAL { false }
18 ::= { dot11PhyEHTEntry 7 }
19
20 dot11EHTPSRBasedSRImplemented OBJECT-TYPE
21 SYNTAX TruthValue
22 MAX-ACCESS read-only
23 STATUS current
24 DESCRIPTION
25 "This is a capability variable.
26 Its value is determined by device capabilities.
27
28 This attribute, when true, indicates that the STA is capable of supporting
29 the (#5444)EHT PSR-based SR operation.
30
This capability is disabled otherwise."
31
DEFVAL { false }
32
::= { dot11PhyEHTEntry 8 }
33
34
dot11EHTPowerBoostFactorImplemented OBJECT-TYPE
35
SYNTAX TruthValue
36
37 MAX-ACCESS read-only
38 STATUS current
39 DESCRIPTION
40 "This is a capability variable.
41 Its value is determined by device capabilities.
42
43 This attribute, when true, indicates that the non-AP STA is capable of
44 receiving EHT MU PPDUs with RUs having a power boost factor in the range
45 [0.5, 2].
46 This capability is disabled otherwise, in which case the non-AP STA is
47 capable of receiving EHT MU PPDUs with RUs having a power boost factor in
48 the range [1/sqrt(2), sqrt(2)]."
49 DEFVAL { false }
50 ::= { dot11PhyEHTEntry 9 }
51
52 dot11EHTTx1024QAMand4096QAMLessThan242ToneRUImplemented OBJECT-TYPE
53 SYNTAX TruthValue
54 MAX-ACCESS read-only
55 STATUS current
56 DESCRIPTION
57 "This is a capability variable.
58 Its value is determined by device capabilities.
59
60 (#4627)In a non-AP STA, this attribute, when true, indicates that the sup-
61 port for transmitting EHT TB PPDUs using 1024-QAM and 4096-QAM in a 26,
62 52, and 106-tone RU as well as 52+26 and 106+26-tone MRU by the non-AP STA
63 is the same as indicated in the Tx EHT-MCS Map (≤ 80 MHz) subfield in the
64 EHT PHY Capabilities Information field in the EHT Capabilities element.
65 This capability is disabled otherwise, in which case the non-AP STA does

Copyright © 2022 IEEE. All rights reserved. 789

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 not support transmitting EHT TB PPDUs using 1024-QAM and 4096-QAM in a 26,
2 52, and 106-tone RU as well as 52+26 and 106+26-tone MRU regardless of the
3 indication in the Tx EHT-MCS Map (≤ 80 MHz) subfield in the EHT PHY Capa-
4 bilities Information field in the EHT Capabilities element.
5 (#4627)Reserved for an AP."
6 DEFVAL { false }
7 ::= { dot11PhyEHTEntry 10 }
8
9 dot11EHTRx1024QAMand4096QAMLessThan242ToneRUImplemented OBJECT-TYPE
10 SYNTAX TruthValue
11 MAX-ACCESS read-only
12 STATUS current
13 DESCRIPTION
14 "This is a capability variable.
15 Its value is determined by device capabilities.
16
17 This attribute, when true, indicates that the support for receiving EHT MU
18 PPDUs using 1024-QAM and 4096-QAM in a 26, 52, and 106-tone RU as well as
19 52+26 and 106+26-tone MRU by the non-AP STA is the same as indicated in
20 the Rx EHT-MCS Map (≤ 80 MHz) subfield in the EHT PHY Capabilities Infor-
21 mation field in the EHT Capabilities element.
22 This capability is disabled otherwise, in which case the non-AP STA does
23 not support receiving EHT MU PPDUs using 1024-QAM and 4096-QAM in a 26,
24 52, and 106-tone RU as well as 52+26 and 106+26-tone MRU regardless of the
25 indication in the Rx EHT-MCS Map (≤ 80 MHz) subfield in the EHT PHY Capa-
26 bilities Information field in the EHT Capabilities element."
27 DEFVAL { false }
28 ::= { dot11PhyEHTEntry 11 }
29
30 dot11EHTExtraLTFsImplemented OBJECT-TYPE
31 SYNTAX TruthValue
32 MAX-ACCESS read-only
33 STATUS current
34 DESCRIPTION
35 "This is a capability variable.
36 Its value is determined by device capabilities.
37
38
This attribute, when true, indicates that the STA is capable of receiving
39
EHT non-OFDMA transmissions using extra EHT-LTF symbols.
40
This capability is disabled otherwise."
41
DEFVAL { false }
42
::= { dot11PhyEHTEntry 12 }
43
44
45 dot11EHTMaxNumberOfSupportedEHTLTFsForSU OBJECT-TYPE
46 SYNTAX INTEGER { 4(0), 8(1) }
47 MAX-ACCESS read-only
48 STATUS current
49 DESCRIPTION
50 "This is a capability variable.
51 Its value is determined by device capabilities.
52
53 This attribute indicates the maximum number of EHT-LTF symbols supported
54 by the STA for non-OFDMA transmissions to a single user."
55 DEFVAL { 0 }
56 ::= { dot11PhyEHTEntry 13 }
57
58 dot11EHTMaxNumberOfSupportedEHTLTFsForMUandNDP OBJECT-TYPE
59 SYNTAX INTEGER { 4(0), 8(1) }
60 MAX-ACCESS read-only
61 STATUS current
62 DESCRIPTION
63 "This is a capability variable.
64 Its value is determined by device capabilities.
65

790 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 This attribute indicates the maximum number of EHT-LTF symbols supported

2 by the STA for transmissions to multiple users and for an EHT sounding
3 NDP(#4500)."
4 DEFVAL { 0 }
5 ::= { dot11PhyEHTEntry 14 }
6
7 dot11EHTMCS15For52p26and106p26MRUImplemented OBJECT-TYPE
8 SYNTAX TruthValue
9 MAX-ACCESS read-only
10 STATUS current
11 DESCRIPTION
12 "This is a capability variable.
13 Its value is determined by device capabilities.
14
15 This attribute, when true, indicates that the STA supports EHT-MCS 15 in
16 52+26-tone and 106+26-tone MRUs.
17 This capability is disabled otherwise."
18 DEFVAL { false }
19 ::= { dot11PhyEHTEntry 15 }
20
21 dot11EHTMCS15For484p242MRUImplemented OBJECT-TYPE
22 SYNTAX TruthValue
23 MAX-ACCESS read-only
24 STATUS current
25 DESCRIPTION
26 "This is a capability variable.
27 Its value is determined by device capabilities.
28
29 This attribute, when true, indicates that the STA supports EHT-MCS 15 in a
30 484+242-tone MRU.
31 This capability is disabled otherwise."
32 DEFVAL { false }
33 ::= { dot11PhyEHTEntry 16 }
34
35
dot11EHTMCS15For996p484and996p484p242MRUImplemented OBJECT-TYPE
36
SYNTAX TruthValue
37
MAX-ACCESS read-only
38
STATUS current
39
DESCRIPTION
40
41 "This is a capability variable.
42 Its value is determined by device capabilities.
43
44 This attribute, when true, indicates that the STA supports EHT-MCS 15 in
45 996+484-tone and 996+484+242-tone MRUs.
46 This capability is disabled otherwise."
47 DEFVAL { false }
48 ::= { dot11PhyEHTEntry 17 }
49
50 dot11EHTMCS15For3x996MRUImplemented OBJECT-TYPE
51 SYNTAX TruthValue
52 MAX-ACCESS read-only
53 STATUS current
54 DESCRIPTION
55 "This is a capability variable.
56 Its value is determined by device capabilities.
57
58 This attribute, when true, indicates that the STA supports EHT-MCS 15 in a
59 3x996-tone MRU.
60 This capability is disabled otherwise."
61 DEFVAL { false }
62 ::= { dot11PhyEHTEntry 18 }
63
64
65

Copyright © 2022 IEEE. All rights reserved. 791

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 dot11EHTDupImplemented OBJECT-TYPE
2 SYNTAX TruthValue
3 MAX-ACCESS read-only
4 STATUS current
5 DESCRIPTION
6 "This is a capability variable.
7 Its value is determined by device capabilities.
8
9 This attribute, when true, indicates that the STA supports EHT DUP in 6
10 GHz.
11 This capability is disabled otherwise."
12 DEFVAL { false }
13 ::= { dot11PhyEHTEntry 19 }
14
15 dot11EHTSupportFor242ToneRUInBWWiderThan20Implemented OBJECT-TYPE
16 SYNTAX TruthValue
17 MAX-ACCESS read-only
18 STATUS current
19 DESCRIPTION
20 "This is a capability variable.
21 Its value is determined by device capabilities.
22
23 (#4627)In a non-AP STA, this attribute, when true, indicates that the non-
24 AP STA is capable of receiving a 242-tone RU in a PPDU with a bandwidth
25 larger than 20 MHz.
26 This capability is disabled (#4627)in a non-AP STA otherwise.
27 (#4627)Reserved for an AP."
28 DEFVAL { false }
29 ::= { dot11PhyEHTEntry 20 }
30
31
dot11EHT20MHzOperatingSTARxNDPwithWiderBWImplemented OBJECT-TYPE
32
SYNTAX TruthValue
33
MAX-ACCESS read-only
34
STATUS current
35
DESCRIPTION
36
"This is a capability variable.
37
38 Its value is determined by device capabilities.
39
40 This attribute, when true, indicates that the STA is capable of receiving
41 an (#4500)EHT sounding NDP with a PPDU bandwidth equal to any one of 40,
42 80 or 160 MHz.
43 This capability is disabled otherwise."
44 DEFVAL { false }
45 ::= { dot11PhyEHTEntry 21 }
46
47 (#7574)dot11MSDOFDMEDthreshold OBJECT-TYPE
48 SYNTAX Unsigned32(0..255)
49 MAX-ACCESS read-write
50 STATUS current
51 DESCRIPTION
52 "This is a control variable.
53 Its value is written by the MAC of a non-AP EHT STA upon receiving a Basic
54 Multi-Link element containing a medium synchronization OFDM ED threshold
55 from the EHT AP with which it is associated.
56
57 Changes take effect as soon as practical in the implementation. This
58 attribute indicates the energy detect threshold being used by the OFDM PHY
59 when the MediumSyncDelay timer of the MAC has nonzero value."
60 ::= { dot11PhyEHTEntry 22 }
61
62 (#4624)dot11EHTCurrentCenterFrequencyIndex0 OBJECT-TYPE
63 SYNTAX Unsigned32(0..255)
64 MAX-ACCESS read-only
65 STATUS current

792 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 DESCRIPTION
2 "This is a status variable.
3 It is written by the PHY.
4
5 This attribute specifies the channel center frequency for a 20 MHz, 40
6 MHz, 80 MHz, 160 MHz or 320 MHz channel."
7 DEFVAL { 0 }
8 ::= { dot11PhyEHTEntry 23 }
9
10 (#4627)dot11EHTSupportedEhtMcsAndNssSet20MhzOnlyImplemented OBJECT-TYPE
11 SYNTAX OCTET STRING (SIZE(4))
12 MAX-ACCESS read-only
13 STATUS current
14 DESCRIPTION
15 "This is a capability variable.
16 Its value is determined by device capabilities.
17
18 For a 20 MHz-only non-AP STA, this attribute indicates the implemented EHT
19 MCSs and NSSs. The encoding is the same as the EHT-MCS Map (20 MHz-Only
20 Non-AP STA) field when present in the Supported EHT-MCS and NSS Set field
21 in the EHT Capabilities element.
22 Reserved for a STA that is not a 20 MHz-only non-AP STA."
23 ::= { dot11PhyEHTEntry 24 }
24
25 (#4627)dot11EHTSupportedEhtMcsAndNssSet20MhzOnlyStaActivated OBJECT-TYPE
26 SYNTAX OCTET STRING (SIZE(4))
27 MAX-ACCESS read-write
28 STATUS current
29 DESCRIPTION
30 "This is a control variable.
31
It is written by the MLME.
32
33
For a 20 MHz-only non-AP STA, this attribute indicates the activated EHT
34
MCSs and NSSs. The encoding is the same as the EHT-MCS Map (20 MHz-Only
35
Non-AP STA) field when present in the Supported EHT-MCS and NSS Set field
36
in the EHT Capabilities element.
37
Reserved for a STA that is not a 20 MHz-only non-AP STA."
38
::= { dot11PhyEHTEntry 25 }
39
40
41 (#4627)dot11EHTSupportedEhtMcsAndNssSetmplemented OBJECT-TYPE
42 SYNTAX OCTET STRING (SIZE(9))
43 MAX-ACCESS read-only
44 STATUS current
45 DESCRIPTION
46 "This is a capability variable.
47 Its value is determined by device capabilities.
48
49 For a STA that is not a 20 MHz-only non-AP STA, this attribute indicates
50 the implemented EHT MCSs and NSSs. The encoding is the same as the EHT-MCS
51 Map (BW ≤ 80 MHz, Except 20 MHz-Only Non-AP STA) field when present fol-
52 lowed by the EHT-MCS Map (BW = 160 MHz) field when present followed by the
53 EHT-MCS Map (BW = 320 MHz) field when present in the Supported EHT-MCS and
54 NSS Set field in the EHT Capabilities element.
55 Reserved for a 20 MHz-only non-AP STA."
56 ::= { dot11PhyEHTEntry 26 }
57
58 (#4627)dot11EHTSupportedEhtMcsAndNssSetActivated OBJECT-TYPE
59 SYNTAX OCTET STRING (SIZE(9))
60 MAX-ACCESS read-write
61 STATUS current
62 DESCRIPTION
63 "This is a control variable.
64 It is written by the MLME.
65

Copyright © 2022 IEEE. All rights reserved. 793

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 For a STA that is not a 20 MHz-only non-AP STA, this attribute indicates
2 the activated EHT MCSs and NSSs. The encoding is the same as the EHT-MCS
3 Map (BW ≤ 80 MHz, Except 20 MHz-Only Non-AP STA) field when present fol-
4 lowed by the EHT-MCS Map (BW = 160 MHz) field when present followed by the
5 EHT-MCS Map (BW = 320 MHz) field when present in the Supported EHT-MCS and
6 NSS Set field in the EHT Capabilities element.
7 Reserved for a 20 MHz-only non-AP STA."
8 ::= { dot11PhyEHTEntry 27 }
9
10 (#4627)dot11EHTDisabledSubchannelBitmap OBJECT-TYPE
11 SYNTAX Unsigned32 (0..65535)
12 MAX-ACCESS read-only
13 STATUS current
14 DESCRIPTION
15 "This is a status variable.
16 It is written by the PHY. This attribute specifies the Disabled Subchannel
17 Bitmap field that is a 16-bit bitmap where the lowest numbered bit corre-
18 sponds to the 20 MHz subchannel that lies within the BSS bandwidth and
19 that has the lowest frequency of the set of all 20 MHz subchannels within
20 the BSS bandwidth. Each successive bit in the bitmap corresponds to the
21 next higher frequency 20 MHz subchannel. A bit in the bitmap is set to 1
22 to indicate the corresponding 20 MHz subchannel is punctured and set to 0
23 to indicate the corresponding 20 MHz subchannel is not punctured."
24 DEFVAL { 0 }
25 ::= { dot11PhyEHTEntry 28 }
26
27 -- **********************************************************************
28 -- * End of dot11 Phy EHT TABLE
29 -- **********************************************************************
30
31 -- **********************************************************************
32 -- * dot11 EHT Transmit Beamforming Config TABLE
33 -- **********************************************************************
34
35 dot11EHTTransmitBeamformingConfigTable OBJECT-TYPE
36 SYNTAX SEQUENCE OF Dot11EHTTransmitBeamformingConfigEntry
37
MAX-ACCESS not-accessible
38
STATUS current
39
DESCRIPTION
40
"Entry of attributes for Dot11EHTTransmitBeamformingConfigTable. Imple-
41
mented as a table indexed on ifIndex to allow for multiple instances on an
42
Agent."
43
::= { dot11phy 36 }
44
45
46 dot11EHTTransmitBeamformingConfigEntry OBJECT-TYPE
47 SYNTAX Dot11EHTTransmitBeamformingConfigEntry
48 MAX-ACCESS not-accessible
49 STATUS current
50 DESCRIPTION
51 "An entry in Dot11EHTTransmitBeamformingConfigTable.
52
53 ifIndex - Each IEEE Std 802.11 interface is represented by an ifEntry.
54 Interface tables in this MIB module are indexed by ifIndex."
55 INDEX {ifIndex}
56 ::= { dot11EHTTransmitBeamformingConfigTable 1 }
57
58 Dot11EHTTransmitBeamformingConfigEntry ::=
59 SEQUENCE {
60 dot11EHTSUBeamformerImplemented TruthValue,
61 dot11EHTSUBeamformeeImplemented TruthValue,
62 dot11EHTMUBeamformerLessThanOrEqualTo80Implemented TruthValue,
63 dot11EHTMUBeamformerEqualTo160Implemented TruthValue,
64 dot11EHTMUBeamformerEqualTo320Implemented TruthValue,
65 dot11EHTPartialBWDLMUMIMOImplemented TruthValue,

794 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 dot11EHTTriggeredSUBeamformingFeedbackImplemented TruthValue,
2 dot11EHTTriggeredMUBeamformingPartialBWFeedbackImplemented TruthValue,
3 dot11EHTTriggeredCQIFeedbackImplemented TruthValue,
4 dot11EHTNonTriggeredCQIFeedbackImplemented TruthValue,
5 dot11EHTBeamformeeSSLessThanOrEqualTo80 Unsigned32,
6 dot11EHTBeamformeeSSEqualTo160 Unsigned32,
7 dot11EHTBeamformeeSSEqualTo320 Unsigned32,
8 dot11EHTNumberSoundingDimensionsLessThanOrEqualTo80 Unsigned32,
9 dot11EHTNumberSoundingDimensionsEqualTo160 Unsigned32,
10 dot11EHTNumberSoundingDimensionsEqualTo320 Unsigned32,
11 dot11EHTNG16SUFeedbackImplemented TruthValue,
12 dot11EHTNG16MUFeedbackImplemented TruthValue,
13 dot11EHTCodebookSizePhi4Psi2SUFeedbackImplemented TruthValue,
14 dot11EHTCodebookSizePhi7Psi5MUFeedbackImplemented TruthValue,
15 dot11EHTMaxNc Unsigned32,
16 dot11EHTNDPwith4xEHTLTFand3point2GIImplemented TruthValue
17 }
18
19 dot11EHTSUBeamformerImplemented OBJECT-TYPE
20 SYNTAX TruthValue
21 MAX-ACCESS read-only
22 STATUS current
23 DESCRIPTION
24 "This is a capability variable.
25 Its value is determined by device capabilities.
26
27 This attribute, when true, indicates that operation as an SU beamformer is
28 supported.
29 This capability is disabled otherwise."
30 DEFVAL { false }
31 ::= { dot11EHTTransmitBeamformingConfigEntry 1 }
32
33
dot11EHTSUBeamformeeImplemented OBJECT-TYPE
34
SYNTAX TruthValue
35
MAX-ACCESS read-only
36
STATUS current
37
DESCRIPTION
38
39 "This is a capability variable.
40 Its value is determined by device capabilities.
41
42 (#4627)In an AP, this attribute, when true, indicates that operation as an
43 SU beamformee is supported in the AP.
44 This capability is disabled (#4627)in an AP otherwise.
45 (#4627)Set to true for a non-AP STA."
46 DEFVAL { false }
47 ::= { dot11EHTTransmitBeamformingConfigEntry 2 }
48
49 dot11EHTMUBeamformerLessThanOrEqualTo80Implemented OBJECT-TYPE
50 SYNTAX TruthValue
51 MAX-ACCESS read-only
52 STATUS current
53 DESCRIPTION
54 "This is a capability variable.
55 Its value is determined by device capabilities.
56
57 (#4627)In an AP, this attribute, when true, indicates that the AP supports
58 non-OFDMA DL MU-MIMO transmission and the required MU sounding for PPDU
59 bandwidths equal to any one of 20, 40 or 80 MHz.
60 This capability is disabled (#4627)in an AP otherwise.
61 (#4627)Reserved for a non-AP STA."
62 DEFVAL { false }
63 ::= { dot11EHTTransmitBeamformingConfigEntry 3 }
64
65

Copyright © 2022 IEEE. All rights reserved. 795

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 dot11EHTMUBeamformerEqualTo160Implemented OBJECT-TYPE
2 SYNTAX TruthValue
3 MAX-ACCESS read-only
4 STATUS current
5 DESCRIPTION
6 "This is a capability variable.
7 Its value is determined by device capabilities.
8
9 (#4627)In an AP, this attribute, when true, indicates that the AP supports
10 non-OFDMA DL MU-MIMO transmission and the required MU sounding for PPDU
11 bandwidth equal to 160 MHz.
12 This capability is disabled (#4627)in an AP otherwise.
13 (#4627)Reserved for a non-AP STA."
14 DEFVAL { false }
15 ::= { dot11EHTTransmitBeamformingConfigEntry 4 }
16
17 dot11EHTMUBeamformerEqualTo320Implemented OBJECT-TYPE
18 SYNTAX TruthValue
19 MAX-ACCESS read-only
20 STATUS current
21 DESCRIPTION
22 "This is a capability variable.
23 Its value is determined by device capabilities.
24
25 (#4627)In an AP, this attribute, when true, indicates that the AP supports
26 non-OFDMA DL MU-MIMO transmission and the required MU sounding for PPDU
27 bandwidth equal to 320 MHz.
28 This capability is disabled (#4627)in an AP otherwise.
29 (#4627)Reserved for a non-AP STA."
30 DEFVAL { false }
31 ::= { dot11EHTTransmitBeamformingConfigEntry 5 }
32
33
dot11EHTPartialBWDLMUMIMOImplemented OBJECT-TYPE
34
SYNTAX TruthValue
35
MAX-ACCESS read-only
36
STATUS current
37
DESCRIPTION
38
39 "This is a capability variable.
40 Its value is determined by device capabilities.
41
42 (#4627)In a non-AP STA, this attribute, when true, indicates that the non-
43 AP STA supports receiving DL MU-MIMO on an RU/MRU in an EHT MU PPDU where
44 the RU/MRU does not span the entire PPDU bandwidth.
45 This capability is disabled (#4627)in a non-AP STA otherwise.
46 (#4627)Reserved for an AP."
47 DEFVAL { false }
48 ::= { dot11EHTTransmitBeamformingConfigEntry 6 }
49
50 dot11EHTTriggeredSUBeamformingFeedbackImplemented OBJECT-TYPE
51 SYNTAX TruthValue
52 MAX-ACCESS read-only
53 STATUS current
54 DESCRIPTION
55 "This is a capability variable.
56 Its value is determined by device capabilities.
57
58 This attribute, when true for an AP implementation, indicates that the AP
59 supports receiving partial and full bandwidth SU feedback in an EHT TB
60 sounding sequence.
61 This attribute, when true for a non-AP STA implementation, indicates that
62 the non-AP STA supports transmitting partial and full bandwidth SU feed-
63 back in an EHT TB sounding sequence.
64 This capability is disabled otherwise."
65 DEFVAL { false }

796 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 ::= { dot11EHTTransmitBeamformingConfigEntry 7 }
2
3 dot11EHTTriggeredMUBeamformingPartialBWFeedbackImplemented OBJECT-TYPE
4 SYNTAX TruthValue
5 MAX-ACCESS read-only
6 STATUS current
7 DESCRIPTION
8 "This is a capability variable.
9 Its value is determined by device capabilities.
10
11 This attribute, when true for an AP implementation, indicates that the AP
12 supports receiving partial bandwidth MU feedback in an EHT TB sounding
13 sequence.
14 This attribute, when true for a non-AP STA implementation, indicates that
15 the non-AP STA supports transmitting partial bandwidth MU feedback in an
16 EHT TB sounding sequence.
17 This capability is disabled otherwise."
18 DEFVAL { false }
19 ::= { dot11EHTTransmitBeamformingConfigEntry 8 }
20
21 dot11EHTTriggeredCQIFeedbackImplemented OBJECT-TYPE
22 SYNTAX TruthValue
23 MAX-ACCESS read-only
24 STATUS current
25 DESCRIPTION
26 "This is a capability variable.
27 Its value is determined by device capabilities.
28
29 This attribute, when true for an AP implementation, indicates that the AP
30 supports receiving partial bandwidth CQI feedback in an EHT TB sounding
31 sequence.
32 This attribute, when true for a non-AP STA implementation, indicates that
33 the non-AP STA supports transmitting partial bandwidth CQI feedback in an
34 EHT TB sounding sequence.
35
This capability is disabled otherwise."
36
DEFVAL { false }
37
::= { dot11EHTTransmitBeamformingConfigEntry 9 }
38
39
dot11EHTNonTriggeredCQIFeedbackImplemented OBJECT-TYPE
40
SYNTAX TruthValue
41
42 MAX-ACCESS read-only
43 STATUS current
44 DESCRIPTION
45 "This is a capability variable.
46 Its value is determined by device capabilities.
47
48 This attribute, when true for an AP implementation, indicates that the AP
49 supports receiving full bandwidth CQI feedback in an EHT non-TB sounding
50 sequence.
51 This attribute, when true for a non-AP STA implementation, indicates that
52 the non-AP STA supports transmitting full bandwidth CQI feedback in an EHT
53 non-TB sounding sequence.
54 This capability is disabled otherwise."
55 DEFVAL { false }
56 ::= { dot11EHTTransmitBeamformingConfigEntry 10 }
57
58 dot11EHTBeamformeeSSLessThanOrEqualTo80 OBJECT-TYPE
59 SYNTAX Unsigned32 (4..8)
60 MAX-ACCESS read-only
61 STATUS current
62 DESCRIPTION
63 "This is a capability variable.
64 Its value is determined by device capabilities.
65

Copyright © 2022 IEEE. All rights reserved. 797

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#4627)If dot11EHTSUBeamformeeImplemented is true, this attribute indi-

2 cates the maximum number of spatial streams that the STA can receive in an
3 EHT sounding NDP of bandwidth equal to any one of 20, 40 or 80 MHz. This
4 attribute also indicates the maximum total number of spatial streams over
5 all users that can be sent in a DL MU-MIMO transmission in an EHT MU PPDU
6 of bandwidth equal to any one of 20, 40 or 80 MHz, on an RU/MRU that
7 includes that STA, where the RU/MRU might or might not span the entire
8 PPDU bandwidth.
9 (#4627)Reserved if dot11EHTSUBeamformeeImplemented is false."
10 DEFVAL { 4 }
11 ::= { dot11EHTTransmitBeamformingConfigEntry 11 }
12
13 dot11EHTBeamformeeSSEqualTo160 OBJECT-TYPE
14 SYNTAX Unsigned32 (4..8)
15 MAX-ACCESS read-only
16 STATUS current
17 DESCRIPTION
18 "This is a capability variable.
19 Its value is determined by device capabilities.
20
21 (#4627)If dot11EHTSUBeamformeeImplemented is true, this attribute indi-
22 cates the maximum number of spatial streams that the STA can receive in an
23 EHT sounding NDP of bandwidth equal to 160 MHz. This attribute also indi-
24 cates the maximum total number of spatial streams over all users that can
25 be sent in a DL MU-MIMO transmission in an EHT MU PPDU of bandwidth equal
26 to 160 MHz, on an RU/MRU that includes that STA, where the RU/MRU might or
27 might not span the entire PPDU bandwidth.
28 (#4627)Reserved if dot11EHTSUBeamformeeImplemented is false."
29 DEFVAL { 4 }
30 ::= { dot11EHTTransmitBeamformingConfigEntry 12 }
31
32 dot11EHTBeamformeeSSEqualTo320 OBJECT-TYPE
33 SYNTAX Unsigned32 (4..8)
34 MAX-ACCESS read-only
35
STATUS current
36
DESCRIPTION
37
"This is a capability variable.
38
Its value is determined by device capabilities.
39
40
41 (#4627)If dot11EHTSUBeamformeeImplemented is true, this attribute indi-
42 cates the maximum number of spatial streams that the STA can receive in an
43 EHT sounding NDP of bandwidth equal to 320 MHz. This attribute also indi-
44 cates the maximum total number of spatial streams over all users that can
45 be sent in a DL MU-MIMO transmission in an EHT MU PPDU of bandwidth equal
46 to 320 MHz, on an RU/MRU that includes that STA, where the RU/MRU might or
47 might not span the entire PPDU bandwidth.
48 (#4627)Reserved if dot11EHTSUBeamformeeImplemented is false."
49 DEFVAL { 4 }
50 ::= { dot11EHTTransmitBeamformingConfigEntry 13 }
51
52 dot11EHTNumberSoundingDimensionsLessThanOrEqualTo80 OBJECT-TYPE
53 SYNTAX Unsigned32 (4..8)
54 MAX-ACCESS read-only
55 STATUS current
56 DESCRIPTION
57 "This is a capability variable.
58 Its value is determined by device capabilities.
59
60 (#4627)If dot11EHTSUBeamformerImplemented is true, this attribute indi-
61 cates the maximum number of spatial streams the beamformer can transmit in
62 an EHT sounding NDP with PPDU bandwidth equal to any one of 20, 40 or 80
63 MHz.
64 (#4627)Reserved if dot11EHTSUBeamformerImplemented is false."
65 DEFVAL { 4 }

798 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 ::= { dot11EHTTransmitBeamformingConfigEntry 14 }
2
3 dot11EHTNumberSoundingDimensionsEqualTo160 OBJECT-TYPE
4 SYNTAX Unsigned32 (4..8)
5 MAX-ACCESS read-only
6 STATUS current
7 DESCRIPTION
8 "This is a capability variable.
9 Its value is determined by device capabilities.
10
11 (#4627)If dot11EHTSUBeamformerImplemented is true, this attribute indi-
12 cates the maximum number of spatial streams the beamformer can transmit in
13 an EHT sounding NDP with PPDU bandwidth equal to 160 MHz.
14 (#4627)Reserved if dot11EHTSUBeamformerImplemented is false."
15 DEFVAL { 4 }
16 ::= { dot11EHTTransmitBeamformingConfigEntry 15 }
17
18 dot11EHTNumberSoundingDimensionsEqualTo320 OBJECT-TYPE
19 SYNTAX Unsigned32 (4..8)
20 MAX-ACCESS read-only
21 STATUS current
22 DESCRIPTION
23 "This is a capability variable.
24 Its value is determined by device capabilities.
25
26 (#4627)If dot11EHTSUBeamformerImplemented is true, this attribute indi-
27 cates the maximum number of spatial streams the beamformer can transmit in
28 an EHT sounding NDP with PPDU bandwidth equal to 320 MHz.
29 (#4627)Reserved if dot11EHTSUBeamformerImplemented is false."
30 DEFVAL { 4 }
31 ::= { dot11EHTTransmitBeamformingConfigEntry 16 }
32
33
dot11EHTNG16SUFeedbackImplemented OBJECT-TYPE
34
SYNTAX TruthValue
35
MAX-ACCESS read-only
36
STATUS current
37
DESCRIPTION
38
"This is a capability variable.
39
40 Its value is determined by device capabilities.
41
42 This attribute, when true, indicates that the EHT beamformee supports sub-
43 carrier grouping of 16 in the EHT Compressed Beamforming Report field for
44 SU feedback.
45 This capability is disabled otherwise."
46 DEFVAL { false }
47 ::= { dot11EHTTransmitBeamformingConfigEntry 17 }
48
49 dot11EHTNG16MUFeedbackImplemented OBJECT-TYPE
50 SYNTAX TruthValue
51 MAX-ACCESS read-only
52 STATUS current
53 DESCRIPTION
54 "This is a capability variable.
55 Its value is determined by device capabilities.
56
57 This attribute, when true, indicates that the EHT beamformee supports sub-
58 carrier grouping of 16 in the EHT Compressed Beamforming Report field for
59 MU feedback.
60 This capability is disabled otherwise."
61 DEFVAL { false }
62 ::= { dot11EHTTransmitBeamformingConfigEntry 18 }
63
64
65

Copyright © 2022 IEEE. All rights reserved. 799

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 dot11EHTCodebookSizePhi4Psi2SUFeedbackImplemented OBJECT-TYPE
2 SYNTAX TruthValue
3 MAX-ACCESS read-only
4 STATUS current
5 DESCRIPTION
6 "This is a capability variable.
7 Its value is determined by device capabilities.
8
9 This attribute, when true, indicates that the EHT beamformee supports
10 codebook size (psi, phi) = {4, 2} in the EHT Compressed Beamforming Report
11 field for SU feedback.
12 This capability is disabled otherwise."
13 DEFVAL { false }
14 ::= { dot11EHTTransmitBeamformingConfigEntry 19 }
15
16 dot11EHTCodebookSizePhi7Psi5MUFeedbackImplemented OBJECT-TYPE
17 SYNTAX TruthValue
18 MAX-ACCESS read-only
19 STATUS current
20 DESCRIPTION
21 "This is a capability variable.
22 Its value is determined by device capabilities.
23
24 This attribute, when true, indicates that the EHT beamformee supports
25 codebook size (psi, phi) = {7, 5} in the EHT Compressed Beamforming Report
26 field for MU feedback.
27 This capability is disabled otherwise."
28 DEFVAL { false }
29 ::= { dot11EHTTransmitBeamformingConfigEntry 20 }
30
31 dot11EHTMaxNc OBJECT-TYPE
32
SYNTAX Unsigned32 (1..8)
33
MAX-ACCESS read-only
34
STATUS current
35
DESCRIPTION
36
"This is a capability variable.
37
Its value is determined by device capabilities.
38
39
40 (#4627)If dot11EHTSUBeamformeeImplemented is true, this attribute indi-
41 cates the maximum number of columns (Nc) supported by the EHT beamformee
42 for the EHT compressed beamforming/CQI.
43 (#4627)Reserved if dot11EHTSUBeamformeeImplemented is false."
44 ::= { dot11EHTTransmitBeamformingConfigEntry 21 }
45
46 dot11EHTNDPwith4xEHTLTFand3point2GIImplemented OBJECT-TYPE
47 SYNTAX TruthValue
48 MAX-ACCESS read-only
49 STATUS current
50 DESCRIPTION
51 "This is a capability variable.
52 Its value is determined by device capabilities.
53
54 (#4627)If dot11EHTSUBeamformeeImplemented is true, this attribute, when
55 true, indicates that the EHT beamformee supports receiving an EHT sounding
56 NDP using 4x EHT-LTF and 3.2 microseconds guard interval duration.
57 (#4627)If dot11EHTSUBeamformeeImplemented is true, this capability is dis-
58 abled otherwise.
59 (#4627)Reserved if dot11EHTSUBeamformeeImplemented is false."
60 DEFVAL { false }
61 ::= { dot11EHTTransmitBeamformingConfigEntry 22 }
62
63 -- **********************************************************************
64 -- * End of dot11 EHT Transmit Beamforming Config TABLE
65 -- **********************************************************************

800 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2 Change Dot11StationConfigEntry as follows (not all lines shown):
3
4 -- **********************************************************************
5 -- * dot11Interworking TABLE
6 -- **********************************************************************
7
8 Dot11InterworkingEntry ::=
9 SEQUENCE {
10 dot11NonAPStationMacAddress MacAddress,
11 …
12 dot11NonAPStationAddtsResultCode INTEGER},
13 (#4172)(#5284)dot11EPCSPriorityAccessAuthorized TruthValue}
14
15 Insert the following after dot11NonAPStationAddtsResultCode:
16
17 (#4172)(#5284)dot11EPCSPriorityAccessAuthorized OBJECT-TYPE
18 SYNTAX TruthValue
19 MAX-ACCESS read-write
20 STATUS current
21 DESCRIPTION
22 "This is a control variable.
23 It is written by the SME after the AP receives the permissions for the
24 non-AP STA (#7526)to use the EPCS priority access from the SSPN interface.
25
26 This attribute, when true, indicates that the non-AP STA is permitted to
27 invoke and use the EPCS priority access capability. If this capability is
28 false, the non-AP STA is not permitted to invoke and use the EPCS priority
29 access capability."
30 DEFVAL { false }
31 ::= { dot11InterworkingEntry <Last assigned + 1> }
32
33 -- **********************************************************************
34 -- * End of dot11Interworking TABLE
35
-- **********************************************************************
36
37
38 Change the compliance statements as follows (not all lines shown):
39
40 -- **********************************************************************
41 -- * Compliance Statements
42 -- **********************************************************************
43
44 dot11Compliance MODULE-COMPLIANCE
45 STATUS current
46 DESCRIPTION
47 "The compliance statement for SNMPv2 entities that implement the IEEE
48 802.11 MIB."
49 MODULE -- this module
50 MANDATORY-GROUPS {
51 dot11SMTbase15,
52 dot11MACbase5,
53 dot11CountersGroup5,
54 dot11SmtAuthenticationAlgorithms,
55 dot11ResourceTypeID,
56 dot11PhyOperationComplianceGroup2}
57
58 GROUP dot11PhyDSSSComplianceGroup
59 DESCRIPTION
60 "Implementation of this group is required when object dot11PHYType is
61 dsss.
62 This group is mutually exclusive to the following groups:
63 dot11PhyOFDMComplianceGroup3
64 dot11PhyHRDSSSComplianceGroup
65 dot11PhyERPComplianceGroup

Copyright © 2022 IEEE. All rights reserved. 801

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 dot11PhyHTComplianceGroup
2 dot11DMGComplianceGroup
3 dot11PhyVHTComplianceGroup
4 dot11PhyTVHTComplianceGroup
5 dot11PhyS1GComplianceGroup
6 dot11CDMGComplianceGroup1
7 dot11CMMGComplianceGroup
8 dot11PHYHEComplianceGroup
9 dot11EDMGComplianceGroup
10 dot11PHYEHTComplianceGroup"
11
12 GROUP dot11PhyOFDMComplianceGroup3
13 DESCRIPTION
14 "Implementation of this group is required when object dot11PHYType is
15 ofdm.
16 This group is mutually exclusive to the following groups:
17 dot11PhyDSSSComplianceGroup
18 dot11PhyHRDSSSComplianceGroup
19 dot11PhyERPComplianceGroup
20 dot11PhyHTComplianceGroup
21 dot11DMGComplianceGroup
22 dot11PhyVHTComplianceGroup
23 dot11PhyTVHTComplianceGroup
24 dot11PhyS1GComplianceGroup
25 dot11CDMGComplianceGroup1
26 dot11CMMGComplianceGroup
27 dot11PHYHEComplianceGroup
28 dot11EDMGComplianceGroup
29 dot11PHYEHTComplianceGroup"
30
31 GROUP dot11PhyHRDSSSComplianceGroup
32 DESCRIPTION
33
"Implementation of this group is required when object dot11PHYType is
34
hrdsss.
35
This group is mutually exclusive to the following groups:
36
dot11PhyDSSSComplianceGroup
37
dot11PhyOFDMComplianceGroup3
38
dot11PhyERPComplianceGroup
39
dot11PhyHTComplianceGroup
40
41 dot11DMGComplianceGroup
42 dot11PhyVHTComplianceGroup
43 dot11PhyTVHTComplianceGroup
44 dot11PhyS1GComplianceGroup
45 dot11CDMGComplianceGroup1
46 dot11CMMGComplianceGroup
47 dot11PHYHEComplianceGroup
48 dot11EDMGComplianceGroup
49 dot11PHYEHTComplianceGroup"
50
51 GROUP dot11PhyERPComplianceGroup
52 DESCRIPTION
53 "Implementation of this group is required when object dot11PHYType is erp.
54 This group is mutually exclusive to the following groups:
55 dot11PhyDSSSComplianceGroup
56 dot11PhyOFDMComplianceGroup3
57 dot11PhyHRDSSSComplianceGroup
58 dot11PhyHTComplianceGroup
59 dot11DMGComplianceGroup
60 dot11PhyVHTComplianceGroup
61 dot11PhyTVHTComplianceGroup
62 dot11PhyS1GComplianceGroup
63 dot11CDMGComplianceGroup1
64 dot11CMMGComplianceGroup
65 dot11PHYHEComplianceGroup

802 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 dot11EDMGComplianceGroup
2 dot11PHYEHTComplianceGroup"
3
4 GROUP dot11PhyHTComplianceGroup
5 DESCRIPTION
6 "Implementation of this group is required when object dot11PHYType is ht.
7 This group is mutually exclusive to the following groups:
8 dot11PhyDSSSComplianceGroup
9 dot11PhyOFDMComplianceGroup3
10 dot11PhyHRDSSSComplianceGroup
11 dot11PhyERPComplianceGroup
12 dot11DMGComplianceGroup
13 dot11PhyVHTComplianceGroup
14 dot11PhyTVHTComplianceGroup
15 dot11PhyS1GComplianceGroup
16 dot11CDMGComplianceGroup1
17 dot11CMMGComplianceGroup
18 dot11PHYHEComplianceGroup
19 dot11EDMGComplianceGroup
20 dot11PHYEHTComplianceGroup"
21
22 GROUP dot11PhyVHTComplianceGroup
23 DESCRIPTION
24 "Implementation of this group is required when object dot11PHYType is vht.
25 This group is mutually exclusive to the following groups:
26 dot11PhyDSSSComplianceGroup
27 dot11PhyOFDMComplianceGroup3
28 dot11PhyHRDSSSComplianceGroup
29 dot11PhyERPComplianceGroup
30 dot11DMGComplianceGroup
31 dot11PhyHTComplianceGroup
32 dot11PhyTVHTComplianceGroup
33
dot11PhyS1GComplianceGroup
34
dot11CDMGComplianceGroup1
35
dot11CMMGComplianceGroup
36
dot11PHYHEComplianceGroup
37
dot11EDMGComplianceGroup
38
dot11PHYEHTComplianceGroup"
39
40
41 GROUP dot11PhyTVHTComplianceGroup
42 DESCRIPTION
43 "Implementation of this group is required when object dot11PHYType is
44 tvht.
45 This group is mutually exclusive to the following groups:
46 dot11PhyDSSSComplianceGroup
47 dot11PhyOFDMComplianceGroup3
48 dot11PhyHRDSSSComplianceGroup
49 dot11PhyERPComplianceGroup
50 dot11PhyHTComplianceGroup
51 dot11DMGComplianceGroup
52 dot11PhyVHTComplianceGroup
53 dot11PhyS1GComplianceGroup
54 dot11CDMGComplianceGroup1
55 dot11CMMGComplianceGroup
56 dot11PHYHEComplianceGroup
57 dot11EDMGComplianceGroup
58 dot11PHYEHTComplianceGroup"
59
60 GROUP dot11PhyS1GComplianceGroup
61 DESCRIPTION
62 "Implementation of this group is required when object dot11PHYType is s1g.
63 This group is mutually exclusive to the following groups:
64 dot11PhyDSSSComplianceGroup
65 dot11PhyOFDMComplianceGroup3

Copyright © 2022 IEEE. All rights reserved. 803

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 dot11PhyHRDSSSComplianceGroup
2 dot11PhyERPComplianceGroup
3 dot11PhyHTComplianceGroup
4 dot11DMGComplianceGroup
5 dot11PhyVHTComplianceGroup
6 dot11PhyTVHTComplianceGroup
7 dot11CDMGComplianceGroup1
8 dot11CMMGComplianceGroup
9 dot11PHYHEComplianceGroup
10 dot11EDMGComplianceGroup
11 dot11PHYEHTComplianceGroup"
12
13 GROUP dot11DMGComplianceGroup
14 DESCRIPTION
15 "Implementation of this group is required when the object dot11PHYType is
16 dmg.
17 This group is mutually exclusive to the following groups:
18 dot11PhyDSSSComplianceGroup
19 dot11PhyOFDMComplianceGroup3
20 dot11PhyHRDSSSComplianceGroup
21 dot11PhyERPComplianceGroup
22 dot11PhyHTComplianceGroup
23 dot11PhyVHTComplianceGroup
24 dot11PhyTVHTComplianceGroup
25 dot11PhyS1GComplianceGroup
26 dot11CDMGComplianceGroup1
27 dot11CMMGComplianceGroup
28 dot11PHYHEComplianceGroup
29 dot11EDMGComplianceGroup
30 dot11PHYEHTComplianceGroup"
31
32 GROUP dot11CDMGComplianceGroup1
33
DESCRIPTION
34
"Implementation of this group is required when the object
35
dot11PHYType has the value of CDMG.
36
This group is mutually exclusive to the following groups:
37
dot11PhyDSSSComplianceGroup
38
dot11PhyOFDMComplianceGroup3
39
dot11PhyHRDSSSComplianceGroup
40
41 dot11PhyERPComplianceGroup
42 dot11PhyHTComplianceGroup
43 dot11PhyVHTComplianceGroup
44 dot11PhyTVHTComplianceGroup
45 dot11PhyDMGComplianceGroup
46 dot11PhyCMMGComplianceGroup
47 dot11PHYHEComplianceGroup
48 dot11EDMGComplianceGroup
49 dot11PHYEHTComplianceGroup"
50
51 GROUP dot11CMMGComplianceGroup
52 DESCRIPTION
53 "Implementation of this group is required when the object dot11PHYType has
54 the value of CMMG.
55 This group is mutually exclusive to the following groups:
56 dot11PhyDSSSComplianceGroup
57 dot11PhyOFDMComplianceGroup3
58 dot11PhyHRDSSSComplianceGroup
59 dot11PhyERPComplianceGroup
60 dot11PhyHTComplianceGroup
61 dot11PhyVHTComplianceGroup
62 dot11PhyTVHTComplianceGroup
63 dot11PhyDMGComplianceGroup
64 dot11PhyCDMGComplianceGroup
65 dot11PHYHEComplianceGroup

804 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 dot11EDMGComplianceGroup
2 dot11PHYEHTComplianceGroup"
3
4 GROUP dot11PhyHEComplianceGroup
5 DESCRIPTION
6 "Implementation of this group is required when object dot11PHYType has the
7 value of HE.
8 This group is mutually exclusive to the following groups:
9 dot11PhyIRComplianceGroup
10 dot11PhyFHSSComplianceGroup2
11 dot11PhyDSSSComplianceGroup
12 dot11PhyOFDMComplianceGroup3
13 dot11PhyHRDSSSComplianceGroup
14 dot11PhyERPComplianceGroup
15 dot11PhyHTComplianceGroup
16 dot11DMGComplianceGroup
17 dot11PhyVHTComplianceGroup
18 dot11PhyTVHTComplianceGroup
19 dot11PhyS1GComplianceGroup
20 dot11CDMGComplianceGroup1
21 dot11CMMGComplianceGroup
22 dot11PHYHEComplianceGroup
23 dot11EDMGComplianceGroup
24 dot11PHYEHTComplianceGroup"
25
26 GROUP dot11PhyEHTComplianceGroup
27 DESCRIPTION
28 "Implementation of this group is required when object dot11PHYType has the
29 value of EHT.
30 This group is mutually exclusive to the following groups:
31 dot11PhyIRComplianceGroup
32 dot11PhyFHSSComplianceGroup2
33 dot11PhyDSSSComplianceGroup
34 dot11PhyOFDMComplianceGroup3
35 dot11PhyHRDSSSComplianceGroup
36 dot11PhyERPComplianceGroup
37 dot11PhyHTComplianceGroup
38 dot11DMGComplianceGroup
39 dot11PhyVHTComplianceGroup
40 dot11PhyTVHTComplianceGroup
41 dot11PhyS1GComplianceGroup
42 dot11CDMGComplianceGroup1
43 dot11CMMGComplianceGroup
44 dot11PhyHEComplianceGroup
45 dot11EDMGComplianceGroup"
46
47 Insert the following compliance objects after the dot11EDMGComplianceGroup object:
48
49
dot11EHTComplianceGroup OBJECT-GROUP
50
OBJECTS {
51
dot11EHTPPEThresholdsRequired
52
}
53
54 STATUS current
55 DESCRIPTION
56 "Attributes that configure the EHT Group for IEEE 802.11."
57 ::= { dot11Groups 120 }
58
59 dot11EHTTransmitBeamformingGroup OBJECT-GROUP
60 OBJECTS {
61 dot11EHTSUBeamformerImplemented,
62 dot11EHTSUBeamformeeImplemented,
63 dot11EHTMUBeamformerLessThanOrEqualTo80Implemented,
64 dot11EHTMUBeamformerEqualTo160Implemented,
65 dot11EHTMUBeamformerEqualTo320Implemented,

Copyright © 2022 IEEE. All rights reserved. 805

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 dot11EHTPartialBWDLMUMIMOImplemented,
2 dot11EHTTriggeredSUBeamformingFeedbackImplemented,
3 dot11EHTTriggeredMUBeamformingPartialBWFeedbackImplemented,
4 dot11EHTTriggeredCQIFeedbackImplemented,
5 dot11EHTNonTriggeredCQIFeedbackImplemented,
6 dot11EHTBeamformeeSSLessThanOrEqualTo80,
7 dot11EHTBeamformeeSSEqualTo160,
8 dot11EHTBeamformeeSSEqualTo320,
9 dot11EHTNumberSoundingDimensionsLessThanOrEqualTo80,
10 dot11EHTNumberSoundingDimensionsEqualTo160,
11 dot11EHTNumberSoundingDimensionsEqualTo320,
12 dot11EHTNG16SUFeedbackImplemented,
13 dot11EHTNG16MUFeedbackImplemented,
14 dot11EHTCodebookSizePhi4Psi2SUFeedbackImplemented,
15 dot11EHTCodebookSizePhi7Psi5MUFeedbackImplemented,
16 dot11EHTMaxNc,
17 dot11EHTNDPwith4xEHTLTFand3point2GIImplemented
18 }
19
20 STATUS current
21 DESCRIPTION
22 "Attributes that configure EHT transmit beamforming for IEEE 802.11."
23 ::= { dot11Groups 121 }
24
25 dot11PhyEHTComplianceGroup OBJECT-GROUP
26 OBJECTS {
27 dot11EHTCurrentChannelWidth,
28 dot11EHTSupportFor320MHzImplemented,
29 dot11EHTNonOFDMAULMUMIMOLessThanOrEqualto80Implemented,
30 dot11EHTNonOFDMAULMUMIMOEqualto160Implemented,
31 dot11EHTNonOFDMAULMUMIMOEqualto320Implemented,
32 dot11EHTPartialBWULMUMIMOImplemented,
33 dot11EHTMUPPDUwith4xEHTLTFand0point8usecGIImplemented,
34 dot11EHTPSRBasedSRImplemented,
35 dot11EHTPowerBoostFactorImplemented,
36 dot11EHTTx1024QAMand4096QAMLessThan242ToneRUImplemented,
37 dot11EHTRx1024QAMand4096QAMLessThan242ToneRUImplemented,
38 dot11EHTExtraLTFsImplemented,
39 dot11EHTMaxNumberOfSupportedEHTLTFsForSU,
40 dot11EHTMaxNumberOfSupportedEHTLTFsForMUandNDP,
41 dot11EHTMCS15For52p26and106p26MRUImplemented,
42 dot11EHTMCS15For484p242MRUImplemented,
43 dot11EHTMCS15For996p484and996p484p242MRUImplemented,
44 dot11EHTMCS15For3x996MRUImplemented,
45 dot11EHTDupImplemented,
46 dot11EHTSupportFor242ToneRUInBWWiderThan20Implemented,
47 dot11EHT20MHzOperatingSTARxNDPwithWiderBWImplemented,
48 }
49 STATUS current
50 DESCRIPTION
51
"Attributes that configure the EHT PHY."
52
::= { dot11Groups 122 }
53
54
55 Insert the following after GROUP dot11CMMGOperationsComplianceGroup:
56
57 GROUP dot11EHTComplianceGroup
58 DESCRIPTION
59 "The dot11EHTComplianceGroup group is optional."
60
61 Change OPTIONAL-GROUPS as follows:
62
63 -- OPTIONAL-GROUPS {
64 -- dot11SMTprivacy,
65 -- dot11MACStatistics,

806 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 -- dot11PhyTxPowerComplianceGroup,
2 -- dot11PhyRegDomainsSupportGroup,
3 -- dot11PhyAntennasListGroup,
4 -- dot11PhyRateGroup,
5 -- dot11MultiDomainCapabilityGroup,
6 -- dot11RSNAadditions,
7 -- dot11OperatingClassesGroup,
8 -- dot11Qosadditions,
9 -- dot11RMCompliance,
10 -- dot11FTComplianceGroup,
11 -- dot11PhyAntennaComplianceGroup2,
12 -- dot11HTMACadditions3,
13 -- dot11PhyMCSGroup,
14 -- dot11TransmitBeamformingGroup,
15 -- dot11TVHTTransmitBeamformingGroup,
16 -- dot11PhyTVHTComplianceGroup,
17 -- dot11S1GTransmitBeamformingGroup,
18 -- dot11PhyS1GComplianceGroup,
19 -- dot11S1GComplianceGroup,
20 -- dot11WNMCompliance,
21 -- dot11BSSStatisticsGroup,
22 -- dot11VHTTransmitBeamformingGroup,
23 -- dot11PhyVHTComplianceGroup,
24 -- dot11VHTMACAdditions,
25 -- dot11TVWSComplianceGroup,
26 -- dot11FILSComplianceGroup,
27 -- dot11PADComplianceGroup,
28 -- dot11HETransmitBeamformingGroup,
29 -- dot11PhyHEComplianceGroup,
30 -- dot11HEComplianceGroup,
31 -- dot11EHTComplianceGroup,
32 -- dot11EHTTransmitBeamformingGroup,
33 -- dot11PhyEHTComplianceGroup}
34 ::= { dot11Compliances 1 }
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 807

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

808 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2
Annex E
3
4 (normative)
5
6
7
8
Country elements and operating classes
9
10
11 E.1 Country information and operating classes
12
13
14 Change the following rows in Table E-4 (Global operating classes):
15
16
17 Table E-4—Global operating classes
18
19
20 Channel Channel
21 Nonglobal Channel
Operating starting Channel center
22 operating spacing Behavior limits set
class frequency set frequency
23 class(es) (MHz)
(GHz) index
24
25 137 — 5.950 320 — 31, 63, 95,
26 127, 159,
27 191
28
29 1378–179 — Reserved Reserved Reserved Reserved Reserved
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 809

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2
Annex R
3
4 (informative)
5
6
7
8
Interworking with external networks
9
10
11 R.4 Interworking and SSPN interface support
12
13
14
15
R.4.2 SSPN interface parameters
16
17 R.4.2.1 General
18
19
20
Insert a new row to and change the header in Table R-3 (SSPN Interface information or
21 permission parameters(#5284)(#5652)) as follows:
22
23
24
25
26
27 Table R-3—SSPN Interface information or permission parameters(#5284)(#5652)
28
29
From Access From SSPN
30 Per non-AP
Information or permission name NetworkAN to ANAccess
31 STA entry
to SSPN Network
32
33
Authorized EPCS Priority Access Type + +
34
35
36
37
38
39
40 R.4.2.4 Non-AP STA Interworking Capability
41
42 Change the first paragraph as follows:
43
44 This parameter is derived from the non-AP STA’s Extended Capabilities element, which is included in
45
46 (Re)Association Request frames. This parameter is also derived from the EHT Capabilities element of the
47 non-AP STA when the non-AP STA supports the (#5284)EPCS priority access. The AP SME obtains this
48 information from the MLME SAP, e.g., MLME-ASSOCIATE.indication primitive. This information needs
49 to be passed over the SSPN interface since the service authorization decisions can depend on the non-AP
50 STA capabilities.
51
52
53 Insert a new subclause at the end of subclause R.4.2 (SSPN interface parameters) as follows:
54
55 R.4.2.14 Authorized EPCS priority access type(#5284)
56
57
58 (#5284)This per-non-AP STA parameter indicates the priority type allocated to the non-AP STA as
59 determined by the SSPN. The AP uses this information to authorize requests for EPCS priority access.
60
61 The following is used:
62
63 — (#4172)(#5284)dot1EPCSPriorityAccessAuthorized is used to authorize a non-AP STA to enable
64 EPCS priority access
65

810 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2
Annex Z
3
4 (informative)
5
6
7 Change the title of the Annex as follows:
8
9
10
11
HE-SIG-B and EHT-SIG content examples(#3055)(#3063)
12
13
14 Z.1 General
15
16
17 Change as follows:
18
19 This annex provides a number of examples to illustrate the content of HE-SIG-B content channels and the
20 content of EHT-SIG content channels.
21
22
23 HE-SIG-B content channels are padded to the same length and to an OFDM symbol boundary as defined in
24 27.3.11.8.5 (Encoding and modulation). For illustration simplicity, the examples do not include the com-
25 plete padding bits but only pad to make the two HE-SIG-B content channels equal in length and an integer
26 number of 4 bits. All the padding bits in the examples are set to 0.
27
28
29 In the examples, the binary sequence of each HE-SIG-B field is in transmission order. For the entire content
30 of each HE-SIG-B content channel, the binary sequences are converted to hexadecimal listed in transmis-
31 sion order as pairs of hexadecimal digits, where the first bit transmitted is the LSB of the first transmitted
32
octet and is the LSB of the second hexadecimal digit.
33
34
35 EHT-SIG content channels are padded to the same length and to an OFDM symbol boundary as defined in
36 36.3.12.8.6 (Encoding and modulation). For illustration simplicity, the examples do not include the com-
37 plete padding bits but only pad to make different EHT-SIG content channels equal in length and an integer
38
number of 4 bits. All the padding bits in the examples are set to 0.
39
40
41 In the examples, the binary sequence of each EHT-SIG field is in transmission order. For the entire content
42 of each EHT-SIG content channel, the binary sequences are converted to hexadecimal listed in transmission
43 order as pairs of hexadecimal digits, where the first bit transmitted is the LSB of the first transmitted octet
44
45
and is the LSB of the second hexadecimal digit.
46
47 Change the title of the subclauses Z.2, Z.3, Z.4, and Z.5 as follows:
48
49
50
51 Z.2 HE-SIG-B example Example 1
52
53
54
55
Z.3 HE-SIG-B example Example 2
56
57
58 Z.4 HE-SIG-B example Example 3
59
60
61
62 Z.5 HE-SIG-B example Example 4
63
64
65 Insert the following at the end of the Annex:

Copyright © 2022 IEEE. All rights reserved. 811

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Z.6 EHT-SIG example 1

2
3
4 An example of the EHT-SIG field with U-SIG overflow and resource allocation signaling for an 80 MHz
5 OFDMA transmission using EHT MU PPDU are shown in Table Z-8 (U-SIG overflow example 1) and
6 Table Z-9 (Resource allocation signaling example 1) respectively.
7
8
9
Table Z-8—U-SIG overflow example 1
10
11
12 Subfield Indication Meaning
13
14 Spatial Reuse 1111 PSR_AND_NON_SRG_OBSS_PD_PROHIBITED.
15
16 GI+LTF Size 11 4 EHT-LTF and 3.2 µs GI.
17
18 Number Of EHT-LTF Symbols 001 2 EHT-LTF symbols.
19
20 LDPC Extra Symbol Segment 1 An LDPC extra symbol segment is present.
21
22 Pre-FEC Padding Factor 01 A pre-FEC padding factor of 1.
23 PE Disambiguity 0 The condition in Equation (36-94) is not met.
24
25 Disregard 1111
26
27
28
29 Table Z-9—Resource allocation signaling example 1
30
31
32 484+242-tone MRU 2
RU/MRU 242-tone RU 2
33 (242-[]-484)
34
35 SS1 STA-ID 1441, EHT-MCS 10, LDPC,
36 no Tx beamforming STA-ID 1442, EHT-MCS 4, BCC,
37 2SS, Tx beamforming
38 SS2 N/A
39
40
41
(#6473)The illustration of an RU Allocation subfield is given in Table Z-10 (Resource Allocation subfield
42
43 illustration example 1).
44
45
46 Table Z-10—Resource Allocation subfield illustration example 1
47
48
49 RU Allocation subfield illustration
50
51 Content channel 1 242-[]-484, MRU 2 (1 User field) 484 (0 User field)
52
53 Content channel 2 242 (1 User field) 484 (0 User field)
54
55
56
57
58
59
60
61
62
63
64
65

812 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 The User field for STA 1441 is in content channel 1 while User field for STA 1442 is in content channel 2.
2 The content of the entire EHT-SIG field for this example is shown in Table Z-11 (EHT-SIG content for
3
example 1).
4
5
6
7 Table Z-11—EHT-SIG content for example 1
8
9
10 EHT-SIG content channel 1 EHT-SIG content channel 2
11
12 Common field 1111 11 100 1 10 0 1111 1111 11 100 1 10 0 1111
13 (U-SIG Overflow, RU Alloca- 000101100 101110000 1000 000000 000000100 101110000 1000 000000
14 tion-1 subfield, CRC, Tail)
15
16 User Specific field 10000101101 01000101101
STA 1441 STA 1442
17 0101 1 0000 0 1 0010 1 1000 1 0
18 CRC and Tail 1010 000000 CRC and Tail 0001 000000
19
20 Padding 000 Padding 000
21
22 EHT-SIG field content in 11111110 01100111 10001011 11111110 01100111 10000001
23 binary, organized as octets 00101110 00010000 00000100 00101110 00010000 00000010
24 (LSB first) 00101101 01011000 00110100 00101101 00101100 01000010
25 00000000 00000000
26
27 EHT-SIG field content in 01111111 11100110 11010001 01111111 11100110 10000001
28 binary, organized as octets 01110100 00001000 00100000 01110100 00001000 01000000
29 (MSB first within each octet) 10110100 00011010 00101100 10110100 00110100 01000010
30 00000000 00000000
31
32 EHT-SIG field content in hexa- 7F E6 D1 74 08 20 B4 1A 2C 00 7F E6 81 74 08 40 B4 34 42 00
33 decimal, organized as octets
34
35
36
37 Z.7 EHT-SIG example 2
38
39 An example of the EHT-SIG field with U-SIG overflow and resource allocation signaling for an 80 MHz
40 OFDMA transmission using EHT MU PPDU are shown in Table Z-12 (U-SIG overflow example 2) and
41
Table Z-13 (Resource allocation signaling example 2) respectively.
42
43
44
45 Table Z-12—U-SIG overflow example 2
46
47
48 Subfield Indication Meaning
49
50 Spatial Reuse 1111 PSR_AND_NON_SRG_OBSS_PD_PROHIBITED.
51
52 GI+LTF Size 11 4 EHT-LTF and 3.2 µs GI.
53 Number Of EHT-LTF Symbols 011 6 EHT-LTF symbols.
54
55 LDPC Extra Symbol Segment 1 An LDPC extra symbol segment is present.
56
57 Pre-FEC Padding Factor 01 A pre-FEC padding factor of 1.
58
59 PE Disambiguity 0 The condition in Equation (36-94) is not met.
60
61 Disregard 1111
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 813

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2
3
4
Table Z-13—Resource allocation signaling example 2
5
6
7 484+242-tone MRU 2
8 RU/MRU 242-tone RU 2
(242-[]-484)
9
10 SS1
11 STA-ID 1441, EHT-MCS 10, LDPC, STA-ID 1442, EHT-MCS 4, BCC,
12 SS2 2SS 2SS, Tx beamforming
13
14 SS3 STA-ID 1443, EHT-MCS 7, LDPC
15 N/A
16 SS4 STA-ID 1445, EHT-MCS 5, LDPC
17
18
19
20 (#6473)The illustration of an RU Allocation subfield is given in Table Z-14 (Resource Allocation subfield
21 illustration example 2).
22
23
24
Table Z-14—Resource Allocation subfield illustration example 2
25
26
27 RU Allocation subfield illustration
28
29 Content channel 1 242-[]-484, MRU 2 (2 User fields) 484 (0 User field)
30
31 Content channel 2 242 (1 User field) 242-[]-484, MRU 2 (1 User field)
32
33
34
35 The AP can perform a dynamic split of the User fields for the three MU-MIMO STAs on 484+242-tone
36
MRU 2, with zero, one, two, or three User fields assigned to EHT-SIG content channel 1 and three, two,
37
38 one, or zero User fields assigned to EHT-SIG content channel 2 correspondingly. In this example, there are
39 two User fields assigned to EHT-SIG content channel 1 and one User field assigned to EHT-SIG content
40 channel 2, to avoid a disparity in the number of User fields between content channels.
41
42
43 The User fields for STA 1441 and STA 1443 are in content channel 1 while the User fields for STA 1445
44 and STA 1442 are in content channel 2. The content of the entire EHT-SIG field for this example is shown
45 in Table Z-15 (EHT-SIG content for example 2).
46
47
48
Table Z-15—EHT-SIG content for example 2
49
50
51 EHT-SIG content channel 1 EHT-SIG content channel 2
52
53 Common field 1111 11 110 1 10 0 1111 1111 11 110 1 10 0 1111 000000100
54 (U-SIG Overflow, RU Alloca- 100101100 101110000 1110 000000 000101100 1011 000000
55 tion-1 subfield, CRC, Tail)
56
57 User Specific field 10000101101 01000101101
58 STA 1441 STA 1442
0101 1 100000 0010 1 1000 1 0
59
60 11000101101 10100101101
STA 1443 STA 1445
61 1110 1 100000 1010 1 100000
62
63 CRC and Tail 1011 000000 CRC and Tail 1110 000000
64
65 Padding 0 Padding 0

814 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table Z-15—EHT-SIG content for example 2 (continued)

2
3
4 EHT-SIG content channel 1 EHT-SIG content channel 2
5
6 EHT-SIG field content in 11111111 01100111 11001011 11111111 01100111 10000001
7 binary, organized as octets 00101110 00011100 00000100 00000101 10010110 00000010
8 (LSB first) 00101101 01011100 00011000 00101101 00101100 01010100
9 10110111 10110000 01011000 0000 10110110 10110000 01110000 0000
10
11 EHT-SIG field content in 11111111 11100110 11010011 11111111 11100110 10000001
12 binary, organized as octets 01110100 00111000 00100000 10100000 01101001 01000000
13 (MSB first within each octet) 10110100 00111010 00011000 10110100 00110100 00101010
14 11101101 00001101 00011010 0000 01101101 00001101 00001110 0000
15
16 EHT-SIG field content in hexa- FF E6 D3 74 38 20 B4 3A 18 ED 0D FF E6 81 A0 69 40 B4 34 2A 6D 0D
17 decimal, organized as octets 1A 00 0E 00
18
19
20 Z.8 EHT-SIG example 3
21
22
23 An example of the EHT-SIG field with U-SIG overflow and resource allocation signaling for a 160 MHz
24 OFDMA transmission using EHT MU PPDU are shown in Table Z-16 (U-SIG overflow example 3) and
25 Table Z-17 (Resource allocation signaling example 3) respectively.
26
27
28
29 Table Z-16—U-SIG overflow example 3
30
31
32 Subfield Indication Meaning
33
34 Spatial Reuse 1111 PSR_AND_NON_SRG_OBSS_PD_PROHIBITED.
35 GI+LTF Size 11 4 EHT-LTF and 3.2 µs GI.
36
37 Number Of EHT-LTF Symbols 001 2 EHT-LTF symbols.
38
39 LDPC Extra Symbol Segment 1 An LDPC extra symbol segment is present.
40
41 Pre-FEC Padding Factor 01 A pre-FEC padding factor of 1.
42
43 PE Disambiguity 0 The condition in Equation (36-94) is not met.
44 Disregard 1111
45
46
47
48 Table Z-17—Resource allocation signaling example 3
49
50
51 996+484-tone MRU 2
RU/MRU 484-tone RU 2
52 (484-[]-996)
53
54 SS0 STA-ID 1441, EHT-MCS 10, LDPC,
55 no Tx beamforming STA-ID 1442, EHT-MCS 4, LDPC, 2SS, Tx beam-
56 forming
57 SS1 N/A
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 815

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#6473)The illustration of an RU Allocation subfield for the lower 80 MHz and upper 80 MHz are given in
2 Table Z-18 (Resource Allocation subfield illustration for the lower 80 MHz example 3) and Table Z-19
3
(Resource Allocation subfield illustration for the upper 80 MHz example 3).
4
5
6
7 Table Z-18—Resource Allocation subfield illustration for the lower 80 MHz example 3
8
9
10 RU Allocation subfield illustration
11
12 Content channel 1 484-[]-996, MRU 2 484 (0 User field) 996 (0 User field) 996 (0 User field)
13 (1 User field)
14
15 Content channel 2 484 (0 User field) 484 (1 User field) 996 (0 User field) 996 (0 User field)
16
17
18 Table Z-19—Resource Allocation subfield illustration for the upper 80 MHz example 3
19
20
21 RU Allocation subfield illustration
22
23 Content channel 1 484 (0 User field) 484 (0 User field) 996 (0 User field) 996 (0 User field)
24
25 Content channel 2 484 (0 User field) 484 (0 User field) 996 (0 User field) 996 (0 User field)
26
27
28
29 The EHT-SIG content channels per 80 MHz are allowed to carry different information when EHT MU
30 PPDU is wider than 80 MHz and for OFDMA transmission(#5433) to multiple users. In this example,
31 STA 1441 and STA 1442 are operating on the primary 80 MHz channel, which is the lower 80 MHz in this
32
example. The User field for STA 1441 is in content channel 1 while the User field for STA 1442 is in con-
33
34 tent channel 2 in the lower 80 MHz. No User field exists in the upper 80 MHz. The contents of the entire
35 EHT-SIG field in the lower 80 MHz and higher 80 MHz for this example are shown in Table Z-20 (EHT-
36 SIG content in the lower 80 MHz for example 3) and Table Z-21 (EHT-SIG content in the upper 80 MHz for
37 example 3), respectively. The EHT-SIG content channels per 80 MHz can also be the same.
38
39
40
41 Table Z-20—EHT-SIG content in the lower 80 MHz for example 3
42
43
44 EHT-SIG content channel 1 EHT-SIG content channel 2
45
46 Common field 1111 11 100 1 10 0 1111 1111 11 100 1 10 0 1111 101110000
47 (U-SIG Overflow, 2 RU Allo- 000100010 101110000 0010 000000 000100100 0000 000000 011110000
48 cation-1 subfields, CRC, Tail, 011110000 011110000 0101 000000 011110000 0101 000000
49 2 RU-Allocation-2 subfields,
50 CRC, Tail)
51 User Specific field STA 1441 10000101101 STA 1442 01000101101
52 0101 1 0000 0 1 0010 1 1000 1 1
53
54 CRC and Tail 1010 000000 CRC and Tail 0001 000000
55
56 Padding 000 Padding 000
57
58
59
60
61
62
63
64
65

816 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table Z-20—EHT-SIG content in the lower 80 MHz for example 3 (continued)

2
3
4 EHT-SIG content channel 1 EHT-SIG content channel 2
5
6 EHT-SIG field content in 11111110 01100111 10001000 11111110 01100111 11011100
7 binary, organized as octets 10101110 00000100 00000011 00000100 10000000 00000011
8 (LSB first) 11000001 11100000 10100000 11000001 11100000 10100000
9 01000010 11010101 10000011 00100010 11010010 11000110
10 01000000 0000 00100000 0000
11
12 EHT-SIG field content in 01111111 11100110 00010001 01111111 11100110 00111011
13 binary, organized as octets 01110101 00100000 11000000 00100000 00000001 11000000
14 (MSB first within each octet) 10000011 00000111 00000101 10000011 00000111 00000101
15 01000010 10101011 11000001 01000100 01001011 01100011
16 00000010 0000 00000100 0000
17
18 EHT-SIG field content in hexa- 7F E6 11 75 20 C0 83 07 05 42 AB 7F E6 3B 20 01 C0 83 07 05 44 4B
19 decimal, organized as octets C1 02 00 63 04 00
20
21
22 Table Z-21—EHT-SIG content in the upper 80 MHz for example 3
23
24
25 EHT-SIG content channel 1 EHT-SIG content channel 2
26
27 Common field 1111 11 100 1 10 0 1111 1111 11 100 1 10 0 1111
28 (U-SIG Overflow, 2 RU Allo- 101110000 101110000 1011 101110000 101110000 1011
29 cation-1 subfields, CRC, Tail, 000000 011110000 011110000 000000 011110000 011110000
30 2 RU-Allocation-2 subfields, 0101 000000 0101 000000
31 CRC, Tail)
32
33 User Specific field Padding 00000000 Padding 00000000
34 00000000 00000000
35 00000000 00000000
36 00000000 000 00000000 000
37
38 EHT-SIG field content in 11111110 01100111 11011100 11111110 01100111 11011100
39 binary, organized as octets 00101110 00010110 00000011 00101110 00010110 00000011
40 (LSB first) 11000001 11100000 10100000 11000001 11100000 10100000
41 00000000 00000000 00000000 00000000 00000000 00000000
42 00000000 0000 00000000 0000
43
44 EHT-SIG field content in 01111111 11100110 00111011 01111111 11100110 00111011
45 binary, organized as octets 01110100 01101000 11000000 01110100 01101000 11000000
46 (MSB first within each octet) 10000011 00000111 00000101 10000011 00000111 00000101
47 00000000 00000000 00000000 00000000 00000000 00000000
48 00000000 0000 00000000 0000
49 EHT-SIG field content in hexa- 7F E6 3B 74 16 C0 83 07 05 00 00 7F E6 3B 74 16 C0 83 07 05 00 00
50 decimal, organized as octets 00 00 00 00 00 00
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 817

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Z.9 EHT-SIG example 4

2
3
4 Another example of the EHT-SIG field with U-SIG overflow and resource allocation signaling for a
5 160 MHz OFDMA transmission using EHT MU PPDU are shown in Table Z-22 (U-SIG overflow
6 example 4) and Table Z-23 (Resource allocation signaling example 4) respectively.
7
8
9
Table Z-22—U-SIG overflow example 4
10
11
12 Subfield Indication Meaning
13
14 Spatial Reuse 1111 PSR_AND_NON_SRG_OBSS_PD_PROHIBITED.
15
16 GI+LTF Size 11 4 EHT-LTF and 3.2 µs GI.
17
18 Number Of EHT-LTF Symbols 011 6 EHT-LTF symbols.
19
20 LDPC Extra Symbol Segment 1 An LDPC extra symbol segment is present.
21
22 Pre-FEC Padding Factor 01 A pre-FEC padding factor of 1.
23 PE Disambiguity 0 The condition in Equation (36-94) is not met.
24
25 Disregard 1111
26
27
28
29 Table Z-23—Resource allocation signaling example 4
30
31
32 484+242-tone 484+242-tone
33 RU/MRU 242-tone RU 1 MRU 1 MRU 7 242-tone RU 7
34 ([]-242-484) (484-[]-242)
35
36 SS0 STA-ID 1441, STA-ID 1445, STA-ID 1447, STA-ID 1448,
37 EHT-MCS 8, BCC EHT-MCS 10, EHT-MCS 4, EHT-MCS 7,
38 LDPC, 2SS LDPC, 2SS, Tx LDPC
39 beamforming
40 SS1 STA-ID 1442, STA-ID 1449,
41 EHT-MCS 7, BCC EHT-MCS 6,
42 LDPC
43 SS2 STA-ID 1443, STA-ID 1446, N/A STA-ID 1450,
44 EHT-MCS 6, BCC EHT-MCS 4, EHT-MCS 5,
45 LDPC, LDPC
46 2SS(#5496)
47 SS3 STA-ID 1444, STA-ID 1451,
48 EHT-MCS 5, BCC EHT-MCS 5,
49 LDPC
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

818 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#6473)The illustration of an RU Allocation subfield for the lower 80 MHz and upper 80 MHz are given in
2 Table Z-24 (Resource Allocation subfield illustration for the lower 80 MHz example 4) and Table Z-25
3
(Resource Allocation subfield illustration for the upper80 MHz example 4).
4
5
6
7 Table Z-24—Resource Allocation subfield illustration for the lower 80 MHz example 4
8
9
10 RU Allocation subfield illustration
11
12 Content channel 1 242 (4 User fields) 484 (0 User field) 484 (0 User field) 242 (0 User field)
13
14 Content channel 2 []-242-484, MRU 1 484 (0 User field) 484 (0 User field) 242 (0 User field)
15 (2 User fields)
16
17
18 Table Z-25—Resource Allocation subfield illustration for the upper80 MHz example 4
19
20
21 RU Allocation subfield illustration
22
23 Content channel 1 242 (0 User field) 484 (0 User field) 484 (0 User field) 242 (4 User fields)
24
25 Content channel 2 242 (0 User field) 484 (0 User field) 484-[]-242, MRU 7 242 (0 User field)
26 (1 User field)
27
28
29
30 The EHT-SIG content channels per 80 MHz are allowed to carry different information when EHT MU
31 PPDU is wider than 80 MHz and for OFDMA transmission and for non-OFDMA transmission to multiple
32 users. In this example, STAs 1441–1446 are operating on the primary 80 MHz channel, which is the lower
33
80 MHz in this example, while STAs 1447–1451 are operating on the secondary 80 MHz channel, which is
34
35 the upper 80 MHz in this example. The User fields for STAs 1441–1444 are in content channel 1 while the
36 User fields for STAs 1445–1446 are in content channel 2 in the lower 80 MHz. The User fields for
37 STAs 1448–1451 are in content channel 1 while the User fields for STA 1447 is in content channel 2 in the
38 upper 80 MHz. The contents of the entire EHT-SIG field in the lower 80 MHz and upper 80 MHz for this
39
example are shown in Table Z-26 (EHT-SIG content in the lower 80 MHz for example 4) and Table Z-27
40
41 (EHT-SIG content in the upper 80 MHz for example 4), respectively. The EHT-SIG content channels per
42 80 MHz can also be the same..
43
44
45 Table Z-26—EHT-SIG content in the lower 80 MHz for example 4
46
47
48 EHT-SIG content channel 1 EHT-SIG content channel 2
49
50 Common field 1111 11 110 1 10 0 1111 110000100 1111 11 110 1 10 0 1111 100001100
51 (U-SIG Overflow, 2 RU Allo- 101110000 1000 000000 101110000 101110000 1011 000000 101110000
52 cation-1 subfields, CRC, Tail, 001110000 0110 000000 001110000 0110 000000
53 2 RU-Allocation-2 subfields,
54 CRC, Tail)
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 819

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table Z-26—EHT-SIG content in the lower 80 MHz for example 4 (continued)

2
3
4 EHT-SIG content channel 1 EHT-SIG content channel 2
5
6 User Specific field STA 1441 10000101101 STA 1445 10100101101
7 0001 0 000000 0101 1 001000
8
9 STA 1442 01000101101 STA 1446 01100101101
10 1110 0 000000 0010 1 001000
11
12 CRC and Tail 0011 000000 CRC and Tail 1100 000000
13 STA 1443 11000101101 Padding 00000000
14 0110 0 000000 00000000
15 00000000
16 STA 1444 00100101101 00000000
17 1010 0 000000 00000000
18 00000000
19 CRC and Tail 0010 000000 00000000 0
20
21 Padding 000
22
23 EHT-SIG field content in 11111111 01100111 11100001 11111111 01100111 11000011
24 binary, organized as octets 00101110 00010000 00000101 00101110 00010110 00000101
25 (LSB first) 11000000 11100000 11000000 11000000 11100000 11000000
26 01000010 11010001 00000000 01010010 11010101 10010000
27 10001011 01111000 00000001 11001011 01001010 01000110
28 10000001 10001011 01011000 00000000 00000000 00000000
29 00000001 00101101 10100000 00000000 00000000 00000000
30 00000100 00000000 00000000 00000000
31 EHT-SIG field content in 11111111 11100110 10000111 11111111 11100110 11000011
32 binary, organized as octets 01110100 00001000 10100000 01110100 01101000 10100000
33 (MSB first within each octet) 00000011 00000111 00000011 00000011 00000111 00000011
34 01000010 10001011 00000000 01001010 10101011 00001001
35 11010001 00011110 10000000 11010011 01010010 01100010
36 10000001 11010001 00011010 00000000 00000000 00000000
37 10000000 10110100 00000101 00000000 00000000 00000000
38 00100000 00000000 00000000 00000000
39
40 EHT-SIG field content in hexa- FF E6 87 74 08 A0 03 07 03 42 8B 00 FF E6 C3 74 68 A0 03 07 03 4A AB
41 decimal, organized as octets D1 1E 80 81 D1 1A 80 B4 05 20 00 09 D3 52 62 00 00 00 00 00 00 00 00
42
43
44
45 Table Z-27—EHT-SIG content in the upper 80 MHz for example 4
46
47
48 EHT-SIG content channel 1 EHT-SIG content channel 2
49
50 Common field 1111 11 110 1 10 0 1111 001110000 1111 11 110 1 10 0 1111 001110000
51 (U-SIG Overflow, 2 RU Allo- 1011100001101 000000 101110000 101110000 1101 000000 000011100
52 cation-1 subfields, CRC, Tail, 110000100 1011 000000 001110000 1010 000000
53 2 RU-Allocation-2 subfields,
54 CRC, Tail)
55
56
57
58
59
60
61
62
63
64
65

820 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table Z-27—EHT-SIG content in the upper 80 MHz for example 4 (continued)

2
3
4 EHT-SIG content channel 1 EHT-SIG content channel 2
5
6 User Specific field STA 1448 00010101101 STA 1447 11100101101
7 1110 1 000000 0010 1 1000 1 1
8
9 STA 1449 10010101101 CRC and Tail 0000 000000
10 0110 1 000000
11
12 CRC and Tail 1110 000000 Padding 00000000
13 00000000
STA 1450 01010101101 00000000
14 1010 1 000000
15 00000000
16 00000000
STA 1451 11010101101 00000000
17 1010 1 000000
18 00000000
19 CRC and Tail 1010 000000 00000000
20 00000000
21 Padding 000 0000000
22
23 EHT-SIG field content in 11111111 01100111 10011100 11111111 01100111 10011100
24 binary, organized as octets 00101110 00011010 00000101 00101110 00011010 00000000
25 (LSB first) 11000011 00001001 01100000 01110000 11100001 01000000
26 00001010 11011110 10000001 01110010 11010010 11000110
27 00101011 01011010 00000111 00000000 00000000 00000000
28 00000000 10101011 01101010 00000000 00000000 00000000
29 00000110 10101101 10101000 00000000 00000000 00000000
30 00010100 00000000 00000000 00000000
31 EHT-SIG field content in 11111111 11100110 00111001 11111111 11100110 00111001
32 binary, organized as octets 01110100 01011000 10100000 01110100 01011000 00000000
33 (MSB first within each octet) 11000011 10010000 00000110 00001110 10000111 00000010
34 01010000 01111011 10000001 01001110 01001011 01100011
35 11010100 01011010 11100000 00000000 00000000 00000000
36 00000000 11010101 01010110 00000000 00000000 00000000
37 01100000 10110101 00010101 00000000 00000000 00000000
38 00101000 00000000 00000000 00000000
39
40 EHT-SIG field content in hexa- FF E6 9C 2E 58 A0 C3 90 06 50 7B FF E6 9C 2E 58 00 0E 87 02 4E 4B
41 decimal, organized as octets 81 D4 5A E0 00 D5 56 60 B5 15 28 63 00 00 00 00 00 00 00 00 00 00 00
42 00
43
44
45
46 Z.10 EHT-SIG example 5
47
48
An example of the EHT-SIG field with U-SIG overflow and resource allocation signaling for an 80 MHz
49
50 DL non-OFDMA MU-MIMO transmission using EHT MU PPDU are shown in Table Z-28 (U-SIG over-
51 flow example 5) and Table Z-29 (Resource allocation signaling example 5) respectively.
52
53
54 Table Z-28—U-SIG overflow example 5
55
56
57 Subfield Indication Meaning
58
59 Spatial Reuse 1111 PSR_AND_NON_SRG_OBSS_PD_PROHIBITED.
60
61 GI+LTF Size 11 4 EHT-LTF and 3.2 µs GI.
62
63 Number Of EHT-LTF Symbols 010 4 EHT-LTF symbols.
64
65 LDPC Extra Symbol Segment 1 An LDPC extra symbol segment is present.

Copyright © 2022 IEEE. All rights reserved. 821

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table Z-28—U-SIG overflow example 5 (continued)

2
3
4 Subfield Indication Meaning
5
6 Pre-FEC Padding Factor 01 A pre-FEC padding factor of 1.
7
8 PE Disambiguity 0 The condition in Equation (36-94) is not met.
9
10 Disregard 1111
11 Number Of Non-OFDMA Users 010 3 non-OFDMA users
12
13
14
15
16
17
18
Table Z-29—Resource allocation signaling example 5
19
20
21 484+242-tone MRU 2
22 RU/MRU
(242-[]-484)
23
24 SS1
25 STA-ID 1441, EHT-MCS 10, LDPC,
26 SS2 2SS
27
28 SS3 STA-ID 1443, EHT-MCS 7, LDPC
29
30 SS4 STA-ID 1445, EHT-MCS 5, LDPC
31
32
33
34 The AP performs an equitable split of the User fields for the three MU-MIMO STAs on 484+242-tone
35 MRU 2, with two User fields assigned to EHT-SIG content channel 1 and one User field assigned to EHT-
36 SIG content channel 2. The User fields for STA 1441 and STA 1443 are in content channel 1 while User
37 field for STA 1445 is in content channel 2. The content of the entire EHT-SIG field for this example is
38
shown in Table Z-30 (EHT-SIG content for example 5).
39
40
41
42 Table Z-30—EHT-SIG content for example 5
43
44
45 EHT-SIG content channel 1 EHT-SIG content channel 2
46
47 (#5485)Common encoding 1111 11 010 1 10 0 1111 010 1111 11 010 1 10 0 1111 010
48 block (U-SIG Overflow, Num- 10000101101 0101 1 100000 10100101101 1010 1 100000
49 ber Of Non-OFDMA Users, 1110 000000 0101 000000
50 1st User Field, CRC, Tail)
51
52 User Specific field STA 1443 11000101101 Padding 0000 0000 0000
53 except for the 1st User field 1110 1 100000 0000 0000 0000
54 000 0000
CRC and Tail 0010 000000
55
56 Padding N/A
57
58
59
60
61
62
63
64
65

822 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table Z-30—EHT-SIG content for example 5 (continued)

2
3
4 EHT-SIG content channel 1 EHT-SIG content channel 2
5
6 EHT-SIG field content in 11111101 01100111 10101000 11111101 01100111 10101010
7 binary, organized as octets 01011010 10111000 00111000 01011011 01011000 00010100
8 (LSB first) 00001100 01011011 11011000 00000000 00000000 00000000
9 00001000 0000 0000000 0000
10
11 EHT-SIG field content in 10111111 11100110 00010101 10111111 11100110 01010101
12 binary, organized as octets 01011010 00011101 00011100 11011010 00011010 00101000
13 (MSB first within each octet) 00110000 11011010 00011011 00000000 00000000 00000000
14 00010000 0000 0000000 000
15
16 EHT-SIG field content in hexa- BF E6 15 5A 1D 1C 30 DA 1B 10 0 2F F9 95 76 86 8A 00 00 00 00 0
17 decimal, organized as octets
18
19
20 Z.11 EHT-SIG example 6
21
22
23 An example of the EHT-SIG field with U-SIG overflow and resource allocation signaling for an 80 MHz
24 DL non-OFDMA transmission to (#4851)a single user using EHT MU PPDU are shown in Table Z-31 (U-
25 SIG overflow example 6) and Table Z-32 (Resource allocation signaling example 6) respectively.
26
27
28
29 Table Z-31—U-SIG overflow example 6
30
31
32 Subfield Indication Meaning
33
34 Spatial Reuse 1111 PSR_AND_NON_SRG_OBSS_PD_PROHIBITED.
35 GI+LTF Size 10 4 EHT-LTF and 0.8 µs GI.
36
37 Number Of EHT-LTF Symbols 001 2 EHT-LTF symbols.
38
39 LDPC Extra Symbol Segment 1 An LDPC extra symbol segment is present.
40
41 Pre-FEC Padding Factor 01 A pre-FEC padding factor of 1.
42
43 PE Disambiguity 0 The condition in Equation (36-94) is not met.
44 Disregard 1111
45
46 Number Of Non-OFDMA Users 000 1 non-OFDMA user
47
48
49
50 Table Z-32—Resource allocation signaling example 6
51
52
53 484+242-tone MRU 2
RU/MRU
54 (242-[]-484)
55
56 SS1 STA-ID 1441, EHT-MCS 10, LDPC,
57 2SS, Tx beamforming
58 SS2
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 823

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 For non-OFDMA transmission to (#4851)a single user, there exists one content channel. The content of the
2 entire EHT-SIG field for this example is shown in Table Z-33 (EHT-SIG content for example 6).
3
4
5
6 Table Z-33—EHT-SIG content for example 6
7
8
9 EHT-SIG content channel 1
10
11 (#5485)Common encoding 1111 01 100 1 10 0 1111 000
12 block (U-SIG Overflow, Num- 10000101101 0101 1 1000 1 1
13 ber Of Non-OFDMA Users, 0001 000000
14 1st User Field, CRC, Tail)
15 EHT-SIG field content in 11110110 01100111 10001000
16 binary, organized as octets 01011010 10111000 11000100 0000
17 (LSB first)
18
19 EHT-SIG field content in 01101111 11100110 00010001
20 binary, organized as octets 01011010 00011101 00100011 0000
21 (MSB first within each octet)
22
23 EHT-SIG field content in hexa- 6F E6 11 5A 1D 23 0
24 decimal, organized as octets
25
26
27
28 Z.12 EHT-SIG example 7(#5496)
29
30
Examples of the EHT-SIG field with U-SIG Overflow and resource allocation, with signaling for a
31
32 320 MHz OFDMA transmission using EHT MU PPDU, are shown in Table Z-34 (U-SIG overflow
33 example 7 (#5496)) and Table Z-35 (Resource allocation signaling example 7 (#5496)), respectively,
34
35
36 Table Z-34—U-SIG overflow example 7 (#5496)
37
38
39 Subfield Indication Meaning
40
41 Spatial Reuse 1111 PSR_AND_NON_SRG_OBSS_PD_PROHIBITED.
42
43 GI+LTF Size 11 4 EHT-LTF and 3.2 µs GI.
44
45 Number Of EHT-LTF Symbols 010 4 EHT-LTF symbols.
46
47 LDPC Extra Symbol Segment 0 An LDPC extra symbol segment is not present.
48 Pre-FEC Padding Factor 01 A pre-FEC padding factor of 1.
49
50 PE Disambiguity 0 The condition in Equation (36-80) is not met.
51
52 Disregard 1111
53
54
55
56
57
58
59
60
61
62
63
64
65

824 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2
3
4
Table Z-35—Resource allocation signaling example 7 (#5496)
5
6
7 996+484-tone
8 RU/MRU 2996-tone RU 1 242-tone RU 9 242-tone RU 10 MRU 5
9 ([]-484-996)
10
11 SS0 STA-ID 1441, Unassigned Unassigned STA-ID 1443,
12 EHT-MCS 10, EHT-MCS 7,
13 LDPC LDPC
14
15 SS2 STA-ID 1442, STA-ID 1444,
16 EHT-MCS 4, EHT-MCS 8,
17 LDPC LDPC
18
19
20
21
22 In this example, the EHT-SIG content channels per 80 MHz frequency subband are set to the same values by
23 the AP. The EHT-SIG content channels per 80 MHz frequency subband can also be different.
24
25
26 The illustration of an RU Allocation subfield for each of the four 80 MHz frequency subbands is given in
27 Table Z-36 (RU Allocation subfield illustration for each 80 MHz frequency subband example 7(#5496)).
28
29
30 Table Z-36—RU Allocation subfield illustration for each 80 MHz frequency subband
31
32 example 7(#5496)
33
34
RU Allocation subfield illustration
35
36
Content 2996 996 996 996 Unas- 484 996 996
37
channel 1 (2 User (0 User (0 User (0 User signed (0 User (0 User (0 User
38
fields) field) field) field) 242 field) field) field)
39
40 Content 996 996 996 996 Unas- []-484- 996 996
41 channel 2 (0 User (0 User (0 User (0 User signed 996 (0 User (0 User
42 field) field) field) field) 242 MRU 5 field) field)
43 (2 User
44 fields)
45
46
47
48
49 The AP can perform a dynamic split of the User fields for the two MU-MIMO STAs on 2996-tone RU 1,
50 with zero, one, or two User fields assigned to EHT-SIG content channel 1 and correspondingly two, one, or
51 zero User fields assigned to EHT-SIG content channel 2. The AP can also perform a dynamic split of the
52 User fields for the two MU-MIMO STAs on 996+484-tone MRU 5, with zero, one, or two User fields
53
54
assigned to EHT-SIG content channel 1 and correspondingly two, one, or zero User fields assigned to EHT-
55 SIG content channel 2. In this example, for 2996-tone RU 1, two User fields are assigned to EHT-SIG con-
56 tent channel 1 and zero User field is assigned to EHT-SIG content channel 2. For 996+484-tone MRU 5,
57 zero User field is assigned to EHT-SIG content channel 1 and two User fields are assigned to EHT-SIG con-
58 tent channel 2. Overall, there are two User fields assigned to EHT-SIG content channel 1 and two User
59
60
fields assigned to EHT-SIG content channel 2, to avoid a disparity in the number of User fields between
61 content channels.
62
63
64 The User fields for STAs 1441 and 1442 are in content channel 1, while the User fields for STAs 1443 and
65 1444 are in content channel 2. The contents of EHT-SIG field in each 80 MHz frequency subband for this

Copyright © 2022 IEEE. All rights reserved. 825

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 example is shown in Table Z-37 (EHT-SIG content in each 80 MHz frequency subband for
2 example 7(#5496)).
3
4
5
6 Table Z-37—EHT-SIG content in each 80 MHz frequency subband for example 7(#5496)
7
8
9 EHT-SIG content channel 1 EHT-SIG content channel 2
10
11 Common encoding block (U- 1111 11 010 0 10 0 1111 1111 11 010 0 10 0 1111
12 SIG Overflow, 2 RU Alloca- 100110100 011110000 1100 000000 011110000 011110000 0110 000000
13 tion-1 subfields, CRC, Tail, 6 011110000 011110000 110110000 011110000 011110000 110110000
14 RU Allocation-2 subfields 101110000 011110000 011110000 100000010 011110000 011110000
15 CRC, Tail) 0111 000000 1011 000000
16 User Specific field STA 1441 10000101101 STA 1443 11000101101
17 0101 1 000000 1110 1 000000
18
19 STA 1442 01000101101 STA 1444 00100101101
20 0010 1 000000 0001 1 000000
21
22 CRC and Tail 1101 000000 CRC and Tail 0010 000000
23
24 Padding 000000 Padding 000000
25
26 EHT-SIG field content in 11111101 00100111 11001101 11111101 00100111 10111100
27 binary, organized as octets 00011110 00011000 00000011 00011110 00001100 00000011
28 (LSB first) 11000001 11100001 10110000 11000001 11100001 10110000
29 10111000 00111100 00011110 10000001 00111100 00011110
30 00001110 00000100 00101101 00010110 00000110 00101101
31 01011000 00001000 10110100 11101000 00000100 10110100
32 10100000 01101000 00000000 01100000 00010000 00000000
33 EHT-SIG field content in 10111111 11100100 10110011 10111111 11100100 00111101
34 binary, organized as octets 01111000 00011000 11000000 01111000 00110000 11000000
35 (MSB first within each octet) 10000011 10000111 00001101 10000011 10000111 00001101
36 00011101 00111100 01111000 10000001 00111100 01111000
37 01110000 00100000 10110100 01101000 01100000 10110100
38 00011010 00010000 00101101 00010111 00100000 00101101
39 00000101 00010110 00000000 00000110 00001000 00000000
40
41 EHT-SIG field content in hexa- BF E4 B3 78 18 C0 83 87 0D 1D 3C BF E4 3D 78 30 C0 83 87 0D 81 3C
42 decimal, organized as octets 78 70 20 B4 1A 10 2D 05 16 00 78 68 60 B4 17 20 2D 06 08 00
43
44
45
46 Z.13 EHT-SIG example 8
47
48
49 An example of the EHT-SIG field with U-SIG overflow and resource allocation signaling for a 160 MHz
50 OFDMA transmission using EHT MU PPDU are shown in Table Z-38 (U-SIG overflow example 8) and
51
Table Z-39 (Resource allocation signaling example 8), respectively. This example covers the cases with pre-
52
53 amble puncturing, small RUs, and small MRUs combined with large RUs/MRUs.
54
55
56 Table Z-38—U-SIG overflow example 8
57
58
59 Subfield Indication Meaning
60
61 Spatial Reuse 1111 PSR_AND_NON_SRG_OBSS_PD_PROHIBITED.
62
63 GI+LTF Size 11 4 EHT-LTF and 3.2 µs GI.
64
65 Number Of EHT-LTF Symbols 010 4 EHT-LTF symbols.

826 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 Table Z-38—U-SIG overflow example 8 (continued)

2
3
4 Subfield Indication Meaning
5
6 LDPC Extra Symbol Segment 1 An LDPC extra symbol segment is present.
7
8 Pre-FEC Padding Factor 01 A pre-FEC padding factor of 1.
9
10 PE Disambiguity 0 The condition in Equation (36-94) is not met.
11 Disregard 1111
12
13
14
15
16
17
18
Table Z-39—Resource allocation signaling example 8
19
20
21 484+242-tone 484+242-tone
22 106+26-tone
RU/MRU 242-tone RU 1 MRU 1 MRU 8 106-tone RU 15
23 MRU 16
([]-242-484) (484-242-[])
24
25 SS1 Punctured STA-ID 1441, STA-ID 1443, STA-ID 1444, STA-ID 1445,
26 EHT-MCS 10, EHT-MCS 8, EHT-MCS 4, EHT-MCS 7,
27 LDPC, 2SS LDPC, 2SS, BCC, BCC,
28 Tx beamforming Tx beamforming Tx beamforming
29
30 SS2 N/A
31
32 SS3 STA-ID 1442, N/A
33 EHT-MCS 4,
34 SS4 LDPC, 2SS
35
36
37
38 In this example, the EHT-SIG content channels per 80 MHz frequency subblock are set to the same values
39
by the AP. The EHT-SIG content channels per 80 MHz frequency subblock can also be different. The illus-
40
41 tration of an RU Allocation subfield for each of the two 80 MHz frequency subblocks is given in Table Z-40
42 (RU Allocation subfield illustration for each 80 MHz frequency subband example 8).
43
44
45 Table Z-40—RU Allocation subfield illustration for each 80 MHz frequency subband
46
example 8
47
48
49 RU Allocation subfield illustration
50
51 Content Punctured 242 484 484-242-[], 242
52 channel 1 (0 User field) MRU 8 (0 User field)
53 (1 User field)
54
55 Content []-242-484, 484 484 106 +
56 channel 2 MRU 1 (0 User field) (0 User field) (106+26) RU 15
57 (2 User fields) + MRU 16
58 (2 User fields)
59
60
61
62
In this example, STAs 1441–1445 are operating on the primary 80 MHz channel, which is the lower
63
64 80 MHz. The User field for STA 1443 is in content channel 1 while the User fields for STAs 1441, 1442,
65 1444, and 1445 are in content channel 2 in the lower 80 MHz. No User fields exist in the upper 80 MHz. The

Copyright © 2022 IEEE. All rights reserved. 827

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 contents of the entire EHT-SIG field in each 80 MHz for this example is shown in Table Z-41 (EHT-SIG
2 content in each 80 MHz frequency subband for example 8).
3
4
5
6 Table Z-41—EHT-SIG content in each 80 MHz frequency subband for example 8
7
8
9 EHT-SIG content channel 1 EHT-SIG content channel 2
10
11 Common encoding block (U- 1111 11 010 1 10 0 1111 1111 11 010 1 10 0 1111
12 SIG Overflow, 2 RU Alloca- 010110000 101110000 0110 000000 100001100 101110000 1101 000000
13 tion-1 subfields, CRC, Tail, 2 000111100 001110000 1111 000000 101110000 010011000 1111 000000
14 RU Allocation-2 subfields
15 CRC, Tail)
16 User Specific field STA 1443 11000101101 STA 1441 10000101101
17 0001 1 1000 1 1 0101 1 001000
18
19 CRC and Tail 1100 000000 STA 1442 01000101101
20 0010 1 001000
21
22 Padding 00000000 CRC and Tail 1100 000000
23 00000000
24 00000000 STA 1444 00100101101
25 00000000 0010 1 0000 1 0
26 00000000
27 00000000 STA 1445 10100101101
28 00000000 1110 1 0000 1 0
29 00000000 CRC and Tail 0110 000000
30 00000000
31 0000000 Padding 000
32
33 EHT-SIG field content in 11111101 01100111 10101100 11111101 01100111 11000011
34 binary, organized as octets 00101110 00001100 00000000 00101110 00011010 00000101
35 (LSB first) 11110000 11100001 11100000 11000001 00110001 11100000
36 01100010 11010001 11000111 01000010 11010101 10010000
37 10000000 00000000 00000000 10001011 01001010 01000110
38 00000000 00000000 00000000 00000000 01001011 01001010
39 00000000 00000000 00000000 00010101 00101101 11101000
40 00000000 00000000 01001100 00000000
41
42 EHT-SIG field content in 10111111 11100110 00110101 10111111 11100110 11000011
43 binary, organized as octets 01110100 00110000 00000000 01110100 01011000 10100000
44 (MSB first within each octet) 00001111 10000111 00000111 10000011 10001100 00000111
45 01000110 10001011 11100011 01000010 10101011 00001001
46 00000001 00000000 00000000 11010001 01010010 01100010
47 00000000 00000000 00000000 00000000 11010010 01010010
48 00000000 00000000 00000000 10101000 10110100 00010111
49 00000000 00000000 00110010 00000000
50
51 EHT-SIG field content in hexa- BF E6 35 74 30 00 0F 87 07 46 8B 73 BF E6 C3 74 58 A0 83 8C 07 42 AB
52 decimal, organized as octets 01 00 00 00 00 00 00 00 00 00 00 09 D1 52 62 00 D2 52 A8 B4 17 32
53 00
54
55
56
57
58
59
60
61
62
63
64
65

828 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1
2
Annex AA
3
4 (informative)
5
6
7
8 Multiple BSSID configuration examples
9
10
11
12 AA.1 Introduction
13
14
15 Change as follows:
16
17 This annex provides examples showing the relationship between profile periodicity (indicated by the Full
18 Set Rx Periodicity field in the Multiple BSSID Configuration element) and the DTIM interval (DTIM Period
19
20
field in the Multiple BSSID-Index element) for a multiple BSSID set as described in 11.1.3.8.3 (Discovery
21 of a nontransmitted BSSID profile). The examples provide guidance on how an AP might organize the
22 advertisement of nontransmitted BSSID profiles in its Beacon frames if it cannot fit all the profiles in a sin-
23 gle Beacon frame (i.e., partial list of profiles) it is advertising. By having the DTIM interval for a nontrans-
24 mitted BSSID a multiple of the profile periodicity, the profile for that BSSID would always appear in its
25
26
DTIM beacon. This helps an associated non-AP STA save power as it is able to receive any updates to the
27 profile when it wakes to receive the DTIM beacon.
28
29 (#1095)(#2292)(#2540)In addition, this annex also provides examples illustrating the relationship between
30
31
multiple BSSID set, co-hosted BSSID set, and multi-link operation.
32
33 Change the title of the subclause AA.2 as follows:
34
35
36
37 AA.2 Examples illustrating the relationship between profile periodicity and
38 DTIM interval
39
40
41 Move the following content from subclause AA.1 as the first paragraph of this subclause and
42 change as follows:
43
44
45 (#8252)The examples provide guidance on how an AP might organize the advertisementinclusion of
46 nontransmitted BSSID profiles in its Beacon frames if it cannot fit all the profiles in a single Beacon frame
47 (i.e., the AP advertises partial list of profiles) it is advertising. By havingselecting the DTIM interval for a
48 nontransmitted BSSID as a multiple of the profile periodicity, the profile for that BSSID would always
49 appear in its DTIM beacon. This helps an associated non-AP STA save power by not having to wake up,
50
51 from doze state, for listening to beacons other than the DTIM beaconas it is able to receive any updates to
52 theits associated profile when it wakes to receive the DTIM beacon.
53
54 Insert a new subclause AA.3 following subclause AA.2:
55
56
57
58 AA.3 Example illustrating the relationship between multi-link operation and
59
60
multiple BSSID set or co-hosted BSSID set(#1095)(#2292)(#2540)
61
62 (#4203)(#2295)Each AP (#6581)affiliated with an AP MLD can correspond to a transmitted or a
63
64 nontransmitted BSSID in a multiple BSSID set, or to an AP belonging to a co-hosted BSSID set, or to an AP
65 that is neither a member of a multiple BSSID set nor a member of a co-hosted BSSID set.

Copyright © 2022 IEEE. All rights reserved. 829

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 (#8253)The first example illustrates the case where APs on each channel belong to a multiple BSSID set.
2 APs affiliated with the same AP MLD have the same properties (such as security, etc.). Therefore, APs
3
belonging to the same multiple BSSID set on a channel are not affiliated with the same AP MLD.
4
5 Figure AA-6 (Example of affiliated APs from different multiple BSSID sets(#8253)) shows an example
6 where APs affiliated with an AP MLD belong to a multiple BSSID set on their respective channel. Further,
7 APs within the same AP MLD may correspond to a transmitted or nontransmitted BSSID.
8
9
10 MLD 1 MLD 2 MLD 3
11
12
BSSID‐x BSSID‐y [T]
13 Channel 1 o o
14 (Link 0) (Link 0)
Multiple BSSID
15 set on channel 1
16
17
18 BSSID‐p BSSID‐r
BSSID‐q [T]
19 Channel 2 o o o
20 (Link 1) (Link 0) (Link 1)
Multiple BSSID
21 set on channel 2
22
23
24 BSSID‐a [T] BSSID‐b BSSID‐c
25 Channel 3 o o o
(Link 2) (Link 1)
26 Multiple BSSID
27 set on channel 3
28
29 Figure AA-6—Example of affiliated APs from different multiple BSSID sets(#8253)
30
31
32
33 (#8253)Figure AA-6 (Example of affiliated APs from different multiple BSSID sets(#8253)) illustrates that
34
35
APs corresponding to BSSID-x and BSSID-y belong to the same multiple BSSID set on channel 1 and are
36 affiliated with different AP MLDs (MLD 1 and MLD 3, respectively). On channel 1, AP-y, affiliated with
37 MLD 3, corresponds to the transmitted BSSID (depicted as BSSID-y [T]) for the multiple BSSID set on
38 channel 1. On channel 2, there are three APs that belong to the same multiple BSSID set and each is affili-
39 ated with a different AP MLD. AP-q, affiliated with MLD 2, corresponds to the transmitted BSSID
40
41
(depicted as BSSID-q [T]) for the multiple BSSID set on channel 2. On channel 3, there are three APs which
42 belong to the same multiple BSSID set and two of the APs are affiliated with two different MLDs. AP-a,
43 affiliated with MLD 1, corresponds to the transmitted BSSID (depicted as BSSID-a [T]) for the multiple
44 BSSID set on channel 3. AP-c is a not affiliated with any AP MLD. Each AP MLD independently assigns a
45 Link ID to its affiliated APs (shown as “(Link n)” in the example).
46
47
48 (#8253)(#1819)The second example illustrates the case where APs affiliated with an AP MLD belong to a
49 mix of a multiple BSSID set, a co-hosted BSSID set and an AP that is neither a member of multiple BSSID
50 set nor a member of a co-hosted BSSID set. APs affiliated with the same AP MLD have same properties
51 (such as security, etc.). Therefore, APs belonging to the same co-hosted BSSID set on a channel are not
52
53
affiliated with the same AP MLD and APs belonging to the same multiple BSSID set on a channel are not
54 affiliated with the same AP MLD. Figure AA-7 (Example of affiliated APs belonging to a multiple BSSID
55 set, a co-hosted BSSID set, and neither of these two cases(#1819)(#8253)) shows an example where APs
56
57
58
59
60
61
62
63
64
65

830 Copyright © 2022 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 IEEE P802.11be/D1.5, March 2022

1 affiliated with an AP MLD belong to a mix of multiple BSSID set, co-hosted set, and neither a member of
2 multiple BSSID set nor a member of a co-hosted BSSID set.
3
4
5 MLD 1 MLD 2 MLD 3
6
7
8 BSSID‐x BSSID‐z BSSID‐y [T]
9 Channel 1 o o o
(Link 0) (Link 0) (Link 0) Multiple BSSID
10
11 set on channel 1
12
13
14 BSSID‐p BSSID‐q BSSID‐r
15 Channel 2 o o o
(Link 1) (Link 1) (Link 1)
16 Co‐hosted BSSID
17 set on channel 2
18
19
20 BSSID‐b
Channel 3 o
21 AP‐b not part of Multiple (Link 2)
22 BSSID set or co‐hosted set
23
24
25
26
Figure AA-7—Example of affiliated APs belonging to a multiple BSSID set, a co-hosted
27 BSSID set, and neither of these two cases(#1819)(#8253)
28
29 (#8253)(#1819)As seen from Figure AA-7 (Example of affiliated APs belonging to a multiple BSSID set, a
30
31 co-hosted BSSID set, and neither of these two cases(#1819)(#8253)), APs corresponding to BSSID-x,
32 BSSID-z, and BSSID-y belong to the same multiple BSSID set on channel 1 and are affiliated with different
33 AP MLDs (MLD 1, MLD 2, and MLD 3, respectively). On channel 1, AP-y, affiliated with MLD 3,
34 corresponds to the transmitted BSSID (depicted as BSSID-y [T]) for the multiple BSSID set on channel 1.
35 The three APs on channel 2, AP-p, AP-q, and AP-r, belong to the same co-hosted BSSID set and each is
36
37 affiliated with a different AP MLD, MLD 1, MLD 2, and MLD 3, respectively. On channel 3, there is a
38 single AP (AP-b) that is affiliated with MLD 2. Each AP MLD independently assigns a Link ID to its
39 affiliated APs (shown as “(Link n)” in this example).
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Copyright © 2022 IEEE. All rights reserved. 831

This is an unapproved IEEE Standards Draft, subject to change.