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.
************************************************************************************