450 likes | 461 Views
TGn-LB115-mac-adhoc-report. Authors:. Date: 2008-01-10. Abstract. Running record of Agenda, Minutes, Results and Motions for TGn LB115 MAC adhoc group from November 2007 meeting through the meeting during which MAC LB115 comment processing is completed. Important IEEE Links.
E N D
TGn-LB115-mac-adhoc-report Authors: Date: 2008-01-10 Matthew Fischer (Broadcom)
Abstract Running record of Agenda, Minutes, Results and Motions for TGn LB115 MAC adhoc group from November 2007 meeting through the meeting during which MAC LB115 comment processing is completed. Matthew Fischer (Broadcom)
Important IEEE Links • The following slides in this deck are believed to be the latest available however the Source locations are: • http://standards.ieee.org/faqs/affiliationFAQ.html • http://standards.ieee.org/resources/antitrust-guidelines.pdf • http://standards.ieee.org/board/pat/pat-slideset.ppt • http://www.ieee.org/portal/cms_docs/about/CoE_poster.pdf • For summary see 11-07-0660-01-0000-opening-presentation Matthew Fischer (Broadcom)
Member Affiliation • It is defined in the IEEE-SA Standards Board Bylaws, 5.2.1.5 as: “An individual is deemed “affiliated” with any individual or entity that has been, or will be, financially or materially supporting that individual’s participation in a particular IEEE standards activity. This includes, but is not limited to, his or her employer and any individual or entity that has or will have, either directly or indirectly, requested, paid for, or otherwise sponsored his or her participation. • http://standards.ieee.org/faqs/affiliationFAQ.html Matthew Fischer (Broadcom)
Declaration of Affiliation • Revision: May 2007 Standards Board Bylaw 5.2.1.1 • 5.2.1.1 Openness • Openness is defined as the quality of being not restricted to a particular type or category of participants. All meetings involving standards development an all IEEE Sponsor ballots shall be open toa all interested parties. Each individual participant in IEEE Standards activities shall disclose his or her affiliations when requested. A person who knows or reasonably should know, that a participant’s disclosure is materially incomplete or incorrect should report that fact to the Secretary of the IEEE-SA Standards Board and the appropriate Sponsors. • http://standards.ieee.org/faqs/affiliationFAQ.html Matthew Fischer (Broadcom)
Affiliation Policy • Requirement to declare affiliation at all standards development meetings and recorded in the minutes • Affiliation not necessarily same as employer • Declaration requirement may be familiar to some 802 WGs, though WG declaration process may evolve • 11. What if I refuse to disclose my affiliation? • As outlined in IEEE-SA governance documents, you will lose certain rights. In a working group where voting rights are gained through attendance, no attendance credit will be granted if affiliation isn’t declared. Similarly, voting rights are to be removed if affiliation isn’t declared. • Affiliation declaration will be added to Sponsor ballot • http://standards.ieee.org/faqs/affiliationFAQ.html Matthew Fischer (Broadcom)
Highlights of the IEEE-SA Standards Board Bylaws on Patents in Standards • Participants have a duty to tell the IEEE if they know (based on personal awareness) of potentially Essential Patent Claims they or their employer own • Participants are encouraged to tell the IEEE if they know of potentially Essential Patent Claims owned by others • This encouragement is particularly strong as the third party may not be a participant in the standards process • Working Group required to request assurance • Early assurance is encouraged • Terms of assurance shall be either: • Reasonable and nondiscriminatory, with or without monetary compensation; or, • A statement of non-assertion of patent rights • Assurances • Shall be provided on the IEEE-SA Standards Board approved LOA form • May optionally include not-to-exceed rates, terms, and conditions • Shall not be circumvented through sale or transfer of patents • Shall be brought to the attention of any future assignees or transferees • Shall apply to Affiliates unless explicitly excluded • Are irrevocable once submitted and accepted • Shall be supplemented if Submitter becomes aware of other potential Essential Patent Claims • A “Blanket Letter of Assurance” may be provided at the option of the patent holder • A patent holder has no duty to perform a patent search • Full policy available at http://standards.ieee.org/guides/bylaws/sect6-7.html#6 1 Matthew Fischer (Broadcom)
IEEE-SA Standards Board Bylaws on Patents in Standards 6.2 Policy IEEE standards may be drafted in terms that include the use of Essential Patent Claims. If the IEEE receives notice that a [Proposed] IEEE Standard may require the use of a potential Essential Patent Claim, the IEEE shall request licensing assurance, on the IEEE Standards Board approved Letter of Assurance form, from the patent holder or patent applicant. The IEEE shall request this assurance without coercion. The Submitter of the Letter of Assurance may, after Reasonable and Good Faith Inquiry, indicate it is not aware of any Patent Claims that the Submitter may own, control, or have the ability to license that might be or become Essential Patent Claims. If the patent holder or patent applicant provides an assurance, it should do so as soon as reasonably feasible in the standards development process. This assurance shall be provided prior to the Standards Board’s approval of the standard. This assurance shall be provided prior to a reaffirmation if the IEEE receives notice of a potential Essential Patent Claim after the standard’s approval or a prior reaffirmation. An asserted potential Essential Patent Claim for which an assurance cannot be obtained (e.g., a Letter of Assurance is not provided or the Letter of Assurance indicates that assurance is not being provided) shall be referred to the Patent Committee. A Letter of Assurance shall be either: a) A general disclaimer to the effect that the Submitter without conditions will not enforce any present or future Essential Patent Claims against any person or entity making, using, selling, offering to sell, importing, distributing, or implementing a compliant implementation of the standard; or b) A statement that a license for a compliant implementation of the standard will be made available to an unrestricted number of applicants on a worldwide basis without compensation or under reasonable rates, with reasonable terms and conditions that are demonstrably free of any unfair discrimination. At its sole option, the Submitter may provide with its assurance any of the following: (i) a not-to-exceed license fee or rate commitment, (ii) a sample license agreement, or (iii) one or more material licensing terms. 2 Matthew Fischer (Broadcom)
IEEE-SA Standards Board Bylaws on Patents in Standards Copies of an Accepted LOA may be provided to the working group, but shall not be discussed, at any standards working group meeting. The Submitter and all Affiliates (other than those Affiliates excluded in a Letter of Assurance) shall not assign or otherwise transfer any rights in any Essential Patent Claims that are the subject of such Letter of Assurance that they hold, control, or have the ability to license with the intent of circumventing or negating any of the representations and commitments made in such Letter of Assurance. The Submitter of a Letter of Assurance shall agree (a) to provide notice of a Letter of Assurance either through a Statement of Encumbrance or by binding any assignee or transferee to the terms of such Letter of Assurance; and (b) to require its assignee or transferee to (i) agree to similarly provide such notice and (ii) to bind its assignees or transferees to agree to provide such notice as described in (a) and (b). This assurance shall apply to the Submitter and its Affiliates except those Affiliates the Submitter specifically excludes on the relevant Letter of Assurance. If, after providing a Letter of Assurance to the IEEE, the Submitter becomes aware of additional Patent Claim(s) not already covered by an existing Letter of Assurance that are owned, controlled, or licensable by the Submitter that may be or become Essential Patent Claim(s) for the same IEEE Standard but are not the subject of an existing Letter of Assurance, then such Submitter shall submit a Letter of Assurance stating its position regarding enforcement or licensing of such Patent Claims. For the purposes of this commitment, the Submitter is deemed to be aware if any of the following individuals who are from, employed by, or otherwise represent the Submitter have personal knowledge of additional potential Essential Patent Claims, owned or controlled by the Submitter, related to a [Proposed] IEEE Standard and not already the subject of a previously submitted Letter of Assurance: (a) past or present participants in the development of the [Proposed] IEEE Standard, or (b) the individual executing the previously submitted Letter of Assurance. 3 Matthew Fischer (Broadcom)
IEEE-SA Standards Board Bylaws on Patents in Standards The assurance is irrevocable once submitted and accepted and shall apply, at a minimum, from the date of the standard's approval to the date of the standard's withdrawal. The IEEE is not responsible for identifying Essential Patent Claims for which a license may be required, for conducting inquiries into the legal validity or scope of those Patent Claims, or for determining whether any licensing terms or conditions are reasonable or non-discriminatory. Nothing in this policy shall be interpreted as giving rise to a duty to conduct a patent search. No license is implied by the submission of a Letter of Assurance. In order for IEEE’s patent policy to function efficiently, individuals participating in the standards development process: (a) shall inform the IEEE (or cause the IEEE to be informed) of the holder of any potential Essential Patent Claims of which they are personally aware and that are not already the subject of an existing Letter of Assurance, owned or controlled by the participant or the entity the participant is from, employed by, or otherwise represents; and (b) should inform the IEEE (or cause the IEEE to be informed) of any other holders of such potential Essential Patent Claims that are not already the subject of an existing Letter of Assurance. 4 Matthew Fischer (Broadcom)
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 fixing product prices, allocation of customers, or dividing 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. --------------------------------------------------------------- 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 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. This slide set is available at http://standards.ieee.org/board/pat/pat-slideset.ppt 5 Matthew Fischer (Broadcom)
Question • Are there any patent claim(s)/patent application claim(s) and/or the holder of patent claim(s)/patent application claim(s) that the participant believes may be essential for the use of that standard? • Minute any responses that were given, specifically the patent claim(s)/patent application claim(s) and/or the holder of the patent claim(s)/patent application claim(s) that were identified (if any) and by whom. Matthew Fischer (Broadcom)
Current MAC adhoc meeting agenda-notes pages Most recent agenda-notes pages are at the top of this document (i.e. have lower slide numbers). Matthew Fischer (Broadcom)
Interpretive guide • Text coloring: • Black = pending agenda item • Red = item partially addressed • Green = item completed • Gray = item not addressed in the session indicated at the top of the slide Matthew Fischer (Broadcom)
Agenda for Conference Call 30 Jan 2008 • Submissions related to CIDs • 11-08-0132-00 duration setting – Yuichi – reviewed but not actioned • 11-07-2942-01-000n-lb115-mac-ht-dls.doc – Liwen/MattF • 11-08-xxxx Security – MattS • 11-08-xxxx STBC – Menzo • CID 5188 – MAC General – undetected error – Adrian • Recycled CIDs Matthew Fischer (Broadcom)
Agenda for Thursday 17 Jan 2008 • Submissions related to CIDs • 11-07-2992-04 multirate – Yuichi – CID 5024, 5464 resolved • 11-08-0132-00 duration setting – Yuichi – reviewed but not actioned • 11-07-2942-01-000n-lb115-mac-ht-dls.doc – Liwen/MattF • 11-08-0190 Measurement Pilot – Doug • 11-08-xxxx Security – MattS • 11-08-0184 AMSDU – MattF • Call for volunteers to prepare submissions to address CIDs • Step through unassigned CIDs • Start with group discussion comments • Step through assigned CIDs • Several STBC comments resolved – several remaining. Matthew Fischer (Broadcom)
Agenda for Wednesday 16 Jan 2008 • Submissions related to CIDs • 11-07-2745-01 – MattF – Mac MGMT – reviewed, resolved some comments, will be revised for IBSS issue – group prefers approach that restricts IBSS to not changing dynamic values for the life of the IBSS and explicitly naming which values are per-STA and which are per-IBSS, use table in HT Info element IBSS column as a start • SEE 11-07-2999-04-000n-LB115-CID5276-MAC-MGMT.doc – MattF • Agreed to forbid dynamic parameter changes in IBSS, agreed to make explicit list of which parameters are adopted and which are not for IBSS as part of BSSdescription in 10.3.2.2.2 • 11-07-2992-02 multirate – Yuichi – CID 5024, 5464 remaining • 11-08-0132-00 duration setting – Yuichi – reviewed but not actioned • 11-07-2942-01-000n-lb115-mac-ht-dls.doc – Liwen/MattF • 11-08-xxxx Measurement Pilot – Doug • 11-08-0146 Submission-A-MSDU-in-7.2.2.1 – Amit/Adrian • Reviewed, polled for support 3-0, need to raise this in TGn, since there is no CID • 11-09-xxxx Security - MattS • Call for volunteers to prepare submissions to address CIDs • Step through unassigned CIDs • Start with group discussion comments • Step through assigned CIDs Matthew Fischer (Broadcom)
Agenda for Tuesday 15 Jan 2008 • Submissions related to CIDs • 11-07-2745-01 – MattF – Mac MGMT – reviewed, resolved some comments, will be revised for IBSS issue – group prefers approach that restricts IBSS to not changing dynamic values for the life of the IBSS and explicitly naming which values are per-STA and which are per-IBSS, use table in HT Info element IBSS column as a start • SEE 11-07-2999-00-000n-LB115-CID5276-MAC-MGMT.doc – MattF • Agreed to forbid dynamic parameter changes in IBSS, agreed to make explicit list of which parameters are adopted and which are not for IBSS as part of BSSdescription in 10.3.2.2.2 • 11-08-0009-02-000n-tgn-D3 0-security-review.doc CID 5116, 5899 – Adrian • CID 5116 still open. • 11-07-2937-01-000n-tgn-lb115-mac-submission-frame-misc-doc.doc – Padam • 11-08-0014-01-000n-tgn-lb115-submission-mac-decouple-from-ht.doc – Padam • 11-07-2992-02 multirate – Yuichi – CID 5024, 5464 remaining • 11-08-0132-00 duration setting - Yuichi • 11-08-0043-00-000n-tgn-lb115-submission-mac-beacon size.doc – Peter • 11-07-2942-01-000n-lb115-mac-ht-dls.doc – Liwen/MattF • 11-08-xxxx Measurement Pilot - Doug • Call for volunteers to prepare submissions to address CIDs • Step through unassigned CIDs • Start with group discussion comments • Step through assigned CIDs Matthew Fischer (Broadcom)
CID 5116 • CID 5116 • CIDPageClauseCommentProposed Change511696.018During the development leading up to D2.0, there were attempts to analyze the security implications of the text (see MAC Ad Hoc minutes at Melbourne ad hoc). However, it is not evident such efforts are repeated for D3.0.Analyze the security implications of the text and address any weaknesses. • Proposed Resolution • Counter (accept in principle). A security review was undertaken and the results documented in 11-08/0009r2. This review identified one problem not associated with any other comment related to the protection of the “A-MSDU Present” field and subsequent discussion in the MAC ad-hoc identified a solution to this problem. • TGn Editor: Make editorial changes shown in 11-08/0009r2. • --------- • and: • Editing Instructions • TGn Editor: Change 11.18 as follows: • 11.18 RSNA A-MSDU procedures (#289) • When dot11RSNAEnabled is TRUE, a STA indicates support for PP (payload protected) A-MSDU or SPP • (signaling and payload protected) A-MSDU during association or reassociation. On either association or reassociation, the associating STA and its peer STA both determine and maintain a record of whether an encrypted • A-MSDU sent to its peer is to be a PP A-MSDU or an SPP A-MSDU based on the value of the SPP • A-MSDU Capable and SPP A-MSDU Required subfields of the RSN Capabilities field of the RSN information • element (see 7.3.2.25.3 (RSN capabilities (#289))). • The SME of an RSNA and HT-capable STA may choose to associate with an RSNA STA that has the SPP • A-MSDU Capable subfield set to either 1 or 0, and the SPP A-MSDU Required field set to either 1 or 0. • Table 11-8a (A-MSDU STA Behavior for RSNA associations) defines both transmit and receive behavior related to the transmission and reception of individually addressed A-MSDUs of a first STA (STA1) that has successfully negotiated an HT and RSNA (re)association with a second STA (STA2). Reception and transmission of A-MSDUs on non-RSNA associations is unaffected by the values of the SPP A-MSDU Capable and SPP A-MSDU Required fields. • Group addressed A-MSDUs shall not be protected (i.e., are always transmitted without encryption). Matthew Fischer (Broadcom)
Agenda for Friday and Saturday 11-12 Jan 2008 • Revisit previous CIDs that have database problems: • 11-07-2938r4 -- • CID 5622 – 9.12 now informative - may have been covered, but no record in database • CID 5222 – RTS Threshold as time not octets - re-approve because of misplaced resolution • Continue partially considered submissions • CID 5599 • 11-08-0040r1, MAC FRAME – Adrian • Poll on removing the word Delayed from the QoS Data with BA agreement row of the AMPDU contents table for Data Enabled Immediate Response Y-N-Do not understand = 1-5-2 • 11-07-2978r1, RD inconsistencies – Yuichi • Submissions related to CIDs • 11-07-2795 – Naveen – PSMP operation • Accepted CIDs 5648, 5381, still has open CIDs – now transferred to 11-08-0066 • 11-08-0066-00 – PSMP operation – Naveen • 11-07-2745-01 – MattF – Mac MGMT – reviewed, resolved some comments, will be revised for IBSS issue – group prefers approach that restricts IBSS to not changing dynamic values for the life of the IBSS and explicitly naming which values are per-STA and which are per-IBSS, use table in HT Info element IBSS column as a start • SEE 11-07-2999-00-000n-LB115-CID5276-MAC-MGMT.doc – MattF • Agreed to forbid dynamic parameter changes in IBSS, agreed to make explicit list of which parameters are adopted and which are not for IBSS as part of BSSdescription in 10.3.2.2.2 • 11-07-xxxx – Doug – MP Frame • 11-08-0009-00-000n-tgn-D3 0-security-review.doc CID 5116, 5899 – Adrian • CID 5116 still open and CID 5899 is closed. • 11-08-0026-00-000n-tgn -- BA Reordering for A-MPDU.ppt -- CID 5899 – Luke • Straw polls on proposed solutions from 5899 – a: 6,1 b: 2,4 c: 1,3 d: 6,0 • It is suggested that while solution d would be nice, it is asked if anyone in the room is aware of anyone that could create the text for such a solution within the time frame remaining for LB115 comment resolution and the answer is no, so CID 5899 is rejected with one vote against the rejection. • 11-08-0014-00-000n-tgn-lb115-submission-mac-decouple-from-ht.doc – Padam • 11-07-2937-01-000n-tgn-lb115-mac-submission-frame-misc-doc.doc – Padam • 11-07-2992-01 Multirate – Yuichi • 11-07-2993-01 L-SIG TXOP – Yuichi – halfway completed • 11-08-0043-00-000n-tgn-lb115-submission-mac-beacon size.doc – Peter • Call for volunteers to prepare submissions to address CIDs • Step through unassigned CIDs • Start with group discussion comments • Step through assigned CIDs Matthew Fischer (Broadcom)
Notes from TGn MAC adhoc Jan 10, 2008 • Discuss Patent policy, response to question of essential patents • Covered in opening ad-hoc by Bruce Kraemer, TGn chair • Submissions related to CIDs • 11-07-2938-03-000n-tgn-lb115-submission-MAC-operation – Adrian • Approved: 5601 (PIFS), 5604 (Dual-CTS), 5522 (TXOP limit of 0) • Action: Adrian to upload r4 edited as agreed. • 11-08-0030-00-000n-tgn-lb115-submission-macBA – Solomon • 5163 – Reject, U • 5164 – Reject, U with a modified description as shown in R1 (done) • 5009 – Accept, U • 5621 – Accept, U Matthew Fischer (Broadcom)
Notes from TGn MAC adhoc Jan 10, 2008 (cont) • 11-07-2991r1, Backoff Procedures, - Tomo (r1 uploaded) • 5316 – Accept, U • 5523 – Reject, U • 5524 – Reject, U • 5467 – Counter, U • Action: chair to ensure with Yuichi that the rules for setting the Duration/ID field also honor any medium occupancy limit. (This assumption is built into the resolution for 5467). • 5372 – Counter, U • 5619 – Counter, U • 5525 – Counter, U • 5373 – Counter, U • 5804 – Withdrawn (Solomon Trainin) • 5158 – Counter, U • 5317 – Counter, U • Action: on discussion, Adrian agrees to work with Matt to relocate the 11.15.7 & 11.15.8 into a proper position in clause 9. • 5374 – Counter, U • R1 uploaded as amended during the meeting with voting record • 11-08-0040r0, MAC FRAME – Adrian • 11-08-0040r0 was discussed and edited in situ to give R1. • Results of agreements are documented in R1. • Resolutions agreed unanimously for: 5579 5581 5292 5419 5287 5423 5294 • 5599 was not agreed on (A-MPDU table re-org) • 11-07-2978r0, RD inconsistencies, related to CID 5599 – Yuichi • R1 to be uploaded Matthew Fischer (Broadcom)
Agenda for TGn MAC adhoc Jan 10, 2008(as originally circulated) • Agenda • Discuss Patent policy, response to question of essential patents • Call for volunteers to prepare submissions to address CIDs • Submissions related to CIDs • 11-07-2938-00-000n-tgn-lb115-submission-MAC-operation – Adrian • 5604 still open, other CIDs resolved through and including CID 5306 • Yuichi should look at CID 5304 • 11-07-2795 – Naveen – PSMP operation • Accepted CIDs 5648, 5381, still has open CIDs • 11-07-2745-01 – MattF – Mac MGMT – reviewed, resolved some comments, will be revised for IBSS issue – group prefers approach that restricts IBSS to not changing dynamic values for the life of the IBSS and explicitly naming which values are per-STA and which are per-IBSS, use table in HT Info element IBSS column as a start • SEE 11-07-2999-00-000n-LB115-CID5276-MAC-MGMT.doc - MattF • 11-07-xxxx – Doug – MP Frame • 11-08-0009-00-000n-tgn-D3 0-security-review.doc CID 5116, 5899 - Adrian • 11-08-0026-00-000n-tgn -- BA Reordering for A-MPDU.ppt -- CID 5899 – Luke • 11-08-0014-00-000n-tgn-lb115-submission-mac-decouple-from-ht.doc – Padam • 11-07-2937-01-000n-tgn-lb115-mac-submission-frame-misc-doc.doc – Padam • 11-07-2992-00 Multirate – Yuichi • 11-07-2993-00 L-SIG TXOP – Yuichi • 11-07-2978-00 RD – Yuichi • 11-08-0030-00-000n-tgn-lb115-submission-macBA - Solomon • Step through unassigned CIDs • Start with group discussion comments • Step through assigned CIDs Matthew Fischer (Broadcom)
Agenda for TGn MAC adhoc November 28, 2007 Conf Call 08:00 PST • Agenda • Discuss Patent policy, response to question of essential patents • No response • Attendance – send email to mfischer@broadcom.com • Tomoko Adachi, Toshiba – Jon Rosdahl, CSR – Bruce Kraemer, Marvell – Matthew Fischer, Broadcom – Adrian Stephens, Intel – Solomon Trianin, Intel – Luke Qian, Cisco - • Call for volunteers to prepare submissions to address CIDs • Submissions related to CIDs • 11-07-2936-00-000n-tgn-lb115-submission-MAC-MLME-SAP Adrian • All CIDs in this doc resolved • 11-07-2935 – Adrian - element length • All CIDs in this doc resolved • 11-07-2938-00-000n-tgn-lb115-submission-MAC-operation – Adrian • 5604 still open, other CIDs resolved through and including CID 5306 • Yuichi should look at CID 5304 • 11-07-2795 – Naveen – PSMP operation • Accepted CIDs 5648, 5381, still has open CIDs • 11-07-2745-01 – MattF – Mac MGMT – reviewed, resolved some comments, will be revised for IBSS issue – group prefers approach that restricts IBSS to not changing dynamic values for the life of the IBSS and explicitly naming which values are per-STA and which are per-IBSS, use table in HT Info element IBSS column as a start • 11-07-xxxx – Doug – MP Frame • Step through unassigned CIDs • Start with group discussion comments • Step through assigned CIDs Matthew Fischer (Broadcom)
Agenda for TGn MAC adhoc November 15, 2007 AM1,2 • Agenda • Call for volunteers to prepare submissions to address CIDs • Submissions related to CIDs • 11-07-2795 – Naveen – PSMP operation • Accepted CIDs 5648, 5381, still has open CIDs • 11-07-2745-01 – MattF – Mac MGMT – reviewed, resolved some comments, will be revised for IBSS issue – group prefers approach that restricts IBSS to not changing dynamic values for the life of the IBSS and explicitly naming which values are per-STA and which are per-IBSS, use table in HT Info element IBSS column as a start • 11-07-xxxx – Doug – MP Frame • Step through unassigned CIDs • Start with group discussion comments • Step through assigned CIDs Matthew Fischer (Broadcom)
Agenda for TGn MAC adhoc November 14, 2007 PM1 • Agenda • Call for volunteers to prepare submissions to address CIDs • Submissions related to CIDs • 11-07-2795 – Naveen – PSMP operation • Accepted CIDs 5648, 5381, still has open CIDs • 11-07-2815 – Naveen – AMPDU • Accepted remaining CIDs • 11-07-2745-01 – MattF – Mac MGMT – reviewed, resolved some comments, will be revised for IBSS issue – group prefers approach that restricts IBSS to not changing dynamic values for the life of the IBSS and explicitly naming which values are per-STA and which are per-IBSS, use table in HT Info element IBSS column as a start • 11-07-2744-01 – MattF – AMSDU – all CIDs resolved or withdrawn • 11-07-2746-01 – MattF – MAC BA Mgmt – reviewed – will be revised by Adrian, no CID resolved • 11-07-2859 – Adrian – Frame Sequence – reviewed, resolved all CIDs • 11-07-2871 – Adrian – RD • 11-07-2895 – Adrian - AMPDU • 11-07-xxxx – Doug – MP Frame • Step through unassigned CIDs • Start with group discussion comments • Step through assigned CIDs Matthew Fischer (Broadcom)
Agenda for TGn MAC adhoc November 13, 2007 PM1 • Agenda • Review of LB115 MAC adhoc comment status • Comment count = 236 (as of 11/6/07) • Comment groups – see 11-07-2706-01-000n-lb115-mac-comments.xls • Review of procedures for processing comments within the MAC adhoc • 11-06-0689-01-000n-tgn-MAC-LB84-Ad-Hoc-Operation.ppt • Call for volunteers to prepare submissions to address CIDs • Submissions related to CIDs • 11-07-2795 – Naveen – PSMP operation • Accepted three resolutions, looking for R1 to provide mods for CIDs 5526, 5646, need more review to cover additional CIDS • 11-07-2815 – Naveen – AMPDU • Reviewed, Naveen to update to R1 with changes • 11-07-2745-01 – MattF – Mac MGMT • 11-07-2744-01 – MattF – AMSDU • 11-07-2746-01 – MattF – MAC BA Mgmt • Step through unassigned CIDs • Start with group discussion comments • Step through assigned CIDs Matthew Fischer (Broadcom)
TGn MAC adhoc Nov 12, 2007 minutes • IEEE patent policy discussed, no one asked for a reading • In response to the question of essential claims (see slide 12), no response was elicited • Attendance • Matthew Fischer, Broadcom • Reviewed CIDs in documents: • Straw polls: TEMPLATE Matthew Fischer (Broadcom)
MAC adhoc Motions All MAC adhoc motions are contained in this section, with the most recent motions appearing first. Matthew Fischer (Broadcom)
MAC adhoc meeting agenda-notes from past sessions Matthew Fischer (Broadcom)
Comment Groups (11-06-07), part 1 Matthew Fischer (Broadcom)
Comment Groups (11-06-07), part 2 Matthew Fischer (Broadcom)
Comment Groups (11-06-07), part 3 Matthew Fischer (Broadcom)
For better viewing Matthew Fischer (Broadcom)
MAC Motion 115g • Set of 13 comments • Various topics, various resolutions • Comments resolved at Jan interim session, Thursday, Jan 17 • All CIDs resolutions proposed with unanimous agreement • #xxx Move to accept comment resolutions in 11-07/2706r15 tab “mac motion 115g” • 08-01-17 PM2 TGn action xxxx Matthew Fischer (Broadcom)
MAC Motion 115f • Set of 6 comments • Various topics, various resolutions • Comments resolved at Jan interim session, Wednesday, Jan 16 • All CIDs resolutions proposed with unanimous agreement • #xxx Move to accept comment resolutions in 11-07/2706r14 tab “mac motion 115f” • 08-01-17 PM2 TGn action xxxx Matthew Fischer (Broadcom)
MAC Motion 115e • Set of 36 comments • Various topics, various resolutions • Comments resolved at Jan interim session, Tuesday, Jan 15 • All CIDs resolutions proposed with unanimous agreement • #288 Move to accept comment resolutions in 11-07/2706r12 tab “mac motion 115e” • 08-01-16 PM2 TGn action approved Matthew Fischer (Broadcom)
MAC Motion 115d • Set of 75 comments • Various topics, various resolutions • Comments resolved in Conference calls from 2007 plus TGn adhoc of Jan 10-12, 2008 • Some comments formerly in tab Mac motion 115c, which has disappeared • All CIDs resolutions proposed with unanimous agreement except CID 5899 which passed the adhoc with a vote of 6-1 – see next two slides • #287 Move to accept comment resolutions in 11-07/2706r11 tab “mac motion 115d” • 08-01-15 EVE TGn action approved Matthew Fischer (Broadcom)
CID 5899 Matthew Fischer (Broadcom)
CID 5899 discussion • In addition to the information found in the proposed resolution the following point was disccussed during the adhoc: • The sender of frames (the originator with respect to the Block Ack agreement) is able to determine that an attack has occurred • If a malicious BAR is sent (with an out-of-window SN), then the recipient responds with a BA that contains the SSN of the malicious BAR • The originator sees a BA SSN that does not correspond to the originator’s current concept of SSN and can establish that an attack has occurred • If a malicious packet is sent, (with an out-of-window SN), then the recipient responds with a BA that contains the SSN of the malicious BAR • The originator sees a BA SSN that does not correspond to the originator’s current concept of SSN and can establish that an attack has occurred Matthew Fischer (Broadcom)
MAC Motion 115c • Set of 23 comments • Various topics • Comments resolved 11/28 (TGn conf call), plus three from 11/15 (end of Nov 2007 session, not included in previous motions) • All resolved unanimously • #xxx Move to accept comment resolutions in 11-07/2706r09 tab “mac motion 115c” • 08-01-16 AM2 TGn action xxxx Matthew Fischer (Broadcom)
MAC Motion 115b • Set of 43 comments • Various topics • Comments resolved 11/15, plus three from 11/13 and 11/14 • All resolved unanimously • #277 Move to accept comment resolutions in 11-07/2706r07 tab “mac motion 115b” • 07-11-15 PM2 TGn action approved Matthew Fischer (Broadcom)
MAC Motion 115a • Set of 20 comments • Frame Exchanges, AMSDU, PSMP • Comments resolved 11/13 and 11/14 • All resolved unanimously • #276 Move to accept comment resolutions in 11-07/2706r07 tab “mac motion 115a” • 07-11-15 PM2 TGn action approved Matthew Fischer (Broadcom)
MAC Motion motion_example • Set of x comments • Topic • Relevant documents 11-07-xxxxry • General nature • #xxx NOT REALLY A MOTION - Move to accept comment resolutions in 11-07/0338rX tab “motion_example” • 07-03-13 PM2 TGn action xxxx TEMPLATE Matthew Fischer (Broadcom)
References • 11-07-2705-00-000n-lb115-mac-adhoc-report.ppt • (this document) • 11-07-2706-01-000n-lb115-MAC-comments.xls • Comment spreadsheet • 11-06-0689-01-000n-tgn-MAC-LB84-Ad-Hoc-Operation.ppt • LB84 MAC adhoc rules Matthew Fischer (Broadcom)