stds-802-16: SYSREQ: Reference Diagram

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

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

Dear colleagues

One suggestion on SYSREQ, which seemed to gain support at the joint
meeting with ETSI-BRAN in Florida, was that  a good start point on
SYSREQ would be to look at ETSI's HIPERACCESS requirements document -
ETSI Report TR 101 177. I still feel this to be "useful reference" (not
a template to follow exactly) for those drafting SYSREQ document. There
may be some good ideas there!

This Technical Report is available to anyone via the ETSI site:
www.etsi.org, then select "Publications and Products" and "ETSI
Download" and specify "TR 101 177" (taking care to insert the spaces
before each 3-digit field. First time customers will need to fill up a
registration form -all quite painless! (Unless specific agreements have
been reached between IEEE and ETSI, I think it would be a breach of
ETSI's copyright to distribute the document via IEEE 802.16 site - so
each of us must retrieve the report separately.)

In this report you will find (at least) two reference models which are
two different views on the same issue - one illustrating the logical
topology of a system and the other indicating a "thread" through the
system showing the relationships of the protocol stacks.

Both identify the interfaces - and it is my understanding that it is the
interfaces that we should focus out standardisation effort. Not all
interfaces need to be standardised - but all should be recognised.

The reference model from Margarete is a valuable contribution and gives
some impression of both views, but I suggest that it has two small
weaknesses which cannot easily be addressed in a single diagram without
sacrificing some of its elegant clarity:

1. The optional use of repeaters, possibly in cascade, is not
represented. In BRAN HIPERACCESS these were considered an essential
system component to enable good coverage at frequencies which only offer
line of sight propagation. The above mentioned report shows the poor
percentage single hop coverage within the nominal range of a "central
station" path obstruction in a typical (European) city. Repeaters cannot
be ignored in the reference model and then grafted on afterwards without
system implications.

2. Another factor is to identify which interfaces are essentially one-
to-one, which are one-to-many and which are many-to-one. 


On a slightly different point, I am inclined to agree with Marianna's
(BreezeCom) point that the "Interworking Function should also appear on
the CPE side" in ther general model - without wanting to enter the ATM v
IP debate. In some case this will be a "null" function.


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