|
Vladimir,
I do
agree (after re-checking..) that there is not other parameter in table 275 that
is negotiated. I think that keeping the parameter provides a good way of knowing
about performance bound in advance, without the need of other mechanisms to
ensure this.
But I
don't have such strong feelings for the parameters, anyway, other opinions form
members on this issue are welcome.
Regarding the listen interval, the TLV is already following a comment I
made at last meeting.
Regards,
Itzik.
Itzik,
Thanks for your comment. My understanding of "minimal
performance" stuff in interoperability standard
is
to protect the performance of the whole cell and properly designed
SSs from being harmed by badly designed SSs.
Nothing can protect performance of badly designed
unit. Suppose, an MSS has requested too large max sleep
window.
There is a choice for BS: either agree and then e.g.
to take care of the increasing amount of data accumulated for the MSS or
alternatively return in MOB_SLP-REQ another value, according to
BS's prediction of activity of communication etc.
If
we consider BS as properly designed unit, it should choose the second
option.
Note
that there is no parameters in the original table 275 that would provide
bounds for negotiatable parameters.
Concerning Listening interval, I agree that it can be decided by BS alone. How this
value becomes known to MSSs?
We need either
TLV or a field in MOB_SLP-RSP.
Vladimir
-----Original Message-----
From:
Itzik Kitroser [mailto:itzikk@runcom.co.il]
Sent: Tuesday, November
04, 2003 10:36 AM
To: Vladimir Yanover;
stds-802-16-mobile@ieee.org
Subject: RE: stds-802-16-mobile: Sleep
window parameters in Table 275a
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.
************************************************************************************
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.
************************************************************************************
|