Presentation on theme: "Doc.: Submission, Slide 1 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [SC Opening/ Report for March."— Presentation transcript:
doc.: Submission, Slide 1 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [SC Opening/ Report for March 2014 Session] Date Submitted: [16 Mar2014] Source: [Patrick Kinney] Company [Kinney Consulting LLC] Address [Chicago area, IL, USA] Voice:[+1.847.960.3715], E-Mail:[firstname.lastname@example.org] Re: [SC Opening Report for March 2014 Session.] Abstract:[Opening Report for the Mar Session] Purpose: Notice:This document has been prepared to assist the IEEE P802.15. 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 acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P802.15.
doc.: Submission, Slide 3 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. Instructions for the WG Chair Slide 3
doc.: Submission, Slide 4 Participants, Patents, and Duty to Inform All participants in this meeting have certain obligations under the IEEE-SA Patent Policy. Participants: l “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 l “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 or patent claims l “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) l The above does not apply if the patent claim 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 l Early identification of holders of potential Essential Patent Claims is strongly encouraged l No duty to perform a patent search Slide #1 Slide 4
doc.: Submission, Slide 5 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 Slide #2 If you have questions, contact the IEEE-SA Standards Board Patent Committee Administrator at email@example.com 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 5
doc.: Submission, Slide 6 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 Slide 6
doc.: Submission, Slide 7 Other Guidelines for IEEE WG Meetings l All IEEE-SA standards meetings shall be conducted in compliance with all applicable laws, including antitrust and competition laws. l Don’t discuss the interpretation, validity, or essentiality of patents/patent claims. l Don’t discuss specific license rates, terms, or conditions. l Relative costs, including licensing costs of essential patent claims, of different technical approaches may be discussed in standards development meetings. l Technical considerations remain primary focus l Don’t discuss or engage in the fixing of product prices, allocation of customers, or division of sales markets. l Don’t discuss the status or substance of ongoing or threatened litigation. l 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 Slide 7
doc.: Submission, Slide 9 Chair’s Role http://ieee802.org/Mike_Spring_Article_on_Stds_ Process.pdfhttp://ieee802.org/Mike_Spring_Article_on_Stds_ Process.pdf …the chairperson of the working group is key to what and how fast a standard is produced. The chair of the committee acts as a facilitator with little power to legislate. The chair must be knowledgeable about the subject but also know how a standard may be used by various segments of the industry. A chairperson should be a leader-diplomat-observer, in equal proportions. Also, the chairperson should not be a doer, perfectionist or obstructionist. This is consistent with the view of the chairperson as a skilled leader with strong negotiation skills who delegates.
doc.: Submission Timing Status Document in progress (15-14-0111-00-0mag) lists all the attributes, constants and parameters that specify or affect specification of MAC timing. Color coded table - what it is and where it came from Red means serious issue probably can’t ignore Yellow means may need attention Blue means minor issues (editorial or other obvious fixes) To include discussion of the issues Problem statement (conflict, unclear, etc.) Proposed fixes (eventually) Currently a work in progress Initial version to circulate among Coconspirators and be posted for next weeks call (4/March) Slide 11,
doc.: Submission Method Search standard for PIB attributes, constants and SAP parameters that may control or affect MAC timing 802.15.4-2011 802.15.4e-2012 802.15.4f-2012 802.15.4g-2012 802.15.4j-2013. 802.15.4k-2013 Draft P802.15.4m Draft P802-15-4p Examine definition and use of each Look for complex entanglements (dependencies or complex specs) Look for conflicts amongst amendments Consider history – what’s been confused and debated Non-trivial task Slide 12,
doc.: Submission Red Zone 1.Acknowledgement Timing a)Complex, PHY specific definitions, some with mixed units b)Depends on a number of constants and other attributes that have been touched a lot c)Specified in more than one way in the standard d)Reference point for timers unclear e)When/if to use CSMA a)More than 4 different CSMA scenarios need addressing 2.LIFs and SIFs a)Suggestion to replace with single IFS specification b)Ripples a lot (including into Ack timing) c)Backwards compatibility issues? Slide 13,
doc.: Submission Yellow Zone 1.macResponseWaitTime a)Complex definition dependent on attributes and constants that have changed throughout amendments b)Should review to ensure still valid for all PHYs 2.macMaxFrameTotalWaitTime a)Complex definition dependent on a bunch of things 3.aBaseSlotDuration and aBaseSuperframeDuration a)Used a lot of places, needs review 4.aUnitBackoffPeriod and aCCATime a)Used in a number of places where it is maybe should not be; b)PHY specific but maybe should not be; c)Differing styles in amendments d)aUnitBackoffPeriod not changed by PHY amendments but maybe should have been? Slide 14,
doc.: Submission Blue Zone PHY dependent timings (6.4.3): some things stated as UWB PHY dependent are really ALOHA dependent macSyncSymbolOffset needs clean-up Duty cycle control macTxControlActiveDuration, macTxControlPauseDuration and macTxTotalDuration Intended to provide control of transmit duty cycle Specification unclear (no MAC or PHY function uses them) macTxTotal Duration: should be read-only except can be reset (i.e. not any value written) No harm done? Slide 15,
doc.: Submission, Slide 16 TG28 Changes ETSI TC ERM change requests 1) Frame ID Extension SC-M agreed to recommend defining the last reserved Frame ID value (0b111) to indicate an Extended Frame ID format consisting of 5 additional bits (total 8-bit Frame ID). IEEE will manage the assignment of the extended Frame ID space to IEEE task groups or SDOs. The value 0b111 111 was agreed to be assigned to TIA to ratify the TR51 Frame ID, giving TIA effectively 4 Frame IDs. The frame format associated with extended Frame ID values is to be defined with each Frame ID as usual.
doc.: Submission, Slide 17 TG28 Changes ETSI TC ERM change requests 2) ID Management SC-M agreed to recommend that IEEE should manage the allocation of various resource IDs including IE IDs. The re-definition of 'unmanaged' ID ranges to 'Reserved' will be coordinated with vendors who have already used 'unmanaged' range values in their products. Requests for resource values by external SDOs should be via the MOU channel between IEEE and the external SDO. IEEE will review the request and may suggest alternate solutions instead of assigning resource identifiers where appropriate. The timescale for response to a request should cover 2 IEEE meetings (i.e. of the order 2 months). A liaison response to ETSI should be generated to report on progress on discussions of resource allocation management.
doc.: Submission, Slide 18 TG28 Changes ETSI TC ERM change requests 3) IE Descriptor Format SC-M agreed to recommend that the last version number value (0b11) for 15.4-2011 frame types (Beacon, Data, ACK, MAC Command) should be used to indicate that IEs use TLV descriptor format. Version 0b10 frames (current 15.4e values) use LTV descriptor format. Similarly, Version 0b01 Multipurpose frames use TLV descriptor format. Existing 0b00 Version Multipurpose frames use LTV descriptor format. Any future changes to 15.4-2011 frames can be accommodated by the large available extended frame ID space. A final note was also agreed that the one remaining reserved bit in 15.4-2011 frames should be assigned if possible when the new version is defined - otherwise it will not be possible to use the bit as there is no further version number space