Bandwidth aware network statistics collection

Herein disclosed are systems, methods, and apparatus for controlling data usage statistics in network-connected devices. The ‘stats’ collection can be suppressed during minimum window periods, thereby reducing CPU and resources usage needed to processes the stats collection. Further, the minimum window can be a function of a link speed of the communication channel as well as a data usage proximity to a data usage warning limit. Further, stats collection can be triggered by expiration of a timer or data usage that meets a buffer threshold, where both the timer and threshold are selected based on the communication channel link speed, and buffer threshold is further a function of the data usage proximity to the warning limit.

BACKGROUND

Field of the Disclosure

The present invention relates to network communication in computing devices. In particular, but not by way of limitation, the present invention relates to collecting network status information for controlling data usage limits that various applications and device features may rely on.

Description of Related Art

Computing devices, such as smart phones, netbooks, and tablets, which utilize network connections, are now pervasive. And many of these devices may communicate via multiple communication protocols corresponding, for example, to WiFi, and a variety of different cellular communication schemes.

In many instances it is useful for the user of these devices to track network utilization. In the context of ANDROID-based devices, a “network stats service” is available, which collects the data transfer from different communication channels (e.g., WiFi and cellular data). But this service computes the data frequently and provides stats frequently whether the amount of data transferred is close or far from a data usage warning limit (hereinafter “warning limit”). These frequent stats computations cause frequent file writes and adversely affect power and performance. Moreover, the network stats service provides far more information than is needed to compare data transfer to the warning limit.

FIG. 1illustrates a method of tracking data transfer on a computing device and notifying the user when the data transfer exceeds a warning limit. The stats collection can be triggered by either expiration of a timer (e.g., 30 sec) or a level of data transfer (e.g., 10 Mb), both of which can be reset when either is reached. So, the method100can start by setting the timer (Block108) and setting a buffer limit (Block110). The buffer can then be registered (Block112) and thereby begin tracking data usage and comparing the data usage to a buffer threshold. At the same time, the timer starts and waits to expire (Block112). The timer can start and the buffer can register at the same time, and both can be triggered by stats collection. When either the timer expires or the buffer threshold is met (i.e., the user has used a certain amount of data) (Decision114), the timer can be cancelled (Block118) and the collection of stats is triggered (Block120). The data usage collected during the stats collection can be compared to the data usage warning limit (Decision122) and a user can be notified (Block124) if the warning limit has been reached. If not (Decision122), then the method100can reset the timer and buffer (Blocks108and110) and both can begin again (Block112).

The timer is preferably fixed while the buffer threshold can be a function of a distance from the data usage warning limit.

Previous attempts to solve this problem have focused on reductions in the numbers of stats collection instances, but to the detriment of the accuracy of identifying data usage warning limits. For instance, triggers for stats collection can be increased such that stats collection occurs less often, however this means that accuracy of identifying the warning limit decreases. Prior attempts did not analyze whether the link speed might affect stats collection, let alone take any steps to tie data link speed to the control of stats collection. The assumption has long been that network stats should be unaffected by link speed.

SUMMARY

Applications may rely upon data usage statistics (hereinafter “stats”) to monitor an amount of data transferred over a given communication channel and compare this to warning limits to prevent excessive usage. As noted above, existing methods for monitoring data usage perform far more instances of data usage stats collection (hereinafter “stats collection”) than is necessary to compare to a warning limit and therefore the prior art stats collection consumes excessive power and hampers device performance. To overcome these and the problems noted above, this disclosure describes partially suppressing the prior art stats collection—instead performing stats collection after a minimum window has elapsed, and before a next minimum window begins (e.g., during a period when a minimum window is not being enforced). This effectively increases the polling period for stats collection, thereby avoiding many of the unnecessary and resource-consuming stats collection instances.

One aspect of the disclosure can be characterized as a method for controlling data usage statistics in network-connected devices, the method including suppressing triggering data usage stats collection during a minimum window. The method can also include performing at least one instance of a data usage stats collection after termination of the minimum window. The method may also include, incrementally decreasing the minimum window as data usage approaches the warning limit, if the data usage stats show that a warning limit has not been met or exceeded.

Another aspect of the disclosure can be characterized as a system for controlling data usage statistics in network-connected devices. The system can include a processing portion with one or more processing components therein. The system can also include a memory coupled to the processing portion. The system can yet further include a minimum window module stored on the memory and executable on the processing portion to: perform data usage stats collection between minimum windows; upon termination of a repeating timer or meeting of a data usage buffer threshold (hereinafter “buffer threshold”) between enforcement of minimum windows, perform stats collection, wherein the timer restarts and the buffer threshold is restarted whenever either the timer expires or the buffer threshold is reached; if a data usage warning limit has been reached or exceeded, then generate a data usage warning; where, the minimum windows are a function of (1) a communication channel link speed, and (2) a proximity of data usage to the warning limit; and where the timer and the buffer threshold are functions of the communication channel link speed; and wherein the buffer threshold is a function of the proximity of the data usage to the warning limit.

Another aspect of the disclosure can be characterized as a non-transitory, tangible processor readable storage medium, encoded with processor executable code to perform a method for controlling data usage statistics in network-connected devices. The method including suppressing triggering data usage stats collection during a minimum window. The method can also include performing at least one instance of a data usage stats collection after termination of the minimum window. The method may also include, incrementally decreasing the minimum window as data usage approaches the warning limit, if the data usage stats show that a warning limit has not been met or exceeded

DETAILED DESCRIPTION

For the purposes of this disclosure, a “link speed” is a maximum data transfer rate for a communication channel. For instance, the link speed of a CAT6 connection is often higher than the actual data transfer rate since CAT6 is capable of multiple data speeds, high, medium, and low. Similarly, bottlenecks, such as the capabilities of a network interface or of a network switch, can force actual data transfer rates to be lower than the potential maximum—lower than the link speed.

Applications may rely upon data usage statistics (hereinafter “stats”) to monitor an amount of data transferred over a given communication channel and compare this to warning limits to prevent excessive usage. As noted above, existing methods for monitoring data usage perform far more instances of data usage stats collection (hereinafter “stats collection”) than is necessary to compare to a warning limit and therefore the prior art stats collection consumes excessive power and hampers device performance. To overcome these and the problems noted above, this disclosure describes partially suppressing the prior art stats collection—instead performing stats collection after a minimum window has elapsed, and before a next minimum window begins (e.g., during a period when a minimum window is not being enforced). This effectively increases the polling period for stats collection, thereby avoiding many of the unnecessary and resource-consuming stats collection instances.

However, merely refraining from performing some scheduled stats collection instances can lead to too-granular of an approach to identifying excessive data usage, especially as the data usage approaches a warning limit. In other words, the minimum window can be so long that stats may occur prior to reaching the warning limit and a next instance may occur long after the warning limit has been reached, thus leading a user to learn of the warning limit long after he/she has surpassed it and started to incur the effects of surpassing a data usage limit (e.g., cellular carrier data overage fees)—one of the reasons that warning limits are used in the first place. To prevent such inaccurate identification of the warning limit, this disclosure not only provides a minimum window, but one that is reduced as a function of proximity to the warning limit, thereby leading to an increased number of stats collection instances as data usage approaches the warning limit. In one aspect, the minimum window can even be cancelled when data usage comes within a minimum window termination threshold from the warning limit, and from that threshold onward, all scheduled stats collection instances can be carried out (i.e., no further suppression of stats collection occurs once the minimum window termination threshold is reached). In other words, before the minimum window termination threshold, stats collection can be partially suppressed, and after the minimum window termination threshold, stats collection is not suppressed.

Another aspect of this disclosure, is that more than one warning limit can be set and monitored, for instance, a different warning limit for each of multiple communication channels (e.g., a WiFi communication channel may have a higher warning limit than a cellular communication channel), or two or more warning limits for each communication channel.

To better understand the details of this disclosure, those of skill in the art will recall that prior art stats collection is not so much periodic, but rather, triggered by either (1) expiration of a timer or (2) meeting a data transfer limit (e.g., a data usage buffer threshold or “buffer threshold”). For the purposes of this disclosure, suppression of stats collection can mean turning the timer and data transfer limit off during a minimum window, or letting the timer run and monitoring the data transfer limit, but not enabling either of these to trigger stats collection during the minimum window. Said another way, the timer and monitoring of the data transfer limit may only be carried out during, or may only trigger stats collection between, minimum windows (i.e., when a minimum window is not being enforced).

Another issue is that where the communication channel link speed changes or starts at an unexpected rate, the minimum window can be too long. To account for unexpected data rates, selection of the minimum window can also consider the communication channel link speed and the minimum window can be dynamically adjusted in real-time. Similarly, the timer-based trigger for stats collection can also be based on the communication channel link speed, whereas this timer is fixed in the prior art. What is more, the data transfer limit that triggers stats collection between minimum windows can also be based on the communication channel link speed, and further can be reduced as the data usage approaches the warning limit.

The result of these various improvements to the monitoring of warning limits is that far from the warning limit, significant power savings will be seen, while closer to the warning limit, less power will be saved, but the warning limit is more likely to be accurately identified.

FIG. 2illustrates one embodiment of a method for controlling stats collection. This method200can at least partially be carried out via a modified network status module that is part of the ANDROID framework. It can use any operating system that exposes the operating system application programming interface (API) for network stats collection. In other words, the modified network stats module is a framework running atop an operating system. In particular, a minimum window module of the network stats module can carry out the method200. A primary aspect of this method200is suppressing unnecessary stats collection. In particular, the method200can refrain from collecting stats during a minimum window (Block204), where the length of the minimum window is a function of a communication channel link speed for the communication channel being monitored (e.g., a mobile device may have a communication channel for WiFi and another communication channel for cellular). During the minimum window, typical stats collection can be suppressed, and once each instance of the minimum window has completed, an instance of stats collection can be allowed to run (Block206) and the data usage for the communication channel can be compared to the data usage warning limit (Decision208). If the warning limit is reached or exceeded, then a data usage warning is generated (Block210). If the limit is not reached (Decision208), but the warning limit is approaching (Decision212), then a next instance of the minimum window can be decreased (Block214). Whether the next instance of the minimum window is decreased or not, maximum data transfer during a next instance of the minimum window can be compared to a minimum window termination threshold (Decision216), and if the maximum data transfer possible in the next instance of the minimum window will not exceed the minimum window termination threshold, then the next minimum window can be started and stats collection can again be suppressed for this next instance of the minimum window (Block204). This suppression of stats collection may continue as the data usage rises, eventually getting close enough to the warning limit that a maximum data transfer during a next instance of the minimum window meets or exceeds the minimum window termination threshold (Decision216). At this point, the minimum window can be terminated or turned off (Block218), and suppression of frequent stats collection can end. Stats collection can then be performed (Block220) in line with traditional triggers (e.g., a repeating timer and repeated comparison of data usage to a buffer threshold (Block223)) until the warning limit is reached (Decision222). Once reached, a warning can be generated (Block210) and presented to a user. In other words, stats collection can be suppressed when data usage is far from the warning limit, thereby conserving significant power, this suppression can be reduced as the data usage approaches the warning limit, and within a certain threshold of the warning limit, the suppression can be terminated, such that frequent stats collection instances can be carried out and thereby identify data usage more accurately just before the warning limit is reached.

WhileFIG. 2has been described in terms of suppression of stats collection, in some embodiments, the timer and threshold that typically trigger stats collection can continue to operate during the minimum window, but within being able to trigger stats collection during the minimum window. In other words, they may only be allowed to trigger stats collection when the minimum window is not being enforced—between the end of one instance of the minimum window and a start of a next instance of the minimum window.

In other embodiments, the timer and buffer threshold that are used to trigger stats collection can be selected based on a communication channel link speed, and in the case of the buffer threshold, also based on a proximity to the warning limit. For instance, for increased communication channel link speed, the timer and buffer threshold can be increased. In an embodiment, even after the warning limit has been reached, stats can continue to be collected where the timer and buffer threshold are tailored to the communication channel link speed (although the buffer threshold may not also be based on a proximity to the warning limit, since the warning limit has already been reached). However, where a second warning limit, higher than the first warning limit, is implemented, the buffer threshold can be selected based on the communication channel link speed and a distance from the second warning limit.

FIGS. 3 and 4illustrate a more detailed embodiment of a method for controlling stats collection.FIG. 3generally describes configuration of the system, whileFIG. 4describes run-time operation. The method300can begin by setting warning limits for all communication channels. This may begin with finding a next communication channel302(i.e., the first communication channel when the method300begins), optionally obtaining a current data used for the selected communication channel (Block306) (e.g., performing an instance of stats collection), and setting a corresponding warning limit (Block308). For instance, a user who has a data cap of 6 GB per month for cellular data could set a warning limit of 5.5 GB for the cellular communication channel. In another example, a user may reboot a device, and the device will need to get previously-used data before setting the warning limit (optional Block306). Some communication channels are not associated with warning limits, and so the Decision304only looks at metered communication channels. Blocks306and308are interchangeable in order.

Once all metered communication channels have been assigned a warning limit (Decision304), the method300can access a current communication channel link speed for a next communication channel (Block312), where this step is not limited to metered channels (since stats can be collected for more than just metered data channels). This can involve a GET command or similar method for accessing a link speed that may be embedded in packet headers or can be retrieved from a network interface, to name two non-limiting examples.

The method300can then determine if a timer, buffer threshold, and minimum window have been set for all communication channels (Decision314). If they have, then the method300can start comparing data usage to a data usage buffer threshold (e.g., register the buffer with the kernel) (Block322) and start the timer (Block324). With these running, the method300can wait for runtime events that trigger stats collection (seeFIG. 4). However, if the timer, buffer threshold, and minimum window have not all been set for all communication channels (decision314), metered or not, then the method300can set the timer, buffer threshold, and minimum window for a currently-selected communication channel based on default values found in storage (Block316). In some cases these can be fixed values, while in others, the timer, buffer threshold, and minimum window can be based on the communication channel link speed for the currently-selected communication channel. The timer, buffer threshold, and minimum window can have configurations that correspond to different communication channel link speeds for each communication channel. In other cases, these values can be dynamically related to communication channel link speed. In yet other cases, an equation with the communication channel link speed as one of its inputs can be used to determine the timer, buffer threshold, and minimum window. Setting the buffer threshold and the minimum window can also take into consideration a distance between the data that has been used and the warning limit for the selected communication channel. As the data usage approaches the warning limit, one or both of the buffer threshold and the minimum window can be reduced.

The Blocks318and320can then make adjustments to the minimum window and buffer threshold if appropriate. Details of these adjustments (e.g., calling a minimum window adjustment function or calling a buffer threshold adjustment function) can be found inFIGS. 16 and 17, respectively.

The method300can start tracking data usage and comparing this to the buffer threshold as well as start the timer (Blocks322and324). Block322can include registering the buffer with the kernel, and the kernel then begins to track data transfer on the selected communication channel. This can also be referred to as buffer limit monitoring. Once the buffer limit or buffer threshold is reached, the kernel can inform the network status module, which can trigger stats collection. While this disclosure often uses the term “buffer,” a physical buffer is not required, but rather any component that can track and indicate that a data transfer limit or threshold has been reached. Registration of the buffer is only needed when the buffer threshold changes. Otherwise, the monitoring of data usage relative to the buffer threshold can merely be restarted.

The method300can get a communication channel link speed for a next communication channel and this can continue until the timer, buffer threshold, and minimum window are set for all communication channels—metered or non-metered. Initialization can be considered complete, and the method300can shift to waiting for runtime events inFIG. 4.

If at any time during initialization (FIG. 3) or during runtime (FIG. 4) the user can change the warning limit (Block310). Any changes to the warning limit cause the method300to return to Block302. For instance, if a user sees a change in their data plan (e.g., an increase in allowable data usage), then the user may change the warning limits for one or more communication data channels and this change will be received as a warning limit changed indicator (Block310).

If at any time during initialization (FIG. 3) or during runtime (FIG. 4) the communication channel link speed changes, then the method300may receive an indication of this (Block326). Further, this enables changes to affected communication data channels without changes to non-affected communication data channels. Any changes to the communication channel link speed causes the method300to return to the timer, buffer threshold, and minimum window set for all communication channels decision (Decision314).

If at any time during initialization (FIG. 3) or during runtime (FIG. 4) a runtime event triggers a change in the minimum window (Block318) or the buffer threshold (Block320), the method300or400returns toFIG. 3, adjustments to either or both of these are made, and the timer and buffer are restarted (Blocks322and324). The method300makes calls to functions for each of Blocks318and320and then returns toFIG. 4.

The order of Blocks inFIG. 3can be altered by those of skill in the art without departing from the scope and intent of this disclosure. For instance, Blocks306and308can be arranged, as can Blocks322and324. Blocks318and320can occur at the same time, in an overlapping fashion, or sequentially. Further, any of the above Blocks can occur in a simultaneous or overlapping manner Block324is independent of Blocks318,320, and322and thus can be interspersed anywhere between or before or after these blocks. Block322can precede Block318. Block320typically occurs before Block322, although this is not required since Blocks318and320are independent of each other. Blocks322and324start at the same time.

Registering the buffer means to make an API call that both registers the buffer threshold with the kernel and starts a counting of data usage and comparing to the buffer threshold.

FIG. 4illustrates a runtime portion of the method of controlling stats collection that was initially shown inFIG. 3. Runtime begins with the waiting for triggering events fromFIG. 3, and either a buffer notification (Block402) or an expiring of the timer (Block404) can start the portion of the method shown inFIG. 4. If either trigger occurs (Block402or404), then the method300cancels the timer and stores a current value for the timer (only applicable if the buffer notification (Block402) is received) that can be used later to resume the timer from the same point (Block406). The buffer is only cancelled when the buffer notification402is received. When the timer expires404, data usage continues to be tracked and compared to the buffer threshold. One result of this is that at Decision434(to be discussed below), if the buffer threshold was the trigger (Block404), then Decision434will always result in “yes.” Said another way, the path including Blocks440,442, and444is only followed when the trigger is the timer expiration (Block404). The method300then determines whether the warning limit has been reached and if it is even valid (or has been set) (Decision408). Since stats have yet to be collected, comparison to the warning limit is made via knowledge of the data usage implied via either the buffer filling or the timer expiring. For instance, if the buffer notification (Block402) is received, the method300knows how much data has been used since a last stats collection since this value is equal to the buffer threshold. If the total of all previous data used plus the buffer threshold is greater than the warning limit, then Decision408determines that the warning limit has been reached. Similarly, if the timer expires (Block404), then the method300knows that the buffer threshold was not met yet, and since the buffer threshold is always selected so that meeting or exceeding the buffer threshold will not lead to overall data usage above the warning limit, the method300knows that the warning limit has not been reached.

If the warning limit is reached (Decision408), and if the minimum window is still in force, then the method300can cancel the minimum window (Block410). Whether the minimum window needs to be cancelled or was previously cancelled, the method300then can collect stats (Block412) and generate a data usage warning (Block414). If there is only a single warning limit, then the method300then resets the timer, buffer, minimum window, and returns to the initialization (FIG. 3) via Block328and begins to get communication channel link speeds and set the timer, buffer threshold, and minimum window. If there is a second or more warning limits, then the method300resets the timer, buffer, minimum window, and returns to the initialization (FIG. 3) via optional block310and begins to reset warning limits.

If the warning limit is not reached (Decision408), then the method300calls a minimum window adjustment function (Block318; seeFIG. 16) and a buffer adjustment function (Block320; seeFIG. 17). The minimum window adjustment function (Block318) adjusts the minimum window size if the data usage has reached a minimum window termination threshold (e.g., seeFIG. 11) and/or as the data usage approaches the warning threshold (e.g., seeFIG. 8). In one embodiment,FIG. 16provides further details of the minimum window adjustment function. The buffer adjustment function (Block320) adjusts the buffer size if the data usage is approaching the warning limit.

The particulars of the minimum window adjustment function (Block318) can be seen inFIG. 16. In particular, when the method300calls this minimum window adjustment function (Block318), a next minimum window data usage can be estimated based on the current minimum window duration (Block418). In other words, the duration of the minimum window can be multiplied by the communication data channel speed to give a maximum data usage that might occur in the next minimum window. If this value, when added to all previous data usage, is equal to or greater than the warning limit (Decision420), then the function reduces the minimum window size (Block422) and then Block318calls Block422. In an embodiment, this reduction in the minimum window can be based on the communication link speed. Once the adjustment has taken place, a comparison of the minimum window to a minimum window termination threshold can be made (Decision424). If the minimum window is smaller than the minimum window termination threshold (e.g., the data usage has approached the warning limit), then the function cancels the minimum window for the warning limit (Block426). Where other warning limits for the communication channel exist, the minimum window may be reinstated. However, where only a single warning limit exists, this cancellation may indicate an end of the minimum window for the method300. If the minimum window is equal to or greater than the minimum window termination threshold (Decision424), the function can return to an estimation of data usage during a next minimum window (Block418). Since the minimum window has been reduced, Block418is likely to generate an estimate that does not meet or exceed the warning limit (Decision420), and the function can proceed without further reduction in the minimum window. However, in some cases, multiple reductions in the minimum window may be needed before the minimum window can be reinstated. In some instance, the reduction in the minimum window (Block422) can include reducing the minimum window by half, while in other instances, other reductions can be used (e.g., constant reductions, dynamic reductions, exponential reductions, although it may also be optimized for a given network technology and device chipset).

The particulars of the buffer adjustment function (Block320) can be seen inFIG. 17. In particular, when the method300calls this buffer adjustment function (Block320), the warning limit can be compared to cumulative data usage added to a size of the buffer threshold (Decision428), and as long as this sum is less than the warning limit, the function does not adjust the buffer threshold. In other embodiments, algorithms or equations other than a sum function can be used. For instance, the current usage and buffer threshold could be compared to a delta value or a dynamic increase or decrease in a value such that the algorithm or equation can be applied across different systems. In another example, the data usage can be used in an equation or algorithm other than a mere sum with the buffer threshold size. In some instances, other values can be added to the data usage and buffer threshold and compared to the warning limit. However, if the data usage plus a size of the buffer threshold is equal to or greater than the warning limit (Decision428), then the function reduces the buffer threshold based on the communication channel link speed (Block430). The reduction (Block430) can direct the method300to the buffer adjustment function (Block320) inFIG. 3. The adjusted buffer is registered and begins tracking data usage (Block432), and the buffer adjustment function (Block320) can again compare the current usage added to the reduced buffer threshold, to the warning limit. If the warning limit is still equaled or exceeded, then further buffer threshold reduction may be in order. However, if the reduction was sufficient to ensure that data usage to meet the next buffer threshold will not lead to the warning limit being reached (Decision428), then the buffer adjustment function (Block320) can exit and return to a determination as to whether the minimum window is being enforced (Decision434). It should be noted that Blocks320and318are illustrated in parallel because they are independent of each other.

The minimum window can be considered enforced within any of multiple minimum windows, and between those minimum windows the minimum window is not being enforced. Expiration of the minimum window leads to disarming of the minimum window (Block448), and the period following this until the minimum window is rearmed (Block444) can be considered a period of non-enforcement of the minimum window. This means that stats can be collected while the minimum window is not enforced.

If the minimum window is not being enforced (Decision434), then the method300can collect stats (Block440), restart the timer (Block442), and begin enforcing the minimum window again (Block444). If the minimum window is still being enforced (Decision434), then the method300can resume the timer from the stored timer value (Block436) that was stored in Block406.

Once the timer has been resumed (Block436), or the timer has been restarted (Block442) and the minimum window is resumed (Block444), then the method300begins waiting for a timer or buffer threshold event again (Block438).

FIG. 4illustrates one exemplary order of operations, but those of skill in the art can reorder the visualized steps without departing from the scope and intent of the disclosure. For instance, Blocks410,412, and414can be reordered. Blocks442and444can be reordered. Block446always occurs between Block438and Block416or between Block438and Block404. In other words, the minimum window only expires after the wait for event Block and before either of the trigger Blocks402and404.

FIGS. 5-10illustrate timing charts for the buffer threshold, timer, communication channel link speed, minimum window, stats collection, and data usage under a variety of different situations. In each plot, the x-axis represents time. In each of these charts, one will notice that the timer typically takes longer to expire than the minimum window. Also, while the timer typically takes longer to expire than it takes data usage to meet the buffer threshold, in certain circumstances the buffer threshold can take longer to be met than the timer expiration. The buffer threshold is not illustrated in these timing charts, but rather a time that it takes the buffer threshold to be met. Thus, the size of the pulses in the buffer timelines is a function both of a rate of data usage and the value of the buffer threshold. One will also notice that stats collection only occurs between minimum windows and only occurs after either an instance of the buffer threshold being met or the timer expiring. Typically, the minimum window resumes or is enforced after an instance of stats collection. Additionally, the timer restarts every time that stats are collected. This means that the length of the timer may appear shorter than it really is in many of the timing charts since the timer is restarting before it expires.

FIG. 5illustrates all of these timing charts for a typical situation where communication channel link speed does not change. The stats collection, triggered by either meeting of the buffer threshold or an expiration of the timer and after expiration of an instance of the minimum window (when the minimum window is not being enforce; between minimum windows), occurs five times during this plot. In this instance, the data usage is such that the buffer threshold is met at a faster rate than an expiration of the timer. This examples shows typical operation of the minimum window when the data usage is far from the warning limit.

This example chart is not necessarily drawn to scale. For instance, in practice, the timer may expire every 30 minutes (e.g., on the order of tens of minutes), whereas the buffer threshold may be met in a matter of seconds. Further, the minimum window may be on the order of seconds. However, these are just examples, and implementation may involve different values for each.

FIG. 6illustrates another timing chart for situation where the rate of data usage changes, even though the link speed remains constant. This is seen in the change in the length of time that it takes the buffer threshold to be met. Early in the chart, data usage is low and the buffer threshold takes longer than the timer expiration to be met. Yet, after the first instance of stats collection, the data usage rate apparently increases since the buffer threshold begins being met much quicker than the timer expiration period. One notices that this is not the result of a change in link speed since link speed stays the same. One also notices that the second stats collection does not occur immediately after the end of the fourth minimum window. Rather, some time elapses before either the buffer threshold being met or expiration of the timer triggers stats collection. Once stats collection takes place, the minimum window is again resumed or enforced. In other words, when the minimum window is not enforced, the system waits until a stats collection is triggered before resuming the minimum window. As inFIG. 5, this example assumes that the data usage is far from the warning limit.FIG. 7illustrates one example of a timing chart when the data usage approaches and exceeds the warning limit.

FIG. 7illustrates a minimum window and buffer threshold being reduced as the data usage approaches the warning limit. Here the minimum window is largest when the data usage is well below or far from the warning limit and decreases as the data usage approaches the warning limit (recall Block422inFIG. 4). Similarly, the buffer threshold decreases as the data usage approaches the warning limit (visible as a reduction in the time taken to meet the buffer threshold). Each of the minimum window and the buffer threshold can decrease by a factor of 2, 3, 4, exponentially, or via any other algorithm known to those of skill in the art. Once the warning limit is reached, the minimum window, timer, and buffer threshold are all reset to default values or based on a path configuration for the system.

FIG. 8provides more detail as to how the minimum window is reduced whileFIG. 9provides more detail as to how the buffer threshold is reduced.

The relative time that it takes the buffer threshold to be met, the timer to expire, and the minimum window to expire are not necessarily drawn to scale, and in practice, the timer will often be much longer than the minimum window.

FIG. 8illustrates how a reduction of the minimum window is determined. After the first illustrated minimum window, an instance of stats collection occurs (triggered by an end of the timer). At relatively the same time, a predicted data usage during a next minimum window can be predicted (recall Block418inFIG. 4), and compared to the warning limit (recall Block420inFIG. 4). In this case the predicted data usage exceeds the warning limit. In such a case, the minimum window can be reduced (not shown; recall Block422inFIG. 4), and this prediction can be performed again to ensure that the maximum data usage during the next minimum window will not exceed the warning limit. The purpose of such prediction and minimum window reduction (e.g., Blocks418,420,422) is to attempt to ensure that stats are collected prior to exceeding the warning limit. In some cases it may take multiple reductions before the minimum window can be resumed, while in other cases only a single reduction may take place.

FIG. 9illustrates how the timing of the buffer threshold reduction is determined. In particular, the buffer threshold can be met at ti, at which point an estimate of the maximum data usage that may occur en route to meeting a next buffer threshold (e.g., see cross hatched buffer threshold rectangle) can be performed. If this estimated data usage, when added to all previous data usage, is below the warning limit, then no change to the buffer threshold occurs (recall Block428inFIG. 4). However, if the estimated data usage, when added to all previous data usage, is equal to or exceeds the warning limit (as illustrated) (recall Block428inFIG. 4), then the buffer threshold can be reduced (the reduced buffer thresholds are not illustrated) (recall Block430inFIG. 4).

FIG. 10illustrates adjustment to the buffer threshold, timer, and minimum window in response to a change in the communication channel link speed. When the communication channel link speed change occurs (from a first to a second speed, where the second speed is greater than the first), the buffer threshold, timer, and minimum window are all reset based on the second communication channel link speed and restarted. This reset includes accounting for the change in data usage that may result from increased or decreased throughput. As illustrated, the communication channel link speed increases from a first value to a second value, and as a result the size of the buffer threshold, and minimum window can be increased, while a size of the timer decreases (e.g., to maintain precision of identifying the warning limit). The adjusted minimum window even restarts prior to a time when the interrupted minimum window would have completed as shown via dashed lines. The illustrated timing assumes that the data usage is far from the warning limit, and hence the buffer threshold and minimum window are not adjusted as a function of data usage proximity to the warning limit.

FIG. 11illustrates a situation where the minimum window is cancelled once the data usage comes within a minimum window termination threshold. In particular, once the data usage meets the minimum window termination threshold, the second illustrated minimum window is cancelled mid-stream, and stats collection begins without suppression thereafter (e.g., at each expiration of the timer and each instance of the buffer threshold being met). In a non-illustrated embodiment, the minimum window termination threshold can be a time. For instance, a time at which the data usage is expected to reach the warning limit can be used to extrapolate a time when the minimum window should be cancelled, thereby allowing more frequent stats collection close to the warning limit.

FIG. 12illustrates two plots of processor current consumption as a function of time showing the prior art stats collection versus the herein disclosed stats collection. The herein disclosed suppression of stats collection greatly reduces power consumption over the prior art.

Referring toFIG. 13, shown are components of an exemplary computing device. As shown the computing device may include one or more applications1302at a highest level of abstraction and one or more network-related communication components1308(e.g., WiFi, Bluetooth, LTE, and 3G-cellular) at a hardware level. Also shown between the applications1302and the network components1308are a network status module1304that includes a minimum window module1306.

The applications1302may include any of a variety of application that utilize one of the network components1308to send and receive data. For example, the applications1302may include gaming applications, a web browser, a weather-related application, stock-tracking application etc. The network status module1304in this embodiment may be realized my modifying an existing network status component in prior versions of the ANDROID framework to include the minimum window module1306. And although not depicted, one of ordinary skill in the art will appreciate that the computing device may include several other components such as additional hardware, devices drivers, etc.

The applications1302may rely upon network stats about data usage to provide details about actual usage and a warning about excessive usage or usage that exceeds a threshold (e.g., to a user). In the depicted embodiment, the minimum window module1306may be used to define a minimum window per data rate/protocol during which stats collections is suppressed. In an embodiment, the buffer threshold can depend on the communication channel link speed. For example, 3G and LTE communication channels may each have a different buffer threshold for triggering stats collection. In an embodiment, the faster the communication channel, the larger the buffer threshold. Similarly, the timer can be decreased for higher throughput communication channels.

FIG. 14shown is a block diagram depicting physical components that may be utilized to realize the minimum window module. The components ofFIG. 14are the same as those ofFIG. 13, and thus identical components are not numbered. However, here, the minimum window module includes the following functions: perform data usage stats collection between minimum windows (Block1452); upon termination of a repeating timer or filling of a data usage buffer between enforcement of minimum windows, perform stats collection, wherein the timer restarts whenever either the buffer threshold is met or the timer expires (Block1454); and if a data usage warning limit has been reached or exceeded, then generate a data usage warning (Block1456).

The methods described in connection with the embodiments disclosed herein may be embodied directly in hardware, in processor-executable code encoded in a non-transitory tangible processor readable storage medium, or in a combination of the two. Referring toFIG. 15for example, shown is a block diagram depicting physical components that may be utilized to realize the minimum window module1306(and the network status component1304generally) according to an exemplary embodiment. As shown, in this embodiment a display portion1512and nonvolatile memory1520are coupled to a bus1522that is also coupled to random access memory (“RAM”)1524, a processing portion (which includes N processing components)1526, an optional field programmable gate array (FPGA)1527, and a transceiver component1528that includes N transceivers. Although the components depicted inFIG. 15represent physical components,FIG. 15is not intended to be a detailed hardware diagram; thus many of the components depicted inFIG. 15may be realized by common constructs or distributed among additional physical components. Moreover, it is contemplated that other existing and yet-to-be developed physical components and architectures may be utilized to implement the functional components described with reference toFIG. 15.

This display portion1512generally operates to provide a user interface for a user, and in several implementations, the display is realized by a touchscreen display. In general, the nonvolatile memory1520is non-transitory memory that functions to store (e.g., persistently store) data and processor-executable code (including executable code that is associated with effectuating the methods described herein). In some embodiments for example, the nonvolatile memory1520includes bootloader code, operating system code, file system code, and non-transitory processor-executable code to facilitate the execution of methods described with reference toFIGS. 2-4described further herein.

In many implementations, the nonvolatile memory1520is realized by flash memory (e.g., NAND or ONENAND memory), but it is contemplated that other memory types may be utilized as well. Although it may be possible to execute the code from the nonvolatile memory1520, the executable code in the nonvolatile memory is typically loaded into RAM1524and executed by one or more of the N processing components in the processing portion1526.

The N processing components in connection with RAM1524generally operate to execute the instructions stored in nonvolatile memory1520to enable less-power-hungry stats collection. For example, non-transitory, processor-executable code to effectuate the methods described with reference toFIGS. 2-4may be persistently stored in nonvolatile memory1520and executed by the N processing components in connection with RAM1524. As one of ordinarily skill in the art will appreciate, the processing portion1526may include a video processor, digital signal processor (DSP), micro-controller, graphics processing unit (GPU), or other hardware processing components or combinations of hardware and software processing components (e.g., an FPGA or an FPGA including digital logic processing portions).

In addition, or in the alternative, the processing portion1526may be configured to effectuate one or more aspects of the methodologies described herein (e.g., the methods described with reference toFIGS. 2-4). For example, non-transitory processor-readable instructions may be stored in the nonvolatile memory1520or in RAM1524and when executed on the processing portion1526, cause the processing portion1526to monitor a warning limit and link speed, and adjust a buffer threshold and minimum window size based on these, among other adjustments. Alternatively, non-transitory FPGA-configuration-instructions may be persistently stored in nonvolatile memory1520and accessed by the processing portion1526(e.g., during boot up) to configure the hardware-configurable portions of the processing portion1526to effectuate the functions of the minimum window module1306.

The input component1530operates to receive signals (e.g., a link speed indicator) that are indicative of one or more aspects of the communication channel. The output component generally operates to provide one or more analog or digital signals to effectuate an operational aspect of the minimum window module1306.

The depicted transceiver component1528includes N transceiver chains, which may be used for communicating with external devices via wireless or wireline networks. Each of the N transceiver chains may represent a transceiver associated with a particular communication scheme (e.g., WiFi, Ethernet, Profibus, etc.).

As used herein, the recitation of “at least one of A, B and C” is intended to mean “either A, B, C or any combination of A, B and C.” The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present disclosure. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the disclosure. Thus, the present disclosure is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.