RE: stds-802-16-mobile: Sleep window parameters in Table 275a
I can't think of a scenario where this would break anything. If you felt
the need to go for a lower duty cycle, you always have the option of
repeating network entry when you wake up.
So sure, I can go for that. Picking a number is always harder than
agreeing with someone else's number :)
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: Thursday, November 06, 2003 12:43 PM
> To: stds-802-16-mobile@ieee.org; Johnston, Dj
> Subject: 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.
> > > **************************************************************
> > > **********
> > > ************
> > >
> > >
> >
> >
> >
>
>