RE: stds-80220-requirements: Comment on Functional requirements d document.
Joanne
et al,
Jim
wrote: "I get nervous about
the quality of the spec when I hear 'MAC and PHY are inextricably woven
together' from some participants." I echo that sentiment. Ever
since the ISO 7-layer model was invented, the quality and modularity of
communication software has greatly improved and has facilitated
the modularity and vendor plurality we all enjoy today. It cannot be over
emphasized that the advantages of maintaining the sanctity of the layered
ISO model greatly outweigh the performance gains promised by "tightly
coupling" layers. Thus, I would not be tempted by the March 03
contributions and leave the standard "cleanly layered". I would also
suggest that vendors are free to implement the standard anyway they
wish, including "coupling" the PHY and MAC so as to gain some performance
advantages. Obviously, in such a case, they will not be able to claim FULL
compliance with standard. But, that is a separate
issue.
The
plurality of 802.20 PHYs, sharing a common MAC, should be discussed for its own
merits. I feel we have a compelling reason to require PHY
plurality. How, for example, do the 802.20 TDD and FDD options fit
together in one standard? Reflecting on the UMTS
standard, its FDD and TDD system options have drifted quite apart
from each other, to the extent that they can no longer be considered
one standard.
So, do
we want to cerate a standard with two separate PHY+MACs or two PHYs
sharing one MAC? Clearly, this is the time to resolve this
issue and the 802.20 System Requirements document is the place to define it
in.
Regards,
Dan Gal
Lucent
Technologies O
Mobility Solutions
Wireless Standards Development
email:
dgal@lucent.com
phone: +1
973-428-7734
Dan,
Jim,
Vladimir asked a very important question. He said, "The question
is whether 802.20 is interested in having "PHY plurality"
features already in
requirements. (emphasis added)" The excellent point that he
raised was that the reference model in the
document imposes
a requirement to be able to support
multiple PHYs on a common MAC. Note that while some, but
not
all,
802 standards provide for this, it is actually precedent-setting for
mobile system standards. We had a couple of
contributions
to
the March meeting that described the performance benefits
that can be achieved by tightly coupling MAC/PHY
design.
Regardless of
what 802.20 decides, I would argue that this as a debate on
how the 802.20 requirements will be
implemented
and,
therefore, should be outside of the scope of an 802.20 Functional
Requirements Document.
Best
regards,
Joanne
Joanne Wilson
ArrayComm, Inc.
Tel: (202) 669-4006
Fax: (253)
484-0330
-----Original
Message-----
From: owner-stds-80220-requirements@majordomo.ieee.org
[mailto:owner-stds-80220-requirements@majordomo.ieee.org]On Behalf Of
Jim Tomcik
Sent: Wednesday, July 16, 2003 3:28 PM
To:
Gal, Dan (Dan)
Cc: 'Vladimir Yanover'; Mcginniss, Dave S [GMG];
stds-80220-requirements@ieee.org
Subject: RE:
stds-80220-requirements: Comment on Functional requirements d
document.
At 01:39 PM 7/16/2003 -0400, Gal, Dan (Dan) wrote:
All,
Vladimir is raising a very valid question, a question the entire
802.20 working group should debate.
Dan, I
agree. Let's include a note in the open issues part of the document so
it can be discussed and the diagram modified in accordance with that
discussion in SFO.
As noted by Vladimir, this was taken from
some 802.11 (and 802.15) materials as a starting point familiar to those
working within 802. Of course multiple PHY are allowed within the 802.11
spec. Regardless of the group's decision on the multiple PHY issue, a
model with a clear breakdown in functionality also helps to cleanly specify
tthe air interface. I get nervous about the quality of the spec when I
hear "MAC and PHY are inextricably woven together" from some
participants. For the purposes of clean specification, we should
attempt to separate the functionality (regardless of how it actually gets
built). This will reduce down-stream problems with the
spec.
Jim
Dan Gal
Lucent Technologies O
Mobility Solutions
Wireless Standards Development
email:
dgal@lucent.com
phone: +1
973-428-7734
- -----Original Message-----
- From: Vladimir Yanover [mailto:vladimir.yanover@alvarion.com]
- Sent: Wednesday, July 16, 2003 3:43 AM
- To: 'Jim Tomcik'; Mcginniss, Dave S [GMG]
- Cc: stds-80220-requirements@ieee.org
- Subject: RE: stds-80220-requirements: Comment on Functional
requirements d ocument.
- Hello,
-
- with respect to comments addressing the Reference Model, let me
point that this model,
- apparently copied from 802.11, was intentionally constructed in such
a way to allow
- single MAC-different PHYs combinations. There is a single MAC
and several different PHYs in 802.11:
- DSSS, FHSS, OFDM, IR, ... This is why the 802.11 model contains
Physical Layer Convergence Procedure (PLCP)
- sublayer which depends on the specific PHY. Note also the name
"PMD"
(Physical Medium
Dependent) for sublayer
- which represents different PHY options. The question is whether
802.20 is interested in having "PHY plurality" features
- already in requirements.
-
- Vladimir Yanover
- =========================================
- Dr. Vladimir Yanover
- Alvarion Ltd.
- 21 A Habarzel St. Ramat - Hahayal Tel - Aviv
69710
- P.O. Box 13139, Tel-Aviv 61131, Israel
- Tel.: +972-36457834
- Fax: +972-36456290
- E-Mail: vladimir.yanover@alvarion.com
-
- -----Original Message-----
- From: Jim Tomcik [mailto:jtomcik@qualcomm.com]
- Sent: Wednesday, July 16, 2003 12:17 AM
- To: Mcginniss, Dave S [GMG]
- Cc: stds-80220-requirements@ieee.org
- Subject: Re: stds-80220-requirements: Comment on Functional
requirements document.
- At 01:24 PM 7/15/2003 -0500, Mcginniss, Dave S [GMG] wrote:
- I have had some comments indicating that section 3.1.1
MBWA-Specific Reference Model is to detailed and make the assumption
that the MAC and PHY should be separate allowing different MAC/PHY to
be used in combination. It has been discussed that the layers
would be so tightly coupled that this model is not appropriate. I for
one agree with this assessment and suggest striking this diagram and
reducing
Dave,
For implementation I believe others can couple MAC and PHY as
tightly as desired, however for the purposes of standardizing the
functionality a Reference model such as that shown should be used to
capture the appropriate functionality and describe it in a non-confusing
way. As we proceed towards a standards development, lets not
muddle the layers together - makes the standard that much more difficult
to understand and implement.
Jim
David S. McGinniss
Sprint Broadband Wireless Group
Principal Engineer II
(630) 926-3184
david.s.mcginniss@mail.sprint.com
..................................................................................
James
D. Tomcik
QUALCOMM,
Incorporated
(858)
658-3231 (Voice)
(619)
890-9537 (Cellular)
From:
San Diego, CA
PGP:
5D0F 93A6 E99D 39D8 B024 0A9B 6361 ACE9 202C C780
..................................................................................
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.
************************************************************************************
..................................................................................
James
D. Tomcik
QUALCOMM,
Incorporated
(858)
658-3231 (Voice)
(619)
890-9537 (Cellular)
From:
San Diego, CA
PGP:
5D0F 93A6 E99D 39D8 B024 0A9B 6361 ACE9 202C
C780
..................................................................................