WO2023239342A1

WO2023239342A1 - Adaptive voip packet clustering control framework

Info

Publication number: WO2023239342A1
Application number: PCT/US2022/032306
Authority: WO
Inventors: Su-Lin Low; Na CHEN
Original assignee: Zeku, Inc.
Priority date: 2022-06-06
Filing date: 2022-06-06
Publication date: 2023-12-14

Abstract

A system includes a downlink circuit configured to receive and decode packets received on a downlink data channel, an uplink circuit configured to receive and encode packets for transmission on an uplink data channel, and a dataplane block including control logic configured to obtain, via one of the downlink circuit or an application processor, a packet for clustering, and determine whether a threshold number of packets has been clustered for a current interval, in response to determining that the threshold number of packets has not been clustered, buffer the packet in a first cluster of one or more packets, in response to determining that the threshold number of packets has been clustered, transmit the first cluster of one or more packets to one of the application processor or the uplink circuit, and determine the threshold number of packets for a subsequent cluster of packets.

Description

ADAPTIVE VOIP PACKET CLUSTERING CONTROL FRAMEWORK

FIELD

[0001] The present disclosure relates, in general , to methods, systems, and apparatuses for low-latency packet management and control.

BACKGROUND

[0002] Typically, low-latency I real-time applications, such as voice over IP (VoIP) and internet of things (loT), are prioritized to ensure acceptable performance. Data path hardware (DPHW) and central processing unit (CPU) resources are often wasted for small packet low throughput traffic like VoIP or loT traffic. Conventional processing schemes often result in high modem power usage and inefficient processing of VoIP / layer 2 (L2) packets.

[0003] Thus, a lightweight, VoIP packet clustering control framework is provided.

SUMMARY

[0004] Tools and techniques for are provided for an adaptive VoIP packet clustering control (VPCC) framework.

[0005] A method includes receiving a packet for clustering, and determining whether a threshold number of packets has been clustered for a current interval. In response to determining that the threshold number of packets has not been clustered, the method may continue by buffering the packet in a first cluster of one or more packets, and in response to determining that the threshold number of packets has been clustered, the method may continue by transmitting the first cluster of one or more packets. The method further includes obtaining one or more parameters, wherein the one or more parameters includes modem or voice over internet protocol performance metrics, and determining the threshold number of packets for a subsequent cluster of packets based, at least in part, on the one or more parameters.

[0006] An apparatus includes a non-transitory computer readable medium in communication with the processor, the non-transitory computer readable medium having encoded thereon a set of instructions executable by the processor to perform various functions. The set of instructions may be executable by the processor to obtain a packet for clustering, determine whether a threshold number of packets has been clustered for a current interval, in response to determining that the threshold number of packets has not been clustered, buffer the packet in a first cluster of one or more packets, and in response to determining that the threshold number of packets has been clustered, transmit the first cluster of one or more packets. The set of instructions may further be executable by the processor to obtain one or more parameters, wherein the one or more parameters includes modem or voice over internet protocol performance metrics, and determine the threshold number of packets for a subsequent cluster of packets based, at least in part, on the one or more parameters. [0007] A system may include a downlink circuit configured to receive and decode packets received on a downlink data channel, an uplink circuit configured to receive and encode packets for transmission on an uplink data channel, and a dataplane block coupled to the downlink circuit and uplink circuit. The dataplane block may further include control logic configured to obtain, via one of the downlink circuit or an application processor, a packet for clustering, and determine whether a threshold number of packets has been clustered for a current interval . In response to determining that the threshold number of packets has not been clustered, the control logic may be configured to buffer the packet in a first cluster of one or more packets, and in response to determining that the threshold number of packets has been clustered, transmit the first cluster of one or more packets to one of the application processor or the uplink circuit. The control logic may further be configured to obtain one or more parameters, wherein the one or more parameters includes modem or voice over internet protocol performance metrics, and determine the threshold number of packets for a subsequent cluster of packets based, at least in part, on the one or more parameters.

[0008] These illustrative embodiments tire mentioned not to limit or define the disclosure, but to provide examples to aid understanding thereof. Additional embodiments are discussed in the Detailed Description, and further description is provided therein.

BRIEF DESCRIPTION OF THE DRAWINGS

[0009] A further understanding of the nature and ad vantages of particular embodiments may be realized by reference to the remaining portions of the specification and the drawings, in which like reference numerals are used to refer to similar components. In some instances, a sub-label is associated with a reference numeral to denote one of multiple similar components. When reference is made to a reference numeral without specification to an existing sub-label, it is intended to refer to all such multiple similar components.

[0010] Fig. 1 is a schematic block diagram of a system for VoIP packet clustering control, in accordance with various embodiments;

[00111 Fig. 2 is a schematic block diagram of an architecture for VoIP packet clustering control, in accordance with various embodiments;

[0012] Fig. 3 is a functional block diagram of VoIP packet clustering control algorithm for downlink packets, in accordance with various embodiments;

[0013] Fig. 4 is a functional block diagram of VoIP packet clustering control algorithm for uplink packets, in accordance with various embodiments;

[0014] Fig. 5 is a flow diagram of a method for V oIP packet clustering control, in accordance with various embodiments;

[0015] Fig. 6 is a flow diagram of one implementation of a method for VoIP packet clustering control, in accordance with various embodiments;

[0016] Fig. 7 is a schematic block diagram of a computer system for a VoIP packet clustering control, in accordance with various embodiments.

DETAILED DESCRIPTION OF EMBODIMENTS

[0017] Various embodiments provide tools and techniques for a VPCC framework is provided.

[0018] In some embodiments, a method for VPCC is provided. A method includes receiving a packet for clustering, and determining whether a threshold number of packets has been clustered for a current interval. In response to determining that the threshold number of packets has not been clustered, the method may continue by buffering the packet in a first cluster of one or more packets, and in response to determining that the threshold number of packets has been clustered, the method may continue by transmitting the first cluster of one or more packets. The method further includes obtaining one or more parameters, wherein the one or more parameters includes modern or voice over internet protocol performance metrics, and determining the threshold number of packets for a subsequent cluster of packets based, at least in part, on the one or more parameters. [0019] In some examples, the method may further include determining a tolerant latency time for each quality of service flow, wherein determining the threshold number of packets for the subsequent cluster of packets includes determining a tolerant latency time for each quality of service flow, determining a time interval between packet clusters based on the one or more parameters, determining a dynamic time interval between packet clusters based on tire tolerant latency time for each quality of service flow and the time interval between packet clusters, and selecting the threshold number of packets based on the dynamic time interval between packet clusters and an interval between packets.

[0029] In some examples, the one or more parameters includes one or more of a voice over internet protocol (VoIP) mean opinion score, signal power over noise and interference ratio, packet loss, jitter delay, packet delay budget, priority level, resource type, and the interval between packets.

[0021] In further examples, transmitting the first cluster of one or more packets includes, during downlink operation, routing the first cluster of one or more packets to an application processor. In some examples, the application processor includes at least one of a voice codec or low-latency small packet application.

[0022] In yet further examples, transmitting the first cluster of one or more packets includes, during uplink operation, routing the first cluster of one or more packets to a media access control layer and physical layer for uplink transmission. In some examples, transmitting the first cluster of one or more packets may further include encoding each packet of the first cluster of one or more packets to generate respective low-latency small packets, and transmitting the low-latency small packets to the physical layer for uplink transmission. [0023] In some examples, the packet may be a real-time protocol packet.

[0024] In some embodiments, an apparatus for VPCC is provided. An apparatus includes a non-transitory computer readable medium in communication with the processor, the non-transitory computer readable medium having encoded thereon a set of instructions executable by the processor to perform various functions. The set of instructions may be executable by the processor to obtain a packet for clustering, determine whether a threshold number of packets has been clustered for a current interval, in response to determining that the threshold number of packets has not been clustered, buffer the packet in a first cluster of one or more packets, and in response to determining that the threshold number of packets has been clustered, transmit the first cluster of one or more packets. The set of instructions may further be executable by the processor to obtain one or more parameters, wherein the one or more parameters includes modem or voice over internet protocol performance metrics, and determine the threshold number of packets for a subsequent cluster of packets based, at least in part, on the one or more parameters.

[0025] In some examples, the set of instructions may further be executable by the processor to determine a tolerant latency time for each quality of service flow, wherein determining the threshold number of packets for the subsequent cluster of packets includes determining a tolerant latency time for each quality of service flow, determining a time interval between packet clusters based on the one or more parameters, determining a dynamic time interval between packet clusters based on the tolerant latency time for each quality of service flow and the time interval between packet clusters, and selecting the threshold number of packets based on the dynamic time interval between packet clusters and an interval between packets.

[0026] In some examples, the one or more parameters includes one or more of a voice over internet protocol (VoIP) mean opinion score, signal power over noise and interference ratio, packet loss, jitter delay, packet delay budget, priority level, resource type, and the interval between packets. In some examples, the first cluster of one or more packets includes, during downlink operation, routing the first cluster of one or more packets to an application processor. In further examples, the application processor includes at least one of a voice codec or low-latency small packet application.

[0027] In some further examples, transmitting the first cluster of one or more packets includes, during uplink operation, routing the first cluster of one or more packets to a media access control layer and physical layer of an uplink dataplane for uplink transmission. In some examples, transmitting the first cluster of one or more packets further includes encoding each packet of the first cluster of one or more packets to generate respective low- latency small packets, and transmitting the low-latency small packets for uplink transmission. [0028] In some examples, the packet may be a real-time protocol packet.

[0029] In in further embodiments, a system for VPCC is provided. A system may include a downlink circuit configured to receive and decode packets received on a downlink data channel, an uplink circuit configured to receive and encode packets for transmission on an uplink data channel, and a dataplane block coupled to the downlink circuit and uplink circuit. The dataplane block may further include control logic configured to obtain, via one of the downlink circuit or an application processor, a packet for clustering, and determine whether a threshold number of packets has been clustered for a current interval. In response to determining that the threshold number of packets has not been clustered, the control logic may be configured to buffer the packet in a first cluster of one or more packets, and in response to determining that the threshold number of packets has been clustered, transmit the first cluster of one or more packets to one of the application processor or the uplink circuit. The control logic may further be configured to obtain one or more parameters, wherein the one or more parameters includes modem or voice over internet protocol performance metrics, and determine the threshold number of packets for a subsequent cluster of packets based, at least in part, on the one or more parameters.

[0030] In some examples, the control logic may further be configured to determine a tolerant latency time for each quality of service flow. Determining the threshold number of packets for the subsequent cluster of packets may further include determining a tolerant latency time for each quality of service flow, determining a time interval between packet clusters based on the one or more parameters, determining a dynamic time interval between packet clusters based on the tolerant latency time for each quality of service flow and the time interval between packet clusters, and selecting the threshold number of packets based on the dynamic time interval between packet clusters and an interval between packets.

[0031] In some examples, transmitting the first cluster of one or more packets may include, during downlink operation, routing the first cluster of one or more packets to the application processor.

[0032] In further examples, transmitting the first cluster of one or more packets includes, during uplink operation, routing the first cluster of one or more packets to a media access control layer and physical layer of an uplink dataplane for uplink transmission.

Transmitting the first cluster of one or more packets further includes encoding each packet of the first cluster of one or more packets to generate respective low-latency small packets, and transmitting the low-latency small packets for upl ink transmission.

[0033] In the following description, for the purposes of explanation, numerous details sire set forth to provide a thorough understanding of the described embodiments. It will be apparent to one skilled in the art, however, that other embodiments may be practiced without some of these details. Several embodiments are described herein, and while various features are ascribed to different embodiments, it should be appreciated that the features described with respect to one embodiment may be incorporated with other embodiments as well. By the same token, however, no single feature or features of any described embodiment should be considered essential to every embodiment of the invention, as other embodiments of the invention may omit such features.

[0034] Similarly, when an element is referred to herein as being "connected" or "coupled" to another element, it is to be understood that the elements can be directly connected to the other element, or have intervening elements present between the elements. In contrast, when an element is referred to as being "directly connected” or "directly coupled" to another element, it should be understood that no intervening elements are present in the "direct" connection between the elements. However, the existence of a direct connection does not exclude other connections, in which intervening elements may be present.

[0035] Furthermore, the methods and processes described herein may be described in a particular order for ease of description. However, it should be understood that, unless tire context dictates otherwise, intervening processes may take place before and/or after any portion of the described process, and further various procedures may be reordered, added, and/or omitted in accordance with various embodiments.

[0036] Unless otherwise indicated, all numbers used herein to express quantities, dimensions, and so forth should be understood as being modified in all instances by the term "about." In this application, the use of the singular includes the plural unless specifically stated otherwise, and use of the terms "and" and "or" means "and/or" unless otherwise indicated. Moreover, the use of the term "including," as well as other forms, such as "includes” and "included,” should be considered non-exclusive. Also, terms such as "element" or "component" encompass both elements and components comprising one unit and elements and components that comprise more than one unit, unless specifically stated otherwise.

[0037] In conventional processing of VoIP downlink packets, pulse code modulated (PCM) packets are received from the modem and sent to a voice codec on a separate chip and/or application processor for every packet. Similarly, VoIP uplink packets are sent to the modem and transmitted from the uplink air interface for every packet. This often results in inefficient use of power and hardware resources for small packet, low throughput traffic. Moreover, conventional approaches are unable to adjust resource utilization dynamically based on network conditions and throughput. [0038] Accordingly, the embodiments below set forth a more efficient, dynamic approach to processing of VoIP packets using a lightweight, VoIP Packet Clustering Control algorithm. Downlink VoIP packets may be clustered before further routing to a voice codec and/or application processor, and uplink VoIP packets may be clustered before processing by the uplink media access control / Tx PHY layers are triggered, lowering overall power consumption by user equipment.

[0039] Fig. 1 is a schematic block diagram of a system 100 for VPCC, in accordance with various embodiments. The system 100 includes a cellular baseband modem 105, which further includes several power domains, power domain A 110, power domain B 115, power domain C 120, power domain E 130, power domain D 125, power domain E 130, and power domain F 135. The cellular baseband modem 105 may further include control plane 140. The system 100 further includes a separate power domain, power domain G 145, which includes application processor 150, and voice codec and app 155. It should be noted that the various components of the system 100 are schematically illustrated in Fig. 1, and that modifications to the various components and other arrangements of system 100 may be possible and in accordance with the various embodiments.

[0040] In various embodiments, power domain A 110 of cellular baseband modem

105 may include a physical layer (PHY) circuitry and/or components (e.g., chips / integrated circuits (IC), etc.). The PHY may be a physical downlink common control channel (PDCCH) PHY, or "PHY„PDCCH." Accordingly, in some examples, power domain A 110 includes components and circuitry for operating and controlling PDCCH functions, such as in a long term evolution (LTE) and/or fifth generation (5G) new radio (NR) system. For example, the PHY JPDCCH may be configured to perform various downlink (DL) control functions, such as receiving downlink control channel signals and decoding of the downlink control indicator (DCI), which schedules downlink (DL) and/or uplink (UL) transmission grants.

[0041] In various embodiments, power domain B 115 may include a physical media access controller (PHYMAC) for physical downlink shared channel (PDSCH), or "PHYMACJPDSCH." In some examples, power domain B 115 includes components and circuitry for operating and controlling PDSCH functions. The PHYMAC ..PDSCH may, for example, be configured to control reception and decoding of the DL data channel. In some examples, decoding of protocol data units (PDIJ) up to the dataplane (DP) layer 2 (L2) is included, such that quality of service (QoS) flow or logical channel (LC) / radio bearer (RB) can be extracted for further routing.

[0042] In various embodiments, power domain C 120 may include a DP block, "Mini_DP," configured to handle small packet, real-time transfer protocol (RTP) applications. The MiniJDP may include, in one example, a controller (e.g., a microcontroller) configured to process VoIP and other low-latency, small packet data. In various examples, this may include packet processing of VoIP data, as well as low-latency loT small packets, such as in industrial loT (IToT). The MiniJDP may further include VPCC logic, configured to manage the flow of low-latency small packets. Logic, as used herein, may include, without limitation, software, hardware, or a combination of both software and hardware. For example, logic may include, without limitation, logic circuits, custom ICs, software instructions, and/or hardware for executing software instructions. Power domain C 120 may further include radio bearer queues for handling VoIP and/or other low latency data packets as clustered according to the VPCC logic.

[0043] In various embodiments, power domain D 125 includes components for uplink data transmission, including an uplink L2 DP 125a "DPL2...UL" 125a, and a physical uplink shared channel (PUSCH) PHY, or "PHYJPUSCH" 125b. In various examples, power domain D 125 is configured to prepare and transmit UL data packets. For example, DPL2..UL 125a may be configured to encode UL data packets and further perform physical layer PHY' Tx encoding. PHYJPUSCH 125b may be configured to transmit the UL packets via baseband / RF transmission.

[0044] In various examples, power domain E 130 includes a PH Y for physical uplink common control channel (PUCCH), "PHY_PUUCH" 130. In various examples, the power domain E 130 is configured to control transmission on the UL control channel, which may be activated without UL data channel. In various examples, power domain F 135 includes DL dataplane hardware (DPHW), or "DPHWJDL" 135a, and UL DPHW, or "DPHWJJL" 135b. The power domain F 135 may further include control plane 140. The power domain F 135 is configured to process packets for all normal UL and DL packets, as well as control plane 140 and platform functions. In various examples, power domain G 145 includes AP 150, and voice codec and app 155. Power domain G 145 is configured to control voice and audio codec functions, and VoIP and other application layer functions. [0045] According to some examples, during low throughput VoIP and low latency loT (e.g., IIoT small packet use cases) operation, power domains A, B, and C 110, 115, 120 may be activated (e.g., turned on) during the DL reception of small packets. During UL small packet transmissions, power domains D and E 125, 130 may be activated. Power Domain F 145 and the AP processor 150 may be disabled (e.g., turned off) or idle to save power during low throughput VoIP and low latency loT operation.

[0046] To further reduce the overall power consumption of user equipment (UE), activation of power domain G 145, including the AP 150, and voice codec and app 155, may be reduced. Specifically, during DL operation, activation of interfaces connecting the baseband cellular modem 105 to tire voice codec and app 155 may be reduced (via selective activation) and/or disabled. During UL operation, activation of the UL MAC / PHY blocks (e.g., power domain D 125) may be reduced and/or disabled.

[0047] In some embodiments, after radio resource control (RRC) is setup and connected (e.g., the logical channel (LC), RB and QoS flow identifier (QFI) flows are setup), the internet protocol (IP) multimedia subsystem (IMS) connection may then be established through session initiation protocol (SIP) signaling from the control plane 140. QFI / LC / RB may be mapped to either the MiniJDP 120 or via a normal datapath. The mapping, once established, may be sent to the PHYMACJPDSCH 1 15. PDCCH DCI may then be decoded, and PDSCH data scheduled.

[0048] Accordingly, the DL datapath may include various downlink circuits and/or components. For example, on the DL side, the PHYMAC_PDSCH 115 may be configured to decode the data channel PDU and extract the QFI or LC / RB information, and further look up QoS routing table information to determine whether to route the packet to the MiniJDP (of power domain C 120). The PHYMACJPDSCH 115 may wake the MiniJDP microcontroller (uC), and route the data PDU upwards. At the MiniJDP, small packets may be efficiently processed through the radio link control (RLC) and packet data convergence protocol (PDCP) layers, with very light functions. Specifically, low-latency small packets may include RLC unacknowledged mode (UM) unsegmented packets, with no RLC automatic repeat request (ARQ) requirements or window variables maintenance. The low- latency packet may then be robust head compression (RoHC) decompressed, and processed by the RTF layer of the MiniJDP, to produce RTF packets. [0049] The RTP packets may then be stored and clustered for later transmission to the voice codec and app 155, for example, via a buffer. Specifically, after processing of the low-latency packet, VPCC logic may be configured to determine whether the number of buffered packets (e.g., clustered RTP packets) meets a threshold number of packets. In some examples, the threshold number of packets for DL operation may be referred to as a DL cluster threshold. In some examples, the threshold number of packets may be determined based, at least in part, on one or more performance metrics. In some examples, the performance metrics may correspond to VoIP quality. For example, performance metrics may include, without limitation, a voice quality score, signal to interference and noise ratio (SINR), RTP packet loss, and RTP jitter delay, among other suitable metrics. If the number of buffered packets (e.g., clustered RTP packets) has not yet met the threshold number of packets, the processed RTP packets may be buffered. If the number of buffered packets has met the threshold number of packets, the cluster of RTP packets may be routed (e.g., transmitted) to the voice codec and app 155 for speech processing and data consumption. [0050] Similarly, the UL datapath may include various uplink circuits and components. For example, on the UL side, packets may be routed to the Mini..DP for packet processing at RTP, RoHC, and L2 layers, and queued to RB queues for UL. The RTP packets may be buffered until a threshold number of packets is met. On the UL side, the threshold number of packets may be referred to as a UL cluster threshold. Once the LIL cluster threshold is met, the UL RTP packets, such as VoIP packets or other low-latency packets, may be triggered for UL transmission. In some examples, like the DL cluster threshold, the UL cluster threshold may be determined based, at least in part, on one or more performance metrics. In some examples, upon receipt of UL grants, either dynamically from the PDCCH, or through configured grant, the UL. logical channel prioritization (LCP) process may be initiated. RTP packets may then be de-queued, prepared, and encoded (e.g., as low-latency small packets / PDU), for example, via DPL2..UL, for UL transmission.

[0051] The details of the VPCC algorithm are described in greater detail below with respect to Figs. 2-4.

[0052] Fig. 2 is a schematic block diagram of an architecture 200 for VPCC, in accordance with various embodiments. The architecture 200 includes dataplane block (Mini_DP) 205, VPCC logic 210, control plane 215, physical downlink shared channel (PHYMAC„PDSCH) 220, UL L2 DP (DPL2JJL) 225 and physical uplink shared channel (PHYJPUSCH) 230, and application processor / voice codec / app 235. It should be noted that the various components of architecture 200 are schematically illustrated in Fig. 2, and that modifications to the various components and other arrangements of harmonic block 200 may be possible and in accordance with the various embodiments.

[0053] In various embodiments, the VPCC logic 210 may be configured to run when a VoIP packet or other low- latency small packet is received at tire MiniJDP 205.

Specifically, VPCC logic 210 may be configured to dynamically determine a minimum number of packets to be clustered (e.g., a DL. cluster threshold or UL cluster threshold) before sending the low-latency small packets to the AP I voice codec / app 235 (for DL operation), and to tire UL MAC / PHY (for UL operation). Accordingly, in various examples, a dataplane block, such as Mini JDP 205, may include, for example, logic and/or circuitry configured to control the handling of low-latency, small packets, such as those used for VoIP and other real-time applications. In some examples, the dataplane block may include digital logic, software logic, microprocessors and/or controllers, and/or application specific ICs (ASICs).

[0054] In some examples, the input parameters to VPCC logic 210 may include various performance metrics and/or other parameters, including, without limitation, filtered modem and/or VoIP statistics or feedback. Thus, VPCC logic 210 may determine the DL and/or UL cluster thresholds based on the modem and/or VoIP statistics or feedback. In some examples, the performance metrics may include, without limitation, a VoIP quality mean opinion score (S_mos) from the AP / VoIP / app 235, a received signal power over noise and Interference ratio (SINR) from the PHY layer (e.g., PHYMACJPDSCH 220), packet loss (PJoss), an RTP jitter delay (Tj) from the RTF layer (e.g., from MiniJDP 205), among other suitable metrics and/or parameters.

[0055] In addition, VPCC logic 210 may further be configured to obtain QoS flow configuration information from the control plane 215 (e.g., non-access stratum (NAS) / RRC), Including a VoIP QoS profile data for each flow, such as the Priority Level, Resource Type, and Packet Delay Budget. In some examples, the VPCC logic 210 may be configured to derive a tolerant latency time (TLi) for each QoS flow, which may be used as an input to the VPCC algorithm.

[0056] Accordingly, in various embodiments, the VPCC logic may be configured to determine the cluster threshold (e.g., a DL and/or UL cluster threshold) based on the above parameters, hi some examples, a selected number of packets ( N_cluster_s) for each clustering instance (e.g., the threshold number of packets) may occur dynamically according to various input performance metrics. In other examples, the cluster threshold may be determined as a static value. In yet further examples, the cluster threshold may be determined upon request by a user (e.g., on-demand), according to a predetermined schedule, and/or periodically.

[0057] In various examples, N_cluster_s may be determined such that the number of packets per cluster are buffered within the QoS flow’s delay tolerant time (e.g., TLi), to ensure acceptable performance, such as VoIP voice quality or other desired characteristics. [0058] In various examples, a packet clustering interval (T_c luster ) may be defined as:

where T_cluster is the time interval between VoIP (or other low-latency / RTP) packet clusters, N_cluster is the number of VoIP packets in the current cluster, and Tv is the pulse code modulation (PCM) voice packet interval (e.g., 20 ms).

[0059] In various examples, T... cluster is a dynamic value which may be calculated at each cluster interval when filtered feedback input (e.g., performance metrics as described above) is received. For example, T_cluster may be determined based on the VoIP voice MOS score (S_mos), modem SINR (SINR), RTP packet loss rate (PJoss), and RTP jitter delay (Tj).

[0060] For example, in some embodiments, when network conditions are good, such that VoIP quality is good (e.g., high S_mos), received signal strength is good (e.g., high SINR), packet loss is minimal with very small jitter delay (e.g., low PJoss and Tj), the T_cluster value may be larger. In other words, the VPCC logic 210 may adjust the clustering to be more aggressive (cluster a greater number of packets) when network conditions are good and app performance (e.g., VoIP quality) is good, thereby saving power by clustering more VoIP (or other low-latency / RTP) packets together before waking and sending the packets in a bundle to the voice codec on the AP / voice codec / app 235.

[0061] Specifically, T„cluster may be determined as:

„ , .

T cluster ( ^vEq '. 21

where KI, K2, K3, and K4 are respective scaling factors for each of input parameters S..mos, SINR, PJoss, and Tj. [0062] In further embodiments, T_cluster may be dependent on a VoIP flow (e.g., a SIP call flow) QoS profile, and specifically a delay tolerance according to the QoS profile. For example, if the VoIP flow is more delay tolerant, then T„cluster may be scaled to become larger, thereby reducing waking up the voice code or AP to save power. TLi, as previously described, may be derived from the QoS profile of a VoIP flow, "i." For example, TLi may be defined and calculated as:

TLi = (K5 J x PDBi) (K6J x PRi) (K7 J x Ri) (Eq. 3)

Where PDBi is the packet delay budget for QoS flow i, PRi is the priority level for QoS flow i, Ri is the resource type for QoS flow i, and K5„i, K6„i, and K7„i are respective scaling factors for PDBi, PRi, and Ri.

[0063] In various examples, PDB may range from about 5ms - 500ms, PR may range from 1-100, (with 1 being the highest priority and 100 the lowest priority). The value of R may be defined as follows: 1 = Delay Critical Guaranteed Bit Rate (GBR), 2 = GBR, and 3 ~ Non-GBR . Thus, in some examples, TLi may be defined such that with a small delay budget (smaller PDBi), a high priority (smaller PR), and with a delay critical GBR resource type (Ri equal to 1 or 2), the TLi may decrease proportionally.

[0064] In various embodiments, based on the above determinations, to deri ve the dynamically selected T_cluster value “T_cluster_s," a minimum TLi among all QoS flows i, and the T_cluster that was scaled with filtered feedback inputs:

T_cluster_s = Min(T_cluster, TLi) (Eq. 4)

For all QoS flows i. In this way, a dynamically selected interval between packet clusters (also referred to as a dynamic interval between packet clusters) may be calculated for all QoS flows as the smallest of TLi and T_cluster for all QoS flows.

[0065] Then, the selected duster packet number for the current cluster, N_cluster_s may be derived as:

N„cluster„s = Floor [T_cluster_.s / Tv} (Eq. 5)

Where N_cluster_s is selected to meet the QoS tolerant latency requirements of all VoIP flows (e.g., the minimum TLi), and reducing power usage while still meeting acceptable performance parameters (e.g., VoIP quality or other performance metrics for low-latency applications).

[0066] The algorithmic steps for clustering based on the one or more performance metrics and/or parameters is described below with respect to Figs. 3 & 4. [0067] Fig. 3 is a functional block diagram of VoIP packet clustering control algorithm for DL packets 300, in accordance with various embodiments. Specifically, the downlink packets 300 are depicted schematically over time.

[0068] In various examples, after RRC i IMS control is established, the DL RTP packets may be processed by the receiver (Rx) PHY and DP subsystems. The number of packets to be clustered, N_cluster_s, may start with a default value of 1. For example, with a default N_cluster_s value of 1 , after DL processing, each RTP packet may be routed to the AP / voice codec immediately. The VPCC logic may subsequently determine a new N_cluster_s value for the next cluster based on new input parameters (e.g., performance metrics) as previously described.

[0069] In the example depicted, the next N_cluster_s may be dynamically updated to 2 (e.g., the RTP VoIP packet is routed to the AP / voice codec after buffering 2 RTP packets). Over the next cluster interval, the N_cluster_s may once again be dynamically updated. In the depicted example, the N_cluster_s is updated to 4 packets, based on input parameters, in this case VoIP performance metrics. During a subsequent clustering interval T_ cluster _s, the N..cluster..s is reduced to 3, based on the input parameters. In this case, the performance metrics may indicate a decrease in VoIP quality, and thus the clustering of packets reduced.

[0070] In this way, the AP/Voice Codec wakeup may be scaled dynamically and overall power consumption reduced.

[0071] Fig. 4 is a functional block diagram of VoIP packet clustering control algorithm for UL packets 400, in accordance with various embodiments. Specifically, the UL packets 400 are depicted schematically over time. In various examples, after RRC / IMS control is established, the UL. RTP packets may be processed by the transmitter (Tx) PHY and DP subsystems.

[0072] As in DL operation, during UL operation, the number of packets to be clustered, N_ciuster_s, may start with a default value of 1 . For example, with a default N_cluster_s value of 1, after UL processing, each RTP packet may be routed to the UL MAC

1 TxPHY immediately. The VPCC logic may subsequently determine a new N_cluster_.s value for the next cluster based on new input parameters as previously described.

[0073] In the example depicted, the next N_cluster_s may be dynamically updated to

2 (e.g., the RTP VoIP packet is routed to the UL MAC / TxPHY after buffering 2 RTP packets). Over the next cluster interval, the N_cluster_s may once again be dynamically updated. In the depicted example, the N_cluster _s is updated to 4 packets, based on input parameters, in this case VoIP performance metrics. During a subsequent clustering interval T_cluster_s, the N_cluster_s is again increased to 5 packets, based on the input parameters. In this case, the performance metrics may indicate VoIP quality within an acceptable range, and thus the clustering of packets may be increased .

[0074] In this way, in UL operation, the UL MAC and TxPH Y wakeup may be scaled dynamically and overall power consumption reduced.

[0075] Figs. 5 & 6 are flow diagrams illustrating a method for implementing a VPCC-based algorithm. Fig. 5 is a flow diagram of a method 500 for VPCC, in accordance with various embodiments. The method 500 begins, at block 505, by determining a tolerant latency time, TLi, for each QoS flow. As previously described, a TLi may be determined for each QoS flow (e.g., of a VoIP call or other low-latency communication session). In various examples, the TLi may be determined based, at least in part, on a QoS profile of a call flow (e.g., VoIP flow / SIP call flow). In some examples, TLi may be determined based on packet delay budget for the QoS flow, a priority level of the QoS flow, and resource type of tire QoS flow, as previously described.

[0076] The method 500 may continue, at block 510, by receiving a low latency packet. In some examples, a low-latency packet may include packets associated with a low- latency application, such as a VoIP packet or loT packet. In some examples, a UE or other user device may be configured to receive a low latency packet from another device (in DL operation). In UL operation, the Mini_DP may receive, from the AP associated with a voice codec / app, an RTF packet. In DL operation, a received PDU may first be identified as containing a low-latency packet. In UL operation, the AP may directly send an RTP packet (e.g., an encoded VoIP or loT packet).

[0077] At block 515, the method 500 may continue by generating an RTP packet. As previously described, in various examples, the low-latency packet may be VoIP or loT small packet PDU. The low-latency packet may, in some examples, include an RTP payload (e.g., RTP packet). Accordingly, as previously described, the PDU may be processed, via the MiniJDP to extract an RTP payload (e.g., RTP packet). In some examples, generating the RTP packet may include processing of the PDU through an RLC and PDCP layers, and decompressed via RoHC, and processed via an RTP layer, to generate the RTP packet. [0078] The method continues, at block 520, by determining whether a clustering threshold has been met. Specifically, in some examples, the VPCC logic may be configured to determine whether a number of clustered RTF packets is greater than or equal to the clustering threshold. As previously described, in some examples, the clustering threshold may be dynamically determined based on one or more input parameters of the VPCC logic (e.g., performance metrics). In some examples, if it is the first packet to be enqueued (e.g., buffered), a default clustering threshold may be used. In some examples, the default clustering threshold may be 1 packet. Accordingly, in some examples, determining the clustering threshold may further include, collecting the one or more parameters.

[0079] If it is determined that the clustering threshold has not been met, the RTF packet may, at block 535, be buffered (e.g., added to a buffer) in the DP (e.g., Mini„DP). If it is determined that the clustering threshold has been met, the method 500 continues, at block 525, by updating the clustering threshold based, at least in part, on the one or more input parameters of the VPCC logic. As previously described, in some examples, the clustering threshold may be determined dynamically (e.g., updated) according to one or more input parameters, which includes performance metrics as previously described. The one or more input parameters may include, without limitation, VoIP voice MOS score, modem SINR, RTP packet loss rate, and RTP jitter delay. Specifically, in some examples, a packet clustering interval, T_cluster, may be determined based on the above one or more input parameters. A dynamically selected clustering interval T_cluster_s may then be determined as a minimum (or smaller) value between T_cluster and TLi across all QoS flows, i. The clustering threshold, N_cluster_s may be determined based, for example, on a floor function of T_cluster_s / Tv (e.g., a value that does not exceed a clustering interval divided by a packet interval.

[0080] The method 500 may continue, at block 530, by routing the clustered packets to an appropriate destination. For example, in downlink operation, the RTP packet may be routed to the AP / voice codec for further processing. In UL operation, the RTP packet may be routed to an UL MAC / TxPHY for further processing and encoding into a low-latency small packet PDU. Once the clustering threshold has been updated and RTP packet routed, the method 500 may continue, at block 510, by receiving a subsequent packet for clustering. [0081] Fig. 6 is a flow diagram of an example implementation of a method 600 for VPCC, in accordance with various embodiments. The method 600 begins, at block 605, by initializing the DPL2, or dataplane layer 2, and Tx/Rx PHY layers. In various examples, initializing the DPL2 and Tx/Rx PHY layers includes initializing with default parameters, performing RRC setup, NAS connection, and QoS flow setup, as previously described. In further examples, the UL and DL DPL2 and a dataplane block, such as mini_DP previously described, may be configured with RRC and QoS parameters to perform IMS SIP call setup from a control plane.

[0082] At block 610, the method continues by determining a tolerant latency time (e.g., TLi) for each QoS flow. As previously described, a TLi may be determined for each QoS flow (e.g., of a VoIP call or other low-latency communication session). In various examples, the TLi may be determined based, at least in part, on a QoS profile of a call flow (e.g., VoIP flow / SIP call flow). In some examples, TLi may be determined based on packet delay budget for the QoS flow, a priority level of the QoS flow, and resource type of the QoS flow, as previously described.

[0083] Depending on whether a packet is a DL or UL packet, the method 600 continues with procedures for processing a VoIP packet. For example, at block 615, the method 600 continues by determining whether a DL packet is a VoIP packet. If it is determined that the DL. packet is not a VoIP packet, the packet (or PDU) may be routed, at block 620, to DL dataplane hardware (e.g., DPHW JDL) and the control plane for further processing, as known to those in the art. If it is determined, at block 615, that the DL packet (or PDU) is a VoIP packet, the method 600 may continue, at block 625, by decoding and extracting a DL RTF packet from the PDU. In some examples, the dataplane block (e.g., MiniJDP) may first be awakened, and the PDU subsequently routed to the dataplane block for DL processing. Decoding and extracting the DL RTP packet from the PDU may include, for example, deciphering, RLC, PDCP window check, and ROHC decompression, as previously described.

[0084] For UL packets, the method 600 may include, at block 630, encoding a LIL RTP packet. In some examples, an AP and/or voice codec may send UL. VoIP packets to the dataplane block (e.g., Mini_DP). Accordingly, in some examples, the MiniJDP may first be awakened and UL VoIP packets routed to the Mini.. DP for UL processing. In some examples, encoding the UL RTP packet may include RTP, ciphering, and ROHC compression of the VoIP packet, as previously described. [0085] The method 600 continues, at block 640, by determining whether a clustering threshold has been met. As previously described, in some examples, the number of RTP packets currently in a buffer may be compared to a clustering threshold (e.g., N_cluster_s). In some examples, VPCC logic may be configured to determine whether a number of clustered RTP packets is greater than or equal to the clustering threshold. As previously described, in some examples, the clustering threshold may be dynamically determined based on one or more input parameters of the VPCC logic (e.g., performance metrics). In some examples, if it is the first packet to be enqueued (e.g., buffered), a default clustering threshold may be used. In some examples, the default clustering threshold may be 1 packet. Accordingly, in some examples, determining the clustering threshold may further include, collecting the one or more parameters.

[0086] At block 645, if it is determined that the clustering threshold has not been met, the RTP packet may be buffered (e.g., added to a buffer) in the DP block (e.g., MiniJDP). If it is determined that the clustering threshold has been met, a threshold number of packets for the next cluster may be determined. Thus, the method 600 continues, at block 650, by collecting input parameters. As previously described, in some examples, the clustering threshold may be determined dynamically (e.g., updated) according to one or more input parameters, which includes performance metrics as previously described. The one or more input parameters may include, without limitation, VoIP voice MOS score (e.g., S„mos), modem SINR, RTP packet loss rate (e.g., P„loss), and RTP jitter delay (e.g., Tj).

[0087] The method 600 may continue, at block 655, by calculating a packet clustering interval, T_cluster. Specifically, in some examples, a packet clustering interval, T_cluster, may be determined based on the above one or more input parameters. At block 660, a dynamically selected clustering interval value (e.g., T_cluster_s) may be selected. For example, a dynamically selected clustering interval T_cluster_s may be determined as a minimum (e.g., a smaller) value between T_cluster and TLi across all QoS flows, i. At block 665, the clustering threshold for the next cluster (e.g., N_cluster_s) may be derived. For example, in some embodiments, N_cluster_s may be derived as a floor function of T_ cluster _s / Tv (e.g., a value that does not exceed a clustering interval divided by a packet interval. Once the clustering threshold has been updated, the method 600 may continue, at block 670, by routing the clustered RTP packets to their respective destinations. For example, in downlink operation, the RTP packet may be routed to the AP / voice codec for further processing. In UL operation, the RTP packet may be routed to an UL MAC I TxPHY for further processing and encoding into a low-latency small packet PDU.

[0088] The techniques and processes described above with respect to various embodiments may be performed by one or more computer systems. Fig. 7 is a schematic block diagram of a computer system 700 for VPCC, in accordance with various embodiments. Fig. 7 provides a schematic illustration of one embodiment of a computer system 700, such as the systems 100, 200, or subsystems thereof, which may perform the methods provided by various other embodiments, as described herein. It should be noted that Fig. 7 only provides a generalized illustration of various components, of which one or more of each may be utilized as appropriate. Fig. 7, therefore, broadly illustrates how individual system elements may be implemented in a relatively separated or relatively more integrated manner.

[0089] The computer system 700 includes multiple hardware elements that may be electrically coupled via a bus 705 (or may otherwise be in communication, as appropriate). The hardware elements may include one or more processors 710, including, wi thout limitation, one or more general-purpose processors and/or one or more special-purpose processors (such as microprocessors, digital signal processing chips, graphics acceleration processors, and microcontrollers); one or more input devices 715, which include, without limitation, a mouse, a keyboard, one or more sensors, and/or the like; and one or more output devices 720, which can include, without limitation, a display device, and/or the like.

[0090] The computer system 700 may further include (and/or be in communication with) one or more storage devices 725, which can comprise, without limitation, local and/or network accessible storage, and/or can include, without limitation, a disk drive, a drive array, an optical storage device, solid-state storage device such as a random-access memory ("RAM") and/or a read-only memory ("ROM”), which can be programmable, flash- updateable, and/or the like. Such storage devices may be configured to implement any appropriate data stores, including, without limitation, various file systems, database structures, and/or the like.

[0091] The computer system 700 might also include a communications subsystem 730, which may include, without limitation, a modem, a network card (wireless or wired), an IR communication device, a wireless communication device and/or chipset (such as a Bluetooth™ device, an 802.11 device, a WiFi device, a WiMax device, a WWAN device, a Z-Wave device, a ZigBee device, cellular communication facilities, etc.), and/or a low-power wireless device. The communications subsystem 730 may permit data to be exchanged with a network (such as the network described below, to name one example), with other computer or hardware systems, between data centers or different cloud platforms, and/or with any other devices described herein. In many embodiments, the computer system 700 further comprises a working memory 735, which can include a RAM or ROM device, as described above. [0092] The computer system 700 also may comprise software elements, shown as being currently located within the working memory 735, including an operating system 740, device drivers, executable libraries, and/or other code, such as one or more application programs 745, which may comprise computer programs provided by various embodiments, and/or may be designed to implement methods, and/or configure systems, provided by other embodiments, as described herein. Merely by way of example, one or more procedures described with respect to the method(s) discussed above might be implemented as code and/or instructions executable by a computer (and/or a processor within a computer); in an aspect, then, such code and/or instructions can be used to configure and/or adapt a general purpose computer (or other device) to perform one or more operations in accordance with the described methods.

[0093] A set of these instructions and/or code might be encoded and/or stored on a non-transitory computer readable storage medium, such as the storage device(s) 725 described above. In some cases, tire storage medium might be incorporated within a computer system, such as the system 700. In other embodiments, the storage medium might be separate from a computer system (i.e., a removable medium, such as a compact disc, etc.), and/or provided in an installation package, such that the storage medium can be used to program, configure, and/or adapt a general purpose computer with the instructions/code stored thereon. These instructions might take the form of executable code, which is executable by the computer system 700 and/or might take the form of source and/or installable code, which, upon compilation and/or installation on the computer system 700 (e.g., using any of a variety of generally available compilers, installation programs, compression/decompression utilities, etc.) then takes the form of executable code.

[0094] It will be apparent to those skilled in the art that substantial variations may be made in accordance with specific requirements. For example, customized hardware (such as programmable logic controllers, single board computers, FPGAs, ASICs, and SoCs) might also be used, and/or particular elements might be implemented in hardware, software (including portable software, such as applets, etc.), or both. Further, connection to other computing devices such as network input/output devices may be employed.

[0095] As mentioned above, in one aspect, some embodiments may employ a computer or hardware system (such as the computer system 700) to perform methods in accordance with various embodiments of the invention. According to a set of embodiments, some or all of the procedures of such methods are performed by the computer system 700 in response to processor 710 executing one or more sequences of one or more instructions (which might be incorporated into the operating system 740 and/or other code, such as an application program 745) contained in the working memory 735. Such instractions may be read into the working memory 735 from another computer readable medium, such as one or more of the storage device(s) 725. Merely by way of example, execution of the sequences of instructions contained in the working memory 735 might cause the processor(s) 710 to perform one or more procedures of the methods described herein.

[0096] The terms "machine readable medium" and "computer readable medium," as used herein, refer to any medium that participates in providing data that causes a machine to operate in a specific fashion. In an embodiment implemented using the computer system 700, various computer readable media might be involved in providing instructions/code to processors) 710 for execution and/or might be used to store and/or carry such instructions/code (e.g., as signals). In many implementations, a computer readable medium is a non-transitory, physical, and/or tangible storage medium. In some embodiments, a computer readable medium may take many forms, including, but not limited to, non-volatile media, volatile media, or the like. Non-volatile media includes, for example, optical and/or magnetic disks, such as the storage device(s) 725. Volatile media includes, without limitation, dynamic memory, such as the working memory 735. In some alternative embodiments, a computer readable medium may take the form of transmission media, which includes, without limitation, coaxial cables, copper wire and fiber optics, including the wires that comprise the bus 705, as well as the various components of the communication subsystem 730 (and/or the media by which the communications subsystem 730 provides communication with other devices). In an alternative set of embodiments, transmission media can also take the form of waves (including, without limitation, radio, acoustic, and/or light waves, such as those generated during radio-wave and infra-red data communications). [0097] Common forms of physical and/or tangible computer readable media include, for example, a floppy disk, a flexible disk, a hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read instructions and/or code.

[0098] Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to the processor(s) 710 for execution. Merely by way of example, the instractions may initially be carried on a magnetic disk and/or optical disc of a remote computer. A remote computer might load the instractions into its dynamic memory and send the instructions as signals over a transmission medium to be received and/or executed by the computer system 700. These signals, which might be in the form of electromagnetic signals, acoustic signals, optical signals, and/or the like, are all examples of carrier waves on which instructions can be encoded, in accordance with various embodiments of the invention.

[0099] The communications subsystem 730 (and/or components thereof) generally receives the signals, and the bus 705 then might cany the signals (and/or the data, instructions, etc. carried by the signals) to the working memory 735, from which the processors) 710 retrieves and executes the instructions. The instructions received by the working memory 735 may optionally be stored on a storage device 725 either before or after execution by the processor(s) 710.

[0100] While some features and aspects have been described with respect to the embodiments, one skilled in the art will recognize that numerous modifications are possible. For example, the methods and processes described herein may be implemented using hardware components, software components, and/or any combination thereof. Further, while various methods and processes described herein may be described with respect to particular structural and/or functional components for ease of description, methods provided by various embodiments are not limited to any particular structural and/or functional architecture but instead can be implemented on any suitable hardware, firmware and/or software configuration. Similarly, while some functionality is ascribed to one or more system components, unless the context dictates otherwise, this functionality can be distributed among various other system components in accordance with the several embodiments. [0101] Moreover, while the procedures of the methods and processes described herein are described in a particular order for ease of description, unless the context dictates otherwise, various procedures may be reordered, added, and/or omitted in accordance with various embodiments. Moreover, the procedures described with respect to one method or process may be incorporated within other described methods or processes; likewise, system components described according to a particular structural architecture and/or with respect to one system may be organized in alternative structural architectures and/or incorporated within other described systems. Hence, while various embodiments are described with or without some features for ease of description and to illustrate aspects of those embodiments, the various components and/or features described herein with respect to a particular embodiment can be substituted, added and/or subtracted from among other described embodiments, unless the context dictates otherwise. Consequently, although several embodiments are described above, it will be appreciated that the invention is intended to cover all modifications and equivalents within the scope of the following claims.

Claims

WHAT IS CLAIMED IS:

1. A method comprising: receiving a packet for clustering; determining whether a threshold number of packets has been clustered for a current interval; in response to determining that the threshold number of packets has not been clustered, buffering the packet in a first cluster of one or more packets; in response to determining that the threshold number of packets has been clustered, transmitting the first cluster of one or more packets; obtaining one or more parameters, wherein the one or more parameters includes modem or voice over internet protocol performance metrics: and determining tire threshold number of packets for a subsequent cluster of packets based, at least in part, on the one or more parameters.

2. The method of claim 1, further comprising: wherein determining the threshold number of packets for the subsequent cluster of packets includes: determining a tolerant latency time for each quality of service flow; determining a time interval between packet clusters based on the one or more parameters; determining a dynamic time interval between packet clusters based on the tolerant latency time for each quality of service flow and the time interval between packet clusters; and selecting the threshold number of packets based on the dynamic time interval between packet clusters and an interval between packets.

3. The method of claim 1 , wherein the one or more parameters includes one or more of a voice over internet protocol (VoIP) mean opinion score, signal power over noise and interference ratio, packet loss, jitter delay, packet delay budget, priority level, resource type, and the interval between packets.

4. The method of claim 1, wherein transmitting the first cluster of one or more packets includes, during downlink operation, routing the first cluster of one or more packets to an application processor.

5. The method of claim 4, wherein the application processor includes at least one of a voice codec or low-latency small packet application.

6. The method of claim 1, wherein transmitting the first cluster of one or more packets includes, during uplink operation, routing the first cluster of one or more packets to a media access control layer and physical layer for uplink transmission.

7. The method of claim 6, wherein transmitting the first cluster of one or more packets further comprises: encoding each packet of the first cluster of one or more packets to generate respective low-latency small packets; and transmitting the low-latency small packets to the physical layer for uplink transmission.

8. The method of claim 1 , wherein the packet is a real-time protocol packet.

9. An apparatus, comprising: a non- transitory computer readable medium in communication with the processor, the non -transitory computer readable medium having encoded thereon a set of instructions executable by the processor to: obtain a packet for clustering: determine whether a threshold number of packets has been clustered for a current interval; in response to determining that the threshold number of packets has not been clustered, buffer the packet in a first cluster of one or more packets; in response to determining that the threshold number of packets has been clustered, transmit the first cluster of one or more packets; obtain one or more parameters, wherein tire one or more parameters includes modem or voice over internet protocol performance metrics; and determine the threshold number of packets for a subsequent cluster of packets based, at least in part, on the one or more parameters.

10. The apparatus of claim 9, wherein the set of instructions is further executable by the processor to: wherein determining the threshold number of packets for the subsequent cluster of packets includes: determining a tolerant latency time for each quality of service flow; determining a time interval between packet clusters based on the one or more parameters; determining a dynamic time interval between packet clusters based on the tolerant latency time for each quality of service flow and the time interval between packet clusters; and selecting the threshold number of packets based on the dynamic time interval between packet clusters and an interval between packets.

11 . The apparatus of claim 9, wherein the one or more parameters includes one or more of a voice over internet protocol (VoIP) mean opinion score, signal power over noise and interference ratio, packet loss, jitter delay, packet delay budget, priority level, resource type, and the interval between packets.

12. The apparatus of claim 9, wherein transmitting the first cluster of one or more packets includes, during downlink operation, routing the first cluster of one or more packets to an application processor.

13. The apparatus of claim 12, wherein the application processor includes at least one of a voice codec or low-latency small packet application.

14. The apparatus of claim 9, wherein transmitting the first cluster of one or more packets includes, during uplink operation, routing the first cluster of one or more packets to a media access control layer and physical layer of an uplink dataplane for uplink transmission.

15. The apparatus of claim 14, wherein transmiting the first cluster of one or more packets further comprises: encoding each packet of the first cluster of one or more packets to generate respective low-latency small packets; and transmitting the low-latency small packets for uplink transmission.

16. The apparatus of claim 1, wherein the threshold number of packets for the subsequent cluster of packets is different from the threshold number of packets for the first cluster.

17. A system comprising: a downlink circuit configured to receive and decode packets received on a downlink data channel; an uplink circuit configured to receive and encode packets for transmission on an uplink data channel; a dataplane block coupled to the downlink circuit and uplink circuit, the dataplane block comprising control logic configured to: obtain, via one of the downlink circuit or an application processor, a packet for clustering; determine whether a threshold number of packets has been clustered for a current interval ; in response to determining that the threshold number of packets has not been clustered, buffer the packet in a first cluster of one or more packets; in response to determining that the threshold number of packets has been clustered, transmi t the first cluster of one or more packets to one of the application processor or the uplink circuit; obtain one or more parameters, wherein the one or more parameters includes modem or voice over internet protocol performance metrics; and determine the threshold number of packets for a subsequent cluster of packets based, at least in part, on the one or more parameters,

18. The system of claim 17, wherein the control logic is further configured to: wherein determining the threshold number of packets for the subsequent cluster of packets includes: determining a tolerant latency time for each quality of service flow; determining a time interval between packet clusters based on the one or more parameters; determining a dynamic time interval between packet clusters based on the tolerant latency time for each quality of service flow and the time interval between packet clusters; and selecting the threshold number of packets based on the dynamic time interval between packet clusters and an interval between packets.

19. The system of claim 17, wherein transmitting the first cluster of one or more packets includes, during downlink operation, routing the first cluster of one or more packets to the application processor.

20. The system of claim 17, wherein transmitting the first cluster of one or more packets includes, during uplink operation, routing the first cluster of one or more packets to a media access control layer and physical layer of an uplink dataplane for uplink transmission, wherein transmitting the first cluster of one or more packets further comprises: encoding each packet of the first cluster of one or more packets to generate respective low-latency small packets; and transmitting the low-latency small packets for uplink transmission.