Jinweon, Joseph and All,
Few
comments:
1.
Typically there is no 1-1 correspondence between data units at different
layers.
For
example, most MAC protocols do both fragmentation and aggregation of data
units from upper layers. The following terminology is widely used: if
we talk
on
certain layer (e.g. MAC), data units of above layer are called MAC
SDUs
(Service Data Units) while data units of this layer are called MAC
PDUs
(Protocol Data Units)
2.
So a reliability indicator for layer X, it should be provided in the
terms
of
errors encountered at the level of SDUs (service data units of this layer).
For example,
Ethernet MAC layer transfers IP datagrams, then the indicator
should be error ratio
of
IP datagrams [M/N where N - number of transferred datagrams, M - number
of erroneous
datagrams]. number . There is some problem as the error
ratio depends on the datagram
size, but we can normalize to per-1-bit value.
3.
It seems natural to measure reliability of future 802.20 PHY in the terms
of
error rate for MAC PDUs transported by the PHY. The above
comment on normaliztion is applicable.
Probably "frames" mentioned by Jinweon are MAC
PDUs
Such definition naturally addresses error ratio "before ARQ"
[and other MAC operations,
for
example fragmentation/assembly], but "after FEC" (which is a part of
PHY)
4. I
completely share Jinweon's statement on diversity of services that may
result in
diversity of MAC procedures [enabled/disabled ARQ, restricted delivery
delay etc.].
Then
above MAC [e.g. at TCP/IP level] we may have different error ratio with
the same
PHY reliability.
5.
Bottom line: reliability requirements should be first specified for PHY.
Then - separately -
requirements for MAC's error correction capabilities [for example, "MAC
should be able to ensure
MAC
SDUs error ratio not more than X while having PHY SDUs
error ratio = Y" Typicaly there
is a
tradeoff between MAC correction capabilities and system
latency].
Vladimir
Dear Joseph and
colleagues,
Thank you for taking your time to work
for the requirements.
But I still have two concerns on the
current requirement statement of
4.1.10 packet error
rate.
One:
If I understand the desciption
of 4.1.10 subsection correctly,
the mentioned packet errors mean errors
over the air.
In this case, packets from the higher layer are segmented
usually at MAC
(Multiple Access Control) layer into frames in a certain
size
for the efficient transmisson over the radio channel.
The
terminology of Frame Error Rate(FER) would be better than
Packet Error
Rate(PER).
Two:
To my understanding, MBWA
system will support diverse services
of which characteristics can be
very different from viewpoint of
delay and error rate.
We can
consider, for instance, two services of VoIP and data services.
In case
of VoIP service,
FER needs to be tightly controlled below a certain
threshold
and retransmission of frames may not be allowed.
In case of
data service,
FER can be less strict in order to maximize throughput over
the air.
Thus, I would like to propose that the
terminology of "Packet Error Rate" in
subsection 4.1.10 be replaced to
"Frame Error Rate" and
that the last sentence in 4.1.10 ("The packet
error rate for...") be deleted,
which is also proposed by John Fan and
other colleagues in the previous mail.
Best regards,
Jin
---------------------------------------------------------------------------------------
Jin
Weon Chang, Ph. D.
Senior Engineer
Global Standards and Strategy
Team
Samsung Electronics Co., Ltd.
Tel: +82-31-279-5117
Pcs:
+82-16-384-7017
Fax: +82-31-279-5130
jwchang1@samsung.com
-------------------------------------------------------------------------------------------------
----- Original Message -----
Sent: Friday, July 25, 2003 2:44
AM
Subject: stds-80220-requirements: 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
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.
************************************************************************************