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



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

System

Name

Time Reference

Min. Value

Default Value

Max. Value

SS

Min_Sleep_Interval

Minimum sleeping time allowed to SS

2 Frames

 

 

SS

Max_Sleep_Interval

Maximum sleeping time allowed to SS

 

 

5 Frames

SS

Listening_Interval

The 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

 

 

 

BS

BEA-ADV interval

Nominal time between transmission of BEA-ADV messages

 

 

30s

BS

ASC-AGING-TIMER

Nominal time for aging of MSS associations

100ms

 

 

BS

Neighbor_Info interval

Nominal time between transmission of Neighbor_Info messages

 

 

600s

BS

Neighbor-Aging-Timer

Nominal time for aging of BS neighbor association and removal from the dynamic Neighbor BS table

3600s

 

 

 

 

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