|
Hi
Heesoo et. al.
I
disagree with the concept of removing a requirement then conducting an
evaluation of an unspecified performance number. That is, if there is
no requirement, there is no evaluation to be done.
Joseph
Cleveland
Hi all,
I agree on Mike, Samir and Jim's point that there
are many different types of traffic we're attempting to serve with this
technology, and different applications require different FER vs Latency
tradeoffs.
The proper or optimized FER for each application is closely
related to RTT, that is, depends on the maximum number of retransmissions
within the delay bound for the application. However, RTT or the maximum number
of retransmissions within the delay bound is a specific AI design issue which
is certainly outside the scope of the requirements document.
As a result,
I also suggest that we should remove the specific FER value in requirements
document, and leave the optimization of proper FER to the evaluation
process.
Best Regards,
Heesoo Lee
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Heesoo Lee, Ph.D.
Senior Member of Research
Staff
ETRI (Electronics and
Telecommunications Research Institute)
Taejon, KOREA
Tel: +82-42-860-5375
E-mail: heelee@etri.re.kr
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
----- Original Message -----
Sent: Saturday, August 02, 2003 6:45
AM
Subject: RE: stds-80220-requirements:
Frame Error Rate Requirement
At 10:30 PM 7/30/2003 -0400, Kapoor Samir wrote:
Just to add to Mike's, and
others before, point about the difficulty in
specifying a particular
FER threshold. In addition to different applications
having different
target FER vs latency tradeoffs, another issue is that the
extent of
uncertainty in channel quality measurements (e.g. depending on the
SNR
regime, rate of channel variation etc) can significantly impact
the
transmitter's selection of appropriate transmission (e.g. coding
and
modulation) parameters and corresponding FER targets under
different
conditions. Consequently, it is probably best to not mandate
a single FER
threshold.
Samir, Michael, Joseph, and
others...
Samir makes a good point here about the fact that different
applications require different FER vs Latency tradeoffs. There are
many different types of traffic we're attempting to serve with this
technology. We've learned this in the CDMA data world too, and as a
result, our radio link protocols are now designed to support negotiating a
range of error/data loss characteristics from that of the raw airlink
(for apps that can support frame loss but not much latency) through that
roughly equivalent to a wireline (for the purposes of TCP retransmission
performance).
Maybe my original comment (from an e-mail 7/16/2003
which wasn't addressed by the group) may help. PThe comment suggests a
requirement to support a range of error vs. latency tradeoffs. These
could be negotiable upon channel setup, if information about the traffic
type is available. Suggest some text such as this:
The Air Interface (PHY+MAC) shall include mechanisms to allow
negotiating a range of latency vs. data loss/error rates subject to
application types.
Best Regards,
Jim
Samir
-----Original Message-----
From: Michael Youssefmir [mailto:mike@arraycomm.com]
Sent: Wednesday, July
30, 2003 8:14 PM
To: Joseph Cleveland
Cc: 'Dorenbosch
Jheroen-FJD007'; stds-80220-requirements@ieee.org;
Michael
Youssefmir
Subject: Re: stds-80220-requirements: Frame Error Rate
Requirement
Hi Joseph,
I see that this
discussion is moving into specific design requirements
such as frame
length instead of addressing functional requirements.
1) An FER
requirement seems to be irrelevant absent the specifics of
the design
and would have different performance implications for
different
designs. As Jheroen pointed out a specific requirement
such as 1%
will bias the requirement to shorter frames, and, as your
response
indicates we rapidly have to go down the path of specifying
frame
lengths to make the requirement have meaning. I think we are
far better
off having the requirements document focus on high level
functional
requirements and not specify specifics such as frame length.
2) As
Jinweon pointed out tuning of FERs has performance
implications in
trading off throughput and latency. For latency
insensitive data, the
"FER can be less strict in order to maximize
throughput over the air",
and for other data, the "FER needs to be
tightly controlled below a
certain threshold". Again I therefore
think it is premature to define a
specific FER.
For these reasons, I continue to believe that we
should remove
the specific FER value and therefore delete the
sentence:
"The frame error rate shall be less than 1 percent, with
95% confidence,
after channel decoding and before any link-level ARQ,
measured under
conditions specified in Section
xx."
Mike
ArrayComm, Inc.
On Tue, Jul 29, 2003 at
04:58:15PM -0500, Joseph Cleveland wrote:
> Hi All -- Yes, we need a
frame length. This is why I asked what MAC layer
> "RLP" we
intend to use.
>
> Joseph Cleveland
>
>
-----Original Message-----
> From: Dorenbosch Jheroen-FJD007 [mailto:J.Dorenbosch@motorola.com]
> Sent:
Tuesday, July 29, 2003 3:31 PM
> To:
stds-80220-requirements@ieee.org
> Subject: RE:
stds-80220-requirements: Frame Error Rate Requirement
>
>
> We seem to be converging.
>
> However, will
it not be hard to specify a maximum error rate for a frame
> unless
we have an idea of the length of the frame or of the number
of
useful
> bits in a frame? A generic requirement could bias
towards short frames.
>
>
> Jheroen Dorenbosch
>
> -----Original Message-----
> From: Joseph
Cleveland [mailto:JClevela@sta.samsung.com]
> Sent:
Tuesday, July 29, 2003 1:40 PM
> To:
stds-80220-requirements@ieee.org
> Subject: stds-80220-requirements:
FW: Frame Error Rate Requirement, 4.1.10
>
>
>
> Hi All: It seems that some are referring to a previous
re-write of
4.1.10,
> Frame Error Rate. Several of the
items noted were already addressed in
the
> latest version sent
on 7/24, which is attached below. Please refer to the
>
content in v0.2.1 so there is not wasted discussion.
>
>
Regards
>
> Joseph Cleveland
>
>
-----Original Message-----
> From: Joseph
Cleveland
> Sent: Thursday, July 24, 2003 12:44
PM
> To: stds-80220-requirements@ieee.org
> Subject: Frame Error
Rate Requirement, 4.1.10
>
> Hi All,
>
> Here
is a revision to the wording on section 4.1.10 based on feedback
from
> many of you. Thanks for the comments.
> <<frame_error_v0.2.1.rtf>>
>
Joseph Cleveland
> Director, Systems & Standards
>
Wireless Systems Lab
> Samsung Telecommunications America
>
Richardson, TX 75081
> (O) 972-761-7981 (M)
214-336-8446 (F) 972-761-7909
>
..................................................................................
James
D. Tomcik
QUALCOMM,
Incorporated
(858)
658-3231 (Voice)
(619)
890-9537 (Cellular)
From:
San Diego, CA
PGP:
5D0F 93A6 E99D 39D8 B024 0A9B 6361 ACE9 202C
C780 ..................................................................................
|