RE: stds-80220-ch-models: Delay-spread limitation
Marianna,
My point was a bit different - i.e. to first come up with channel models
that make sense for the problem at hand (e.g. as per the PAR requirements),
and then the delay profile characterisitcs will follow. Not the other way
round where a max delay cutoff is first assumed and then channel models are
sliced and diced to meet it.
Regards,
Samir
-----Original Message-----
From: Marianna Goldhammer [mailto:marianna.goldhammer@alvarion.com]
Sent: Friday, August 08, 2003 12:56 PM
To: Kapoor Samir; Fred Vook; stds-80220-ch-models@ieee.org
Subject: RE: stds-80220-ch-models: Delay-spread limitation
Samir,
I agree with you in principle.
But when you came to design, and you will want to spend no more
than 10% of the BW for max. delay spread accommodation, you will
(at least for OFDM) go to high FFT sizes. And high FFT sizes:
bring you to phase noise problem (cost)
- you will loose from PHY granularity (capacity)
- increased complexity in resource managing, that will translate also
in lower capacity
- higher degradation with Doppler effect.
So it is better to be focused from the beginning.
Marianna
-----Original Message-----
From: Kapoor Samir [mailto:S.Kapoor@flarion.com]
Sent: Friday, August 08, 2003 7:26 PM
To: Marianna Goldhammer; Fred Vook; stds-80220-ch-models@ieee.org
Subject: RE: stds-80220-ch-models: Delay-spread limitation
Just to revisit the delay spread limitation question, I'm not sure we need
to worry too much about setting an artificial hard and fast limit like 5us
or 10us. As pointed out before, its not just the delay but also the number
of paths, their statistical properties, their relative powers etc that all
count together. So its not clear what specifying such a single value would
buy us? In any case, most systems are able to handle longer delay spreads
with graceful degradation.
Instead, if we try to focus on which particular (well known) channels models
are appropriate for this group (which has to be done regardless) based on
expected mobility, cell size characteristics etc, the delay profile
parameters would naturally fall out of that and side-step this issue.
Samir
-----Original Message-----
From: Marianna Goldhammer [mailto:marianna.goldhammer@alvarion.com]
Sent: Friday, August 08, 2003 11:27 AM
To: Fred Vook; stds-80220-ch-models@ieee.org
Subject: RE: stds-80220-ch-models: Delay-spread limitation
Fred,
I agree that tap 4 has more power, and at beginning, during the
conference call, I proposed to keep it in.
Nevertheless, if Sprint found that apparition probability of this tap
is very low, why to mess the standard development with delays that
describe almost un-existing channels?! And to significantly
increase the equipment cost and complexity?
This channel model is a "selected test environments", not an absolute
channel, and actually Sprint message was: Vehicular B is not a
valid selection!.
We can have a "Call for < 10us delay channel models" or to
shrink (according to a selected model) all the tapes of
Vehicular B, to fit the max. 10us.
I am sure that we will be able to pick more realistic channels
for testing.
Marianna
-----Original Message-----
From: Fred Vook [mailto:vook@labs.mot.com]
Sent: Thursday, August 07, 2003 11:43 PM
To: Marianna Goldhammer; stds-80220-ch-models@ieee.org
Subject: Re: stds-80220-ch-models: Delay-spread limitation
Hi,
I'm not sure I fully understood the discussion which resulted in this
proposed power
delay profile. Could someone please clarify what this proposed power delay
profile
would be used for? (Thanks in advance.)
If the resulting profile is to be used as a starting point for our channel
models, then
I'm not sure this is the right way to proceed. Simply deleting the taps
beyond a
particular delay value would seem to violate the spirit of sticking with
power delay
profiles that were derived based on large amounts of measured data. The
delay and
power values of this particular ITU model were characteristic of the
measured vehicular
channels on which the model was based. Real channels having no taps beyond
10usec would
probably have a different power delay profile than the proposed modified
profile.
Therefore, there really is no scientific basis for using the proposed
truncated profile
as the starting point for our channel models. Deleting taps based on a
relative power
threshold might make (somewhat) more sense to me, but that is obviously not
what's being
done here. (The deleted tap 4 has more power than the retained tap 3.)
On the other hand, if the idea here is to generate the specifics of a delay
spread
requirement for the requirements document, does it make sense to have a
specific power
delay profile for such a requirement (given that our MBWA channel models are
not yet
specified)? Wouldn't it be awkward to have one power delay profile in the
requirements
document (for the delay spread requirement) and a different profile (or set
of profiles)
in the channel modeling document? Isn't there a better way of stating the
requirement
that the MBWA system must operate well in terrestrial delay spread
environments?
Best Regards,
- Fred
--
Fred W. Vook -- Motorola Labs -- Communication Systems Research Laboratory
1301 E. Algonquin Road, IL02-2912, Schaumburg, IL 60196 USA
--
Marianna Goldhammer wrote:
> Hi,
>
> In support of 10us max. delay (Khurram proposal), following the
> discussion in the Channel Models teleconference, here is the
> proposed modification of Vehicular Channel Model B, from ITU-R
> Rec. M-1225, page 28:
>
> - keep tap 1: 0ns, -2.5dB
>
> - keep tap 2: 300ns, 0dB
>
> - keep tap 3: 8 900ns, -12.8dB
>
> - delete tap 4: 12 900ns, -10dB
>
> - delete tap 5: 17 100ns, -25.2dB
>
> - delete tap 6: 20 000ns, -16dB
>
> Kind Regards,
>
> Marianna
>
> Marianna Goldhammer
> Director - Strategic Technologies
>
> Alvarion, Ltd.
> 10 years of wireless expertise
>
> 21 HaBarzel Street
> P.O.Box 13139, Tel Aviv 61131, Israel
> Tel: (972)- 3 -6456241/6262
> Fax: (972) -3 -6456204
>
> Email: marianna.goldhammer@alvarion.com
>
> www.alvarion.com
>
> 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.
>
****************************************************************************
********
This mail passed through 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.
****************************************************************************
********
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.
****************************************************************************
********
This mail passed through 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.
****************************************************************************
********
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.
****************************************************************************
********