stds-802-16: RE: More about UGS (and rtPS)
Thanks again for bringing errata to our attention.
Everywhere that "Tolerated Grant Jitter" appears in the standard, it should
be changed to "Tolerated Jitter". The two lines in note 12 that reference
"Nominal Grant Jitter" are obsolete and should be deleted. For the
Real-Time Polling Service key parameters, "Nominal Polling Interval" and
"Tolerated Poll Jitter" should be replaced with "Maximum Sustained Traffic
Rate, Minimum Reserved Traffic Rate, Tolerated Jitter". Likewise in section
6.2.5.3, "Nominal Polling Interval" should be deleted.
For UGS services, since they mirror CBR services in general, Maximum
Sustained Traffic Rate should equal Minimum Reserved Traffic Rate just as
PCR = SCR for CBR ATM connections. Since they are the same, one or the
other in the DSA messages would be sufficient. We haven't said anywhere
that the SS must handle one or the other or both. This is definitely an
ambiguity in the specification. If we had mibs defined for the connection
setup, the mib would probably always have both values and some bounds check
software would ensure that the values are always the same for UGS. We'll
need to clear up this ambiguity, but the actual solution may need some
discussion since numerous alternatives work.
The sentence that describes giving fixed size Data Grants at specific
intervals is a very out of date sentence left over from DOCSIS. I'll work
on re-wording that section. basically, what is allocated is a function of
the connection type and the BS scheduler. For packet services with
fragmentation, the BS scheduler needs to allocate enough bandwidth often
enough to meet the needs of the connection and can do it in fewer large
chunks or more small chunks. For ATM without fragmentation (the normal case
for ATM), the BS would allocate 1 cell every 4 frames in your example
because the SS couldn't send any cells otherwise. In both cases, if the
scheduling algorithm adds jitter, the BS needs to remove it, usually through
jitter buffers. Granted this converts the jitter to delay. The actual
process used is outside the scope of the standard, but is solvable.
Ken
-----Original Message-----
From: Germán Madinabeitia Luque [mailto:german@trajano.us.es]
Sent: Friday, November 29, 2002 10:48 AM
To: ken@ensemble.com
Cc: stds-802-16@ieee.org
Subject: More about UGS (and rtPS)
Dear Ken,
Thank you for your swift reply.
You mention the "Tolerated Grant Jitter", which I am unable to
find, I guess you mean the "Tolerated Jitter" as defined in section
11.8.4.13. Please note that at page 126, footnote #12, the
Tolerated Grant Jitter and the Nominal Grant Interval are mentioned
again.
Coming back to section 6.2.5.1, the last paragraph mentions the
Maximum Sustained Traffic Rate parameter of the Active QoS
Parameter Set. Do I need to specify this extra parameter for UGS
flows?
Please note that, when defining the Real Time Polling Service,
several parameters are mentioned, namely "the Nominal Polling
Interval, the Tolerated Poll Jitter, and the Request/Transmission
Policy". But the first one is undefined, and the second one only
appears as a PHY-specific value in 10.3.1.5, not as a service flow
definition parameter.
Finally, your answer has raised another question I'd like to ask you.
When defining the UGS, it is stated that the BS shall provide fixed
size Data Grant Burst Types at periodic intervals. What happens if
the desired rate was less than 1 cell/frame (let's say 0.25
cells/frame? How is supposed the capacity to be provided? One full
cell on every fourth frame? or a quarter or a cell on every frame?
It may have non negligible impact in the observed transfer delay of
the cell.
Thank you for your time.