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

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

Info

Publication number
WO1998042108A1
WO1998042108A1 PCT/US1998/005532 US9805532W WO9842108A1 WO 1998042108 A1 WO1998042108 A1 WO 1998042108A1 US 9805532 W US9805532 W US 9805532W WO 9842108 A1 WO9842108 A1 WO 9842108A1
Authority
WO
Grant status
Application
Patent type
Prior art keywords
packet
sequence number
data
acknowledgment
number
Prior art date
Application number
PCT/US1998/005532
Other languages
French (fr)
Inventor
D. Greg Graham
Timothy J. Doiron
Anthony Spivey
Peter Sadrozinski
Russell Croucher
Original Assignee
Ericsson Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATIONS NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation, e.g. WAP [Wireless Application Protocol]
    • H04W80/06Transport layer protocols, e.g. TCP [Transport Control Protocol] over wireless
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. van Duuren system ; ARQ protocols
    • H04L1/1806Go-back-N protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L29/00Arrangements, apparatus, circuits or systems, not covered by a single one of groups H04L1/00 - H04L27/00 contains provisionally no documents
    • H04L29/02Communication control; Communication processing contains provisionally no documents
    • H04L29/06Communication control; Communication processing contains provisionally no documents characterised by a protocol
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic regulation in packet switching networks
    • H04L47/10Flow control or congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic regulation in packet switching networks
    • H04L47/10Flow control or congestion control
    • H04L47/14Flow control or congestion control in wireless networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic regulation in packet switching networks
    • H04L47/10Flow control or congestion control
    • H04L47/19Flow control or congestion control at layers above network layer
    • H04L47/193Flow control or congestion control at layers above network layer at transport layer, e.g. TCP related
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic regulation in packet switching networks
    • H04L47/10Flow control or congestion control
    • H04L47/34Sequence integrity, e.g. sequence numbers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Application independent communication protocol aspects or techniques in packet data networks
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32High level architectural aspects of 7-layer open systems interconnection [OSI] type protocol stacks
    • H04L69/322Aspects of intra-layer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/326Aspects of intra-layer communication protocols among peer entities or protocol data unit [PDU] definitions in the transport layer, i.e. layer four

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.
PCT/US1998/005532 1997-03-20 1998-03-19 Method for implementing a transport layer protocol for wireless packet data delivery WO1998042108A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US82123597 true 1997-03-20 1997-03-20
US08/821,235 1997-03-20

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
AU6473498A AU6473498A (en) 1997-03-20 1998-03-19 Method for implementing a transport layer protocol for wireless packet data delivery

Publications (1)

Publication Number Publication Date
WO1998042108A1 true true WO1998042108A1 (en) 1998-09-24

Family

ID=25232880

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1998/005532 WO1998042108A1 (en) 1997-03-20 1998-03-19 Method for implementing a transport layer protocol for wireless packet data delivery

Country Status (1)

Country Link
WO (1) WO1998042108A1 (en)

Cited By (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000025470A1 (en) * 1998-10-28 2000-05-04 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for discarding packets in a data network having automatic repeat request
EP1021024A2 (en) * 1998-12-09 2000-07-19 Coveley, Solbyung Wireless transport protocol
EP1059823A1 (en) * 1999-06-11 2000-12-13 Lucent Technologies Inc. Primary transfer for simplex mode forward-link high-speed packet data services in CDMA systems
WO2002028033A1 (en) * 2000-09-22 2002-04-04 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for managing traffic flows
US6434367B1 (en) 1999-06-11 2002-08-13 Lucent Technologies Inc. Using decoupled power control sub-channel to control reverse-link channel power
WO2002091658A1 (en) * 2001-05-03 2002-11-14 Nokia Corporation Processing of segmented messages
WO2003015336A1 (en) * 2001-08-10 2003-02-20 Motorola, Inc., A Corporation Of The State Of Delaware A method for implementing a modified radio link protocol
WO2003039085A1 (en) * 2001-10-30 2003-05-08 Qualcomm, Incorporated Method and apparatus for scheduling packet data transmissions in a wireless communication system
US6629261B1 (en) 2000-11-21 2003-09-30 At&T Wireless Services, Inc. Enhanced data link layer selective reject mechanism in noisy wireless environment
US6631126B1 (en) 1999-06-11 2003-10-07 Lucent Technologies Inc. Wireless communications using circuit-oriented and packet-oriented frame selection/distribution functions
US6697983B1 (en) 2000-10-24 2004-02-24 At&T Wireless Services, Inc. Data link layer tunneling technique for high-speed data in a noisy wireless environment
US6757270B1 (en) 1999-06-11 2004-06-29 Lucent Technologies Inc. Low back haul reactivation delay for high-speed packet data services in CDMA systems
US6765869B2 (en) 2000-12-21 2004-07-20 At&T Wireless Services, Inc. Medium access dynamic congestion control mechanism for wireless data
US6765870B2 (en) 2000-12-21 2004-07-20 At&T Wireless Services, Inc. Medium access dynamic congestion control mechanism for wireless data
US7822041B2 (en) 2000-11-30 2010-10-26 Qualcomm Incorporated Method and apparatus for scheduling packet data transmissions in a wireless communication system
WO2014151072A1 (en) * 2013-03-15 2014-09-25 A10 Networks, Inc. System and method for customizing the identification of application or content type
US9066264B2 (en) 2007-10-01 2015-06-23 Google Technology Holdings LLC Status report triggering in wireless communication system
US9294503B2 (en) 2013-08-26 2016-03-22 A10 Networks, Inc. Health monitor based distributed denial of service attack mitigation
US9537886B1 (en) 2014-10-23 2017-01-03 A10 Networks, Inc. Flagging security threats in web service requests
US9584318B1 (en) 2014-12-30 2017-02-28 A10 Networks, Inc. Perfect forward secrecy distributed denial of service attack defense
US9621575B1 (en) 2014-12-29 2017-04-11 A10 Networks, Inc. Context aware threat protection
US9756071B1 (en) 2014-09-16 2017-09-05 A10 Networks, Inc. DNS denial of service attack protection
US9787581B2 (en) 2015-09-21 2017-10-10 A10 Networks, Inc. Secure data flow open information analytics
US9838425B2 (en) 2013-04-25 2017-12-05 A10 Networks, Inc. Systems and methods for network access control
US9848013B1 (en) 2015-02-05 2017-12-19 A10 Networks, Inc. Perfect forward secrecy distributed denial of service attack detection
US9900343B1 (en) 2015-01-05 2018-02-20 A10 Networks, Inc. Distributed denial of service cellular signaling
US9906422B2 (en) 2014-05-16 2018-02-27 A10 Networks, Inc. Distributed system to determine a server's health
US9912555B2 (en) 2013-03-15 2018-03-06 A10 Networks, Inc. System and method of updating modules for application or content identification
US10044582B2 (en) 2012-01-28 2018-08-07 A10 Networks, Inc. Generating secure name records
US10063591B1 (en) 2015-02-14 2018-08-28 A10 Networks, Inc. Implementing and optimizing secure socket layer intercept

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH03175759A (en) * 1989-12-04 1991-07-30 Mitsubishi Electric Corp Packet exchange control system
US5448561A (en) * 1991-09-19 1995-09-05 Robert Bosch Gmbh Method & apparatus for data exchange in data processing installations
EP0748096A2 (en) * 1995-06-07 1996-12-11 Xerox Corporation Event consistent graphical user interface on a high communication latency mobile computer

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH03175759A (en) * 1989-12-04 1991-07-30 Mitsubishi Electric Corp Packet exchange control system
US5448561A (en) * 1991-09-19 1995-09-05 Robert Bosch Gmbh Method & apparatus for data exchange in data processing installations
EP0748096A2 (en) * 1995-06-07 1996-12-11 Xerox Corporation Event consistent graphical user interface on a high communication latency mobile computer

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
PATENT ABSTRACTS OF JAPAN vol. 015, no. 419 (E - 1126) 24 October 1991 (1991-10-24) *

Cited By (45)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000025470A1 (en) * 1998-10-28 2000-05-04 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for discarding packets in a data network having automatic repeat request
US6424625B1 (en) 1998-10-28 2002-07-23 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for discarding packets in a data network having automatic repeat request
US6563813B1 (en) 1998-12-09 2003-05-13 Solbyung Coveley Wireless transport protocol
EP1021024A3 (en) * 1998-12-09 2002-06-05 Coveley, Solbyung Wireless transport protocol
EP1021024A2 (en) * 1998-12-09 2000-07-19 Coveley, Solbyung Wireless transport protocol
EP1059823A1 (en) * 1999-06-11 2000-12-13 Lucent Technologies Inc. Primary transfer for simplex mode forward-link high-speed packet data services in CDMA systems
US6631126B1 (en) 1999-06-11 2003-10-07 Lucent Technologies Inc. Wireless communications using circuit-oriented and packet-oriented frame selection/distribution functions
US6434367B1 (en) 1999-06-11 2002-08-13 Lucent Technologies Inc. Using decoupled power control sub-channel to control reverse-link channel power
US6507572B1 (en) 1999-06-11 2003-01-14 Lucent Technologies Inc. Primary transfer for simplex mode forward-link high-speed packet data services in CDMA systems
US6757270B1 (en) 1999-06-11 2004-06-29 Lucent Technologies Inc. Low back haul reactivation delay for high-speed packet data services in CDMA systems
US6925096B2 (en) 2000-09-22 2005-08-02 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for managing traffic flows
WO2002028033A1 (en) * 2000-09-22 2002-04-04 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for managing traffic flows
US7395481B2 (en) 2000-10-24 2008-07-01 At&T Mobility Ii Llc Data link layer tunneling technique for high-speed data in a noisy wireless environment
US8578234B2 (en) 2000-10-24 2013-11-05 At&T Mobility Ii Llc Data link layer tunneling technique for high-speed data in a noisy wireless environment
US6697983B1 (en) 2000-10-24 2004-02-24 At&T Wireless Services, Inc. Data link layer tunneling technique for high-speed data in a noisy wireless environment
US8407548B2 (en) 2000-10-24 2013-03-26 At&T Mobility Ii Llc Data link layer tunneling technique for high-speed data in a noisy wireless environment
US6629261B1 (en) 2000-11-21 2003-09-30 At&T Wireless Services, Inc. Enhanced data link layer selective reject mechanism in noisy wireless environment
US7822041B2 (en) 2000-11-30 2010-10-26 Qualcomm Incorporated Method and apparatus for scheduling packet data transmissions in a wireless communication system
US6765869B2 (en) 2000-12-21 2004-07-20 At&T Wireless Services, Inc. Medium access dynamic congestion control mechanism for wireless data
US6765870B2 (en) 2000-12-21 2004-07-20 At&T Wireless Services, Inc. Medium access dynamic congestion control mechanism for wireless data
WO2002091658A1 (en) * 2001-05-03 2002-11-14 Nokia Corporation Processing of segmented messages
US6941500B2 (en) 2001-08-10 2005-09-06 Motorola, Inc. Method for implementing a modified radio link protocol
WO2003015336A1 (en) * 2001-08-10 2003-02-20 Motorola, Inc., A Corporation Of The State Of Delaware A method for implementing a modified radio link protocol
WO2003039085A1 (en) * 2001-10-30 2003-05-08 Qualcomm, Incorporated Method and apparatus for scheduling packet data transmissions in a wireless communication system
US6788687B2 (en) 2001-10-30 2004-09-07 Qualcomm Incorporated Method and apparatus for scheduling packet data transmissions in a wireless communication system
US7463631B2 (en) 2001-10-30 2008-12-09 Qualcomm Incorporated Method and apparatus for scheduling packet data transmissions in a wireless communication system
US9066264B2 (en) 2007-10-01 2015-06-23 Google Technology Holdings LLC Status report triggering in wireless communication system
EP2195978B1 (en) * 2007-10-01 2016-06-08 Google Technology Holdings LLC Status report triggering in wireless communication system
US10044582B2 (en) 2012-01-28 2018-08-07 A10 Networks, Inc. Generating secure name records
US9912555B2 (en) 2013-03-15 2018-03-06 A10 Networks, Inc. System and method of updating modules for application or content identification
US9722918B2 (en) 2013-03-15 2017-08-01 A10 Networks, Inc. System and method for customizing the identification of application or content type
WO2014151072A1 (en) * 2013-03-15 2014-09-25 A10 Networks, Inc. System and method for customizing the identification of application or content type
US10091237B2 (en) 2013-04-25 2018-10-02 A10 Networks, Inc. Systems and methods for network access control
US9838425B2 (en) 2013-04-25 2017-12-05 A10 Networks, Inc. Systems and methods for network access control
US9860271B2 (en) 2013-08-26 2018-01-02 A10 Networks, Inc. Health monitor based distributed denial of service attack mitigation
US9294503B2 (en) 2013-08-26 2016-03-22 A10 Networks, Inc. Health monitor based distributed denial of service attack mitigation
US9906422B2 (en) 2014-05-16 2018-02-27 A10 Networks, Inc. Distributed system to determine a server's health
US9756071B1 (en) 2014-09-16 2017-09-05 A10 Networks, Inc. DNS denial of service attack protection
US9537886B1 (en) 2014-10-23 2017-01-03 A10 Networks, Inc. Flagging security threats in web service requests
US9621575B1 (en) 2014-12-29 2017-04-11 A10 Networks, Inc. Context aware threat protection
US9584318B1 (en) 2014-12-30 2017-02-28 A10 Networks, Inc. Perfect forward secrecy distributed denial of service attack defense
US9900343B1 (en) 2015-01-05 2018-02-20 A10 Networks, Inc. Distributed denial of service cellular signaling
US9848013B1 (en) 2015-02-05 2017-12-19 A10 Networks, Inc. Perfect forward secrecy distributed denial of service attack detection
US10063591B1 (en) 2015-02-14 2018-08-28 A10 Networks, Inc. Implementing and optimizing secure socket layer intercept
US9787581B2 (en) 2015-09-21 2017-10-10 A10 Networks, Inc. Secure data flow open information analytics

Similar Documents

Publication Publication Date Title
US6424625B1 (en) Method and apparatus for discarding packets in a data network having automatic repeat request
US6389016B1 (en) Data communication system and method for transporting data
US7502860B1 (en) Method and apparatus for client-side flow control in a transport protocol
US6987981B2 (en) Robust RLC reset procedure in a wireless communication system
US5448561A (en) Method & apparatus for data exchange in data processing installations
US7403528B2 (en) Method of data communication using a control message
US20070186134A1 (en) Method and system for generating block ancknowledgements in wireless communications
US5664091A (en) Method and system for a voiding unnecessary retransmissions using a selective rejection data link protocol
US20050226239A1 (en) Optimizing IEEE 802.11 for TCP/IP data transfer
US5968197A (en) Method and apparatus for data recovery
US20060026296A1 (en) Methods and apparatus for optimum file transfers in a time-varying network environment
US6922557B2 (en) Wireless communication system
US7433314B2 (en) Method and system for acknowledging the receipt of a transmitted data stream in a wireless personal area network
US20100192035A1 (en) Method and Arrangement for Retransmission Using HARQ
US6601207B1 (en) Method and a device for re-transmitting data transfer packets
US4423414A (en) System and method for name-lookup in a local area network data communication system
US20070277074A1 (en) Sonar Collision Avoidance System
US20030095534A1 (en) Applicable PDU range test and calculation for window-based polling
US4430651A (en) Expandable and contractible local area network system
US20010021984A1 (en) Apparatus and method for re-transmitting erroneous packet data
US6553032B1 (en) Packeting timeout spoofing in a wireless data communications network
US20070064631A1 (en) Method and apparatus for transmitting signaling data messages in a wireless communications system
US20040062275A1 (en) Method and apparatus for offloading message segmentation to a network interface card
WO2000060799A1 (en) Packet discard notification for semi reliable retransmission protocol
WO2000057594A1 (en) Data discard mechanism for selective repeat protocol

Legal Events

Date Code Title Description
AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN ML MR NE SN TD TG

AK Designated states

Kind code of ref document: A1

Designated state(s): AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GE GH GM GW HU ID IL IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG UZ VN YU ZW

121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

NENP Non-entry into the national phase in:

Ref country code: CA

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase in:

Ref country code: JP

Ref document number: 1998540843

Format of ref document f/p: F