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

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