Re: stds-802-16-mobile: Sleep window parameters in Table 275a
DJ and all,
I think I am a little slow today, but I am not following your argument here.
To summarize the current sleep algorithm, with a 1,024 frame
Max_Sleep_Interval, upon reaching the Max limit, the MSS would sleep for
1,024 frames, wake for a minimum of 4 frames to Listen, and sleep again;
repeating the cycle infinitely or until interrupted by the BS. From a power
conservation standpoint, the MSS would be spending as much as 99.6% of its
time sleeping. From a QoS session initiation latency standpoint, the MSS
would never be more than 2 seconds away from awakening and initiating a QoS
session. The Max value seems to do well for both criteria in the mobile
multimedia model for 802.16e. The only way I can see it not making as good
sense is if you change the criteria. Let's say you decide that you are
going to implement a network that is going to be mobile, but best effort
data only. Then you could have substantially longer Max values because you
would not care how long (relatively speaking) it took to initiate a
non-timing sensitive session. But that is not the criteria as I understand
it. I think the critical design constraint of mobile multimedia applies
universally for 802.16e. So the Max value of 1,024 seem a happy compromise
number.
As I said though, I could be completely misunderstanding your argument. I
think I need some more coffee.
Thanks,
Phillip Barber
----- Original Message -----
From: "Johnston, Dj" <dj.johnston@intel.com>
To: "Phillip Barber" <pbarber@broadbandmobiletech.com>;
<stds-802-16-mobile@ieee.org>
Sent: Tuesday, November 04, 2003 12:19 PM
Subject: RE: stds-802-16-mobile: Sleep window parameters in Table 275a
I feel a little uncomfortable about setting a hard constraint of 1024
frames through the bit level encoding. Negotiating (or the BS dictating)
a constraint is fine.
I have worked on wireless systems where the power saving duty cycle was
as high as 1 slot in10 and as low as 10ms per week. The rational for the
former was response time, the rational for the latter was low service
intervals through huge battery life.
The point is that the application can sometimes dictate a duty cycle
much longer than 1024 frames and we would be unwise to presuppose what
the range of applications might be. A 1024 limit might lock 802.16 out
of certain applications.
DJ
David Johnston
Intel Corporation
Chair, IEEE 802 Handoff ECSG
Email : dj.johnston@intel.com
Tel : 503 380 5578 (Mobile)
Tel : 503 264 3855 (Office)
-----Original Message-----
From: owner-stds-802-16-mobile@majordomo.ieee.org
[mailto:owner-stds-802-16-mobile@majordomo.ieee.org] On Behalf Of
Phillip Barber
Sent: Tuesday, November 04, 2003 8:51 AM
To: stds-802-16-mobile@ieee.org; Vladimir Yanover; Itzik Kitroser; Ofer
Kelman; Changhoi Koo
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 -----
From: Itzik Kitroser
To: Vladimir Yanover ; stds-802-16-mobile@ieee.org
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.
-----Original Message-----
From: Vladimir Yanover [mailto:vladimir.yanover@alvarion.com]
Sent: Tuesday, November 04, 2003 11:47
To: 'Itzik Kitroser'; stds-802-16-mobile@ieee.org
Subject: RE: stds-802-16-mobile: Sleep window parameters in Table 275a
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.
-----Original Message-----
From: owner-stds-802-16-mobile@majordomo.ieee.org
[mailto:owner-stds-802-16-mobile@majordomo.ieee.org]On Behalf Of
Vladimir Yanover
Sent: Tuesday, November 04, 2003 09:40
To: 'Changhoi Koo'; Ofer Kelman; Phillip Barber;
stds-802-16-mobile@ieee.org
Subject: RE: stds-802-16-mobile: Sleep window parameters in Table 275a
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
-----Original Message-----
From: Changhoi Koo [mailto:chkoo@samsung.com]
Sent: Tuesday, November 04, 2003 5:40 AM
To: Ofer Kelman; Phillip Barber; stds-802-16-mobile@ieee.org
Subject: stds-802-16-mobile: Sleep window parameters in Table 275a
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 -----
From: Ofer Kelman
To: Phillip Barber ; stds-802-16-mobile@ieee.org
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
-----Original Message-----
From: Phillip Barber [mailto:pbarber@broadbandmobiletech.com]
Sent: 28 October, 2003 6:16 PM
To: stds-802-16-mobile@ieee.org
Subject: stds-802-16-mobile: Sleep window parameters in Table 275a
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
SystemNameTime ReferenceMin. ValueDefault ValueMax. Value
SSMin_Sleep_IntervalMinimum sleeping time allowed to SS2 Frames
SSMax_Sleep_IntervalMaximum sleeping time allowed to SS 5 Frames
SSListening_IntervalThe 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
BSBEA-ADV intervalNominal time between transmission of BEA-ADV messages
30s
BSASC-AGING-TIMERNominal time for aging of MSS associations100ms
BSNeighbor_Info intervalNominal time between transmission of
Neighbor_Info messages 600s
BSNeighbor-Aging-TimerNominal time for aging of BS neighbor association
and removal from the dynamic Neighbor BS table3600s
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.
************************************************************************
************