Efficient error control for wireless packet transmissions

Details Efficient error control for wireless packet transmissions Efficient error control for wireless packet transmissions

1998-08-04

2001-10-09

Patel, Ajit (Department: 2662)

Multiplex communications

Pathfinding or routing

Switching a message which includes an address header

C714S748000

Reexamination Certificate

active

06301249

ABSTRACT:

FIELD OF THE INVENTION
The field of this invention pertains to telecommunications, including a telecommunications system that includes efficient error control for packet transmissions.
DESCRIPTION OF THE TECHNOLOGY
Generally, known communication systems provide transmission error correction of packet data, i.e., messages transmitted in a packetized format, through the use of standard automatic repeat request (“ARQ”) mechanisms, also known as backward error correction mechanisms. In wireline systems, ARQ mechanisms are thought to be fairly effective, as, generally, wireline channels experience relatively low transmission error rates.
In wireless networks, or systems, however, the radio channel, or over-the-air interface, is characterized by a considerably elevated transmission error rate compared to a wireline channel. This, in turn, tends to reduce the effectiveness of standard ARQ mechanisms, as the probability of ever successfully transmitting a frame, i.e., a portion of packet data, also referred to as a data segment, error free may be very low. The overall impact may be either a serious reduction in system throughput and an increase in delay, or, possibly, total system collapse.
Known systems employing transmission error control also may provide a cyclic redundancy code (“CRC”) for error detection. Generally, a cyclic redundancy code is a type of frame check sequence computed by treating data bit strings as polynomials with binary coefficients, and performing a mathematical calculation thereon. A CRC, therefore, is basically a code that is transmitted along with a frame, or data segment, to enable the receiver to detect data corruption.
Known systems employing transmission error control also generally provide a mechanism for signaling failures, which are used to trigger retransmissions. Most known data system retransmission policies fall into one of the two following categories.
The first known retransmission category is a “stop and wait” protocol. In a stop and wait protocol, each frame must be explicitly acknowledged before the next can be sent.
As shown in
FIG. 1
, wherein a stop and wait protocol is employed in an exemplary transmission sequence
1
, an acknowledge (“ack”) message is sent in response to every successful frame transmission. Thus, ack
1
message
10
is transmitted in response to the successful receipt of frame
5
, ack
2
message
20
is transmitted in response to the successful receipt of frame
15
, ack
3
message
30
is transmitted in response to the successful receipt of frame
25
, and so on.
FIG. 1
, depicting successful transmission conditions, shows that even under favorable conditions, with a stop and wait protocol the data transmission throughput is generally poor. Only one data frame is generally transmitted per time frame
50
. Too, an acknowledge message must be sent in each time frame, in response to the data transmission in that time frame, causing additional message traffic on what may already be a scarce resource.
Thus, using a stop and wait protocol, it can take fifteen time frames to transmit a packet data segmented into fifteen frames. And the transmission sequence
1
is shown under favorable transmission conditions, i.e., all data transmissions are successful on the first attempt.
FIG. 2
shows the poor throughput performance of packet data transmissions using a stop and wait protocol for an exemplary transmission scenario
59
when there are errors in the transmission of one or more frames. In
FIG. 2
, like
FIG. 1
, the first frame, or data sequence,
60
is successfully transmitted, and an acknowledge message ack
1
62
is sent in response. However, in transmission scenario
59
, the second frame
64
is unsuccessfully transmitted, and a negative acknowledge (“nack”) message nack
2
66
is sent in response. Receipt of the nack
2
66
triggers the entity transmitting the packet data to transmit the second frame a second time (message
68
). On the second attempt, the second frame
68
is successfully transmitted and an acknowledge message ack
2
70
is sent in response. However, because the initial transmission of the second frame
64
was unsuccessful, it has taken three time frames
140
to successfully transmit two frames of data.
Further, in
FIG. 2
, while the third frame
72
is successfully transmitted, with an acknowledge message ack
3
74
sent in response, the fourth frame
76
is unsuccessfully transmitted, with a negative acknowledge message nack
4
78
sent in response. Receipt of the nack
4
78
triggers the entity transmitting the packet data to transmit the fourth frame a second time (message
80
). On the second attempt in exemplary traffic scenario
59
, the fourth frame
80
is successfully transmitted and an acknowledge message ack
4
82
is sent in response. As both the initial transmission of the second frame
64
and the fourth frame
76
were unsuccessful, it has taken six time frames
140
to successfully transmit four frames of data.
In the same scenario
59
, the fifth frame
84
is unsuccessfully transmitted on the first attempt, and a negative acknowledge message nack
5
86
is sent in response. Receipt of the nack
5
86
, like receipt of the other negative acknowledge messages, triggers the entity transmitting the packet data to retransmit the fifth frame a second time (message
88
). On the second attempt in scenario
59
, the fifth frame
88
is successfully transmitted and an acknowledge message ack
5
90
is sent in response. However, as the initial transmission of the second frame
64
, the fourth frame
76
and the fifth frame
84
were unsuccessful, it has taken eight time frames
140
to successfully transmit five frames of data.
The sixth frame
92
of scenario
59
is successfully transmitted, and an acknowledge message ack
6
94
is sent in response. The seventh frame
96
, however, is unsuccessfully transmitted, and a negative acknowledge message nack
7
98
is sent in response. Upon receiving the nack
7
98
, the entity transmitting the packet data transmits the seventh frame once again (message
100
). On the second attempt in scenario
59
, the seventh frame
100
is successfully transmitted and an acknowledge message ack
7
102
is sent in response. However, it has now taken eleven time frames to successfully transmit only seven frames of data.
The eighth frame
104
and the ninth frame
108
are both successfully transmitted on the first attempt in scenario
59
, with an acknowledge message ack
8
106
and ack
9
110
respectively sent in response. However, the initial transmission of the tenth frame
112
is unsuccessful, and a negative acknowledge message nack
10
114
is sent in response. Upon receipt of the nack
10
114
, the entity transmitting the packet data transmits the tenth frame again (message
116
), in the subsequent time frame. On the second attempt, the tenth frame
116
is successfully transmitted and an acknowledge message ack
10
118
is sent in response. However, it has taken fifteen time frames to successfully send just ten frames of data.
In traffic scenario
59
, the remaining five frames
120
,
124
,
128
,
132
and
136
of the packet data are successfully transmitted on the first attempt, with respective acknowledge messages
122
,
126
,
130
,
134
and
138
sent in response.
With a stop and wait protocol, where several frame transmissions are unsuccessfully transmitted on an initial attempt, several additional transmissions and a significantly longer time to successfully transmit the entire packet data results. Specifically, as well as frames
64
,
76
,
84
,
96
and
112
of scenario
59
requiring subsequent retransmission, five negative acknowledge messages are transmitted and five additional acknowledgment messages are also transmitted. Also, in scenario
59
, twenty time frames are required to transmit fifteen frames of data.
Thus, with a stop and wait protocol, as the data transmission error rate increases, the additional message transmission count and the delay in finalizing transmission of data packets also increases. Use of stop and wait protocols, therefor

Affiliated with

Also associated with

Rating

Efficient error control for wireless packet transmissions does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Efficient error control for wireless packet transmissions, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Efficient error control for wireless packet transmissions will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2587658