RE: stds-802-16-mobile: Sleep window parameters in Table 275a
Guys,
I think I may missing something here.
The Max_Sleep_Window does not imply that the MSS should sleep
no more than this value, it just mean that an MSS, which is
in sleep mode must awake, verify that there is no awaiting
traffic for it and return to sleep.
Having the MSS to be able to sleep for minutes, and assuming
some realistic assumption that the MSS will have an IP
connection (even if not active), will result that, in the
worst case, will take minutes to initiate an IP session. I
assume that the rate that will be available for such MSS will
not be very high, for some period of time.
Taking Phil's numbers of 99.6% of the time sleeping, seems
reasonable, while eliminating such potential delays.
Again, the hour here is quite late, so maybe I'm missing
something.
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
> Johnston, Dj
> Sent: Thursday, November 06, 2003 22:48
> To: Phillip Barber; stds-802-16-mobile@ieee.org
> Subject: 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.
> > > >
**************************************************************
> > > > **********
> > > > ************
> > > >
> > > >
> > >
> > >
> > >
> >
> >
>
>