1 / 5

QoS Data Retry Limits Proposal by Yoshihiro Ohtani of Sharp Corporation

This document discusses the current specifications and proposed solutions for defining retry limits for QoS data frames and Burst ACK Request frames in traffic streams. It addresses the need for setting appropriate retry limits to ensure successful transmission in various network conditions.

tmoss
Download Presentation

QoS Data Retry Limits Proposal by Yoshihiro Ohtani of Sharp Corporation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Retry Limit for QoS Data Yoshihiro Ohtani Sharp Corporation 2 March 2002 Yoshihiro Ohtani, Sharp

  2. (*) Current Spec of the Retry Limit Current spec of the retry limit for an MPDU within a burst If the BurstAck indicates that an MPDU was not received correctly, the originator shall retry that MPDU subject to that MPDU's appropriate retry limit. Current spec of the retry limit for the Burst ACK Request frame If there is no response (i.e., neither a BurstAck nor an ACK) to final frame, the originator can retransmit BurstAckReq within the current TXOP (if time permits) or within a subsequent TXOP. This retransmission is subject to the short retry limit. If the BurstAckReq is discarded due to reaching its retry limit, all MPDUs in the burst are considered to have failed transmission and are discarded. (*) Discussed in Burst ACK subgroup Yoshihiro Ohtani, Sharp

  3. Question • How large should be the retry limit for QoS data frames in a traffic stream ? • Each MPDU is “alive” until its delay bound. • QoS data frames cannot be retransmitted any more through upper layer, unlike non-QoS data. So basically, each QoS Data frames in a traffic stream should be retransmitted as long as its delay bound. • Typical value for retry limit ( 4 or 7 ) may be spent rather frequently under multipass fading environment. • A relatively large value should be able to be set as the retry limit of QoS Data for a traffic stream. Yoshihiro Ohtani, Sharp

  4. Question • How large should be the retry limit for QoS data frames in a traffic stream ? (Cont.) • A large value of Short/Long retry limit brings a side effect while sending eDCF frames ( A TC who has a very bad channel condition will prevent the other TC in the same queue to be sent out for a very long time. ) • A large value of Short/Long retry limit brings another side effect in sending RTS/CTS. Yoshihiro Ohtani, Sharp

  5. Proposal • Potential Solution (1) • Define a new MIB parameter which specifies the retry limit for QoS data frame in traffic streams. • Define a new MIB parameter which specifies the retry limit for Burst ACK Request frame. • Potential Solution (2) • The retransmission of QoS Data frame or Burst ACK request frame are not subject to any retry limit if that QoS data frame belongs to a traffic stream. Yoshihiro Ohtani, Sharp

More Related