Method for dynamically adjusting low latency mode of modem in client device, client device and storage medium

Abstract

Methods and systems for providing dynamic control of low latency mode (LLM) operation of a client device to a software application on the client device. A client device can monitor downlink data packets of a client software application operating on the client device to detect a trigger event. The client device can determine a modem operating parameter based on the detected trigger event, and dynamically adjust a low latency mode of the modem based on the detected trigger event or the determined operating parameter.

Description

[0001] Related applications

[0002] This application claims priority to U.S. Patent Application No. 17 / 120,714, filed December 14, 2020, which is incorporated herein by reference in its entirety. Background Technology

[0003] Long Term Evolution (LTE), 5G New Radio (NR), and other recently developed communication technologies allow wireless devices to transmit information at data rates several orders of magnitude higher than those available just a few years ago (e.g., in gigabits per second). Today's communication networks are also more secure, resilient to multipath fading, allow for lower network traffic latency, and offer better communication efficiency (e.g., in terms of bits per second per unit of bandwidth used). These and other recent improvements in communication technologies have facilitated the emergence of the Internet of Things (IoT), massive machine-to-machine (M2M) communication systems, vehicles, and other technologies that rely on consistent and secure wireless communication. As a result, billions of small, mobile, or resource-constrained computing devices (e.g., smartphones, watches, smart appliances, vehicles, etc.) now use Internet Protocol (IP) and cellular communication networks to transmit critical and commonplace information.

[0004] LTE, 5G NR, and other modern modems can support Low Latency Mode (LLM). When operating in LLM mode, data packets are moved to the next level without accumulation or aggregation. This reduces latency but increases the amount of power and processing resources used by the device. Some modems support multiple LLM modes, with different latency, performance, and power and consumption tradeoffs on the device. Summary of the Invention

[0005] Various aspects include methods for dynamically adjusting the low-latency mode of a modem in a client device, which may include: monitoring downlink data packets of a client software application operating on the client device to detect triggering events; determining operating parameters of the modem based on the detected triggering events; and dynamically adjusting the low-latency mode of the modem based on the determined operating parameters.

[0006] In some aspects, determining modem operating parameters based on detected trigger events may include at least one of the following: determining whether to operate the client device at a higher power level to increase the rate of delivering downlink data packets to client software applications; determining whether to process downlink data packets in the modem's hardware block without actively involving the client device's main application processor (AP) to reduce power consumption on the client device; or determining whether to aggregate downlink data packets in the modem to reduce power consumption on the client device.

[0007] In some respects, dynamically adjusting the low-latency mode of a modem based on defined operating parameters may include: invoking packet refresh at a fast time ratio, such that downlink data packets identified by the client software application are moved to the next level in the modem's protocol or processing stack without performing accumulation or aggregation operations to reduce latency on the client device, and performing accumulation or aggregation operations on the remaining downlink data packets to reduce power consumption on the client device.

[0008] In some aspects, monitoring downlink data packets of client software applications operating on client devices to detect triggering events may include: evaluating the timestamps of previously received data packets to determine whether the previously received data packets arrived early or late, and dynamically adjusting the low-latency mode of the demodulator based on determined operating parameters may include: switching between different low-latency modes with different latencies based on whether the previously received data packets arrived early or late.

[0009] In some aspects, monitoring downlink data packets of a client software application operating on a client device to detect triggering events may include: monitoring downlink data packets to determine whether the client software application is in a static or near-static state; determining modem operating parameters based on the detected triggering events may include: setting a timer in response to determining whether the client software application is in a static or near-static state; and dynamically adjusting the demodulator's low-latency mode based on the determined operating parameters may include: determining whether the timer has expired; gathering or accumulating downlink data packets in the modem in response to determining that the timer has not expired; and invoking a packet refresh in response to determining that the timer has expired, which transmits downlink data packets to the next level in the modem's protocol or processing stack without performing accumulation or gathering operations.

[0010] In some respects, monitoring downlink data packets of client software applications operating on client devices to detect triggering events includes: monitoring downlink data packets to detect transport layer timeout triggering events, detecting whether all segments corresponding to a slice arrive within a data burst, detecting whether downlink data packets arrive earlier than expected, detecting whether downlink data packets arrive later than expected, detecting download service interruption events, or detecting controller events.

[0011] In some respects, determining modem operating parameters based on detected trigger events includes determining operating parameters to balance the trade-off between meeting the immediate latency requirements of client software applications and reducing power consumption on client devices.

[0012] Some aspects may include a computing device (e.g., a client device) having memory storing processor-executable instructions and a processor configured to execute those instructions, which are configured to perform operations of any of the methods summarized above. Some aspects may include a processor for use in a computing device, having memory and configured to perform operations of any of the methods outlined above. Some aspects may include a computing device having various components with functionality for performing any of the methods outlined above. Attached Figure Description

[0013] The accompanying drawings, which are incorporated herein and form part of this specification, illustrate exemplary embodiments of the invention and, together with the general description given above and the detailed description given below, serve to explain the features of the invention.

[0014] Figure 1 This is a block diagram of a communication system illustrating network components suitable for use with various embodiments of an exemplary telecommunications system.

[0015] Figure 2 This is a component block diagram of an example computing system configured to detect and respond to unauthorized emergency messages and unauthorized jurisdictional alerts, according to an embodiment.

[0016] Figure 3 It is a component block diagram of an example software architecture that includes a radio protocol stack for the user and control planes in wireless communication.

[0017] Figures 4A-4D This is a flowchart illustrating a method for operating a base station to eliminate or reduce beam splitting according to some embodiments.

[0018] Figure 5 This is a component block diagram of an example client device suitable for implementing various embodiments. Detailed Implementation

[0019] Various embodiments will be described in detail with reference to the accompanying drawings. Throughout the drawings, the same reference numerals will be used to denote the same or similar parts whenever possible. References to specific examples and implementations are for illustrative purposes and are not intended to limit the scope of the claims.

[0020] Various embodiments include methods for providing dynamic control over low-latency mode (LLM) operation of a modem / device to a client software application, and components (e.g., a 5G modem, a client device, etc.) configured to implement the method. The modem in the client device can be configured to receive data from a server or base station and determine whether the received data is for a low-latency application. In response to determining that the received data is for a low-latency application, the modem can dynamically enter the LLM, in which the received data is delivered from the modem to the client software application without aggregation or accumulation. In some embodiments, the modem can intelligently select the LLM to balance improved performance, power consumption, latency, and / or thermal characteristics of the device.

[0021] In the future, a variety of different cellular and mobile communication services and standards may be available or anticipated, all of which can be implemented and benefit from various embodiments. Such services and standards include, for example, the 3rd Generation Partnership Project (3GPP), Long Term Evolution (LTE) systems, 3rd Generation Wireless (3G), 4th Generation Wireless (4G), 5th Generation Wireless (5G), Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), 3GSM, General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA) systems (e.g., cdmaOne, CDMA2000TM), Enhanced Data Rate Evolution of GSM (EDGE), Advanced Mobile Telephone Systems (AMPS), Digital AMPS (IS-136 / TDMA), Evolved Data Optimized (EV-DO), and Digital Enhanced Cordless Telecommunications (DECT). Each of these technologies involves the transmission and reception of, for example, voice, data, signaling, and / or content messages. It should be understood that any references to terms and / or technical details relating to individual telecommunications standards or technologies are for illustrative purposes only and are not intended to limit the scope of the claims to a particular communication system or technology, unless specifically stated in the language of the claims.

[0022] The term "client device" as used herein may refer to any or all of the following electronic devices: wireless devices, Internet of Things (IoT) devices, cellular phones, smartphones, personal or mobile multimedia players, personal data assistants (PDAs), laptops, tablets, ultrabooks, handheld computers, wireless email receivers, multimedia-enabled internet-enabled cellular phones, wireless game controllers, smart cars, connected vehicles, and similar electronic devices, which include a programmable processor, memory, and circuitry for transmitting and / or receiving wireless communication signals. While various embodiments are particularly useful in wireless devices such as smartphones and tablets, embodiments are generally useful in any electronic device that includes communication circuitry for accessing wireless Internet Protocol (IP) and data services via cellular and wireless communication networks.

[0023] The term "IP Accelerator (IPA)" is used herein to refer to a hardware block within a client device's modem. An IPA can be configured to perform data path functions and / or allow the client device to perform certain network functions (e.g., routing, filtering, network address translation, aggregation, etc.) without actively involving the client device's main application processor (AP). The data path can be the path between application layer components (e.g., client software applications, etc.) and the modem. Data path functions can be performed on uplink and downlink bits within the application layer and / or the modem's Packet Data Convergence Protocol (PDCP) layer.

[0024] The term "System-on-a-Chip" (SOC) is used herein to refer to a single integrated circuit (IC) chip containing multiple resources and / or processors integrated on a single substrate. A single SOC may contain circuitry for digital, analog, mixed-signal, and radio frequency functions. A single SOC may also include any number of general-purpose and / or special-purpose processors (digital signal processors, modem processors, video processors, etc.), memory blocks (e.g., ROM, RAM, flash memory, etc.), and resources (e.g., timers, voltage regulators, oscillators, etc.). A SOC may also include software for controlling the integrated resources and processors, as well as software for controlling peripheral devices.

[0025] The term "System-in-Package (SIP)" is used herein to refer to a single module or package containing two or more IC chips, substrates, or multiple resources, computing units, cores, and / or processors on a System-on-a-Chip (SoC). For example, a SIP may include a single substrate on which multiple IC chips or semiconductor dies are stacked in a vertical configuration. Similarly, a SIP may include one or more multi-chip modules (MCMs) on which multiple ICs or semiconductor dies are packaged into a unified substrate. A SIP may also include multiple independent SoCs coupled together via high-speed communication circuitry and packaged in very close proximity, such as on a single motherboard or in a single wireless device. Proximity of the SoCs facilitates high-speed communication and the sharing of memory and resources.

[0026] Typically, client devices receive data from servers at a regular pace. The client device's modem holds the received data (i.e., used for accumulation, probing, aggregation, etc.) for a short period before sending it to the client software application. While this latency is tolerable for most client software applications, it can be problematic for applications whose performance may be affected by delayed data reception (latency), such as extended reality (XR) and cloud gaming applications.

[0027] Modems can include multiple operating modes, including one or more Low Latency Modes (LLMs), where packets are moved to the next level in the protocol or processing stack without accumulation or aggregation. Modems can also include client software applications that allow operation and / or reception of data packets on the device to select and set the characteristics of the low latency modes for the device or application. While such low latency modes reduce latency, they may require / consume additional processing resources and / or increase power consumption on the device. For example, a low latency operating mode may require the modem to operate at a higher frequency to process tasks faster (e.g., measured in millions of instructions per second (MIPS), which may drain the mobile device's battery or increase the power consumption characteristics of the client device. To better balance latency, performance, and power consumption, some modems allow client software applications to select one of several different low latency modes, each achieving a different balance and / or achieving different equilibrium points between latency, performance, and power consumption.

[0028] Using traditional solutions, client devices or modems that enter low-latency mode will continue to operate in that mode regardless of packet latency, whether the modem continues to achieve an appropriate balance between latency, performance, and power consumption, and / or whether low-latency mode operation continues to be effective or beneficial. This can lead to unnecessary power consumption in client devices. For example, the impact of data packet latency on user experience can vary significantly throughout a game (e.g., explosions require low latency, while near-static scenes do not). Thus, game applications that select a particular low-latency mode may fail to achieve the correct balance between latency and power consumption for some tasks (e.g., explosions during gameplay), wasting device processing power or battery resources used for other tasks (e.g., rendering near static scenes).

[0029] Various embodiments overcome the limitations of conventional solutions by configuring modems (e.g., 5G modems) to dynamically implement or adjust low-latency modes based on various application conditions through application-based dynamic configuration of their IPA and data path parameters. Thus, a modem configured according to embodiments can transmit packets with low latency for some tasks or parts of an application's execution (e.g., when a game is fast-paced or actions require large amounts of data downloads), and transmit packets in a power-efficient manner for other tasks or parts of the application's execution (e.g., during static or slower-moving parts of a game).

[0030] Modems can be configured to allow client software applications (i.e., applications that use data) to use application-layer or transport-layer triggers (e.g., real-time transport protocol layer trigger events) to determine whether to enter a low-latency mode and / or to determine operational parameters that balance latency, performance, and power consumption on the device. For example, client software applications can use trigger events to determine whether downlink data packets should be delivered faster at higher power consumption, whether downlink data packets may undergo IPA and data path aggregation / accumulation on the modem to reduce power consumption on the client device, and / or whether there are static conditions that allow data packets to be aggregated to achieve even greater power consumption reductions on the client device.

[0031] In response to a client software application determining that downlink data packets should be delivered faster with higher power consumption, the client software application may frequently or use a rapid time scale (e.g., every 1-100 milliseconds) to invoke packet "refresh". Only packets indicated by the client software application are moved to the next layer in the protocol or processing stack without performing accumulation or aggregation operations. All other packets are accumulated or aggregated to reduce power consumption on the device.

[0032] In response to the client software application determining that downlink data packets may have to pass through the IPA and data path aggregation / accumulation on the modem, or in response to determining that packets may be delivered less frequently or at a slower time scale (e.g., every 100 ms, 1 second, 3 seconds, etc.), the client software application may switch between different low-latency modes with different latency based on how long or early past packets were received.

[0033] In response to the client software application determining that static conditions exist that allow data packets to be aggregated, or that the current conditions are nearly static (e.g., a pause in action or a near-still image lasting for several seconds or minutes), the client software application can configure frame or slice timeouts associated with events at the modem (e.g., first packet rx, last packet rx). In response, the modem can aggregate packets of a frame (or slice). The modem can start a timer in response to determining that an event has occurred. Upon detecting a timer timeout or expiration, the client software application can invoke a packet "refresh," causing the packets to be refreshed to the application layer and / or causing the packets to be accumulated / aggregated to improve the power consumption characteristics of the client device.

[0034] In some embodiments, the client software application can be configured to dynamically determine operating parameters, dynamically select a low-latency mode, and / or dynamically control low-latency mode operation in order to balance the immediate latency requirements of the client software application with reducing power consumption on the client device.

[0035] In various embodiments, the client software application can be configured to use detected application layer or transport layer trigger events to determine operating parameters (i.e., values ​​that achieve a proper balance between latency, performance, and power consumption on the device). Triggers can be event-driven procedures, messages, or information structures that include trigger definitions. Trigger definitions can identify or define one or more trigger events. The term "trigger event" is used herein to refer to an event or condition defined in a trigger definition that causes the client device to perform Low Latency Mode (LLM) related actions. Specifically, in response to the detection of a trigger event, the client device can determine the modem's operating parameters based on the detected trigger event and then dynamically adjust the demodulator's low latency mode based on the determined operating parameters. Non-limiting examples of trigger events include transport layer timeouts, detection that not all segments corresponding to a slice have arrived within a data burst, determination that packets arrived earlier or later than expected, detection of short circuits / interruptions in a download service, detection that not all segments corresponding to a slice have been received or not included in a received data burst, detection of short circuits / interruptions in a download service, detection of controller events such as button press events, etc. Trigger definitions may also include the payload or content of the triggering event (e.g., a software application), information identifying the destination to which the payload / content is to be sent, and / or trigger type information.

[0036] In some embodiments, the client software application may be configured to dynamically select a low-latency mode and / or dynamically control low-latency mode operation based on triggering events / conditions and / or based on the nature of controller events or their mappings. The triggering events / conditions may include the client device detecting triggering events such as transport layer timeouts, determining that not all segments corresponding to slices arrive within a data burst, determining that packets arrive earlier or later than expected, or detecting short circuits / interruptions in the download service.

[0037] In some embodiments, the triggering event / condition can be based on a transport layer timeout. Client software applications may use transport layer submodules or sublayers, such as the Reliable User Datagram Protocol (RUDP) transport layer, to meet strict reliability and latency constraints. RUDP layer components typically request the retransmission of lost packets. After a pre-programmed timeout, the RUDP layer component can acknowledge any or all packets that have not yet arrived at the socket (e.g., up to a certain sequence number, etc.). Before such a timeout, the RUDP layer component can determine or select a low-latency mode for immediately releasing packets accumulated in the IPA. That is, packets accumulated in the IPA are not marked as lost (from the socket's perspective), which can improve the latency characteristics of the client device and / or client software application.

[0038] In some embodiments, the triggering event may be based on the determination that not all segments corresponding to a slice have arrived within the data burst in the Real-Time Transport Protocol (RTP) layer. That is, the RTP layer components may be configured to examine the packet header and determine whether all segments corresponding to a slice are included in the received data burst. In response to the triggering event determining where all segments corresponding to a slice have not yet arrived or are not included in the received data burst, the client device may determine or select a low-latency mode for immediately releasing discrete segments (i.e., segments that have not yet arrived), allowing the client device to begin performing data decoding operations. This can improve the latency characteristics of the client device and / or client software applications.

[0039] In some embodiments, triggering events / conditions can be based on whether a packet is received early or late. For example, a client device can compare the RTP timestamps of packets to determine whether a packet is early or late, and dynamically implement or adjust a low-latency mode based on whether a packet is received early or late. In some embodiments, a client device can be configured to read the RTP timestamp of each packet as an absolute value. If the local clock offset relative to the source clock is known, the client device can determine whether a packet is early based on the absolute RTP timestamp of that packet. The client device can implement or adjust a low-latency mode and / or improve the latency characteristics of the client device and / or client software applications based on whether a packet is received early.

[0040] In some embodiments, the triggering event / condition may be based on the presence of a short circuit / interruption in the download service. A brief interruption / interruption in the download service can indicate to the client device that a burst of accumulated packets may arrive soon. Thus, in response to detecting a short circuit / interruption in the download service, the client device or client software application can trigger a low-latency mode to move to the next I-frame in the sequence to prevent error propagation. The client device can continue to trigger low-latency mode (or continue operating in low-latency mode) until an I-frame is received.

[0041] In some embodiments, the triggering event / condition may be based on the nature of controller events and / or their mapping. A client device or client software application may trigger a low-latency mode in response to the client software application detecting a button press (which is a controller event), enabling the action associated with the button press event (e.g., simulated shooting in a game application) to be received, processed, presented, or rendered with low latency.

[0042] Figure 1 An example of a communication system 150 suitable for implementing various implementations is illustrated. The communication system 150 can be a 5G NR network, or any other suitable network, such as an LTE network.

[0043] Communication system 150 may include a heterogeneous network architecture, which includes communication network 140 and various client devices (in... Figure 1 The communication system 150 may also include multiple base stations (illustrated as BS 104a, BS 104b, BS 104c, and BS 104d) and other network entities. A base station is an entity that communicates with client devices (mobile devices) and may also be referred to as a NodeB, Node B, LTE Evolution NodeB (eNB), Access Point (AP), Radio Headend, Transmit / Receive Point (TRP), New Radio Base Station (NR BS), 5G NodeB (NB), Next Generation NodeB (gNB), etc. Each base station can provide communication coverage for a specific geographic area. In 3GPP, the term "cell" can refer to the coverage area of ​​a base station, a base station subsystem serving that coverage area, or a combination thereof, depending on the context in which the term is used. For ease of reference, the term "base station" is used herein to refer to any of the communication nodes in a wireless communication network, including, for example, eNB, NR BS, gNB, TRP, AP, Node B, 5G NB, client equipment (CPE), integrated access backhaul (IAB) nodes, and other communication nodes that establish a wireless communication "cell".

[0044] Base stations 104a-104d can provide communication coverage for macrocells, picocells, femtocells, another type of cell, or a combination thereof. A macrocell can cover a relatively large geographic area (e.g., a radius of several kilometers) and can allow unrestricted access for client devices with service subscriptions. A picocell can cover a relatively small geographic area and can allow unrestricted access for client devices with service subscriptions. A femtocell can cover a relatively small geographic area (e.g., a home) and can allow restricted access for client devices associated with that femtocell (e.g., client devices in a Closed Subscriber Group (CSG)). A base station for a macrocell can be referred to as a macro BS. A base station for a picocell can be referred to as a pico BS. A base station for a femtocell can be referred to as a femtocell BS or a home BS. Figure 1 In the example illustrated, base station 104a can be a macro BS for macro cell 152a, base station 104b can be a pico BS for pico cell 152b, and base station 104c can be a femto BS for femto cell 152c. Base stations 104a-104d can support one or more (e.g., three) cells.

[0045] In some examples, the cell may not be fixed, and the geographical area of ​​the cell may move depending on the location of the mobile base station. In some examples, base stations 104a-104d may interconnect with each other and with one or more other base stations or network nodes (not shown) in the communication system 150 using any suitable transport network through various types of backhaul interfaces (such as direct physical connections, virtual networks, or combinations thereof).

[0046] The communication system 150 may also include relay stations (such as relay BS 104d). A relay station is an entity that can receive data transmissions from an upstream station (e.g., a base station or client equipment) and transmit data transmissions to a downstream station (e.g., a client equipment or base station). A relay station may also be a client device capable of relaying transmissions used by other client devices. Figure 1 In the example shown, relay station 104d can communicate with macro base station 104a and client device 102d to facilitate communication between macro base station 104a and client device 102d. A relay station can also be referred to as a relay base station, relay, etc.

[0047] The communication system 150 can be a heterogeneous network comprising different types of base stations, such as macro base stations, pico base stations, femto base stations, relay base stations, etc. These different types of base stations can have different transmit power levels, different coverage areas, and different impacts on interference within the communication system 150. For example, macro base stations can have high transmit power levels (e.g., 5 to 40 watts), while pico base stations, femto base stations, and relay base stations can have lower transmit power levels (e.g., 0.1 to 2 watts).

[0048] Network controller 130 can be coupled to a group of base stations and can provide coordination and control for these base stations. Network controller 130 can communicate with the base stations via backhaul. The base stations can also communicate with each other directly or indirectly, for example, via wireless or wired backhaul.

[0049] Client devices 102a, 102b, and 102c may be distributed throughout the communication system 150, and each client device may be fixed or mobile. Client devices may also be referred to as access terminals, terminals, mobile stations, subscriber units, stations, etc. Client devices 102a, 102b, and 102c may be cellular phones (e.g., smartphones), personal digital assistants (PDAs), wireless modems, wireless communication devices, handheld devices, laptop computers, cordless phones, wireless local loop (WLL) stations, tablet computers, cameras, gaming devices, netbooks, smartbooks, ultrabooks, medical devices or equipment, biometric sensors / devices, wearable devices (smartwatches, smart clothing, smart glasses, smart wristbands, smart jewelry (e.g., smart rings, smart bracelets)), entertainment devices (e.g., music or video devices, or satellite radios), vehicle components or sensors, smart meters / sensors, industrial manufacturing equipment, GPS devices, or any other suitable device configured to communicate via wireless or wired media.

[0050] Macro base station 104a can communicate with communication network 140 via wired or wireless communication link 126. Client devices 102a, 102b, and 102c can communicate with base stations 104a-104d via wireless communication link 122.

[0051] The wired communication link 126 can use various wired networks (such as Ethernet, TV cable, telephone, fiber optic and other forms of physical network connection) that can use one or more wired communication protocols, such as Ethernet, point-to-point protocol, advanced data link control (HDLC), advanced data communication control protocol (ADCCP) and transmission control protocol / Internet protocol (TCP / IP).

[0052] Wireless communication links 122 and 124 may include multiple carrier signals, frequencies, or frequency bands, each of which may include multiple logical channels. The wireless communication links may utilize one or more radio access technologies (RATs). Examples of RATs that can be used in wireless communication links include 3GPP LTE, 3G, 4G, 5G (such as NR), GSM, Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Global System for Mobile Communications (WiMAX), Time Division Multiple Access (TDMA), and other cellular RATs for mobile phone communication technologies. Further examples of RATs that can be used in one or more of the various wireless communication links within the communication system 150 include mid-range protocols such as Wi-Fi, LTE-U, LTE-Direct, LAA, and MuLTEfire, and relatively short-range RATs such as ZigBee, Bluetooth, and Bluetooth Low Energy (LE).

[0053] Some wireless networks (such as LTE) utilize Orthogonal Frequency Division Multiplexing (OFDM) on the downlink and Single-Carrier Frequency Division Multiplexing (SC-FDM) on the uplink. OFDM and SC-FDM divide the system bandwidth into multiple (K) orthogonal subcarriers, often referred to as tones, bins, etc. Each subcarrier can be modulated with data. Typically, modulation symbols are transmitted using OFDM in the frequency domain and SC-FDM in the time domain. The spacing between adjacent subcarriers can be fixed, and the total number of subcarriers (K) can depend on the system bandwidth. For example, the subcarrier spacing could be 15 kHz, and the minimum resource allocation (called a "resource block") could be 12 subcarriers (or 180 kHz). Therefore, for system bandwidths of 1.25, 2.5, 5, 10, or 20 MHz, the Fast Fourier Transform (FFT) size could be 128, 256, 512, 1024, or 2048, respectively. System bandwidth can also be divided into subbands. For example, a subband can cover 1.08 MHz (i.e., 6 resource blocks), and there can be 1, 2, 4, 8, or 16 subbands for system bandwidths of 1.25, 2.5, 5, 10, or 20 MHz, respectively.

[0054] While descriptions of some implementations may use terminology and examples associated with LTE technology, some implementations may be applicable to other wireless communication systems, such as New Radio (NR) or 5G networks. NR can utilize OFDM with a cyclic prefix (CP) on both the uplink (UL) and downlink (DL) and includes support for half-duplex operation using Time Division Duplex (TDD). A single component carrier bandwidth of 100 MHz can be supported. An NR resource block can span 12 subcarriers with a subcarrier bandwidth of 75 kHz over a duration of 0.1 milliseconds (ms). Each radio frame can include 50 subframes of 10 ms in length. Therefore, each subframe can have a length of 0.2 ms. Each subframe can indicate the link direction for data transmission (i.e., DL or UL), and the link direction of each subframe can be dynamically switched. Each subframe can include DL / UL data as well as DL / UL control data. Beamforming can be supported, and beam direction can be dynamically configured. Precoded multiple-input multiple-output (MIMO) transmission can also be supported. MIMO configurations in DL can support up to eight transmit antennas, with up to eight streams in multi-layer DL transmission and up to two streams per client device. Multi-layer transmission with up to two streams per client device is possible. Up to eight serving cells can be used to support aggregation of multiple cells. Alternatively, NR can support different air interfaces in addition to OFDM-based interfaces.

[0055] Some client devices can be considered Machine-Type Communication (MTC) or Evolved or Enhanced Machine-Type Communication (eMTC) client devices. MTC and eMTC client devices include, for example, robots, remote devices, sensors, meters, monitors, location tags, etc., which can communicate with a base station, another device (e.g., a remote device), or some other entity. Wireless nodes can, for example, provide connectivity to or to a network (e.g., a wide area network, such as the Internet or a cellular network) via wired or wireless communication links. Some client devices can be considered Internet of Things (IoT) devices, or can be implemented as NB-IoT (Narrowband Internet of Things) devices. Client devices 102a-102e can be included within a housing that houses the components of client devices 102a-102e, such as processor components, memory components, similar components, or combinations thereof.

[0056] Typically, any number of communication systems and wireless networks can be deployed within a given geographical area. Each communication system and wireless network can support a specific Radio Access Technology (RAT) and can operate on one or more frequencies. RAT can also be referred to as radio technology, air interface, etc. Frequency can also be referred to as carrier, frequency channel, etc. Each frequency can support a single RAT within a given geographical area to avoid interference between communication systems using different RATs. In some cases, NR or 5G RAT networks can be deployed.

[0057] Access to the air interface can be scheduled, where a scheduling entity (e.g., a base station) allocates resources for communication between some or all devices and equipment within the scheduling entity's service area or cell. The scheduling entity can be responsible for scheduling, allocating, reconfiguring, and releasing resources for one or more subordinate entities. That is, for scheduled communication, subordinate entities utilize the resources allocated by the scheduling entity.

[0058] In some implementations, two or more client devices 102a-102e (e.g., shown as client device 102a and client device 102e) can communicate directly using one or more sidelink channels 124 (e.g., without using base stations 104a-d as intermediaries to communicate with each other). For example, client devices 102a-120e can communicate using peer-to-peer (P2P) communication, device-to-device (D2D) communication, vehicle-to-everything (V2X) protocols (which may include vehicle-to-vehicle (V2V) protocols, vehicle-to-infrastructure (V2I) protocols, or similar protocols), mesh networks or similar networks, or combinations thereof. In this case, client devices 102a-120e can perform scheduling operations, resource selection operations, and other operations described elsewhere herein as being performed by base stations 104a-d.

[0059] To establish communication with base stations 104a-d, client devices 102a-102e may attempt to obtain SI from base stations 104a-d. SI may be provided in one or more system information blocks, such as a main information block (MIB) and one or more system information blocks (SIBs). SI provides timing and structure information that enables client devices 102a-102e to receive and decode further information from base stations 104a-d. This information allows client devices 102a-102e to, for example, access communication, perform cell access, execute cell reselection, intra-frequency, inter-frequency, and RAT inter-cell selection processes, and perform other operations via base stations 104a-d.

[0060] In 5G NR, base stations broadcast certain system information, such as MIB and SIB1 messages. In some implementations, additional SIs may also be broadcast. However, in some implementations, additional SIs (such as on-demand SIs) may be sent by the base station in response to a request for additional SIs (such as a request for on-demand SIs). In some implementations, broadcasting SIs (i.e., MIB or SIB1 messages) may include scheduling information to enable client devices 102a-102e to request and receive on-demand system information.

[0061] When client devices 102a-102e are powered on, they can perform cell search and acquire one or more synchronization signals (such as the primary synchronization signal (PSS) and secondary synchronization signal (SSS)) and physical broadcast channel (PBCH) from base stations 104a-d. Using the synchronization signals(s) and information from the PBCH, client devices 102a-102e can receive, decode, and store (multiple) MIB messages from base stations 104a-d. Using parameters from the decoded MIBs, client devices 102a-102e can receive and decode SIB1 messages. In some implementations, the SIB1 message may indicate that base stations 104a-d are configured to provide one or more on-demand SI messages. To acquire such on-demand SI messages, client devices 102a-102e may send a request for one or more on-demand SI messages to base stations 104a-d. In some implementations, sending a request for one or more on-demand messages may be part of a random access channel (RACH) request procedure.

[0062] Figure 2 The illustration shows an example computing system or SIP200 architecture that can be used in client devices with various implementations.

[0063] refer to Figure 1 and Figure 2The illustrated example SIP 200 includes two SOCs 202 and 204, a clock 206, a voltage regulator 208, and a wireless transceiver 266 configured to send and receive wireless communications to / from a client device such as base station 104a via an antenna (not shown). In some implementations, the first SOC 202 operates as the central processing unit (CPU) of the client device implementing software application instructions by performing arithmetic, logic, control, and input / output (I / O) operations specified by instructions. In some implementations, the second SOC 204 may operate as a dedicated processing unit. For example, the second SOC 204 may act as a dedicated 5G processing unit responsible for managing high-capacity, high-speed (such as 5 Gbps) or very high frequency short-wavelength (such as 28 GHz mmWave spectrum) communications.

[0064] The first SOC 202 may include a digital signal processor (DSP) 210, a modem processor 212, a graphics processor 214, an application processor 216, one or more coprocessors 218 (such as vector coprocessors) connected to one or more of the processors, memory 220, custom circuitry 222, system components and resources 224, an interconnect / bus module 226, one or more temperature sensors 230, a thermal management unit 232, and a thermal power envelope (TPE) component 234. The second SOC 204 may include a 5G modem processor 252, a power management unit 254, an interconnect / bus module 264, multiple millimeter-wave transceivers 256, memory 258, and various additional processors 260, such as application processors, packet processors, etc.

[0065] Each processor 210, 212, 214, 216, 218, 252, 260 may include one or more cores, and each processor / core may perform operations independently of the other processors / cores. For example, the first SOC 202 may include a processor running a first type of operating system (such as FreeBSD, LINUX, OS X, etc.) and a processor running a second type of operating system (such as Microsoft WINDOWS 10). Furthermore, any or all of processors 210, 212, 214, 216, 218, 252, 260 may be included as part of a processor cluster architecture (such as a synchronous processor cluster architecture, an asynchronous or heterogeneous processor cluster architecture, etc.).

[0066] The first SOC 202 and the second SOC 204 may include various system components, resources, and custom circuitry for managing sensor data, analog-to-digital conversion, wireless data transmission, and performing other specialized operations, such as decoding data packets and processing encoded audio and video signals for rendering in a web browser. For example, the system components and resources 224 of the first SOC 202 may include power amplifiers, voltage regulators, oscillators, phase-locked loops, peripheral bridges, data controllers, memory controllers, system controllers, access ports, timers, and other similar components to support processors and software clients running on client devices. System components and resources 224 or custom circuitry 222 may also include circuitry for interfacing with peripheral devices such as cameras, electronic displays, wireless communication devices, external memory chips, etc.

[0067] The first SOC 202 and the second SOC 204 can communicate via interconnect / bus module 250. Various processors 210, 212, 214, 216, and 218 can be interconnected via interconnect / bus module 226 to one or more memory elements 220, system components and resources 224, as well as custom circuitry 222 and thermal management unit 232. Similarly, processor 252 can be interconnected via interconnect / bus module 264 to power management unit 254, millimeter-wave transceiver 256, memory 258, and various additional processors 260. Interconnect / bus modules 226, 250, and 264 may include reconfigurable logic gate arrays or implement bus architectures such as CoreConnect, AMBA, etc. Communication can be provided via advanced interconnects such as on-chip high-performance networks (NoCs).

[0068] The first SOC 202 and the second SOC 204 may also include input / output modules (not shown) for communicating with external resources such as clock 206 and voltage regulator 208. External resources such as clock 206 and voltage regulator 208 may be shared by two or more internal SOC processors / cores.

[0069] In addition to the example SIP 200 discussed above, some implementations can be implemented in a variety of computing systems, which may include a single processor, multiple processors, multi-core processors, or any combination thereof.

[0070] Figure 3 An example of software architecture 300 is illustrated, which includes a wireless protocol stack for the user and control planes in wireless communication between base station 350 (such as base station 104a) and client devices 320 (such as client devices 102a-102e, 200). Reference Figure 1A-3, Client device 320 may implement software architecture 300 to communicate with base station 350 of a communication system (such as 100). In various implementations, layers in software architecture 300 may form logical connections with corresponding layers in the software of base station 350. Software architecture 300 may be distributed across one or more processors (such as processors 212, 214, 216, 218, 252, 260). Although a single radio protocol stack has been described, in a multi-SIM (Subscriber Identity Module) client device, software architecture 300 may include multiple protocol stacks, each of which may be associated with a different Subscriber Identity Module (SIM) (such as two protocol stacks associated with two SIMs respectively in a dual-SIM wireless communication device). Although described below with reference to the LTE communication layer, software architecture 300 may support any of the various standards and protocols used for wireless communication, or may include additional protocol stacks supporting any of the various standards and protocols for wireless communication.

[0071] Software architecture 300 may include a Non-Access Layer (NAS) 302 and an Access Layer (AS) 304. NAS 302 may include functions and protocols for supporting packet filtering, security management, mobility control, session management, and services and signaling between client devices (such as (multiple) SIMs 204) and their core network. AS 304 may include functions and protocols for supporting communication between (multiple) SIMs (such as (multiple) SIMs 204) and entities (such as base stations) of the supported access network. In particular, AS 304 may include at least three layers (Layer 1, Layer 2, and Layer 3), each layer may include various sublayers.

[0072] In the user and control planes, Layer 1 (L1) of AS 304 can be Physical Layer (PHY) 306, which oversees the functions that enable transmission or reception over the air interface. Examples of such Physical Layer 306 functions may include Cyclic Redundancy Check (CRC) appending, decoding blocks, scrambling and descrambling, modulation and demodulation, signal measurement, MIMO, etc. The Physical Layer may include various logical channels, including the Physical Downlink Control Channel (PDCCH) and the Physical Downlink Shared Channel (PDSCH).

[0073] In the user and control plane, Layer 2 (L2) of AS 304 is responsible for the link between client device 320 and base station 350 on physical layer 306. In various implementations, Layer 2 may include a Media Access Control (MAC) sublayer 308, a Radio Link Control (RLC) sublayer 310, and a Packet Data Convergence Protocol (PDCP) sublayer 312, each of which forms a logical connection that terminates at base station 350.

[0074] In the control plane, Layer 3 (L3) of AS 304 may include a Radio Resource Control (RRC) sublayer 3. Although not shown, software architecture 300 may include additional Layer 3 sublayers, as well as various upper layers above Layer 3. In various implementations, RRC sublayer 313 may provide functions including broadcasting system information, paging, and establishing and releasing RRC signaling connections between client device 320 and base station 350.

[0075] In various implementations, PDCP sublayer 312 can provide uplink functions, including multiplexing between different radio bearers and logical channels, sequence numbering, handover data processing, integrity protection, encryption, and header compression. In the downlink, PDCP sublayer 312 can provide functions including data packet ordering, duplicate data packet detection, integrity verification, decryption, and header decompression.

[0076] In the uplink, RLC sublayer 310 can provide segmentation and concatenation of upper-layer data packets, retransmission of lost data packets, and Automatic Repeat Request (ARQ). In the downlink, the functions of RLC sublayer 310 can include reordering data packets to compensate for out-of-order reception, reassembly of upper-layer data packets, and ARQ.

[0077] In the uplink, MAC sublayer 308 can provide functions including multiplexing between logical and transport channels, random access procedures, logical channel prioritization, and hybrid ARQ (HARQ) operations. In the downlink, MAC layer functions can include intra-cell channel mapping, demultiplexing, discontinuous reception (DRX), and HARQ operations.

[0078] While the software architecture 300 provides the ability to transmit data over a physical medium, it may also include at least one host layer 314 to provide data transmission services to various applications in the client device 320. In some implementations, application-specific functions provided by at least one host layer 314 may provide an interface between the software architecture and the general-purpose processor 206.

[0079] In other implementations, software architecture 300 may include one or more higher logical layers (such as transport, session, presentation, application, etc.) that provide host-level functionality. For example, in some implementations, software architecture 300 may include a network layer (such as the IP layer), where logical connections terminate at a packet data network (PDN) gateway (PGW). In some implementations, software architecture 300 may include an application layer, where logical connections terminate at another device (such as an end-user device, server, etc.). In some implementations, software architecture 300 may also include a hardware interface 316 in AS 304 between physical layer 306 and communication hardware (such as one or more radio frequency transceivers).

[0080] In some embodiments, the protocol stack of a client device may include a physical layer module, a data link layer module, a network layer module, a transport layer module, and an application layer module, each of which may be implemented in hardware, software, or a combination of hardware and software. Furthermore, each of these layers may include a sublayer, which may also be implemented in hardware, software, or a combination of hardware and software.

[0081] The physical layer module may include radio components configured to receive basic communication signals, extract data from the communication signals, and provide the data to a media transport stream (e.g., an MPEG-2 transport stream) or a media access control module in the data link layer module. The data link layer module can provide addressing and channel access control mechanisms, enabling various components of the client device to receive different data streams. The data link layer module may also include various submodules or sublayers for carrying packet protocols (e.g., Internet Protocol) over a Moving Picture Experts Group (MPEG) transport stream (TS), such as a Multiprotocol Encapsulation Forward Error Correction (MPE-FEC) module / layer and a Program and System Information (SI / PSI) module / layer.

[0082] A portion of the stream / signal carrying content and information can be passed from the data link layer module to the network layer module, which may include an IP module / interface for relaying streams, datagrams, and / or packet communications to the transport layer module. Streams and data received in the transport layer module can be delivered to appropriate transport layer submodules or sublayers, which process and encapsulate the data for transmission. Such transport layer submodules / sublayers may include User Datagram Protocol (UDP) modules / layers, Asynchronous Layered Coding / Layered Coding Transport (ALC / LCT) modules / layers, Real-Time Transport Protocol (RTP) modules / layers, and File Delivery over One-Way Transport (FLUTE) modules / layers. In one embodiment, the RTP module / layer may be included in or as part of the application layer, similar to the Dynamic Adaptive Streaming (DASH) format over Hypertext Transfer Protocol (HTTP).

[0083] Application layer modules may include protocols and methods required to establish host-to-host, end-to-end connections, and process-to-process communication. Application layer modules may also include end-user applications (e.g., media players) for processing, reproducing, and / or displaying received content on a mobile receiver device. The application layer may also include media formats such as DASH format, encoded media streams and other media-related metadata, RTP modules, and media player modules.

[0084] Figure 4A The illustration shows a method 400, which, according to some embodiments, can be executed by a processor of a client device to dynamically implement or adjust a low-latency mode. Figure 4B ,4C The diagram illustrates alternative operations in methods 410, 420, and 430, which may be performed as part of method 400 in some embodiments. The operations of methods 400, 410, 420, and 430 are intended to be illustrative. In some embodiments, methods 400, 410, 420, and 430 may be performed using one or more additional operations not described and / or without one or more of the operations discussed.

[0085] refer to Figure 1-4D Methods 400, 410, 420, and 430 may be implemented in one or more processors (e.g., 202, 204, 210, 212, 214, 216, 218, 252, 260) of a client device configured with processor-executable instructions stored on a non-transitory processor-readable storage medium. The processing system may include one or more processors (e.g., 202, 204, 210, 212, 214, 216, 218, 252, 260) configured by hardware, firmware, and / or software stored in memory (e.g., 220, 258, 325).

[0086] Figure 4A The illustration depicts a method 400 for dynamically adjusting a low-latency mode according to some embodiments. In block 402, a client device processor can monitor downlink data packets of a client software application operating on the client device to detect triggering events. Triggering events may include: the client device detecting a transport layer timeout, the client device determining that not all segments corresponding to a slice have arrived within the data burst, the client device determining that packets have arrived earlier or later than expected, the client device detecting a short circuit / interruption in the download service, and / or based on the presence, nature of the client device detection or controller event, or their mapping.

[0087] In block 404, the client device processor can determine modem operating parameters based on detected trigger events. In some embodiments, the processor can determine operating parameters that balance latency, performance, and power consumption on the device. In some embodiments, the client software application can use triggers to determine whether downlink data packets should be transmitted faster at higher power consumption, whether downlink data packets may be subject to IPA and data path aggregation / accumulation on the modem to reduce power consumption on the client device, and / or whether there are static conditions that allow data packets to be aggregated to achieve even greater power consumption reduction on the client device.

[0088] In block 406, the client device processor can dynamically adjust the low-latency mode of the demodulator based on determined operating parameters and / or based on detected trigger events. In some embodiments, the client device processor can invoke packet refresh at a fast time ratio, such that downlink data packets identified by the client software application are moved to the next level in the modem's protocol or processing stack without performing accumulation or aggregation operations to reduce latency on the client device, and accumulation or aggregation operations are performed on the remaining downlink data packets to reduce power consumption on the client device. In some embodiments, the client device processor can switch between different low-latency modes with different latency based on the device's operating conditions (or the current task performed by the client software application) to achieve a balance between latency, performance, and power consumption on the device.

[0089] Figure 4B The illustration depicts a method 410 for dynamically adjusting a low-latency mode according to an embodiment. In some embodiments, method 410 may be performed as part of the operations in block 406 of method 400.

[0090] In box 412, the client device processor can invoke packet refresh at a fast time ratio, so that downlink data packets identified by the client software application are moved to the next level in the modem's protocol or processing stack without performing accumulation or aggregation operations to reduce latency on the client device.

[0091] In box 414, the client device processor can perform accumulation and / or aggregation operations on the remaining downlink data packets to reduce power consumption on the client device.

[0092] Figure 4C The illustration depicts a method 420 for dynamically adjusting a low-latency mode according to an embodiment. In block 422, the client device processor can evaluate the timestamp of a previously received data packet to determine whether the previously received data packet arrived early or late. In block 424, the client device processor can switch between different low-latency modes with different latencies based on whether the previously received data packet arrived early or late.

[0093] Figure 4DThe illustration depicts a method 430 for dynamically adjusting a low-latency mode according to an embodiment. In block 432, the client device processor may monitor downlink data packets to determine whether the condition of the client software application is static (or near-static). In block 434, the client device processor may set a timer in response to determining that the condition of the client software application is static or near-static. In block 436, the client device processor may begin gathering and / or accumulating downlink data packets in the modem until the timer expires. In block 438, the client device processor may invoke a packet refresh that, after the timer expires, forwards downlink data packets to the next layer in the modem's protocol or processing stack without performing accumulation or gathering operations.

[0094] Various implementations can be implemented on various client devices, in Figure 5 An example of a client device is illustrated in the form of a smartphone. The smartphone 500 may include a first system-on-a-chip (SoC) 202 (e.g., an SoC-CPU) coupled to a system-on-a-chip (SoC) 204 (e.g., a 5G-capable SoC). The first SoC 202 and the second SoC 204 may include processors (e.g., an application processor, a modem processor, a graphics processor, etc.) and may be coupled to internal memories 506, 516, a display 512, and a speaker 514. Additionally, the client device 500 may include an antenna 504 for transmitting and receiving electromagnetic radiation, which may be connected to a wireless data link and / or to a cellular transceiver 508 coupled to one or more processors in the first SoC 202 and / or the second SoC 204. The client device 500 may also include menu selection buttons or a rocker switch 520 for receiving user input.

[0095] The client device 500 also includes a sound codec (CODEC) circuit 510, which digitizes the sound received from the microphone into data packets suitable for wireless transmission and decodes the received sound data packets to generate an analog signal that is provided to the speaker to produce sound. Furthermore, one or more processors in the first SOC 202 and the second SOC 204, the wireless transceiver 508, and the CODEC 510 may include digital signal processor (DSP) circuitry (not shown separately).

[0096] The processor of client device 500 can be any programmable microprocessor, microcomputer, or multiprocessor chip, which can be configured by software instructions (applications) to perform various functions, including those implemented as described above. Typically, the software application can be stored in memories 506, 516 before it is accessed and loaded into the processor. The processor may include sufficient internal memory to store application software instructions.

[0097] The various implementations illustrated and described are provided by way of example only to illustrate the various features of the claims. However, the features shown and described with respect to any given implementation are not necessarily limited to the associated implementation and may be used or combined with other implementations shown and described. Furthermore, the claims are not intended to be limited to any one of the example implementations. For example, one or more operations of methods 400, 410, 420, and 430 may replace or be combined with one or more operations of methods 400, 410, 420, and 430.

[0098] Implementation examples are described in the following paragraphs. While some of the following implementation examples are described with reference to the example methods, further example implementations may include: the example methods discussed in the following paragraphs are implemented by a computing device including a processor configured with processor-executable instructions to perform the operations of the example methods; the example methods discussed in the following paragraphs are implemented by a computing device including components for performing the functions of the example methods; and the example methods discussed in the following paragraphs are implemented as a non-transitory processor-readable storage medium on which processor-executable instructions are stored, which are configured to cause the processor of the computing device to perform the operations of the example methods.

[0099] Example 1. A method for dynamically adjusting the low-latency mode of a modem in a client device, comprising: monitoring downlink data packets of a client software application operating on the client device to detect a triggering event; determining operating parameters of the modem based on the detected triggering event; and dynamically adjusting the low-latency mode of the modem based on the determined operating parameters.

[0100] Example 2. According to the method of Example 1, wherein: in some aspects, monitoring downlink data packets of a client software application operating on a client device to detect triggering events further includes: evaluating the timestamps of previously received data packets to determine whether the previously received data packets arrived early or late, and dynamically adjusting the low-latency mode of the demodulator based on determined operating parameters, including switching between different low-latency modes with different latencies based on whether the previously received data packets arrived early or late.

[0101] Example 3. According to the method of Example 1, wherein: monitoring downlink data packets of a client software application operating on a client device to detect a triggering event includes: monitoring downlink data packets to determine whether the condition of the client software application is static or near static; determining modem operating parameters based on the detected triggering event further includes: setting a timer in response to determining that the condition of the client software application is static or near static; and dynamically adjusting the low-latency mode of the modem based on the determined operating parameters includes: determining whether the timer has expired; gathering or accumulating downlink data packets in the modem in response to determining that the timer has not expired; and invoking a packet refresh in response to determining that the timer has expired, the packet refresh transmitting downlink data packets to the next level in the modem's protocol or processing stack without performing the accumulation or gathering operation.

[0102] Example 4. According to the method of Example 1, wherein monitoring downlink data packets of the client software application operating on the client device to detect triggering events includes monitoring downlink data packets to: detect a transport layer timeout triggering event; detect whether all segments corresponding to a slice arrive within a data burst; detect whether downlink data packets arrive earlier than expected; detect whether downlink data packets arrive later than expected; detect a download service interruption event; or detect a controller event.

[0103] Example 5. The method of any of Examples 1-4, wherein determining the modem's operating parameters based on the detected triggering event includes determining the operating parameters to balance the trade-off between meeting the immediate latency requirements of the client software application and reducing power consumption on the client device.

[0104] Example 6. According to the method of Examples 1-4, the determination of the modem's operating parameters based on the detected triggering event includes at least one of the following: determining whether to operate the client device at a higher power level to increase the rate of delivering downlink data packets to the client software application; determining whether to process downlink data packets in the modem's hardware block without actively involving the client device's main application processor (AP) to reduce power consumption on the client device; or determining whether to aggregate downlink data packets in the modem to reduce power consumption on the client device.

[0105] Example 7. The method according to any of Examples 1-6, wherein dynamically adjusting the low-latency mode of the modem based on determined operating parameters includes: invoking packet refresh at a fast time ratio, such that downlink data packets identified by the client software application are moved to the next level in the modem's protocol or processing stack without performing accumulation or aggregation operations to reduce latency on the client device, and performing accumulation or aggregation operations on the remaining downlink data packets to reduce power consumption on the client device.

[0106] The foregoing method descriptions and process flowcharts are provided as illustrative examples only and are not intended to require or imply that the blocks of the various embodiments must be performed in the presented order. As those skilled in the art will understand, the order of the blocks in the foregoing embodiments can be performed in any order. Words such as “after,” “then,” and “next” are not intended to limit the order of the blocks; these words are only used to guide the reader through the description of the method. Furthermore, any reference to an element of the claims in the singular form, such as the use of the articles “a,” “an,” or “the,” should not be construed as limiting the element to the singular.

[0107] The various illustrative logic blocks, modules, circuits, and algorithm blocks described in conjunction with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability between hardware and software, various illustrated components, blocks, modules, circuits, and frames have been described above in terms of their functionality. Whether such functionality is implemented in hardware or software depends on the specific application and the design constraints imposed on the overall system. Those skilled in the art may implement the described functionality in different ways for each specific application, but such implementation decisions should not be construed as departing from the scope of the invention.

[0108] The hardware used to implement the various illustrative logics, logic blocks, functional components, and circuits described in conjunction with the embodiments disclosed herein may be implemented or executed using a general-purpose processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof. The general-purpose processor may be a microprocessor, but alternatively, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices (e.g., a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration). Alternatively, some blocks or methods may be executed by circuitry specific to a given function.

[0109] The functionality described for various embodiments can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functionality may be stored as one or more instructions or code on a non-transitory computer-readable storage medium or a non-transitory processor-readable storage medium. The steps of the methods or algorithms disclosed herein may be embodied in a processor-executable software module that may reside on a non-transitory computer-readable or processor-readable storage medium. A non-transitory computer-readable or processor-readable storage medium may be any storage medium accessible by a computer or processor. By way of example and not limitation, this non-transitory computer-readable or processor-readable medium may include RAM, ROM, EEPROM, flash memory, CD-ROM or other optical disc storage devices, disk storage devices or other magnetic storage devices, or any other medium that may be used to store desired program code in the form of instructions or data structures and is accessible by a computer. As used herein, disks and optical discs include compact optical discs (CDs), laser optical discs, optical discs, digital versatile optical discs (DVDs), floppy disks, and Blu-ray discs, wherein disks generally reproduce data magnetically, while optical discs reproduce data optically using lasers. The combinations described above also fall within the scope of non-transitory computer-readable and processor-readable media. Furthermore, the operation of a method or algorithm may reside as one or any combination or set of code and / or instructions on a non-transitory processor-readable and / or computer-readable medium that can be incorporated into a computer program product.

[0110] The foregoing description of the disclosed embodiments is intended to enable any person skilled in the art to make or use the claims. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments without departing from the scope of the claims. Therefore, the claims are not intended to be limited to the embodiments shown herein, but are accorded the widest scope consistent with the following claims and the principles and novel features disclosed herein.

Claims

1. A method for dynamically adjusting the low-latency mode of a modem in a client device, comprising: Monitor downlink data packets of client software applications operating on the client device to detect triggering events; The operating parameters of the modem are determined based on the detected triggering events; as well as Dynamically adjusting the low-latency mode of the modem based on the determined operating parameters includes: Packet refresh is invoked in a fast time ratio so that downlink data packets identified by the client software application are moved to the next level in the protocol or processing stack of the modem, without performing accumulation or aggregation operations to reduce latency on the client device. as well as The accumulation or aggregation operation is performed on the remaining downlink data packets to reduce power consumption on the client device.

2. The method of claim 1, wherein determining the operating parameters of the modem based on the detected trigger event includes at least one of the following: Based on the detected triggering event, determine whether to operate the client device at a higher power level to increase the rate of delivering downlink data packets to the client software application; Based on the detected triggering event, determine whether to process downlink data packets in the modem's hardware block without actively involving the client device's main application processor (AP) to reduce power consumption on the client device; or Based on the detected triggering event, it is determined whether to aggregate downlink data packets in the modem to reduce power consumption on the client device.

3. The method according to claim 1, wherein: Monitoring downlink data packets of the client software application operating on the client device to detect triggering events also includes: evaluating the timestamps of previously received data packets to determine whether the previously received data packets arrived early or late; and Dynamically adjusting the low-latency mode of the modem based on the determined operating parameters includes switching between different low-latency modes with different latency based on whether the previously received data packets arrive early or late.

4. The method according to claim 1, wherein: Monitoring downlink data packets of the client software application operating on the client device to detect triggering events includes: monitoring downlink data packets to determine whether the client software application is in a static or near-static state; Determining the operating parameters of the modem based on the detected triggering event further includes: setting a timer in response to determining that the conditions of the client software application are static or near-static; and Dynamically adjusting the low-latency mode of the modem based on the determined operating parameters includes: Determine whether the timer has expired; In response to determining that the timer has not yet expired, downlink data packets are aggregated or accumulated in the modem; and In response to determining that the timer has expired, a packet refresh is invoked, which transmits downlink data packets to the next level in the modem's protocol or processing stack without performing accumulation or aggregation operations.

5. The method of claim 1, wherein monitoring downlink data packets of the client software application operating on the client device to detect a triggering event includes monitoring downlink data packets to perform the following operations: Detect transport layer timeout trigger event; Detect whether all segments corresponding to the slice arrive within the data burst; Detect whether downlink data packets arrive earlier than expected; Detect whether downlink data packets arrive later than expected; Detect download service interruption events; or Detect controller events.

6. The method of claim 1, wherein determining the operating parameters of the modem based on the detected triggering event includes determining the operating parameters to balance a tradeoff between meeting the immediate latency requirements of the client software application and reducing power consumption on the client device.

7. A client device, comprising: The processor is configured as follows: Monitor downlink data packets of client software applications operating on the client device to detect triggering events; The operating parameters of the client device's modem are determined based on the detected triggering events; as well as The low-latency mode of the modem is dynamically adjusted based on the determined operating parameters, by: Packet refresh is invoked in a fast time ratio so that downlink data packets identified by the client software application are moved to the next level in the protocol or processing stack of the modem, without performing accumulation or aggregation operations to reduce latency on the client device. as well as The accumulation or aggregation operation is performed on the remaining downlink data packets to reduce power consumption on the client device.

8. The client device of claim 7, wherein the processor is further configured to determine the operating parameters of the modem based on the detected triggering event by: Based on the detected triggering event, determine whether to operate the client device at a higher power level to increase the rate of delivering downlink data packets to the client software application; Based on the detected triggering event, determine whether to process downlink data packets in the modem's hardware block without actively involving the client device's main application processor (AP) to reduce power consumption on the client device; or Based on the detected triggering event, it is determined whether to aggregate downlink data packets in the modem to reduce power consumption on the client device.

9. The client device according to claim 7, wherein the processor is further configured to: Monitoring downlink data packets of the client software application operating on the client device to detect triggering events by evaluating the timestamps of previously received data packets to determine whether the previously received data packets arrived early or late; and The low-latency mode of the modem is dynamically adjusted based on the determined operating parameters by switching between different low-latency modes with different delays based on whether the previously received data packets arrive early or late.

10. The client device according to claim 7, wherein the processor is further configured to: Monitoring downlink data packets of the client software application operating on the client device to detect triggering events by monitoring downlink data packets, in order to determine whether the status of the client software application is static or nearly static; Determining the operating parameters of the modem based on the detected triggering event further includes: setting a timer in response to determining that the conditions of the client software application are static or near-static; and The low-latency mode of the modem is dynamically adjusted based on the determined operating parameters by the following: Determine whether the timer has expired; In response to determining that the timer has not yet expired, downlink data packets are aggregated or accumulated in the modem; and In response to determining that the timer has expired, a packet refresh is invoked, which transmits downlink data packets to the next level in the modem's protocol or processing stack without performing accumulation or aggregation operations.

11. The client device of claim 7, wherein the processor is further configured to monitor downlink data packets of the client software application operating on the client device, in order to detect a triggering event by monitoring the downlink data packets to perform the following operations: Detect transport layer timeout trigger event; Detect whether all segments corresponding to the slice arrive within the data burst; Detect whether downlink data packets arrive earlier than expected; Detect whether downlink data packets arrive later than expected; Detect download service interruption events; or Detect controller events.

12. The client device of claim 7, wherein the processor is further configured to determine the operating parameters of the modem based on the detected triggering event by determining the operating parameters to balance a tradeoff between meeting the immediate latency requirements of the client software application and reducing power consumption on the client device.

13. A non-transitory computer-readable storage medium having stored thereon processor executable software instructions configured to cause a processor of a client device to perform operations including: Monitor downlink data packets of client software applications operating on the client device to detect triggering events; The operating parameters of the modem are determined based on the detected trigger events; as well as Dynamically adjusting the low-latency mode of the modem based on the determined operating parameters includes: Packet refresh is invoked in a fast time ratio so that downlink data packets identified by the client software application are moved to the next level in the protocol or processing stack of the modem, without performing accumulation or aggregation operations to reduce latency on the client device. as well as The accumulation or aggregation operation is performed on the remaining downlink data packets to reduce power consumption on the client device.

14. The non-transitory computer-readable storage medium of claim 13, wherein the stored processor-executable software instructions are configured to cause the processor to perform operations such that determining the operating parameters of the modem based on the detected trigger event includes at least one of the following: Based on the detected triggering event, determine whether to operate the client device at a higher power level to increase the rate of delivering downlink data packets to the client software application; Based on the detected triggering event, determine whether to process downlink data packets in the modem's hardware block without actively involving the client device's main application processor (AP) to reduce power consumption on the client device; or Based on the detected triggering event, it is determined whether to aggregate downlink data packets in the modem to reduce power consumption on the client device.

15. The non-transitory computer-readable storage medium of claim 13, wherein the stored processor-executable software instructions are configured to cause the processor to perform operations such that: monitoring downlink data packets of the client software application operating on the client device to detect a triggering event further comprises: Evaluate the timestamps of previously received data packets to determine whether the previously received data packets arrived early or late; as well as Dynamically adjusting the low-latency mode of the modem based on the determined operating parameters includes switching between different low-latency modes with different latency based on whether the previously received data packets arrive early or late.

16. The non-transitory computer-readable storage medium of claim 13, wherein the stored processor-executable software instructions are configured to cause the processor to perform operations such that: Monitoring downlink data packets of the client software application operating on the client device to detect triggering events includes: Monitor downlink data packets to determine whether the client software application is in a static or near-static state; Determining the operating parameters of the modem based on the detected triggering event further includes: setting a timer in response to determining that the conditions of the client software application are static or near-static; and Dynamically adjusting the low-latency mode of the modem based on the determined operating parameters includes: Determine whether the timer has expired; In response to determining that the timer has not yet expired, downlink data packets are aggregated or accumulated in the modem; and In response to determining that the timer has expired, a packet refresh is invoked, which transmits downlink data packets to the next level in the modem's protocol or processing stack without performing accumulation or aggregation operations.

17. The non-transitory computer-readable storage medium of claim 13, wherein the processor-executable software instructions stored therein are configured to cause the processor to perform operations such that monitoring downlink data packets of the client software application operating on the client device to detect a triggering event includes monitoring downlink data packets to perform the following operations: Detect transport layer timeout trigger event; Detect whether all segments corresponding to the slice arrive within the data burst; Detect whether downlink data packets arrive earlier than expected; Detect whether downlink data packets arrive later than expected; Detect download service interruption events; or Detect controller events.

18. The non-transitory computer-readable storage medium of claim 13, wherein the stored processor-executable software instructions are configured to cause the processor to perform operations such that determining the operating parameters of the modem based on the detected trigger event includes: The operating parameters are determined to strike a balance between meeting the immediate latency requirements of the client software application and reducing power consumption on the client device.

19. A client device, comprising: A component used to monitor downlink data packets of client software applications operating on the client device to detect triggering events; A component for determining the operating parameters of the modem of the client device based on detected triggering events; as well as The components for dynamically adjusting the low-latency mode of the modem based on the determined operating parameters include: A component for rapidly invoking packet refresh at a fast time ratio, so that downlink data packets identified by the client software application are moved to the next level in the protocol or processing stack of the modem without performing accumulation or aggregation operations to reduce latency on the client device. as well as A component used to perform the accumulation or aggregation operation on the remaining downlink data packets to reduce power consumption on the client device.

20. The client device of claim 19, wherein the components for determining the operating parameters of the modem based on the detected trigger event include at least one of the following: A component for determining, based on the detected triggering event, whether to operate the client device at a higher power level to increase the rate of delivering downlink data packets to the client software application; A component for determining, based on the detected triggering event, whether to process downlink data packets in the hardware block of the modem without actively involving the main application processor (AP) of the client device in order to reduce power consumption on the client device; or A component for determining whether to aggregate downlink data packets in the modem to reduce power consumption on the client device based on the detected triggering event.

21. The client device according to claim 19, wherein: The component for monitoring downlink data packets of the client software application operating on the client device to detect triggering events further includes: a component for evaluating the timestamps of previously received data packets to determine whether the previously received data packets arrived early or late; and The components for dynamically adjusting the low-latency mode of the modem based on the determined operating parameters include: components for switching between different low-latency modes with different latency based on whether the previously received data packets arrive early or late.

22. The client device according to claim 19, wherein: The components for monitoring downlink data packets of the client software application operating on the client device to detect triggering events include: components for monitoring downlink data packets to determine whether the state of the client software application is static or nearly static; The components for determining the operating parameters of the modem based on the detected triggering event further include: components for setting a timer in response to determining that the conditions of the client software application are static or near-static; and The components for dynamically adjusting the low-latency mode of the modem based on the determined operating parameters include: A component used to determine whether the timer has expired; Components for gathering or accumulating downlink data packets in the modem in response to determining that the timer has not yet expired; and The component is used to invoke packet refresh in response to determining that the timer has expired. Packet refresh transmits downlink data packets to the next level in the protocol or processing stack of the modem without performing accumulation or aggregation operations.

23. The client device of claim 19, wherein the component for monitoring downlink data packets of the client software application operating on the client device to detect a triggering event comprises: Components used to monitor downlink data packets to perform the following operations: Detect transport layer timeout trigger event; Detect whether all segments corresponding to the slice arrive within the data burst; Detect whether downlink data packets arrive earlier than expected; Detect whether downlink data packets arrive later than expected; Detect download service interruption events; or Detect controller events.

24. The client device of claim 19, wherein the component for determining the operating parameters of the modem based on the detected triggering event comprises: A component for determining the operating parameters in order to balance the trade-off between meeting the immediate latency requirements of the client software application and reducing power consumption on the client device.

Images