1. Comments on Standards Development Process
January 2010
Comments on Standards Development Process
Date:
Authors:
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 TAG 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 TAG. If you have questions, contact the IEEE Patent Committee Administrator at
Joe Kwak, Alex Reznik, Eldad Zeira (InterDigital)
Steve Shellhammer, Qualcomm

2. January 2010
Abstract
This contribution highlights several approach to standards development that have been used by IEEE 802
Pros and cons of each approach are discussed
A standards development process for is proposed
Straw Poll of group
Joe Kwak, Alex Reznik, Eldad Zeira (InterDigital)

3. Two Standards Development Approaches
January 2010
Two Standards Development Approaches
Complete proposal approach
WG/TG establishes proposal guidelines and evaluation methodologies
A call for proposal is issued. While partial proposals are generally welcome there is an expectation that at least some complete proposals will be presented
Competing complete proposals are discussed and evaluated by the group. These are modified or merged so as to make them acceptable to an ever-increasing portion of the WG/TG.
(Hopefully) a single proposal results which garners the necessary 75% support
This approach is usually used by and many other groups within 802
Incremental progress approach
Agree on broad strokes and high-level structure of the standard/amendment first
As work on details proceeds and the standard/amendment details are filled in, feature proposals are considered separately provided that these fully comply with the high-level detail previously agreed on
This process has been in used within and m is currently following it. We’ll use the m process to provide a more concrete example of how this proceeds
Joe Kwak, Alex Reznik, Eldad Zeira (InterDigital)

4. 802.11n: example complete proposal process
January 2010
802.11n: example complete proposal process
802.11n developed a set of up-front requirement specs
This led to a call for proposals
Ref: IEEE /1392r0
Usage Models
Channel Models
Functional Requirements
Comparison Criteria
Call for
Complete Proposals
Step 2 Next Slide
Joe Kwak, Alex Reznik, Eldad Zeira (InterDigital)

5. 802.11n: example complete proposal process
January 2010
802.11n: example complete proposal process
Once proposal come in these are evaluated
The process continues until only 1 proposal is “left standing”
This full proposal then requires 75% approval
Joe Kwak, Alex Reznik, Eldad Zeira (InterDigital)

6. 802.16m: example incremental process
January 2010
802.16m: example incremental process
As part of the standards development process, TGm agreed to develop the following document
System Requirements Document (SRD)
A set of possible deployment scenarios and applications of the m standard.
A set of performance targets and features that m compliantsystems shall meet or exceed.
Evaluation Methodology Document (EMD)
A complete set of parameters, models, and methodologies for the link-level and system-level simulations that allow fair evaluation/comparison of various technical proposals.
Channels Models: A set of spatial channel model parameters are specified to characterize particular features of MIMO radio channels to be used for simulating technical proposals for the future m standard.
System Description Document (SDD)
Architecture and design of the m air interface amendment
Captures the core technical concepts behind the features included in the amendment
Will enable analysis and/or simulations for characterizing the coarse level performance benefits of the air interface in association with the Evaluation Methodology Document
These document then lead to the amendment to
See m-09/0019r1 for reference
Joe Kwak, Alex Reznik, Eldad Zeira (InterDigital)

7. 802.16m: example incremental process
January 2010
802.16m: example incremental process
Development of Intermediate Documents (SRD, EMD, SDD)
Performed using a 50% voting process until a complete (or close to complete) version is available
A formal motion (75% approval) was used to adopt each one
Once adopted, a format change, via a 75%-approval CR required to change
Development of the standard amendment
The SDD effectively dictated the “table of content” of amendment
Proposal on various features considered separately
Each requires compliance with SRD/EMD/SDD as appropriate
Each requires 75% approval for acceptance and/or change
If a feature violated SRD/EMD/SDD
A CR for an appropriate SRD/EMD/SDD must be approved first
The feature of interest can be introduced for approach no earlier then 1 meeting after the necessary SRD/EMD/SDD change is approved
See m-08/0043r0 for details
Joe Kwak, Alex Reznik, Eldad Zeira (InterDigital)

8. Comparing the Two Approaches
January 2010
Comparing the Two Approaches
Complete proposal approach
Pros:
Is potentially faster, as good proposals are available early in the process and can be moved on quickly
Cons:
Can result in a stalemate is several good proposals are available without a clear winner
Failure of a proposal returns the group to square 1 – even if all available proposal had agreement in general details
Open to derailment of process by late-comers to the group
Discourages incremental improvements by others
Incremental process approach
Provides a means for a group to agree on the high-level issues up-front
Disagreement and stalemate on a particular feature does not stall the rest of the process
Establish barrier to change high-level agreements late in the standards development process
A priori requires longer time as the up-front documents (e.g m’s SRD/EMD/SDD) have to be discusses before the group gets to the “meat.”
Summary
The incremental process requires a potentially longer initial development time, but reduces the risk of stalled progress.
Joe Kwak, Alex Reznik, Eldad Zeira (InterDigital)

9. Standards Development Process for 802.19.1
January 2010
Standards Development Process for
Our proposal
Take advantage of the benefits offered by the incremental approach
Develop a set of documents which are agreed on up-front and frame the rest of the process
Minimize the impact of the development timeline by minimizing the number and scope of up-front document
Potential documents to develop
System Design Document, which may contain
Set of common terms, definitions and acronyms
Set of features/mechanisms the standards will defined
Architecture definitions
Evaluation Methodology
How well does a technique improve coexistence
Complexity of adding new technique to each 802 MAC/PHY?
Other considerations??
Joe Kwak, Alex Reznik, Eldad Zeira (InterDigital)

10. Straw Poll
Which standard development process do you support for ?
Complete Proposal process
Incremental Proposal process
Not sure
Vote only for one of the above three choices.