RE: stds-802-16: SYSREQ: BRAN-HA Reference Diagram

[Marianna Goldhammer <mariannag@breezecom.co.il>]

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

    Hi All,

   I agree with Chris that the 802.16 Sys. Req. document has to address
many of the points of BRAN-HA Req. document.

   Some comments:
   
   1. The BRAN HA General Reference Model is ATM oriented.
   2. It hides an internal ATM switch, at the Access Point.
   3. It hides a Router, in the Access Point, when using IP backbone as
IP interface.
   4. It hides a Router, inside the User Terminal, if he will be
connected to anything different from ATM.
   5. It hides a complicated queuing system, even BRAN has no intention
to send packets with 1 ATM payload over the air!
      They have to be recombined, per destination, in order to achieve
some normal spectrum efficiency at these speeds!

  The model was copied from the UMTS standards, its implementation will
provide a high cost solution, really targeting only the business market.
If we want to draft standards that will give solutions for SoHo or low
end user also, we have to provide suitable architectures.

 Marianna 

> -----Original Message-----
> From:	Chris Cant [SMTP:telegen@telegen.demon.co.uk]
> Sent:	Wed, April 21, 1999 12:49 PM
> To:	stds-802-16@ieee.org
> Subject:	stds-802-16: SYSREQ: Reference Diagram
> 
> [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