Re: [STDS-802-16] [STDS-802-16-MOBILE] Contribution 281, (comment 785)
Vladimir
First of all, the one bit we proposed in the Fast DownLink Notification (FDLN) is used for indicating the presence of any broadcast configuration change, and I am not sure if DCD/UCD is the only example of such a change. But assuming that your observatiuon is true, only one of the bits is used for this purpose. The main reason of introducing such channel is to announce the presence of any paging message for the mobile (such as the ones indicating the presence of traffic for the Idle mobile, which has nothing to do with DCD/UCD). Therefore, we think that to preserve the power, specially for some applications like voice, such a quick paging concept is needed, and as a matter of fact, almost all of the mobile technologies have something like this.
Masoud
-----Original Message-----
From: owner-stds-802-16@listserv.ieee.org on behalf of Vladimir Yanover
Sent: Tue 8/31/2004 7:04 AM
To: STDS-802-16@listserv.ieee.org
Cc:
Subject: [STDS-802-16-MOBILE] Contribution 281, (comment 785)
Hello,
This is to clarify my position on 802.16e comment #785 (Contribution #281)
Change in "configuration change count" is a very rare event.
BS may never change "DCD configuration change count" and may work hours
with same "UCD configuration change" count value [typical reason should be
change in "Ranging/Request Backoff Start/End" UCD parameters].
Change in DCD/UCD burst profile encodings is yet more rare event
as it happens only when the BS decides to change meaning of DIUC/UIUC for
certain burst profiles.
So reasonable behavior for MSS in Idle mode would be to listen to MAPs, say,
once a second
[if PAGING_CYCLE is greater than 1 sec]. Then the MSS will definitely
capture change
in "configuration change count" values. In this case it will continue
reception until DCD/UCD comes.
As the MSS is listening to MAPs only once a second, power may be saved and
there is
no need in additional signaling.
Vladimir
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.
************************************************************************************