90 likes | 103 Vues
This document provides an introduction to the proposed specification framework for TGac, including the evolution and scope of the framework. It does not address the formal rules of modification, which should be covered in the Selection Procedure document.
E N D
Proposed Specification Framework for TGac – Introductory Comments Date: 2009-09-22 Authors:
Introduction • This document describes some of the thinking behind the proposed specification framework document 11-09/0992r0. • What is the specification framework? • How does the specification framework evolve? • This document does not address the formal rules by which the specification framework document is modified • These should be addressed in the Selection Procedure (last revision: 11-09/0059r4)
What is the Specification Framework? • Provides the framework from which the draft amendment will be developed • It is a working document that will start out small, evolve, and grow with group consensus • At some point, the document will include enough detail on features and architecture that the document can be frozen and work begin on the draft amendment itself • The scope of the work on the draft amendment should be constrained to the features in the spec framework • A discussion of what features TGac supports occurs in the context of the specification framework document • All features should be present in the spec framework before work begins on the amendment
Evolving the Spec Framework (1) • The document begins with a small, core set of feature • i.e., the requirements with broad consensus • The document then evolves in two ways: • New features that have broad support are added • Detail is added
Evolving the Spec Framework (2) • Adding features: • The spec framework begins as a slim document • Features should be thoroughly vetted before addition to the spec framework • Features with a major impact on the system design should be investigated in detail in the ad-hocs • To gain an idea of complexity of the feature • To gain a good understanding of the performance benefit • Ultimately all features need to show a reasonable cost/benefit tradeoff
Evolving the Spec Framework (3) • Adding detail: • Feature requirements acquire more detail with time • This occurs as specific techniques are discussed and technology options explored • Some features are fundamental with other features dependent on the details • For example, information present in the preamble signaling field may need to be specified in detail since it impacts MAC protocol design (e.g. aggregation bit impacts use or normal ack and block ack) • Thus some parts of the spec framework may require significant detail while other parts do not
Straw Poll questions • We would like to ask two questions to clarify whether TGac members agree with the process introduced by this document. • Question 1 can be asked after a presentation of the framework document 11-09/0992r0 • Question 2 can be asked after all related presentations on this topic
Question 1 • Do you approve in principle of an initial starting point for the framework that contains only core features? • Yes • No
Question 2 • Background on Ad-hocs: • The topics that Adhocs investigate will include: the "fleshing out" of existing topics in the framework document as well as OBSS Management, Multichannel approaches and UL MU-MIMO. • Grouping of Ad Hocs may be: • COEX (includes OBSS and Multichannel) • PHY • MAC • MU-MIMO (includes DL/UL MIMO) • Do you approve 11-09/0992r0 as the starting point for a TGac framework together with creation of adhocs as described above? • Yes • No