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
..................................................................................