System and method for managing transmission control protocol (TCP) acknows

Abstract

The present disclosure relates to systems and methods for managing Transmission Control Protocol (TCP) acknowledgements. A client device in a wireless network accesses a queue including transmission control protocol acknowledgement (TCP ACK) packets, at least some of the TCP ACK packets including packet descriptors, each packet descriptor having a flow identifier indicating a TCP flow associated with the packet and a TCP ACK generation count. The device checks a packet descriptor of the first TCP ACK packet and identifies a first flow identifier and a first TCP ACK generation count. The device accesses entries in the data structure, each entry including a first field and a second field storing a stream identifier and a TCP ACK generation count, respectively. The device determines that a first entry in the data structure includes a flow identifier and a TCP ACK generation count that match the first flow identifier and the first TCP ACK generation count, respectively. In response to the determination, the device marks the first TCP ACK packet as to be discarded.

Description

[0001] Divisional Application Statement

[0002] This application is a divisional application of a Chinese patent application with an application date of June 30, 2022, an invention title of "System and Method for Managing Transmission Control Protocol (TCP) Acknowledgments", and an application number of 2022107791183. Technical Field

[0003] The following disclosure generally relates to communication technologies, and more particularly to systems, methods, and apparatuses for Transmission Control Protocol (TCP) acknowledgment (ACK) transmissions in a communication network. Background Art

[0004] TCP is a communication protocol that facilitates message exchange 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

[0005] 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 embodiments, the disclosed systems, devices, and methods are used to manage 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 embodiments, 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 embodiments, 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 the same counter value as the counter value of one or more other TCP ACK packets (generated by the TCP application at the client device). In some specific embodiments, 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 embodiments, 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.

[0006] TCP is a reliable stream delivery service, where the receiver of a TCP packet responds to the sender with a TCP ACK message upon receiving the TCP packet. For reliable transmission, TCP uses sequence numbers to identify each data byte. The sequence number identifies 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 before 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 before 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.

[0007] 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 receiving packet #3, the client device starts sending duplicate TCP ACKs so that the server can start the fast retransmit process.

[0008] 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 duplicate TCP ACKs is due to lost data packets or just due to data packet reordering, the server waits to receive a small number of duplicate TCP ACKs. If multiple duplicate TCP ACKs are received consecutively, this strongly indicates that a data packet has been lost.

[0009] 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 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 there is a delay in the client device sending a TCP ACK packet to acknowledge receipt of the data packets sent by the server, the throughput of the communication session with the server is reduced because the sending of data packets by the server stops.

[0010] In some cases, when data packets are lost, connections 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, thereby reducing the data throughput of the communication session.

[0011] 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 the receiver (e.g., a client device) when sending a TCP ACK packet to the 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).

[0012] 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.

[0013] In general aspects, a client device in a wireless network manages Transmission Control Protocol acknowledgment (TCP ACK) packet transmissions by, in response to receiving a TCP packet from another device in the wireless network, accessing in a memory a queue that includes TCP ACK packets to be transmitted to another device. 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 the 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 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 this determination, the client device marks the first TCP ACK packet as to be discarded.

[0014] Particular embodiments include one or more of the following features. 1. In some embodiments, the first entry in the data structure corresponds to a second TCP ACK packet in the queue, where the first TCP ACK packet is 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 embodiments, the queue is examined starting from the latest packet first.

[0015] In some embodiments, the packet descriptors are assigned by a TCP application processor included in the client device and are examined 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 the 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.

[0016] In some specific implementations, the client device checks the packet descriptor of the third TCP ACK packet in the TCP packet 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.

[0017] In some specific implementations, the client device checks the packet descriptor of the third TCP ACK packet in the TCP ACK packet 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 implementations, 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.

[0018] In some specific implementations, the client device checks the packet descriptor of the fourth TCP packet in the TCP packet 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.

[0019] In some specific embodiments, the client device checks the packet descriptor of the fifth TCP packet in the TCP packet 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.

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

[0021] 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.

[0022] In some specific embodiments, 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 one or more entries in the data structure to determine whether there is a match; and

[0023] In response to this comparison, determining that the hash value included in the first entry matches the first hash value.

[0024] 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 a queue including TCP ACK packets to be transmitted to the other network device in a memory coupled to the client 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 a data structure having one or more entries in a memory coupled to the client device, each entry including a flow identifier and a corresponding TCP ACK generation count; determining that the data structure includes a first entry that includes (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 the positions of the first TCP ACK packet and the second TCP ACK packet in the queue based at least on the first position field and the second position field 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.

[0025] Certain specific embodiments include one or more of the following features. In some embodiments, the first entry in the data structure corresponds to a second TCP ACK packet in the queue, and wherein the first TCP ACK packet is generated before the second TCP ACK packet, and wherein 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.

[0026] In some embodiments, the queue is examined starting from the latest packet first.

[0027] In some specific implementations, these packet descriptors are assigned 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 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, 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.

[0028] In some specific implementations, the method further includes: checking a 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 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.

[0029] In some specific implementations, the method further includes: checking a packet descriptor of a third TCP ACK packet of TCP ACK 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 flow identifier is set to an invalid value; and in response to the determination, aborting further processing of the third TCP ACK packet. In some specific implementations, determining that the third flow identifier of the third TCP ACK packet is set to an invalid value includes determining one of the following: a 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.

[0030] 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 a first flow identifier in a first entry in the queue, and (ii) that the fourth TCP ACK generation count is different from a first TCP ACK generation count in the first entry in the queue; and in response to that determination, updating the first entry by replacing the first TCP ACK generation count stored in a second position field of the first entry with the fourth TCP ACK generation count.

[0031] 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 that 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.

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

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

[0034] In some specific embodiments, one or more entries in the data structure include hash values representing flow identifiers, and wherein 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 hash values included in one or more entries in the data structure to determine whether there is a match; and in response to that comparison, determining that the hash value included in the first entry matches the first hash value.

[0035] 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 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.

[0036] 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.

[0037] 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.

[0038] In some specific implementations, the method further includes: determining by the 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 the ACK generation count value in the packet descriptor of the first TCP ACK packet to a predetermined invalid value.

[0039] In some specific implementations, the method further includes: determining by the 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 the baseband processor without a TCP ACK generation count value.

[0040] In some specific implementations, the method further includes: determining, by an application processor, that a 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.

[0041] In some specific implementations, the method further includes: determining, by an application processor, that a 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 without a flow identifier.

[0042] Eliminating redundant TCP ACK packets in the UL as disclosed in the specific implementations 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.

[0043] Specific implementations 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 implementations, the apparatus is a baseband processor for a client device (e.g., UE) in a wireless network. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Figure 1 A block diagram of a communication system is shown in accordance with some disclosed specific implementations.

[0045] Figure 2 Optimization of TCP ACK packets is shown in accordance with some disclosed specific implementations.

[0046] Figure 3 A flowchart of an exemplary process for managing TCP ACK packets is shown in accordance with some disclosed specific implementations.

[0047] Figure 4 Optimization of a TCP ACK packet flow is shown in accordance with some disclosed specific implementations.

[0048] Figure 5A flowchart showing a second exemplary process for managing TCP ACK packets according to some disclosed embodiments.

[0049] Figure 6 A data structure for managing TCP ACK packets according to some disclosed embodiments is shown.

[0050] Figure 7 A second data structure for managing TCP ACK packets by reordering according to some disclosed embodiments is shown.

[0051] Figure 8 A block diagram of a communication device according to some disclosed embodiments is shown.

[0052] Figure 9 A block diagram of a communication device according to some disclosed embodiments is shown.

[0053] Figure 10 A 3GPP protocol stack according to some disclosed embodiments is shown.

[0054] Figure 11 A block diagram of a communication system according to some disclosed embodiments is shown. DETAILED DESCRIPTION

[0055] 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 a host device implementing the TCP protocol (commonly referred to as TCP in this disclosure) are responsible for establishing a connection with another host device and maintaining that connection for data transmission. 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.

[0056] TCP uses a mechanism called a 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 SYN (synchronization) 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 back a SYN-ACK (synchronization-acknowledgment) message to the client. The client device responds with an ACK message, and the connection is established.

[0057] 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 that the TCP data packet has been received. The client device selects the 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 sequence numbers of the other 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.

[0058] 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.

[0059] In some specific implementations, the available downlink (DL) bandwidth is greater than the available uplink (UL) bandwidth. In some cases, the 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 transmitting TCP ACK packets, leading to degradation of throughput.

[0060] 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 detailed in the following sections, in some specific implementations, the BB circuit (also known 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 the 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 the specific implementations in which one or more newer duplicate TCP ACK packets are discarded.

[0061] The client device uses a counter called TCP ACK generation count to track TCP ACK packets that are potential duplicates. In some specific implementations, the process of implementing a TCP application (also known as an application processor, AP) in the client device generates a TCP ACK generation count value (also known as 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 an n - millisecond interval. In some specific implementations, n is set to a predetermined value, for example, as a design parameter. In other specific implementations, the TCP AP 105 is configured to dynamically modify the value of n at runtime, for example, according to the current throughput.

[0062] Upon 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 the counter value to determine whether some TCP ACK packets in the output queue are redundant and can be discarded. For example, this may occur during UL transmission delays 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), so that the TCP connection remains stable even when some TCP ACK packets are discarded. The server starts retransmitting data packets after receiving the first duplicate TCP ACK packet.

[0063] 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.

[0064] For purposes of convenience and not limitation, system 100 is described in the context of 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 non-standalone (NSA) networks that combine both LTE and NR (e.g., E-UTRA (Evolved Universal Terrestrial Radio Access)-NR dual connectivity (EN-DC) networks and NE-DC networks). However, system 100 can also be a standalone (SA) network that combines only NR. System 100 can 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 the like.

[0065] In some specific implementations, 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 system 100 can include multiple client devices, and the disclosed techniques apply equally 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-vehicle 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.

[0066] In some specific implementations, the client device 102 is an Internet of Things (IoT) client device, and the IoT client device may include a network access layer for low-power IoT applications designed to 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. The M2M or MTC data exchange may 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.

[0067] 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 implementations, 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.

[0068] The network 108 may 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 may, for example, be embodied 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, a combination thereof, etc.), a wireless network (e.g., a cellular network, a wireless local area network, a wireless wide area network, a combination thereof, etc.), or a combination of them, and in some exemplary specific implementations may include the Internet.

[0069] In some specific implementations, 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, and each connection (or channel) includes a physical communication interface or layer.

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

[0071] As shown in the figure, the client device 102 is connected to an access point (AP) 104 (also referred to as a "WLAN node", "WLAN", "WLAN terminal", "WT", etc.) via a connection 107. The connection 107 can 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 specific implementations, the client device 102, the RAN 112, and the AP 104 can be configured to utilize LWA operations and / or LWIP operations. LWA operations can involve the RAN nodes 112a-b configuring the client device 102 in the RRC_CONNECTED state to utilize the radio resources of LTE and WLAN. LWIP operations can involve the client device 102 using the WLAN radio resources (e.g., the connection 107) via an IPsec protocol tunnel to authenticate and encrypt the packets (e.g., IP packets) sent through the connection 107. IPsec tunneling can include encapsulating the entire original IP packet and adding a new packet header, thereby protecting the original header of the IP packet.

[0072] The RAN 112 may include one or more AN nodes or RAN nodes 112a and 112b (collectively referred to as "RAN node 112a" or "RAN node 112b" or "RAN node 112a-b") that enable 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 that provides coverage within a geographical area (e.g., a cell). As used herein, terms such as "NG RAN node" etc. may refer to a RAN node 112 (e.g., a gNB) operating in an NR or 5G system 100, while terms such as "E-UTRAN node" etc. may refer to a RAN node 112 (e.g., an eNB) operating in an LTE or 4G system. According to various embodiments, the 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 a macrocell.

[0073] In some embodiments, all or some of the RAN nodes 112a-b may be implemented as one or more software entities running on a server computer, as part of a virtual network that may be referred to as a Centralized RAN (CRAN) and / or virtual baseband unit pool (vBBUP). In these embodiments, the CRAN or vBBUP may implement RAN function splitting, such as PDCP splitting, 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 splitting, 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" splitting, 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 embodiments, each of the RAN nodes 112a-b may represent a respective gNB-DU connected to the gNB-CU via a respective F1 interface (not shown). In these embodiments, the gNB-DU may include one or more remote radio heads or RFEMs, and the gNB-CU may be operated by a server (not shown) located within the RAN 112 or by a pool of servers in a manner similar to the CRAN / vBBUP. Additionally or alternatively, one or more of the RAN nodes 112a-b may 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).

[0074] 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) 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 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 band) and / or provide connectivity 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.

[0075] Any one of the RAN nodes 112a-b can be the end point of an air interface protocol and can be the first point of contact for the client device 102. In some embodiments, 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.

[0076] In a particular implementation, the client device 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 technologies, such as but not limited to OFDMA communication technology (e.g., for downlink communication) or SC-FDMA communication technology (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 subcarriers.

[0077] In some particular implementations, a downlink resource grid may be used for downlink transmissions from any one of the RAN nodes 112a-b to the client device 102, and uplink transmissions 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 resources in the downlink in each time slot. For OFDM systems, such time-frequency plane representations are 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 subcarrier, 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.

[0078] According to various particular implementations, the client device 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 the 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.

[0079] 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 prior to transmission in the unlicensed spectrum. The medium / carrier sensing operations may be performed according to the Listen Before Talk (LBT) protocol.

[0080] 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. The 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 for a period of time and comparing the sensed RF energy with a predefined or configured threshold.

[0081] Typically, existing systems in the 5 GHz 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 prior to 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 exponentially increases 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 CSMA / CA of WLANs. In some embodiments, the LBT procedure for a DL or UL transmission burst (including PDSCH or PUSCH transmissions, respectively) may have a variable-length LAA contention window between X and Y ECCA time 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 MCOT (e.g., transmission burst) may be based on government regulatory requirements.

[0082] 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.

[0083] CA also includes individual serving cells to provide each CC. The coverage of the 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 the 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.

[0084] 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 of the RAN nodes 112a - b based on the channel quality information fed back from any 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).

[0085] 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 of 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. In LTE, there can be four or more different PDCCH formats with different numbers of CCEs (e.g., aggregation levels, L = 1, 2, 4, or 8).

[0086] 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 of four physical resource elements, called EREGs. In some cases, an ECCE can have other numbers of EREGs.

[0087] RAN nodes 112a - b can be configured to communicate with each other via interface 116. In a specific implementation where system 100 is an LTE system, 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 an X2 user plane interface (X2 - U) and an 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 expected 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.

[0088] In a specific implementation where system 100 is a 5G or NR system, 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 5GC 108, between a RAN node 112a-b (e.g., gNB) connected to 5GC 108 and an eNB, and / or between two eNBs connected to 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.

[0089] RAN 112 is shown as communicatively coupled to a core network, which in this particular implementation is communicatively coupled to core network (CN) 108. CN 108 may include a plurality of network elements 122 that are configured to provide various data and telecommunication 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 and include components for reading and executing instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium). In some particular implementations, NFV may be used to virtualize any 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 that include 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 a virtual or reconfigurable implementation of one or more EPC components / functions.

[0090] 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.

[0091] In a specific 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 specific 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.

[0092] In a specific implementation, CN 108 can be a 5G CN (referred to as "5GC 108", etc.), while in other specific 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 specific 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.

[0093] In some specific 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 the successful receipt of the TCP data packets by sending an acknowledgment 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 number chain, i.e., there are no missing sequence numbers due to non-receipt of the corresponding TCP data packets.

[0094] As previously pointed out, in some specific implementations, the client device 102 includes the 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, where these computer-readable program instructions are stored on a computer-readable medium (e.g., a storage memory) and executed by a processing device (e.g., the baseband circuit 910 described Figure 9 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).

[0095] In some specific implementations, 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 was received, the sequence number of the most recent data packet, the timestamp when these data packets were received, and the number of unacknowledged data packets. In some specific implementations, the BB circuit 103 stores this information in a memory coupled to the client device 102, for example, stored in the database 106.

[0096] The TCP packets sent by the AS 110 are associated with one or more different communication sessions. In some specific implementations, the TCP AP 105 uses different TCP flow identifiers (referred to as flow IDs) to identify different communication sessions. In some specific implementations, 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 implementations, 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 implementations, 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 packets, 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.

[0097] In some specific implementations, 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 the flow ID. In such cases, the BB circuit 103 treats these TCP ACK packets as invalid for traffic reduction and ignores these packets when examining the redundant packets in the output queue 107.

[0098] In some specific implementations, the BB circuit 103, for example, uses a timer to track the period during which TCP ACK packets wait in the output queue before UL transmission. If the value of the timer exceeds a predetermined value, indicating that the period during which the TCP ACK packets are 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 implementations, 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 implementations, 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.

[0099] In addition or alternatively, in some specific implementations, 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. Depending on the specific implementation, 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, detect the occurrence of one or more redundant TCP ACK packets of the flow.

[0100] In some specific implementations, as described in more detail in the following sections, when there are newer TCPACK packets to be processed 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, timestamps are used to identify TCP ACK packets, and the timestamp indicates the time when the TCP ACK packet is generated or added to the output queue 107. In some cases, when TCP ACK packets having the same flow ID and ACK Gen Count but having a more recent timestamp value are also in the output queue, one or more TCP ACK packets having an earlier timestamp are discarded. In some other cases, when TCP ACK packets having the same flow ID and ACK Gen Count but having an earlier timestamp value are also in the output queue, one or more TCP ACK packets having a more recent timestamp are discarded.

[0101] 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.

[0102] 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 the 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 "Flow a" and an ACK Gen Count "ackgen 2", and the newest TCP ACK packet (Packet #13) has a flow ID "Flow a" and an ACK Gen Count "ackgen 3".

[0103] Configuration 202 shows that before the BB circuit 103 optimizes the queue, the output queue includes multiple TCP ACK packets with 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.

[0104] Configuration 202 shows that the output queue also includes multiple TCP ACK packets with the same flow ID but different ACK Gen Count values; and TCP ACK packets with different flow IDs. For example, packet #1 and #10 have the same flow ID "flow a", but different ACK Gen Count values, "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 in 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, "flow a" and "flow b" respectively. These TCP ACK packets with the same flow ID but different ACK Gen Count values or different flow IDs are not identified as redundant relative to each other.

[0105] 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.

[0106] 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 check, 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 likely to be 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 an empty 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.

[0107] 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.

[0108] 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, leaving it in the output queue. In some embodiments, the 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.

[0109] 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, the 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 GenCount values of the two packets (e.g., packet #13 and packet #10) are the same.

[0110] In some cases, 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 the older packet and the newer packet have the same flow ID and ACK Gen Count value, BB circuit 103 determines that the older packet (e.g., packet #10) is a redundant duplicate TCP ACK packet. BB circuit 103 keeps 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, 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, BB circuit 103 marks packet #10 (e.g., the corresponding database entry) as a discarded packet, as shown in 206a.

[0111] In some specific implementations, 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, 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.

[0112] 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.

[0113] 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 examining 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 Gen Count ("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.

[0114] Similarly, considering the next older TCP ACK packet in the output queue that has not been examined 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.

[0115] 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.

[0116] In some embodiments, the TCP AP 105 sets the ACK Gen Count of a particular TCP ACK packet to invalid, e.g., 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 could be a 16-bit field; the TCP AP 105 could 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 be the case, 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 the data packets are not checked for reduction by setting the ACK Gen Count or the flow ID or both of the data packets to an invalid value.

[0117] Figure 3 An exemplary process 300 for managing TCP ACK packets in an output queue according to some embodiments is shown. In some embodiments, the 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, the process 300 is described in the following sections with respect to the client device 102 and the system 100. However, in other embodiments, the process 300 may also be executed by other devices.

[0118] 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 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, 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 embodiments, accessing output queue 107 includes accessing records of TCP ACK packets in database 106. Regarding Figure 6 Such records are shown. In some embodiments, 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.

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

[0120] The client device identifies the values of the ACK Gen Count and the 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 the ACK Gen Count value included in the packet.

[0121] 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 embodiments, having an empty ACK Gen Count field indicates that the ACK Gen Count is invalid.

[0122] 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 moving 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), 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 moving to examine the next packet in the queue (if there are other unexamined packets).

[0123] 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 value or an invalid value (e.g., hexadecimal FFFF or some other suitable predefined value indicating invalid). In some specific implementations, the absence of any value in the flow ID field indicates that the flow ID is invalid.

[0124] 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 moving 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), 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).

[0125] 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 entry in the database 106 to determine whether the 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).

[0126] 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 with respect to Figure 6 The BB circuit 103 stores the flow ID of the packet and the ACK Gen Count value in the newly created entry.

[0127] 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 with respect to 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.

[0128] 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.

[0129] 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. Thus, 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.

[0130] In a particular 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 particular 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. Thus, compared to the case when examining the 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.

[0131] Then, the client device verifies 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 the output queue has been compressed for the current iteration.

[0132] 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, sending the TCP ACK packets to the remote server is delayed because the newer TCP ACK packets are in 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 such 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 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.

[0133] Figure 4Shows the optimization of TCP ACK packet flows 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, regarding Figure 4 the operations described are performed by the BB circuit 103, and the configurations 402 - 410 correspond to the output queue 107.

[0134] Each of the configurations 402 - 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 with different flow IDs and corresponding ACK Gen Count values assigned by the TCPAP 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 in the queue (Packet #1) 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".

[0135] Configuration 402 shows that before the BB circuit 103 optimizes the queue, the output queue includes multiple TCP ACK packets with 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 with 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.

[0136] Configuration 402 shows that the output queue also includes multiple TCP ACK packets with the same flow ID but different ACK Gen Count values; and TCP ACK packets with 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 with the same flow ID but different ACK Gen Count values or different flow IDs are not identified as redundant relative to each other.

[0137] 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, for example, stored in a data structure such as a table as described in Figure 7 the data structure described 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.

[0138] 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 descriptor of the packet and compares the information in the packet descriptor with the entries stored in database 106.

[0139] As previously described, in some specific implementations, when storing TCP ACK packets in the output queue for redundancy check, 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 ineffective 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. In addition 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 ineffective 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.

[0140] 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 that has 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.

[0141] 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 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 (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"), thereby updating the ACK Gen Count field to store the ACK Gen Count value of packet #11 and updating the winner index field to store the location index of packet #11.

[0142] 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.

[0143] 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 additional duplicate TCP ACK packets are 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 the 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).

[0144] 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.

[0145] 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 "ackgen3", packet #10 is a redundant copy of packet #13, and their respective queue positions are stored as the replacement candidate index and 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 of the TCP ACK packets corresponding to the flow ID "Flow a" and the ACK Gen Count value "ackgen 3" in the queue (e.g., the original position of packet #10) is maintained, while removing the redundant duplicate packets.

[0146] 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 "ackgen 2", 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.

[0147] 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).

[0148] 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, e.g., by BB circuit 103 of client device 102. Accordingly, process 500 is described below with respect to client device 102 and system 100. However, process 500 may also be performed by other devices.

[0149] 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 whether 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.

[0150] 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 begins examining packets from the latest packet in the queue (e.g., packet #13 as shown by configuration 402). In some embodiments, BB circuit 103 begins examining packets from the oldest packet in the queue (e.g., packet #1 as shown by configuration 402). In some embodiments, when examining packets in output queue 107, BB circuit 103 reads the packet descriptor corresponding to the packet.

[0151] 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 ACK Gen Count values included in the packet's packet descriptor.

[0152] 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.

[0153] 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).

[0154] 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.

[0155] 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 not eligible for reduction and continues to move on 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 particular 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).

[0156] 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).

[0157] 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 with respect to 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 of the TCP ACK packet and the ACK Gen Count value 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 described with respect to Figure 4 described.

[0158] 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 with respect to Figure 4As described above, packet #10 in queue (404) has a flow ID of "flow a" and an ACK Gen Count of "ackgen 3". 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.

[0159] 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), 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, 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 previously described, 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.

[0160] 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 (which previously stored the queue position of packet #12) of the database entry to store the queue position index of packet #11.

[0161] 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.

[0162] 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).

[0163] 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 exchanges the positions of packet #13 and packet #10, as described in 406a regarding 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 shows the output queue at the end of process 500.

[0164] Figure 6 shows an entry in the database 106 for managing TCP ACK packets according to some disclosed specific embodiments. As described regarding Figure 1 the database 106 is included in the client device 102.

[0165] As Figure 6As shown, 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, which store the flow ID and the ACK Gen Count value determined by the BB circuit 103 when inspecting 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 inspecting the output queue 107 in each iteration, the BB circuit resets the database 106 by clearing all entries.

[0166] When inspecting 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-204 and process 300. For example, this occurs when inspecting the latest packet corresponding to a specific flow ID. For example, as described with respect to Figure 2 and Figure 3 when inspecting 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 inspecting packet #12 and packet #7 accordingly, the BB circuit 103 creates entries 604 and 606.

[0167] Figure 7 Entries in the database 106 for managing TCP ACK packets according to some disclosed embodiments are shown. 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.

[0168] The flow ID field 720 and the ACK Gen Count field 722 store the flow ID and the ACK Gen Count value determined by the BB circuit 103 when inspecting TCP ACK packets in the output queue 107, respectively. 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.

[0169] 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 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, 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.

[0170] 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 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 already been checked. For example, as described with respect to Figure 4 and Figure 5As described above, when packet #10 in output queue 107 is inspected, BB circuit 103 determines that the combination of the flow ID ("flow a") and the ACK Gen Count value ("ackgen3") of packet #10 already exists in entry 702 in database 106 (created when packet #13 was inspected). 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 inspected, 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 inspected). 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 inspected (when the queue is inspected starting from the latest packet from right to left first 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, thereby replacing the previous value recorded in field 724, i.e., the queue position of packet #6.

[0171] Once BB circuit 103 has finished inspecting 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 process 500 therein. For example, for the flow ID "flow a" and the 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.

[0172] In some specific embodiments, 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.

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

[0174] In some specific implementations, 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, thus causing additional latency overhead when compressing the output queue. In some specific implementations, 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 requirement or the speed of parsing the database or both. In such specific implementations, 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 specific implementations, 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.

[0175] In some specific implementations, when using the hash value in the above manner, the complete 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 complete flow ID. When a hash match and a hash table entry are found, all the complete flow IDs mapped to the hash value in the hash table entry are verified until the 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.

[0176] Figure 8 Shows an example of infrastructure equipment 800 according to various specific implementations. Infrastructure equipment 800 (or "system 800") 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 800 can be implemented in or by client device 102. System 800 includes: application circuit 805, baseband circuit 810, one or more radio front-end modules (RFEMs) 815, memory circuit 820, program 822 stored in memory 820, power management integrated circuit (PMIC) 825, power triple circuit 830, network controller circuit 835, network interface connector 840, satellite positioning circuit 845, and user interface 850.

[0177] In some specific implementations, device 800 can include additional elements, such as, for example, memory / storage, display, camera, sensor, or input / output (I / O) interface. In other specific implementations, 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 implementations.

[0178] Application circuit 805 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 product, 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 805 can be coupled to or can include memory / storage elements, and can be configured to execute instructions stored in the memory / storage to enable various application programs or operating systems to run on system 800. In some specific implementations, 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.

[0179] The processor of application circuit 805 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.

[0180] In some specific embodiments, application circuit 805 may include or may be a dedicated processor / controller for operating according to the various specific embodiments herein. As an example, the processor of application circuit 805 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 the ARM Cortex-A series processors provided by Cavium (TM), Inc. and MIPS-based designs from MIPS Technologies, Inc., such as the MIPS Warrior P-class processors; and so on. In some specific embodiments, system 800 may not utilize application circuit 805, but may include a dedicated processor or controller to process, for example, IP data received from the EPC or 5GC.

[0181] In some specific embodiments, application circuit 805 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 805 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.

[0182] In such specific implementations, the circuitry of application circuit 805 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.)).

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

[0184] User interface circuit 850 may include one or more user interfaces designed to enable a user to interact with system 800 or a peripheral component interface designed to enable peripheral components to interact with system 800. The user interface may include, but is not limited to, one or more physical or virtual buttons (e.g., a reset button), one or more indicators (e.g., light-emitting diodes (LEDs)), a physical keyboard or keypad, a mouse, a touchpad, a touch screen, a speaker or other audio emitting device, a microphone, a printer, a scanner, headphones, a 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.

[0185] Radio frequency front-end module (RFEM) 815 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 mmWave 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 815 that combines millimeter wave antennas and sub-millimeter wave.

[0186] Memory circuit 820 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 820 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.

[0187] PMIC 825 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.

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

[0189] The network controller circuit 835 may provide connectivity 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 800 via a network interface connector 840, which may be an electrical connection (commonly referred to as a "copper interconnect"), an optical connection, or a wireless connection. The network controller circuit 835 may include one or more dedicated processors and / or FPGAs for communicating using one or more of the aforementioned protocols. In some implementations, the network controller circuit 835 may include multiple controllers for providing connectivity to other networks using the same or different protocols.

[0190] Positioning circuit 845 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.

[0191] The positioning circuit 845 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 845 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 845 may also be part of or interact with the baseband circuit 810 and / or the RFEM 815 to communicate with nodes and components of the positioning network. The positioning circuit 845 may also provide position data and / or time data to the application circuit 805, which may use this data to synchronize operations with various infrastructure (e.g., RAN nodes 112a, 112b, etc.).

[0192] Figure 8 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 I2C interface, SPI interface, point-to-point interface, and power bus, etc.

[0193] Figure 9 An example of a computer platform 900 (or “device 900”) according to various embodiments is shown. In some embodiments, the computer platform 900 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 900 may include any combination of the components shown in the example. The components of the platform 900 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 900, or as components otherwise incorporated within the chassis of a larger system. Figure 9 The block diagram is intended to show a high-level view of the components of the computer platform 900. However, some of the components shown may be omitted, additional components may be present, and different arrangements of the shown components may occur in other embodiments.

[0194] The application circuit 905 includes circuitry such as, but not limited to, one or more processors (or processor cores), cache memory, and one or more of an LDO, an interrupt controller, a serial interface (such as SPI), I2C, or a general-purpose programmable serial interface module, an RTC, timer-counters (including interval timers and watchdog timers), general-purpose I / O, a memory card controller (such as SDMMC or a similar controller), a USB interface, a MIPI interface, and a JTAG test access port. The processor (or core) of the application circuit 905 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 900. In some embodiments, the memory / storage elements may be on-chip memory circuitry that 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.

[0195] The processor of the application circuit 905 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, a multi-threaded processor, an ultra-low voltage processor, an embedded processor, some other known processing elements, or any suitable combination thereof.

[0196] In some embodiments, the application circuit 905 may include or may be a dedicated processor / controller for operating according to the various embodiments herein. As an example, the processor of the application circuit 905 may include an Apple A-series processor. The processor of the application circuit 905 may also be one or more of the following: a processor based on Architecture Core TM such as Quark TM 、Atom TM 、i3, i5, i7, or an MCU-class processor, or another such processor available from Corporation, Santa Clara, CA ; Advanced Micro Devices (AMD) processor or an accelerated processing unit (APU); 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; and so on.

[0197] In some specific implementations, application circuit 905 can be part of a system-on-chip (SoC), where application circuit 905 and other components are formed as a single integrated circuit. Additionally or alternatively, application circuit 905 can include circuits, such as but not limited to one or more field programmable devices (FPDs), such as FPGAs; programmable logic devices (PLDs), such as complex PLDs (CPLDs), high-capacity PLDs (HCPLDs), etc.; ASICs, such as structured ASICs; programmable SoCs (PSoCs); and so on. In such specific implementations, the circuits of application circuit 905 can 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.

[0198] In such specific implementations, the circuits of application circuit 905 can 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 implementations, client device 102 can include one or more processors configured to execute software instructions stored in application circuit 905. Application circuit 905 can include an output queue optimizer 948.

[0199] The baseband circuit 910 can be implemented as, for example, a soldered-in substrate that includes one or more integrated circuits, a single packaged integrated circuit soldered to the main circuit board, or a multi-chip module that includes two or more integrated circuits. In some specific implementations, the baseband circuit 910 is similar to the baseband circuit 103. In some specific implementations, the operations performed through the interaction between the output queue optimizer 948 and the baseband circuit 910 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 948 and the baseband circuit 910.

[0200] The 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 can be implemented in the same physical RFEM 915 that combines millimeter-wave antennas and sub-millimeter-wave.

[0201] The memory circuit 920 may include any number and type of memory devices for providing a given amount of system memory. For example, the memory circuit 920 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 known as flash memory), phase change random access memory (PRAM), magnetoresistive random access memory (MRAM), etc.

[0202] The memory circuit 920 may 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 920 may 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 920 may be an on-chip memory or register associated with the application circuit 905. To provide persistent storage of information such as data, applications, operating systems, etc., the memory circuit 920 may include one or more mass storage devices, which may 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 900 may incorporate 3D cross-point (XPOINT) memory obtained from and .

[0203] The removable memory circuit 923 may include devices, circuits, enclosures / cases, ports, or sockets, etc., for coupling a portable data storage device to the platform 900. These portable data storage devices may be used for mass storage and may 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.

[0204] The platform 900 may also include interface circuitry (not shown) for connecting external devices to the platform 900. External devices connected to the platform 900 via this interface circuitry include sensor circuit 921 and electromechanical components (EMC) 922, and removable memory devices coupled to the removable memory circuit 923.

[0205] The sensor circuit 921 includes a device, module, or subsystem aimed at detecting events or changes in its environment and sending information about the detected events (sensor data) to some other device, module, subsystem, etc. Examples of such sensors particularly include: 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.

[0206] The EMC 922 includes a device, module, or subsystem aimed at enabling the platform 900 to change its state, position, and / or orientation or move or control a mechanism or (sub)system. Additionally, the EMC 922 can be configured to generate messages / signaling and send messages / signaling to other components of the platform 900 to indicate the current state of the EMC 922. The EMC 922 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 900 is configured to operate one or more EMC 922s based on one or more captured events and / or instructions or control signals received from a service provider and / or various clients.

[0207] In some specific implementations, the interface circuit can connect the platform 900 to the positioning circuit 945. The positioning circuit 945 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 945 can 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 945 can include a micro PNT IC that uses a primary timing clock to perform position tracking / estimation without GNSS assistance. The positioning circuit 945 can 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 can also provide position data and / or time data to the application circuit 905, which can use this data to synchronize operations with various infrastructures (e.g., radio base stations) for turn-by-turn navigation applications, etc.

[0208] In some specific implementations, the interface circuit can connect the platform 900 to the near field communication (NFC) circuit 940. The NFC circuit 940 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 940 and NFC-enabled devices external to the platform 900 (e.g., "NFC contact points"). The NFC circuit 940 includes an NFC controller coupled to an antenna element and a processor coupled to the NFC controller. The NFC controller can be a chip / IC that provides NFC functionality to the NFC circuit 940 by executing NFC controller firmware and an NFC stack. The NFC stack can be executed by the processor to control the NFC controller, and the NFC controller firmware can be executed by the NFC controller to control the antenna element to transmit short-range RF signals. The RF signals can power a passive NFC tag (e.g., a microchip embedded in a sticker or wristband) to transfer stored data to the NFC circuit 940, or initiate data transfer between the NFC circuit 940 and another active NFC device (e.g., a smart phone or an NFC-enabled POS terminal) near the platform 900.

[0209] The drive circuit 946 may include software elements and hardware elements for controlling specific devices embedded in, attached to, or otherwise communicatively coupled to the platform 900. The drive circuit 946 may include respective drivers, thereby allowing other components of the platform 900 to interact with or control various input / output (I / O) devices that may be present within or connected to the platform 900. For example, the drive circuit 946 may include: a display driver for controlling and allowing access to a display device, a touchscreen driver for controlling and allowing access to a touchscreen interface of the platform 900, a sensor driver for obtaining sensor readings of the sensor circuit 921 and controlling and allowing access to the sensor circuit 921, an EMC driver for obtaining the actuator position of the EMC 922 and / or controlling and allowing access to the EMC 922, 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.

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

[0211] In some specific implementations, the PMIC 925 may control or otherwise be part of various power saving mechanisms of the platform 900. For example, if the platform 900 is in the RRC_Connected state, in which the platform remains connected to a RAN node because it anticipates receiving traffic soon, then after a period of inactivity, the platform may enter a state called discontinuous reception mode (DRX). During this state, the platform 900 may power off for short intervals, thereby saving power. If there is no data traffic activity for an extended period, then the platform 900 may 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 900 enters a very low power state and performs paging, where the device wakes up periodically again to listen for the network and then powers off again. The platform 900 may not receive data in this state; to receive data, the platform must transition back to the RRC_Connected state. Additional power saving modes may render the device unable to use 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 may be completely powered off. Any data sent during this period will incur a significant delay, and it is assumed that the delay is acceptable.

[0212] The battery 930 can power the platform 900. However, in some examples, the platform 900 can be installed and deployed at a fixed location and can have a power source coupled to the power grid. The battery 930 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 930 can be a typical lead-acid automotive battery.

[0213] In some specific implementations, the battery 930 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 900 to track the state of charge (SoCh) of the battery 930. The BMS can be used to monitor other parameters of the battery 930, such as the state of health (SoH) and the state of function (SoF) of the battery 930 to provide fault prediction. The BMS can transmit information about the battery 930 to the application circuit 905 or other components of the platform 900. The BMS can also include an analog-to-digital (ADC) converter that allows the application circuit 905 to directly monitor the voltage of the battery 930 or the current from the battery 930. The battery parameters can be used to determine actions that the platform 900 can perform, such as transmission frequency, network operation, sensing frequency, etc.

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

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

[0216] The user interface circuit 950 includes an input device circuit and an output device circuit. The input device circuit includes any physical or virtual device for accepting input, particularly including one or more physical or virtual buttons (e.g., reset button), physical keyboard, keypad, mouse, touchpad, touch screen, microphone, scanner, headset, etc. The output device circuit 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 circuit may 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 display devices or touch screens (e.g., liquid crystal displays (LCDs), LED displays, quantum dot displays, projectors, etc.), where the output of characters, graphics, multimedia objects, etc. is generated or produced by the operation of the platform 900. The output device circuit may also include speakers or other audio emitting devices, printers, etc.

[0217] In some specific embodiments, the sensor circuit 921 can be used as an input device circuit (e.g., image capture device, motion capture device, etc.) and one or more EMCs can be used as an output device circuit (e.g., actuators for providing haptic feedback, etc.). In another example, an NFC circuit may be included to read electronic tags 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 may include but is not limited to non-volatile memory ports, USB ports, audio jacks, power interfaces, etc.

[0218] Although not shown, the components of the platform 900 can communicate with each other using a suitable bus or interconnect (IX) technology, which can 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 can be a proprietary bus / IX, e.g., 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, etc.

[0219] Figure 10 Various protocol functions that can be implemented in a wireless communication device according to various specific embodiments are shown. Specifically, Figure 10 Arrangement 1000 including the interconnection between various protocol layers / entities is shown. The following description is provided for various protocol layers / entities operating in conjunction with the 5G / NR system standard and the LTE system standard, but Figure 10 some or all aspects of Figure 10 are also applicable to other wireless communication network systems.

[0220] In addition to other higher layer functions not shown, the protocol layer of arrangement 1000 may further include one or more of PHY 1010, MAC 1020, RLC 1030, PDCP 1040, SDAP 1047, RRC 1055, and NAS layer 1057. These protocol layers may include one or more service access points capable of providing communication between two or more protocol layers (e.g., Figure 10 items 1059, 1056, 1050, 1049, 1045, 1035, 1025, and 1015 in).

[0221] PHY 1010 may transmit and receive physical layer signals 1005, which may be received from or transmitted to one or more other communication devices. Physical layer signals 1005 may include one or more physical channels, such as those discussed herein. PHY 1010 may 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 RRC 1055). PHY 1010 may further perform error detection on transport channels, forward error correction (FEC) encoding / 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 PHY 1010 may process requests from an instance of MAC 1020 via one or more PHY-SAPs 1015 and provide indications thereto. According to some particular implementations, requests and indications transmitted via PHY-SAP 1015 may include one or more transport channels.

[0222] An instance of MAC 1020 may process requests from an instance of RLC 1030 via one or more MAC-SAPs 1025 and provide indications thereto. These requests and indications transmitted via MAC-SAP 1025 may include one or more logical channels. MAC 1020 may perform mapping between logical channels and transport channels, multiplex MAC SDUs from one or more logical channels onto a TB to be delivered to PHY 1010 via a transport channel, demultiplex MAC SDUs from a TB delivered from PHY 1010 via a transport channel onto one or more logical channels, multiplex MAC SDUs onto a TB, schedule information reporting, error correction via HARQ, and logical channel prioritization.

[0223] An instance of RLC 1030 may process requests from an instance of PDCP 1040 via one or more radio link control service access points (RLC-SAPs) 1035 and provide indications thereto. These requests and indications transmitted via RLC-SAP 1035 may include one or more RLC channels. RLC 1030 may operate in multiple operation modes, including: transparent mode (TM), unacknowledged mode (UM), and acknowledged mode (AM). RLC 1030 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 SDUs for UM and AM data transmission. RLC 1030 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.

[0224] An instance of PDCP 1040 may process requests from an instance of RRC 1055 and / or an instance of SDAP 1047 via one or more packet data convergence protocol service access points (PDCP-SAPs) 1045 and provide indications thereto. These requests and indications transmitted via PDCP-SAP 1045 may include one or more radio bearers. PDCP 1040 may perform header compression and decompression of IP data, maintain a PDCP sequence number (SN), perform in-sequence delivery of upper layer PDUs upon re-establishment of the lower layer, 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.).

[0225] Instances of SDAP 1047 may process requests from one or more higher layer protocol entities via one or more SDAP-SAPs 1049 and provide indications thereto. These requests and indications transmitted via SDAP-SAP 1049 may include one or more QoS flows. SDAP 1047 may map QoS flows to DRBs and vice versa, and may also mark QFIs in DL packets and UL packets. A single SDAP entity 1047 may be configured for a separate PDU session. In the UL direction, NG-RAN 112 may control the mapping of QoS flows to DRBs in two different ways (reflection mapping or explicit mapping). For reflection mapping, the SDAP 1047 of client device 102 may monitor the QFI of DL packets of each DRB and may apply the same mapping for packets flowing in the UL direction. For a DRB, the SDAP 1047 of client device 102 may 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, NG-RAN may mark DL packets with the QoS flow ID via the Uu interface. Explicit mapping may involve RRC 1055 configuring SDAP 1047 with an explicit mapping rule of QoS flows to DRBs, which may be stored and followed by SDAP 1047. In a particular implementation, SDAP 1047 may be used only in NR particular implementations and may not be used in LTE particular implementations.

[0226] RRC 1055 may 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 may include one or more instances of PHY 1010, MAC 1020, RLC 1030, PDCP 1040, and SDAP 1047. In a particular implementation, an instance of RRC 1055 may process requests from one or more NAS entities 1057 and provide indications to the one or more NAS entities via one or more RRC-SAPs 1056. The main services and functions of RRC 1055 may include broadcasting of system information (e.g., included in MIB or SIB related to NAS), broadcasting of system information related to the access stratum (AS), paging, establishment, maintenance, and release of an RRC connection between client device 102 and RAN (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release), 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 may include one or more IEs, each of which may include separate data fields or data structures.

[0227] NAS 1057 can form the top layer of the control plane between the client device 102 and the AMF. NAS 1057 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.

[0228] According to various specific implementations, one or more protocol entities of the arrangement 1000 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 1055, the SDAP 1047, and the PDCP 1040 that control one or more gNB-DU operations of the gNB, and the gNB-DUs of the gNB 112A can each host the RLC 1030, the MAC 1020, and the PHY 1010 of the gNB 112A.

[0229] In a first example, the control plane protocol stack can include, in order from the highest layer to the lowest layer, NAS 1057, RRC 1055, PDCP 1040, RLC 1030, MAC 1020, and PHY 1010. In this example, the upper layer 1060 can be built on top of NAS 1057, which includes an IP layer 1061, an SCTP 1062, and an application layer signaling protocol (AP) 1063.

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

[0231] The NG-AP 1063 can support the functions of the NG interface 113 and may include an elementary procedure (EP). The NG-AP EP can be an interaction unit between the NG-RAN point 112A and the AMF. The services of the NG-AP 1063 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 in-system HO to support mobility within the NG-RAN, and for inter-system HO to support mobility 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 up the NG interface and monitoring errors through 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.

[0232] The XnAP 1063 can support the functions of the Xn interface 112B and may 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.

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

[0234] The S1 Application Protocol Layer (S1-AP) 1063 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 1063 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.

[0235] The X2AP 1063 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.

[0236] The SCTP layer (alternatively referred to as the SCTP / IP layer) 1062 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 1062 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 1061. The Internet Protocol layer (IP) 1061 can be used to perform packet addressing and routing functions. In some implementations, the IP layer 1061 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.

[0237] In a second example, the user plane protocol stack may include, in order from the highest layer to the lowest layer, SDAP 1047, PDCP 1040, RLC 1030, MAC 1020, and PHY 1010. 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 1051 may be built on top of SDAP 1047 and may include the User Datagram Protocol (UDP) and Internet Protocol Security layer (UDP / IP) 1052, the General Packet Radio Service (GPRS) Tunneling Protocol for the user plane layer (GTP-U) 1053, and the user plane PDU layer (UP PDU) 1063.

[0238] The transport network layer 1054 (also referred to as the "transport layer") may be built on top of IP transport, and GTP-U 1053 may be used on top of the UDP / IP layer 1052 (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 of the IPv4, IPv6, or PPP formats.

[0239] GTP-U 1053 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 being transported may be packets in any of the IPv4, IPv6, or PPP formats. UDP / IP 1052 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 1010), L2 layers (e.g., MAC 1020, RLC 1030, PDCP 1040, and / or SDAP 1047), UDP / IP layer 1052, and GTP-U 1053. 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 layers, UDP / IP layer 1052, and GTP-U 1053. 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.

[0240] In addition, although Figure 10Not shown, but an application layer may exist above AP 1063 and / or the transport network layer 1054. 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, for example, executed by application circuit 805 or application circuit 905, respectively. The application layer may also provide one or more interfaces for the software application to interact with the communication systems (such as baseband circuits 810 or 910) of the client device 102, RAN nodes 112a, 112b. In some specific implementations, the IP layer and / or the application layer may provide the same or similar functions as 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).

[0241] Figure 11 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 11 shows a schematic diagram of hardware resources 1100, including one or more processors (or processor cores) 1110, one or more memory / storage devices 1120, and one or more communication resources 1130, each of which may be communicatively coupled via a bus 1140. For specific implementations in which node virtualization (e.g., NFV) is utilized, a hypervisor 1102 may be executed to provide an execution environment for one or more network slices / sub-slices to utilize the hardware resources 1100.

[0242] The processor 1110 may include, for example, processor 1112 and processor 1114. The processor 1110 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.

[0243] The memory / storage device 1120 may include a main memory, a disk storage device, or any suitable combination thereof. The memory / storage device 1120 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.

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

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

[0246] 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.

[0247] The specific implementations of the subject matter and functional operations described in this specification can be implemented in digital electronic circuits, in tangibly embodied computer software or firmware, in computer hardware (including the structures disclosed in this specification and their structural equivalents), 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 device 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.

[0248] 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, a 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, ANTROL, or IOS).

[0249] 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 via 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 various components may be combined into a single component as appropriate. Thresholds for performing computational determinations can be determined statically, dynamically, or both statically and dynamically simultaneously.

[0250] The methods, processes, or logical flows described in this specification can be executed 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 executed by dedicated logic circuitry (e.g., a CPU, FPGA, or ASIC), and the apparatus can also be implemented as dedicated logic circuitry.

[0251] 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, 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 implementations, the computer can receive data from and transfer data to the 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.

[0252] A computer-readable medium (transitory or non-transitory, as the case may be) 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 the memory may be supplemented by, or incorporated in, dedicated logic circuitry.

[0253] Although this specification includes many specific implementation details, these details 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 described previously 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 removed from the combination, and the claimed combination may cover a sub-combination or a variation of a sub-combination.

[0254] Specific 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 a specific order in the drawings or claims, this should not be construed as requiring that such operations be performed in the specific order or sequence shown, or that all of the operations shown 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 as appropriate.

[0255] 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.

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

[0257] The present disclosure may also include the following examples.

[0258] Example 1 includes a method performed by a client device in a wireless network for transmitting Transmission Control Protocol Acknowledgment (TCP ACK) packets, the method including: 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 including TCP ACK packets to be transmitted to the other device, 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 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 including 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 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 in response to the determination, marking the first TCP ACK packet as to be discarded.

[0259] Example 2 includes the method according to Example 1, wherein the first entry in the data structure corresponds to a second TCP ACK packet in the queue, and wherein the first TCP ACK packet is generated before the second TCP ACK packet, and wherein a position of the first TCP ACK packet in the queue is in front of a position of the second TCP ACK packet in the queue.

[0260] Example 3 includes the method according to Example 2, wherein the queue is checked starting from the latest packet first.

[0261] Example 4 includes the method according to Example 1, wherein the packet descriptor is assigned by a TCP application processor included in the client device, and the packet descriptor is examined by a baseband processor circuit included in the client device.

[0262] Example 5 includes the method according to Example 4, wherein the application processor assigns the first ACK generation count value corresponding to the 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 the second flow identifier to a plurality of TCP ACK packets generated in a second time interval different from the first time interval, and the first ACK generation count value is different from the second ACK generation count value.

[0263] Example 6 includes the method according to Example 5, wherein 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.

[0264] Example 7 includes the method according to Example 1, further comprising: checking a packet descriptor of a third TCP ACK packet among the 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.

[0265] Example 8 includes the method according to Example 7, wherein 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.

[0266] Example 9 includes the method according to Example 1, further comprising: checking a packet descriptor of a third TCP ACK packet among the TCP ACK 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 flow identifier is set to an invalid value; and in response to the determination, aborting further processing of the third TCP ACK packet.

[0267] Example 10 includes the method according to Example 9, wherein determining that the third flow identifier of the third TCP ACK packet is set to an invalid value includes determining one of the following: a 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.

[0268] Example 11 includes the method according to Example 1, further comprising: checking a packet descriptor of a fourth TCP packet among the TCP packets in the queue; 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 the determination, updating 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.

[0269] Example 12 includes the method according to Example 1, further comprising: checking a packet descriptor of a fifth TCP packet among the TCP packets in the queue; 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 the 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.

[0270] Example 13 includes the method according to Example 1, wherein the received TCP packet includes one or more of application control information and application data.

[0271] Example 14 includes the method according to Example 1, wherein the queue includes one or more additional TCP ACK packets having packet descriptors without a TCP ACK generation count field.

[0272] Example 15 includes the method according to Example 1, wherein one or more entries in the data structure include a hash value representing a flow identifier, and wherein determining that the data structure includes a first entry storing the first TCP ACK generation count and the 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 a match exists; and in response to the comparison, determining that the hash value included in the first entry matches the first hash value.

[0273] Example 16 includes a method performed by a client device in a wireless network for transmitting Transmission Control Protocol Acknowledgment (TCP ACK) packets, the method comprising: 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 comprising TCP ACK packets to be transmitted to the other network device, 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 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 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 determining, 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.

[0274] Example 17 includes the method according to Example 16, wherein the first entry in the data structure corresponds to a second TCP ACK packet in the queue, and wherein the first TCP ACK packet is generated before the second TCP ACK packet, and wherein 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.

[0275] Example 18 includes the method according to Example 17, wherein the queue is examined starting from the latest packet first.

[0276] Example 19 includes the method according to Example 16, wherein the packet descriptor is assigned by a TCP application processor included in the client device, and the packet descriptor is checked by a baseband processor circuit included in the client device.

[0277] Example 20 includes the method according to Example 19, wherein the application processor assigns a first ACK generation count value corresponding to the 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 the 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.

[0278] Example 21 includes the method according to Example 20, wherein 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.

[0279] Example 22 includes the method according to Example 16, further comprising: checking a packet descriptor of a third TCP ACK packet among the 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.

[0280] Example 23 includes the method according to Example 22, wherein 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.

[0281] Example 24 includes the method according to Example 16, further comprising: checking a packet descriptor of a third TCP ACK packet among the TCP ACK 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 flow identifier is set to an invalid value; and in response to the determination, aborting further processing of the third TCP ACK packet.

[0282] Example 25 includes the method according to Example 24, wherein 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.

[0283] Example 26 includes the method according to Example 16, further comprising: checking a packet descriptor of a fourth TCP packet among the TCP packets in the queue; 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 the 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.

[0284] Example 27 includes the method according to Example 16, further comprising: checking a packet descriptor of a fifth TCP packet among the TCP packets in the queue; 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 the 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.

[0285] Example 28 includes the method according to Example 16, wherein the received TCP packet includes one or more of application control information and application data.

[0286] Example 29 includes the method according to Example 16, wherein the queue includes one or more additional TCP ACK packets having packet descriptors without a TCP ACK generation count field.

[0287] Example 30 includes the method according to Example 16, wherein one or more entries in the data structure include a hash value representing a flow identifier, and wherein determining that the data structure includes a first entry storing the first TCP ACK generation count and the 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.

[0288] Example 31 includes the method according to Example 16, wherein one or more entries in the data structure include a hash value representing a flow identifier, and wherein determining that the data structure includes a first entry storing the first TCP ACK generation count and the 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.

[0289] Example 32 includes a method performed by a Transmission Control Protocol (TCP) application processor in a client device in a wireless network for TCP acknowledgment (TCP ACK) packet transmission, the method including: 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 a respective packet descriptor 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 subset of the TCP ACK packets including the TCP ACK packets to a baseband processor included in the client device.

[0290] Example 33 includes the method according to Example 32, wherein 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.

[0291] Example 34 includes the method according to Example 33, wherein 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.

[0292] Example 35 includes the method according to Example 32, further comprising determining, by the application processor, that a first TCP ACK packet includes at least one of additional header information or TCP payload information; and in response to the determination, setting the ACK generation count value in the packet descriptor of the first TCP ACK packet to a predetermined invalid value.

[0293] Example 36 includes the method according to Example 32, further comprising determining, by the application processor, that a 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 the baseband processor without a TCP ACK generation count value.

[0294] Example 37 includes the method according to Example 32, further comprising determining, by the application processor, that a first TCP ACK packet includes at least one of additional header information or TCP payload information; and in response to the determination, setting the flow identifier in the packet descriptor of the first TCP ACK packet to a predetermined invalid value.

[0295] Example 38 includes the method according to Example 32, further comprising determining, by the application processor, that a 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 the baseband processor without a flow identifier.

[0296] Example 39 includes a baseband processor of a user equipment (UE) in a wireless network, the baseband processor comprising: circuitry for executing instructions for performing the operations according to any one of Examples 1 - 15.

[0297] Example 40 includes a baseband processor of a user equipment (UE) in a wireless network, the baseband processor comprising: circuitry for executing instructions for performing the operations according to any one of Examples 16 - 31.

[0298] Example 41 includes an application processor of a user equipment (UE) in a wireless network, the application processor comprising: circuitry for executing instructions for performing the operations according to any one of Examples 32 - 38.

[0299] Example 42 includes one or more non-transitory computer-readable media storing instructions that, when executed, are configured to cause one or more processors to perform the operations according to any one of Examples 1-15.

[0300] Example 43 includes one or more non-transitory computer-readable media storing instructions that, when executed, are configured to cause one or more processors to perform the operations according to any one of Examples 16-31.

[0301] Example 44 includes one or more non-transitory computer-readable media storing instructions that, when executed, are configured to cause one or more processors to perform the operations according to any one of Examples 32-38.

Claims

1. A method, the method comprises: accessing, in a queue of a memory coupled to a user equipment (UE) in a wireless network, a first Transmission Control Protocol acknowledgement (TCP ACK) packet corresponding to a Transmission Control Protocol (TCP) session; identifying, using information included in a packet descriptor of the first TCP ACK packet, a TCP flow identifier and a TCP ACK generation count corresponding to the first TCP ACK packet, wherein the TCP ACK generation count represents a count value indicating a count of duplicate TCP ACK packets for a TCP flow; determining that the queue includes a second TCP ACK packet having the same TCP flow identifier and the same TCP ACK generation count as the first TCP ACK packet; and in response to the determination, discarding the first TCP ACK packet.

2. The method according to claim 1, further comprising determining that the TCP flow includes a plurality of Network Protocol (IP) packet flows, wherein determining that the queue includes the second TCP ACK packet is based on determining that the first TCP ACK packet corresponds to uplink data transmitted in one or more given IP packet flows.

3. The method according to claim 2, wherein a packet descriptor of a TCP ACK packet is assigned by a TCP application processor included in the UE, and the packet descriptor is checked by a baseband processor circuit included in the UE, wherein the TCP application processor assigns a first ACK generation count value corresponding to the TCP 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 TCP 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.

4. The method according to claim 3, wherein the TCP application processor controls a rate of discarding TCP ACK packets from the queue by controlling a duration of at least one of the first time interval or the second time interval.

5. The method according to claim 1, wherein the first TCP ACK packet is generated before the second TCP ACK packet, and a position of the first TCP ACK packet in the queue is in front of a position of the second TCP ACK packet in the queue, and wherein the queue is checked starting from the latest packet.

6. The method according to claim 1, further comprises: checking a packet descriptor of a third TCP ACK packet in the queue; identifying a third TCP ACK generation count and a third TCP 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, including determining one of the following: the TCP ACK generation count of the third TCP ACK packet is empty, or the TCP ACK generation count of the third TCP ACK packet is set to a predetermined invalid value; and in response to the determination, abort further processing of the third TCP ACK packet.

7. The method according to claim 1, further comprising: checking a packet descriptor of a third TCP ACK packet in the queue; identifying a third TCP ACK generation count and a third TCP 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 flow identifier is set to an invalid value, including determining one of the following: a flow identifier is not assigned to the third TCP ACK packet, or the flow identifier of the third TCP ACK packet is set to a predetermined invalid value; and in response to the determination, abort further processing of the third TCP ACK packet.

8. The method according to claim 7, further comprising: checking a packet descriptor of a fourth TCP ACK packet in the queue; identifying a fourth TCP ACK generation count and a fourth TCP 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 TCP flow identifier are valid; determining (i) that the fourth TCP flow identifier is the same as the TCP flow identifier corresponding to the first TCP ACK packet, and (ii) that the fourth TCP ACK generation count is different from the TCP ACK generation count corresponding to the first TCP ACK packet; and in response to the determination, updating the TCP ACK generation count corresponding to the first TCP ACK packet in the queue with the fourth TCP ACK generation count.

9. The method according to claim 8, further comprising: checking a packet descriptor of a fifth TCP ACK packet in the queue; identifying a fifth TCP ACK generation count and a fifth TCP flow identifier corresponding to the fifth TCP ACK packet included in the packet descriptor of the fifth TCP ACK packet; determining that the fifth TCP ACK generation count and the fifth TCP flow identifier are valid; determining that the queue does not include an entry corresponding to the fifth TCP flow identifier; and in response to the determination, storing the fifth TCP flow identifier and the fifth TCP ACK generation count in the queue.

10. A method performed by an application processor of a user equipment (UE) in a wireless network, the method comprising: generating a transmission control protocol acknowledgement (TCP ACK) packet for a transmission control protocol (TCP) session During a first time interval, assign a first ACK generation count value to a first number of TCP ACK packets for the TCP session generated during the first time interval, where the first ACK generation count value represents a count value indicating duplicate TCP ACK packets for the TCP session; Add the first ACK generation count value to a packet descriptor of one or more of the first number of TCP ACK packets; Forward the first number of TCP ACK packets to a baseband processor of the UE; During a second time interval, assign a second ACK generation count value to a second number of TCP ACK packets for the TCP session generated during the second time interval, where the second time interval is different from the first time interval and the second ACK generation count value is different from the first ACK generation count value; Add the second ACK generation count value to a packet descriptor of one or more of the second number of TCP ACK packets; And Forward the second number of TCP ACK packets to the baseband processor of the UE.

11. A processor, the processor includes circuitry for executing instructions to perform the method according to any one of claims 1 to 10.

12. An apparatus, the apparatus includes one or more processors configured to perform operations including: Access a first Transmission Control Protocol Acknowledgment (TCP ACK) packet corresponding to a Transmission Control Protocol (TCP) session in a queue of a memory coupled to a User Equipment (UE) in a wireless network; Utilize information included in a packet descriptor of the first TCP ACK packet to identify a TCP flow identifier and a TCP ACK generation count corresponding to the first TCP ACK packet, where the TCP ACK generation count represents a count value indicating duplicate TCP ACK packets for the TCP flow; Determine that the queue includes a second TCP ACK packet having the same TCP flow identifier and the same TCP ACK generation count as the first TCP ACK packet; And In response to the determination, discard the first TCP ACK packet.

13. The apparatus according to claim 12, the operation further Includes: Determine that the TCP flow includes a plurality of Network Protocol (IP) packet flows, where determining that the queue includes the second TCP ACK packet is based on determining that the first TCP ACK packet corresponds to uplink data transmitted in one or more given IP packet flows.

14. The apparatus according to claim 13, where a packet descriptor of the TCP ACK packet is assigned by a TCP application processor included in the UE, and the packet descriptor is checked by a baseband processor circuit included in the UE, The TCP application processor assigns a first ACK generation count value corresponding to the TCP 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 TCP flow identifier to a plurality of 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.

15. The apparatus according to claim 14, wherein the TCP 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.

16. The apparatus according to claim 12, wherein the first TCP ACK packet is 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, and wherein the queue is checked starting from the latest packet.

17. The apparatus according to claim 12, the operation further comprises: checking a packet descriptor of a third TCP ACK packet in the queue; identifying a third TCP ACK generation count and a third TCP 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, including determining one of the following: the TCP ACK generation count of the third TCP ACK packet is empty, or the TCP ACK generation count of the third TCP ACK packet is set to a predetermined invalid value; and in response to the determination, aborting further processing of the third TCP ACK packet.

18. The apparatus according to claim 12, the operation further comprises: checking a packet descriptor of a third TCP ACK packet in the queue; identifying a third TCP ACK generation count and a third TCP 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 flow identifier is set to an invalid value, including determining one of the following: a flow identifier is not assigned to the third TCP ACK packet, or the flow identifier of the third TCP ACK packet is set to a predetermined invalid value; and in response to the determination, aborting further processing of the third TCP ACK packet.

19. The apparatus according to claim 18, the operation further comprises: checking a packet descriptor of a fourth TCP ACK packet in the queue; identifying a fourth TCP ACK generation count and a fourth TCP flow identifier corresponding to the fourth TCP ACK packet included in the packet descriptor of the fourth TCP ACK packet; Determine that the fourth TCP ACK generation count and the fourth TCP flow identifier are valid; Determine (i) that the fourth TCP flow identifier is the same as the TCP flow identifier corresponding to the first TCP ACK packet, and (ii) that the fourth TCP ACK generation count is different from the TCP ACK generation count corresponding to the first TCP ACK packet; And In response to the determination, update the TCP ACK generation count corresponding to the first TCP ACK packet in the queue with the fourth TCP ACK generation count.

20. An apparatus, the apparatus comprising one or more processors configured to perform operations including the following: Generate a Transmission Control Protocol acknowledgement (TCP ACK) packet for a Transmission Control Protocol (TCP) session; In a first time interval, assign a first ACK generation count value to a first number of TCP ACK packets for the TCP session generated in the first time interval, wherein the first ACK generation count value represents a count value indicating duplicate TCP ACK packets for the TCP session; Add the first ACK generation count value to a packet descriptor of one or more of the first number of TCP ACK packets; Forward the first number of TCP ACK packets to a baseband processor of a user equipment (UE); In a second time interval, assign a second ACK generation count value to a second number of TCP ACK packets for the TCP session generated in the second time interval, wherein the second time interval is different from the first time interval and the second ACK generation count value is different from the first ACK generation count value; Add the second ACK generation count value to a packet descriptor of one or more of the second number of TCP ACK packets; And Forward the second number of TCP ACK packets to the baseband processor of the UE.

Images