TGac Ad-hoc lifecycle model Month Year doc.: IEEE 802.11-yy/xxxxr0 TGac Ad-hoc lifecycle model Date: 2009-11-17 Authors: John Doe, Some Company

Revision history R1: Added straw polls and results during 2009-11-17 am1 TGac meeting.

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?

Lifecycle Establishing requirements Making top-level design decisions Writing draft text Resolving comments

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)

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

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

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

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?

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?

Comparison of the ‘Hard Switch’ and ‘Soft Switch’ Approaches Month Year doc.: IEEE 802.11-yy/xxxxr0 Comparison of the ‘Hard Switch’ and ‘Soft Switch’ Approaches ‘Hard Switch’ ‘Soft Switch’ ‘Requirements Definition’ ‘Systems Design’ ‘Spec Text Development’ System Design Document Spec Framework Document System Design Document Draft Text Draft Text Source: Rolf de Vegt (this and next slide) Slide 11 Page 11 John Doe, Some Company

Alternatives for Major Taskgroup Decision Points Month Year doc.: IEEE 802.11-yy/xxxxr0 Alternatives for Major Taskgroup Decision Points Framework Update System Design Draft Text Coex PHY MAC MU Framework Update System Design Draft Text Hard Switch Letter Ballot Framework Update System Design Draft Text Framework Update System Design Draft Text System Design Draft Text Coex PHY MAC MU System Design Draft Text Soft Switch Letter Ballot System Design Draft Text System Design Draft Text = Taskgroup Approval Decision Point Slide 12 Page 12 John Doe, Some Company

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

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