Re: stds-802-16: SYSREQ: Iissues for debate and discussion at 5/99 Boulder meeting

[Chris Cant <telegen@telegen.demon.co.uk>]

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

Dear Brian - and all

I regret that I shall not be attending your meeting in Boulder, but I
should like to make (repeat) the following points:

1. I suggest we should be drafting a SYSTEM Requirements document, which
is concerned with the applications, services, external interfaces and
performance of the system - not how it achieves these aspects. It should
only address the highest level of architectures - I would argue that
"Reference Model" is the most prescriptive aspect of a SYSTEM
requirements document - and is mainly there to define the scope of the
system (and of the standard) and to introduce vocabulary - not to say
how systems should be physically designed.

2. Looking at the Outline for System Requirements Document (which I
think came from the Dallas meeting), I am concerned that it is moving
too far towards the "solution" at this stage - and not actually
addressing the "requirements".  I think the PHY layer aspects - such as
modulation have no place in such a document. 

I also think this outline does not give adequate weight to the
telecommunications aspects. (I agree with Steve Farrell on this point.)

3. Although the SYSREQ work is defined as part of the Interoperability
activity, I guess 95% of the requirements will be common to both
Interoperability and Coexistence aspects and it should be written in a
generic way  - with just a few paragraphs on the differences. (I guess
this is your intention - if so, I think it should be stated explicitly.)

4. On a more detailed level, I think your reference model should reflect
the need for repeaters in the SYSREQ document. This could be considered
more "Solution" than "Requirement" - but unless their implications are
recognised at an early stage I believe they will be difficult to "bolt
on" afterwards. (The "Requirement" is to be able to deliver service to
90% (say) of premises within the nominal range of the "hub" - but as the
urban topography and propagation laws are "given",  repeaters seem
inescapable.) I believe they should be optional in any implementation,
but they are essential weapons in the overall armoury. (They are
specifically mentioned as requirements in the ETSI BRAN HIPERACCESS
model to give the coverage required in European towns.)

5. Picking up that last point, I still advocate checking any proposed
"Contents list" of the SYSREQ document against that of the equivalent
ETSI BRAN HIPERACCESS  document to see if any appropriate areas of
requirements have been accidentally omitted. This ETSI document is far
from perfect, but it could be a useful input for your work. ETSI
copyright prevents me distributing this - but it is available to
individuals via the ETSI server. (Paul Khana will have the details.)

6. The TDD v FDD (or both?) issue will be important. I am unsure whether
this is an issue for the SYSTEM requirements document - or whether it is
better addressed as a high level design issue. Certain performance
aspects (such as dynamic flexibility in up- and down-link traffic) are
best delivered by TDD - but fitting into a spectrum management regime
which is FDD orientated (as is the case in many territories outside USA)
presents TDD with a challenge. It comes back to stating the requirements
first. 




Best wishes for a successful meeting

Chris Cant


Brian_Petry@3com.com writes
>
>Hello all,
>
>As editor for our System Requirements document, I am proposing some discussion
>items for the Boulder meetings so that we can reach consensus on some of the
>issues for system requirements.  After reviewing the email discussions and
>looking at the outline proposals for a document, I have come up with the
>following issues.  For these issues, if you have a specific point of view, I
>urge you to participate in Boulder by presenting your views to the group so
>that we can discuss them.
>
>If you like, please contact Roger Marks (r.b.marks@ieee.org) to get a spot on
>the agenda.  I think the Boulder meetings will focus mainly on coexistence
>issues, but it would be great if we could discuss system requirements issues
>as well.
>
>[I am going to name some names in the following paragraphs in hopes that it
>provokes the named people to present their valuable experience and opinions.
>I appologize if I have "pigeon-holed" anyone into a certain camp, but I am
>just trying to provoke discussions.]
>
>ATM vs. IP
>        I saw two, maybe three points of view here.  If I may, let me
>        summarize them:
>
>        1) Must support ATM, perhaps because existing products and system use
>           ATM and telco-ish carriers like ATM
>
>           I saw interesting comments from: Steve Farrell and David
>           Jarrett--maybe you could come prepared with a short presentation on
>           your point of view.  Examples of existing systems that rely on ATM
>           would be particularly useful.
>
>        2) Should focus on IP, perhaps because MAC is more efficient, market
>           reality is migrating to IP, 802.14 experience
>
>           Comments from Chet Shirali, Jack Fijolek, Jim Mollenauer, Marianna
>           Goldhammer were interesting; Imed Frigui (VC from 802.14)
>           summarized 802.14's status
>
>           It would be great if any of you came prepared with your points of
>           view, supporting IP (or variable-length-frame)-centric approach.
>
>        3) Should support both ATM and IP
>
>           Comments from Jay Klein, Jim Mollenauer, David Jarrent and Peter
>           Ecclesine seemed to support an agnostic approach.  Also, an article
>           from Jan/Feb of IEEE Network was mentioned.
>
>ATM vs. IP as it relates to QoS
>
>        I sense a general agreement that we want QoS guarantees for telephony,
>        videophony, and maybe video broadcast services.  If anyone has
>        anything particular to present at the Boulder meeting, I think that
>        would be helpful.
>
>TDD vs FDD
>
>        Although I did not see any discussion on the list regarding TDD vs
>        FDD, and it may be more of a coexistence issue, I think the group
>        would like to see a presentation to make the case for either TDD or
>        FDD.  Are there any "system issues" we should consider?
>
>Reference Diagram
>
>        I saw some good comments regarding the reference diagram.  If
>        Margarete Ralston (who drew up the proposal that was discussed
>        on the list), or anyone else has a new or updated proposal, that would
>        be great.
>
>We have a "functional requirements" proposal from Jim Mollenauer.  I didn't
>see any comments on it.  Does that mean we all agree with the content?
>
>Nit-Picky Things
>
>        We have two proposals for a system requirements outline, one from the
>        task group's work in Austin and another from a group of people
>        submitted by Gene Robinson.  There are some inconsistencies between
>        the two:
>
>        1) The title.  What should it be?  Should the System Requirements
>           task group focus on one document?  I think some people want
>           two documents: a "functional requirements" document and a
>           "system requirements" document.  Could someone (Gene Robinson?)
>           please explain the difference so we can figure out if we need to
>           produce two documents?
>
>        2) I thought we decided in Austin to leave out PHY specifics such as
>           bps/HZ, modulation approaches, etc.
>
>        3) The section "Layer Management" in 802.16sc-99/6 (submitted by
>           Gene) I think defines and describes layer management incorrectly.
>           It should describe network management objects, not generic protocol
>           layering.
>
>        4) 802.16sc-99/6 (from Gene) and 802.16sc-99/1 (from Austin) are
>           outlines that do not "match up" insofar as the various section
>           heading titles, order of sections, added sections and omitted
>           sections.  I think the authors of 802.16sc-99/6 should be prepared
>           to explain why their outline is different from our Austin outline.
>
>Best Regards, and see you in Boulder...
>
>Brian Petry
>
>
>
>

Best regards

Chris Cant

Telegen Limited
14 Brookdale Close, Waterlooville, Hampshire PO7 7NY, United Kingdom
EMAIL:chris@telegen.demon.co.uk TEL: +44 1705 261098 FAX: +44 1705 640678