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

RE: stds-80220-requirements: Section 4.1.2 Spectral Efficiency




John

Actually there is a discrepancy between the text and the slide presentation, the slide presentation states "2 bits/hertz/cell at 3km/hr". That is also what I recall from the conference call. Based on the discussion of 3 sectors per cell (as per the eval reference configuration) being used to derive that number I was willing to go along with that. I definitely would have a problem if the text changes back to per sector basis.

Mark 

-----Original Message-----
From: Humbert, John J [NTWK SVCS] [mailto:JHumbe01@sprintspectrum.com] 
Sent: Thursday, November 06, 2003 12:56 PM
To: Marianna Goldhammer; Michael Youssefmir; stds-80220-requirements@ieee.org
Subject: RE: stds-80220-requirements: Section 4.1.2 Spectral Efficiency


Michael,

For the most part the new proposal does a good job of addressing the
issues raised on the last conference call.  The problem with the new
proposal is in the last section dealing with target values.  

In the last conference call the group agreed on a target value of 2
bits/hertz/sector at 3km/hr. The question on the table was whether or
not there needed to be another target value for a higher speed.

The target values in this section are consistent with the PAR because
the PAR specifies 1 bit/hertz/sector as a minimum value. 

I propose that we stick with the text in the original proposal for this
paragraph:

[Downlink > 2 bps/Hz/sector] @ 3km/hr
[Uplink >1 bps/Hz/sector] @ 3km/hr


 

John J. Humbert
6220 Sprint Parkway
Mailstop KSOPHD0504 - 5D276
Overland Park, KS 66251-6118
PCS (816) 210-9611

-----Original Message-----
From: Marianna Goldhammer [mailto:marianna.goldhammer@alvarion.com] 
Sent: Thursday, November 06, 2003 6:19 AM
To: Michael Youssefmir; Humbert, John J [NTWK SVCS];
stds-80220-requirements@ieee.org
Subject: RE: stds-80220-requirements: Section 4.1.2 Spectral Efficiency

Mike,

Both definitions are a mix of requirement / attempt to define
conditions.

If you look at evaluation methodology used in 3GPP/2, there are tenths
of
 conditions influencing the spectral efficiency, still not addressing
 sector/beam number and frequency planning issue.

I would propose to state in this document only the requirement. Should
 be done a study to see which are the most appropriate deployment
 architectures, for broadband data traffic, NOT limited by using the
existing
 cellular infrastructure (see Dan's e-mails).

And besides, the evaluation criteria should permit creative/advanced
modes
 of improving spectral efficiency. 

Marianna

-----Original Message-----
From: Michael Youssefmir [mailto:mike@arraycomm.com]
Sent: Thursday, November 06, 2003 9:45 AM
To: Humbert, John J [NTWK SVCS]; stds-80220-requirements@ieee.org
Cc: Michael Youssefmir
Subject: stds-80220-requirements: Section 4.1.2 Spectral Efficiency




Folks,

I was on tap for updating the text in this section
to reflect the last requirements call. The general consensus on
the call was to move forward with specifying a definition that
would also lead to a baseline configuration for the evaluation
group. (Please note previous recent text from Dan, Faroukh,
and Samir on this section)

Current text

Sustained spectral efficiency is computed in a loaded multi-cellular
network
setting. It is defined as the ratio of the expected aggregate throughput
(taking out all PHY/MAC overhead) to all users in an interior cell
divided
by the system bandwidth. The sustained spectral efficiency calculation
shall assume that users are distributed uniformly throughout the
network.


[Downlink > 2 bps/Hz/sector]
[Uplink >1 bps/Hz/sector]

Proposed Text

Sustained spectral efficiency is computed in a loaded multi-cellular
network
setting. It is defined as the ratio of the expected aggregate throughput
(taking out all PHY/MAC overhead) to all users in a sector divided
by the system bandwidth (the aggregate spectral allocation in use across
the entire system). The sustained spectral efficiency calculation shall
assume that users are distributed uniformly throughout the network
and shall include a specification of the minimum expected data
rate/user.

A fair comparison of the spectral efficiencies of different air
interfaces
can best be achieved for a single specified baseline configuration.  To
facilitate the subsequent evaluation of different proposals for the
802.20
air interface, the spectral efficiency of the 802.20 air interface shall
be quoted as b/s/Hz/sector for a three sector baseline configuration.
Within this subsequent evaluation, proposals may submit respective
deployment models over and beyond the base configuration.

Consistent with the PAR requirement that is stated on a per cell basis
and
the definitions shown in Appendix A, the sustained spectral efficiency
of
the 802.20 air interface shall be greater than 1 b/s/Hz/sector.

Rationale

This proposal captures the need for a baseline comparison methodology
for ease of evaluating various proposals. By establishing a baseline
three sectored configuration, we also finesse the subtleties in
the per cell or per sector nature of the definition of spectral
efficiency.

[NOTE: The definition of "cell" in Appendix A states, "The term "cell"
refers to  one single-sector base station or to one sector of a base
station deployed with multiple cells."   As such, the PAR requirement of
1 bits/sec/Hz/cell is equivalent to 1 bits/sec/Hz/sector.
The value established in the PAR and by the definition in the
appendix through the definition: "Spectral efficiency: Spectral
efficiency is measured in terms of bits/s/Hz/cell. (In the case
of a sectorized configuration, spectral efficiency is given as
bits/s/Hz/ sector.)"

The current text in the Requirements document -- Version 8c
has:
        downlink > 2 b/s/Hz/sector,  and
        uplink > 1 b/s/Hz/sector

While these values are proposed in the current document. I could
not find any  rationale for them on the list.  The Requirements Group
still needs to agree on target values for spectral efficiency.
]

Mike





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