RE: stds-802-16-mobile: Sleep window parameters in Table 275a
Phil (and all),
I agree that those kind of services may be required, although
we are aiming for a broadband system.
In such scenario that you have mentioned, the MSS can just
tuned off, or de-register from the BS, and re-register after
(hours, days) to check status or receive information.
It doesn't have to be required that the sleep-mode mechanism,
which supports power saving, for an active, or pseudo active
devices, will be used in conjunction with such applications.
Here you have a simple solution, which still keeps some
performance guaranties for MSSs that are still in active mode.
I'm still in the position that the max number of 1024 frames
should be kept for Max_Sleep_Window parameter.
Regards,
Itzik.
> -----Original Message-----
> From: Phillip Barber
[mailto:pbarber@broadbandmobiletech.com]
> Sent: Friday, November 07, 2003 04:59
> To: stds-802-16-mobile@ieee.org; Itzik Kitroser
> Subject: Re: stds-802-16-mobile: Sleep window parameters in
Table 275a
>
>
> Itzik and all,
>
> No, you are not missing anything. Well, not much.
>
> DJ's is considering one or two application models, valid
models, which we
> have not been considering. Let's look at those models.
>
> One model is a fixed service, battery powered data-
telemetry model. These
> would be SS used in industrial and commercial low-data rate
telemetry
> applications. Think meter reading. These units need to be
> battery operated
> to reduce installation and maintenance costs, but have
extraordinarily low
> data throughput and latency requirements. Session
initiation latency on
> these could tolerate days worth of delay. So our 16e
mobility
> changes don't
> do anything for these devices, but our 'sleep-mode'
addition to
> the standard
> can create incredibly valuable battery-life savings. For
these
> MSS devices,
> sleep-windows measured in many hours if not days would be
preferable.
>
> Another example is to take these devices mobile. Think
automotive and
> medical equipment telemetry. While some units may have
access to
> substantially more available battery-life, power
consumption is still a
> consideration. Given that these units may be low-data
rate, non-timing
> sensitive; tolerated session initiation latency could be
measured
> in minutes
> or hours.
>
> These are just a couple of examples. There are many more.
>
> It does not cause us any injury to make allowance for these
> longer potential
> sleep-windows (all we do is add a few bits in MOB_SLP-
REQ/RSP). It does
> make it much harder to arbitrarily wake one of these units
up or determine
> if it has lost connectivity. But these units by definition
are
> supposed to
> be able to tolerate that.
>
> After consideration, I am in favor of allowing dramatically
larger
> sleep-window sizes. Manufacturers will have to be cautious
in
> implementation. But it would enable some additional,
valuable application
> models that could drive many millions more units out the
door.
> And I am in
> favor of expanding market applications for the standard.
>
> Thanks,
> Phillip Barber
>
> ----- Original Message -----
> From: "Itzik Kitroser" <itzikk@runcom.co.il>
> To: <stds-802-16-mobile@ieee.org>
> Sent: Thursday, November 06, 2003 5:23 PM
> Subject: 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.
> > > > > >
> >
**************************************************************
> > > > > > **********
> > > > > > ************
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
>
>