Dynamic scheduling of a radio unit that executes multiple wireless protocols

Abstract

Network control, comprehensive: a network interface that includes a radio unit; a processing unit; and a storage device in communication link with the processing unit, wherein the storage device comprises instructions which, when executed by the processing unit, enable the network controller to: To compare actions of multiple network software stacks, where each action includes a requested start time, an estimated action duration, a slack time, and a priority; to select one of the actions from the multiple network software stacks based on the requested start time, the estimated action duration, the slack time, and the priority of each action; and to schedule the execution of the selected action via the network interface.

Description

[0001] This patent application claims priority to U.S. Provisional Patent Application Serial No. 62 / 538,036, filed July 28, 2017, and U.S. Provisional Patent Application Serial No. 15 / 842,492, filed December 14, 2017, the disclosures of which are incorporated herein by reference in their entirety. Field of the invention

[0002] The present disclosure describes systems and methods that allow the operation of multiple network protocols with a single radio unit. General state of the art

[0003] The widespread use of networks has presented a number of challenges for those seeking to develop devices that utilize multiple network protocols. For example, Wi-Fi, ZigBee, Thread, and Bluetooth Low Energy are widely used network protocols. In many situations, a device supports more than one type of network protocol. For example, a mobile phone may have a Wi-Fi interface, a Bluetooth interface, and a cellular interface. Furthermore, most computing devices, including tablets and laptops, support at least two different network protocols.

[0004] Due to the need to support multiple network protocols with a single device, there is a desire to use a single radio unit to operate all these wireless protocols. This minimizes cost, space requirements, and energy consumption.

[0005] However, each protocol has its own specific timing requirements. Certain protocols allow a device to remain unresponsive for long periods of time. For example, ZigBee® uses the concept of a sleeping terminal, where a device can be in a low-power state for several minutes. During this time, it will not respond to any attempts to access it. On the other hand, other protocols have a connection timeout period; if a device does not receive a packet from the sender within this connection timeout period, the connection is dropped.

[0006] Due to these protocol differences, developing a scheduler that can handle multiple wireless protocols is challenging. It would be advantageous to have a scheduler that could receive send and receive requests from different network protocol stacks and schedule these requests in an optimal manner.

[0007] US 2013 / 0295978 A1 discloses a method comprising receiving, at a user device, a request having a priority for a radio frequency (RF) resource from one of a plurality of wireless radio stacks, the request having a time slot, and pre-reserve the RF resource for the received request if the time slot of the received request is fixed and does not conflict with that of an existing pre-reserved request, or the priority of the request is higher than that of the existing, conflicting pre-reserved request. The method also comprises reserving the RF resource for the received request if the time slot of the received request does not conflict with that of a pre-reserved request from another radio stack, or the priority of the received request is higher than that of the conflicting pre-reserved request.

[0008] US 2008 / 0200120 A1 relates to a system for optimizing the operation of a plurality of radio modules integrated into a wireless communication device (WCD) connected as a slave in a low-power wireless network, with a low-power device acting as the master of the wireless network. The timing of communication between master and slave may be determined by the master, and as a result, the WCD may employ a control strategy to enable substantially simultaneous active communication in one or more of the plurality of radio modules while continuing to operate under the parameters determined by the low-power master device. Brief description

[0009] A system and method for intelligently scheduling actions from multiple network software stacks is disclosed. The timer uses information such as the requested start time, slack time, action duration, and priority to schedule actions between multiple network software stacks. In some embodiments, the timer attempts to maximize radio unit utilization by prioritizing actions not only based on their given priority, but also based on their duration and the ability of other actions to tolerate a delay in their execution.

[0010] According to one embodiment, a network controller is disclosed. The network controller comprises a network interface including a radio unit; a processing unit; and a storage device in communication with the processing unit, the storage device comprising instructions that, when executed by the processing unit, enable the network controller to: compare actions from a plurality of network software stacks, each action including a requested start time, an estimated action duration, a slack time, and a priority; select one of the actions of the plurality of network software stacks based on the requested start time, the estimated action duration, the slack time, and the priority of each action; and schedule execution of the selected action by the network interface.In certain embodiments, the instructions enable the processing unit to calculate a latest allowable start time for a first action by summing the requested start time and the slack time of the first action. In certain embodiments, the instructions enable the processing unit to compare the latest allowable start time of the first action with a sum of the current time and the estimated action duration of a second action.In certain embodiments, the instructions enable the processing unit to schedule the second action ahead of the first action if the sum is less than the latest allowed start time and, if the second action is not scheduled, enable the processing unit to calculate a latest allowed start time for the second action by adding the requested start time and the slack time of the second action, and to compare the latest allowed start time of the second action to a sum of the current time and the estimated action duration of the first action.

[0011] In another embodiment, a method for scheduling actions for multiple network software stacks is disclosed. The method includes comparing actions from multiple network software stacks, each action including a requested start time, an estimated action duration, a slack time, and a priority; selecting one of the actions from the multiple network software stacks based on the requested start time, the estimated action duration, the slack time, and the priority of each action; and scheduling, by the network interface, execution of the selected action.

[0012] In another embodiment, a software program disposed on a non-transitory storage medium is disclosed. The software program includes instructions for comparing actions from multiple network software stacks, each action including a requested start time, an estimated action duration, a slack time, and a priority; selecting one of the actions from the multiple network software stacks based on the requested start time, the estimated action duration, the slack time, and the priority of each action; and scheduling execution of the selected action by a network interface.

[0013] In another embodiment, a network controller is disclosed.The network controller comprises a network interface comprising a radio unit; a processing unit; and a storage device in communication with the processing unit, the storage device comprising instructions that, when executed by the processing unit, enable the network controller to: accept actions from multiple network software stacks, each action including a requested start time, an estimated action duration, a slack time, and a priority; determine that an ongoing action has exceeded or will exceed the action duration; check the priority of a second action that is next scheduled for execution; allow the ongoing action to continue if its priority is not lower than the priority of the second action; and terminate the ongoing action if its priority is lower than the priority of the second action.

[0014] In another embodiment, a method for scheduling actions from multiple network software stacks is disclosed. The method includes accepting actions from multiple network software stacks, each action including a requested start time, an estimated action duration, a slack time, and a priority; determining that an ongoing action has exceeded or will exceed the action duration; checking the priority of a second action that is next scheduled for execution; allowing the ongoing action to continue if its priority is not lower than the priority of the second action; and terminating the ongoing action if its priority is lower than the priority of the second action.

[0015] In another embodiment, a software program disposed on a non-transitory storage medium is disclosed. The software program includes instructions for accepting actions from multiple network software stacks, each action including a requested start time, an estimated action duration, a slack time, and a priority; determining that an ongoing action has exceeded or will exceed the action duration; checking the priority of a second action that is next scheduled for execution; allowing the ongoing action to continue if its priority is not lower than the priority of the second action; and terminating the ongoing action if its priority is lower than the priority of the second action. Brief description of the drawings

[0016] For a better understanding of the present disclosure, reference is now made to the accompanying drawings in which like elements are designated by like reference numerals and in which: Fig. 1 is a block diagram of the low-energy grid control; Fig. Figure 2 illustrates the interface between the timer and the network protocol software stacks; Fig. 3 represents the information provided to the timer; Fig. 4 illustrates a flowchart showing the operation of the timer; Fig. 5 illustrates an example of the operation of the timer; and Fig. Figure 6 illustrates a flowchart showing the anticipatory nature of the timer. Detailed description

[0017] Fig. 1 shows a block diagram of a multi-protocol network controller. Throughout this disclosure, the term "multi-protocol network controller" is used to refer to any controller that operates with multiple network protocols. In certain embodiments, all network protocols may operate in the same frequency range, such as WIFI, ZIGBEE®, Thread, Bluetooth®, and Bluetooth Low Energy (BLE). Other network protocols layered on top of IEEE 802.15.4 would also operate in the same frequency range. It should be understood that the methods and systems described herein are applicable to any frequency range. In addition, this disclosure is also applicable to a radio capable of operating in two or more different frequency bands. Thus, multi-protocol network controller is not limited to controllers that implement multiple protocols operating in the same frequency band.Rather, network controllers that implement two or more network protocols that use different frequency ranges also fall within the scope of the disclosure.

[0018] Fig. 1 shows a block diagram of a representative multi-protocol network controller 20. The multi-protocol network controller 20 includes a processing unit 21 and an associated storage device 22. This storage device 22 contains instructions that, when executed by the processing unit, enable the multi-protocol network controller 20 to perform the functions described herein. This storage device 22 may be non-volatile memory, such as FLASH ROM, electrically erasable ROM, or other suitable devices. In other embodiments, the storage device 22 may be volatile memory, such as RAM or DRAM. In all embodiments, the storage device 22 is a non-transitory storage medium. The multi-protocol network controller also includes a network interface 23, which is a wireless interface having an antenna 25.The network interface also includes a radio unit 24, which may include baseband processing and lower MAC layer processing. The multi-protocol network controller may include a second storage device 26 in which data received by the network interface 23 and data to be transmitted by the network interface 23 are stored. This second storage device 26 is typically a volatile memory. The processing unit 21 has the ability to read and write to the second storage device 26 in order to communicate with the other nodes in the networks. Although not shown, each multi-protocol network controller 20 also has a power supply, which may be a battery or a connection to a permanent power source, such as a wall outlet.

[0019] Within the multi-protocol network controller 20, there are multiple network protocol software stacks. Each software stack is responsible for maintaining a connection to the other devices in the network that use that protocol. Furthermore, each software stack is responsible for receiving, analyzing, and responding to incoming packets received using that protocol. Each software stack can perform all higher-level MAC processing. Essentially, each network protocol software stack operates independently of the other software stacks. For example, each can have a defined area in the second storage device 26 where incoming and outgoing packets are stored. These network software stacks are software programs that can be stored in the storage device 22 and executed by the processing unit 21.

[0020] However, the multi-protocol network controller 20 utilizes only a single network interface 23. Thus, although the software stacks operate independently, they share common hardware components. In this embodiment, the software stacks share a common resource, specifically the network interface 23 and its associated radio unit 24.

[0021] Fig. Figure 2 illustrates the interaction between the software stacks and the network interface 23. In this figure, a Bluetooth software stack 100 and a ZigBee software stack 110 are present in the multi-protocol network controller 20. These two software stacks communicate with a timer 200, which controls the actions of the network interface 23. Thus, the timer 200 is located between the higher MAC (located in the software stacks) and the lower MAC (located in the network interface 23). Although in Fig. While two software stacks are illustrated in Figure 2, it should be understood that the disclosure is not limited to this embodiment. Rather, timer 200 may work with any number of software stacks.

[0022] While in certain embodiments, a single processing unit is used to execute the code associated with the network software stacks and the timer, other embodiments are also possible. For example, the code associated with each network software stack may be executed by a dedicated processing unit. Furthermore, the code associated with the timer 200 may be executed by a processing unit that is different from the processing unit used to execute the code for one or more of the network software stacks. Thus, while the system is described in Fig. 1, the timer is not restricted to operation exclusively in single processing unit environments.

[0023] The timer 200 is responsible for many functions. First, it is responsible for configuring the network interface 23 for the requested protocol. For example, before the Bluetooth software stack 100 can send a packet, the radio unit 24 must be configured to operate using wireless parameters associated with the Bluetooth protocol. Similarly, if the Bluetooth software stack wants to monitor the shared medium (e.g., the air) for incoming packets, the radio unit 24 must be correctly configured. The timer 200 is responsible for this configuration activity.

[0024] The timer 200 is also responsible for selecting the next operation to be performed from those requested by the software stacks. For example, the Bluetooth software stack 100 may include a list of actions that must be performed. These actions may include sending a message to one or more destinations, configuring the radio to listen for an expected incoming message, and others. For example, BLE is very time-sensitive, and the Bluetooth software stack 100 schedules transmissions at very specific times and also schedules small receive windows at times when it expects an incoming packet. The ZigBee software stack 110 may have a similar list of actions.

[0025] In certain embodiments, each software stack is responsible for prioritizing actions for the respective network protocol. In this case, timer 200 must choose between the next actions requested by each software stack. In other embodiments, timer 200 may choose between a larger number of actions requested by each software stack.

[0026] In one embodiment, each network stack is responsible for providing certain information to the timer 200. Fig. 3 shows a representation of the information that can be provided to the timer 200, according to one embodiment. One of this information is the action type 300. The action type 300 can be a send request, a receive request, or another action. The priority 310 indicates the importance of the action. A higher priority indicates that the action is more important than a lower priority action. The requested start time 320 is an indication of when the software stack requests that the action take place. A value of 0 can be used to indicate that the action should take place at the current time. Higher values ​​indicate that the action should be delayed before taking place. The action duration 330 is an estimate of the length of time the requested action will require.For example, the duration of a send action can be estimated based on the number of bytes to be sent and the transmission rate of the network protocol in question. The slack time 340 is the maximum length of time after which the action may begin after its requested start time. For time-critical actions, this value can be zero. In other embodiments, the slack time can be set to a higher value, thereby granting the timer 200 more insight and flexibility in coordinating various actions.

[0027] This information can be used by the timer 200 to intelligently schedule the actions of the multiple software stacks to minimize the number of failed attempts.

[0028] Assume that the first action has an action duration of 500 milliseconds, a priority of 4, a requested start time of 0, and a slack time of 300 milliseconds. Assume that the second action has an action duration of 100 milliseconds, a priority of 3, a requested start time of 0, and a slack time of 200 milliseconds.

[0029] Typical timers use priority to choose between actions to be executed. For example, since a first action has a priority of 4 and a second action has a priority of 3, the first action will be scheduled before the second. However, adding additional information allows the timer to make a more intelligent choice.

[0030] Considering the information given above, it is evident that the second action can be completed in 0.1 seconds, which is less than the maximum slack time of 0.3 seconds exhibited by the first action. In other words, the second action can be performed before the first action, and both will meet their timing requirements. However, if the first action is performed first, it will be completed in 0.5 seconds, which is longer than the maximum slack time of 0.2 seconds exhibited by the second action. Therefore, if the first action is performed first, the second action must fail.

[0031] Thus, in one embodiment, the timer for a first action determines the requested start time 320 and the slack time 340. It then calculates the sum of these values ​​to determine a latest allowable start time for the first action. This latest allowable start time of the first action is then compared to the action duration 330 of a second action. If the second action can be completed before the latest allowable start time, the second action is scheduled ahead of the first action. In certain embodiments, this scheduling decision is made regardless of the relative priorities of the two actions. In other words, even though the first action has a higher priority than the second action, the second action is scheduled first.

[0032] In other words, if (current time + action duration 330 of the second action) is less than (requested start time 320 + slack time 340 of the first action), then the second action is scheduled before the first action. Note that this comparison only needs to be made if the priority of the second action is less than or equal to the priority of the first action. This is because, by default, higher-priority actions are scheduled before lower-priority actions.

[0033] This algorithm is in Fig. 4. In process 400, timer 200 compares the actions that are at the top of each queue for each respective network software stack. For this example, assume that the requested start time of each action is the current time. Timer 200 then determines whether (current time + action duration 330 of the second action) is less than (requested start time 320 + slack time 340 of the first action), as shown in process 410. If true, timer 200 schedules action 2 next, as shown in process 420. If timer 200 determines that (current time + action duration 330 of the second action) is not less than (requested start time 320 + slack time 340 of the first action), timer 200 next compares the priorities of the two actions, as shown in process 430.If the priority of action 2 is higher than the priority of action 1, then timer 200 schedules action 2 next, as shown in process 420. Otherwise, timer 200 schedules action 1 next, as shown in process 440. Finally, the queues are updated to reflect that one of the two actions has been scheduled, as shown in process 450. The algorithm then repeats.

[0034] In other embodiments, the algorithm described in Fig. 4, further steps occur if the result of process 410 is not "true." In these embodiments, instead of comparing the priorities of the two actions, timer 200 may then perform a second comparison in which it determines whether (current time + action duration 330 of the first action) is less than (requested start time 320 + slack time 340 of the second action). If this comparison is "true," timer 200 schedules the first action as shown in process 440. However, if (current time + action duration 330 of the first action) is not less than (requested start time 320 + slack time 340 of the second action), then the timer has determined that one of the actions must fail. In this case, timer 200 will schedule the action with the higher priority. If the actions have the same priority, the timer 200 may use other criteria to determine which action should be scheduled.

[0035] Assume that the software stacks each present a queue of actions to the timer 200. Assume that this queue is a sequentially ordered list in which the most important or time-critical action is placed in the queue before a less important or time-critical action. Fig. Figure 5 shows two queues that may belong to a Bluetooth software stack 100 or a ZigBee software stack 110. Each queue contains four actions, ordered sequentially and containing all the information described above.

[0036] Timer 200 begins by comparing the positions at the top of the two queues. In this action, Bluetooth action 1 has a lower priority than ZigBee action 1. However, Bluetooth action 1 cannot be completed before the latest allowed start time for ZigBee action 1. Therefore, Bluetooth action 1 must be scheduled after ZigBee action 1. However, Bluetooth action 1 has a slack time of 0. Since it cannot be scheduled immediately, Bluetooth action 1 must fail.

[0037] The timer then compares the new position at the top of the Bluetooth software stack 100 (i.e., Bluetooth Action 2) with ZigBee Action 1. Since Bluetooth Action 2 can be completed before the latest allowed start time of ZigBee Action 1, it is scheduled before ZigBee Action 1.

[0038] The timer then compares the new position at the top of the Bluetooth software stack 100 (i.e., Bluetooth Action 3) with ZigBee Action 1. Since Bluetooth Action 3 can be completed before the latest allowed start time of ZigBee Action 1, it is scheduled before ZigBee Action 1.

[0039] The timer then compares the new position at the top of the Bluetooth software stack 100 (i.e., Bluetooth Action 4) with ZigBee Action 1. Since Bluetooth Action 4 cannot be completed before the latest allowed start time of ZigBee Action 1, ZigBee Action 1 is scheduled next.

[0040] The timer then compares the position at the top of the Bluetooth software stack 100 (i.e., Bluetooth Action 4) with the new position at the top of the ZigBee software stack 110 (i.e., ZigBee Action 2). Since Bluetooth Action 4 can be completed before the latest allowed start time of ZigBee Action 1, Bluetooth Action 4 is scheduled next.

[0041] Thereafter, the remaining positions in the queue for the ZigBee software stack 110 are scheduled in sequence.

[0042] Fig. Figure 5 also shows a timeline indicating where each action was scheduled in the two queues. Note that using slack time, action duration, and requested start time, timer 200 was able to successfully schedule seven of the eight actions in the two queues.

[0043] In contrast, a typical timer would have scheduled ZigBee action 1 first due to its higher priority. However, this scheduling would have prevented the first three Bluetooth actions from being scheduled.

[0044] Thus, the timer disclosed herein represents an improvement over existing timers in that it is capable of successfully scheduling actions received from multiple network software stacks.

[0045] Although Fig. 5 shows the timer 200 and the queues for each network software stack. In certain embodiments, the timer 200 does not have access to the actions in each of the queues. For example, the timer 200 may only have access to one action from each network software stack. Based on the rules outlined above, the timer 200 selects one of the two actions to be scheduled next. Once that action is completed, the timer 200 selects again between the two actions at the top of the respective stacks. In addition, it is understood that even if Fig. Figure 5 shows two network software stacks, showing that this concept can be extended to any number of network software stacks and network protocols. In this case, the timer performs the comparison between all actions located at the top of their respective queues.

[0046] Although the above disclosure describes the operation of timer 200 when actions reliably determine their duration, this is not possible in some cases. During actual operation, actions may not be executed within their expected runtime. For example, the CSMA algorithm used by ZigBee for transmitting packets uses random backoff, and therefore, it is not possible to predict how much time an incoming receive packet or an outgoing transmit packet will require. Accordingly, timer 200 may need to make a decision about what to do when an action exceeds its allocated duration.

[0047] In certain embodiments, timer 200 may simply allow any action currently in progress (i.e., an in-progress action) to continue running until completion. In another embodiment, timer 200 may determine the priority of the action being delayed by the in-progress action. If the delayed action has a higher priority than the in-progress action, the in-progress action is aborted, causing it to fail. The higher-priority action is then scheduled for execution in an effort to ensure that the highest-priority action is always executed when required. If the delayed action does not have a higher priority, the in-progress action is allowed to complete.

[0048] Fig.Figure 6 shows a flowchart illustrating this anticipatory behavior of timer 200. First, as shown in process 500, timer 200 determines that the current action has either exceeded or will exceed its action duration. Next, timer 200 checks the priority of the next action to be executed, as shown in process 510. The priority of the next action is compared with that of the current action, as shown in process 520. If the next action has a higher priority, timer 200 aborts the current action and reports the failure to the network software stack, as shown in process 530. Next, timer 200 schedules the next action for execution, as shown in process 540. If the next action does not have a higher priority than the current action, timer 200 allows the current action to continue to completion, as shown in process 550.

[0049] For certain tasks, no end time may be defined. In certain embodiments, these may be referred to as indefinite tasks. For example, a parent ZigBee node may define an indefinite task, causing the ZigBee radio to wait for the arrival of incoming packets. These indefinite tasks have a low priority, allowing other actions to precede them, as described above.

[0050] Thus, in one embodiment, the present disclosure describes a multi-protocol network controller 20 that includes a network interface 23 with a single radio unit 24. The multi-protocol network controller 20 also includes multiple network software stacks that communicate with a timer 200. Each network software stack has a queue of actions, with the action at the top of the queue being passed to the timer 200. The timer 200 utilizes information regarding the expected duration, priority, requested start time, and slack time to intelligently schedule actions of the multiple network software stacks. This information is provided by the network software stacks.

[0051] In another embodiment, the present disclosure describes a software program referred to as a scheduler. This software program may be stored in storage device 22 and executed by processing unit 21. In terms of data flow, this timer is located between two or more network software stacks and a hardware component, such as a network interface. Each network software stack has a queue of actions it wants the hardware component to execute. The timer uses information associated with the actions at the top of each queue to determine which action should be scheduled next. Unlike conventional timers that rely solely on priority, the present timer uses additional information, such as action duration and slack time, to schedule actions more intelligently.The goal is to maximize the use of hardware components while meeting scheduling constraints for as many actions as possible.

[0052] In another embodiment, the present disclosure describes a method for scheduling actions for a shared resource, such as a hardware component. The method includes presenting at least two actions to a timer responsible for scheduling actions for the resource in question. Each action presented to the timer includes additional information, such as action type, estimated action duration, slack time, requested start time, and priority. The timer then uses this information to intelligently select the next action to be scheduled to utilize the shared resource. In certain embodiments, the timer may select an action that has a lower priority than another action.

[0053] It is not intended to limit the scope of the present disclosure to the embodiments described herein. Rather, various other embodiments and modifications of the present disclosure will be apparent to those of ordinary skill in the art from the foregoing description and the accompanying drawings. Thus, it is intended that such other embodiments and modifications be included within the scope of the present disclosure. Furthermore, although the present disclosure has been described herein in the context of a particular implementation in a particular environment for a particular purpose, those of ordinary skill in the art will recognize that its utility is not so limited and that the present disclosure may be advantageously implemented in any number of environments for any number of purposes.Accordingly, the claims set forth below are to be construed in light of the full breadth and spirit of the present disclosure as described herein.

Claims

[1] Network control, including: a network interface comprising a radio unit; a processing unit; and a storage device in communication with the processing unit, the storage device comprising instructions that, when executed by the processing unit, enable the network controller to: Compare actions from multiple network software stacks, where each action includes a requested start time, an estimated action duration, a slack time, and a priority; select one of the actions of the multiple network software stacks based on the requested start time, the estimated action duration, the slack time, and the priority of each action; and to schedule the execution of the selected action by the network interface. [2] The network controller of claim 1, further comprising instructions enabling the processing unit to calculate a latest allowable start time for a first action by adding the requested start time and the slack time of the first action. [3] The network controller of claim 2, further comprising instructions enabling the processing unit to compare the latest allowable start time of the first action with a sum of the current time and the estimated action duration of a second action. [4] The network controller of claim 3, further comprising instructions enabling the processing unit to schedule the second action prior to the first action if the sum is less than the latest allowable start time. [5] The network controller of claim 4, further comprising instructions that, if the second action is not scheduled, enable the processing unit to calculate a latest allowable start time for the second action by adding the requested start time and the slack time of the second action, and to compare the latest allowable start time of the second action with a sum of the current time and the estimated action duration of the first action. [6] The network controller of claim 5, further comprising instructions enabling the processing unit to schedule the first action ahead of the second action if the sum of the current time and the estimated action duration of the first action is less than the latest allowable start time of the second action. [7] The network controller of claim 3, further comprising instructions enabling the processing unit to schedule the second action prior to the first action if the priority of the second action is higher than the priority of the first action. [8] A method for scheduling actions of multiple network software stacks, comprising: Comparing actions from multiple network software stacks, where each action includes a requested start time, an estimated action duration, a slack time, and a priority; Selecting one of the actions from the plurality of network software stacks based on the requested start time, the estimated action duration, the slack time, and the priority of each action; and Scheduling the execution of the selected action by the network interface. [9] The method of claim 8, further comprising calculating a latest allowable start time for a first action by adding the requested start time and the slack time of the first action. [10] The method of claim 9, further comprising comparing the latest allowable start time of the first action with a sum of the current time and the estimated action duration of a second action. [11] The method of claim 10, further comprising scheduling the second action prior to the first action if the sum is less than the latest allowable start time. [12] The method of claim 11, further comprising: if the second action is not scheduled, calculate a latest allowable start time for the second action by adding the requested start time and the slack time of the second action; and to compare the latest permissible start time of the second action with a sum of the current time and the estimated action duration of the first action. [13] The method of claim 12, further comprising scheduling the first action prior to the second action if the sum of the current time and the estimated action duration of the first action is less than the latest allowable start time of the second action. [14] The method of claim 10, further comprising scheduling the second action prior to the first action if the priority of the second action is higher than the priority of the first action. [15] A software program located on a non-transitory storage medium and comprising instructions which, when executed by a processing unit: Compare actions from multiple network software stacks, where each action includes a requested start time, an estimated action duration, a slack time, and a priority; select one of the actions from the multiple network software stacks based on the requested start time, the estimated action duration, the slack time, and the priority of each action; schedule the execution of the selected action through a network interface. [16] The software program of claim 15, further comprising instructions enabling the processing unit to calculate a latest allowable start time for a first action by adding the requested start time and the slack time of the first action. [17] The software program of claim 16, further comprising instructions enabling the processing unit to compare the latest allowable start time of the first action with a sum of the current time and the estimated action duration of a second action. [18] The software program of claim 17, further comprising instructions enabling the processing unit to schedule the second action prior to the first action if the sum is less than the latest allowable start time. [19] The software program of claim 18, further comprising instructions that, if the second action is not scheduled, enable the processing unit to calculate a latest allowable start time for the second action by adding the requested start time and the slack time of the second action, and to compare the latest allowable start time of the second action with a sum of the current time and the estimated action duration of the first action. [20] The software program of claim 19, further comprising instructions enabling the processing unit to schedule the first action prior to the second action if the sum of the current time and the estimated action duration of the first action is less than the latest allowable start time of the second action. [21] The software program of claim 17, further comprising instructions enabling the processing unit to schedule the second action prior to the first action if the priority of the second action is higher than the priority of the first action.

Images