|
Dear All
I agree with Phillip Barber..
Actually, the MAX-WINDOW and MIN-WINDOW size shall be
defined to gurantee the performance protection and make firm the MSS operatio in
sleep mode.
And also, it would be needed that two values are
partially negotiated (It means that the MSS can suggest the values and the only
BS shall decide and allocated based on the MSS suggestions..I don't know it can
be called "Negotiation"..)
And regarding Listening interval...
The listening interval depends on the MSS power
saving..Thus, it should be allowed that the MSS suggest the listening interval
based on its power status..
Of course in this case, the BS only can decide and
allocate the listening interval..
As results, I would like to suggest that the all of
listening interval related issues should be went to back to original
version...(I have already uploaded it as an one of commentary...)
Thanks
Changhoi Koo
----- Original Message -----
Sent: Wednesday, November 05, 2003 1:51
AM
Subject: Re: stds-802-16-mobile: Sleep
window parameters in Table 275a
I don't think the argument of 'no
other parameter in Table 275a is constraining a negotiated value' applies
because all other bound values in 275a (excepting Min_ and Max_
Sleep_Interval) are simple, non-derived values. In most cases upper
bound of a value is constrained by the bits allocated. As a calculated
value based on contributing variables, Max_Sleep_Interval is not similarly
constrained. Therefore an external, arbitrary constraint MAY be
warranted. And because of the unconstrained, exponential increase in the
sleep window, Max_Sleep_Interval MUST either be negotiated as a maximum
constraint or arbitrarily set. It absolutely MUST be constrained or
else you will have infinite size sleep windows. Even if you wanted to
let the MSS and BS negotiate Max_Sleep_Interval, the negotiation would be
arbitrarily constrained by the bits allocated to the negotiation variable (10
bits?, 12 bits?). It is simplest to put
in a reasonable boundary and be done with it. Changhoi and I have suggested 1,024
frames. 1,024 seems fairly consistent with Itzik's requirements.
Only Ofer has put forth a significantly different value (30 frames) which
seems far too low to me.
Of course, you
could also just use the sleep algorithm I propose in my contribution 57.
It is more fexible in negotiated values and structures; can be linear,
exponential, truncated, or of substantial duration.
As far as
listening_interval, we decided at Session 27 to make it a value set by the BS
(11.4.14.1 Listening Interval, reported in REG-RSP
TLV). Table 275a has Listening_Interval constraint in the table,
but no values. We also agreed that Min Value should be 4 frames, but it
is not in Table 275a. Max Value is constrained by the 8 bit size
allocation for Listening Interval in 11.4.14.1., so no need to set Max
Value. I have not checked to see if any comments
address the omission of Min Value for Listening_Interval, but I know my
contribution 57 does.
Thanks,
Phillip Barber
----- Original Message -----
Sent: Tuesday, November 04, 2003 4:02
AM
Subject: RE: stds-802-16-mobile: Sleep
window parameters in Table 275a
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.
************************************************************************************
|