1 / 50

TGah MAC Ad Hoc Agenda and Report

TGah MAC Ad Hoc Agenda and Report. Authors:. Date: 2012-09-18. Agenda for September 18, 2012 – PM1, India Wells, CA. Designation of a secretary for the minutes Reminder on Affiliation, IEEE Patent review and IP claims policies Reminder to record attendance

cili
Download Presentation

TGah MAC Ad Hoc Agenda and Report

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. TGah MAC Ad Hoc Agenda and Report Authors: Date: 2012-09-18 Shao, Merlin, Liu

  2. Agenda for September 18, 2012 – PM1, India Wells, CA • Designation of a secretary for the minutes • Reminder on Affiliation, IEEE Patent review and IP claims policies • Reminder to record attendance • Summary of operating rules for MAC ad hoc group • Submissions • Any more submissions? • Straw polls / Pre-motions Shao, Merlin, Liu

  3. Summary of ad hoc operating rules (1) • The following summary is derived from 11-12/239r2 • Pre-Motion: A pre-motion (doesn’t require voting rights) result of >=75% is required within an Ad Hoc to approve the resolution of all or part of an issue and forward that resolved item to the Taskgroup where it becomes a motion that requires >=75% approval to modify the specification framework or the draft specification. • Note: the term Pre-Motion was introduced by11ac ad hoc operating rules to create a distinction between straw polls which intent is to result in a Motion at the Taskgroup, and strawpolls which intent is to only gauge the opinion of the members on a particular topic and are not intended to results in a motion at the Taskgroup. • Stalemate: In the case a consensus can not be reached within an Ad Hoc group (a stalemate that prohibits further progress), the subject is moved to the Taskgroup if an Ad Hoc straw poll vote to move the subject to the Taskgroup achieves >50% approval. Shao, Merlin, Liu

  4. Summary of ad hoc operating rules (2) • The following summary is derived from 11-12/239r2 • Transfer to another ad hoc: A motion passing with >50% in the Taskgroup shall be sufficient to move an issue previously assigned to an Ad Hoc group to any Ad Hoc group. A straw poll vote of >50% is required in an Ad Hoc group to refuse an issue from the Taskgroup. • Transfer to another ad hoc: An issue may be sent from one Ad Hoc to another if both the sending Ad Hoc and the receiving Ad Hoc approve straw polls for taking the respective actions with >50% approval. A notice should be sent to the reflector indicating the approval of a straw poll to move an issue. • To be accepted into the Draft specification, proposals from Ad Hoc group require a motion that passes with >=75% Taskgroup approval Shao, Merlin, Liu

  5. Submissions Shao, Merlin, Liu

  6. Interpretive guide • Text coloring: • Black = pending agenda item • Red = item partially addressed • Green = item completed • Gray = item not addressed • The following slides include the pending MAC submissions as shown in TG agenda 11-12/1115r7 Shao, Merlin, Liu

  7. Submissions • 12/1100 mid-CRC-in-long-beacon (MAC) • Yong Liu (Marvell) • 12/1101 active-polling • Yong Liu (Marvell) Shao, Merlin, Liu

  8. Submissions • 12/1083 Sensor Only BSS • George Calcev (Huawei) Shao, Merlin, Liu

  9. Submissions • 12/1084 TIM and Page Segmentation • ChittabrataGhosh (Nokia) • 12/1086 TIM for no buffered unicasttrafic • KaiyingLv (ZTE Corp.) Shao, Merlin, Liu

  10. Submissions • 12/1065 Estimated battery life improvement by TFM2P • Shusaku Shimada (Yokogawa Co.) Shao, Merlin, Liu

  11. Submissions • 12/1089 Frame Classification Based on MAC Header Content • Qi Wang (Broadcom Corporation) Shao, Merlin, Liu

  12. MAC ad hoc Straw Polls Shao, Merlin, Liu

  13. Straw Poll 1 Shao, Merlin, Liu

  14. MAC ad hoc Pre-Motions to be brought for vote in TGahtask group Shao, Merlin, Liu

  15. Pre-Motion 1 (12/1100r1) • Do you support • The Mid-CRC concept as in slide 5; • The Mid-CRC design as in slide 6 and 7 • Passed by unanimous consent Shao, Merlin, Liu

  16. Pre-Motion 2 (12/1101r1) • Do you support to include in SFD that: • An active polling STA can solicit the BSS change sequence (one byte) from an AP upon waking up. • AP may provide the information immediately or suggest the STA to check beacons. • Yes: 23 • No: 0 • Abstain:1 Passed Shao, Merlin, Liu

  17. Pre-Motion 3 (12/1101r1) • Do you support to include in SFD that: • An active polling STA can solicit the current timestamp from an AP upon waking up • AP may provide the information immediately or suggest the STA to check beacons Passed by unanimous consent Shao, Merlin, Liu

  18. Pre-Motion 4 (12/1083r0) Move to accept the separation between BSS Sensor Only, BSS Offloading Only and BSS Mixed Mode ? Yes: 32 No: 0 Abstain: 3 Passed Shao, Merlin, Liu

  19. Pre-Motion 5 (12/1083r0) Move to accept the identification of STA device types as Sensor Only, Offloading Only and Mixed Mode STAs ? Yes:28 No: 0 Abstain:2 Passed Shao, Merlin, Liu

  20. Pre-Motion 6 (12/1083r0) Move to accept that the Sensor Only/Offload Only/Mixed BSS type is provided in beacons /Probe Response? Passed by unanimous consent Shao, Merlin, Liu

  21. Pre-Motion 7 (12/1084r3) Do you agree to have a fixed length page segment per TIM segment as described in Slide 6? Passed by unanimous consent Shao, Merlin, Liu

  22. Pre-Motion 8 (12/1084r3) Do you agree to introduce a Page Bitmap for early indication of block-level buffered data? Passed by unanimous consent Shao, Merlin, Liu

  23. Pre-Motion 9 (12/1084r3) Do you agree to have a Segment Count IE as in Slide 9 for indication of assignment of STAs in TIM segments? Passed by unanimous consent Shao, Merlin, Liu

  24. Pre-Motion 10 (12/1084r3) Do you agree to have the frame format for the Segment Count IE as shown in Slide 8? Passed by unanimous consent Shao, Merlin, Liu

  25. Pre-Motion 11 (12/1084r1) Do you agree to include the TIM Segment Number field in the TIM IE as shown in Slide 10? Passed by unanimous consent Shao, Merlin, Liu

  26. Pre-Motion 12 (12/1086r1) Do you support to add the texts below in the TGah SFD 4.3.3 TIM encoding: • R.4.3.3.B: the Group Addressed Buffered Data field (Bit 0 of the Bitmap Control field) is set to 1 when one or more group addressed MSDUs/MMPDUs are buffered at the AP. • Passed by unanimous consent Shao, Merlin, Liu

  27. Pre-Motion 13 (12/1086r1) Do you support to add the texts below in the TGah SFD 4.3.3 TIM encoding: • R.4.3.3.C: If there is no bit in the traffic indication bitmap set to 1 in the TIM IE, the Encoded TIM Bitmap field is not present and the Length field is set to 3 • Passed by unanimous consent Shao, Merlin, Liu

  28. Motions from MAC ad hoc meeting Shao, Merlin, Liu

  29. Motion 1 (12/1100r1) • Do you support • The Mid-CRC concept as in slide 5; • The Mid-CRC design as in slide 6 and 7 • Yes: • No: • Abstain: Shao, Merlin, Liu

  30. Motion 2 (12/1101r1) • Do you support to include in SFD that: • An active polling STA can solicit the BSS change sequence (one byte) from an AP upon waking up. • AP may provide the information immediately or suggest the STA to check beacons. • Yes: • No: • Abstain: Shao, Merlin, Liu

  31. Motion 3 (12/1101r1) • Do you support to include in SFD that: • An active polling STA can solicit the current timestamp from an AP upon waking up • AP may provide the information immediately or suggest the STA to check beacons • Yes: • No: • Abstain: Shao, Merlin, Liu

  32. Motion 4 (12/1083r0) Move to accept the separation between BSS Sensor Only, BSS Offloading Only and BSS Mixed Mode ? Yes: No: Abstain: Shao, Merlin, Liu

  33. Motion 5 (12/1083r0) Move to accept the identification of STA device types as Sensor Only, Offloading Only and Mixed Mode STAs ? Yes: No: Abstain: Shao, Merlin, Liu

  34. Motion 6 (12/1083r0) Move to accept that the Sensor Only/Offload Only/Mixed BSS type is provided in beacons /Probe Response? Yes: No: Abstain: Shao, Merlin, Liu

  35. Motion 7 (12/1084r3) Do you agree to have a fixed length page segment per TIM segment as described in Slide 6? Yes: No: Abstain: Shao, Merlin, Liu

  36. Motion 8 (12/1084r3) Do you agree to introduce a Page Bitmap for early indication of block-level buffered data? Yes: No: Abstain: Shao, Merlin, Liu

  37. Motion 9 (12/1084r3) Do you agree to have a Segment Count IE as in Slide 9 for indication of assignment of STAs in TIM segments? Yes: No: Abstain: Shao, Merlin, Liu

  38. Motion 10 (12/1084r3) Do you agree to have the frame format for the Segment Count IE as shown in Slide 8? Yes: No: Abstain: Shao, Merlin, Liu

  39. Motion 11 (12/1084r1) Do you agree to include the TIM Segment Number field in the TIM IE as shown in Slide 10? Yes: No: Abstain: Shao, Merlin, Liu

  40. Motion 12 (12/1086r1) Do you support to add the texts below in the TGah SFD 4.3.3 TIM encoding: • R.4.3.3.B: the Group Addressed Buffered Data field (Bit 0 of the Bitmap Control field) is set to 1 when one or more group addressed MSDUs/MMPDUs are buffered at the AP. • Yes: • No: • Abstain: Shao, Merlin, Liu

  41. Motion 13 (12/1086r1) Do you support to add the texts below in the TGah SFD 4.3.3 TIM encoding: • R.4.3.3.C: If there is no bit in the traffic indication bitmap set to 1 in the TIM IE, the Encoded TIM Bitmap field is not present and the Length field is set to 3 • Yes: • No: • Abstain: Shao, Merlin, Liu

  42. Appendix - Policies Shao, Merlin, Liu

  43. Instructions for the WG Chair The IEEE-SA strongly recommends that at each WG meeting the chair or a designee: • Show slides #1 through #4 of this presentation • Advise the WG attendees that: • The IEEE’s patent policy is consistent with the ANSI patent policy and is described in Clause 6 of the IEEE-SA Standards Board Bylaws; • Early identification of patent claims which may be essential for the use of standards under development is strongly encouraged; • There may be Essential Patent Claims of which the IEEE is not aware. Additionally, neither the IEEE, the WG, nor the WG chair can ensure the accuracy or completeness of any assurance or whether any such assurance is, in fact, of a Patent Claim that is essential for the use of the standard under development. • Instruct the WG Secretary to record in the minutes of the relevant WG meeting: • That the foregoing information was provided and that slides 1 through 4 (and this slide 0, if applicable) were shown; • That the chair or designee provided an opportunity for participants to identify patent claim(s)/patent application claim(s) and/or the holder of patent claim(s)/patent application claim(s) of which the participant is personally aware and that may be essential for the use of that standard • 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. • The WG Chair shall ensure that a request is made to any identified holders of potential essential patent claim(s) to complete and submit a Letter of Assurance. • It is recommended that the WG chair review the guidance in IEEE-SA Standards Board Operations Manual 6.3.5 and in FAQs 12 and 12a on inclusion of potential Essential Patent Claims by incorporation or by reference. Note: WG includes Working Groups, Task Groups, and other standards-developing committees with a PAR approved by the IEEE-SA Standards Board. Shao, Merlin, Liu

  44. 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 Shao, Merlin, Liu

  45. 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 Shao, Merlin, Liu

  46. 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 Shao, Merlin, Liu

  47. 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 Shao, Merlin, Liu

  48. 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 Shao, Merlin, Liu

  49. 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 Shao, Merlin, Liu

  50. 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 Shao, Merlin, Liu

More Related