[STDS-802-16] Problems with incremental bandwidth request header?

[Kalash <kalash.kuhasa@gmail.com>]

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