Leader based Multicast Service Proposal

Yongho Seok, Thierry Turletti, Diego Dujovne, Emily Qi, Adrien Stephens, Alex Ashley, Menzo Wentink, Pedro Cuenca

<figure><img src="image_1.png" /></figure>

To cite this version:

Yongho Seok, Thierry Turletti, Diego Dujovne, Emily Qi, Adrien Stephens, et al. Leader based Multicast Service Proposal. 2007. hal-04650253

HAL Id: hal-04650253

https://inria.hal.science/hal-04650253v1

Submitted on 16 Jul 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
IEEE P802.11
Wireless LANs

Leader based Multicast Service Proposal

Date: 2007-07-17

Author(s):

<table><thead><tr><td>Name</td><td>Company</td><td>Address</td><td>Phone</td><td>Email</td></tr></thead><tbody><tr><td>Yongho Seok</td><td>LG Electronics</td><td>16 Woomyeon-Dong, Seocho-Gu, Seoul 137-724, Korea</td><td>+8225264225</td><td>vhseok@lge.com</td></tr><tr><td>Thierry Turletti Diego Dujovne</td><td>INRIA</td><td>2004, route des Lucioles, Sophia Antipolis, France</td><td>+33492387879</td><td>turletti@sophia.inria.fr<br>ddujovne@sophia.inria.fr</td></tr><tr><td>Emily Qi</td><td>Intel Corporation</td><td>2111 NE 25th Hillsboro OR 97124, USA</td><td>+15032647799</td><td>Emily.h.qi@intel.com</td></tr><tr><td>Menzo Wentink</td><td>Conexant</td><td>Oudegracht 3a, Utrecht, Netherlands</td><td>+31651836231</td><td>Menzo.wentink@conexant.com</td></tr><tr><td>Pedro CUENCA</td><td>Universidad de Castilla-La Mancha</td><td>EPSA, Campus Universitario s/n., Albacete, Spain</td><td>+34967599200</td><td>puenca@dsi.uclm.es</td></tr></tbody></table>

Abstract

This document contains proposed changes to the IEEE P802.11v Draft to address Req 2120 of the TGv Objectives. In particular, to enhance multicast data delivery, the proposed changes enable the utilization of leader-based transmission mechanisms. Such mechanisms aim to improve the throughput fairness between multicast connections and point-to-point connections and can optionally increase the reliability of multicast transmissions. Leader-based mechanisms consist of a leader election protocol and a multicast acknowledgement mechanism. The leader election protocol is responsible for electing the station, called leader, which generates an ACK frame for each successfully received multicast frame. If the AP does not receive an ACK frame, it carries out the binary exponential backoff mechanism as it is the case for point-to-point connections. Furthermore, the proposed leader-based mechanism can optionally retransmit multicast frames and use RTS/CTS exchange when multicast frames are exchanged.

The text is aligned with P802.11v-D0.08.

**Notice:** This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.

**Release:** The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE's name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE's sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11.

**Patent Policy and Procedures:** The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http://ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair <stuart@ok-brit.com> as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>.
### 3. Definitions

Insert the following new definitions:

**3.v.5 Leader Based Multicast Service (LBMS):** A service aims to improve the throughput fairness between multicast connections and point-to-point connections and can optionally increase the reliability of multicast transmissions.

### 4. Abbreviations and acronyms

Insert the following new acronyms in alphabetical order:

LBMS Leader Based Multicast Service

#### 7.2.3.4 Association Request frame format

Insert new rows into table 10 as shown below:

<table><caption>Table 10—Association Request frame body</caption><thead><tr><td>Order</td><td>Information</td><td>Notes</td></tr></thead><tbody><tr><td>11</td><td>Wireless Network Management Capability</td><td>Wireless Network Management Capability element is present if dot11WirelessManagementImplemented is true.</td></tr><tr><td>12</td><td>FBMS Request</td><td>FBMS Request element may be present if dot11WirelessManagementImplemented is true and FBMS bit in the Wireless Network Management Capability is set to 1.</td></tr><tr><td>13</td><td>Presence Parameters</td><td>The Presence Parameters element is present if dot11WirelessManagementImplemented is true and the Presence bit in the Wireless Network Management Capabilities element is set to 1.</td></tr><tr><td>14</td><td>Traffic Generation</td><td>The Traffic Generation element is present if dot11WirelessManagementImplemented is true.</td></tr><tr><td>15</td><td>Supported Regulatory Classes</td><td>Supported Regulatory Classes element is present if dot11WirelessManagementImplemented is true.</td></tr><tr><td>16</td><td>LBMS Request</td><td>LBMS Request element may be present if dot11WirelessManagementImplemented is true and LBMS bit in the Wireless Network Management Capability is set to 1.</td></tr></tbody></table>

NOTE— last entry in 11ma-D9.0 has order 6 and last entry in 802.11r-D4.0 has order 11.

#### 7.2.3.6 Reassociation Request frame format
Insert new rows into table 12 as shown below:

<table><caption>Table 12—Reassociation Request frame body</caption><thead><tr><td>Order</td><td>Information</td><td>Notes</td></tr></thead><tbody><tr><td>14</td><td>Wireless Network Management Capability</td><td>Wireless Network Management Capability element is present if dot11WirelessManagementImplemented is true.</td></tr><tr><td>15</td><td>FBMS Request</td><td>FBMS Request element may be present if dot11WirelessManagementImplemented is true and the FBMS bit in the Wireless Network Management Capability is set to 1.</td></tr><tr><td>16</td><td>Presence Parameters</td><td>The Presence Parameters element is present if dot11WirelessManagementImplemented is true and the Presence bit in the Wireless Network Management Capability element is set to 1.</td></tr><tr><td>17</td><td>Traffic Generation</td><td>The Traffic Generation element is present if dot11WirelessManagementImplemented is true.</td></tr><tr><td>18</td><td>Supported Regulatory Classes</td><td>Supported Regulatory Classes element is present if dot11WirelessManagementImplemented is true.</td></tr><tr><td>16</td><td>LBMS Request</td><td>LBMS Request element may be present if dot11WirelessManagementImplemented is true and LBMS bit in the Wireless Network Management Capability is set to 1.</td></tr></tbody></table>

NOTE— last entry in 11ma-D8.0 has order 10 and last entry in 802.11r-D4.0 has order 13.

Change 7.3.2.49 as shown:

### 7.3.2.49 Wireless Network Management Capability information element

The Wireless Network Management Capability Information element contains information about the wireless network management capabilities of a STA as shown in Table v15.

<figure><img src="image_3.png" /><figcaption>Figure v15—Wireless Network Management Capability information element format</figcaption></figure>

The Element ID field is equal to the Wireless Network Management Capability value in Table 26.

The value of the length field is variable and depends on the length of the Wireless Network Management Capabilities field. The minimum value of the Length field is 2.

The Wireless Network Management Capabilities field is a bit-field indicating the advertised management capabilities of the STA. The Wireless Network Management Capabilities field is shown in Table v16.
<figure><img src="image_4.png" /><figcaption>Figure v16—Wireless Network Management Capabilities</figcaption></figure>

- The Event Log bit set to 1 indicates the STA supports Event Log as described in 11.15.2. The Event Log bit set to 0 indicates that the STA does not support this service.

- The Diagnostics bit set to 1 indicates the STA supports Diagnostics as described in 11.15.3. The Diagnostics bit set to 0 indicates that the STA does not support this service.

- The Multicast Alert bit set to 1 indicates the STA supports Multicast diagnostics as described in 11.15.11. The Multicast Alert bit set to 0 indicates that the STA does not support this service.

- The Presence bit set to 1 indicates that the STA supports Presence as described in 11.15.4. The Presence bit set to 0 indicates that the STA does not support this service.

- The FBMS bit set to 1 indicates the STA supports FBMS as described in 11.2.1.5. The FBMS bit set to 0 indicates the STA does not support FBMS.

- The Proxy ARP Service bit set to 1 indicates the AP is providing proxy ARP service. If Proxy ARP service is enabled, then the AP responds to broadcast ARP request on behalf of the STA. The Proxy ARP Service bit set to 0 indicates the AP is not providing proxy ARP service for any associated STA.

- The Co-located Interference Reporting bit set to 1 indicates the STA supports Co-located Interference Reporting as described in 11.15.9. The Co-located Interference Reporting bit set to 0 indicates that the STA does not support this service.

- The LBMS bit set to 1 indicates the STA supports the LBMS as described in 9.2.7.2. The LBMS bit set to 0 indicates that the STA does not support the LBMS.

- All other bits are reserved, and are set to 0 on transmission and ignored on reception.

The lack of a Wireless Network Management Capability element is interpreted as the STA having no advertised Wireless Network Management Capabilities.

Insert the following after 7.3.2.63:

### 7.3.2.64 LBMS Request element

The LBMS Request element defines information about the leader based multicast service being requested by the non-AP STA. The format of LBMS Request element is shown in Figure v107.

<figure><img src="image_5.png" /></figure>
**Figure v107—LBMS Request element format**

The Length field is set to n, where n indicates the total length of all LBMS Sub-elements contained in the element.
The format of the LBMS sub-element is shown in Figure v108.

<table><thead><tr><th></th><th>Multicast Address</th><th>LBMS Option</th></tr></thead><tbody><tr><td>Octets:</td><td>6</td><td>1</td></tr></tbody></table>

**Figure v108— LBMS Sub-element format**

The Multicast Address field is set to the MAC address corresponding to the multicast group for initiating a LBMS.

The LBMS Option field is a bit field as defined in Figure v109.

<table><thead><tr><th></th><th>Multicast ACK Policy</th><th>Retry Limit</th><th>Reserved</th></tr></thead><tbody><tr><td>Bit:</td><td>0</td><td>1 - 3</td><td>4 - 7</td></tr></tbody></table>

**Figure v109— LBMS Option field**

**Table v48—Multicast ACK Policy encoding**

<table><thead><tr><th>Value</th><th>Description</th></tr></thead><tbody><tr><td>0</td><td>No ACK</td></tr><tr><td>1</td><td>Normal ACK</td></tr></tbody></table>

- ACK Policy identifies the acknowledgement policy that is followed upon the delivery of the multicast MPDU. The interpretation of Multicast ACK Policy field is given in Table v48.

- Retry Limit is used to indicate the maximum retry limit of the multicast frames.

*Change 7.4.8 as shown:*

**7.4.8 Wireless Network Management action details**

Several Action frame formats are defined for Wireless Network Management purposes. An Action field, in the octet field immediately after the Category field, differentiates the formats. The Action field values associated with each frame format are defined in Table v49.

**Table v49—Wireless Network Management Action field values**
<table><thead><tr><td>Action field value</td><td>Description</td></tr></thead><tbody><tr><td>0</td><td>Event Log Request</td></tr><tr><td>1</td><td>Event Log Report</td></tr><tr><td>2</td><td>Diagnostic Request</td></tr><tr><td>3</td><td>Diagnostic Report</td></tr><tr><td>4</td><td>Presence Request</td></tr><tr><td>5</td><td>Presence Response</td></tr><tr><td>6</td><td>Presence Configuration Request</td></tr><tr><td>7</td><td>Presence Configuration Response</td></tr><tr><td>8</td><td>BSS Transition Management Query</td></tr><tr><td>9</td><td>BSS Transition Management Request</td></tr><tr><td>10</td><td>BSS Transition Management Response</td></tr><tr><td>11</td><td>FBMS Request</td></tr><tr><td>12</td><td>FBMS Response</td></tr><tr><td>13</td><td>Co-located Interference Request</td></tr><tr><td>14</td><td>Co-located Interference Response</td></tr><tr><td>15</td><td>LBMS Request</td></tr><tr><td>16</td><td>LBMS Report</td></tr><tr><td>17-255</td><td>Reserved</td></tr></tbody></table>

Insert the following after 7.4.8.15:

### 7.4.8.16 LBMS Request

The LBMS Request frame uses the Action frame body format. The format of the LBMS Request frame body is shown in Figure v105.

<table><thead><tr><td>Category</td><td>Action</td><td>LBMS Request Element</td></tr></thead></table>

Octets: 1 1 variable

<caption>Figure v105—LBMS Request frame body format</caption>

The Category field is set to the value indicating the Wireless Network Management category, as specified in Table 24 in 7.3.1.11.

The Action field is set to the value indicating LBMS Request frame, as specified in Table v49 in 7.4.8.
The LBMS Request Element field indicates the multicast address and option about the leader based multicast service (LBMS) being requested by the non-AP STA, as specified in 7.3.2.64.

### 7.4.8.17 LBMS Report

The LBMS Report frame uses the Action frame body format. The format of the LBMS Report frame body is shown in Figure v105.

<figure><img src="image_6.png" /><figcaption>Figure v105—LBMS Report frame body format</figcaption></figure>

The Category field is set to the value indicating the Wireless Network Management category, as specified in Table 24 in 7.3.1.11.

The Action field is set to the value indicating LBMS Request frame, as specified in Table v49 in 7.4.8.

The Length field is set to n, where n indicates the total number of all multicast group addresses.

The Multicast Group Address fields are set to the MAC addresses corresponding to the multicast groups to lead. The non-AP STA is requested to become the leader for each of these Multicast Group Addresses.

Change 9.2.7 as shown:

### 9.2.7 Broadcast and multicast MPDU transfer procedure

In the absence of a PCF, when broadcast or multicast MPDUs are transferred from a STA with the ToDS bit clear, only the basic access procedure shall be used except when the LBMS is used, see section 9.2.7.2. Regardless of the length of the frame, no RTS/CTS exchange shall be used. In addition, no ACK shall be transmitted by any of the recipients of the frame. However, when the LBMS is used, the ACK frame shall be transmitted by a selected receiver and RTS/CTS exchange is used as an option. Any broadcast or multicast MPDUs transferred from a STA with a ToDS bit set shall, in addition to conforming to the basic access procedure of CSMA/CA, obey the rules for RTS/CTS exchange, because the MPDU is directed to the AP. The broadcast/multicast message shall be distributed into the BSS. The STA originating the message shall receive the message as a broadcast/multicast message. Therefore, all STAs shall filter out broadcast/multicast messages that contain their address as the source address. Broadcast and multicast MSDUs shall be propagated throughout the ESS.

There is no MAC-level recovery on broadcast or multicast frames, except for those frames sent with the ToDS bit set or with the LBMS enabled. As a result, the reliability of this traffic is reduced, relative to the reliability of directed traffic, due to the increased probability of lost frames from interference, collisions, or time-varying channel properties. An AP that supports a leader-based multicast mechanism shall indicate this capability using the Wireless Network Management Capability information element. A non-AP STA shall inform the AP that it supports this functionality by using the Wireless Network Management Capability information element.

Insert the following after 9.2.7.1:

#### 9.2.7.2 Leader Based Multicast Service (LBMS)
An AP that supports a LBMS shall indicate this capability using the Wireless Network Management Capabilities information element. A non-AP STA shall inform the AP that it supports this functionality by using the Wireless Network Management Capabilities information element.

### 9.2.7.2.1 Leader Election Protocol

The algorithm to select the non-AP STA to become a leader for a multicast stream is out of scope of this specification. The leader may dynamically change according to varying channel conditions or group membership changes. For example, the leader may be selected based on packet error rate statistics; the packet error rate of multicast receivers may be obtained through the Multicast Diagnostic Reports as specified in 11.15.1.1. This specification describes the mechanism used by the AP to elect a non-AP STA (called selected leader) within the multicast stream as a leader for this multicast stream.

Two management action frames, specified in 7.4.8, have been defined on this purpose: the LBMS Request frame and the LBMS Report frame.

In order to join the LBMS, a non-AP STA shall transmit the LBMS Request frame or (Re)association Request frame containing the LBMS Request element of the corresponding multicast stream. The LBMS Request element consists of the LBMS option such as the multicast ack policy and the retry limit.

To elect a new leader for one or several multicast stream(s), the AP shall send a LBMS Report frame containing the multicast address of the corresponding multicast stream to the selected leader under a normal ack policy. Upon reception of the LBMS Report frame, the selected leader shall generate an ACK frame for each successfully received multicast frame.

If there is already a leader for the multicast stream(s) specified in this leader election, the AP shall indicate to the previous leader that it is no longer leader for these multicast streams. On this purpose, the AP shall send to the previous leader a LBMS Report frame except the multicast address of the corresponding multicast stream to stop acknowledging multicast frames under a normal ack policy, before electing a new leader.

The elected leader may update the multicast policy by sending an LBMS Request frame to the AP with the updated LBMS option. It may send to the AP a LBMS Request frame with LBMS option set to no ACK policy for the corresponding multicast stream to resign the leadership under a normal ack policy.

In order to leave the LBMS, a non-AP STA shall send to the AP a LBMS Request frame without containing the LBMS Request element of the corresponding multicast stream to leave the LBMS under a normal ack policy.

The AP should ensure that the current leader is still in the BSS and trigger a new leader election in case for example some number of consecutive ACKs is missing.

### 9.2.7.2.2 Multicast Acknowledgement Mechanism

The leader is responsible of acknowledging each multicast frame successfully received for the multicast streams it has the leadership. The AP shall only elect one leader for a particular multicast stream. The selected leader shall send an ACK frame after waiting SIFS upon successful reception of a data frame for this multicast stream. If the AP does not receive the ACK frame from the leader during the ACK timeout, the AP shall increase the contention window by using the binary exponential backoff medium access mechanism defined in 9.1. The acknowledgements can also be used by the AP to adapt the PHY transmission rate of multicast frames and/or to improve the reliability of multicast transmission with retransmission, see section 9.2.7.2.3.

### 9.2.7.2.3 Multicast Retransmission Mechanism

When the LBMS is used, an optional retransmission mechanism is possible. The AP can disable multicast retransmission by forcing a retry limit of 0. If multicast retransmission is enabled, possibly duplicated multicast frames should be filtered out within the multicast receiver MAC as defined in 9.2.9.
Also, in order to prevent the duplicated frames in a non-AP STA that does not support the LBMS, the AP shall utilize the TKIP or CCMP replay protection procedure to retransmit a multicast frame. The duplicated frames encrypted by the TKIP and CCMP should be filtered out by comparing TSC or PN value of them with a replay counter of a multicast receiver.

#### 9.2.7.2.4 Multicast RTS/CTS Mechanism

The AP should initiate a (unicast) RTS/CTS sequence prior to a multicast transmission, to avoid collisions. The receiver address of the RTS frame may be set to the MAC address of any active station, rather than using the multicast address of the pending multicast transmission. The RTS may be sent at a non-basic rate if used as a collision detect and not as a protection frame. The duration may be set to cover until the end of the CTS in this case.

Insert the following after 10.3.52

##### 10.3.53 LBMS Request

This set of primitives supports the initialization of the leader election for the specific multicast streams between peer SMEs. Figure v113 depicts the Leader Management process using the LBMS Request and LBMS Response. The figure is only example and therefore is not meant to be exhaustive of all possible protocol uses.

<figure><img src="image_7.png" /><figcaption>Figure v113—Leader Management Process</figcaption></figure>

###### 10.3.53.1 MLME-LeaderRequest.request

##### 10.3.53.1.1 Function

This primitive requests the transmission of a LBMS Request frame to a peer entity.

##### 10.3.53.1.2 Semantics of the service primitive
The primitive parameters are as follows:

MLME-LeaderRequest.request

(
Peer MAC Address,
LBMS Request
)

<table><thead><tr><td>Name</td><td>Type</td><td>Valid Range</td><td>Description</td></tr></thead><tbody><tr><td>Peer MAC Address</td><td>MAC Address</td><td>Any valid individual MAC Address</td><td>The address of the peer MAC entity to which the LBMS Request frame shall be sent.</td></tr><tr><td>LBMS Request</td><td>As defined in LBMS Request element</td><td>As defined in LBMS Request element</td><td>Specifies the proposed service parameters for the LBMS.</td></tr></tbody></table>

### 10.3.53.1.3 When generated

This primitive is generated by the SME to request that a LBMS Request frame be sent to a peer entity.

### 10.3.53.1.4 Effect of receipt

On receipt of this primitive, the MLME constructs a LBMS Request frame containing the LBMS Request element of the specified multicast stream to lead. This frame is then scheduled for transmission.

### 10.3.53.2 MLME-LeaderRequest confirm

#### 10.3.53.2.1 Function

This primitive reports the request result of a LBMS Request.

#### 10.3.53.2.2 Semantics of the service primitive

The primitive parameters are as follows:

MLME-LeaderRequest confirm

(
Result Code
)
<table><thead><tr><td>Name</td><td>Type</td><td>Valid Range</td><td>Description</td></tr></thead><tbody><tr><td>Result Code</td><td>Enumeration</td><td>SUCCESS, INVALID PARAMETERS, or UNSPECIFIED FAILURE</td><td>Reports the outcome of a request to send a LBMS Request frame.</td></tr></tbody></table>

### 10.3.53.2.3 When generated

This primitive is generated by the MLME when the request to transmit a LBMS Request frame completes.

### 10.3.53.2.4 Effect of receipt

On receipt of this primitive, the SME evaluates the result code.

### 10.3.53.3 MLME-LeaderRequest.indication

#### 10.3.53.3.1 Function

This primitive indicates that a LBMS Request frame has been received.

#### 10.3.53.3.2 Semantics of the service primitive

This primitive parameters are as follows:

MLME-LeaderRequest.indication
( Peer MAC Address, LBMS Request )

<table><thead><tr><td>Name</td><td>Type</td><td>Valid Range</td><td>Description</td></tr></thead><tbody><tr><td>Peer MAC Address</td><td>MAC Address</td><td>Any valid individual MAC Address</td><td>The address of the peer MAC entity from which the LBMS Request was sent.</td></tr><tr><td>LBMS Request</td><td>As defined in LBMS Request element</td><td>As defined in LBMS Request element</td><td>Specifies the proposed service parameters for the LBMS.</td></tr></tbody></table>

#### 10.3.53.3.3 When generated
This primitive is generated by the MLME when a valid LBMS Request frame is received.

### 10.3.53.3.4 Effect of receipt

On receipt of this primitive, the SME either rejects the request or commences the LBMS as described in 9.2.7.2.

### 10.3.54 LBMS Report

This set of primitives supports the leader election between peer SMEs.

#### 10.3.54.1 MLME-LeaderReport.request

##### 10.3.54.1.1 Function

This primitive requests the transmission of a LBMS Report frame to a peer entity.

##### 10.3.54.1.2 Semantics of the service primitive

The primitive parameters are as follows:

MLME-LeaderReport.request

(
  Peer MAC Address,
  Length,
  Multicast Group Address
)

<table><thead><tr><td>Name</td><td>Type</td><td>Valid Range</td><td>Description</td></tr></thead><tbody><tr><td>Peer MAC Address</td><td>MAC Address</td><td>Any valid individual MAC Address</td><td>The address of the peer MAC entity to which the LBMS Report frame shall be sent.</td></tr><tr><td>Length</td><td>Integer</td><td>0 – 255</td><td>The total length of the multicast group addresses.</td></tr><tr><td>Multicast Group Address</td><td>Integer</td><td>As specified in 7.4.8.17</td><td>Indicates the result Report to the LBMS Request from the peer MAC entity.</td></tr></tbody></table>

##### 10.3.54.1.3 When generated

This primitive is generated by the SME to request that a LBMS Request frame be sent to a peer entity to convey an indication that the peer entity is selected as the leader transmitting the ACK frame for the multicast frames.

##### 10.3.54.1.4 Effect of receipt
On receipt of this primitive, the MLME constructs a LBMS Report frame containing the multicast group address of the specified multicast stream to lead. This frame is then scheduled for transmission.

### 10.3.54.2 MLME-LeaderReport confirm

#### 10.3.54.2.1 Function

This primitive reports the request result of a LBMS Report.

#### 10.3.54.2.2 Semantics of the service primitive

The primitive parameters are as follows:

MLME-LeaderReport confirm

(
Result Code
)

<table><thead><tr><td>Name</td><td>Type</td><td>Valid Range</td><td>Description</td></tr></thead><tbody><tr><td>Result Code</td><td>Enumeration</td><td>SUCCESS, INVALID PARAMETERS, or UNSPECIFIED FAILURE</td><td>Reports the outcome of a request to send a LBMS Report frame.</td></tr></tbody></table>

#### 10.3.54.2.3 When generated

This primitive is generated by the MLME when the request to transmit a LBMS Report frame completes.

#### 10.3.54.2.4 Effect of receipt

On receipt of this primitive, the SME evaluates the result code.

### 10.3.54.3 MLME-LeaderReport.indication

#### 10.3.54.3.1 Function

This primitive indicates that a LBMS Report frame has been received.

#### 10.3.54.3.2 Semantics of the service primitive
The primitive parameters are as follows:

MLME-LeaderReport.indication

(
Peer MAC Address,
Length,
Multicast Group Address
)

<table><thead><tr><td>Name</td><td>Type</td><td>Valid Range</td><td>Description</td></tr></thead><tbody><tr><td>Peer MAC Address</td><td>MAC Address</td><td>Any valid individual MAC Address</td><td>The address of the peer MAC entity from which the LBMS Report was sent.</td></tr><tr><td>Length</td><td>Integer</td><td>0 - 255</td><td>The total length of the multicast group addresses.</td></tr><tr><td>Multicast Group Address</td><td>Integer</td><td>As specified in 7.4.8.17</td><td>Indicates the result Report to the LBMS Request from the peer MAC entity.</td></tr></tbody></table>

### 10.3.54.3.3 When generated

This primitive is generated by the MLME upon reception of a valid LBMS Report frame.

### 10.3.54.3.4 Effect of receipt

On receipt of this primitive, the SME commences the LBMS as described in 9.2.7.2.

Insert the following after 11.2.1.11:

### 11.2.1.12 Power Management with LBMS

Non-AP STAs using the LBMS in PS mode shall wake up early enough to receive every DTIM sent by the AP of the BSS regardless of the ReceiveDTIMs parameter.

The AP shall transmit buffered broadcast and multicast frames immediately after DTIM (Beacon frame with DTIM Counter field of the TIM element equal to zero). A leader shall generate an ACK frame for each successfully received broadcast and multicast frame. But, the AP should not carry out the binary exponential backoff mechanism when an ACK frame is missing from the leader.
Insert the following new rows into A.4.15:

A.4.16 Wireless Network Management extensions

<table><thead><tr><td>Item</td><td>Protocol Capability</td><td>References</td><td>Status</td><td>Support</td></tr></thead><tbody><tr><td>RME11</td><td>Leader Based Multicast Service</td><td>9.2.7.2</td><td>CFv:O</td><td>Yes, No, N/A</td></tr><tr><td>RME11.1</td><td>LBMS Request</td><td>7.4.8.16</td><td>CFv:M</td><td>Yes, No, N/A</td></tr><tr><td>RME11.2</td><td>LBMS Report</td><td>7.4.8.17</td><td>CFv:M</td><td>Yes, No, N/A</td></tr></tbody></table>