|
Vladimir,
My
perspective on this issue, is that this parameter is required to provide a
maximum bound to the local parameter which is negotiated.
I
agree that since this parameter is negotiated, it seems to be redundant, but
then we don't have any performance assurance or bound, in the case when "bad
implementation" will choose to select a very high value.
Regarding the Listening_Interval, I think that it
should not be negotiated, but rather be set by the BS. According to my
understanding, and If the comments from the previous meeting were implemented,
this should be reflected in the draft.
As you
identified correctly, the sentence "The Listening-interval duration is negotiated between the BS and the SS." should be
removed from the Listening-Interval definition.
Regards,
Itzik.
Changhoi, Ofer, Philip and All,
It is not clear for me why we need
Max_Sleep_Interval value as global
parameter. I think, there is a need in some justification, for example:
if we don't have it, then badly designed MSS may
harm performance of the cell or whatever else. Note that
sleep parameters are negotiated anyway.
I would suggest
simply deleting Min/Max_Sleep_Interval from the table and adding
some description of negotiation
(for
example, "BS replies with smaller or equal initial/final sleep windows
values"). It is written
that Listening_Interval
also
should be negotiated, so we have to add it
to MOB_SLP-REQ/RSP messages?
Vladimir
Dear All...
I have already uploaded the comment inclduing
this issue...
Two points are there...
At least 80ms should be allocated to Max
value...from point of measurement of 1x(CDMA)
MODEM, the value(around 80ms) is minimum value for the power saving
considering RF ON/OFF and worming-up time etc...
And we have 10 bits for the Max
value...
So, I have proposed the 1024 frames for the Max
value...
Thanks
Changhoi Koo
----- Original Message -----
Sent: Sunday, November 02, 2003 10:45
PM
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
This
mail passed through
mail.alvarion.com
************************************************************************************
This
footnote confirms that this email message has been scanned by
PineApp
Mail-SeCure for the presence of malicious code, vandals & computer
viruses.
************************************************************************************
This
mail was sent via
mail.alvarion.com
************************************************************************************
This
footnote confirms that this email message has been scanned by
PineApp
Mail-SeCure for the presence of malicious code, vandals & computer
viruses.
************************************************************************************
|