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

Re: [STDS-802-16] [PREAMBLE] Aug 13 Preamble Ad-Hoc group CC sum mary

Title: Message
Dear Wen
Thank you for your response. The way I see it (and I have heard Peying mentioning it in the CC tonight) that the 1024/512/128 FTT modes should be a scaled down version of the 2048 mode, namely, we cannot, under the 802.16e PAR, add any mandatory features to any of the modes, but only an optional one. And if we do, it better be a solution to a real problem, which I am still not convinced it is.
 
Best Regards
Avi
----- Original Message -----
From: Wen Tong
Sent: Monday, August 16, 2004 7:30 AM
Subject: Re: [STDS-802-16] [PREAMBLE] Aug 13 Preamble Ad-Hoc group CC sum mary

Dear Avi
 
Thanks for raising the issue. We need to clarify this. It should be understood as the SYNC symbol is mandatory transmitted for BS with 1024/512/128 FTT modes (optional for 2048 FFT mode). Hope this is more accurate.
 
Regards
Wen
-----Original Message-----
From: Avi Freedman [mailto:avif@HEXAGONLTD.COM]
Sent: Sunday, August 15, 2004 3:51 PM
To: STDS-802-16@listserv.ieee.org
Subject: Re: [STDS-802-16] [PREAMBLE] Aug 13 Preamble Ad-Hoc group CC sum mary

Dear All,
I joined your interesting discussion on Friday, and I was glad to hear that most of the participants agreed to keep  the existing preamble to maintain backward compatibility. Backward compatibilty is a major comitment towards all those using and implementing 802.16 systems and comprimising it will, in my opinion jeopardize the group credibility and the acceptance of the standard in the future
In view of that, I understand that the sentence "This Sync symbol shall be transmitted mandatory by BS"  does not mean that 802.16-2004 fixed systems are obligated to use this sync symbol, or even 802.16e systems that support fixed SS's have to transmit it.  It is mandatory only for those BS's which use this option
I would also like to quote the (new) PAR:
'there shall be no changes or additions to the mandatory features and backward compatibility shall be maintained"
So please clarify this point before the whole preamble  efforts whould be ruled out of the scope of the PAR.
 
Avi Freedman
Hexagon System Engineering
----- Original Message -----
Sent: Saturday, August 14, 2004 2:41 AM
Subject: Re: [STDS-802-16] [PREAMBLE] Aug 13 Preamble Ad-Hoc group CC sum mary

Dear All:
 
Thank you for attending the CC. Here is the summary for today's CC.

Attendees: due to a larger number of participants, I only captured the company names here. 

Adacom, Alvarion; Beceem; Broadband Mobile Technologies; ETRI; Hanaro Telecom; Hexagon; Intel; KT; LGE; Motorola; Nortel; TI; Proxim; Qualcomm; Runcom; SOLiD Technologies; Samsung; Sprint; ZTE

We discussed the following items:

1. The joint draft proposal: Preamble_adhoc_structure_v0.1.doc

There was a long discussion over the proposal, which proved to be very useful. It is not clear that we have reached a consensus, however only members from Samsung have not agreed with the proposal. The agreement is that we will not change the existing preamble structure in order to maintain backward compatibility, but introduce a Sync symbol (or postamble) which has a time domain repetition structure. The Sync symbol is transmitted in certain interval (the exact interval is to be defined). There are several different opinions on the location of the Sync symbol, the exact location is to be defined. This Sync symbol shall be transmitted mandatory by BS, but it is optional for MSS. It is up to MSS to decide whether it wants to take advantage of this Sync symbol.  The actual sequence design depends on the outcome of sequence design harmonization. It shall use whichever sequences chosen for the existing preamble design, possible different lengths.

Raja proposed another revision based on this proposal to add group ID in additional to the common Sync sequence.

Wen Tong will work with others to provide a revision to reflect today's CC agreement. Samsung agreed to review the revision. The document combining with the consensus on sequence design will be used as the first draft for Aug. 17 comment submission.

2. Sequence harmonization status

We discussed how to evaluate the sequences. The following are the criteria suggested: low PAPR, low cross-correlation, complexity, consistency with the existing preamble sequence. The simulation will use the existing preamble structure.

Jeff Zhuang agreed to work with others to generate performance matrices for proposed sequences before Monday CC. It is agreed to continue offline Email discussion. We need to work hard on this to reach a consensus by Monday night.

3. Comment on "reference signaling" from LGE

Bin-Chul Ihm presented the proposal on "reference signal", several members objected to use guard band for any other purpose. There was no support for this proposal. Bin-Chul Ihm will do further explanation to seek support before Aug. 17. 

4. Next CC

We agreed to add another CC to discuss sequence design.

Monday, Aug 16 --- 20:00-22:00 USA pacific time, 12:00 for Seoul, 6:00 for TelAviv, 23:00 for Ottawa

The conference bridge is:

1+(613)7650160
Pass code: 3958089#

Regards,

Peiying

 -----Original Message-----
From: Zhu, Peiying [CAR:DP13:EXCH]
Sent: Friday, August 13, 2004 7:47 AM
To: Zhu, Peiying [CAR:DP13:EXCH]; STDS-802-16@LISTSERV.IEEE.ORG
Subject: RE: [STDS-802-16] [PREAMBLE] Aug 13 Preamble Ad-Hoc group CC agenda

Dear All:
 
Here is the proposed agenda for today's CC:
 
 
2. Discuss the sequence harmonization status
 
3. Comment on "reference signaling" from LGE
 
Please let me know if you have suggestions on Agenda.
 
=============================================================================
 
Friday, Aug  13    ---  7:00-9:00 am USA pacific time, 11 pm for Seoul, 5 pm for TelAviv, 10 am for Ottawa

The conference bridge is:

1+ (613)7650160
Pass code: 3958089 #

Regards,
 
Peiying