Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: stds-80220-requirements: Comment on Functional requirements d document.



Dan,
I agree with some of the benefits of a clean layered description but its not clear if a "cut and paste" approach to MAC and PHY specifications has proven itself to be the natural choice. Hopefully, whichever model is eventually chosen will not lead to artificially specifying sub-layer upon sub-layer in the air-interface design just to keep up with the reference model and also not lead to a "layered" organizational structure along PHY and MAC lines.
Samir
-----Original Message-----
From: Gal, Dan (Dan) [mailto:dgal@lucent.com]
Sent: Wednesday, July 16, 2003 5:22 PM
To: 'Joanne Wilson'; Jim Tomcik; 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.

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
 
 
-----Original Message-----
From: Joanne Wilson [mailto:joanne@arraycomm.com]
Sent: Wednesday, July 16, 2003 4:05 PM
To: Jim Tomcik; 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.

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 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
joanne@arraycomm.com

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