As shown, the base station 102A may also be equipped to communicate with a network 100 (e.g., a core network of a cellular service provider, a telecommunication network such as a public switched telephone network (PSTN), and/or the Internet, among various possibilities). Thus, the base station 102A may facilitate communication between the user devices and/or between the user devices and the network 100. In particular, the cellular base station 102A may provide UEs 106 with various telecommunication capabilities, such as voice, SMS and/or data services.

Base station 102A and other similar base stations (such as base stations 102B through 102N) operating according to the same or a different cellular communication standard may thus be provided as a network of cells, which may provide continuous or nearly continuous overlapping service to UEs 106A-106N and similar devices over a geographic area via one or more cellular communication standards.

Thus, while base station 102A may act as a “serving cell” for UEs 106A-106N as illustrated in FIG. 1, each UE 106 may also be capable of receiving signals from (and possibly within communication range of) one or more other cells (which may be provided by base stations 102B-102N and/or any other base stations), which may be referred to as “neighboring cells.” Such cells may also be capable of facilitating communication between user devices and/or between user devices and the network 100. Such cells may include “macro” cells, “micro” cells, “pico” cells, and/or cells which provide any of various other granularities of service area size. For example, base stations 102A and 102B illustrated in FIG. 1 may be macro cells, while base station 102N may be a micro cell. Other configurations are also possible.

In some aspects, base station 102A may be a next generation base station, (e.g., a 5G New Radio (5G NR) base station, or “gNB”). In some aspects, a gNB may be connected to a legacy evolved packet core (EPC) network and/or to a NR core (NRC)/5G core (5GC) network. In addition, a gNB cell may include one or more TRPs. In addition, a UE capable of operating according to 5G NR may be connected to one or more TRPs within one or more gNBs. For example, it may be possible that that the base station 102A and one or more other base stations 102 support joint transmission, such that UE 106 may be able to receive transmissions from multiple base stations (and/or multiple TRPs provided by the same base station). For example, as illustrated in FIG. 1, both base station 102A and base station 102C are shown as serving UE 106A.

Note that a UE 106 may be capable of communicating using multiple wireless communication standards. For example, the UE 106 may be configured to communicate using a wireless networking (e.g., Wi-Fi) and/or peer-to-peer wireless communication protocol (e.g., Bluetooth, Wi-Fi peer-to-peer, and the like) in addition to at least one of the cellular communication protocol discussed in the definitions above. The UE 106 may also or alternatively be configured to communicate using one or more global navigational satellite systems (GNSS) (e.g., GPS or GLONASS), one or more mobile television broadcasting standards (e.g., ATSC-M/H), and/or any other wireless communication protocol, if desired. Other combinations of wireless communication standards (including more than two wireless communication standards) are also possible.

In one or more embodiments, the UE 106 may be a device with cellular communication capability such as a mobile phone, a hand-held device, a computer, a laptop, a tablet, a smart watch, or other wearable device, or virtually any type of wireless device. Embodiments may also include vehicles, industrial equipment, or other devices that may benefit from multi-panel wireless connectivity.

The UE 106 may include a processor (processing element) that is configured to execute program instructions stored in memory. The UE 106 may perform any of the method aspects described herein by executing such stored instructions. Alternatively, or in addition, the UE 106 may include a programmable hardware element such as an FPGA (field-programmable gate array), an integrated circuit, and/or any of various other possible hardware components that are configured to perform (e.g., individually or in combination) any of the method aspects described herein, or any portion of any of the method aspects described herein.

The UE 106 may include one or more antennas for communicating using one or more wireless communication protocols or technologies. In some aspects, the UE 106 may be configured to communicate using, for example, NR or LTE using at least some shared radio components. As additional possibilities, the UE 106 could be configured to communicate using CDMA2000 (1×RTT/1×EV-DO/HRPD/eHRPD) or LTE using a single shared radio and/or GSM or LTE using the single shared radio. The shared radio may couple to a single antenna, or may couple to multiple antennas (e.g., for a multiple-input multiple output (MIMO) configuration) for performing wireless communications. In general, a radio may include any combination of a BB processor, analog RF signal processing circuitry (e.g., including filters, mixers, oscillators, amplifiers, and the like), or digital processing circuitry (e.g., for digital modulation as well as other digital processing). Similarly, the radio may implement one or more receive and transmit chains using the aforementioned hardware. For example, the UE 106 may share one or more parts of a receive and/or transmit chain between multiple wireless communication technologies, such as those discussed above.

In some aspects, the UE 106 may include separate transmit and/or receive chains (e.g., including separate antennas and other radio components) for each wireless communication protocol with which it is configured to communicate. As a further possibility, the UE 106 may include one or more radios which are shared between multiple wireless communication protocols, and one or more radios which are used exclusively by a single wireless communication protocol. For example, the UE 106 might include a shared radio for communicating using either of LTE or 5G NR (or either of LTE or 1×RTT, or either of LTE or GSM, among various possibilities), and separate radios for communicating using each of Wi-Fi and Bluetooth. Other configurations are also possible.

In some aspects, a downlink resource grid may be used for downlink transmissions from any of the base stations 102 to the UEs 106, while uplink transmissions may utilize similar techniques. The grid may be a time-frequency grid, called a resource grid or time-frequency resource grid, which is the physical resource in the downlink in each slot. Such a time-frequency plane representation is a common practice for Orthogonal Frequency Division Multiplexing (OFDM) systems, which makes it intuitive for radio resource selection. Each column and each row of the resource grid corresponds to one OFDM symbol and one OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to one slot in a radio frame. The smallest time-frequency unit in a resource grid is denoted as a resource element. Each resource grid may comprise a number of resource blocks, which describe the mapping of certain physical channels to resource elements. Each resource block comprises a collection of resource elements. There are several different physical downlink channels that are conveyed using such resource blocks.

The physical downlink shared channel (PDSCH) may carry user data and higher layer signaling to the UEs 106. The physical downlink control channel (PDCCH) may carry information about the transport format and resource allocations related to the PDSCH channel, among other things. It may also inform the UEs 106 about the transport format, resource allocation, and HARQ (Hybrid Automatic Repeat Request) information related to the uplink shared channel. Typically, downlink scheduling (assigning control and shared channel resource blocks to the UE 102 within a cell) may be performed at any of the base stations 102 based on channel quality information fed back from any of the UEs 106. The downlink resource assignment information may be sent on the PDCCH used for (e.g., assigned to) each of the UEs.

The PDCCH may use control channel elements (CCEs) to convey the control information. Before being mapped to resource elements, the PDCCH complex-valued symbols may first be organized into quadruplets, which may then be permuted using a sub-block interleaver for rate matching. Each PDCCH may be transmitted using one or more of these CCEs, where each CCE may correspond to nine sets of four physical resource elements known as resource element groups (REGs). Four Quadrature Phase Shift Keying (QPSK) symbols may be mapped to each REG. The PDCCH may be transmitted using one or more CCEs, depending on the size of the Downlink Control Information (DCI) and the channel condition. There may be four or more different PDCCH formats defined in LTE with different numbers of CCEs (e.g., aggregation level, L=1, 2, 4, or 8).

Example Communication Device

FIG. 2 illustrates an example simplified block diagram of a communication device 206, according to some aspects. It is noted that the block diagram of the communication device of FIG. 2 is only one example of a possible communication device. According to aspects, communication device 206 may be a UE device or terminal, a mobile device or mobile station, a wireless device or wireless station, a desktop computer or computing device, a mobile computing device (e.g., a laptop, notebook, or portable computing device), a tablet, and/or a combination of devices, among other devices. As shown, the communication device 206 may include a set of components 200 configured to perform core functions. For example, this set of components may be implemented as a system on chip (SOC), which may include portions for various purposes. Alternatively, this set of components 200 may be implemented as separate components or groups of components for the various purposes. The set of components 200 may be coupled (e.g., communicatively: directly or indirectly) to various other circuits of the communication device 206.

For example, the communication device 206 may include various types of memory (e.g., including NAND flash 210), an input/output interface such as connector I/F 220 (e.g., for connecting to a computer system; dock: charging station; input devices, such as a microphone, camera, keyboard: output devices, such as speakers; and the like), the display 260, which may be integrated with or external to the communication device 206, and wireless communication circuitry 230 (e.g., for LTE, LTE-A, NR, UMTS, GSM, CDMA2000, Bluetooth, Wi-Fi, NFC, GPS, and the like). In some aspects, communication device 206 may include wired communication circuitry (not shown), such as a network interface card (e.g., for Ethernet connection).

The wireless communication circuitry 230 may couple (e.g., communicatively: directly or indirectly) to one or more antennas, such as antenna(s) 235 as shown. The wireless communication circuitry 230 may include cellular communication circuitry and/or short to medium range wireless communication circuitry, and may include multiple receive chains and/or multiple transmit chains for receiving and/or transmitting multiple spatial streams, such as in a MIMO configuration.

In some aspects, as further described below, cellular communication circuitry 230 may include one or more receive chains (including and/or coupled to (e.g., communicatively: directly or indirectly) dedicated processors and/or radios) for multiple Radio Access Technologies (RATs) (e.g., a first receive chain for LTE and a second receive chain for 5G NR). In addition, in some aspects, cellular communication circuitry 230 may include a single transmit chain that may be switched between radios dedicated to specific RATs. For example, a first radio may be dedicated to a first RAT (e.g., LTE) and may be in communication with a dedicated receive chain and a transmit chain shared with a second radio. The second radio may be dedicated to a second RAT (e.g., 5G NR) and may be in communication with a dedicated receive chain and the shared transmit chain. In some aspects, the second RAT may operate at mmWave frequencies. As mmWave systems operate in higher frequencies than typically found in LTE systems, signals in the mmWave frequency range are heavily attenuated by environmental factors. To help address this attenuating, mmWave systems often utilize beamforming and include more antennas as compared LTE systems. These antennas may be organized into antenna arrays or panels made up of individual antenna elements. These antenna arrays may be coupled to the radio chains.

The communication device 206 may also include and/or be configured for use with one or more user interface elements. The communication device 206 may further include one or more smart cards 245 that include Subscriber Identity Module (SIM) functionality, such as one or more Universal Integrated Circuit Card(s) (UICC(s)) cards 245.

As shown, the SOC 200 may include processor(s) 202, which may execute program instructions for the communication device 106 and display circuitry 204, which may perform graphics processing and provide display signals to the display 260. The processor(s) 202 may also be coupled to memory management unit (MMU) 240, which may be configured to receive addresses from the processor(s) 202 and translate those addresses to locations in memory (e.g., memory 206, read only memory (ROM) 250, NAND flash memory 210) and/or to other circuits or devices, such as the display circuitry 204, wireless communication circuitry 230, connector I/F 220, and/or display 260. The MMU 240 may be configured to perform memory protection and page table translation or set up. In some aspects, the MMU 240 may be included as a portion of the processor(s) 202.

As noted above, the communication device 206 may be configured to communicate using wireless and/or wired communication circuitry. As described herein, the communication device 206 may include hardware and software components for implementing any of the various features and techniques described herein. The processor 202 of the communication device 206 may be configured to implement part or all of the features described herein (e.g., by executing program instructions stored on a memory medium). Alternatively (or in addition), processor 202 may be configured as a programmable hardware element, such as a Field Programmable Gate Array (FPGA), or as an Application Specific Integrated Circuit (ASIC). Alternatively (or in addition) the processor 202 of the communication device 206, in conjunction with one or more of the other components 200, 204, 206, 210, 220, 230, 240, 245, 250, 260 may be configured to implement part or all of the features described herein.

In addition, as described herein, processor 202 may include one or more processing elements. Thus, processor 202 may include one or more integrated circuits (ICs) that are configured to perform the functions of processor 202. In addition, each integrated circuit may include circuitry (e.g., first circuitry, second circuitry, and the like) configured to perform the functions of processor(s) 202.

Further, as described herein, wireless communication circuitry 230 may include one or more processing elements. In other words, one or more processing elements may be included in wireless communication circuitry 230. Thus, wireless communication circuitry 230 may include one or more integrated circuits (ICs) that are configured to perform the functions of wireless communication circuitry 230. In addition, each integrated circuit may include circuitry (e.g., first circuitry, second circuitry, and the like) configured to perform the functions of wireless communication circuitry 230.

Example Base Station

FIG. 3 illustrates an example block diagram of a base station 302, according to some aspects. It is noted that the base station of FIG. 3 is a non-limiting example of a possible base station. As shown, the base station 302 may include processor(s) 304 which may execute program instructions for the base station 302. The processor(s) 304 may also be coupled to memory management unit (MMU) 340, which may be configured to receive addresses from the processor(s) 304 and translate those addresses to locations in memory (e.g., memory 360 and read only memory (ROM) 350) or to other circuits or devices.

The base station 302 may include at least one network port 370. The network port 370 may be configured to couple to a telephone network and provide a plurality of devices, such as UE devices 106, access to the telephone network as described above in FIG. 1.

The network port 370 (or an additional network port) may also or alternatively be configured to couple to a cellular network, e.g., a core network of a cellular service provider. The core network may provide mobility related services and/or other services to a plurality of devices, such as UE devices 106. In some cases, the network port 370 may couple to a telephone network via the core network, and/or the core network may provide a telephone network (e.g., among other UE devices serviced by the cellular service provider).

In some aspects, base station 302 may be a next generation base station, (e.g., a 5G New Radio (5G NR) base station, or “gNB”). In such aspects, base station 302 may be connected to a legacy evolved packet core (EPC) network and/or to a NR core (NRC)/5G core (5GC) network. In addition, base station 302 may be considered a 5G NR cell and may include one or more transition and reception points (TRPs). In addition, a UE capable of operating according to 5G NR may be connected to one or more TRPs within one or more gNBs.

The base station 302 may include at least one antenna 334, and possibly multiple antennas. The at least one antenna 334 may be configured to operate as a wireless transceiver and may be further configured to communicate with UE devices 106 via radio 330. The antenna 334 communicates with the radio 330 via communication chain 332. Communication chain 332 may be a receive chain, a transmit chain or both. The radio 330 may be configured to communicate via various wireless communication standards, including 5G NR, LTE, LTE-A, GSM, UMTS, CDMA2000, Wi-Fi, and the like.

The base station 302 may be configured to communicate wirelessly using multiple wireless communication standards. In some instances, the base station 302 may include multiple radios, which may enable the base station 302 to communicate according to multiple wireless communication technologies. For example, as one possibility, the base station 302 may include an LTE radio for performing communication according to LTE as well as a 5G NR radio for performing communication according to 5G NR. In such a case, the base station 302 may be capable of operating as both an LTE base station and a 5G NR base station. When the base station 302 supports mmWave, the 5G NR radio may be coupled to one or more mmWave antenna arrays or panels. As another possibility, the base station 302 may include a multi-mode radio, which is capable of performing communications according to any of multiple wireless communication technologies (e.g., 5G NR and LTE, 5G NR and Wi-Fi, LTE and Wi-Fi, LTE and UMTS, LTE and CDMA2000, UMTS and GSM, and the like).

Further, the BS 302 may include hardware and software components for implementing or supporting implementation of features described herein. The processor 304 of the base station 302 may be configured to implement or support implementation of part or all of the methods described herein (e.g., by executing program instructions stored on a memory medium). Alternatively, the processor 304 may be configured as a programmable hardware element, such as a Field Programmable Gate Array (FPGA), or as an Application Specific Integrated Circuit (ASIC), or a combination thereof. Alternatively (or in addition) the processor 304 of the BS 302, in conjunction with one or more of the other components 330, 332, 334, 340, 350, 360, 370 may be configured to implement or support implementation of part or all of the features described herein.

In addition, as described herein, processor(s) 304 may include one or more processing elements. Thus, processor(s) 304 may include one or more integrated circuits (ICs) that are configured to perform the functions of processor(s) 304. In addition, each integrated circuit may include circuitry (e.g., first circuitry, second circuitry, and the like) configured to perform the functions of processor(s) 304.

Further, as described herein, radio 330 may include one or more processing elements. Thus, radio 330 may include one or more integrated circuits (ICs) that are configured to perform the functions of radio 330. In addition, each integrated circuit may include circuitry (e.g., first circuitry, second circuitry, and the like) configured to perform the functions of radio 330.

FIG. 4 illustrates communication in a system, in accordance with some aspects. In the examples of FIG. 4, a UE 406 includes an AP and the BS 402 includes a BB. At step 402, adversity is detected in the DL from the BS to the UE. The adversity may be detected by the AP in the UE, or by the BB in the BS, or by both in combination. For example, DL data delivery to end applications may be monitored. More specifically, the data delivery relative to an application priority may be monitored. Also, DL stress in the form of an amount of pending data in a DL queue may be monitored.

In addition, the system health may be monitored to detect adversity in the DL. For example, a high CPU load utilization factor on the AP, i.e., CPU throttling, may be an indication of adversity in the DL. A memory crunch in the AP or the BB may also be an indication of adversity in accordance with embodiments disclosed herein.

A slow drain of data from the application can result in back pressure on the BB/BS. For example, a critical application, such as XR/VR or TCP ACK, may get stuck behind best effort data. Also, a slow interconnect between the AP/UE and the BB/BS may develop as a result of such adversities to the health of the system.

The thermal threshold of components in the UE and BS may be monitored to detect adversity in accordance with embodiments disclosed herein. A component approaching, or reaching, a thermal threshold can be indicative of adversity in a DL.

A suboptimal physical layer condition can result in bursts of data that may adversely affect the DL. For example, the expiration of a Package Data Convergence Protocol (PDCP) reordering timer may result in a suboptimal physical layer, leading to bursts of data.

Returning to FIG. 4, DL-CDP is enabled in step 404 in response to the detection of the adversity at step 402. The enablement of the DL-CDP may be instigated by the UE or the BS in accordance with embodiments disclosed herein. Enabling the DL-CDP includes establishing the DL-CDP policy for the DL based on the adversity detected. In accordance with embodiments disclosed herein, the policy may be static or dynamic depending on the detected adversity and current conditions.

The policy is defined and established in step 406. In embodiments disclosed herein, the rules in the policy may be defined based on various measurements and attributes of the system. The policy also establishes the order in which the rules should be executed. Embodiments disclosed herein may dynamically add/remove/change policy rules and their associated order in order to perform the DL-CDP. In embodiments, the policy may be exchanged over a data path logical channel for faster, efficient communication.

Examples of policy attributes include, but are not limited to, an application criticality or category. Examples of such categories include voice applications, low latency applications, Best Effort applications, Keep Alive applications, Streaming applications, etc. Voice applications are applications that include voice communications, such as video conferencing, Voice over New Radio (VoNR), and Voice over Long Term Evolution (VOLTE). Low latency applications are applications that may require low latency in the transmissions, such as XR/VR. Examples of best effort applications may include media streaming or other Internet-based applications.

Other attributes that may be used to establish the policy include flow aspects in accordance with embodiments disclosed herein. For example, flow aging, average time in DL queue, flow throughput, and flow periodicity may be used. For example, flow aging aspects may include new flows, old flows, or short lived flows-such as flows associated with gaming consoles or internet speed test applications. The flow throughput may be established by determining how much data is received over a period of time. For example, a flow throughput may be defined as the amount of data received in the previous 100 ms. The flow periodicity aspects include the periodic sending/receiving of data and/or continues in data streaming. Flow discards, or flows associated with relatively large applications may also be included.

Other attributes include the sizes of the packets transmitted in accordance with embodiments disclosed herein. For example, small packets, such as a PING, as compared to larger IP packets, such as in FTP.

The Layer 4 protocol type communication attributes may also contribute to the policy in accordance with embodiments. For example, aspects of the TCP ACKs, DNS response, PING response, and User Datagram Protocol (UDP) communication may be included in establishing the policy. The Differentiated Services Codepoint (DSCP) or Type of Service (ToS) in the layer 2 header may also contribute to the policy in accordance with embodiments disclosed herein.

The Protocol Data Unit (PDU) secessions established in the Packet Data Network (PDN), Data Radio Bearer (DRB) and the flows associated with DRBs, Ultra-Reliable Low Latency Communication (URLLC) slices, IP Multimedia Subsystem (IMS) signaling bearers, IMS media bearers, current internet traffic, and Admin PDUs may also be considered while establishing a policy in accordance with embodiments disclosed herein.

In embodiments disclosed herein, the policy establishment may include defining new attributes and rules based the DL patterns observed. The DL-CDP policy is dynamic in nature, and the policy may included more, or less, rules based on downlink pattern.

The following provides several examples of policies that may be established in accordance with embodiments disclosed herein. The examples are provide to illustrate the various possibilities, and the examples are not intended to be limiting.

For example, the UE and BS may define a simple policy based on the application criticality, or a category based policy. The policy is defined by a number of ranked rules. In this example, five tuples have been identified to categorize the applications and ranked according to priority. The policy may then be defined as: Rule 1: XR/VR Application: Rule 2: videoconferencing or voice application; Rule 3: intelligent assistant/AI-based application: Rule 4: streaming application; and Rule 5: remaining application. This categorized ranking provides a policy that may be used to implement the DL-CDP in accordance with embodiments disclosed herein. If one or more applications are set up, the system may dynamically add one or more rules based on the new applications.

As another simple example, the system may monitor DL patterns and define a time critically and throughput policy. For example, the policy may be defined as: Rule 1: new flows; Rule 2: short lived flows: Rule 3: minimum average time spent in DL queue: Rule 4: small packets; and Rule 5: remaining applications. In some embodiments, the system may dynamically add or remove rules based on a new DL pattern detected.

As another simple example, the system may establish a static policy. For example, the policy may then be defined as: Rule 1: URLLC slice: Rule 2: IMS bearers: Rule 3: TCP pure ACKs; Rule 4: DNS response: Rule 5: PING response: and Rule 6: remaining applications.

As another example, the system may establish a policy based on both the application criticality and the time criticality. For example, the policy may be defined as: Rule 1: XR/VR application with relatively small packets; Rule 2: Video conferencing application on Internet PDN: Rule 3: internet speed test application and no voice call: Rule 4: new TCP flow application and pure ACKs; and Rule 5: discard remaining packets.

As previously noted, the policy may be dynamically altered in accordance with embodiments disclosed herein. For example, an initial policy may be established as: Rule 1: XR/VR applications; Rule 2: IMS PDU traffic: Rule 3: music stream application; and Rule 4: rest all application. While this policy is established, a user may start an application, such as an Intelligent Assistant. Embodiments of the UE (or AP) may dynamically modify the policy to replace the IMS PDU rule (Rule 2) with Intelligent Assistant application traffic. As a result, the new policy would be: Rule 1: XR/VR application: Rule 2: Intelligent Assistant Application Traffic: Rule 3: music stream application; and Rule 4: rest all application.

Returning to FIG. 4, after the policy has been defined in step 406, the DL-CDP policy is enforced for data destined to the UE from the network. Specifically, data transmissions are received by the BS from the core network in step 408. The DL-CDP includes the UE, or AP of the UE, advertising a number of available credits for the DL in step 410. In step 412, the BS transmits data in the DL according to the advertised number of credits and the policy established. Further details regarding the transmission of credits in the DL according to the DL-CDP is given in FIGS. 5A and 5B. As shown in step 414, the advertising of credit, followed by the transmission of credits according to the DL-CDP and advertisement may be repeated. Step 414 may be continuously repeated until the policy changes, or the adversity subsides.

Embodiments disclosed herein intelligently distribute credits among rules defined in policy using the limited credits advertised. Embodiments of the BS, or BB, distribute the credits in the methods disclosed herein to ensure fairness and avoid starvation of low priority traffic. In general, the BS assigns a minimum credit to each rule in the policy, and the remaining credits are assigned to rules in the order the rules were defined.

More specifically, embodiments disclosed herein use a DL credit distribution algorithm that includes a two-pass approach to consume the number of available credits advertised. Embodiments of the first pass are demonstrated in FIG. 5A, while embodiments of the second pass are demonstrated in FIG. 5B.

Referring to FIG. 5A, the DL-CDP is initialized in step 520. In step 520, a minimum number of credits for the first pass is determined. For example, half of the available credits may be allocated to the first pass. A minimum DL credit percentage per rule may be defined as half the total number of credits per the number of rules in the policy, i.e., Min. DL credit % per rule=((Total number of credits/2)/Number of rules in the policy. This establishes the number of credits available for the first pass in accordance with embodiments disclosed herein. Embodiments disclosed herein are not limited to using 50% of the available credits in the first pass. As explained below, any credits not used in the first pass will be available for the second pass. However, to ensure fairness, the number of credits used for the first pass ideally allows for using a minimum credit for all the rules in the policy.

The process then proceeds to assign the minimum number of credits to each rule in the order of the rule index (i.e., the priority). Specifically, in step 522, it is determined if the current rule index is less than the total number of rules. If so (YES), it is determined if there is any DL data associated with the current rule. If there is DL data associated with the current rule, the data is to be downloaded, and the number of credits for the data download is recorded in step 528. The current rule index is then increased by one in step 526, and the process returns to step 522. If there is no DL data associated with the current rule index (NO in step 524), the current rule index is increased by one and the process returns to step 522. Once all the rules have been traversed (NO in step 522), any remaining credits from the determined number of credits for the first pass are stored, or allocated, to the second pass in step 530. Step 530 may include determining the number of credits that have been consumed in the first pass.

After the conclusion of Step 530, the process may proceed to FIG. 5B, which illustrates a second pass according to some aspects. The second pass may be considered a greedy approach to the consumption of credits while still honoring the priority of the rules in the policy. In step 532 of FIG. 5B, the current rule index is reset to the highest priority rule for the second pass. In step 534, it is determined if the current rule index is less than the total number of rules (i.e., if all the rules been considered) and if there are any credits available for the DL of data.

If both of the conditions are met in step 534 (YES), it is determined if the current rule identified by the rule index has data to download in step 536. If so (YES), the data is set for downloaded in step 538. At this step, the process greedily assigns the available credits to the current rule. That is, all the data/credits associated with the rule are set for download, as restricted by the number of available credits. The process proceeds to step 540 where the rule index is increase by 1 and, then, the process returns to step 534.

If there is no data associated with the current rule index (NO in step 536), the process proceeds to step 540 where the current rule index is incremented, and the process returns to step 534.

If the available credits have been consumed, or if all of the rules have been considered (NO in step 534), the process ends.

As noted, the second pass starts at the highest priority rule, and tries to use as many credits as possible for said rule, and then proceeds to the next rule in the prioritized list. That is, once all data for a particular higher priority rule is completely sent, and there are still credits pending, the algorithm jumps to next rule and repeats the process until all of the available credits are consumed. In the circumstance that there are residual credits available after the second pass, such credits will not be used.

FIG. 6 provides an example in accordance with embodiments disclosed herein. FIG. 6 illustrates an example of the DL-CDP described by FIGS. 4, 5A, and 5B. FIG. 6 illustrates a Baseband 602 showing five ranked rules in accordance with the DL-CDP disclosed herein. There are 13 credits to be transmitted on the DL to the Application processor 606 in the example of FIG. 6. Each of the 13 credits is associated with a rule as shown. As previously noted, in this context, one credit may refer to one packet, or one or more number of bytes.

In FIG. 6, a 10 credit grant is relayed to the baseband 602. As shown, in the first pass, a credit from each of the rules is picked and transmitted to the data buffer of the application processor 606. Specifically, credits 1, 5, 10, and 13 are transmitted via the first pass. Note that Rule 4 does not have any traffic, so no credit is used. Further, the credit that would be used for Rule 4 is now available for the second pass.

In accordance with embodiments disclosed herein, the second pass starts at Rule 1, and the credits are used in greedy manner until all of the available credits are consumed. Thus, credits 2, 3, and 4 are set for transmission. The process moves to Rule 2, where credits 6, 7, 8 are set for transmission. Given that 10 credits were advertised, the process runs out of credits after credit 8 is set.

FIGS. 7A, 7B, 7C, and 7D illustrate another example in accordance with embodiments disclosed herein. For the process described in the totality of FIG. 7, a simple policy is defined to prioritize videoconferencing application data in accordance with embodiments disclosed herein. Specifically, the policy is defined as: Rule 1: IMS Signal bearer traffic: Rule 2: IMS Media bearers; and Rule 3: remaining applications.