Patent Publication Number: US-2003225739-A1

Title: Flexible scheduling architecture

Description:
[0001] This application claims priority to U.S. Provisional Application Serial No. 60/377,907 filed May 4, 2002. 
    
    
     
       BACKGROUND OF THE INVENTION  
       [0002] 1. Field of the Invention  
       [0003] The present invention relates generally to a hardware control engine, and particularly a hardware control engine that can provide for the aggregation of multiple streams, particularly into a single channel. Thus, aggregation of different streams having comparable priority is achieved using an architecture that allows for configurable priority among the different streams as well as the ability to implement a variety of different protocols using the same hardware control engine.  
       [0004] 2. Description of Related Art  
       [0005] Computer systems often aggregate data from different devices or sources, particularly onto a single channel. For example, in a simple computer system that contains a keyboard, a mouse, a display and a printer, data from each of these various devices will need to be processed by the central processor. In many early systems, these various devices caused a hardware interrupt, which caused the central processor to pay attention to the particular device asserting the interrupt, so that the associated data could be obtained.  
       [0006] As networks have become more sophisticated, so have the schemes for aggregating data. For example, certain systems require a single stream being transmitted through a single interface, such as in certain wireless networks, it is conventional to provide a network interface controller with a single queue, with descriptors from each of the multiple data streams being placed in a single output queue. These descriptors are used to then obtain and then transmit each packet of data. In particular, in the context of data being transmitted according to requirements set forth by IEEE Standard 802.11, the wireless LAN medium access control (MAC) layer will use descriptors from an output queue to obtain a single stream of data. This data can then be routed to the physical layer (PHY) for transmission through the air.  
       [0007] There are, nonetheless, certain non-wireless systems that obtain a single stream of data using multiple queues. These systems, however, provide for specific queues that meet the specific requirements of the systems for which they are intended.  
       [0008] Thus, for instance, Ethernet interfaces exist that have one or two priority queues. As another example, the GSN SHAC (Super Hippi Adapter Chip) has four output queues—one for each of four physical connections supplied by the hardware, but the output queues are limited to supporting this specific hardware, and are not intended for use in any other system. Further, asynchronous transfer mode (“ATM”) adapters use a number of different rate-controlled queues used to send what is termed constant bit-rate (CBR) data (which in reality is constant frame rate data) such as MPEG video, but these queues are limited to providing data at the various rates associated with each of the different queues.  
       [0009] Thus, while it is commonplace to provide a NIC, typically formed on a single integrated circuit chip, that contains either a single output queue or a small number of queues each directed to a specific purpose, such as either priority or rate control, a flexible architecture that allows for the different types of output operations to occur depending upon a user-desired configuration has not been achieved.  
       [0010] Various different types of output control can exist for a device in a communications system. For example, they may include rate control outputs in which data is output at a constant rate (typically on a per-frame basis, such as with MPEG-1 and MPEG-2). Also, priority control outputs exist in which certain data to be output has priority over other data to be output. Polling control outputs also exist in which a poll with data is transmitted with a poll, and an acknowledgement with or without data attached thereto is received from an external device to indicate receipt and respond, at which time another acknowledgement may be sent, depending upon the protocol, to the external device indicating receipt of the acknowledgement. It should be noted that polling control outputs is different than a device being polled, since a device being polled, such as the external device mentioned above, is responding to receipt of a poll rather than generating a poll, although in certain systems a particular device can poll and also be polled. Polling as used herein can refer to generating polls as well as responding to polls.  
       [0011] To date, systems do not have the ability to easily switch between various different types of output control. Thus, a flexible architecture that allows both priority and rate control outputs, or rate control and polling outputs, or any combination of normal FIFO, prioritized, rate control, and polling outputs would be desirable, particularly when used to implement wireless communications.  
       [0012] Further, a hardware control engine that provides such a flexible architecture also has advantages in being able to implement a hardware scheduler, as well as other components, which have usefulness in contexts other than wireless communications media access control.  
       SUMMARY OF THE INVENTION  
       [0013] A method and apparatus is described that provides multiple queues that can each be separately operated upon, so that various combinations of outputs result, including normal FIFO, prioritized, rate control, and polling outputs.  
       [0014] In a preferred embodiment is described a scheduling architecture, including a plurality of queues each within an associated queue control unit, and a plurality of data control units. The queue control units are directed to operations that obtain data for transmission of a stream from a host and ensure that it is available for transmission, preferably as a single stream. The data control units are each directed to operations that format the data from the queue control units in dependence upon the transmission (or channel) characteristics that are to be associated with that data. Further, each queue control unit can configurably be input to any of the data control units. In one embodiment the output of each of the data control units is controlled by a data arbiter, so that a single stream of data is obtained.  
       [0015] In a specific implementation, the scheduling architecture is applied to a media access control for a wireless communication system, and the output from the data arbiter can be transmitted to a protocol control unit so that protocol control, dependent on the particular physical layer characteristics, can take place.  
       [0016] Advantages of this architecture are flexibility to allow for different types of communications, such as contention based and polling based communications, to be implemented, both individually as well as different types simultaneously in the same network.  
       [0017] Further, this architecture provides for hardware scheduling in contexts other than wireless communication media access channel to occur.  
       [0018] Timing components of a hardware control engine (typically implemented within an integrated circuit chip as is known) according to the present invention can also be synchronized with external sources for managing access, such as, for instance, to an array of antennas or for send/receive operations with external timing sources, which can be useful for a variety of applications. 
     
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
     [0019] The present invention is illustrated by way of example, and not limitation, in the figures of the accompanying drawings in which like references denote similar elements, and in which:  
     [0020]FIG. 1 illustrates one aspect of the architecture of the present invention.  
     [0021]FIG. 2 illustrates a scheduling architecture according to one embodiment of the present invention;  
     [0022]FIG. 3 illustrates a specific implementation of the scheduling architecture according to the present invention applied to a preferred wireless communication system;  
     [0023]FIG. 4 illustrates a functional block diagram of a queue control unit (QCU) according to one embodiment of the present invention;  
     [0024]FIG. 5 illustrates a functional block diagram of a data control unit (DCU) according to one embodiment of the present invention;  
     [0025]FIG. 6 illustrates an exemplary functional block diagram of a traffic shaping control unit according to one embodiment of the present invention; and  
     [0026]FIG. 7 illustrates state machine diagram for a DCU that implements a CSMA channel access method according to one embodiment of the present invention.  
    
    
     DETAILED DESCRIPTION  
     [0027] A flexible architecture that allows scheduling of multiple data streams for injection onto a single shared output channel, possibly a network transmission device, is described. In one embodiment, the architecture allows both priority and rate control outputs, or rate control and polling outputs, or any combination of normal FIFO, prioritized, rate control, and polling outputs. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be evident, however, to one skilled in the art that the present invention may be practiced in a variety of devices, especially wireless devices, without these specific details. In other instances, well-known operations, steps, functions and elements are not shown in order to avoid obscuring the invention.  
     [0028] Various operations will be described as multiple discrete steps performed in turn in a manner that is most helpful in understanding the present invention. However, the order of description should not be construed as to imply that these operations are necessarily performed in the order that they are presented, or that they are even order dependent. Lastly, repeated usage of the phrases “in one embodiment,” “an alternative embodiment,” or an “alternate embodiment” does not necessarily refer to the same embodiment, although it may.  
     [0029] One advantageous aspect related to the architecture of the present invention is that it allows for traffic shaping, which, as is known, is the process of controlling the parameters used for injecting application data into a network, including rate, burst characteristics (such as periodicity and burst length) and other statistical properties (such as minimum rate, maximum rate, and mean rate). Thus, in one aspect, traffic shaping will inject data into a network at a rate corresponding to the traffic specification (Tspec) for the flow accepted for quality of service (QoS). Traffic shaping can also provide policing capability to ensure that the rate at which data in injected into a network is guaranteed, i.e. not below and/or above a certain amount.  
     [0030] In the context of traffic shaping, there is also the need for scheduling components upon which different traffic shaping functions are dependent and which controls the selection and ordering of multiple flows that may be contending for network bandwidth  
     [0031] When used for traffic shaping, the present invention replaces the traditional single output queue, or output channel, by a succession (pipeline) of processing stages with a set of parallel datapath components at each stage. The datapath components operate relatively independently and contribute, in a controllable and-selectable manner.  
     [0032] A significant aspect of the present invention is the architecture that provides for segmentation of various types of operations, such that repeatable circuit blocks are used to provide the same type of operations on various different data streams. FIG. 1 generally shows a plurality of stream operation blocks  110  that are each able to input the data which they output at an appropriate time to an aggregation block  120 , such that a single output stream results. As illustrated, the stream operation blocks  110  each receive signals  130  from the aggregation block  120 , which allow data to be correctly formatted, as well as provide for timing. When this architecture is applied particularly to traffic shaping, the stream operation blocks  110  and the aggregation block  120  can preferably be further partitioned into various independent pipelined and parallel-operating blocks. For example, one set of circuit units can be used to ready data in different streams for transfer, whereas another set of circuit units can be used to control channel access features associated with the data, such as contention window management and backoff, such that each circuit unit is capable of implementing a different type of channel access policy, as will be described further hereinafter. This allows for many different types of scheduling to be implemented, based upon the choice of the user, as will be described further herein.  
     [0033] It will also become apparent that the architecture described herein, while having particular utility and usefulness in the context of traffic shaping for wireless networks, also has advantageous features that can be used in other environments. In this regard, the following detailed description will be in the context of a network, and in particular a wireless network. It will be understood, however, that other examples mentioned herein illustrate the flexibility that this architecture has and how it can be used in other contexts, such as to provide a stand along hardware scheduler that can be used in many different types of systems.  
     [0034] When applied to scheduling, the present invention provides a scheduling architecture. The scheduling architecture includes a first processing stage that consists of a number of queue control units (QCU)  210 , which receive signals from a host interface unit  205  that provides a standardized interface to each of the QCU&#39;s  210 . The QCU&#39;s  210  are each responsible for managing the direct memory access of frame data from the host, via the HIU  205 , and for determining when a frame is available for transmission. The second stage consists of a number of data control units (DCU)  220 , which each receive frame data from only one of the QCU&#39;s  210  at a time, but which can each receive frame data from different QCU&#39;s  210  at different points in time, as will be discussed further herein. The DCU&#39;s  220  are responsible for managing the channel access procedure on behalf of all QCU&#39;s  210  associated with it. A DCU arbiter  230  merges together the output packets. From there, when applied to a wireless network as further described hereinafter, the output packets are input to a protocol control unit (PCU)  240 , which manages the final details of sending the frame to baseband logic. The QCU&#39;s  210  in this embodiment correspond to the stream operation blocks  110  in FIG. 1, whereas the DCU&#39;s  220 , the DCU arbiter  230  and the PCU  240  correspond to the aggregation block  120  in FIG. 1.  
     [0035] Since the functionality of a PCU  240  will be found in any scheduling architecture of a communication system, particularly as applied to a wireless communication system, and more particularly the media access control of a wireless communication system, the discussion hereinafter will focus on those aspects of the architecture relating to the parallel-pipeline arrangement of QCU and DCU components.  
     [0036] On the receive side, a single DMA receive unit (DRU)  250  is connected between the PCU  240  and the HIU  205 . The DRU unit  250  manages receive descriptors and transfers the incoming frame data and status to the system host via the HIU  205 .  
     [0037] The host interface unit  205  will include a core that corresponds to the type of transmission used by the system to which the architecture  200  connects. Thus host interface unit  205  could include, for example, a Phoenix PCI core for connection to PCI bus systems, a core for connection to AHB/APB bus systems, a PCI Express™ bus system, or a USB core for connection to USB bus systems. The logic used within the host interface unit  205  is not of particular importance, as it could connect to other interfaces as well, although it is understood that no matter which interface the host interface unit  205  connects to, the host interface unit  205  must be able to export signals and data as described herein to the QCU&#39;s  210  and the DCU&#39;s  220  upon receipt of appropriate control signals.  
     [0038] As mentioned above, the user can selectively program each of the DCU&#39;s  220  for a particular mode of operation: e.g. polling, time division multiple access (TDMA), CSMA, deferred (such as with a power save mode in which packets are held until a sleep period ends), or other mode of operation, such as a specific other mode of operation (for example, a special PHY mode or a special channel access mechanism). Thus, for example, a DCU  220  can be referred to as a polling DCU or a TDMA DCU depending on how it was initialized. All DCU&#39;s  220  are preferably able to provide all of the output policies that are compatible with a particular choice of PCU  240 . Note that there may be embodiments where the technical properties of the access mechanism of the PCU  240  dictate that the DCU&#39;s  220  have differences between them. But since any QCU  210  can potentially be associated with any DCU  220  and since all the DCU&#39;s  220  eventually feed into the PCU  240 , there is no loss of generality or flexibility if one or more DCU&#39;s  220  have additional functionality.  
     [0039] PCU  240 , because it implements the media access control access mechanism, is in control on an instant-to-instant basis of whether or not the current mode is polling, slotted contention or other, depending on the nature of the underlying access mechanism. If the underlying mechanism provides multiple modes, e.g. both polling and priority, then PCU  240  will select from the DCUs  220  corresponding to each mode at the appropriate interval, e.g. select from a polling DCU  220  during polling periods and select from a high-priority DCU  220  during priority periods.  
     [0040] A DCU  220  takes the output of a QCU  210  that is ready, signals to PCU  240  when the DCU  220  is ready to transmit by generating a readiness indication, and provides output to the PCU  240  when selected by the PCU. PCU  240  places the QCU output on the physical medium, and provides success/failure notification back to the DCU.  
     [0041] According to one embodiment each DCU  220  selects from the QCU&#39;s  210  connected thereto according to round robin policy, but other schemes, such as priority or weighted round robin are also possible.  
     [0042] PCU  240  selects from the ready DCU&#39;s  220  according to their priority level—if the PCU  240  is providing a priority service at that instant—or from polling or TDMA DCU&#39;s if the PCU  240  is providing that different service at that instant.  
     [0043] In light of the above overall description of the architecture  200  according to a preferred embodiment of the invention, further details regarding the QCU&#39;s  210  and the DCU&#39;s  220  will be provided. It is noted, however, that these further details can be implemented in many different manners. For example, as described, each of the QCU&#39;s  210  and DCU&#39;s  220  contain their own separate hardware, such as dedicated logic gates, which are replicated for each different unit. For purposes of understanding, as well as in certain specific implementations, having such separate hardware may be desirable in order to maximize potential throughput, as each separate hardware block can operate when the other hardware blocks are also operating. But such separation is not necessarily needed. Rather than having separate hardware for each different QCU  210  and DCU  220 , the same parallel functionalities can be achieved using, for instance, various different threads within a multi-threaded processor. Further, while there are advantages to replicating the architecture of the QCU&#39;s  210  and DCU&#39;s  220 , that is not a requirement, as will be apparent.  
     [0044] With the above in mind, FIG. 3 illustrates a block diagram of an exemplary implementation of a NIC  300  that provides for both prioritization and polling in a wireless network in a system with  6  priority levels, although  10  or more priority levels could be used. As illustrated, DCU  320 - 6  inputs a data stream used to generate a beacon and having the highest priority from QCU  310 - 10 . DCU  320 - 5  inputs another data stream that is used to generate beacon-gated frames and these have the second highest priority from QCU  310 - 9 . DCU  320 - 4  and QCU  310 - 8  is associated with HCF polling and has the third highest priority. DCU  320 - 3  and QCU&#39;s  310 - 7  and  310 - 6  are at the next level of priority, DCU  320 - 2  and QCUs  310 - 5 ,  310 - 4  and  3103  provide the next level of priority, and the lowest level of priority is provided by DCU  320 - 1  and QCU&#39;s  310 - 1  and  310 - 2 . These can be used, for example, to implement the different priority levels provided by the IEEE 802.11 bridging standard, which provide traffic priority classes 0, 1, 2, 3, . . . . 7 for best effort, background, standard, excellent effort, controlled load, video, voice and network control, in decreasing priority order. All of these classes need not be provided, and unsupported classes can be mapped into supported classes, as shown in FIG. 3.  
     [0045] While the particular circuit elements that make up QCU&#39;s and DCU&#39;s can vary, FIGS. 4 and 5 will be used to provide a general description of the various functionalities of a QCU and a DCU. These will be referred to generally as QCU  410  and DCU  520 , although it will be understood that the functional description provided herein is exemplary, and other combinations of functional blocks can be used to achieve the overall functionality of a QCU or DCU as described herein.  
     [0046] Further, before providing such description, however, it is noted that with respect to QCU&#39;s and DCU&#39;s, when used in a wireless communication media access control environment, they are intended to operate together to schedule data transfers using descriptors and status flags, in combination with control signals dependent upon the PHY layer being implemented and the channel access mechanism being used. Specific descriptors used for both transmit and receive are not necessary to understand the present invention and its advantages, but such descriptors will of course be necessary to a specific successful implementation.  
     [0047] QCU Implementation  
     [0048] Each QCU  410  according to one preferred embodiment of the present invention when used for media access control in a wireless medium will preferably contain all the logic and state (registers) needed to manage a single queue (linked list) of transmit descriptors. The QCU  410  will fetch frames in dependence on the descriptor list, and provide the frames to the DCU  520 , subject to the frame scheduling policy. When a QCU  410  is ready to fetch the frames, the QCU  410  will then signal to its DCU  520  that it has a frame ready for transmission. Typically, a frame ready for transmission will indicate that the frame can be fetched from the host memory and provided to the DCU  520  based upon the transmit descriptors, although the system can also be implemented in a manner that pre-fetches the frames and temporarily stores the pre-fetched frames in a local memory associated with the QCU  410 .  
     [0049] According to one embodiment of the present invention, the QCU, illustrated in FIG. 4, includes user control register  412  that includes various control registers, including the QCU ready bit register  414 , traffic shaper  416 , queue descriptor processing block  418  that contains a queue  422  of descriptors, queue logic  424 , direct memory access (DMA) control logic  426 , and DMA buffers  428 .  
     [0050] A significant aspect of the present invention is that the traffic shaping block  416 , which essentially controls the traffic associated with particular QCU  410 , can be implemented in dependence on the specific requirements associated with a particular queue, as described more fully hereinafter. Thus, based on that logic, various transmit descriptors will be placed into or taken off of the queue  422  within the queue descriptor block  418  using the PUT and GET signals. A head pointer and a tail pointer will point to the first and last descriptors, respectively, in the queue  422 , with each descriptor providing an indication of the operation needed in order to obtain data associated with it, as is known. As long as descriptors are within the queue  422 , the queue empty signal is not generated, which the traffic shaping block  416  can use to generated the READY signal, which signal, for example, is stored in the preferred embodiment in the QCU ready bit register  414 . As will be apparent from the description hereinafter, the READY state may change based upon external condition changes, which the traffic shaper  416  can respond to by causing the state of the QCU ready bit  414  to be cleared to a NOT READY state that will not generate the READY signal, as well as affect other logic within traffic shaper  416  so that the traffic shaper  416  can respond to the changed condition and continue to monitor conditions so that, when appropriate, another READY signal can be generated.  
     [0051] Further, the queue logic  424 , the data control  426 , and the DMA buffers  428  will each operate based upon the signals that derive from the traffic shaping circuit  416 . As these functions are conventional, they need not be further described. As is apparent, however, as data associated with the descriptor that is operated upon is obtained and output to the DCU associated therewith, state is affected, which is shown as affecting the QCU  410  by the signals output from the DMA buffer  428  to the traffic shaper  416 .  
     [0052] As a result of this architecture, the traffic shaping block  416  can be programmed for a particular stream that it will generate, and the other blocks within the QCU  410  will operated based upon that programming. Thus, the QCU  410  can be replicated for different streams that each QCU will access, with each QCU  410  having the same architecture, while being programmed differently by having a different traffic shaping block  416 .  
     [0053]FIG. 6 illustrates an exemplary traffic-shaping block  600 . As shown, this figure depicts the control logic between the output queue, traffic shaper  600 , and the DCU  220 , but does not illustrate the data path, which is not relevant to the traffic-shaping decisions.  
     [0054] The objective of this generic traffic shaping circuit is to schedule controlled bursts of output packets at predetermined time intervals. The bursts are limited to a number of packets and a maximum time limit. The signals shown are positive logic. Thus, the focus of the exemplary traffic-shaping block  600  is to set the READY bit  631  at periodic intervals determined by the DN counter  602 . The SR gate  612  may be set by either the counter  602  or by other events or logic circuits  622 .  
     [0055] The preset interval  601  provides the initial value for the time  602 . The zero output of the DN counter  602  dives the S input of SR gate  612 , which sets the ENABLE signal  620  that is exported to the DCU  220  as the READY signal  631  if it is not disabled by other logic elements.  
     [0056] The other two down counters  603  and  605  limit the number of packets per burst or the time allowed per burst, respectively. The zero output of each of these counters disables the ENABLE signal  620  by pulsing the reset input of the SR gate  612  through the gates  608  and  610 . The OR gate  608  makes provision for other disabling events or logic circuit to also clear the ENABLE signal  620 .  
     [0057] The output queue generates a QUEUE EMPTY signal  628 , the inverse  629  of which implies the queue is not empty, or ready to transmit. Without traffic shaping the QUEUE READY signal would be passed directly to the DCU  220  via the READY signal  631 . But the traffic shaping logic combines the QUEUE READY indication with other times and conditions that dictate the timing and burstiness of the forwarded READY signal  631 .  
     [0058] If the ASAP signal  627  is present, the QUEUE READY signal will control READY  631  as long as the OTHER INHIBITS  630  is not clear. This ASAP mode disables traffic shaping and allows the READY signal to propagate as soon as possible (ASAP). Otherwise the READY bit  631  is propagated whenever the logic sets ENABLE  620 .  
     [0059] The DCU  220  provides a BEGIN signal  610  when it starts to transmit packets. The DCU  220  also provides a SEND PACKET signal  609  for each packet it sends. Thus, the traffic shape  600  provides READY to the DCU  220  when it has one or more packets to be transmitted from the output queue.  
     [0060] The BEGIN TX signal  631  loads the DN counter  605  with a preset time TIME LIMIT signal  606 . The DN counter  605  ticks down for each CLK pulse  608  until reaching zero. The zero (Z) output  626  indicates the DN counter  605  has reached zero.  
     [0061] As each packet is transmitted the SEND PACKET signal  625  causes DN counter  603  to decrement from its initial value supplied as a PACKET LIMIT value  604 .  
     [0062] It will be apparent that the exemplary traffic shaper  600  described above can instead be implemented in a variety of different way, depending upon the requirements. Thus, the above-described exemplary traffic shaping circuit  600  of FIG. 6 is exemplary. The generic traffic shaping circuit  416  as illustrated in FIG. 4 can be configured to provide different traffic shaping methods, such as constant bit rate, variable bit rate, externally synchronized, and others. To implement multiple methods, elements such as CBR counters, timers, limits and other elements for controlling traffic shaping can thus be located in the traffic shaper  416  as illustrated in FIG. 4.  
     [0063] With such implementation, each QCU  410  can be programmed to provide different types of frame scheduling, for example each of the different QCU&#39;s  310  illustrated in FIG. 3. For purposes of the invention, the particulars described above, as well as the considerations mentioned herein, provide the detail necessary to provide for a traffic shaper, and thus a QCU that will implement the various aspect of the present invention. In general, a QCU, such as QCU  410  in FIG. 4, will typically provide one of three types of frame scheduling:  
     [0064] Unthrottled—the queue, with frame descriptor or sequence of frames descriptors (or frames depending on the particular QCU implementation) is marked READY, and each frame is obtained as the corresponding frame descriptor reaches the head of the queue.  
     [0065] Time-throttled—the queue, with frame descriptor or sequence of frame descriptors (or frames depending on the particular QCU implementation) is marked READY only upon the elapse of a certain time interval (i.e., frame descriptors are held in the queue until the time interval elapses)  
     [0066] Event-throttled—the queue, with frame descriptor or sequence of frames descriptors (or frames depending on the particular QCU implementation) is marked READY only upon the occurrence of a particular event, typically one that is detected outside the QCU.  
     [0067] Specific QCU frame scheduling policies that can thus be achieved using a QCU as described herein include:  
     [0068] ASAP—the queue, with frame descriptor or sequence of frame descriptors (or frame or frames) is marked READY and each frame is obtained as soon as it reaches the head of the queue. Frame transmission continues until the end of the queue is reached. This is an unthrottled mode.  
     [0069] CBR (“constant bit rate”—though CBR is the acronym conventionally used, it is in fact a constant frame rate since an entire sequence of frames is transmitted each time the CBR interval elapses, without regard to the number of bits in the frames). With such a policy, the queue, with a frame descriptor or sequence of frame descriptors, (or frame or sequence of frames) is marked READY only upon expiration of the QCU&#39;s CBR interval timer. Once this timer elapses, frame transmission continues until the end of the descriptor chain in the queue is reached. Preferably, with such a policy, a CBR interval timer is immediately reset and begins counting down the next CBR interval. This is an example of time-throttled frame scheduling policy, as noted above.  
     [0070] In particular, with a CBR policy, each time the CBR interval elapses, the QCU increments a “CBR expired” counter. Whenever the CBR expired counter is non-zero and a frame descriptor or sequence of frame descriptors is available at the head of the queue, the QCU marks the frame descriptor or sequence of frame descriptors READY. Upon encountering the end of queue condition, the QCU decrements the CBR expired counter. If this decrement of the CBR expired counter brings the counter value to zero, then the QCU does not attempt new frame transmission until the current CBR interval elapses, at which point the CBR expired counter increments to one and frame transmission resumes. If the decrement of the CBR expired counter leaves the counter value still non-zero, then the QCU resumes frame transmission attempts immediately. In this way, the QCU attempts to “catch up” to the host&#39;s desired frames-per-CBR interval rate, even if network conditions temporarily cause the achieved frame transmission rate to fall below the desired value.  
     [0071] In a particular implementation according to the present invention, this “catch-up” mechanism further supports a limit on the value of the CBR expired counter. When the CBR expired counter reaches its limit, the QCU responds not by incrementing the CBR expired counter, but by dropping the next series of frames at the head of the queue, until an end of descriptor chain (also referred to as “EOL”) condition is reached. This generalizes the “catch-up” mechanism from an “always catch up fully” policy to a “try to catch up fully unless the queue falls too far behind, in which case drop frame descriptors until the queue is no longer too far behind” policy.  
     [0072] DBA-gated—A queue is marked READY only upon the occurrence of the DMA beacon alert (DBA), as signaled from the PCU  240  illustrated in FIG. 2. Once the DBA occurs, frame transmission continues until the end of the queue is reached. This is an example of event throttled scheduling policy, as noted above.  
     [0073] With a DBA gated policy, the occurrence of DBA is tracked using the same “CBR expired” counter mechanism as was discussed above for the CBR scheduling policy. That is, the CBR expired counter is incremented each time DBA occurs and decremented upon reaching an end-of-queue condition. The QCU marks the queue READY whenever the CBR expired counter is non-zero.  
     [0074] TIM-gated—A TIM-gated scheduling policy is the same as DBA-gated scheduling policy except that the trigger event for marking the queue READY is:  
     [0075] In STA mode, the receipt of a beacon with the local station&#39;s bit set in the partial virtual bitmap within the TIM element. Note that a beacon arriving with the DTIM bit set (bit zero of the “bitmap control” field within the TIM element) but not the local station&#39;s bit within the partial virtual bitmap does not qualify as a trigger event for this frame scheduling policy.  
     [0076] In AdHoc mode, the receipt of an ATIM frame directed to the local station.  
     [0077] Beacon-sent-gated—The same as DBA-gated except that the trigger event for marking the queue READY is the successful transmission of a beacon frame from the DCU designated for beacon transmission.  
     [0078] TSF gated: a TSF (Timing Synchronization Function (as used in IEEE 802.11 terminology)) gated scheduling policy implements scheduling based upon signals that are synchronized with or derived from TSF in order to synchronize internal clocks and/or slots.  
     [0079] Externally gated: an externally gated scheduling policy implements scheduling based upon synchronization signals received from an outside source, such as, for example, antenna switching logic or other external synchronization logic in order to synchronize internal clocks and/or slots.  
     [0080] Other policies, in addition to frame scheduling policies can also be implemented, using certain of the above concepts, as well as other. For instance, power savings policies can be used to turn off some or all components, such as when a network interface controller chip is used. While different types of sleep states are known, that such sleep states can be triggered from power savings policies that are implemented by the same engine that implements other policies, such as scheduling and other types of policies as described herein, is considered advantageous. Thus, for example, sleep states between beacons, which many times result in periods of inactivity, can be programmed to occur. As another example, sleep states can be programmed to occur between expected incoming packets that have a known predictable arrival pattern, such as voice packets.  
     [0081] A number of QCU functions depend on the detection of the end of the transmit descriptor chain, the EOL condition referred to above. Three significant EOL conditions include when the QCU (1) fetches a descriptor whose LinkPtr field is NULL, (2) fetches a descriptor whose “virtual end-of-list” (VEOL) bit is set, or (3) exceeds the ReadyTime limit. The ReadyTime QCU parameter determines the maximum continuous period of time the queue indicates that it has frames ready for transmission.  
     [0082] When the ReadyTime function is enabled by setting the ReadyTimeEn bit, the QCU begins counting down the ReadyTime starting at the same event (i.e., the expiration of the CBR interval timer or the occurrence of DBA) that causes the queue to be marked ready. Thereafter, normal frame processing occurs until the ReadyTime duration expires. At this point the QCU ceases marking frames ready even if it has not yet encountered one of the other two end-of-queue conditions.  
     [0083] The ReadyTime function may be enabled only with a non-ASAP frame scheduling policies. It may not be used with the ASAP policy.  
     [0084] In most cases the three end-of-queue conditions mentioned above are treated identically, with two exceptions:  
     [0085] The QCU signals an EOL interrupt only if a descriptor&#39;s LinkPtr is NULL.  
     [0086] The QCU by default does not clear the TXE bit on occurrence of VEOL or the expiration of ReadyTime. The QCU clears TXE only when it encounters a NULL LinkPtr. A register bit within each QCU can be set to change this policy so that the QCU clears TXE for VEOL and ReadyTime expiration.  
     [0087] DCU Implementation  
     [0088] Whereas the QCU is generally concerned with implementing access to data associated with a particular stream, the DCU, in the preferred wireless communication environment, is generally concerned with implementing the protocol procedures of the channel access method associated with the particular data, which formatting is dependent upon a specific channel access protocol. Further, if desired, final formatting can also be performed by the DCU is desired, such final formatting including, for example, error check coding, cryptography or compression. Thus, each of the DCU&#39;s are programmed in a manner that becomes protocol dependent. Thus, as mentioned previously, the DCU manages the channel access procedure. In doing so, associated with each DCU are DCU state variables, such as contention window (“CW”), CWMAX, CWMIN, retry, and associated counts. Further, in conjunction with signals received from PCU  240 , in the preferred wireless communication environment, each DCU will decide whether to retransmit or abandon a frame.  
     [0089]FIG. 5 illustrates a functional block diagram of a DCU  520  in the in the preferred wireless communication environment. An arbitrary number of QCU&#39;s  410  are connected to the DCU (four are shown), with the READY signal capable of being input from each of the QCU&#39;s  410  associated with this particular DCU  520  into the QCU arbiter  522  along READY input line  524 . As explained in further detail hereinafter, QCU arbiter  522  will select one of the QCU&#39;s  410  based upon some priority, as described further herein, and input the data corresponding thereto along one of the data input lines  526 . This data, from whichever of the QCU&#39;s  410  it comes from, is transmitted along data bus  528  and is output to PCU  240  illustrated in FIG. 2, under the control of the DCU state control logic  530 . The DCU state control logic  530  and the QCU arbiter  522  both receive and transmit control signals to the PCU  240  along control lines  534 .  
     [0090] In operation, the DCU  520  begins channel arbitration by determining whether any of the associated QCU&#39;s  410  has a frame ready for transmission. The DCU makes this determination using QCU arbiter  522 , which logically ANDs each of the QCU READY bits with a QCUMask register to arrive at a set of QCU&#39;s that are both associated with the DCU and have a frame available. If more than one QCU is ready is not relevant to the DCU  520  at this point in the sequence.  
     [0091] For the QCU  410  selected, the DCU  520  will then initiate a sequence that may result in the input of the data associated with one of the QCU&#39;s  410  in the set, so that the DCU state control logic  530  can then operate to determine how to format that data for the associated channel access procedure.  
     [0092] In particular, in the context of an 802.11 environment, the DCU state control logic  530 , if programmed for an EDCF contention access method, will perform an EDCF channel access procedure, meaning it waits until the channel has been idle for at least an AIFS (if the channel has not already been idle for this long) and then attempts transmission or, if the channel is found to be busy or becomes busy, it generates a backoff count and CW value and begins counting down the backoff slots. At some point, the DCU state control logic  530  determines that frame transmission is “imminent.” The definition of “imminent” would, in theory, be when the DCU&#39;s state control logic backoff count reaches zero, but in practice needs to be somewhat more conservative to allow time to fetch the frame data and forward it to the PCU  240  before the PCU  240  actually needs to put the frame on the air. Thus the DCU state control logic  530  might, for instance, determine that frame transmission is imminent when a frame is available and the backoff count is less than or equal to four (the threshold for the “imminent” determination preferably being software programmable). Regardless of the actual threshold value, once the DCU state control logic  530  determines that frame transmission is imminent, it asserts a DCUReady signal to the DCU arbiter  230  illustrated in FIG. 2. The DCU arbiter  230  inspects the DCUReady inputs from each DCU  520  and selects the highest-priority DCU per the priority levels noted above and asserts a DCUGO signal to the selected DCU  520  and DCUCollision signals to the other ready but lower-priority DCU&#39;s  520 .  
     [0093] The selected DCU  520  now proceeds to select the QCU  410  to be the source of the frame. To do so, the DCU  520  again operates using QCU arbiter  522 , and again logically ANDs the QCU READY bits with the QCUMask value and passes the result into a round-robin priority encoder within the QCU arbiter  522 . The encoder&#39;s output identifies the QCU  410  that will be the source of the next frame in a preferred operational sequence, although all frames associated with a particular QCU may be transmitted together if a different operational mode is desired, although typically this is not preferred. Note that the selected QCU  410  might not be the one that caused the DCU  520  to begin arbitrating for the channel. Once the DCU  520  has selected the QCU  410 , it signals the selected QCU  410  to begin DMA of the frame data from host memory (or from the temporary memory within the QCU as alternatively mentioned above). Note also that the actions taken by the DCU  520  in selecting a particular QCU  410  to be the source of the next frame impose a transmission order on the QCUs, effectively providing a transmission schedule for frames.  
     [0094] The DCU state control logic  530  places the frame data into a prefetch buffer and, simultaneously, drives the data from the prefetch buffer to the PCU  240 . In addition to the frame data itself, the DCU  520  also conveys to the PCU  240 :  
     [0095] The control information from the transmit descriptor; and  
     [0096] A tag that identifies the DCU  520  and QCU  410  from which the frame originated, in an order that is further described below with respect to the PCU FIFOS described below.  
     [0097] The DCU state control logic  530  now waits (if needed) until the EDCF channel access requirements have been met (backoff count is zero, channel has been idle for at least an AIFS, etc.) and then indicates to the PCU  240  to begin frame transmission on the air.  
     [0098] The PCU  240  then initiates transmission of the frame and reports the result to the DCU state control logic  530  that sourced the frame. Once the PCU  240  has completed the frame transmission attempt, it must report the results to the DCU  520  that sourced the frame. The transmission attempt results include:  
     [0099] An indication of whether the frame was  
     [0100] Sent successfully (that is, sent on the air and received a valid ACK if one was expected)  
     [0101] Sent on the air, but no ACK was received  
     [0102] Never sent on the air because the RTSCTSEN bit was set, an RTS was sent on the air, but no CTS was received  
     [0103] The remaining status indications as specified in the transmit descriptor completion status  
     [0104] Another PCU  240  responsibility is to report CCA information to the DCU&#39;s  520  so that the DCU&#39;s  520  can properly implement the EDCF channel access state machine. The PCU  240  continuously reports to the DCU  520  when the channel is busy, taking into account both when the channel is physically busy and when the channel is virtually busy, as indicated by the NAV or other 802.11 protocol state. In order to enable TDMA applications, PCU  240  will include a CCA disable signal, which can come from an external source, for example, the network interface controller chip that can make up the NIC, or an external antenna controller  
     [0105] To allow the DCU&#39;s  520  to begin transferring the next frame to be sent to the PCU  240 , the PCU  240  implements two transmit FIFOS, each large enough to store a single, maximum-size frame (typically about 2360 bytes). As a DCU  520  transfers a frame to the PCU  240 , it indicates into which FIFO the frame data is to be written. The DCU  520  then signals to the PCU  240  that the frame is complete by marking one of the PCU  240  transmit FIFOs as valid. The PCU  240  is responsible for sending frames from its two FIFOs in the same order in which the DCU&#39;s  520  marked the FIFOs valid.  
     [0106] The DCU&#39;s  520  attempt to optimize the case in which the PCU  240  just reported a “transmission failed” event for a frame but now the same frame is going to be retried. Thus the PCU  240  cannot assume that frame transmission alternates between the two FIFOS. In the case described, for example, the DCU  520  marks the same FIFO for re-transmission without any intervening push into the other FIFO.  
     [0107] All frames are transferred to the PCU in the same manner:  
     [0108] The DCU  520  asserts pci-txreq and drives pci-txreq-idx depending on whether the data word is to be written into FIFO  0  or I  
     [0109] The PCU  240  accepts the word only if it asserts pcu-txack in the same cycle in which pci-txreq is asserted  
     [0110] To signal to the PCU  240  that one of its FIFOs should be transmitted, the DCU  520  asserts pci-txfifo-rdy and drives pci-txfifo-idx appropriately. The pci-tX_filter, pci-tx-seqnum, and pci-tx-retry signals are valid in the same cycle in which the DCU  520  asserts pci-txfifo-rdy.  
     [0111] The sequence of data words transferred into the FIFO is:  
     [0112] The first and second data words are words  2  and  3 , respectively, of the first descriptor for the frame. These words contain control information (frame length, frame type, etc.) that the PCU requires to process the frame correctly.  
     [0113] The next N words are the frame data, where N is the ceiling of the total frame length divided by four.  
     [0114] The final word is a DCU-specific cookie. The PCU  240  does not interpret the contents of this word; all it does is echo the word back to the DCU  240  when the frame completes.  
     [0115] If the frame was sent successfully, the DCU  520  repeats the above process and selects a new frame for transmission, potentially from a different QCU  410 . If, however, the PCU  240  reports that frame transmission failed, then the DCU  520  follows the backoff procedure defined in the VDCF specification and re-arbitrates for the PCU  240  on behalf of the same frame until either the PCU  240  reports successful transmission or until the frame&#39;s retry limit is reached, as controlled by the SRL/LRL DCU parameters.  
     [0116] Once a frame is completed, either by successful transmission or by reaching its retry limit, the DCU  520  accepts the status information from the PCU  240  and issues the necessary completion write to update the descriptor status words in host memory.  
     [0117] A particular type of DCU access is known as frame bursting, as mentioned above. Frame bursting is determined in dependence upon whether a ChannelTimeEn bit is set. If set, then the DCU  520  performs a frame burst each time it gains access to the channel. To manage this process, the DCU  520  initializes a timer to the value of the ChannelTime register setting and starts the timer when the DCU arbiter  230  illustrated in FIG. 2 first grants the DCU  520  access to the PCU  240 . The DCU  520  also indicates to the DCU arbiter  230  that it is starting a frame burst. The DCU arbiter  230  responds by continuing the grant that DCU  520  access to the channel, even if higher priority DCU&#39;s  520  become ready, until the bursting DCU  520  indicates that its burst is complete. The DCU  520  ends the frame burst when either the ChannelTime duration elapses or there are no ready QCU&#39;s  410 . Note that during a burst the DCU  420  preferably continues to process ready QCU&#39;s  410  in round-robin order and that the DCU  520  terminates ChannelTime bursts only at intra-frame boundaries.  
     [0118]FIG. 7 illustrates a particular state machine diagram for the state control logic  530  of a particular DCU  520  (and associated portions of the PCU) that implements CSMA channel access, according to one embodiment of the present invention. For this particular DCU  520 , the state information used includes:  
     [0119] S[i] a state variable taking the valued [IDLE, BACKOFF, TRANSMIT];  
     [0120] BC[i] a backoff counter initialized to INF;  
     [0121] QSRC[i] and QLRC[i] short and long term retry counters;  
     [0122] CW[i], the contention window variable;  
     [0123] aCWmin[i] current Cwmin value;  
     [0124] TxAIFS[i] current IFS holdoff; and  
     [0125] aCWmax[i] current Cwmax value.  
     [0126] There are four major states for such CMA channel access protocol implementation: idle; backoff; transmission; and retry. The transitions between these states will now be described.  
     [0127] Idle  
     [0128] On arrival of a frame ( 701 ), if the medium is determined to be idle for longer than AIFS[i], then set BC[i]=0 and attempt transmission ( 702 ).  
     [0129] On arrival of a frame ( 701 ), if the medium is busy, then set CW[i]=aCWmin[i], BC[i]=Random(1, CW[i]+1), and proceed to the backoff state ( 703 ).  
     [0130] Backoff  
     [0131] For each idle timeslot subsequent to the medium having been idle for AIFS[i], decrement BC[i] ( 704 ). Arbitration timing stipulates that backoff counter BC decrements at the end of a timeslot, meaning that BC transitions from one to zero on the first timeslot after AIFS[i]. The backoff decrementing rules for EDCF count the final timeslot of AIFS as the first timeslot to sample for decrementing. Thus, a station with AIFS set to DIFS can decrement BC from 1 to 0 at the end of the AIFS period and transmit in the zeroth timeslot after AIFS, or, in this case, DIFS.  
     [0132] When BC[i] reaches zero ( 705 ) and there is a frame in queue[i] ready for transmission, attempt transmission ( 706 ).  
     [0133] If BC[i] reaches zero ( 705 ) and queue[i] does not have a ready frame, set CW[i]=INF and proceed to the IDLE state ( 707 )  
     [0134] Transmit  
     [0135] TRANSMIT ( 708 ) if no higher priority backoff counter, BC[x], is zero; otherwise perform the retry procedure ( 709 ).  
     [0136] After a successful transmission ( 710 ), reset the appropriate retry counter(s), dequeue the frame, set CW[i]=aCWmin[i],BC[i]=Random(1,CW[i]+1), and go into BACKOFF ( 710 ).  
     [0137] After a failed transmission, do the retry procedure ( 711 ).  
     [0138] Retry  
     [0139] Increment the appropriate retry counter—QSRC[i] or QLRC[i].  
     [0140] If the retry limits have not been exceeded, set CW[i]=min(Cwnew[i],aCWmax), set BC[i]=random(1,CW[i]+1) and go to BACKOFF ( 712 ).  
     [0141] If a retry limit has been exceeded, reset the appropriate counter(s), dequeue the frame set CW[i]=aCWmin[i], BC[i]=Random(1,CW[i]+1), and go into BACKOFF ( 713 ).  
     [0142] As is also shown, the PCU provides a Clear Channel Assessment (CCA) signal when the wireless receiver detects that no wireless signals are present. The duration of the CCA signal is timed as part of the conditional logic  702  within the DCU in observance of the timing procedures of the channel access protocol.  
     [0143] As another example, if functionality related to a beacon is desired, the basic flow between QCU and DCU is as follows:  
     [0144] the host receives a software beacon alert interrupt at a software-defined time before both the DMA beacon alert time and TBTT  
     [0145] At DMA beacon alert (DBA), the QCU&#39;s associated with the beacon and beacon-gated frames become ready.  
     [0146] Since the beacon DCU to which one of these QCU&#39;s is associated has highest priority, it will be the next source of a frame for the PCU. Thus the next frame to be passed to the PCU after the PCU finishes the frame it is presently processing will be the beacon.  
     [0147] The PCU inspects the FrType field of the beacon descriptor and knows that the frame is a beacon. The PCU will use this information to delay actually transmitting the frame until TBTT occurs.  
     [0148] The transmit descriptor for the beacon has its VEOL bit set. Thus after a single frame, the beacon QCU/DCU pair no longer will be marked as ready.  
     [0149] At this point, the beacon-gated QCU/DCU pair becomes the highest-priority requestor for the PCU. Thus as long as the beacon-gated QCU has ready frames, it will be granted, via its DCU, access to the PCU.  
     [0150] This means that the next series of frames to appear on the medium comes strictly from the beacon-gated QCU/DCU.  
     [0151] When the Beacon mechanism is used by an Access Point (AP), i.e. the Basic Service Set (BSS) configuration in 802.11 terminology, this flow works as described, even when the corner case of too many multicast/broadcast frames occurs. In this situation, the beacon-gated queue continues to be marked as ready. But when DBA recurs, the highest-priority beacon QCU/E)CU again is marked READY, and thus the stream of multicast/broadcast frames from the beacon-gated QCU/DCU will be interrupted by the next beacon, which is exactly the desired behavior.  
     [0152] This mechanism must be adapted somewhat to handle the Independent BSS (IBSS) case. In this situation, the QCU associated with beacon-gated frames will have its ReadyTimeEn bit set and its ReadyTime parameter set to the duration of the beacon period minus the SBA, and perhaps minus some queue scheduling uncertainty. Thus once this QCU commences sending frames, it self-terminates before reaching the next SBA because its ReadyTime timer expires. Software then is responsible for clean up should the queue still be non-empty. It may be necessary to put in special-case logic to detect that the corner case of failing to exhaust the beacon-gated queue has occurred and signal an interrupt or provide some other status indication to the software. This is a far simpler task than handling the situation in the QCU or DCU hardware.  
     [0153] The remaining IBSS corner cases—sending a directed frame only if an ATIM has been successfully sent, not sending ATIMs outside the ATIM window, and not sending non-ATIMs until the ATIM window closes—are handled by the PCU, which delays or filters outgoing frames as needed.  
     [0154] As mentioned above, the DCU  520  can be configured to implement many other channel access mechanisms such as polling methods where the DCU generates a poll signal to another networking device (the polled device) to stimulate a data response, or a polled method whereby the DCU sends data only after receiving a poll signal from another device, or a Time Domain Multiple Access method (TDMA) whereby the DCU delivers data to the PCU according to a time slotting protocol. When such mechanisms as these are needed, they are programmed into the DCU state control logic  530 , as described above.  
     [0155] Other Implementation Considerations  
     [0156] Since the media access controller in the preferred embodiment for wireless communications has so many transmit queues, and because software may want to track transmit-related events on a per-queue basis, per-QCU transmit interrupts are preferably provided. To implement this, it is preferable that each of the QCU&#39;s  410  generate interrupts indicating that a frame was sent successfully, a frame could not be sent successfully (retry limit reached, etc.), a frame was sent (successfully or not) and the InterReq bit in the frame&#39;s transmit descriptor was set, or that the QCU has reached the physical end of the transmit descriptor list (generated only by reaching a descriptor with a NULL LinkPtr; not generated just because the VEOL bit was set)  
     [0157] Thus, for the implementation illustrated in FIG. 2, with 16 QCU&#39;s  410 , this leads to 64 transmit-related interrupts. If the maximum size of an atomic register read is limited to 32 bits by the hardware environment, then hardware support for simulating an atomic read of an interrupt status register that is more than 32 bits wide is provided. Thus, provided are several Interrupt Status Registers (ISRs): a single primary ISR and several secondary ISR&#39;s. The primary ISR contains one bit per queue and can be read atomically. The secondary ISRs may be examined after reading the primary ISR to see which sub-bits are set and to service the QCUs identified by bits set in the primary ISR.  
     [0158] Software can check the nontransmit-related interrupts and can determine whether any transmit-related bits are set in the secondary ISRs with just a single read of the primary ISR. In many cases, the software does not even need to read the secondary ISRs; just knowing that some bits are set often is sufficient. The same logical ORing is used for several other ISR bits as well.  
     [0159] In addition, to make the read of all ISRs appear atomic, the present invention will also preferably implement shadow copies of all the secondary ISRs. On the same cycle in which software reads the primary ISR, the contents of all secondary ISRs are copied into the shadow registers. Software then can read the shadow copies of the secondary ISRs and receive a consistent view of the overall ISR state when the primary ISR was read, thus simulating an atomic read of all ISRs.  
     [0160] The preferred embodiment provides two ways to access the primary and secondary ISRs:  
     [0161] Write-one-to-clear access. When used, reads of the ISRs neither copy data to the shadow copies nor clear the ISR being read. Software can write to both the primary ISR and to the secondary ISRS. For each such write, the ISR bits for which the write data bit is a one are cleared. ISR bits for which the write data is a zero are unaffected.  
     [0162] Read-and-clear access. When used, only the primary ISR may be read. Each read of the primary ISR triggers a copy into the shadow registers, as described above, and clears all primary and secondary ISR bits as well, all as a single atomic operation. Writes to the primary and secondary ISRs are not meaningful (and are dropped) in this mode.  
     [0163] Software may intermix write-one-to-clear and read-and-clear ISR accesses.  
     [0164] As mentioned previously, although the architecture using multiple QCU&#39;s and DCU&#39;s has a specific advantage in the context of a media access control for wireless communications, this architecture also can be used to implement schedules, typically hardware schedules, in many environments. By having multiple units that each operate in parallel, increased throughput can be achieved.  
     [0165] Thus, methods and apparatus for network interface controllers and other systems with multiple different queues are described. Further, methods and apparatus that allow for reconfigurable mappings between QCU&#39;s and DCU&#39;s have been described, which allows reconfiguration as changes to the type of traffic occur. Further, methods and apparatus for scheduling have been described in the form of traffic shaping within a QCU, queue selection at the input to a DCU, and DCU selection for input to a PCU.  
     [0166] Although the present invention has been described with reference to specific exemplary embodiments, it will be evident to one of ordinary skill in the art that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the invention as set forth in the claims. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.