1 / 25

TGmb Agenda for May 2009 Meeting in Montreal

This document provides the agenda and important information for the TGmb meeting in Montreal, Canada from May 11-14, 2009.

waylonj
Download Presentation

TGmb Agenda for May 2009 Meeting in Montreal

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TGmb Agenda, May 2009 Authors: Date: 2009-05-08 Matthew Gast, Trapeze Networks

  2. Abstract Agenda for the TGmb meeting in Montréal, Québec, Canada from May 11-14, 2009. Matthew Gast, Trapeze Networks

  3. Agenda • Call meeting to order • Agenda review • Policies & procedures (including patent policy) • Attendance recording & meeting resources • TGmb status update • Approval of teleconference recommendations • Comment review & resolution • MIB variable structure • Interpretation request • Plans for next meeting • Authorize teleconferences & ad hocs • Review timeline • AOB • Adjourn Matthew Gast, Trapeze Networks

  4. Monday AM211 May 2009, 10:30 – 12:30 • Call meeting to order Matthew Gast, Trapeze Networks

  5. Participants, Patents, and Duty to Inform All participants in this meeting have certain obligations under the IEEE-SA Patent Policy. Participants: • “Shall inform the IEEE (or cause the IEEE to be informed)” of the identity of each “holder of any potential Essential Patent Claims of which they are personally aware” if the claims are owned or controlled by the participant or the entity the participant is from, employed by, or otherwise represents • “Personal awareness” means that the participant “is personally aware that the holder may have a potential Essential Patent Claim,” even if the participant is not personally aware of the specific patents orpatent claims • “Should inform the IEEE (or cause the IEEE to be informed)” of the identity of “any other holders of such potential Essential Patent Claims” (that is, third parties that are not affiliated with the participant, with the participant’s employer, or with anyone else that the participant is from or otherwise represents) • The above does not apply if the patentclaim is already the subject of an Accepted Letter of Assurance that applies to the proposed standard(s) under consideration by this group Quoted text excerpted from IEEE-SA Standards Board Bylaws subclause 6.2 • Early identification of holders of potential Essential Patent Claims is strongly encouraged • No duty to perform a patent search Slide #1 Matthew Gast, Trapeze Networks

  6. Patent Related Links All participants should be familiar with their obligations under the IEEE-SA Policies & Procedures for standards development. Patent Policy is stated in these sources: IEEE-SA Standards Boards Bylaws http://standards.ieee.org/guides/bylaws/sect6-7.html#6 IEEE-SA Standards Board Operations Manual http://standards.ieee.org/guides/opman/sect6.html#6.3 Material about the patent policy is available at http://standards.ieee.org/board/pat/pat-material.html If you have questions, contact the IEEE-SA Standards Board Patent Committee Administrator at patcom@ieee.org or visit http://standards.ieee.org/board/pat/index.html This slide set is available at http://standards.ieee.org/board/pat/pat-slideset.ppt Slide #2 Matthew Gast, Trapeze Networks

  7. Call for Potentially Essential Patents • If anyone in this meeting is personally aware of the holder of any patent claims that are potentially essential to implementation of the proposed standard(s) under consideration by this group and that are not already the subject of an Accepted Letter of Assurance: • Either speak up now or • Provide the chair of this group with the identity of the holder(s) of any and all such claims as soon as possible or • Cause an LOA to be submitted Slide #3 Matthew Gast, Trapeze Networks

  8. Other Guidelines for IEEE WG Meetings • All IEEE-SA standards meetings shall be conducted in compliance with all applicable laws, including antitrust and competition laws. • Don’t discuss the interpretation, validity, or essentiality of patents/patent claims. • Don’t discuss specific license rates, terms, or conditions. • Relative costs, including licensing costs of essential patent claims, of different technical approaches may be discussed in standards development meetings. • Technical considerations remain primary focus • Don’t discuss or engage in the fixing of product prices, allocation of customers, or division of sales markets. • Don’t discuss the status or substance of ongoing or threatened litigation. • Don’t be silent if inappropriate topics are discussed … do formally object. --------------------------------------------------------------- See IEEE-SA Standards Board Operations Manual, clause 5.3.10 and “Promoting Competition and Innovation: What You Need to Know about the IEEE Standards Association's Antitrust and Competition Policy” for more details. Slide #4 Matthew Gast, Trapeze Networks

  9. Resources – URLs • Link to IEEE Disclosure of Affiliation • http://standards.ieee.org/faqs/affiliationFAQ.html • Links to IEEE Antitrust Guidelines • http://standards.ieee.org/resources/antitrust-guidelines.pdf • Link to IEEE Code of Ethics • http://www.ieee.org/web/membership/ethics/code_ethics.html • Link to IEEE Patent Policy • http://standards.ieee.org/board/pat/pat-slideset.ppt Matthew Gast, Trapeze Networks

  10. Meeting Etiquette • IEEE 802 is a world-wide professional technical organization • Meetings are to be conducted in an orderly and professionalmanner in accordance with the policies and procedures governed by the organization. • Individuals are to address the “Technical” content of the subject under consideration and refrain from making “personal” comments to or about the presenter. Matthew Gast, Trapeze Networks

  11. Monday AM2 (continued)11 May 2009, 10:30 – 12:30 • Attendance recording procedures • See 11-09/0246r0 • https://murphy.events.ieee.org/imat • Must register before logging attendance • Must log attendance during each 2 hour session • Documentation • http://mentor.ieee.org • Use “TGm” for documents relating to the Revision PAR Matthew Gast, Trapeze Networks

  12. Monday AM2 (continued)11 May 2009, 10:30 – 12:30 • Approve Agenda • 11-09/0525r1 (this document) • Approval of March 2009 (Vancouver, British Columbia, Canada) meeting minutes: 11-09/0325r0 • https://mentor.ieee.org/802.11/dcn/09/11-09-0325-00-000m-minutes-for-tgmb-march-2009.doc • Approval of March/April/May teleconference minutes: 11-09/0428r4 • https://mentor.ieee.org/802.11/dcn/09/11-09-0428-04-000m-consolidated-minutes-for-tgmb-for-march-27-may-8-2009.doc Matthew Gast, Trapeze Networks

  13. Monday AM2 (continued)11 May 2009, 10:30 – 12:30 • Goals for this meeting: Go for initial letter ballot (see plan of record and amendment order on next slides) Matthew Gast, Trapeze Networks

  14. TGmb Plan of Record • May 2008 – Issue Call for Comment/Input • July 2008 – begin process input and old Interpretation requests Acknowledge previous Task Group referrals • Sept 2008 – PAR revision process started • Nov 2008 – close receipt of new input • Nov 2008 – WG/EC approval of PAR Revision • Dec 2008 – NesCom/SASB approval PAR Revision • May 2009 – First WG Letter ballot • (includes All published Amendments as of May 2009) • Sep/Nov 2009 – Recirc start • November 2009– Form Sponsor Pool • January 2010 – Sponsor Ballot Start • (Include all published amendments as of Jan 2010) • May 2010 – Sponsor Recirc • Jan 2011 – WG/EC Final Approval (conditional in Nov 2010) • Mar 2011 – RevCom/SASB Approval Matthew Gast, Trapeze Networks

  15. Amendment Ordering (Note: This is taken from 11-09/0322r1) • Data as of March 12 from 802.11 website. • See http://grouper.ieee.org/groups/802/11/Reports/802.11_Timelines.htm Slide 15 Matthew Gast, Trapeze Networks

  16. Monday AM2 (continued)11 May 2009, 10:30 – 12:30 • Editorial update: 11-09/0444r0 (Adrian Stephens) • Comment update • Requests for corrections/improvements closed November 2008 with 104 comments received • Two comments remain in 11-08/1127r18: CIDs 61 & 62 on power saving – anticipated resolution of these is 11-09/0003rSomething • Comment group 12 has recommendations from teleconferences Matthew Gast, Trapeze Networks

  17. Monday AM2 (continued)11 May 2009, 10:30 – 12:30 • Draft approval motion: Approve draft D0.05 as the TGmb draft. • Moved: • Seconded: • Result (Y/N/A): Matthew Gast, Trapeze Networks

  18. Monday AM2 (continued)11 May 2009, 10:30 – 12:30 • Teleconference comment resolution approval motion: Approve comment resolutions in comment group 12 in document 11-08/1127r18 • Moved: • Seconded: • Result (Y/N/A): Matthew Gast, Trapeze Networks

  19. Monday AM2 (continued)11 May 2009, 10:30 – 12:30 • Consideration of CID 93 • Mark Hamilton states on reflector: “[W]e need to also remove the phrase "and at least one of the four U-APSD flags is set to 1" from the sentence following the deletion.” • Consideration of CIDs 61 & 62 and document 11-09/0003r4 • Two points from Mark Hamilton on TGm reflector: • 1) Do we still need Disassociation and Deauthentication to be buffered? Work in 11w has removed the need for this. • 2) From the text in 09-0003r3, in the section titled "Change 11.2.1 as follows", replace the 3rd, 4th and 5th paragraphs with • "STAs shall use the techniques described in this clause to indicate buffered frames, and to designate times for their transmission that allow STAs in PS mode to coordinate with the transmission timing." • My intent is to avoid having several paragraphs to detail out how buffered frames are signaled and transmitted under all different Power Save mechanisms. I think to try to detail it all out here is complicated and messy and therefore clutters the intent of this section (which is, in my opinion, meant to be an overview and introduction to the concept that there is thing called Power Save, and it causes frames to buffered and delivered in a controlled fashion at appropriate times). Further to detail all this here just introduces a redundancy in the Standard, which results in things getting out of synch (like they already have with the introduction of 802.11e, as exemplified by the fact this problem is there now). • On reflector, Jouni Malinen states in response to #1 that buffering is not required. • Recess Matthew Gast, Trapeze Networks

  20. Monday PM111 May 2009, 13:30 – 15:30 • Consideration of CIDs 61 & 62 and document 11-09/0003r4 • Recess Matthew Gast, Trapeze Networks

  21. Tuesday AM112 May 2009, 08:00 – 10:00 • Consideration of CIDs 61 & 62 and document 11-09/0003r4 • Recess Matthew Gast, Trapeze Networks

  22. Tuesday PM212 May 2009, 08:00 – 10:00 • MIB presentation: 11-09/0533r0 (Dave Bagby) • Interpretation request (see next slide) • Recess Matthew Gast, Trapeze Networks

  23. Interpretation Request #17 • Request received from Paul Kimelman (paul.kimelman@luminarymicro.com): I am requesting an "interpretation" of 11.2.1.5 (power management) of 802.11 2007. The issue has to do with ListenInterval and MSDUs being buffered. Between the "shall"s and "can"s, there is a wide range of possible behaviors that makes it very hard for systems trying to conserve power, especially in the embedded domain, including WSN. I have a bigger discussion below. The main issue is that the STA and the AP cannot coordinate or agree on any parameter of behavior. For example, some APs will disassociate a STA if the ListenInterval is too long. They do not refuse the Associate, they just choose to disassociate the STA based on time from last interaction. The cost of associating again is very high in power/time, so this is very non-optimal. In the case of WSN nodes, a ListenInterval of many minutes would be reasonable. Coupled to all of this is the unknowns related to the MSDU buffering. It would be much better if the STA and AP could agree/negotiate the amount of buffering the AP would be willing to do. Some STAs would indicate that they want essentially no MSDU buffering since they expect data only when sending data. Others would like most recent data kept and others would like oldest kept. Some APs may use a global buffer, so cannot make assurances about buffering, which is what should be communicated. Finally, it would be preferable for the AP to be able to tell the STA that it has tossed data per the subsection (k) of 11.2.1.5. The issue is that an AP is required (shall) to hold MSDU RX packets during the listen interval. But, most APs have limited space. So, this creates a problematic model made worse by the listen interval not being negotiated (the STA cannot ask what interval is OK). The problem is that many APs simply disassociate a STA if too much data arrives between accesses or in some cases too much. time (even though subsection (k) says they can just delete it). This creates an unwieldy system with highly unpredictable behavior. It clearly is not what you intended. I believe that the optimal solution is to let the STA make a "lease" of space on the AP with an agreement to what happens if that is exceeded (newer data packets ignored, older ones ignored, disassociation). This would be very clean for all parties and since it would be negotiated (based on what AP was willing to do), both sides would be clear what the behavior was. A less optimal solution is to at least find out how much memory will be allocated to storing that STA's RX data during the listen interval, and what policy the AP takes if that is exceeded. As a somewhat related situation, it would be preferable if the STA could find out what the max listen interval the AP will support and whether it will disassociate a STA when there are too many STAs associating (that is, toss the least recently used/probed STA). This all matters a lot to embedded systems of the WSN (Wireless Sensor Network) type of use. Power management is far more severe than a handheld device, and scheduling is generally very precise as a result. Further, most sensors do not expect any unsolicited RX data, so they can control the amount expected very accurately. The most disastrous case for an embedded system is to wake up and find they have been disassociated (because they have to stay power up waiting for the whole process (JOIN, AUTH, ASSOC)). If it happens occasionally, that is fine, but if it happens every time for the above reasons, that is a disaster. I expect a similar case can be made for PAN type devices that are not plugged in. Matthew Gast, Trapeze Networks

  24. Thursday AM214 May 2009, 10:30 – 12:30 • Letter ballot motion (if necessary):Having approved and comment resolutions for all of the comments received on STD 802.11-2007, Having incorporated these comment resolutions and having incorporated all the published amendments (STD 802.11k-2008, STD 802.11r-2008, STD 802.11y-2008), resulting in Draft P802.11REVmb_D1.0, Approve a 30 day Working Group Technical Letter Ballot asking the question “Should TGmb Draft 1.0 be forwarded to Sponsor Ballot?” Moved: Seconded: Result (Y/N/A): Matthew Gast, Trapeze Networks

  25. Thursday AM2 (continued)12 May 2009, 08:00 – 10:00 • Preparation for July 2009 meeting • Teleconferences/ad hocs • Review timeline • http://grouper.ieee.org/groups/802/11/Reports/802.11_Timelines.htm • AOB • Adjourn Matthew Gast, Trapeze Networks

More Related