RE: stds-802-16-mobile: Sleep window parameters in Table 275a
All,
I share Itzik's opinion concerning listening interval duration: it is
certainly defined by ability of BS
to find time for transmitting TRF-IND message. Neverheless, it does not
contradict the idea that
MSS may suggest a value, just as a side interested in power saving. Then we
leave
to implementation (of BS) to decide, having inputs from MSSs, on priority /
frequency of
transmitting TRF-IND messages.
Vladimir
-----Original Message-----
From: Itzik Kitroser [mailto:itzikk@runcom.co.il]
Sent: Friday, November 07, 2003 9:52 PM
To: chkoo@samsung.com; stds-802-16-mobile@ieee.org
Subject: RE: stds-802-16-mobile: Sleep window parameters in Table 275a
Dear Changhoi and all,
I would like to emphasis one point, which seems to be missed.
The listening interval, as currently defined, especially
following the last session, after a discussion and agreement
by the people participated at that discussion, is only
related to the BS's capabilities to be able to send TRF-IND
message in a timely manner.
It does not related, by any means, to the time that the MSS
spends to re-synchronize with the BS after awakening from a
sleep-mode.
If you try to think about this from the aspect of problem
complexity, real implementation, and have a practical
solution, then, at least for me, it is much straight forward
that each MSS, which has its own implementation constraints,
will compensate its own time, arriving awake and ready to
receive TRF-IND message on the end of its sleep window.
Having this value to be encapsulated within the listening
interval just adds complexity and/or delay.
In addition, I don't understand the context of a Mobile with
fixed power and a listening interval. My believe is that such
mobile will not go to sleep, and may spend it's idle time
doing some productive tasks, like scanning for neighbors.
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 Changhoi Koo
Sent: Friday, November 07, 2003 13:22
To: Phillip Barber; stds-802-16-mobile@ieee.org
Subject: Re: stds-802-16-mobile: Sleep window parameters in
Table 275a
Dear Phillip and all
Thanks for your good comments..
I'd like to add something on your comments..
As you know that, the Mobile with fixed power will prefer the
longer listening interval rather than shorter interval
because of taking pending data if it is. Of course the sleep
interval also would affect it. From the BS side, to make
tight and effcient scheduling to give a positive indication,
the BS can assign the relatively longer listening interval.
At this stage, the MSS can get attemption to receive the data
from the BS. Therefore, In my understanding, it should be
allowed that MSS suggest the listening interval based on its
power status. However, if we add some information on the
message explaning the MSS type such as fixed or mobie, it
may not be required...
Regarding Listening interval in TLV of REG-RSP message..
If the MSS does not involved into sleep mode, the BS cannot
assign the propser listening interval because the listening
interval is strongly dependent the cell status that how many
MSS are in traffic state (come and go to sleep-mode and awake-
mode). Therefore, it would not be good approach that the MSS
gives a listening interval through REG-RSP messsage.... In my
understanding, the listening interval should be allocated
through SLP-RSP message..
Thanks
Changhoi Koo
----- Original Message -----
From: Phillip Barber
To: Changhoi Koo ; stds-802-16-mobile@ieee.org
Sent: Friday, November 07, 2003 11:34 AM
Subject: Re: stds-802-16-mobile: Sleep window parameters in
Table 275a
Changhoi and all,
Listening interval cannot affect QoS session initiation
latency, only sleep-window duration can affect latency.
Listening interval could only affect latency if you were
going to do multiple MOB_TRF-IND messages targeted to the
same MSS during one MSS listening interval (yuk!). In that
case, you may as well stay awake (not in sleep-mode) and let
the scheduler spool down the MSS's time/frame allocation, but
stay on the active list. Or go back in to sleep mode (short
sleep-window) in between waiting for your next MOB_TRF-IND
message opportunity.
Listening interval only has to be long enough for the MSS to
listen to a pending MOB_TRF-IND message. Staying awake
longer only cuts into any possible battery life. If the MSS
is on line-power, a short listening interval causes it no
injury. Having the MSS stay listening longer accomplishes
nothing as it will not act until it hears a positive MOB_TRF-
IND message. The answer is instead to reduce the sleep-
window duration to reduce the time intervals between
listening-windows. That will minimize latency very
efficiently.
Variation in traffic loading can certainly cause you to want
to change sleep-window duration, but never listening
interval. Buffering due to traffic loading is irrelevant.
BS is only tickling a traffic flag, not providing the data at
time of MOB_TRF-IND. So traffic loading may cause scheduling
issues AFTER the MSS has been tickled out of sleep-mode, but
won't affect tickling the MSS awake.
And as we discussed previously, negotiating differing
listening-intervals for many MSS can result in massive
complexity when scheduling common MOB_TRF-IND ticklers. You
end up having individual MOB_TRF-IND notifications all over
the place. Far less than ideal.
The answer is to negotiate and control sleep-window duration,
not listening interval.
Listening-interval had been a negotiated value prior to
Session 27. We changed listening-interval to be a system TLV
value passed at registration for all of these reasons. I am
not seeing a compelling argument for reverting to our
previous methodology or for having arbitrarily long listening-
intervals.
Thanks,
Phillip Barber
----- Original Message -----
From: Changhoi Koo
To: Phillip Barber ; Itzik Kitroser ; stds-802-16-
mobile@ieee.org
Sent: Thursday, November 06, 2003 6:32 PM
Subject: Re: stds-802-16-mobile: Sleep window parameters in
Table 275a
Dear Itzik and Phillip
Thanks for your reply...
I think that the listening interval would affect the data
receiving time. if the lietening interval is short, it may be
happened that the BS shall buffer the data and the data
transmission will be delayed...Becuase the short listening
interval may deminish the receiving(at MSS) and transmitting
(at BS) attempt.Therefore, if the battery of the MSS is
enough (e.g the MSS with fixed power in car, train, or
something like that...), the MSS would be waiting with
relatively longer listening interval. Therefore in your mail
the mentioning the MSS wants short listening interal any time
may not be correct..As results, it should be allowed that the
MSS suggest the listening interval based on its power
status.... from my understanding
From BS scheduling point of view..
To adjust the exact and effect scheduling point at the BS
side, the listening interval should be allocated dynamically
to be reflected the traffic pattern..
Even in allocating the fixed listening interval, the real
listening interval will be decided based on the traffic
pattern (take sleep interval increasing...) And also, because
sleep-interval as well as listening interval will be
dependent of the traffic pattern and decided when the MSS
goes to sleep mode, not exchanging REG-REQ/RSP message(like
as current docuement)..Therefore, the allocation of listening
interval during REG-REQ/RSP exchanging may not be correct and
reflect the traffic status...
So my understanding is ...
The MSS suggests the listening interval(based on its power
status) and the BS allocate it (based on scheduling
policy)..during MOB_SLP-REQ/RSP exchanging same as the
original approach
Thanks
Changhoi Koo
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.
************************************************************************************