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