Re: RE: stds-80220-requirements: Spectral Efficiency (4.1.2)
Who is Yournet ? Also message seems curtailed so am usure what
the total thrust was supposed to be here ....
Dave James
----- Original Message -----
From: "Yournet@hotmail.com" <yournet@hotmail.com>
To: <djames@oak-global.com>
Sent: Tuesday, December 02, 2003 4:58 PM
Subject: Re: RE: stds-80220-requirements: Spectral Efficiency
(4.1.2)
| The mandate for 802.20 is high speed isn't it? Your statement
"To a great
| extent
| markets are there today for what I refer to as ADSL/cable
untethered . . ."
| is a good observation. But rather than try to make a sows ear
into a purse,
| why not pursue the broad market agenda within a standard that
has a broad
| mandate and appropriately written PAR?
|
|
| If that is a contrary purpose to what now appears to be the
broadened
| mandate, namely universal, cellular coverage, or
| ----- Original Message -----
| From: "Dave James (OAK Global)" <djames@oak-global.com>
| To: "'Humbert, John J [NTWK SVCS]'"
<JHumbe01@sprintspectrum.com>;
| "'Requirements Reflector'" <stds-80220-requirements@ieee.org>
| Sent: Monday, December 01, 2003 10:08 PM
| Subject: RE: RE: stds-80220-requirements: Spectral Efficiency
(4.1.2)
|
|
| John et al:
|
| A few points that relate to the market needs, the Requirements
that are
| linked to this:
|
| - I have consistently held the view that the issue of high
physical speed is
| over-cooked here, reflected to some extent in the PAR, I have
to say. It is
| not that it is totally needless to accommodate speeds like 180
kph, it is
| the weighting that we ascribe that concerns me .
|
| - like the offered traffic, the speeds in practice are
distributed over a
| fair range. But IMHO the speeds are generally skewed markedly
for target
| markets to ambulant + modest vehicular speeds. In fact in many
cases the
| user is essentially nomadic e.g. usage is often FWA - like but
with
| advantage as per RLANs of no antenna directionality - and using
appropriate
| technology thriving in a high-multipath etc., non LoS
environments i.e.
| anywhere....
|
| We can all think of special cases, but I think we should be
careful about
| excess bias placed on higher physical speeds. As I mentioned at
ABQ mtg.,
| WAN + LAN makes a great combination looking ahead (.11 + .20)
with suitable
| handover featured, but that does NOT mean that our .20 design
should be
| compromised in its primary characteristics by skewing the
overall AI
| approach to pander too much to high physical speeds. To a
great extent
| markets are there today for what I refer to as ADSL/cable
untethered
| (portable) e.g. portable wireless DSL, so to speak (PWDSL) I,e
decent wired
| world experience now made un-wired, and not too much attention
paid to
| comparison with conventional cellular legacy market and design
thinking.
|
| This is another reason I have got so frustrated over all the
pre-occupation
| on mail traffic over the issue of detailed discussion of FDD
extant spectrum
| for PCS. As I mentioned at ABQ, there are plenty of great
applications in a
| number of bands internationally, we seem to endlessly drift
into comparison
| with 3G and detailed usage of PCS bands. We are not
'addressing' 2G, 2.5G,
| 3G here surely.
|
| I take note of your points, but again I see a danger in being
overly
| specific about exactly how to specify UL, DL SE etc under all
conditions and
| situations. Before we know it, we will have a 'camel = horse as
designed by
| committee' syndrome. As we know, too, it is the overall
combination of data
| rates, coverage, capacity and other parameters that is the key
and not just
| one or two in isolation. We can bury ourselves in statistical
simulations
| here, so for example, just to be clear: what constraints are we
suggesting
| for the associated range and say traffic here for item 1) ?
We need simple
| scenarios and sets of criteria. But proposals can surely also
explain in
| due course more of the pros and cons of different arrangements
and feature
| sets We surely don't mean such SEs as computed at the highest
range and
| worst traffic mix and worst channel conditions and extremas
for X ...and
| for Y..., true ?
|
| BR, Dave
|
| > -----Original Message-----
| > From: Humbert, John J [NTWK SVCS]
| > [mailto:owner-stds-80220-requirements@majordomo.ieee.org] On
Behalf Of
| > Humbert, John J [NTWK SVCS]
| > Sent: 01 December 2003 21:01
| > To: Requirements Reflector
| > Subject: RE: stds-80220-requirements: Spectral Efficiency
(4.1.2)
| >
| > Below is a proposal that addresses the remaining issues from
the plenary
| > meeting:
| >
| > 1) Set the target values to
| > Downlink: 2 bits/Hz/sector at 3 km/hr
| > Uplink: 1 bits/Hz/sector at 3 km/hr
| >
| > Downlink: 1 bits/Hz/sector at 180 km/hr
| > Uplink: 0.5 bits/Hz/sector at 180
km/hr
| >
| > Rational
| > 1) The requirements for UL and DL data rates are not
| > the same and it is assumed that both will use the same system
bandwidth.
| > If the same calculation for SE is applied to both the UL and
the DL the UL
| > will not have the same spectral efficiency as the DL. Also,
if the two
| > are blended together then it is possible for a proposal to
have poor
| > spectral efficiency in one direction masked by very good
spectral
| > efficiency in the other direction.
| > 2) It is necessary to specify the SE at a given speed
| > because the SE depends on the modulation used and the highest
order
| > modulation that can be transmitted is dependant on the speed
of the mobile
| > 3) Higher target values are needed because the SE
| > degrades in a non-linear fashion, SE should be optimized
across a range of
| > speeds not for a particular speed.
| > 4) The values for the 3 km/hr are set based achieving
| > targets that are significantly better than what can be
achieved by other
| > technologies in the near future. (See the presentation from
plenary)
| >
| >
| > John J. Humbert
| > 6220 Sprint Parkway
| > Mailstop KSOPHD0504 - 5D276
| > Overland Park, KS 66251-6118
| > PCS (816) 210-9611
| >
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.516 / Virus Database: 313 - Release Date: 01/09/03