RE: stds-80220-requirements: Comment on Functional requirements d document.
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
..................................................................................