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