|
Marianna,
I think the "3rd frame" you're mentioning is a ack/nak control
message, not a data frame and is counted within the round trip latency. It is
common for many systems to support multiple frame sizes, including longer
ones, so I believe the intent of the requirement in the PAR was to require
at least one (realistic) configuration that meets these latencies. The
issue with longer ARQ loop times is not just for voice, it impacts
overall latency after retransmissions for every traffic type, particularly under
harsh conditions. The fact the some types of traffic may "tolerate" it better
than others does not necessarily mean that their performance is not impacted
(e.g. TCP/IP). It also impacts the tolerable underlying error rates that
the physical layer can operate at (and its corresponding impact on choice of
coding and modulation options, utilised power
and bandwidth etc).
Regards,
Samir
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.
************************************************************************************
|