WO2017193262A1

WO2017193262A1 - Handling packet acknowledgments during tune-aways on mobile devices

Info

Publication number: WO2017193262A1
Application number: PCT/CN2016/081423
Authority: WO
Inventors: Ruiming Zheng; Jiming Guo; Rulin XING; Xipeng Zhu; Lizhong Jin; Huichun LIU
Original assignee: Qualcomm Incorporated
Priority date: 2016-05-09
Filing date: 2016-05-09
Publication date: 2017-11-16
Also published as: WO2017193533A1

Abstract

Various methods for managing TCP communications in a mobile communication device may include determining whether there is an upcoming tune-away from a first RAT on the mobile communication device to a second RAT on the mobile communication device, adding a first timestamp to a TCP packet for transmission before the tune-away begins in response to determining that there is an upcoming tune-away from the first RAT to the second RAT, transmitting the TCP packet to a first network, performing the tune-away from the first RAT to the second RAT, triggering a retransmission time out on the first RAT, receiving a TCP acknowledgement (ACK) from the first network, in which the TCP ACK includes a second timestamp, determining whether the TCP ACK corresponds to the TCP packet, and restoring a prior congestion window value of the first RAT in response to determining that the TCP ACK corresponds to the TCP packet.

Description

Handling Packet Acknowledgments During Tune-Aways on Mobile Devices

BACKGROUND

Some designs of mobile communication devices—such as smart phones, tablet computers, and laptop computers—contain one or more Subscriber Identity Module (SIM) cards that provide users with access to multiple separate mobile telephony networks. Examples of mobile telephony network technologies, referred to as radio access technologies (RATs) , include Third Generation (3G) , Fourth Generation (4G) , Long Term Evolution (LTE) , Time Division Multiple Access (TDMA) , Frequency Division Multiple Access (FDMA) , Code Division Multiple Access (CDMA) , Wideband CDMA (WCDMA) , Time Division Synchronous CDMA (TD-SCDMA) , Global System for Mobile Communications (GSM) , Universal Mobile Telecommunications Systems (UMTS) , evolved High Speed Packet Access (HSPA+) , Dual-Cell High Speed Packet Access (DC-HSPA) , Evolution Data-Optimized (EV-DO) , Enhanced Data rates for GSM Evolution (EDGE) , and single carrier Radio Transmission Technologies (1xRTT) .

A mobile communication device that includes one or more SIMs and connects to two or more separate mobile telephony networks using a shared radio frequency (RF) resource/radio may be termed a multi-SIM multi-standby (MSMS) communication device. Sharing the RF resource by concurrent radio access technologies (CRATs) may result in hardware cost savings.

One example of an MSMS communication device is a dual-SIM dual-standby (DSDS) communication device, which includes two SIM cards supporting two subscriptions associated with different RATs sharing one RF resource. In DSDS communication devices, the separate subscriptions share the one RF resource to communicate with two separate mobile telephony networks on behalf of their respective subscriptions. When one RAT is using the RF resource, the other RAT is in stand-by mode and is not able to communicate using the RF resource.

SUMMARY

Various examples of methods for managing transmission control protocol (TCP) communications in a mobile communication device may include determining whether there is an upcoming tune-away from a first radio access technology (RAT) on the mobile communication device to a second RAT on the mobile communication device, adding a first timestamp to a TCP packet for transmission before the tune-away begins in response to determining that there is an upcoming tune-away from the first RAT to the second RAT, transmitting the TCP packet to a first network, performing the tune-away from the first RAT to the second RAT, triggering a retransmission time out on the first RAT, receiving a TCP acknowledgement (ACK) from the first network, in which the TCP ACK includes a second timestamp, determining whether the TCP ACK corresponds to the TCP packet, and restoring a prior congestion window value of the first RAT in response to determining that the TCP ACK corresponds to the TCP packet.

In some examples, determining whether the TCP ACK corresponds to the TCP packet may include comparing the first timestamp to the second timestamp. Some examples may further include adding an offset to the first timestamp, in which the offset is based on an estimated duration of the tune-away. In some examples, a modem of the mobile communication device may add the first timestamp to the TCP packet. In some examples, a high level operating system of the mobile communication device may add the first timestamp to the TCP packet. Some examples may further include keeping a current congestion window value in response to determining that the TCP ACK does not correspond to the TCP packet. In some examples, a congestion value window of the first RAT may be set to one when the retransmission time out is triggered.

Other example methods for managing TCP communications in a network base station may include receiving a tune-away schedule from a mobile communication device, determining whether there is an upcoming tune-away on the mobile communication device from the tune-away schedule, adding a first timestamp to a TCP packet for transmission before the tune-away begins in response to determining that there is an upcoming tune-away on the mobile communication device, transmitting the TCP packet to the mobile communication device, triggering a retransmission time out on TCP communications between the network base station and the mobile communication device, receiving a TCP acknowledgement (ACK) from the mobile communication device, in which the TCP ACK includes a second timestamp, determining whether the TCP ACK corresponds to the TCP packet, and restoring a prior congestion window value on the network base station in response to determining that the TCP ACK corresponds to the TCP packet.

In some examples, determining whether the TCP ACK corresponds to the TCP packet may include comparing the first timestamp to the second timestamp. Some examples may further include adding an offset to the first timestamp, in which the offset is based on an estimated duration of the tune-away. Some examples may further include keeping a current congestion window value in response to determining that the TCP ACK does not correspond to the TCP packet. In some examples, a congestion value window of the network base station may be set to one when the retransmission time out is triggered.

Other example methods for managing TCP communications in a mobile communication device may include transmitting a TCP packet from a first radio access technology (RAT) on the mobile communication device to a first network, receiving a hybrid automatic repeat request (HARQ) acknowledgement (ACK) or a radio link control (RLC) ACK from the first network, generating a local TCP ACK from the HARQ ACK or the RLC ACK, delivering the local TCP ACK to a high level operating system (HLOS) or an application on the mobile communication device, determining whether the first RAT has received a remote TCP ACK from the first network, and ignoring the remote TCP ACK in response to determining that the first RAT has received a remote TCP ACK from the first network.

In some examples, a TCP adaption sub-layer in a packet data convergence protocol layer of a modem in the mobile communication device may generate the local TCP ACK. In some examples, the TCP adaption sub-layer receives the HARQ ACK or the RLC ACK from a medium access control (MAC) layer or an RLC layer of the modem. In some examples, the TCP adaption sub-layer may store a copy of the TCP packet. Some examples may further include determining that a loss of the TCP packet has occurred in response to determining that the first RAT has not received a remote TCP ACK from the first network, and retransmitting the TCP packet. Some examples may further include determining whether there is an upcoming tune-away from the first RAT to a second RAT on the mobile communication device, setting a receive window value of the local TCP ACK to zero in response to determining that there is an upcoming tune-away from the first RAT to the second RAT, and performing the tune-away from the first RAT to the second RAT. Some examples may further include setting the receive window value of the local TCP ACK to a prior receive window value of a prior received TCP ACK in response to determining that there is no upcoming tune-away from the first RAT to the second RAT. Some examples may further include generating one or more local TCP ACKs for each of a plurality of buffered TCP packets during the tune-away, in which each of the one or more local TCP ACKs has a receive window value of zero. Some examples may further include determining whether the remote TCP ACK contains additional information not contained in the local TCP ACK, and delivering the additional information to the HLOS or the application in response to determining that the remote TCP ACK contains additional information not contained in the local TCP ACK.

Other example methods for managing TCP communications in a network base station may include transmitting a TCP packet to a mobile communication device, receiving a hybrid automatic repeat request (HARQ) acknowledgement (ACK) or a radio link control (RLC) ACK from the mobile communication device, generating a local TCP ACK from the HARQ ACK or the RLC ACK, delivering the local TCP ACK to a high level operating system (HLOS) or application on the network base station, determining whether the network base station has received a subsequent remote ACK from the mobile communication device, and ignoring the subsequent remote ACK in response to determining that the network base station has received a subsequent remote ACK from the mobile communication device.

In some examples, a TCP adaption sub-layer in the network base station may generate the local TCP ACK. Some examples may further include determining that a loss of the TCP packet has occurred in response to determining that the network base station has not received a subsequent remote ACK from the mobile communication device, and retransmitting the TCP packet. In some examples, the local TCP ACK may include a receive window value set to equal a prior receive window value of a prior received TCP ACK. Some examples may further include determining whether the subsequent remote ACK contains additional information not contained in the local TCP ACK, and delivering the additional information to the HLOS or the application in response to determining that the subsequent remote ACK contains additional information not contained in the local TCP ACK. Some examples may further include instructing the mobile communication device to not transmit a TCP ACK corresponding to the TCP packet.

Other example methods for managing transmission control protocol (TCP) communications in a mobile communication device may include transmitting a TCP packet from a first radio access technology (RAT) of the mobile communication device to a first network, determining whether there is an upcoming tune-away from the first RAT to a second RAT on the mobile communication device before receiving a TCP response from the first network, buffering a previously received TCP acknowledgment (ACK) in response to determining that there is a tune-away from the first RAT to the second RAT scheduled before receiving a TCP response from the first network, initiating the tune-away, initiating a timer, determining whether the timer has expired, and delivering the buffered TCP ACK to a high level operating system (HLOS) or application on the mobile communication device in response to determining that the timer has not expired.

Some examples may further include reinitiating the timer after delivering the buffered TCP ACK. Some examples may further include determining whether the tune-away has ended, and receiving a TCP response from the first network in response to determining that the tune-away has ended. In some examples, a duration of the timer may be shorter than a retransmission time out threshold time.

Further examples include a mobile communication device including a memory, a subscriber identity module (SIM) , an RF resource configured to support a first RAT and a second RAT, and a processor configured to perform operations of the methods summarized above. Further examples include a non-transitory processor-readable storage medium having stored thereon processor-executable software instructions configured to cause a processor of a mobile communication device to perform operations of the methods summarized above. Further examples include a mobile communication device that includes means for performing functions of the methods summarized above.

Further examples include a network base station including a memory, a network interface, and a processor configured to perform operations of the methods summarized above. Further examples include a non-transitory processor-readable storage medium having stored thereon processor-executable software instructions configured to cause a processor of a network base station to perform operations of the methods summarized above. Further examples include a network base station that includes means for performing functions of the methods summarized above.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated herein and constitute part of this specification, illustrate examples, and together with the general description and the detailed description given herein, serve to explain the features of the disclosed systems and methods.

FIG. 1 is a communication system block diagram of mobile telephony networks suitable for use with various examples.

FIG. 2 is a component block diagram of a multi-SIM mobile communication device according to various examples.

FIG. 3 is The call flow diagram illustrating transmission control protocol (TCP) communications between a mobile communication device and a network according to conventional methods.

FIGS. 4A-4B are call flow diagrams illustrating the utilization of timestamps in TCP communications between a mobile communication device and a network in the presence of a tune-away according to various examples.

FIG. 5 is a block diagram of the communication layers in a mobile communication device according to various examples.

FIG. 6 is The call flow diagram illustrating the utilization of acknowledgement buffers in TCP communications between a mobile communication device and a network in the presence of a tune-away according to various examples.

FIG. 7 is a process flow diagram illustrating a method for utilizing timestamps in TCP communications in a mobile communication device according to various examples.

FIG. 8 is a process flow diagram illustrating a method for utilizing timestamps in TCP communications in a network base station according to various examples.

FIG. 9 is a process flow diagram illustrating a method for generating local acknowledgements for TCP communications in a mobile communication device according to various examples.

FIG. 10 is a process flow diagram illustrating a method for generating local acknowledgements for TCP communications in a network base station according to various examples.

FIG. 11 is a process flow diagram illustrating a method for utilizing acknowledgement buffers for TCP communications in a mobile communication device according to various examples.

FIG. 12 is a component block diagram of a mobile communication device suitable for implementing some example methods.

FIG. 13 is a component block diagram of a network base station suitable for implementing some example methods.

DETAILED DESCRIPTION

Various examples will be described in detail with reference to the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts. References made to particular examples and implementations are for illustrative purposes, and are not intended to limit the scope of the written description or the claims.

As used herein, the term “mobile communication device, ” “multi-SIM mobile communication device, ” or “multi-SIM device” refers to any one or all of cellular telephones, smart phones, personal or mobile multi-media players, personal data assistants, laptop computers, tablet computers, smart books, smart watches, palm-top computers, wireless electronic mail receivers, multimedia Internet-enabled cellular telephones, wireless gaming controllers, and similar personal electronic devices that includes one or more SIM cards, a programmable processor, memory, and circuitry for connecting to at least two mobile communication network with one or more shared RF resources. Various examples may be useful in mobile communication devices, such as smart phones, and so such devices are referred to in the descriptions of various examples. However, the examples may be useful in any electronic devices that may individually maintain a plurality of RATs supporting one or more subscriptions that utilize at least one shared RF chain, which may include one or more of antennae, radios, transceivers, etc.

As used herein, the terms “SIM, ” “SIM card, ” and “subscriber identification module” are used interchangeably to refer to a memory that may be an integrated circuit or embedded into a removable card, and that stores an International Mobile Subscriber Identity (IMSI) , related key, and/or other information used to identify and/or authenticate a mobile communication device on a network and enable a communication service with the network. Because the information stored in a SIM enables the mobile communication device to establish a communication link for a particular communication service with a particular network, the term “subscription” is used herein as a shorthand reference to refer to the communication service associated with and enabled by the information stored in a particular SIM as the SIM and the communication network, as well as the services and subscriptions supported by that network, correlate to one another.

In the following descriptions of various examples, references are made to a first subscription and a second subscription, and to a first RAT and a second RAT. The references to the first and second subscriptions and RATs are arbitrary and are used merely for the purposes of describing the examples. The device processor may assign any indicator, name or other designation to differentiate the subscriptions and RATs on the mobile communication device.

One consequence of having a plurality of RATs that maintain network connections simultaneously using a shared RF resource of a mobile communication device is that one RAT sometimes interrupts communications of the other RAT as one RAT can use the shared RF resource to communicate with its mobile network at a time. Even when a RAT is in an “idle-standby” mode, meaning that the RAT is not actively communicating with the network, the RAT still needs to periodically receive access to the shared RF resource in order to perform various network operations. For example, an idle RAT may need the shared RF resource at regular intervals to perform idle-mode operations or to receive paging messages.

In conventional mobile communication devices, an idle RAT may occasionally interrupt the active RAT’s RF operations so that the idle RAT can use the shared RF resource to perform the idle RAT’s idle mode operations (e.g., paging monitoring and decoding, cell reselection, system information monitoring, etc. ) . This process of switching access of the shared RF resource from the active RAT to the idle RAT is referred to herein as a “tune-away, ” as the RF resource tunes away from the active RAT’s frequency band or channel and tunes to the idle RAT’s frequency bands or channels. After the idle RAT has finished its network communications, access to the RF resource may switch from the idle RAT to the active RAT via a “tune-back” operation. For example, a LTE+GSM DSDS (dual-SIM dual-standby) mobile communication device may have a first subscription utilizing a LTE RAT and a second subscription utilizing a GSM RAT. The mobile communication device may periodically tune the RF resource from the first subscription to the second subscription for page monitoring, voice or short message service (SMS) service, and GSM camping operations (e.g., measuring and making cell reselections if needed, reading system information, location registering, etc. ) .

In CRAT mobile communication devices, tune-aways may also occur between two different RATs utilized by the same subscription. For example, a CRAT device may have one SIM/subscription that utilizes both an LTE RAT and another RAT, such as GSM or CDMA2000. Thus, a tune-away may be performed between the RATs utilized by the same subscription.

Tune-aways from an active RAT to an idle RAT may interfere with communication exchanges on the active RAT. For example, an active RAT may be engaging in uplink communications with a network using a transmission control protocol (TCP) . The active RAT may transmit a TCP packet to a network base station. The network may acknowledge receipt of the TCP packet in a number of different ways. For example, the network may transmit a hybrid automatic repeat request (HARQ) acknowledgement (ACK) , followed by a radio link control (RLC) ACK in response to receiving the TCP packet. The HARQ and RLCs ACK may be transmitted a short time after receiving the TCP packet. At a later time the network may transmit a TCP ACK after transmitting the HARQ and RLC ACKs.

After transmission of the TCP packet and receipt of the HARQ and RLC ACKs, but before receipt of the TCP ACK, the mobile communication device may perform a tune-away to an idle RAT. During the tune-away the active RAT may not receive any TCP ACKs from the network. This may lead the active RAT to trigger a retransmission time out (RTO) . One consequence of triggering a RTO is that the congestion window (cwnd) value of the active RAT may be reduced to one. The congestion window value represents the amount of data for transmission that may be outstanding at any given time. The higher the congestion window value, the higher the data throughput of the active RAT. Thus after an RTO, the data throughput of the active RAT is significantly reduced, and gradually increases according to a slow start procedure. In addition, during a tune-away the TCP layer of the mobile communication device may not know the lower layers (i.e., the layers in the modem) are not available, and so may continue to send data to the modem until a transmission window (twnd) of the active RAT is exhausted. Thus tune-aways may impact the throughput performance of TCP communications on the active RAT even after the tune-away is complete. Further, when a TCP ACK is received, the mobile communication device may not know whether the ACK is acknowledging the original TCP packet or acknowledging a retransmitted TCP packet.

In overview, various examples provide systems and methods implemented with a processor of a mobile communication device (e.g., a multi-SIM mobile communication device) for handling TCP communications in the presence of tune-aways. In some examples, the processor may identify an upcoming tune-away and dynamically add a timestamp to a TCP packet that is transmitted by a first RAT on the mobile communication device before the tune-away begins. If there is no tune-away, then no timestamp is added to a TCP packet. During the tune-away, an RTO may be triggered. After the tune-away is complete, the first RAT may receive a TCP ACK from the network that includes a timestamp. By comparing the timestamp, the mobile communication device may determine whether the TCP ACK corresponds to the original TCP packet transmission. If the timestamp of the TCP ACK matches the timestamp of the transmitted TCP packet, then the TCP ACK corresponds to the TCP packet. The mobile communication device may then restore the prior value of the congestion window rather than have it remain at one because of the RTO, and also stop retransmission. This increases the data throughput of the first RAT. If the TCP ACK does not correspond to the TCP packet, the first RAT may retransmit the TCP packet. This process may also be implemented on a network base station for downlink communications.

In other examples, a TCP adaption sub-layer may be added to a packet data convergence protocol (PDCP) layer of the modem. A first RAT may transmit a TCP packet to a network, and receive a HARQ or RLC ACK from the network. The HARQ/RLC ACK may be passed to the TCP adaption sub-layer, which generates a local TCP ACK from the HARQ/RLC ACK. A receive window value of the TCP ACK may be chosen depending on whether there is an upcoming tune-away. If there is a tune-away, the receive window value may be set to zero, whereas if there is no tune-away the prior receive window value may be maintained. The local TCP ACK is passed to the TCP layer of the mobile communication device (e.g., a high level operating system (HLOS) or application on the mobile communication device) . After the tune-away is complete, the first RAT may receive a remote TCP ACK from the network, and may ignore the remote TCP ACK. If the first RAT does not receive a remote TCP ACK, the processor may determine a packet loss has occurred and retransmit the TCP packet. This process may also be implemented on a network base station for downlink communications.

In other examples, before a tune-away begins the processor may buffer a previously received TCP ACK on the first RAT. During the tune-away, the processor may deliver the buffered TCP ACK to the TCP layer (e.g., the HLOS or application) at an interval that is less than a RTO threshold time. This may result in the HLOS or application reducing the congestion window value (e.g., by half) , but not as much as if a RTO is declared. When the tune-away ends the first RAT may resume receiving TCP responses from the network.

Various examples may be implemented within a variety of communication systems 100, such as at least two mobile telephony networks, an example of which is illustrated in FIG. 1. A first mobile network 102 and a second mobile network 104 typically each include a plurality of cellular base stations (e.g., a first base station 130 and a second base station 140) . A first mobile communication device 110 may be in communication with the first mobile network 102 through a cellular connection 132 to the first base station 130. The first mobile communication device 110 may also be in communication with the second mobile network 104 through a cellular connection 142 to the second base station 140. The first base station 130 may be in communication with the first mobile network 102 over a wired connection 134. The second base station 140 may be in communication with the second mobile network 104 over a wired connection 144.

A second mobile communication device 120 may similarly communicate with the first mobile network 102 through the cellular connection 132 to the first base station 130. The second mobile communication device 120 may also communicate with the second mobile network 104 through the cellular connection 142 to the second base station 140. The

cellular connections

132 and 142 may be made through two-way wireless communication links, such as Third Generation (3G) , Fourth Generation (4G) , Long Term Evolution (LTE) , Time Division Multiple Access (TDMA) , Code Division Multiple Access (CDMA) , Wideband CDMA (WCDMA) , Global System for Mobile Communications (GSM) , Universal Mobile Telecommunications Systems (UMTS) , and other mobile telephony communication technologies.

While the

mobile communication devices

110, 120 are shown connected to the first mobile network 102 and, optionally, to the second mobile network 104, in some examples (not shown) , the

mobile communication devices

110, 120 may include two or more RATs to two or more mobile networks and may connect to those RATs in a manner similar to those described herein.

In some examples, the first mobile communication device 110 may optionally establish a wireless connection 152 with a peripheral device 150 used in connection with the first mobile communication device 110. For example, the first mobile communication device 110 may communicate over a

link with a Bluetooth-enabled personal computing device (e.g., a “smart watch” ) . In some examples, the first mobile communication device 110 may optionally establish a wireless connection 162 with a wireless access point 160, such as over a Wi-Fi connection. The wireless access point 160 may be configured to connect to the Internet 164 or another network over a wired connection 166.

While not illustrated, the second mobile communication device 120 may similarly be configured to connect with the peripheral device 150 and/or the wireless access point 160 over wireless links.

FIG. 2 is a functional block diagram of a multi-SIM mobile communication device 200 suitable for implementing various examples. With reference to FIGS. 1–2, the multi-SIM mobile communication device 200 may be similar to one or more of the

mobile communication devices

110, 120 as described. The multi-SIM mobile communication device 200 may include a first SIM interface 202a, which may receive a first identity module SIM-1 204a that is associated with a first subscription. The multi-SIM mobile communication device 200 may also optionally include a second SIM interface 202b, which may receive an optional second identity module SIM-2 204b that is associated with a second subscription.

A SIM in various examples may be a Universal Integrated Circuit Card (UICC) that is configured with SIM and/or Universal SIM applications, enabling access to, for example, GSM and/or UMTS networks. The UICC may also provide storage for a phone book and other applications. Alternatively, in a CDMA network, a SIM may be a UICC removable user identity module (R-UIM) or a CDMA subscriber identity module (CSIM) on a card. A SIM card may have a central processing unit (CPU) , read only memory (ROM) , random access memory (RAM) , electrically erasable programmable read only memory (EEPROM) and input/out (I/O) circuits.

A SIM used in various examples may contain user account information, an international mobile subscriber identity (IMSI) , a set of SIM application toolkit (SAT) commands, and storage space for phone book contacts. A SIM card may further store home identifiers (e.g., a System Identification Number (SID) /Network Identification Number (NID) pair, a Home Public Land Mobile Number (HPLMN) code, etc. ) to indicate the SIM card network operator provider. An Integrated Circuit Card Identity (ICCID) SIM serial number may be printed on the SIM card for identification. However, a SIM may be implemented within a portion of memory of the multi-SIM mobile communication device 200 (e.g., in a memory 214) , and thus need not be a separate or removable circuit, chip or card.

The multi-SIM mobile communication device 200 may include at least one controller, such as a general processor 206, which may be coupled to a coder/decoder (CODEC) 208. The CODEC 208 may in turn be coupled to a speaker 210 and a microphone 212. The general processor 206 may also be coupled to the memory 214. The memory 214 may be a non-transitory computer-readable storage medium that stores processor-executable instructions. For example, the instructions may include routing communication data relating to the first or second subscription though a corresponding baseband-RF resource chain. The memory 214 may store a high level operating system, as well as user application software and executable instructions.

The general processor 206 and the memory 214 may each be coupled to at least one baseband modem processor 216. Each SIM and/or RAT in the multi-SIM mobile communication device 200 (e.g., the SIM-1 204a and/or the SIM-2 204b) may be associated with a baseband-RF resource chain. A baseband-RF resource chain may include the baseband modem processor 216, which may perform baseband/modem functions for communications with/controlling a RAT, and may include one or more amplifiers and radios, referred to generally herein as RF resources (e.g., RF resource 218) . In some examples, baseband-RF resource chains may share the baseband modem processor 216 (i.e., a single device that performs baseband/modem functions for all RATs on the multi-SIM mobile communication device 200) . In other examples, each baseband-RF resource chain may include physically or logically separate baseband processors (e.g., BB1, BB2) .

The RF resource 218 may be a transceiver that performs transmit/receive functions for each of the SIMs/RATs on the multi-SIM mobile communication device 200. The RF resource 218 may include separate transmit and receive circuitry, or may include a transceiver that combines transmitter and receiver functions. In some examples, the RF resource 218 may include multiple receive circuitries. The RF resource 218 may be coupled to a wireless antenna (e.g., a wireless antenna 220) . The RF resource 218 may also be coupled to the baseband modem processor 216.

In some examples, the general processor 206, the memory 214, the baseband processor (s) 216, and the RF resource 218 may be included in the multi-SIM mobile communication device 200 as a system-on-chip 250. In some examples, the first and

second SIMs

204a, 204b and the corresponding

interfaces

202a, 202b may be external to the system-on-chip 250.

Various input and output devices may be coupled to components on the system-on-chip 250, such as interfaces or controllers. Example user input components suitable for use in the multi-SIM mobile communication device 200 may include, but are not limited to, a keypad 224, a touchscreen display 226, and the microphone 212. In some examples, the keypad 224, the touchscreen display 226, the microphone 212, or a combination thereof, may perform the function of receiving a request to initiate an outgoing call. For example, the touchscreen display 226 may receive a selection of a contact from a contact list or receive a telephone number. In another example, either or both of the touchscreen display 226 and the microphone 212 may perform the function of receiving a request to initiate an outgoing call. For example, the touchscreen display 226 may receive selection of a contact from a contact list or receive a telephone number. As another example, the request to initiate the outgoing call may be in the form of a voice command received via the microphone 212. Interfaces may be provided between the various software modules and functions in the multi-SIM mobile communication device 200 to enable communication between them, as is known in the art.

Functioning together, the two

SIMs

204a, 204b, the baseband processor BB1, BB2, the RF resource 218, and the wireless antenna 220 may constitute two or more radio access technologies (RATs) . For example, the multi-SIM mobile communication device 200 may be a LTE communication device that includes a SIM, baseband processor, and RF resource configured to support two different RATs, such as LTE, WCDMA, and GSM. More RATs may be supported on the multi-SIM mobile communication device 200 by adding more SIM cards, SIM interfaces, RF resources, and antennae for connecting to additional mobile networks.

In some examples (not shown) , the multi-SIM mobile communication device 200 may include, among other things, additional SIM cards, SIM interfaces, a plurality of RF resources associated with the additional SIM cards, and additional antennae for supporting subscriptions communications with additional mobile networks.

FIG. 3 illustrates conventional TCP communications between a multi-SIM multi-standby mobile communication device and a network in the presence of tune-aways. The call flow diagram 300 includes a mobile communication device 302 having a first RAT 304 and a second RAT 306. The first RAT 304 and the second RAT 306 may be associated with the same subscription or different subscriptions on the mobile communication device. For example, the mobile communication device 302 may be a MSMS mobile communication device, such as a DSDS mobile communication device, and the first RAT 304 may be associated with a first subscription and the second RAT 306 may be associated with a second subscription. The first RAT 304 and the second RAT 306 may utilize a shared RF resource on the mobile communication device 302. The first RAT 304 communicates with a first network 308, while the second RAT 306 communicates with a second network 310. If the first RAT 304 and the second RAT 306 share the same subscription, the first network 308 may be the same as the second network 310 or under the control of the same network operator.

The first RAT 304 may be in TCP communication with the first network 308. The first RAT 304 may transmit a TCP packet n 312 to the first network 308 during uplink TCP communications with the first network 308. In response, the first network 308 may transmit a HARQ ACK 314 to the first RAT 304 acknowledging receipt of the TCP packet n 312 as part of the HARQ transmission process on the medium access control (MAC) layer. The HARQ ACK 314 may arrive quickly but may not be reliable (e.g., higher rates of false positives or false negatives) . The first network 308 may also transmit a RLC ACK 316 to the first RAT 304 acknowledging receipt of the TCP packet n 312 as part of the transmission process on the RLC layer. The RLC ACK 316 may be used to fix the residual errors of the lower layers, such as errors in the HARQ transmission process. The HARQ ACK 314 and the RLC ACK 316 may be transmitted after receiving the TCP packet n 312 but before a tune-away 318.

After receiving the HARQ ACK 314 and the RLC ACK 316, the mobile communication device 302 may perform the tune-away 318 of the shared RF resource to the second RAT 306 so that the second RAT 306 may perform idle mode operations. During the tune-away 318 the first RAT 304 is unable to receive messages from the first network 308, including any TCP ACKs. In addition, the TCP layer of the mobile communication device 302 may not be aware of the tune-away 318, and so may continue to keep sending data to the modem layers for transmission until the transmission window (twnd) is exhausted (i.e., equals zero) .

The mobile communication device 302 may perform a tune-back 320 to the first RAT 304 when the tune-away 318 is complete. The first RAT 304 may not have received any TCP ACKs during the tune-away 318. The duration of the tune-away 318 may be longer than a RTO threshold time. When the RTO threshold time is exceeded, the modem may trigger a RTO on the first RAT 304 in operation 324. This reduces the size of the congestion window (cwnd) value to one. The first RAT 304 may also have to follow a slow start transmission process in operation 326. The slow start transmission process may gradually increase the congestion window value as TCP ACKs are received again, but during this time the data throughput of the first RAT 304 is reduced. Thus, the tune-away 318 may negatively impact the data throughput of TCP communications of the first RAT 304.

In addition, because the first RAT 304 did not receive any TCP ACKs before the RTO, the first RAT 304 may send a retransmission 328 of the TCP packet n 312 after the tune-away 318 is complete. At some later time, the first network 308 may transmit a TCP ACK 330 for packet n. The TCP ACK 330 arrives in a longer time frame than the HARQ ACK 314 and the RLC ACK 316. However, the first RAT 304 may be unable to determine whether the TCP ACK 330 corresponds to the original transmission of the TCP packet n 312 or the retransmission 328.

Some solutions resolve this uncertainty by including a timestamp in the TCP header of a transmitted TCP packet. The network may include the same timestamp in the TCP ACK corresponding to the TCP packet. By comparing the timestamps, the mobile communication device may determine whether the TCP ACK corresponds to the original transmission or the retransmission of the TCP packet. If the TCP ACK corresponds to the original transmission, the mobile communication device may restore the congestion window value to the value that existed before the RTO was triggered and stop retransmission. However, adding a timestamp to each TCP packet may increase the data overhead by up to 12 bytes. In order to same power and data capacity, the HLOS of the mobile communication device may often disable the timestamp feature in TCP communications.

Various examples described herein dynamically enable the timestamps to be used in TCP communications at certain times, for example in the presence of tune-aways. FIG. 4A illustrates call flows and message exchanges for dynamically utilizing timestamps in TCP communications on a mobile communication device in the presence of tune-aways according to various examples. The call flow diagram 400a illustrates communications of a mobile communication device 402 having a first RAT 404 and a second RAT 406. The first RAT 404 and the second RAT 406 may be associated with the same subscription or different subscriptions on the mobile communication device. For example, the mobile communication device 402 may be a MSMS mobile communication device, such as a DSDS mobile communication device, and the first RAT 404 may be associated with a first subscription and the second RAT 406 may be associated with a second subscription. The first RAT 404 and the second RAT 406 may utilize a shared RF resource on the mobile communication device 402. The first RAT 404 communicates with a first network 408, while the second RAT 406 communicates with a second network 410. If the first RAT 404 and the second RAT 406 share the same subscription, the first network 408 may be the same as the second network 410 or under the control of the same network operator.

The first RAT 404 and the first network 408 may be engaged in uplink TCP communications. The mobile communication device 402 may identify an upcoming tune-away 420 from the first RAT 404 to the second RAT 406 and add a timestamp to a TCP packet n 414 in operation 412. The TCP packet n 414 may be the last packet in queue for transmission before the tune-away 420 begins. Tune-aways may be periodically scheduled, so the modem may identify if there is an upcoming tune-away during TCP packet transmission. The timestamp added to the TCP packet n 414 may be the current time when the timestamp is added. In some examples, the timestamp may also include an offset that is based on the estimated duration of the tune-away 420. In some examples, the modem of the mobile communication device 402 may add the timestamp to the TCP packet n 414 through deep packet inspection. The header of the TCP packet n 414 may include a timestamp value field that contains a current time and an offset. In other examples, the modem may identify the upcoming tune-away 420 and the tune-away information is sent to a HLOS executing on the mobile communication device 402. The HLOS may dynamically enable the addition of the timestamp to the TCP packet n 414 before the tune-away 420 is about to start, and disable the timestamp addition after the tune-away 420 is complete. The HLOS may also add an offset to the timestamp based on the estimated duration of the tune-away 420.

Once the timestamp has been added to the TCP packet n 414, the TCP packet n 414 may be transmitted to the first network 408. The first network 408 may transmit a HARQ ACK 416 and/or a RLC ACK 418 before the tune-away 420 begins indicating receipt of the TCP packet n 414 on the lower modem layers. The mobile communication device 402 may then initiate the tune-away 420 and tune the shared RF resource to the second RAT 406 to perform idle mode operations. During the tune-away 420 the first RAT 404 may not be able to receive messages from the first network 408. The mobile communication device 402 may then perform a tune-back 422 to the first RAT 404.

During or after the end of the tune-away 420, the first RAT 404 may trigger a RTO if the duration of the tune-away 420 exceeds a RTO threshold time in operation 424. As part of the RTO, the congestion window value may be set to one. In response to the RTO, the first RAT 404 may retransmit TCP packet n 414 as retransmission 426. The first network 408 may then transmit a TCP ACK 428 that includes a timestamp. The first network 408 may be configured to detect when a timestamp is included in a received TCP packet and include the same timestamp in the corresponding TCP ACK. The modem of the mobile communication device 402 may compare the timestamps of the TCP packet n 414 and the TCP ACK 428 in operation 430. If the timestamps match, then the TCP ACK 428 corresponds to the TCP packet n 414. In this case, the modem may then restore the congestion window value of the first RAT 404 to the value that existed prior to the RTO. For example, if congestion window value was five before the RTO, then the modem may restore the value from one to five. This allows the data throughput of the first RAT 404 to return to the same level as before the tune-away 420. If the timestamps do not match, the first RAT 404 may keep the current congestion window value of one and initiate a slow start procedure to gradually increase the congestion window value. Thus by identifying upcoming tune-aways, the mobile communication device 402 may dynamically enable timestamping of TCP packets that are sent before the tune-aways begin. After the tune-aways end, the TCP packets may be transmitted without timestamps.

Dynamic addition of timestamps may also be done by the network base station on downlink TCP communications. This is illustrated in the call flow diagram 400b shown in FIG. 4B. If the network base station knows the tune-away cycle and duration (e.g., from mobile communication device signaling) , the network can dynamically enable or disable a TCP timestamp. For example, a base station (e.g., eNodeB) of a first network 408 may receive a tune-away schedule of the mobile communication device 402 in operation 432. The mobile communication device 402 may be configured to transmit tune-away scheduling information to the first network 408. The first network 408 may then dynamically add a timestamp to a TCP packet m 436 that is scheduled to be transmitted just before a tune-away 442 on the mobile communication device 402 begins in operation 434. The timestamp may be the current time when the timestamp is added. In some examples, the timestamp may also include an offset that is based on the estimated duration of the tune-away 442.

The first network 408 may then transmit the TCP packet m 436 to the first RAT 404. The first RAT 404 may respond by transmitting a HARQ ACK 438 and a RLC ACK 440 indicating receipt of the TCP packet m 436 before the tune-away 442 begins. The mobile communication device 402 may then initiate the tune-away 442 and tune the shared RF resource to the second RAT 406 to perform idle mode operations. During the tune-away 442 the first RAT 404 may not be able to receive messages from the first network 408. The mobile communication device 402 may then perform a tune-back 444 to the first RAT 404.

After the end of the tune-away 442, the first network 408 may trigger a RTO if the duration of the tune-away 442 exceeds a RTO threshold time in operation 446. As part of the RTO, the congestion window value may be set to one. The first network 408 may retransmit the TCP packet m 436 as retransmission 448 in response to the RTO. The first RAT 404 may then transmit a TCP ACK 450 that includes a timestamp. The mobile communication device 402 may be configured to detect when a timestamp is included in a received TCP packet and include the same timestamp in the corresponding TCP ACK. The first network 408 may compare the timestamps of the TCP packet m 436 and the TCP ACK 450 in operation 452. If the timestamps match, then the TCP ACK 450 corresponds to the TCP packet m 436. In this case, the first network 408 may restore the congestion window value of TCP communications with the first RAT 404 to the value that existed prior to the RTO in operation 452. For example, if the congestion window value was five before the RTO, then the first network 408 may restore the value from one to five. This allows the data throughput between the first network 408 and the first RAT 404 to return to the same level as before the tune-away 442. If the timestamps do not match, the first network 408 may keep the current congestion window value of one and initiate a slow start procedure to gradually increase the congestion window value. Thus by identifying upcoming tune-aways, the first network 408 may dynamically enable timestamping of TCP packets that are sent before the tune-aways begin. After the tune-aways end, the TCP packets may be transmitted without timestamps.

In other examples described herein, rather than utilizing timestamps a mobile communication device may utilize the HARQ and/or RLC ACKs to locally trigger a TCP ACK in order to avoid data throughput reduction in the presence of tune-aways. This is illustrated in FIG. 5, which shows a diagram 500 of communication layers in a mobile communication device. The mobile communication device may have a modem that controls a shared RF resource utilized by a plurality of RATs on the mobile communication device. The communication layers in the modem may include a physical layer 502, which includes the network hardware technology of the modem and shared RF resource. The modem may also include a MAC layer 504 that maps logical communication channels to transport communication channels. The modem may also include a RLC layer 506 that is responsible various functions such as transfer of upper layer protocol data units (PDUs) and error correction. The modem may also include a packet data convergence protocol (PDCP) layer 508 that provides services to upper layers, such as a TCP/IP layer 512 that is part of a HLOS or application executing on the mobile communication device. The services may include transfer of user plane or control plane data, header compression, ciphering, and integrity protection.

In various examples described herein, the PDCP layer 508 may also include a TCP adaption sub-layer 510. The TCP adaption sub-layer 510 may be configured to generate local TCP ACKs from lower level ACKs, such as HARQ ACKs or RLC ACKs. These local TCP ACKs may be delivered to the TCP/IP layer 512 during a tune-away on the mobile communication device rather than waiting for the receipt of a remote TCP ACK from the network, which arrives after the tune-away. Also, TCP ACKs may be delayed or lost due to the tune-away. This prevents the triggering of a RTO and reduction of data throughput of the RAT engaged in TCP communications.

For example, a first RAT on the mobile communication device may receive an uplink grant from its associated network. When the uplink grant is received, the MAC layer 504 may request transmission data from the PDCP layer 508 via the RLC layer 506. Uplink PDUs that are created by the TCP/IP layer 512 may be delivered to the lower modem layers through the TCP adaption sub-layer 510 and assigned a PDCP sequence number (SN) . TCP packets may be generated from the uplink PDUs, which are passed through the lower modem layers and transmitted out to the network. The TCP adaption sub-layer 510 may also store a copy of the transmitted TCP packet.

After the mobile communication device transmits the TCP packet to a network, the physical layer 502 may receive a HARQ and/or a RLC ACK 514 from the network acknowledging receipt of the TCP packet. The HARQ/RLC ACK 514 may be passed to the MAC layer 504 or the RLC layer 506. The MAC layer 504 or the RLC layer 506 may be configured to notify the TCP adaption sub-layer 510 of the HARQ/RLC ACK 514. In response, the TCP adaption sub-layer 510 may generate a local TCP ACK 516 from the HARQ/RLC ACK 514. If there is no upcoming tune-away, the receive window value of the local TCP ACK 516 may be set to equal the receive window value in the last received remote TCP ACK from the network. If there is an upcoming tune-away, the receive window value of the local TCP ACK 516 may be set to equal zero in order to suspend the transmission of TCP packets during the tune-away. The TCP adaption sub-layer 510 may deliver the local TCP ACK 516 to the TCP/IP layer 512 in the HLOS or application. Thus the TCP/IP layer 512 may determine that the TCP packet was successfully received and no RTO is triggered if a tune-away is initiated after the first RAT receives the HARQ/RLC ACK 514. If there are buffered TCP packets for transmission in the PDCP layer 508, the TCP adaption sub-layer 510 may also generate one or more TCP ACKs for the buffered TCP packets with a receive window value of zero to prevent triggering a RTO.

At a later time after the tune-away is complete, the network may transmit a remote TCP ACK to the first RAT. The TCP adaption sub-layer 510 may be notified of the receipt of the remote TCP ACK. However, because the local TCP ACK 516 has already been delivered to the TCP/IP layer 512, the TCP adaption sub-layer 510 may ignore the remote TCP ACK. The TCP adaption sub-layer 510 may also delete the locally stored copy of the transmitted TCP packet upon receipt of the remote TCP ACK. If a remote TCP ACK is not received, the TCP packet may have been lost in either the air interface or the wireline link. If the packet loss occurs in the air interface, the RLC retransmission mechanism may initiate. If the packet loss occurs in the wireline link, the TCP adaption sub-layer 510 may detect packet loss when duplicate remote TCP ACKs are received or if a RTO is triggered, and then initiate retransmission of the TCP packet.

A network base station may also generate local TCP ACKs during downlink TCP communications as well. For example, a network base station may have a TCP handling sub-layer in the PDCP layer similar to the TCP adaption sub-layer 510 of the mobile communication device. For example, the network base station may receive a HARQ ACK or RLC ACK from the first RAT of the mobile communication device in response to a TCP packet transmission. The TCP packet may be stored in the TCP adaption sublayer of the network base station. The TCP adaption sub-layer may generate a local TCP ACK from the HARQ ACK or RLC ACK and deliver the local TCP ACK to the TCP/IP layer of the network base station. The network base station may then wait for the receipt of a subsequent remote ACK, such as a remote TCP ACK if the local TCP ACK was generated from a RLC ACK, or in the alternative a remote RLC ACK if the local TCP ACK was generated from a HARQ ACK. Because there is no further wireline transmission and the air interface is the last part of the TCP transmission, the RLC ACK may be indicative of whether the transmission was successful on the TCP layer as well. Further, the cyclic redundancy check (CRC) bits for the RLC/HARQ ACK are longer than for the TCP ACK, so there is less error. Thus in the case when the RLC ACK is received, the locally acknowledged (ACKed) TCP packets stored in the TCP adaption sub-layer may be deleted.

If the network base station later receives a subsequent remote ACK (e.g., TCP or RLC ACK) from the mobile communication device, the TCP adaption sub-layer may determine whether there is any additional information in the subsequent remote ACK aside from the acknowledgement itself. If there is additional information, this information may be delivered to the TCP/IP layer of the network base station. Otherwise, the subsequent remote ACK may be ignored. In some examples, the mobile communication device may be configured by the network base station not to transmit any TCP ACKs, but rather HARQ and RLC ACKs. Thus, both the mobile communication device and the network base station may be configured to generate local TCP ACKs in order to avoid data throughput reduction in the presence of tune-aways.

In other examples described herein, rather than utilizing timestamps or locally generated TCP ACKs, a mobile communication device may utilize TCP ACK buffers to lessen data throughput reduction in the presence of tune-aways. This is illustrated in FIG. 6, which shows the call flow diagram 600 including a mobile communication device 602 having a first RAT 604 and a second RAT 606. The first RAT 604 and the second RAT 606 may be associated with the same subscription or different subscriptions on the mobile communication device. For example, the mobile communication device 602 may be a MSMS mobile communication device, such as a DSDS mobile communication device, and the first RAT 604 may be associated with a first subscription and the second RAT 606 may be associated with a second subscription. The first RAT 604 and the second RAT 606 may utilize a shared RF resource on the mobile communication device 602. The first RAT 604 communicates with a first network 608, while the second RAT 606 communicates with a second network 610. If the first RAT 604 and the second RAT 606 share the same subscription, the first network 608 may be the same as the second network 610, or both networks may be under the control of the same network operator.

The first RAT 604 may be in TCP communication with the first network 608. The first network 608 may transmit a TCP ACK 612 to the first RAT 604. The TCP ACK 612 may be in response to a packet n-1 that the first RAT 604 previously transmitted to the first network 608. The first RAT 604 may then transmit a TCP packet n 614 to the first network 608. The modem on the mobile communication device 602 may determine whether there is an upcoming tune-away in operation 616.

If there is an upcoming tune-away, the modem may buffer the previously received TCP ACK 612 for packet n-1 in operation 618. The mobile communication device 602 may then perform a tune-away 620 from the first RAT 604 to the second RAT 606 so that the second RAT 606 may perform idle mode operations. During the tune-away 620, the modem may deliver the buffered TCP ACK to the TCP/IP layer of the mobile communication device 602 (e.g., to a HLOS or application executing on the mobile communication device 602) at regular time intervals T in operation 622. The time interval may be selected to be shorter than the RTO threshold time in order to avoid triggering a RTO during the tune-away 620.

Because the buffered TCP ACK is a duplicate of a previously received TCP ACK, the HLOS/application may reduce the congestion window value of the first RAT 604. However, the congestion window value is usually reduced by half when receiving duplicate TCP ACKs rather than down to one if a RTO is triggered. Thus by buffering and delivering duplicated TCP ACKs during the tune-away 620, the data throughput of the first RAT 604 may be higher than if no buffered TCP ACKs were delivered and a RTO is triggered. After the tune-away 620 ends and the mobile communication device 602 performs a tune-back 624 to the first RAT 604, the first RAT 604 may resume normal transmission procedures. For example, the first network 608 may transmit a TCP ACK 626 corresponding to the packet n. The first RAT 604 may receive the TCP ACK 626 and deliver it to the HLOS/application. In this manner, buffered TCP ACKs may be used to reduce the impact of tune-aways on the data throughput of the first RAT 604.

FIG. 7 illustrates a method 700 for utilizing timestamps in TCP communications in a mobile communication device according to various examples. The method 700 may be implemented with a processor (e.g., the general processor 206, the baseband modem processor 216, a separate controller, and/or the like) of a mobile communication device (such as the

mobile communication devices

110, 120, 402) that supports a first RAT and a second RAT that share an RF resource. The first RAT and the second RAT may share the same subscription, or may be associated with different subscriptions. The first RAT may be engaged in TCP communications with an associated first network.

In determination block 702, the processor may determine whether there is an upcoming tune-away from the first RAT, which is engaged in an active communication, to the second RAT. For example, the modem may schedule periodic tune-aways to the second RAT and the periodicity of the tune-aways may be used to determine whether a tune-away is about to occur.

In response to determining that there is no upcoming tune-away from the first RAT to the second RAT (i.e., determination block 702 ＝ “No” ) , the processor may transmit a TCP packet to the first network in block 724. In other words, when there is no upcoming tune-away the processor may follow normal procedures for TCP communications and continue generating and transmitting TCP packets without timestamps.

In response to determining that there is an upcoming tune-away from the first RAT to the second RAT (i.e., determination block 702 ＝ “Yes” ) , the processor may add a timestamp to a TCP packet for transmission before the tune-away begins in block 704. The timestamp may be the current time when the timestamp is added to the TCP packet. For example, the modem of the mobile communication device may perform deep packet inspection to add the timestamp to the header of the TCP packet. Alternatively, a HLOS executing on the mobile communication device may be notified by the modem of the upcoming tune-away and the HLOS may enable the addition of timestamps to the TCP packets.

In optional block 706, the processor may add an offset to the timestamp. The value of the offset may be based on the estimated duration of the upcoming tune-away. For example, the modem and/or the HLOS may determine or estimate the duration of the tune-away and set the offset equal to the duration of the tune-away. The modem and/or HLOS may then add the offset to the timestamp.

In block 708, the processor may transmit the TCP packet with the timestamp from the first RAT to the first network.

In block 710, the processor may perform a tune-away from the first RAT to the second RAT so that the second RAT may perform idle mode operations.

In block 712, during or after the tune-away an RTO may be triggered on the first RAT because the first RAT does not receive any TCP ACKs during the tune-away. When an RTO is triggered, the congestion window value of the first RAT may be set to one. After the tune-away is complete, the first RAT may retransmit the TCP packet as part of a retransmission process following the RTO.

In block 714, the first RAT may receive a TCP ACK from the first network, and in block 716, the processor may compare the timestamps of the transmitted TCP packet and the received TCP ACK.

In determination block 718, the processor may determine whether the TCP ACK corresponds to the transmitted TCP packet. For example, if the timestamp of the TCP ACK matches the timestamp of the transmitted TCP packet, then the TCP ACK corresponds to the TCP packet. When the first network receives the TCP packet and generates a TCP ACK in response, the first network may be configured to include the timestamp of the TCP packet in the header of the TCP ACK.

In response to determining that the TCP ACK corresponds to the TCP packet (i.e., determination block 718 ＝ “Yes” ) , the processor may restore a prior congestion window value of the first RAT in block 720. In other words, if the processor determines that the first network successfully received the TCP packet, the effect of the RTO may be reversed by restoring the prior congestion window value rather than leaving it at one. This may prevent a reduction of data throughput on the first RAT even in the presence of a tune-away.

In response to determining that the TCP ACK does not correspond to the TCP packet (i.e., determination block 718 ＝ “No” ) , the processor may keep the current congestion window value of the first RAT in block 722. For example, if the congestion window value was one after the RTO, the congestion value may remain at one. The processor may also initiate a slow start procedure to gradually increase the congestion window value. The method 700 may be repeated for every TCP packet transmission on the first RAT. In this manner, the method 700 provides a way to dynamically add timestamps to uplink TCP transmissions that are interrupted.

FIG. 8 illustrates a method 800 for utilizing timestamps in TCP communications in a network base station according to various examples. The method 800 may be implemented with a processor (e.g., a general processor, a baseband modem processor, a separate controller, and/or the like) of a network base station (such as a base station of the first network 408) . The network base station may be engaged in TCP communication with a first RAT on a mobile communication device that supports a first RAT and a second RAT sharing an RF resource (e.g., a MSMS mobile communication device) .

In block 802, the network base station may receive a tune-away schedule from the mobile communication device. The tune-away schedule may specify the times, durations and/or periodicity of scheduled tune-aways from the first RAT to the second RAT in the mobile communication device.

In determination block 804, the processor may determine whether there is an upcoming tune-away on the mobile communication device. In response to determining that there is no upcoming tune-away on the mobile communication device (i.e., determination block 804 ＝ “No” ) , the processor may transmit a TCP packet to the mobile communication device in block 824. In other words, when there is no upcoming tune-away the network base station may follow normal procedures for TCP communications and continue generating and transmitting TCP packets without timestamps.

In response to determining that there is an upcoming tune-away on the mobile communication device (i.e., determination block 804 ＝ “Yes” ) , the processor may add a timestamp to a TCP packet for transmission before the tune-away begins in block 806. The timestamp may be the current time when the timestamp is added to the TCP packet. The timestamp may be added to the header of the TCP packet.

In optional block 808, the processor may add an offset to the timestamp. The value of the offset may be based on the estimated duration of the upcoming tune-away, which may be determined from the received tune-away schedule.

In block 810, the processor may transmit the TCP packet with the timestamp from the network base station to the mobile communication device.

In block 812, the network base station may trigger a RTO for the TCP communication between the network base station and the mobile communication device. For example, after the TCP packet is transmitted, the mobile communication device may perform a tune-away from the first RAT to the second RAT so that the second RAT may perform idle mode operations. During the tune-away, a RTO may be triggered on the network base station because it has not received any TCP ACKs during the duration of the tune-away. When a RTO is triggered, the congestion window value of the TCP communication with the mobile communication device may be set to one. The network base station may retransmit the TCP packet as part of a retransmission process following the RTO.

In block 814, the network base station may receive a TCP ACK from the mobile communication device.

In block 816, the processor may compare the timestamps of the transmitted TCP packet and the received TCP ACK. In determination block 818, the processor may determine whether the TCP ACK corresponds to the transmitted TCP packet. For example, if the timestamp of the TCP ACK matches the timestamp of the transmitted TCP packet, then the TCP ACK corresponds to the TCP packet. When the mobile communication device receives the TCP packet and generates a TCP ACK in response, the mobile communication device may be configured to include the timestamp of the TCP packet in the header of the TCP ACK.

In response to determining that the TCP ACK corresponds to the TCP packet (i.e., determination block 818 ＝ “Yes” ) , the processor may restore a prior congestion window value of the TCP communication with the mobile communication device in block 820. In other words, if the processor determines that the mobile communication device successfully received the TCP packet, the effect of the RTO may be reversed by restoring the prior congestion window value rather than leaving it at one. This may prevent a reduction of data throughput on downlink communications with the mobile communication device even in the presence of a tune-away.

In response to determining that the TCP ACK does not correspond to the TCP packet (i.e., determination block 818 ＝ “No” ) , the processor may keep the current congestion value in block 822. For example, if the congestion window value was one after the RTO, the congestion value may remain one. The processor may also initiate a slow start procedure to gradually increase the congestion window value. The method 800 may be repeated for every TCP packet transmission on the network base station. In this manner, the method 800 provides a way to dynamically add timestamps to downlink TCP transmissions that are interrupted.

FIG. 9 illustrates a method 900 for generating local acknowledgements for TCP communications in a mobile communication device according to various examples. The method 900 may be implemented with a processor (e.g., the general processor 206, the baseband modem processor 216, a separate controller, and/or the like) of a mobile communication device (such as the

mobile communication devices

In block 902, the processor of the mobile communication device may transmit a TCP packet from the first RAT to the first network. In block 904, the first RAT may receive a HARQ or RLC ACK corresponding to the TCP packet from the first network. In block 906, the processor of the mobile communication device may generate a local TCP ACK from the HARQ/RLC ACK. For example, a PDCP layer of the modem in the mobile communication device may include a TCP adaption sub-layer as described with reference to FIG. 5. The MAC layer or RLC layer of the modem may notify the TCP adaption sub-layer of the received HARQ/RLC ACK. The TCP adaption sub-layer may generate a local TCP ACK from the HARQ/RLC ACK. The TCP adaption sub-layer may also store a copy of the transmitted TCP packet.

In determination block 908, the processor may determine whether there is an upcoming tune-away from the first RAT to the second RAT. For example, the modem may schedule periodic tune-aways to the second RAT and the periodicity of the tune-aways may be used to determine whether a tune-away is about to occur.

In response to determining that there is no upcoming tune-away (i.e., determination block 908 ＝ “No” ) , the processor may set a receive window value of the local TCP ACK to a prior receive window value from the last received TCP ACK in block 912. In order words, when there is no tune-away the same data throughput may be maintained on the first RAT.

In block 914, the processor may deliver the local TCP ACK to a HLOS or application executing on the mobile communication device (i.e., deliver to the upper TCP/IP layer) .

In response to determining that there is an upcoming tune-away (i.e., determination block 908 ＝ “Yes” ) , the processor may set a receive window value of the local TCP ACK to zero in block 910. This may prevent the first RAT from transmitting TCP packets during the tune-away.

In block 914, the processor may deliver the local TCP ACK to the HLOS or application executing on the mobile communication device.

In block 916, the processor may perform a tune-away from the first RAT to the second RAT so that the second RAT may perform idle mode operations.

In block 918, the processor may generate one or more local TCP ACKs for buffered TCP packets in the PDCP layer of the modem during the tune-away. These local TCP ACKs may also have a receive window value of zero to prevent the triggering of a RTO during the tune-away.

After the tune-away is complete, or after delivering the local TCP ACK to the HLOS or application in the case when there is no tune-away, the processor may determine whether the first RAT has received a remote TCP ACK from the first network in determination block 920. For example, after receiving the TCP packet transmitted in block 902, the first network may generate and transmit a TCP ACK indicating successful reception of the TCP packet.

In response to determining that the first RAT has received a remote TCP ACK from the first network (i.e., determination block 920 ＝ “Yes” ) , the processor may determine whether the remote TCP ACK contains additional information not found in the local TCP ACK in determination block 922.

In response to determining that the remote TCP ACK contains additional information not found in the local TCP ACK (i.e., determination block 922 ＝ “Yes” ) , the processor may deliver the additional information the HLOS/App in block 924.

In response to determining that the remote TCP ACK does not contain additional information not found in the local TCP ACK (i.e., determination block 922 ＝ “No” ) , the processor may ignore the remote TCP ACK in block 926. In other words, if it is confirmed that the first network successfully received the TCP packet and the TCP packet does not contain any additional information, the remote TCP ACK is redundant to the local TCP ACK that was already delivered to the HLOS or application in block 914.

In response to determining that the first RAT has not received a remote TCP ACK from the first network (i.e., determination block 920 ＝ “No” ) , the processor may determine that a loss of the TCP packet has occurred in block 928. For example, the first RAT may receive duplicate remote TCP ACKs that may be indicative of a lost packet, or the processor may check whether a RTO has been triggered.

In block 930, the processor may initiate retransmission of the TCP packet. The method 900 may be repeated for each TCP packet transmission. In this manner, the method 900 provides a way for a mobile communication device to generate local TCP ACKs from lower layer ACKs to prevent data throughput loss during a tune-away.

FIG. 10 illustrates a method 1000 for generating local acknowledgements for TCP communications in a network base station according to various examples. The method 1000 may be implemented with a processor (e.g., a general processor, a baseband modem processor, a separate controller, and/or the like) of a network base station (such as a base station of the first network 408) . The network base station may be engaged in TCP communication with a first RAT on a mobile communication device that supports a first RAT and a second RAT sharing an RF resource (e.g., a MSMS mobile communication device) .

In block 1002, the processor of the network base station may transmit a TCP packet from the network base station to the first RAT of the mobile communication device. In block 1004, the network base station may receive a HARQ ACK or a RLC ACK corresponding to the TCP packet from the mobile communication device.

In block 1006, the processor of the network base station may generate a local TCP ACK from the HARQ/RLC ACK. For example, a PDCP layer of the network base station may include a TCP adaption sub-layer as described with reference to FIG. 5. The MAC layer may notify the TCP adaption sub-layer of the received HARQ/RLC ACK. The TCP adaption sub-layer may generate a local TCP ACK from the HARQ/RLC ACK. The TCP adaption sub-layer may also store a copy of the transmitted TCP packet. The processor may set a receive window value of the local TCP ACK to a prior receive window value from the last received TCP ACK. This allows the network base station to maintain the same data throughput in the TCP communication with the mobile communication device. In block 1008, the processor may deliver the local TCP ACK to a HLOS or application executing on network base station (i.e., deliver to the upper TCP/IP layer) .

In block 1010, the processor may instruct the mobile communication device to not send a TCP ACK corresponding to the transmitted TCP packet. The instruction may be done through various mobile network signaling mechanisms, such as radio resource control (RRC) signaling or TCP/IP signaling. This may be done so that the mobile communication device transmits the RLC ACK but does not also have to transmit the TCP ACK because the RLC ACK arrives earlier.

In determination block 1012, the processor may determine whether the network base station has received a subsequent remote ACK from the mobile communication device. For example, after receiving the TCP packet transmitted in block 1002, the mobile communication device may first generate and transmit a RLC ACK indicating successful reception of the TCP packet, and then later transmit a TCP ACK for the same TCP packet. If the local TCP ACK was generated from a received HARQ ACK, the subsequent remote ACK may be a RLC ACK. If the local TCP ACK was generated from a received RLC ACK, the subsequent remote ACK may be a TCP ACK

In response to determining that the network base station has received a subsequent remote ACK from the mobile communication device (i.e., determination block 1012 ＝ “Yes” ) , the processor may determine whether the subsequent remote ACK contains additional information not found in the local TCP ACK in determination block 1018.

In response to determining that the subsequent remote ACK contains additional information not found in the local TCP ACK (i.e., determination block 1018 ＝ “Yes” ) , the processor may deliver the additional information to the HLOS or application in block 1020.

In response to determining that the subsequent remote ACK does not contain additional information not found in the local TCP ACK (i.e., determination block 1018 ＝ “No” ) , the processor may ignore the subsequent remote ACK in block 1022. In other words, if it is confirmed that the mobile communication device did successfully receive the TCP packet and did not send any additional information other than the acknowledgement, the subsequent remote ACK is redundant to the local TCP ACK that was already delivered to the HLOS or application in block 1008. The TCP adaption sub-layer may also delete the stored TCP packet when the subsequent remote ACK is received.

In response to determining that the network base station has not received a subsequent remote ACK from the mobile communication device (i.e., determination block 1012 ＝ “No” ) , the processor may determine that a loss of the TCP packet has occurred in block 1014, and initiate retransmission of the TCP packet in block 1016. For example, the network base station may receive duplicate remote TCP ACKs that may be indicative of a lost packet, or the processor may check whether a RTO has been triggered.

The method 1000 may be repeated for each transmitted TCP packet. In this manner, the method 1000 provides a way for a network base station to generate local TCP ACKs from lower layer ACKs to prevent data throughput loss when communicating with a mobile communication device that may be performing tune-aways.

FIG. 11 illustrates a method 1100 for utilizing acknowledgement buffers for TCP communications in a mobile communication device according to various examples. The method 1100 may be implemented with a processor (e.g., the general processor 206, the baseband modem processor 216, a separate controller, and/or the like) of a mobile communication device (such as the

mobile communication devices

110, 120, 602) that supports a first RAT and a second RAT that share an RF resource. The first RAT and the second RAT may share the same subscription, or may be associated with different subscriptions. The first RAT may be engaged in TCP communications with an associated first network.

In block 1102, the processor of the mobile communication device may transmit a TCP packet from the first RAT to the first network.

In determination block 1104, the processor may determine there is an upcoming tune-away before receiving a TCP response from the first network. For example, the processor may estimate the average time that the first network takes to send a TCP response and compare it to the tune-away schedule on the mobile communication device.

In response to determining that there is no upcoming tune-away before receiving a TCP response from the first network (i.e., determination block 1104 ＝ “No” ) , the processor may receive the TCP response from the first network in block 1118.

In response to determining that there is an upcoming tune-away before receiving a TCP response from the first network (i.e., determination block 1104 ＝ “Yes” ) , the processor may buffer a previously received TCP ACK in block 1106.

In block 1108, the processor may initiate the tune-away from the first RAT to the second RAT.

In block 1110, the processor may initiate a timer with a time interval T. The duration of the timer may be chosen to be shorter than a RTO threshold time so that a RTO is not triggered during the tune-away.

In determination block 1112, the processor may determine whether the tune-away has ended.

In response to determining that the tune-away has ended (i.e., determination block 1112 ＝ “Yes” ) , the processor may the processor may receive the TCP response from the first network in block 1118.

In response to determining that the tune-away has not ended (i.e., determination block 1112 ＝ “No” ) , the processor may determine whether the timer has expired in determination block 1114. In response to determining that the timer has not expired (i.e., determination block 1114 ＝ “No” ) , the processor may continue to wait until either the tune-away has ended or the timer has expired in determination block 1112.

In response to determining that the timer has expired (i.e., determination block 1114 ＝ “Yes” ) , the processor may deliver the buffered TCP ACK to a HLOS or application executing on the mobile communication device (i.e., deliver to the upper TCP/IP layer) in block 1116. The HLOS or application may respond to the duplicate TCP ACK by reducing the congestion window value of the first RAT (e.g., reducing the value by half) . However, the reduction is usually less than if no TCP ACK is delivered and an RTO is triggered (i.e., the congestion window value may be set to one in a RTO) . The processor may then reinitiate the timer in block 1110. The processor may continue to deliver the buffered TCP ACK to the HLOS or application according to the timer period until the tune-away has ended. Before the RTO time expires (i.e., the time interval T has passed) , the mobile communication device may deliver the buffered TCP ACKs as fake duplicate TCP ACPS so that an RTO is not triggered. In this manner, the method 1100 provides a way for a mobile communication device to reduce the impact of tune-aways to data throughput by utilizing buffered TCP ACKs before an RTO is triggered.

Various examples may be implemented in any of a variety of communication devices, an example of which (e.g., multi-SIM mobile communication device 1200) is illustrated in FIG. 12. The multi-SIM mobile communication device 1200 may be similar to the

mobile communication devices

110, 120, 200, 402, and 602 as described. As such, the multi-SIM mobile communication device 1200 may implement the

methods

700, 900, and 1100 according to various examples.

The multi-SIM mobile communication device 1200 may include a processor 1202 coupled to a touchscreen controller 1204 and an internal memory 1206. The processor 1202 may be one or more multi-core integrated circuits designated for general or specific processing tasks. The internal memory 1206 may be volatile or non-volatile memory, and may also be secure and/or encrypted memory, or unsecure and/or unencrypted memory, or any combination thereof. The touchscreen controller 1204 and the processor 1202 may also be coupled to a touchscreen panel 1212, such as a resistive-sensing touchscreen, capacitive-sensing touchscreen, infrared sensing touchscreen, etc. Additionally, the display of the multi-SIM mobile communication device 1200 need not have touch screen capability.

The multi-SIM mobile communication device 1200 may have one or more cellular network transceivers 1208 coupled to the processor 1202 and to one or more antennas 1210 and configured for sending and receiving cellular communications. The one or more transceivers 1208 and the one or more antennas 1210 may be used with the herein-mentioned circuitry to implement various example methods. The multi-SIM mobile communication device 1200 may include one or more SIM cards 1216 coupled to the one or more transceivers 1208 and/or the processor 1202 and may be configured as described herein.

The multi-SIM mobile communication device 1200 may also include speakers 1214 for providing audio outputs. The multi-SIM mobile communication device 1200 may also include a housing 1220, constructed of a plastic, metal, or a combination of materials, for containing all or some of the components discussed herein. The multi-SIM mobile communication device 1200 may include a power source 1222 coupled to the processor 1202, such as a disposable or rechargeable battery. The rechargeable battery may also be coupled to the peripheral device connection port to receive a charging current from a source external to the multi-SIM mobile communication device 1200. The multi-SIM mobile communication device 1200 may also include a physical button 1224 for receiving user inputs. The multi-SIM mobile communication device 1200 may also include a power button 1226 for turning the multi-SIM mobile communication device 1200 on and off.

Various examples may be implemented in any of a variety of network base stations, an example of which (e.g., network base station 1300) is illustrated in FIG. 13. The network base station 1300 may be similar to the base station of the

first network

408, 608 as described. As such, the network base station 1300 may implement the

methods

800 and 1000 according to various examples.

The network base station 1300 may include a processor 1301 coupled to volatile memory 1302 and a large capacity nonvolatile memory, such as a disk drive 1303. The network base station 1300 may also include a network interface 1305 coupled to the processor 1301 for establishing data connections with a network 1306, such as a mobile telephony network connected to a plurality of mobile communication devices. The processor 1301 may be any programmable microprocessor, microcomputer or multiple processor chip or chips that can be configured by software instructions (applications) to perform a variety of functions, including the functions of the various aspects described herein. Typically, software applications may be stored in the

internal memories

1302, 1303 before they are accessed and loaded into the processor 1301. The processor 1301 may include internal memory sufficient to store the application software instructions.

The various examples illustrated and described are provided merely as examples to illustrate various features of the claims. However, features shown and described with respect to any given example are not necessarily limited to the associated example and may be used or combined with other examples that are shown and described. Further, the claims are not intended to be limited by any one example.

The foregoing method descriptions and the process flow diagrams are provided merely as illustrative examples and are not intended to require or imply that the operations of various examples must be performed in the order presented. As will be appreciated by one of skill in the art the order of operations in the foregoing examples may be performed in any order. Words such as “thereafter, ” “then, ” “next, ” etc. are not intended to limit the order of the operations； these words are simply used to guide the reader through the description of the methods. Further, any reference to claim elements in the singular, for example, using the articles “a, ” “an” or “the” is not to be construed as limiting the element to the singular.

The various illustrative logical blocks, modules, circuits, and algorithm operations described in connection with the examples disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and operations have been described herein generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present examples.

The hardware used to implement the various illustrative logics, logical blocks, modules, and circuits described in connection with the aspects disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP) , an application specific integrated circuit (ASIC) , a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but, in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configurations. Alternatively, some operations or methods may be performed by circuitry that is specific to a given function.

In one or more aspects, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or code on a non-transitory computer-readable storage medium or non-transitory processor-readable storage medium. The operations of a method or algorithm disclosed herein may be embodied in a processor-executable software module, which may reside on a non-transitory computer-readable or processor-readable storage medium. Non-transitory computer-readable or processor-readable storage media may be any storage media that may be accessed by a computer or a processor. By way of example but not limitation, such non-transitory computer-readable or processor-readable storage media may include RAM, ROM, EEPROM, FLASH memory, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to store desired program code in the form of instructions or data structures and that may be accessed by a computer. Disk and disc, as used herein, includes compact disc (CD) , laser disc, optical disc, digital versatile disc (DVD) , floppy disk, and Blu-ray disc in which disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the storage media are also included within the scope of non-transitory computer-readable and processor-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and/or instructions on a non-transitory processor-readable storage medium and/or computer-readable storage medium, which may be incorporated into a computer program product.

The preceding description of the disclosed examples is provided to enable any person skilled in the art to make or use the present examples. Various modifications to these examples will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to some examples without departing from the spirit or scope of the written description. Thus, the present disclosure is not intended to be limited to the examples shown herein but is to be accorded the widest scope consistent with the following claims and the principles and novel features disclosed herein.

Claims

A method for managing transmission control protocol (TCP) communications in a mobile communication device, comprising:

determining whether there is an upcoming tune-away from a first radio access technology (RAT) on the mobile communication device to a second RAT on the mobile communication device；

adding a first timestamp to a TCP packet for transmission before the tune-away begins in response to determining that there is an upcoming tune-away from the first RAT to the second RAT；

transmitting the TCP packet to a first network；

performing the tune-away from the first RAT to the second RAT；

triggering a retransmission time out on the first RAT；

receiving a TCP acknowledgement (ACK) from the first network, wherein the TCP ACK includes a second timestamp；

determining whether the TCP ACK corresponds to the TCP packet； and

restoring a prior congestion window value of the first RAT in response to determining that the TCP ACK corresponds to the TCP packet.
The method of claim 1, wherein determining whether the TCP ACK corresponds to the TCP packet comprises comparing the first timestamp to the second timestamp.
The method of claim 1, further comprising:

adding an offset to the first timestamp, wherein the offset is based on an estimated duration of the tune-away.
The method of claim 1, wherein a modem of the mobile communication device adds the first timestamp to the TCP packet.
The method of claim 1, wherein a high level operating system of the mobile communication device adds the first timestamp to the TCP packet.
The method of claim 1, further comprising:

keeping a current congestion window value of the first RAT in response to determining that the TCP ACK does not correspond to the TCP packet.
The method of claim 1, wherein a congestion window value of the first RAT is set to one when the retransmission time out is triggered.
A method for managing transmission control protocol (TCP) communications in a network base station comprising:

receiving a tune-away schedule from a mobile communication device；

determining whether there is an upcoming tune-away on the mobile communication device from the tune-away schedule；

adding a first timestamp to a TCP packet for transmission before the tune-away begins in response to determining that there is an upcoming tune-away on the mobile communication device；

transmitting the TCP packet to the mobile communication device；

triggering a retransmission time out on TCP communications between the network base station and the mobile communication device；

receiving a TCP acknowledgement (ACK) from the mobile communication device, wherein the TCP ACK includes a second timestamp；

determining whether the TCP ACK corresponds to the TCP packet； and

restoring a prior congestion window value of the network base station in response to determining that the TCP ACK corresponds to the TCP packet.
The method of claim 8, wherein determining whether the TCP ACK corresponds to the TCP packet comprises comparing the first timestamp to the second timestamp.
The method of claim 8, further comprising:

adding an offset to the first timestamp, wherein the offset is based on an estimated duration of the tune-away.
The method of claim 8, further comprising:

keeping a current congestion window value of the network base station in response to determining that the TCP ACK does not correspond to the TCP packet.
The method of claim 8, wherein a congestion window value of the network base station is set to one when the retransmission time out is triggered.
A method for managing transmission control protocol (TCP) communications in a mobile communication device, comprising:

transmitting a TCP packet from a first radio access technology (RAT) on the mobile communication device to a first network；

receiving a hybrid automatic repeat request (HARQ) acknowledgement (ACK) or a radio link control (RLC) ACK from the first network；

generating a local TCP ACK from the HARQ ACK or the RLC ACK；

delivering the local TCP ACK to a high level operating system (HLOS) or an application on the mobile communication device；

determining whether the first RAT has received a remote TCP ACK from the first network； and

ignoring the remote TCP ACK in response to determining that the first RAT has received a remote TCP ACK from the first network.
The method of claim 13, wherein a TCP adaption sub-layer in a packet data convergence protocol layer of a modem in the mobile communication device generates the local TCP ACK.
The method of claim 14, wherein the TCP adaption sub-layer receives the HARQ ACK or the RLC ACK from a medium access control (MAC) layer or an RLC layer of the modem.
The method of claim 14, wherein the TCP adaption sub-layer stores a copy of the TCP packet.
The method of claim 13, further comprising:

determining that a loss of the TCP packet has occurred in response to determining that the first RAT has not received a remote TCP ACK from the first network； and

retransmitting the TCP packet.
The method of claim 13, further comprising:

determining whether there is an upcoming tune-away from the first RAT to a second RAT on the mobile communication device；

setting a receive window value of the local TCP ACK to zero in response to determining that there is an upcoming tune-away from the first RAT to the second RAT； and

performing the tune-away from the first RAT to the second RAT.
The method of claim 18, further comprising setting the receive window value of the local TCP ACK to a prior receive window value of a prior received TCP ACK in response to determining that there is no upcoming tune-away from the first RAT to the second RAT.
The method of claim 18, further comprising generating one or more local TCP ACKs for each of a plurality of buffered TCP packets during the tune-away, wherein each of the one or more local TCP ACKs have a receive window value of zero.
The method of claim 13, further comprising:

determining whether the remote TCP ACK contains additional information not contained in the local TCP ACK； and

delivering the additional information to the HLOS or the application in response to determining that the remote TCP ACK contains additional information not contained in the local TCP ACK.
A method of managing transmission control protocol (TCP) communications in a network base station, comprising:

transmitting a TCP packet to a mobile communication device；

receiving a hybrid automatic repeat request (HARQ) acknowledgement (ACK) or a radio link control (RLC) ACK from the mobile communication device；

generating a local TCP ACK from the HARQ ACK or the RLC ACK；

delivering the local TCP ACK to a high level operating system (HLOS) or application on the network base station；

determining whether the network base station has received a subsequent remote ACK from the mobile communication device； and

ignoring the subsequent remote ACK in response to determining that the network base station has received a subsequent remote ACK from the mobile communication device.
The method of claim 22, wherein a TCP adaption sub-layer in the network base station generates the local TCP ACK.
The method of claim 22, further comprising:

determining that a loss of the TCP packet has occurred in response to determining that the network base station has not received a subsequent remote ACK from the mobile communication device； and

retransmitting the TCP packet.
The method of claim 22, wherein the local TCP ACK includes a receive window value set to equal a prior receive window value of a prior received TCP ACK.
The method of claim 22, further comprising:

determining whether the subsequent remote ACK contains additional information not contained in the local TCP ACK； and

delivering the additional information to the HLOS or the application in response to determining that the subsequent remote ACK contains additional information not contained in the local TCP ACK.
The method of claim 22, further comprising:

instructing the mobile communication device to not transmit a TCP ACK corresponding to the TCP packet.
A method of managing transmission control protocol (TCP) communications in a mobile communication device, comprising:

transmitting a TCP packet from a first radio access technology (RAT) of the mobile communication device to a first network；

determining whether there is an upcoming tune-away from the first RAT to a second RAT on the mobile communication device before receiving a TCP response from the first network；

buffering a previously received TCP acknowledgment (ACK) in response to determining that there is a tune-away from the first RAT to the second RAT scheduled before receiving a TCP response from the first network；

initiating the tune-away；

initiating a timer；

determining whether the timer has expired； and

delivering the buffered TCP ACK to a high level operating system (HLOS) or application on the mobile communication device in response to determining that the timer has not expired.
The method of claim 28, further comprising:

reinitiating the timer after delivering the buffered TCP ACK.
The method of claim 28, further comprising:

determining whether the tune-away has ended； and

receiving the TCP response from the first network in response to determining that the tune-away has ended.
The method of claim 28, wherein a duration of the timer is shorter than a retransmission time out threshold time.
A mobile communication device, comprising:

a memory；

a subscriber identity module (SIM) ；

a radio frequency (RF) resource configured to support a first radio access technology (RAT) and a second RAT； and

a processor coupled to the memory, the SIM, the RF resource, and configured to:

determine whether there is an upcoming tune-away from the first RAT to the second RAT；

add a first timestamp to a transmission control protocol (TCP) packet for transmission before the tune-away begins in response to determining that there is an upcoming tune-away from the first RAT to the second RAT；

transmit the TCP packet to a first network；

perform the tune-away from the first RAT to the second RAT；

trigger a retransmission time out on the first RAT；

receive a TCP acknowledgement (ACK) from the first network, wherein the TCP ACK includes a second timestamp；

determine whether the TCP ACK corresponds to the TCP packet； and

restore a prior congestion window value of the first RAT in response to determining that the TCP ACK corresponds to the TCP packet.
The mobile communication device of claim 32, wherein the processor is configured to determine whether the TCP ACK corresponds to the TCP packet by comparing the first timestamp to the second timestamp.
The mobile communication device of claim 32, wherein the processor is further configured to:

add an offset to the first timestamp, wherein the offset is based on an estimated duration of the tune-away.
The mobile communication device of claim 32, wherein a modem of the mobile communication device adds the first timestamp to the TCP packet.
The mobile communication device of claim 32, wherein a high level operating system of the mobile communication device adds the first timestamp to the TCP packet.
The mobile communication device of claim 32, wherein the processor is further configured to:

keep a current congestion window value of the first RAT in response to determining that the TCP ACK does not correspond to the TCP packet.
The mobile communication device of claim 32, wherein a congestion window value of the first RAT is set to one when the retransmission time out is triggered.
A network base station, comprising

a memory；

a network interface, and

a processor coupled to the memory and the network interface, and configured to:

receive a tune-away schedule from a mobile communication device；

determining whether there is an upcoming tune-away on the mobile communication device from the tune-away schedule；

add a first timestamp to a transmission control protocol (TCP) packet for transmission before the tune-away begins in response to determining that there is an upcoming tune-away on the mobile communication device；

transmit the TCP packet to the mobile communication device；

trigger a retransmission time out on TCP communications between the network base station and the mobile communication device；

receive a TCP acknowledgement (ACK) from the mobile communication device, wherein the TCP ACK includes a second timestamp；

determine whether the TCP ACK corresponds to the TCP packet； and

restore a prior congestion window value of the network base station in response to determining that the TCP ACK corresponds to the TCP packet.
The network base station of claim 39, wherein the processor is configured to determine whether the TCP ACK corresponds to the TCP packet by comparing the first timestamp to the second timestamp.
The network base station of claim 39, wherein the processor is further configured to:

add an offset to the first timestamp, wherein the offset is based on an estimated duration of the tune-away.
The network base station of claim 39, wherein the processor is further configured to:

keep a current congestion window value of the network base station in response to determining that the TCP ACK does not correspond to the TCP packet.
The network base station of claim 39, wherein a congestion window value of the network base station is set to one when the retransmission time out is triggered.
A mobile communication device, comprising:

a memory；

a subscriber identity module (SIM) ；

a radio frequency (RF) resource configured to support a first radio access technology (RAT) ； and

a processor coupled to the memory, the SIM, and the RF resource, and configured to:

transmit a transmission control protocol (TCP) packet from the first RAT to a first network；

receive a hybrid automatic repeat request (HARQ) acknowledgement (ACK) or a radio link control (RLC) ACK from the first network；

generate a local TCP ACK from the HARQ ACK or the RLC ACK；

deliver the local TCP ACK to a high level operating system (HLOS) or an application on the mobile communication device；

determine whether the first RAT has received a remote TCP ACK from the first network； and

ignore the remote TCP ACK in response to determining that the first RAT has received a remote TCP ACK from the first network.
The mobile communication device of claim 44, wherein a TCP adaption sub-layer in a packet data convergence protocol layer of a modem in the mobile communication device generates the local TCP ACK.
The mobile communication device of claim 45, wherein the TCP adaption sub-layer receives the HARQ ACK or the RLC ACK from a medium access control (MAC) layer or an RLC layer of the modem.
The mobile communication device of claim 45, wherein the TCP adaption sub-layer stores a copy of the TCP packet.
The mobile communication device of claim 44, wherein the processor is further configured to:

determine that a loss of the TCP packet has occurred in response to determining that the first RAT has not received a remote TCP ACK from the first network； and

retransmit the TCP packet.
The mobile communication device of claim 44, wherein the RF resource is further configured to support a second RAT, and the processor is further configured to:

determine whether there is an upcoming tune-away from the first RAT to the second RAT；

set a receive window value of the local TCP ACK to zero in response to determining that there is an upcoming tune-away from the first RAT to the second RAT； and

perform the tune-away from the first RAT to the second RAT.
The mobile communication device of claim 49, wherein the processor is further configured to:

set the receive window value of the local TCP ACK to a prior receive window value of a prior received TCP ACK in response to determining that there is no upcoming tune-away from the first RAT to the second RAT.
The mobile communication device of claim 49, wherein the processor is further configured to:

generate one or more local TCP ACKs for each of a plurality of buffered TCP packets during the tune-away, wherein each of the one or more local TCP ACKs have a receive window value of zero.
The mobile communication device of claim 44, wherein the processor is further configured to:

determine whether the remote TCP ACK contains additional information not contained in the local TCP ACK； and

deliver the additional information to the HLOS or the application in response to determining that the remote TCP ACK contains additional information not contained in the local TCP ACK.
A network base station, comprising:

a memory；

a network interface, and

a processor coupled to the memory and the network interface, and configured to:

transmit a transmission control protocol (TCP) packet to a mobile communication device；

receive a hybrid automatic repeat request (HARQ) acknowledgement (ACK) or a radio link control (RLC) ACK from the mobile communication device；

generate a local TCP ACK from the HARQ ACK or the RLC ACK；

deliver the local TCP ACK to a high level operating system (HLOS) or application on the network base station；

determine whether the network base station has received a subsequent remote ACK from the mobile communication device； and

ignore the subsequent remote ACK in response to determining that the network base station has received a subsequent remote ACK from the mobile communication device.
The network base station of claim 53, wherein a TCP adaption sub-layer in the network base station generates the local TCP ACK.
The network base station of claim 53, wherein the processor is further configured to:

determine that a loss of the TCP packet has occurred in response to determining that the network base station has not received a subsequent remote ACK from the mobile communication device； and

retransmit the TCP packet.
The network base station of claim 53, wherein the local TCP ACK includes a receive window value set to equal a prior receive window value of a prior received TCP ACK.
The network base station of claim 53, wherein the processor is further configured to:

determine whether the subsequent remote ACK contains additional information not contained in the local TCP ACK； and

deliver the additional information to the HLOS or the application in response to determining that the subsequent remote ACK contains additional information not contained in the local TCP ACK.
The mobile communication device of claim 53, wherein the processor is further configured to:

instruct the mobile communication device to not transmit a TCP ACK corresponding to the TCP packet.
A mobile communication device, comprising:

a memory；

a subscriber identity module (SIM) ；

a radio frequency (RF) resource configured to support a first radio access technology (RAT) and a second RAT； and

a processor coupled to the memory, the SIM, and the RF resource, and configured to:

transmit a transmission control protocol (TCP) packet from the first RAT to a first network；

determine whether there is an upcoming tune-away from the first RAT to the second RAT before receiving a TCP response from the first network；

buffer a previously received TCP acknowledgment (ACK) in response to determining that there is a tune-away from the first RAT to the second RAT scheduled before receiving a TCP response from the first network；

initiate the tune-away；

initiate a timer；

determine whether the timer has expired； and

deliver the buffered TCP ACK to a high level operating system (HLOS) or application on the mobile communication device in response to determining that the timer has not expired.
The mobile communication device of claim 59, wherein the processor is further configured to:

reinitiate the timer after delivering the buffered TCP ACK.
The mobile communication device of claim 59, wherein the processor is further configured to:

determine whether the tune-away has ended； and

receive the TCP response from the first network in response to determining that the tune-away has ended.
The mobile communication device of claim 59, wherein a duration of the timer is shorter than a retransmission time out threshold time.
A non-transitory computer readable storage medium having stored thereon processor-executable software instructions configured to cause a processor of a mobile communication device to perform operations comprising:

determining whether there is an upcoming tune-away from a first radio access technology (RAT) on the mobile communication device to a second RAT on the mobile communication device；

adding a first timestamp to a transmission control protocol (TCP) packet for transmission before the tune-away begins in response to determining that there is an upcoming tune-away from the first RAT to the second RAT；

transmitting the TCP packet to a first network；

performing the tune-away from the first RAT to the second RAT；

triggering a retransmission time out on the first RAT；

receiving a TCP acknowledgement (ACK) from the first network, wherein the TCP ACK includes a second timestamp；

determining whether the TCP ACK corresponds to the TCP packet； and

restoring a prior congestion window value of the first RAT in response to determining that the TCP ACK corresponds to the TCP packet.
A non-transitory computer readable storage medium having stored thereon processor-executable software instructions configured to cause a processor of a network base station to perform operations comprising:

receiving a tune-away schedule from a mobile communication device；

determining whether there is an upcoming tune-away on the mobile communication device from the tune-away schedule；

adding a first timestamp to a transmission control protocol (TCP) packet for transmission before the tune-away begins in response to determining that there is an upcoming tune-away on the mobile communication device；

transmitting the TCP packet to the mobile communication device；

triggering a retransmission time out on TCP communications between the network base station and the mobile communication device；

receiving a TCP acknowledgement (ACK) from the mobile communication device, wherein the TCP ACK includes a second timestamp；

determining whether the TCP ACK corresponds to the TCP packet； and

restoring a prior congestion window value of the network base station in response to determining that the TCP ACK corresponds to the TCP packet.
A non-transitory computer readable storage medium having stored thereon processor-executable software instructions configured to cause a processor of a mobile communication device to perform operations comprising:

transmitting a transmission control protocol (TCP) packet from a first radio access technology (RAT) on the mobile communication device to a first network；

receiving a hybrid automatic repeat request (HARQ) acknowledgement (ACK) or a radio link control (RLC) ACK from the first network；

generating a local TCP ACK from the HARQ ACK or the RLC ACK；

delivering the local TCP ACK to a high level operating system (HLOS) or an application on the mobile communication device；

determining whether the first RAT has received a remote TCP ACK from the first network； and

ignoring the remote TCP ACK in response to determining that the first RAT has received a remote TCP ACK from the first network.
A non-transitory computer readable storage medium having stored thereon processor-executable software instructions configured to cause a processor of a network base station to perform operations comprising:

transmitting a transmission control protocol (TCP) packet to a mobile communication device；

receiving a hybrid automatic repeat request (HARQ) acknowledgement (ACK) from the mobile communication device；

generating a local TCP ACK from the HARQ ACK；

delivering the local TCP ACK to a high level operating system (HLOS) or application on the network base station；

determining whether the network base station has received a subsequent remote ACK from the mobile communication device； and

ignoring the subsequent remote ACK in response to determining that the network base station has received a subsequent remote ACK from the mobile communication device.
A non-transitory computer readable storage medium having stored thereon processor-executable software instructions configured to cause a processor of a mobile communication device to perform operations comprising:

transmitting a transmission control protocol (TCP) packet from a first radio access technology (RAT) of the mobile communication device to a first network；

determining whether there is an upcoming tune-away from the first RAT to a second RAT on the mobile communication device before receiving a TCP response from the first network；

buffering a previously received TCP acknowledgment (ACK) in response to determining that there is a tune-away from the first RAT to the second RAT scheduled before receiving a TCP response from the first network；

initiating the tune-away；

initiating a timer；

determining whether the timer has expired； and

delivering the buffered TCP ACK to a high level operating system (HLOS) or application on the mobile communication device in response to determining that the timer has not expired.
A mobile communication device, comprising:

means for determining whether there is an upcoming tune-away from a first radio access technology (RAT) on the mobile communication device to a second RAT on the mobile communication device；

means for adding a first timestamp to a transmission control protocol (TCP) packet for transmission before the tune-away begins in response to determining that there is an upcoming tune-away from the first RAT to the second RAT；

means for transmitting the TCP packet to a first network；

means for performing the tune-away from the first RAT to the second RAT；

means for triggering a retransmission time out on the first RAT；

means for receiving a TCP acknowledgement (ACK) from the first network, wherein the TCP ACK includes a second timestamp；

means for determining whether the TCP ACK corresponds to the TCP packet； and

means for restoring a prior congestion window value of the first RAT in response to determining that the TCP ACK corresponds to the TCP packet.
The mobile communication device of claim 68, wherein means for determining whether the TCP ACK corresponds to the TCP packet comprises means for comparing the first timestamp to the second timestamp.
The mobile communication device of claim 68, further comprising:

means for adding an offset to the first timestamp, wherein the offset is based on an estimated duration of the tune-away.
The mobile communication device of claim 68, wherein a modem of the mobile communication device adds the first timestamp to the TCP packet.
The mobile communication device of claim 68, wherein a high level operating system of the mobile communication device adds the first timestamp to the TCP packet.
The mobile communication device of claim 68, further comprising:

means for keeping a current congestion window value of the first RAT in response to determining that the TCP ACK does not correspond to the TCP packet.
The mobile communication device of claim 68, wherein a congestion window value of the first RAT is set to one when the retransmission time out is triggered.
A network base station comprising:

means for receiving a tune-away schedule from a mobile communication device；

means for determining whether there is an upcoming tune-away on the mobile communication device from the tune-away schedule；

means for adding a first timestamp to a transmission control protocol (TCP) packet for transmission before the tune-away begins in response to determining that there is an upcoming tune-away on the mobile communication device；

means for transmitting the TCP packet to the mobile communication device；

means for triggering a retransmission time out on TCP communications between the network base station and the mobile communication device；

means for receiving a TCP acknowledgement (ACK) from the mobile communication device, wherein the TCP ACK includes a second timestamp；

means for determining whether the TCP ACK corresponds to the TCP packet； and

means for restoring a prior congestion window value of the network base station in response to determining that the TCP ACK corresponds to the TCP packet.
The network base station of claim 75, wherein means for determining whether the TCP ACK corresponds to the TCP packet comprises means for comparing the first timestamp to the second timestamp.
The network base station of claim 75, further comprising:

means for adding an offset to the first timestamp, wherein the offset is based on an estimated duration of the tune-away.
The network base station of claim 75, further comprising:

means for keeping a current congestion window value of the network base station in response to determining that the TCP ACK does not correspond to the TCP packet.
The network base station of claim 75, wherein a congestion window value of the network base station is set to one when the retransmission time out is triggered.
A mobile communication device, comprising:

means for transmitting a transmission control protocol (TCP) packet from a first radio access technology (RAT) on the mobile communication device to a first network；

means for receiving a hybrid automatic repeat request (HARQ) acknowledgement (ACK) or a radio link control (RLC) ACK from the first network；

means for generating a local TCP ACK from the HARQ ACK or the RLC ACK；

means for delivering the local TCP ACK to a high level operating system (HLOS) or an application on the mobile communication device；

means for determining whether the first RAT has received a remote TCP ACK from the first network； and

means for ignoring the remote TCP ACK in response to determining that the first RAT has received a remote TCP ACK from the first network.
The mobile communication device of claim 80, wherein a TCP adaption sub-layer in a packet data convergence protocol layer of a modem in the mobile communication device generates the local TCP ACK.
The mobile communication device of claim 81, wherein the TCP adaption sub-layer receives the HARQ ACK or the RLC ACK from a medium access control (MAC) layer or a RLC layer of the modem.
The mobile communication device of claim 81, wherein the TCP adaption sub-layer stores a copy of the TCP packet.
The mobile communication device of claim 80, further comprising:

means for determining that a loss of the TCP packet has occurred in response to determining that the first RAT has not received a remote TCP ACK from the first network； and

means for retransmitting the TCP packet.
The mobile communication device of claim 80, further comprising:

means for determining whether there is an upcoming tune-away from the first RAT to a second RAT on the mobile communication device；

means for setting a receive window value of the local TCP ACK to zero in response to determining that there is an upcoming tune-away from the first RAT to the second RAT； and

means for performing the tune-away from the first RAT to the second RAT.
The mobile communication device of claim 85, further comprising means for setting the receive window value of the local TCP ACK to a prior receive window value of a prior received TCP ACK in response to determining that there is no upcoming tune-away from the first RAT to the second RAT.
The mobile communication device of claim 85, further comprising means for generating one or more local TCP ACKs for each of a plurality of buffered TCP packets during the tune-away, wherein each of the one or more local TCP ACKs have a receive window value of zero.
The mobile communication device of claim 80, further comprising:

means for determining whether the remote TCP ACK contains additional information not contained in the local TCP ACK； and

means for delivering the additional information to the HLOS or the application in response to determining that the remote TCP ACK contains additional information not contained in the local TCP ACK.
A network base station, comprising:

means for transmitting a transmission control protocol (TCP) packet to a mobile communication device；

means for receiving a hybrid automatic repeat request (HARQ) acknowledgement (ACK) or a radio link control (RLC) ACK from the mobile communication device；

means for generating a local TCP ACK from the HARQ ACK or the RLC ACK；

means for delivering the local TCP ACK to a high level operating system (HLOS) or application on the network base station；

means for determining whether the network base station has received a subsequent remote ACK from the mobile communication device； and

means for ignoring the subsequent remote ACK in response to determining that the network base station has received a subsequent remote ACK from the mobile communication device.
The network base station of claim 89, wherein a TCP adaption sub-layer in the network base station generates the local TCP ACK.
The network base station of claim 89, further comprising:

means for determining that a loss of the TCP packet has occurred in response to determining that the network base station has not received a subsequent remote ACK from the mobile communication device； and

means for retransmitting the TCP packet.
The network base station of claim 89, wherein the local TCP ACK includes a receive window value set to equal a prior receive window value of a prior received TCP ACK.
The network base station of claim 89, further comprising:

means for determining whether the subsequent remote ACK contains additional information not contained in the local TCP ACK； and

means for delivering the additional information to the HLOS or the application in response to determining that the subsequent remote ACK contains additional information not contained in the local TCP ACK.
The network base station of claim 89, further comprising:

means for instructing the mobile communication device to not transmit a TCP ACK corresponding to the TCP packet.
A mobile communication device, comprising:

means for transmitting a transmission control protocol (TCP) packet from a first radio access technology (RAT) of the mobile communication device to a first network；

means for determining whether there is an upcoming tune-away from the first RAT to a second RAT on the mobile communication device before receiving a TCP response from the first network；

means for buffering a previously received TCP acknowledgment (ACK) in response to determining that there is a tune-away from the first RAT to the second RAT scheduled before receiving a TCP response from the first network；

means for initiating the tune-away；

means for initiating a timer；

means for determining whether the timer has expired； and

means for delivering the buffered TCP ACK to a high level operating system (HLOS) or application on the mobile communication device in response to determining that the timer has not expired.
The mobile communication device of claim 95, further comprising:

means for reinitiating the timer after delivering the buffered TCP ACK.
The mobile communication device of claim 95, further comprising:

means for determining whether the tune-away has ended； and

means for receiving the TCP response from the first network in response to determining that the tune-away has ended.
The mobile communication device of claim 95, wherein a duration of the timer is shorter than a retransmission time out threshold time.