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.

All,
There has been a strong support among the WG members dating back to the SG phase for tightly coupled PHY and MAC since such thing would help optimize the air interface in order to achieve "significantly better" performance than existing systems, specially in the context of TDD and FDD. I believe this was Dave M.'s intent in suggesting the removal of Figure 1 and I support it.
 
Tightly coupled PHY and MAC, of course, argues against the idea of unified MAC for multiple PHYs. Replacing Figure 1 with the two new figures Mike Y. suggested in a previous email, however, would defeat the purpose and would contradict the intention since the same unified MAC approach is being suggested in those graphs as well, as noticed by Vladimir.
 
As for Jim's comment about the diagram helping the implementation , the specifications will have separate PHY and MAC sections so there will be no confusion in the implementation. I don't think Figure 1 would be of any additional help.
 
Reza 
-----Original Message-----
From: owner-stds-80220-requirements@majordomo.ieee.org [mailto:owner-stds-80220-requirements@majordomo.ieee.org]On Behalf Of Gal, Dan (Dan)
Sent: Wednesday, July 16, 2003 1:39 PM
To: 'Vladimir Yanover'; 'Jim Tomcik'; Mcginniss, Dave S [GMG]
Cc: stds-80220-requirements@ieee.org
Subject: RE: stds-80220-requirements: Comment on Functional requirements d document.

All,
 
Vladimir is raising a very valid question, a question the entire 802.20 working group should debate.  
 
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.
************************************************************************************