MXPA06006016A - Quality of service scheduler for a wireless network - Google Patents

Abstract

In one aspect of the invention, a communication device, operable with a plurality of remote devices, and operable with an admission profile comprising a capacity reservation for zero or more remote devices, comprises a scheduler for determining if a remote device corresponding to the data transmission indicator has a capacity reservation in the admission profile and for allocating capacity in accordance with the data transmission indicator. In another aspect, data indicators correspond to one or more service levels. Remaining capacity may be allocated in priority of increasing size of data transmission requirement. In yet another aspect, an admission profile is updated to accept a new flow, characterized by flow parameters, in accordance with available system capacity.

Description

QUALITY OF THE SERVICE PROGRAMMER FOR A WIRELESS NETWORK FIELD OF THE INVENTION The present invention generally relates to communications, and very specifically to the quality of service programming for a wireless network.

BACKGROUND OF THE INVENTION Wireless communication systems are widely deployed to provide various types of communication such as voice and data. A typical wireless data system, or network, provides multiple users with access to one or more shared resources. A system can use a variety of multiple access techniques such as Frequency Division Multiplexing (FDM), Time Division Multiplexing (TDM), Code Division Multiplexing (CDM), and others. Exemplary wireless networks include cell-based data systems. The following are several such examples: (1) the "Mobile Station Compatibility Standard-TIA / EIA-95-B Base Station for Dual-Mode Broadband Scattered Spectrum Cell System" (the IS-95 standard), (2) the standard offered by a consortium called "Third Generation Partnership Project" (3GPP) and incorporated into a set of documents that include Documents Number 3G TS 25.211, 3G TS 25.212, 3G TS 25.213, and 3G TS 25.214 (the W-CDMA standard), (3) the standard offered by the consortium named "Third Generation Society Project 2" (3GPP2) and incorporated into the "Physical Layer Standard TR-45.5 for Systems of Dispersed Spectrum cdma2000"(the IS-2000 standard), and (4) the high-speed data system (HDR) that conforms to the TIA / EIA / IS-856 standard (the IS-856 standard). Other examples of wireless systems include Wireless Local Area Networks (WLAN) such as the IEEE 802.11 standards (ie 802.11 (a), (b), or (g)). Improvements in these networks can be achieved by deploying a Multi-Input Multiple Output WLAN (MIMO) comprising Orthogonal Frequency Division Multiplexing (OFDM) modulation techniques. As the designs of the wireless systems have advanced, higher data rates have become available. Higher data speeds have opened the possibility of advanced applications, among which are the rapid transfer of data, voice, video, and other applications. However, several applications may have different requirements for their respective data transfer. Many types of data may have latency and performance requirements, or may require a certain Quality of Service (QoS) guarantee. Current systems can offer the best-effort programming of the requests, but in practice the access, on purpose for the case, to a shared resource can be the norm (ie, the Multiple Access with Carrier Detection (CSMA)) . Without resource management, the capacity of a system can be reduced, and the system may not operate efficiently. In addition, if all traffic is treated identically (including access on purpose for the case or better-effort), some applications may be limited or may not work at all (ie, video streams with relatively low latency, in bursts). Therefore, there is a need in the art for QoS programming in the wireless network.

SUMMARY OF THE INVENTION In one aspect of the invention, a communication device, which operates with a plurality of remote devices, and which operates with an admission profile comprising a plurality of time periods and a capacity reservation for zero or more remote devices in each one of the plurality of time periods, comprises a programmer for, during each of the plurality of time periods, for each of a plurality of data transmission indicators, to determine whether a remote device corresponding to the transmission indicator of Data has a capacity reservation in the admission profile and to assign the capacity according to the data transmission indicator. In another aspect, the data indicators correspond to one or more service levels. In still another aspect, the assignment is made for a service level prior to another level of service. The remaining capacity can be assigned by priority in order of increasing size of the data transmission requirement. In still another aspect, an admission profile is updated to accept a new flow, which is differentiated by the flow parameters, according to the available capacity of the system. Other aspects are also presented.

BRIEF DESCRIPTION OF THE FIGURES Figure 1 is an exemplary embodiment of a communication system; Figure 2 is an exemplary embodiment of a communication device, i.e., an access point or a user terminal; Figure 3 illustrates programming the data of three classes for a plurality of terminals / user applications; Figure 4 illustrates an example of admission control; Figure 5 is a flow diagram of an exemplary admission control unit; Figure 6 is a flow diagram of a generalized mode of a programmer method; Figure 7 shows an alternative method to assign the remaining capacity after the QoS programming; and Figure 8 shows an alternative method for assigning the remaining capacity after QoS programming when certain information about the data classes is known.

DETAILED DESCRIPTION OF THE INVENTION The word "exemplary" is used in the present invention to mean "that it serves as an example, case or illustration". Any modality described in the present invention as "exemplary" will not necessarily be construed as preferred or advantageous over other modalities. Figure 1 shows an exemplary communication system 100. The system 100 includes a Wireless Local Area Network (WLAN) 190 comprising the Access Point (AP) 110 and the User Terminals (UT) 130A-130N. The access point 120 includes the scheduler 120 and the admission control unit 125 (among other components, details are not shown). The admission control unit 125 executes the admission control and the programmer 120 schedules the data traffic. Below are several modalities. The access point 120 is connected to an external network 140, i.e., the Internet, corporate intranet, etc., or another data connection. In exemplary mode, the network 140 conforms to the Internet Protocol (IP), and therefore the traffic communication in the network comprises IP packets. Those skilled in the art will recognize that the principles described in the present invention are not limited thereto, and that they can be deployed with any data network. For illustration, applications 150 connected to the external network 140 are shown. In general, an application 150 will reside on a server, or any other device, including another user terminal, which may attempt to establish a data connection with one or more terminals. user 130 sometimes. Said connection, also referred to in the present invention as a data flow, or more simply, a flow, can be established through the AP 110, and the flow can be transported to the respective UT, and with the application integrated within of the same, through an air interface 180. Similarly, applications running on a user terminal, i.e., 160A-160N applications on the UT 130A, may attempt to establish a connection with a device and / or application in another user terminal or connected to the network 140. Again, said connection can be established through the AP 110. The location of the programmer 120 and the admission control unit 125 in the access point 110 is for example only. In alternate modalities, these do not have to be placed. In an alternate mode, one or more UTs may contain a programmer and / or admission control unit. One or more UTs can establish, through signaling, that a designated UT will execute admission control and / or control. In this case, the designated UT is a de facto access point. The designated UT may change over time. One or more UTs may have a connection to an external network 140. Alternatively, there may be no connection to an external WLAN network 190. Managed peer-to-peer connections are also contemplated.

For example, an access point (or designated UT) can manage admission control and / or scheduling for a connection between two other user terminals. Thus, data transmission occurs directly between peers, and only control signaling, such as requests and grants, is transmitted to and received from the management access point (or designated UT). Thousands of configurations, including these options as well as others, will be readily adapted by those skilled in the art by virtue of the teachings of the present invention. In the present invention, an embodiment comprising an access point and one or more user terminals connected in a star topology is often used as an example. This is a useful example to describe the various aspects of the present invention, but the present invention is not limited thereto. WLAN 190 can handle various types of traffic, including real-time services such as voice, video on demand, broadcast video, gaming applications, and TCP / IP network browsing, for example. The characteristics of the flows of the data applications may differ. For example, several streams may have different latency and / or error tolerance requirements. It is generally considered that voice data requires low latency to avoid delay, which could be perceived by the listener. However, several speech coding schemes are known in the art which allow a "lossy" transmission of voice data, i.e. speech quality is not greatly affected by a low level frame error rate consistent. On the other hand, a file download, for example, may not be as sensitive to latency. However, it can be essential that the file be received without errors. To provide an acceptable performance to a provision of anticipated applications, the scheduler 120 provides Quality of Service (QoS) management. In an exemplary mode, traffic is segmented into two groups: QoS-sensitive traffic and Better-Effort Traffic (BET). Traffic with a strict delay and / or bandwidth restrictions is placed in the QoS responsive group. The rest is placed in the best-effort group. The scheduler 120 manages the QoS sensitive traffic using a bandwidth reservation scheme that is detailed below. The admission control unit 125 employs admission control to accept or reject a proposed flow based on flow characteristics and the amount of resources available. The best-effort traffic is managed using a simple critical circuit queue formation scheme. These as well as other alternative modalities are detailed below. In the exemplary embodiment, the air interface 180 is a WLAN of Multiple Inputs Multiple Out (MIMO) using Orthogonal Frequency Division Multiplexing (OFDM). Alternatively, other air interface schemes may be used, including, FDM, CDM, TDM. Other techniques such as spatial diversity may be employed to allow multiple users to access one or more common interfaces. Several standards and designs for air interfaces have defined one or more types of channel for transmission and reception in a shared communication resource. Typically, one or more control channels and one or more data channels are recommended. A broadcast channel is often defined for sending signals to more than one destination simultaneously (for example, a message on the forward link). Often a random access channel is deployed for devices to gain access to the network (for example, UTs that initiate communication on the reverse link). Any configuration of data and / or control channels can be displayed within the scope of the present invention. Regardless of the channel, or the type of channel, the users (ie, applications 150 connected through the network 140, or user terminals 130) make requests for access to the shared resource. The programmer assigns the resource using one or more of the techniques detailed below. One or more users are then granted access to the shared resource. Those skilled in the art will readily adapt the principles described in the present invention to various communication systems. Figure 2 is a block diagram of an exemplary communication device, such as a user terminal 130 or access point 110. The blocks shown in this exemplary embodiment will generally be a subset of the included components, either in a user terminal 130 or access point 110. Those skilled in the art will adapt easily the mode shown in Figure 2 for use in any number of access point and user terminal configurations. It can be seen that the use of the terms forward link and reverse link is for analysis purposes only. When an access point 110 operates analogously to a base station and the user terminals interact in a typical star topology, the terms forward link and reverse link are apt. However, as described above, the scope of the present invention encompasses networks purposely for the case (wherein any one of a number of user terminals 130 is configured as a de facto access point 110), the connections peer-to-peer managed, and the like. Those skilled in the art will recognize that the use of these terms does not limit the scope of the invention, but may serve as convenient conventions for the context in which they are being used. The signals are received on the antenna 210 and delivered to the receiver 220. The antenna 210 may comprise one or more antennas. The receiver 220 executes processing according to the WLAN system 190, which may correspond to one or more wireless system standards, such as the standards mentioned above. Receiver 220 executes various processing such as Radio Frequency (RF) for baseband conversion, amplification, analog-to-digital conversion, filtering, and the like. Several reception techniques are known in the art. The receiver 220 can be used to measure the quality of the forward or reverse link channel, although a separate channel quality estimator 235 is shown for purposes of analysis clarity. A channel quality estimator 235 can be used to determine the quality of the channel, and therefore to calculate the bearable data rate. When a communication device knows the amount of data it has to send, or the required duration of the transmission, and the data rate bearable, it can determine the amount of resources it needs and makes a request accordingly. In exemplary mode, a communication device determines the number of OFDM symbols it requires to transmit. Those skilled in the art will recognize that there are many alternatives that can be deployed to determine the amount of shared resources that are required to transmit a known amount of data in a variant channel. As an alternative, a transmission request may include the amount of data and a channel quality indicator. The programmer could, in turn, make a determination regarding the number of OFDM symbols to be granted based on these factors. The signals from the receiver 220 are demodulated in the demodulator 225 according to one or more communication designs or standards. In an exemplary embodiment, a demodulator having the ability to demodulate MIMO OFDM signals is deployed. In alternate modalities, alternative standards can be supported, and there are modalities that can support multiple communication formats. The demodulator 230 can execute the reception of RAKE, equalization, combination, de-interleaving, decoding and other functions as required by the format of the received signals. Various demodulation techniques are known in the art. At an access point 110, demodulator 225 can perform the demodulation according to the reverse link. In a user terminal, demodulator 225 can perform the demodulation according to the forward link. Both the data channel and the control channel described in the present invention are examples of channels that can be received and demodulated in the receiver 220 and the demodulator 225. The demodulation of the forward data channel can occur in accordance with the signaling in the control channel, as described above. The message decoder 230 receives the demodulated data and extracts the signals or messages directed to the user terminal 130 or access point 110 on the forward or reverse links, respectively. The message decoder 230 decodes several messages used in setting up, maintaining and dropping a data session in a system. The messages may include transmission requests, transmission grants or any number of messages from the control channel. Other types of messages are known in the art and can be specified in various standards or communication designs that are being supported. The messages are delivered to the processor 250 for use in further processing. Some or all of the functions of the message decoder 230 may be carried out in the processor 250, although for clarity of analysis, a discrete block is shown. Alternatively, demodulator 225 can decode certain information and send it directly to processor 250 (a single-bit message such as an ACK / NAK or a control on / off command, to mention a few examples). The channel quality estimator 235 is connected to the receiver 220, and is used to perform various power level calculations for use in methods described in the present invention, as well as for use in other processing used in communication, such as demodulation. . The channel quality estimator 235 is shown as a discrete block only for clarity of the analysis. It is common for said block to be incorporated into another block, such as the receiver 220 or the demodulator 225. Various types of signal intensity calculations can be made, depending on the signal and the type of system being calculated. In particular, for a MIMO channel (M transmission antennas and N reception antennas), the channel calculation can be an Mx matrix. In general, any type of channel quality metric calculation block can be displayed in place of the channel quality estimator 235 within the scope of the present invention.

The signals are transmitted through the antenna 210, which may include a plurality of antennas. The transmitted signals are formatted in the transmitter 270 according to one or more standards or designs of wireless systems, such as those mentioned above. Examples of components that may be included in the transmitter 270 are amplifiers, filters, digital-to-analogue converters (D / A), radio frequency (RF) converters, and the like. The data for transmission is provided to the transmitter 270 by the modulator 265. The data and control channels can be formatted for transmission in accordance with a variety of formats. The data for transmission in the channel. forward link data can be formatted in modulator 265 according to a modulation rate and format indicated by a programming algorithm according to a C / I or other channel quality measurement. Examples of components that can be incorporated into the modulator 265 include encoders, spreaders, and modulators of various types. The message generator 260 can be used to prepare messages of various types, as described in the present invention. For example, request messages may be generated to request access to the air interface for transmission. Granting messages may be generated for transmission in response to request messages, the granting message contains a shared resource allocation available for the requesting user terminal, for example. Various types of control messages may be generated at either the access point 110 or the user terminal 130. The data received and demodulated in the demodulator 225 may be delivered to the processor 250 for use in data communications, as well as for others components. Similarly, the data for transmission can be directed to the modulator 265 and the transmitter 270 from the processor 250. For example, various data applications may be present in the processor 250, or in another processor included in the communication device 110 or 130 (not shown). An access point 110 may be connected, through the network interface 280, to one or more external networks, such as the Internet, or network 140. A user terminal 130 or access point 110 may include a link to an external device, such as a laptop (not shown). A programmer, such as programmer 120, described above, may reside in processor 250. An admission control unit 125 may reside in processor 250. Various modalities thereof are detailed below. The processor 250 may be a general purpose microprocessor, a digital signal processor (DSP), or a special purpose processor. The processor 250 can perform some or all of the functions of the receiver 220, demodulator 225, message decoder 230, channel quality estimator 235, message generator 260, modulator 265, transmitter 270, or network interface 280, as well as any other processing required by the communication device. The processor 250 may be connected with special purpose hardware to assist in these tasks (the details of which are not shown). The data and voice applications can be external, such as a connection or laptop externally connected to a network, can run on an additional processor within the communication device 110 or 130 (not shown), or can run on the processor 250 same. The processor 250 is connected to the memory 255, which can be used to store data as well as instructions for executing the various methods and methods described herein. Those skilled in the art will recognize that the memory 255 may be composed of one or more memory components of various types, which may be incorporated in whole or in part within the processor 250. A memory 255 may be used to display one or more tails, as described in the present invention. The memory 255 is convenient for storing one or more admission profiles, which are detailed below. In the exemplary mode, a single Media Access Control (MAC) frame is deployed, which can support multiple UT flows as well as multiple flows per UT. A superframe comprising a plurality of MAC frames is defined. In this example, the number of MAC frames in a super-frame is 16. In exemplary mode, a Control Channel (CCH) is transmitted at the start of each MAC frame containing the programming information for all active flows in the segments of forward link and reverse link of the current MAC frame. The programming of the forward link is facilitated through the use of the link data rate information feedback from the UTs. The programming of the reverse link is facilitated through the queue status information and the implicit link data rate information provided by the UTs (for example, the amount of capacity requested is correlated with both the data demand and with the quality of the link). A latent UT can use a Random Access Channel (RCH) to request system resources. An access point can also register user terminals, as an option. It can be seen that, in the case of managed peer-to-peer connections, all transmissions are between torque UT and, from the perspective of the programmer, they can be treated as part of the programming of the reverse link. Generally, it is desirable to minimize the delay between the time when the link state information is received at the access point and the time at which the resulting programming information is transmitted to the UTs on the CCH. Excessive delay can result in the data rates allocated in a given MAC frame becoming obsolete if the Radio Frequency (RF) channel changes before the resulting transmission occurs. In exemplary mode, an objective delay of a MAC frame (approximately 2 ms) is used as a target. In the exemplary mode, the forward link data for multiple UTs are stored in queues at the access point. The queues may or may not be identified by the type of data class. Alternatively, the respective queues can be maintained in applications connected through the network 140. In this example, the reverse link data is stored in queues at respective user terminals. It can be seen that the use of the terms reverse link and forward link does not prevent the use of peer-to-peer connections (where the data flows between peers, and not to, or from the access point, or UT of management), or any of the other alternatives described here. The requests for access to the shared communication resource can identify the type of data that is being requested, or they can simply be a single request that can allow multiple classes. In the exemplary embodiment, a request for a number of OFDM symbols is made. In the alternative, a request can be made for any portion of the shared resource (ie, time slots, channels, power, etc.). The requests may reflect that the requesting body has adjusted the size of the request based on the amount of data and the bearable bit rate, due to the changing conditions of the channel. An advantage of this type of request is that the programmer does not need to have access to peer-to-peer channel measurements in managed peer-to-peer situations, nor does it need to explicitly determine the quality of the reverse link channel (i.e. situations where the forward link and the reverse link are not necessarily symmetric). Alternatively, a request may not specify the amount of the desired resource, but rather the amount of data and some channel quality indicator. The programmer can allow any type of request, or combination of application types. For clarity, it can be assumed that the various user terminals are fixed, although the scope of the present invention is not limited thereto. For purposes of clarity of the present invention, the transfer between multiple access points by a mobile UT is not analyzed. Whether mobile or not, the wireless channel between any UT and the AP may vary over time due to various causes of interference. Therefore, the capacity of the forward and / or reverse link for any UT may fluctuate. As discussed above, the UT flows are placed in one of two categories, namely better-effort and sensitive to QoS. The best-effort service is provided for latency-insensitive flows. The reservation of the bandwidth, coupled with the admission control, is used for QoS sensitive flows. The independent control of the latency is also facilitated by the scheduler 120. The QoS sensitive flows are assigned a nominal fixed fraction of the resources, either on a per MAC frame basis or in a distributed form on a superframe (it is say, 16 MAC frames). The nominal assignment is a function of the traffic profile of the resource that is statistically characterized by a set of parameters that can include the average speed, the maximum speed, the bursts, the maximum latency, etc. The admission control unit 125 uses these and other parameters to determine the nominal speed and program that are required to satisfy the QoS requirements of a flow. As detailed below, the programming task is complicated by the fact that the instantaneous data rate of the source and the bit rate supported by the channel may vary. Many data applications have burst traffic profiles. For example, video encoded with MPEG (Motion Picture Experts Group - International Electrotechnical Commission / International Standards Organization) can show peak-to-average ratios approaching 10: 1. The signal-to-noise ratio (SNR) of the wireless channel can vary widely due to shadowing and interference (regardless of whether the UT is mobile or fixed), and therefore the bearable data rate of the link also varies widely. QoS guarantees can be met and good system efficiency can be achieved by using an appropriate admissions policy coupled with statistical multiplexing. When a flow requires resources in a nominal allocation, it can be allocated additional resources, as long as they are available.

When a large number of flows are supported, the gains of statistical multiplexing can be substantial and good system efficiency is obtained as a result. - Below are several types of programming and admission control. A summary of an exemplary mode is shown below. Resources not used in a MAC frame are made available to other flows. Flows sensitive to QoS, whose instantaneous requirements exceed their nominal assignments, are the first to receive service. Unused resources are distributed in a way that maximizes the number of flows that meet your QoS requirements. If there are still resources left after servicing the QoS sensitive flows, then the best effort flows are serviced. The unused resources can be distributed among the best effort flows in a critical circuit form. Optionally, a fairness policy can be deployed. Figure 3 illustrates programming for data of three classes for a plurality of terminals / user applications. In an exemplary mode, traffic is classified into three groups by the programmer. The prioritization within each group is handled differently. In this example, each UT manages separate queues for each traffic class. The UTs can have multiple flows in each traffic class. In exemplary mode, the queues are managed as byte-oriented buffers. The bytes in a queue receive service using a first-in-first-out (FIFO) discipline by the programmer. In alternate modalities, any type of access order and queue can be displayed. The first traffic class, the Radio Link Control (RLC) traffic, is associated with the management of the radio link connection of a UT and is generally quite time sensitive. Therefore, in this example, the RLC traffic has the highest priority of all traffic classes. The programmer first allocates the resources to the UTs with pending RLC traffic. RLC traffic typically constitutes a small fraction of total resources. As such, for clarity of analysis except in the cases that were observed before, the following modalities are described with respect to the following two classes of traffic. Those skilled in the art will readily adapt any of the embodiments described in the present invention to allow a third class of traffic, such as RLC. The second class of traffic, flows sensitive to Quality of Service (QoS), requires more stringent parameters to meet needs such as maximum latency and / or capacity to carry data in burst. QoS-sensitive flows can be assigned a nominal fraction of the total resource through the admission control unit. QoS traffic takes precedence over Best Effort Traffic (BET), the third traffic class. Flows that request substantially more resources than their nominal allocation are more likely to receive degraded service. QoS traffic can make up a substantial fraction of total resources, depending on how the system is managed. The third class, BET, has the lowest priority. Below is a variety of techniques to handle BET traffic. In Figure 3 a plurality of queues, 310A-310N, is maintained for a plurality of UT A-UT N user terminals. It can be seen that these queues can be maintained at an access point 110, for forward link transmission. In that case, the access point would know exactly what queues are contained in what kind of data. Analogous queues can be maintained at each of the respective user terminals 130A-130N. The user terminals may or may not indicate to an access point, in a transmission request, which class or classes of data are included in the transmission request. Below are several modalities that include both situations, and a combination of both. In general, those skilled in the art will be able to display a programmer to program either the forward link or the reverse link, or both, by virtue of the teachings of the present invention. The RLC programming function 320 programs the RLC data in queue from each of the respective RLC queues. The QoS programming function 330 programs the respective QoS queues. Similarly, the BET programming function 340 schedules the BET queues, which have the lowest priority. The resulting transmissions are shown for UT A - UT N at the bottom of the figure. It can be appreciated that, as an illustrative exception, a portion of the QoS queue 310B is programmed in the BET portion for that UT, as opposed to the QoS portion. This illustrates an example of a request that exceeds the nominal QoS assignment. In this case, the BET allocation was sufficient to meet any remaining QoS traffic needs, and no degradation of QoS will be experienced. Figure 3 only serves as an example of data classes and programming. Below are several modalities. Below are two basic aspects: admission control and package programming. An exemplary system employs the admission control unit to control the acceptance or denial of the service for QoS sensitive traffic. The programmer can maintain a record of the admitted flows and may try to keep their service speeds negotiated.

Admission control If desired, you can reserve a maximum number of slots (ie, OFDM symbols), FRr for QoS sensitive traffic. The rest, if any, FB, is reserved for the best effort traffic. The total resources available (not including RLC or similar control class traffic, as discussed above) are provided by FA: _ (1) Fa - FR + FB FR can be used by the admissions control unit to determine whether or not to commit resources to a flow that is requesting a specific QoS. The admission control unit can use several per-flow variables to determine whether or not a flow is allowed. Some examples are shown below, and others will be clear to those skilled in the art. Several font characterization variables can be specified. For example, you can specify a reservation request for bandwidth ar (i) for flow i, which is a data rate requirement in bits / seconds and can be calculated based on the QoS parameters associated with the flow . A dynamic counter model can be assumed when describing the source, that is, an average sustainable speed, peak speed, and burst capacity. You can also specify a maximum latency of the source dmax (i) to derive an efficient method for programming the flow. You can also specify multiple link characterization variables. For example, you can identify an achievable average data rate r (í), observed in the link (with separate variables maintained for forward and reverse links). r (í) is the average value of the achievable speed associated with the physical layer for each terminal and can be determined during the registration / calibration. This value may fluctuate over time based on the conditions of the link (ie, fading, path loss, interference, etc.). In this example, the flows in the QoS group are assigned a nominal slot allocation by the admission control unit based on these parameters. The nominal assignment guarantees that a fixed number of slots will be assigned in a given time interval (ie, an integral multiple of frames). Depending on these parameters, the nominal allocation may result in a fixed number of slots per MAC frame, or a fixed number of slots per superframe (i.e., 16 MAC frames). If the speed of the source data exceeds the negotiated speed or the speed of the link data falls below the negotiated speed, the flow will require additional slots to meet this requirement. In these cases, statistical multiplexing can provide the adequate flow margin to meet the deficits per-flujb. The efficiency of the statistical multiplexing is proportional to the number of users who share the resource. In general, more users result in greater efficiency. In this example, the allocation assigned to flow i is provided by: í = mi (^ max (0) (2) where: It can be seen that \ x \ implies x rounded up, and ^ max is an upper limit imposed on the maximum allowance for a single flow. Those skilled in the art will recognize that, in some modalities, the smaller the fmax, the greater the efficiency of the system. However, in some circumstances, limiting fmax can restrict potentially the coverage area for higher speed services. Those skilled in the art will adapt fmax, according to this compensation at the time to display several modalities. The total allocation is the sum of the allocations for each flow in the QoS group, Na: FR =? F (j) (4); = 1 The requirement for a given flow is provided by: < p (i) = brQ) (5: r i) where br (i) is the instantaneous bit rate of the source and r (i) is the data rate observed in the link. The total requirement is provided by: Na D =? FQ)? = L (6) A service outage occurs whenever the total requirement exceeds the total allocation. In an exemplary embodiment, the admission control algorithm denies the service to any flow that causes the probability of D > FR exceeds a cut-off threshold (for example 0.1%). It can be seen that a cut does not necessarily translate into a cut for all flows. The cutoff probability associated with a specific flow depends on the other instantaneous flow requirements. In an exemplary admission control embodiment, each UT with a QoS flow is assigned a utilization factor and a MAC frame phase parameter. The utilization factor indicates the periodicity associated with the schedule interval for the flow (for example, 1 slot for every 10 MAC frames). The phase parameter indicates the MAC frame rates for whose transmission the flow occurs (for example, 0 to 15). When multiple QoS flows are handled per UT, the flow with the highest utilization factor can dictate the program for all QoS flows associated with the UT. Consider the following example that is illustrated graphically in Figure 4. Assume that a velocity request for a stream results in a requirement of 375 slots per superframe (ie, 32 ms). To satisfy the speed parameters for this flow, an average of 23.4375 slots per MAC frame is assigned. In addition, assume that the flow has a parameter of maximum latency of dmax (i) = 5 MAC frames (ie, 10 ms). The following is an allowable allowance: MAC frame # 4 117 slots MAC frame # 9 117 slots MAC frame # 14 117 slots MAC frame # 15 24 slots The admission control unit constructs an assignment vector over the 16 MAC frames in a superframe : A [i] =. { 0.0, 0.0, 117, 0.0, 0.0, 117, 0.0, 0.0, 117, 24.}. D Allowing R [i] to be the slot allocation vector added for MAC frames 0.1, ... 15. The admission control unit can then determine a phase change, kñ, of A [i] designated to reserve availability for subsequent assignments. Figure 4 illustrates an exemplary R [i], and the result of a change in A [i] of kñ = 15 summed with R [i]. Those skilled in the art will recognize that various criteria can be used to determine whether a flow is accepted, and how to allocate an accepted flow. For example, the capacity of a frame can be assigned to both QoS and BET traffic. The assignment can be set per frame, or it can be adjusted to increase the efficiency of the package. For each assignment, there may be a tradeoff between packaging efficiency and the ability to accept additional flows. Those skilled in the art will adapt various modalities to make allocation decisions based on various factors, including, for example, statistical properties of the expected number of QoS flows in a given time, and the expected parameters of the flows (ie, the factor of use and phase, etc.). In addition, those skilled in the art will recognize the potential trade-off between efficiency achieved and maintenance of QoS. For example, consider a flow whose speed and maximum latency allows it to be transmitted satisfactorily during a slot every 4th MAC frame, reaching a packing efficiency of 80%. Alternatively, the flow could be transmitted during a slot every two MAC frames with a slot packing efficiency of 40%. From the perspective of the efficiency of a system, the first program will be preferred. However, the second program may be better from a QoS perspective because it can provide an additional link margin to handle a reduction in link data rate. An admission control unit can be deployed with the ability to balance the desired level of efficiency and / or QoS maintenance when establishing flow programs. Figure 5 is a flow diagram of an exemplary admission control unit 500. In block 510, an application makes an admission request for a new QoS flow. The request contains parameters for expected characteristics of the flow. Examples of such features are described above. It should be remembered that, in general, the admission control unit makes admission decisions on expected parameters (ie, averages). However, the programmer will be assigning capacity based on real-time data transmission requests, which is a function of the actual amount of data and the present state of the communication channel with time variation. In block 520, the admission control unit evaluates the capacity availability for the new requested flow, based on the existing admission profile, which indicates the expected data requirements for the already admitted flows. Previously, an exemplary way to determine how to incorporate a requested stream under an existing profile was described with respect to FIG. In decision block 530, if there is sufficient capacity to allow for performance requirements, as well as any QoS requirements (such as latency and utilization factor requirements), continue with block 540. In block 540, send a message to the requesting application indicating that the new flow has been accepted. The requesting application can then start any process or processes that are associated with the new flow. If there is not enough capacity, in decision block 530, continue with block 570. In block 570, send a message that rejects the new flow for the requesting application. Then the procedure can be stopped. In block 550, after a new flow has been admitted, modify the admission profile to include the commitment for the new flow. Those skilled in the art will recognize that there are thousands of ways to represent an admission profile within the scope of the present invention. In the exemplary mode, the capacity is assigned in terms of OFDM symbols. A MAC superframe consisting of 16 MAC frames is displayed. The admission profile includes a commitment, or contract, for a number of OFDM symbols in each MAC frame assigned to each supported stream. In alternate modes other capacity units may be assigned, such as time slots in a TDM system, power and / or codes in a CDMA system, etc. An admission profile can be established at different levels of granularity in time, and can be of variable period length. In addition, a commitment to a flow does not have to be fixed for specific frames. For example, a stream can be assigned a certain number of symbols within a range of frames as part of its commitment to admission profile. The programmer can have flexibility as to which frames to assign to the flow, as long as its contractual minimum within the specified range is met. In block 560 the updated admission profile is provided to the programmer. Any means for making the admission profile available to the programmer falls within the scope of the present invention. For example, the programmer can simply access the admission profile in the shared memory with the admissions control unit. In an alternate mode, the admission profile can be signaled or sent in a message to the programmer. The entire admission profile does not have to be transmitted, since the addition of new flows can be combined with previously admitted flows to form the current admission profile. Then the procedure can be stopped. It can be seen that the procedure can be repeated as often as desired to allow applications to reserve bandwidth with the programmer. Furthermore, it can be appreciated that the flows can also be removed from the intake profile, as will be apparent to those skilled in the art. The details are not shown in Figure 5. An application can send a message indicating that a flow is no longer necessary. Alternatively, a new request can be sent to modify a flow. As another option, a programmer can direct the admission control unit to withdraw a flow if the application is not adhering to its contracted parameters. In such a case, the flow may be cut off completely, or relegated to a state of best effort. In such a case, an application may be forced to terminate the procedure associated with the flow in case the minimum QoS levels are not being met. That application can re-request admission for a flow, with adjusted parameters, to establish a maintained QoS service with the programmer (that is, service renegotiation).

QoS Programming In a basic mode that uses QoS programming, a transmission request (ie, access) is made for a flow. The request does not need to identify the type of traffic for transmission, this may simply be an indication of the amount. In this situation, the requesting application can sort the data in its queue according to the priority (ie, QoS before BET). It can be seen that in a modality where the programmer is placed with one or more queues, such as at an access point with queues for forward link traffic, or at a UT that acts as an access point or manages a or more peer-to-peer connections, as described above, a transmission request may not be necessary, since the data in the various queues placed indicate the need for transmission. In a basic mode, the type of data in the queue may not be known, in which case the sending application should sort the data sent to the queue according to the priority. In these basic scenarios, QoS programming can be allowed through the use of the contracted commitments indicated in the admissions profile. Additional functionality and control may be available when additional information regarding queued data is available. For example, when the programmer is placed with one or more queues associated with several streams, and the queues are separated or otherwise provide an indication of the data class (ie, QoS or BET), the programmer knows how many data, and of what kind, are waiting for transmission. The programmer can prioritize the data of different types in this scenario. An exemplary mode can be an access point that holds queues for forward link flows. It can be seen that the applications that produce these flows could be seen as needing to indicate the class of data if more than one kind of data is being sent from a source to a UT. In such a scenario, reverse link programming may be basic, as described, while forward link programming may be considered for several kinds of data (described below). Optionally, a transmission request can indicate the class of data. If more than one class expects transmission (that is, from a UT), a request can indicate how much data of each type is waiting for transmission. In this case, the programmer can consider the data class just as it does with the queues placed. You can display any combination of request types and queues within a modality. A programmer can simply take advantage of specific knowledge when it is available, and continue without that information when it is not available. In any mode, a programmer can use the admission profile, as contracted between the various applications / flows and the admissions control unit, as described above, to achieve the benefits of QoS programming, as described in present invention. A flowchart of a generalized modality of a 600 programmer method is shown in Figure 6. The 600 method can be used for the basic scenario described above, scenarios where more advanced knowledge of the data classes is available, or any combination of them. Figure 7 further details a 640 block option, convenient for use when the type of class is not known. Figure 8 also details a block option 64, convenient when the type of class is known. Figure 8 also illustrates other aspects of the present invention. Method 600 begins at block 610, where an updated admissions profile is received from the admission control unit. As described above with respect to figure 5, the admissions profile can simply be stored in a shared memory, so that the admission control unit and the programmer have access to it. In an alternate modality the admission profile updates are transmitted, and the updates are incorporated in the current status of the admissions profile available to the programmer. It can be seen that the commitments for QoS flow capacity can be added or withdrawn over time. In block 620, the programmer receives a plurality of transmission requests from a plurality of user terminals and / or applications (i.e., that are received through network 140). In block 630, for each applicant application / UT with a contract in the admissions profile, assign capacity up to the amount contracted. In exemplary mode, each application / UT may have a contracted number of OFDM symbols reserved for transmission in the current frame (an example of which was described above with respect to Figure 4). It can be appreciated that an allocation associated with this block 630 may not satisfy all the requested amount of data. This is due to the fact that variable speed data sources often generate more data than the average amount that would have been used for contracting. In addition, the degradation of the wireless channel may require additional capacity (i.e., OFDM symbols, time slots, power, etc.) to transmit a desired amount of data. In block 640, if there is still additional capacity to assign, it can be divided among any remaining requests. In figures 7 and 8, which are described below, alternatives for block 640 are shown. In one embodiment, the remaining capacity can be allocated using any number of best effort type strategies. For example, the capacity can be assigned as a critical circuit among the remaining requests. In an alternate modality, these UT / applications with QoS assignments contracted in a frame can be given priority over the remaining BET assignment, under the theory that part or all of the remainder of their request, not assigned in block 630, may be QoS data that exceeded the contracted assignment. Other unbiased criteria may be used to allocate the rest. Additional prioritization levels can be deployed so that some UT / applications are given priority in the BET assignment over others. Any combination of these techniques can be displayed. Below are additional options. Those skilled in the art will readily extend the teachings of the present invention to additional classes, and combinations of types of classes. For example, for clarity of the analysis, several modalities described herein have omitted the description of the RLC traffic, described above. In an exemplary embodiment, the RLC traffic may be the traffic with the highest priority, but may also require a relatively small amount of the overall capacity. Because of this, one method to allow this third class of high priority data is to allocate a small amount of capacity to each requesting UT for which the RLC data can be a portion of the request. The rest can then be assigned according to the QoS or BET programming, as described in the present invention. Obviously, if the request identifies RLC traffic or otherwise is known to exist (ie, that is contained in a queue placed), the assignment can be made in a simple manner. Figure 7 shows an alternative mode of block 640 to allocate the remaining capacity after QoS programming. As an alternative to the various methods described above, the modality of block 640, shown in Figure 7, can be displayed to try to maximize the number of UT / applications that have their transmission request granted. In block 710, applications that were not assigned, or only partially assigned, in block 630, described above, are classified, where the highest rank is inversely proportional to the size of the request (or the remaining portion thereof). In block 720, the remaining capacity is assigned to requests starting from the highest rank. If the final assignment can not be made in full due to lack of capacity, that request will be partially distributed. Therefore, the maximum number of requests that can be allowed is fulfilled through this method. This modality can be used together with several techniques described above. As already described, when the programmer is aware of the type of data associated with a request, or in a queue, that information can be incorporated into the programming decision. To illustrate this principle, consider the following example. An active indicator is maintained for each QoS flow managed by the programmer. In any given frame, the active indicator is configured for all supported QoS flows that have a nominal allocation of slots within that frame (as in the example in Figure 4). All QoS flows with their configured active indicator receive service first in a current MAC frame. Other QoS flows may or may not receive service in the current MAC frame, depending on whether or not FR resources are used. In this example, FR can be a limit on the amount of capacity reserved for QoS services, as described above, and FB can be reserved for best effort traffic. It is clear that FR can be configured to any capacity, if desired. When the programmer knows if one or more partially allocated requests contain QoS data, and other requests are directed to better effort traffic, the programmer can prioritize the remaining QoS traffic. It may also be desirable for the programmer to "work in advance," when a portion of the RF is not fully allocated to reduce a future load. The use of this option to preempt current BET requests may be convenient when a limited portion of capacity, FR1, is assigned to the QoS service. However, the work in advance (detailed below) can be executed whenever there is unassigned capacity. In this example, the active flows sensitive to QoS are segmented into two groups: those with a positive flow margin D +, and those with a negative flow margin, D ~: i < = D ~, if f (i) > f (i), Q i e D +, if < p (i) = f (i) (9) D + flows do not experience a cut because their flow requirement is less than, or equal to, their allocation. In addition, flows in D + that have a positive flow margin contribute to a grouping of unused slots, M, which can be made available to other QoS flows in a prioritized manner. The D ~ flows may or may not receive their requirement, depending on whether unused resources are available. If D "is not empty, then any unused slots can be made available to flows in this first group.There are a number of ways to handle the allocation of unused slots to activate QoS flows in D ~. example, it is to maximize the number of flows that meet its QoS requirements, this is achieved by ordering the flows in D ~ by rank based on their flow margins, ie, the flow with the smallest receives the highest rank, it can be seen that m ± that belongs to D "implies that my is a negative value. In this example, the programmer assigns the minimum number of slots from the pool of excess margin to allow the flow with the highest range D "to meet its requirement, f (i) .This procedure is repeated until the Excess margin grouping or until all the active QoS flows receive service If the last considered QoS flow is not fully satisfied, then a partial allocation can be granted The flows that can not be fully satisfied can be experienced A degraded service This example can result in a flow that does not receive its allocation, in which case buffer overflow can occur and packets can be lost To avoid this, the buffer overflow from the QoS queue for A given flow can be placed in the front of the user's best effort queue, if after servicing all active flows there is still Unused curves, the remainder of FR can be made available to the group of QoS streams that have data in their QoS queues but do not have an active pointer configured for the current frame. This "work in advance" programming capability, presented above, is typically executed when the programmer has access to data that will be transmitted in the future, that is, data that is intended to be transmitted in the next frame or frames. In one embodiment, the access point hosts the scheduler and maintains queues for forward link data. Therefore, the programmer can work in advance, if desired, when appropriate. In an exemplary mode where requests for reverse link data are scheduled for QoS based solely on the admission profile (as described above), the programmer may not have knowledge of future data in the user terminal, and, for therefore, only execute the work in advance in the advance link. For this reverse link, the programmer does not distinguish between QoS and BET data beyond what is programmed in the MAC frame (according to the admission profile). That is, once the QoS traffic for a given flow has been granted its requirement in the reverse link segment, the rest of the data of that UT is considered by the programmer as BET traffic. Those skilled in the art will recognize how to adapt this principle to the forward link or the reverse link, and to any location of the programmer. In particular, this programmer may be in a designated UT that provides programming for peer-to-peer connections managed using the procedures described above. Additionally it can be seen that, from the perspective of the UT, in this example, the data can be accommodated in any desired way in the tail of the UT (for example, QoS working data in advance can be placed on the front of the BET queue of the UT). Therefore, the UT can execute work in advance, if desired, even when the programmer can not. The assignment of unused slots to inactive forward link QoS flows (work in advance) can be done in the following way. Inactive forward link QoS flows are classified by priority according to their phase parameter. That is, the idle forward link flows that become active in the next MAC frame receive the highest priority. The flows within this phase group are prioritized in a way that maximizes the number of flows satisfied (as described above). Therefore, inactive flows are first serviced with the least amount of data in their queue. The programmer continues to provide work in advance to those inactive QoS flows until all the slots in FR are occupied, or all QoS queues are empty. Figure 8 shows an alternative mode of block 640 to allocate the remaining capacity after QoS programming when certain information is known regarding the data requested for transmission (or placed in a queue). This modality is compatible with the example of positive and negative flow margins, previously described, and optionally you can also use the work in advance. The procedure starts at decision block 810. If there is no remaining capacity to be allocated, the procedure stops. If there is remaining capacity, continue with block 820. In block 820, QoS requests are sorted by rank. You can contemplate several classifications by rank. In exemplary mode, to service most requests, requests are sorted by rank in inverse function to their size. In block 830, the ranked request with the highest rank is selected (the highest rank for the first iteration). In block 840, the remaining capacity is assigned to the selected request. If the rest of the request is greater than the remaining capacity, the rest of the capacity will be assigned. In decision block 850, if the remaining capacity has been exhausted, the procedure can be stopped. If there is still capacity, continue with decision block 860. In decision block 860, if there are additional QoS requests that remain unassigned, return to block 830, select the request with the next highest rank, and repeat the procedure that has just been described. If all QoS requests have been processed, continue with block 870. Block 870 is shown with a discontinuous contour to indicate that advance work is optional. If desired, the programmer can work in advance for future QoS frames. Previously, an exemplary method for executing such work in advance was described. In block 880, any remaining capacity is allocated to the best effort traffic. Any method of better effort can be deployed. In an exemplary embodiment, the best effort traffic is served using a critical circuit programming method. Such an approach does not provide QoS differentiation through different user terminals, or through multiple flows associated with a particular user. However, as described above, a user terminal is free to prioritize the packets in its queue to allow any QoS scheme it wishes. If additional levels of prioritization between users are desired, signaling may be displayed to allow the programmer to assist in that prioritization, as will be apparent to those skilled in the art. It should be noted that in all the embodiments described above, the steps of the methods can be exchanged without departing from the scope of the invention. The descriptions here made in many cases have referred to signals, parameters and methods associated with a MIMO OFDM system, but the scope of the present invention is not limited thereto. Those skilled in the art will readily apply the principles mentioned herein for other communication systems. These and other modifications will be apparent to those skilled in the art. Those skilled in the art will understand that information and signals can be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols and chips, which can be referenced throughout the preceding description, can be represented by voltages, currents, electromagnetic waves, fields or magnetic particles, fields or optical particles, or any combination thereof. Those skilled in the art will further appreciate that the various illustrative logic blocks, modules, circuits, and algorithm steps described in connection with the embodiments shown herein, may be executed as electronic hardware, computer software, or combinations of both. To clearly illustrate this hardware and software exchange capability, various illustrative components, blocks, modules, circuits and steps have been described above in terms of their functionality. Whether such functionality is executed as hardware or software depends on the particular application and the design restrictions imposed on the entire system.

Those skilled in the art can execute the described functionality in various ways for each particular application, but such execution decisions should not be interpreted as a cause for departing from the scope of the present invention. The various illustrative logic blocks, modules and circuits described in relation to the embodiments described in the present invention can be executed or realized with a general purpose processor, a digital signal processor (DSP), a specific application integrated circuit (ASIC) , a programmable field gate layout (FPGA) signal or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described in the present invention. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any processor, controller, microcontroller, or conventional state machine. A processor may also be executed as a combination of computing devices, for example, a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a central DSP, or any other configuration.

The steps of a method or algorithm described in connection with the embodiments described in the present invention can be incorporated directly into hardware, into a software module executed by a processor, or into a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor so that the processor can read the information from, and write information to, the storage medium. In the alternative, the storage medium can be an integral part of the processor. The processor and storage medium can reside in an ASIC. The ASIC can reside in a user terminal. In the alternative, the processor and the storage medium may reside as discrete components in a user terminal. The prior description of the described embodiments is provided to enable those skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not intended to be limited to the modalities shown herein but will be accorded the broadest scope consistent with the principles and novel features described herein.

Claims (37)

1. NOVELTY OF THE INVENTION Having described the present invention, it is considered as a novelty and, therefore, the content of the following is claimed as a priority: CLAIMS 1. - A programmer for programming a data transmission in a communication system, the programmer comprises: first logic to determine whether each of one or more devices corresponding to one or more data transmission indicators has a reservation of capacity in a profile of admission; and second logic to assign capacity according to a data transmission indicator when a capacity reservation is discovered.
2. 2. The programmer according to claim 1, characterized in that the second logic limits the allocation according to the capacity reservation.
3. 3. The programmer according to claim 2, characterized in that the second logic also allocates the remaining capacity, if any, in response to any data transmission indicators not satisfied in order of increasing size of the unassigned portion of the indicator of data transmission.
4. 4. The programmer according to claim 1, characterized in that each of a plurality of data transmission indicators is associated with one of a plurality of service levels.
5. 5. The programmer according to claim 4, characterized in that the second logic allocates capacity in response to one or more transmission indicators associated with one or more of a first group of service levels according to the admission profile, and allocates the remaining capacity, if any, in response to one or more transmission indicators associated with one or more of a second group of service levels.
6. 6. The programmer according to claim 5, characterized in that the first group comprises one or more levels of guaranteed service quality service. 7. - The programmer according to claim 5, characterized in that the second group comprises one or more service levels of better effort. 8. - A communication device operating with a plurality of remote devices, and operating with an admission profile comprising a plurality of time periods and a capacity reservation for zero or more remote devices in each of the plurality of periods of time, the communication device comprises: a scheduler so that during each of the plurality of time periods, for each of a plurality of data transmission indicators, determine whether a remote device corresponding to the data transmission indicator it has a capacity reservation in the admission profile and to assign capacity according to the data transmission indicator. 9. The communication device according to claim 8, characterized in that the programmer limits the allocation according to the capacity reservation. 10. The communication device according to claim 9, characterized in that the programmer also allocates the remaining capacity, if any, in response to any data transmission indicators not satisfied in order of increasing size of the unassigned portion of the data. data transmission indicator. 11. The communication device according to claim 8, further comprising a receiver for receiving a request message comprising a data transmission indicator. 12. The communication device according to claim 8, further comprising one or more data queues, a data transmission indicator generated with the presence of data within a queue. 13. The communication device according to claim 8, further comprising a transmitter for transmitting one or more granting messages indicating the assigned capacity. 14. The communication device according to claim 8, further comprising an admission control unit for: receiving, from a remote device, an admission request comprising flow parameters corresponding to a data flow; admit, in a conditioned manner, the flow when the flow parameters, if combined with the intake profile, do not exceed the capacity of the system; and modify the admission profile to incorporate the flow at the time of admission. 15. The communication device according to claim 8, characterized in that each remote device can correspond to a plurality of data transmission indicators, each indicator is associated with a service level. 16. The communication device according to claim 15, characterized in that the programmer allocates capacity in response to one or more transmission indicators associated with one or more of a first group of service levels according to the admission profile, and allocates the remaining capacity, if any, in response to one or more transmission indicators associated with one or more of a second group of service levels. 17. The communication device according to claim 16, characterized in that the first group comprises one or more levels of guaranteed service quality service. 18. The communication device according to claim 16, characterized in that the second group comprises one or more levels of service of better effort. 19. The communication device according to claim 15, characterized in that the scheduler: allocates capacity in response to one or more transmission indicators associated with one or more remote devices that have a capacity reservation in the admission profile, the assigned capacity for each remote device is limited to the respective capacity reservation; then allocate the remaining capacity, if any, in response to the unsatisfied transmission indicators associated with a first level of service; and then allocate the remaining capacity, if any, in response to the transmission indicators associated with a second level of service. 20. The communication device according to claim 19, characterized in that the programmer also allocates the remaining capacity, if any, in response to the transmission indicators for data in one or more future periods of time associated with the first level. of service before the assignment in response to indicators associated with the second level of service. 21. The communication device according to claim 19, characterized in that the allocation in response to non-satisfied indicators is performed in order of increasing size of the unassigned portion of the data transmission indicator. 22. A communication system comprising: a plurality of remote devices; an admission profile comprising a plurality of time periods and a capacity reservation for zero or more remote devices in each of the plurality of time periods; and communication device comprising a scheduler so that during each of the plurality of time periods, for each of a plurality of data transmission indicators, it determines whether a remote device corresponding to the data transmission indicator has a reservation of capacity in the admission profile and to assign capacity according to the data transmission indicator. 23.- A programming method, comprising: receiving one or more transmission indicators from one or more remote devices; and grant one or more of the transmission requests according to an admission profile. The method according to claim 23, further comprising: receiving, from a remote device, an admission application comprising flow parameters corresponding to a data flow; admit, in a conditioned manner, the flow when the flow parameters, if combined with the intake profile, do not exceed the capacity of the system; and modify the admission profile to incorporate the flow at the time of admission. 25. - A programming method, comprising: determining, for each of a plurality of time periods and for each of a plurality of data transmission indicators, whether a remote device corresponding to the data transmission indicator has a reservation of capacity in an admission profile; and assigning capacity according to the data transmission indicator when a capacity reservation is in the admission profile. 26. The method according to claim 25, characterized in that one or more of the data transmission indicators are received from one or more remote devices. - The method according to claim 25, characterized in that one or more of the data transmission indicators are generated in response to the presence of data within a queue. 28. The method according to claim 25, characterized in that each of the plurality of data transmission indicators corresponds to one of a plurality of service levels. 29. The method according to claim 28, characterized in that the capacity is assigned first for the data transmission indicators corresponding to a first level of service, and the remaining capacity, if any, is assigned to corresponding transmission indicators. to one or more second service levels. 30. A programming method, comprising: receiving a plurality of transmitting indicators corresponding to a plurality of remote devices; have access to an admissions profile to determine if one or more transmission indicators have an associated reservation in the admissions profile; 'assign the capacity according to the reserves located; assign the remaining capacity to the remaining transmission indicators; and transmit one or more bestowal messages in accordance with the allocation of capacity. 31.- A device, comprising: means for receiving one or more transmission requests from one or more remote devices; and means to grant one or more of the transmission requests according to an admission profile. 32. The device according to claim 31, characterized in that the admission profile comprises a plurality of frames, and zero or more capacity values associated with a remote device per frame. • The device according to claim 31, characterized in that the intake profile is created according to a utilization factor and a frame phase for one or more data flows. 34. The device according to claim 31, further comprising: means for receiving, from a remote device, an admission request comprising flow parameters corresponding to a data flow; means to admit, in a conditioned manner, the flow when the flow parameters, if combined with the intake profile, do not exceed the capacity of the system; and means to modify the admission profile to incorporate the flow at the time of admission. 35.- A communication system, comprising: means for receiving one or more transmission requests from one or more remote devices; and means to grant one or more of the transmission requests according to an admission profile. 36.- Computer-readable media that operate to execute a method that includes the following: receiving one or more transmission requests from one or more remote devices; and grant one or more of the transmission requests according to an admission profile. The means according to claim 36, further operating to execute the following: receive, from a remote device, an admission request comprising flow parameters corresponding to a data flow; admit, in a conditioned manner, the flow when the flow parameters, if combined with the intake profile, do not exceed the capacity of the system; and modify the admission profile to incorporate the flow at the time of admission.