stds-802-16: System requirements

[Jim Mollenauer <jmollenauer@TSAnet.com>]

[Notice: It is the policy of 802.16 to treat messages posted here as non-confidential.]

It seems to me that there are two types of issues that we are grappling
with.

The first is one of packaging: how do we bundle up different types of
traffic, particularly STM, ATM, and packets, and send them over the air
interface so that they can be reconstituted at the other end.  This is
not too hard; we just need to minimize the overhead.

The second issue is one of quality of service.  This is harder, at least
in a point-to-multipoint system.  We must be able to provide adequate
service quality in the face of varying demands from the aggregate set of
users.  This issue is largely orthogonal to the packaging issue.  ATM
now involves a multiplicity of QoS requirements, and IP will too, once
DiffServ becomes prevalent.

The 802.14 working group set out to deal with a similar set of issues,
and failed to do the job.  There was much discussion of how to handle
STM, and little motion toward an agreement, so it was dropped in the
interest of progress.  Originally it was expected that the non-STM
traffic would all go over ATM, but the rise of IP made it desirable to
add a variable-length packet type as well.  This was dropped late in the
game as a way of providing differentiation vs. DOCSIS, and QoS issues
were essentially handed back to the ATM layer.  The real lesson learned
from the displacement of 802.14 by DOCSIS is that standards have a
market window that must be met.

Jim Mollenaer