doc.:IEEE 802.11-09/1181r2
November 2009
TGac Ad-hoc lifecycle model
Date: 2009-11-19
Authors:
Name
Company
Adrian Stephens
Intel
Submission
Address
Phone
email
Adrian.P.Stephens@intel.
com
Slide 1
Adrian Stephens, Intel Corporation
November 2009
doc.:IEEE 802.11-09/1181r2
Revision history
• R1: Added straw polls and results during 2009-11-17
am1 TGac meeting.
• R2: Added discussion and straw poll related to
generation of draft text.
Submission
Adrian Stephens, Intel Corporation
doc.:IEEE 802.11-09/1181r2
November 2009
Introduction
• TGac Ad-hocs are starting up activity this week
• There needs to be a clear expectation of the phases of activity (the
“lifecycle”) performed by an ad-hoc
• Earlier work (11-09/0237) addressed the contents of the
framework document. It did not address how high-level design
decisions should be recorded. This submission highlights the need
to record these design decisions before drafting text.
• Also there are two questions that need to be discussed and
addressed now:
– Are transitions between phases of activity formalized (e.g. formal sign-off
that requirements are complete)?
– Do we record high-level design decisions in the Framework document, or
some other document?
Submission
Adrian Stephens, Intel Corporation
doc.:IEEE 802.11-09/1181r2
November 2009
Lifecycle
1.
2.
3.
4.
Establishing requirements
Making top-level design decisions
Writing draft text
Resolving comments
Submission
Adrian Stephens, Intel Corporation
doc.:IEEE 802.11-09/1181r2
November 2009
Establishing requirements
• Purpose of this phase is to determine the features that
the ad-hoc is supporting
• During this phase we expect to see justification of
features
– i.e. performance simulations/results, complexity estimates
• Output is the Framework document, e.g.
– “Preamble shall support colored training symbols” **
** The example is fictitious :0)
Submission
Adrian Stephens, Intel Corporation
November 2009
doc.:IEEE 802.11-09/1181r2
Making top-level design decisions
• During this lifecycle phase, the ad-hoc considers alternative
proposals that show how to meet its requirements (which have
been documented in the framework doc).
• Eventually the group decides on mechanisms/methods/structures
that meet its requirements.
• The output is in a TBD document (could be Framework document,
or new system design document), containing high-level design
– e.g. “The preamble supports colored training symbols through the
following structure: following the single spatial stream VHT SIG field
there will be n VHT-LTFs, where n is the total number of spatial streams.
the colors of the LTFs will be selected in order from: red, green, blue, red,
green, blue … ” **
* This is still a fictitious example
Submission
Adrian Stephens, Intel Corporation
November 2009
doc.:IEEE 802.11-09/1181r2
Writing draft text
• During this phase, the ad-hoc writes text for
incorporation into the draft amendment.
• Only “low level design” decisions are made at this stage
– All feature decisions and top-level design decisions have been
made in previous phases of the lifecycle
• Phase is complete when the draft is approved for ballot
Submission
Adrian Stephens, Intel Corporation
November 2009
doc.:IEEE 802.11-09/1181r2
Resolving comments
• Comments will be received during letter ballot
• The ad-hoc will be asked to provide resolutions for
comments “in scope” of its charter, to be approved by
TGac
• This phase completes when the IEEE Standards Board
have approved the amendment
Submission
Adrian Stephens, Intel Corporation
November 2009
doc.:IEEE 802.11-09/1181r2
Moving between phases of the lifecycle
• Do we have a hard switch?
– i.e. Once an ad-hoc has started making top-level design decisions, is it
allowed to go back and change its requirements?
– Switch into comment resolution is necessarily “hard” because it is
dependent on entry to letter ballot
• If we have a hard switch, we need to formalize two transitions:
– From requirements to top-level design
– From top-level design to drafting text
• If have a “soft” switch, an ad-hoc can move between phases as it
needs
– e.g., to reflect learnings from design back into requirements
• Which is going to be the most effective way to operate?
Submission
Adrian Stephens, Intel Corporation
November 2009
doc.:IEEE 802.11-09/1181r2
Recording the top-level design
• We need a place to record top-level design decisions
• We have only two documents so far:
– Framework
– Draft Amendment
• Do we need a third document “System design spec”, or
can we use the framework document to capture this
output?
Submission
Adrian Stephens, Intel Corporation
doc.:IEEE 802.11-09/1181r2
November 2009
Comparison of the ‘Hard Switch’ and ‘Soft
Switch’ Approaches
‘Requirements
Definition’
‘Systems Design’
‘Spec Text
Development’
‘Hard Switch’
‘Soft Switch’
Spec Framework
Document
System Design
Document
System Design
Document
Draft Text
Draft Text
Source: Rolf de Vegt (this and next slide)
Submission
Slide 11
Adrian Stephens, Intel Corporation
doc.:IEEE 802.11-09/1181r2
November 2009
Hard Switch
Coex
Framework
Update
System Design
Draft Text
PHY
Framework
Update
System Design
Draft Text
MAC
Framework
Update
System Design
Draft Text
MU
Framework
Update
System Design
Draft Text
Soft Switch
Alternatives for Major Taskgroup Decision Points
Coex
Letter Ballot
PHY
System Design
Draft Text
System Design
Draft Text
System Design
Draft Text
System Design
Draft Text
Letter Ballot
MAC
MU
= Taskgroup Approval Decision Point
Submission
Slide 12
Adrian Stephens, Intel Corporation
doc.:IEEE 802.11-09/1181r2
November 2009
Straw poll 1
• Should we have a separate system design document, or should we
use the framework document to hold the system design?
• Separate 6
• Framework 24
• Don’t know yet 34
Submission
Adrian Stephens, Intel Corporation
doc.:IEEE 802.11-09/1181r2
November 2009
Straw poll 2
• Should we use a formal switch (i.e. by motion in task
group to switch between requirements and system
design) between requirements and design phases, or
should we allow iteration between them?
• Formal switch 0
• Allow iteration 36
• Don’t know 16
Submission
Adrian Stephens, Intel Corporation
November 2009
doc.:IEEE 802.11-09/1181r2
When can we generate draft text?
• It is clear that changes to the framework document, or
changes to the draft text require 75% TGac approval.
• It is not clear (i.e., we haven’t discussed this in TGac
yet) whether TGac approval is needed to switch
between “requirements/system-design” and “drafting”
phases in the ad-hoc.
Submission
Adrian Stephens, Intel Corporation
doc.:IEEE 802.11-09/1181r2
November 2009
Straw Poll
• Does an ad-hoc need TGac permission before starting
to consider/generate draft text?
• Yes – needs TGac permission - 2
• No – can generate draft text whenever it likes - 32
• Don’t know- 27
Submission
Adrian Stephens, Intel Corporation
doc.:IEEE 802.11-09/1181r2
November 2009
Straw Poll 2
• If permission is required for an ad-hoc to start
generating draft text, is this permission granted
independently, or coordinated across all ad-hocs?
• Independent decision points for each ad-hoc
• A single decision point across all ad-hocs.
• Don’t know
Submission
Adrian Stephens, Intel Corporation