WO2007072266A2

WO2007072266A2 - Method and device for driving a tcp/ip-based communication with near field communication

Info

Publication number: WO2007072266A2
Application number: PCT/IB2006/054634
Authority: WO
Inventors: Francesco Gallo
Original assignee: Koninklijke Philips Electronics N.V.; Philips Intellectual Property & Standards Gmbh
Priority date: 2005-12-21
Filing date: 2006-12-06
Publication date: 2007-06-28
Also published as: WO2007072266A3

Abstract

A method and a device for avoiding timeout expirations and consequent packet retransmissions in the TCP protocol during NFC link resuming is described. The method comprises the following steps: when the NFC disconnection is detected, specific data are sent from the device to the TCP/IP server to cause the TCP/IP server to stop sending more data packets and to disable internal retransmission timeouts, acknowledgement data packets which have been sent from the TCP/IP client towards the TCP/IP server after the disconnection are stored on the device, when the NFC link is re-established, the TCP/IP client sends the previously stored acknowledgement data packets to the TCP/IP server, which data packets enable the TCP/IP server to continue the sending of data.

Description

Method and device for driving a TCP/IP -based communication with Near Field Communication

FIELD OF THE INVENTION

The invention relates to a method and a device for driving a TCP/IP -based communication with Near Field Communication.

BACKGROUND OF THE INVENTION

Identification products such as smart cards and RFID (Radio Frequency Identification) tags are widely used in the field of transport (ticketing, road tolling, baggage tagging), finance (debit and credit cards, electronic purse, merchant card), communications (SIM cards for mobile phones), and tracking (access control, inventory management, asset tracking). For example, in electronic ticketing for public transport, travelers just wave their card over a reader at the turnstiles or entry points, benefiting from improved convenience and speed in the ticketing process. Such products are set to be the key to individual mobility in the future, supporting multiple applications including road tolling, airline tickets, access control and many more. Near Field Communication (NFC), which has evolved from a combination of contactless identification and networking technologies, is a short-range and wireless technology for distances measured in centimeters and is optimized for intuitive, easy and secure communications between various devices without user configuration. In order to make two devices communicate, users bring the devices close together or even make them touch. The NFC interfaces in the devices will automatically connect and configure themselves to form a peer-to-peer network. NFC can also bootstrap other protocols such as Bluetooth™ or Wireless Ethernet (WiFi) by exchanging the configuration and session data. NFC is compatible with contactless smart card platforms. This enables NFC devices to read information from these cards, making contactless smart cards a suitable solution for bringing information and vouchers into the world of NFC. NFC devices can also operate like a contactless card making them compatible with a huge installed infrastructure of ISO 14443 A- compliant systems. Secure NFC combines NFC applications with smart card security. Interface and protocol for simple wireless communication between close coupled devices are specified in the international standard ISO/IEC 18092. These Near Field Communication devices communicate with specified transfer rates. Inside the NFC Forum, the Logical Link Control Protocol (LLCP) has been standardized. Messages/abbreviations/definitions of this standard are hereinafter incorporated by reference.

The LLCP provides data service to be able to send and receive LLCP data packets over the NFCIP-I link. LLCP manages session-recovering connections that have been disconnected at the NFC layer for a relatively short time (seconds) without reestablishing it from scratch and without resending already transmitted data between two peer devices.

To recover a session, the GAP TIMEOUT (GAP TO) message has been added to LLCP on the target devices. The target uses the GAP TIME OUT message to detect that the underlying NFC communication link is broken. When this message has been received, the target assumes that the NFC communication is lost and starts to recover the NFC communication doing the device discovery for a time of SESSION TIMEOUT seconds. If the connection is not re-established before SESSION TIMEOUT seconds, the NFC communication is definitely closed. The complete TCP/IP stack can be implemented on top of the LLCP layer.

The LLCP session recovery mechanism can have adverse interactions with the Transport Control Protocol (TCP) in terms of throughput reductions and unnecessary retransmissions. The session recovery could last several seconds, during which period internal TCP retransmission timeouts are triggered in the TCP's sender due to delayed TCP acknowledgement data.

WO 02/28032 Al discloses a network interface driver and a method for the communication of TCP packets with a mobile terminal and a wireless link. The method is provided to detect late acknowledgement signals in an upstream wireless link. In response to such a detection, the method suspends an activity at a TCP packet source before a timeout period expires.

OBJECT AND SUMMARY OF THE INVENTION

It is an object of the invention to provide an improved method and a device for a TCP/IP-based data communication with Near Field Communication.

The object of the invention is achieved by a method as defined in claim 1, a computer program product as defined in claim 11 and a communication device as defined in claim 12. Preferred embodiments of the invention are defined in dependent claims. The method according to the invention is provided for operating a TCP/IP -based communication with Near Field Communication, said communication being executed by a TCP/IP server device, a TCP/IP client device and governing means arranged on both the TCP/IP client device and the TCP/IP server device. The method comprises the following steps:

Causing the TCP/IP server device to stop a transmission of data and to disable internal retransmission timeouts when a disconnection in the communication occurs,

Storing acknowledgement data in the governing means arranged on the TCP/IP client device, which acknowledgement data have been sent by the TCP/IP client device to the TCP/IP server device after disconnection of the communication, and

Sending the stored acknowledgement data from the TCP/IP client device to the TCP/IP server device after the communication has been re-established.

The method according to the present invention advantageously accelerates a re-establishment of a broken data connection using Near Field Communication between the communicating TCP/IP devices. After the TCP/IP -based communication has been reestablished, the governing means sends stored acknowledgement data packets to the TCP/IP server device. As a result, the TCP/IP server device sends further data packets from the TCP/IP server device to the TCP/IP client device. In this way, internal retransmission timeouts can be prevented advantageously by means of the method according to the present invention, whereas the re-establishment of the disconnected TCP/IP -based communication can be accelerated enormously. A throughput of a data rate and an improved usage of the TCP/IP-based communication result therefrom.

The features defined in claim 2 have a particular advantage in that specific information from the LLCP layer being part of NFC are used to trigger the method steps as defined in claim 1.

Features as defined in claim 3 offer the particular advantage that the detection of disconnection of the communication is performed by varying specific information from the LLCP layer, which information depends on whether the TCP/IP server device acts as an initiator or as a target according to the NFC protocol. In this way, it is irrelevant from which side the TCP/IP-based communication has been initiated (either from the initiator side or from the target side) according to the NFC protocol. In both cases, the method according to the present invention can accelerate the re-establishment of the disconnected TCP/IP-based communication with Near Field Communication. The features as defined in claims 4 and 5 offer the particular advantage that a disconnection of the communication can be detected by the governing means arranged on the TCP/IP server side by specific varying information from the LLCP layer, the information depending on whether the TCP/IP client/server acts as an initiator or as a target according to the NFC protocol. Furthermore, if a disconnection of the communication has been detected, zero window acknowledgement data are sent to the TCP/IP server for each ongoing TCP- based communication, which keeps the TCP/IP server device from sending further data packets and prevents timeouts due to several retransmissions of data.

The features as defined in claim 9 offer the particular advantage that a permanent disconnection of the TCP/IP-based communication is detected and signaled by means of a specific timeout message from the LLCP called "SESSION TIMEOUT". The features defined in claim 10 offer the particular advantage that the governing means is not burdened with the stored acknowledgment data after detection of a permanent disconnection of the communication, wherein the governing means correctly classifies the TCP-based communication as being permanently disabled.

According to a further aspect of the present invention, a computer program product is provided.

According to a further aspect of the present invention, a communication device is provided. These and other aspects of the invention are apparent from and will be elucidated with reference to the embodiments described hereinafter.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will be described in greater detail hereinafter, by way of non- limiting examples, with reference to embodiments shown in the drawings.

Fig. 1 shows an arrangement of two TCP/IP client/server devices, which communicate via Near Field Communication (NFC).

Fig. 2 shows the governing means of the present invention in more detail. Fig. 3A shows a flow diagram of the method according to the invention, wherein the TCP/IP client/server device acts as an initiator according to the NFC protocol, and wherein the governing means is arranged upstream on the TCP/IP server device side.

Fig. 3B shows a flow diagram of the method according to the present invention, wherein the TCP/IP client/server device acts as a target according to the NFC protocol. Fig. 4A shows a flow diagram of the method according to the present invention, wherein the TCP/IP client/server device acts as an initiator according to the NFC protocol.

Fig. 4B shows a flow diagram of the method according to the present invention, wherein the TCP/IP server/client device acts as a target according to the NFC- protocol.

Fig. 5 shows a conventional re-establishment of a communication flow between a TCP/IP server device and a TCP/IP client device.

Fig. 6 shows, in principle, a re-establishment of a communication flow according to the present invention between a TCP/IP server device and a TCP/IP client device.

DESCRIPTION OF EMBODIMENTS

Fig. 1 shows an arrangement with a TCP/IP client/server device 10 which performs a data communication with another TCP/IP client/server device 10 using Near Field Communication (NFC). The data communication is performed via the TCP/IP stack which is implemented on both TCP/IP client/server devices 10. Furthermore, the data communication is performed by means of the NFC protocol, wherein the Logical Link Control Protocol (LLCP) is part of the NFC protocol. An NFC TCP booster 30 according to the present invention is arranged on both TCP/IP client/server devices 10. It goes without saying that the data communication flow is bidirectional, i.e. data can be sent from one TCP/IP client/server device 10 acting as a TCP/IP server to the other TCP/IP client/server device 10 acting as a TCP/IP client. The data communication can invert its direction after a complete communication cycle between the TCP/IP client/server device 10 acting as a TCP/IP server and the TCP/IP client/server device 10 acting as a TCP/IP client. An application 31 (e.g. an FTP stack) is implemented on top of the TCP/IP stack, which enables the application 31 to be performed between the two TCP/IP client/server devices 10. The TCP/IP client/server device 10 can generally be called a communication device. The TCP/IP client/server device 10 acting as a server can generally be called a TCP/IP server. The TCP/IP client/server device 10 acting as a client can generally be called a TCP/IP client.

Fig. 2 shows the NFC TCP booster 30 according to the invention in more detail. An upstream controlling means 40, which controls a flow of acknowledgement data (ACK) from the TCP/IP client towards the TCP/IP server, is arranged in a left section of the NFC TCP booster 30. The upstream controlling means 40 is arranged upstream, i.e. on the side of the TCP/IP server. A downstream controlling means 50, which also controls acknowledgement data (ACK) from the TCP/IP client/server-device 10 acting as a TCP/IP client to a TCP/IP server/client-device 10 acting as a TCP/IP server, is arranged in a right section of the NFC TCP booster 30. The downstream controlling means 50 is arranged downstream, i.e. on the side of the TCP/IP client. A monitoring means 60, which controls the logical link control protocol (LLCP) layer being part of NFC, is arranged in the center of the NFC TCP booster 30.

Upstream controlling means 40 controls acknowledgement data of all TCP/IP connections in the TCP/IP device (10) where they are generated. Controlling means 40,50 are able to control more than one TCP/IP-based communication at the same time and can work on one TCP/IP client/server device 10 essentially simultaneously. Overall, the upstream controlling means 40 and the downstream controlling means 50 implement four different types of algorithms.

The upstream controlling means 40 and the downstream controlling means 50 are used to send zero window acknowledgment data to the TCP/IP server and to store and later send acknowledgement data (ACK), respectively. Upstream sending means 41 is directly under the control of the upstream controlling means 40, while downstream sending means 51 is directly under the control of the downstream controlling means 50. The upstream sending means 41 is used to send zero window acknowledgement data to the TCP/IP server. Monitoring means 60 is responsible for signaling to the upstream controlling means 40 and to the downstream controlling means 50 when a LLCP link inside the communication between the TCP/IP client/server devices 10 is disconnected, resumed or definitely lost.

As is shown in Fig. 2, upstream controlling means 40 controls the TCP/IP data connections and sends zero window acknowledgement packets by way of the upstream sending means 41 towards the TCP/IP server. One zero window acknowledgement packet is sent via a particular TCP/IP connection, when a corresponding conventional timeout expires. Downstream sending means 51 is used to send acknowledgement data from the TCP/IP client towards the TCP/IP server and to the NFC TCP booster 30 arranged inside the TCP/IP client, respectively. Fig. 3A shows a flow diagram of the method according to the present invention if the NFC TCP booster 30 is arranged on the TCP/IP server, wherein the TCP/IP server acts as an initiator according to the NFC protocol. The flow diagram is executed by the upstream controlling means 40 inside the NFC TCP booster 30. In a step S31, an inquiry is performed about an expiration of the conventional timeout, wherein zero window acknowledgement data are sent to the TCP/IP server (step S37) if the conventional timeout has expired. In order to distinguish the method according to the present invention from conventional solutions, a dashed line framing steps S32 and S33 according to the present invention is drawn. In a step S32, an inquiry is performed about a specific message from LLCP called "LLCP Link Broken". If this specific message has been received by the upstream controlling means 40 inside the NFC TCP booster 30, zero window acknowledgement data (ZWA) are sent to the TCP/IP server for each ongoing TCP connection (step S33).

Fig. 3B shows a flow diagram with method steps S35, S36 according to the present invention. In order to better distinguish the inventive steps from known solutions, the inventive steps S35, S36 are shown inside a dashed frame. The flow diagram is executed if the NFC TCP booster 30 is arranged upstream on the TCP/IP server side, with the TCP/IP server acting as a target according to the NFC protocol. Conventional step S34 corresponds to conventional step S31 in Fig. 3 A. Conventional step S38 corresponds to conventional step S37 in Fig. 3 A. In a step S35, an inquiry is performed about a specific message from the LCCP called "GAP TIMEOUT" (GAP TO). If this specific message has been received by the upstream controlling means 40 inside the NFC TCP booster 30, zero window acknowledgement data (ZWA) are sent to the TCP/IP server for each ongoing TCP connection (step S 36). The difference between the two flow charts of Fig. 3 A and Fig. 3B is therefore the manner in which it is determined that the LLCP link inside the TCP/IP -based communication between the two TCP/IP client/server devices 10 is broken. When the TCP/IP client/server device 10 acts as an initiator according to the NFC protocol, the broken LLCP link is detected with the specific LLCP message "LLCP Link Broken" (Fig. 3A). However, when the TCP/IP client/server device 10 acts as the target according to the NFC protocol, the specific LLCP message "GAP TIMEOUT" is used (Fig. 3B) to detect the disconnection. GAP TIME OUT is a specific timeout message specified inside the LLCP document that belongs to the NFC Forum. Both "GAP TIMEOUT" and "LLCP Link Broken" messages are sent from the monitoring means 60 to the upstream controlling means 40. After reception of any of these two messages, zero window acknowledgement data are sent by way of the sending means 41 to the TCP/IP server. After reception of the zero window acknowledgement data, the TCP/IP server stops sending any more data packets towards the TCP/IP client. Fig. 4 A shows a flow diagram which is executed by the downstream controlling means 50 inside the NFC TCP booster 30, when the NFC TCP booster 30 is arranged on the side of the TCP/IP client. In a step S401, an inquiry is performed about the "LLCP Link Broken" message. In more detail, it is inquired if the message was received by the downstream controlling means 50. If this is the case, an inquiry is performed in a step S402 if there are any ongoing TCP connections. If this is the case, the acknowledgement data packets (ACK) which have been sent by the TCP/IP client towards the TCP/IP server after disconnection of the TCP/IP-based communication are stored inside the NFC TCP booster 30 (step S403). In a step S404, an inquiry is performed on whether a specific message from the LLCP protocol called "LLCP Link Resume" has been received by the downstream controlling means 50 inside the NFC TCP booster 30. If the message has been received, this is an indicator that the communication between the two TCP/IP client/server devices 10 was resumed. If this is the case, the downstream controlling means 50 inside the NFC TCP booster 30 sends the stored acknowledgement data to the TCP/IP server in order to cause the TCP/IP server to restart sending further data packets towards the TCP/IP client (step S 405). Consequently, a time-saving continuation of the TCP/IP-based communication after re- establishment of the communication can be performed. In a step 406, when the LLCP Link Resume event has not been received, it is inquired whether a specific LLCP timeout (SESSION TIMEOUT) has expired. If the timeout has expired, all previously stored acknowledgement data are deleted from the NFC TCP booster 30 in a step S407. This indicates that the communication between the TCP/IP client/server devices 10 has definitely been lost. In this case, no more acknowledgement data are stored inside the NFC TCP booster 30, as there is no chance that the communication is going to be re-established. Advantageously, an unnecessary burden in the form of stored acknowledgement data can be avoided for the NFC TCP booster 30 in this way.

Fig. 4B shows a flow diagram which is executed by the downstream controlling means 50 inside the NFC TCP booster 30, when the NFC TCP booster 30 is arranged downstream on the TCP/IP client side, with the TCP/IP client acting as a target according to the NFC protocol. In a step S408, an inquiry about the specific LLCP timeout message "GAP TIMEOUT" is performed by the downstream controlling means 50. If this message has been received by the downstream controlling means 50, it is inquired in a step S409 if there are any ongoing TCP connections between the TCP/IP client/server devices 10. If this is the case, acknowledgement data packets which have been sent towards the TCP/IP server after disconnection of the communication are stored for each ongoing TCP connection inside the NFC TCP booster 30 in a step S410. Subsequently, in a step S411, it is inquired whether the "LLCP Link Resume" message has been received by the downstream controlling means 50. If this is the case, this is a verification of a re-established communication between the two TCP/IP client/server devices 10. As a result, the previously stored acknowledgement data packets are sent from the NFC TCP booster 30 to the TCP/IP server in a step S413.

Consequently, a time-saving continuation of the re-established TCP/IP-based communication can be performed.

If, in step S411, no LLCP link resume event has been received by the NFC TCP booster 30, it is inquired in a step S412 whether the LLCP specific SESSION TIMEOUT (SESSION TO) has expired. If the SESSION TIMEOUT has expired, stored acknowledgement data are deleted from the NFC TCP booster 30 in a step S414. Thus, an unnecessary burden of the NFC TCP booster 30 can be removed and avoided advantageously. In summary, Figs. 4A and 4B show a control of the LLCP link inside the NFC protocol by means of differing messages from the LLCP layer. The differences in the flow diagrams of Figs. 4A and 4B result from the fact that, in Fig. 4A, the TCP/IP client acts as an initiator according to the NFC protocol, whereas in Fig. 4B, the TCP/IP client acts as a target according to the NFC protocol.

Fig. 5 shows, in principle, a conventional data communication flow between a TCP/IP server and a TCP/IP client. Data sent from the TCP/IP server to the TCP/IP client are denoted as DATA. Acknowledgement data packets sent from the TCP/IP client to the TCP/IP server are denoted as ACK. If the NFC link is broken at a time tl, several retransmissions are made by the TCP/IP server according to the TCP/IP protocol. In the Figure, the retransmissions are denoted as DATA (re-tx). Three retransmissions DATA (re-tx) are shown in Fig. 5. However, the retransmissions from the TCP/IP server are disadvantageously also continued when the NFC link has been recovered at a time t2. Consequently, a time waste

TW results due to the TCP timeouts TAl, TA2 and TA3. As an example, TAl has 200 msec, TA2 has 400 msec and TA3 has 800 msec, resulting in a total TCP interruption length TCPl of circa 1400 msec. This means that the time waste TW is essentially the duration of the third TCP timeout TA3. However, it can be seen that the NFC link recovery (t2) takes place circa 600 msec after the break of the NFC link at tl . This means that the second retransmission from the TCP/IP server takes place shortly before the NFC link has been recovered and therefore produces a big waste of time, because the third TCP timeout TA3 ends when the NFC link has already been recovered for a long time. In order to solve this problem, Fig. 6 shows a data communication flow between two TCP/IP client/server devices 10, wherein NFC TCP boosters 30 according to the present invention are arranged in both TCP/IP client/server devices 10, respectively. In the Figure, it can be seen that a disconnection of the NFC link takes place at a time tl . After the disconnection of the NFC link at tl, acknowledgement data packets (ACK), which have been sent from the TCP/IP client towards the TCP/IP server after the disconnection, are stored within the NFC TCP booster 30 arranged on the TCP/IP client/server device 10 acting as a TCP/IP client. Corresponding to this action, zero window acknowledgement data (ZWA) are sent from the NFC TCP booster 30 arranged on the TCP/IP client/server device 10 acting as TCP/IP server to the TCP/IP server, which data cause the TCP/IP server to stop further transmissions of data packets towards the TCP/IP client. In this way, the time-wasting retransmission timeouts shown in the arrangement of Fig. 5 can be avoided advantageously. As soon as the NFC link has been re-established at a time t2, the previously stored acknowledgement data in the NFC TCP booster 30 inside the TCP/IP client are sent from the NFC TCP booster 30 to the TCP/IP server. As a result, an overall time of inactivity of the NFC link can be minimized. This means that a total TCP interruption length TCP2 is approximately 700 msec as compared to 1400 msec in the conventional arrangement shown in Fig. 5. Favorably, the re-establishment of the data connection between the two TCP/IP client/server devices 10 can therefore be accelerated to a considerable degree. The method according to the invention can be seen as two parts of a method, wherein an inventive interaction takes place between the two method parts. From the point of view of the TCP/IP server, the TCP/IP server device 10 acting as the TCP/IP server is informed of a breakage of a TCP/IP -based communication using the NFC protocol by means of the NFC TCP booster 30 arranged on the TCP/IP server. Furthermore, in addition, the TCP/IP server is caused to abandon the sending of further data packets towards the TCP/IP client by means of the NFC TCP booster 30.

From the point of view of the TCP/IP client, storage of acknowledgement data ACK within the NFC TCP booster 30 arranged on the TCP/IP client is provided. In more detail, such acknowledgement data ACK are stored within the TCP/IP client, which acknowledgement data ACK have been sent by the TCP/IP client towards the TCP/IP server after breakage of the TCP/IP-based communication with the NFC protocol.

For example, the method according to the present invention can be implemented advantageously as a software product which can be executed on a computer. The method according to the invention can be applied advantageously to all NFC-enabled devices that implement the peer-to-peer- feature of NFC by means of LLCP and the TCP/IP protocol. The method according to the invention can be used to avoid TCP timeouts, data packet retransmissions, delays and latencies. Advantageously, the method according to the present invention can be applied independently of the fact whether the TCP/IP client/server device 10 acts as an initiator or as a target according to the NFC protocol. Dependent on these facts, differing messages from the LLCP are used to trigger the method steps according to the present invention. The method according to the present invention avoids wasting bandwidth during the LLCP connection recovery. Moreover, the method according to the present invention improves user experience when the TCP/IP stack is used over NFC and allows a smooth integration of TCP/IP into the NFC stack. It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be capable of designing many alternative embodiments without departing from the scope of the invention as defined by the appended claims. In the claims, any reference signs placed in parentheses shall not be construed as limiting the claims. Use of the verb "comprise" and its conjugations does not exclude the presence of elements or steps other than those stated in any claim or the specification as a whole. The singular reference of an element does not exclude the plural reference of such elements, and vice versa. In a device claim enumerating several means, several of these means may be embodied by one and the same item of software or hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Claims

CLAIMS:

1. A method of operating a TCP/IP -based communication using the Near Field

Communication Protocol, said communication being executed by a TCP/IP server device (10), a TCP/IP client device (10) and governing means (30) arranged on both the TCP/IP server device (10) and the TCP/IP client device (10), the method comprising the following steps: causing the TCP/IP server device (10) to stop a transmission of data and to disable internal retransmission timeouts when a disconnection in the communication occurs, storing acknowledgement data (ACK) in the governing means (30) arranged on the TCP/IP client device (10), which acknowledgement data (ACK) have been sent by the TCP/IP client device (10) towards the TCP/IP server device (10) after disconnection of the communication, and sending the stored acknowledgement data (ACK) from the TCP/IP client device (10) to the TCP/IP server device (10) after the communication has been re-established.

2. A method according to claim 1, wherein triggering of the steps is controlled by specific information from the Logical Link Control Protocol layer being part of the Near Field Communication Protocol controlling the physical communication between the TCP/IP client device (10) and the TCP/IP server device (10).

3. A method according to claim 2, wherein the disconnection of the communication is detected by varying specific information from the LLCP layer, the information depending on whether the TCP/IP server device (10) acts as an initiator or as a target in the communication according to the NFC protocol.

4. A method according to claim 3, wherein, if the TCP/IP server device (10) acts as the target according to the NFC protocol, the disconnection is detected by the governing means (30) arranged on the TCP/IP server device (10) with the aid of a timeout message (GAP TO), wherein zero window acknowledgement data (ZWA) are sent to the TCP/IP server device (10) for each ongoing TCP/IP -based communication, which data indicate the disconnection to the TCP/IP server device (10) and stop the TCP/IP server device (10) from sending further data towards the TCP/IP client device (10).

5. A method according to claim 3, wherein, if the TCP/IP server device (10) acts as the initiator according to the NFC protocol, the disconnection is detected by the governing means (30) arranged on the TCP/IP server device (10) with the aid of a LLCP Link Broken message, wherein zero window acknowledgement data (ZWA) are sent to the TCP/IP server device (10) for each ongoing TCP-based communication, which data indicate the disconnection to the TCP/IP server device (10) and stop the TCP/IP server device (10) from sending further data towards the TCP/IP client device (10).

6. A method according to claim 3, wherein, if the TCP/IP server device (10) acts as the target according to the NFC protocol, the disconnection is detected by the governing means (30) arranged on the TCP/IP client device (10) with the aid of the GAP TIMEOUT timeout message (GAP TO), wherein acknowledgement data (ACK) which have been sent from the TCP/IP client device (10) towards the TCP/IP server device (10) are stored within the governing means (30), and wherein the stored acknowledgement data (ACK) are sent from the governing means (30) to the TCP/IP server device (10) after the communication has been re-established.

7. A method according to claim 3, wherein, if the TCP/IP client device (10) acts as the initiator according to the NFC protocol, the disconnection is detected by the governing means (30) arranged on the TCP/IP client device (10) with the aid of the LLCP Link Broken message, wherein acknowledgement data (ACK) which have been sent from the TCP/IP client device (10) towards the TCP/IP server device (10) after the disconnection are stored within the governing means (30), and wherein the stored acknowledgement data (ACK) are sent from the governing means (30) to the TCP/IP server device (10) after the communication has been re-established.

8. A method according to claim 6 or 7, wherein the re-establishment of the communication is detected with the aid of a specific LLCP message LLCP Link Resume.

9. A method according to any one of claims 6 to 8, wherein a permanent disconnection of the communication is detected and signaled by means of a specific LLCP message SESSION TIMEOUT.

10. A method according to claim 9, wherein, if a permanent disconnection of the communication is detected, all previously stored acknowledgement data (ACK) are deleted from the governing means (30) arranged on the TCP/IP client device (10).

11. A computer program product which is directly loadable into the memory of a communication device (10) comprising software code portions for performing the steps of the method according to any one of claims 1 to 10 when said program is run on the communication device (10).

12. A communication device (10) which is designed to perform the steps of the method according to any one of claims 1 to 10.