Re: stds-802-16-mobile: Sleep window parameters in Table 275a
What max sleep-window duration value would you suggest for your best-effort
data example?
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: Thursday, November 06, 2003 12:59 PM
Subject: RE: stds-802-16-mobile: Sleep window parameters in Table 275a
Phil,
You are right, I am appyling a different requirement to that of a
'normal' mobile station and using this to justify not building in a
certain level of inflexibility.
I'm anticipating that power saving will open up a range of *fixed*
applications as well as mobile (e.g. remote monitoring) and a bit of
additional flexibility in the sleep interval will help.
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: Phillip Barber [mailto:pbarber@broadbandmobiletech.com]
> Sent: Wednesday, November 05, 2003 7:13 AM
> To: stds-802-16-mobile@ieee.org; Johnston, Dj
> Subject: 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.
> **************************************************************
> **********
> ************
>
>