|
Dear Joseph and all colleagues,
I agree with Josheph in that we do not remove
requirement statements for frame error rate.
But I also support that we do not specify a specific
value for FER.
Best regards, Jin
----- Original Message -----
Sent: Friday, September 05, 2003 5:24
AM
Subject: RE: stds-80220-requirements: Frame
Error Rate Requirement
Joanne et al:
I agree with this last
post (Joanne's)
I think Jim's
suggested statement is a decent interim approach.
To pick up Joseph's
remark. Re last sentence: one can also have the obverse case, too:
a design requirement or a target (better term) but still not demand a specific
evaluation because (for instance) one cannot agree on a v tricky evaluation or
test approach - I speak in general terms. This often happens
in military work e.g. one may not desire EMP testing or other notional
evaluation, but one still has a design requirement that is deadly
serious.
BUT in this context we
are talking of the proposal for a specific FER value/set for the widest set of
(undefined) scenarios and which is dependent on the AI. . It is not that one
could not imagine how to evaluate, but it doesn't seem to make sense to
arbitrarily bias it all in one direction needlessly. There are so many
widely different user situations, as mentioned by others. The FER cannot
- just taking the end user's needs into account, regardless of AI, technology
used - be separately defined at this stage, it is part of a set of
trade-offs related to offered traffic types and
needs..
I agree with Joanne's
last sentence that refers to Heesoo's recommendation. One might consider
re-evaluation of this at a later stage - but I'd take some convincing
..
I concur with Mike' s
request to remove the sentence that was there (see his last half dozen or
so lines)
Regards,
Dave
James
OAK Global
B.V.
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 .................................................................................
|