WO1998042108A1

WO1998042108A1 - Method for implementing a transport layer protocol for wireless packet data delivery

Info

Publication number: WO1998042108A1
Application number: PCT/US1998/005532
Authority: WO
Inventors: D. Greg Graham; Timothy J. Doiron; Anthony Spivey; Peter Sadrozinski; Russell Croucher
Original assignee: Ericsson Inc.
Priority date: 1997-03-20
Filing date: 1998-03-19
Publication date: 1998-09-24
Also published as: AU6473498A

Abstract

The present invention is a transport layer protocol for data packet delivery in a wireless environment. The method of the present invention incorporates a transport data protocol structure to implement a modified go-back-n automatic repeat request for data packet delivery. The invention further employs a distinct pair of sequence numbers and request numbers for client and server originated data packet transmissions. Several packets can be transmitted by the sender without the need for each packet to be individually acknowledged by the receiver. After n successive packets have been transmitted, the sender polls the receiver for an acknowledgment. The acknowledgment (350) sent by the receiving party contains the request number equal to the sequence number of the packet that the receiver requests to be sent next (325). This number represents the last packet which was received in order plus one (325). Lastly, the present invention provides a method for the client and server to imply that an acknowledgment (350) has been sent to it even though the acknowledgement was lost in transmission.

Description

METHOD FOR IMPLEMENTING A TRANSPORT LAYER PROTOCOL FOR WIRELESS PACKET DATA DELIVERY

BACKGROUND OF THE INVENTION Technical Field of the Invention

The present invention pertains in general to a transport layer protocol and more particularly, to a method for implementing a modified go-back-n automatic repeat request protocol in the transport layer for wireless packet data delivery.

Description of Related Art

The International Standards Organization (ISO) has established a seven layer model regarding communication protocols. The forth layer of this model is referred to as the transport layer and is responsible for packet data delivery between a client and a server. To date, the vast majority of communication using packet data delivery has occurred via a wireline link. A standard solution for providing reliable packet data delivery in the wired environment is the use of Transport Control Protocol (TCP) . Transport Control Protocol was designed for wired environments characterized by relatively reliable physical connections between communication devices having large memories and computing power. For various known reasons Transport Control Protocol is unsuited for the harsh environment of wireless packet switched networks. For example, Transport Control Protocol requires a large memory to store both the software for implementing the Transport Control Protocol and the numerous data packets necessary for implementing the Transport Control Protocol's automatic repeat request methodology which allows for the receipt of out-of-order packets. Wireless communication, however, is characterized by the use of radios with small memories and limited computing power as compared to the wired environment . A further problem related to the use of Transport Control Protocol in the wireless environment is the large number of acknowledgments required between a client and a server during a communication session. In a wireless environment there is a greater chance for unsuccessful transmissions due to interference and collisions. The numerous acknowledgments required by the Transport Control Protocol leads to increased retransmissions, is inefficient in the wireless environment, and occupies valuable communications resources.

It would be advantageous, therefore, to devise a method for implementing a transport layer protocol in a wireless environment requiring less memory space for receiving data packets and reduced numbers of acknowledgments.

SUMMARY OF THE INVENTION

The present invention employs a multi-field transport data protocol structure for conducting a communication session. A modified go-back-n automatic repeat request is used to provide reliable data packet delivery requiring minimal memory space and computational power. The present invention numbers non-acknowledgment data packets sequentially using sequence numbers. Several packets are then transmitted by the sender without the need for each packet to be individually acknowledged by the receiver. After a given number of packets have been transmitted, the sender polls the receiver for an acknowledgment. A response to the requested acknowledgment includes a request number indicating the sequence number of the packet the receiver wants to be sent next. If all the packets sent are successfully received, the request number will equal the sequence number of the next packet to be sent. Otherwise, the sender begins retransmission starting with the packet having the request number . The present invention provides for a separate and distinct pair of sequence numbers and request numbers for client originated data transmissions and server originated data transmissions. Thus, for client originated data transmissions, the client sequentially numbers transmitted data packets with one set of sequence numbers and the server responds with request numbers equal to the sequence number of the data packet next expected to be sent. Conversely, for server originated data transmissions, the server sequentially numbers transmitted data packets with another set of sequence numbers distinct from client originated transmissions and the server responds with request numbers equal to the sequence number of the data packet next expected to be sent . The present invention further provides a method for the client and server to imply that an acknowledgment has been sent even though the acknowledgment may have been lost in transmission. The client and server imply an acknowledgment if a subsequent packet is received having an expected sequence number.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the method of the present invention may be acquired by reference to the following Detailed Description when taken in conjunction with the accompanying Drawings wherein:

Figure 1 is a Transport Protocol Data Unit for implementing the present invention;

Figure 2 is a sequence diagram for initiating a communication session;

Figure 3 is a flow diagram for implementing the go- back-n automatic repeat request method of the present invention;

Figure 4 is a sequence diagram for transmitting data from a client to a server without the loss of any data; Figure 5 is a sequence diagram for transmitting data from a client to a server when a packet of data is lost; Figure 6 is a sequence diagram for requesting and transmitting data from a server to a client; and

Figure 7 is a sequence diagram for requesting and transmitting data from a server to a client when acknowledgment messages are unsuccessfully transmitted.

DETAILED DESCRIPTION OF THE INVENTION

Referring now to Figure 1, there is illustrated a Transport Protocol Data Unit (TPDU) 100 for implementing the transport protocol of the present invention. The TPDU 100 contains a header 110 and a trailer 120. Included in the TPDU 100 is a data portion 130 which, together with the header 110 and trailer 120, is limited to a maximum of four hundred sixty-four bytes for the entire TPDU 100. The least significant seven bits of the second byte of the TPDU 100 comprises a command/response field 140. The most significant bit of the second byte of the TPDU 100 comprises a response bit (R)150. If the response bit 150 is clear (i.e. 0) , then the TPDU 100 is a command TPDU and the command/response field 140 contains either a command or an indication that the TPDU 100 contains data in the data portion 130. The third byte of the TPDU 100 comprises a response field 160.

A command TPDU does not contain a response, and therefore, the response field 160 is set to a zero value. On the other hand, if the response bit 150 is set (i.e. 1) , then the TPDU 100 is a response TPDU and the command/response field 140 contains the command to which the TPDU 100 is responding. The response field 160 contains the response to the command indicated in the command/response field 140.

The third bit of the fourth byte of the TPDU 100 comprises a poll bit (P)170. The poll bit 170 is used to request an acknowledgment. When the poll bit 170 is clear (i.e., 0), the receiver continues to receive data without sending an acknowledgment. When the receiver receives a TPDU 100 having the poll bit 170 set (i.e., 1), the receiver sends an acknowledgment to the sender. T h e fifth byte of the TPDU 100 comprises either the most significant eight bits of a session ID 181 or an eight bit value representing a retry time 182. During an initialization command sent by a client to a server the session ID has not yet been defined and the fifth byte of the TPDU 100 contains an eight bit value informing the server of the initial retry timeout value. This value has a five second resolution making the initial retry time in seconds equal to five times the value provided in this field. Upon receiving the initialization command, the server sends an acknowledgment to the client containing the most significant eight bits of the session ID 181 in the fifth byte and the least significant eight bits of the session ID 183 contained in the sixth byte of the TPDU 100. The most significant eight bits of the session ID 181 together with the least significant eight bits of the session ID 183 comprise a sixteen bit value identifying the current communication session between the client and the server. All TPDUs transmitted between the client and the server must contain the session identifier, otherwise, the data will be ignored.

The seventh and eighth byte of the TPDU 100 comprises the sequence number 180 and the ninth and tenth byte of the TPDU 100 comprises the request number 190. Every TPDU contains a unique sequence number identifying that particular TPDU 100. When a communication session between a client and a server is set up, numbers based on the current time of day are selected for client originated sequence number 180 and for the server originated sequence number which is communicated to the server via the request number 190. For the duration of the communication session, each TPDU 100 is identified with sequentially increasing sequence numbers 180. The last two bytes of the TPDU 100 forming the trailer 120 contain a sixteen bit cyclic redundancy check for the TPDU 100. Referring additionally now to Figure 2, there is illustrated a sequence diagram for initiating a communication session. To initiate a communication session between a client 200 and a server 210, the client 200 transmits an initialization TPDU 220. The initialization TPDU 220 includes an initialization command contained within the command/response field 140, a time based sequence number y contained in the sequence number field 180 and an initial retry time out represented by a number in the retry time field 182 which is equal to the number of seconds divided by five. Upon receiving the initialization TPDU 220 the server 210 transmits an acknowledgment TPDU 230 to the client 200 containing an acknowledgment response in the response field 160, the most significant byte 181 and least significant byte 183 of the session ID, the initialization command in the command/response field 140 and a request number y+1 in the request number field 190. The request number y+1 transmitted by the server 210 signifies that the server 210 is expecting to receive the next sequentially numbered TPDU following the initialization TPDU 220 (i.e., the y+1 numbered TPDU) . Upon receipt of the acknowledgment TPDU 230 the client 200 proceeds to transmit a data TPDU 240 containing data in the data field 130 and an indication of the presence of data in the command/response field 140. The data TPDU 240 contains a sequence number of y+1 contained in the sequence number field 180.

Referring additionally now to Figure 3, there is illustrated a flow diagram of the present invention for implementing the go-back-n automatic repeat request methodology. After a communication session has been initiated, the party currently receiving data packets listens for a received TPDU (step 300) . When a TPDU is received the receiving party compares the sequence number 180 of the received TPDU against the expected sequence number (step 310) . The expected sequence number is the next number in sequence following the sequence number of a previously, correctly received TPDU. If the sequence number 180 of the TPDU does not match the expected sequence number, the receiving party discards the received packet (step 320) . If, on the other hand, the sequence number 180 of the TPDU matches the expected sequence number the receiving party increments the expected sequence number (step 325) and performs an operation on the TPDU (step 330) in accordance with the command contained in the TPDU field 140. After the receiving party has operated on the data (step 330) , or discarded a packet containing a sequence number 180 other than the expected sequence number (step 320) the receiving party determines whether the pole bit 170 is set on the received

TPDU (step 340) . If the pole bit 170 is not set the receiving party returns to continue monitoring for further transmitted packets (step 300) . If, on the other hand, the pole bit 170 is set, the receiving party sends an acknowledgment (step 350) to the sending party, and then returns to continue monitoring for transmitted packets (step 300) . The acknowledgment sent by the receiving party contains the request number 190 equal to the sequence number 180 of the packet that the receiver requests to be sent next. This number represents the last packet which was received in order plus one. The method described in the flow diagram of Figure 3 applies equally both to client and server originated transmissions.

Referring additionally now to Figure 4, there is illustrated a sequence diagram for transmitting data from a client 200 to a server 210 when no data packets have been lost. After a communication session has been established, the client 200 proceeds to transmit data packets to the server 210. The number of packets p which the client 200 transmits to the server 210 before requesting an acknowledgment is set by the user. The client 200 transmits multiple data packets to the server 210 and eventually the client 200 transmits the p-1 data packet 400 having a sequence number 180 of a. Since one additional data packet is to be transmitted prior to requesting an acknowledgment, the pole bit 170 of the TPDU 400 is not set. The client 200 then transmits the pth data packet 410 with the pole bit 170 set. Upon receiving the TPDU 410 the server 210 determines that the pole bit 170 is set and transmits an acknowledgment TPDU 420 containing a request number 190 of a+2. In this illustration no data packets have been lost and the requested number a+2 of the acknowledgment TPDU 420 is equal to the sequence number 180 for the TPDU that should next be transmitted by the client 200.

Referring additionally now to Figure 5, there is illustrated a sequence diagram for transmitting data from a client to a server where a packet of data has been lost. As with Figure 4, the client 200 of Figure 5 has initiated a communication session and is in the process of transmitting data packets to the server 210. The client 200 transmits TPDU 500 containing a sequence number 180 of b. The TPDU 500 is successfully received by the server 210 which increments its expected sequence number by 1 thereby expecting the next TPDU to contain a sequence number 180 of b+1. The client 200 transmits data TPDU 510 with a sequence number 180 of b+1 which, for whatever reason, is not received by the server 210. The client 200 having no knowledge of the unsuccessful transmission continues with the transmission of TPDU 520 containing a sequence number 180 of b+2 which is received by the server 210. Since the sequence number b+2 of TPDU 520 does not match the expected sequence number b+1, the server 210 discards the packet. The server 210, however, recognizes that the pole bit 170 of TPDU 520 is set and in response generates an acknowledgment TPDU 530 containing a request number 190 of b+1 (instead of b+3) . Upon receiving the acknowledgment TPDU 530, the client 200 begins retransmission of data packets starting with TPDU 510 having a sequence number 180 of b+1. Referring additionally now to Figure 6, there is illustrated a sequence diagram for transmitting data from a server 210 to a client 200. This diagram includes server 210 originated data transmissions and illustrates the distinction between sequence numbers 180 and request numbers 190 associated with client 200 originated and server 210 originated transmissions.

The client 200 initiates a communication session by transmitting an initialization TPDU 600. The initialization TPDU 600 contains a randomly generated sequence number 180 of y for client 200 originated transmissions and a time based request number 190 of z corresponding to server 210 originated transmissions. The server 210 upon receiving the initialization TPDU 600 transmits an acknowledgment TPDU 610 containing a request number 190 of y+1. Upon receiving the acknowledgment TPDU 610 the client 200 transmits a data request TPDU 620 in which the pole bit 170 is set thereby requesting an acknowledgment. Since this TPDU 620 is a client 200 originated TPDU the sequence number 180 is equal to the sequence number y of the previously transmitted TPDU 600 plus 1 or y+1. The data request TPDU 620 also includes a request number 190 of z which is the sequence number 180 which the server 210 will use to begin data transmission. Upon receiving the data request 620 the server 610 transmits an acknowledgment TPDU 630 having a request number 190 of y+2. The server 210 then begins to transmit the requested data with server 210 originated TPDU transmissions . These transmissions have sequence numbers 180 beginning with z as requested by the client. A data TPDU 640 having a sequence number 180 of z and a request number 190 of y+2 is thus transmitted to the client 200 with the pole bit 170 set to request acknowledgment . The data TPDU 640 also contains the client 200 requested data. Upon receiving the data TPDU 640 the client 200 transmits an acknowledgment TPDU 650 having a request number 190 of z+1 equal to the next server 210 originated packet sequence number 180 expected by the client 200. The next client 200 originated transmission data TPDU 660 has a client originated sequence number 180 of y+2 and a request number 190 of z+1. As can be seen by the illustration in Figure 6, the appropriate sequence number 180 and request number 190 depends upon whether the transmission and subsequent acknowledgment is a result of client 200 or server 210 originated data packet transmissions.

A problem associated with server 210 originated data transmissions is that the server 210 has no way of recognizing whether an acknowledgment TPDU which it transmits to the client 200 was unsuccessfully received by the client 200. Likewise, a client 200 has no way of recognizing whether an acknowledgment sent by it to the server 210 in response to the server originated data transmissions has been unsuccessfully received by the server 210. To solve this problem the method of the present invention stipulates that an acknowledgment is implied if a packet is subsequently received which has the expected request number 190.

Referring additionally now to Figure 7, there is illustrated a sequence diagram for requesting and transmitting data from a server 210 to a client 200 when acknowledgment messages are unsuccessfully transmitted. In response to the transmission of a data request TPDU 700, similar to data request TPDU 620 of Figure 6, containing a sequence number 180 of y+1, a request number 190 of z, and the pole bit 170 set, the server 210 transmits an acknowledgment TPDU 710 having a request number 190 of y+2. The acknowledgment TPDU 710, for whatever reason, is not received by the client 200. Nevertheless, the server 210 transmits a data TPDU 720 containing a sequence number 180 of z, a request number 190 of y+2, and the pole bit 170 being set. Although the client 200 has not received the acknowledgment TPDU 710 from the server 210, the client 200, following the methodology of the present invention, recognizes that the request number y+2 of the data TPDU 720 contains the appropriate request number 190 and implies that an acknowledgment TPDU 710 has been sent by the server 210. The client 200, therefore, retains the data TPDU 720 and transmits an acknowledgment 730 having a request number 190 equal to z+1 to the server 210. In a similar fashion, this acknowledgment TPDU 730 may be unsuccessfully received by the server 210. Nevertheless, the client 200 transmits another TPDU, which for this example is data TPDU 740 having a sequence number 180 equal to y+2 and a request number 190 equal to z+1. The server 210, following the methodology of the present invention, recognizes that the request number z+1 is the appropriate request number 190 and implies that the client 200 has transmitted the acknowledgment TPDU 730 even though it was not received by the server 210. The stipulation of implying an acknowledgment if a packet is subsequently received which has the expected request number 190 prevents the client 200 and the server 210 from becoming out of synchronization with one another and constantly re- sending data packets to one another.

Unlike Transport Control Protocol, the transport layer protocol of the present invention does not support a selective automatic repeat request methodology and thus, does not support the receipt of out of order packets . In the present invention, packets received out of order are discarded. If, however, a packet is received out of order but contains a request for acknowledgment, an acknowledgment is sent containing the request number equal to the sequence number of the last packet received in order plus one .

Although a preferred embodiment of the method of the present invention has been illustrated in the accompanying Drawings and described in the foregoing Detailed Description, it is understood that the invention is not limited to the embodiment disclosed, but is capable of numerous rearrangements, modifications and substitutions without departing from the spirit of the invention as set forth and defined by the following claims.

Claims

WHAT IS CLAIMED IS:

1. A Transport Protocol Data Unit for a wireless packet data delivery comprising: a response bit for signifying the Transport Protocol Data Unit as a command or response Transport Protocol Data Unit; a poll bit for requesting an acknowledgment; a sequence number field for identifying the Transport Protocol Data Unit; and a request number field for communicating a sequence number of the Transport Protocol Data Unit requested to be next transmitted.

2. A method for data packet delivery between a sender and a receiver, comprising the steps of: transmitting a user selected number of data packets, wherein each packet is sequentially numbered and each packet except for a last packet has a poll bit cleared, the last packet having the poll bit set; receiving the data packets transmitted by the sender; detecting the sequence number and the poll bit of each received packet; comparing the sequence number of each received packet against an expected sequence number; storing data contained within packets when the sequence number of the packet matches the expected sequence number; otherwise discarding the data packets.

3. A method for data packet delivery between a sender and a receiver, comprising the steps of: transmitting a user selected number of data packets, wherein each packet is sequentially numbered and each packet except for a last packet has a poll bit cleared, the last packet having the poll bit set; receiving the data packets transmitted by the sender; detecting the sequence number and the poll bit of each received packet; comparing the sequence number of each received packet against an expected sequence number; storing data contained within packets when the sequence number of the packet matches the expected sequence number; discarding data packets when the sequence number of the packet does not match the expected sequence number; and transmitting an acknowledgment in response to the detection of a set poll bit, the acknowledgment including a request number equal to the expected sequence number .

4. The method of Claim 3, further including the steps of : transmitting the data packet having the sequence number equal to the request number transmitted by the receiver in the acknowledgment; and transmitting all subsequent data packets.

5. A method for data packet delivery between a client and a server when a client requested acknowledgment is not received by the client prior to the receipt of a subsequent data packet, comprising the steps of: receiving a data packet not containing an acknowledgment when an acknowledgment is expected; detecting a sequence number of the received data packet ; comparing the sequence number of the received packet against an expected sequence number; and implying that an acknowledgment was sent even though not received if the sequence number of the received packet matches the expected sequence number.