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

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



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