| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Kapoor, Michael, Jheroen, and All,
Regarding the impact of channel quality, the requirement does refer to the RF section where the channel quality conditions will be specified. The intent is to have a FER threshold for a defined channel condition and a defined channel coding/modulation scheme. Obviously, if you change the channel state, you change the FER; if you change the <Eb/No>, you change the FER.
Just to reiterate previous comments, we need to establish a common performance level so that vendors and service providors have baseline data for network planning. Given a baseline FER performance, the service provider can then design the network for the type of services offered, the quality of services, and the types of channel conditions. I suggest that attempts to cover all possible applications and deployment conditions in a system specification or standard is unnecessary.
Maybe we do not need a FER requirement. But if we do, I strongly recommend that it state a target FER value for specific and settable conditions (channel, modulation, coding) that can be measured.
As Jim Mollenauer suggested, can we keep the requirements "simple"?
Joseph Cleveland
-----Original Message-----
From: Kapoor Samir [mailto:S.Kapoor@flarion.com]
Sent: Wednesday, July 30, 2003 9:31 PM
To: 'Michael Youssefmir'; Joseph Cleveland
Cc: 'Dorenbosch Jheroen-FJD007'; stds-80220-requirements@ieee.org
Subject: RE: stds-80220-requirements: Frame Error Rate Requirement
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
-----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
>