1. Broadcast and Multicast Enhancements
Month Year
July 2006
July 2006
Broadcast and Multicast Enhancements
Authors:
Date:
Notice: This document has been prepared to assist IEEE 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
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < 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 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 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Jokela et al
Jokela et al

2. Month Year
July 2006
July 2006
Abstract
This document outlines the enhancements related to broadcast and multicast traffic (Req. #2120) as defined in normative text document IEEE /0947r0
Specifically the intention is to improve terminals power efficiency (Req. #2010).
Furthermore it contains aspects related to advertisements (Req. #1300).
Jokela et al
Jokela et al

3. Agenda Guiding Principles Overview Messages Other Changes July 2006
Month Year
July 2006
July 2006
Agenda
Guiding Principles
Overview
Messages
Other Changes
Jokela et al
Jokela et al

4. Month Year
July 2006
July 2006
Guiding Principles
Proposal must be backward compatible with legacy power save for multicast/broadcast traffic. 
Proposal must not require replication of broadcast or multicast frames
Proposal must exhibit "good" network behavior
Proposal must ensure one client cannot change another’s behavior  
Jokela et al
Jokela et al

5. Overview Goal Flexible Broadcast Multicast Service (FBMS)
Month Year
July 2006
July 2006
Overview
Goal
Increase the period of time a STA may be in power save state
Flexible Broadcast Multicast Service (FBMS)
A client can request a listen interval longer than the normal DTIM interval
A client may not have to wake up at every DTIM interval in order to receive broadcast and multicast frames.
Backward compatible with existing method for delivering these streams
Proxy ARP Service
An AP provides Proxy ARP on behalf of the STA
Jokela et al
Jokela et al

6. Reassociation Request + Reassociation Response +
Month Year
July 2006
July 2006
FBMS Messages AP
Non-AP STA
New Wireless Network Management action frames
FBMS Request
FBMS Response
Beacon
AID 0 Information Element
Reassociation Request
FBMS Request IE
Reassociation Response
FBMS Response IE
Beacon +
AID 0 IE
FBMS Request
FBMS Response
Reassociation Request +
FBMS Request IE
Reassociation Response +
FBMS Response IE
Jokela et al
Jokela et al

7. FBMS Request STA sends request to AP with one or more FBMS elements
July 2006
FBMS Request
STA sends request to AP with one or more FBMS elements
Request is declarative
A FBMS Element contains
TCLAS identifies L2 or L3 traffic
Delivery Interval is the number of DTIM intervals the traffic should be transmitted at
Jokela et al

8. July 2006
FBMS Response
For each requested FBMS Element, response contains FBMS Status Element
Each FBMS Status Element contains
FBMSID: Identifies the stream associated with the FBMS element at the AP
Jokela et al

9. FBMS Response - Status AP replies with Accept, Deny or Override
Month Year
July 2006
July 2006
FBMS Response - Status
AP replies with Accept, Deny or Override
For deny or override, Reason Code provides more details
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
Jokela et al
Jokela et al

10. Advertisements Wireless Network Management Capability Element
Month Year
July 2006
July 2006
Advertisements
Wireless Network Management Capability Element
FBMS
Advertises FBMS supported
Proxy ARP Service
Advertises Proxy ARP service supported on behalf of the STA
Jokela et al
Jokela et al

11. AID 0 Info Element Contained in beacons
July 2006
AID 0 Info Element
Contained in beacons
For each FBMS stream with traffic queued
Counters count down modulo interval
Interval 4
Counter values:
Stream transmitted when counter hits 0
Jokela et al

12. July 2006
Questions/Feedback
Jokela et al

13. Month Year
July 2006
July 2006
Motion
Move to include normative text in document v-bc-and-mc-enhancements into the TGv draft.
Mover:
Seconder:
Results:
Jokela et al
Jokela et al