Browse Prior Art Database

Rx-end Assisted Ack/Nack Message transmission to enhance Capacity and QoS in selective ARQ based packet data systems

IP.com Disclosure Number: IPCOM000005033D
Original Publication Date: 2001-Jul-24
Included in the Prior Art Database: 2001-Jul-24
Document File: 5 page(s) / 92K

Publishing Venue

Motorola

Related People

Davood Molkdar: AUTHOR [+2]

Abstract

The paper describes a technique that reduces the probability of stalling the transmit-window and maintains the frequency of receiving channel estimates in systems employing automatic repeat request (ARQ) and/or a Link Adaptation (LA) mechanism. The technique proposed also minimises the time period for which the system is stalled should the stall condition occur. To illustrate the problem and solution, GPRS/EGPRS (General Packet Radio System / Enhanced GPRS) RLC protocol is used; the technique is, however, equally applicable to other ARQ multi-code rate systems employing similar type of protocol and LA mechanism

This text was extracted from a WORD97 document.
This is the abbreviated version, containing approximately 32% of the total text.

Rx-end Assisted Ack/Nack Message transmission to enhance Capacity and QoS in selective ARQ based packet data systems

Davood Molkdar and Walter Featherstone

Abstract

The paper describes a technique that reduces the probability of stalling the transmit-window and maintains the frequency of receiving channel estimates in systems employing automatic repeat request (ARQ) and/or a Link Adaptation (LA) mechanism. The technique proposed also minimises the time period for which the system is stalled should the stall condition occur. To illustrate the problem and solution, GPRS/EGPRS (General Packet Radio System Enhanced GPRS) RLC protocol is used; the technique is, however, equally applicable to other ARQ multi-code rate systems employing similar type of protocol and LA mechanism.

Introduction

This paper proposes a technique to enhance the operation of ARQ. ARQ is an error control mechanism for data transmission in which the transmit-end (Tx-end) periodically polls the Rx-end for an Ack/Nack message. Upon the reception of a poll message the Rx-end transmits an Ack/Nack message back to the Tx-end. The Ack/Nack message contains the Ack/Nack state of the previous packets sent to the Rx-end by the Tx-end. The paper discusses the consequences of the TX-end not receiving the Ack/Nack message. It then goes on to propose a technique to increase the likelihood of the Tx-end receiving an Ack/Nack message through re-transmission of the Ack/Nack message based on Rx-end determining that the Ack/Nack message has not been received by the Tx-end, hence the name Rx-end assisted Ack/Nack message transmission for the proposed technique.

Problem(s) To Be Solved

In practice there are two scenarios in which the Tx-end does not receive the Ack/Nack message. In the first scenario, the poll message maybe corrupted and therefore is not received by the Rx-end (which means that the Rx-end will not transmit an Ack/Nack message). In the second scenario, the Ack/Nack message maybe corrupted and therefore not received at the Tx-end. The problem is that in both scenarios the Tx-end will not receive acknowledgement for the information that it has transmitted. This can cause an unnecessary extension of the data transfer, as the final acknowledgement is not received and therefore system resources are tied up; it also increases the likelihood of stalling the transmit-window mid-way through transmission.

The transmit-window defines maximum number of packets that can be sent to the Rx-end without acknowledgement. The window is advanced by one on receiving acknowledgement for the first block in the window. If all blocks within the transmit-window are transmitted and no Ack/Nack message is received then the transmit-window stalls. If the transmit-window stalls when using a system employing an ARQ system it is usual that the Tx-end sends a polling message to prompt the Rx-end for an Ack/Nack message. However, ...