Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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.
> > > > 
**************************************************************
> > > > **********
> > > > ************
> > > >
> > > >
> > >
> > >
> > >
> > 
> > 
> 
>