Re: stds-80220-requirements: Frame Error Rate Requirement
Joseph et al,
Let's try to wrap up this discussion. I believe that the majority
consensus is to not quote a specific error rate (be they packet
errors or frame errors) in the requirements document.
The current text reads:
Section 4.1.10
The physical layer shall be capable of adapting the modulation, coding, and power levels to accommodate RF signal deterioration between the BS and user terminals. The air interface shall use appropriate ARQ schemes to ensure that error rates are reduced to a suitably low levels in order to accommodate higher level IP based protocols (for example, TCP over IP). The packet error rate for 512 byte IP packet shall be less that 1 percent after error correction and before ARQ.
Change:
Delete the last sentence.
Rationale: Various (see requirements document ver 7). Basically, the existing
text without the last sentence captures what is needed of the air interface.
The evaluation criteria group will have to decide how they wish to
handle the interaction of ARQ and FERs in their evaluation in order to
"reduce error rates to suitably low levels".
Mike
On Fri, Sep 05, 2003 at 03:53:05PM +0900, ì?¥ì§?ì?? wrote:
> MessageDear 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 -----
> From: Dave James (OAK)
> To: 'Joanne Wilson' ; 'Joseph Cleveland' ; 'Heesoo Lee' ; stds-80220-requirements@ieee.org
> 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.
> -----Original Message-----
> From: owner-stds-80220-requirements@majordomo.ieee.org [mailto:owner-stds-80220-requirements@majordomo.ieee.org] On Behalf Of Joanne Wilson
> Sent: Thursday, September 04, 2003 3:43 PM
> To: Joseph Cleveland; 'Heesoo Lee'; stds-80220-requirements@ieee.org
> Subject: RE: stds-80220-requirements: Frame Error Rate Requirement
>
>
> 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
> -----Original Message-----
> From: owner-stds-80220-requirements@majordomo.ieee.org [mailto:owner-stds-80220-requirements@majordomo.ieee.org]On Behalf Of Joseph Cleveland
> Sent: Thursday, September 04, 2003 10:16 AM
> To: 'Heesoo Lee'; stds-80220-requirements@ieee.org
> Subject: RE: stds-80220-requirements: Frame Error Rate Requirement
>
>
> 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
> -----Original Message-----
> From: Heesoo Lee [mailto:heelee@etri.re.kr]
> Sent: Thursday, September 04, 2003 3:01 AM
> To: stds-80220-requirements@ieee.org
> Subject: Re: stds-80220-requirements: Frame Error Rate Requirement
>
>
> 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 -----
> From: Jim Tomcik
> To: Kapoor Samir
> Cc: 'Michael Youssefmir' ; Joseph Cleveland ; 'Dorenbosch Jheroen-FJD007' ; stds-80220-requirements@ieee.org
> 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
> .................................................................................