Fw: stds-802-16-mobile: Sleep window parameters in Table 275a
Might I suggest expanding the max sleep-window duration to 24 bits (max of
approx. 560 minutes) to accommodate your battery powered, best-effort data
usage model? This would result in the device potentialy spending 99.99998%
of its time in power conservation 'sleep' mode.
Thanks,
Phillip Barber
----- Original Message -----
From: "Phillip Barber" <pbarber@broadbandmobiletech.com>
To: "Johnston, Dj" <dj.johnston@intel.com>; <stds-802-16-mobile@ieee.org>
Sent: Thursday, November 06, 2003 1:20 PM
Subject: 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.
> > **************************************************************
> > **********
> > ************
> >
> >
>
>
>