Re: [STDS-802-16] Problems with incremental bandwidth request header?
It will also be very interesting to understand the impact of these
problems on
inter-op / certification.
Regards,
Kaushik
Kalash wrote:
>Hi all,
>
>I come from the DOCSIS side of the world and am still trying to figure
>out the GPSS (grant per SS) in 802.16 vs GPC(grant per connection) in
>DOCSIS.
>
>I do understand the advantages of GPSS but I feel that the lack of
>feedback from BS regarding the bandwidth requests received by it
>and/or being processed by it can cause a lot of interesting scenarios.
>In GPC (DOCSIS), the resolution to most (if not all) these scenarios
>is a clear cut answer - no interpretations.
>
>I have the following questions - would appreciate if someone would
>attempt to answer:
>
>1. If two connections of an SS make a bandwidth request uplink and BS
>sends a grant to the SS, should the request timers of both the
>requests be cancelled?
>
>2. If a connection was waiting for contention resolution process to
>complete when a grant to SS comes in, should it also cancel out
>contention resolution?
>
>3. How would a connection calculate the number of bytes to request in
>an incremental bandwidth request? The grant is to the SS and hence the
>SS has no idea if the grant was made to the connection that actually
>uses it or not. Hence, there is no way that the SS can make an
>estimation of how much incremental request is to be made. Consider the
>following example where incremental request makes perfect sense:
>Last Aggregate request from connection 1: L1 = 1000 bytes
>Connection 1 has another 300 bytes of SDUs arriving, so total pending
>bytes = 1300 bytes
>Grant to SS: G = 500 bytes
>Allocated to connection 1: A1 = 500 bytes
>Pending bytes for connection 1: P1 = 1300 - 500 = 800 bytes
>Now incremntal request would be: I1 = P1 - (L1 - A1) = 800 - (1000 -
>500) = 300 bytes
>
>But consider the following example where it does not:
>Assume 2 connections for the SS with connection 1 higher priority than
>connection 2.
>Last Aggregate request from connection 1: L1 = 100 bytes
>Last Aggregate request from connection 2: L1 = 600 bytes
>Connection 1 has another 800 bytes of SDUs arriving, so total pending
>bytes = 900 bytes
>Grant to SS: G = 500 bytes
>Allocated to connection 1: A1 = 500 bytes
>Pending bytes for connection 1: P1 = 900 - 500 = 400 bytes
>Now incremntal request can be either:
> I1 = P1 - (L1 - A1) = 400 - (100 - 500) = 800 bytes
>or
> I1 = P1 = 400 = 400 bytes
>
>What should be the incremental piggyback request for connection 1?
>Should it be 800 bytes? Or should it be 400 bytes?
>Why is this not clarified in the 802.16 specification?
>
>4. If BS received multiple UGS MPDUs (say 3 MPDUs) with PM bit set,
>should it grant 3 bandwidth request polls or just one?
>
>5. Assume that the BS cannot allocate bandwidth to the bandwidth
>request sent by a SS' connection because link is congested. Must the
>BS drop the request after T16 timer? There is no indication that the
>BS can provide the SS that its request has been received and is being
>processed.
>
>6. SS can start fragmentation on its own while dividing the allocated
>SS grants to its connections even though BS may not have intended to
>start the fragmentation for the connection. This can result in
>unwanted and uncontrolled fragmentation.
>I have been involved in fragmentation reassembly on DOCSIS CMTSes and
>this particular point more than any before is a major concern for the
>BS. BS must have a way to control the fragmentation of the SDUs coming
>in from the SS - if not BS will either have to load up a lot of memory
>for the fragment reassembly or expect to drop the fragments as its
>buffers start filing up.
>
>Is there a working group document that delved into the effects of GPSS
>on request grant state machine scenarios when multiple connections are
>active on an SS?
>
>Thank you
>Kalash
>
>