RE: stds-802-16: SUB11 Comments

[Brian_Petry@3com.com]

Demos,

Thank you for the "Reader Friendly Format."

Though it really is necessary to comply/conform/be-assimilated :>).

Process details can be found at:
http://ieee802.org/16/arc/802-16list/msg00526.html

The reasons for this are:

     -Automates the process.  Since I'm lazy about manual, data-entry-oriented
labor, I wrote an automated script that processes the comment forms so the
comments, and all the fields in the forms, can be easily imported into an
MS-Access database.  Aside from my general laziness, it helps avoid human error
(mine) if I were to attempt to process your coments "manually."

     -Ensures accuracy, completeness and fairness.  The form "forces" commentors
to provide all the information we need to deal with each and every comment.
With the form, it's easy to verify that commentors fill-out all the fields for
each comment.  This way, the task group can easily understand and resolve each
comment at the next meeting.  And since each comment is "created equal," (except
maybe for late comments or comments that did not comply to the instructions)
they can be resolved in a fair and equitable manner.

What I do is take everyone's comment forms that come via email and run them
through scripts that verify the fields are complete, and translate the format
into an even-less-human-readable-form that can be directly imported into
MS-Access.  Then I generate a report (database-style) of all the comments,
sorted by page #/line#.  From this, I edit each comment into the current draft
(with change bars, etc.) thus forming a new draft that is pending resolution by
the committee.  Prior to the meeting, I mail out the report, and the new draft
(as standard pdf contributions).  Then at the next meeting, I project the
database on the big screen, and we go through all of the comments, resolving
them one by one (sometimes accepting "editorial" comments in a batch).  This
process actually works pretty well---we used it  for 802.16.1 functional
requirements.

So, please bear with us.  If you have comments on how to improve the process,
let us know.  One thing we have thought about before is on-line comment
submittal (e.g., a web page).  But that generates a whole bunch of new problems.

Even so, your "reader friendly format" still helps greatly, because other
commentors can more easily see and understand your comments before they submit
their own.

-Brian






"Kostas, Demos" <dkostas@adaptivebroadband.com> on 04/21/2000 07:49:09 PM

Sent by:  "Kostas, Demos" <dkostas@adaptivebroadband.com>


To:   Brian Petry/PA/3Com, stds-802-16@ieee.org
cc:
Subject:  RE: stds-802-16: SUB11 Comments






Attached find my comments on the Subject.  The Attached Comments are in a
"Reader Friendly Format". After I did my comments in this format I
discovered that the editor requires different format, which I personally
find very difficult to review and very tedious to comment using the editor's
Proposed Format. Nevertheless I will not be discouraged and will attempt to
put my comments within the constrains of the Editor and resend to you next
week.
Regards
Demos
PREFACE:

What follows are a "fist-cut" proposed changes to the Proposed 802.16.3
Functional Requirements Document to make it reflect the needs of the
wide-range of applications that the 802.16.3 Standard-based P-MP BWAS will
be called to support.


1.  Introduction
-First Paragraph Second Sentence should read:

The BWA system is intended to support a wide-range of transport capabilities
(e.g., frame relay, ATM, IP, and Ethernet 802.11) that in turn can support a
wide-range of services (e.g., telephone, data, and video)

- First Paragraph third sentence is redundant with second Paragraph.
Suggest deleting this sentence.

-Third Paragraph Second Sentence is not consistent with the Second
Paragraph.  Second Paragraph states that this document provides "guidelines"
and the third Paragraph states that "The requirements with future
amendments, are binding"... the air interface standard MUST comply... with
the functional requirements".   Suggest replacing alternative words as
follows:

"These functional requirements, with possible future amendments, are to be
used to identify the constrains in the development of the 802.16.3 air
interface standard.  Such terms as SHALL, MUST and SHOULD as used herein are
to indicate the relative importance of a requirement"

1.1 Scope:
Second Sentence should read:

So, "Functional Requirements" describes the 802.16.3 MAC and PHY Layer
functions and system parameters that need be specified so that the BWA
system can support a wide-range of transport capabilities (e.g., frame
relay, ATM, and Ethernet 802.11), that in turn can support a wide-range of
services (e.g., telephone, data, and video)


-4th Paragraph, First Sentence
In the context of functional requirements what is meant that "The 802.16.3
air interface interoperability SHALL "be part of a family of standards" for
local, metropolitan, and wide area networks" ?
Does it mean "The 802.16.3 air interface interoperability SHALL readily
interwork with existing local, metropolitan, and wide area network
standards?  If so than this wording change is suggested

-4th Paragraph, Second Sentence should read
As an example, Figure 1 shows how the 802.16.3 PHY and MAC layers relate to
some other 802 standards.

In the Figure 1 replace 802.16 with 802.16.3



Add Figure 0.  That depicts the how the 802.16.3 MAC and PHY Layers relate
to the supported upper layer protocols (e.g., Frame Relay, ATM, 802.11);
i.e., 802.16.3 Protocol Reference Model


-Change title of Figure 1 to
Figure 1: Relationship between 802.16.3 and other 802 Protocol Standards(...


Section 2.0
Change the word "degenerative version" to "limit case"

Section 2.1
First Paragraph, ending of second sentence should read, and continue as
"... envisaged, but the 802.16.3 protocols focus on the Air Interface shown
in the simplified model of Figure 2.2.  Also shown in Figure 2.2 are typical
configurations of the Base Station (BS) and the Subscriber Station (SS),
that include the functions of "Indoor Units"(IU) and "Outdoor Units" (OU).
However, the physical separation and protocols between OU and IU are beyond
the scope of this document.

An additional function to this System Reference Model that should be
considered is Security.  The BS Network Interface (BNI) and the SS Network
Interface (SNI) are also shown.

A single SNI may... are abstract functional entities.  The details of these
functional entities which are sometimes called Inter-Working Functions
(IWFs) are beyond..."

Section 2.2 First Paragraph, Second Sentence
The SS may identify the bandwidth needed to achieve the required QoS (see
section) , but the BS has the "smarts" to
allocate bandwidth.

Section 2.2 Second Paragraph should read,

In the downstream..., and more than one SS can share a downstream channel.
In the upstream direction the topology is similar...to a contention-oriented
bus, and thus 802.16.3 protocols MUST provide the means to multiplex traffic
from multiple SS, resolve contention, and allocate bandwidth in the upstream
direction.

3 Supported Services

This section describes some services that an 802.16.3 system SHOULD support.
In what follows both the target markets and their associated bearer services
are described.

3.1 Services

"This Section describes typical services supported by an 802.16.3 system.
In this document services refer to the services provided by the MAC layer to
the layer above it.  The term services is also used in this document as an
adjective to qualify the type of networks that interface with 802.16.3-based
BWA networks(12)(54).

The MAC and PHY... in a generic fashion."
Delete the second sentence of this paragraph

3.1.1 Voice Services:  first paragraph, second sentence,

Delete the words
 "and voice services will be recovered from the packets"

Editorial question; what is the definition of a "consumer service level"?

Section 3.1.1.1, first bullet, delete the second sentence or reword it to

"Voice connectivity will be provided by packet(e.g., VoIP) or cell(e.g.,
VoATM)protocol and may involve low rate encoding(e.g., vocoding)"

Delete the parenthetical statement
(e.g., residential vs. business)
as in this context the items have ambivalent meaning.

Section 3.1.1.1, -second bullet, should be modified to read,

Delay - as apparent to the end user, the amount of delay and delay variation
MUST be kept within acceptable limits.  Again the specific amount of delay
and delay variation acceptable is based on the QoS sold to the end user.

BWA protocols ...

Section 3.1.1.1.1 Internet Protocol Service

The 802.16.3 system MUST transport variable length IP datagrams efficiently.
...


ADD
Section 3.1.1.1.1.1 ATM Protocol Services

The 802.16.3 system MUST transport constant bit rate(CBR), non-real-time
variable-bit-rate(non-rt VBR), real-time variable-bit-rate(rt VBR) and ABR
ATM services.

3.1.3 Other Services; Delete Second Sentence


4 802.16.3 Protocols

Delete the first and fourth sentence of the first paragraph.
Delete Paragraphs 2,3,4,5, and add a new Paragraph #2 as

"For the different ATM Services their Convergence Layers reside above MAC
Sublayer.  See Figure 4.1."

Delete Paragraph 8

Modify Figure 4.1 to include the ATM and ATM Convergence Layers above the
MAC Layer.

Paragraph 10 next to last sentence should read,

"Note that the function of the MAC layer can include error correction by
retransmission, or Automatic Repeat Request(ARQ)."

and the last sentence of this paragraph is deleted.

5 Performance; First Paragraph, second sentence should read,

Specifying protocols that can maintain a specified/mandatory performance
levels in the face of rapidly changing channel characteristics(e.g., due to
multipath) is a problem that the 802.16.3 work group has to consider.

5.1 Scalability

The 802.16.3 protocols SHOULD allow  for increases in capacity and
performance.

6.2 Parameters
The 802.16.3 protocols SHALL define a set of parameters to meet the required
QoS parameters for the supported services (e.g., ATM CBR Services and IP)

6.3 Service QoS Mappings; The last sentence parenthesis should read
( such as those required for IP- and ATM-based services)

Appendix: Table 2: Mandatory Requirements: Should be adjusted to be
consistent with the agreed text that precedes the Appendix

Dr. Demosthenes J. Kostas
Director, Industry Standards
Adaptive Broadband Corporation

3314 Dartmouth Ave
Dallas, TX 75205  USA

tel: 214 520 8411
fax: 214 520 9802


-----Original Message-----
From: Brian_Petry@3com.com [mailto:Brian_Petry@3com.com]
Sent: Thursday, April 20, 2000 10:26 AM
To: stds-802-16@ieee.org
Subject: stds-802-16: SUB11: Reminder: comment deadline is one week from
today





http://ieee802.org/16/arc/802-16list/msg00526.html