Hello, All
Jim's text "The
Air Interface (PHY+MAC) shall include mechanisms to allow negotiating a range
of latency vs. data loss/error rates subject to application types." seems
close to ideal. The only possible change could be
"control"
instead of "negotiation" (which is
a particular type of control; e.g. configuration is another
type).
Argumentation for having DiffServ
[or another specific mechanism of QoS control] seems not sufficient.
We have to differentiate
between "IP-centric" and "IP-aware". There seems to be a wide consensus
about "IP-centric"
meaning MAC/PHY optimized for
transferring traffic with characteristics similar to those we
used
to see in IP traffic [bursty
nature, nIPP models, ... etc.]. "IP-awareness" would mean that virtually every
802.20 device
should operate as IP host with functions like DiffServ
[or IntServ or RSVP or MPLS, ... endless list]. I don't
think,
IP-awarness would gain serious
support - business of IEEE 802 wireless is MAC/PHY. We may learn from another
groups and concentrate on MAC/PHY with possible addition of
classification of non-802.20 data units (Ethernet packets, IP
datagrams etc.). Classifier looks at certain fields of IP datagram, for
example, at TOS field, and decides whether certain MAC/PHY rule
[e.g. lower delay with less restrictions on FER] is applicable to the
datagram.
Such approach does not preclude
from further development of complimentary standard that may point e.g. to
DiffServ
as a recommended QoS control
protocol; but such a standard should be separated from MAC/PHY
specifications.
Example of
complimentary standard: PacketCable [for DOCSIS MAC/PHY]
Vladimir
I
agree that the MAC/PHY must be able to handle various application
requirements in terms of data loss/error rates etc in a flexible manner.
However, given the IP-centric nature of system, it might be better for
application QoS requirements such as these to be framed in a more
unified and comprehensive manner through use of the diffserv
architecture (for which there seems to be broad support in the
group).
Samir
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
..................................................................................
This mail passed through
mail.alvarion.com
************************************************************************************
This
footnote confirms that this email message has been scanned by
PineApp
Mail-SeCure for the presence of malicious code, vandals & computer
viruses.
************************************************************************************
This
mail was sent via
mail.alvarion.com
************************************************************************************
This
footnote confirms that this email message has been scanned by
PineApp
Mail-SeCure for the presence of malicious code, vandals & computer
viruses.
************************************************************************************