Higher-layer control of TCP layer processing based on TCP error count reporting

Abstract

In a method and system for controlling TCP processing within a device, the device has a protocol stack defining a sequence of logical layers and is configured to process data for transmission from the device through the sequence of logical layers, the sequence of logical layers including a TCP layer and an upper layer that precedes the TCP layer in the sequence. An exemplary method includes, when the device passes data from the upper layer to a lower TCP layer for processing at the TCP layer, reporting by the device from the TCP layer to the upper layer a count of the number of TCP errors that occurred during processing of the data at the TCP layer. Further, the exemplary method includes, at the upper layer, using the reported count by the device as a criterion to control resumption of TCP layer processing of the data.

Description

Background Art

[0001] When a user of a communication device instructs the device to initiate an Internet Protocol (VoIP) call or other packet-based real-time media session with a called party, the device can responsively perform packet-based session setup signaling with a call server and / or the called party's device to set up the call.

[0002] For example, using the industry-standard Session Initiation Protocol (SIP), the originating device first sends a packet-based SIP INVITE message carrying the identifier of the called party (e.g., the called phone number) to the server, then receives a packet-based SIP 200 OK message from the server to confirm that the call has been set up, and then the originating device may send a packet-based SIP ACK message to the server to complete the setup of the outgoing call leg, such as a Real-Time Transport Protocol (RTP) session between the originating device and the server. Further, upon receiving a SIP INVITE message from the originating device, the server may perform similar SIP signaling with the called party's device to set up an incoming call leg, such as an RTP session between the server and the called party's device. The server may then bridge the outgoing call leg and the incoming call leg together to enable the caller and the called party to communicate with each other.

Summary of the Invention

[0003] One technical issue with setting up VoIP calls or other packet-based real-time media sessions is signaling latency. When a user makes a call, they may expect the call to be set up very quickly. However, the mechanisms of the packet-based session setup signaling process can cause undesirable delays in call setup, which can result in an unpleasant experience for the user.

[0004] For two devices to communicate with each other in a packet-based manner, each device may implement a protocol stack that defines a sequence of logical processing layers. For example, in the Internet Protocol Suite, the protocol stack ranges from top to bottom, from the application layer to the transport layer (e.g., the Transport Control Protocol (TCP) layer), the network layer (e.g., the IP layer), the data link layer (e.g., the Media Access Control (MAC) layer), the physical layer, and possibly other layers. Each device may be configured to process data sequentially through the layers of such a stack, with the transmitting device processing the data downwards through the stack and taking specific actions at each layer (e.g., data segmentation, adding layer-specific headers, etc.), and then the receiving device processing the data upwards through the stack and taking layer-specific actions at each layer (e.g., header removal, segment recombination, etc.).

[0005] This configuration allows devices to communicate with each other at corresponding layers of their respective protocol stacks, with each successive layer of those corresponding protocol stacks operating on the communication in between. For example, a layer of a transmitting device can communicate with a corresponding layer of a receiving device, and this communication propagates downwards through the transmitting device's protocol stack, and then through the physical transmission medium between devices to the corresponding upper layer of the destination via the receiving device's protocol stack.

[0006] SIP is an application layer protocol. Therefore, when an originating device attempts to initiate a VoIP call or other packet-based real-time media session, the device may generate a SIP INVITE directed to the call server at the application layer and pass the generated SIP INVITE message to the lower TCP layer for processing. At the TCP layer, the device may segment the SIP INVITE message into chunks, encapsulate each chunk in a TCP header specifying the source and destination TCP port numbers and TCP sequence numbers, and pass each resulting TCP packet (or "TCP segment") to the lower IP layer for processing. Next, at the IP layer, the device may encapsulate each TCP packet in an IP header specifying the source and destination IP addresses, and pass each resulting IP packet to the lower MAC layer for processing. Next, at the MAC layer, the device may segment and encapsulate each IP packet into a frame suitable for the physical transmission medium. Finally, at the physical layer, the device may output the resulting frame to the server for transmission over the physical communication path. Furthermore, the originating device may perform similar processing for each additional SIP message it sends to the server.

[0007] Similarly, when a server sends a SIP message, such as a SIP 200 OK response message, to a sending device, the sending device can receive the SIP message as a series of frames at the physical layer and reverse the above process at each layer until the SIP message reaches the application layer. For example, the device may reverse the process at the MAC layer to reveal IP packets, reverse the process at the IP layer to reveal TCP packets, or reverse the process at the TCP layer to reveal SIP messages for processing at the application layer.

[0008] One of the causes of delays in the SIP signaling process is errors that may occur at the TCP layer.

[0009] TCP is a connection-oriented protocol in which devices establish TCP sessions (TCP sockets) with each other and use sequence numbering and acknowledgment schemes to ensure the successful communication of TCP packets. In particular, each device may include its own sequence number in the header of each TCP packet it sends to other devices, and the sequence number of each TCP packet is generally increased by an amount equal to the number of payload bytes of the sending device's last TCP packet transmission (or by just 1 during the initial TCP handshake process, which may not contain any payload data). Upon receiving each such TCP packet transmission, the receiving device may send a TCP acknowledgment (ACK) to the sending device specifying the expected sequence number of the sending device's next TCP packet transmission. Furthermore, the sending device may expect to receive such an ACK for each such TCP packet transmission between the time the sending device's TCP layer passes the TCP packet to the IP layer for processing and the expiration of a retransmission timer, such as 3 seconds.

[0010] This TCP process is susceptible to various errors caused by latency.

[0011] For example, a TCP "retransmission" error can occur when a device sends a TCP packet and does not receive the associated TCP ACK before the retransmission timer expires, at which point the device may be retransmitting the TCP packet. Furthermore, the device may allow up to a maximum number of such retransmissions (e.g., 5 times) of a given TCP packet before concluding that the TCP transmission has completely failed, at which point the TCP layer may send a FAIL response to the application layer. As another example, a TCP "duplicate ACK" error can occur when devices receive multiple ACKs specifying the same sequence number to each other, and the receiving device sends this duplicate ACK error to the sending device as a means of informing the sending device that it has detected a missing TCP packet, which may result in a retransmission.

[0012] As yet another example, a TCP "out of order" error can occur when a device receives a TCP packet with a sequence number greater than any sequence number it has previously encountered. When this occurs, the receiving device can notify the sending device of the error by sending an ACK with the expected sequence number instead of the sequence number of the received TCP packet, which may also result in retransmission. Furthermore, as a related example, a TCP "failed to capture previous segment" error can occur when a device receives a TCP packet with sequence number N, but there are no previous TCP packets from the same TCP session where the sequence number plus the data length equals N. When this occurs, the receiving device can similarly notify the sending device of the error by sending an ACK with the expected sequence number instead, which may also result in retransmission.

[0013] Any of these TCP errors and / or other TCP errors can cause delays in the SIP message transmission process. Furthermore, a given SIP message transmission may involve numerous such TCP errors or instances of TCP errors, which, combined, can substantially delay the setup of the associated VoIP call or other packet-based real-time media session.

[0014] In practice, the application layer may also apply its own timer to receive a SIP response when it provides SIP message transmission. For example, when the application layer sends a SIP message to the TCP layer for processing, the application layer may set a request timeout timer and expect to receive a SIP response message before that timer expires. If the application layer does not receive a SIP response before the SIP timer expires, the application layer may conclude that the setup of the packet-based real-time media session has failed, which in itself can cause problems in the user experience.

[0015] This specification discloses a mechanism that may help address session setup delays resulting from the occurrence of one or more TCP layer errors. According to this disclosure, when the application layer sends a SIP message to the TCP layer for processing (whether directly or through one or more intermediate layers), the TCP layer enters reporting mode, in which the TCP layer notifies the application layer of the TCP layer error count for the SIP message, and the application layer dynamically resumes TCP processing of the SIP message using the TCP error count as a basis. For example, whenever any of the TCP errors described above or one or more other TCP errors occur, the TCP layer may signal the application layer to report the current count of TCP errors that occurred during the processing of the SIP message. Furthermore, whenever the application layer receives such a report from the TCP layer, the application layer may determine whether the reported count has reached at least a predetermined threshold. If the application layer determines that the count has reached at least a predetermined threshold, the application layer may responsively trigger TCP connection recovery (i.e., recovery or re-establishment of the TCP connection) and then provide the SIP message again for processing.

[0016] By optimizing this process, the application layer can effectively control the session setup delays induced by the TCP layer. For example, by setting an appropriate error count threshold, the application layer can trigger TCP connection recovery more quickly than if it simply waited until the entire TCP process failed, such as when the TCP layer sent a FAIL message to the application layer.

[0017] Furthermore, it should be noted that the TCP layer in this process may not be aware that the data it receives for processing is a SIP message. Therefore, the disclosed principles do not need to be limited to sending SIP messages, nor do they need to be limited to packet-based session setup signaling, but can be extended more generally to any data transmission. Moreover, the disclosed principles do not need to be limited to the interaction between the application layer and the TCP layer, but can be extended more generally to the interaction between (i) any protocol stack layer higher than the TCP layer and (ii) the TCP layer.

[0018] Accordingly, in one embodiment, a method for controlling TCP layer processing within a device is disclosed, the device having a protocol stack defining a sequence of logical layers, configured to process data for outbound transmission from the device through the sequence of logical layers, the sequence of logical layers including the TCP layer and higher layers that precede the TCP layer in the sequence. According to the method, when the device passes data from the higher layers to the TCP layer for processing at the TCP layer, the device reports a count of the number of TCP errors that occurred during processing of the data at the TCP layer from the TCP layer to the higher layers, and the higher layers use the reported count as a basis for controlling the resumption of TCP layer processing of the data.

[0019] In another embodiment, a device is disclosed. The device includes a processor, non-temporary data storage, and program instructions executable by the processor to define a protocol stack having a sequence of logical layers for processing data to be sent outbound from the device, the sequence of logical layers including a TCP layer and a higher layer that precedes the TCP layer in the sequence. According to the program instructions, when the processor passes data from the higher layer to the TCP layer for processing at the TCP layer, the processor reports a count of the number of TCP errors that occurred during processing of the data at the TCP layer to the higher layer, and the higher layer uses the reported count as a reference to control the resumption of TCP layer processing of the data.

[0020] In yet another embodiment, a non-temporary computer-readable medium is disclosed which stores program instructions executable by the device's processor to define a protocol stack having a sequence of logical layers for processing data for outbound transmission from the device, the sequence of logical layers including a TCP layer and a higher layer that precedes the TCP layer in the sequence. According to the program instructions, when the processor passes the data from the higher layer to the TCP layer for processing at the TCP layer, the processor reports a count of the number of TCP errors that occurred during processing of the data at the TCP layer to the higher layer, and the higher layer uses the reported count as a reference to control the resumption of TCP layer processing of the data.

[0021] In yet another embodiment, a system is disclosed that includes various means for performing each of the operations described herein.

[0022] These and other embodiments, advantages, and alternatives will become apparent to those skilled in the art by reading the following detailed description with reference to the accompanying drawings as appropriate. Furthermore, it should be understood that the summary of this invention and the description provided below are illustrative examples of the invention and are not intended to limit it.

Brief Description of the Drawings

[0023] [Figure 1] It is a diagram of an exemplary communication system to which various disclosed principles can be applied. [Figure 2] It is a message flow diagram showing an exemplary SIP signaling process. [Figure 3] It is a simplified diagram of an exemplary protocol stack. [Figure 4] It is a message flow diagram showing an exemplary TCP handshake process. [Figure 5] It is a message flow diagram showing an exemplary TCP transmission and acknowledgment scheme. [Figure 6] It is a message flow diagram showing an exemplary process according to the present disclosure. [Figure 7] It is a message flow diagram showing another exemplary process according to the present disclosure. [Figure 8] It is a message flow diagram showing another exemplary process according to the present disclosure. [Figure 9] It is a message flow diagram showing another exemplary process according to the present disclosure. [Figure 10] It is a message flow diagram showing another exemplary process according to the present disclosure. [Figure 11] It is a message flow diagram showing another exemplary process according to the present disclosure. [Figure 12] It is a flowchart showing an exemplary method. [Figure 13] It is a simplified block diagram of an exemplary device.

Modes for Carrying Out the Invention

[0024] Exemplary methods, devices, and systems are described herein. However, it should be understood that any embodiment disclosed should not necessarily be construed as more preferable or advantageous than other embodiments unless otherwise stated. Furthermore, it should be understood that variations are possible from certain configurations and processes disclosed. For example, various entities, components, connections, operations, and other elements disclosed may be added, omitted, distributed, duplicated, rearranged, reordered, combined, or otherwise modified. Furthermore, it should be understood that various technical operations disclosed may be implemented at least partially by programmed processing units to perform these operations or to cause one or more other entities to perform the operations.

[0025] This specification describes an exemplary implementation of a VoIP call setup in which a mobile calling device performs SIP signaling over a cellular radio network with a call server bridging the VoIP call to the receiving device, and the calling device manages the SIP signaling at the application layer. However, as described above, the disclosed principles may be similarly applicable to other scenarios. For example, the principles may be applicable to different data communications, different protocol stack layers, different types of devices, and / or different network connections. Furthermore, with respect to a VoIP call setup, the disclosed principles may be applied directly between the calling and receiving devices with respect to SIP signaling, and / or to other forms of session setup signaling. Other variations may also be possible.

[0026] Referring to the drawings, as described above, Figure 1 is a simplified diagram of an exemplary communication system to which various disclosed principles can be applied. The exemplary communication system includes a cellular wireless communication network having an access node 100 such as an advanced node B (eNodeB) and a core network 102 that provides connectivity to a transport network 104 such as the Internet. Furthermore, the exemplary system includes an Internet Multimedia Subsystem (IMS) 106 that functions as a call server as discussed above and can support, for example, the setup and bridging of VoIP calls. Furthermore, an exemplary calling device 110 such as a mobile phone is shown as being serviced by the access node 100 via a radio frequency (RF) air interface 108, and an exemplary receiving device 112 such as another mobile phone (which may be serviced by the same or other cellular system) is shown as being accessible via the transport network 104.

[0027] The access node 100 may be configured to provide coverage and services on one or more radio frequency (RF) carriers that define each cell. In each cell, the access node 100 can provide services to user equipment devices (UEs) via a defined air interface according to a defined air interface protocol or radio access technology such as 4G Long-Term Evolution (LTE) or 5G New Radio (5G NR). Furthermore, the core network 102 may be a packet-switched network such as an advanced packet core (EPC) network or a next-generation core (NGC) network, and may include both a user plane subsystem through which UE bearer communications are exchanged with the transport network 104, and a control plane subsystem that supports functions such as UE authentication, mobility management, and bearer management.

[0028] IMS106 may support VoIP call services and other packet-based real-time media sessions. To facilitate this, IMS106 may include a Call Session Control Function Unit (CSCF) 114 that supports SIP signaling and a media server 116 that supports RTP communication (in practice, IMS106 may include multiple CSCFs, including a proxy CSCF (P-CSCF), an inquiry CSCF (I-CSCF), and a service CSCF (S-CSCF), and CSCF114 is the S-CSCF). IMS may be accessible through the transport network 104 and / or through or as part of the core network 102. Therefore, once the originating device 110 is serviced by the access node 100, the originating device 110 can perform SIP signaling with the CSCF 114 via the air interface 108, the access node 100, the core network 102, and optionally the transport network 104, thereby facilitating the setup of a VoIP call with the incoming device 112, among other possibilities.

[0029] In this configuration, the calling device 110 and CSCF114 can become endpoints for SIP signaling carried over TCP, as discussed above. Specifically, when a user of calling device 110 attempts to make a call to a user of receiving device 112, for example by instructing the receiving device 112 to initiate a call to a telephone number assigned to the receiving device 112, calling device 110 can perform SIP signaling with CSCF114 to set up the call.

[0030] To facilitate this call setup signaling, if the calling device 110 is not yet registered with IMS 106, the calling device 110 may perform a SIP registration process with CSCF 114. For example, the calling device 110 may send a SIP REGISTER message to CSCF 114, and after authentication and other processing by IMS, CSCF 114 may respond to the calling device 110 with a SIP 200 OK message to complete the registration process.

[0031] Once the calling device 110 is registered with the IMS 106, the calling device may perform SIP signaling with the CSCF 114 to initiate a VoIP call with the recipient, and the CSCF 114 (in some cases in cooperation with the remote IMS) may responsively perform SIP signaling with the receiving device 112 to set up the call. The SIP signaling involved in this process may take various forms, an example of which is shown in Figure 2.

[0032] As shown in Figure 2, the calling device 110 first sends a SIP INVITE message carrying the incoming user's SIP address to the CSCF 114, which responds by sending a corresponding SIP INVITE message to the incoming device 112 and a SIP 100 TRYING message to the calling device 112. When the incoming device 112 initiates a call to attract the incoming user's attention, the incoming device 112 responds with a SIP 180 RINGING message, to which the CSCF 114 subsequently sends a corresponding SIP 180 RINGING message to the calling device 110. Furthermore, when the incoming user answers the call on the incoming device 112, the incoming device 112 responds with a SIP 200 OK message, to which the CSCF 114 subsequently sends a corresponding SIP 200 OK message to the calling device 110. Subsequently, the calling device 110 sends a SIP ACK message to the CSCF 114 to complete the setup of the outgoing RTP call leg between the calling device 110 and the IMS 106. The CSCF 114 then sends a corresponding SIP ACK message to the receiving device 112 to complete the setup of the incoming RTP call leg between the IMS 106 and the receiving device 112. The IMS 106 then bridges these call legs together to enable the caller and the recipient to communicate with each other.

[0033] As described above, in order to facilitate SIP signaling, the originating device 110 may include a protocol stack that defines a sequence of logical processing layers, including an application layer that handles SIP signaling and a TCP layer that handles transport control.

[0034] Figure 3 shows an exemplary protocol stack 300 that the originating device 110 may implement for this purpose and other purposes. As shown in the figure, the exemplary protocol stack 300 includes, from top to bottom, the application layer 302, the TCP layer 304, the IP layer 306, the MAC layer 308, and the physical layer 310, some of which have been described above. The exemplary protocol stack may also include other layers and may take on other forms. For example, the exemplary protocol stack may include a session layer between the application layer 302 and the TCP layer 304, the session layer may function to handle the negotiation of RTP session parameters, among other possibilities.

[0035] Each of these logic processing layers may be defined by a set of program logic, such as a program module, which can be executed by the processor of the originating device 110 to perform the operation of the processing layer, among other possibilities. Thus, characterizing a layer that performs a function may mean that the device performs the function by executing program instructions that define the layer, for example.

[0036] In accordance with the above discussion, when the originating device 110 attempts to send a SIP message to the CSCF 114, the application layer 302 of the originating device 110 may generate the SIP message and pass the SIP message to the lower stack 300, in which case the SIP message flows as data to the TCP layer 304, either directly or through one or more intervening layers (which may modify the message in ways irrelevant at this point). Furthermore, in accordance with the above discussion, the TCP layer may then perform processing to facilitate the communication of this data to the corresponding TCP layer at the CSCF 114. For example, the TCP layer may divide the data into chunks and add a TCP header with a sequence number associated with each chunk, and the originating device 110 may process the resulting TCP packet at a lower layer to facilitate the final communication to the CSCF 114. Similarly, when CSCF114 attempts to send a SIP message to the originating device 110, the application layer of CSCF114 may similarly generate a SIP message, which may flow as data into the TCP layer of CSCF114 and function to communicate data to the TCP layer 304 of the originating device 110.

[0037] When the originating device 110 attempts to initiate SIP communication with the CSCF114, if the originating device 110 and the CSCF114 do not yet have a TCP session established with each other for this purpose, they may first perform a TCP handshake process to establish a TCP session. This TCP handshake process may be a three-way handshake process, as shown in Figure 4.

[0038] As shown in Figure 4, the originating device 110 first sends a TCP SYN message to the CSCF 114, which may be a TCP packet that has no payload but has header parameters, the header parameters indicating that the TCP SYN message is a SYN message and indicating a sequence number selected by the originating device 110. Upon receiving this TCP SYN message, the CSCF 114 may then respond with a TCP SYN / ACK message, which acknowledges the originating device's SYN message and provides its own SYN message that has no payload but has the following header parameters, the header parameters indicating that (i) the TCP SYN / ACK message is a SYN / ACK message, (ii) the sequence number selected by the CSCF 114 (for the SYN), and (iii) an ACK number that is one greater than the sequence number in the originating device's SYN message. Next, upon receiving this SYN / ACK message, the originating device 110 may acknowledge the CSCF's SYN message and respond with a TCP ACK message that similarly has no payload but has header parameters, which include (i) an indication that the TCP ACK message is an ACK message, (ii) a sequence number one greater than the sequence number in the originating device's SYN message (i.e., the same as the ACK number in the SYN / ACK message sent by CSCF114), and (iii) an ACK number one greater than the sequence number in the CSCF's SYN / ACK message, and generally one sequence number after the sequence number in the CSCF's ACK-SYN message. This may result in the originating device 110 and CSCF114 having an established TCP session, through which they can further TCP signal each other, generally continuing to communicate using the sequence numbers used in the handshake process.

[0039] Once the transmitting device 110 and CSCF 114 have established a TCP session with each other, they can then communicate data with each other through that session using the transmit and acknowledgment scheme as discussed above. That is, once the transmitting end generates a TCP packet, the transmitting device may send each TCP packet to the receiving end (i.e., pass the TCP packet from the TCP layer of the transmitting device to the protocol stack of the lower transmitting device, to the lower receiving device for final transmission over the physical communication path, and from the protocol stack of the receiving device to the TCP layer of the higher receiving device). Furthermore, for each such packet, the transmitting device expects to receive a corresponding TCP ACK from the receiving device in a timely manner, and may retransmit the TCP packet (limited by the maximum retransmission setting) if such a TCP ACK is not received in a timely manner.

[0040] Figure 5 illustrates the TCP transmission and acknowledgment scheme for an exemplary TCP data packet transmission from the originating device 110 to the CSCF114. As shown in Figure 5, the originating device 110 first sends a TCP packet to the CSCF114. If the originating device 110 does not receive a corresponding TCP ACK from the CSCF114 within a defined retransmission timer period, the originating device 110 then retransmits the TCP packet to the CSCF114. Upon receiving a corresponding TCP ACK from the CSCF114, the originating device 110 may then continue by sending the next TCP packet to the CSCF114, and so on.

[0041] In line with the above discussion, for each TCP packet that TCP Layer 304 of the originating device 110 is attempting to send to the corresponding TCP Layer of CSCF114, TCP Layer 304 may include a sequence number in the TCP packet header, which is incremented from the sequence number of the last TCP packet by an amount equal to the number of bytes in that last TCP packet. Furthermore, for each such TCP packet that TCP Layer 304 passes to the lower IP Layer 306 for processing, TCP Layer 304 may expect to receive a TCP ACK from CSCF114 within a defined retransmission timer period, carrying an ACK number equal to the next sequence number that TCP Layer 304 will use. If such a TCP ACK is not received, TCP Layer 304 may retransmit as described above. Similarly, when TCP Layer 304 receives a TCP data packet from CSCF114, TCP Layer 304 may expect that the TCP data packet has an appropriate sequence number, taking into account the TCP transmissions that TCP Layer 304 has received from CSCF114 so far in the TCP session.

[0042] Furthermore, in line with the above discussion, TCP layer 304 may detect the occurrence of various TCP errors. Specifically, as discussed above, examples of these errors include (i) TCP retransmission, in which TCP layer 304 retransmits a TCP packet because it did not receive the expected ACK for the TCP packet; (ii) TCP duplicate ACKs, in which TCP layer 304 receives multiple ACKs that mutually specify the same sequence number; (iii) TCP out of order, in which TCP layer 304 receives a TCP packet with a sequence number higher than the numbers it has acknowledged so far; and (iv) TCP previous segment not captured, in which TCP layer 304 receives a TCP packet with sequence number N without having received a previous TCP packet whose sequence number plus data length is N.

[0043] As described above, these TCP errors and / or other TCP errors can cause undesirable delays in VoIP call setup by delaying SIP signaling between the originating device 110 and the CSCF114. This delay in VoIP call setup can occur at various stages of the process. For example, the delay may occur in a scenario where the originating device 110 responds to a user request to initiate a VoIP call by first registering with the CSCF114 in SIP before sending a SIP INVITE for the call. Another example of a delay that may occur is in SIP INVITE / OK / ACK messaging with the CSCF114.

[0044] Furthermore, delays in SIP signaling can be caused by one or more TCP errors related to outbound SIP messaging and / or inbound SIP messaging. For example, if originating device 110 attempts to send a SIP INVITE message to CSCF114, one or more TCP errors in sending that SIP INVITE to CSCF114 may cause a delay in the process. Additionally or alternatively, assuming that originating device 110 sends a SIP INVITE message to CSCF114 and receives a SIP 100 TRYING message in response, one or more TCP errors in sending the SIP 100 TRYING message from CSCF114 to originating device 110 may cause a delay in the process. Moreover, one or more TCP errors may occur during the TCP handshake process and / or TCP data communication. Other examples are similarly possible.

[0045] As further described above, the application layer 302 of the originating device 110 may apply a request timeout timer to control the time it waits for successful transmission of SIP messaging. When the application layer 302 passes the SIP message to the underlying protocol stack for transmission, the application layer 302 may start this timer, and if the timer expires without the application layer 302 receiving an expected response to the SIP message, the application layer 302 may retransmit the SIP message or conclude that the call setup process has failed.

[0046] To circumvent this problem, as described above, application layer 302 puts TCP layer 304 into error reporting mode, where the TCP layer notifies application layer 302 of the TCP layer error count. Then application layer 302 detects when the TCP layer error count reaches a threshold, and at that point, application layer 302 can trigger TCP connection recovery and then re-submit SIP messages for processing.

[0047] In an exemplary implementation, when operating in error reporting mode, TCP layer 304 can track a count of the number of TCP errors that occur and report the current count to application layer 302 each time a TCP error occurs. Each time application layer 302 receives such a count from TCP layer 304, the application layer can determine whether the reported current TCP layer error count has reached at least a predetermined threshold count (for example, by comparing the reported count with a threshold count). If application layer 302 determines that the reported TCP layer error count is below the predetermined threshold count, application layer 302 does not need to take any action in response to this report. On the other hand, if application layer 302 determines that the reported TCP layer error count has reached at least a predetermined threshold count, application layer 302 may trigger TCP connection recovery and re-submit a SIP message for processing.

[0048] In a variation of this implementation, the TCP layer 304 may provide such a report to the application layer 302 for each group of TCP errors, for example, every two TCP errors. Furthermore, in an alternative implementation, the TCP layer 304 may otherwise notify the application layer 302 of the TCP layer error count so that the application layer 302 can use the TCP layer error count as a basis for determining when to trigger TCP connection recovery and re-submit SIP messages for processing. For example, doing so may include reporting the occurrence of TCP layer errors to the application layer 302 and having the application layer 302 track the count based on the report.

[0049] To facilitate this process, the program code of TCP layer 304 may include a "Start TCP Error Notification Display" function that application layer 302 can call to transition TCP layer 304 into error reporting mode. This function call can be constructed with various arguments.

[0050] For example, a function call may include a reset argument to reset or start the TCP layer error count. In an exemplary implementation, the TCP layer error count may be represented by a variable n, in which case this argument can set n to equal to zero. Furthermore, a function call may, if necessary, restrict TCP layer error reporting to only one or more specific types of TCP errors. For example, a function call may include a bitmask indicating one or more TCP errors that should be considered in order to increment the TCP layer error count (thus excluding one or more other TCP errors from the TCP layer error count). Such an exemplary bitmask may be a 4-bit string, where each bit represents a given TCP error, with a value of 1 meaning the error should be counted or reported, and a value of 0 meaning the error does not need to be counted or reported. For example, the lowest digit (0001) could represent a TCP "retransmission," the next highest digit (0010) could represent a TCP "out of order," the next highest digit (0100) could represent a "duplicate ACK," and the highest digit (1000) could represent a "failure to capture the previous segment."

[0051] When application layer 302 calls this "Start TCP Error Notification Display" function of TCP layer 304, TCP layer 304 may enter error reporting mode and respond to application layer 302 with a "TCP Error IND" message that provides the current TCP layer error count whenever a TCP error occurs. For example, if the error count is represented by a variable n, the "TCP Error IND" could carry or provide n, which is the current count value c, to application layer 302 as "TCP Error IND(n=c)".

[0052] Application layer 302 may be configured with or constitute itself using a threshold count value which may be represented by the variable N. Each time application layer 302 receives the current error count n from TCP layer 304 to subsequently trigger a TCP reset and determine whether to resend the SIP message, application layer 302 compares the reported error count n with the threshold N to determine whether n has reached at least N.

[0053] Furthermore, the TCP layer 304 program code may include a “stop TCP error reporting” function that the application layer 302 can call to stop TCP error reporting at the TCP layer. The application layer 302 can call this function when it determines that TCP layer error reporting is no longer desirable. For example, when the application layer 302 receives an expected response to an application layer SIP message, it may call this function to stop TCP layer error reporting.

[0054] Furthermore, the TCP layer 304 program code may also include a "TCP Connection Recovery REQ" function that the application layer 302 can call to trigger TCP connection recovery. The application layer 302 may call this function to trigger TCP connection recovery when it detects, based on a report from the TCP layer 304, that the current TCP layer error count has reached at least a predetermined error count threshold. The TCP layer 304 then responds to this function call by performing the TCP connection recovery process, and can then return a result message to the application layer 302, for example, by sending a "TCP Connection Recovery RESP" message to the application layer 302 indicating whether the TCP connection recovery was successful or not.

[0055] The TCP connection recovery process performed by TCP Layer 304 upon receiving a "TCP Connection Recovery Request" may include TCP Layer 304 sending a TCP RST or TCP SYN message to CSCF114 to re-establish the TCP connection between the originating device 110 and CSCF114. For example, TCP Layer 304 may send a TCP RST message to CSCF114 that does not carry a payload but includes an indication in its header that it is a reset request. This reset request results in the disconnection of the existing TCP session between the originating device 110 and CSCF114 and the re-establishment of the TCP connection. Furthermore, if the TCP session is disconnected without the reset request re-establishing the TCP connection, the TCP connection recovery process may include TCP Layer 304 operating to establish a new TCP session with CSCF114 by performing a new TCP handshake process, for example, as discussed above. In a scenario where the originating device 110 has a TCP connection with CSCF114 and also has one or more other TCP connections (e.g., data TCP connections), the device can limit the recovery of this TCP connection to the TCP connection the device has with CSCF114.

[0056] If this TCP connectivity recovery process or any other such TCP connectivity recovery process successfully re-establishes or recovers TCP connectivity between the originating device 110 and the CSCF 114, the TCP layer 304 may return a DONE response to the application layer 302. At that point, the application layer 302 may re-submit the SIP message in question and, if applicable, set the SIP request timeout timer to half of the value initially set by the application layer 302 to prevent the call setup process from taking too long. On the other hand, if this process fails, such as if TCP connectivity is not recovered, the TCP layer 304 may return a "FAIL" response to the application layer 302, which may indicate a failure in setting up the VoIP call.

[0057] Figures 6-9 illustrate an example of how this process can actually work.

[0058] Figure 6 illustrates an example of how application layer 302 may initiate error reporting for an exemplary SIP message to TCP layer 304, and then, once application layer 302 receives a response to the SIP message, may cause TCP layer 304 to stop reporting the error.

[0059] As shown in Figure 6, when the application layer is about to send a SIP INVITE message, the application layer 302 first instructs the TCP layer 304 to begin reporting errors by calling the "Start TCP Error Notification" function as described above. In this example, the application layer 302 resets the error count n to zero and specifies that the TCP layer 304 should report the error count when each TCP retransmission error and / or each TCP duplicate ACK error occurs by including the bitmask 0101. Next, the application layer 302 passes the SIP INVITE message to the lower stack for processing. If there is no TCP session with the CSCF114 yet, the TCP layer 304 performs the TCP handshake process with the CSCF114. Then, once the TCP session is established, the TCP layer 304 sends the SIP INVITE data as one or more TCP packets to the TCP layer of the CSCF114. Next, CSCF114 responds to the originating device's SIP INVITE with a SIP 100 TRYING message, thereby passing the originating device's protocol stack to the higher-level application layer 302. Then, in response to the timely receipt of this SIP response message, and provided that the application layer also receives other expected SIP response messages such as a SIP 200 OK message as necessary, the application layer 302 calls the "stop TCP error notification" function in TCP layer 304.

[0060] Figure 7 shows an example of how the process might be executed if one or more TCP errors occur during the TCP handshake process. In particular, Figure 7 is a variation of the process shown in Figure 6, and this is what is shown.

[0061] As shown in Figure 7, when TCP layer 304 sends a TCP SYN to CSCF114, TCP layer 304 detects that there is no expected SYN-ACK in the response from CSCF114, and therefore may retransmit the TCP SYN. ​​Furthermore, TCP layer 304 may provide application layer 302 with a "TCP Error IND" report indicating that the current TCP layer error count is 1, i.e., n=1. This figure assumes, as an example, that a given threshold error count N is 3. Therefore, in response to this error report containing a value n smaller than the threshold N, application layer 302 may continue to wait for a SIP response message.

[0062] As shown in the figure, TCP layer 304 may then detect the occurrence of a TCP out-of-order error and a previous segment capture failure error, but these TCP errors may not trigger an error report to application layer 302 because they were not included in the exemplary bitmask of the application layer's "start TCP error notification" call to TCP layer 304. Next, TCP layer 304 may detect a TCP duplicate ACK error and therefore provide the application layer with an error report indicating that the current TCP layer error count is 2, i.e., n=2. Again, since the reported error count is less than N, application layer 302 may continue to wait for a SIP response message.

[0063] Next, the process may continue as shown in Figure 6, in which application layer 302 receives one or more expected SIP response messages and therefore instructs TCP layer 304 to stop reporting TCP errors.

[0064] Figure 8 shows how the process might proceed if the error report from TCP layer 304 indicates that the current TCP layer error count has reached at least the threshold N, and that TCP connection recovery was successful. In particular, Figure 8 is a variation of Figure 6, which is shown below.

[0065] As shown in Figure 8, when application layer 302 is attempting to send a SIP message such as SIP INVITE or SIP REGISTER, application layer 302 first instructs TCP layer 304 to begin error reporting by calling the "start TCP error reporting" function as described above. In this example, application layer 302 resets the error count n to zero and specifies that TCP layer 304 should report the error count when each TCP retransmission error occurs by including the bitmask 0001. Next, application layer 302 passes the SIP message to the lower stack for processing.

[0066] Furthermore, as shown in the diagram, TCP layer 304 then experiences three TCP SYN retransmissions, reporting the latest error count value n to the application layer each time. When the error count n equals the error count threshold N (e.g., N=3 and n=3), application layer 302 takes action to address the high TCP error count. Specifically, application layer 302 instructs TCP layer 304 to stop reporting errors by calling the “Stop TCP Error Notifications” function. Furthermore, application layer 302 stops its SIP timer(s) and initiates TCP connection recovery by calling the “TCP Connection Recovery REQ” function of TCP layer 304. Upon successful TCP recovery, TCP layer 304 provides a positive “DONE” response to application layer 302. Furthermore, upon receiving this DONE response, application layer 302 resubmits the SIP message for transmission and sets its SIP timer(s) to half their value.

[0067] Figure 9 illustrates how the process might proceed if an error report from TCP Layer 304 indicates that the current TCP Layer error count has reached at least the threshold N, and that TCP connection recovery was unsuccessful. In particular, Figure 9 is a variation of Figure 8, which is shown here. As shown in Figure 9, since the TCP connection recovery process is unsuccessful, TCP Layer 304 sends a "FAIL" response to Application Layer 302. At this point, Application Layer 302 may set the SIP timer(s) to half and try the process again, or Application Layer 302 may consider the VoIP call setup process to have failed.

[0068] In further or alternative implementations, the application layer 302 may be configured to trigger TCP connection recovery in response to (i) detecting a SIP request timeout expiration and (ii) receiving a report from the TCP layer 304 indicating a TCP error count of at least one or at least another threshold. Figures 10–11 illustrate how this can actually work.

[0069] Figure 10 shows an example of how application layer 302 can trigger TCP connection recovery in this situation where connection recovery has been successful.

[0070] As shown in Figure 10, when application layer 302 is about to send a SIP INVITE message, application layer 302 first instructs TCP layer 304 to begin reporting errors by calling the "start TCP error notification" function as described above. Again in this example, application layer 302 resets the error count n to zero and specifies that TCP layer 304 should report the error count when each TCP retransmission error occurs by including the bitmask 0001. Next, application layer 302 passes the SIP INVITE message to the lower stack for processing.

[0071] As shown in the diagram, the TCP layer 304 then experiences a TCP SYN retransmission and reports to the application layer 302 that the current error count is 1, i.e., n=1. Furthermore, the application layer 302 also detects that the SIP request timeout timer has expired. In response to the current TCP layer error count being at least 1 and the SIP request timeout timer expiring (or, for example, in response to a combination of these factors), the application layer 302 then takes action to address the situation. Specifically, the application layer 302 instructs the TCP layer 304 to stop reporting errors by calling the “stop TCP error notification” function. Furthermore, the application layer 302 stops its SIP timer(s) and initiates TCP connection recovery by calling the TCP layer 304's “TCP connection recovery REQ” function. If the TCP recovery is successful, the TCP layer 304 provides the application layer 302 with a positive “DONE” response. Furthermore, upon receiving this DONE response, application layer 302 resubmits the SIP INVITE message for transmission and sets its SIP timer(s) to half its value.

[0072] Figure 11 shows how the TCP connection recovery process may be executed if it fails. In particular, Figure 11 is a variation of Figure 10, which is shown here. As shown in Figure 11, since the TCP connection recovery process fails, TCP layer 304 sends a "FAIL" response to application layer 302. At this point, application layer 302 may set the SIP timer(s) to half their value and try the process again, or application layer 302 may consider the VoIP call setup process to have failed.

[0073] Next, Figure 12 is a flowchart illustrating a method implemented pursuant to this disclosure to control TCP layer processing within a device, the device having a protocol stack that defines a sequence of logical layers, and configured to process data for transmission from the device through the sequence of logical layers, the sequence of logical layers including the TCP layer and higher layers that precede the TCP layer in the sequence. As shown in Figure 12, in block 1201, the method includes the device reporting to the higher layers from the TCP layer a count of the number of TCP errors that occurred during processing of the data at the TCP layer, once the device has passed the data from the higher layers to the TCP layer for processing at the TCP layer. Furthermore, in block 1204, the method includes the device using the reported count as a reference at the higher layers to dynamically control the resumption of TCP layer processing of the data.

[0074] In line with the above discussion, the upper layer can be the application layer. Furthermore, the data can represent SIP messages that may be part of setup messaging for setting up a VoIP call. Also, as discussed above, TCP errors can include at least one error such as (i) TCP retransmission, (ii) TCP duplicate ACK, (iii) TCP out of order, and / or (iv) TCP failure to capture previous segment.

[0075] Furthermore, as discussed above, this method may involve the device providing instructions from the upper layer to the TCP layer to cause the TCP layer to report to the upper layer. As described above, the upper layer may use function calls defined in the TCP layer. Alternatively, the upper layer may call other functions to consequently instruct the TCP layer in this manner. Furthermore, as discussed above, the device may include, along with the instructions, a specification (e.g., a bitmask representation) of one or more types of TCP errors to be included in the count.

[0076] As discussed in addition above, in order to facilitate the updated processing of data that may be re-provided by higher layers, the TCP layer may have a TCP connection with a remote node, such as a CSCF or another IMS entity, and the action of resuming TCP layer processing of the data may include resetting that TCP connection.

[0077] As further discussed above, actions taken by a device at a higher layer to control the resumption of TCP layer processing of data may include (i) the device at a higher layer determining whether the reported count has reached at least a predetermined threshold count, and (ii) the device, at least based on the determination that the reported count has reached at least a predetermined threshold count, initiating the resumption of TCP layer processing of data, for example, by sending a TCP connection recovery request.

[0078] Furthermore, as discussed above, the threshold count may be greater than 2, or it may simply be 1. Furthermore, as described above, the upper layer may use both the reported count and the expiration of its own timer as criteria to trigger the resumption of TCP layer processing of the data. For example, in a scenario where a device applies a request timeout timer at the upper layer and waits for a response when it passes data from the upper layer to the lower TCP layer, the actions taken by the device at the upper layer to control the resumption of TCP layer processing of the data, using the reported count as a criterion, may include (a) the device at the upper layer determining both (i) whether the reported count is at least 1 and (ii) whether the request timeout timer has expired, and (b) in response to the determination that it is positive, the device initiating the resumption of TCP layer processing of the data.

[0079] Figure 13 is a simplified block diagram of an exemplary device 1300 that may be configured to perform the operations described above. For example, this device may be a transmitting device 110 and / or other devices that perform the operations. The devices illustrated herein are wireless communication devices such as mobile phones. However, the disclosed principles can be applied similarly to other types of devices.

[0080] As shown in Figure 13, the exemplary device includes a wireless communication interface 1302, a user interface 1304, a processor 1306, and non-temporary data storage 1308, all of which can be integrated and / or linked in a communicative manner in various ways, for example, via a system bus, a network, or another connection mechanism 1310.

[0081] The wireless communication interface 1302 may include one or more modules to facilitate wireless communication between device 1300 and other entities. The wireless communication interface 1302 may support communication according to one or more air interface protocols such as WiFi, BLUETOOTH®, UWB, and cellular (e.g., 4G, 5G, 6G, etc.). As shown in the figure, the wireless communication interface 1302 may include one or more radios 1312, one or more amplifiers 1314, and one or more antennas 1316. One or more radios 1312 may include one or more radio transmitters configured to modulate a baseband signal on a radio frequency (RF) carrier, and one or more radio receivers configured to demodulate a baseband signal from one or more RF carriers. One or more amplifiers 1314 may be configured to amplify outbound signals for transmission and / or inbound signals for processing. And one or more antennas 1316 may be configured to transmit and / or receive RF signals. The wireless communication module 1302 may further include various circuits and / or other logic to facilitate operation according to an exemplary air interface protocol.

[0082] The user interface 1304 may include one or more components to facilitate the user's interaction with the device 1300. For example, the user interface 1304 may include various output components such as a display screen, an audio speaker, indicator lights, and a haptic feedback interface, as well as associated circuitry and / or other logic to facilitate the operation of these output components. Furthermore, the user interface 1304 may include various input components such as a touchscreen interface integrated with the display screen, a microphone, and a keypad, as well as associated circuitry and / or other logic to facilitate the operation of these input components.

[0083] The processor 1306 may include one or more general-purpose processors (e.g., one or more microprocessors) and / or one or more dedicated processors (e.g., application-specific integrated circuits). Furthermore, the non-temporary data storage 1308 may include one or more volatile and / or non-volatile storage components (e.g., read-only memory, random-access memory, flash storage, cache memory, etc.) which are optionally integrated all or partially with the processor 1306.

[0084] As shown in the figure, the data storage 1308 may store program instructions 1318 that can be executed by the processor 1306 to perform various operations described herein. For example, the program instructions 1318 may define a protocol stack 1320 and, among other possibilities, may be executable to perform operations such as those described in relation to Figure 12.

[0085] The various features described herein can be implemented in this context, and vice versa.

[0086] As discussed in addition to the above, this disclosure also envisions a non-temporary computer-readable medium (e.g., optical, magnetic, or flash storage, RAM, ROM, EPROM, EEPROM, etc.) in which program instructions that can be executed by the device's processor to perform various operations described herein, including, among other possibilities, the operations described in relation to Figure 12.

[0087] Exemplary embodiments have been described above. However, those skilled in the art will understand that these embodiments may be modified and altered without departing from the true scope and spirit of the invention.

Claims

1. A method for controlling transport control protocol (TCP) processing within a device, wherein the device has a protocol stack defining a sequence of logical layers, and is configured to process data for transmission from the device via the sequence of logical layers, the sequence of logical layers including a TCP layer and higher layers that precede the TCP layer in the sequence, and the method is When the device passes the data from the upper layer to the TCP layer in order to process the data at the TCP layer, the device reports to the upper layer from the TCP layer the count of TCP errors that occurred during the processing of the data at the TCP layer. A method comprising the device using the reported count as a reference in the upper layer to control the resumption of TCP layer processing of the said data.

2. The method according to claim 1, wherein the upper layer is an application layer.

3. The method according to claim 1, wherein the data represents a Session Initiation Protocol (SIP) message.

4. The method according to claim 3, wherein the SIP message is part of setup messaging for setting up a Voice over Internet Protocol (VoIP) call.

5. The method according to claim 1, wherein the TCP error includes at least one error selected from the group consisting of (i) TCP retransmission, (ii) TCP duplicate ACKs, (iii) TCP out of order, and (iv) TCP previous segment not captured.

6. The method according to claim 1, further comprising providing the device with an instruction from the upper layer to the TCP layer to cause the TCP layer to make the report to the upper layer.

7. The method according to claim 6, wherein the device provides the TCP layer with the command to cause the TCP layer to make the report to the upper layer, the command includes, together with, the designation of one or more types of TCP errors included in the count.

8. The method according to claim 1, wherein the TCP layer has a TCP connection with a remote node, and restarting TCP layer processing of the data includes resetting the TCP connection.

9. To control the resumption of TCP layer processing of the aforementioned data, the device may use the reported count as a reference in the higher layer. The device determines, at the upper layer, whether the reported count has reached at least a predetermined threshold count. The method according to claim 1, comprising the device initiating the restart of TCP layer processing of the data, at least based on the determination that the reported count has reached at least the predetermined threshold count.

10. The method according to claim 9, wherein the threshold count is at least 2.

11. The device applies a request timeout timer in the upper layer to wait for a response when passing the data from the upper layer to the lower TCP layer, and controls the resumption of TCP layer processing of the data by using the reported count as a reference in the upper layer. The device determines, at the upper layer, whether (i) the reported count is at least 1, and whether (ii) the request timeout timer has expired. The method according to any one of claims 1 to 10, comprising: in response to the decision being positive, the device initiating the restart of TCP layer processing of the data.

12. It is a device, Processor and Non-temporary data storage and Includes, a program instruction stored in the non-temporary data storage and executable by the processor to perform an operation, The program instructions define a protocol stack having a sequence of logical layers, the device is configured to process data for transmission from the device via the sequence of logical layers, the sequence of logical layers includes a TCP layer and higher layers that precede the TCP layer in the sequence, The aforementioned operation is, When the device passes the data from the upper layer to the lower TCP layer in order to process the data in the TCP layer, the TCP layer reports to the upper layer the count of TCP errors that occurred during the processing of the data in the TCP layer. A device that includes using the reported count as a reference in the upper layer to control the resumption of TCP layer processing of the aforementioned data.

13. The device according to claim 12, wherein the device is a mobile phone.

14. The device according to claim 12, wherein the upper layer is an application layer, and the data represents a session initiation protocol (SIP) message which is part of setup messaging for setting up a Voice over Internet Protocol (VoIP) call.

15. The device according to claim 12, wherein the operation further includes providing the TCP layer with an instruction from the upper layer to cause the TCP layer to make the report to the upper layer.

16. The device applies a request timeout timer in the upper layer to wait for a response when it passes the data from the upper layer to the lower TCP layer. The device according to any one of claims 12 to 15, wherein the upper layer uses the reported count as a criterion to control the resumption of TCP layer processing of the said data, the upper layer determines whether (i) the reported count is at least 1, and (ii) whether the requested timeout timer has expired, and (b) in response to the determination being positive, the device invokes the resumption of TCP layer processing of the said data.

17. A program storing program instructions executable by the device's processor to cause the device to perform operations for controlling transport control protocol (TCP) processing within the device, wherein the device has a protocol stack defining a sequence of logical layers, and is configured to process data for transmission from the device via the sequence of logical layers, the sequence of logical layers including a TCP layer and higher layers preceding the TCP layer in the sequence, and the operation is When the device passes the data from the upper layer to the lower TCP layer in order to process the data in the TCP layer, the TCP layer reports to the upper layer the count of TCP errors that occurred during the processing of the data in the TCP layer. A program that includes using the reported count as a reference in the upper layer to control the resumption of TCP layer processing of the aforementioned data.

18. The program according to claim 17, wherein the upper layer is an application layer, and the data represents a session initiation protocol (SIP) message which is part of setup messaging for setting up a Voice over Internet Protocol (VoIP) call.

19. The program according to claim 17, wherein the operation further includes providing the TCP layer with an instruction from the upper layer to cause the TCP layer to make the report to the upper layer.

20. The device applies a request timeout timer in the upper layer to wait for a response when it passes the data from the upper layer to the lower TCP layer. A program according to any one of claims 17 to 19, wherein the upper layer uses the reported count as a criterion to control the initiation of TCP layer processing of the said data, the upper layer determines whether (i) the reported count is at least 1, and (ii) whether the request timeout timer has expired, and (b) in response to the determination being positive, initiates the restart of TCP layer processing of the said data.

Images