Re: [STDS-802-16] Bandwidth related questions
Hi Kalash,
please find my clarifications/thoughts embedded in
1,2,4,5,6,7 points.
Thanks
-Giridhar.
--- Kalash <kalash.kuhasa@gmail.com> wrote:
> Hi,
>
> I have a few questions on some items pertaining to
> bandwidth allocation:
> 1. Request / transmission policy bit prohibiting
> piggyback request -
> if this bit is set for a connection, does this
> prohibit just the grant
> management sub-header for the connection's MPDUs or
> also the bandwidth
> request header for the connection in a unicast grant
> to SS?
> Basically, there are three types of requests that a
> connection can make:
> a. Bandwidth request in grant management sub-header
> of the connection's MPDU
> b. Bandwidth request header concatenated with MPDUs
> of same or other
> connections' MPDUs
> c. Bandwidth request header in a contention request
> region
>
> Question is if piggyback is prohibited by R/T
> policy, can the
> connection use (b) for bandwidth requests?
>
> My understanding is that only grant management
> sub-header requests are
> gated by this bit.
any request sent either embedded in the data PDU or
attached to the PDU is termed as piggy-back. (this is
the case in other technologies like IEEE 1394).
My understanding is, if the Req-Tr policy sets this
bit, only option c is to be applied on the
correspondng SF.
>
> 2. Request / transmission policy bit prohibiting
> broadcast BW requests
> - does this cover the request header transmissions
> in multicast
> polling groups? What if the SS is part of a
> multicast polling group
> but the R/T policy bit prohibiting broadcast BW
> requests for a
> connection is set ON - can the connection use
> multicast polling
> regions to make a contention bandwidth request?
>
> My understanding is that the bit should apply to
> both broadcast as
> well as multicast request polling regions.
I agree with you.
It poses a confusion only for nrtPS sched type SFs.
For other shced types, the ReqIE slot usage is well
defined in table 110, page 142 (std D5).
>
> 3. Midamble insertion interval calculation - should
> the burst preamble
> be accounted for while making the decision of
> whether to include a
> postamble symbol?
>
> Requirement is that there should be a postamble
> symbol if the number
> of symbols after the last midamble is greater than
> half the midamble
> insertion interval. Consider the following case:
> Data grant - short preamble = 1 symbol
> Total grant (including preamble and midambles) =
> 21 symbols
> Midamble insertion interval = 8 symbols
>
> If preamble is included in the calculation, then a
> postamble must be
> added; if not the postamble is not required.
>
> My understanding is that the preamble also counts
> towards the calculation.
>
> 4. Is it a requirement for the BS to allocate a
> single unicast grant
> to the SS per UL-MAP? Can the SS assume that the BS
> will combine all
> the allocations to the SS into a single UL-MAP IE?
> Does the
> specification explicitly mandate this requirement
> for the BS? If it
> does not, should this requirement be mandated?
>
> My understanding is that it is not required for BS
> to allocate a
> single unicast grant per UL-MAP to the SS (i.e., it
> can grant zero or
> more per UL-MAP). How ever, it is inefficient to use
> more than a
> single IE for per SS allocation.
I fully agree with you.
Even the IRI and ReqIE slots could be shceduled
anywhere in UL-MAP and not necessarily at the start.
But for some real time applications(not necessarily
voice and video but industrial also), the latency may
be an issue if the length of the frame is more than
the latency period. The complexity of BS scheduling
algo grows by this.
>
> 5. What is the SDU size of the UGS allocations from
> BS point of view?
> Is this just the minimum reserved traffic rate
> divided by the maximum
> latency? I am at a loss in understanding why this
> information is left out of
> the specification - especially considering that a
> wrong value can cause
> the UGS connection not to pass any traffic.
>
> My understanding is that UGS grant size = minimum
> rate / maximum latency
Acc to sec 6.3.5.2.1 of D5 std, the UGS SFs generate
fixed size SDUs peroiodically. This value could be
exchanged in Fixed-length versus variable-length SDU
indicator (11.13.15). This is the min grant (incl the
MAC hdr/sub-hdr) BS has to alloc each time for the SF.
>
> 6. Can SDUs from UGS connections be fragmented -
> nothing in the
> specification prohibits this but fragmentation is
> always an overhead.
> In DOCSIS, UGS SDUs cannot be fragmented, but there
> are some very
> good arguments why fragmentation should be allowed
> on UGS connections.
>
> My understanding is that the UGS connection SDUs
> cannot be
> fragmented - SS does not have an easy way to provide
> a feedback to
> BS about pending UGS fragment SDUs.
Section 6.3.5.2.1 of D5 std says,
"The size of these grants shall be sufficient to hold
the fixed length data associated with the service flow
(with associated generic MAC header and Grant
management subheader) but may be larger at the
discretion of the BS scheduler."
(1)This clearly indicates the SDU size can't exceed
the MAX_PDU size for fragmentation.
(2)Also sec 11.13.15 says about the packing only and
not fragmentation (this if more meaningful for ATM
CS).
by above 2 points, my understanding is, implicitly
frag is not allowed.
>
> 7. Can UGS connection SDUs be packed together -again
> nothing in the
> specification prohibits it? In DOCSIS, UGS SDUs
> cannot be packed
> (concatenation is closest concept to packing in
> DOCSIS)
>
> My understanding is that the UGS SDUs may be packed
> as long as they
> are not fragmented.
see above reply.
>
> 8. How is the tolerated jitter enforced? Consider
> the following scenario:
> Frame duration - 10 msec
> UGS connection - each allocation is 8 symbols
> Maximum latency 20 msec
> Tolerated jitter - 2 msec
> Frame 1 - allocation starts at symbols 4 and ends at
> symbols 11.
> In the frame 3, when the next allocation is due, is
> an allocation any
> where in the UL sub-frame considered okay or should
> the allocation be
> between symbol 4 and (symbol 4 + 2 msec)?
> Reason I bring this up is that DOCSIS requirement is
> very strict for
> the UGS allocations - all the allocations are
> strictly tied to the
> first allocation for the connection with the
> following restriction:
> Ti + maximum latency <= Ti+1 <= Ti + maximum
> latency + tolerated jitter
> Is it the same here or different?
>
> My understanding is that any allocation in the frame
> is the same as
> if it were at the beginning of the frame.
>
> 9. How is the DL preamble configured - is it a per
> SS parameter? Is it
> per DIUC parameter? Or it expected to be enabled for
> all transmissions
> when certain conditions are met?
>
> Appreciate any clarifications/comments/flames :)
>
> Thanks
> Kalash
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com