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

Abstract

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

Description

Technical Field

[0001] The following disclosure relates in general to communication technology, and more particularly to systems, methods and apparatus for transmission control protocol (TCP) acknowledgment (ACK) transmission in communication networks. Background Technology

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

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

[0004] TCP is a reliable streaming delivery service in which a receiver of TCP packets responds to the sender with a TCP ACK message when it receives a TCP packet. For reliable transmission, TCP uses sequence numbers to identify each data byte. Sequence numbers identify the order in which bytes were sent from each computer, allowing data to be reconstructed in order, regardless of any packet reordering or loss that may occur during transmission. The receiver sends a TCP ACK along with the sequence number to inform the sender that the specified byte of data has been received. The sequence number associated with the TCP ACK is cumulative and used to acknowledge all data bytes received up to that sequence number. In some cases, TCP packets may be lost during transmission, and the receiver may receive TCP packets with sequence numbers that are not consecutive in the sequence number chain. In such cases, upon detecting a break in the sequence number chain, the receiver sends a duplicate ACK with the latest sequence number before the break. This duplicate ACK acts 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 packets.

[0005] In some implementations, duplicate TCP ACKs are part of a fault recovery mechanism to ensure the reliability of the TCP protocol. A duplicate ACK is sent when the client device notices gaps between a series of packets or when it 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 begins sending duplicate TCP ACKs, allowing the server to initiate a rapid retransmission process.

[0006] In some implementations, the TCP protocol uses duplicate ACKs and timer timeouts to retransmit lost data packets. Duplicate ACKs are used as part of fast retransmission and data packet recovery. In some implementations, duplicate TCP ACKs are used to notify the server before a timeout occurs. Because the server doesn't know whether receiving duplicate TCP ACKs is due to lost data packets or simply due to packet reordering, it waits to receive a small number of duplicate TCP ACKs. If multiple duplicate TCP ACKs are received consecutively, this strongly indicates that data packets have been lost.

[0007] In some implementations, a server sending 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 acknowledging successful receipt of the sent unacknowledged data packets. If the server sending the series of data packets has already sent the predetermined number of unacknowledged data packets, the server must abort sending additional sequential packets in the series and / or retransmit one or more previously sent data packets until the server receives a TCP ACK from the client device. Therefore, if there is a delay in the client device sending TCP ACK packets to acknowledge receipt of 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 is stopped.

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

[0009] The various implementations disclosed herein provide optimizations for TCP connections (also interchangeably referred to as TCP streams or TCP flows) by discarding duplicate or redundant TCP ACK packets at the receiver (e.g., a client device) when a TCP ACK packet is sent to the sender (e.g., the AS). In some implementations, the client device is configured to discard one or more packets from older TCP ACK packets pending processing in the output queue at the client device within the TCP uplink stream (e.g., from the client device to the AS) in response to the detection of a newer duplicate TCP ACK packet (e.g., a TCP ACK packet with the same sequence number at the head of the output queue).

[0010] In some 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 over the network to the AS. The TCP layer within the client device's 3GPP protocol stack is implemented to check the queue during the UL delay, for example, as the queue grows, to determine whether some TCP ACK packets are redundant (e.g., have the same sequence number as one or more other TCP ACK packets) and can be discarded before transmission. Discarding redundant TCP ACK packets is also referred to as traffic reduction in this specification.

[0011] In general, a client device in a wireless network manages Transmission Control Protocol Acknowledgment (TCP ACK) packet transmission by accessing a queue of TCP ACK packets to be transmitted to the other device in memory in response to receiving a TCP packet from another device in the wireless network. At least a subset of the TCP ACK packets in the queue includes corresponding packet descriptors, each packet descriptor having a stream identifier indicating the TCP stream associated with the packet and a TCP ACK generation count. The client device examines the packet descriptor of a first TCP ACK packet in the queue and identifies a first stream identifier and a first TCP ACK generation count corresponding to the first TCP ACK packet. Upon determining that the first stream identifier and the first TCP ACK generation count are valid, the client device accesses entries in a data structure in memory, where each entry includes a first field storing the stream identifier and a second field storing the corresponding TCP ACK generation count. The client device determines that the data structure includes a stream identifier and a TCP ACK generation count that respectively match the first stream 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.

[0012] Specific implementations include one or more of the following features: 1. In some implementations, the first entry in the data structure corresponds to the second TCP ACK packet in the queue, wherein the first TCP ACK packet was generated before the second TCP ACK packet, and wherein the first TCP ACK packet is positioned in the queue before the second TCP ACK packet. In some implementations, the queue is checked starting with the most recent packet.

[0013] In some implementations, these packet descriptors are assigned by a TCP application processor included in the client device, and these packet descriptors are inspected by baseband processor circuitry included in the client device. In some implementations, the application processor assigns a first ACK generation count value corresponding to a first stream 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 stream 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 implementations, the application processor controls the rate at which TCP ACK packets are discarded from the queue by controlling the duration of at least one of the first or second time intervals.

[0014] In some implementations, the client device examines the packet descriptor of the third TCP ACK packet in the TCP packets in the queue, and identifies the third TCP ACK generation count and third stream 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 implementations, determining that the TCP ACK generation count of the third TCP packet is set to an invalid value includes determining that: 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.

[0015] In some implementations, the client device examines the packet descriptor of a third TCP ACK packet in the TCP ACK packet queue and identifies the third TCP ACK generation count and third stream 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 stream 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 implementations, determining that the third stream identifier of the third TCP ACK packet is set to an invalid value includes determining one of the following: the stream identifier was not assigned to the third TCP ACK packet; or the stream identifier of the third TCP packet was set to a predetermined invalid value.

[0016] In some specific implementations, the client device examines the packet descriptor of the fourth TCP packet in the queue of TCP packets and identifies the fourth TCP ACK generation count and the fourth stream 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 stream identifier are valid. The client device determines that (i) the fourth stream identifier is the same as the first stream 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.

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

[0018] In some specific implementations, the received TCP packets include one or more of application control information and application data.

[0019] In some implementations, the queue includes one or more additional TCP ACK packets, which have packet descriptors without a TCP ACK generation count field.

[0020] In some specific implementations, one or more entries in the data structure include a hash value representing a stream identifier, and wherein determining that the data structure includes a first entry storing a first TCP ACK generation count and a first stream identifier and the first TCP ACK generation count includes: performing a hash function on the first stream 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 stream identifier; comparing the first hash value with hash values ​​included in one or more entries in the data structure to determine whether a match exists; and

[0021] In response to this comparison, it is determined that the hash value included in the first entry matches the first hash value.

[0022] In another general aspect, a method for transmitting TCP ACK packets 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 of 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 stream identifier indicating a TCP stream associated with the packet and (ii) a TCP ACK generation count; checking the packet descriptor of a first TCP ACK packet in the queue of TCP ACK packets; identifying a first stream 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 stream 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 stream identifier and a corresponding TCP ACK generation count; determining that the data structure includes a first entry including (i) a stream identifier matching the first stream identifier and (ii) a TCP ACK generation count matching the first TCP ACK generation count, the first entry further storing a second TCP ACK generation count corresponding to the first TCP ACK packet. The second position field of the position of the ACK packet in the queue; in response to the determination, storing the position of the first TCP ACK packet in the first position field of 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 in the queue previously occupied by the second TCP ACK packet, and the second TCP ACK packet moves to the position in the queue previously occupied by the first TCP ACK packet; and discarding the first TCP ACK packet from the queue.

[0023] Specific implementations include one or more of the following features. In some implementations, the first entry in the data structure corresponds to the second TCP ACK packet in the queue, and the first TCP ACK packet is generated before the second TCP ACK packet, and the first TCP ACK packet is positioned in the queue before the second TCP ACK packet is positioned in the queue.

[0024] In some implementations, the queue is checked starting with the most recent group.

[0025] In some implementations, these packet descriptors are assigned by a TCP application processor included in the client device, and these packet descriptors are inspected by baseband processor circuitry included in the client device. In some implementations, the application processor assigns a first ACK generation count value corresponding to a first stream 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 stream 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 implementations, the application processor controls the rate at which TCP ACK packets are discarded from the queue by controlling the duration of at least one of the first or second time intervals.

[0026] In some implementations, the method further includes: checking the packet descriptor of a third TCP ACK packet in the queue; identifying the third TCP ACK generation count and third stream 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 this determination, aborting further processing of the third TCP ACK packet. In some implementations, determining that the TCP ACK generation count of the third TCP packet is set to an invalid value includes determining that the TCP ACK generation count of the third TCP packet is empty; or that the TCP ACK generation count of the third TCP packet is set to a predetermined invalid value.

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

[0028] In some specific implementations, the method further includes: examining the packet descriptor of a fourth TCP packet in the TCP packets in the queue; identifying the fourth TCP ACK generation count and the fourth stream identifier included in the packet descriptor of the fourth TCP ACK packet corresponding to the fourth TCP ACK packet; determining that the fourth TCP ACK generation count and the fourth stream identifier are valid; determining that (i) the fourth stream identifier is the same as the first stream 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; and in response to this determination, updating the first entry by replacing the first TCP ACK generation count stored in the second position field of the first entry with the fourth TCP ACK generation count.

[0029] In some specific implementations, the method further includes: checking the packet descriptor of the fifth TCP packet in the queue; identifying the fifth TCP ACK generation count and the fifth stream 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 stream identifier are valid; determining that the data structure does not include an entry corresponding to the fifth stream identifier; and in response to the determination, creating a third entry in the data structure and storing the fifth stream identifier and the fifth TCP ACK generation count in the third entry.

[0030] In some specific implementations, the received TCP packets include one or more of application control information and application data.

[0031] In some implementations, the queue includes one or more additional TCP ACK packets, which have packet descriptors without a TCP ACK generation count field.

[0032] In some specific implementations, one or more entries in the data structure include a hash value representing a stream identifier, and wherein determining that the data structure includes a first entry storing a first TCP ACK generation count and a first stream identifier and a first TCP ACK generation count includes: performing a hash function on the first stream 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 stream identifier; comparing the first hash value with hash values ​​included in one or more entries in the data structure to determine if a match exists; and in response to the comparison, determining that the hash value included in the first entry matches the first hash value.

[0033] In some specific implementations, one or more entries in the data structure include a hash value representing a stream identifier, and wherein determining that the data structure includes a first entry storing a first TCP ACK generation count and a first stream identifier and a first TCP ACK generation count includes: performing a hash function on the first stream 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 stream identifier; comparing the first hash value with hash values ​​included in one or more entries in the data structure to determine if a match exists; and in response to the comparison, determining that the hash value included in the first entry matches the first hash value.

[0034] 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 transmission to a remote device in the wireless network, each TCP ACK packet including a packet descriptor; storing (i) a flow identifier indicating a TCP stream associated with the packet and (ii) a TCP ACK generation count in the corresponding packet descriptors of at least a subset of the TCP ACK packets; and forwarding the TCP ACK packets, including the subset of TCP ACK packets, to a baseband processor included in the client device.

[0035] Specific implementations include one or more of the following features. In some 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 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.

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

[0037] 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 if no TCP ACK generation count value is generated.

[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 flow identifier in the packet descriptor of the first TCP ACK packet to a predetermined invalid value.

[0039] In some 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 in the absence of a flow identifier.

[0040] The elimination of redundant TCP ACK packets in the UL, as disclosed in the specific implementation described, results in: fewer packet processing and power savings in subsequent processing entities; reduced data volume to be sent, or the saved bandwidth being reused by other packet data services; reduced latency for all subsequent UL packets (after the discarded packet); or reduced TCP RTT (Round-Trip Time), which ultimately leads to a faster increase in TCP throughput and therefore higher end-to-end throughput. This results in a faster and more efficient method of packet data transmission compared to conventional TCP methods.

[0041] Specific implementations of the above technologies include methods, apparatus, and computer program products. One such computer program product is suitably embodied in one or more non-transitory machine-readable media storing instructions configured, when executed by one or more processors, to cause the one or more processors to perform the aforementioned actions. One such apparatus includes processing circuitry for executing the instructions to perform the aforementioned 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., a UE) in a wireless network. Attached Figure Description

[0042] Figure 1 A block diagram of a communication system based on some publicly available specific implementations is shown.

[0043] Figure 2 Optimizations to TCP ACK packets based on some publicly available implementations are shown.

[0044] Figure 3 A flowchart is shown of an exemplary process for managing TCP ACK packets, based on some publicly available specific implementations.

[0045] Figure 4 An optimization of the TCP ACK packet stream is shown based on some publicly available specific implementations.

[0046] Figure 5A flowchart is shown of a second exemplary process for managing TCP ACK packets, based on some publicly disclosed specific implementations.

[0047] Figure 6 The data structures for managing TCP ACK packets are shown according to some publicly available specific implementations.

[0048] Figure 7 A second data structure for managing TCP ACK packets by reordering, based on some publicly available specific implementations, is shown.

[0049] Figure 8 A block diagram of a communication device based on some publicly available specific implementations is shown.

[0050] Figure 9 A block diagram of a communication device based on some publicly available specific implementations is shown.

[0051] Figure 10 This illustrates a 3GPP protocol stack based on some publicly available implementations.

[0052] Figure 11 A block diagram of a communication system based on some publicly available specific implementations is shown. Detailed Implementation

[0053] TCP is a network communication protocol that enables reliable data exchange between two host devices (e.g., client devices and servers such as AS) over a communication network (e.g., a 3GPP wireless communication network). TCP is a connection-oriented protocol; hardware and software operations performed by the host device implementing the TCP protocol (generally referred to as TCP in this disclosure) in the protocol stack 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 client devices (e.g., UEs) and servers (e.g., ASs) 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.

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

[0055] When a server sends a TCP data packet (also simply called a data packet) to a client device, the client device sends a TCP ACK packet to indicate that the TCP data packet has been received. The client device chooses the initial sequence number set in the first SYN packet. The server also chooses its own initial sequence number set in the SYN ACK packet. Each side confirms the other's sequence number by incrementing the sequence number; this is called 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 a server sends a TCP data packet to a client device, the client device acknowledges the TCP data packet by responding with a TCP ACK packet.

[0056] In some 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 is ready to 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.

[0057] In some implementations, the available downlink (DL) bandwidth is greater than the available uplink (UL) bandwidth. In some cases, constraints in the available UL bandwidth prevent the transmission of TCP ACK data packets at the same rate as receiving TCP data packets from the server. During the UL delay period, a large number of TCP ACKs may accumulate in the output queue. Therefore, data packet transmission from the server may be halted due to the delay in TCP ACK packet transmission, leading to a degradation in throughput.

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

[0059] Client devices use a counter called the TCP ACK generation count to track TCP ACK packets for potential replicas. In some implementations, the process of implementing the TCP application (also known as the application processor, AP) in the client device generates the TCP ACK generation count value (also known as the ACK Gen Count) and stamps the packets with the counter value before they are sent to the BBU circuitry for uplink transmission. In some implementations, the AP increments the counter every n milliseconds (where n is a positive integer). The AP stamps TCP ACK data packets with the same counter value generated for the specific time interval at n millisecond intervals. In some implementations, n is set to a predetermined value, for example, as a design parameter. In other implementations, the TCP AP 105 is configured to dynamically modify the value of n at runtime, for example, based on the current throughput.

[0060] Upon receiving a TCP ACK packet from the AP, the BBU temporarily stores the packet in the output queue until UL transmission. In some implementations, the BBU uses a counter value to determine whether some TCP ACK packets in the output queue are redundant and can be discarded. This may occur, for example, during UL transmission delays when the queue length increases. By using the counter value, the BBU ensures that at least one TCP ACK packet is sent to the server in the UL direction on the 3GPP network within a certain time period (e.g., n milliseconds), making the TCP connection stable even if some TCP ACK packets are discarded. The server begins retransmitting data packets after receiving the first duplicate TCP ACK packet.

[0061] Figure 1 An exemplary wireless communication system 100 implementing the disclosed TCP ACK management technology 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.

[0062] For 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 a Non-Standalone (NSA) network combining both LTE and NR (e.g., E-UTRA (Evolved Universal Terrestrial Radio Access) - NR Dual Connectivity (EN-DC) network and NE-DC network). However, System 100 may also be a Standalone (SA) network combining only NR. System 100 may also implement other types of communication standards, including future 3GPP systems (e.g., sixth generation (6G) systems), IEEE 802.16 protocols (e.g., WMAN, WiMAX, etc.), etc.

[0063] 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 may include multiple client devices, and the disclosed techniques are equally applicable to these client devices. The client device or UE 102 can be any suitable type of mobile or non-mobile computing device, such as consumer electronics, cellular phones, smartphones, feature phones, tablet computers, wearable computing devices, personal digital assistants (PDAs), pagers, wireless handheld devices, desktop computers, laptop computers, in-vehicle infotainment (IVI), in-vehicle entertainment (ICE) devices, instrument panel (IC), head-up display (HUD) devices, onboard diagnostic (OBD) devices, in-vehicle mobility equipment (DME), mobile data terminal (MDT), electronic engine management system (EEMS), electronic / engine control unit (ECU), electronic / engine control module (ECM), embedded systems, microcontrollers, control modules, engine management system (EMS), connected or “smart” appliances, machine-type communication (MTC) devices, machine-to-machine (M2M) devices, Internet of Things (IoT) devices, or combinations thereof.

[0064] In some implementations, client device 102 is an Internet of Things (IoT) client device, which may include a network access layer designed for low-power IoT applications utilizing short-lived client device connectivity. 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 Service (ProSe), Device-to-Device (D2D) communication, sensor networks, IoT networks, or combinations thereof. 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-lived connectivity. The IoT client devices may execute background applications (e.g., keeping track of activity messages, status updates, etc.) to facilitate connectivity within the IoT network.

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

[0066] Network 108 may be embodied as any network that supports communication between two networked devices, such as between client device 102 and application server 110(a). Network 108 may be embodied, for example, as a wired network (e.g., Ethernet network, wired LAN, fiber optic network, wired network maintained by a telephone / wired service provider, some combination thereof, etc.), a wireless network (e.g., cellular network, wireless LAN, wireless WAN, some combination thereof, etc.), or a combination thereof, and in some exemplary embodiments may include the Internet.

[0067] In some implementations, client device 102 is connected to an access network (AN) or radio access network (RAN) 112. In some examples, RAN 112 may 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, the term "NG RAN" and the like may refer to a RAN operating in a 5G NR system 100, while the term "E-UTRAN" and the like may refer to a RAN operating in an LTE or 4G system 100. Client device 102 utilizes connections (or channels) 109, each connection (or channel) including a physical communication interface or layer.

[0068] In this example, connection 109 is shown as an air interface for implementing communication coupling and may be consistent with cellular communication protocols such as GSM, CDMA network protocols, PTT, POC, UMTS, 3GPP LTE, LTE-A (LTE-Advanced Long Term Evolution), LTE-U (LTE-U), 5G, NR, NR-U (NR-U), and / or any other suitable wireless communication protocol.

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

[0070] RAN 112 may include one or more AN nodes or RAN nodes 112a and 112b (collectively referred to as "RAN node 112a", "RAN node 112b", or "RAN node 112a-b") that enable connection 109. As used herein, the terms "access node", "access point", etc., can describe equipment that provides radio baseband functionality for data and / or voice connections between the 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 ground stations (e.g., terrestrial access points) or satellite stations that provide coverage within a geographic area (e.g., a cell). As used herein, the terms "NG RAN node", etc., can refer to RAN node 112 (e.g., gNB) operating in NR or 5G system 100, while the terms "E-UT RAN node", etc., can refer to RAN node 112 (e.g., eNB) operating in LTE or 4G system. Depending on the specific implementation, RAN nodes 112a-b may be implemented as one or more of dedicated physical devices such as macro cell base stations and / or low-power (LP) base stations for providing smaller coverage areas, smaller user capacity, or higher bandwidth compared to macro cells.

[0071] In some implementations, all or some of the RAN nodes 112a-b can be implemented as one or more software entities running on a server computer as part of a virtual network, which may be referred to as CRAN and / or Virtual Baseband Unit Pool (vBBUP). In these implementations, CRAN or vBBUP can implement RAN function partitioning, such as PDCP partitioning, where the RRC and PDCP layers are operated by CRAN / vBBUP, while other L2 protocol entities are operated by the individual RAN nodes 112a-b; MAC / PHY partitioning, where the RRC, PDCP, RLC, and MAC layers are operated by CRAN / vBBUP, while the PHY layer is operated by the individual RAN nodes 112a-b; or "lower PHY" partitioning, where the upper part of the RRC, PDCP, RLC, MAC, and PHY layers is operated by CRAN / vBBUP, while the lower part of the PHY layer is operated by the individual RAN nodes 112a-b. This virtualization framework allows the idle processor cores of RAN nodes 112a-b to execute other virtualized applications. In some implementations, each RAN node 112a-b may represent a gNB-DU connected to the gNB-CU via a respective F1 interface (not shown). In these implementations, 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 in RAN 112 or by a server pool in a manner similar to CRAN / vBBUP. Alternatively, one or more RAN nodes in RAN nodes 112a-b may be next-generation eNBs (ng-eNBs), which are RAN nodes that provide E-UTRA user plane and control plane protocol terminals to client equipment 102 and are connected to the 5GC via an NG interface (discussed below).

[0072] In a vehicle-to-everything (V2X) scenario, one or more RAN nodes in RAN nodes 112a-b can be or act as roadside units (RSUs). The term "roadside unit" or "RSU" can refer to any traffic infrastructure entity used for V2X communication. An RSU can be implemented in or by a suitable RAN node or a stationary (or relatively stationary) UE, wherein an RSU implemented in or by a UE can be referred to as a "UE-type RSU," an RSU implemented in or by an eNB can be referred to as an "eNB-type RSU," an RSU implemented in or by a gNB can be referred to as a "gNB-type RSU," and so on. In one example, an RSU is a computing device coupled to radio frequency circuitry located on the roadside, which provides connectivity support to passing vehicle client devices. An RSU may also include internal data storage circuitry for storing intersection map geometry, traffic statistics, media, and applications / software for sensing and controlling ongoing vehicle and pedestrian traffic. The RSU may operate on the 5.9 GHz Direct Near Range Communication (DSRC) band to provide extremely low-latency communication required for high-speed events, such as collision avoidance and traffic warnings. Alternatively, the RSU may operate on the cellular V2X band to provide the aforementioned low-latency communication as well as other cellular communication services. Alternatively, the RSU may 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 circuitry in the computing device and the RSU may be encapsulated in a weather-resistant enclosure suitable for outdoor installation and may include a network interface controller to provide wired connectivity (e.g., Ethernet) to traffic signal controllers and / or backhaul networks.

[0073] Any one of RAN nodes 112a-b can serve as the endpoint of the air interface protocol and can be the first point of contact for client device 102. In some specific implementations, any one of RAN nodes 112a-b can perform various logical functions of 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.

[0074] In a specific implementation, the client device 102 may be configured to communicate with each other or with any of the RAN nodes 112a-b using OFDM communication signals on a multi-carrier communication channel, 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 specific implementation is not limited in this respect. The OFDM signal may include multiple orthogonal subcarriers.

[0075] In some implementations, the downlink resource grid can be used for downlink transmissions from any of the RAN nodes 112a-b to client device 102, while uplink transmissions can utilize similar techniques. The grid can be a time-frequency grid, called a resource grid or time-frequency resource grid, which represents the physical resources in the downlink within each time slot. This time-frequency plane representation is common practice for OFDM systems, making radio resource allocation intuitive. Each column and row of the resource grid corresponds to an OFDM symbol and an OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to a time slot in a radio frame. The smallest time-frequency unit in the resource grid is represented as a resource element. Each resource grid comprises multiple resource blocks that describe the mapping of certain physical channels to resource elements. Each resource block comprises a set of resource elements; in the frequency domain, this can represent the minimum amount of resources currently available for allocation. Such resource blocks are used to transmit several different physical downlink channels.

[0076] Depending on the specific implementation, client equipment 102 and RAN nodes 112a-b transmit data (e.g., transmit and receive data) through licensed media (also referred to as “licensed spectrum” and / or “licensed band”) and unlicensed shared media (also referred to as “unlicensed spectrum” and / or “unlicensed band”). Licensed spectrum may include channels operating in the frequency range of approximately 400 MHz to approximately 3.8 GHz, while unlicensed spectrum may include a 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.

[0077] To operate in unlicensed spectrum, client device 102 and RAN nodes 112a-b may use LAA, eLAA, and / or feLAA mechanisms. In these specific implementations, client device 102 and RAN nodes 112a-b may perform one or more known media sensing and / or carrier sensing operations to determine whether one or more channels in the unlicensed spectrum are unavailable or otherwise occupied before transmission in the unlicensed spectrum. Media / carrier sensing operations may be performed according to a Listen-After-Talk (LBT) protocol.

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

[0079] Typically, existing systems in the 5GHz band are WLANs based on IEEE 802.11 technology. WLANs employ a contention-based channel access mechanism called CSMA / CA. Here, when a WLAN node (e.g., a mobile station (MS) such as client device 102, AP 104, etc.) intends to transmit, the WLAN node can first perform CCA before transmitting. Additionally, in cases where more than one WLAN node senses the channel as idle and transmits simultaneously, a backoff mechanism is used to avoid collisions. This backoff mechanism can be a counter randomly introduced within the CWS, which increases exponentially upon collision and resets to a minimum value upon successful transmission. The LBT mechanism designed for LAA is somewhat similar to WLAN's CSMA / CA. In some specific implementations, the LBT procedure for DL ​​or UL transmission bursts (comprising PDSCH or PUSCH transmissions, respectively) can 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 can be 9 microseconds (μs); however, the size of the CWS and MCOT (e.g., transmission burst) can be based on government regulatory requirements.

[0080] The LAA mechanism is built upon the CA technology of LTE-Advanced systems. In CA, each aggregated carrier is called a CC. A CC can have a bandwidth of 1.4MHz, 3MHz, 5MHz, 10MHz, 15MHz, or 20MHz, and a maximum of five CCs can be aggregated, thus the maximum aggregated bandwidth is 100MHz. In FDD systems, the number of aggregated carriers can differ for DL ​​and UL, where the number of UL CCs is equal to or less than the number of DL component carriers. In some cases, individual CCs can have different bandwidths than the other CCs. In TDD systems, the number of CCs and the bandwidth of each CC are usually the same for DL ​​and UL.

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

[0082] The PDSCH carries user data and higher-layer signaling to 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 inform client device 102 of the transmission format, resource allocation, and HARQ information related to the uplink shared channel. Typically, downlink scheduling (allocating control and shared channel resource blocks to client devices 102 within the cell) can be performed at any of the RAN nodes 112a-b based on channel quality information fed back from any of the client devices 102. Downlink resource allocation information can be transmitted on the PDCCH used for (e.g., allocated to) each client device in client device 102.

[0083] PDCCH uses CCEs to transmit control information. Before being mapped to resource elements, the complex-valued symbols of the PDCCH can first be organized into quadruplets, which can then be arranged using a sub-block interleaver for rate matching. One or more of these CCEs can be used to transmit each PDCCH, where each CCE can correspond to nine sets, called REGs, each with four physical resource elements. Four Quadrature Phase Shift Keying (QPSK) symbols can be mapped to each REG. Depending on the DCI size and channel conditions, one or more CCEs can be used to transmit the PDCCH. In LTE, four or more different PDCCH formats with different numbers of CCEs (e.g., aggregation levels, L = 1, 2, 4, or 8) can exist.

[0084] Some implementations may apply the concept of resource allocation to control channel information; the concept of resource allocation is an extension of the above-mentioned concept. For example, some implementations may utilize EPDCCH, which uses PDSCH resources for control information transmission. One or more ECCEs may be used to transmit EPDCCH. Similarly, each ECCE may correspond to a set of nine with four physical resource elements, called EREG. In some cases, an ECCE may have a different number of EREGs.

[0085] 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 an 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 EPC 108, and / or between two eNBs connected to EPC 108. In some implementations, the X2 interface may include an X2 user plane interface (X2-U) and an X2 control plane interface (X2-C). X2-U provides flow control mechanisms for user packets transmitted via the X2 interface and can be used to transmit information about the delivery of user data between eNBs. For example, X2-U can provide specific sequence number information about user data transmitted from MeNB to SeNB; information about the successful in-order delivery of PDCP PDUs from SeNB to client device 102 for user data; information about PDCP PDUs not delivered to client device 102; information about the current minimum expected buffer size at SeNB for transmitting user data to UE; and so on. The X2-C provides LTE intra-eNB access mobility functions, including context transmission from the source eNB to the target eNB, user plane transmission control, load management functions, and inter-cell interference coordination functions.

[0086] In a specific implementation where system 100 is a 5G or NR system, interface 116 may be an 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 RAN nodes 112a-b (e.g., gNBs) connected to 5GC 108 and eNBs, and / or between two eNBs connected to 5GC 108. In some implementations, the Xn interface may include an Xn user plane (Xn-U) interface and an Xn control plane (Xn-C) interface. Xn-U provides non-guaranteed delivery of user plane PDUs and supports / provides data forwarding and flow control functions. Xn-C provides management and error handling functions for managing the functionality of the Xn-C interface; mobility support for client equipment 102 in connected mode (e.g., CM-CONNECTED), including functions for managing UE mobility in connected modes between one or more RAN nodes 112a-b. Mobility support may include context transport from the old (source) serving RAN node 112a-b to the new (destination) serving RAN node 112a-b; and control of the user plane tunnel between the old (source) serving RAN node 112a-b and the new (destination) serving RAN node 112a-b. The Xn-U protocol stack may include a transport network layer built on top of the Internet Protocol (IP) transport layer, and a GTP-U layer on top of the UDP and / or IP layers for carrying user plane PDUs. 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 top of SCTP. SCTP may be on top of the IP layer and provides guaranteed delivery of application layer messages. In the transport IP layer, point-to-point transport 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.

[0087] RAN 112 is shown communicatively coupled to the core network, which in this embodiment is communicatively coupled to the core network (CN) 108. CN 108 may include a plurality of network elements 122 configured to provide various data and telecommunications services to customers / subscribers (e.g., users of client equipment 102) connected to CN 108 via RAN 112. Components of CN 108 may be implemented in a single physical node or separate physical nodes, including components for reading and executing instructions from machine-readable or computer-readable media (e.g., non-transitory machine-readable storage media). In some embodiments, NFV may be used to virtualize any or all of the aforementioned 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 subslice. NFV architectures and infrastructure may be used to virtualize one or more network functions onto physical resources comprising a combination of industry-standard server hardware, storage hardware, or switches (optionally performed by proprietary hardware). In other words, an NFV system can be used to perform a virtual or reconfigurable concrete implementation of one or more EPC components / functions.

[0088] In some implementations, the application server (AS) 110 is a network server that uses IP to carry resources and the core network (e.g., UMTSPS domain, LTE PS data service, etc.). AS 110 can also be configured to support one or more communication services (e.g., VoIP sessions, PTT sessions, group communication sessions, social networking services, etc.) for client device 102 via EPC 108. As described in the following sections, in some implementations, client device 102 establishes a TCP session with AS 110 and uses the optimized TCP protocol disclosed in this specification. In such implementations, TCP AP 107 in client device 102 provides a TCP-ACK generation counter so that BB circuit 103 can track TCP ACK packets as copies. TCP AP 107 generates a TCP-ACK generation counter 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.

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

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

[0091] In some implementations, client device 102 receives data for a communication session from AS110 via CN 108 and AN 112 on the downlink channel. AS110 sends data using TCP as TCP data packets. Client device 102 acknowledges successful reception of TCP data packets by sending an acknowledgment (e.g., a TCP ACK packet) to AS110. TCP data packets can be identified using sequence numbers. The TCP ACK sent by 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 consecutive sequence number chain; that is, no sequence number is missing due to the failure to receive a corresponding TCP data packet.

[0092] As previously noted, in some implementations, client device 102 includes BB circuit 103. BB circuit 103 may be embodied as hardware circuitry, or a computer program product having computer-readable program instructions, or some combination thereof, which are stored on a computer-readable medium (e.g., a storage memory) and processed by a processing device (e.g., regarding…). Figure 9 The baseband circuit 910 described is used for execution. As previously described, the client device 102 is configured to generate TCP ACK packets and add TCP ACK packets to an output queue, which is maintained by the client device 102 for pending TCP packets waiting for uplink transmission (e.g., waiting for uplink to AN 112, waiting for transmission to AS 110).

[0093] In some implementations, BB circuit 103 tracks one or more TCP connections or TCP packet flows and maintains detailed information for each tracked TCP connection or flow. BB circuit 103 tracks recent TCP ACK information, including the timestamp when a 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 implementations, BB circuit 103 stores this information in a memory coupled to client device 102, for example, in database 106.

[0094] TCP packets sent by AS 110 are associated with one or more distinct communication sessions. In some implementations, TCP AP 105 uses different TCP flow identifiers (called flow IDs) to identify different communication sessions. In some 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, and IP protocol). The flow ID uniquely identifies the flow associated with a TCP data packet and its corresponding TCP ACK packet. TCP AP 105 determines a corresponding flow ID for each TCP data packet received at client device 102. In some implementations, TCP AP 105 provides different TCP ACK generation count values ​​to associate with TCP ACK packets from different flows. In other implementations, TCP AP 105 provides the same TCP ACK generation count value to associate with TCP ACK packets from different flows. In the packet descriptor prepared for the generated TCP ACK packets, TCP AP105 includes the flow ID determined for the corresponding TCP data packet and the TCP ACK generation count for the specific flow in the current time interval. The packet descriptor is stored in 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.

[0095] In some implementations, TCP AP 105 does not provide flow IDs for certain TCP packets. This could be due, for example, to external traffic via tethered connections, or because the packets do not contain all the fields required to generate a flow ID. In such cases, BB circuit 103 treats these TCP ACK packets as invalid for traffic reduction and ignores them when checking redundant packets in output queue 107.

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

[0097] Alternatively, in some implementations, the BB circuit 103 may use a counter to track the number of TCP ACK packets waiting in the output queue before UL transmission. If the counter value 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), 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 may be equal to the predetermined number. Depending on the implementation, the specified number may be set to any suitable value. For example, the specified number may be set to 3, 12, 27, or any other suitable number. Thus, the BB circuit 103 may be configured to monitor the number of pending TCP ACK packets in the output queue 107 and detect the presence of one or more redundant TCP ACK packets in the stream if the number of pending TCP ACK packets reaches a predetermined threshold limit.

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

[0099] Figure 2 An optimization of the TCP ACK packet stream is shown based on some publicly available specific implementations. Figure 2 The diagram illustrates the output queue configuration 202 before optimization; configurations 204 and 206 during optimization, involving the identification and removal of redundant TCP ACK packets; and configuration 208 after optimization is complete. In some specific implementations, regarding... Figure 2 The described operation is performed by BB circuit 103, and configurations 202-208 correspond to output queue 107.

[0100] Each of 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 with different flow IDs and corresponding ACK Gen Count values ​​assigned by TCP AP 105. In some specific implementations, the TCP ACK packets are arranged in order from oldest to newest, with packet #1 being the oldest and packet #13 being the newest. The oldest TCP ACK packet (packet #1) in the TCP ACK queue (202) has the flow ID "flow a" and the ACK Gen Count "ackgen 2", and the newest TCP ACK packet (packet #13) has the flow ID "flow a" and the ACK Gen Count "ackgen 3".

[0101] Configuration 202 illustrates 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 "flow a" and an ACKGen Count "ackgen 2". In some specific implementations, packets #1, #3, and #9 are processed by TCPAP 105 within the same time period, causing TCPAP 105 to stamp each of these packets with the same ACK Gen Count value. When the output queue 107 is optimized, 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, which are then removed from the queue.

[0102] Configuration 202 illustrates 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 "flow a" but different ACK Gen Count values, "ackgen 2" and "ackgen 3" respectively. In some specific implementations, packets #1 and #10 corresponding to "flow a" are processed by TCP AP 105 at different time periods, causing TCP AP 105 to stamp these packets with different ACK Gen Count values. As another example, packets #1 and #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.

[0103] In some specific implementations, the packet descriptors (e.g., stream ID and ACK GenCount) of TCP ACK packets in the queue are stored in a database 106, for example, stored in a database such as... Figure 6 The data structures described are as shown in the table. In some implementations, the BB circuit 103 manages the table. When inspecting a packet and obtaining the associated flow ID and ACK Gen Count, if the flow ID does not already 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 below, the BB circuit 103 manages the TCP ACK packets in the output queue 107 by examining the corresponding packet descriptor entry in the database 106 to identify redundant TCP ACK packets.

[0104] To inspect TCP ACK packets in the output queue, BB circuit 103 accesses the corresponding entry in the database for that packet and compares the relevant fields of the packet descriptor from that packet with the values ​​stored in database 106 for other TCP ACK packets in output queue 107. As previously described, in some implementations, when checking for redundancy in TCP ACK packets stored in the output queue, BB circuit 103 first checks whether the packet's ACK GenCount or Stream ID, or both, is valid. If BB circuit 103 determines that the ACK GenCount of the currently inspected packet is invalid, the BB circuit marks the database entry corresponding to the TCP ACK packet as invalid for reduction (e.g., not a candidate for removal as a redundant TCP ACK packet) and moves on to the next entry in the database, for example, corresponding to the next packet in the output queue. In some implementations, TCPAP 105 sets the packet's ACK GenCount to invalid when it is determined that the TCP ACK packet contains important information. This may occur, for example, for TCP ACK packets with additional header information or TCP data packets. In some implementations, a TCP ACK packet with an empty ACK Gen Count field or a predetermined invalid ACK Gen Count value (e.g., 0x10000) also indicates that the ACK Gen Count is invalid for reduction, and the BB circuit 103 does not treat the associated TCP ACK as a redundant candidate and leaves the packet in the output queue. In some implementations, the ACK generation count is valid if the value is within a valid range (e.g., 0…0xffff), otherwise it is invalid.

[0105] In some implementations, the TCP ACK packet descriptor includes a separate AckGenCount_valid field, which indicates whether the packet's ACK Gen Count value is valid. In some implementations, BB circuit 103 determines the validity of the ACK Gen Count value by validating the AckGenCount_valid field.

[0106] Alternatively, in some implementations, the BB circuit 103 verifies the flow ID associated with the packet being checked. 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 moves on 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 to reduce its presence in the output queue. In some implementations, the TCP flow ID is valid if the value is within a valid range (e.g., 0…0xffff), while a value (0x10000) indicates that the flow ID is invalid.

[0107] In some implementations, BB circuit 103 determines that two or more TCP ACK packets in the queue have the same flow ID and ACK Gen Count, thereby indicating that one or more of these packets are redundant duplicate ACK packets. For example, configuration 204 instructs BB circuit 103 to check the packets in the output queue in order from most recent to oldest. Regarding the most recent packet (e.g., packet #13), BB circuit 103 searches entries in database 106 to determine if the entry corresponding to any other TCP ACK packet in the queue has the same flow ID (e.g., "flow a") and the same ACK Gen Count (e.g., "ackgen3"). If BB circuit 103 determines that no matching entry exists in database 106, the BB circuit stores the flow ID and ACK Gen Count of the currently checked packet as a new entry in database 106. BB circuit 103 then continues checking the next older packet in the queue (e.g., packet #12). If BB circuit 103 determines that there is an older TCP ACK packet with the same flow ID in the queue (e.g., packet #10), then BB circuit 103 checks whether the ACK GenCount values ​​of the two packets (e.g., packet #13 and packet #10) are the same.

[0108] 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, packets #13 and #10 both have the flow ID "flow a" and the ACK GenCount "ackgen 3". When it is determined that the older packet has the same flow ID and ACK GenCount value as the newer packet, BB circuit 103 determines that the older packet (e.g., packet #10) is a redundant duplicate TCP ACK packet. BB circuit 103 keeps the newest packet (e.g., packet #13) in the output queue while discarding the older packet (e.g., packet #10) from the queue as a redundant duplicate TCP ACK packet. In some cases, as shown in configuration 206, BB circuit 103 marks redundant packets as discardable packets for later discarding from the queue, such as during a queue cleanup procedure. For example, when it is determined 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 discardable packet, as shown in 206a.

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

[0110] After the TCP ACK packet inspection is complete, BB circuit 103 continues to move to inspect the next older TCP ACK packet in the output queue, comparing the packet's flow ID and ACK Gen Count with other remaining packets in the queue, similar to the method described above. For example, after resolving the latest TCP ACK packet, i.e., packet #13, BB circuit 103 selects the next TCP ACK packet in the queue, e.g., TCP ACK packet #12. BB circuit 103 obtains the packet descriptor for TCP ACK packet #12 from database 106. 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 the two TCP ACK packets are different. This could occur, for example, when the two TCP ACK packets were generated by TCP AP 105 at two different intervals. In this case, the packets are not considered redundant relative to each other, and neither packet is discarded or removed from the queue, as shown in configuration 206. However, the corresponding database entry for a stream (e.g., "stream c") is updated with the most recent ACK Gen Count value (e.g., "ackgen88") corresponding to the latest TCP ACK packet of the stream.

[0111] BB circuit 103 continues to examine output queue 107, moving backward from newer TCP ACK packets to older TCP ACK packets in a manner similar to that described above. For example, as shown with regard to configuration 204, when examining packet #11, BB circuit 103 identifies two other TCP ACK packets, namely packets #6 and #5, that have the same flow ID (“flow c”) and the same ACK GenCount (“ackgen 87”), as shown in associations 204b and 204c. In this case, BB circuit 103 determines that the two older packets (e.g., packets #6 and #5) are redundant and marks them for discarding, as shown in configuration 206.

[0112] Similarly, considering the next older TCP ACK packet in the output queue that has not yet been checked (e.g., packet #9), 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. As another example, BB circuit 103 determines that packet #7 is a redundant copy of packet #4, as shown in association 204f. In these cases, BB circuit 103 discards the redundant duplicate packets, as shown in configuration 206.

[0113] The results of output queue optimization / reduction after discarding all redundant packets are shown in 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 (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 leads to reduced latency. This results in a reduction in TCP RTT, leading to increased TCP throughput and therefore higher end-to-end throughput.

[0114] In some implementations, TCP AP 105 invalidates the ACK Gen Count of a specific TCP ACK packet, for example, by making the ACK Gen Count field in the packet descriptor empty or assigning a predetermined invalid value. For example, the ACK Gen Count field in the packet descriptor may be a 16-bit field; TCP AP 105 may set the 16-bit field to the hexadecimal value FFFF to indicate that the ACK Gen Count is invalid. In some implementations, a similar approach is used for the stream ID, as previously described. By invalidating the ACK Gen Count or the stream ID, or both, for TCP ACK packets, application processor 105 prevents the corresponding TCP ACK packets from being classified as redundant and thus discarded. This may occur, for example, for TCP ACK packets determined to include important information (e.g., TCP ACKs with additional header information). In some implementations, output queue 107 includes additional packets, such as TCP data packets. In such implementations, TCP AP 105 ensures that data packets are not checked for reduction by setting the ACK Gen Count or the stream ID, or both, of the data packets to invalid values.

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

[0116] Process 300 begins when a client device accesses an output queue (302) containing multiple TCP ACK packets. For example, BB circuit 103 accesses output queue 107 to determine if there are any discardable redundant packets. In some implementations, BB circuit 103 accesses output queue 107 to optimize the queue when the number of TCP ACK packets in the queue exceeds a predetermined threshold. In some implementations, BB circuit 103 accesses output queue 107 to optimize the queue when the duration for which TCP ACK packets are queued in output queue 107 exceeds a predetermined time threshold. In some implementations, BB circuit 103 accesses output queue 107 to optimize the queue at predetermined periodic time intervals. In some implementations, the predetermined time interval corresponds to the time period used by TCP AP 105 to stamp packets with the same ACK Gen Count value, as previously described. In some implementations, accessing output queue 107 includes accessing records of TCP ACK packets in database 106. (About...) Figure 6 Such records are illustrated. In some specific implementations, when the output queue is accessed, the BB circuit 103 resets the database 106. For example, when the output queue 107 is accessed, the BB circuit 103 clears the entries in the database 106.

[0117] When accessing the output queue, the client device examines the TCP ACK packets in the queue (304). For example, in some implementations, the BB circuit 103 begins examining packets from the newest packet in the queue (e.g., packet #13 as shown in configuration 204). In other implementations, the BB circuit 103 begins examining packets from the oldest packet in the queue (e.g., packet #1 as shown in configuration 204).

[0118] The client device identifier corresponds to the ACK Gen Count and Stream ID values ​​(306) of the currently accessed packet. For example, when inspecting TCP ACK packets (such as packet #13) in output queue 107, BB circuit 103 accesses the Stream ID and ACK Gen Count values ​​included in the packet.

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

[0120] If the client device determines that the ACKGen Count value of the TCP ACK packet being inspected is invalid (308—No), the client device marks the TCP ACK packet as invalid and continues moving to inspect 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 (e.g., a TCP ACK with additional header information or TCP data packets), TCP AP 105 sets the ACK Gen Count of the packet to invalid to indicate that the packet should not be considered as a candidate for removal from the output queue. When 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 moving to inspect the next packet in the queue (if there are other uninspected packets).

[0121] 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 (310). For example, BB circuit 103 verifies whether the 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 implementations, the flow ID field does not have any value indicating that the flow ID is invalid.

[0122] If the client device determines that the flow ID of the inspected packet indicates that the flow ID is invalid (310—No), the client device marks the TCP ACK packet as invalid and continues moving to check 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 TCP data packets), TCP AP 105 sets the flow ID of the specific TCP ACK packet as invalid to indicate that the packet should not be considered as a candidate for removal from the output queue. When BB circuit 103 determines that the flow ID of the currently inspected packet is invalid, the BB circuit leaves the packet in output queue 107 without further processing and continues moving to check the next packet in the queue (if there are other uninspected packets).

[0123] On the other hand, if the client device determines that the flow ID of the inspected 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, BB circuit 103 verifies the entry in database 106 to determine whether the entry includes the flow ID of the currently inspected packet, which indicates that another TCP ACK packet corresponding to the same flow exists in the output queue (and has been previously inspected).

[0124] If the client device determines that the flow ID is not stored in the database (312—No), the client device stores the flow ID and TCP ACK Gen Count of the packet in the database (314). For example, if BB circuit 103 determines that database 106 does not contain an entry with the flow ID of the currently inspected TCP ACK packet, BB circuit 103 creates a new entry in database 106, for example, as per the information about... Figure 6 As shown. BB circuit 103 stores the packet's flow ID and ACK Gen Count value in the newly created entry.

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

[0126] If the client device determines that the ACKGen Count value of the inspected 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 ACKGen Count value of the inspected TCP ACK packet (318). For example, if BB circuit 103 determines that an entry in database 106 with the same flow ID as the inspected 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 inspected TCP ACK packet.

[0127] On the other hand, if the client device determines that the ACK Gen Count of the inspected 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 targeting packet #10 (such as... Figure 2 When examining entries in database 106 (as shown), BB circuit 103 determines that an entry exists that has the same flow ID (“flow a”) and the same ACK Gen Count value (“ackgen 3”) as packet #10. As previously mentioned, this entry was created when examining packet #13. Therefore, BB circuit 103 determines that packet #10 is a redundant duplicate TCP ACK packet compared to packet #13. BB circuit 103 then drops or discards TCP ACK packet #10 from output queue 107.

[0128] In an implementation where BB circuit 103 first checks the output queue starting with the oldest packet, when a redundant TCPACK 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 this implementation, entries for older packets are retained in the database, while entries for newer packets are deleted. It should be noted that in this case, when checking 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 the next packet with the same flow ID is checked. Therefore, compared to the case where packets in the output queue are checked first starting with the newest packet, the decision of whether to retain or discard a packet is delayed during the iteration of checking packets.

[0129] Then, the client device checks whether there are additional packets in the output queue (322). If there are one or more additional packets in the output queue (322—Yes), the client device accesses the TCP ACK packet in the output queue (324) and begins checking entries in the database for matches corresponding to the flow ID and ACKGen Count of the newly accessed TCP ACK packet, as described in the preceding sections regarding (304)-(320). On the other hand, if there are no additional packets in the output queue (322—No), process 300 ends, where the output queue has been compressed for the current iteration.

[0130] In some cases of process 300 described above, when older TCP ACK packets, which are redundant copies, are removed from the output queue while newer TCP ACK packets are retained in the queue, the transmission of TCP ACK packets to the remote server is delayed because the newer TCP ACK packets are located later in the output queue. As described below, in some implementations, the position of the (discarded) duplicate older TCP ACK packets in the output queue is provided to the newer TCP ACK packets, allowing the TCP ACKs to be sent to the remote server earlier (e.g., when the older TCP ACK packets will be sent based on their position in the output queue), which helps reduce latency. In such implementations, BB circuit 103 tracks the position of TCP ACK packets in the output queue. When an older redundant TCP ACK packet is identified, 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, BB circuit 103 maintains additional fields in the entries in database 106. These 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 an older packet in the stream 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 in the stream with a specific TCP ACK Gen Count value. This field is set when a packet with a new TCP ACK Gen Count value is identified.

[0131] Figure 4This diagram illustrates the optimization of a TCP ACK packet stream according to some publicly disclosed specific implementations, where packets are reordered in the output queue. The diagram shows the output queue configuration 402 before optimization; configurations 404, 406, and 408 of the output queue during optimization, where redundant TCP ACK packets are identified and removed; and configuration 410 of the output queue after optimization is complete. In some specific implementations, regarding... Figure 4 The described operation is performed by BB circuit 103, and configurations 402-410 correspond to output queue 107.

[0132] Each of configurations 402-410 includes a TCP ACK packet 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 TCPAP 105. In some specific implementations, the TCP ACK packets are arranged in order from oldest to newest, with packet #1 being the oldest and packet #13 being the newest. The oldest TCP ACK packet in the queue (packet #1) 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".

[0133] Configuration 402 illustrates 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 the flow ID "flow a" and the ACK Gen Count "ackgen 2". When the output queue 107 is optimized, 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, which are then removed from the queue.

[0134] Configuration 402 illustrates 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 "flow a" but different ACK Gen Count values, "ackgen 2" and "ackgen 3" respectively; while packets #1 and #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.

[0135] In some specific implementations, the packet descriptors (e.g., stream ID and ACK GenCount values) of TCP ACK packets in the queue are stored in a database 106, for example, stored in a database such as... Figure 7 The data structures described are, for example, tables. In some implementations, the BB circuit 103 manages the tables. When inspecting packets, if the associated flow ID and ACKGen Count value does not exist in the 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 below, the BB circuit 103 manages the TCP ACK packets in the output queue 107 by examining the entries in the database 106 to identify redundant TCP ACK packets.

[0136] In some implementations, BB circuit 103 begins inspecting output queue 107 starting with the most recent packet (e.g., packet #13 as shown in configuration 402). To inspect TCP ACK packets in the output queue, BB circuit 103 accesses the packet descriptor and compares the information in the packet descriptor with entries stored in database 106.

[0137] As previously described, in some implementations, when checking TCP ACK packets stored in the output queue for redundancy verification, 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 BB circuit 103 determines that the ACK Gen Count of the currently checked packet is invalid, the BB circuit marks the TCP ACK packet as invalid for reduction (e.g., not a candidate for removal as a redundant TCP ACK packet) and moves on to the next packet in the output queue. Alternatively, in some implementations, BB circuit 103 checks the flow ID associated with the checked packet. If the flow ID indicates that the flow ID is invalid, BB circuit 103 marks the TCP ACK packet as invalid for reduction and moves on 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, BB circuit 103 ignores the packet for reduction, thus leaving it in the output queue.

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

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

[0140] BB circuit 103 continues to examine output queue 107, moving backward from newer TCP ACK packets to older TCP ACK packets in a manner similar to that described above. For example, as shown with regard to configuration 404, when examining packet #6 and then packet #5, 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, BB circuit 103 determines that the two older packets (packets #6 and #5) are redundant copies relative to packet #11 (shown by associations 404b and 404c) and marks these packets for discarding.

[0141] In some implementations, when multiple redundant duplicate TCP ACK packets exist as in the previous example, 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 of the replacement candidate index value, as well as the position of the winning packet, in a database entry corresponding to the flow ID and ACK Gen Count value. In some implementations, the replacement candidate field in the database entry is updated when an additional duplicate TCP ACK packet is identified. In such implementations, the final value of the replacement candidate field corresponds to the position index of the identified oldest duplicate TCP ACK packet. Considering the example above again, BB circuit 103 first identifies packet #6 as having the same flow ID and the same ACK Gen Count value, as shown in association 404b. Since packet #6 is an older packet compared to packet #11, 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. Following this identification, BB circuit 103 stores the position of group #6 in the replacement candidate index field of the database entry corresponding to the stream ID (“stream c”) and ACK Gen Count value (“ackgen 87”), while the position of group #11 exists in the winner group field. Subsequently, BB circuit 103 identifies group #5 (which is an older group in the output queue compared to group #5) as another copy corresponding to the stream ID “stream c” and ACK Gen Count value “ackgen 87”, as shown in the associated 404c. BB circuit 103 then updates the replacement candidate index field in the corresponding database entry for the stream ID (“stream c”) and ACK Gen Count value (“ackgen 87”) to store the position of group #5 (removing the position of group #6 from the previously stored field in the database entry).

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

[0143] After examining the output queue to identify redundant TCP ACK packets and annotate the positions of the winner packet and replacement candidate, 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 specific 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 relation 404a, for 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 in the corresponding database entries as replacement candidate index and winner index, respectively. As shown in configuration 406, when rearranging the packets in the output queue after identifying redundant copies, BB circuit 103 swaps the positions of packet #13 and packet #10 in the output queue by looking up their positions in the replacement candidate index and winner index fields of the database entries. As shown in 406a, the reserved packet #13 is moved up in the queue to the position previously occupied by packet #10. This reordering ensures that the earliest available position of the TCP ACK packet corresponding to flow ID "flow a" and ACK Gen Count value "ackgen 3" in the queue (e.g., the original position of packet #10) is maintained, while redundant duplicate packets are removed.

[0144] In a similar manner to the above, when removing redundant and duplicate TCP ACK packets, the TCP ACK packets corresponding to other <flow ID, ACKGen Count value> tuples are reordered. For example, as shown in association 406b, the positions of packets #11 and #5, which correspond to the latest and oldest packets for flow ID "flow c" and ACK Gen Count value "ackgen 87", are swapped; as shown in association 406c, the positions of packets #9 and #1, which correspond to the latest and oldest packets for flow ID "flow a" and ACK Gen Count value "ackgen 2", are swapped; and as shown in association 406d, the positions of packets #7 and #4, which correspond to the latest and oldest packets for flow ID "flow b" and ACK Gen Count value "ackgen 41", are swapped. For each of these reorderings, 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.

[0145] After the BB circuit 103 has swapped the positions of the packets and rearranged the queue as described above, the BB circuit 103 discards TCP ACK packets identified as redundant duplicates. For example, as shown in configuration 408, packet #10, which is a redundant duplicate packet corresponding to flow ID "flow a" and ACKGen Count value "ackgen 3", is discarded. Similarly, packets #5 and #6, which are redundant duplicate packets corresponding to flow ID "flow c" and ACK Gen Count value "ackgen 87", are discarded; packets #1 and #3, which are redundant duplicate packets corresponding to flow ID "flow a" and ACK Gen Count value "ackgen 2", are discarded; and packet #4, which is a redundant duplicate packet corresponding to flow ID "flow b" and ACK Gen Count value "ackgen 41", is discarded. After discarding redundant packets, 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 so that the order in which acknowledgments are sent remains unchanged. This results in a reduction in the latency of all subsequent UL TCP ACK packets (after the discarded packets), a reduction in TCP RTT (round-trip time), which ultimately leads to an increase in TCP throughput and therefore higher end-to-end throughput.

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

[0147] Process 500 begins when a client device accesses an output queue (502) containing multiple TCP ACK packets. For example, BB circuit 103 accesses output queue 107 to determine if there are any discardable redundant packets. In some implementations, BB circuit 103 accesses output queue 107 to optimize the queue when the number of TCP ACK packets in the queue exceeds a predetermined threshold. In some implementations, BB circuit 103 accesses output queue 107 to optimize the queue when the duration for which TCP ACK packets are queued in output queue 107 exceeds a predetermined time threshold. In some implementations, BB circuit 103 accesses output queue 107 to optimize the queue at predetermined periodic time intervals. In some implementations, BB circuit 103 resets database 106 when accessing the output queue. For example, in such an implementation, BB circuit 103 clears entries from database 106 when accessing output queue 107.

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

[0149] The client device identifier corresponds to the ACK Gen Count and Stream ID values ​​(506) of the currently accessed TCP ACK packet. For example, when inspecting a TCP ACK packet (such as packet #13) in output queue 107, BB circuit 103 accesses the Stream ID and ACK Gen Count values ​​included in the packet's packet descriptor.

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

[0151] If the client device determines that the ACKGen Count value of the TCP ACK packet being inspected is invalid (508—No), the client device marks the TCP ACK packet as invalid and continues moving to inspect 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 (e.g., a TCP ACK with additional header information or TCP data packets), the TCP AP 105 sets the ACK Gen Count of the packet to invalid to indicate that the packet should not be considered as 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 moving to inspect the next packet in the queue (if there are other uninspected packets).

[0152] 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, BB circuit 103 verifies whether the 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 implementations, the flow ID field does not have any value indicating that the flow ID is invalid.

[0153] If the client device determines that the flow ID of the inspected packet indicates an invalid flow ID (510—No), the client device marks the TCP ACK packet as invalid and continues moving to check 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 TCP data packets), the TCP AP 105 sets the flow ID of the specific TCP ACK packet to invalid to indicate that the packet should not be considered as a candidate for removal from the output queue. When the BB circuit 103 determines that the flow ID of the currently inspected packet is invalid, the BB circuit leaves the packet in the output queue 107 without further processing and continues moving 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 flow ID of the inspected 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, BB circuit 103 verifies the entry in database 106 to determine whether the entry includes a flow ID that matches the flow ID of the currently inspected packet, indicating that another TCP ACK packet corresponding to the same flow exists in the output queue (and has been previously inspected).

[0155] If the client device determines that the flow ID is not stored in the database (512—No), the client device stores the flow ID and TCP ACK Gen Count of the packet in the database (514). For example, if BB circuit 103 determines that database 106 does not contain an entry with the flow ID of the TCP ACK packet currently being inspected, BB circuit 103 creates a new entry in database 106, for example, as per the information provided. Figure 7 As shown. BB circuit 103 stores the packet's flow ID and ACK Gen Count value in the newly created entry. The client device also stores the packet's position in a database (515). For example, in addition to storing the TCP ACK packet's flow ID and ACK Gen Count value in the newly created entry, BB circuit 103 also stores the packet's position in the output queue in the winner index field of the database entry, as previously mentioned. Figure 4 As stated above.

[0156] On the other hand, if the client device determines that the flow ID of the inspected packet exists in an entry in the database (512—Yes), the client device verifies whether the ACK GenCount of the inspected packet matches the ACK GenCount value in the entry (516). For example, as above and regarding Figure 4The packet #10 in queue (404) has a flow ID “flow a” and an ACK Gen Count “ackgen 3”. When packet #10 is inspected, BB circuit 103 determines, while retrieving entries in database 106, that an entry with the same flow ID (“flow a”) exists in the database (e.g., previously created when inspecting packet #13). 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.

[0157] 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 the BB circuit 103 determines that an existing entry in database 106 with the same flow ID as the inspected packet has an ACK Gen Count value different from the packet's ACK Gen Count value, the BB circuit 103 updates the database entry. The 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, the BB circuit 103 determines that database 106 includes an entry with the flow ID ("flow c") of TCP ACK packet #11, but the ACK Gen Count value ("ackgen 87") of packet #11 is different from the ACK Gen Count value in the database entry (corresponding to "ackgen 88" for packet #12 with the same flow ID). In this case, BB circuit 103 updates the corresponding database entry for "stream 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.

[0158] The client device also stores the position of the group as the winner group in the database entry (519). For example, in addition to updating the ACKGen Count field in the database entry as described above, the BB circuit 103 also stores the output queue position of the group in the winner index field of the entry, as previously mentioned. Figure 4 As described above, considering the example of group #11, BB circuit 103 updates the winner index field of the database entry (which previously stored the queue position of group #12) to store the queue position index of group #11.

[0159] On the other hand, if the client device determines that the ACK Gen Count of the inspected packet 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 inspected packet #10 (such as... Figure 4 When packet #10 is checked (as shown), BB circuit 103 determines that there exists an entry (created when checking packet #13) with the same flow ID (“flow a”) and the same ACK GenCount value (“ackgen 3”) as packet #10. Therefore, BB circuit 103 determines that packet #10 is a redundant TCP ACK packet compared to packet #13. BB circuit 103 marks TCP ACK packet #10 as pending discard from output queue 107 and stores the position of packet #10 in the replacement candidate index field of the corresponding database entry for flow ID “flow a”, where the queue position of packet #13 is stored in the winner index field.

[0160] Then, the client device checks whether there are additional packets in the output queue (522). If there are 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 begins checking entries in the database for a match corresponding to the flow ID and ACK Gen Count of the newly accessed TCP ACK packet, as described in the preceding sections regarding (504)-(520).

[0161] 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 discards redundant TCP ACK packets (526). For example, BB circuit 103 swaps the positions of packet #13 and packet #10, as per [reference to...]. Figure 4 As described in 406a, redundant duplicate TCP ACK packets #10 are discarded, 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 implementations, Figure 4 Configuration 410 shows the output queue at the end of process 500.

[0162] Figure 6 The entries in database 106 for managing TCP ACK packets are shown, based on some publicly available specific implementations. (See also: regarding...) Figure 1 The database 106 is included in the client device 102.

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

[0164] When inspecting TCP ACK packets in the output queue, if BB circuit 103 does not find an entry for a matching flow ID in database 106, BB circuit 103 creates a new entry in database 106 and enters the flow ID and ACK Gen Count values ​​in the corresponding fields of the entry, as described regarding output queue configurations 202-204 and process 300. This occurs, for example, when a recent packet corresponding to a specific flow ID is detected. For example, as described regarding... Figure 2 and Figure 3 When examining packet #13 in output queue 107, BB circuit 103 determines that the flow ID (“flow a”) for packet #13 does not exist in database 106. Therefore, BB circuit 103 creates a new entry in database 106, such as entry 602, and enters the flow ID and ACK Gen Count value of packet #13 in the corresponding field of the newly created entry. Similarly, when examining packets #12 and #7 respectively, BB circuit 103 creates entries 604 and 606.

[0165] Figure 7 The entries in database 106 for managing TCP ACK packets are shown, based on some publicly available specific implementations. (See also: regarding...) Figure 1 The database 106 is included in the client device 102. For example... Figure 7 As shown, database 106 includes one or more entries, such as 702, 704, and 706, which are represented as rows and also referred to as data records. Each entry includes four fields: a stream ID field 720, an ACK Gen Count field 722, a replacement candidate index field 724, and a winner index field 726.

[0166] The Stream ID field 720 and the ACK Gen Count field 722 store the Stream ID and ACK Gen Count values ​​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 Stream ID and ACK Gen Count values. For example, entry 702 has the value "Stream a" in its Stream 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 positions of the redundant duplicate packets to be discarded and the TCP ACK packets to be retained, respectively. For example, entry 702 has the queue position of packet #10 in its replacement candidate index field 724 (referred to as the packet #10 index) and the queue position of packet #13 in its winner index field 726 (referred to as the packet #13 index). Therefore, when the output queue 107 is compressed, as per the relevant information... Figure 4 and Figure 5 The BB circuit 103 swaps the positions of group #10 and group #13, and discards group #10.

[0167] When BB circuit 103 begins checking output queue 107 in each iteration, it resets database 106 by clearing all entries. As previously described, when checking TCP ACK packets in the output queue, if BB circuit 103 does not find an entry in database 106 matching the flow ID of the packet, BB circuit 103 creates a new entry in database 106 and enters the flow ID, ACK Gen Count value, and packet queue position in the corresponding fields of the entry, as described regarding output queue configurations 402-408 and process 500. This occurs, for example, when the latest packet corresponding to a specific flow ID and ACK Gen Count interval is checked. For example, as described regarding... Figure 4 and Figure 5When inspecting packet #13 in output queue 107, BB circuit 103 determines that the combination of flow ID (“flow a”) and ACK Gen Count value (“ackgen 3”) for packet #13 does not exist 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 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 packet #12 is inspected, and updates this entry when packet #11, which has the same flow ID but a different ACK Gen Count value compared to packet #12, is inspected. Similarly, BB circuit 103 creates entry 706 when packet #8 is inspected, and updates this entry when packet #7 is inspected.

[0168] On the other hand, when a TCP ACK packet is inspected in the output queue, if the BB circuit 103 finds an entry in the database 106 that matches the combination of the packet's flow ID and ACK Gen Count value, the BB circuit 103 determines that the currently inspected packet is redundant. The BB circuit 103 marks the packet as to be discarded and records the packet's queue position in the replacement candidate index field 724 of the corresponding entry, as described regarding output queue configurations 402-408 and process 500. This occurs, for example, when the most recent packet corresponding to a specific flow ID and ACK Gen Count interval has been inspected. For example, as described regarding... Figure 4 and Figure 5When packet #10 is checked in output queue 107, BB circuit 103 determines that the combination of the flow ID (“flow a”) and ACK Gen Count value (“ackgen 3”) of packet #10 already exists in entry 702 of database 106 (created when checking packet #13). Therefore, BB circuit 103 marks packet #10 as to be discarded and records the queue position of packet #10 (“packet #10 index”) in the replacement candidate index field 724 of entry 702. Similarly, when packet #6 is checked in output queue 107, BB circuit 103 determines that the combination of the flow ID (“flow c”) and ACK Gen Count value (“ackgen 87”) of packet already exists in entry 706 of database 106 (updated when checking packet #11). Therefore, BB circuit 103 marks packet #6 as to be discarded and records the queue position of packet #6 in the replacement candidate index field 724 of entry 706. Next, examine packet #5 in output queue 107 (when checking the queue from right to left starting with the newest packet results in packet #6 being newer than packet #5 in the output queue). BB circuit 103 determines that the combination of the packet's flow ID ("flow c") and ACK Gen Count value ("ackgen 87") already exists in database 106 in entry 706. Therefore, BB circuit 103 marks packet #5 as to be discarded and records the queue position of packet #5 in the 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.

[0169] Once the BB circuit 103 has completed checking the output queue 107 in the current iteration, the entries in the database 106 are as follows: Figure 7 As shown. BB circuit 103 swaps the positions of the winner group and redundant duplicate groups, as per [reference to...]. Figure 4 As described in configuration 406 and process 500. For example, for a stream ID “stream a” and an ACK Gen Count value “ackgen 3” (entry 702), BB circuit 103 moves the winner group #13 to the position of the redundant group #10 that is earlier in the output queue 107 and is known from the replacement candidate index field 724 in entry 702.

[0170] In some specific implementations, BB circuit 103 moves redundant packet #10 to the position of winner packet #13 known from the winner index field 726 in entry 702. A similar exchange is performed for entries 704 and 706. After the exchange is complete, BB circuit 103 discards redundant duplicate packets, as per [the previous sentence about...]. Figure 4As described in configuration 408 and process 500. For example, for the stream ID "stream a" and the ACK Gen Count value "ackgen 3" (entry 702), BB circuit 103 discards the group #10 that now occupies the position indicated by the winner index field 726.

[0171] Thus, during implementation process 500, BB circuit 103 uses database 106 to optimize output queue 107, thereby removing redundant duplicate groups.

[0172] In some implementations, the stream ID may be very large (e.g., 116 bits or 128 bits). Storing stream IDs of such a large size would require significant memory. The time spent parsing the stream ID and finding a match in database 106 could be longer due to the large size of the stream ID, resulting in additional latency overhead when compressing the output queue. In some implementations, the memory storage requirements or the speed of parsing the database, or both, are reduced by compressing the size of the stream ID by using the last X bits of the stream ID as a hash value to perform the initial search in database 106. In such implementations, X is a predetermined positive integer less than the number corresponding to the full length of the stream ID. For example, X could be 8 bits, 16 bits, or 32 bits, while the full length of the stream ID could be 116 bits or 128 bits. In such implementations, BB circuit 103 uses the hash value as an index in a hash table that stores entries with <stream ID, ack_gen_count> pairs that have the same hash value. The table is searched to identify entries that have the same hash value as the stream ID of the currently processed TCP ACK packet. Since the hash value is smaller in number than the original stream ID, using the hash value reduces the time required to search database 106.

[0173] In some implementations, when hash values ​​are used in the manner described above, the complete flow ID is also stored in the hash table. This is useful, for example, for resolving flow ID collisions (e.g., two or more different flow IDs mapped to the same hash value). In such cases, initially, a search is performed using the hash value to determine the presence 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 hash table entry are found, all complete flow IDs mapped to the hash value in the hash table entry are verified until a flow ID matching the flow ID of the checked group is found. If no match is found, the flow ID of the group is stored in the same hash table entry. Thus, a hash table entry comprises a linear list of flow IDs hashed to the hash value corresponding to the entry. Using hashing in the manner described above involves a trade-off between memory consumption (e.g., large hash tables, but fewer collisions) and speed (e.g., small hash tables, but greater search effort due to flow ID collisions). The size of the hash value is chosen based on this trade-off.

[0174] Figure 8 Examples of infrastructure equipment 800 according to various specific implementations are shown. Infrastructure equipment 800 (or “system 800”) may be implemented as a base station, a radio headend, a RAN node (such as RAN nodes 112a and 112b and / or AP 104 previously shown and described), an application server 110, and / or any other element / device discussed herein. In other examples, system 800 may be implemented in or by a client device 102. System 800 includes: application circuitry 805, baseband circuitry 810, one or more radio front-end modules (RFEMs) 815, memory circuitry 820, a program 822 stored in memory 820, a power management integrated circuit (PMIC) 825, a power tee circuit 830, a network controller circuitry 835, a network interface connector 840, satellite positioning circuitry 845, and a user interface 850.

[0175] In some embodiments, device 800 may include additional components such as, for example, a memory / storage device, a display, a camera, a sensor, or an input / output (I / O) interface. In other embodiments, these components may be included in more than one device. For example, the circuitry may be individually included in more than one device for use with a CRAN, vBBU, or other similar embodiments.

[0176] Application circuitry 805 may include circuitry such as, but not limited to, one or more processors (or processor cores), cache memory, and one or more of the following: low-dropout regulators (LDOs), interrupt controllers, serial interfaces such as SPI, I2C, or Universal Programmable Serial Interface modules, real-time clocks (RTCs), timer-counters (including interval timers and watchdog timers), general-purpose input / output (I / O or IO), memory card controllers such as Secure Digital (SD) Multimedia Card (MMC) or similar products, Universal Serial Bus (USB) interfaces, Mobile Industry Processor Interface (MIPI) interfaces, and Joint Test Access Group (JTAG) test access ports. The processor (or core) of application circuitry 805 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 system 800. In some specific implementations, the memory / storage element may be an on-chip memory circuit, which may include any suitable volatile and / or non-volatile memory, such as DRAM, SRAM, EPROM, EEPROM, flash memory, solid-state memory and / or any other type of memory device technology, such as those discussed herein.

[0177] The processor of the application circuit 805 may include, for example, one or more processor cores (CPU), 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 machine (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.

[0178] In some implementations, application circuitry 805 may include or may be a dedicated processor / controller for operation according to the various implementations herein. As an example, the processor of application circuitry 805 may include one or more Apple A-series processors, Intel processors, etc. or Processor; Advanced Micro Devices (AMD) Processor, Accelerated Processing Unit (APU) or Processors; ARM-based processors licensed by ARM Holdings, Ltd., such as the ARM Cortex-A series processors supplied by Cavium™, Inc. MIPS-based designs from MIPS Technologies, Inc., such as the MIPS Warrior P-class processor; etc. In some specific implementations, system 800 may not utilize application circuitry 805, but may instead include a dedicated processor or controller to process, for example, IP data received from EPC or 5GC.

[0179] In some implementations, application circuitry 805 may include one or more hardware accelerators, which may be microprocessors, programmable processing devices, etc. These hardware accelerators may include, for example, computer vision (CV) and / or deep learning (DL) accelerators. For example, programmable processing devices may be one or more field-programmable devices (FPDs), such as field-programmable gate arrays (FPGAs); programmable logic devices (PLDs), such as complex PLDs (CPLDs), high-capacity PLDs (HCPLDs); ASICs, such as structured ASICs; programmable SoCs (PSoCs); and so on. In such implementations, the circuitry of application circuitry 805 may include logic blocks or logic architectures, and other interconnect resources that can be programmed to perform various functions such as programs, methods, and functions.

[0180] In such a specific implementation, the circuitry of application circuit 805 may include memory cells (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), fuse, etc.)) for storing logic blocks, logic architectures, data, etc.

[0181] The baseband circuit 810 may be implemented, for example, as a solderable substrate, which includes one or more integrated circuits, a single packaged integrated circuit soldered to a main circuit board, or a multi-chip module containing two or more integrated circuits.

[0182] User interface circuitry 850 may include one or more user interfaces designed to enable a user to interact with system 800, or peripheral interface designed to enable peripheral components to interact with system 800. User interfaces may include, but are 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 touchscreen, a speaker or other audio transmitting device, a microphone, a printer, a scanner, headphones, a display screen or display device, etc. Peripheral 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.

[0183] The radio 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 embodiments, the one or more sub-millimeter-wave RFICs may be physically separated from the millimeter-wave RFEM. The RFIC may include connectors to one or more antennas or antenna arrays, and the RFEM may be connected to multiple antennas. In another embodiment, the radio functions of both the millimeter-wave and sub-millimeter-wave antennas may be implemented in the same physical RFEM 815 that combines both the millimeter-wave antenna and the sub-millimeter-wave antenna.

[0184] The memory circuitry 820 may include one or more of the following: volatile memory, including dynamic random access memory (DRAM) and / or synchronous dynamic random access memory (SDRAM); and non-volatile memory (NVM), including high-speed electrically erasable memory (commonly referred to as flash memory), phase-change random access memory (PRAM), magnetoresistive random access memory (MRAM), etc., and may be combined with... and A three-dimensional (3D) XPOINT memory. The memory circuit 820 can be implemented as one or more of the following: a solder-in packaged integrated circuit, a socket memory module, and an insert memory card.

[0185] The PMIC 825 may include a voltage regulator, surge protector, power alarm detection circuitry, and one or more backup power sources, such as batteries or capacitors. The power alarm detection circuitry can detect one or more of a power outage (undervoltage) and a power surge (overvoltage) condition.

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

[0187] Network controller circuitry 835 can provide connectivity to a network using standard network interface protocols such as Ethernet, GRE-tunneled Ethernet, Multiprotocol Label Switching (MPLS)-based Ethernet, or some other suitable protocol. Network connectivity can be provided to / from infrastructure equipment 800 via a physical connection via network interface connector 840; this physical connection can be an electrical connection (typically referred to as a "copper interconnect"), an optical connection, or a wireless connection. Network controller circuitry 835 may include one or more dedicated processors and / or FPGAs for communicating using one or more of the aforementioned protocols. In some implementations, network controller circuitry 835 may include multiple controllers for providing connectivity to other networks using the same or different protocols.

[0188] Positioning circuit 845 includes circuitry for receiving and decoding signals transmitted / broadcast by a positioning network of a Global Navigation Satellite System (GNSS). Examples of navigation satellite constellations (or GNSS) include the U.S. 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., using the Indian constellation (NAVIC), Japan's Quasi-Zenith Satellite System (QZSS), France's Doppler orbit chart and satellite integrated radio positioning (DORIS), etc.).

[0189] The positioning circuit 845 may include various hardware components (e.g., hardware devices such as switches, filters, amplifiers, antenna elements, etc.) for facilitating OTA communication to communicate with components of the positioning network, such as navigation satellite constellation nodes. In some implementations, the positioning circuit 845 may include a micro-technology (micro PNT) IC for positioning, navigation, and timing, which performs position tracking / estimation using a master timing clock without GNSS assistance. The positioning circuit 845 may also be part of or interact with the baseband circuit 810 and / or 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 application circuitry 805, which may use this data to synchronize operations with various infrastructure components (e.g., RAN nodes 112a, 112b, etc.).

[0190] Figure 8 The components shown can communicate with each other using interface circuitry, 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, such as a proprietary bus used in a SoC-based system. Other bus / IX systems may be included, such as I2C interfaces, SPI interfaces, point-to-point interfaces, and power buses, etc.

[0191] Figure 9 Examples of computer platform 900 (or “device 900”) according to various specific embodiments are shown. In some embodiments, computer platform 900 may be adapted to function as client device 102, application server 110, and / or any other element / device discussed herein. Platform 900 may include any combination of the components shown in the examples. Components of 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 in computer platform 900, or may be implemented as components otherwise integrated 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 components shown may occur in other specific embodiments.

[0192] Application circuitry 905 includes circuitry such as, but not limited to, one or more processors (or processor cores), cache memory, and one or more of the following: LDO, interrupt controller, serial interface (such as SPI), I2C or general programmable serial interface module, RTC, timer-counter (including interval timers and watchdog timers), general-purpose I / O, memory card controller (such as SDMMC or similar controllers), USB interface, MIPI interface, and JTAG test access port. The processor (or core) of application circuitry 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 system 900. In some specific implementations, the memory / storage element may be on-chip memory circuitry, which may include any suitable volatile and / or non-volatile memory, such as DRAM, SRAM, EPROM, EEPROM, flash memory, solid-state memory, and / or any other type of memory device technology, such as those discussed herein.

[0193] 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, multi-threaded processors, ultra-low voltage processors, embedded processors, some other known processing elements, or any suitable combination thereof.

[0194] In some implementations, application circuitry 905 may include or may be a dedicated processor / controller for operation according to the various implementations herein. As an example, the processor of application circuitry 905 may include an Apple A-series processor. The processor of application circuitry 905 may also be one or more of the following: based on... ArchitectureCore TM processors, such as Quark TM Atom TM i3, i5, i7 or MCU-level processors, or available from Santa Clara, California. company( Another such processor is from Corporation, Santa Clara, CA; Advanced Micro Devices (AMD) Processor or Accelerated Processing Unit (APU); from Snapdragon by Technologies, Inc. TM Processor, Texas Instruments Open MultimediaApplications Platform(OMAP) TM Processors; MIPS-based designs from MIPS Technologies, Inc., such as the MIPS Warrior M-class, Warrior I-class, and Warrior P-class processors; ARM-based designs licensed from ARM Holdings, Ltd., such as the ARM Cortex-A, Cortex-R, and Cortex-M series processors; etc.

[0195] In some implementations, application circuitry 905 may be part of a system-on-a-chip (SoC), where application circuitry 905 and other components are formed as a single integrated circuit. Alternatively, application circuitry 905 may include circuitry 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); ASICs, such as structured ASICs; programmable SoCs (PSoCs); and so on. In such implementations, the circuitry of application circuitry 905 may include logic blocks or logic architectures, and other interconnect resources that can be programmed to perform various functions such as programs, methods, and functions.

[0196] In such embodiments, the application circuitry 905 may include memory cells (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), fuses, etc.)) for storing logic blocks, logic architectures, data, etc. In some embodiments, the client device 102 may include one or more processors configured to execute software instructions stored in the application circuitry 905. The application circuitry 905 may include an output queue optimizer 948.

[0197] The baseband circuit 910 may be implemented, for example, as a solderable substrate comprising one or more integrated circuits, a single-package integrated circuit soldered to a main circuit board, or a multi-chip module containing two or more integrated circuits. In some embodiments, the baseband circuit 910 is similar to the baseband circuit 103. In some embodiments, 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. This may occur, for example, 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.

[0198] RFEM 915 may include a millimeter-wave (mmWave) RFEM and one or more sub-millimeter-wave radio frequency integrated circuits (RFICs). In some embodiments, the one or more sub-millimeter-wave RFICs may be physically separated from the millimeter-wave RFEM. The RFIC may include connectors to one or more antennas or antenna arrays, and the RFEM may be connected to multiple antennas. In another embodiment, the radio functions of both millimeter-wave and sub-millimeter-wave technologies may be implemented in the same physical RFEM 915 that combines both the millimeter-wave antenna and the sub-millimeter-wave technology.

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

[0200] The memory circuit 920 can be developed according to the Joint Electron Device Engineering Council (JEDEC) design based on Low Power Double Data Rate (LPDDR), such as LPDDR2, LPDDR3, LPDDR4, etc. The memory circuit 920 can be implemented as one or more of the following: solder-in packaged integrated circuits, single-die packages (SDP), dual-die packages (DDP), or quad-die packages (Q17P), socket memory modules, dual in-line memory modules (DIMMs) including micro DIMMs or mini DIMMs, and / or soldered to a motherboard via a ball grid array (BGA). In a low-power implementation, the memory circuit 920 can be an on-chip memory or register associated with the application circuit 905. To provide persistent storage for information such as data, applications, operating systems, etc., the memory circuit 920 can include one or more mass storage devices, which may include, in particular, solid-state drives (SSDDs), hard disk drives (HDDs), miniature HDDs, resistance-changing memories, phase-change memories, holographic memories, or chemical memories. For example, the computer platform 900 can be integrated with... and 3D XPOINT memory.

[0201] The removable storage circuitry 923 may include devices, circuitry, enclosures / housings, ports, or sockets for coupling portable data storage devices to the platform 900. These portable data storage devices can be used for mass storage and may include, for example, flash memory cards (e.g., Secure Digital (SD) cards, MicroSD cards, xD picture cards, etc.) as well as USB flash drives, optical discs, external HDDs, etc.

[0202] Platform 900 may also include interface circuitry (not shown) for connecting external devices to platform 900. External devices connected to platform 900 via this interface circuitry include sensor circuitry 921 and electromechanical components (EMC) 922, as well as a removable memory device coupled to removable memory circuitry 923.

[0203] Sensor circuit 921 includes devices, modules, or subsystems designed to detect events or changes in their environment and transmit information about the detected events (sensor data) to other devices, modules, subsystems, etc. Examples of such sensors include, in particular: inertial measurement units (IMUs) including accelerometers, gyroscopes, and / or magnetometers; microelectromechanical systems (MEMS) or nanoelectromechanical systems (NEMS) including triaxial accelerometers, triaxial gyroscopes, and / or magnetometers; level sensors; flow sensors; temperature sensors (e.g., thermistors); pressure sensors; barometric pressure sensors; gravimeters; altimeters; image capture devices (e.g., cameras or lensless aperture devices); light detection and ranging (LiDAR) sensors; proximity sensors (e.g., infrared radiation detectors, etc.), depth sensors, ambient light sensors, ultrasonic transceivers; microphones or other similar audio capture devices; etc.

[0204] The EMC 922 includes devices, modules, or subsystems intended to enable the platform 900 to change its state, position, and / or orientation, or to move or control mechanisms or (sub)systems. 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 electromechanical relays (EMRs) and / or solid-state relays (SSRs)), actuators (e.g., valve actuators), audible generators, visual warning devices, motors (e.g., DC motors, stepper motors, etc.), wheels, propellers, pawls, clamps, hooks, and / or other similar electromechanical components. In specific implementations, the platform 900 is configured to operate one or more EMC 922s based on one or more captured events and / or commands or control signals received from a service provider and / or various clients.

[0205] In some implementations, the interface circuitry can connect platform 900 to positioning circuitry 945. Positioning circuitry 945 includes circuitry for receiving and decoding signals transmitted / broadcast by a GNSS positioning network. Examples of navigation satellite constellations (or GNSS) include GPS (USA), GLONASS (Russia), Galileo (EU), BeiDou (China), regional navigation systems, or GNSS augmentation systems (e.g., NAVIC, QZSS (Japan), DORIS (France), etc.). Positioning circuitry 945 may include various hardware components (e.g., hardware devices such as switches, filters, amplifiers, antenna elements, etc.) to facilitate OTA communication for communication with components of the positioning network, such as navigation satellite constellation nodes. In some implementations, positioning circuitry 945 may include a miniature PNT IC that performs position tracking / estimation using a master timing clock without GNSS assistance. Positioning circuitry 945 may also be part of or interact with baseband circuitry 910 and / or RFEM 915 to communicate with nodes and components of the positioning network. The positioning circuit 945 can also provide location data and / or time data to the application circuit 905, which can use the data to synchronize operations with various infrastructures (e.g., radio base stations) for use in turn-by-turn navigation applications, etc.

[0206] In some implementations, the interface circuitry can connect platform 900 to near-field communication (NFC) circuitry 940. NFC circuitry 940 is configured to provide contactless short-range communication based on radio frequency identification (RFID) standards, where magnetic field sensing is used to enable communication between NFC circuitry 940 and NFC-enabled devices (e.g., “NFC contacts”) external to platform 900. NFC circuitry 940 includes an NFC controller coupled to an antenna element and a processor coupled to the NFC controller. The NFC controller may be a chip / IC that provides NFC functionality to NFC circuitry 940 by executing NFC controller firmware and an NFC stack. The NFC stack may be executed by the processor to control the NFC controller, and the NFC controller firmware may be executed by the NFC controller to control the antenna element to transmit short-range RF signals. The RF signals may power passive NFC tags (e.g., microchips embedded in stickers or wristbands) to transmit stored data to NFC circuitry 940, or initiate data transfer between NFC circuitry 940 and another active NFC device (e.g., a smartphone or an NFC-enabled POS terminal) located near platform 900.

[0207] The drive circuitry 946 may include software and hardware elements for controlling specific devices embedded in, attached to, or otherwise communicatively coupled to the platform 900. The drive circuitry 946 may include various drivers that allow other components of the platform 900 to interact with or control various input / output (I / O) devices that may exist within or be connected to the platform. For example, the drive circuitry 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 acquiring sensor readings of sensor circuitry 921 and controlling and allowing access to sensor circuitry 921; an EMC driver for acquiring actuator position of EMC 922 and / or controlling and allowing access to 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.

[0208] A power management integrated circuit (PMIC) 925 (also referred to as "power management circuit 925") manages the power supplied to various components of platform 900. Specifically, relative to baseband circuit 910, PMIC 925 controls power selection, voltage scaling, battery charging, or DC-DC conversion. PMIC 925 is typically included when platform 900 can be powered by battery 930, for example, when the device is included in client device 102.

[0209] In some implementations, the PMIC 925 can be controlled or otherwise integrated into various power-saving mechanisms of the platform 900. For example, if the platform 900 is in the RRC_Connected state, where it remains connected to the RAN node as it anticipates receiving traffic soon, it can enter a state known as Discontinuous Receive (DRX) after a period of inactivity. During this state, the platform 900 can power down for short intervals to conserve power. If there is no data traffic activity for an extended period, the platform 900 can transition to the RRC_Idle state, in which the device is disconnected from the network and does not perform operations such as channel quality feedback or handover. The platform 900 enters a very low-power state and performs paging, during which the device periodically wakes up again to listen to the network and then power down 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 can allow the device to be 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 can be completely powered off. Any data sent during this time will result in significant latency, which is assumed to be acceptable.

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

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

[0212] A power block coupled to the mains or other power source can be coupled to the BMS to charge the battery 930. In some examples, a wireless power receiver can replace the power block 930 to wirelessly obtain power, for example, via a loop antenna in the computer platform 900. In these examples, wireless battery charging circuitry can be included in the BMS. The specific charging circuitry chosen may depend on the size of the battery 930 and therefore on the required current. Charging can be performed using the aviation fuel standards published by the Aviation Fuel Alliance, the Qi wireless charging standard published by the Radio Power Alliance, or the Rezence charging standard published by the Radio Power Alliance.

[0213] User interface circuitry 950 includes various input / output (I / O) devices present in or connected to platform 900, and includes one or more user interfaces designed to enable user interaction with platform 900 and / or peripheral component interfaces designed to enable interaction with peripheral components of platform 900.

[0214] User interface circuitry 950 includes input device circuitry and output device circuitry. Input device circuitry includes any physical or virtual device for accepting input, particularly one or more physical or virtual buttons (e.g., a reset button), a physical keyboard, a keypad, a mouse, a touchpad, a touchscreen, a microphone, a scanner, a headset, etc. Output device circuitry includes any physical or virtual device for displaying information or otherwise conveying information (such as sensor readings, actuator positions, or other similar information). Output device circuitry may include any number and / or combination of audio or visual displays, particularly one or more simple visual outputs / indicators (e.g., binary status indicators (e.g., light-emitting diodes (LEDs)) and multi-character visual outputs, or more complex outputs such as display devices or touchscreens (e.g., liquid crystal displays (LCDs), LED displays, quantum dot displays, projectors, etc.), wherein the output of characters, graphics, multimedia objects, etc., is generated or produced by the operation of platform 900. Output device circuitry may also include speakers or other audio transmitting devices, printers, etc.

[0215] In some implementations, sensor circuitry 921 may be used as input device circuitry (e.g., an image capture device, motion capture device, etc.) and one or more EMCs may be used as output device circuitry (e.g., an actuator for providing haptic feedback, etc.). In another example, NFC circuitry may be included to read electronic tags and / or connect to another NFC-enabled device, the NFC circuitry including an NFC controller and processing device coupled to an antenna element. Peripheral component interfaces may include, but are not limited to, non-volatile memory ports, USB ports, audio jacks, power interfaces, etc.

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

[0217] Figure 10 This illustrates various protocol functions that can be implemented in wireless communication devices according to various specific implementations. Specifically, Figure 10 This includes an arrangement 1000 illustrating the interconnections between various protocol layers / entities. It provides various protocol layers / entities operating in conjunction with 5G / NR system standards and LTE system standards. Figure 10 The following description, but Figure 10 Some or all of these aspects may also be applicable to other wireless communication network systems.

[0218] In addition to other higher-layer functions not shown, the protocol layers of arrangement 1000 may also 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 (e.g., capable of providing communication between two or more protocol layers). Figure 10 Items 1059, 1056, 1050, 1049, 1045, 1035, 1025, and 1015 in the list.

[0219] PHY 1010 can transmit and receive physical layer signals 1005, which can 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 can also perform link adaptive 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 (e.g., RRC 1055). PHY 1010 can 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 specific implementations, instances of PHY 1010 may process requests from instances of MAC 1020 via one or more PHY-SAP 1015 and provide indications to them. According to some specific implementations, requests and indications transmitted via PHY-SAP 1015 may include one or more transport channels.

[0220] An instance of MAC 1020 can process requests from instances of RLC 1030 via one or more MAC-SAP 1025s and provide them with instructions. These requests and instructions transmitted via MAC-SAP 1025s may include one or more logical channels. MAC 1020 can perform mapping between logical channels and transport channels, multiplexing MAC SDUs from one or more logical channels onto a TB to be delivered to PHY 1010 via a transport channel, demultiplexing MAC SDUs from a TB delivered from PHY 1010 via a transport channel onto one or more logical channels, multiplexing MAC SDUs onto TBs, scheduling information reporting, error correction via HARQ, and logical channel prioritization.

[0221] An instance of RLC 1030 can process requests from instances of PDCP 1040 via one or more Radio Link Control Service Access Points (RLC-SAP) 1035 and provide them with instructions. These requests and instructions transmitted via RLC-SAP 1035 may include one or more RLC channels. RLC 1030 can operate in several operating modes, including: Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). RLC 1030 can perform transmission of Upper Layer Protocol Data Units (PDUs), error correction via Automatic Repeat Request (ARQ) for AM data transmission, and concatenation, segmentation, and reassembly of RLCSDUs for UM and AM data transmission. RLC 1030 can also perform resegmentation 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 RLC re-establishment.

[0222] An instance of PDCP 1040 can process and provide instructions to instances of RRC 1055 and / or SDAP 1047 via one or more Packet Data Convergence Protocol Service Points (PDCP-SAP) 1045. These requests and instructions transmitted via PDCP-SAP 1045 may include one or more radio bearers. PDCP 1040 can perform header compression and decompression of IP data, maintain PDCP sequence numbers (SNs), perform ordered delivery of upper-layer PDUs during lower-layer re-establishment, eliminate duplication of lower-layer SDUs during lower-layer re-establishment for radio bearers mapped on RLCAM, 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.).

[0223] An instance of SDAP 1047 can process requests from one or more higher-layer protocol entities via one or more SDAP-SAP 1049s and provide them with indications. These requests and indications transmitted via SDAP-SAP 1049s can include one or more QoS flows. SDAP 1047 can map QoS flows to DRBs and vice versa, and can also tag QFIs in DL and UL packets. A single SDAP entity 1047 can be configured for a single PDU session. In the UL direction, NG-RAN 112 can control the mapping of QoS flows to DRBs in two different ways (reflective mapping or explicit mapping). For reflective mapping, the SDAP 1047 of client device 102 can monitor the QFI of DL packets for each DRB and can apply the same mapping for packets flowing in the UL direction. For DRBs, the SDAP 1047 of client device 102 can map UL packets belonging to a QoS flow that corresponds to the QoS flow ID and PDU session observed in the DL packets of that DRB. To implement reflection mapping, NG-RAN can tag DL packets with QoS flow IDs via the Uu interface. Explicit mapping may involve configuring SDAP1047 with explicit mapping rules from QoS flows to DRBs using RRC 1055; these rules can be stored and followed by SDAP 1047. In practice, SDAP 1047 may be used only in NR implementations and may not be used in LTE implementations.

[0224] The RRC 1055 can configure aspects of one or more protocol layers via one or more Management Service Access Points (M-SAPs), which may include one or more instances of PHY 1010, MAC 1020, RLC 1030, PDCP 1040, and SDAP 1047. In a specific implementation, an instance of the RRC 1055 can process requests from one or more NAS entities 1057 and provide instructions to those entities via one or more RRC-SAPs 1056. The main services and functions of the RRC 1055 may include broadcasting system information (e.g., included in NAS-related MIBs or SIBs), broadcasting system information related to the Access Layer (AS), paging, establishing, maintaining, and releasing RRC connections between client equipment 102 and the RAN (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release), establishing, configuring, maintaining, and releasing point-to-point radio bearers, security functions including key management, inter-RAT mobility, and measurement configuration for UE measurement reporting. These MIBs and SIBs may include one or more IEs, each of which may include a separate data field or data structure.

[0225] The NAS 1057 forms the highest level of the control plane between client device 102 and the AMF. The NAS 1057 supports the mobility and session management procedures of client device 102 to establish and maintain IP connections between client device 102 and the P-GW in an LTE system.

[0226] Depending on the specific implementation, one or more protocol entities of the gNB 1000 may be implemented in client device 102, RAN node 112a, AMF in NR implementation or MME in LTE implementation, UPF in NR implementation or S-GW and P-GW in LTE implementation, etc., for use in the control plane or user plane communication protocol stack between the aforementioned devices. In such implementations, one or more protocol entities implemented in one or more of client device 102, gNB 112a, AMF, etc., may communicate with corresponding peer protocol entities that may 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 implementations, the gNB-CU of gNB 112A may host the RRC 1055, SDAP 1047, and PDCP 1040 for controlling one or more gNB-DU operations of the gNB, and the gNB-DU of gNB 112A may each host the RLC 1030, MAC 1020, and PHY 1010 of gNB 112A.

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

[0228] In a specific NR implementation, AP 1063 may be an NG application protocol layer (NGAP or NG-AP) 1063 for an NG interface 113 that is limited between NG-RAN nodes 112A and AMF, or AP 1063 may be an Xn application protocol layer (XnAP or Xn-AP) 1063 for an Xn interface 112B that is limited between two or more RAN nodes 112A.

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

[0230] XnAP 1063 supports the functions of Xn interface 112B and may include XnAP basic mobility procedures and XnAP global procedures. The XnAP basic mobility procedures may include procedures for handling UE mobility within NG RAN 112A (or E-UTRAN), such as handover preparation and cancellation procedures, SN state transmission procedures, UE context retrieval and UE context release procedures, RAN paging procedures, and procedures related to dual connectivity. The XnAP global procedures may include procedures independent of the specific client device 102, such as Xn interface setup and reset procedures, NG-RAN update procedures, and cell activation procedures.

[0231] In a specific LTE implementation, AP 1063 can be an S1 application protocol layer (S1-AP) 1063 for an S1 interface 113 that is limited between E-UTRAN node 112A and MME, or AP 1063 can be an X2 application protocol layer (X2AP or X2-AP) 1063 for an X2 interface 112B that is limited between two or more E-UTRAN nodes 112A.

[0232] The S1 Application Protocol Layer (S1-AP) 1063 supports the functions of the S1 interface and, similar to the previously discussed NG-AP, may include an S1-AP EP. The S1-AP EP can be the interaction unit between the E-UTRAN node 112A and the MME within the LTE core network. S1-AP 1063 services may include two sets: UE-associated services and non-UE-associated services. These services perform functions including, but 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.

[0233] X2AP 1063 supports the functions of X2 interface 112B and may include X2AP basic mobility procedures and X2AP global procedures. The X2AP basic mobility procedures may include procedures for handling UE mobility within 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, and procedures related to dual connectivity. The X2AP global procedures may include procedures independent of specific client equipment 102, such as X2 interface setup and reset procedures, load indication procedures, error indication procedures, and cell activation procedures.

[0234] The SCTP layer (optionally referred to as the SCTP / IP layer) 1062 provides guaranteed delivery of application layer messages (e.g., NGAP or XnAP messages in NR implementations, or S1-AP or X2AP messages in LTE implementations). SCTP 1062 may, in part, rely on the IP protocol supported by IP 1061 to ensure reliable delivery of signaling messages between RAN node 112a or 112b and the AMF / MME. The Internet Protocol layer (IP) 1061 can be used to perform packet addressing and routing functions. In some implementations, IP layer 1061 may use point-to-point transmission to deliver and transmit PDUs. In this regard, RAN node 112a or 112b may include L2 and L1 layer communication links (e.g., wired or wireless) with the MME / AMF to exchange information.

[0235] In the second example, the user plane protocol stack may include SDAP 1047, PDCP 1040, RLC 1030, MAC 1020, and PHY 1010 in order from the highest to the lowest layer. The user plane protocol stack can be used for communication between client devices 102, RAN nodes 112a, 112b, or serving or packet gateways in an LTE implementation. In this example, the upper layer 1051 may be built on top of SDAP 1047 and may include User Datagram Protocol (UDP) and IP Security Layer (UDP / IP) 1052, General Packet Radio Service (GPRS) Tunneling Protocol for User Plane Layer (GTP-U) 1053, and User Plane PDU Layer (UP PDU) 1063.

[0236] The transport network layer 1054 (also known as the "transport layer") can be built on top of IP transport, and the GTP-U 1053 can be used on top of the UDP / IP layer 1052 (which includes the UDP and IP layers) to carry user plane PDUs (UP-PDUs). The IP layer (also known as the "Internet layer") can be used to perform packet addressing and routing functions. The IP layer can assign IP addresses to user data packets in any of the formats, such as IPv4, IPv6, or PPP.

[0237] The GTP-U 1053 can be used to carry user data within the GPRS core network and between the radio access network and the core network. For example, the transmitted user data can be packets in any of the IPv4, IPv6, or PPP formats. The UDP / IP 1052 provides checksums for data integrity, port numbers for addressing different functions at the source and destination, and encryption and authentication for selected data streams. RAN nodes 112a and 112b, as well as the service and packet gateways (not shown), can utilize the S1-U interface to exchange user plane data via a protocol stack including L1 layer (e.g., PHY 1010), L2 layer (e.g., MAC 1020, RLC 1030, PDCP 1040, and / or SDAP 1047), UDP / IP layer 1052, and GTP-U 1053. The service and packet gateway can utilize the S5 / S8a interface to exchange user plane data via a protocol stack including L1 layer, L2 layer, UDP / IP layer 1052 and GTP-U 1053. As previously discussed, the NAS protocol can support the mobility and session management procedures of client device 102 to establish and maintain IP connections of client device 102.

[0238] Furthermore, despite Figure 10Not shown, but the application layer may exist above AP 1063 and / or transport network layer 1054. The application layer may be a layer where users of client devices 102, RAN nodes 112a, 112b, or other network elements interact with software applications, for example, executed by application circuitry 805 or application circuitry 905. The application layer may also provide one or more interfaces for software applications to interact with the communication systems of client devices 102, RAN nodes 112a, 112b (such as baseband circuitry 810 or 910). In some implementations, the IP layer and / or application layer may provide the same or similar functionality as layers 5 through 7 of the Open Systems Interconnection (OSI) model, or portions thereof (e.g., OSI layer 7—application layer, OSI layer 6—presentation layer, and OSI layer 5—session layer).

[0239] Figure 11 This is a block diagram illustrating components capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and executing any or more methods discussed herein, according to some exemplary specific embodiments. Specifically, Figure 11 A schematic diagram of hardware resource 1100 is shown, 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 is communicatively coupled via bus 1140. For a specific implementation utilizing node virtualization (e.g., NFV), an executable hypervisor 1102 provides an execution environment for one or more network slices / subslices to utilize hardware resource 1100.

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

[0241] The memory / storage device 1120 may include main memory, disk storage devices, 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.

[0242] Communication resource 1130 may include interconnect or network interface components or other suitable devices for communicating with one or more peripheral devices 1104 or one or more databases 1106 via network 1108. For example, communication resource 1130 may include wired communication components (e.g., for coupling via USB), cellular communication components, NFC components, etc. (or Low-power components Components and other communication components.

[0243] Instructions 1150 may include software, programs, applications, applets, or other executable code for causing at least any one of processors 1110 to perform any or more of the methods discussed herein. Instructions 1150 may reside wholly or partially within processor 1110 (e.g., within the processor's cache memory), memory / storage device 1120, or at least one of any suitable combination thereof. Furthermore, any portion of instructions 1150 may be transferred to hardware resource 1100 from any combination of peripheral device 1104 or database 1106. Thus, the memory of processor 1110, memory / storage device 1120, peripheral device 1104, and database 1106 are examples of computer-readable and machine-readable media. In some implementations, hardware resource 1100 may be included in client device 102. Client device 102 may include one or more processors similar to processor 1110 configured to execute software instructions that, when executed, perform various functions such as programs, methods, and functions discussed herein.

[0244] As is widely recognized, the use of personally identifiable information should comply with privacy policies and practices that are generally accepted to meet or exceed industry or governmental requirements for protecting user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of authorized use should be clearly explained to users.

[0245] Specific implementations of the subject matter and functional operations described in this specification may be implemented in digital electronic circuits, in tangibly embodied computer software or firmware, in computer hardware (including the structures disclosed herein and their equivalents), or in a combination of one or more of these. Software implementations of the subject matter may be implemented as one or more computer programs. Each computer program may include one or more modules of computer program instructions encoded on a tangible, non-transitory, computer-readable computer storage medium for execution by a data processing apparatus or for controlling the operation of the data processing apparatus. Alternatively or additionally, the program instructions may be encoded in / on an artificially generated propagated signal. In one example, the signal may be a machine-generated electrical signal, optical signal, or electromagnetic signal generated to encode information for transmission to a suitable receiver device for execution by the data processing apparatus. The computer storage medium may 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.

[0246] The terms “data processing apparatus,” “computer,” and “computing device” (or their equivalents as understood by one of ordinary skill in the art) refer to data processing hardware. For example, a data processing apparatus may encompass various means, devices, and machines for processing data, including programmable processors, computers, or multiple processors or computers. The apparatus may also include special-purpose logic circuitry, including, for example, a central processing unit (CPU), a field-programmable gate array (FPGA), or an application-specific integrated circuit (ASIC). In some embodiments, the data processing apparatus or special-purpose logic circuitry (or a combination thereof) may be hardware-based or software-based (or a combination of hardware-based and software-based). The apparatus may optionally include code that creates an execution environment for computer programs, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, or a combination of execution environments. This disclosure contemplates the use of data processing apparatuses with or without conventional operating systems (e.g., LINUX, UNIX, WINDOWS, MAC OS, ANTROL, or IOS).

[0247] A computer program, also referred to or described as a program, software, software application, module, software module, script, or code, can be written in any form of programming language. Programming languages ​​may include, for example, compiled languages, interpreted languages, declarative languages, or procedural languages. A program can be deployed in any form, including as a standalone program, module, component, subroutine, or unit for use in a computing environment. A computer program may, but does not necessarily, correspond to a file in a file system. A program may be stored as part of a file containing other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple harmonizing files storing one or more modules, subroutines, or code portions. A computer program may be deployed to execute on a single computer or on multiple computers located at, for example, a single site or distributed across multiple sites interconnected by a communication network. While portions of a program shown in the various figures may be depicted as separate modules implementing various features and functions through various objects, methods, or processes, a program may alternatively include multiple submodules, third-party services, components, and libraries. Conversely, the features and functions of various components may be combined into a single component as appropriate. The thresholds used for computation determination may be determined statically, dynamically, or simultaneously statically and dynamically.

[0248] The methods, processes, or logical flows described in this specification may be executed by one or more programmable computers that execute one or more computer programs to perform functions by manipulating input data and producing outputs. These methods, processes, and logical flows may also be executed by special-purpose logic circuitry (e.g., a CPU, FPGA, or ASIC), and the apparatus may also be implemented as special-purpose logic circuitry.

[0249] A computer suitable for executing computer programs may be based on one or more of general-purpose microprocessors, special-purpose microprocessors, and other types of CPUs. The components of a computer are a CPU for executing instructions and one or more memory devices for storing instructions and data. Generally, the CPU receives instructions and data from memory (and writes data to memory). A computer may also include or be operatively coupled to one or more mass storage devices for storing data. In some specific implementations, the computer may receive data from and transfer data to mass storage devices, including, for example, magnetic disks, magneto-optical disks, or optical disks. Furthermore, the computer may 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.

[0250] Computer-readable media (transient or non-transient, as the case may be) suitable for storing computer program instructions and data can include all forms of permanent / non-permanent and volatile / non-volatile memory, media, and memory devices. Computer-readable media can 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. Computer-readable media can also include, for example, magnetic devices such as magnetic tape, tape cassettes, cassettes, and internal / removable disks. Computer-readable media can also include magneto-optical and optical memory devices and technologies, including, for example, digital video optical discs (DVDs), CD-ROMs, DVD+ / -R, DVD-RAM, DVD-ROM, HD-DVD, and BLURAY. Memory can store various objects or data, including caches, classes, frames, applications, modules, backup data, jobs, web pages, web page templates, data structures, database tables, libraries, and dynamic information. The types of objects and data stored in memory can include parameters, variables, algorithms, instructions, rules, constraints, and references. Additionally, memory can include logs, policies, security or access data, and report files. Processors and memory can be supplemented by dedicated logic circuitry or integrated into dedicated logic circuitry.

[0251] While this specification includes numerous specific implementation details, these details should not be construed as limiting the scope of the claims, but rather as descriptions of features that may be specific to particular implementations. Some features described in the context of different implementations may also be implemented in combination in a single implementation. Conversely, various features described in the context of a single implementation may be implemented individually or in any suitable sub-combination in multiple implementations. Furthermore, while the features previously described may be described as functioning in certain combinations, and even initially claimed in this manner, one or more features in a claimed combination may be removed from that combination in certain circumstances, and the claimed combination may involve sub-combinations or variations thereof.

[0252] Specific embodiments of the subject matter have been described. Other embodiments, modifications, and arrangements of the described embodiments are within the scope of the following claims, and will be apparent to those skilled in the art. Although the operations are shown in a specific order in the drawings or claims, this should not be construed as requiring such operations to be performed in the specific order or successive order shown, or requiring all of the operations shown to 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.

[0253] Furthermore, the division or integration of 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 can generally be integrated together in a single software product or packaged into multiple software products.

[0254] Therefore, the exemplary embodiments described above do not limit or restrict this disclosure. Other changes, substitutions, and modifications are also possible without departing from the spirit and scope of this disclosure.

[0255] This disclosure may also include the following examples.

[0256] Example 1 includes a method performed by a client device in a wireless network for transmission of Transmission Control Protocol Acknowledgment (TCPACK) packets, the method comprising: in response to receiving a TCP packet from another device in the wireless network, accessing in a memory coupled to the client device a queue of TCP ACK packets to be transmitted to the other 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 stream associated with the packet and (ii) a TCP ACK generation count; examining a packet descriptor of a first TCP ACK packet in the queue of TCP ACK packets; 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, the first entry having (i) a flow identifier matching the first flow identifier and (ii) a TCP ACK generation count matching the first TCP ACK packet. The TCP ACK generation count is used to determine the ACK generation count; and in response to the determination, the first TCP ACK packet is marked as to be discarded.

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

[0258] Example 3 includes the method described in Example 2, wherein the queue first checks the latest group.

[0259] 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 checked by a baseband processor circuit included in the client device.

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

[0261] Example 6 includes the method according to Example 5, wherein the application processor controls the rate at which TCP ACK packets are discarded from the queue by controlling the duration of at least one of the first time interval or the second time interval.

[0262] Example 7 includes the method according to Example 1, further comprising: examining a packet descriptor of a third TCP ACK packet in the TCP packets in the queue; identifying a third TCP ACK generation count and a third stream 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.

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

[0264] Example 9 includes the method according to Example 1, further comprising: examining the packet descriptor of a third TCP ACK packet in the TCP ACK packets in the queue; identifying a third TCP ACK generation count and a third stream identifier corresponding to the third TCP ACK packet in the packet descriptor of the third TCP ACK packet; determining that the third stream identifier is set to an invalid value; and, in response to the determination, aborting further processing of the third TCP ACK packet.

[0265] 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: 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.

[0266] Example 11 includes the method according to Example 1, further comprising: examining a packet descriptor of a fourth TCP packet in the TCP packets in the queue; identifying a fourth TCP ACK generation count and a fourth stream identifier corresponding to the fourth TCP ACK packet in the packet descriptor of the fourth TCP ACK packet; determining that the fourth TCP ACK generation count and the fourth stream identifier are valid; determining that (i) the fourth stream identifier is the same as the first stream 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; 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.

[0267] Example 12 includes the method according to Example 1, further comprising: examining 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 stream 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 stream identifier are valid; determining that the data structure does not include an entry corresponding to the fifth stream identifier; and in response to the determination, creating a third entry in the data structure and storing the fifth stream identifier and the fifth TCP ACK generation count in the third entry.

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

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

[0270] Example 15 includes the method according to Example 1, wherein one or more entries in the data structure include hash values ​​representing stream identifiers, and wherein determining that the data structure includes a first entry storing the first TCP ACK generation count and the first stream identifier and the first TCP ACK generation count includes: performing a hash function on the first stream 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 stream identifier; comparing the first hash value with 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.

[0271] Example 16 includes a method performed by a client device in a wireless network for transmission of Transmission Control Protocol Acknowledgment (TCPACK) 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 of TCPACK packets to be transmitted to the other network device, wherein at least a subset of the TCPACK packets includes corresponding packet descriptors, each packet descriptor including (i) a flow identifier indicating a TCP stream associated with the packet and (ii) a TCP ACK generation count; examining a packet descriptor of a first TCP ACK packet in the queue of TCP ACK packets; 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. An ACK generation count is generated, and the first entry further stores a second position field corresponding to the position of the second TCP ACK packet in the queue; in response to the determination, the position of the first TCP ACK packet is stored in a first position field in the first entry; based at least 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 are swapped, such that the first TCP ACK packet moves to a position in the queue previously occupied by the second TCP ACK packet, and the second TCP ACK packet moves to a position in the queue previously occupied by the first TCP ACK packet; and the first TCP ACK packet is discarded from the queue.

[0272] 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 was generated before the second TCP ACK packet, and wherein the position of the first TCP ACK packet in the queue is before the position of the second TCP ACK packet in the queue.

[0273] Example 18 includes the method described in Example 17, wherein the queue first checks the latest group.

[0274] 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 baseband processor circuitry included in the client device.

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

[0276] Example 21 includes the method according to Example 20, wherein the application processor controls the rate at which TCP ACK packets are discarded from the queue by controlling the duration of at least one of the first time interval or the second time interval.

[0277] Example 22 includes the method according to Example 16, further comprising: examining a packet descriptor of a third TCP ACK packet in the TCP packets in the queue; identifying a third TCP ACK generation count and a third stream 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.

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

[0279] Example 24 includes the method according to Example 16, further comprising: examining a packet descriptor of a third TCP ACK packet in the TCP ACK packets in the queue; identifying a third TCP ACK generation count and a third stream identifier corresponding to the third TCP ACK packet in the packet descriptor of the third TCP ACK packet; determining that the third stream identifier is set to an invalid value; and, in response to the determination, aborting further processing of the third TCP ACK packet.

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

[0281] Example 26 includes the method according to Example 16, further comprising: examining a packet descriptor of a fourth TCP packet in the TCP packets in the queue; identifying a fourth TCP ACK generation count and a fourth stream identifier corresponding to the fourth TCP ACK packet in the packet descriptor of the fourth TCP ACK packet; determining that the fourth TCP ACK generation count and the fourth stream identifier are valid; determining that (i) the fourth stream identifier is the same as the first stream 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; 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.

[0282] Example 27 includes the method according to Example 16, further comprising: examining a packet descriptor of a fifth TCP packet in the TCP packets in the queue; identifying a fifth TCP ACK generation count and a fifth stream 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 stream identifier are valid; determining that the data structure does not include an entry corresponding to the fifth stream identifier; and in response to the determination, creating a third entry in the data structure and storing the fifth stream identifier and the fifth TCP ACK generation count in the third entry.

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

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

[0285] Example 30 includes the method according to Example 16, wherein one or more entries in the data structure include hash values ​​representing stream identifiers, and wherein determining that the data structure includes a first entry storing the first TCP ACK generation count and the first stream identifier and the first TCP ACK generation count includes: performing a hash function on the first stream 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 stream identifier; comparing the first hash value with 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 a hash value included in the first entry matches the first hash value.

[0286] Example 31 includes the method according to Example 16, wherein one or more entries in the data structure include hash values ​​representing stream identifiers, and wherein determining that the data structure includes a first entry storing the first TCP ACK generation count and the first stream identifier and the first TCP ACK generation count includes: performing a hash function on the first stream 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 stream identifier; comparing the first hash value with 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 a hash value included in the first entry matches the first hash value.

[0287] Example 32 includes a method executed 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 comprising: generating TCP ACK packets for transmission to a remote device in the wireless network, each TCP ACK packet including a packet descriptor; storing (i) a flow identifier indicating a TCP stream associated with the packet and (ii) a TCP ACK generation count in a corresponding packet descriptor of at least a subset of the TCP ACK packets; and forwarding the TCP ACK packets, including the subset of the TCP ACK packets, to a baseband processor included in the client device.

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

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

[0290] Example 35 includes the method according to Example 32, further comprising the application processor determining 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.

[0291] Example 36 includes the method according to Example 32, further comprising the application processor determining 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 if no TCP ACK count value is generated.

[0292] Example 37 includes the method according to Example 32, further comprising the application processor determining 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 flow identifier in the packet descriptor of the first TCP ACK packet to a predetermined invalid value.

[0293] Example 38 includes the method according to Example 32, further comprising the application processor determining 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 flow identifier.

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

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

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

[0297] Example 42 includes one or more non-transitory computer-readable media that store instructions, which, when executed, are configured to cause one or more processors to perform an operation according to any one of Examples 1-15.

[0298] Example 43 includes one or more non-transitory computer-readable media that store instructions, which, when executed, are configured to cause one or more processors to perform an operation according to any one of Examples 16-31.

[0299] Example 44 includes one or more non-transitory computer-readable media that store instructions, which, when executed, are configured to cause one or more processors to perform any one of Examples 32-38.

Claims

1. A method performed by a client device in a wireless network for transmitting TCPACK packets for Transmission Control Protocol Acknowledgment, the method comprising: In response to receiving a Transmission Control Protocol (TCP) packet from another device in the wireless network, a queue of TCP ACK packets to be transmitted to the other device is accessed in a memory coupled to the client device, wherein at least a subset of the TCP ACK packets includes a corresponding packet descriptor, each packet descriptor including (i) a stream identifier indicating the TCP stream associated with the corresponding TCP ACK packet and (ii) a TCP ACK generation count, and wherein multiple TCP ACK packets generated at the same time interval have the same TCP ACK generation count; Examine the packet descriptor of the first TCP ACK packet in the TCP ACK packets in the queue; Identify the first stream identifier and the first TCP ACK generation count, which are included in the packet descriptor of the first TCP ACK packet and correspond to the first TCP ACK packet; It is determined that the first stream identifier and the first TCP ACK generation count are valid; Accessing a data structure comprising entries in the memory coupled to the client device, each entry having at least a first field and a second field, the first field and the second field storing a stream identifier and a corresponding TCPACK generation count, respectively; The data structure is determined to include a first entry, the first entry having (i) a stream identifier that matches the first stream identifier and (ii) a TCP ACK generation count that matches the first TCP ACK generation count; as well as In response to the determination, the first TCP ACK packet is marked as to be discarded.

2. The method of claim 1, wherein the first entry in the data structure corresponds to the second TCP ACK packet in the queue, and wherein the first TCP ACK packet is generated before the second TCP ACK packet, wherein the position of the first TCP ACK packet in the queue is before the position of the second TCP ACK packet in the queue, and wherein the queue is first checked with the latest packet.

3. The method of claim 1, wherein the packet descriptor is assigned by a TCP application processor included in the client device, and the packet descriptor is inspected by baseband processor circuitry included in the client device. The TCP application processor assigns a first ACK generation count value corresponding to the first stream 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 stream identifier to a plurality of TCP ACK packets generated in a second time interval different from the first time interval, wherein the first ACK generation count value is different from the second ACK generation count value.

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

5. The method according to claim 1, further comprising: Examine the packet descriptor of the third TCP ACK packet in the TCP ACK packets in the queue; Identify the third TCP ACK generation count and third stream identifier corresponding to the third TCP ACK packet, which are 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 includes determining one of the following: The third TCP ACK generation count of the third TCP ACK packet is empty, or The third TCP ACK generation count of the third TCP ACK packet is set to a predetermined invalid value; and In response to the determination, further processing of the third TCP ACK packet is aborted.

6. The method according to claim 1, further comprising: Examine the packet descriptor of the third TCP ACK packet in the TCP ACK packets in the queue; Identify the third TCP ACK generation count and third stream identifier corresponding to the third TCP ACK packet, which are included in the packet descriptor of the third TCP ACK packet; Determining that the third-stream identifier is set to an invalid value includes determining one of the following: The flow identifier was not assigned to the third TCP ACK packet, or The third stream identifier of the third TCP ACK packet is set to a predetermined invalid value; and In response to the determination, further processing of the third TCP ACK packet is aborted.

7. The method according to claim 6, further comprising: Examine the packet descriptor of the fourth TCP ACK packet in the queue; Identify the fourth TCP ACK generation count and fourth stream identifier corresponding to the fourth TCP ACK packet, which are included in the packet descriptor of the fourth TCP ACK packet; It is determined that the fourth TCP ACK generation count and the fourth stream identifier are valid; Determine that (i) the fourth stream identifier is the same as the first stream 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; as well as In response to the determination, the first entry is updated by replacing the first TCP ACK generation count stored in the second field of the first entry with the fourth TCP ACK generation count.

8. The method according to claim 7, further comprising: Examine the packet descriptor of the fifth TCP ACK packet in the TCP ACK packets in the queue; Identify the fifth TCP ACK generation count and fifth stream identifier corresponding to the fifth TCP ACK packet, which are included in the packet descriptor of the fifth TCP ACK packet; It is determined that the fifth TCP ACK generation count and the fifth stream identifier are valid; It is determined that the data structure does not include an entry corresponding to the fifth stream identifier; as well as In response to the determination, Create a third entry in the data structure, and The fifth stream identifier and the fifth TCP ACK generation count are stored in the third entry.

9. The method of claim 1, wherein one or more entries in the data structure include hash values ​​representing stream identifiers, and wherein determining that the data structure includes a first entry storing the first TCP ACK generation count and the first stream identifier comprises: A hash function is performed on the first stream 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 stream identifier; The first hash value is compared with the hash values ​​of the one or more entries included in the data structure to determine whether a match exists; as well as In response to the comparison, it is determined that the hash value included in the first entry matches the first hash value.

10. A processor for a user equipment (UE) in a wireless network, the processor comprising: Circuitry for executing instructions, the instructions being used to perform the following operations: In response to receiving a Transmission Control Protocol (TCP) packet from another UE in the wireless network, a queue of TCP ACK packets to be transmitted to the other UE is accessed in a memory coupled to the UE, wherein at least a subset of the TCP ACK packets includes a corresponding packet descriptor, each packet descriptor including (i) a stream identifier indicating the TCP stream associated with the corresponding TCP ACK packet and (ii) a TCP ACK generation count, and wherein multiple TCP ACK packets generated at the same time interval have the same TCP ACK generation count; Examine the packet descriptor of the first TCP ACK packet in the TCP ACK packets in the queue; Identify the first stream identifier and the first TCP ACK generation count, which are included in the packet descriptor of the first TCP ACK packet and correspond to the first TCP ACK packet; It is determined that the first stream identifier and the first TCP ACK generation count are valid; Accessing a data structure comprising entries in the memory coupled to the UE, 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; The data structure is determined to include a first entry, the first entry having (i) a stream identifier matching the first stream identifier and (ii) a TCP ACK generation count matching the first TCP ACK generation count; and In response to the determination, the first TCP ACK packet is marked as to be discarded.

11. The processor of claim 10, 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, wherein the first TCP ACK packet is positioned in the queue before the second TCP ACK packet is positioned in the queue, and wherein the queue is first checked with the latest packet.

12. The processor of claim 10, wherein the packet descriptor is assigned by a TCP application processor included in the UE, and the packet descriptor is checked by baseband processor circuitry included in the UE. The TCP application processor assigns a first ACK generation count value corresponding to the first stream 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 stream identifier to a plurality of TCP ACK packets generated in a second time interval different from the first time interval, wherein the first ACK generation count value is different from the second ACK generation count value.

13. The processor of claim 12, wherein the TCP application processor controls the rate at which TCP ACK packets are discarded from the queue by controlling the duration of at least one of the first time interval or the second time interval.

14. The processor of claim 10, further comprising: Examine the packet descriptor of the third TCP ACK packet in the TCP ACK packets in the queue; Identify the third TCP ACK generation count and third stream identifier corresponding to the third TCP ACK packet, which are 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 includes determining one of the following: The third TCP ACK generation count of the third TCP ACK packet is empty, or The third TCP ACK generation count of the third TCP ACK packet is set to a predetermined invalid value; and In response to the determination, further processing of the third TCP ACK packet is aborted.

15. The processor of claim 10, further comprising: Examine the packet descriptor of the third TCP ACK packet in the TCP ACK packets in the queue; Identify the third TCP ACK generation count and third stream identifier corresponding to the third TCP ACK packet, which are included in the packet descriptor of the third TCP ACK packet; Determining that the third-stream identifier is set to an invalid value includes determining one of the following: The flow identifier was not assigned to the third TCP ACK packet, or The third stream identifier of the third TCP ACK packet is set to a predetermined invalid value; and In response to the determination, further processing of the third TCP ACK packet is aborted.

16. The processor of claim 15, further comprising: Examine the packet descriptor of the fourth TCP ACK packet in the queue; Identify the fourth TCP ACK generation count and fourth stream identifier corresponding to the fourth TCP ACK packet, which are included in the packet descriptor of the fourth TCP ACK packet; It is determined that the fourth TCP ACK generation count and the fourth stream identifier are valid; Determine that (i) the fourth stream identifier is the same as the first stream 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; as well as In response to the determination, the first entry is updated by replacing the first TCP ACK generation count stored in the second field of the first entry with the fourth TCP ACK generation count.

17. The processor of claim 16, further comprising: Examine the packet descriptor of the fifth TCP ACK packet in the TCP ACK packets in the queue; Identify the fifth TCP ACK generation count and fifth stream identifier corresponding to the fifth TCP ACK packet, which are included in the packet descriptor of the fifth TCP ACK packet; It is determined that the fifth TCP ACK generation count and the fifth stream identifier are valid; It is determined that the data structure does not include an entry corresponding to the fifth stream identifier; as well as In response to the determination, Create a third entry in the data structure, and The fifth stream identifier and the fifth TCP ACK generation count are stored in the third entry.

18. The processor of claim 10, wherein one or more entries in the data structure include hash values ​​representing stream identifiers, and wherein determining that the data structure includes a first entry storing the first TCP ACK generation count and the first stream identifier comprises: A hash function is performed on the first stream 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 stream identifier; The first hash value is compared with the hash values ​​of the one or more entries included in the data structure to determine whether a match exists; as well as In response to the comparison, it is determined that the hash value included in the first entry matches the first hash value.

19. A method executed by an application processor of a user equipment (UE) in a wireless network for transmitting Transmission Control Protocol Acknowledgment (TCPACK) packets, the method comprising: Generate TCP ACK packets for transmission to remote devices in the wireless network, each TCP ACK packet including a packet descriptor; as well as In the corresponding packet descriptor for at least a subset of the TCP ACK packets, store (i) a flow identifier indicating the Transmission Control Protocol TCP stream associated with the corresponding TCP ACK packet and (ii) a TCP ACK generation count, wherein multiple TCP ACK packets generated in the same time interval have the same TCP ACK generation count; as well as The TCP ACK packets, including the subset of the TCP ACK packets, are forwarded to the baseband processor included in the UE.

20. The method of claim 19, 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, wherein the first ACK generation count value is different from the second ACK generation count value, and 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.

Images