Dear all,
Have the group considered the latency
requirements for different applications, as percieved by the end users? ITU and
3GPP have defined the different classes of services and the respective
requirements for delay, delay variation and information loss. Perhaps we could
take a similar approach regarding the requirements for latency and FER.
References:
1) "Draft New Recommendation G.QoSRQT
- End-user multimedia QoS Categories", ITU-T Study Group 12, Contribution
37, August 2001. [Published standard: G.1010]
2) 3GPP TS 22.105, "Services and
service capabilities"
3) 3GPP TS 23.107, "QoS concept and
Architecture"
Best regards,
Anna.
-----Original Message-----
From:
owner-stds-80220-requirements@majordomo.ieee.org
[mailto:owner-stds-80220-requirements@majordomo.ieee.org] On Behalf Of Marianna Goldhammer
Sent: Thursday, October 30, 2003
9:09 AM
To: Li Junyi; Jin-Weon Chang;
stds-80220-requirements@ieee.org
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