EP0980614A1

EP0980614A1 - Reliable communication over an unreliable transport layer in a hand-held device using user-configurable timers

Info

Publication number: EP0980614A1
Application number: EP98920174A
Authority: EP
Inventors: Julia J. Renouard; Alan Piercy; Steve Heckt; Joe Savarese
Original assignee: Intermec Technologies Corp
Current assignee: Intermec Technologies Corp
Priority date: 1997-05-06
Filing date: 1998-05-04
Publication date: 2000-02-23
Also published as: JP2001524290A; WO1998051052A1; AU7280798A

Abstract

The disclosed system provides reliable communication over the UDP transport layer in a handheld device. By providing reliable communication over the UDP transport layer instead of using the TCP transport layer, memory requirements are reduced, and applications running on the handheld device have reliable data transfers performed on their behalf. Additionally, the use of standardized components, such as the UDP transport layer and a standard network layer like the IP layer, enables the handheld device to efficiently communicate with many other devices in a standardized manner. The disclosed system provides the reliable communication by utilizing a UDP+ layer on top of the UDP transport layer. The UDP+ layer acts as an interface between the application layer and the UDP layer both to provide reliable communication to the application layer and to hide the complexities involved with performing this functionality from the application layer. To provide reliable communication, the UDP+ layer acknowledges all messages received, and the UDP+ layer utilizes a retry timer such that when receipt of a message has not been acknowledged and the retry timer expires, the UDP+ layer resends the message. The value of the retry timer as well as other values used during retransmission of the message are configurable by the user to optimize performance. Also, the UDP+ layer utilizes a number of messages that are used to open a connection, transfer data, and close a connection.

Description

RELIABLE COMMUNICATION OVER AN UNRELIABLE TRANSPORT LAYER IN A HAND-HELD DEVICE USING USER-CONFIGURABLE TIMERS

TECHNICAL FIELD

The present invention relates generally to data processing systems and, more particularly, to providing reliable communication over an unreliable transport layer in a hand-held device using user-configurable timers.

BACKGROUND OF THE INVENTION

Conventional systems that perform data transfers typically use a protocol stack to facilitate the data transfer. A "protocol stack," also known as a protocol suite, contains a number of layers, with each layer responsible for a different facet of the data transfer. Each layer typically utilizes a protocol, which defines the types and formats of messages transferred by a layer to perform its facet of the data transfer.

A data transfer typically occurs between two end systems: the source of the data and the destination for the data. Often, the end systems are not directly connected, so the data transferred between the end systems must be routed through a number of intermediate systems. Each end system typically has the same protocol stack, although the intermediate systems need only a subset of the protocol stack that includes the layers necessary to perform the routing.

Figure 1 depicts a protocol stack 100, known as the TCP/IP protocol stack, which has been used extensively by data transfer systems. For example, many systems on the Internet utilize a TCP/IP stack. One of the benefits of utilizing a TCP/IP stack is the ability to communicate in an easy, efficient, and standardized manner with many computers world wide. The TCP/IP protocol stack 100 comprises an application layer 102, a transport layer 104, a network layer 106, and a link layer 108. The application layer 102 performs the processing of a particular application. For example, the application layer 102 may provide file transfer functionality, electronic mail functionality, network management functionality, or remote log-in functionality. When performing one of these applications, the application layer 102 on one end system sends data to a corresponding application layer on another end system by passing the data to the transport layer 104.

The transport layer 104 receives data from the application layer 102 and facilitates the flow of this data between the application layers on the end systems. In the TCP/IP protocol stack 100, two different transport protocols are used: the transmission control protocol (TCP) and the user datagram protocol (UDP). TCP reliably transfers data between two end systems. The data transfer is reliable because TCP guarantees that the data will be sent correctly to the destination end system. To provide such reliability, TCP (1) divides the data received from the application layer 102 into appropriately sized packets for the network layer 106, (2) acknowledges all packets received, (3) sets time-outs to ensure that the destination end system acknowledges that the packets were received, and (4) performs other functionality to ensure that when TCP receives data from the application layer 102, the corresponding TCP layer on the destination end system receives that data correctly. One drawback to TCP's reliable data transfer is, to perform this functionality, the size of the TCP layer is large, thus requiring a significant amount of memory.

In contrast to TCP, UDP is a much simpler service that provides unreliable data transfer. Upon receiving data from the application layer 102, UDP forms a packet, known as a datagram, and sends this packet to the network layer 106 for transfer to the end system in an unreliable manner: no acknowledgments are used and UDP does not guarantee that the datagrams reach the end system. UDP thus performs less functionality than TCP and, consequently, requires less memory.

The network layer 106, also known as the internet layer, receives packets from the transport layer 104 and performs the processing necessary to route these packets through the network. In the TCP/IP protocol stack 100, this layer utilizes one of three well-known protocols: the internet protocol (IP), the internet control message protocol (ICMP), or the internet group management protocol (IGMP).

The link layer 108, also known as the data-link layer or the network- interface layer, receives packets from the network layer 106 and performs the processing necessary to physically interface with the network transfer media, such as a cable, to transfer the packets across the network. To interface with the network transfer media, the link layer typically includes a network interface card and a suitable device driver that resides in the operating system.

The TCP/IP protocol stack 100 is utilized to transfer data within either a single network or within an internetwork ("internet"), which is a collection of networks using the same protocol stack. Each addressable entity, such as an application program, that can be accessed via the TCP/IP protocol stack has an associated IP address: the IP address is a 32-bit address specifying both a host ID (the ID of the computer on which the resource is located) and a network ID (the ID of the network on which the computer is located). IP addresses and, more generally, the TCP/IP protocol stack 100 is described in greater detail in Stevens, TCP/IP Illustrated Volume 1, Addison Wesley (1994), at pages 1-51, 143-168, and 223-337.

Although the TCP/IP protocol stack facilitates communication between systems, some systems are unable to utilize the TCP/IP stack and are thus unable to reap the benefits of efficiently communicating with numerous systems and devices in a standardized manner with relative simplicity. For example, hand-held devices, devices that can both be easily held and manipulated using one or two hands, have been developed for reading bar codes. These devices receive bar-code information and transmit it to a host computer via radio communications. Such devices can greatly benefit from using a TCP/IP protocol stack to facilitate communications to the host and other computers in a standardized manner using standard components. However, these devices have an extremely limited amount of memory. When selecting a transport layer for such a device, the TCP layer cannot be used because it is too large, thus requiring an unacceptable amount of memory. Likewise, the UDP layer cannot be utilized, because it provides unreliable communication, and the application on the hand-held device typically lacks the sophistication necessary to identify which datagrams have not been received, to keep track of these datagrams, and then to retransmit them when necessary. It is thus desirable to overcome these problems and to incorporate a TCP/IP protocol stack into a hand-held device. SUMMARY OF THE INVENTION

The disclosed system provides reliable communication over the UDP transport layer in a hand-held device. By providing reliable communication over the UDP transport layer instead of using the TCP transport layer, memory requirements are reduced, and applications running on the hand-held device have reliable data transfers performed on their behalf. Additionally, the use of standardized components, such as the UDP transport layer and a standard network layer like the IP layer, enables the handheld device to efficiently communicate with many other devices in a standardized manner. The disclosed system provides reliable communication by utilizing a UDP+ layer on top of the UDP transport layer. The UDP+ layer acts as an interface between the application layer and the UDP layer both to provide reliable communication to the application layer and to hide the complexities involved with performing this functionality from the application layer. To provide reliable communication, the UDP+ layer acknowledges all messages received, and the UDP+ layer utilizes a retry timer such that when receipt of a message has not been acknowledged and the retry timer expires, the UDP+ layer resends the message. The value of the retry timer as well as other values used during retransmission of the message are user-configurable and may be changed by the user to optimize performance. Also, the UDP+ layer utilizes a number of messages that are used to open a connection, transfer data, and close a connection. Under a first embodiment of the present invention, a method is provided in a data processing system for transferring data between a client and a server via wireless communications. Both the client and the server have an unreliable transport layer that unreliably transfers the data. The client sends a message containing a portion of the data to the server via the unreliable transport layer of the client and the wireless communications. The client also sets a retry timer to a user-configurable value such that if the retry timer expires before receiving an acknowledgment to the message indicating that the message has been successfully transferred to the server, the client resends the message. Additionally, the client receives an acknowledgment indicating the successful transfer of the message and cancels the retry timer responsive to receiving this acknowledgment. Under a second embodiment of the present invention, a method is provided in a data processing system for transferring data between a client and a server via wireless communications. Both the client and the server have an unreliable transport layer that unreliably transfers the data. The server sends a message containing a portion of the data to the client via the unreliable transport layer of the server and the wireless communications. The server also sets a retry timer to a user-configurable value, determines whether the retry timer has expired, and determines whether the server has received an acknowledgment indicating that the message has been successfully transferred to the client. When the retry timer has expired and the server has not received the acknowledgment, the server resends the message to the client.

Under a third embodiment of the present invention, a client device for transferring data to a server device via wireless communications is provided. The client device includes the following components: a wireless communications subsystem for transferring the data to the server; a memory containing an unreliable transport layer, a reliability-providing component, and a computer program; and a processor for running the unreliable transport layer, the reliability-providing component, and the computer program. The unreliable transport layer unreliably transfers the data to the server via the wireless communications subsystem. The reliability-providing component reliably transfers the data over the unreliable transport layer to the server device, and if the reliability-providing component does not receive an acknowledgment indicating that the data message has been received by the server device within a user-configurable amount of time, the reliability-providing component resends the data message to the server device. The computer program provides the data to the reliability-providing component for the reliable transfer of the data to the server device.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 depicts a conventional TCP/IP protocol stack. Figure 2 depicts a data processing system suitable for practicing an exemplary embodiment of the present invention. Figure 3 depicts a more detailed diagram of a server computer of Figure 2.

Figure 4 depicts a more detailed diagram of a connection structure of the server computer of Figure 3. Figure 5A depicts a graph comparing the retry strategies of a conventional system (TCP/IP) and an exemplary embodiment (UDP+).

Figure 5B depicts a flowchart of the steps performed during retry processing.

Figure 6 depicts a more detailed diagram of a client computer of Figure 2. Figure 7 A depicts a format of a UDP message.

Figure 7B depicts a message format utilized by UDP+ layers of both the client and the server depicted in Figures 3 and 6.

Figures 8A, 8B, and 8C depict a flowchart of exemplary steps performed by the client UDP+ layer of Figure 6 when transferring data to the server UDP+ layer of Figure 3.

DETAILED DESCRIPTION OF THE INVENTION

An exemplary embodiment of the present invention provides reliable communication over the UDP transport layer in a hand-held device. By providing reliable communication over the UDP transport layer instead of using the TCP transport layer, memory requirements are reduced, and applications running on the hand-held device have reliable data transfers performed on their behalf. Additionally, the use of standardized components, such as the UDP transport layer and a standard network layer like the IP layer, enables the hand-held device to efficiently communicate with many other devices in a standardized manner. An exemplary embodiment provides reliable communication by utilizing a

UDP+ layer on top of the UDP transport layer. The UDP+ layer acts as an interface between the application layer and the UDP layer both to provide reliable communication to the application layer and to hide the complexities involved with performing this functionality from the application layer. To provide reliable communication, the UDP+ layer acknowledges all messages received, and the UDP+ layer utilizes a retry timer such that when receipt of a message has not been acknowledged and the retry timer expires, the UDP+ layer resends the message. The value of the retry timer as well as other values used during retransmission of the message are user-configurable and may be changed by the user to optimize performance. Also, the UDP+ layer utilizes a number of messages that are used to open a connection, transfer data, and close a connection. The format of the messages and their use are further described below.

To provide a thorough understanding of the present invention, the following description sets forth numerous specific details, such as particular messages and fields within messages. One skilled in the art, however, will recognize that the present invention can be practiced without the specific details, or with other messages or fields within messages. In other instances, well-known structures and methods are not described in detail to avoid obscuring the present invention.

Figure 2 depicts a data processing system 200 that is suitable for practicing an exemplary embodiment of the present invention. The data processing system 200 contains a server computer 202 ("server") and a client hand-held device 204 ("client") that are communicating using radio frequency or other wireless communications via antennae 206 and 208, respectively. In an exemplary embodiment, the client 204 is a bar-code reader that reads or receives bar-code information and then transmits the bar-code information to the server 202. However, one skilled in the art will appreciate that the present invention can be utilized with other systems communicating via wireless communications.

Figure 3 depicts a more detailed diagram of the server 202. The server 202 contains a memory 302, a secondary storage device 304, an input device 306, a radio communication subsystem 308, a video display 309, and a central processing unit (CPU) 310. The memory 302 contains an application program 312, a UDP+ layer 314, a UDP transport layer 316, an IP network layer 318, a link layer 320, and a connection structure 322. The application program 312 receives bar-code information from the client 204 and stores the bar-code information onto or within the secondary storage device 304, so that this information can then be used for generating reports, such as an inventory report of the types and numbers of inventory items located in a remote warehouse. The UDP+ layer 314 provides reliable communication over the UDP layer 316, and the UDP+ layer provides an interface 324 to the application program 312, so the application program can determine the connection status of a particular client (i.e., whether the client is connected or disconnected). To perform this processing, the UDP+ layer 314 utilizes a connection structure 322 that stores connection-related information for the clients with which it communicates. The UDP layer 316 is a standard UDP layer and conforms with Request for Comments (RFC) 768, J. Postel, "User Datagram Protocol," 1980. Similarly, the IP layer 318 is a standard IP layer and conforms to RFC 791, J. Postel, "Internet Protocol," 1981. The link layer 320 provides suitable functionality to interface with the hardware components of the radio communication subsystem 308. The radio communication subsystem 308 includes an antenna 206 and network interface hardware components that facilitate communication via radio frequencies to the client 204. Alternatively, the server 202 may utilize an Ethernet connection to an Ethernet/radio frequency bridge which is external to the server.

Although an exemplary embodiment is described as using the UDP and IP layers, one skilled in the art will appreciate that the present invention can be used with other transport and network layer protocols, including the NetBEUI transport protocol available from Microsoft Corporation of Redmond, WA, the internet packet exchange (IPX) network layer protocol available from Novell Corp. of Provo, UT, or the connectionless network protocol (CLNP) defined in ISO 8473 by the International Standards Organization.

The connection structure 322, as depicted in Figure 4, contains a number of entries, including entries 402 and 404. Each entry 402 and 404 contains connection- related information for an application program ("client application") on the client that communicates with the server. Each entry 402 and 404 contains the IP address 406 of the client application, the session number 408, an Rx value 410, a Tx value 412, a data pointer 414, an application ID 416, and a client state indication 418. The IP address 406, whose structure is well known, is a 32-bit address uniquely identifying the network address of the client application (e.g., 192.9.200.10). The session number 408 is a number assigned by the UDP+ layer to identify a communication session between the server and a particular client application (e.g., 55).

The Rx value 416 contains the message or sequence number for the next message that the UDP+ layer expects (e.g., 11). Each message transferred between the client and the server by the UDP+ layer has an associated, sequential message number. The Rx value 410 indicates the message number of the last message that the UDP+ layer acknowledged receiving plus one. In other words, the Rx value 410 indicates the next message number that the UDP+ layer expects to receive from the client. The Tx value 412 indicates the number of the most recent message received from the client (e.g., 10). The data pointer 414 is an address to a memory location containing the next amount of data to be transferred to the client (e.g., 507). For instance, when the server transfers a series of data messages to the client, this pointer refers to the data for the next message to be sent. The application ID 416 is an identifier of the particular application utilizing the UDP+ layer. For example, the application utilized by an exemplary embodiment is a bar-code scanner application used for inventory.

The client state field 418 indicates whether the client is connected to, disconnected from, or not responding to the server. A client 204 is "connected" when the UDP+ layer of the client and UDP+ layer of the server have both indicated a willingness or intention to be involved in a data transfer. Establishing a connection is a necessary prerequisite for UDP+ to perform a data transfer; as such, UDP+ provides a connection-oriented protocol.

A client can be "disconnected" either explicitly or implicitly. For an explicit disconnection, the server UDP+ layer and the client UDP+ layer exchange messages indicating their intention to terminate the connection. An implicit disconnect occurs when the server UDP+ layer has not received a message for more than a predetermined amount of time ranging between 1 and 3,600 minutes. The server UDP+ layer determines when such a time has expired by setting a dead horse timer, and when this timer expires without receiving a message from the client UDP+ layer, the server UDP+ layer changes the client's connection status to disconnected. A client 204 is "not responding" when the server's UDP+ layer has sent a given message to the client a predetermined number of times (e.g., 7) requesting an acknowledgment and, each time, an acknowledgment was not received. After either the client UDP+ layer or the server UDP+ layer sends a message without receiving an acknowledgment, the message is resent when a retry timer expires, which is initially set to a configurable, predetermined value ranging between 300 milliseconds and 60 seconds. Each time the retry timer expires and a message is resent, the retry timer value increases by approximately 40%, but never exceeds a user-configurable ceiling of 60 seconds. The server UDP+ layer considers the client 204 to be not responding when the server UDP+ layer has sent the message to the client a predetermined number of times (e.g., 7) without receiving an acknowledgment. This predetermined number of times is known as the max retries value and may be user-configurable. The server UDP+ layer may not receive an acknowledgment because of faulty communications.

When retransmitting a message in an exemplary embodiment, the system follows an underlying assumption that differs from some protocol stacks. The assumption made by some protocol stacks, like TCP/IP, is that when a message does not reach its destination, it is because the network has too much traffic, which is a condition that may not subside for a long time. Thus, since these protocol stacks assume that the condition which caused the transmission failure will not change for a long time, when a message does not reach its destination, the protocol stacks retransmit the message and double the value of the retry timer.

Although this solution works well in an environment like the Internet, the doubling of the retry timer value quickly leads to an unacceptably long time to wait for retransmission in other environments, like hand-held devices communicating via wireless communications. In such devices, when a message does not reach its destination, it is often not due to an increase in network traffic; rather, it is most likely due to interference which will be temporary. Therefore, since the transmission failure is due to a temporary condition which will be resolved in a relatively short amount of time, the hand-held device can attempt retransmission more quickly than when the transmission failure is due to network traffic. An exemplary embodiment uses this underlying assumption as the basis for its retransmission strategy.

To further illustrate the differences between the retry strategies of the TCP/IP protocol stack and an exemplary embodiment, Figure 5A depicts a comparison between the values of the retry timers for TCP/IP and an exemplary embodiment (UDP+). As shown in Figure 5A, the value of TCP/IP's retry timer increases much faster than the retry timer of UDP+. Additionally, the upper bound of TCP/IP is much higher than UDP+.

To better illustrate the processing performed during a retransmission of a message, Figure 5B depicts a flowchart of the steps performed when sending data by the server 202 of an exemplary embodiment. One skilled in the art will appreciate that the below-described steps may also be performed by the client 204. The first step performed by the server 202 is to send data to the client 204 (step 502). After sending the data, the server 202 sets a retry timer (step 504). The server 202 calculates the value of the retry timer using the following variables and formulae:

Variables

ALPHA Smoothing factor of 0.7 - user configurable

SRTT Smoothed Round Trip Time (calculated below)

RTT The measured round trip time of the last message that received an acknowledgment (i.e., the time elapsed between sending a message and receiving an acknowledgment) uBound Acknowledgment timeout upper bound ranging from 2 sec. to 60 sec. - user configurable, the range of values has been empirically proven to yield the best performance for a hand-held device communicating via wireless communications. lBound Acknowledgment timeout lower bound ranging between 200 ms to 2 sec. - user configurable, the range of values has been empirically proven to yield the best performance for a hand-held device communicating via wireless communications.

BETA Delay variance factor (e.g., 1.3) - user configurable ATO Acknowledgment timeout or retry timer value (calculated below)

Formulae

SRTT = (ALPHA * SRTT) + ((1 -ALPHA) * RTT) ATO = min[uBound, max[lBound,BETA*SRTT)]]

The "ATO" is the value to be used for the retry timer. If this value is less than the value of lBound, the value in lBound is used as the ATO value. After setting the retry timer to the ATO value, the server 202 determines if it has received an acknowledgment for the message (step 506). If the server 202 has received an acknowledgment, the server updates the round trip time (RTT) by calculating the amount of time elapsed between sending the data in step 502 to receiving the acknowledgment in step 506 (step 508). After updating the RTT, the server 202 determines if there is more data to be sent (step 512). If no more data is to be sent, processing ends. However, if there is more data to be sent, processing continues to step 502, and the additional data is sent. If the server 202 did not receive an acknowledgment, eventually the retry timer expires (step 514). After the retry timer expires, the server determines if the maximum allowable number of retries has occurred (step 516). The maximum allowable number of retries is contained in the max retries value, which is a user-configurable value ranging from 1 to 99 that indicates the number of times that a message should be retransmitted before the destination is considered to be not responding If the server 202 has resent a message a number of times equivalent to the max retries value, the server indicates in the connection structure that the client is not responding and continues to step 520 (step 518) However, if the message has not been sent a number of times equivalent to the maximum number of retries, the server updates the value of the retry timer (step 520) The value is updated by multiplying the current value of ATO by the square root of 2 (i.e., 1 4142) However, if this new value exceeds the upper bound (uBound), then the value of uBound is used After updating the timer, the server resends the data (step 522) and continues to step 506 All of the values described as being used in conjunction with retry processing are user-configurable, which allows the user to optimize performance That is, the user can specify a value for uBound, lBound, ALPHA, BETA, and the max retries value This user configurability is used to facilitate the underlying assumption that a message needing to be resent is not due to network traffic, but rather is due to faulty communications because of the nature of wireless communications

Figure 6 depicts a more detailed diagram of the client 204 In an exemplary embodiment, the client 204 is a hand-held bar-code scanner containing a memory 602, a CPU 604, a display 606, a keypad input device 608, a radio communication subsystem 610 similar to that described relative to Figure 3, and a bar- code input device 612 The memory 602 contains an application program 614 for reading bar-code data from inventory items and for sending this data to the server 202, a UDP+ layer 616, a UDP layer 618, an IP layer 620, and a link layer 622 The UDP+ layer 616 provides reliable communication over the UDP layer 618 The UDP layer 618, the IP layer 620, and the link layer 622 perform similar functionality to their respective counterparts as described relative to Figure 3 The bar-code input device 612 reads bar codes and contains a light source 624, a receiver/converter 626, and a sensor 628. The sensor 628 receives the light reflected from a bar code and converts this light into an electrical signal. For example, the light source 624 may be a laser, while the sensor 628 may be a photodetector. Alternatively, the light source 624 may be an LED, flashbulb, infrared light source, or other light-emitting element, while the sensor 628 may be a CCD, semiconductor array, vidicon, or other area imager capable of converting received light into electrical signals. The receiver/converter 626 receives the electrical signal from the sensor 628 and converts it into a signal to be processed by the CPU 604. Typically, the sensor 628 produces an analog signal that represents the modulated light reflected from the elements in the bar code. A bar-code input device suitable for use with the client 204 is more clearly described in U.S. Patent No. 5,486,689, entitled "Method and Apparatus for Decoding Unresolved Multi-Width Bar Code Symbology Profiles," issued January 23, 1996, and assigned to a common assignee, which is hereby incorporated by reference. Although a suitable bar-code input device has been described, one skilled in the art will appreciate that other bar-code or data collection symbol input devices may be used.

The UDP+ layers of both the client and server utilize a protocol that provides reliable communications over an unreliable UDP layer. This protocol specifies particular types and formats of messages, which are stored in a UDP packet and passed to the UDP layer for transfer. Figure 7A shows the standard protocol data packet layout for a UDP 700 packet as defined by RFC 768. This packet 700 contains a 20-byte, well- known IP header 702, an 8-byte, well-known UDP header 704, and variable-length UDP data 706. The messages transferred by the UDP+ layers specify a format for the UDP data 706 as shown in Figure 7B.

The UDP+ message format for the UDP data 706 has a number of fields as shown in Figure 7B, including a 2-byte length field 708 indicating the entire length of the UDP+ data 706, a 6-byte reserved field 710, a 1-byte version identifier 712 indicating the version of UDP+ that both the client and server are utilizing, a Tx field or value 714 indicating the message number of the message, an Rx field or value 716 indicating the next message number that either the client UDP+ layer or the server UDP+ layer is expecting, a 1-byte control field 718 indicating the particular type of message, and a variable length data field 720 used for transmitting data in the messages. The data field 720 may include any data to be transferred, such as bar code information. The message format of the UDP data 706 is a generic format utilized by the UDP+ layer of an exemplary embodiment for all the different types of messages.

As previously stated, the control field 718 of the UDP data 706 differs depending upon the type of message transferred. There are ten messages utilized by the

UDP+ layer of an exemplary embodiment, although one skilled in the art will appreciate that additional or different messages can be used. The below table describes each of the various messages.

Figures 8A, 8B, and 8C depict a flowchart of an exemplary usage of the previously described messages by both the UDP+ layer 314 on the server and the UDP+ layer 616 on the client. As such, this flowchart describes the use of the retry timer, the use of the watchdog message, and other features of the system that facilitate the reliable transfer of data. This flowchart chronologically presents both the client and server UDP+ layer's processing. Although the example describes the client sending data to the server, one skilled in the art will appreciate that the server can likewise send data to the client. In response to being invoked by the client application 614, the client UDP+ layer 616 starts a data transfer by initiating a connection and sending a connect request to the server UDP+ layer 314 (step 802). The server UDP+ layer 314 receives the connect request and sends a connect response to the client UDP+ layer 616 (step 804). The client UDP+ layer 616 receives the connect response and sends a second connect response (step 806). The server UDP+ layer 314 receives the second connect response and changes the connection status of the client application 614 to indicate that the client application is connected to the server (step 808). In this step, the server UDP+ layer 314 accesses the connection structure and changes the client application's status field 418 to indicate that the client application 614 is connected. After this processing, a connection has been established, and the client UDP+ layer 616 and the server UDP+ layer 314 can transfer data back and forth.

After the connection has been established, the client UDP+ layer 616 sends a data message to the server UDP+ layer 314 and sets the retry timer (step 810). The data for the data message is received from the client application 614. The retry timer is a timer set to a value as previously described (e.g., 300 ms to 5 sec.) such that if the client UDP+ layer 616 does not receive an acknowledgment to the data message within this time, the client UDP+ layer will resend the message, thus facilitating the reliable transfer of the data to the server UDP+ layer 314. In this example, the server UDP+ layer 314 receives the data message and sends an IAck message to the client UDP+ layer 616 (step 812). The server UDP+ layer 314 also sets a dead horse timer to a value such as a user-configurable value, ranging between 1 and 3,600 minutes. If the dead horse timer expires before the server UDP+ layer 314 receives a message from the client UDP+ layer 616, then the server UDP+ layer changes the client application's connection status to disconnected, thus implicitly disconnecting the client application. In this example, the client UDP+ layer 616 receives the IAck message and cancels the retry timer (step 814).

Eventually, the client UDP+ layer 616 receives more data from the client application 614 that needs to be sent to the client UDP+ layer 616. Consequently, the client UDP+ layer 616 both sends a second data message to the server UDP+ layer 314 and sets the retry timer (step 816). After sending the second data message, the retry timer expires before the client UDP+ layer 616 receives an acknowledgment (step 818 in Figure 8B). The expiration of the retry timer indicates that an acknowledgment has not been received in a sufficient amount of time, and therefore, the client UDP+ layer 616 resends the second data message (step 820). The client UDP+ layer 616 then increases the retry timer value by a predetermined increment, such as 41%, and resets the retry timer (step 822). The increase has a ceiling or upper boundary that the retry timer will not exceed. The ceiling, which is configurable, ranges between 2 seconds and 60 seconds. It should be appreciated that, due to the sometimes unreliable nature of wireless communications, the second data message may not arrive at the server UDP+ layer. In this situation, the processing of step 822 is repeated, and if the message has been resent a number of times equivalent to the max retries value, the client UDP+ 616 will change the server application's connection status to not responding. After the client UDP+ layer 616 increases the timer value and resets the timer, the server UDP+ layer 314 receives the resent data message, sends an IAck message to the client UDP+ layer 616, and resets the dead horse timer (step 824). The client UDP+ layer 616 receives the IAck message and cancels the retry timer (step 826).

At this point in the client UDP+ layer's processing, the client UDP+ layer 616 may not have data to send to the server UDP+ layer 314, because the client application 614 has not provided it with any. However, the client UDP+ layer 616 may want to remain connected to the server UDP+ layer 314, because the client application 614 eventually will have more data and does not want to incur the overhead of reestablishing the connection. Therefore, to keep the connection alive, the client UDP+ layer 616 sets a watchdog timer, so that the client UDP+ layer will be notified when it should send a watchdog message to the server UDP+ layer to keep the connection alive (step 828). When the watchdog timer expires (step 830), the client UDP+ layer 616 sends the watchdog message to the server UDP+ layer 314 (step 832). The server UDP+ layer 314 receives the watchdog message, sends a watchdog response to the client UDP+ layer 616, and resets the dead horse timer (step 834). The client UDP+ layer 616 receives the watchdog response (step 836). Assuming that the client application 614 has completed sending all of the desired data to the server, the client application may instruct the client UDP+ layer 616 to terminate the connection; in this case, the client UDP+ layer sends a disconnect message to the server UDP+ layer 314 (step 838 in Figure 8C). The server UDP+ layer 314 receives the disconnect message and changes the client application's status in the connection structure from connected to disconnected (step 840). The server UDP+ layer 314 then sends a disconnect acknowledgment to the client UDP+ layer 616 (step 842), and the client UDP+ layer receives the disconnect acknowledgment (step 844). At this point, both the client UDP+ layer 616 and the server UDP+ layer 314 are disconnected and must reestablish a connection before they can transfer data.

The connection-related processing performed by an exemplary embodiment is described in greater detail in copending U.S. Patent Application No.08/851,848 entitled "Providing Reliable Communication Over an Unreliable Transport Layer in a Hand-Held Device Using a Persistent Session," assigned to a common assignee and filed on even date herewith, which is hereby incorporated by reference.

While the present invention has been described with reference to an exemplary embodiment thereof, those skilled in the art will know of various changes in form and detail that may be made without departing from the spirit and scope of the claimed invention as defined in the appended claims. Such changes may include different messages being transferred between the client UDP+ layer and server UDP+ layer, different fields being utilized within the messages, and different counter values used in the messages.

In general, the terms used in the following claims should not be construed to limit the invention to the specific embodiments disclosed in both the specification and the claims, but should be construed to include all systems that operate in accordance with the claims. Accordingly, the invention is not limited by the disclosure, but instead its scope is to be determined entirely by the following claims.

Claims

CLAIMSWhat is claimed is:

1. A method in a data processing system for transferring data between a hand-held bar-code scanner client and a computer server via wireless communications, the client and the server each having a radio communications subsystem for transferring data, an internet protocol (IP) link layer for interfacing with the radio communication subsystem, and a user datagram protocol (UDP) layer for interfacing with the IP layer, comprising the steps of: the client creating a connect message requesting establishment of a connection with the server, storing the connect message in a first packet suitable to the UDP layer of the client, and invoking the UDP layer of the client to send the packet to the server as a first datagram message, wherein the UDP layer of the client passes the first datagram message to the IP layer of the client, and wherein the IP layer of the client sends the first datagram message to the server via the radio communications subsystem of the client; the server receiving the connect message, establishing a connection with the client, creating a response message indicating that the connection has been established, storing the response message into a second packet that is suitable to the UDP layer of the server, and invoking the UDP layer of the server to send the second packet to the client as a second datagram message, wherein the UDP layer of the server passes the second datagram message to the IP layer of the server, and wherein the IP layer of the server sends the second datagram message to the client via the radio communications subsystem of the client; the client receiving the response message, sending a data message to the server, and setting a retry timer, the data message requesting acknowledgment that the data message has been received by the server; the server receiving the data message and sending an acknowledgment to the client indicating that the data message has been received; the client receiving the acknowledgment such that the data transfer has been completed, canceling the retry timer responsive to the receipt of the acknowledgment, and sending a disconnect message to the server requesting termination of the connection; the server receiving the disconnect message, disconnecting the client, and sending a disconnect response to the client indicating termination of the connection; and the client receiving the disconnect response such that the connection is terminated and a new connection must be established before transferring additional data.

2. The method of claim 1 wherein the step of the client receiving the acknowledgment includes the steps of calculating a round trip time which is an amount of time elapsed between the sending of the first message and the receiving of the acknowledgment, sending a second data message to the client, and adjusting the value of the retry timer proportional to the calculated round trip time.

3. The method of claim 1 wherein the server has a data structure containing connection-related information, wherein the data structure has an entry for the client with an indication of whether the client is connected, and wherein the method further includes the steps of the server sending a second data message to the client a predetermined number of times without receiving an acknowledgment to the second data message and storing an indication in the entry that the client is not responding responsive to sending the second data message to the client the predetermined number of times without receiving the acknowledgment to the second data message.

4. A method in a data processing system for transferring data between a client and a server via wireless communications, the client and the server having an unreliable transport layer for unreliably transferring the data, the method performed by the client comprising the steps of: sending a first message containing a portion of the data to the server, wherein the message is sent to the server via the unreliable transport layer of the client and the wireless communications; and receiving an acknowledgment indicating the successful transfer of the message from a source communicating over the unreliable transport layer of the server.

5. The method of claim 43, further including the step of canceling the retry timer responsive to the receiving the acknowledgment.

6. The method of claim 4, further including the steps of sending a second message to the server, calculating a value for a retry timer that is based on an amount of time elapsed between the step of sending the first message and the step of receiving an acknowledgment, and setting the retry timer to the calculated value such that, if the retry timer expires before receiving an acknowledgment to the second message, the client resends the second message.

7. The method of claim 4, further including the steps of sending a second message to the server, calculating a value for a retry timer that is based on an amount of time elapsed between the step of sending the first message and the step of receiving an acknowledgment, determining whether the calculated value is within a predefined range, and when the calculated value is within the predefined range, setting the retry timer to a predefined value such that, if the retry timer expires before receiving an acknowledgment to the second message, the client resends the second message.

8. The method of claim 4 wherein the unreliable transport layer is a standard transport layer.

9. The method of claim 4 wherein the unreliable transport layer is a user datagram protocol transport layer.

10. The method of claim 4 wherein the client has an internet protocol network layer for interfacing between the unreliable transport layer and the wireless communications.

11. The method of claim 4 wherein the wireless communications is radio frequency-based communications, and wherein the step of sending a message includes sending the message to the server via the radio frequency-based communications.

12. The method of claim 4 wherein the client and the server have an established connection, and wherein the method further includes the steps of determining when a user-configurable amount of time has expired since the acknowledgment was received without sending a second portion of the data to the server, and when it is determined that the user-configurable amount of time has expired since the acknowledgment was received without sending the second portion of the data, sending a watchdog message to the server indicating that the client wants to remain connected.

13. The method of claim 4, further including the steps of sending a second message containing a second portion of the data to the server, setting a retry timer to a user- configurable value, determining when the retry timer has expired and the client has not received an acknowledgment to the second message, and when it is determined that the retry timer has expired and the client has not received the acknowledgment to the second message, resending the second message to the server, and setting the retry timer to the user- configurable value plus an additional predetermined increment.

14. The method of claim 4, further including the steps of sending a second message containing a second portion of the data to the server, setting a retry timer to a user- configurable value, determining when the retry timer has expired and the client has not received an acknowledgment to the second message, and when it is determined that the retry timer has expired and the client has not received the acknowledgment to the second message, resending the second message to the server, and setting the retry timer to the user- configurable value times a square root of 2.

15. A method in a data processing system for transferring data between a client and a server via wireless communications, the client and the server having an unreliable transport layer for unreliably transferring the data, the method performed by the server comprising the steps of: sending a message to the client containing a portion of the data, wherein the server sends the message via the unreliable transport layer of the server and the wireless communications; setting a retry timer to an expiration value; receiving an indication that the retry timer has reached the expiration value; and and when the retry timer has reached the expiration value and the server has not received an acknowledgment indicating that the message has been successfully transferred to the client, resending the message to the client.

16. The method of claim 15 wherein the step of resending includes setting the retry timer to a user-configurable value plus a predetermined increment.

17. The method of claim 15 wherein the step of resending the message includes determining a number of times that the message has been resent, and when the message has been resent more than a predefined number of times, indicating that the client is not responding.

18. The method of claim 15 wherein the unreliable transport layer is a standard transport layer.

19. The method of claim 15 wherein the unreliable transport layer is a user datagram protocol transport layer.

20. The method of claim 15 wherein the client has an internet protocol network layer for interfacing between the unreliable transport layer and the wireless communications.

21. A client device for transferring data to a server device via wireless communications, comprising: a wireless communications subsystem for transferring the data to the server; a memory, further comprising: an unreliable transport layer for unreliably transferring the data to the server via the wireless communications subsystem; a reliability-providing component for reliably transferring the data over the unreliable transport layer; and a computer program for providing the data to the reliability-providing component for the reliable transfer of the data to the server device; and a processor for running the unreliable transport layer, the reliability-providing component, and the computer program.

22. A bar-code scanner for transferring data to a computer, comprising: a radio communications subsystem for transferring the data to the computer; a bar-code input device that reads bar codes and generates bar-code information; a memory, further comprising: a user datagram protocol transport layer for transferring the data to the server as a series of datagram messages via the radio communications subsystem; a connection component for reliably transferring the data over the user datagram protocol transport layer; and an application program or receiving the bar-code information from the bar-code input device and for transferring the bar-code information to the computer using the reliable communications provided by the connection component; and a processor for running the user datagram protocol transport layer, the connection component, and the application program.

23. A computer for transferring data to a plurality of clients via wireless communications, comprising: a wireless communications subsystem for transferring the data to the plurality of clients; a memory, further comprising: a connectionless transport layer for transferring data to the plurality of clients via the wireless communications subsystem; a connection data structure for storing an indication of whether each of the plurality of clients is connected with the computer; a connection-providing component for providing connection-oriented communications over the connectionless transport layer and for providing access to the connection data structure; and an application program for invoking the connection-providing component to transfer a portion of the data to a first of the clients, for requesting the connection-providing component to return an indication of whether a second of the clients is connected, and for receiving the indication of the second client from the connection-providing component; and a processor for running the connectionless transport layer, the connection- providing component, and the application program.

24. A data structure encoded on a computer-readable memory device for use in maintaining a connection between a server and a plurality of clients when transferring data, the data structure having entries, each entry comprising: a client identifier indicating one of the plurality of the clients; and an indication of whether the client is connected to the server, disconnected to the server, or not responding to the server, the server transferring data to the plurality of clients using a reliability component that provides for the reliable transfer of the data over an unreliable transport layer using wireless communications, the client not responding to the server when a portion of the data has been sent to the server, an acknowledgment indicating successful transfer of the portion has not been received within a user-configurable amount of time, and the server has resent the portion to the client a user-configurable number of times without receiving the acknowledgment.

25. The data structure of claim 24 wherein the client identifier is an internet protocol address.

26. A computer-readable medium containing instructions for controlling a data processing system to perform a method for transferring data between a client and a server via wireless communications, the client and the server having an unreliable transport layer for unreliably transferring the data, the method performed by the client comprising the steps of: sending a message containing a portion of the data to the server, wherein the message is sent to the server via the unreliable transport layer of the client and the wireless communications; and receiving an acknowledgment indicating a successful transfer of the message from a source communicating over the unreliable transport layer of the server.

27. The computer-readable medium of claim 26, further including the steps of sending a second message to the server, calculating a value for a retry timer that is based on an amount of time elapsed between the step of sending a first message and the step of receiving an acknowledgment, and setting the retry timer to the calculated value such that, if the retry timer expires before receiving an acknowledgment to the second message, the client resends the second message.

28. The computer-readable medium of claim 26, further including the steps of sending a second message to the server, calculating a value for a retry timer that is based on an amount of time elapsed between the step of sending a first message and the step of receiving an acknowledgment, determining whether the calculated value is within a predefined range, and when the calculated value is within the predefined range, setting the retry timer to a predefined value such that, if the retry timer expires before receiving an acknowledgment to the second message, the client resends the second message.

29. The computer-readable medium of claim 26 wherein the unreliable transport layer is a standard transport layer.

30. The computer-readable medium of claim 26 wherein the unreliable transport layer is a user datagram protocol transport layer.

31. The computer-readable medium of claim 26 wherein the client has an internet protocol network layer for interfacing between the unreliable transport layer and the wireless communications.

32. The computer- readable medium of claim 26 wherein the wireless communications is radio frequency-based communications.

33. The computer-readable medium of claim 26 wherein the client and the server have an established connection, and wherein the method further includes the steps of determining when a user-configurable amount of time has expired since the acknowledgment was received without sending a second portion of the data to the server, and when it is determined that the user-configurable amount of time has expired since the acknowledgment was received without sending the second portion of the data, sending a watchdog message to the server indicating that the client wants to remain connected.

34. The computer-readable medium of claim 26, further including the steps of sending a second message containing a second portion of the data to the server, setting a retry timer to the user-configurable value, determining when the retry timer has expired and the client has not received an acknowledgment to the second message, and when it is determined that the retry timer has expired and the client has not received the acknowledgment to the second message, resending the second message to the server, and setting the retry timer to the user-configurable value plus an additional predetermined increment.

35. The computer- readable medium of claim 26, further including the steps of sending a second message containing a second portion of the data to the server, setting a retry timer to the user-configurable value, determining when the retry timer has expired and the client has not received an acknowledgment to the second message, and when it is determined that the retry timer has expired and the client has not received the acknowledgment to the second message, resending the second message to the server, and setting the retry timer to the user-configurable value times a square root of 2.

36. A computer-readable medium containing instructions for controlling a data processing system to perform a method for transferring data between a client and a server via wireless communications, the client and the server having an unreliable transport layer for unreliably transferring the data, the method performed by the server comprising the steps of: sending a message to the client containing a portion of the data, wherein the server sends the message via the unreliable transport layer of the server and the wireless communications; setting a retry timer to a user-configurable value; receiving an indication that the retry timer has expired; and when the retry timer has expired and the server has not received an acknowledgment indicating that the message has been successfully transferred to the client, resending the message to the client.

37. The computer-readable medium of claim 36 wherein the step of resending includes setting the retry timer to the user-configurable value plus a predetermined increment.

38. The computer-readable medium of claim 36 wherein the step of resending the message includes determining a number of times that the message has been resent, and when the message has been resent more than a predefined number of times, indicating that the client is not responding.

39. The computer- readable medium of claim 36 wherein the unreliable transport layer is a standard transport layer.

40. The computer-readable medium of claim 36 wherein the unreliable transport layer is a user datagram protocol transport layer.

41. The computer-readable medium of claim 36 wherein the client has an internet protocol network layer for interfacing between the unreliable transport layer and the wireless communications.

42. The method of claim 1 wherein the retry timer may be set to a user- configurable value.

43. The method of claim 4, further including the step of setting a retry timer to a user-configurable value such that if the retry timer expires before receiving an acknowledgment to the first message, the client resends the first message.

44. The method of claim 4 wherein the wireless communications is frequency based communications.

45. The method of claim 4 wherein before sending the first message, the method performs the steps of: sending to the server a connection request that requests establishment of a connection between the client and the server; and

receiving a response from the server indicating that the connection has been established.

46 The method of claim 4 wherein the step of sending the first message includes the unreliable transport layer of the client sending the message to the server via the wireless communications as a datagram message

47 The method of claim 4 wherein the client and the server have an established connection, and wherein the method further includes the steps of sending a disconnect request to the server requesting that the established connection be terminated, and receiving a disconnect acknowledgment from the server indicating that the established connection has been terminated.

48 The method of claim 15 wherein the expiration value is user- configurable

49 The method of claim 15 wherein the wireless communications is radio frequency-based communications

50 The method of claim 15 wherein before receiving the message, the method performs the steps of receiving from the client a connection request that requests establishment of a connection between the client and the server, and sending a response to the server indicating that the connection has been established

51 The method of claim 15 wherein the step of sending an acknowledgment includes the unreliable transport layer sending the acknowledgment to the client via the wireless communications as a datagram message

52 The method of claim 15 wherein the server and the client have an established connection, and wherein the method further includes the steps of receiving a disconnect request from the client requesting that the established connection be terminated, and sending a disconnect acknowledgment to the client indicating termination of the established connection.

53. The method of claim 15 wherein the server has a program and wherein the method further includes the steps of receiving a request from the program to determine whether the client has a connection with the server such that the client and the server indicate an intention to transfer the data, determining whether the client is connected with the server, and returning to the program an indication of whether the client is connected with the server.

54. The method of claim 15 wherein the server has a program and a data structure containing an indication of whether the client is connected to the server such that the client and the server indicate an intention to transfer the data, and wherein the method includes receiving a request from the program to determine whether the client is connected to the server, determining whether the client is connected to the server by accessing the data structure to retrieve the indication, and returning the indication to the program.

55. The client device of claim 21 wherein the data is in the form of messages and wherein the reliability providing component transfers the data over the unreliable transport layer to the server device and if the reliability providing component does not receive an acknowledgment that the data has been received by the user device within a user- configurable amount of time, the reliability providing component resends the data to the server device.

56. The client device of claim 21 wherein the unreliable transport layer is a user datagram protocol transport layer.

57. The client device of claim 21, further including a standard network layer for interfacing between the unreliable transport layer and the wireless communications subsystem.

58. The client device of claim 21, further including an internet protocol network layer for interfacing between the unreliable transport layer and the wireless communications subsystem.

59. The bar-code scanner of claim 22 wherein the connection component sends the data as a plurality of messages and wherein the connection component resends a given message if the connection component does not receive an indication that the given message was received by the computer within a user-configurable amount of time.

60. The bar-code scanner of claim 22 wherein the memory further includes a standard network layer for interfacing between the user datagram protocol transport layer and the radio communications subsystem.

61. The bar-code scanner of claim 22 wherein the memory further includes an internet protocol network layer for interfacing between the user datagram protocol transport layer and the radio communications subsystem.

62. The bar-code scanner of claim 22 wherein the bar-code scanner is a hand-held device.

63. The computer of claim 23 wherein the connection-providing component provides connection-oriented communications by sending the data as a plurality of messages, wherein for each message the connection-providing component resends the message if an acknowledgment indicating that the message has been successfully transferred has not been received within a user-configurable amount of time, and wherein if a given message has been resent more than a predefined number of times without receiving an acknowledgment, the connection-providing component stores an indication in the connection data structure that the client to which the given message is destined is not responding.

64. The computer of claim 23 wherein the connectionless transport protocol is a user datagram protocol.

65. The computer of claim 23 wherein the memory further includes a standard network layer for interfacing between the connectionless transport layer and the wireless communications subsystem.

66. The computer of claim 23 wherein the memory further includes an internet protocol network layer for interfacing between the connectionless transport layer and the wireless communications subsystem.

67. The computer readable medium of claim 26 wherein the method performed by the client further comprises the following steps: setting a retry timer to a user-configurable value such that if the retry timer expires before receiving an acknowledgment to the message indicating that the message has been successfully transferred to the server, the client resends the message; and canceling the retry timer responsive to receiving the acknowledgment.

68. A method in a data processing system for transferring data between a hand-held bar-code scanner client and a computer server via wireless communications, the client and the server each having a radio communications subsystem for transferring data, an internet protocol (IP) link layer for interfacing with the radio communication subsystem, and a user datagram protocol (UDP) layer for interfacing with the IP layer, comprising the steps of: the client creating a connect message requesting establishment of a connection with the server, storing the connect message in a first packet suitable to the UDP layer of the client, and invoking the UDP layer of the client to send the packet to the server as a first datagram message, wherein the UDP layer of the client passes the first datagram message to the IP layer of the client, and wherein the IP layer of the client sends the first datagram message to the server via the radio communications subsystem of the client; the server receiving the connect message, establishing a connection with the client, creating a response message indicating that the connection has been established, storing the response message into a second packet that is suitable to the UDP layer of the server, and invoking the UDP layer of the server to send the second packet to the client as a second datagram message, wherein the UDP layer of the server passes the second datagram message to the IP layer of the server, and wherein the IP layer of the server sends the second datagram message to the client via the radio communications subsystem of the client; the client receiving the response message and sending a plurality of data messages to the server, each data message requesting acknowledgment that the data message has been received by the server; the server receiving the plurality of data messages and sending an acknowledgment to the client after receiving each data message indicating that the data message has been received; the client receiving the acknowledgments such that the data transfer is completed and sending a disconnect message to the server requesting termination of the connection; the server receiving the disconnect message, disconnecting the client, and sending a disconnect response to the client indicating a successful termination of the connection; and the client receiving the disconnect response such that the connection is terminated and a new connection must be established before transferring additional data.

69. A method in a data processing system for transferring data between a client and a server via wireless communications, the client and the server having an unreliable transport layer for unreliably transferring the data, the method performed by the client comprising the steps of: sending at least one message containing a portion of the data to the server, wherein the message is sent to the server via the unreliable transport layer of the client and the wireless communications; and receiving an acknowledgment indicating a successful transfer of the message from a source communicating over the unreliable transport layer of the server.

70. A computer-readable medium whose contents control a data processing system to perform a method for transferring data between a client and a server via wireless communications, the client and the server having an unreliable transport layer for unreliably transferring the data, the method performed by the server comprising the steps of: receiving at least one message from the client containing a portion of the data, wherein the client sends the message via the unreliable transport layer of the client and the wireless communications; and sending an acknowledgment to the client indicating that the portion of the data was transferred successfully, wherein the acknowledgment is sent to the client via the unreliable transport layer of the server and the wireless communications.