|
Dear Mr. Junyi Li , Mis. Mariana Goldhammer, and
other colleagues,
Let me clarify my estimation on ARQ loop
delay.
I had no intention to make an exact
evaluation of ARQ loop delay from the start
because it is highly dependent on many
assumptions.
(I can not make an exact esitmation without a
complete physical spec.^^)
The following is an explanation of my clumsy
evaluation:
According to the ARQ loop delay definition in the
current req. document,
it is
"the duration from when a data frame is received by
the physical layer
of the transmitter to the time when an acknowledgeent
for that frame is
received by the transmitting
station."
That is, for instance, if we use
interleaving technique on the transmitter side
the whole duration of a physical frame should be
included into the TX time.
The TX time should include all processing times
needed for physical operations
such as channel coding, rate matching, etc in
addition to that for interleaving.
And then the real transmission of a physical frame
can be made.
I think one frame time is the minimum for TX time
if my understanding of
the definition is correct.
I would like to point out serveral additional
assumtions.
1. Regaring processing time for acknowledgement on
the RX side
I did not count it
for the whole 4 frame time of ARQ loop delay.
I did ignore the processing
time for deinterleaving that is quite long as you
know.
2. I do not assume 'Multi-channel'
HARQ scheme.
If we use multi-channel HARQ
scheme, the time for delivering ACK/NACK info
requires serveral times of a
frame depending on the number of channels.
-> In the previous systems
that use a short frame, they mostly use N-channel HARQ
and the
multi-channel delay should be additionally considered.
3. I assume ACK/NACK information is transffered in
a physical frame.
As you know the 'ARQ loop delay' is highly
dependent on physical designs
and a lot of physical parameters.
That is why I proposed to remove the limitation of
10 ms.
Best regards,
Jin
----- Original Message -----
Sent: Friday, October 31, 2003 2:08 AM
Subject: RE: stds-80220-requirements: 4.1.9
Latency- ARQ loop delay
Li,
1. Probably
3 frames will be needed for most of implementations
2. For
systems targeting SDMA, the MAC frame will be longer than
3-4ms.
2. For
VoIP, not necessarely one needs retransmissions, the codecs are tolerant
to packet losses.
Regards,
Marianna
Jin,
I am a little
puzzled by your estimation. Note that when a physical frame is transmitted,
it is also received at the same time. Unless the receiver has to take the
entire time duration of a physical frame to finish the decoding after the
frame has been received, the ARQ loop delay seems to be dominated by the two
TX physical frames, not four.
In addition, the
use of small frame size is not uncommon in other technologies. For example,
in HDR, the slot time is 1.66ms. Voice traffic often has delay constraint of
20 or 40 ms. Considering the scheduling jitter and retransmission
requirement, 10 ms ARQ loop delay does not seem to be terribly
small.
Regards,
Junyi
-----Original
Message-----
From: Marianna
Goldhammer [mailto:marianna.goldhammer@alvarion.com]
Sent: Thursday, October
30, 2003 8:05
AM
To: Jin-Weon Chang;
stds-80220-requirements@ieee.org
Subject: RE: stds-80220-requirements:
4.1.9 Latency- ARQ loop delay
I
agree with your comments.
In my
understanding, video teleconf needs the lowest delay, I
guess
that 40-50ms
for ARQ loop delay should be enough.
-----Original
Message-----
From:
Jin-Weon Chang [mailto:jwchang1@samsung.com]
Sent: Thursday, October 30, 2003 4:16
AM
To:
stds-80220-requirements@ieee.org
Subject: stds-80220-requirements:
4.1.9 Latency- ARQ loop delay
In the section 4.1.8 Latency "ARQ
loop delay" is required to be less than 10ms.
If I understand the ARQ loop delay
correctly, it includes
- TX time of a physical
frame,
- Propagation time over the
air,
- RX time of a physical
frame,
- Processing time for
acknowledgement,
- TX time of a ACK/NACK frame,
- Propagation time over the air,
and
- RX time of an ACK/NACK
frame.
ARQ loop delay includes 4 times of
physical frame
if we assume ACK/NACK information is
transffered in a physical frame.
Limiting the delay within 10ms
results in limiting the size of a physical frame
This requirement will
highly restrict physical design of
MBWA.
I think the size of a physical frame
should be determined
considering not only delay factor but
also many other factors.
Thus I would like to propose that
10ms requirement in ARQ loop delay be removed.
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.
************************************************************************************
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.
************************************************************************************
|