Neka,
Given the unspecified nature of the network architecture in which a .20
air-interface would plug in and the number of ways by which different users'
traffic can be partitioned at Base Stations/other elements in the network
infrastructure, its not clear if specifically using 802.1Q VLAN tags ought
to be a requirement, particularly a binding one. So I would second Mike'e
suggestion to not have it so.
Regarding software push, software loads etc, since these pertain more
generally to the management/admin of the user terminal and not to the
desired behavior of the MAC/PHY itself, we should not be specifying them in
this requirements document.
Regards,
Samir
-----Original Message-----
From: Michael Youssefmir [mailto:mike@arraycomm.com]
Sent: Friday, August 01, 2003 4:53 PM
To: Neka Hicks
Cc: Stds-80220-Requirements (E-mail); Michael Youssefmir
Subject: Re: stds-80220-requirements: Higher Layer Services, x.x.x
Hi Neka,
I definitely share your sentiments with regard for the need
for an operator to be (optionally) able to run a wholesale network.
Nevertheless, there have been a number of contributions that have
proposed keeping 802.20 "network agnostic". In particular, for example,
http://www.ieee802.org/20/Contribs/C802.20-03-31r1.pdf
argues this point and its advantages in allowing operators to use
existing network infrastructure in support of 802.20 deployments
(including the operation of a wholesale access network).
I therefore propose to not include a specific mandate to support
802.1Q just as it would be inappropriate to mandate the use of
MPLS, PPP, or PPP/MPLS which could be used to satisfy the same
functional requirements.
Regarding code push to the UT, this is a management function
independent of the air interface, and dependent on the
on the operations processes of the ISP or network operator.
Alan Chickinsky made an excellent proposal at the meeting last week.
He said that, for those requirements that are not at the PHY/MAC level,
we need to understand what features the PHY/MAC
must support. It would be helpful if you would recast
your requirement in those terms. In this context, I believe it is
safe to say that the PHY/MAC could accomplish what you suggest through an
appropriate QOS service level for the code data itself.
Finally requirements on the number of code images a UT should support
and how it switches between the two are clearly out of the scope
of the PHY/MAC and should not appear in the requirements document.
For completeness here is your original contribution:
Proposed New text
Additional items:
802.1Q tagging must be supported by the system (such that network egress
traffic can be switched by a L2 device to the appropriate L2 termination
device for managing backbone traffic or distinguishing traffic for wholesale
partners in a wholesale environment).
CPE software upgrade .push. . an operator should have the ability to .push.
a software upgrade to CPE that are currently connected to the network. The
packets that make up the software image should be given a very high priority
and should be coded heavily such that they have a very high chance of
arriving error free at the CPE. The CPE should be capable of holding 2
software loads (the existing one and a new one) such that an operator can
ensure that the .new. software load has arrived safely at the CPE before
deciding to switch from the .old. software load to the .new. software load.
Rationale
It is very important for operators to be able to manage traffic on the
backbone for different customer types (business vs. residential) or to enter
into wholesale arrangements whereby the wholesale partner provides the CPE
to the end user, but the network is owned and maintained by the operator.
In this scenario, the operator needs to have the ability to separate traffic
from CPE belonging to each wholesale partner and direct that traffic to each
wholesale partner independently.
It is very important (particularly during the early deployment stage) that
operators have the ability to .push. out new software loads to CPE quickly
and efficiently to ensure network element software upgrades can efficiently
coincide with user CPE software upgrades
Mike
On Tue, Jul 29, 2003 at 02:20:47PM -0500, Neka Hicks wrote:
> All,
>
> I'm not sure which section will contain a list of these (possibly one of
the
> Appendices), but here is a contribution for that section:
>
> <<clearwire contribution 072803 - higher layer services.doc>>
>
> Neka C. Hicks
> Director of Network Engineering
> Clearwire Technologies
>
> 469-737-7555 (office)
> 817-706-2548 (cell)
>