RE: stds-80220-requirements: Max Tolerable Delay Spread, 4.2.3
Marianna, I do not wish to imply that there should not be numbers in the
requirements document. I believe that we have a fine line to walk in
evaluating each of the proposed requirements to make sure that
(a) It is a requirement on the PHY or MAC layer, and not an upper layer
requirement, and
(b) It is a primary requirement for a system which will lead to a successful
standard and successful products, as opposed to a secondary requirement
derived from some primary requirement but directed toward a specific
implementation.
or (c) the requirement is necessary for interoperability.
Note that requirements that really belong to the upper layers may be
translated into requirements for capabilities at the MAC or PHY layers to
support those upper layer capabilities. An example might be a special
address in the frame format that is required by the upper layers to execute
a required feature.
I believe that a list of requirements document that adheres to these
guidelines will have significant quantitative specifications to be used for
evaluating the various choices.
Best regards.
Robert D. Love
rdlove@ieee.org
>From: Marianna Goldhammer <marianna.goldhammer@alvarion.com>
>To: Robert Love <rd_love@hotmail.com>, joanne@arraycomm.com,
>nhicks@Clearwire.com, stds-80220-requirements@ieee.org
>Subject: RE: stds-80220-requirements: Max Tolerable Delay Spread, 4.2.3
>Date: Wed, 30 Jul 2003 18:30:07 +0300
>
>Robert,
>
>Sorry for not agreeing with this:
>
>We eliminate those "requirements" which are really attempts to
>include one solution set and exclude another.
>
>If no numbers are in the requirements, how people like you will
> be able to select a proposal? All of them will be equally good?
>All of them will perform in a equal reliable mode?
>
>In 802.16, to respond to delay spread requirements, FFT
>equalizer has been introduced, even for Single Carrier.
>
>Was this an unnecessary complication? Or was driven
> by market requirements?
>
>Marianna
>
>-----Original Message-----
>From: Robert Love [mailto:rd_love@hotmail.com]
>Sent: Wednesday, July 30, 2003 5:41 PM
>To: joanne@arraycomm.com; nhicks@Clearwire.com;
>stds-80220-requirements@ieee.org
>Subject: RE: stds-80220-requirements: Max Tolerable Delay Spread, 4.2.3
>
>
>
>That was well stated Joanne. We need to be careful in writing requirements
>to focus on those parameters that are vital for MBWA to be successful. Jim
>Mollenauer expressed it well in his presentation when he said that the best
>requirements can be stated simply. By paring down our requirements to only
>those parameters necessary for a successful standard and product set we
>accomplish two purposes.
> 1) We minimize the size of the requirements document, and with that,
>the time it takes to write it.
> 2) We eliminate those "requirements" which are really attempts to
>include one solution set and exclude another. This second set causes
>divisevness in the Working Group, prolongs the process of creating an
>agreed
>
>to requirements document, and is generally counterproductive to progressing
>the standard. Once we agree on the requirements, the various potential
>solutions should each have an opportunity to be heard and evaluated so the
>Working Group can select from amongst all choices that meet the needs of
>the
>
>marketplace.
>
>Neka, I understand that you may have been thinking in terms of real
>requirements when you posted your note, and therefore, they could be
>candidate parameters to include in the requirements document. However, I
>thought that Joanne's point addressed a real issue that deserved more
>focus.
>
> Specifically, her focus on requirements is a great starting place for
>evaluating each of our proposed requirements to see if they really belong
>in
>
>the Requirements document.
>
>Best regards.
>
>Robert D. Love
>rdlove@ieee.org
>
>
> >From: "Joanne Wilson" <joanne@arraycomm.com>
> >To: "Neka Hicks" <nhicks@Clearwire.com>, "Stds-80220-Requirements
> >(E-mail)" <stds-80220-requirements@ieee.org>
> >Subject: RE: stds-80220-requirements: Max Tolerable Delay Spread, 4.2.3
> >Date: Tue, 29 Jul 2003 18:24:02 -0400
> >
> >
> >Neka,
> >
> >You have provided a rationale for your proposal,
> >
> > "The maximum tolerable delay spread should be specified so that
> >it
> >can be
> > determined whether various vendor proposals can meet this
> >criteria."
> >
> >which I don't believe to be a valid reason for establishing such a
> >requirement.
> >Can you provide any other reasoning for this proposal? I would expect
>the
> >rationale to explain why such a requirement would be essential for the
> >802.20 MBWA
> >to achieve it performance objectives.
> >
> >Best regards,
> >
> >Joanne Wilson
> >ArrayComm, Inc.
> >joanne@arraycomm.com
> >
> >
> >
> >-----Original Message-----
> >From: owner-stds-80220-requirements@majordomo.ieee.org
> >[mailto:owner-stds-80220-requirements@majordomo.ieee.org]On Behalf Of
> >Neka Hicks
> >Sent: Tuesday, July 29, 2003 3:19 PM
> >To: Stds-80220-Requirements (E-mail)
> >Subject: stds-80220-requirements: Max Tolerable Delay Spread, 4.2.3
> >
> >
> >All,
> >
> >Here's a contribution regarding max tolerable delay spread:
> >
> > <<clearwire contribution 072803 - max tolerable delay spread.doc>>
> >
> >Neka C. Hicks
> >Director of Network Engineering
> >Clearwire Technologies
> >
> >469-737-7555 (office)
> >817-706-2548 (cell)
> >
> >
>
>_________________________________________________________________
>Tired of spam? Get advanced junk mail protection with MSN 8.
>http://join.msn.com/?page=features/junkmail
>
>
>
>This mail passed through mail.alvarion.com
>
>****************************************************************************
>********
>This footnote confirms that this email message has been scanned by
>PineApp Mail-SeCure for the presence of malicious code, vandals & computer
>viruses.
>****************************************************************************
>********
>This mail was sent via mail.alvarion.com
>
>************************************************************************************
>This footnote confirms that this email message has been scanned by
>PineApp Mail-SeCure for the presence of malicious code, vandals & computer
>viruses.
>************************************************************************************
_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail