Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-16] =?gb2312?Q?=B4=F0=B8=B4:?= [STDS-802-16] DCD/UCD message in OFDMA -2048




Hello Dazi,

    Thanks for the answer. Your answer is the same one as my colleague told me.
However, I could not find the sentence in either 16e-2005 or 16d-2004 saying that
DCD/UCD is in the burst profile with DIUC = 0, except that in Table 14 of 16e-2005 (page 44),
the UCD and DCD belong to "Fragmentable Broadcast", which are supposed to be demodulated
by all subscriber stations (SS) as broadcast messages.

   How could we ensure the fidelity on this question?

Best regards,
   Lepidus.



Dazi Feng <dfeng@ztesandiego.com>

2006/06/15 12:37 AM
請回信 給 dfeng

       
        收件人:      STDS-802-16@listserv.ieee.org
               
        副本抄送:  
        主旨:          [STDS-802-16] 答复: [STDS-802-16] DCD/UCD message in OFDMA -2048



Hi,

                My Idea is:
               
                On standard 2004 page 522, it specifies that "DIUC=0 shall have
burst profile parameters that are the same as those used for
transmission of the DL-MAP message". So before the MS reads the DCD/UCD
to get the burst profile, the only burst it can demodulate is the DIUC=0
one. the DCD/UCD must have same profile as DL-MAP and using the
broadcasting CID, which make sense to me.

Regards

Dazi Feng
System advisor
ZTE San Diego
dfeng@ztesandiego.com

-----邮件原件-----
发件人: Jonny SUN [mailto:jonny.sun@ST.COM]
发送时间: 2006年6月13日 6:53 PM
收件人: STDS-802-16@LISTSERV.IEEE.ORG
主题: [STDS-802-16] DCD/UCD message in OFDMA-2048


Dear all,

According to  standard (802.16e-2005), the following rules for DCD/UCD
message are defined for OFDMA-2048:
- DCD/UCD are MAC PDU with broadcast (or fragmented broadcast) CID.
- The position and DIUC code of DCD/UCD message are appointed by DL_MAP.
- The uplink/downlink burst profile parameters for each UIUC/DIUC code
are defined and updated by UCD/DCD message (except for the burst profile
used by DL_MAP, which is defined in the downlink frame prefix).
- DCD/UCD may not present in every DL subframe. The maximum time
interval between the transmission of DCD/UCD message will be 10s.

The questions are:
1. When an MS is entering the network, it can decode the downlink frame
prefix because the burst profile is well known. And then it can decode

the DL_MAP because the burst profile is defined in downlink frame
prefix. But the DIUC code used in the DL_MAP are defiend in previous DCD
message. How can MS decode the downlink MAC PDU using the burst profile
it has no idea about? If the MS can not decode the downlink MAC PDU, how
can it decode the DCD, UCD and UL_MAP. And if the UCD and UL_MAP can not
be decoded, how to
know initial ranging allocation at MS?    
2. Since the DCD/UCD message may not present in every DL subframe, the
new entering MS may waiting for a few frames before it get the first
DCD/UCD message. During this period, it can not decode any other message
except for the DL_MAP/UL_MAP. However, since the DCD/UCD message are
treat as generic MAC PDU, the MS can not recognize them until decode the
PDU. So, is there any method to know the presence and position of
DCD/UCD in current DL subframe?

Thanks.

Best Regards
Jonny




************* Email Confidentiality Notice ********************

The information contained in this e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. It is intended to be conveyed only to the designated recipient(s). Any use, dissemination, distribution, printing, retaining or copying of this e-mail (including its attachments) by unintended recipient(s) is strictly prohibited and may be unlawful. If you are not an intended recipient of this e-mail, or believe that you have received this e-mail in error, please notify the sender immediately (by replying to this e-mail), delete any and all copies of this e-mail (including any attachments) from your system, and do not disclose the content of this e-mail to any other person. Thank you!