|
Joseph,
I have
to agree with Mike, Samir, Jim and Heesoo. For FER to be an appropriate
requirement, it
would
have to be visible and meaningful to the end user. My take
from Heesoo's message is that,
and I believe this is also the point
Mike, Samir and Jim have been trying to make, the impact of
a
specific FER at the application level (which is what
end users see) will vary with the AI design.
From
my perspective, I don't see how we could establish an FER requirement that is
independent
of the
AI design. For example, we don't know either the length, structure or
payload of the frames
for
which we'd be setting a FER requirement? Certainly, all of the those are
outside of the scope
of the
Requirements Document. As Heesoo recommends, I prefer to have the
evaluation group
consider whether and, if so, how to address
optimization of the FER in the context of the specific
AI
proposals under evaluation.
Best
regards,
Joanne
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 ..................................................................................
|