RE: stds-80220-requirements: 802.20 Reference Model
Mark, Joanne,
Unfortunately, if you do not prepare the CS principles from the
beginning, in any direction you want, after that is not possible
to add it in a layered mode.
802.11 has designed the CS concept from the beginning, so
was possible to "drop" 802.11a in the 802.11 MAC.
The diagram proposed, but not invented by me is newer,
so it is more exact.
Simple like that.
Marianna
-----Original Message-----
From: Klerer Mark [mailto:M.Klerer@flarion.com]
Sent: Thursday, July 31, 2003 10:01 PM
To: 'Joanne Wilson'; Marianna Goldhammer
Cc: stds-80220-requirements@ieee.org
Subject: RE: stds-80220-requirements: 802.20 Reference Model
Marianna,
I would also add that from a layering viewpoint, there is perfect symmetry,
in the sense that just as multiple PHYs can use one MAC, there can be
multiple MACs on top of one PHY. Actually in many cases it is the latter
that is more common, i.e. a common PHY with different MACs to accommodate
different communication needs.
In general convergence sub-layers are written when one knows what one is
trying to "converge", if anything. So I believe the architecture at this
time need not identify this as a design choice as in some sense the CS is
written to accommodate an impedance mismatch between the PHY and MAC design.
We are starting out without such a mismatch. When someone wants to propose a
new MAC to be "slipped" under an existing PHY the CS gets specified and in
some sense it is not really that interesting whether it is a part of the PHY
or a CS.
Mark Klerer
-----Original Message-----
From: Joanne Wilson [mailto:joanne@arraycomm.com]
Sent: Thursday, July 31, 2003 2: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.
************************************************************************************