Systems and methods for managing Transmission Control Protocol (TCP) acknowledgments

Abstract

The present disclosure relates to systems and methods for managing Transmission Control Protocol (TCP) acknowledgments. A client device in a wireless network accesses a queue that includes Transmission Control Protocol acknowledgment (TCP ACK) packets. At least some of the packets include a packet descriptor having a flow identifier and a TCP ACK generation count, the flow identifier indicating a corresponding TCP flow. The device examines the packet descriptor of a first TCP ACK packet and identifies a first flow identifier and a first TCP ACK generation count. The device accesses an entry in a data structure, each entry including a first field and a second field that store a flow identifier and a TCP ACK generation count, respectively. The device determines that a condition is met, the condition including that the entry in the data structure includes a flow identifier and a TCP ACK generation count that respectively match the first flow identifier and the first TCP ACK generation count. In response to the determination, the device marks the first TCP ACK packet as pending discard.

Description

Technical Field

[0001] The following disclosure generally relates to communication technologies and, in particular, to systems, methods, and apparatuses for transmission control protocol (TCP) acknowledgment (ACK) transmission in a communication network. Background Art

[0002] TCP is a communication protocol that facilitates the exchange of messages between computing devices on a network, e.g., application data exchange between a client device and a server device connected via one or more network connections. TCP is designed to ensure reliable, ordered, and error-checked delivery of data sent in the form of TCP packets. TCP uses acknowledgment (ACK) packets for reliable transmission. Summary of the Invention

[0003] The present disclosure describes systems, devices, and methods for managing the transmission of TCP acknowledgment packets (referred to as TCP ACK packets). In some specific implementations, the disclosed systems, devices, and methods are for managing the transmission of TCP ACK packets from a client device to another network device (such as an application server (AS)) in response to receiving TCP data and control packets at the client device. In some specific implementations, the baseband (BB) circuitry in the client device examines TCP ACK packets queued for transmission to the AS and discards duplicate TCK ACK packets (e.g., TCP ACK packets corresponding to the same flow with the same sequence number) that the BB circuitry determines to be redundant. In some specific implementations, the BBU circuitry determines the TCP ACK packet to be redundant when the TCP ACK packet is a duplicate of one or more other TCP ACK packets and is stamped with a counter value that is the same as the counter value of one or more other TCP ACK packets (generated by a TCP application at the client device). In some specific implementations, the client device is an electronic device in a wireless communication network that is connected to the AS via one or more network connections. For example, in some specific implementations, the client device is a user equipment (UE) in a 3rd Generation Partnership Project (3GPP) mobile wireless communication network that uses a 3GPP network connection to connect to the AS. In such cases, the UE manages the transmission of TCP ACK packets in the uplink direction.

[0004] TCP is a reliable stream delivery service where the receiver of a TCP packet responds to the sender with a TCP ACK message upon receipt of the TCP packet. For reliable transmission, TCP uses sequence numbers to identify each data byte. The sequence numbers identify the order in which bytes are sent from each computer so that the data can be reconstructed in order, regardless of any packet reordering or packet loss that may occur during transmission. The receiver sends the TCP ACK along with the sequence number to inform the sender that the specified bytes of data have been received. The sequence number associated with the TCK ACK is cumulative and is used to acknowledge all data bytes received prior to that sequence number. In some cases, TCP packets may be lost during transmission and the receiver may receive TCP packets with sequence numbers that are not consecutive in the sequence number chain. In such cases, upon detecting an interruption in the sequence number chain, the receiver sends a duplicate ACK with the latest sequence number prior to the interruption. This duplicate ACK serves as a signal of packet loss, triggering the sender to retransmit the last unacknowledged packet. When multiple duplicate TCP ACK packets are received, the sender will retransmit the missing data packet.

[0005] In some specific implementations, duplicate TCP ACKs are part of a fault recovery mechanism to ensure the reliability of the TCP protocol. Duplicate acknowledgments are sent when the client device notices a gap between a series of packets or when the client device receives out-of-order data packets. For example, if the client device receives the following sequence of data packets: data packet #1 - data packet #3 - data packet #2 instead of data packet #1 - data packet #2 - data packet #3, then upon receipt of packet #3, the client device begins sending duplicate TCP ACKs so that the server can begin the fast retransmit process.

[0006] In some specific implementations, the TCP protocol uses duplicate ACKs as well as timer timeouts to retransmit lost data packets. Duplicate ACKs are used as part of fast retransmit and data packet recovery. In some specific implementations, duplicate TCP ACKs are used to notify the server before a timeout occurs. Since the server does not know whether the receipt of a duplicate TCP ACK is due to a lost data packet or simply due to reordering of data packets, the server waits to receive a small number of duplicate TCP ACKs. If multiple duplicate TCP ACKs are received in succession, this strongly indicates that a data packet has been lost.

[0007] In some specific implementations, a server that sends a series of data packets to a client device is allowed to send up to a predetermined number of unacknowledged data packets to the client device before receiving a TCP ACK packet that acknowledges the successful receipt of the sent unacknowledged data packets. If the server that sends the series of data packets has sent the predetermined number of unacknowledged data packets, the server must abort sending additional sequential packets in the series of data packets and / or retransmit one or more previously sent data packets until the server receives a TCP ACK from the client device. Thus, if the client device has a delay in sending a TCP ACK packet to acknowledge the receipt of the data packets sent by the server, the throughput of the communication session with the server decreases because the sending of data packets by the server stops.

[0008] In some cases, when data packets are lost, a connection with more latency between the receiver and the sender may have a large number of duplicate TCP ACK packets. For example, for several lost data packets, a high-latency connection may observe dozens or hundreds of duplicate TCP ACK packets, which may increase congestion and round-trip time, thus reducing the data throughput of the communication session.

[0009] Various specific implementations disclosed herein provide optimization of a TCP connection (also interchangeably referred to as a TCP stream or TCP flow) by discarding duplicate or redundant TCP ACK packets at a receiver (e.g., a client device) when sending a TCP ACK packet to a sender (e.g., an AS). In some specific implementations, the client device is configured to discard one or more packets among the older TCP ACK packets pending in the output queue at the client device in the TCP uplink flow (e.g., from the client device to the AS) in response to detecting a newer duplicate TCP ACK packet (e.g., a TCP ACK packet having the same sequence number at the head of the output queue).

[0010] In some specific implementations, the client device queues TCP uplink (UL) packets including TCP ACK packets in a memory coupled to the client device until the packets can be transmitted via the network to the AS. The TCP layer within the 3GPP protocol stack of the client device is implemented to check the queue, for example, during UL latency when the queue grows, to determine whether some TCP ACK packets are redundant (e.g., having the same sequence number as one or more other TCP ACK packets) and can be discarded before sending. Discarding redundant TCP ACK packets is also referred to as traffic reduction in this specification.

[0011] In general aspects, a client device in a wireless network manages Transmission Control Protocol acknowledgement (TCP ACK) packet transmissions by accessing, in a memory, a queue that includes TCP ACK packets to be transmitted to another device in response to receiving a TCP packet from another device in the wireless network. At least a subset of the TCP ACK packets in the queue includes respective packet descriptors, each packet descriptor having a flow identifier indicating a TCP flow associated with the packet and a TCP ACK generation count. The client device examines a packet descriptor of a first TCP ACK packet among the TCP ACK packets in the queue and identifies a first flow identifier and a first TCP ACK generation count corresponding to the first TCP ACK packet. When determining that the first flow identifier and the first TCP ACK generation count are valid, the client device accesses an entry in a data structure in the memory, where each entry includes a first field storing a flow identifier and a second field storing a corresponding TCP ACK generation count. The client device determines that a condition is satisfied, where the condition includes that the data structure includes a first entry having a flow identifier and a TCP ACK generation count that respectively match the first flow identifier and the first TCP ACK generation count. In response to determining that the condition is satisfied, the client device marks the first TCP ACK packet as to be discarded.

[0012] Specific embodiments include one or more of the following features.

[0013] In some embodiments, the condition further includes that a loss rate of a lower layer queue is lower than a threshold.

[0014] In some embodiments, the TCP flow includes uplink data in multiple queues. The condition further includes that the first TCP ACK packet corresponds to uplink data in a specific queue among the multiple queues. The specific queue may have a high priority or a low priority.

[0015] In some embodiments, the TCP flow includes uplink data transmitted in multiple data radio bearers (DRBs). The condition further includes that the first TCP ACK packet corresponds to uplink data transmitted in one or more DRBs. The one or more DRBs may be a default DRB on an Internet protocol data network (PDN). At least one of the one or more DRBs may have a throughput within a given range. The one or more DRBs may also be bidirectional DRBs.

[0016] In some embodiments, the TCP flow includes uplink data corresponding to multiple packet data networks (PDNs). The condition further includes that the first TCP ACK packet corresponds to uplink data transmitted in one or more given PDNs.

[0017] In some specific implementations, the condition further includes that the client device operates in a known power mode.

[0018] In some specific implementations, the TCP flow includes multiple Internet Protocol (IP) packet flows. The condition further includes that the first TCP ACK packet corresponds to uplink data transmitted in one or more given IP packet flows.

[0019] In some specific implementations, the condition further includes that the client device detects downlink TCP data at the baseband.

[0020] In some specific implementations, the first entry in the data structure corresponds to the second TCP ACK packet in the queue, where the first TCP ACK packet was generated before the second TCP ACK packet, and where the position of the first TCP ACK packet in the queue is in front of the position of the second TCP ACK packet in the queue. In some specific implementations, the queue is checked starting from the latest packet first.

[0021] In some specific implementations, these packet descriptors are allocated by a TCP application processor included in the client device, and these packet descriptors are checked by a baseband processor circuit included in the client device. In some specific implementations, the application processor assigns a first ACK generation count value corresponding to a first flow identifier to multiple TCP ACK packets generated in a first time interval, and assigns a second ACK generation count value corresponding to a second flow identifier to multiple TCP ACK packets generated in a second time interval different from the first time interval, where the first ACK generation count value is different from the second ACK generation count value. In some specific implementations, the application processor controls the rate of discarding TCP ACK packets from the queue by controlling the duration of at least one of the first time interval or the second time interval.

[0022] In some specific implementations, the client device checks the packet descriptor of the third TCP ACK packet in the TCP packets in the queue, and identifies the third TCP ACK generation count and the third flow identifier corresponding to the third TCP ACK packet included in the packet descriptor of the third TCP ACK packet. The client device determines that the third TCP ACK generation count is set to an invalid value. In response to this determination, the client device aborts further processing of the third TCP ACK packet. In some specific implementations, determining that the TCP ACK generation count of the third TCP packet is set to an invalid value includes determining one of the following: the TCP ACK generation count of the third TCP packet is empty; or the TCP ACK generation count of the third TCP packet is set to a predetermined invalid value.

[0023] In some specific embodiments, the client device checks the packet descriptor of the third TCP ACK packet in the TCP ACK packets in the queue, and identifies the third TCP ACK generation count and the third flow identifier corresponding to the third TCP ACK packet included in the packet descriptor of the third TCP ACK packet. The client device determines that the third flow identifier is set to an invalid value. In response to this determination, the client device aborts further processing of the third TCP ACK packet. In some specific embodiments, determining that the third flow identifier of the third TCP ACK packet is set to an invalid value includes determining one of the following: the flow identifier is not assigned to the third TCP ACK packet; or the flow identifier of the third TCP packet is set to a predetermined invalid value.

[0024] In some specific embodiments, the client device checks the packet descriptor of the fourth TCP packet in the TCP packets in the queue, and identifies the fourth TCP ACK generation count and the fourth flow identifier corresponding to the fourth TCP ACK packet included in the packet descriptor of the fourth TCP ACK packet. The client device determines that the fourth TCP ACK generation count and the fourth flow identifier are valid. The client device determines that (i) the fourth flow identifier is the same as the first flow identifier in the first entry in the queue, and (ii) the fourth TCP ACK generation count is different from the first TCP ACK generation count in the first entry in the queue. In response to this determination, the client device updates the first entry by replacing the first TCP ACK generation count stored in the second field of the first entry with the fourth TCP ACK generation count.

[0025] In some specific embodiments, the client device checks the packet descriptor of the fifth TCP packet in the TCP packets in the queue, and identifies the fifth TCP ACK generation count and the fifth flow identifier corresponding to the fifth TCP ACK packet included in the packet descriptor of the third TCP ACK packet. The client device determines that the fifth TCP ACK generation count and the fifth flow identifier are valid, and the data structure does not include an entry corresponding to the fifth flow identifier. In response to this determination, the client device creates a third entry in the data structure and stores the fifth flow identifier and the fifth TCP ACK generation count in the third entry.

[0026] In some specific embodiments, the received TCP packet includes one or more of application control information and application data.

[0027] In some specific embodiments, the queue includes one or more additional TCP ACK packets, and the one or more additional TCP ACK packets have packet descriptors without TCP ACK generation count fields.

[0028] In some specific implementations, one or more entries in the data structure include hash values representing flow identifiers, and determining that the data structure includes a first entry storing a first TCP ACK generation count and a first flow identifier and the first TCP ACK generation count includes: performing a hash function on the first flow identifier to obtain a first hash value, the first hash value being represented by fewer bits than the number of bits used to represent the first flow identifier; comparing the first hash value with the hash values included in the one or more entries in the data structure to determine whether there is a match; and in response to the comparison, determining that the hash value included in the first entry matches the first hash value.

[0029] In another general aspect, a method for TCP ACK packet transmission performed by a client device in a wireless network includes: in response to receiving a TCP packet from another network device in the wireless network, accessing, in a memory coupled to the client device, a queue including TCP ACK packets to be transmitted to the other network device, wherein at least a subset of the TCP ACK packets includes corresponding packet descriptors, each packet descriptor including (i) a flow identifier indicating a TCP flow associated with the packet and (ii) a TCP ACK generation count; examining the packet descriptor of a first TCP ACK packet among the TCP ACK packets in the queue; identifying a first flow identifier and a first TCP ACK generation count corresponding to the first TCP ACK packet included in the packet descriptor of the first TCP ACK packet; determining that the first flow identifier and the first TCP ACK generation count are valid; accessing, in the memory coupled to the client device, a data structure having one or more entries, each entry including a flow identifier and a corresponding TCP ACK generation count; determining that a condition is satisfied, wherein the condition includes that the data structure includes a first entry, the first entry including (i) a flow identifier matching the first flow identifier and (ii) a TCP ACK generation count matching the first TCP ACK generation count, the first entry further storing a second position field corresponding to the position of a second TCP ACK packet in the queue; in response to the determination, storing the position of the first TCP ACK packet in a first position field in the first entry; swapping, at least based on the first position field and the second position field, the positions of the first TCP ACK packet and the second TCP ACK packet in the queue such that the first TCP ACK packet moves to the position previously occupied by the second TCP ACK packet in the queue and the second TCP ACK packet moves to the position previously occupied by the first TCP ACK packet in the queue; and discarding the first TCP ACK packet from the queue.

[0030] Specific embodiments include one or more of the following features. In some embodiments, the first entry in the data structure corresponds to the second TCP ACK packet in the queue, and the first TCP ACK packet was generated before the second TCP ACK packet, and the position of the first TCP ACK packet in the queue is in front of the position of the second TCP ACK packet in the queue.

[0031] In some embodiments, the queue is checked starting from the latest packet first.

[0032] In some embodiments, the packet descriptors are assigned by a TCP application processor included in the client device and are checked by a baseband processor circuit included in the client device. In some embodiments, the application processor assigns a first ACK generation count value corresponding to a first flow identifier to a plurality of TCP ACK packets generated in a first time interval, and assigns a second ACK generation count value corresponding to a second flow identifier to a plurality of TCP ACK packets generated in a second time interval different from the first time interval, the first ACK generation count value being different from the second ACK generation count value. In some embodiments, the application processor controls the rate of discarding TCP ACK packets from the queue by controlling the duration of at least one of the first time interval or the second time interval.

[0033] In some embodiments, the method further includes: checking the packet descriptor of a third TCP ACK packet of TCP packets in the queue; identifying a third TCP ACK generation count and a third flow identifier corresponding to the third TCP ACK packet included in the packet descriptor of the third TCP ACK packet; determining that the third TCP ACK generation count is set to an invalid value; and in response to the determination, aborting further processing of the third TCP ACK packet. In some embodiments, determining that the TCP ACK generation count of the third TCP packet is set to an invalid value includes determining one of the following: the TCP ACK generation count of the third TCP packet is empty; or the TCP ACK generation count of the third TCP packet is set to a predetermined invalid value.

[0034] In some specific embodiments, the method further includes: checking a packet descriptor of a third TCP ACK packet in a queue of TCP ACK packets; identifying a third TCP ACK generation count and a third flow identifier corresponding to the third TCP ACK packet included in the packet descriptor of the third TCP ACK packet; determining that the third flow identifier is set to an invalid value; and in response to this determination, aborting further processing of the third TCP ACK packet. In some specific embodiments, determining that the third flow identifier of the third TCP ACK packet is set to an invalid value includes determining one of the following: the flow identifier is not assigned to the third TCP ACK packet; or the flow identifier of the third TCP packet is set to a predetermined invalid value.

[0035] In some specific embodiments, the method further includes: checking a packet descriptor of a fourth TCP packet in a queue of TCP packets; identifying a fourth TCP ACK generation count and a fourth flow identifier corresponding to the fourth TCP ACK packet included in the packet descriptor of the fourth TCP ACK packet; determining that the fourth TCP ACK generation count and the fourth flow identifier are valid; determining (i) that the fourth flow identifier is the same as the first flow identifier in the first entry in the queue, and (ii) that the fourth TCP ACK generation count is different from the first TCP ACK generation count in the first entry in the queue; and in response to this determination, updating the first entry by replacing the first TCP ACK generation count stored in the second position field of the first entry with the fourth TCP ACK generation count.

[0036] In some specific embodiments, the method further includes: checking a packet descriptor of a fifth TCP packet in a queue of TCP packets; identifying a fifth TCP ACK generation count and a fifth flow identifier corresponding to the fifth TCP ACK packet included in the packet descriptor of the third TCP ACK packet; determining that the fifth TCP ACK generation count and the fifth flow identifier are valid; determining that the data structure does not include an entry corresponding to the fifth flow identifier; and in response to this determination, creating a third entry in the data structure and storing the fifth flow identifier and the fifth TCP ACK generation count in the third entry.

[0037] In some specific embodiments, the received TCP packet includes one or more of application control information and application data.

[0038] In some specific embodiments, the queue includes one or more additional TCP ACK packets, and the one or more additional TCP ACK packets have packet descriptors without a TCP ACK generation count field.

[0039] In some specific implementations, one or more entries in the data structure include a hash value representing a flow identifier, and determining that the data structure includes a first entry storing a first TCP ACK generation count and a first flow identifier and the first TCP ACK generation count includes: performing a hash function on the first flow identifier to obtain a first hash value, the first hash value being represented by fewer bits than the number of bits used to represent the first flow identifier; comparing the first hash value with the hash values included in the one or more entries in the data structure to determine whether there is a match; and in response to the comparison, determining that the hash value included in the first entry matches the first hash value.

[0040] In some specific implementations, one or more entries in the data structure include a hash value representing a flow identifier, and determining that the data structure includes a first entry storing a first TCP ACK generation count and a first flow identifier and the first TCP ACK generation count includes: performing a hash function on the first flow identifier to obtain a first hash value, the first hash value being represented by fewer bits than the number of bits used to represent the first flow identifier; comparing the first hash value with the hash values included in the one or more entries in the data structure to determine whether there is a match; and in response to the comparison, determining that the hash value included in the first entry matches the first hash value.

[0041] In another general aspect, a method performed by a TCP application processor in a client device in a wireless network for TCP ACK packet transmission includes: generating TCP ACK packets for sending to a remote device in the wireless network, each TCP ACK packet including a packet descriptor; and storing in the respective packet descriptors of at least a subset of the TCP ACK packets (i) a flow identifier indicating a TCP flow associated with the packet and (ii) a TCP ACK generation count; and forwarding the TCP ACK packets including the subset of TCP ACK packets to a baseband processor included in the client device.

[0042] Particular specific implementations include one or more of the following features. In some specific implementations, the application processor assigns a first ACK generation count value to a plurality of TCP ACK packets generated in a first time interval, and assigns a second ACK generation count value to a plurality of TCP ACK packets generated in a second time interval different from the first time interval, the first ACK generation count value being different from the second ACK generation count value. In some specific implementations, the application processor controls the number of TCP ACK packets assigned the first ACK generation count value or the second ACK generation count value by controlling the duration of at least one of the first time interval or the second time interval.

[0043] In some specific embodiments, the method further includes: determining, by an application processor, that the first TCP ACK packet includes at least one of additional header information or TCP payload information; and in response to the determination, setting an ACK generation count value in a packet descriptor of the first TCP ACK packet to a predetermined invalid value.

[0044] In some specific embodiments, the method further includes: determining, by an application processor, that the first TCP ACK packet includes at least one of additional header information or TCP payload information; and in response to the determination, forwarding the first TCP ACK packet to a baseband processor in the absence of a TCP ACK generation count value.

[0045] In some specific embodiments, the method further includes: determining, by an application processor, that the first TCP ACK packet includes at least one of additional header information or TCP payload information; and in response to the determination, setting a flow identifier in a packet descriptor of the first TCP ACK packet to a predetermined invalid value.

[0046] In some specific embodiments, the method further includes: determining, by an application processor, that the first TCP ACK packet includes at least one of additional header information or TCP payload information; and in response to the determination, forwarding the first TCP ACK packet to a baseband processor in the absence of a flow identifier.

[0047] Eliminating redundant TCP ACK packets in the UL as disclosed in the specific embodiments results in: less packet processing and power consumption savings in subsequent processing entities; a reduction in the amount of data to be transmitted, or the saved bandwidth is reused by other packet data services; a reduction in the latency of all subsequent UL packets (after the discarded packet); or a reduction in TCP RTT (round-trip time), which ultimately leads to a faster increase in TCP throughput and thus higher end-to-end throughput. Compared with conventional TCP methods, this can lead to a faster and more efficient packet data transmission method.

[0048] Specific embodiments of the above technologies include methods, apparatuses, and computer program products. One such computer program product is suitably embodied in one or more non-transitory machine-readable media that store instructions which, when executed by one or more processors, are configured to cause the one or more processors to perform the above actions. One such apparatus includes processing circuitry for executing instructions to perform the above actions. These instructions may be stored in a memory coupled to the apparatus. In some specific embodiments, the apparatus is a baseband processor for a client device (e.g., a UE) in a wireless network. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] Figure 1Shows a block diagram of a communication system according to some disclosed embodiments.

[0050] Figure 2 Shows the optimization of TCP ACK packets according to some disclosed embodiments.

[0051] Figure 3 Shows a flowchart of an exemplary process for managing TCP ACK packets according to some disclosed embodiments.

[0052] Figure 4 Shows the optimization of TCP ACK packet flows according to some disclosed embodiments.

[0053] Figure 5 Shows a flowchart of a second exemplary process for managing TCP ACK packets according to some disclosed embodiments.

[0054] Figure 6 Shows a data structure for managing TCP ACK packets according to some disclosed embodiments.

[0055] Figure 7 Shows a second data structure for managing TCP ACK packets by reordering according to some disclosed embodiments.

[0056] Figures 8A to 8G Each shows exemplary conditions for enabling or disabling TCP ACK optimization according to some disclosed embodiments.

[0057] Figure 9 Shows a block diagram of a communication device according to some disclosed embodiments.

[0058] Figure 10 Shows a block diagram of a communication device according to some disclosed embodiments.

[0059] Figure 11 Shows a 3GPP protocol stack according to some disclosed embodiments.

[0060] Figure 12 Shows a block diagram of a communication system according to some disclosed embodiments. Detailed Description

[0061] TCP is a network communication protocol that enables reliable data exchange between two host devices (e.g., a client device and a server such as an AS) over a communication network (e.g., a 3GPP wireless communication network). TCP is a connection-oriented protocol; the hardware and software operations performed by the host devices implementing the TCP protocol (commonly referred to as TCP in this disclosure) are responsible for establishing a connection with another host device and maintaining the connection for data transfer. In the following description, without loss of generality, the disclosed TCP improvements are described with respect to a client device (e.g., a UE) and a server (e.g., an AS) communicating over a 3GPP wireless network. It should be understood that the disclosed techniques are equally applicable to TCP connections between other types of host devices or in other types of networks or both.

[0062] TCP uses a mechanism called the three-way handshake to establish a connection between a server and a client device. This mechanism is a three-step process that requires both the client device and the server to exchange synchronization and acknowledgment packets before actual data packets can be exchanged. In the three-way handshake, a synchronization (SYN) message is used to initiate and establish the connection. The SYN message also helps to synchronize the sequence numbers between the devices. As an illustrative example, the client device requests a connection by sending a SYN message to the server. The server acknowledges by sending a SYN-ACK (synchronization-acknowledgment) message back to the client. The client device responds with an ACK message, and the connection is established.

[0063] When the server sends a TCP data packet (also simply referred to as a data packet) to the client device, the client device sends a TCP ACK packet indicating receipt of the TCP data packet. The client device selects an initial sequence number set in the first SYN packet. The server also selects its own initial sequence number set in the SYN ACK packet. Each side acknowledges the other's sequence number by incrementing the sequence number, which is the acknowledgment number. The use of sequence numbers and acknowledgment numbers allows both sides to detect missing, lost, or out-of-order data packets. For example, when the server sends a TCP data packet to the client device, the client device acknowledges the TCP data packet by responding with a TCP ACK packet.

[0064] In some specific implementations, the client device generates a TCP ACK in response to receiving a TCP data packet and temporarily stores the TCP ACK in an output queue maintained by the client device until the TCP ACK can be transmitted to the server. One or more additional TCP ACK packets may also be waiting to be sent to the server. Sometimes, duplicate TCP ACKs are added to the output queue.

[0065] In some specific implementations, the available downlink (DL) bandwidth may be greater than the available uplink (UL) bandwidth. In some cases, constraints in the available UL bandwidth prohibit transmitting TCP ACK data packets at the same rate as receiving TCP data packets from the server. During periods of UL latency, a large number of TCP ACKs may be stored in the output queue. As a result, the transmission of data packets from the server may stop due to the delay in TCP ACK packet transmission, leading to throughput degradation.

[0066] The specific implementations disclosed herein provide optimization of the uplink TCP flow by discarding duplicate TCP ACK packets in the output queue of the client device. As described in detail in the following sections, in some specific implementations, the BB circuit (also referred to as the baseband unit, BBU) in the client device is configured to discard one or more of the older TCP ACK packets pending processing in the output queue in response to detecting a newer duplicate TCP ACK packet. In some other specific implementations, these operations are configured to discard one or more of the newer TCP ACK packets pending processing in the output queue in response to detecting an older duplicate TCP ACK packet. In the following sections, these techniques are described with respect to specific implementations in which one or more older duplicate TCP ACK packets are discarded. However, it should be understood that these techniques are equally applicable to specific implementations in which one or more newer duplicate TCP ACK packets are discarded.

[0067] The client device uses a counter called the TCP ACK generation count to track TCP ACK packets that are potential duplicates. In some specific implementations, the process implementing the TCP application (also referred to as the application processor, AP) in the client device generates a TCP ACK generation count value (also referred to as the ACK Gen Count), and stamps the packet with the counter value before the TCP ACK packet is sent to the BBU circuit for uplink transmission. In some specific implementations, the AP increments the counter every n milliseconds (where n is a positive integer). The AP stamps the TCP ACK data packets with the same counter value generated for a specific time interval within one n - millisecond interval. In some specific implementations, n is set to a predetermined value, e.g., as a design parameter. In other specific implementations, the TCP AP 105 is configured to dynamically modify the value of n at runtime, e.g., based on the current throughput.

[0068] When receiving a TCP ACK packet from the AP, the BBU temporarily stores the packet in an output queue until UL transmission. In some specific implementations, the BBU uses a counter value to determine whether some TCP ACK packets in the output queue are redundant and disposable. For example, this may occur during UL transmission latency when the queue length grows. By using the counter value, the BBU ensures that at least one TCP ACK packet is sent to the server in the UL direction over the 3GPP network within a certain time period (e.g., n milliseconds), such that the TCP connection remains stable even in the case of discarding some TCP ACK packets. The server starts retransmitting data packets after receiving the first duplicate TCP ACK packet.

[0069] Figure 1 An exemplary wireless communication system 100 implementing the disclosed TCP ACK management technique is shown. System 100 includes a client device 102, an access point (AP) 104, a radio access network (RAN) 112, a core network (CN) 108, and an application server (AS) 110.

[0070] For purposes of convenience and not limitation, system 100 is described in the context of the Long-Term Evolution (LTE) and Fifth Generation (5G) New Radio (NR) communication standards as defined by 3GPP technical specifications. More specifically, wireless communication system 100 is described in the context of a non-standalone (NSA) network that combines both LTE and NR (e.g., an Evolved Universal Terrestrial Radio Access (E-UTRA)-NR Dual Connectivity (EN-DC) network and an NE-DC network). However, system 100 may also be a standalone (SA) network that combines only NR. System 100 may also implement other types of communication standards, including future 3GPP systems (e.g., Sixth Generation (6G) systems), IEEE 802.16 protocols (e.g., WMAN, WiMAX, etc.), and so on.

[0071] In some specific implementations, the client device 102 is a UE (and may alternatively be referred to herein as UE 102). Although a single client device 102 is shown, it should be understood that the system 100 may include multiple client devices, and the disclosed techniques are equally applicable to these client devices. The client device or UE 102 can be any suitable type of mobile or non-mobile computing device, such as a consumer electronic device, a cellular phone, a smart phone, a feature phone, a tablet computer, a wearable computing device, a personal digital assistant (PDA), a pager, a wireless handheld device, a desktop computer, a laptop computer, an in-vehicle infotainment (IVI), an in-vehicle entertainment (ICE) device, an instrument cluster (IC), a head-up display (HUD) device, an on-board diagnostic (OBD) device, an on-board mobile equipment (DME), a mobile data terminal (MDT), an electronic engine management system (EEMS), an electronic / engine control unit (ECU), an electronic / engine control module (ECM), an embedded system, a microcontroller, a control module, an engine management system (EMS), a networked or "smart" home appliance, a machine type communication (MTC) device, a machine-to-machine (M2M) device, an Internet of Things (IoT) device, or a combination thereof, etc.

[0072] In some specific implementations, the client device 102 is an Internet of Things (IoT) client device, which may include a network access layer designed for low-power IoT applications that utilize short-term client device connections. The IoT client device may utilize technologies such as machine-to-machine (M2M) communication or machine type communication (MTC) to exchange data with an MTC server or device using, for example, a public land mobile network (PLMN), proximity services (ProSe), device-to-device (D2D) communication, a sensor network, an IoT network, or a combination thereof, etc. The M2M or MTC data exchange can be machine-initiated data exchange. The IoT network describes interconnected IoT client devices, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure) with short-term connections. The IoT client device may execute background applications (e.g., keep-alive messages, status updates, etc.) to facilitate the connection of the IoT network.

[0073] As shown in the figure, the client device 102 includes a baseband (BB) circuit 103 (also referred to as BBU 103), a TCP application processor (AP) 105, a database 106, and an output queue 107. In some specific embodiments, the client device 102 includes one or more processors configured to execute instructions stored in a memory (e.g., a storage memory) coupled to the client device to perform various functions, such as the programs, methods, and functions discussed herein. These functions include operations performed by the baseband circuit 103 and the TCP AP 105, which are described below.

[0074] The network 108 can be embodied as any network that can support communication between two networked devices, such as between the client device 102 and the application server 110(a). The network 108 can be embodied, for example, as a wired network (e.g., an Ethernet network, a wired local area network, a fiber optic network, a wired network maintained by a telephone / cable service provider, some combination thereof, etc.), a wireless network (e.g., a cellular network, a wireless local area network, a wireless wide area network, some combination thereof, etc.), or a combination thereof, and in some exemplary specific embodiments can include the Internet.

[0075] In some specific embodiments, the client device 102 is connected to an access network (AN) or a radio access network (RAN) 112. In some examples, the RAN 112 can be a next-generation RAN (NG RAN), an evolved UMTS terrestrial radio access network (E-UTRAN), or a legacy RAN, such as a UMTS terrestrial radio access network (UTRAN) or a GSM EDGE radio access network (GERAN). As used herein, terms such as "NG RAN" can refer to a RAN operating in a 5G NR system 100, while terms such as "E-UTRAN" can refer to a RAN operating in an LTE or 4G system 100. The client device 102 utilizes connections (or channels) 109, respectively, each connection (or channel) including a physical communication interface or layer.

[0076] In this example, the connection 109 is shown as an air interface that enables a communication coupling and can be consistent with a cellular communication protocol, such as the GSM protocol, a CDMA network protocol, a PTT protocol, a POC protocol, the UMTS protocol, the 3GPP LTE protocol, the advanced long term evolution (LTE-A) protocol, LTE-based unlicensed spectrum access (LTE-U), the 5G protocol, the NR protocol, NR-based unlicensed spectrum access (NR-U) protocol, and / or any other suitable wireless communication protocol.

[0077] As shown in the figure, client device 102 is connected to an access point (AP) 104 (also referred to as a "WLAN node", "WLAN", "WLAN terminal", "WT", etc.) via connection 107. Connection 107 may include a local wireless connection, such as a connection consistent with any IEEE 802.11 protocol, where the AP will include a Wi-Fi router. In various embodiments, client device 102, RAN 112, and AP 104 may be configured to operate using LWA and / or LWIP. LWA operations may involve configuring client device 102 in the RRC_CONNECTED state by RAN nodes 112a-b to utilize the radio resources of LTE and WLAN. LWIP operations may involve client device 102 using the WLAN radio resources (e.g., connection 107) via an IPsec protocol tunnel to authenticate and encrypt packets (e.g., IP packets) sent over connection 107. IPsec tunneling may include encapsulating the entire original IP packet and adding a new packet header to protect the original header of the IP packet.

[0078] RAN 112 may include one or more AN nodes or RAN nodes 112a and 112b (collectively referred to as "RAN nodes 112a" or "RAN nodes 112b" or "RAN nodes 112a-b") enabling connection 109. As used herein, terms such as "access node", "access point", etc. may describe equipment that provides radio baseband functionality for data and / or voice connections between a network and one or more users. These access nodes may be referred to as BS, gNB, RAN node, eNB, NodeB, RSU, TRxP, or TRP, etc., and may include a terrestrial station (e.g., a land access point) or a satellite station providing coverage within a geographical area (e.g., a cell). As used herein, terms such as "NG RAN node" etc. may refer to RAN node 112 (e.g., gNB) operating in an NR or 5G system 100, while terms such as "E-UTRAN node" etc. may refer to RAN node 112 (e.g., eNB) operating in an LTE or 4G system. According to various embodiments, RAN nodes 112a-b may be implemented as one or more of dedicated physical devices such as macrocell base stations and / or low-power (LP) base stations for providing femtocells, picocells, or other similar cells with a smaller coverage area, a smaller user capacity, or a higher bandwidth compared to macrocells.

[0079] In some specific implementations, all or some of the RAN nodes 112a-b can be implemented as one or more software entities running on a server computer and as part of a virtual network that can be referred to as a Cloud RAN (CRAN) and / or a virtual baseband unit pool (vBBUP). In these specific implementations, the CRAN or vBBUP can implement RAN function partitioning, such as PDCP partitioning, where the RRC and PDCP layers are operated by the CRAN / vBBUP, while the other L2 protocol entities are operated by the respective RAN nodes 112a-b; MAC / PHY partitioning, where the RRC, PDCP, RLC, and MAC layers are operated by the CRAN / vBBUP, while the PHY layer is operated by the respective RAN nodes 112a-b; or "lower PHY" partitioning, where the RRC, PDCP, RLC, MAC layers, and the upper part of the PHY layer are operated by the CRAN / vBBUP, while the lower part of the PHY layer is operated by the respective RAN nodes 112a-b. This virtualization framework allows the idle processor cores of the RAN nodes 112a-b to execute other virtualized applications. In some specific implementations, each of the RAN nodes 112a-b can represent a respective gNB-DU connected to the gNB-CU via a respective F1 interface (not shown). In these specific implementations, the gNB-DU can include one or more remote radio heads or RFEMs, and the gNB-CU can be operated by a server (not shown) located in the RAN 112 or by a pool of servers in a manner similar to the CRAN / vBBUP. In addition or alternatively, one or more of the RAN nodes 112a-b can be a next-generation eNB (ng-eNB), which is a RAN node that provides E-UTRA user plane and control plane protocol terminations to the client device 102 and is connected to the 5GC via an NG interface (discussed below).

[0080] In a vehicle-to-everything (V2X) scenario, one or more of the RAN nodes 112a-b can be or act as a roadside unit (RSU). The term "roadside unit" or "RSU" can refer to any traffic infrastructure entity for V2X communication. The RSU can be implemented in or by a suitable RAN node or a stationary (or relatively stationary) UE, where the RSU implemented in or by a UE can be referred to as a "UE-type RSU", the RSU implemented in or by an eNB can be referred to as an "eNB-type RSU", the RSU implemented in or by a gNB can be referred to as a "gNB-type RSU", etc. In one example, the RSU is a computing device coupled to a radio frequency circuit located on the roadside, and the computing device provides connectivity support to passing vehicle client devices. The RSU can also include an internal data storage circuit for storing intersection map geometries, traffic statistics, media, and applications / software for sensing and controlling ongoing vehicle and pedestrian traffic. The RSU can operate on the 5.9 GHz direct short-range communication (DSRC) frequency band to provide extremely low-latency communication required for high-speed events, such as collision avoidance, traffic warnings, etc. In addition or alternatively, the RSU can operate on the cellular V2X frequency band to provide the aforementioned low-latency communication and other cellular communication services. In addition or alternatively, the RSU can operate as a Wi-Fi hotspot (2.4 GHz frequency band) and / or provide a connection to one or more cellular networks to provide uplink and downlink communication. Some or all of the radio frequency circuits in the computing device and the RSU can be encapsulated in a weather-resistant enclosure suitable for outdoor installation and can include a network interface controller to provide a wired connection (e.g., Ethernet) to a traffic signal controller and / or a backhaul network.

[0081] Any one of the RAN nodes 112a-b can be the endpoint of an air interface protocol and can be the first point of contact for the client device 102. In some specific implementations, any one of the RAN nodes 112a-b can perform various logical functions of the RAN 112a-b, including but not limited to radio network controller (RNC) functions, such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management.

[0082] In a particular implementation, the client devices 102 may be configured to communicate with each other or with any one of the RAN nodes 112a-b over a multi-carrier communication channel using OFDM communication signals according to various communication techniques, such as but not limited to OFDMA communication techniques (e.g., for downlink communication) or SC-FDMA communication techniques (e.g., for uplink and ProSe or sidelink communication), but the scope of the particular implementation is not limited in this regard. The OFDM signal may include a plurality of orthogonal sub-carriers.

[0083] In some particular implementations, a downlink resource grid may be used for downlink transmission from any one of the RAN nodes 112a-b to the client devices 102, and uplink transmission may utilize similar techniques. The grid may be a time-frequency grid, referred to as a resource grid or a time-frequency resource grid, which is the physical resource in the downlink in each time slot. For OFDM systems, such time-frequency plane representations are a common practice, which makes radio resource allocation intuitive. Each column and each row of the resource grid correspond to an OFDM symbol and an OFDM sub-carrier, respectively. The duration of the resource grid in the time domain corresponds to one time slot in the radio frame. The smallest time-frequency unit in the resource grid is represented as a resource element. Each resource grid includes a plurality of resource blocks, which describe the mapping of certain physical channels to resource elements. Each resource block includes a set of resource elements; in the frequency domain, this may represent the smallest amount of resources that can be currently allocated. Such resource blocks are used to transmit several different physical downlink channels.

[0084] According to various particular implementations, the client devices 102 and the RAN nodes 112a-b transmit data (e.g., transmit data and receive data) over a licensed medium (also referred to as "licensed spectrum" and / or "licensed band") and an unlicensed shared medium (also referred to as "unlicensed spectrum" and / or "unlicensed band"). The licensed spectrum may include channels operating in a frequency range of approximately 400 MHz to approximately 3.8 GHz, while the unlicensed spectrum may include the 5 GHz band. NR in the unlicensed spectrum may be referred to as NR-U, and LTE in the unlicensed spectrum may be referred to as LTE-U, Licensed-Assisted Access (LAA), or MulteFire.

[0085] To operate in unlicensed spectrum, client device 102 and RAN nodes 112a - b may operate using LAA, eLAA, and / or feLAA mechanisms. In these embodiments, client device 102 and RAN nodes 112a - b may perform one or more known medium sensing operations and / or carrier sensing operations to determine whether one or more channels in the unlicensed spectrum are unavailable or otherwise occupied before transmitting in the unlicensed spectrum. The medium / carrier sensing operations may be performed according to the listen - before - talk (LBT) protocol.

[0086] LBT is a mechanism by which a device (e.g., client device 102, RAN nodes 112a - b, etc.) senses the medium (e.g., a channel or carrier frequency) and transmits when the medium is sensed to be idle (or when a particular channel in the medium is sensed to be unoccupied). The medium sensing operation may include CCA, which uses at least ED to determine whether there are other signals on the channel to determine whether the channel is occupied or idle. This LBT mechanism allows cellular / LAA networks to coexist with existing systems in the unlicensed spectrum and with other LAA networks. ED may include sensing RF energy on the expected transmission band over a period of time and comparing the sensed RF energy with a predefined or configured threshold.

[0087] Typically, existing systems in the 5GHz band are WLANs based on IEEE 802.11 technology. WLANs employ a contention - based channel access mechanism called CSMA / CA. Here, when a WLAN node (e.g., a mobile station (MS) such as client device 102, AP 104, etc.) intends to transmit, the WLAN node may first perform CCA before transmission. Additionally, in the case where more than one WLAN node senses the channel as idle and transmits simultaneously, a backoff mechanism is used to avoid collisions. The backoff mechanism may be a counter randomly introduced within the CWS, which increases exponentially in the event of a collision and is reset to a minimum value upon successful transmission. The LBT mechanism designed for LAA is somewhat similar to WLAN's CSMA / CA. In some embodiments, the LBT procedure for DL or UL transmission bursts (including PDSCH or PUSCH transmissions respectively) may have a variable - length LAA contention window between X and Y ECCA slots, where X and Y are the minimum and maximum values of the LAA's CWS. In one example, the minimum CWS for LAA transmission may be 9 microseconds (μs); however, the size of the CWS and the MCOT (e.g., transmission burst) may be based on government regulatory requirements.

[0088] The LAA mechanism is built on the CA technology of the LTE-Advanced system. In CA, each aggregated carrier is called a CC. A CC can have a bandwidth of 1.4 MHz, 3 MHz, 5 MHz, 10 MHz, 15 MHz, or 20 MHz, and up to five CCs can be aggregated, so the maximum aggregated bandwidth is 100 MHz. In an FDD system, for DL and UL, the number of aggregated carriers can be different, where the number of UL CCs is equal to or lower than the number of DL component carriers. In some cases, each CC can have a different bandwidth from other CCs. In a TDD system, the number of CCs and the bandwidth of each CC are usually the same for DL and UL.

[0089] CA also includes individual serving cells to provide individual CCs. The coverage of serving cells can be different. For example, because CCs on different frequency bands will experience different path losses. The primary serving cell or PCell can provide PCC for both UL and DL, and can handle activities related to RRC and NAS. Other serving cells are called SCell, and each SCell can provide a separate SCC for both UL and DL. SCCs can be added and removed as needed, while changing the PCC may require the client device 102 to undergo a handover. In LAA, eLAA, and feLAA, some or all of the SCell can operate in the unlicensed spectrum (referred to as "LAA SCell"), and the LAA SCell is assisted by the PCell operating in the licensed spectrum. When the UE is configured with more than one LAA SCell, the UE can receive UL authorization on the configured LAA SCell, thereby indicating different PUSCH start positions within the same subframe.

[0090] The PDSCH carries user data and higher layer signaling to the client device 102. Among other information, the PDCCH carries information about the transmission format and resource allocation related to the PDSCH channel. The PDSCH can also notify the client device 102 of the transmission format, resource allocation, and HARQ information related to the uplink shared channel. Generally, downlink scheduling (allocating control and shared channel resource blocks to the client devices 102 within the cell) can be performed at any one of the RAN nodes 112a - b based on the channel quality information fed back from any one of the client devices in the client device 102. Downlink resource allocation information can be sent on the PDCCH for each client device in the client device 102 (e.g., allocated to).

[0091] The PDCCH uses CCEs to transmit control information. Before being mapped to resource elements, the PDCCH complex-valued symbols can first be organized into quadruples, and then a sub-block interleaver can be used to permute them for rate matching. One or more of these CCEs can be used to transmit each PDCCH, where each CCE can correspond to nine sets each having four physical resource elements, called REGs. Four quadrature phase shift keying (QPSK) symbols can be mapped to each REG. Depending on the size of the DCI and the channel conditions, one or more CCEs can be used to transmit the PDCCH. There can be four or more different PDCCH formats in LTE with different numbers of CCEs (e.g., aggregation levels, L = 1, 2, 4, or 8).

[0092] Some specific implementations can use the concept of resource allocation for control channel information, which is an extension of the above concept. For example, some specific implementations can utilize the EPDCCH that uses PDSCH resources for control information transmission. One or more ECCEs can be used to transmit the EPDCCH. Similar to the above, each ECCE can correspond to nine sets each having four physical resource elements, called EREGs. In some cases, the ECCE can have other numbers of EREGs.

[0093] The RAN nodes 112a - b can be configured to communicate with each other via the interface 116. In a specific implementation where the system 100 is an LTE system, the interface 116 can be the X2 interface 116. The X2 interface can be defined between two or more RAN nodes 112a - b (e.g., two or more eNBs, etc.) connected to the EPC 108, and / or between two eNBs connected to the EPC 108. In some specific implementations, the X2 interface can include the X2 user plane interface (X2 - U) and the X2 control plane interface (X2 - C). The X2 - U provides a flow control mechanism for user packets transmitted through the X2 interface and can be used to convey information about the delivery of user data between eNBs. For example, the X2 - U can provide specific sequence number information about user data transmitted from the MeNB to the SeNB; information about the successful in - order delivery of PDCP PDUs from the SeNB to the client device 102 for user data; information about PDCP PDUs not delivered to the client device 102; information about the current minimum desired buffer size at the SeNB for transmitting user data to the UE; and so on. The X2 - C can provide access mobility functions within LTE, including context transfer from the source eNB to the target eNB, user plane transmission control, etc.; load management functions; and inter - cell interference coordination functions.

[0094] In a specific implementation where the system 100 is a 5G or NR system, the interface 116 can be the Xn interface 116. The Xn interface is defined between two or more RAN nodes 112a-b (e.g., two or more gNBs, etc.) connected to the 5GC 108, between a RAN node 112a-b (e.g., gNB) connected to the 5GC 108 and an eNB, and / or between two eNBs connected to the 5GC 108. In some specific implementations, the Xn interface may include an Xn user plane (Xn-U) interface and an Xn control plane (Xn-C) interface. The Xn-U can provide non-guaranteed delivery of user plane PDUs and support / provide data forwarding and flow control functions. The Xn-C can provide management and error handling functions for managing the functions of the Xn-C interface; mobility support for client devices 102 in the connected mode (e.g., CM-CONNECTED), including functions for managing UE mobility in the connected mode between one or more RAN nodes 112a-b. The mobility support may include context transfer from an old (source) serving RAN node 112a-b to a new (target) serving RAN node 112a-b; and control of the user plane tunnel between the old (source) serving RAN node 112a-b and the new (target) serving RAN node 112a-b. The protocol stack of the Xn-U may include a transport network layer built on the Internet Protocol (IP) transport layer, and a GTP-U layer for carrying user plane PDUs on top of the UDP and / or IP layer. The Xn-C protocol stack may include an application layer signaling protocol (referred to as the Xn application protocol (Xn-AP)) and a transport network layer built on SCTP. SCTP can be on top of the IP layer and can provide guaranteed delivery of application layer messages. In the transport IP layer, point-to-point transmission is used to deliver signaling PDUs. In other specific implementations, the Xn-U protocol stack and / or the Xn-C protocol stack may be the same as or similar to the user plane and / or control plane protocol stacks shown and described herein.

[0095] RAN 112 is shown as communicatively coupled to a core network, and in this particular implementation, communicatively coupled to core network (CN) 108. CN 108 may include a plurality of network elements 122 configured to provide various data and telecommunications services to customers / subscribers (e.g., users of client device 102) connected to CN 108 via RAN 112. Components of CN 108 may be implemented in one physical node or separate physical nodes, including components for reading and executing instructions from a machine-readable or computer-readable medium (e.g., non-transitory machine-readable storage medium). In some particular implementations, NFV may be used to virtualize any one or all of the above network node functions via executable instructions stored in one or more computer-readable storage media (described in further detail below). A logical instantiation of CN 108 may be referred to as a network slice, and a logical instantiation of a portion of CN 108 may be referred to as a network sub-slice. The NFV architecture and infrastructure may be used to virtualize one or more network functions onto physical resources including a combination of industry-standard server hardware, storage hardware, or switches (alternatively performed by proprietary hardware). In other words, an NFV system may be used to perform virtual or reconfigurable implementations of one or more EPC components / functions.

[0096] In some particular implementations, application server (AS) 110 is a network server of a core network (e.g., UMTS PS domain, LTE PS data service, etc.) using IP bearer resources. AS 110 may also be configured to support one or more communication services (e.g., VoIP sessions, PTT sessions, group communication sessions, social network services, etc.) for client device 102 via EPC 108. As described in the following sections, in some particular implementations, client device 102 establishes a TCP session with AS 110 and uses the optimized TCP protocol disclosed in this specification. In such particular implementations, TCP AP 107 in client device 102 provides a TCP-ACK generation count so that BB circuit 103 can track TCP ACK packets that are duplicates. TCP AP 107 generates a TCP-ACK generation count value (ack_gen_count) for TCP ACK packets and provides the counter value to BB circuit 103. TCP AP 107 also increments the counter every n milliseconds.

[0097] In a particular implementation, CN 108 can be a 5GC (referred to as "5GC 108", etc.), and the RAN 112 can be connected to the CN 108 via the NG interface 113. In a particular implementation, the NG interface 113 can be divided into two parts: the NG user plane (NG-U) interface 114, which carries traffic data between the RAN nodes 112a-b and the UPF; and the S1 control plane (NG-C) interface 115, which is a signaling interface between the RAN nodes 112a-b and the AMF.

[0098] In a particular implementation, CN 108 can be a 5G CN (referred to as "5GC 108", etc.), while in other particular implementations, CN 108 can be an EPC. In the case where CN 108 is an EPC (referred to as "EPC 108", etc.), the RAN 112 can be connected to the CN 108 via the S1 interface 113. In a particular implementation, the S1 interface 113 can be divided into two parts: the S1 user plane (S1-U) interface 114, which carries traffic data between the RAN nodes 112a-b and the S-GW; and the S1-MME interface 115, which is a signaling interface between the RAN nodes 112a-b and the MME.

[0099] In some particular implementations, the client device 102 receives data for a communication session from the AS 110 via the CN 108 and the AN 112 on a downlink channel. The AS 110 sends data using TCP, as TCP data packets. The client device 102 confirms successful receipt of the TCP data packets by sending an acknowledgement to the AS 110 (e.g., a TCP ACK packet). The TCP data packets can be identified using sequence numbers. The TCP ACK sent by the client device 102 indicates one or more successfully received data packets by including the sequence number of the most recently received TCP data packet in a contiguous sequence of sequence numbers, i.e., there are no missing sequence numbers due to non-receipt of the corresponding TCP data packets.

[0100] As previously noted, in some particular implementations, the client device 102 includes a BB circuit 103. The BB circuit 103 can be embodied as a hardware circuit, or a computer program product having computer-readable program instructions, or some combination thereof, which are stored on a computer-readable medium (e.g., a storage memory) and executed by a processing device (e.g., the baseband circuit 1010 as described Figure 10 previously). As previously described, the client device 102 is configured to generate TCP ACK packets and add the TCP ACK packets to an output queue, which is maintained by the client device 102 for pending TCP packets waiting for an uplink transmission (e.g., waiting to go up to the AN 112, waiting to be sent to the AS 110).

[0101] In some specific embodiments, the BB circuit 103 tracks one or more TCP connections or TCP packet flows and maintains detailed information for each tracked TCP connection or flow. The BB circuit 103 tracks the most recent TCP ACK information and the timestamp when the TCP ACK is received, the sequence number of the most recent data packet, the timestamp when these data packets are received, and the number of unacknowledged data packets. In some specific embodiments, the BB circuit 103 stores this information in a memory coupled to the client device 102, for example, stored in the database 106.

[0102] The TCP packets sent by the AS 110 are associated with one or more different communication sessions. In some specific embodiments, the TCP AP 105 uses different TCP flow identifiers (referred to as flow IDs) to identify different communication sessions. In some specific embodiments, the flow ID corresponds to a 5-tuple (source IP address, source TCP / UDP port, destination IP address, destination TCP / UDP port, and IP protocol) or a 3-tuple (source IP address, destination IP address, IP protocol). The flow ID uniquely identifies the flow associated with the TCP data packet and the corresponding TCP ACK packet. The TCP AP 105 determines the corresponding flow ID for each TCP data packet received at the client device 102. In some specific embodiments, the TCP AP 105 provides different TCP ACK generation count values to be associated with the TCP ACK packets of different flows. In other specific embodiments, the TCP AP 105 provides the same TCP ACK generation count value to be associated with the TCP ACK packets of different flows. In the packet descriptor prepared for the generated TCP ACK packet, the TCP AP 105 includes the flow ID determined for the corresponding TCP data packet and the TCP ACK generation count for a specific flow in the current time interval. The packet descriptor is stored in the database 106. Information including but not limited to the total packet count, the total byte count, and the time when the packet was last seen is maintained for each flow in the flow.

[0103] In some specific embodiments, the TCP AP 105 does not provide the flow ID for some TCP packets. This may be, for example, due to tethered external traffic, or because the packet does not contain all the fields required to generate a flow ID. In such cases, the BB circuit 103 treats these TCP ACK packets as invalid for traffic reduction and ignores these packets when checking for redundant packets in the inspection output queue 107.

[0104] In some specific embodiments, the BB circuit 103, for example, uses a timer to track the period that a TCP ACK packet waits in the output queue before UL transmission. If the value of the timer exceeds a predetermined value, indicating that the period for which the TCP ACK packet is queued is longer than a specified threshold (e.g., due to congestion in the uplink channel), then the BB circuit 103 examines the TCP ACK packets in the output queue 107 to determine whether some TCP ACK packets can be discarded. The threshold can be set to a predetermined period. In some specific embodiments, the threshold is set to n milliseconds, for example, synchronized with the time interval at which the TCP AP 105 updates the ACK Gen Count value. In such specific embodiments, using the ACK Gen Count value ensures that at least one TCP ACK packet of a flow within a specific period (e.g., n milliseconds (ms)) is transmitted in the UL direction to the network 108, while the remaining TCP ACK packets of the flow within the specific period are discarded. In this way, the BB circuit 103 reduces network congestion by removing redundant TCP ACK packets while maintaining the stability of the TCP connection.

[0105] In addition or alternatively, in some specific embodiments, the BB circuit 103, for example, uses a counter to track the number of TCP ACK packets waiting in the output queue before UL transmission. If the value of the counter exceeds a predetermined value, indicating that the number of queued TCP ACK packets is greater than a specified number (e.g., due to congestion in the uplink channel), then the BB circuit 103 examines the TCP ACK packets in the queue to determine whether some TCP ACK packets can be discarded. The specified number can be equal to a predetermined number. According to the specific embodiment, the specified number can be set to any suitable value. For example, the specified number can be set to 3, 12, 27, or any other suitable number. Thus, the BB circuit 103 can be configured to monitor the number of TCP ACK packets to be processed in the output queue 107, and if the number of TCP ACK packets to be processed reaches a predetermined threshold limit, then detect the occurrence of one or more redundant TCP ACK packets of the flow.

[0106] In some specific implementations, as described in more detail in the following sections, when there are newer TCPACK packets pending in the output queue 107, the BB circuit 103 discards one or more older duplicate TCP ACK packets having the same flow ID and ACK Gen Count. In some specific implementations, after discarding one or more redundant TCP ACK packets, at least one most recent TCP ACK packet having the same flow ID and ACK Gen Count remains pending in the output queue 107. In some specific implementations, a timestamp is used to identify the TCP ACK packet, and the timestamp indicates the time when the TCP ACK packet is generated or added to the output queue 107. In some cases, when there are also TCP ACK packets having the same flow ID and ACK Gen Count but with a more recent timestamp value in the output queue, one or more TCP ACK packets with an earlier timestamp are discarded. In some other cases, when there are also TCP ACK packets having the same flow ID and ACK Gen Count but with an earlier timestamp value in the output queue, one or more TCP ACK packets with a more recent timestamp are discarded.

[0107] Figure 2 Illustrates the optimization of the TCP ACK packet flow according to some disclosed specific implementations. Figure 2 Illustrates the configuration 202 of the output queue before optimization; the configurations 204 and 206 of the output queue during the optimization of identifying and removing redundant TCP ACK packets; and the configuration 208 of the output queue after the optimization is completed. In some specific implementations, the operations described Figure 2 are performed by the BB circuit 103, and the configurations 202 - 208 correspond to the output queue 107.

[0108] Each of the configurations 202 - 208 illustrates the arrangement of TCP ACK packets in the output queue, where each packet is identified by a packet number (e.g., "Packet #1"), a flow ID (e.g., "Flow a"), and an ACK Gen Count value associated with the flow ("ackgen") (e.g., "ackgen 2"). As shown, the queue includes multiple TCP ACK packets having different flow IDs and corresponding ACK Gen Count values assigned by the TCP AP 105. In some specific implementations, the TCP ACK packets are arranged in order from the oldest to the newest packet, where Packet #1 is the oldest and Packet #13 is the newest. The oldest TCP ACK packet (Packet #1) in the TCP ACK queue (202) has a flow ID of "Flow a" and an ACK Gen Count of "ackgen 2", and the newest TCP ACK packet (Packet #13) has a flow ID of "Flow a" and an ACK Gen Count of "ackgen 3".

[0109] Configuration 202 shows that before the BB circuit 103 optimizes the queue, the output queue includes multiple TCP ACK packets having the same flow ID and the same ACK Gen Count. For example, packet #1, packet #3, and packet #9 have the flow ID "flow a" and the ACK Gen Count "ackgen 2". In some specific implementations, packet #1, packet #3, and packet #9 are processed by the TCP AP 105 within the same time period, such that the TCP AP 105 stamps each of these packets with the same ACK Gen Count value. When optimizing the output queue 107, the BB circuit 103 identifies one or more packets among these TCP ACK packets that have the same flow ID and ACK Gen Count value as redundant duplicate ACK packets, and these redundant duplicate ACK packets are then removed from the queue.

[0110] Configuration 202 shows that the output queue also includes multiple TCP ACK packets having the same flow ID but different ACK Gen Count values; and TCP ACK packets having different flow IDs. For example, packet #1 and #10 have the same flow ID "flow a", but have different ACK Gen Count values, namely "ackgen 2" and "ackgen 3" respectively. In some specific implementations, packet #1 and packet #10 corresponding to "flow a" are processed by the TCP AP 105 within different time periods, such that the TCP AP 105 stamps these packets with different ACK Gen Count values. Also, for example, packet #1 and packet #2 have different flow IDs, namely "flow a" and "flow b" respectively. These TCP ACK packets having the same flow ID but different ACK Gen Count values or different flow IDs are not identified as redundant with respect to each other.

[0111] In some specific implementations, the packet descriptors (e.g., flow ID and ACK Gen Count) of the TCP ACK packets in the queue are stored in the database 106, for example, stored in a data structure such as a table as described Figure 6 above. In some specific implementations, the BB circuit 103 manages the table. When examining a packet and obtaining the associated flow ID and ACK Gen Count, if the flow ID does not yet exist in the database 106, the BB circuit 103 records this information in an entry in the data structure of the database 106. As described in more detail in the following section, the BB circuit 103 manages the TCP ACK packets in the output queue 107 by examining the corresponding packet descriptor entries in the database 106 to identify redundant TCP ACK packets.

[0112] To check the TCP ACK packets in the output queue, the BB circuit 103 accesses the corresponding entry in the database for the packet and compares the relevant fields of the packet descriptor from the packet with the values stored in the entries in the database 106 corresponding to other TCP ACK packets in the output queue 107. As previously described, in some specific embodiments, when storing TCP ACK packets in the output queue for redundancy checking, the BB circuit 103 first checks whether the ACK GenCount or the flow ID or both of the packet are valid. If the BB circuit 103 determines that the ACK Gen Count of the currently checked packet is invalid, the BB circuit marks the database entry corresponding to the TCP ACK packet as less invalid (e.g., not a candidate for removal as a redundant TCP ACK packet) and continues to move to the next entry in the database, e.g., corresponding to the next packet in the output queue. In some specific embodiments, when it is determined that the TCP ACK packet contains important information, the TCPAP 105 sets the ACK Gen Count of the packet to invalid. This may occur, for example, for TCP ACKs with additional header information or TCP data packets. In some specific embodiments, a TCP ACK packet with a null AckGenCount field or a predetermined invalid AckGenCount value (e.g., 0x10000) also indicates that the ACK Gen Count is invalid for reduction, and the BB circuit 103 does not consider the associated TCP ACK as a candidate for redundancy and leaves the packet in the output queue. In some specific embodiments, if the value is within the valid range (e.g., 0...0xffff), the ACK generation count is valid; otherwise, it is invalid.

[0113] In some specific embodiments, the packet descriptor of the TCP ACK packet includes a separate AckGenCount_valid field that indicates whether the ACK Gen Count value of the packet is available. In some specific embodiments, the BB circuit 103 determines the validity of the ACK Gen Count value by checking the AckGenCount_valid field.

[0114] In addition or alternatively, in some embodiments, the BB circuit 103 verifies the flow ID associated with the packet being examined. If the flow ID indicates that the flow ID is invalid, the BB circuit 103 marks the database entry corresponding to the TCP ACK packet as invalid for compression and continues moving to the next entry in the database corresponding to the next packet in the output queue. Once a TCP ACK packet is determined to be invalid due to an invalid ACK Gen Count or an invalid flow ID or both, the BB circuit 103 ignores the packet for reduction purposes, thus leaving it in the output queue. In some embodiments, a TCP flow ID is valid if the value is within a valid range (e.g., 0...0xffff), while a value of (0x10000) indicates that the flow ID is invalid.

[0115] In some embodiments, the BB circuit 103 determines that two or more TCP ACK packets in the queue have the same flow ID and ACK Gen Count, indicating that one or more of these packets are redundant duplicate ACK packets. For example, configuration 204 instructs the BB circuit 103 to examine the packets in the output queue in order from the newest packet to the oldest packet. Regarding the newest packet (e.g., packet #13), the BB circuit 103 searches the entries in the database 106 to determine whether any other entries corresponding to TCP ACK packets in the queue have the same flow ID (e.g., "flow a") and the same ACK Gen Count (e.g., "ackgen3"). If the BB circuit 103 determines that there is no matching entry in the database 106, the BB circuit stores the flow ID and ACK Gen Count of the currently examined packet as a new entry in the database 106. Then, the BB circuit 103 continues to examine the next older packet in the queue (e.g., packet #12). If the BB circuit 103 determines that there is an older TCP ACK packet in the queue with the same flow ID (e.g., packet #10), the BB circuit 103 verifies whether the ACK Gen Count values of the two packets (e.g., packet #13 and packet #10) are the same.

[0116] In some cases, the BB circuit 103 determines that another packet with the same flow ID also has the same ACK GenCount value. For example, as shown in association 204a, both packet #13 and packet #10 have the flow ID "flow a" and ACK Gen Count "ackgen 3". When determining that an older packet and a newer packet have the same flow ID and ACK Gen Count value, the BB circuit 103 determines that the older packet (e.g., packet #10) is a redundant duplicate TCP ACK packet. The BB circuit 103 leaves the latest packet (e.g., packet #13) in the output queue while discarding the older packet (e.g., packet #10) as a redundant duplicate TCP ACK packet from the queue. In some cases, as shown in configuration 206, the BB circuit 103 marks the redundant packet as a discarded packet for later discard from the queue, for example, during a queue cleaner. For example, when determining that packet #10 is a redundant duplicate TCP ACK packet relative to packet #13, the BB circuit 103 marks packet #10 (e.g., the corresponding database entry) as a discarded packet, as shown in 206a.

[0117] In some specific implementations, the BB circuit 103 determines that the flow IDs of two TCP ACK packets are the same, but the ACK Gen Count values of the two packets are different. The ACK GenCount of the older packet marked as the most recent ACK Gen Count in the database is associated with the flow ID. In such cases, the BB circuit 103 replaces the ACK Gen Count associated with the flow ID in the database with the ACK Gen Count of the newer TCP ACK packet.

[0118] After the inspection of the TCP ACK packet is completed, the BB circuit 103 continues to move on to inspect the next older TCP ACK packet in the output queue, and compares the flow ID and ACK Gen Count of the packet with the other remaining packets in the queue in a manner similar to the above. For example, after resolving the latest TCP ACK packet, i.e., packet #13, the BB circuit 103 selects the next TCP ACK packet in the queue, e.g., TCP ACK packet #12. The BB circuit 103 obtains the packet descriptor of TCP ACK packet #12 from the database 106. The BB circuit 103 determines that the flow ID of TCP ACK packet #12 matches the flow ID of TCP ACK packet #11, but the ACK Gen Count values of these two TCP ACK packets are different. For example, this may occur when these two TCP ACK packets are generated by the TCP AP 105 within two different intervals. In this case, the packets are not considered redundant with respect to each other, and neither of the two packets is discarded or removed from the queue, as shown in configuration 206. However, the corresponding database entry for the flow (e.g., "flow c") is updated with the most recent ACK Gen Count value (e.g., "ackgen88") corresponding to the latest TCP ACK packet of the flow.

[0119] The BB circuit 103 continues to examine the output queue 107, moving backward from the newer TCP ACK packets in the queue to the older TCP ACK packets in a manner similar to the above. For example, as shown with respect to configuration 204, when inspecting packet #11, the BB circuit 103 determines that two other TCP ACK packets, i.e., packet #6 and packet #5, have the same flow ID ("flow c") and the same ACK GenCount ("ackgen 87"), as shown in associations 204b and 204c. In this case, the BB circuit 103 determines that the two older packets (e.g., packet #6 and packet #5) are redundant and marks these packets for discard, as shown in configuration 206.

[0120] Similarly, considering the next older TCP ACK packet in the output queue that has not been inspected yet (e.g., packet #9), the BB circuit 103 determines that two older packets in the output queue (e.g., packet #3 and packet #1) are redundant duplicate TCP ACK packets because they have the same flow ID ("flow a") and the same ACK Gen Count value ("ackgen 2"), as shown in associations 204d and 204e. Also, for example, the BB circuit 103 determines that packet #7 is a redundant copy of packet #4, as shown in association 204f. In these cases, the BB circuit 103 discards the redundant duplicate packets, as shown in configuration 206.

[0121] After discarding all redundant packets, the result of output queue optimization / reduction is shown by configuration 208. As shown, the number of TCP ACK packets in the output queue after optimization is less than the number of TCP ACK packets in the output queue before the optimization process is executed (204). Eliminating redundant TCP ACK packets in this way results in a lower number of packets being sent on the UL, which improves processing efficiency and results in reduced latency. This results in a reduction in TCP RTT, which in turn results in increased TCP throughput and thus higher end-to-end throughput.

[0122] In some embodiments, the TCP AP 105 sets the ACK Gen Count of a particular TCP ACK packet to invalid, for example, by leaving the ACK Gen Count field in the packet descriptor empty or by assigning a predetermined invalid value. For example, the ACK Gen Count field in the packet descriptor can be a 16-bit field; the TCP AP 105 can set the 16-bit field to the hexadecimal value FFFF to indicate that the ACK Gen Count is invalid. In some embodiments, a similar approach is taken for the flow ID, as previously described. By setting the ACK Gen Count or the flow ID or both to invalid for a TCP ACK packet, the application processor 105 can avoid the corresponding TCP ACK packet being classified as redundant and thus discarded. This may occur, for example, for a TCP ACK packet determined to include important information (e.g., a TCP ACK with additional header information). In some embodiments, the output queue 107 includes additional packets, such as TCP data packets. In such embodiments, the TCP AP 105 ensures that data packets are not examined for reduction by setting the ACK Gen Count or the flow ID or both of the data packets to an invalid value.

[0123] Figure 3 An exemplary process 300 for managing TCP ACK packets in an output queue is shown in accordance with some embodiments. In some embodiments, process 300 is executed by the client device 102 (e.g., by the BB circuit 103 of the client device 102) to manage TCP ACK packets cached in the output queue 107 for uplink transmission by checking the TCP ACK packets for discardable redundant packets. Thus, process 300 is described in the following sections with respect to the client device 102 and the system 100. However, in other embodiments, process 300 may also be executed by other devices.

[0124] Process 300 begins when a client device accesses an output queue (302) that includes multiple TCP ACK packets. For example, BB circuit 103 accesses output queue 107 to determine if there are redundant packets that can be discarded. In some specific implementations, when the number of TCP ACK packets in the queue exceeds a predetermined threshold number, BB circuit 103 accesses output queue 107 to optimize the queue. In some specific implementations, when the duration that a TCP ACK packet has been queued in output queue 107 exceeds a predetermined time threshold, BB circuit 103 accesses output queue 107 to optimize the queue. In some specific implementations, BB circuit 103 accesses output queue 107 at a predetermined periodic time interval to optimize the queue. In some specific implementations, the predetermined time interval corresponds to the time period used by TCP AP 105 to stamp packets with the same ACK Gen Count value, as previously described. In some specific implementations, accessing output queue 107 includes accessing the records of TCP ACK packets in database 106. Regarding Figure 6 Such records are shown. In some specific implementations, when accessing the output queue, BB circuit 103 resets database 106. For example, when accessing output queue 107, BB circuit 103 clears the entries in database 106.

[0125] When accessing the output queue, the client device checks the TCP ACK packets in the queue (304). For example, in some specific implementations, BB circuit 103 starts checking packets from the latest packet in the queue (e.g., packet #13 as shown by configuration 204). In other specific implementations, BB circuit 103 starts checking packets from the oldest packet in the queue (e.g., packet #1 as shown by configuration 204).

[0126] The client device identifies the values of ACK Gen Count and flow ID corresponding to the currently accessed packet (306). For example, when checking a TCP ACK packet (such as packet #13) in output queue 107, BB circuit 103 accesses the flow ID and ACK Gen Count values included in the packet.

[0127] When identifying the ACK Gen Count value of the TCP ACK packet being checked, the client device verifies the validity of the ACK Gen Count of the packet (308). For example, BB circuit 103 verifies whether the ACK generation count value of the packet is set to a valid value or an invalid value (such as hexadecimal FFFF or some other suitable predetermined value indicating invalidity). In some specific implementations, having an empty ACK Gen Count field indicates that the ACK Gen Count is invalid.

[0128] If the client device determines that the ACK Gen Count value of the examined TCP ACK packet is invalid (308 - No), the client device marks the TCP ACK packet as not eligible for reduction and continues to move on to examine the next packet in the output queue (if available). For example, as previously described, in some cases, such as when the packet contains important information (such as a TCP ACK with additional header information or a TCP data packet), the TCP AP 105 sets the ACK Gen Count of the packet to invalid to indicate that the packet should not be a candidate for removal from the output queue. When the BB circuit 103 determines that the ACK Gen Count of the currently examined packet is invalid, the BB circuit leaves the packet in the output queue 107 without further processing and continues to move on to examine the next packet in the queue (if there are other unexamined packets).

[0129] On the other hand, if the client device determines that the examined TCP ACK packet has a valid ACK Gen Count, the client device verifies whether the flow ID of the TCP ACK packet is valid (310). For example, the BB circuit 103 verifies whether a flow ID value is assigned to the TCP ACK packet, and if so, checks whether the flow ID indicates a valid or invalid value (e.g., hexadecimal FFFF or some other suitable predefined value indicating invalid). In some specific implementations, having no value in the flow ID field indicates that the flow ID is invalid.

[0130] If the client device determines that the flow ID of the examined packet indicates that the flow ID is invalid (310 - No), the client device marks the TCP ACK packet as not eligible for reduction and continues to move on to examine the next packet in the output queue (if available). For example, as previously described, in some cases, such as when the client device determines that the TCP ACK packet contains important information (such as a TCP ACK with additional header information or a TCP data packet), the TCP AP 105 sets the flow ID of a specific TCP ACK packet to invalid to indicate that the packet should not be a candidate for removal from the output queue. When the BB circuit 103 determines that the flow ID of the currently examined packet is invalid, the BB circuit leaves the packet in the output queue 107 without further processing and continues to move on to examine the next packet in the queue (if there are other unexamined packets).

[0131] On the other hand, if the client device determines that the flow ID of the examined packet is valid (310 - Yes), the client device verifies whether the flow ID of the packet is stored in an entry in the database (312). For example, the BB circuit 103 verifies the entries in the database 106 to determine whether an entry includes the flow ID of the currently examined packet, which indicates that another TCP ACK packet corresponding to the same flow exists in the output queue (and has been previously examined).

[0132] If the client device determines that the flow ID is not stored in the database (312 - No), the client device stores the flow ID of the packet and the TCP ACK Gen Count in the database (314). For example, if the BB circuit 103 determines that the database 106 does not include an entry with the flow ID of the currently examined TCP ACK packet, the BB circuit 103 creates a new entry in the database 106, for example, as shown regarding Figure 6 The BB circuit 103 stores the flow ID of the packet and the ACK Gen Count value in the newly created entry.

[0133] On the other hand, if the client device determines that the flow ID of the examined packet exists in an entry in the database (312 - Yes), the client device verifies whether the ACK Gen Count of the examined packet matches the ACK Gen Count value stored in the database entry (316). For example, as described above and regarding Figure 2 Packet #10 in the queue (204) has a flow ID "flow a" and an ACK Gen Count "ackgen 3". If packet #10 is the currently examined packet, the BB circuit 103 determines that there is at least one entry with the same flow ID in the database corresponding to another TCP ACK packet in the queue with the same flow ID when searching the entries in the database 106. The BB circuit 103 determines whether the ACK Gen Count of the entry is the same as the ACK Gen Count of packet #10.

[0134] If the client device determines that the ACK Gen Count value of the examined TCP ACK packet is different from the ACK Gen Count value stored in the database entry (316 - No), the client device updates the ACK Gen Count value in the database by replacing the existing value with the ACK Gen Count value of the examined TCP ACK packet (318). For example, if BB circuit 103 determines that the entry in database 106 with the same flow ID as the examined packet has a different ACK Gen Count value, BB circuit 103 updates the ACK Gen Count field in the entry with the ACK Gen Count value of the examined TCP ACK packet.

[0135] On the other hand, if the client device determines that the ACK Gen Count of the examined packet matches the ACK Gen Count value stored in the database entry (316 - Yes), the client device discards the TCP ACK packet (320). For example, when examining the entry in database 106 for packet #10 (as Figure 2 shown), BB circuit 103 determines that there is an entry with the same flow ID ("flow a") and the same ACK Gen Count value ("ackgen 3") as packet #10. As previously described, this entry was created when examining packet #13. Therefore, BB circuit 103 determines that packet #10 is a redundant duplicate TCP ACK packet compared to packet #13. Then, BB circuit 103 discards or drops TCP ACK packet #10 from output queue 107.

[0136] In a specific implementation where BB circuit 103 examines the output queue starting from the oldest packet first, when a redundant TCP ACK packet (such as packet #10) is identified, BB circuit 103 discards the newer packet (e.g., packet #13) and retains the older packet (e.g., packet #10) in the output queue. In such specific implementations, the entry for the older packet remains in the database while the entry for the newer packet is deleted. It should be noted that in such cases, when examining a packet, BB circuit 103 does not immediately know whether the packet will be discarded or retained in the output queue. This determination is made when examining the next packet with the same flow ID. Therefore, compared to the case when examining packets in the output queue starting from the newest packet first, the decision of whether to retain a packet in the output queue or discard it is delayed during the iteration of examining packets.

[0137] Then, the client device checks whether there is an additional packet (322) in the output queue. If there is one or more additional packets (322 - Yes) in the output queue, the client device accesses the TCP ACK packet (324) in the output queue and starts checking the entries in the database for a match corresponding to the flow ID and ACKGen Count of the newly accessed TCP ACK packet in the manner described in the foregoing section with respect to (304)-(320). On the other hand, if there is no additional packet (322 - No) in the output queue, the process 300 ends, where for the current iteration, the output queue has been compressed.

[0138] In some cases of the foregoing process 300, when the older TCP ACK packets as redundant copies are removed from the output queue while the newer TCP ACK packets are retained in the queue, the sending of the TCP ACK packets to the remote server is delayed because the newer TCP ACK packets are located at a later position in the output queue. As described in the following section, in some specific implementations, the position of the (discarded) duplicate older TCP ACK packets in the output queue is provided to the newer TCP ACK packets so that the TCP ACK is sent to the remote server earlier (e.g., when the older TCP ACK packet would be sent based on its position in the output queue), which helps to reduce the latency. In such specific implementations, the BB circuit 103 tracks the position of the TCP ACK packets in the output queue. When an older redundant TCP ACK packet is identified, the BB circuit 103 discards the older packet and moves the newer packet to the position of the older packet in the queue. To achieve this reordering of the output queue, the BB circuit 103 maintains additional fields in the entries in the database 106. The additional fields include a replacement candidate index and a winner packet (e.g., the retained newer packet) index. The replacement candidate index indicates the position in the queue of the older packet of the flow that has the same TCP ACK Gen Count value as the newer TCP ACK packet. This field is updated whenever an older packet with the same TCP ACK Gen Count value is found in the output queue. The winner packet index indicates the queue position of the latest packet of the flow that has a specific TCP ACK Gen Count value. This field is set when a packet with a new TCP ACK Gen Count value is identified.

[0139] Figure 4Shows the optimization of the TCP ACK packet flow according to some disclosed embodiments, where packets are reordered in the output queue. The figure shows the configuration 402 of the output queue before optimization; the configurations 404, 406, and 408 of the output queue during the optimization of identifying and removing redundant TCP ACK packets; and the configuration 410 of the output queue after the optimization is completed. In some embodiments, with respect to Figure 4 the operations described are performed by the BB circuit 103, and the configurations 402 - 410 correspond to the output queue 107.

[0140] Each of the configurations 402 to 410 includes TCP ACK packets identified by a packet number (e.g., "Packet #1"), a flow ID (e.g., "Flow a"), and an ACK Gen Count value (e.g., "ackgen 2"). As shown, the queue includes multiple TCP ACK packets having different flow IDs and corresponding ACK Gen Count values assigned by the TCP AP 105. In some embodiments, the TCP ACK packets are arranged in order from the oldest to the newest packet, where Packet #1 is the oldest and Packet #13 is the newest. The oldest TCP ACK packet (Packet #1) in the queue has a flow ID of "Flow a" and an ACK Gen Count of "ackgen 2", and the newest TCP ACK packet (Packet #13) has a flow ID of "Flow a" and an ACK Gen Count of "ackgen 3".

[0141] Configuration 402 shows that before the BB circuit 103 optimizes the queue, the output queue includes multiple TCP ACK packets having the same flow ID and the same ACK Gen Count. For example, Packets #1, #3, and #9 have a flow ID of "Flow a" and an ACK Gen Count of "ackgen 2". When optimizing the output queue 107, the BB circuit 103 identifies one or more of these TCP ACK packets having the same flow ID and ACK Gen Count value as redundant duplicate ACK packets, and these redundant duplicate ACK packets are then removed from the queue.

[0142] Configuration 402 shows that the output queue also includes multiple TCP ACK packets having the same flow ID but different ACK Gen Count values; and TCP ACK packets having different flow IDs. For example, Packets #1 and #10 have the same flow ID of "Flow a", but different ACK Gen Count values of "ackgen 2" and "ackgen 3", respectively; while Packets #1 and #2 have different flow IDs of "Flow a" and "Flow b", respectively. These TCP ACK packets having the same flow ID but different ACK Gen Count values or different flow IDs are not identified as redundant relative to each other.

[0143] In some specific implementations, the packet descriptors of TCP ACK packets in the queue (e.g., flow ID and ACK GenCount value) are stored in database 106, e.g., stored in a data structure such as a table as described Figure 7 above. In some specific implementations, the BB circuit 103 manages the table. When examining a packet, if the associated flow ID and ACK Gen Count value do not exist in database 106, the BB circuit 103 records the packet descriptor information as an entry in the database and also records the index or position of the packet in the output queue. As described in more detail in the following section, the BB circuit 103 manages the TCP ACK packets in the output queue 107 by examining the entries in database 106 to identify redundant TCP ACK packets.

[0144] In some specific implementations, the BB circuit 103 starts examining the output queue 107 from the latest packet (e.g., packet #13 as shown by configuration 402). To examine the TCP ACK packets in the output queue, the BB circuit 103 accesses the packet descriptors of the packets and compares the information in the packet descriptors with the entries stored in database 106.

[0145] As previously described, in some specific implementations, when storing TCP ACK packets in the output queue for redundancy checking, the BB circuit 103 first checks whether the corresponding packet descriptor of the packet has a valid ACK Gen Count or a valid flow ID or both. If the BB circuit 103 determines that the ACK Gen Count of the currently examined packet is invalid, the BB circuit marks the TCP ACK packet as invalid for reduction (e.g., not a candidate for removal as a redundant TCP ACK packet) and continues to move to the next packet in the output queue. Additionally or alternatively, in some specific implementations, the BB circuit 103 checks the flow ID associated with the examined packet. If the flow ID indicates that the flow ID is invalid, the BB circuit 103 marks the TCP ACK packet as invalid for reduction and continues to move to the next packet in the output queue. Once a TCP ACK packet is determined to be invalid due to an invalid ACK Gen Count or an invalid flow ID or both, the BB circuit 103 ignores the packet for reduction and thus leaves it in the output queue.

[0146] In some specific implementations, the BB circuit 103 determines that the same flow ID and ACK GenCount of the TCP ACK packets in the queue match the entries in the database 106, thereby indicating that the packets are redundant duplicate ACK packets. For example, considering configuration 404, the BB circuit 103 checks the packets in the output queue in the order from the latest packet to the oldest packet. Regarding the latest packet, i.e., packet #13, the BB circuit 103 determines that there is no entry in the database 106 with the same flow ID ("flow a") and the same ACK Gen Count ("ackgen3"). Therefore, the BB circuit 103 creates a new entry in the database 106 to store the flow ID "flow a", the ACK GenCount "ackgen 3", and the position index of packet #13. Subsequently, when checking the older TCP ACK packet #10, the BB circuit 103 determines that there is an entry in the database 106 with the same flow ID "flow a" and ACK Gen Count value "ackgen 3" as packet #10. As shown by the association 404a in configuration 404, both packet #13 and packet #10 have the flow ID "flow a" and the ACK Gen Count "ackgen 3". The BB circuit 103 determines that packet #10 has the same flow ID and ACK GenCount value as the newer packet (e.g., packet #13) and is a discardable redundant duplicate TCP ACK packet. The BB circuit 103 annotates the position index of the replacement candidate packet #10 (which is the discarded TCP ACK packet) in the database entry corresponding to the specific flow ID ("flow a") and ACK Gen Count ("ackgen 3"), as shown regarding Figure 7 shown.

[0147] After completing the inspection of the TCP ACK packet, the BB circuit 103 continues to move on to inspect the next older TCP ACK packet in the output queue and compares the flow ID and ACK Gen Count of the packet with the entries in the queue in a manner similar to the above. For example, after resolving TCP ACK packet #12, the BB circuit 103 selects the next TCP ACK packet in the queue, i.e., TCP ACK packet #11. The BB circuit 103 determines that the database 106 includes an entry with the flow ID ("flow c") of TCP ACK packet #11, but the ACK Gen Count value ("ackgen 87") of packet #11 is different from the ACK Gen Count value in the database entry (e.g., "ackgen 88" corresponding to packet #12 with the same flow ID). In this case, packet #11 is not a redundant copy of packet #12 and is not discarded or removed from the queue as shown in configuration 404. The BB circuit 103 updates the corresponding database entry (e.g., the entry corresponding to "flow c") so as to update the ACK Gen Count field to store the ACK Gen Count value of packet #11 and update the winner index field to store the position index of packet #11.

[0148] The BB circuit 103 continues to examine the output queue 107, moving backward from the newer TCP ACK packets in the queue to the older TCP ACK packets in a manner similar to the above. For example, as shown with respect to configuration 404, when inspecting packet #6 and then packet #5, the BB circuit 103 determines that these packets have the same flow ID ("flow c") and the same ACK Gen Count ("ackgen 87") as the entry in the database corresponding to packet #11, as described above. In this case, the BB circuit 103 determines that the two older packets (packet #6 and packet #5) are redundant copies with respect to packet #11 (shown by associations 404b and 404c) and marks these packets for discard.

[0149] In some specific implementations, when there are multiple redundant and duplicate TCP ACK packets as in the foregoing examples, the BB circuit 3 selects the position of the oldest packet among the multiple duplicate TCP ACK packets as the replacement position for the latest packet to be retained, and stores the position of the oldest copy, which is the value of the replacement candidate index, and the position of the winner packet in the database entry corresponding to the flow ID and the ACK Gen Count value. In some specific implementations, the replacement candidate field in the database entry is updated when an additional duplicate TCP ACK packet is identified. In such specific implementations, the final value of the replacement candidate field corresponds to the position index of the oldest duplicate TCP ACK packet identified. Considering the above example again, the BB circuit 103 first identifies that packet #6 has the same flow ID and the same ACK Gen Count value, as shown in association 404b. Since packet #6 is an older packet compared to packet #11, the BB circuit 103 determines that packet #6 can be discarded, and the position occupied by packet #6 in the queue can be given to packet #11. After this identification, the BB circuit 103 stores the position of packet #6 in the replacement candidate index field in the database entry corresponding to the flow ID (“flow c”) and the ACK Gen Count value (“ackgen87”), while the position of packet #11 exists in the winner packet field. Subsequently, the BB circuit 103 identifies packet #5 (which is an older packet in the output queue compared to packet #5) as another copy corresponding to the flow ID “flow c” and the ACK Gen Count value “ackgen 87”, as shown in the associated 404c. Then, the BB circuit 103 updates the replacement candidate index field in the corresponding database entry for the flow ID (“flow c”) and the ACK Gen Count value (“ackgen 87”) to store the position of packet #5 (removing the position of packet #6 previously stored in this field in the database entry).

[0150] Similarly, considering the flow ID "Flow a" corresponding to packet group #9 and the ACK Gen Count value "acckgen 2", the BB circuit 103 identifies two older packets in the output queue that are redundant duplicate TCP ACK packets (i.e., packet #3 and packet #1), because these two older packets have the same flow ID and ACK Gen Count value, as shown in associations 404d and 404e. Among these two redundant duplicate TCP ACK packets, packet #1 is older than packet #3. Therefore, the BB circuit 103 stores the position of packet #1 in the corresponding database entry for the flow ID "Flow a" and the ACK Gen Count value "ackgen 2" as the final value in the replacement candidate index field. Also, for example, the BB circuit 103 determines that packet #4 is a single redundant duplicate of packet #7, as shown in association 404f. In this case, the BB circuit 103 stores the position of packet #4 in the database entry for the corresponding flow ID ("Flow b") and ACK Gen Count value ("ackgen 41") as the final value in the replacement candidate index field, while the position of packet #7 is stored in the winner candidate index field.

[0151] After examining the output queue to identify redundant TCP ACK packets and annotating the positions of the winner packets and replacement candidates, the BB circuit 103 uses the recorded position index information to rearrange the packets in the queue such that the position of the winner packet corresponding to a particular flow ID and ACK Gen Count value is swapped with the position of the oldest packet corresponding to that flow ID and ACK Gen Count value. For example, as discussed above with respect to association 404a, for the flow ID "Flow a" and ACK Gen Count "ackgen 3", packet #10 is a redundant copy of packet #13, and their respective queue positions are stored as the replacement candidate index and the winner index in the corresponding database entry. As shown in configuration 406, when rearranging the packets in the output queue after identifying the redundant copies, the BB circuit 103 swaps their positions in the output queue by looking up the positions of packet #13 and packet #10 in the replacement candidate index and winner index fields of the database entry. As shown in 406a, the retained packet #13 is moved up in the queue to the position previously occupied by packet #10t. This reordering ensures that the earliest available position (e.g., the original position of packet #10) of the TCP ACK packets corresponding to the flow ID "Flow a" and the ACK Gen Count value "ackgen 3" in the queue is maintained while removing the redundant duplicate packets.

[0152] In a manner similar to the above, when removing redundant duplicate TCP ACK packets, TCP ACK packets corresponding to other <flow ID, ACK Gen Count value> tuples are reordered. For example, as shown in association 406b, the positions of packet #11 and packet #5, which are respectively the latest packet and the oldest packet corresponding to the flow ID "flow c" and the ACK Gen Count value "ackgen 87", are swapped; as shown in association 406c; the positions of packet #9 and packet #1, which are respectively the latest packet and the oldest packet corresponding to the flow ID "flow a" and the ACK Gen Count value "ackgen2", are swapped; and as shown in association 406d, the positions of packet #7 and packet #4, which are respectively the latest packet and the oldest packet corresponding to the flow ID "flow b" and the ACK Gen Count value "ackgen 41", are swapped. For each of these reorderings, the BB circuit 103 looks up the positions to be swapped from the replacement candidate index field and the winner index field in the corresponding database entry.

[0153] After the BB circuit 103 has swapped the positions of the packets and reordered the queue as described above, the BB circuit 103 discards the TCP ACK packets identified as redundant duplicates. For example, as shown in configuration 408, packet #10, which is a redundant duplicate packet corresponding to the flow ID "flow a" and the ACK Gen Count value "ackgen 3", is discarded. Similarly, packet #5 and packet #6, which are redundant duplicate packets corresponding to the flow ID "flow c" and the ACK Gen Count value "ackgen 87", are discarded; packet #1 and packet #3, which are redundant duplicate packets corresponding to the flow ID "flow a" and the ACK Gen Count value "ackgen 2", are discarded; and packet #4, which is a redundant duplicate packet corresponding to the flow ID "flow b" and the ACK Gen Count value "ackgen 41", is discarded. After discarding the redundant packets, the configuration 410 of the output queue shows that the number of packets in the compressed queue is less than the number of packets in the original queue, as shown in configuration (402). In this way, redundant TCP ACK packets are eliminated from the output queue to improve processing efficiency. In doing so, the remaining packets are reordered such that the order of sending acknowledgments is not changed, which results in a reduction in the latency of all subsequent UL TCP ACK packets (after the discarded packets), and a reduction in TCP RTT (round-trip time) (which ultimately leads to an increase in TCP throughput and thus higher end-to-end throughput).

[0154] Figure 5Exemplary process 500 for managing TCP ACK packets in an output queue and reordering is shown in accordance with some disclosed embodiments. In some embodiments, process 500 is performed by client device 102, such as by BB circuit 103 of client device 102. Accordingly, process 500 is described in the following sections with respect to client device 102 and system 100. However, process 500 may also be performed by other devices.

[0155] Process 500 begins when a client device accesses an output queue (502) that includes a plurality of TCP ACK packets. For example, BB circuit 103 accesses output queue 107 to determine if there are redundant packets that can be discarded. In some embodiments, when the number of TCP ACK packets in the queue exceeds a predetermined threshold number, BB circuit 103 accesses output queue 107 to optimize the queue. In some embodiments, when the duration that a TCP ACK packet has been queued in output queue 107 exceeds a predetermined time threshold, BB circuit 103 accesses output queue 107 to optimize the queue. In some embodiments, BB circuit 103 accesses output queue 107 at a predetermined periodic time interval to optimize the queue. In some embodiments, when accessing the output queue, BB circuit 103 resets database 106. For example, in such embodiments, when accessing output queue 107, BB circuit 103 clears the entries in database 106.

[0156] When accessing the output queue, the client device examines the TCP ACK packets in the queue (504). For example, in some embodiments, BB circuit 103 examines the packets starting from the latest packet in the queue (e.g., packet #13 as shown by configuration 402). In some embodiments, BB circuit 103 examines the packets starting from the oldest packet in the queue (e.g., packet #1 as shown by configuration 402). In some embodiments, when examining the packets in output queue 107, BB circuit 103 reads the packet descriptor corresponding to the packet.

[0157] The client device identifies the values of the ACK Gen Count and the flow ID corresponding to the currently accessed TCP ACK packet (506). For example, when examining a TCP ACK packet (such as packet #13) in output queue 107, BB circuit 103 accesses the flow ID and the ACK Gen Count values included in the packet's packet descriptor.

[0158] When identifying the ACK Gen Count value of the TCP ACK packet being inspected, the client device verifies whether the ACK Gen Count value of the packet is valid (508). For example, the BB circuit 103 verifies whether the ACK Gen Count value of the packet is set to a valid value or an invalid value (e.g., hexadecimal FFFF or some other suitable predetermined value indicating invalidity). In some specific implementations, the absence of any value in the ACK Gen Count field indicates that the ACK Gen Count is invalid.

[0159] If the client device determines that the ACK Gen Count value of the TCP ACK packet being inspected is invalid (508 - No), the client device marks the TCP ACK packet as non-compliant for reduction and continues to move on to check the next packet in the output queue (if available) (522). For example, as previously described, in some cases, such as when the packet contains important information (such as a TCP ACK with additional header information or a TCP data packet), the TCP AP 105 sets the ACK Gen Count of the packet to invalid to indicate that the packet should not be a candidate for removal from the output queue. When the BB circuit 103 determines that the ACK Gen Count of the currently inspected packet is invalid, the BB circuit leaves the packet in the output queue 107 without further processing and continues to move on to check the next packet in the queue (if there are other uninspected packets).

[0160] On the other hand, if the client device determines that the inspected TCP ACK packet has a valid ACK Gen Count, the client device verifies whether the flow ID of the TCP ACK packet is valid (510). For example, the BB circuit 103 verifies whether a flow ID value is assigned to the TCP ACK packet, and if so, checks whether the flow ID indicates a valid value or an invalid value (e.g., hexadecimal FFFF or some other suitable predetermined value indicating invalidity). In some specific implementations, the absence of any value in the flow ID field indicates that the flow ID is invalid.

[0161] If the client device determines that the flow ID of the examined packet indicates that the flow ID is invalid (510 - No), the client device marks the TCP ACK packet as non-compliant for reduction and continues moving to examine the next packet in the output queue (if available) (522). For example, as previously described, in some cases, such as when the client device determines that the TCP ACK packet contains important information (such as a TCP ACK with additional header information or a TCP data packet), the TCP AP 105 sets the flow ID of a specific TCP ACK packet to invalid to indicate that the packet should not be a candidate for removal from the output queue. When the BB circuit 103 determines that the flow ID of the currently examined packet is invalid, the BB circuit leaves the packet in the output queue 107 without further processing and continues moving to examine the next packet in the queue (if there are other unexamined packets).

[0162] On the other hand, if the client device determines that the flow ID of the examined packet is valid (510 - Yes), the client device verifies whether the flow ID of the packet is stored in an entry in the database (512). For example, the BB circuit 103 verifies the entries in the database 106 to determine whether an entry includes a flow ID that matches the flow ID of the currently examined packet, which indicates that another TCP ACK packet corresponding to the same flow exists in the output queue (and has been previously examined).

[0163] If the client device determines that the flow ID is not stored in the database (512 - No), the client device stores the flow ID of the packet and the TCP ACK Gen Count in the database (514). For example, if the BB circuit 103 determines that the database 106 does not include an entry with the flow ID of the currently examined TCP ACK packet, the BB circuit 103 creates a new entry in the database 106, for example, as shown regarding Figure 7 shown. The BB circuit 103 stores the flow ID of the packet and the ACK Gen Count value in the newly created entry. The client device also stores the position of the packet in the database (515). For example, in addition to storing the flow ID and the ACK Gen Count value of the TCP ACK packet in the newly created entry, the BB circuit 103 also stores the position of the packet in the output queue in the winner index field of the database entry, as previously regarding Figure 4 described.

[0164] On the other hand, if the client device determines that the flow ID of the examined packet exists in an entry in the database (512 - Yes), the client device verifies whether the ACK Gen Count of the examined packet matches the ACK Gen Count value in the entry (516). For example, as above and regarding Figure 4As described above, packet #10 in queue (404) has a flow ID of "flow a" and an ACK Gen Count of "ackgen3". When packet #10 is inspected, BB circuit 103 determines that there is an entry in the database with the same flow ID ("flow a") (e.g., previously created when inspecting packet #13) when retrieving the entry in database 106. BB circuit 103 determines whether the ACK Gen Count value of the entry matches the ACK Gen Count of packet #10. BB circuit 103 verifies whether the ACK Gen Count in the entry is the same as the ACK Gen Count of packet #10.

[0165] If the client device determines that the ACK Gen Count of the TCP ACK packet does not match the ACK Gen Count of the database entry (516 - No), then the client device updates the ACK Gen Count value of the entry in the database (518). If BB circuit 103 determines that an existing entry in database 106 with the same flow ID as the flow ID of the inspected packet has an ACK Gen Count value different from the ACK Gen Count value of the packet, then BB circuit 103 updates the database entry. BB circuit 103 updates the ACK Gen Count field of the entry with the ACK Gen Count value of the inspected packet. For example, as described above, when inspecting TCP ACK packet #11, BB circuit 103 determines that database 106 includes an entry with the flow ID of TCP ACK packet #11 ("flow c"), but the ACK Gen Count value of packet #11 ("ackgen 87") is different from the ACK Gen Count value in the database entry (corresponding to "ackgen 88" of packet #12 with the same flow ID). In this case, BB circuit 103 updates the corresponding database entry for "flow c" by updating the ACK Gen Count field to store the ACK Gen Count value of packet #11 and the winner index field to store the position index of packet #11.

[0166] The client device also stores the position of the packet that is the winner packet in the database entry (519). For example, in addition to updating the ACK Gen Count field in the database entry as described above, BB circuit 103 also stores the output queue position of the packet in the winner index field of the entry, as previously described with respect to Figure 4 As described. Considering the above example of packet #11, BB circuit 103 updates the winner index field of the database entry (which previously stored the queue position of packet #12) to store the queue position index of packet #11.

[0167] On the other hand, if the client device determines that the ACK Gen Count of the packet under inspection matches the ACK Gen Count value stored in the database entry (516 - Yes), the client device marks the TCP ACK packet as redundant and stores the position of the TCP ACK packet as a replacement candidate index in the database entry (520). For example, when considering the packet under inspection #10 (as Figure 4 shown), the BB circuit 103 determines that there is an entry (created when inspecting packet #13) with the same flow ID ("flow a") and the same ACK Gen Count value ("ackgen 3") as packet #10. Therefore, the BB circuit 103 determines that packet #10 is a redundant duplicate TCP ACK packet compared to packet #13. The BB circuit 103 marks the TCP ACK packet #10 to be discarded from the output queue 107 and stores the position of packet #10 in the replacement candidate index field of the corresponding database entry for the flow ID "flow a", where the queue position of packet #13 is stored in the winner index field.

[0168] Then, the client device checks whether there are additional packets in the output queue (522). If there is one or more additional packets in the output queue (522 - Yes), the client device accesses the next TCP ACK packet in the output queue (524), and starts checking the entries in the database for a match corresponding to the flow ID and ACK Gen Count of the newly accessed TCP ACK packet in the manner described in the foregoing section regarding (504)-(520).

[0169] On the other hand, if there are no additional packets in the output queue (522 - No), the client device continues to reorder the TCP ACK packets in the output queue and discard redundant TCP ACK packets (526). For example, the BB circuit 103 swaps the positions of packet #13 and packet #10, as described in 406a of Figure 4 and discards the redundant duplicate TCP ACK packet #10, as shown in configuration 408. Then, process 500 ends, where for the current iteration, the output queue has been compressed and reordered. For example, in some specific embodiments, Figure 4 configuration 410 in

[0170] Figure 6 shows the output queue at the end of process 500. Figure 1

[0171] Figure 6 As Figure 6As shown, the database 106 includes one or more entries, such as 602, 604, and 606. The one or more entries are represented as rows and are also referred to as data records. Each entry includes two fields, namely a flow ID field 620 and an ACK GenCount field 622. These two fields store the flow ID and the ACK Gen Count value determined by the BB circuit 103 when checking the TCP ACK packets in the output queue 107, respectively. Each entry in the database 106 includes a unique combination of a flow ID and an ACK Gen Count value. For example, entry 602 has the value "flow a" in its flow ID field 620 and the value "ackgen 3" in its ACK Gen Count value field 622. When the BB circuit 103 starts to check the output queue 107 in each iteration, the BB circuit resets the database 106 by clearing all entries.

[0172] When checking the TCP ACK packets in the output queue, if the BB circuit 103 does not find an entry in the database 106 with a flow ID that matches the packet, the BB circuit 103 creates a new entry in the database 106 and enters the flow ID and the ACK Gen Count value in the corresponding fields of the entry, as described with respect to output queue configurations 202 to 204 and process 300. For example, this occurs when checking the latest packet corresponding to a specific flow ID. For example, as described with respect to Figure 2 and Figure 3 When checking packet #13 in the output queue 107, the BB circuit 103 determines that there is no entry in the database 106 with the flow ID ("flow a") of packet #13. Therefore, the BB circuit 103 creates a new entry in the database 106, such as entry 602, and enters the flow ID and the ACK Gen Count value of packet #13 in the corresponding fields of the newly created entry. Similarly, when checking packet #12 and packet #7 accordingly, the BB circuit 103 creates entries 604 and 606.

[0173] Figure 7 Shows an entry in the database 106 for managing TCP ACK packets according to some disclosed embodiments. As described with respect to Figure 1 The database 106 is included in the client device 102. As Figure 7 shown, the database 106 includes one or more entries, such as 702, 704, and 706. The one or more entries are represented as rows and are also referred to as data records. Each entry includes four fields: a flow ID field 720, an ACK Gen Count field 722, a replacement candidate index field 724, and a winner index field 726.

[0174] The flow ID field 720 and the ACK Gen Count field 722 store the flow ID and the ACK Gen Count value respectively determined by the BB circuit 103 when inspecting TCP ACK packets in the output queue 107. Each entry in the database 106 includes a unique combination of the flow ID and the ACK Gen Count value. For example, entry 702 has the value "flow a" in its flow ID field 720 and the value "ackgen 3" in its ACK Gen Count value field 722. When the BB circuit 103 identifies redundant duplicate TCP ACK packets, the replacement candidate index field 724 and the winner index field 726 of the entry store the position of the redundant duplicate packet to be discarded and the position of the TCP ACK packet to be retained respectively. For example, entry 702 has the queue position of packet #10 (referred to as the packet #10 index) in its replacement candidate index field 724 and the queue position of packet #13 (referred to as the packet #13 index) in its winner index field 726. Thus, when the output queue 107 is compressed, as described with respect to Figure 4 and Figure 5 the BB circuit 103 swaps the positions of packet #10 and packet #13 and discards packet #10.

[0175] When the BB circuit 103 starts inspecting the output queue 107 in each iteration, the BB circuit resets the database 106 by clearing all entries. As previously described, when inspecting TCP ACK packets in the output queue, if the BB circuit 103 does not find an entry in the database 106 that matches the flow ID of the packet, the BB circuit 103 creates a new entry in the database 106 and enters the flow ID, the ACK Gen Count value, and the queue position of the packet in the corresponding fields of the entry, as described with respect to the output queue configurations 402 - 408 and the process 500. For example, this occurs when inspecting the latest packet corresponding to a specific flow ID and ACK Gen Count interval. For example, as described with respect to Figure 4 and Figure 5As described above, when checking Packet #13 in output queue 107, BB circuit 103 determines that there is no combination of the flow ID ("Flow a") and the ACK Gen Count value ("ackgen 3") of Packet #13 in database 106. Therefore, BB circuit 103 creates a new entry in database 106, such as entry 702, and inputs the flow ID, the ACK Gen Count value, and the queue position of Packet #13 (Packet #13 index) into the corresponding fields 720, 722, and 726 of the newly created entry. BB circuit 103 creates entry 704 when checking Packet #12, and updates the entry when checking Packet #11 that has the same flow ID but a different ACK Gen Count value compared to Packet #12. Similarly, BB circuit 103 creates entry 706 when checking Packet #8, and updates the entry when checking Packet #7.

[0176] On the other hand, when checking a TCP ACK packet in the output queue, if BB circuit 103 finds an entry in database 106 that matches the combination of the flow ID and the ACK Gen Count value of the packet, then BB circuit 103 determines that the currently checked packet is a redundant duplicate. BB circuit 103 marks the packet as pending discard, and records the queue position of the packet in the replacement candidate index field 724 of the corresponding entry, as described with respect to output queue configurations 402-408 and process 500. For example, this occurs when the most recent packet corresponding to a specific flow ID and ACK Gen Count interval has been checked. For example, as described with respect to Figure 4 and Figure 5As described, when packet #10 in output queue 107 is examined, BB circuit 103 determines that the combination of the flow ID ("flow a") and the ACK Gen Count value ("ackgen 3") of packet #10 already exists in entry 702 in database 106 (created when packet #13 was examined). Therefore, BB circuit 103 marks packet #10 as to be discarded and records the queue position of packet #10 ("packet #10 index") in replacement candidate index field 724 of entry 702. Similarly, when packet #6 in output queue 107 is examined, BB circuit 103 determines that the combination of the flow ID ("flow c") and the ACK Gen Count value ("ackgen 87") of the packet already exists in entry 706 in database 106 (updated when packet #11 was examined). Therefore, BB circuit 103 marks packet #6 as to be discarded and records the queue position of packet #6 in replacement candidate index field 724 of entry 706. Next, when packet #5 in output queue 107 is examined (when the queue is examined starting from the latest packet from right to left such that packet #6 is newer than packet #5 in the output queue), BB circuit 103 determines that the combination of the flow ID ("flow c") and the ACK Gen Count value ("ackgen 87") of the packet already exists in entry 706 in database 106. Therefore, BB circuit 103 marks packet #5 as to be discarded and records the queue position of packet #5 in replacement candidate index field 724 of entry 706, thus replacing the previous value recorded in field 724, i.e., the queue position of packet #6.

[0177] Once BB circuit 103 has finished examining output queue 107 in the current iteration, the entries in database 106 are as Figure 7 shown. BB circuit 103 exchanges the positions of the winner packet and the redundant duplicate packet as described with respect to Figure 4 configuration 406 and procedure 500. For example, for flow ID "flow a" and ACK Gen Count value "ackgen 3" (entry 702), BB circuit 103 moves winner packet #13 to the position of redundant packet #10 that is earlier in output queue 107 and known from replacement candidate index field 724 in entry 702.

[0178] In some specific implementations, BB circuit 103 moves redundant packet #10 to the position of winner packet #13 known from winner index field 726 in entry 702. Similar exchanges are made for entries 704 and 706. After the exchanges are complete, BB circuit 103 discards the redundant duplicate packets as described with respect to Figure 4as described in Configuration 408 and Process 500. For example, for flow ID "flow a" and ACK Gen Count value "ackgen 3" (entry 702), BB circuit 103 discards packet #10 that now occupies the position indicated by the winner index field 726.

[0179] Thus, in implementing Process 500, BB circuit 103 utilizes database 106 to optimize output queue 107, thereby removing redundant duplicate packets.

[0180] In some embodiments, the flow ID may be very large (e.g., 116 bits or 128 bits). Storing flow IDs of such large sizes would require a large amount of memory. The time taken to parse the flow ID and find a match in database 106 may be long due to the large size of the flow ID, resulting in additional latency overhead when compressing the output queue. In some embodiments, the size of the flow ID is compacted by using the last X bits of the flow ID as a hash value to perform an initial search in database 106, reducing either the memory storage requirements or the speed of parsing the database or both. In such embodiments, X is a predetermined positive integer less than the number corresponding to the full bit length of the flow ID. For example, X can be 8 bits, 16 bits, or 32 bits, while the full bit length of the flow ID can be 116 bits or 128 bits. In such embodiments, BB circuit 103 uses the hash value as an index in a hash table that stores entries with <flow ID, ack_gen_count> pairs having the same hash value. The table is searched to identify an entry having the same hash value as the hash value of the flow ID of the currently processed TCP ACK packet. Since the number of bits of the hash value is smaller compared to the original flow ID bit length, using the hash value reduces the time required to search database 106.

[0181] In some embodiments, when using the hash value in the above manner, the full flow ID is also stored in the hash table. This is useful for resolving flow ID conflicts (e.g., two or more different flow IDs that map to the same hash value), for example. In such cases, initially, the hash value is used for searching to determine the existence of an entry in the database. This is followed by a second search to locate the entry using the full flow ID. When a hash match and a hash table entry are found, all full flow IDs mapped to the hash value in the hash table entry are verified until a flow ID that matches the flow ID of the packet being examined is found. If no match is found, the flow ID of the packet is stored in the same hash table entry. Thus, the hash table entry includes a linear list of flow IDs that are hashed to the hash value corresponding to the entry. Using the hash in the above manner involves a trade-off between memory consumption (e.g., large hash table, but fewer conflicts) and speed (e.g., small hash table, but greater search effort due to flow ID conflicts). The size of the hash value is selected based on the trade-off.

[0182] In some specific implementations, the complexity of TCP ACK optimization is O(n), where n is the number of packets in the output queue. That is, the complexity of TCP ACK optimization increases linearly with the growth of n. To reduce computational resource consumption and save power, it is desirable to have the flexibility to turn TCP ACK optimization on or off. Therefore, a client device (e.g., client device 102) can be configured with features that subject TCP ACK optimization to various conditions. Implementing these features can be useful in devices or applications such as a modem operating in a low-power mode or a consumer electronic device with an affordable hardware configuration (e.g., a low-end smartwatch and a mobile phone). The following refers to Figures 8A to 8G the example shown in Figures 8A to 8G to describe exemplary TCP ACK optimization conditions. Figures 2 to 7 The example shown in

[0183] Figures 8A to 8G focuses on the operation between an application processor (AP) 810 and a baseband (BB) circuit 820. In some specific implementations, the AP 810 is similar to the TCP AP 105, and the BB circuit 820 is similar to the BBU 103. As shown in the figure, the AP 810 includes an application block 811 and an IP stack 812, and the BB circuit 820 includes a TCP-Ack optimization block 821 and a layer 2 (L2) block 822. The application block 811, the IP stack block 812, the TCP-Ack optimization block 821, and the L2 block 822 can be functional blocks implemented by software code and / or hardware circuits. The AP 810 outputs an uplink packet stream 830 to the BB circuit 820. After processing the uplink packet stream 830 with the L2 block 822, the BB circuit 820 outputs the uplink packet stream 830 to, for example, the physical (PHY) layer for wireless transmission.

[0184] Figure 8A shows an exemplary condition 800A for turning TCP ACK optimization on or off according to some disclosed specific implementations. The condition 800A is based on determining whether the packet loss rate 824 is below a threshold. The packet loss rate 824 can be a parameter that describes how quickly the packets stored in the L2 queue 823 are processed (e.g., removed from the queue and transmitted to the PHY). To determine the condition 800A, the TCP-Ack optimization block 821 receives the packet loss rate 824 from the L2 block 822 and determines whether to turn on TCP ACK optimization to reduce the backlog. If the packet loss rate 824 exceeds the threshold, the TCP ACK optimization block 821 can infer that the backlog in the L2 queue 823 is low. If the packet loss rate 824 is below the threshold, the TCP ACK optimization block 821 can infer that the backlog in the L2 queue 823 is high and needs optimization.

[0185] Figure 8B Illustrates exemplary condition 800B for enabling or disabling TCP ACK optimization according to some disclosed embodiments. Condition 800B is applicable when uplink packets from AP 810 to BB circuit 820 are divided into multiple queues, including a high-priority queue 825 for high-priority data and a best-effort queue 826 for best-effort data without strict requirements on priority (e.g., TCP data packets in File Transfer Protocol (FTP) uploads). Condition 800B is based on determining whether the uplink packet to be transmitted belongs to a specific queue among the multiple queues. In an example, AP 810 is configured to transmit all TCK ACKs in high-priority queue 825. In this case, since high-priority queue 825 is the only queue with TCP ACKs, TCP ACK optimization is enabled only for high-priority queue 825 and disabled for other queues. In another example, AP 810 is also configured to transmit TCP ACKs in best-effort queue 826, but at a lower speed than the data in high-priority queue 825. In this case, TCP ACK optimization is enabled only for best-effort queue 826 to improve processing efficiency, and TCP ACK optimization is disabled for other queues.

[0186] Figure 8C Illustrates exemplary condition 800C for enabling or disabling TCP ACK optimization according to some disclosed embodiments. Condition 800C is applicable when multiple DRBs (e.g., radio bearers for transmitting data) are available for L2 block to process uplink packets. In this case, condition 800C can specify certain DRBs for TCP ACK optimization. In an example, TCP ACK optimization is enabled only for the default DRB used to process the Internet PDN. In an example, TCP ACK optimization is enabled only for DRBs whose throughput is within a given range (e.g., the DRB with the highest throughput, the DRB with the lowest throughput, the DRB whose throughput is below a threshold, or the DRB whose throughput is above a threshold). In an example, TCP ACK optimization is enabled only for bidirectional DRBs (e.g., DRBs with both uplink data and incoming downlink data).

[0187] Figure 8D Illustrates exemplary condition 800D for enabling or disabling TCP ACK optimization according to some disclosed embodiments. Condition 800D is applicable when multiple PDNs are available from AP 810 to BB circuit 820. Since not all PDNs have high throughput, condition 800D can select one or more PDNs for TCP ACK optimization based on, for example, the throughput requirements of the PDN.

[0188] Figure 8E Illustrates exemplary condition 800E for enabling or disabling TCP ACK optimization according to some disclosed embodiments. Condition 800E is based on the power mode of the client device. When the client device operates in a low power mode controlled by power control block 827, TCP ACK optimization can be disabled to save power. Otherwise, TCP ACK optimization can be enabled to improve data transmission efficiency.

[0189] Figure 8F Illustrates exemplary condition 800F for enabling or disabling TCP ACK optimization according to some disclosed embodiments. Condition 800F applies when IP stack 812 divides uplink data into a stream of multiple IP packets. In this case, condition 800F can select certain IP packet streams for TCP ACK optimization. Exemplary selection criteria include historical information of the IP packet stream and information on TCP receive window adaptation. For example, when the UE recognizes that there are a large number of TCP ACKs in the previous packets of a specific stream, the UE can enable TCP ACK optimization for all subsequent packets of the same stream. Conversely, when the UE recognizes that there are no TCP ACKs in the previous packets of a specific stream, the UE can disable TCP ACK optimization for the same stream. Additionally, the UE can be configured to enable TCP ACK optimization when the TCP sliding window is small (e.g., less than a given threshold) in order to reduce the number of packets sent. These criteria can be based on stream information 828 provided by, for example, IP stack 812.

[0190] Figure 8G Illustrates exemplary condition 800G for enabling or disabling TCP ACK optimization according to some disclosed embodiments. Condition 800G is based on determining whether BB circuit 820 detects a downlink TCP data packet 829. For example, TCP ACK optimization can only be enabled when BB circuit 820 detects a downlink TCP data packet 829. This is because when there is no downlink TCP data, TCP ACKs will not be sent in the uplink direction, and thus TCP ACK optimization is not required.

[0191] The conditions described above with respect to Figures 8A to 8G the examples, together with other possible conditions for enabling and disabling TCP ACK optimization, provide the client device with great flexibility in balancing performance metrics such as power consumption, computing resources, hardware complexity, and transmission latency. The client device can implement one or more of these conditions according to its specific performance needs.

[0192] Figure 9An example of infrastructure equipment 900 according to various specific embodiments is shown. Infrastructure equipment 900 (or "system 900") can be implemented as a base station, radio headend, RAN node (such as the RAN nodes 112a and 112b and / or AP 104 shown and described previously), application server 110, and / or any other element / device discussed herein. In other examples, system 900 can be implemented in or by client device 102. System 900 includes application circuit 905, baseband circuit 910, one or more radio front-end modules (RFEMs) 915, memory circuit 920, program 922 stored in memory 920, power management integrated circuit (PMIC) 925, power triple circuit 930, network controller circuit 935, network interface connector 940, satellite positioning circuit 945, and user interface 950.

[0193] In some specific embodiments, device 900 can include additional elements, such as, for example, memory / storage, display, camera, sensor, or input / output (I / O) interface. In other specific embodiments, these components can be included in more than one device. For example, the circuits can be separately included in more than one device for CRAN, vBBU, or other similar specific embodiments.

[0194] Application circuit 905 can include circuits such as, but not limited to, one or more processors (or processor cores), cache memory, and one or more of the following: low-dropout regulator (LDO), interrupt controller, serial interface such as SPI, I2C, or general programmable serial interface module, real-time clock (RTC), timer-counter (including interval timer and watchdog timer), general-purpose input / output (I / O or IO), memory card controller such as secure digital (SD) multimedia card (MMC) or similar products, universal serial bus (USB) interface, mobile industry processor interface (MIPI) interface, and joint test access group (JTAG) test access port. The processor (or core) of application circuit 905 can be coupled to or can include memory / storage elements, and can be configured to execute instructions stored in the memory / storage device to enable various application programs or operating systems to run on system 900. In some specific embodiments, the memory / storage elements can be on-chip memory circuits, which can include any suitable volatile and / or non-volatile memory, such as DRAM, SRAM, EPROM, EEPROM, flash memory, solid-state memory, and / or any other type of memory device technology, such as those discussed herein.

[0195] The processor of application circuit 905 may include, for example, one or more processor cores (CPUs), one or more application processors, one or more graphics processing units (GPUs), one or more reduced instruction set computing (RISC) processors, one or more Acorn RISC machines (ARM) processors, one or more complex instruction set computing (CISC) processors, one or more digital signal processors (DSPs), one or more FPGAs, one or more PLDs, one or more ASICs, one or more microprocessors or controllers, or any suitable combination thereof.

[0196] In some specific embodiments, application circuit 905 may include or be a dedicated processor / controller for operating according to the various specific embodiments herein. As an example, the processor of application circuit 905 may include one or more Apple A-series processors, Intel or processors; Advanced Micro Devices (AMD) processors, accelerated processing units (APUs), or processors; ARM-based processors licensed by ARM Holdings, Ltd., such as ARM Cortex-A series processors provided by Cavium (TM), Inc. and MIPS-based designs from MIPS Technologies, Inc., such as MIPS Warrior P-class processors; and so on. In some specific embodiments, system 900 may not utilize application circuit 905, but may include a dedicated processor or controller to process, for example, IP data received from the EPC or 5GC.

[0197] In some specific embodiments, application circuit 905 may include one or more hardware accelerators, which may be microprocessors, programmable processing devices, etc. The one or more hardware accelerators may include, for example, computer vision (CV) and / or deep learning (DL) accelerators. For example, the programmable processing device may be one or more field programmable devices (FPDs), such as field programmable gate arrays (FPGAs), etc.; programmable logic devices (PLDs), such as complex PLDs (CPLDs), high-capacity PLDs (HCPLDs), etc.; ASICs, such as structured ASICs, etc.; programmable system on a chip (PSoCs); and so on. In such specific embodiments, the circuit of application circuit 905 may include logic blocks or logic architectures, and other interconnected resources that can be programmed to perform various functions such as programs, methods, functions, etc.

[0198] In such specific implementations, the circuitry of application circuit 905 may include memory units for storing logic blocks, logic architectures, data, etc. (e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, static memory (e.g., static random access memory (SRAM), antifuse, etc.)).

[0199] Baseband circuit 910 may be implemented as, for example, a solder-in substrate that includes one or more integrated circuits, a single packaged integrated circuit soldered to a main circuit board, or a multi-chip module that includes two or more integrated circuits.

[0200] User interface circuit 950 may include one or more user interfaces designed to enable a user to interact with system 900, or a peripheral component interface designed to enable a peripheral component to interact with system 900. The user interface may include, but is not limited to, one or more physical or virtual buttons (e.g., reset button), one or more indicators (e.g., light-emitting diode (LED)), physical keyboard or keypad, mouse, touchpad, touch screen, speaker or other audio emitting device, microphone, printer, scanner, headset, display screen or display device, etc. The peripheral component interface may include, but is not limited to, a non-volatile memory port, a universal serial bus (USB) port, an audio jack, a power interface, etc.

[0201] Radio frequency front-end module (RFEM) 915 may include a millimeter wave (mmWave) RFEM and one or more sub-millimeter wave radio frequency integrated circuits (RFICs). In some specific implementations, the one or more sub-millimeter wave RFICs may be physically separated from the millimeter wave RFEM. The RFIC may include connections to one or more antennas or antenna arrays, and the RFEM may be connected to multiple antennas. In an alternative specific implementation, the radio functions of both millimeter wave and sub-millimeter wave may be implemented in the same physical RFEM 915 that combines millimeter wave antennas and sub-millimeter wave.

[0202] Memory circuit 920 may include one or more of the following: volatile memory that includes dynamic random access memory (DRAM) and / or synchronous dynamic random access memory (SDRAM); and non-volatile memory (NVM) that includes high-speed electrically erasable memory (commonly referred to as flash memory), phase change random access memory (PRAM), magnetoresistive random access memory (MRAM), etc., and may incorporate and three-dimensional (3D) cross-point (XPOINT) memory. Memory circuit 920 may be implemented as one or more of the following: a solder-in packaged integrated circuit, a socketed memory module, and a plug-in memory card.

[0203] PMIC 925 may include a voltage regulator, a surge protector, a power alarm detection circuit, and one or more backup power supplies, such as a battery or capacitor. The power alarm detection circuit may detect one or more of a brownout (undervoltage) and a surge (overvoltage) condition.

[0204] The power tee circuit 930 can provide power extracted from the network cable to provide both power and data connections to the infrastructure equipment 900 using a single cable.

[0205] The network controller circuit 935 may provide a connection to the network using a standard network interface protocol such as Ethernet, Ethernet based on a GRE tunnel, Ethernet based on a multi-protocol label switching (MPLS), or some other suitable protocol. A physical connection may be used to provide a network connection to / from the infrastructure equipment 900 via a network interface connector 940, which may be an electrical connection (commonly referred to as a "copper interconnect"), an optical connection, or a wireless connection. The network controller circuit 935 may include one or more dedicated processors and / or FPGAs for communicating using one or more of the aforementioned protocols. In some specific implementations, the network controller circuit 935 may include multiple controllers for providing connections to other networks using the same or different protocols.

[0206] Positioning circuit 945 includes circuits for receiving and decoding signals transmitted / broadcasted by a positioning network of a global navigation satellite system (GNSS). Examples of navigation satellite constellations (or GNSS) include the United States' Global Positioning System (GPS), Russia's Global Navigation System (GLONASS), the European Union's Galileo system, China's BeiDou Navigation Satellite System, regional navigation systems or GNSS augmentation systems (e.g., navigation using the Indian constellation (NAVIC), Japan's Quasi-Zenith Satellite System (QZSS), France's Doppler Orbit Chart and Satellite Integrated Radio Positioning (DORIS), etc.), etc.

[0207] The positioning circuit 945 may include various hardware components (e.g., including hardware devices for facilitating OTA communication such as switches, filters, amplifiers, antenna elements, etc.) to communicate with components of a positioning network such as nodes of a navigation satellite constellation. In some embodiments, the positioning circuit 945 may include a microtechnology for positioning, navigation, and timing (micro-PNT) IC that uses a primary timing clock to perform position tracking / estimation without GNSS assistance. The positioning circuit 945 may also be part of or interact with the baseband circuit 910 and / or the RFEM 915 to communicate with nodes and components of the positioning network. The positioning circuit 945 may also provide position data and / or time data to the application circuit 905, which may use this data to synchronize operations with various infrastructure (e.g., RAN nodes 112a, 112b, etc.).

[0208] Figure 9 The components shown may communicate with each other using an interface circuit, which may include any number of bus and / or interconnect (IX) technologies such as Industry Standard Architecture (ISA), Extended ISA (EISA), Peripheral Component Interconnect (PCI), Peripheral Component Interconnect Extended (PCIx), PCI Express (PCIe), or any number of other technologies. The bus / IX may be a proprietary bus, e.g., a proprietary bus used in an SoC-based system. Other bus / IX systems may be included, such as an I2C interface, an SPI interface, a point-to-point interface, and a power bus, etc.

[0209] Figure 10 An example of a computer platform 1000 (or “device 1000”) is shown according to various embodiments. In some embodiments, the computer platform 1000 may be adapted to be used as a client device 102, an application server 110, and / or any other element / device discussed herein. The platform 1000 may include any combination of the components shown in the example. The components of the platform 1000 may be implemented as integrated circuits (ICs), portions of ICs, discrete electronic devices, or other modules, logic, hardware, software, firmware, or combinations thereof adapted within the computer platform 1000, or as components otherwise incorporated within the chassis of a larger system. Figure 10 The block diagram is intended to show a high-level view of the components of the computer platform 1000. However, some of the components shown may be omitted, additional components may exist, and different arrangements of the shown components may occur in other embodiments.

[0210] The application circuit 1005 includes circuitry such as, but not limited to, one or more processors (or processor cores), cache memory, and one or more of the following: LDO, interrupt controller, serial interfaces (such as SPI), I2C or general programmable serial interface module, RTC, timers (including interval timers and watchdog timers), general-purpose I / O, memory card controllers (such as SD MMC or similar controllers), USB interfaces, MIPI interfaces, and JTAG test access ports. The processor (or core) of the application circuit 1005 may be coupled to or may include memory / storage elements and may be configured to execute instructions stored in the memory / storage device to enable various applications or operating systems to run on the system 1000. In some specific embodiments, the memory / storage element may be an on-chip memory circuit, which may include any suitable volatile and / or non-volatile memory such as DRAM, SRAM, EPROM, EEPROM, flash memory, solid-state memory, and / or any other type of memory device technology such as those discussed herein.

[0211] The processor of the application circuit 1005 may include, for example, one or more processor cores, one or more application processors, one or more GPUs, one or more RISC processors, one or more ARM processors, one or more CISC processors, one or more DSPs, one or more FPGAs, one or more PLDs, one or more ASICs, one or more microprocessors or controllers, multi-threaded processors, ultra-low voltage processors, embedded processors, some other known processing elements, or any suitable combination thereof.

[0212] In some specific embodiments, the application circuit 1005 may include or may be a dedicated processor / controller for operating according to the various specific embodiments herein. As an example, the processor of the application circuit 1005 may include an Apple A series processor. The processor of the application circuit 1005 may also be one or more of the following: a processor based on ArchitectureCore TM such as Quark TM , Atom TM , i3, i5, i7, or MCU-class processors, or another such processor available from Corporation, Santa Clara, CA ; Advanced Micro Devices (AMD) processors or accelerated processing units (APUs); from Snapdragon from Technologies, Inc. TM processors, Texas Instruments, Open Multimedia Applications Platform (OMAP) TM processors; MIPS-based designs from MIPS Technologies, Inc., such as MIPS Warrior M-class, Warrior I-class, and Warrior P-class processors; ARM-based designs licensed from ARM Holdings, Ltd., such as ARM Cortex-A, Cortex-R, and Cortex-M series processors; etc.

[0213] In some specific embodiments, the application circuit 1005 may be part of a system-on-chip (SoC), where the application circuit 1005 and other components are formed as a single integrated circuit. Additionally or alternatively, the application circuit 1005 may include circuitry, such as but not limited to one or more field programmable devices (FPDs) such as FPGAs, etc.; programmable logic devices (PLDs), such as complex PLDs (CPLDs), high-capacity PLDs (HCPLDs), etc.; ASICs, such as structured ASICs, etc.; programmable SoCs (PSoCs); and so on. In such specific embodiments, the circuitry of the application circuit 1005 may include logic blocks or logic architectures, as well as other interconnect resources that can be programmed to perform various functions such as programs, methods, functions, etc.

[0214] In some specific embodiments, the circuitry of the application circuit 1005 may include memory units for storing logic blocks, logic architectures, data, etc. (e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, static memory (e.g., static random access memory (SRAM), antifuse, etc.)). In some specific embodiments, the client device 102 may include one or more processors configured to execute software instructions stored in the application circuit 1005. The application circuit 1005 may include an output queue optimizer 1048.

[0215] The baseband circuit 1010 may be implemented as, for example, a soldered-in substrate that includes one or more integrated circuits, a single-packaged integrated circuit soldered to a main circuit board, or a multi-chip module that includes two or more integrated circuits. In some specific implementations, the baseband circuit 1010 is similar to the baseband circuit 103. In some specific implementations, operations performed through the interaction between the output queue optimizer 1048 and the baseband circuit 1010 are similar to the operations performed by the BB circuit 103 to manage the output queue 107. For example, this may occur when one or more processors associated with the BB circuit 103 execute instructions to perform operations similar to those performed by the output queue optimizer 1048 and the baseband circuit 1010.

[0216] The RFEM 1015 may include a millimeter-wave (mmWave) RFEM and one or more sub-millimeter-wave radio frequency integrated circuits (RFICs). In some specific implementations, the one or more sub-millimeter-wave RFICs may be physically separated from the millimeter-wave RFEM. The RFIC may include connections to one or more antennas or antenna arrays, and the RFEM may be connected to multiple antennas. In an alternative specific implementation, the radio functions of both millimeter-wave and sub-millimeter-wave may be implemented in the same physical RFEM 1015 that combines millimeter-wave antennas and sub-millimeter-wave.

[0217] The memory circuit 1020 may include any number and type of memory devices for providing a given amount of system memory. For example, the memory circuit 1020 may include one or more of the following: volatile memory including random access memory (RAM), dynamic RAM (DRAM), and / or synchronous dynamic RAM (SDRAM), non-volatile memory (NVM) including high-speed electrically erasable memory (commonly referred to as flash memory), phase change random access memory (PRAM), magnetoresistive random access memory (MRAM), etc.

[0218] The memory circuit 1020 can be developed according to Joint Electron Device Engineering Council (JEDEC) low-power double data rate (LPDDR)-based designs such as LPDDR2, LPDDR3, LPDDR4, etc. The memory circuit 1020 can be implemented as one or more of the following: a soldered-in package integrated circuit, a single-die package (SDP), a dual-die package (DDP), or a quad-die package (Q17P), a socketed memory module, a dual in-line memory module (DIMM) including a micro DIMM or a mini DIMM, and / or soldered to a motherboard via a ball grid array (BGA). In a low-power implementation, the memory circuit 1020 can be an on-chip memory or register associated with the application circuit 1005. To provide persistent storage of information such as data, applications, operating systems, etc., the memory circuit 1020 can include one or more mass storage devices, which can particularly include solid state disk drives (SSDDs), hard disk drives (HDDs), micro HDDs, resistive change memories, phase change memories, holographic memories, or chemical memories, etc. For example, the computer platform 1000 can incorporate 3D cross-point (XPOINT) memory obtained from and .

[0219] The removable memory circuit 1023 can include devices, circuits, enclosures / cases, ports, or sockets, etc., for coupling a portable data storage device to the platform 1000. These portable data storage devices can be used for mass storage and can include, for example, flash memory cards (e.g., Secure Digital (SD) cards, micro SD cards, xD Picture cards, etc.) and USB flash drives, optical discs, external HDDs, etc.

[0220] The platform 1000 can also include interface circuitry (not shown) for connecting external devices to the platform 1000. External devices connected to the platform 1000 via this interface circuitry include sensor circuit 1021 and electromechanical components (EMC) 1022, as well as removable memory devices coupled to the removable memory circuit 1023.

[0221] The sensor circuit 1021 includes a device, module, or subsystem intended to detect an event or change in its environment and to send information (sensor data) about the detected event to some other device, module, subsystem, etc. Examples of such sensors include, in particular: an inertial measurement unit (IMU) including an accelerometer, a gyroscope, and / or a magnetometer; a microelectromechanical system (MEMS) or nanoelectromechanical system (NEMS) including a three-axis accelerometer, a three-axis gyroscope, and / or a magnetometer; a liquid level sensor; a flow sensor; a temperature sensor (e.g., a thermistor); a pressure sensor; a barometric pressure sensor; a gravimeter; an altimeter; an image capture device (e.g., a camera or a lensless aperture); a light detection and ranging (LiDAR) sensor; a proximity sensor (e.g., an infrared radiation detector, etc.), a depth sensor, an ambient light sensor, an ultrasonic transceiver; a microphone or other similar audio capture device; etc.

[0222] The EMC 1022 includes a device, module, or subsystem intended to enable the platform 1000 to change its state, position, and / or orientation or to move or control a mechanism or (sub)system. Additionally, the EMC 1022 may be configured to generate messages / signaling and send messages / signaling to other components of the platform 1000 to indicate the current state of the EMC 1022. The EMC 1022 includes one or more power switches, relays (including an electromechanical relay (EMR) and / or a solid-state relay (SSR)), actuators (e.g., a valve actuator, etc.), an audible sound generator, a visual warning device, a motor (e.g., a DC motor, a stepper motor, etc.), a wheel, a thruster, a propeller, a claw, a clamp, a hook, and / or other similar electromechanical components. In a specific implementation, the platform 1000 is configured to operate one or more EMC 1022 based on one or more captured events and / or instructions or control signals received from a service provider and / or various clients.

[0223] In some specific implementations, the interface circuit may connect the platform 1000 to the positioning circuit 1045. The positioning circuit 1045 includes circuitry for receiving and decoding signals transmitted / broadcast by the positioning network of GNSS. Examples of navigation satellite constellations (or GNSS) include GPS of the United States, GLONASS of Russia, Galileo system of the European Union, Beidou Navigation Satellite System of China, regional navigation systems, or GNSS augmentation systems (e.g., NAVIC, QZSS of Japan, DORIS of France, etc.). The positioning circuit 1045 may include various hardware components (e.g., including hardware devices for facilitating OTA communication such as switches, filters, amplifiers, antenna elements, etc.) to communicate with components of the positioning network such as navigation satellite constellation nodes. In some specific implementations, the positioning circuit 1045 may include a micro PNT IC that uses the main timing clock to perform position tracking / estimation without GNSS assistance. The positioning circuit 1045 may also be part of or interact with the baseband circuit 1010 and / or the RFEM 1015 to communicate with nodes and components of the positioning network. The positioning circuit 1045 may also provide position data and / or time data to the application circuit 1005, which may use this data to synchronize operations with various infrastructures (e.g., radio base stations) for turn-by-turn navigation applications, etc.

[0224] In some specific implementations, the interface circuit may connect the platform 1000 to the near field communication (NFC) circuit 1040. The NFC circuit 1040 is configured to provide non-contact short-range communication based on the radio frequency identification (RFID) standard, where magnetic field sensing is used to enable communication between the NFC circuit 1040 and an NFC-enabled device external to the platform 1000 (e.g., an "NFC contact point"). The NFC circuit 1040 includes an NFC controller coupled to an antenna element and a processor coupled to the NFC controller. The NFC controller may be a chip / IC that provides NFC functionality to the NFC circuit 1040 by executing NFC controller firmware and an NFC stack. The NFC stack may be executed by the processor to control the NFC controller, and the NFC controller firmware may be executed by the NFC controller to control the antenna element to transmit short-range RF signals. The RF signals may power a passive NFC tag (e.g., a microchip embedded in a sticker or wristband) to transfer stored data to the NFC circuit 1040, or initiate data transfer between the NFC circuit 1040 and another active NFC device (e.g., a smart phone or an NFC-enabled POS terminal) near the platform 1000.

[0225] The drive circuit 1046 may include software elements and hardware elements for controlling specific devices embedded in, attached to, or otherwise communicatively coupled with the platform 1000. The drive circuit 1046 may include respective drivers, thereby allowing other components of the platform 1000 to interact with or control various input / output (I / O) devices that may be present within or connected to the platform 1000. For example, the drive circuit 1046 may include: a display driver for controlling and allowing access to a display device, a touchscreen driver for controlling and allowing access to the touchscreen interface of the platform 1000, a sensor driver for obtaining sensor readings of the sensor circuit 1021 and controlling and allowing access to the sensor circuit 1021, an EMC driver for obtaining the actuator position of the EMC 1022 and / or controlling and allowing access to the EMC 1022, a camera driver for controlling and allowing access to an embedded image capture device, and an audio driver for controlling and allowing access to one or more audio devices.

[0226] A power management integrated circuit (PMIC) 1025 (also referred to as “power management circuit 1025”) may manage the power provided to various components of the platform 1000. Specifically, with respect to the baseband circuit 1010, the PMIC 1025 may control power selection, voltage regulation, battery charging, or DC-DC conversion. When the platform 1000 is capable of being powered by a battery 1030, e.g., when the device is included in the client device 102, the PMIC 1025 is typically included.

[0227] In some specific implementations, the PMIC 1025 can control or otherwise be part of various power-saving mechanisms of the platform 1000. For example, if the platform 1000 is in the RRC_Connected state, in which the platform remains connected to the RAN node because it expects to receive traffic soon, then after a period of inactivity, the platform can enter a state called discontinuous reception mode (DRX). During this state, the platform 1000 can power down for short intervals, thus saving power. If there is no data traffic activity for an extended period, the platform 1000 can transition to the RRC_Idle state, in which the device disconnects from the network and does not perform operations such as channel quality feedback, handover, etc. The platform 1000 enters a very low power state and performs paging, in which the device wakes up periodically again to listen for the network and then powers down again. The platform 1000 cannot receive data in this state; to receive data, the platform must transition back to the RRC_Connected state. Additional power-saving modes can cause the device to be unavailable to the network for longer than the paging interval (ranging from a few seconds to several hours). During this period, the device is completely unable to connect to the network and can be powered down completely. Any data sent during this period will incur a significant delay, and it is assumed that the delay is acceptable.

[0228] The battery 1030 can power the platform 1000, but in some examples, the platform 1000 can be installed and deployed in a fixed location and can have a power source coupled to the power grid. The battery 1030 can be a lithium-ion battery, a metal-air battery such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, etc. In some specific implementations, such as in V2X applications, the battery 1030 can be a typical lead-acid automotive battery.

[0229] In some specific implementations, the battery 1030 can be a "smart battery" that includes or is coupled to a battery management system (BMS) or a battery monitoring integrated circuit. The BMS can be included in the platform 1000 to track the state of charge (SoCh) of the battery 1030. The BMS can be used to monitor other parameters of the battery 1030, such as the state of health (SoH) and the state of function (SoF) of the battery 1030, to provide fault prediction. The BMS can transmit information about the battery 1030 to the application circuit 1005 or other components of the platform 1000. The BMS can also include an analog-to-digital (ADC) converter that allows the application circuit 1005 to directly monitor the voltage of the battery 1030 or the current from the battery 1030. Battery parameters can be used to determine actions that the platform 1000 can perform, such as transmission frequency, network operation, sensing frequency, etc.

[0230] A power block or other power source coupled to the power grid can be coupled to the BMS to charge the battery 1030. In some examples, the power block 1030 can be replaced with a wireless power receiver to wirelessly obtain power, for example, through a loop antenna in the computer platform 1000. In these examples, the wireless battery charging circuit can be included in the BMS. The specific charging circuit selected can depend on the size of the battery 1030 and thus on the required current. Charging can be performed using the aviation fuel standards published by the Aviation Fuel Alliance, the Qi wireless charging standards published by the Wireless Power Consortium, or the Rezence charging standards published by the Wireless Power Consortium.

[0231] The user interface circuit 1050 includes various input / output (I / O) devices present within or connected to the platform 1000 and includes one or more user interfaces designed to enable interaction with the user of the platform 1000 and / or a peripheral component interface designed to enable interaction with peripheral components of the platform 1000.

[0232] The user interface circuit 1050 includes input device circuitry and output device circuitry. The input device circuitry includes any physical or virtual device for accepting input, particularly including one or more physical or virtual buttons (e.g., a reset button), a physical keyboard, a keypad, a mouse, a touchpad, a touchscreen, a microphone, a scanner, a headset, etc. The output device circuitry includes any physical or virtual device for displaying information or otherwise communicating information (such as sensor readings, actuator positions, or other similar information). The output device circuitry can include any number and / or combination of audio or visual displays, particularly including one or more simple visual outputs / indicators (e.g., binary state indicators (e.g., light-emitting diodes (LEDs)) and multi-character visual outputs, or more complex outputs such as a display device or a touchscreen (e.g., a liquid crystal display (LCD), an LED display, a quantum dot display, a projector, etc.), where the output of characters, graphics, multimedia objects, etc. is generated or produced by the operation of the platform 1000. The output device circuitry can also include a speaker or other audio emitting device, a printer, etc.

[0233] In some specific implementations, the sensor circuit 1021 can be used as input device circuitry (e.g., an image capture device, a motion capture device, etc.) and one or more EMCs can be used as output device circuitry (e.g., an actuator for providing haptic feedback, etc.). In another example, an NFC circuit can be included to read an electronic tag and / or connect to another NFC-enabled device, and the NFC circuit includes an NFC controller and a processing device coupled to an antenna element. The peripheral component interface can include, but is not limited to, a non-volatile memory port, a USB port, an audio jack, a power interface, etc.

[0234] Although not shown, the components of platform 1000 may communicate with each other using a suitable bus or interconnect (IX) technology, which may include any number of technologies, including ISA, EISA, PCI, PCIx, PCIe, Time-Triggered Protocol (TTP) systems, FlexRay systems, or any number of other technologies. The bus / IX may be a proprietary bus / IX, such as a proprietary bus used in an SoC-based system. Other bus / IX systems may be included, such as I2C interfaces, SPI interfaces, point-to-point interfaces, and power buses, among others.

[0235] Figure 11 Various protocol functions that may be implemented in a wireless communication device according to various specific implementations are shown. Specifically, Figure 11 Arrangement 1100 is included, which shows the interconnection between various protocol layers / entities. The following description is provided for various protocol layers / entities operating in conjunction with 5G / NR system standards and LTE system standards, but Figure 11 some or all aspects of Figure 11 are also applicable to other wireless communication network systems.

[0236] In addition to other higher layer functions not shown, the protocol layers of arrangement 1100 may also include one or more of PHY 1110, MAC 1120, RLC 1130, PDCP 1140, SDAP 1147, RRC 1155, and NAS layer 1157. These protocol layers may include one or more service access points capable of providing communication between two or more protocol layers (e.g., Figure 11 items 1159, 1156, 1150, 1149, 1145, 1135, 1125, and 1115 in

[0237] The PHY 1110 can transmit and receive physical layer signals 1105, which can be received from or transmitted to one or more other communication devices. The physical layer signals 1105 can include one or more physical channels, such as those discussed herein. The PHY 1110 can also perform link adaptation or adaptive modulation and coding (AMC), power control, cell search (e.g., for initial synchronization and handover purposes), and other measurements used by higher layers, such as the RRC 1155. The PHY 1110 can further perform error detection on transport channels, forward error correction (FEC) coding / decoding of transport channels, modulation / demodulation of physical channels, interleaving, rate matching, mapping to physical channels, and MIMO antenna processing. In a particular implementation, an instance of the PHY 1110 can process requests from an instance of the MAC 1120 via one or more PHY-SAPs 1115 and provide indications thereto. According to some particular implementations, the requests and indications transmitted via the PHY-SAP 1115 can include one or more transport channels.

[0238] An instance of the MAC 1120 can process requests from an instance of the RLC 1130 via one or more MAC-SAPs 1125 and provide indications thereto. These requests and indications transmitted via the MAC-SAP 1125 can include one or more logical channels. The MAC 1120 can perform mapping between logical channels and transport channels, multiplex MAC SDUs from one or more logical channels onto the TBs to be delivered to the PHY 1110 via the transport channels, demultiplex MAC SDUs from the TBs delivered from the PHY 1110 via the transport channels onto one or more logical channels, multiplex MAC SDUs onto the TBs, schedule information reporting, error correction via HARQ, and logical channel prioritization.

[0239] An instance of RLC 1130 may process requests from an instance of PDCP 1140 and provide indications thereto via one or more Radio Link Control Service Access Points (RLC-SAPs) 1135. These requests and indications transmitted via RLC-SAP 1135 may include one or more RLC channels. RLC 1130 may operate in a variety of operation modes, including: Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). RLC 1130 may perform the transmission of upper layer protocol data units (PDUs), error correction by Automatic Repeat reQuest (ARQ) for AM data transmission, and concatenation, segmentation, and reassembly of RLC Service Data Units (SDUs) for UM and AM data transmission. RLC 1130 may also perform re-segmentation of RLC data PDUs for AM data transmission, reordering of RLC data PDUs for UM and AM data transmission, detection of duplicate data for UM and AM data transmission, discarding of RLC SDUs for UM and AM data transmission, detection of protocol errors for AM data transmission, and perform RLC re-establishment.

[0240] An instance of PDCP 1140 may process requests from an instance of RRC 1155 and / or an instance of SDAP 1147 and provide indications thereto via one or more Packet Data Convergence Protocol Service Access Points (PDCP-SAPs) 1145. These requests and indications transmitted via PDCP-SAP 1145 may include one or more radio bearers. PDCP 1140 may perform header compression and decompression of IP data, maintain a PDCP Sequence Number (SN), perform in-sequence delivery of upper layer PDUs upon lower layer re-establishment, eliminate duplication of lower layer SDUs upon re-establishment of the lower layer for radio bearers mapped to RLC AM, encrypt and decrypt control plane data, perform integrity protection and integrity verification on control plane data, control timer-based data discarding, and perform security operations (e.g., encryption, decryption, integrity protection, integrity verification, etc.).

[0241] Instances of SDAP 1147 can process requests from one or more higher layer protocol entities via one or more SDAP-SAPs 1149 and provide indications thereto. These requests and indications transmitted via SDAP-SAP 1149 can include one or more QoS flows. SDAP 1147 can map QoS flows to DRBs and vice versa, and can also mark the QFI in DL packets and UL packets. A single SDAP entity 1147 can be configured for a separate PDU session. In the UL direction, the NG-RAN 112 can control the mapping of QoS flows to DRBs in two different ways (reflection mapping or explicit mapping). For reflection mapping, the SDAP 1147 of the client device 102 can monitor the QFI of DL packets of each DRB, and can apply the same mapping to the packets flowing in the UL direction. For a DRB, the SDAP 1147 of the client device 102 can map UL packets belonging to a QoS flow that corresponds to the QoS flow ID and PDU session observed in the DL packets of that DRB. To implement reflection mapping, the NG-RAN can mark DL packets with the QoS flow ID via the Uu interface. Explicit mapping can involve the RRC 1155 configuring the SDAP 1147 with an explicit mapping rule of QoS flows to DRBs, which can be stored and followed by the SDAP 1147. In a specific implementation, SDAP 1147 can be used only in NR specific implementations and not in LTE specific implementations.

[0242] The RRC 1155 can configure aspects of one or more protocol layers via one or more management service access points (M-SAPs), and the one or more protocol layers can include one or more instances of PHY 1110, MAC 1120, RLC 1130, PDCP 1140, and SDAP 1147. In a specific implementation, an instance of the RRC 1155 can process requests from one or more NAS entities 1157 and provide indications to the one or more NAS entities via one or more RRC-SAPs 1156. The main services and functions of the RRC 1155 can include the broadcast of system information (e.g., included in the MIB or SIB related to the NAS), the broadcast of system information related to the access stratum (AS), the paging, establishment, maintenance, and release of the RRC connection between the client device 102 and the RAN (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release), the establishment, configuration, maintenance, and release of point-to-point radio bearers, security functions including key management, mobility between RATs, and measurement configuration for UE measurement reporting. These MIBs and SIBs can include one or more IEs, each of which can include separate data fields or data structures.

[0243] NAS 1157 can form the top layer of the control plane between the client device 102 and the AMF. NAS 1157 can support the mobility and session management procedures of the client device 102 to establish and maintain an IP connection between the client device 102 and the P-GW in the LTE system.

[0244] According to various specific implementations, one or more protocol entities of the arrangement 1100 can be implemented in the client device 102, the RAN node 112a, the AMF in the NR implementation or the MME in the LTE implementation, the UPF in the NR implementation or the S-GW and P-GW in the LTE implementation, etc., for the control plane or user plane communication protocol stacks between the aforementioned devices. In such implementations, one or more protocol entities that can be implemented in one or more of the client device 102, the gNB 112a, the AMF, etc. can communicate with the corresponding peer protocol entities that can be implemented in another device or on another device (using the services of the corresponding lower-layer protocol entities to perform such communication). In some specific implementations, the gNB-CU of the gNB 112A can host the RRC 1155, SDAP 1147, and PDCP 1140 that control one or more gNB-DU operations of the gNB, and each gNB-DU of the gNB 112A can host the RLC 1130, MAC 1120, and PHY 1110 of the gNB 112A.

[0245] In the first example, the control plane protocol stack can include, in order from the highest layer to the lowest layer, NAS 1157, RRC 1155, PDCP 1140, RLC 1130, MAC 1120, and PHY 1110. In this example, the upper layer 1160 can be built on top of NAS 1157, which includes an IP layer 1161, an SCTP 1162, and an application layer signaling protocol (AP) 1163.

[0246] In the NR implementation, the AP 1163 can be the NG application protocol layer (NGAP or NG-AP) 1163 for the NG interface 113 defined between the NG-RAN node 112A and the AMF, or the AP 1163 can be the Xn application protocol layer (XnAP or Xn-AP) 1163 for the Xn interface 112B defined between two or more RAN nodes 112A.

[0247] The NG-AP 1163 can support the functions of the NG interface 113 and can include an elementary procedure (EP). The NG-AP EP can be an interaction unit between the NG-RAN point 112A and the AMF. The NG-AP 1163 services can include two groups: UE-associated services (e.g., services related to the client device 102) and non-UE-associated services (e.g., services related to the entire NG interface instance between the NG-RAN node 112a and the AMF). These services can include functions, including but not limited to: a paging function for sending a paging request to the NG-RAN nodes 112A involved in a specific paging area; a UE context management function for allowing the AMF to establish, modify, and / or release the UE context in the AMF and the NG-RAN node 112a; a mobility function for the client device 102 in the ECM-CONNECTED mode, for supporting mobility within the system HO in the NG-RAN, and for supporting mobility between systems HO from / to the EPS system; a NAS signaling transmission function for transmitting or rerouting NAS messages between the client device 102 and the AMF; a NAS node selection function for determining the association between the AMF and the client device 102; an NG interface management function for setting the NG interface and monitoring errors on the NG interface; a warning message sending function for providing a means to transmit a warning message via the NG interface or cancel the broadcast of an ongoing warning message; a configuration transmission function for requesting and transmitting RAN configuration information (e.g., SON information, performance measurement (PM) data, etc.) between two RAN nodes 112A via the CN 108; and / or other similar functions.

[0248] The XnAP 1163 can support the functions of the Xn interface 112B and can include an XnAP basic mobility procedure and an XnAP global procedure. The XnAP basic mobility procedure can include procedures for handling UE mobility within the NG RAN 112A (or E-UTRAN), such as handover preparation and cancellation procedures, SN status transmission procedures, UE context retrieval and UE context release procedures, RAN paging procedures, procedures related to dual connectivity, etc. The XnAP global procedures can include procedures that are independent of a specific client device 102, such as Xn interface setup and reset procedures, NG-RAN update procedures, cell activation procedures, etc.

[0249] In the LTE embodiment, the AP 1163 can be the S1 application protocol layer (S1-AP) 1163 for the S1 interface 113 defined between the E-UTRAN node 112A and the MME, or the AP 1163 can be the X2 application protocol layer (X2AP or X2-AP) 1163 for the X2 interface 112B defined between two or more E-UTRAN nodes 112A.

[0250] The S1 application protocol layer (S1-AP) 1163 can support the functions of the S1 interface, and similar to the previously discussed NG-AP, the S1-AP can include S1-AP EPs. The S1-AP EP can be an interaction unit between the E-UTRAN node 112A and the MME within the LTE core network. The S1-AP 1163 services can include two groups: UE-associated services and non-UE-associated services. The functions performed by these services include, but are not limited to: E-UTRAN radio access bearer (E-RAB) management, UE capability indication, mobility, NAS signaling transmission, RAN information management (RIM), and configuration transmission.

[0251] The X2AP 1163 can support the functions of the X2 interface 112B, and can include X2AP basic mobility procedures and X2AP global procedures. The X2AP basic mobility procedures can include procedures for handling UE mobility within the E-UTRAN 108, such as handover preparation and cancellation procedures, SN status transmission procedures, UE context retrieval and UE context release procedures, RAN paging procedures, procedures related to dual connectivity, etc. The X2AP global procedures can include procedures that are independent of a specific client device 102, such as X2 interface setup and reset procedures, load indication procedures, error indication procedures, cell activation procedures, etc.

[0252] The SCTP layer (alternatively referred to as the SCTP / IP layer) 1162 can provide guaranteed delivery of application layer messages (e.g., NGAP or XnAP messages in an NR implementation, or S1-AP or X2AP messages in an LTE implementation). The SCTP 1162 can ensure reliable delivery of signaling messages between the RAN nodes 112a or 112b and the AMF / MME, partially based on the IP protocol supported by the IP 1161. The Internet Protocol layer (IP) 1161 can be used to perform packet addressing and routing functions. In some implementations, the IP layer 1161 can use point-to-point transmission to deliver and transfer PDUs. In this regard, the RAN nodes 112a or 112b can include communication links (e.g., wired or wireless) with the L2 and L1 layers of the MME / AMF to exchange information.

[0253] In a second example, the user plane protocol stack may include, in order from the highest layer to the lowest layer, SDAP 1147, PDCP 1140, RLC 1130, MAC 1120, and PHY 1110. The user plane protocol stack may be used for communication between the client device 102, RAN nodes 112a, 112b, or the serving or packet gateway in an LTE implementation. In this example, the upper layer 1151 may be built on top of SDAP 1147 and may include the User Datagram Protocol (UDP) and IP Security layer (UDP / IP) 1152, the General Packet Radio Service (GPRS) Tunneling Protocol for the user plane layer (GTP-U) 1153, and the user plane PDU layer (UP PDU) 1163.

[0254] The transport network layer 1154 (also referred to as the "transport layer") may be built on top of IP transport, and GTP-U 1153 may be used on top of the UDP / IP layer 1152 (including the UDP layer and the IP layer) to carry user plane PDUs (UP-PDUs). The IP layer (also referred to as the "internet layer") may be used to perform packet addressing and routing functions. The IP layer may assign IP addresses to user data packets in, for example, any one of the IPv4, IPv6, or PPP formats.

[0255] GTP-U 1153 may be used to carry user data within the GPRS core network and between the radio access network and the core network. For example, the user data transmitted may be packets in any one of the IPv4, IPv6, or PPP formats. UDP / IP 1152 may provide a checksum for data integrity, port numbers for addressing different functions at the source and destination, and encryption and authentication for selected data flows. The RAN nodes 112a and 112b and the serving and packet gateway (not shown) may utilize the S1-U interface to exchange user plane data via a protocol stack including the L1 layer (e.g., PHY 1110), L2 layer (e.g., MAC 1120, RLC 1130, PDCP 1140, and / or SDAP 1147), UDP / IP layer 1152, and GTP-U 1153. The serving and packet gateway may utilize the S5 / S8a interface to exchange user plane data via a protocol stack including the L1 layer, L2 layer, UDP / IP layer 1152, and GTP-U 1153. As previously discussed, the NAS protocol may support the mobility and session management procedures of the client device 102 to establish and maintain an IP connection for the client device 102.

[0256] In addition, although Figure 11Not shown, but an application layer may exist above the AP 1163 and / or the transport network layer 1154. The application layer may be a layer in which users of the client device 102, RAN nodes 112a, 112b, or other network elements interact with software applications, such as those executed by the application circuit 905 or the application circuit 1005, respectively. The application layer may also provide one or more interfaces for the software applications to interact with the communication systems (such as the baseband circuits 910 or 1010) of the client device 102, RAN nodes 112a, 112b. In some specific implementations, the IP layer and / or the application layer may provide functions that are the same as or similar to those of layers 5 to 7 or parts thereof of the Open Systems Interconnection (OSI) model (e.g., OSI layer 7 - application layer, OSI layer 6 - presentation layer, and OSI layer 5 - session layer).

[0257] Figure 12 is a block diagram showing components capable of reading instructions from a machine-readable medium or a computer-readable medium (e.g., a non-transitory machine-readable storage medium) and executing any one or more of the methods discussed herein. Specifically, Figure 12 shows a schematic diagram of the hardware resources 1200, which includes one or more processors (or processor cores) 1210, one or more memory / storage devices 1220, and one or more communication resources 1230, each of which may be communicatively coupled via a bus 1240. For specific implementations in which node virtualization (e.g., NFV) is utilized, a hypervisor 1202 may be executed to provide an execution environment for one or more network slices / sub-slices to utilize the hardware resources 1200.

[0258] The processor 1210 may include, for example, the processor 1212 and the processor 1214. The processor 1210 may be, for example, a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a DSP such as a baseband processor, an ASIC, an FPGA, a radio frequency integrated circuit (RFIC), another processor (including those discussed herein), or any suitable combination thereof.

[0259] The memory / storage device 1220 may include a main memory, a disk storage device, or any suitable combination thereof. The memory / storage device 1220 may include, but is not limited to, any type of volatile or non-volatile memory, such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid-state storage devices, etc.

[0260] The communication resource 1230 may include an interconnect or network interface component or other suitable device to communicate with one or more peripheral devices 1204 or one or more databases 1206 via a network 1208. For example, the communication resource 1230 may include a wired communication component (e.g., for coupling via USB), a cellular communication component, an NFC component, (or low-power) component, a Wi- component, and other communication components.

[0261] The instructions 1250 may include software, programs, applications, applets, applications, or other executable code for causing at least any one of the processors 1210 to execute any one or more of the method sets discussed herein. The instructions 1250 may reside, in whole or in part, in at least one of the processors 1210 (e.g., within the cache memory of the processor), the memory / storage device 1220, or any suitable combination thereof. Additionally, any portion of the instructions 1250 may be transferred from any combination of the peripheral devices 1204 or the database 1206 to the hardware resource 1200. Accordingly, the memory of the processors 1210, the memory / storage device 1220, the peripheral devices 1204, and the database 1206 are examples of computer-readable and machine-readable media. In some particular implementations, the hardware resource 1200 may be included in the client device 102. The client device 102 may include one or more processors similar to the processor 1210 configured to execute software instructions that, when executed, perform various functions such as the programs, methods, functions discussed herein.

[0262] It is well known that the use of personally identifiable information should follow privacy policies and practices that are generally recognized as meeting or exceeding industry or government requirements for maintaining user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of inadvertent or unauthorized access or use, and the nature of the authorized use should be clearly explained to the user.

[0263] The subject matter and specific implementations of the functional operations described in this specification can be implemented in digital electronic circuitry, in tangibly embodied computer software or firmware, in computer hardware (including the structures disclosed in this specification and structural equivalents thereof), or in combinations of one or more of them. The software specific implementation of the subject matter can be implemented as one or more computer programs. Each computer program can include one or more modules of computer program instructions encoded on a tangible non-transitory computer-readable computer storage medium for execution by, or to control the operation of, a data processing apparatus. Alternatively or additionally, the program instructions can be encoded in / on an artificially generated propagated signal. In one example, the signal can be a machine-generated electrical, optical, or electromagnetic signal that is generated to encode information for transmission to a suitable receiver apparatus for execution by the data processing apparatus. The computer storage medium can be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of computer storage media.

[0264] The terms “data processing apparatus,” “computer,” and “computing device” (or equivalent forms as understood by a person of ordinary skill in the art) refer to data processing hardware. For example, the data processing apparatus can encompass various devices, apparatuses, and machines for processing data, such as including programmable processors, computers, or multiple processors or computers. The apparatus can also include dedicated logic circuitry, which includes, for example, a central processing unit (CPU), a field programmable gate array (FPGA), or an application specific integrated circuit (ASIC). In some specific implementations, the data processing apparatus or the dedicated logic circuitry (or a combination of the data processing apparatus and the dedicated logic circuitry) can be based on hardware or software (or a combination based on hardware and based on software). The apparatus can optionally include code that creates an execution environment for computer programs, such as code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of execution environments. The present disclosure contemplates the use of a data processing apparatus with or without a conventional operating system (such as LINUX, UNIX, WINDOWS, MAC OS, ANDROID, or IOS).

[0265] A computer program, which may also be referred to as or described as a program, software, software application, module, software module, script, or code, can be written in any form of programming language. The programming language may include, for example, a compiled language, an interpreted language, a declarative language, or a procedural language. The program can be deployed in any form, including as a stand-alone program, module, component, subroutine, or unit in a computing environment. A computer program may or may not correspond to a file in a file system. The program can be stored as part of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program being discussed, or in multiple coordinated files that store one or more modules, subroutines, or portions of code. The computer program can be deployed to execute on one computer or on multiple computers located, for example, at one site or distributed across multiple sites interconnected by a communication network. Although portions of the program shown in the various figures may be depicted as separate modules that implement various features and functions through various objects, methods, or processes, the program may alternatively include multiple sub-modules, third-party services, components, and libraries. Conversely, the features and functions of the various components may be combined into a single component as appropriate. Thresholds for making computational determinations can be determined statically, dynamically, or both statically and dynamically.

[0266] The methods, processes, or logical flows described in this specification can be performed by one or more programmable computers executing one or more computer programs to perform functions by operating on input data and generating output. These methods, processes, and logical flows can also be performed by dedicated logic circuitry (e.g., a CPU, an FPGA, or an ASIC), and the apparatus can also be implemented as dedicated logic circuitry.

[0267] Computers suitable for executing a computer program can be based on one or more of a general-purpose microprocessor, a special-purpose microprocessor, and other kinds of CPUs. The elements of a computer are a CPU for executing instructions and one or more memory devices for storing instructions and data. Generally speaking, the CPU can receive instructions and data from the memory (and write data to the memory). The computer may also include or be operatively coupled to one or more mass storage devices for storing data. In some specific embodiments, the computer can receive data from and transfer data to mass storage devices, which include, for example, magnetic disks, magneto-optical disks, or optical disks. Additionally, the computer can be embedded in another device, such as a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a portable storage device such as a universal serial bus (USB) flash drive.

[0268] A computer-readable medium (transient or non-transient, as appropriate) suitable for storing computer program instructions and data may include all forms of permanent / non-permanent and volatile / non-volatile memory, media, and memory devices. The computer-readable medium may include, for example, semiconductor memory devices such as random access memory (RAM), read-only memory (ROM), phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory devices. The computer-readable medium may also include, for example, magnetic devices such as tapes, tape cartridges, cassettes, and internal / removable disks. The computer-readable medium may also include magneto-optical and optical memory devices and technologies, including, for example, digital video discs (DVDs), CD ROMs, DVD+ / -Rs, DVD-RAMs, DVD-ROMs, HD-DVDs, and BLURAYs. The memory may store various objects or data, including caches, classes, frameworks, applications, modules, backup data, jobs, web pages, web page templates, data structures, database tables, repositories, and dynamic information. The types of objects and data stored in the memory may include parameters, variables, algorithms, instructions, rules, constraints, and references. Additionally, the memory may include logs, policies, security or access data, and report files. The processor and memory may be supplemented by, or incorporated into, dedicated logic circuitry.

[0269] Although this specification includes many specific implementation details, these should not be construed as limitations on the scope of what is claimed, but rather as descriptions of features that may be specific to particular implementations. Certain features described in the context of different implementations in this specification may also be implemented combinatorially in a single implementation. Conversely, the various features described in the context of a single implementation may also be implemented separately or in any suitable sub-combination in multiple implementations. Moreover, although the features previously described may be described as acting in certain combinations and even initially claimed as such, one or more features in the claimed combination may in some cases be excluded from that combination, and the claimed combination may cover a sub-combination or a variation of a sub-combination.

[0270] Particular specific implementations of the subject matter have been described. Other specific implementations, changes, and permutations of the specific implementations are within the scope of the following claims and will be apparent to those skilled in the art. Although operations are shown in the drawings or claims in a particular order, this should not be construed as requiring that such operations be performed in the particular order or sequence shown, or that all of the shown operations be performed (some operations may be considered optional) to achieve the desired result. In some cases, multitasking or parallel processing (or a combination of multitasking and parallel processing) may be advantageous and may be performed depending on the circumstances.

[0271] Furthermore, the division or integration of the various system modules and components in the previously described specific implementations should not be construed as requiring such division or integration in all specific implementations, and it should be understood that the program components and systems may generally be integrated together in a single software product or packaged into multiple software products.

[0272] Accordingly, the previously described exemplary specific implementations do not limit or constrain the present disclosure. Other changes, substitutions, and alterations are also possible without departing from the spirit and scope of the present disclosure.

Claims

1. A method performed by a client device in a wireless network for transmitting a Transmission Control Protocol (TCP) acknowledgement (TCP ACK) packet, the method comprising: In response to receiving a TCP packet from another device in the wireless network, accessing, in a memory coupled to the client device, a queue comprising TCP ACK packets to be transmitted to the other device, wherein at least a subset of the TCP ACK packets comprises respective packet descriptors, each packet descriptor comprising (i) a flow identifier indicating a TCP flow associated with the packet and (ii) a TCP ACK generation count; Examining a packet descriptor of a first TCP ACK packet among the TCP ACK packets in the queue; Identifying a first flow identifier and a first TCP ACK generation count corresponding to the first TCP ACK packet, included in the packet descriptor of the first TCP ACK packet; Determining that the first flow identifier and the first TCP ACK generation count are valid; Accessing, in the memory coupled to the client device, a data structure comprising entries, each entry having at least a first field and a second field, the first field and the second field storing a flow identifier and a corresponding TCP ACK generation count, respectively; Determining that a condition is satisfied, wherein the condition comprises that the data structure comprises a first entry having (i) a flow identifier matching the first flow identifier and (ii) a TCP ACK generation count matching the first TCP ACK generation count, and wherein the condition further comprises at least one of the following: A loss rate of a lower layer queue is lower than a threshold, The client device is operating in a given power mode, or The client device detects downlink TCP data at a baseband; and In response to determining that the condition is satisfied, marking the first TCP ACK packet as pending discard.

2. The method according to claim 1, further comprising determining that the TCP flow comprises uplink data in a plurality of queues, wherein the condition further comprises: The first TCP ACK packet corresponds to uplink data in a specific queue among the plurality of queues.

3. The method according to claim 2, wherein the specific queue among the plurality of queues has a high priority.

4. The method according to claim 2, wherein the specific queue among the plurality of queues has a low priority.

5. The method according to claim 1, further comprising determining that the TCP flow comprises uplink data transmitted in a plurality of data radio bearers (DRBs), wherein the condition further comprises: The first TCP ACK packet corresponds to uplink data transmitted in one or more DRBs.

6. The method according to claim 5, wherein the one or more DRBs are default DRBs on an Internet Protocol data network (PDN).

7. The method according to claim 5, wherein at least one of the one or more DRBs has a throughput within a given range.

8. The method according to claim 5, wherein the one or more DRBs are bi-directional DRBs.

9. The method according to claim 1, further comprising determining that the TCP flow includes uplink data corresponding to a plurality of packet data networks (PDNs), wherein the condition further comprises: The first TCP ACK packet corresponds to uplink data transmitted in one or more given PDNs.

10. The method according to claim 1, wherein the condition further comprises: The client device operates in a known power mode.

11. The method according to claim 1, further comprising determining that the TCP flow includes a plurality of Internet Protocol (IP) packet flows, wherein the condition further comprises: The first TCP ACK packet corresponds to uplink data transmitted in one or more given IP packet flows.

12. A processor, the processor comprising circuitry for executing instructions to perform operations, the operations comprising: Accessing, in a memory coupled to the processor, a queue comprising Transmission Control Protocol (TCP) acknowledgement (ACK) packets associated with a user equipment (UE), in response to receiving a TCP packet from another UE in a wireless network, the TCP ACK packets being to be transmitted to the other UE, wherein at least a subset of the TCP ACK packets comprises respective packet descriptors, each packet descriptor comprising (i) a flow identifier indicating the TCP flow associated with the packet and (ii) a TCP ACK generation count; Examining a packet descriptor of a first TCP ACK packet among the TCP ACK packets in the queue; Identifying a first flow identifier and a first TCP ACK generation count corresponding to the first TCP ACK packet included in the packet descriptor of the first TCP ACK packet; Determining that the first flow identifier and the first TCP ACK generation count are valid; Accessing, in the memory, a data structure comprising entries, each entry having at least a first field and a second field, the first field and the second field storing a flow identifier and a corresponding TCP ACK generation count, respectively; Determining that a condition is met, wherein the condition comprises that the data structure includes a first entry having (i) a flow identifier matching the first flow identifier and (ii) a TCP ACK generation count matching the first TCP ACK generation count, wherein the condition further comprises at least one of the following: The loss rate of a lower layer queue is lower than a threshold, The UE operates in a given power mode, or The UE detects downlink TCP data at a baseband; and In response to determining that the condition is met, marking the first TCP ACK packet as pending discard.

13. The processor according to claim 12, wherein the operations further comprise determining that the TCP flow includes uplink data in a plurality of queues, wherein the condition further comprises: The first TCP ACK packet corresponds to uplink data in one of the plurality of queues.

14. The processor according to claim 12, wherein the operation further comprises determining that the TCP flow includes uplink data transmitted in a plurality of data radio bearers (DRBs), and wherein the condition further comprises: The first TCP ACK packet corresponds to uplink data transmitted in one or more given DRBs.

15. The processor according to claim 12, wherein the operation further comprises determining that the TCP flow includes uplink data corresponding to a plurality of packet data networks (PDNs), and wherein the condition further comprises: The first TCP ACK packet corresponds to uplink data transmitted in one or more given PDNs.

16. The processor according to claim 12, wherein the operation further comprises determining that the TCP flow includes a plurality of Internet Protocol (IP) packet flows, and wherein the condition further comprises: The first TCP ACK packet corresponds to uplink data transmitted in one or more given IP packet flows.

17. The processor according to claim 12, wherein the operation further comprises determining that the TCP flow includes uplink data transmitted in a plurality of data radio bearers (DRBs), and wherein the condition further comprises: The first TCP ACK packet corresponds to uplink data transmitted in one or more given DRBs.

18. The processor according to claim 12, wherein the operation further comprises determining that the TCP flow includes uplink data corresponding to a plurality of packet data networks (PDNs), and wherein the condition further comprises: The first TCP ACK packet corresponds to uplink data transmitted in one or more given PDNs.

19. The processor according to claim 12, wherein the operation further comprises determining that the TCP flow includes a plurality of Internet Protocol (IP) packet flows, and wherein the condition further comprises: The first TCP ACK packet corresponds to uplink data transmitted in one or more given IP packet flows.

20. An apparatus for managing the transmission of Transmission Control Protocol (TCP) acknowledgement (TCP ACK) packets, the apparatus comprising: Processing circuitry configured to execute instructions that cause a user equipment (UE) to perform operations, the operations including: In response to receiving a TCP packet from another UE in a wireless network, accessing, in a memory, a queue that includes TCP acknowledgement (TCP ACK) packets to be transmitted to the other UE, wherein at least a subset of the TCP ACK packets includes respective packet descriptors, each packet descriptor including (i) a flow identifier indicating a TCP flow associated with the packet and (ii) a TCP ACK generation count; Examining a packet descriptor of a first TCP ACK packet among the TCP ACK packets in the queue; identifying a first flow identifier and a first TCP ACK generation count corresponding to the first TCP ACK packet included in the packet descriptor of the first TCP ACK packet; Determining that the first flow identifier and the first TCP ACK generation count are valid; Access a data structure including entries in the memory, each entry having at least a first field and a second field, the first field and the second field storing a flow identifier and a corresponding TCP ACK generation count, respectively; Determine that a condition is satisfied, where the condition includes that the data structure includes a first entry having (i) a flow identifier matching the first flow identifier and (ii) a TCP ACK generation count matching the first TCP ACK generation count, and where the condition further includes at least one of the following: The loss rate of a lower layer queue is lower than a threshold, The UE operates in a given power mode, or The UE detects downlink TCP data at the baseband; and In response to determining that the condition is satisfied, mark the first TCP ACK packet as to be discarded.

Images