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

Re: [STDS-802-16] Comment 112



Title: Message
Hi, All,
 
Yes, we did discuss this issue in our Orlando meeting. The group indicated that they prefer to adding it as optional, instead of mandatory. That's the reason why it was rejected. In this recalculation, changes have been made to reflect the group suggestion.
 
Just provide you a little bit more background information: the TC sublayer is not new in our 802.16 standard, it has been there from day 1 of the 802.16.  However, since it is specified in the PHY section, so it didn't get included in our 16a. We do believe there are technical advantages to have it. Comment 112 proposes to add it back for OFDM PHY.
 
Best Regards;
 
Lei
-----Original Message-----
From: Radu Selea [mailto:Radu@REDLINECOMMUNICATIONS.COM]
Sent: May 6, 2004 4:27 PM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: [STDS-802-16] Comment 112

Guys,
 
        I would have a small observation on the comment number #112 . Although I assume that you guys had a technical review of all these comments I should point out some details.
Comment # 112 proposes a method of errored PDU's recovery in case of errored PDU header. In this particular situation as you loose the length information if no specific recovery is done  all PDU's contained in a burst can be lost.
The problem is that aside of introducing a new optional mode that is changing the frame (burst) structure ,it does not add value on the technical side for few reasons:
 
1. There are methods for next header recovery that are widely used in ATM for instance, without any OVERHEAD addition and structure change. Some fields in the header have some possible patterns which any correlator can identify .Starting  from there, any simple HW machine can position on the header 'candidate' .When the header candidate is localized the simplest thing is to check the CRC at the end of it. If it matches that means the header is identified. The probability for mistake is almost null.
There are two conditions that have to be met:
    - the pattern
    - CRC on the candidate header sequence  
This algorithm does not require any change ,any overhead and any option.
 
2. The method presented in the contribution is not good  , aside added overhead and special framing. These pointers present in the sequence are exposed to errors as much as any bit in the burst. Then probability of that pointer being errored is the same. That errored pointer does not have any protection and any indication that is errored or not. Based on that you can get in a worse situation ... The only probability on this method to work is to be lucky enough in a noisy environment to receive correct pointers. 
 
3. We talked about this item in the last Orlando meeting and as I remember was rejected on technical ground. I replied to the comment in recirculation but I did not get any feedback .    
 
Cheers,
Radu.       


IMPORTANT NOTICE: This message is intended only for the use of the individual or entity to which it is addressed. The message may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify Redline immediately by email at
postmaster@redlinecommunications.com.

Thank you.