RE: stds-80220-requirements: 802.20 Reference Model
Hi again,
I agree with all the Dan points.
I proposed the alternative diagram, based on my best technical
knowledge. For reasons, go back to my first e-mail.
I would suggest Joanne and Mark to ckeck if their existing
systems comply with the second diagram. I have strong doubts.
Marianna
-----Original Message-----
From: Gal, Dan (Dan) [mailto:dgal@lucent.com]
Sent: Friday, August 01, 2003 12:14 AM
To: Marianna Goldhammer; Joanne Wilson; Klerer Mark (E-mail)
Cc: stds-80220-requirements@ieee.org
Subject: RE: stds-80220-requirements: 802.20 Reference Model
Marianna, Joanne, Mark and all,
I propose to defer the definition of the reference model to the next stage
of the 802.20 project - the actual PHY and MAC specification. I feel that
there is no compelling reason to define the reference model in the System
Requirement document. One starts working on the solution only when the
problem definition is complete, and, clearly, we are still in the
problem-definition stage. Thus, I would suggest that for now, it should be
sufficient to get consensus on the following fundamental specification
design principles:
1. The MAC sub-layer and the PHY layer shall be "isolated" from each other
by way of functional abstraction and well defined interfaces.
2. The Data Link Layer (DLL) shall hide the underlying PHY characteristics
from the upper (ISO)layers.
3. The MAC specification shall support multiple PHY types and provide for
their interoperability.
I am quite confident that when we get past the technology-proposals
evaluation and selection phase, the task of defining the reference model
will be much easier and more "grounded" to the requirements of the chosen
radio technology(-ies) and supported services and applications.
Dan
-----Original Message-----
From: Marianna Goldhammer [mailto:marianna.goldhammer@alvarion.com]
Sent: Thursday, July 31, 2003 3:25 PM
To: Joanne Wilson
Cc: stds-80220-requirements@ieee.org
Subject: RE: stds-80220-requirements: 802.20 Reference Model
Johanne, Mark,
I do not understand what's the problem, if:
"The group decided that by having well-defined interfaces,
one could in the future propose a different
PHY to work with a previously adopted MAC."
CS is the "well-defined" interface.
Besides, if you do not feel comfortable with this diagram,
feel free to use any diagram you want.
I will stop now, is time to go home,
Marianna
-----Original Message-----
From: Joanne Wilson [mailto:joanne@arraycomm.com]
Sent: Thursday, July 31, 2003 10:12 PM
To: Marianna Goldhammer
Cc: stds-80220-requirements@ieee.org
Subject: RE: stds-80220-requirements: 802.20 Reference Model
Dear Marianna,
I have to say I disagree with the logic of your argument.
Including the CS PHY sub-layer explicitly in the diagram means that
the we are requiring the MAC to be support multiple PHYs. That's
not what the group decided. The group decided that by having
well-defined interfaces, one could in the future propose a different
PHY to work with a previously adopted MAC. The key issue of importance
was the overall AI performance, which allowed for the proposals to
optimize the MAC for its PHY. This can be done while maintaining the
requirement to have a well-defined interface between the two. For
those reasons, I believe that including the CS PHY sub-layer in the
diagram is not consistent with the consensus we reached previously.
Thanks much.
Best regards,
Joanne
-----Original Message-----
From: Marianna Goldhammer [mailto:marianna.goldhammer@alvarion.com]
Sent: Thursday, July 31, 2003 2:44 PM
To: Joanne Wilson
Cc: stds-80220-requirements@ieee.org
Subject: RE: stds-80220-requirements: 802.20 Reference Model
Dear Joanne,
The CS PHY is exactly what you are looking for;
allows the support of different PHY layers; at the contrary,
not specifying a CS is the same with
having only one MAC-PHY combination, which does not need
this interface.
If you look at the CS explannation for interface with the higher
layers, is written:
"Multiple CS specifications are provided for interfacing with
various protocols".
Hope this helps,
Marianna
-----Original Message-----
From: Joanne Wilson [mailto:joanne@arraycomm.com]
Sent: Thursday, July 31, 2003 9:30 PM
To: Marianna Goldhammer
Cc: stds-80220-requirements@ieee.org
Subject: RE: stds-80220-requirements: 802.20 Reference Model
Marianna,
Thanks for that explanation. I'm copying this to the reflector as it
relevant to our discussion about the reference architecture model. It's
unfortunate that you were not able to be on the Requirements CG call on
Friday, July 18 prior to our meeting. We had a lengthy discussion about
whether there should be a requirement to support multiple PHYs or not.
It was agreed that there was a need for well-defined interfaces between the
MAC and PHY and, at the same time, that the MAC and PHY can be jointly
optimized (i.e. aspects of the MAC can be optimized for its associated PHY)
in order to optimize the overall performance of the air interface. The
prospect
of having a single MAC supporting more than one PHY was neither ruled out
nor made
a requirement. As such, I believe that the "CS PHY" sub-layer implies a
decision
that is beyond what was agreed to by the Requirements CG and should not be
included
in the reference architecture. Leaving that out of the diagram does not
mean that
the 802.20 cannot provide a single MAC supporting multiple PHYs, only that
it is
not required to do so.
Best regards,
Joanne
-----Original Message-----
From: Marianna Goldhammer [mailto:marianna.goldhammer@alvarion.com]
Sent: Thursday, July 31, 2003 4:11 AM
To: Joanne Wilson
Subject: RE: stds-80220-requirements: 802.20 Reference Model
Joanne,
The interface between MAC and PHY is to support multiple PHYs.
Marianna
-----Original Message-----
From: Joanne Wilson [mailto:joanne@arraycomm.com]
Sent: Wednesday, July 30, 2003 10:51 PM
To: Jim Tomcik; Marianna Goldhammer
Cc: Stds-80220-Requirements (E-mail)
Subject: RE: stds-80220-requirements: 802.20 Reference Model
Jim,
I believe that the two diagrams in our proposal should be taken together,
and therefore the management interfaces is included in the second diagram.
The diagrams were intended to be complementary to each other. Maybe we need
to add some text to the document to explain how the two diagrams should be
interpreted. I can work on some text and propose it to the group if folks
agree that this would help make the section clearer. If it is necessary to
add management interfaces to the first of the two diagrams, I would propose
to do so without too much detail.
Regarding the diagram that Marianna proposes, I don't believe that the "CS
PHY" (meaning Convergence Sublayer PHY) that lies between the MAC and PHY
represents greater clarity about the interface between the MAC and PHY.
Instead, it
appears to impose the same sublayer structure as the alternative diagram
that we
opposed earlier for that same reason. I, too, don't see what the sublayers
buy us,
particularly when the actual functional requirement appears elsewhere in the
document.
Best regards,
Joanne
-----Original Message-----
From: Jim Tomcik [mailto:jtomcik@qualcomm.com]
Sent: Tuesday, July 29, 2003 8:37 PM
To: Joanne Wilson; Marianna Goldhammer
Cc: Stds-80220-Requirements (E-mail)
Subject: RE: stds-80220-requirements: 802.20 Reference Model
Joanne, and Marianna, (and others, of course...),
Generally I think the draft posted by Joanne and Mark goes in the right
direction, but Marianna's diagram points out a couple items that we should
think about adding to it.
(1) Joanne and Mark's (Fig 1) does not include the management interface and
so is inconsistent with the very high level 802 model shown below it. We
should add this to be consistent with the 802 approach shown, and to
indicate that proposals should be planned and described in such a way that
equipment can be managed via this standard approach.
(2) Marianna's Figure 1 clearly shows an interface between Physical Layer
and Mac (noted as CS PHY). This should also be included in our reference
diagram to clearly delineate PHY and MAC. (I miss the subtelty of CS vs
SAP in these diagrams, however the idea of a clean interface does come
through.)
Its not clear to me what the sublayers buy us at this point. We do have a
section on security in the text, and this can (and should) be used to state
that the technology proposals must have a security feature that includes
Authentication, Key Management, and Encryption. What do we miss by
omitting the Common Part Sublayer and the Service Specific Convergence
Sublayer?
Regards,
Jim Tomcik
At 05:19 PM 7/29/2003 -0400, Joanne Wilson wrote:
>Mariana,
>
>Unfortunately, you were not able to participate in the Requirements
>conference call that occurred on Friday, July 19th prior to last week's
>802.20 meeting. The concensus on the call was in favor of the more
>general MBWA System Reference Architecture. While the eventual standard
>may contain various sub-layers, there appears to be no benefit to
>constraining
>a priori future proposals to a specific sub-layering. The main objective
>of the section, in my humble opinion, was to express a requirement for the
>802.20 AI to be specified in a well-defined layered MAC/PHY architecture
>consistent with the OSI/ISO model and with other 802 systems. To express
>the agreement on the conference call, Mark Klerer and I were assigned
>to redraft this section. We did this on the margins of last week's meeting
>and it was sent to the 802.20 requirements CG last Thursday. I have
>attached
>that proposal again, which I continue to support.
>
>Best regards,
>
>Joanne
>
>-----Original Message-----
>From: owner-stds-80220-requirements@majordomo.ieee.org
>[mailto:owner-stds-80220-requirements@majordomo.ieee.org]On Behalf Of
>Marianna Goldhammer
>Sent: Tuesday, July 29, 2003 2:05 PM
>To: Stds-80220-Requirements (E-mail)
>Subject: stds-80220-requirements: 802.20 Reference Model
>
>
>
>Hi,
>
>I propose to adopt the MBWA-Specific Reference Model and its
> explanation from the attachment, that will replace 5.1.1.
>
>Reasons for that are:
>
>- 802.1 bridging, in Fig. 2, is actually beyond the standard;
> including it in the standard scope will make the radio behave
> as a Ethernet bridge and will have implications in frame
> headers (look at 802.11 MAC, carrying if I remember well,
> up to four Ethernet addresses in the frame header);
>
>- 802.1 Management, in Fig. 2 is actually insufficient for access
> systems, being suitable only for LAN and WLAN systems;
>
>- Security functions are not shown;
>
>- Management functions and their interaction with
> MAC/PHY/Security is not shown;
>
>- PHY interaction with the radio deployment is not shown.
>
>Marianna
>
> <<Reference Model.doc>>
>
> Marianna Goldhammer
> Director - Strategic Technologies
>
> Alvarion, Ltd.
>10 years of wireless expertise
>
> 21 HaBarzel Street
> P.O.Box 13139, Tel Aviv 61131, Israel
> Tel: (972)- 3 -6456241/6262
> Fax: (972) -3 -6456204
>
> Email: marianna.goldhammer@alvarion.com
>
> www.alvarion.com
>
> The information contained in this electronic mail message is
privileged
>and confidential, and is intended only for use of the addressee. If you
are
>not the intended recipient, you are hereby notified that any disclosure,
>reproduction, distribution or other use of this communication is strictly
>prohibited. If you have received this communication in error, please
notify
>the sender by reply transmission and delete the message without copying or
>disclosing it.
>
>
>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
............................................................................
......
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.
****************************************************************************
********
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.
****************************************************************************
********
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.
****************************************************************************
********
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.
************************************************************************************