|
I understand, and think I partially
agree. I think the amount of absolute time spent in a given sleep interval
window is more important than percentage of time that 4,096 frames
represents. Absolute time affects
recovery-to-active operation to meet sleep interval QoS request for
session initiation. Percentage of time spent sleeping versus listening
affects power conservation, but is essentially arbitrary, and has no QoS
implications. So you want the sleep interval/listening interval ratio to
be something like 10-to-1. As long as the ratio is adequately high, you
don't really care about 10-to-1 or 12-to-1. But you certainly care
about 8 second absence versus 2 second absence. At 4,096 frames
with 2ms frame sizes, the MSS would be spending eight second time slices in
sleep windows before entering a listening interval--really too long to recover for QoS request for session initiation while
MSS was sleeping. Two second delay is probably more reasonable, so a
Max_Sleep_Interval window of 1,024 frames is more reasonable for the current
model.
For my contribution C80216e-03_57 revised sleep
mechanism, I should probably reduce final sleep window bit size to 10 bits
(1,024 frames) and expand sleep window iterations to 10 bits (1,024
iterations). So using max values, no single sleep window would exceed
2 seconds and the total time through all sleep window iterations would
be 87 minutes before MSS would have to return to Normal Operation with
Serving BS (if you max out all variables). A pretty reasonable
number. Forcing the MSS to return to Normal Operation every hour- to
two-hours or so is a good idea because it allows the Serving BS to re-establish
that the MSS is still 'connected'. The MSS could have dropped-off in the
interim and the Serving BS would have no way to know. Need to let Serving
BS clean-up resources and allocations periodically. Especially important
in mobile systems. Using normal sleep
interval expiration to force the MSS to return to Normal Operation is a more
elegant mechanism than forcing the Serving BS to send false traffic messages
periodically to make the MSS exit sleep and return to Normal Operation to find
dropped MSS.
Itzik's response points to a one second max and
references previous literature. But I am not aware of any critical QoS
documents that indicate one second is an imporant max recovery period to
overcome QoS session initiation lag. Indeed, for most common forms of
multimedia traffic, of all types and through all transmission mediums employed
today, four to twelve second session initiation windows are the rule.
Also, on average, a two second max window will result in a one second imposed
average latency. I just think two seconds is a better number to use than
one second for max period. But I will submit to the will of the
group.
Thanks for continuing to look at this. I
think it still could use more noodling.
Thanks,
Phillip Barber
----- Original Message -----
Sent: Sunday, November 02, 2003 7:45
AM
Subject: RE: stds-802-16-mobile: Sleep
window parameters in Table 275a
Phillip and all,
I
agree that the 5 frames duration may me too small of a period, but at the same
time 4096 is much too much. To my understanding, the sleeping
interval should be around 10 times of the listening time. This gives
us some 90% power savings in time. to get better percentage the
sleep interval grows too much. For example take a ratio of 20 frames sleep and
2 frames listening time. It is around 89% power saving (taking into
consideration that the "wake-up" process consumes more power then
continues operation). While 30 frames of sleep with 2 listening frames goes to
96%. This shows that the additional 7% of saving costs 30% in sleeping time.
I
would recommend 30 to be the maximum value.
Ofer
Itzik and all,
I have been working on a revision to Table
275a. A few observations:
SS/Max_Sleep_Interval/Max. Value seems very
low. Shouldn't this be something more like 4,096 frames or
more?
For SS/Listening_Interval/Min. Value, didn't we
settle on 4 frames at Session 27?
Thanks all.
Table 275a-Parameters
and Constants
|
System |
Name |
Time Reference |
Min. Value |
Default Value |
Max. Value |
|
SS |
Min_Sleep_Interval |
Minimum sleeping time allowed to
SS |
2 Frames |
|
|
|
SS |
Max_Sleep_Interval |
Maximum sleeping time allowed to
SS |
|
|
5 Frames |
|
SS |
Listening_Interval |
The time duration during which the SS, after waking up and
synchronizing with the DL transmissions, can demodulate downlink
transmissions and decides whether to stay awake or go back to
sleep |
|
|
|
|
BS |
BEA-ADV interval |
Nominal time between transmission of BEA-ADV
messages |
|
|
30s |
|
BS |
ASC-AGING-TIMER |
Nominal time for aging of MSS
associations |
100ms |
|
|
|
BS |
Neighbor_Info interval |
Nominal time between transmission of Neighbor_Info
messages |
|
|
600s |
|
BS |
Neighbor-Aging-Timer |
Nominal time for aging of BS neighbor association and
removal from the dynamic Neighbor BS table |
3600s |
|
|
Thanks,
Phillip
Barber
|