AU5343900A - An apparatus, a computer program product, and a method of transmitting data - Google Patents

Description

AUSTRALIA

Patents Act 1990 isoft GmbH

ORIGINAL

COMPLETE SPECIFICATION STANDARD PATENT a.

C

a Invention Title: a An apparatus, a computer program product, and a method of transmitting data The following statement is a full description of this invention including the best method of performing it known to us:- Documents received on' U 6 2 0 0 0 The invention relates to a data transmission apparatus, a computer program product, and a data transmission method.

In the state of the art data are transmitted, for instance, via the internet. The exchange of data, for example, between two computers is effected with the aid of internet protocols, in particular according to the so-called Transmission Control Protocol (TCP) and the so-called Internet Protocol (IP), briefly TCP/IP. To carry out the exchange, both computers are loaded with software which is capable of understanding and evaluating the TCP/IP (socket or TCP/IP stack).

:i The most rapidly growing internet service is based on the Hypertext Transfer Protocol (HTTP) and is called World Wide Web (WWW). This service is used to transmit individual documents, so-called web pages. HTTP is a client/server protocol. The user needs a client, such as a computer or a (mobile) telephone, and furthermore client software running on the same, the so-called web browser. The web browser requests a desired web page while opening a link from a web server which then returns the same to the web browser, establishing the desired connection with the browser.

The web pages of the WWW are based predominantly on the hypertext markup language (HTML), a static instruction language, which means that the web page, once mapped, cannot be changed.

To improve this situation, solutions like dynamic HTML (dHTML) have been devised by which dynamic changes can be made to individual elements on a web page while it is displayed. Other solutions are known which permit an interactive exchange of data between the browser and the server, such as the Common Gateway Interface (CGI) or Active Server Pages (ASP).

The internet is based on packet switching technology. The data transmitted via the internet are packaged in individual data packets which are sent independently of one another. A packet, in general, comprises less than 1500 characters. Each packet includes a checksum calculated by the transmitter on the basis of the data to be sent. At the receiving end it can thus be determined on the basis of the checksum whether or not errors occurred in the transmission.

The receiver likewise calculates a checksum on the basis of the data received and this checksum is compared with the checksum that was transmitted. If there is disagreement between the checksums the transmitter is requested to repeat transmission of the packet.

It is an object of the instant invention to provide a novel apparatus for data transmission, a novel computer program product, and a novel data transmission method, as compared to the state of the art.

These and further objects of the invention are met by a data transmission apparatus which transmits data in the form of successive data packets via a data circuit, especially a radio telephone link, comprising means for determining the transmission quality and/or means for determining the occurrence of a disconnection, the quantity of useful data transmitted per unit time, especially the length of a data packet transmitted being varied in response to the transmission quality determined and/or upon occurrence of a disconnection.

As regards the method, the above and further objects of the invention are met by a data transmission method by which data in the form of successive data packets are transmitted via a data circuit, especially a radio telephone link, the method comprising the steps of determining the transmission quality and/or determining the occurrence of a disconnection, varying the quantity of useful data transmitted per unit time in response to the transmission quality determined and/or upon occurrence of a disconnection.

The above and further objects of the invention, moreover, are met by the provision of a computer program product comprising instruction code sections by which the method specified above is caused to be carried out when the computer program runs on a terminal, especially a computer and/or a telephone.

As regards the expression "computer program product" used in the claims it should be noted that this is understood to be a computer program or a computer program module embodied by memorization on a magnetic storage medium or a volatile .or non-volatile semiconductor memory of the apparatus specified above, in particular a computer and/or a telephone) or by S. signals transmitted via a network, especially the internet.

The computer program need not exist in a form to be realized directly. Instead, it may also be available in a form ready to be intalled in the computer and/or telephone. And, of course, it may be packed, encrypted, divided into packets for forwarding through a network and provided with headers related to any such transmission, etc.

Advantageous further developments of the invention are defined in the subclaims. It is clear to those skilled in the art that a great many of these further developments can be used without the above mentioned variation of the quantity of useful data transmitted per unit time. For this reason the applicant reserves the right to direct future claims to subject matters which do not contain that feature.

According to an aspect of the invention, data are transmitted via a data circuit, especially a radio telephone link, in the form of a succession of data packets. Each data packet contains useful data and control data, preferably in predetermined order. Moreover, means are provided for determining the quality of the transmission and/or means for determining the occurrence of a disconnection. Furthermore, the quantity of useful data transmitted per unit time is varied in response to the transmission quality determined and/or upon occurrence of a disconnection. Transmission according to the invention thus is adapted specifically to the respective existing conditions of transmission, conditions which change frequently and dramatically in wireless data communication traffic.

The-transmission quality can be determined, for instance, by a server computer (or, alternatively, a client computer) sending confirmation signals to the apparatus, in particular a client computer (or, alternatively, a server computer). It is advantageous if the receiver confirms the correct receipt separately for each individual data packet. That can be ascer- S tained by the receiver in conventional manner, for instance, by evaluating checksum bits contained in the data packet.

Instead of generating a confirmation signal, the receiver, alternatively, can indicate a data packet not received correctly by sending an error signal. It is advantageous if the confirmation signal, or the error signal, contains a bit sequence to characterize the associated data packet.

Advantageously, the transmission quality is determined based on the relationship between the number of packets sent and the number of packets confirmed to be correct. The quality of the transmission is considered to be "poor" when this relationship fails to reach a certain desired value. Alternatively, the transmission quality can be graded "poor" if only a single data packet does not arrive properly.

The occurrence of a disconnection can be determined, for instance, in the case of a telephone communication by detecting a busy signal which the client or server computer will receive in such an instance, or by a network status.

It is advantageous to reduce the quantity of useful data transmitted per unit time when "poor" transmission quality has been determined and/or a disconnection has occurred. That is accomplished preferably by shortening the data packet length, thereby reducing the amount of useful data contained in a data packet. The advantage remains that the quantity of control data contained in each data packet is constant. Alternatively, it is conceivable to leave the data packet length as it is and instead reduce the quantity of useful data contained in it, such as by redundant transmission of data bits.

If one data packet got lost or was not transmitted properly it is advantageous not to transmit once more all those packets after the one that was lost or not transmitted correctly in contrast to the TCP/IP. Instead it is determined precisely .which were the packets that were sent successfully and which *were not and only the ones not sent successfully are then transmitted again.

It is especially preferred to implement the invention by way of software. In this context it is of advantage to install both on the client computer and on the server computer special *oo* software which includes instruction code sections mapping function calls of a TCP/IP socket interface, e.g. a Windows socket interface or, alternatively, any other internet interface in such a way that the above mentioned procedures will be carried out. In other words, the interface of the TCP/IP is translated by the software according to the invention into an original protocol which effects the above mentioned steps. A plurality of client/server applications can be supported by using the TCP/IP interface without having to make any special adjustments to the software according to the invention.

The data transmission according to the invention is advantageous, taking place as follows: If data are to be transmitted by a conventional software program loaded in the client or in the server to the server or the client, respectively, the program calls the (TCP/IP) internet interface, i.e. a corresponding software program. The client or server software, respectively, of the invention recognizes that data are to be transmitted to a specific server or client, respectively, in which the corresponding server or client software, respectively, according to the invention is installed. This is done, for example, through the internet address, telephone number, etc. In this event, the program according to the invention causes the mapping mentioned of the calls of the TCP/IP socket interface to take place, whereby the method steps mentioned above are carried out, for instance, by effecting corresponding.control of a modem.

It is especially advantageous to interrupt the connection automatically when the transmission quality is poor and then restore it again. Interruption of a connection can be achieved, for example, by causing the modem to send a corresponding telephone communication end signal to the corresponding client or server, respectively. Thereupon the connection is restored, for example, by transmitting the telephone communication dial signal corresponding to the telephone number of the server or client, respectively, in other words by dialing the server or client telephone number. After renewed dialing, often the transmission quality is much better, particularly with wireless telephone connections.

*It is advantageous if the apparatus according to the invention comprises a mobile telephone and/or a portable computer in which the software according to the invention is installed. It Sis especially preferred with the invention, after an intentional or unintentional disconnection, to transmit only data packets which had not been confirmed as faultless. It is advantageous after a disconnection to automatically dial the corresponding server or client, respectively, once more. The server or client, respectively, recognizes that this is a restoration of a connection after a disconnection, for example, because of the sequence number of the client or server software, respectively, the telephone number of the mobile radio telephone or the IMEI number, the International Mobile station Equipment Identity number.

It is especially advantageous with the invention that the connection is interrupted automatically, for example by the transmission of a telephone communication end signal if no data to be transmitted are given for a predetermined period of time of 1 minute, 30 seconds, or 10 seconds, for instance.

The connection is preferred when actually it should be closed according to the TCP/IP and yet is maintained for a predetermined period, such as for 1 minute, 30 seconds, or seconds. In this manner superfluous dialing attempts are avoided.

9.*Embodiments of the invention will be described in greater detail below, with reference to the accompanying drawings, in which: 1 is a diagrammatic representation of the protocol layers of the program system according to the invention; 9999 9 Fig. 2 is a diagrammatic representation of the communication between processes of the client component of fig. 1; Fig. 3 is a diagrammatic representation of states occurring with the Rapid Transport Protocol of fig. 1; Fig. 4 is a diagrammatic representation of sub-states of the IDLE state shown in fig. 3; Fig. 5 is a diagrammatic representation of sub-states of the CONNECTING state shown in fig. 3; Fig. 6 is a diagrammatic representation of sub-states of the CONNECTED state shown in fig. 3; Fig. 7 is a diagrammatic representation of sub-states of the FLOW STOPPED state shown in fig. 6; Fig. 8 is a diagrammatic representation of sub-states of the DISCONNECTING state shown in fig. 3; Fig. 9 is a diagrammatic representation of a data packet according to the invention; Fig. 10 is a diagrammatic representation of a section of the data packet shown in fig. 9; Fig. 11 is a diagrammatic representation of the data portion of a data packet transmitted at the beginning of a connection.

Fig. 1 diagramatically illustrates the protocol layers of MOBILEmanager, the program system 1 according to the invention. The program system 1 presents a Windows socket 4a, 4b based environment for client/server applications 5, 6. This environment is oriented towards utilization of mobile radio services, such as Modacom, GSM, or UMTS.

.The program system 1 consists of a server component 2 and a client component 3, the two presenting a communications interface on the basis of Windows sockets 4a, 4b for client/server applications 5, 6. In this manner a great number of customary client/server applications 5, 6 can be supported without having to make any adjustments.

oo•.

•oo.

Function calls of the socket interface 4a are mapped on a mobile medium (radio data transmission) by means of the client component 3 of the program system 1 according to the invention. To that end a modem, such as a Modacom modem 7, or a GSM modem 8, or an ISDN card 9 is driven by the client component 0* 3. The modem transmits the data to an associated base station or a modem server 11, or an ISDN server 12. The client/server application has no knowledge of the respective transmission medium. The server component 2 in turn maps the data received as protocol units from the base station 10, or the modem server 11, or the ISDN server 12, respectively, on the socket functions 4b. The server application 6 and the server component usually are located in a LAN environment to which the TCP connections of the client applications 5 are switched.

The client component 3 of the program system 1 according to the invention consists of the following processes/modules: MOBILEmanager.exe MOBILEmanager.dll The process MOBILEmanager.exe practices the following: management of the service provider interface (activation/deactivation of MOBILEmanager.dll) control of the trace level activities profile check and profile selection TAPI check and TAPI selection release of dialing independent of application handling of the RTProtocol and RLLProtocol.

All the API functions of the Winsock 2.0 service provider interface are carried into effect by the MOBILEmanager.dll process. Communication between the MOBILEmanager.dll 14 and MOBILEmanager.exe processes takes place through the shared memory 13, as indicated in fig. 2.

oo ~The MOBILEmanager.dll 14 process comprises the following submodules: socket interface This module provides all the function calls specified in the, Windows sockets 4a. All the functions operate exclusively on a set of internal control structures so that the client applications 5 cannot access the hardware directly.

process management Under the Windows 95 multitasking operating system it is possible for several client applications 5 to use the program system 1 according to the invention in parallel. The process management module distinguishes between different processes of client applications 5 so that data received can be associated with the correct process, for instance.

automatic control This module provides automatic control for each of the modem, ISDN, and modacom services. Hereby the physical states of the connection are controlled, such as a connection made, a connection interrupted, etc.

socket management This module provides all the functions for managing the individual socket states. This is also where the data allocation and realization of the RTProtocol takes place.

output buffer control In this module the transmission data are controlled as well as the received data queue.

modem interface control This is where the modem automatic states are converted into the RLLProtocol.

ISDN interface control This is where the ISDN automatic states are converted into the RLLP (radio link level protocol).

COM interface control This module guarantees a uniform interface for modem interface control, irrespective of the interface chosen, whether TAPI or COM-port.

11 TAPI interface This module realizes the following functions: log in upon TAPI/initialization; check whether a TSP having the requisite properties is present; make connection; transmit and receive data through the selected TSP; recognize when there is no carrier or the connection has been interrupted; terminate the connection actively; log out from TAPI.

COM-Direct interface This module provides the necessary functionality for communication with the direct COM port.

RTProtocol module The mapping proper of the Windows socket functions on protocol data and vice versa takes place in this module. The RTP is tailored especially for realizing TCP connections via radio data transmission.

modem control The modem control module consists of two submodules. The first is used to drive the modem, among others a GSM modem and a Motorola DataTAC modem, so that it will either transmit or receive data. During modem control error situations are noticed and responded to in an intelligent way.

RLLProtocol The RLLP implements error recognition and correction, where necessary, in the data transmission via radio networks.

The server component 2 of the program system according to the invention is utilized under the Linux, UNIX, or Windows NT operating systems. It consists of the following processes: Scrdaemon Scrproc The Scrdaemon is the core process. It manages all the TCP connections of all the modems connected, no matter whether GSM, ISDN, or Modacom is utilized as service. The protocol used for control of the modem is SCR, Standard Context Routing. The Scrdaemon process is connected to the respective Modacom service provider via protocol X.25 (DATEX-P). The SCR protocol permits control of any desired number of Modacom modems via a logical X.25 connection.

GSM, ISDN, and MODEM connections are connected to the Scrdaemon process by means of the Scrproc converter process.

The RLLP used on the physical connection is mapped on the SCR protocol by this process. The TCProtocol establishes the connection to the Scrdaemon process. The Scrproc process is activated when the client component 3 has dialed in.

The Scrdaemon process comprises two submodules too# core module SCR module The core module works on the RTProtocol and manages all TCP connections.

The SCR module serves for control of the modems. It processes the SCR protocol. TCP and X.25 are useful as the medium for SCR connections.

The protocols used with program system 1 according to the invention, as shown in fig. 1, will be explained below.

RTP Radiowave Transmission Protocol The RTP is used between the MOBILEmanager client and the MOBILEmanager server. Its principal function is to provide a mechanism by which TCP connections can be provided in the radio medium. A prerequisite for this protocol is the secure transmission of the PDUs as well as recognition and correction of any errors in the transmission. The PDUs themselves are very simple so as to avoid overhead which would give rise to transmission costs. The maximum PDU length is 2000 bytes, due to limitations of the SCR protocol. The first byte of each PDU is structured as follows: bit no. 8 bit no. 7 bit no. 6-1 The PDU is an instruction PDU if this bit is set. If the bit is not set it is a data PDU.

This bit must not be set except with data PDUs, in which case it indicates that the PDU contains V.42bis compressed data.

These six bits code a logical channel number.

Precisely one channel is allocated to each TCP connection from the client to the server. It should be noted that only channels 0 to 61 are used. Channels 62 and 63 are reserved for possible future enlargements.

RTP data PDU Under normal circumstances, the useful data of the PDU follow the first byte. Compressed useful data are indicated by bit no. 7 being set in the first byte. In view of the fact that utilization of the RTP together with the GSM modem may cause PDU duplication, an optional sequence number may be transmitted within the data PDU. The use of sequence numbers is negotiated during setup of a logical RTP connection. If sequence numbers indeed are used for an RTP connection they are located in the second byte of the PDU, while the useful data will begin as of the third byte only.

RTP command PDU Bits nos. 1 5 in the second byte define the instruction PDU if bit no. 8 is set in the first byte. The following is a list of all the instructions specified: Connect Request (command no. 1) This PDU must comprise at least one IP address and a port number for TCP connection setup. The IP address is contained in the PDU in bytes nos. 3 to 6. The order of the bytes is the Network Byte Order, i.e. the first byte of the IP address is at position no. 3, the second one at position no. 4, and so on. The IP address is followed by the port number at positions nos. 7 and 8, again in Network Byte Order. The port number may be followed by a flag byte. If the flag byte is present, bit no. 1, if set, indicates that compression is applied with all the data PDUs in this logical connection. The difference as compared to the compression flag in the first byte of a data PDU is reflected by the significance it has for the data PDU.

Bit no. 2 in the flag byte establishes that sequence numbers are to be transmitted in the data PDUs for this logical connection. The third bit indicates that the UDP is to be used instead of the TCP. Another field of variable length is allowed to follow only if the flag byte is present in the PDU.

The first byte of this field determines the length of the chain of signals to follow. In this field, the sequence number will transmit an unambiguous identification character consisting of the client software, provided GSM modems are used.

This identification character is not transmitted for the Modacom service because in this case the modem address is provided by the SCR protocol. The identification character is followed by the name and the password (the two being separated by zero byte) for RADIUS authentication in case this length field is greater than 12. If further data are contained in the instruction PDU the physical carrier is coded in the next two bytes.

The coding is as follows: Modacom 0x0001 GSM UDI 0x0002 Modem 0x0010 GSM UDI 0x0020 ISDN 0x0040 X.31 0x0080 The version number of the client terminated by a zero byte will follow if there are further data in the PDU. A byte with length information will be next if the PDU should be greater still. This is where the IP address of the client will be located if this length equals 4. The length of the IMEI number of the cellular telephone will be indicated here in case the length is greater. If the IP address is indicated the IMEI number may be stated in addition. That again is decided on the basis of the dimension of the PDU.

Connect Confirmation (command no. 2) This PDU comprises the result of a connection setup at positions nos. 3 and 4 in the Network Byte Order. A connection has been set up to the server application if this field shows 0 value. In all other cases this field comprises the error value for the Windows sockets connect function call. In addition, configuration data are transmitted to the client if this PDU is longer than 4 bytes. The validity of the values is coded in byte 5. Where the corresponding bit is set, this means that *-the value succeeding the bit is valid. Byte 5 is composed as follows: bit 8: always set bit 7: idle value is valid bit 6: poll value is valid bit 5: hold value is valid bits 4, 3, 2: not used bit 1: compression switched on.

The idle value is to be found in bytes 6, 7, 8, and 9, the poll value in bytes 10, 11, 12, and 13, and the hold value in bytes 14, 15, 16, and 17.

Disconnect request (command no. 3) This PDU serves to indicate the disconnection of the logical connection. The PDU has no parameters.

Flow control stop (command no. 4) Upon receipt of this PDU no data PDUs must be transmitted until a flow control start PDU has been received. This PDU has no parameters.

Flow control start (command no. Data transmission can be reactivated with this PDU. This PDU has no parameters.

Protocol error (reject, command no. 8) This PDU serves to signal erroneous behavior in the protocol, such as receipt of a data PDU when there is no connection. In byte 3 the erroneous behavior is coded: host cannot be reached 0 no socket 1 loss of data 2 compression error 3 wrong sequence number 4.

Extended connect request (command no. 9) After loss of the physical connection, the logical connections are reestablished when the physical connection reappears. This PDU must not be transmitted anywhere except on the reserved channel 63. Its parameter is an unambiguous session identification character. The first byte of the parameter fixes the length of the succeeding session identification character. In case of a length greater than 12 and following a zero byte for separation purposes, the name and the password separated from each other by another zero byte follow for RADIUS authentication. If there are further data in the PDU, the physical carrier is coded in the next two bytes (for coding please refer to connect request PDU above). The callback flag will be set in case the value in the next successive two bytes is greater than 0 and the server will call back. The IP address and the IMEI will be transmitted if further data are present in the PDU, as is the case with the connect request discussed above.

Domain name service request (database request, command no.

The domain name service routines are mapped in this PDU. The respective service is coded in byte 3 as follows: gethostbyname 1 gethostbyaddr 2 getservbyname 3 getservbyport 4.

oooo The length of the data following as of byte 5 is to be found in byte 4. This PDU is used for the request and the reply.

Error indication (command no. 11) The client can be informed of errors/texts by this PDU. The text is caused to be displayed to the user in a message box.

The length of the data to follow as of byte 5 is indicated in bytes 3 and 4.

Connect confirm callback (command no. 18) The physical connection is terminated when the client receives this PDU and a callback from the server is waited for. Internally, the server has set the callback flag and will call back automatically as soon as a physical connection has ceased to exist. Otherwise the structure is the same as with command no. 2.

Physical disconnect request (command no. 19) This command is used by the server for the short hold mode control. This packet is sent to the client, and thereupon the physical connection is terminated by the client. Morever, the idle time of the socket is indicated in byte 3-6.

Error message (error indication 2, command no. The client can be informed of errors/texts by this PDU. The text is caused to be displayed to the user in a message box.

The length of the data to follow as of byte 5 is indicated in bytes 3 and 4.

o* Data packet with EOF (error indication 2, command no. 21) Data are transported in this PDU and, at the same time, the :logical connection, i.e. the socket is connected.

UnambiQuous indentification The serial number of the client software, the telephone number of the subscriber, and the IMEI number of the mobile radio telephone are used for unambiguous association and identification. The number is used in the RTP command PDUs.

Execution of protocol Fig. 3 is a diagrammatic illustration of the states which occur with the RTP shown in fig. i. The RTP is carried out for each individual TCP connection, i.e. separately for each socket. The only exception is command no. 9 (extended connect). Thus the individual states in the protocol always correspond to the state of a single socket. A socket is in IDLE state after it was allocated by the system call "socket".

Fig. 4 is schematic illustration of substates of the IDLE state.

Transition to "connecting" takes place when the system function "connect" is called. Fig. 5 is a schematic illustration of substates of the CONNECTING state.

The desire to establish a connection is transmitted to the MOBILEmanager server in a connect request PDU. The server, having received this request, will try to set up the TCP connection accordingly. The result is transmitted back to the client system in the form of a connect confirmation PDU. This PDU comprises the result of the call of system function "connect". Upon successful setup of the TCP connection from the server to an application the socket changes over into the CONNECTED state. Fig. 6 is a schematic illustration of the substates thereof.

In this state (CONNECTED) the data transfer takes place for the TCP connection. Data passed on by the system function "send" are collected and then transmitted as data PDU. Data PDUs are collected until they are read by system function "recv". This state is left when the system function "closesocket" is called or a disconnect PDU is received.

Thereupon the socket will be in DISCONNECTING state. Fig. 8 is a schematic illustration of substates of the DISCONNECTING state. The protocol, and with it the socket, is finished when a disconnect PDU has been transmitted.

RLLP (radiowave link level protocol) The principal function of the RLLP is the provision of secure transmission of RTP PDUs having the following features: bidirectional (simultaneous transmission from client and server is possible) stream oriented safeguarding the full protocol information through a 32 bit CRC window mechanism (maximum window size 7) variable escape mechanism adapted to be configured.

Execution of RLLP PDU structure The structure of a PDU or data packet 15 is illustrated in fig. 9. All PDUs begin with an STX character and end with an ETX character. They do not contain any length information and, therefore, there is no block length restriction.

Immediately before the ETX character, a 4 byte checksum is transmitted. Calculation of the checksum begins after the STX character and comprises all the characters between the STX character and the checksum.

The STX character is followed by a byte of PDU specific information which in turn is followed optionally by the useful data proper. The overall length of the PDU thus results from the length of the useful data plus seven bytes.of protocol information.

The eight bits of the PDU type are organized as illustrated in fig. *DATA

PDU

The DATA PDU always is transmitted with the optional data portion. The window number lies in the range between 2 and PDUs in which the M bit is set (more data bit) must be put together to form an RTP PDU. The PDU received is the last part of the RTP PDU if the M bit is not set in the DATA PDU. Upon receipt of this PDU, the RTP PDU is signaled to the next higher layer.

In cases where the P bit (poll bit) is set, the receiver of the DATA PDU is requested to confirm the correct receipt immediately.

ACK PDU The ACK PDU is transmitted without a data portion. It serves to confirm receipt of PDUs of the DATA or INIT types. The window number of the last PDU correctly received is entered as window number. This amounts to an implicit confirmation of the previously received PDUs which may not have been confirmed.

NAK PDU The NAK PDU is transmitted without a data portion. It serves to signal transmission errors. The window number of the last PDU correctly received plus 1 is entered as window number.

This window number thus is the window number of the DATA PDU next expected by the receiver.

The E bit is set if the receiver of a DATA PDU is of the opinion that a reduction of the block length would make sense.

The E bit is merely a recommendation for the sender of the DATA PDU and, consequently, the receiver of the NAK PDU. The E bit should be set, for example, if data losses occurred in the "receipt. It should not be set if a checksum error was detected. The receiver of the NAK PDU must decide how to react to the E bit. It is convenient to reduce the block length at once *if the E bit is set, whereas the transmission may be repeated several times with the same block length if the E bit is not "set. A NAK PDU may not be sent more than once in a row. Only eeoupon faultless receipt of a data PDU may another NAK PDU be transmitted.

INIT PDU The INIT PDU must be transmitted from the client to the server at the beginning of a connection. That applies also to redialing. The client configures all the protocol parameters at the server by means of the INIT PDU. Since the INIT PDU is used at the beginning of a session, the window number always is 0. This is the value with which the window mechanism must be initialized.

The data portion of the INIT PDU has the structure shown in fig. 11.

Version This is the current version number (0x30 at the present time) in one byte Dial In this byte the dialing is counted. If dialing takes place more than 255 times, the counter stays at 255. The value is 1 for the first dialing.

Window size The size of the window to be used is entered in this byte.

Permitted values lie between 2 and Escape group The escape group is fixed in this byte. Escape groups are predetermined sets of control characters which must be "escaped" for the transmission. The escape character is 0x18, and the character to be "escaped" is altered by 0x40 via "exclusive The escape group 1 comprises the following: 0x02 (STX), 0x03 (ETX), Oxll (start 0x13 (stop and 0x18 (escape).

Block length A suggested block length is transmitted in this short. The server is allowed to ignore this suggestion. The block length is transmitted in "Network Order" i.e. the more significant byte first. The values range from 64 to 65535.

Timer T1 The timer T1 is transmitted in this short. The value is indicated in milliseconds and may reach from 1 to 65535. Transmission is effected in "Network Order" i.e. the more significant byte first.

The timer T1 fixes the time period after which the last DATA/INIT PDU received must be confirmed, provided no further DATA PDUs were received. After this time period an ACK PDU is transmitted with the window number of the PDU last received and not confirmed. The value of T1 always must be significantly smaller than the value of T2 in order to avoid a repetition before the confirmation has been carried out.

99 Timer T2 The timer T2 is transmitted in this short. The value is indicated in milliseconds and may reach from 1 to 65535. Transmission is effected in "Network Order" i.e. the more significant byte first.

The timer T2 fixes the time period for which confirmation of a PDU (DATA or INIT) sent is waited for. Upon expiration of this period of time renewed transmission of the unconfirmed PDUs begins.

Timer T3 The timer T3 is transmitted in this short. The value is indicated in milliseconds and may reach from 1 to 65535. Transmission is effected in "Network Order" i.e. the more significant byte first.

The timer T3 fixes the time period within which further characters must follows after receipt of an STX character.

This timer is used to find out whether the input of a PDU must be interrupted because a loss of data occurred. Upon expiration of the timer T3, an NAK PDU must be transmitted with the window number of the next DATA PDU expected.

Retry count In this byte the maximum number of repetitions for an unconfirmed PDU is indicated. When the repetition counter has reached this limit the respective transmitter must terminate the data connection.

Protocol behavior Initialization The client begins with the initialization by transmitting an INIT PDU to the server. The server immediately must confirm receipt by means of an ACK PDU.

If an NAK is received, the PDU is repeated at once. If an ACK is received, the PDU is repeated upon expiration of T2. The client terminates the connection when the retry count is exceeded. The receiver of the INIT PDU must initialize its protocol module with the parameters received.

Transfer A window mechanism is used when transmitting. The window number always is within the range from 0 to (WindowSize Up to WindowSize DATA PDUs may be transmitted one after another without waiting for confirmation. Confirmation must be waited for only when WindowSize is exhausted. The next DATA PDUs may be transmitted when confirmation is received, yet only up to the point where again WindowSize DATA PDUs are unconfirmed.

The window number is calculated with the following algorithm: winnr (winnr 1) MODULO WindowSize.

The receiver of the DATA PDUs should not wait with the confirmations until the window size is exhausted. Instead, the receiver will transmit the ACK PDU when the window is about half exhausted. That guarantees a continuous flow of data.

When it is foreseeable for the transmitter that no further data will have to be forwarded, the P bit is set in the last DATA PDU.

Next, the procedures will be described for receipt of PDUs.

Receipt of DATA PDU It is checked whether or not the P bit is set. If it is, an ACK PDU is transmitted at once. Furthermore, it is checked whether the number of DATA PDUs received and not confirmed is greater than or equals half the WindowSize. If so, an ACK PDU is forwarded immediately.

Additionally, it is checked whether the M bit is not set an longer. If indeed it is not, the DATA PDUs which were not yet signaled to the higher layer and in which the M bit always must be set are combined to form an RTP DPU which then is oe o signaled to the higher layer. Otherwise, i.e. if the M bit is not set, the PDU is attached to a list for later combination.

Receipt of ACK PDU The confirmed DTA PDUs can be erased from the transmission buffer after an ACK PDU has been received.

It is checked whether the last ten DATA PDUs have been transmitted without error. If that is the case the next DATA PDUs are forwarded with a block length which is increased by 25 Finally, DATA PDUs are transmitted once more until the WindowSize is exhausted.

Receipt of NACK PDU PDUs which have been sent are confirmed implicitly by an NAK PDU up to the (exclusively) requested window number. These DATA PDUs are cancelled in the transmission buffer.

The block length is reduced by 25 if the E bit is set.

Otherwise the block length is shortened by 25 only if this is the second consecutive error.

Finally, the DATA PDUs of the transmission buffer are transmitted once more. Thereupon new DATA PDUs may be transmitted as well until the WindowSize is exhausted.

If the limit for repetitions of a DATA PDU is surpassed an error must be signaled to the higher layer so that the higher layer can terminate the connection.

Timer T1 The DATA PDU last received and as yet unconfirmed must be confirmed when timer T1 expires.

This should occur rather seldom because, in the transfer phase, confirmation is given after exhaustion of half the window size already. At the end of a transfer phase it is o*e* possible for the transmitter to request confirmation immediately by setting the P bit.

Timer T2 All the PDUs of the transmission buffer, in other words all 'S.0 the unconfirmed PDUs, are transmitted again upon expiration of ooo...

S" the second timer T2. The procedure is the same as with the receipt of an NAK PDU.

Timer T3 Upon expiration of the timer T3 an NAK PDU with the expected window number is transmitted. The timer T3 may be started only if the input of a PDU has begun, i.e if at least the STX character has been read.

PDU input Inputting a PDU begins when the STX character is read, and it ends when the ETX character is read. In case of a buffer overflow or if the timer T3 expires before the ETX character is read, the input is interrupted and an NAK is transmitted with the E bit set.

An NAK with the E bit set is transmitted also if characters are received without first having received an STX character.

Upon receipt of the ETX character the checksum is verified. If it is incorrect an NAK is sent without setting of the E bit.

The PDU type is evaluated if the checksum is correct. This is followed by the procedures as described above.

Possible errors Loss of a DATA PDU The total loss of a DATA PDU is highly unlikely because, as a rule, some characters always arrive and, therefore, an NAK would be issued during input of a PDU.

However, if a complete DATA PDU indeed should get lost that will be noticed based on the window number. If the window num- *"ber is not conform with the number expected, an NAK with the expected window number must be transmitted.

If the last PDU of a transfer gets lost the transmitter will S"repeat the PDU upon expiration of the timer T2.

Loss of an INIT PDU What has been stated above with respect to DATA PDUs applies in this event as well. Yet a sequence number error cannot occur.

Loss of an ACK PDU This is compensated upon expiration of the timer T2.

Loss of an NAK PDU This is compensated upon expiration of the timer T2.

Claims (12)

1. 2. The apparatus as claimed in claim 1, wherein the useful data quantity transmitted is varied by changing the length of the data packet .eeee
2. 3. The apparatus as claimed in claim 1 or 2, wherein the connection is interrupted automatically when the trans- mission quality is poor and is restored automatically.
3. 4. The apparatus as claimed in claim 3, wherein the telephone number of a corresponding client or server computer is dialed for automatically restoring the connection.
4. 5. The apparatus as claimed in any one of the preceding claims, wherein the data circuit is a wireless connection.
5. 6. The apparatus as claimed in any one of the preceding claims, comprising a mobile telephone.
6. 7. The apparatus as claimed in any one of the preceding claims, comprising a portable computer.
7. 8. The apparatus as claimed in any one of the preceding claims, comprising a modem
8. 9. The apparatus as claimed in any one of the preceding claims, wherein the only data packets trans- mitted after a disconnection are data packets which were not yet confirmed as being faultless. The apparatus as claimed in any one of the preceding claims, further comprising a time duration counter, and wherein the connection is interrupted automatically if no data to be transmitted are present for a predetermined period of time.
9. 11. A data transmission method with which data in the form of successive data packets are transmitted via a data cir- cuit, especially a radio telephone connection, characterized in that the method comprises the steps of determining the transmission quality and/or determining the occurrence of a disconnection, varying the quantity of useful data transmitted per unit S* time in response to the transmission quality determined and/or upon occurrence of a disconnection.
10. 12. The method as claimed in claim 11, wherein an apparatus as claimed in any one of claims 1 to 10 is used.
11. 13. A computer program product, comprising instruction code sections by which the method as claimed in claim 11 or 12 is caused to be carried out when the computer program runs on a terminal especially a computer and/or a telephone.
12. 14. The computer program product as claimed in claim 13, com- prising instruction code sections which map function calls of a TCP/IP socket interface so that the method as claimed in claim 11 or 12 is carried out. Dated this 16 day of August 2000 isoft GmbH Patent Attorneys for the Applicant:- FB Rice Co. *r S 4S**