Dear Mr. Jin-Weon Chang,
Several folks have already pointed out the
desired need of low ARQ loop times. Below I just wanted to provide a simple
analysis of why I think 10 ms is not terribly constraining.
Consider A sends a data frame to B and B
sends an ack frame back to A. Use your assumption that both data frame and ack
frame are transmitted in a physical frame, whose duration is T.
At time instant 0, A has the data frame
ready. A spends T0 to do the coding, interleaving, etc, so that A starts to
transmit the physical frame at time instant t0+T0. Here T0 represents all the
TX processing time. Thus, the transmission of the physical frame ends at T0+T.
Denote T1 the propagation delay from A to
B. So B receives the physical frame in the time interval of [T0+T1, T0+T+T1]. B
further spends T2 to do the deinterleaving, decoding, etc, so that B determines
whether the physical frame is received correctly at time instant T0+T+T1+T2,
where T2 represents all the RX processing time. Then B prepares an ack or nak,
does the usual TX processing and sends the ack or nak in another physical
frame. Similarly, A will do the usual signal reception, and RX processing.
Therefore, A will know whether the feedback is ack or nak at time instant (T0+T+T1+T2)*2
(indeed the coding/decoding for ack/nak is much faster than that for the data
frame. But here we assume the same).
Now let's look at the numbers.
Assume that the physical frame is T=1.66 ms (the same as in HDR. This is just
an example.) With 10 mile cell radius, T1=0.05ms. To meet the requirement of (T0+T+T1+T2)*2=10ms,
T0+T2=3.3 ms, which I believe most of the current DSP/FPGA/ASIC can do it
easily.
Hope the above analysis clarifies the
points.
Thanks,
Junyi
-----Original Message-----
From: Jin-Weon Chang
[mailto:jwchang1@samsung.com]
Sent: Friday, October 31, 2003
12:38 AM
To: Marianna Goldhammer; Li Junyi;
stds-80220-requirements@ieee.org
Subject: Re:
stds-80220-requirements: 4.1.9 Latency- ARQ loop delay
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,
"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.
----- Original Message -----
Sent: Friday, October 31, 2003 2:08 AM
Subject: RE: stds-80220-requirements: 4.1.9
Latency- ARQ loop delay
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.
-----Original
Message-----
From: Li Junyi
[mailto:Junyi_Li@flarion.com]
Sent: Thursday, October 30, 2003
5:56 PM
To: Marianna Goldhammer; Jin-Weon
Chang; stds-80220-requirements@ieee.org
Subject: RE:
stds-80220-requirements: 4.1.9 Latency- ARQ loop delay
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.
************************************************************************************