Re: [STDS-802-16] [PREAMBLE] Aug 2 Preamble Ad-Hoc group telecon ferenc

Alvarion; Arraycomm; Beceem; ETRI; Hanaro Telecom; Intel; KT; LGE; Motorola; Nextel; Nortel; TI; Proxim; Qualcomm; Runcom; SOLiD Technologies; Samsung; Sprint; ZTE

I may miss few companies joined at a later time. Please note that for the next CC, I will open the bridge 10 minutes before the scheduled meeting so that people can dial in and we can start the meeting on time.

1. Discussion on comments related to requirement document from the last CC

Make it clear that one OFDM symbol preamble is preferable

Operation mode identification is not agreed requirement from the last CC

Yossi's Email comments, I attached his Email here for your convenience

There was a long debate over whether we need to enhance the current preamble design for FFT size other than 2k. Both Zion and Yossi from Runcom explained the current preamble design and stated that the current preamble works well for both fixed and mobile case. There is no need to improve the design for mobility. Some other companies expressed different views on these issues. Some of these difference may come from the different assumptions.

Actions:

Peiying will make sure that the first two points are clearly stated in the requirement document.
Runcom to submit a contribution explaining how the current design works in multi-cell mobility environment so that everyone has the same basic understanding of design intention and have more time to think over the issues offline.

2. Review of contributions related to preamble structure design

In general, the contributions are classified into two categories: structure vs. sequence design. I updated the spreadsheet to indicate the category for each contribution, please see the document http://wirelessman.dyndns.org/cgi-script/CSUpload//upload/temp%252edb/preamble_Adhoc_Conntribution_list_2.xls.

We had some difficult to hear the presentation from LGE. Please review it offline and send your comments/questions.

Due to the time limitation, we were not able to review the contributions related to sequence design. Jeff from Motorola is doing simulation to comparing different sequences, there is a suggest to take consideration of implementation impairments such as timing and frequency offset for comparison. Jeff will share the results with everyone.

Actions: Everyone

Start offline Email discussion on the contributions. For the contribution presenters, please provide answers to the questions/issues raised if you have not answered it during the meeting.

Review the contributions related to sequence design

Discuss the possible harmonization among the contributions through Email, we need to reduce the number of contributions by the next CC.

Do you feel that we should set up a smaller Email distribution list to discuss the technical details so not to floor the reflector? Please let me know your view.

3. Next conference call:

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

The conference bridge is:

1+(613)7650160
Pass code: 3958089#

Please remember to dial # after the pass code.

Regards,

Peiying

-----Original Message-----
From: Zhu, Peiying [CAR:DP13:EXCH]
Sent: Monday, August 02, 2004 11:15 AM
To: Zhu, Peiying [CAR:DP13:EXCH]; 'STDS-802-16@listserv.ieee.org'
Subject: RE: [STDS-802-16] [PREAMBLE] Aug 2 Preamble Ad-Hoc group teleconference reminder

Dear All:

This is a reminder for tomorrow's conference call. I have not received any comments on the proposal extending the call duration. Tentatively, I put a 2-hour call here.

Tuesday, Aug 3 --- 7:00-9:00 am USA pacific time, 11 pm for Seoul, 5 pm for TelAviv, 10 am for Ottawa

The conference bridge is:

(613)7650160
Pass code: 3958089

Proposed Agenda:

1. Review contributions

2. Discuss possible harmonization

Regards,

Peiying

PS: Please upload new contributions before 9:00pm Aug. 2 US pacific time.

There is a contribution from Beceem suggesting to include an evaluation table in each contribution to facilitate the discussion. Please take a look.

http://wirelessman.dyndns.org/cgi-script/CSUpload//upload/temp%252edb/merits_table.pdf

To: STDS-802-16@listserv.ieee.org
Subject: [STDS-802-16] [PREAMBLE] - Comments on requirements
From: Yossi Segal <yossis@RUNCOM.CO.IL>
Date: Tue, 3 Aug 2004 06:26:38 -0400
Reply-To: yossis@RUNCOM.CO.IL
Sender: owner-stds-802-16@listserv.ieee.org

Title: [STDS-802-16] [PREAMBLE] - Comments on requirements

Hi all Preamble folks,

I would like to have some discussion on the requirements before the CC due
to the limited
time of the CC and the problem of on line interaction in a such large group.

I have a few comments on some of the requirements:
1) I do not see any reason why we should focus on simulations on the
proposed BW and FFT sizes, as
they will be almost the same (defining the same CS), this does not relates
to the large possibilities
of the BW/FFT size we already defined, as well as being relevant to only the
synchronization (maybe
tracking) and the estimation for the first 1/2 symbols.
2) I do not see the relevancy of the preamble to the MIMO modes as the first
symbols always start with
the PUSC transmission for all the users (especially the non STC/MIMO ones).
As we already agreed that
the preamble will hold for 1/2 symbols (for estimation) it has no relevancy
to the MIMO modes.
3) Complexity should be clarified, I guess people have in mind that some
preamble form in the time
domain has some correlation properties, which they claim exceeds the current
preamble (let us put it on the table),
the 1:2 preamble format (every second carrier modulated). I would like to
comment on the issue:
- In no way this is inherited from the 16d draft (out of scope I believe,
unless the mechanism is broken). From my perspective,
   "scaled down" as defined in the PAR, means that the 2K FFT is the basic
structure, and all other FFTs should be
   scaled down from it, meaning taking the basic building block.
- using time correlation properties to achieve frequency accuracy is, at
best, incorrect. We have to consider
   the fact that in a mobile/multi-cell environment the preambles from
several BS's will be received by the user
   and the correlation will give a weighted some of all the received
preambles (which will have no meaning as
   it will include different delays and different frequencies due to
movement in different directions - towards the BS's).
   Therefore one can not relay on this mechanism to achieve anything
(maximum a correlation value indicating
   there is some reception from somewhere).
- Time locking on the preamble is also not accurate, due to the fact that
you will lock in time on the same weighted preambles
results which will not give you any information at best (and when trying
to stay locked on a specific BS which is
received poorly compared to other BS's - like in HO - the mechanism will
by default lock you to the one you do not want).
4) Overhead - I see no reason of using more then 1 preamble, as the
throughput punishment is severe.
5) Multi-Mode - I don't see how these new feature relates to mobility in any
way, and the fact that we already have
    mechanism to switch between zones in the current definitions.

Best Regards,

Yossi Segal
yossis@runcom.co.il
CTO, Runcom Technologies LTD.
Broadband Wireless Technologies DVB-RCT, IEEE802.16
http://www.runcom.co.il/
Tel: 972-3-9528440 ext. 106 Fax: 972-3-9528805
2 Hachoma St. 75655, Rishon Lezion, Israel