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



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