Re: stds-802-16-mobile: Sleep window parameters in Table 275a

["Phillip Barber" <pbarber@broadbandmobiletech.com>]

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