July 2006 doc.: IEEE 802.11-06/0947r0
IEEE P802.11
Wireless LANs
Broadcast and Multicast Enhancements
Date: 2006-07-18
Author(s):
Name Company Address Phone email
Visiokatu 1, 33720 Tampere, jari.jokela
Jari Jokela Nokia Finland
+358504860445 @nokia.com
Itämerenkatu 11 – 13, 00180
Jarkko Jarkko.kneckt
Nokia Helsinki, Finland +358504821550 @nokia.com
Kneckt
Mikko Visiokatu 3, 33720 Tampere, Mikko.Jaakkola
Nokia +358505816945 @nokia.com
Jaakkola Finland
170 W. Tasman Drive, San
Bob O’Hara Cisco Systems +1-408-853-5513 boohara@cisco.com
Jose, CA 95134
Dave 170 W. Tasman Drive, San
Cisco Systems +1-408-527-7991 daves@cisco.com
Stephenson Jose, CA 95134
Allan 170 W. Tasman Drive, San
Cisco Systems +1-408-853-5570 allant@cisco.com
Thomson Jose, CA 95134
5775 Morehouse Drive, San snanda@qualcomm.c
Sanjiv Nanda Qualcomm +1-858-845-2375 om
Diego, CA 92121
Arnaud 5775 Morehouse Drive, San ameylan@qualcomm.
Qualcomm +1-858-845-1343 com
Meylan Diego, CA 92121
Abstract
This submission contains the normative text related to broadcast and multicast enhancements (Req.
#2120). Specifically the intention is to improve terminals power efficiency (Req. #2010). Furthermore
it contains aspects related to advertisements (Req. #1300).
The text is aligned with P802.11v-D0.03.
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 , 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
as early as possible, in written or electronic form, if patented technologyJari technologyNokia
Submission page 1 (or Jokela, 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 .
July 2006 doc.: IEEE 802.11-06/0947r0
[Make the following changes to 3]
3 Definitions
[Insert the following definition]
3.x Flexible Broadcast/Multicast Service (FBMS). This document introduces a Flexible
Broadcast/Multicast Service whereby a client can request a delivery interval longer than the normal
DTIM interval for the purposes of lengthing the period of time a STA may be in power save state. Thus a
client may not have to wake up at every DTIM interval in order to receive broadcast and multicast frames.
This method is backward compatible with existing 802.11 method for delivering these streams.
3.y Flexible Broadcast or Multicast stream identifier FBMSID. A 1-octet broadcast or multicast
stream identifier which has been assigned by the AP to a particular broadcast or multicast stream
subsequent to a Multicast Service Setup Request
[Insert the following to the end of section 7.1.3.5.2]
If FBMS intervals are supported then the HC shall set the EOSP bit of broadcast or multicast frame to
indicate that no more broadcast or multicast frames with the same group address are buffered in the AP.
[Make the following changes to 7.2.3.1]
7.2.3.1 Beacon frame format
[Insert the following rows in Table 5]
Order Information Notes
29 AID 0 Info AID 0 is present if
dot11WirelessManagementImplemented is true.
[Make the following changes to 7.2.3.6]
7.2.3.6 Reassociation Request frame format
[Insert the following rows in Table 12]
Order Information Notes
11 FBMS Request Information Element This optional IE may be present only if
dot11WirelessManagementImplemented is true
and FBMS bit is set to 1.
Submission page 2 Jari Jokela, Nokia
July 2006 doc.: IEEE 802.11-06/0947r0
[Make the following changes to 7.2.3.7]
7.2.3.7 Reassociation Response frame format
[Insert the following rows in Table 13]
Order Information Notes
7 FBMS Response Information Element This optional IE may be present only if
dot11WirelessManagementImplemented is true
and FBMS bit is set to 1 and FBMS Request
Information Element was present in
corresponding Reassociation Request frame.
[Make the following changes to 7.3.2]
7.3.2 Information elements
[Insert the following row into Table 26]
Information element Element ID
AID 0 Info x+9
FBMS Request x+10
FBMS Response x+11
Reserved x+12, 220
[Make the following changes to 7.3.2.35]
[Replace Figurev16 with the following]
B0 B1 B2 B3 B4 B5 B6 B15
Event Diagnostics Multicast Presence FBMS Proxy Reserved
Log Alert ARP
Service
Bits: 1 1 1 1 1 1 11
Figure v16—Wireless Network Management Capabilities
The Event Log bit set to 1 indicates the STA supports Event Log as described in TBS. The Event Log bit set to
0 indicates that the STA does not support this service.
Submission page 3 Jari Jokela, Nokia
July 2006 doc.: IEEE 802.11-06/0947r0
The Diagnostics bit set to 1 indicates the STA supports Diagnostics as described in TBS. 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 TBS. 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 clause TBS. 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 section 11.2.1.2. 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 will respond 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 client.
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.41]
7.3.2.42 AID 0 Info information element
The AID 0 Info gives information about the buffered broadcast or multicast frames. It may be present
only if dot11WirelessManagementImplemented is true and if the AP supports FBMS. If there is no active
FBMS stream then the AID 0 Info IE is not included in the beacon
Element ID Length Number FBMS … FBMS FBMSID … FBMSID
of FBMS Counter Counter
Counters #1 #N
Octets: 1 1 1 1 … 1 1 … 1
Figure vn. AID 0 Info information element.
The Length field shall be set to 2+n+m, where n is the Number of FBMS Counters present and m
indicates the number of 1-octet FBMSIDs present in the information element.
The format of the FBMS Counter is shown in Figure vn+1. When there is one or more active FBMS
streams, then at least one FBMS counter must be present in the AID 0 Info IE. Optionally, from 2 to a
maximum of eight counters are permitted. The FBMS counters are used by the client to identify the
DTIM beacon after which broadcast or multicast frames assigned to a particular delivery interval will be
transmitted.
B0 B2 B3 B7
FBMS Counter ID Current Count
Bits: 3 5
Figure vn+1. FBMS Counter definition.
The FBMS Counter ID field includes three least significant bits of FBMS Counter ID assigned by using
FBMS Response IE.
Submission page 4 Jari Jokela, Nokia
July 2006 doc.: IEEE 802.11-06/0947r0
The Current Count field indicates how many DTIM beacons (including the current one) appears before
the next DTIM after which the broadcast or multicast frames assigned to a particular delivery interval will
be transmitted.
The FBMSID is a 1-octet identifier as defined in 3.y.
Presence of an FBMSID indicates the AP has buffered frames for corresponding broadcast or multicast
stream which will be scheduled for transmission immediately after the DTIM beacon.
[Insert the following after 7.3.2.42]
7.3.2.43 FBMS Request information element
The FBMS Request gives information about the multicast and broadcast frames being requested by the
STA.
Element Length Multicast FBMS FBMS
ID Element Count Element 1 Element n
Octets: 1 1 1 variable variable
Figure vn. FBMS Request information element.
The Length field shall be set to 2+n, where n indicates the total length of all FBMS Elements contained in
the IE.
The Multicast Element Count indicates number of the FBMS Elements present.
The FBMS Element contains the following information.
TCLAS Optional Optional Optional Delivery
IE TCLAS TCLAS IE TCLAS Interval
IE Processing
IE
Octets: variable variable variable 3 1
The TCLAS Information Element defines the broadcast or multicast stream as defined in clause 7.3.2.31.
Optionally multiple TCLAS IEs are permitted to classify the broadcast or multicast stream.
The Optional TCLAS Processing IE defines how multiple TCLAS IE should be processed as defined in
clause 7.3.2.33.
The Delivery Interval defines the number of DTIMs that the stream will be transmitted at. The default
value will be 1.
Submission page 5 Jari Jokela, Nokia
July 2006 doc.: IEEE 802.11-06/0947r0
7.3.2.44 FBMS Response information element
The FBMS Response gives information about the broadcast and multicast status.
Element Length FBMS Status FBMS Status
ID Element 1 Element n
Octets: 1 1 5 5
Figure vn. FBMS Response information element.
The Length field shall be set to 1+n, where n indicates the total length of all FBMS Elements contained in
the IE.
The FBMS Element contains the following information.
Element Delivery Element FBMSID FBMS
Status Interval Reason Counter
Code ID
Octets: 1 1 1 1 1
The Element Status field defines the following values.
Field value Description
1 Accept
2 Deny
3 Override
4-255 Reserved
A status value of Accept will be transmitted by the AP when the requested delivery interval will be
supported by the AP.
A status value of Deny will be transmitted by the AP when the AP denies the STA’s requested delivery
interval and TCLAS completely.
A status value of Override will be transmitted by the AP when the AP denies the requested delivery
interval but can support an alternate delivery interval for the requested TCLAS. The STA must comply
with the AP’s override value. If the STA does not accept this overridden rate, then the STA must send a
new request with the TCLAS IE removed.
The Element Reason Code field provides additional explanation to the STA when the Status field returns
Deny or Override. The following values are defined:
Submission page 6 Jari Jokela, Nokia
July 2006 doc.: IEEE 802.11-06/0947r0
Field value Description
1 Denied due to malformed request or ambiguous
classifier.
2 Denied due to lack of resources on AP.
3 Denied due to requested classifier(s) matching 2 or
more existing streams on different intervals
4 Denied. By policy, requested stream is not
permitted to participate in FBMS
5 Overridden due to existing stream with different
delivery interval
6 Overridden due to policy limits on AP.
7 Overriden due to AP changed the delivery interval.
8-255 Reserved
The Delivery Interval defines the number of DTIMs that the stream will be transmitted at as defined by
the AP.
The FBMSID is assigned by the AP and provides a unique identifier for this stream within the BSS.
The FBMSID Counter ID provides a unique identifier for this stream counter within the BSS.
[Make the following changes to 7.4.6]
7.4.6 Wireless Network Management action details
[Insert the following rows in table v44]
Table v44—Wireless Network Management Action field values
Action field value Description
11 FBMS Request
12 FBMS Response
13-255 Reserved
[Insert the following after 7.4.6.11]
7.4.6.12 FBMS Request frame format
FBMS Request frame is sent by a STA to the AP to request the specified FBMS and to propose delivery
intervals for the set of broadcast and multicast streams.
Submission page 7 Jari Jokela, Nokia
July 2006 doc.: IEEE 802.11-06/0947r0
Category Action FBMS Request IE
Octets: 1 1 variable
Figure vn. FBMS Request frame format.
The Category field shall be set to x.
The Action field shall be set to 11.
The FBMS Request IE indicates the broadcast and multicast traffic streams that are requested by the STA.
The FBMS Request frame defines all the broadcast and multicast streams the client is interested in. That
is, it is a declarative definition of all broadcast and multicast streams active for which the STA has
requested an flexible delivery interval
7.4.6.13 FBMS Response frame format
FBMS Response frame is sent by an AP in response to a FBMS Request frame.
Category Action FBMS Response IE
Octets: 1 1 variable
Figure vn. FBMS Response frame format.
The Category field shall be set to x.
The Action field shall be set to 12.
The FBMS Response IE indicates the broadcast or multicast traffic streams that the AP will support and
at what delivery intervals.
[Insert new subclauses after 9.2.7]
9.2.7.1 FBMS
An AP supporting FBMS shall indicate its support by using Wireless Network Management Capability
information element. A STA wishing to use FBMS shall indicate it by using Wireless Network
Management Capability information element.
9.2.7.1.1 FBMS operation
The non-AP STA that wishes to use the FBMS shall send a FBMS Request or Reassociation Request with
all FBMS elements for which it wants to subscribe. This is a declaration of all streams in which the STA
is interested. For each stream, the STA proposes a delivery interval for the requested FBMS element. The
AP can adopt the proposed delivery interval or provide an alternate delivery interval for the stream. The
FBMS delivery interval is always an integer multiple of the DTIM Beacon period. If the AP denies the
usage of FBMS for a particular traffic stream, normal broadcast and multicast transmission rules apply.
Submission page 8 Jari Jokela, Nokia
July 2006 doc.: IEEE 802.11-06/0947r0
The AP shall support up to eight different delivery intervals. Corresponding to these eight delivery
intervals are eight FBMS counters. Each counter decrements once per DTIM beacon and when the
counter reaches zero, the delivery interval expires. Upon expiry, the AP schedules for transmission any
frames present for broadcast or multicast streams assigned to that interval. Upon request from the STA,
an AP assigns broadcast and multicast streams to a particular ID (the FBMSID), negotiates the Delivery
Interval and assigns a counter (the FBMS Counter ID) using the FBMS Element.
The
An AP uses the AID 0 Info field in Beacon frames to indicate to which broadcast or multicast addresses
the buffered broadcast/multicast frames are targeted. This field is present only if the bit for AID 0 is set to
1.
A non-AP STA may indicate that it is not using a particular FBMS Element anymore by transmitting a
FBMS Request frame without that FBMS Element contained in it. The AP shall send a FBMS response
with FBMS status value set to OK, upon receipt of the FBMS Request.
If an AP receives an FBMS Request for an FBMS stream which has already been assigned to a particular
delivery interval (and FBMS Counter ID), the AP may adjust the corresponding FBMS current count so
as to align the transmission time of said stream to the transmission time of other FBMS streams for which
the STA is already receiving. The AP accomplishes this by changing the current count. The Current
Count shall be changed only by holding the value of the field same in two consecutive Beacons in which
the Current Count field appears. The algorithm by which the AP chooses to align or offset the different
FBMS counters is unspecified.
AP may update the Delivery Interval for a FBMSID by sending an unsolicited FBMS response to the
appropriate address with updated Delivery Interval when the Current Count reaches zero.
Submission page 9 Jari Jokela, Nokia
July 2006 doc.: IEEE 802.11-06/0947r0
Change 10.3.7 as follows:
10.3.7 Reassociate
10.3.7.1 MLME-REASSOCIATE.request
10.3.7.1.2 Semantics of the service primitive
Change the primitive parameter list as shown:
MLME-REASSOCIATE.request (
NewAPAddress,
ReassociateFailureTimeout,
CapabilityInformation,
ListenInterval,
Supported Channels,
RSN,
QoSCapability,
WirelessManagementCapabilities
FBMSRequest)
Insert the following row at the end of the parameter table:
Name Type Valid Range Description
FBMSRequest As defined in As defined in Specifies the proposed service parameters for the FBMS
frame format frame format
10.3.7.2 MLME-REASSOCIATE.confirm
10.3.7.2.12Semantics of the service primitive
Change the primitive parameters as shown:
MLME-REASSOCIATE.confirm (
Resultcode,
CapabilityInformation,
AssoicationID,
SupportedRates,
EDCAParameterSet,
WirelessManagementCapabilities
FBMSResponse)
Submission page 10 Jari Jokela, Nokia
July 2006 doc.: IEEE 802.11-06/0947r0
Insert the following row at the end of the parameter table:
Name Type Valid Range Description
FBMSResponse As defined in As defined in Specifies service parameters for the FBMS
frame format frame format
10.3.7.3 MLME-REASSOCIATE.indication
10.3.7.3.2 Semantics of the service primitive
Change the primitive parameter list as shown:
MLME-REASSOCIATE.indication (
PeerSTAAddress,
CurrentAPAddress,
CapabilityInformation,
ListenInterval,
SSID,
SupportedRates,
RSN,
QoSCapability,
WirelessManagementCapabilities
FBMSRequest)
Insert the following row at the end of the parameter table:
Name Type Valid Range Description
FBMSReques As defined in As defined in Specifies the proposed service parameters for the FBMS
frame format frame format
10.3.7.4 MLME-REASSOCIATE.response
10.3.7.4.2 Semantics of the service primitive
Change the primitive parameter list as shown:
MLME-REASSOCIATE.response (
PeerSTAAddress,
ResultCode,
CapabilityInformation,
AssociationID,
WirelessManagementCapabilities
FBMSResponse)
Submission page 11 Jari Jokela, Nokia
July 2006 doc.: IEEE 802.11-06/0947r0
Insert the following row at the end of the parameter table:
Name Type Valid Range Description
FBMSResponse As defined in As defined in Specifies service parameters for the FBMS
frame format frame format
[Insert the following clauses after 10.3.38]
10.3.39 FBMS Setup
The following MLME primitives support the signaling of FBMS Setup.
10.3.39.1 MLME-FBMS.request
10.3.39.1.1 Function
This primitive requests that a FBMS Request frame be sent to the AP with which the STA is associated.
10.3.39.1.2 Semantics of the Service Primitive
The primitive parameters are as follows:
MLME-FBMS.request (
PeerSTAAddress,
FBMSRequest
)
Name Type Valid Range Description
PeerSTAAddress MAC Address Any valid Specifies the address of the peer MAC entity with which
individual MAC to perform the FBMS process.
Address
FBMSRequest As defined in As defined in Specifies the proposed service parameters for the FBMS
frame format frame format
10.3.39.1.3 When Generated
This primitive is generated by the SME to request that a FBMS Request frame be sent to the AP with which the STA
is associated.
10.3.39.1.4 Effect of Receipt
On receipt of this primitive, the MLME constructs a FBMS Request action management frame. The STA then
attempts to transmit this to the AP with which it is associated.
10.3.39.2 MLME-FBMS.confirm
10.3.39.2.1 Function
This primitive reports the result of a FBMS procedure.
Submission page 12 Jari Jokela, Nokia
July 2006 doc.: IEEE 802.11-06/0947r0
10.3.39.2.2 Semantics of the Service Primitive
The primitive parameters are as follows:
MLME- FBMS.confirm (
FBMSResponse
)
Name Type Valid Range Description
FBMSResponse As defined in As defined in Specifies service parameters for the FBMS
frame format frame format
10.3.39.2.3 When Generated
This primitive is generated by the MLME as a result of an MLME-FBMS.request and indicates the results of the
request.
This primitive is generated when the MLME-FBMS.request contains invalid parameters, when a timeout or failure
occurs, or when the STA receives a FBMS Response frame from the AP.
10.3.39.2.4 Effect of Receipt
On receipt of this primitive, the SME evaluates the Element Status and may use the reported data.
Submission page 13 Jari Jokela, Nokia
July 2006 doc.: IEEE 802.11-06/0947r0
10.3.39.3 MLME-FBMS.indication
10.3.39.3.1 Function
This primitive indicates that a FBMS Request frame was received from a non-AP STA.
10.3.39.3.2 Semantics of the Service Primitive
The primitive parameters are as follows:
MLME- MSERVICESETUP.indication (
PeerSTAAddress,
FBMSRequest
)
Name Type Valid Range Description
PeerSTAAddress MACAddress Any valid The address of the non-AP STA MAC entity from which
individual MAC a FBMS Request frame was received.
Address
FBMSRequest As defined in As defined in Specifies the proposed service parameters for the FBMS
frame format frame format
10.3.39.3.3 When Generated
This primitive is generated by the MLME when a valid FBMS Request frame is received.
10.3.39.3.4 Effect of Receipt
On receipt of this primitive the SME should operate according to the procedure in 9.2.7.1.1.
10.3.39.4 MLME-FBMS.response
10.3.39.4.1 Function
This primitive is generated in response to an MLME-FBMS.indication requesting a FBMS Response frame be sent
to a non-AP STA.
Submission page 14 Jari Jokela, Nokia
July 2006 doc.: IEEE 802.11-06/0947r0
10.3.39.4.2 Semantics of the Service Primitive
The primitive parameters are as follows:
MLME-MSERVICESETUP.response (
PeerSTAAddress,
FBMSResponse
)
Name Type Valid Range Description
PeerSTAAddress MACAddress Any valid The address of the non-AP STA MAC entity from which
individual MAC a FBMS Request frame was received.
Address
FBMSResponse As defined in As defined in Specifies service parameters for the FBMS
frame format frame format
10.3.39.4.3 When Generated
This primitive is generated by the SME in response to an MLME-FBMS.indication requesting a FBMS Response be
sent to a non-AP STA.
10.3.39.4.4 Effect of Receipt
On receipt of this primitive, the MLME constructs a FBMS Response frame. The STA then attempts to
transmit this to the non-AP STA indicated by the PeerSTAAddress parameter.
[Insert the following clauses after 11.2.1.4 and renumber the following clauses]
11.2.1.5 FBMS power management
Using the FBMS it is possible to create different delivery intervals for different FBMS streams.
The delivery interval for a FBMS stream is created by using the FBMS Request and Response frames or
by using Reassociation Request and Response frames. A non-AP STA wishing to use FBMS can propose
an delivery interval to the AP for FBMS streams. FBMS delivery interval can be multiple of DTIM
periods. The AP shall make the selection of the FBMS delivery interval and shall indicate it by using the
FBMS Response or Reassociation Response frame.
The APs shall send an AID 0 Info element in each Beacon frame containing the bit for AID 0 set to 1 if
there is one or more FBMS set up. The AID 0 Info contains information about to which broadcast and/or
multicast groups the buffered frames in the AP belongs to.
[Insert the following text at the end of bullet c in 11.2.1.5]
11.2.1.5 AP operation during the CP
c)
Submission page 15 Jari Jokela, Nokia
July 2006 doc.: IEEE 802.11-06/0947r0
If FBMS is used the AP shall include AID 0 Info information element to every Beacon containing the bit
for AID 0 set to 1. The AID 0 Info information element shall indicate all the broadcast and/or multicast
groups for which the AP is having buffered frames.
[Insert the following text at the end of bullet f in 11.2.1.5]
f)
If FBMS is used the AP will send all broadcast or multicast frames belonging to particular FBMS Element
immediately after the DTIM having Current Count of FBMS Counter field set to 0 for that particular FBMS
stream. If any of the associated STAs are using FBMS then the EOSP field of each multicast or broadcast
frame shall be set to indicate the presence of further buffered multicast MSDUs belonging to the multicast
or broadcast address of that particular frame. The More Data field of each multicast or broadcast frame
shall be set to indicate the presence of further buffered broadcast/multicast MSDUs. If the AP is unable to
transmit all the buffered broadcast or multicast MSDUs before the next TBTT, the AP shall indicate that it
will continue to deliver the multicast MSDUs by setting the bit for AID 0 in TIM field to 1 and by setting
the AID 0 Info information element to indicate to which group addresses there are still buffered frames.
AID 0 Info information element shall be present until all buffered broadcast and multicast frames have
been transmitted.
[Insert the following text at the end of bullet e in 11.2.1.6]
e)
If FBMS is used the AP will send all broadcast or multicast frames belonging to particular FBMS Element
immediately after the DTIM having Current Count of FBMS Counter field set to 0 for that particular FBMS
stream. If any of the associated STAs are using FBMS then the EOSP field of each multicast or broadcast
frame shall be set to indicate the presence of further buffered multicast or broadcast MSDUs belonging to
the multicast or broadcast address of that particular frame. The More Data field of each multicast frame
shall be set to indicate the presence of further buffered broadcast/multicast MSDUs. If the AP is unable to
transmit all the buffered broadcast or multicast MSDUs before the next TBTT, the AP shall indicate that it
will continue to deliver the multicast MSDUs by setting the bit for AID 0 in TIM field to 1 and by setting
the AID 0 Info information element to indicate to which group addresses there are still buffered frames.
AID 0 Info information element shall be present until all buffered broadcast and multicast frames have
been transmitted.
[Insert the following text at the end of bullet e in 11.2.1.7]
11.2.1.7 Receive operation for STAs in PS mode during the CP
e) If the non-AP STA is using FBMS it shall wake up before the DTIM having Current Count of FBMS
Counter field set to 0 for that particular FBMS stream. A non-AP STA shall remain awake until the More
Data field of the multicast or broadcast MSDU indicates there are no further buffered broadcast/multicast
MSDUs or until a non-AP STA until the EOSP bits indicates no further buffered frames belonging to all
broadcast and multicast addresses of which the STA is using or bit for AID 0 in TIM filed is set to 0 or
until AID 0 Info information element indicates that there are no further buffered multicast frames belonging
to broadcast and multicast groups of which the STA is using.
Submission page 16 Jari Jokela, Nokia
July 2006 doc.: IEEE 802.11-06/0947r0
[Insert the following rows to A.4.14]
A.4.14 Wireless Network Management extensions
Item Protocol Capability References Status Support
RME8 FBMS 9.2.7.1 CFv:O Yes, No, N/A
RME8.2 FBMS Request frame 7.4.6.5 (CF2&RME8):M Yes, No, N/A
RME8.3 FBMS Response frame 7.4.6.6 (CF1&RME8):M Yes, No, N/A
Submission page 17 Jari Jokela, Nokia
July 2006 doc.: IEEE 802.11-06/0947r0
References:
Submission page 18 Jari Jokela, Nokia