JP5204139B2 - Admission control and resource allocation within a communication system that supports quality of service - Google Patents

Description

Display of related applications

  This patent application is assigned to this assignee and is expressly entitled “System for Allocating Resources in a Communication System”, 2003, which is expressly incorporated herein by reference. Claims priority of provisional patent application No. 60 / 455,906 filed on May 17th.

  The present application relates to communication systems. In particular, these embodiments are aimed at allocating communication resources among multiple subscribers of a communication system.

  Several solutions have been presented to address the problem of allocating limited communication resources provided by a single node in a communication system between multiple subscribers. It is the purpose of such a system to provide each node with sufficient resources to meet the requirements of all subscribers while minimizing costs. Therefore, such a system is usually designed for efficient resource allocation among various subscribers.

  Various systems have implemented frequency division multiple access (FDMA) schemes that allocate resources to each of the subscribers simultaneously. The communication node of such a system typically has limited bandwidth for either sending information to each subscriber in the network or receiving information from each subscriber at any given time. Have. This scheme typically involves allocating a separate portion of the overall bandwidth to individual subscribers. Such a scheme may be effective for systems where subscribers require uninterrupted communication with a communication node, but when such constant, uninterrupted communication is not required Even better utilization of the overall bandwidth can be achieved.

  Another method for allocating communication resources of a single communication node among a plurality of subscribers is a time division multiple access (TDMA) method. These TDMA schemes are for allocating the limited bandwidth resources of a single communication node among multiple subscribers and do not require the user to have uninterrupted and uninterrupted communication with a single communication node. It is especially effective when. A TDMA scheme typically dedicates the entire bandwidth of a single communication node to each of the subscribers at specified time intervals. In a wireless communication system utilizing a code division multiple access (CDMA) scheme, this can be achieved by assigning all code channels to each of the subscriber units at time intervals specified on a time division basis. The communication node introduces a unique carrier frequency or channel code associated with the subscriber in order to allow exclusive communication with the subscriber. The TDMA scheme may be implemented in landline systems using physical contact relay switching or packet switching.

  TDMA systems typically assign equal time intervals to each subscriber in a brute force manner. For this reason, use of a certain time interval by the subscriber may be wasted. Similarly, other subscribers may make requests for communication resources that exceed the allocated time interval, and this subscriber may receive insufficient service. The system operator either bears the cost of expanding the bandwidth of the node to ensure that no subscriber receives the lack of service, or the subscriber receiving insufficient service has insufficient service You can choose to allow them to continue receiving.

  Therefore, there is a need to provide a system and method for allocating communication resources between subscribers of one communication network efficiently and fairly according to a network policy for allocating communication resources between subscribers. Along with that, services provided by the system include (but are not limited to) providing a mechanism for performing resource allocation on a per-flow and / or aggregate basis depending on the specific requirements, constraints and / or goals of the system. There is a need to maximize the number of users who receive it. There is also a need for admission control and preemption methods that optimize resource allocation.

1 shows a communication network according to an embodiment of the present invention. 1 shows a block diagram of a base station controller and a base station device configured in accordance with an embodiment of the present invention. 1 shows a block diagram of a remote station device configured in accordance with an embodiment of the present invention. FIG. 2B shows a flow diagram depicting the execution of a scheduling algorithm in the channel scheduler embodiment shown in FIG. 2A. A communication system supporting multimedia applications, where each application communication is represented by an application flow. A queue of application flows. It is a timing diagram which draws the signal timing of a part of application flow. FIG. 6 is a timing diagram depicting application flow jitter measurement. FIG. 6 is a timing diagram depicting transmission of consecutive IP packets during a time slot for processing an application flow. 2 is a flow diagram depicting scheduling of application flows within a communication system. 2 is a flow diagram depicting the scheduling of application flows with various quality of service (QoS) requirements. FIG. 3 is an architectural diagram depicting the definition of each application flow consistent with a scheduling algorithm according to one embodiment. FIG. 6 is a table identifying class types according to one embodiment. FIG. 1 depicts a portion of a scheduling algorithm according to one embodiment, including application flow initialization. FIG. 4 illustrates a portion of a scheduling algorithm according to one embodiment including processing application flows as a class type function. FIG. Processing modes I application flows, the processing of Mode II application flow, and the processing of Mode III application flow, shows a portion of a scheduling algorithm according to one embodiment. 1 depicts a portion of a scheduling algorithm according to one embodiment, including processing of mode I application flows. 1 depicts a portion of a scheduling algorithm according to one embodiment, including adaptive weighting and scheduling based thereon. 1 depicts a base station transceiver system (BTS) for implementing an algorithm for scheduling application flows using an adaptive weighting algorithm in a wireless communication system. FIG. 5 is a timing diagram depicting maximum resources for allocation such as data rate ( L _MAX ), reserved resources (Res (t)), and available resources (Avail (t)) as a function of time. FIG. 6 is a timing diagram depicting a data request received from a user within a high-speed packet data type system and an estimated capacity L (t) as a function of time to reserve at time t. FIG. 2 is an information flow diagram depicting a scheduler for a high-speed packet data type system that supports multiple application flows with quality of service (QoS) requirements, where the flows are scheduled by a per-flow compensation application. FIG. 4 is an information flow diagram illustrating a scheduler for a high-speed packet data type system that supports multiple application flows with quality of service (QoS) requirements, where the flows are scheduled by an aggregate compensation application. Describes an algorithm for admission control within a high-speed packet data type system that supports multiple application flows with quality of service (QoS) requirements. Describes an algorithm for admission control within a high-speed packet data type system that supports multiple application flows with quality of service (QoS) requirements. Describes an algorithm for admission control within a high-speed packet data type system that supports multiple application flows with quality of service (QoS) requirements. Describes an algorithm for admission control within a high-speed packet data type system that supports multiple application flows with quality of service (QoS) requirements. Describes an algorithm for admission control within a high-speed packet data type system that supports multiple application flows with quality of service (QoS) requirements. Describes an algorithm for pre-processing within a high-speed packet data type system that supports multiple application flows with quality of service (QoS) requirements. 1 is a block diagram of an access network (AN) element in a high-speed packet data type system that supports multiple application flows with quality of service (QoS) requirements. FIG.

Embodiments of the present invention are directed to systems and apparatus for allocating resources among multiple subscribers of a single communication network that are served by a single communication node. At each separate transmission interval, or “service interval”, an individual subscriber acquires all the other subscribers and obtains a finite resource of communication nodes. Individual subscribers are selected to obtain finite resources based on weights or scores associated with the individual subscribers. The change in weight associated with an individual subscriber is preferably based on the instantaneous rate at which the individual subscriber can consume finite resources.

Referring to the figures, FIG. 1 represents an exemplary variable speed communication system. One such system is assigned to Qualcomm, Inc. and is incorporated herein by reference, published on June 3, 2003, in “Methods for High-Speed Packet Data Transmission and US Pat. No. 6,574,211 entitled “Method and Apparatus for High Rate Packet Data Transmission”. The variable speed communication system includes a plurality of cells 2A to 2G. Each cell 2 is served by a corresponding base station 4. Various remote stations 6 are distributed throughout the communication system. In the exemplary embodiment, each remote station 6 communicates with at most one base station 4 on the forward link at any data transmission interval. For example, in time slot n, base station 4A transmits data only to remote station 6A, base station 4B transmits data only to remote station 6B, and base station 4C transmits data only to remote station 6C on the downlink. To do. As shown in FIG. 1, each base station 4 preferably transmits data to one remote station 6 at any point in time. In other embodiments, the base station 4 may communicate with two or more remote stations 6 at a certain data transmission interval except for all other remote stations 6 associated with the base station 4. Furthermore, the data rate is variable, and in one embodiment the carrier-to-interference ratio (C / I) as measured by the receiving remote station 6 and the required energy per bit pair. It depends on the energy-per-bit-to-noise (Eb / N _O ). For simplicity, the uplink from the remote station 6 to the base station 4 is not shown in FIG. According to one embodiment, the remote station 6 is a mobile unit with a wireless transceiver operated by a wireless data service subscriber.

  Block diagrams depicting the basic subsystems of an exemplary variable speed communication system are shown in FIGS. 2A-2B. The base station controller 10 includes a packet network interface 24, a public switched telephone network (PSTN) 30, and all base stations 4 in the communication system (for simplicity, only one base station 4 is shown in FIG. 2A). And interface. The base station controller 10 coordinates communication between the remote station 6 in the communication system and other users connected to the packet network interface 24 and the PSTN 30. The PSTN 30 interfaces with the user through a standard telephone network (not shown in FIG. 2A).

  Although only one is shown in FIG. 2A for simplicity, the base station controller 10 includes a number of selector elements 14. Each selector element 14 is assigned to control communication between one or more base stations 4 and one remote station 6. If the selector element 14 is not assigned to the remote station 6, the call control processor 16 is informed of the need to call the remote station 6. Call control processor 16 then instructs base station 4 to call remote station 6.

  Data source 20 contains indeterminate data to be transmitted to remote station 6. Data source 20 provides data to packet network interface 24. The packet network interface 24 receives the data and sends the data to the selector element 14. The selector element 14 transmits data to each base station 4 in communication with the remote station 6. In the exemplary embodiment, each base station 14 maintains a data queue 40 that stores data that is to be transmitted to the remote station 6.

  Data is transmitted from the data queue 40 to the channel element 42 in data packets. In the exemplary embodiment, on the downlink, a “data packet” is scheduled to be transmitted to the destination remote station 6 within a “time slot (eg, 1.667 msec)” and indefinite amount of data that is up to 1024 bits. Refers to indefinite amount of data. For each data packet, channel element 42 inserts the necessary control fields. In the exemplary embodiment, channel element 42 CRC encodes the data packet and control field and inserts a set of code tail bits. The data packet, control field, CRC parity bit and code tail bit comprise a formatted packet. In the exemplary embodiment, channel element 42 then encodes the formatted packet and interleaves (ie, reorders) the symbols within the encoded packet. In the exemplary embodiment, the interleaved packet is covered with a Walsh code and spread with a short PNI code and a PNQ code. The spread data is fed to an RF device 44 that quadrature modulates, filters and amplifies the signal. The downlink signal is transmitted wirelessly through the antenna 46 on the downlink 50.

  In the remote station 6, the downlink signal is received by the antenna 60 and sent to the receiver in the front end 62. The receiver filters, amplifies, quadrature modulates and quantizes the signal. The digitized signal is supplied to a demodulator (DEMOD) 64 where it is despread with a short PNI code and a PNQ code and decovered with a Walsh cover. The demodulated data is provided to a decoder 66 that performs the inverse of the signal processing functions performed by the base station 4, in particular the de-interleaving, decoding, and CRC checking functions. The decrypted data is supplied to the data sink 68.

  As pointed out above, the hardware supports variable rate transmission of data, messaging, voice, video and other communications on the downlink. The rate of data transmitted from the data queue 40 varies to accommodate changes in signal strength and noise environment at the remote station 6. Each remote station 6 preferably transmits a data rate control (DRC) signal to the associated base station 4 in each time slot. DRC refers to a control mechanism by which a remote station determines a desired data rate for the downlink, that is, a data rate for receiving data at the remote station. The remote station transmits the desired data rate as a data rate request or command to the base station via a DRC message. The DRC signal provides information to the base station 4 including the identity of the remote station 6 and the rate at which the remote station 6 should receive data from its associated data queue. Thus, the remote station 6 circuitry measures the signal strength and estimates the noise environment at the remote station 6 to determine the rate information to be transmitted in the DRC signal.

  The DRC signal transmitted by each remote station 6 travels through the uplink channel 52 and is received at the base station 4 through the antenna 46 and the RF device 44. In the exemplary embodiment, the DRC information is demodulated by channel element 42 and provided to channel scheduler 12A located in base station controller 10 or to channel scheduler 12B located in base station 4. In the first exemplary embodiment, the channel scheduler 12B is located in the base station 4. In another embodiment, the channel scheduler 12A is located in the base station controller 10 and is connected to all selector elements 14 in the base station controller 10.

  In one embodiment, the channel scheduler 12B receives information from the data queue 40 indicating the amount of data that is queued for each remote station, also called the queue size. Channel scheduler 12B then performs scheduling based on the DRC information and queue size for each remote station served by base station 4. The channel scheduler 12A may receive queue size information from the selector element 14 if the queue size is required for the scheduling algorithm used in another embodiment.

  Embodiments of the present invention are applicable to other hardware architectures that can support variable rate transmission. The present invention may be easily extended to cover variable rate transmission in the uplink. For example, instead of determining the rate at which the base station 4 receives data based on the DRC signal from the remote station 6, the base station 4 measures the strength of the signal received from the remote station 6 and estimates the noise environment. The speed at which data is received from the remote station 6 is determined. The base station 4 then transmits to each of the associated remote stations 6 the rate at which data is to be transmitted in the uplink from the remote station 6. The base station 4 may then schedule an uplink transmission schedule based on different data rates in the uplink in a manner similar to that described herein for the downlink.

  In addition, the base station 4 of the above-described embodiment uses the CDMA scheme to select one or more selected ones of the remote stations 6 except for the remaining remote stations associated with the base station 4. To the remote station. At any particular time, the base station 4 can select one or more selected ones of the remote stations 6 by using a code assigned to the receiving base station (s) 4. Send to remote station. However, the present invention provides various TDMA methods for providing data for selecting base station (s) 4 except for other base stations 4 in order to optimally allocate transmission resources. It can be applied to other systems to be used.

  The channel scheduler 12 schedules variable speed transmission in the downlink. The channel scheduler 12 receives a queue size indicating the amount of data to be transmitted to the remote station 6 and a message from the remote station 6. The channel scheduler 12 preferably schedules data transmissions to achieve the system goal of maximum data throughput while complying with fairness constraints.

  As illustrated in FIG. 1, remote stations 6 are distributed throughout the communication system and may or may not be communicating with base station 4 on the downlink. In the exemplary embodiment, channel scheduler 12 coordinates downlink data transmission throughout the communication system. A scheduling method and apparatus for high-speed data transmission is assigned to the assignee of the present invention and is assigned to US Pat. No. 6,335,922 issued Jan. 1, 2002, which is incorporated herein by reference. It is explained in detail in the issue.

  According to one embodiment, the channel scheduler 12 is implemented in a computer system that includes a processor, a random access memory (RAM), and a program memory for storing instructions to be executed by the processor (not shown). The processor, RAM, and program memory may be dedicated to the function of the channel scheduler 12. In other embodiments, the processor, RAM, and program memory may be part of a shared computing resource for performing additional functions at the base station controller 10.

  FIG. 3 shows an embodiment of a scheduling algorithm that controls the channel scheduler 12 to schedule transmissions from the base station 4 to the remote station 6. As described above, a data queue 40 is associated with each remote station 6. The channel scheduler 12 associates each of the data queues 40 with a “weight”. The weight is evaluated at step 110 to select a particular remote station 6 associated with the base station 4 and receiving data at the next service interval. The channel scheduler 12 selects individual remote stations 6 that receive data transmissions at different service intervals. In step 102, the channel scheduler initializes weights for each queue associated with base station 4.

  The channel scheduler 12 periodically repeats steps 104 to 112 at transmission intervals or service intervals. In step 104, the channel scheduler 12 determines whether there are additional queues to be added for association with the further remote station 6 with the base station 4 detected in the previous service interval. Channel scheduler 12 also initializes the weight associated with the new queue at step 104. As described above, the base station 4 receives a DRC signal from each remote station 6 associated with itself at regular intervals such as time slots.

  This DRC signal also provides information that the channel scheduler uses in step 106 to determine the instantaneous rate for consuming information (ie, receiving transmitted data) for each remote station associated with each queue. To do. According to an embodiment, a DRC signal transmitted from any remote station 6 indicates that the remote station 6 can receive data at any one of a plurality of valid data rates.

The channel scheduler 12 determines in step 108 that the data will be sent to any particular remote based on the instantaneous speed (as indicated in the closest previously received DRC signal) associated with the remote station 6 to receive the data. Determine the length of the service interval to be transmitted to the station 6. According to an embodiment, the instantaneous rate of receiving data R _i determines the service interval length L _i associated with a particular data queue at step 106.

  In step 110, the channel scheduler 12 selects a specific data queue for transmission. The associated amount of transmission data is then removed from the data queue 40 and then provided to the channel element 42 for transmission to the remote station 6 associated with the data queue 40. As described below, at step 110, the channel scheduler 12 selects a queue for providing data to be transmitted at the next service interval using information including each weight associated with each queue. The weight associated with the transmitted queue is then updated at step 112.

  Those skilled in the art will appreciate that the channel scheduler 12 may be implemented using a variety of approaches without departing from the present invention. For example, the channel scheduler 12 may be implemented using a computer system that includes a processor, a random access memory (RAM), and a program memory for storing instructions to be executed by the processor (not shown). In other embodiments, the functions of the channel scheduler 12 may be incorporated into a shared computing resource that is also used to perform additional functions at the base station 4 or the base station controller 10. Further, the processor used to perform the channel scheduler function may be a general purpose microprocessor, digital signal processor (DSP), programmable logic device, application specific integrated circuit (ASIC) or without departing from the invention. It may be another device that can execute the algorithm described in the document.

As shown in the embodiment of FIG. 1, the remote station 6 is mobile and can change the association between the various base stations 4. For example, remote station 6F initially receives data transmission from base station 4F. The remote station 6F may then exit the base station 4F cell and enter the base station 4G cell. The remote station 6F may then begin transmitting a DRC signal to alert the base station 4G instead of the base station 4F. By not receiving a DRC signal from the remote station 6F, the base station 4F logic infers that the remote station 6F has disconnected and no longer receives data transmissions. The data queue associated with the remote station 6F may then be transmitted to the base station 4G via land line or RF communication link.

Adaptive Weighted Scheduling Algorithm In addition, multimedia services or various transmission requirements in one wireless communication system where multimedia service transmissions called “flows” (described further below) create bursty traffic. A problem exists when other services with are sent. Burst traffic is characterized by a number of variables including a measure of burstiness and an average data rate. In addition, there is a need to meet quality of service (QoS) requirements for each of the various flows in the system. Current scheduling methods, such as the Proportional Fair (PF) algorithm, are usually shown as the ratio of the requested data rate called Data Rate Control Data Request or “DRC” to the throughput identified as “T”. Select a flow to provide services based on the metric being Such calculations may not guarantee the required QoS for all users. Thus, a pure PF algorithm may not provide enough complexity to meet the QoS requirements of users accessing multimedia or other applications. There is a need for a scheduler that can meet these diverse requirements.

  Note that the following discussion considers a cdma2000 system that supports high-speed packet data (HRPD) services as described in IS-856. This system is used as an example. The present invention is applicable to other systems where users are selected for service according to a scheduling algorithm.

  In the HRPD system, the air interface can support up to four parallel application streams. The first stream carries signaling information and the other three can be used to carry different quality of service (QoS) requirement applications, or other applications.

  The following glossary is provided for clarity in understanding one embodiment presented below. The following glossary is not intended to be exhaustive. The following glossary is not intended to limit the invention thereto, but rather is provided for clarity and understanding with respect to one embodiment of a communication system that supports adaptive weighted scheduling algorithms.

Glossary Access Network (AN): A network device that provides data connectivity between a cellular network and a packet-switched data network (usually the Internet) and an AT. An AN in the HRPD system corresponds to a base station in a cellular communication system.

  Access terminal (AT): A device that provides data connectivity to a user. The AT in the HRPD system corresponds to the mobile phone in the cellular communication system. The AT may be connected to a computing device such as a laptop personal computer, or the AT may be a self-contained data device such as a personal digital assistant (PDA).

  Application flow: A specified transmission path from a source to an AT for an application stream. Each application flow is identified by source, destination, traffic profile, and quality of service profile.

  Application stream: Data communication corresponding to an application. Most application streams have designated quality of service requirements.

  Automatic Repeat Request (ARQ)-A mechanism by which a transmitter initiates retransmission of data based on the occurrence or non-occurrence of an event.

  Avail (t): Unreserved bandwidth at time t on the downlink.

  Average data rate (r): The average input data rate over time for an application flow.

  Average delay (AvgD): The average delay that occurs in multiple packets or bits from the AN to the AT.

  Burst (σ): Burst, that is, a related index of the density and time unit of packets in an application flow.

  Data rate control (DRC): A mechanism whereby the AT sends the requested data rate to the AN.

  Missing packets (defpkts): defined for flow k at the beginning of slot n. Missing packets are packets that have not yet been transmitted in the flow, and defpkts is particularly mid-processing, such as a medium access control (MAC) packet that has remained in the BTS for longer than the delay threshold of flow k. Defined as the number of packets of equal size, such as packets.

  Missing bits (defbits): The number of bits corresponding to a missing packet.

  Delay limit: A specified time allowed for transmission of a packet of data from the AN to the AT.

  Delay threshold: A function of delay limit or jitter limit, used to calculate defpkts.

  Delay compensation factor (Φ): A compensation factor used to compensate for delay violations.

  DRC compensation factor (β): A compensation factor that is a major cause of data requirement requirements associated with users of application flows. Used to perform graceful recovery of applications.

  Extended Jitter Threshold (dv): Used to calculate an extended jitter compensation function when detecting a jitter violation between two consecutive IP packets of a flow.

  Flow weight (w): Initial weight value applied to each application flow using an adaptive weighted scheduling algorithm. The adaptive weight (aw) is an adaptive value of the weight.

  Downlink (FL): Transmission radio link from AN to AT.

  First-of-line (HOL) packet: The first packet in the queue.

  High-speed packet data (HRPD): A data service that transmits packet data communications at a high data rate. Also referred to as a high data rate, it is defined in the IS-856 standard entitled “cdma2000 High Rate Packet Data Air Interface Specification”.

  Jitter: Time variation between consecutive packets received.

  Jitter limit (j): A limit on jitter for an application flow.

  Jitter compensation coefficient, enhanced (δ): Compensation coefficient to compensate for jitter violations for flows.

L _max : Maximum speed at which the BTS can transmit data in the downlink (eg, 2.4 Mbps in a cdma2000 1xEV-DO type network).

  L (t): Estimated downlink capacity to be secured at time t based on the previous QoS violation statistics and network load related statistics.

  Normalized missing packets (ndefpkts): Normalized missing packets calculated using the missing packets and the requested rate of the flow.

  Normalized missing bits (ndefbits): Normalized missing bits corresponding to normalized missing packets.

  Empeg (MPEG): A protocol for transmission of multimedia data.

Pending packet: pend _{k, j} [n]: Number of pending bytes of IP packet j of flow k in BTS and BSC of slot n.

  Proportional fair (PF) algorithm: A scheduling algorithm in which data communication is scheduled according to a selection factor calculated for each AT as a ratio of requested data rate to throughput.

  Quality of Service (QoS): Requirements relating to the transmission of packet data communications, including but not limited to delay, required rate and jitter.

  QoS and network compensation functions (Φ, γ, α, β, δ): compensation functions as used in adaptive weighted scheduling algorithms.

  Quality of Service Group (QSG): A group of application types with similar QoS requirements.

  Rate compensation factor (α): Compensation factor calculated to compensate for rate violations.

  Service rate (R) or requested rate (required_rate): the rate required by the flow.

  Res (t): Bandwidth reserved at time t on the downlink.

  Retransmission queue (Rx): A retransmission queue that stores application flows that are scheduled for retransmission.

  Uplink (RL): Transmission radio link from AT to AN.

  Selection metric (Y): A metric used for application flow comparison to determine schedules.

  Traffic profile (σ, r): an index related to burstiness and data rate.

  Transmission queue (Tx): A transmission queue that stores application flows for a given BTS.

  Standby time parameter (γ): The value of the standby time for the HOL of the IP packet in the AN.

Applying Adaptive Weights to Proportional Fair Scheduling Algorithm A proportional fair (PF) scheduling algorithm that selects a flow to serve based on the metric DRC / T is described for the downlink of a cdma2000 1xEV-DO network. The PF algorithm is designed to provide each user with approximately the same number of transmission slots. In order to enhance such scheduling algorithms, an adaptive weighted DRC / T algorithm is described herein that extends and optimizes the DRC / T algorithm to meet various QoS requirements for different types of applications. Yes. Each multimedia application has its own specific QoS requirements. The goal of the scheduling algorithm includes meeting various QoS requirements. The adaptation algorithm presented here, also referred to as the adaptive w * DRC / T algorithm, is superior to the DRC / T algorithm for downlink in cdma2000 1xEV-DO networks, where the application flow includes multimedia application services. Provides performance benefits. Delay and jitter limit requirements for delay and jitter sensitive applications on the downlink of a cdma2000 1xEV-DO network are met using an adaptive algorithm. In addition, the adaptive scheduling algorithm ensures that rate requirements are met and average delay is reduced for multimedia applications. Although a multimedia application is shown as an example to illustrate the implementation of an adaptive scheduling algorithm, the methods and apparatus described herein are useful for other applications that have QoS requirements or other quantifiable requirements associated therewith. May be applied to.

  For applications with rate and latency requirements, such as web browsing and games, the adaptive scheduling algorithm provides rate guarantees and reduces average delay. For other applications that have only rate requirements, an adaptive weighted scheduling algorithm may be used to meet the rate guarantee. While providing these QoS guarantees, the adaptive weighted scheduling algorithm also works to maintain the total throughput at a fairly high level, with a total throughput close to the total throughput achieved when a pure PF scheduling algorithm is used. To achieve. A pure PF scheduling algorithm refers to an algorithm that utilizes DRC / T computation. While giving special resources to flows with QoS violations, the adaptive weighted scheduling algorithm distributes the available resources fairly. Various compensation mechanisms consistent with it are shown here.

  FIG. 4 depicts a system 800 that supports multimedia applications. Note again that the present invention is applicable to other systems where the flow has QoS requirements. System 800 includes a multimedia source 802 that is coupled to a packet data service node (PDSN) 806. PDSN 806 is also coupled to a base station controller (BSC) 804. There may be a plurality of BSCs 804. The BSC 804 communicates with various ATs 812, 814, 816, 818, etc. via base station transceiver systems (BTS) 808, 810. System 800 may include more BTSs and ATs than depicted. Three flows are drawn. That is, the first flow from the multimedia source 802 to the AT 812 via the PDSN 806, BSC 804 and BTS 808, the second flow from the multimedia source 802 to the AT 816 via the PDSN 806, BSC 804 and BTS 810, and the PDSN 806, BSC 804, and FIG. 10 is a third flow from multimedia source 802 to AT 818 via BTS 810. FIG. Note that one AT can be the destination for multiple flows. In one example, transmission of an MPeg (MPEG) type application separates audio and video into separate flows.

  Each application flow transmitted in system 800 has an associated source address, destination address and QoS requirements. The application flow is then scheduled for transmission from the source to the destination. The application flow crosses the path similar to that depicted in FIG.

Each BTS 808, 810 is adapted to maintain a flow queue as depicted in FIG. Note that each BTS maintains a set of queues corresponding to each application flow on its downlink (FL). One application flow is directed to one AT. Note, however, that multiple flows may be directed to one AT. Each flow has a quality of service group (QSG) type associated with it. Each QSG is defined by a set of QoS parameters. Each flow in a QSG has a specific value for each of the parameters in the set. For example, one QSG may be defined by a set including delay and jitter. Those flows of such QSG specify requirements for delay and jitter. For each flow in the queue, the BTS maintains a set that includes three independent queues. That is, (1) the original transmission queue (Tx), (2) the retransmission queue (Rx), and (3) the automatic repeat request queue (ARQ). In one embodiment, the ARQ queue may correspond to a queue that stores a flow for any type of retransmission mechanism performed between the BTS and the AT, such as early decision ARQ. Multimedia applications may include delay sensitive applications such as video conferencing with delay limit requirements. The delay limit is a specified time allowed from transmission from the AN to reception by the AT. The adaptive weighting algorithm works to meet delay limit requirements and to reduce the average delay experienced by such application IP packets. For applications that have both a rate requirement and an average delay requirement, the adaptive weighted scheduling algorithm functions to meet the rate requirement and to reduce the average delay.

  Another consideration for some types of applications, such as multimedia video applications, is the “jitter” experienced between successive packets in multimedia transmissions. Jitter refers to the variation in time between received packets. Jitter occurs when the continuous waveform reaches the receiver slightly earlier or slightly later. In wireless communications, such a waveform typically conveys a logic one or zero that is later decoded at the receiver. Timing variations, defined as jitter, distort the visual effect of the received transmission. The adaptive weighted scheduling algorithm reduces not only the delay variation between consecutive packets for delay sensitive applications, but also the worst case delay variation.

  While satisfying the diverse user QoS requirements, adaptive algorithms are also designed to meet the rate requirements of application flows when they are “conforming”. An application flow is said to be compliant when it transmits data for each traffic profile specified in advance. If the flows with rate requirements are not compliant, that is, if they transmit more data as specified in the traffic profile, the algorithm gives higher priority to flows with lower data rates. Although the adaptive weighting algorithm is described herein in the context of a cdma2000 1xEV-DO network, the concepts and methods may be applied to other types of wireless networks.

  With respect to multimedia application flows, each flow is defined by (1) a traffic profile, (2) a QoS profile, (3) an internet protocol (IP) source address, and (4) an IP destination address. The flow may also include (5) L4 protocol type, (6) L4 port number, and (7) L4 destination port number. L4 refers to the Transfer Control Protocol (TCP) / Unreliable Datagram Protocol (UDP) layer in the protocol stack. For example, an MPEG audio flow and an MPEG video flow corresponding to an MPEG application may be processed as separate flows.

  Each flow is specified by a traffic profile and is monitored or modified to ensure that it is adapted to that traffic profile. The traffic profile is defined by a variable representing the burstiness measure specified as σ and the average data rate of the flow specified as r. Accordingly, each flow is described by a traffic profile (σ, r). The QoS profile is defined by at least one of the following parameters: That is, (1) a delay limit that defines an allowable time from transmission to reception for an IP packet and is identified as “D”. For multimedia application flows, the system can specify a delay limit. For some other application flows, such as web browsing, the system can specify an average delay (AvgD) instead of or in addition to the delay limit. (2) A jitter limit that defines the maximum allowable variation in time between received packets at the AT and is identified as “j”. (3) The rate of the service specified as “R” or “req_rate” (that is, the requested rate).

To define the delay limit D, refer to FIG. 6, which is a timing diagram including various AN elements and one AT. The multimedia flow is sent from the multimedia source (not shown) to the AT via PDSN, BSC and BTS. The IP packet is transmitted from the PDSN at time t ₀ and received at the AT at time t ₃ . Parameter D defines the maximum allowable time from time t ₀ to time t ₃ . That is, D designates a range of t ₃ -t ₀ (there may be a plurality of cases).

To define the jitter limit j, reference is made to FIG. 7A, which is a timing diagram including an AN element and one AT. The first packet is transmitted at time t ₁ from the PDSN, it is received by the AT at time t ₁ '. The second packet is transmitted at time from PDSN t _2, it is received by the AT at time t ₂ '. The jitter limit j defines the maximum allowable variation between consecutive packets, and the variable is given as (t ₂ '-t ₁ ')-(t ₂ -t ₁ ). FIG. 7B further details successive IP packets transmitted on multiple slots.

In one embodiment, the QoS profiles are grouped into groups called QoS scheduling groups (QSGs). Table 1 lists the categories.

FIG. 8 illustrates the processing of a flow according to an adaptive weighted scheduling algorithm. Flows 900, 902, 904, and 906 are processed by the scheduling device 908 labeled “S”. The scheduling device 908 applies an adaptive weighted scheduling algorithm. The adaptive weighted scheduling algorithm uses a QSG profile for each of the flows. The QSG profile specifies variables that are used to calculate adaptive weights, as detailed below. Scheduling device 908 then outputs transmission 910 scheduled for the selected AT.

A PF scheduling algorithm called DRC / T algorithm is described. In the algorithm, packets are, for example, Q1, Q2,. . . Classified into m queues such as Qm. DRC [k. n] is the DRC corresponding to flow k for slot n and required by the mobile station. The scheduler selects the selection metric Y [. ,. ] Select the flow with the highest value.

Y [k, n + 1] is the selection metric for queue Qk in slot (n + 1). here,

as well as

T _c used here is a time constant, and the average is calculated with this time constant.

Adaptive w * DRC / T Algorithm In one embodiment, an adaptive weighted scheduling algorithm called the “adaptive w * DRC / T” algorithm assigns initial weights to each flow. Assume that the initial weight assigned to flow k is denoted by w _k , corresponds to flow k for slot n, and the DRC required by the AT is DRC [k, n]. The adaptive w * DRC / T algorithm calculates the following metric for each flow k in every slot n.

Here, the throughput for flow k and slot n, T _k [n], is as defined for DRC / T of the PF algorithm. As used in the adaptive weighted scheduling algorithm, aw _k [n] is the adaptive weight for flow k in slot n. The adaptive w * DRC / T scheduling algorithm operates in multiple modes, which are defined by the QSG. The adaptive weight, aw _k [n], for flow k in slot n is calculated based on the scheduler mode and a further selected policy or mechanism set, as detailed below. Note that equation (4) is calculated for each flow and the adaptive weights are calculated according to the formulation specific to each flow. In other words, the scheduling algorithm considers the QoS profile of a flow and uses it to calculate the adaptive weight for the flow. In this way, different flows with different QoS requirements may have adaptive weights that are calculated differently. The scheduling algorithm then selects the highest value flow of Y _k [n] and provides service in slot n.

  The adaptive w * DRC / T scheduler operates in the following modes.

  Mode I [aw * DRC / T] (r, d, j): Designed for applications that are sensitive to delay and jitter, have stringent requirements on delay and jitter limits, and require some minimum rate.

  Mode II [aw * DRC / T] (r, d): Used for applications with average delay and rate requirements.

  Mode III [aw * DRC / T] (r): Used for applications that have only specified rate requirements.

  Mode IV [DRC / T]: Does not specify a QoS plan, but is used for flows serviced by the DRC / T algorithm.

Based on QoS requirements, a specific mode of the adaptive w * DRC / T algorithm may be specified for a flow. Mode II may be used for a flow to increase the throughput specified for that flow by the scheduler. For example, Mode II may be used for FTP applications to potentially increase the throughput for the corresponding application flow.

  An example of grouping applications, ie QSG, is shown below.

  Group I: Applications such as Voice over IP (VoIP) with strict requirements on delay limits and delay variation. Note that in many cases such applications also have rate requirement (s). Use scheduler mode I.

  Group II: Multimedia conferencing applications with stringent requirements on delay limits and delay variation. Even though some of these applications are adaptive, it is desirable to ensure rates of service for consistent high quality. Use scheduler mode I.

  Group III: Video streaming applications with requirements regarding delay limit, rate and delay variation. Use scheduler mode I.

  Group IV: Web browsing application with rate and (average) delay requirements, scheduler mode II is used.

  Group V: Use rate FTP application, scheduler mode III. Alternatively, scheduler mode II in which the delay constraint is relaxed is used.

  Group VI: Best effort application, use PF algorithm, ie DRC / T algorithm, without using adaptive weighting.

  Note that database transactions, games, and other applications may be classified into appropriate groups according to their QoS requirements.

  FIG. 9 depicts an adaptive weighted scheduler having multiple levels including (but not limited to) level I and level II. The level I scheduler includes a plurality of schedulers S1, S2, S3,. . . Sm, where m refers to the total number of groups. Each level I scheduler in FIG. 9 executes a specific mode of operation of the adaptive w * DRC / T scheduling algorithm and selects one flow from the group. First, the level I scheduler calculates a portion of Y, in particular the throughput T and the rate compensation factor α. The level II scheduler then reviews the flow and provides sufficient input to the level I scheduler for complete calculation of the selection metric Y by the level I scheduler. Once Y is completely calculated for all outstanding flows, the level I scheduler evaluates the Y value and selects the flow with the highest Y value. Each Level I scheduler evaluates a group of flows that have similar QoS requirements. The selected flow of each level I scheduler is then fed to the level II scheduler for comparison with flows from other groups. The level II scheduler considers one selected flow for each group and selects the flow with the highest metric (aw * DRC / T), ie Y. This process is repeated for each slot when the scheduler needs to select a flow to service. Alternative embodiments may use a single level scheduler or may use more levels than depicted in FIG. Another embodiment may include another number of level I schedulers, which depend on the organization of the flow.

In general, the adaptive weight calculation is given as a function of several parameters and is shown as follows:

The delay compensation function is specified as Φ. The waiting time parameter is specified as γ. The rate compensation function is specified as α. The DRC compensation function is specified as β. The extended jitter compensation coefficient is specified as δ. Note that not all of the parameters have substantial values for all multimedia services. For example, if the only QoS requirement for a flow is the specified data rate, the variable α is specified (the rate parameter has a substantial value) and all other parameters are set equal to the value 1. The In this case, only the rate parameter is included in the adaptive weight calculation. In one embodiment, the adaptive weight is calculated as follows:

  Here, the operator is multiplication. The following description provides details of various compensation terms that can be included in the adaptive weight calculation.

  For mode I applications, the QoS profile specifies all of the parameters shown in equation (6). Adaptive weight calculation considers delay compensation due to delay threshold violation, delay compensation due to latency threshold violation, rate compensation due to rate violation, and enhanced jitter compensation due to enhanced jitter threshold violation . The concept is to increase the weight of flows that violate specified QoS requirements. Triggered on violation of QoS requirement (s) and credits are given for such flows. Credits are realized by multiplying the delay compensation function by the flow weight by an appropriate value. This is further multiplied by rate compensation and enhanced jitter compensation.

  In contrast, such a flow can be penalized when it is considered that the flow enjoys excessive service. Flows can be penalized in any of a variety of ways. According to one method, the flow can be directly penalized by reducing the flow weight. According to another method, the flow is penalized indirectly by maintaining the weight of the flow while increasing the weight of other users who are lagging (ie, the flow that has not achieved the required QoS). Can be imposed.

There are various mechanisms for computing delay compensation to compensate for delay threshold violation (s). Suppose the delay threshold for flow k is denoted by dth_φ _k and the delay compensation due to the delay threshold violation for flow k in slot n is denoted by φ _k [n]. To calculate the delay compensation φ _k [n], consider the packets in all three queues (ie, Tx, RTx and ARQ) per flow.

A maximum and minimum threshold for φ is also specified for each flow to ensure that the flow does not consume multiple slots in succession or starve other flows. This is also set to ensure that the flow delay compensation term due to the delay threshold violation is at least as effective as the minimum threshold. _Let φ _{thres, min, k} and φ _{thres, max, k} be the minimum and maximum thresholds specified for flow k. This results in (for all k and all n):

The following definitions are used to advance the calculation of delay compensation.

  D [n]: defines a set of flows that experience a delay threshold violation at the beginning of the slot (ie, each such flow will receive at least one packet that exceeds the delay threshold of that flow in slot n Have at the beginning).

defpkts _k [n]: Defines a “deficit” packet for flow k at the beginning of slot n. Missing packets are packets that have not yet been transmitted in the flow, and defpkts stays in the BTS longer than the delay threshold for flow k.
It is specifically defined as the number of (MAC) packets of equal size.

required_rate _k : defines the requested rate of flow k.

ndefpkts _k : defines the number of missing packets normalized for flow k, specifically defined as:

Note that packets in BTS, BSC and PDSN may be of unequal size, so it is beneficial to count the number of missing bits here instead of packets.

If a flow's HOL packet is in the BTS queue for a time period longer than a pre-specified threshold, the flow can be compensated using the following mechanism. The wait time threshold used for this purpose must be greater than or equal to the threshold used to calculate φ. The waiting time threshold for flow k is denoted by dth_γ _k , and the waiting time threshold is constrained by dth_γ _k ≧ dth_φ _k , ∀k. To select HOL packets for a flow, first consider HOL packets from the Tx queue, RTx queue, and ARQ queue for the flow, and select a queue based on the latency at the BTS. That is, the queue waiting in the BTS for the longest period is selected. Let γ _k [n] be the waiting time compensation for flow k at the beginning of slot n, and let S _k [n] be the time spent by the HOL packet for flow k in the BTS queue at the beginning of slot n. For each flow k, a minimum threshold S _{thres, min, k} and a maximum threshold S _{thres, max, k} are specified,

Meet.

According to one embodiment, delay compensation is applied when the flow is experiencing a delay threshold violation or a waiting time threshold violation. This mechanism applies DRC data rate requirements to adaptive weights. Let β _k [n] be the DRC adjustment function for flow k in slot n. For each flow k, a minimum threshold β _{tmin, thres, k} and a maximum threshold β _{max, thres, k} are specified,

Meet.

  While the compensation mechanism described above helps reduce flow delay variation for some applications such as video / audio conferencing, it more effectively includes delay variation (jitter) control to further reduce delay variation. It may be desirable to do so. The following mechanism provides effective delay variation control by reducing delay variation between successive packets of the flow. Larger IP packet size flows gain more benefits from this compensation mechanism.

Assume that at (k, j) is the arrival time of the IP packet j of the flow k when the BSC enters. Let dt (k, j) be the departure time of this IP packet from the BTS. That is, by this time, all parts of the IP packet have been transmitted by the downlink scheduler in the BTS. Pend _{k, j} [n] is the total length in bytes of the IP packet j of the flow k in the BTS and BSC. Also, dv _{k, target} is the target delay variation (jitter) between consecutive IP packets for flow k, and this flow is specified in advance so that dv _{k, thres} is dv _{k, thres} <dv _{k, target.} This is the extended function jitter threshold. In one embodiment, the algorithm triggers flow k's enhanced variation compensation mechanism when the delay variation between successive IP packets exceeds dv _{k, thres} .

  FIG. 10 provides an architectural diagram corresponding to one embodiment. Each application flow is described by a traffic profile, a QoS profile and a DRC request, i.e. a requested data rate. Each traffic profile includes a burstiness measure and an average data rate. Each QoS profile includes a class type and parameter limits. The class type may be one of Mode I, Mode II, Mode III, or Mode IV. The limits specify delay, jitter and required data rate limits. Some applications, such as web browsing, may specify an average delay instead of a delay limit. The delay threshold for mode I is chosen to be less than the jitter limit, and for mode II, the delay threshold is chosen to be less than the average delay. The enhanced jitter threshold is chosen to be below the jitter limit. In another embodiment, more or less information may be applied to each application flow, and the QoS requirements may be network and configuration specific.

  FIG. 11 is a table specifying QoS requirements and QoS parameters for each class type. As shown, mode IV corresponds to the best effort where QoS requirements are not specified, while mode I corresponds to the most stringent requirements. Alternative embodiments may include other QoS requirements, QoS parameters, and / or modes.

12A-12E depict the processing of an application flow and the scheduling of that application flow as part of an active application flow. FIG. 12A is a flow diagram depicting initialization and setup for individual application flows. The process begins at step 1100 to select a mechanism to be used for each compensation parameter. Compensation parameters include, but are not limited to, delay (Φ), pending time (γ), DRC (β), jitter (δ), and rate (α). In step 1102, a threshold for the applicable compensation parameter is selected. Note that the compensation parameters may include any parameters of the application flow that are important to the AN. In step 1104 , an algorithm for calculating the intermediate weight is selected. The intermediate weight is used in calculating the adaptive weight used for scheduling. In step 1106, both the scaling parameter (C) and the priority factor (Z) used in calculating the adaptive weight are set. In step 1108, the initial weight of this application flow is set. In step 1110, the QoS requirements of the application flow are evaluated. If there are no QoS requirements specified other than the rate specified by the DRC request, the default condition is used. The default condition is called “best effort” as described above. In this case, the default processing sets all of the compensation factors used for this application flow equal to one. In the present embodiment, in this case, the multiplication operator is used in the calculation of equation (6), so setting the coefficients to 1 results in those coefficients being ignored. That is, those coefficients do not affect the weighting. Note that in other embodiments, other mechanisms and functions may be implemented, and thus other mechanisms may be used to ignore special factors or all compensation factors.

  The best effort processing continues at steps 1112 and 1116. The resulting calculation of the scheduling factor is consistent with the proportional fair calculation. If the application flow has a QoS requirement, processing continues to step 1114. Steps 1114 and 1116 show processing that continues in subsequent figures.

  FIG. 12B continues the processing of FIG. 12A from step 1114. At step 1120, processing for the current slot begins. In step 1122, a determination is made as the class type of the application flow. Mode I is processed at step 1128, mode II is processed at step 1126, and mode III is processed at step 1124. Mode I QoS parameters are monitored at step 1128. Mode II QoS parameters are monitored at step 1126. Mode III QoS parameters are monitored at step 1124. A QoS violation check is then performed at steps 1130, 1140 and 1150, further detailed in FIGS. 12C and 12D.

  Application flow processing continues to step 1130 of FIG. 12C for mode I, II or III applications. In step 1132, the algorithm periodically monitors for rate violations. Note that the rate compensation calculation is performed periodically and is subsequently used for multiple slots. If a rate violation is detected at step 1134, processing continues to step 1138 to calculate the compensation factor (α). Otherwise, the rate compensation factor (α) is set equal to 1 at step 1136. Processing then continues to step 1160, which is further detailed in FIG. 12E.

  Application flow processing continues to step 1140 of FIG. 12C for mode I or II applications. In step 1142, the method monitors each slot for delay violations and jitter violations. If a delay and / or jitter violation is detected at step 1144, processing continues at step 1148 to calculate the delay compensation factor (Φ) according to the mechanism selected at initialization. For mode I flows that require enhanced jitter compensation, the enhanced jitter compensation factor (δ) is then also calculated. For mode I flows that did not require enhanced jitter compensation and for mode II flows, δ is set equal to 1. Alternatively, the delay compensation factor (Φ) is set equal to 1 in step 1146 and δ is set equal to 1. Processing then continues to step 1160, which is further detailed in FIG. 12E. For mode I or II application flows, violation checks may be performed serially or in parallel. In other words, the rate violation and delay / jitter violation checks may be performed sequentially in time or simultaneously.

Application flow processing continues to step 1150 of FIG. 12D for Mode I applications. In step 1152, the method monitors for waiting time violations. If a waiting time violation is detected at step 1154, processing continues to step 1158 to calculate a waiting time compensation factor (γ) according to the mechanism selected at initialization. Otherwise, the waiting time compensation factor (γ) is set equal to 1 in step 1156. Processing then continues to step 1160, which is further detailed in FIG. 12E. Note that for mode I application flows, violation checks may be performed serially or in parallel. In other words, as shown in steps 1170, 1172, rate violation, delay / jitter violation and wait time checks may be performed sequentially in time or simultaneously.

FIG. 12E depicts the processing from step 1160 and step 1116. Step 1162 calculates application flow adaptive weights as a function of QoS parameters and compensation factors, as shown below.

  In step 1164, a scheduling factor or scheduling metric is calculated as follows.

Scheduling coefficient = aw * (DRC / T) (10)
The scheduling algorithm then schedules application flows in step 1166 according to a scheduling factor calculated for each active application flow.

  FIG. 13 depicts a BTS 1200 adapted to apply a scheduling algorithm according to one embodiment. The BTS 1200 includes a scheduling device 1202, an application flow processing device 1206, a QoS parameter evaluation 1204, an adaptive weight calculation device 1212, and a CPU 1208 that are each coupled to the communication bus 1210. The scheduling device 1202 creates a scheduling coefficient for each application flow, and then performs scheduling by selecting from various active application flows according to the scheduling coefficient. The policy and goals for a given system are built into the scheduling algorithm. QoS parameter evaluation 1204 monitors for QoS violations and provides information to scheduling device 1202 and weight calculation device 1212. The application flow process includes directing the packet to the destination AT, receiving QoS information used for scheduling from the destination AT, and supplying such information to the QoS parameter evaluation 1204 ( The process is not limited to these. The BTS 1200 also includes memory 1214 for storing intermediate information and holding data used to calculate averages, flow queues, and the like. A violation check is performed at the BTS. One embodiment keeps counting the number of bytes sent out per flow and uses it for rate violation checking. Each packet is time stamped when it reaches the BSC. As long as the packet stays at the AN, BSC or BTS, the time continues to increment. The BTS uses this time for threshold violation detection and then calculates a delay function, a wait time function, or an enhanced jitter compensation function according to the flow.

Authorization Control Authorization control refers to the decision process when authorizing an entry for a user requesting a data service. When a new user requests a data service such as an application with QoS requirements, the AN determines whether there are resources available to support such use. The authorization process considers not only QoS statistics and network statistics, but also the requested application and current usage. If the AN determines that a new user may be supported, the corresponding application flow is allowed. Or, if no resources are currently available, the application flow is rejected or queued waiting for a status change. Note that a new user may actually be a user with a currently active application flow requesting additional services, ie additional application flows.

  In addition to and as part of admission control, a pre-processing process may be implemented to terminate the active application flow, where the current operating state is evaluated to make a pre-processing decision. In this case, each of the current flows is evaluated for QoS violations as well as data rates.

  This section presents an adaptive sector unit grant control algorithm. Such an admission control algorithm determines whether a flow is allowed (that is, pre-processed) in a certain wireless multimedia network. Thus, it is possible to determine the number of flows (of each class) that may be allowed in a network. The embodiment of the admission control algorithm presented herein includes a mechanism for performing QoS monitoring between and within users, and then uses this information for admission and / or pre-processing decisions. Such embodiments are designed to ensure that per-flow and per-user QoS requirements are met for authorized flows and users. Such a mechanism facilitates coordination of admission control algorithms and hierarchical scheduling algorithms.

  Scheduling and admission control are part of downlink (FL) QoS management of wireless networks, and such management is a complex issue. QoS management is a critical consideration in network design and operation. Application flows are classified according to criteria as defined by the system. In one embodiment, this classification is in accordance with QoS requirements. First, admission control determines the number of flows that can be allowed under the current operating state. This number of flows is then divided into the number of flows per class. The system then operates to meet the QoS requirements for each allowed flow. Note that the number of flows can change dynamically over time and with the type of application. For example, at a first point in time, the access network (AN) may support a first scenario where a certain number of flows are allowed for each type of application. At a second time, the AN may support a second scenario where a different number of flows are allowed for at least one of the application types.

  The scheduler (i.e. scheduling algorithm) implements a strategy to ensure fairness among the allowed flows. The scheduler will also attempt to perform a graceful recovery of flows with QoS violations. Operator revenues and profits depend on the effectiveness of the scheduling algorithm used. More efficient and feature-rich algorithms offer the opportunity to increase these benefits.

  With respect to admission control, in one embodiment, a method based on a subscription factor is implemented. Note that methods based on subscription factors are often used in admission control algorithms for wireline networks. In the wireless network, since the channel state of each user continues to change, the downlink capacity as viewed from the BTS scheduler also continues to change. Since the algorithm based on the wire subscription coefficient assumes a constant link capacity, it cannot be directly applied to a wireless network.

  For wireless networks, in one embodiment, an admission control algorithm based on an adaptive subscription factor (ASF) for FL management is provided, where the network supports multiple application flows with QoS requirements. With the ASF admission control in the wireless network, the subscription coefficient is dynamically updated by monitoring QoS statistics and network statistics. Various mechanisms are used to perform the update function. Thus, it is possible to take corrective action using the adaptive addition factor. In addition, ASF is used to implement the preprocessing method.

ASF, AS (t) is calculated every hour t. The process determines a minimum threshold AS _{min_prespecified} and a maximum threshold AS _{max_prespecified} for AS (t) such that AS (t) is 1 ≦ AS _{min_prespecified} ≦ AS (t) ≦ AS _{max_prespecified} <∞, ∀t. Initially, the value S _initial is assigned to the ASF, resulting in AS (0) = S _initial .

FIG. 14 is a timing diagram that plots the maximum data rate, reserved bandwidth, and available bandwidth as a function of time. The maximum rate (L _max ) at which the BTS can transmit data on the downlink is an upper limit for resource allocation. Active application flows are evaluated to determine the reserved bandwidth Res (t). Using the QoS violation and network load related statistics, a calculation of an adaptive subscription factor and downlink capacity estimate L (t) that is desired to be reserved at time t is performed. Note that L (t) ≦ Res (t). For example, assume that grant flows enjoyed very good channel conditions when they were granted. Now, the channel conditions of multiple flows have deteriorated and some flows have not achieved the associated QoS guarantees. In this case, the system is conservative in allowing more flows and may want to set Avail (t) = 0. On the other hand, if L (t)> Res (t), the system may set Avail (t) = L (t) −Res (t). Therefore, the value L (t) is an estimate of the downlink capacity that is desired to be reserved at time t based on past QoS violation statistics and network load related statistics, and is a function of L _max and ASF as Is calculated as follows.

With constraints,

It is. The available bandwidth Avail (t) is calculated as follows:

Avail (t) = maximum (L (t)-Res (t), 0) (14)
Various measures of resources as depicted in FIG. 14 are determined by data rate control (DRC) data requests received from users. Each user transmits a DRC data request on the uplink. In cdma2000 1xEV-DO or other HRPD type systems, the user sends a DRC data request in each slot of the RL transmission. As depicted in FIG. 15, the data request from user 1 (DRC 1) and the data request from user 2 (DRC2) change over time. The data request and the required QoS determine the reserved bandwidth (Res). Note that the relationship between the DRC value and Res is shown as an illustration. Different embodiments and scenarios may lead to different relationships.

Each application flow has a traffic profile specified in terms of average rate and burstiness, and the traffic profile of the flow f _k is given by (σ _k , r _k ). Here, r _k is the average required rate for flow f _k, sigma _k is the burst of the measure, the request rate for flow f _k is given by _{req_rate (f k) = r k} .

According to one embodiment, admission control evaluates flow f _k for admission. The admission control first applies the observed DRCu (f _k ) for the user corresponding to the flow f _k to satisfy the requested rate. The observed DRC is below the average DRC data request for the user as follows:

ASF and AS (t) are calculated, and then Avail (t) is calculated as follows using these values.

Finally, consider permission decisions for flow f _k at time t.

When flow f _k is granted, the resource measures as depicted in FIG. 14 are updated as follows:

  The AN continues to monitor QoS statistics for all allowed flows and continues to monitor network related statistics. This monitoring provides feedback to adapt the subscription factor.

Adaptive Method for AS (t): Per-Sector QoS Statistics and Network Statistics FIGS. 18A-18E provide a flow diagram of a method 300 for admission control in a system that supports multiple application flows with QoS requirements. In FIG. 18A, if a request for a new flow is received by the AN at decision diamond 302, an admission control procedure is run at step 304. Otherwise, the process waits for a new flow request. Note that during this time, the AN continues to monitor the current operational state to develop QoS statistics for the currently active flow and network statistics for the flow. The admission control procedure determines whether resources are available to support the new flow. The resource measure as depicted in FIG. 14 is updated at step 305. If a new flow is permitted at decision diamond 306, processing continues to step 307 for application of the adaptive scheduling process.

The permission control procedure of step 304 is further detailed in FIG. 18B. In decision diamond 308, the request rate for flow f _k when the average is greater than DRC data request for the flow f _k, the process rejects entry of the flow f _k continue to step 312. Otherwise, the process returns to decision diamond 310 to determine whether the requested rate for f _k exceeds the available resource Avail at time t. If the requested rate is less than Avail, the flow is allowed at step 314. Otherwise, the flow is rejected at step 312.

  The resource measure update in step 305 is further detailed in FIG. 18C. In step 320, resource measures Avail and Res are updated. QoS statistics are updated and monitored at step 322. The ASF is updated at step 324 based on the results of steps 320 and 322. The estimated resource level L is recalculated at step 326. When a new flow is requested at step 328, processing returns for processing at step 304 of FIG. 18A. If a new flow is not required at step 328, the presence of users in the sector is determined for each user at step 330. In step 332, the sample duration is determined.

Continuing with FIG. 18D, in step 340, QSG parameters are selected for each flow. Two parallel processing paths are considered. The first path handles rate violations at step 342 at rate sample intervals. Note that the rate sample interval exceeds the sample duration calculated in step 332. The second route details the processing of the active flow. For a flow, the process determines the percentage of IP packets with delay violations during the sample duration at step 344. In step 346, the percentage of IP packets with jitter violations during the sample duration is calculated for the flow under consideration. The percentage of slots used by the flow during the sample duration is calculated at step 348. In step 350, the process determines the percentage of slots that are given to flows with QoS requirements during the sample duration. In step 352, the process checks for QoS violations and in step 354 the QoS group ID is determined.

  Processing continues to FIG. 18E where step 360 calculates the number of flows for each QoS group. In step 362, the process calculates the percentage of QoS flow corresponding to each QoS statistic. The results of steps 360 and 362 are compared with a predetermined threshold value in step 364. Note that the threshold may be updated dynamically during the operation. In step 366, the ASF is adjusted accordingly.

  18A to 18E show an embodiment of the admission control method. Further details of the admission control method are described below. An AN element such as a BTS collects sector-by-sector statistics for each flow and uses this information for sector-by-sector admission control and preprocessing algorithms. Per-sector statistics are collected only for the duration that the user corresponding to the flow is in the sector. The BTS periodically collects QoS statistics and network related statistics. Let T be the time period after they are collected. Z is the sample index t = Z * T.

Consider the flow f _{k of} sector s. u (f _k ) is a user corresponding to the flow f _k . The user enters sector s at time t _enter . Resources are reserved for this flow for a duration [t _reserve (f _k , s), t _free (f _k , s)] in sector s. Here, the resource is reserved at time t _reserve . Resources are reserved when a user requests an application service. The user u (f _k ) enters the j-th sector s in t duration _{, j} (f _k , s) within the duration, and the j-th exit in t _{leave, j} (f _k , s). . Therefore, t _reserve (f _k , s) ≦ t _{enter, first} (f _k , s) and t _free (f _k , s) ≧ t _{leave, last} (f _k , s). It is noted that the AN may be instructed to reserve resources for the flow via the QoS signaling protocol in anticipation that the user may move to this sector at some point in the future. I want. Here, t _{enter, first} (f _k , s) is the first time user u (f _k ) enters this sector s, and t _{leave, last} (f _k , s) _This is the last time to leave sector s while _k is valid.

The algorithm considers QoS statistics and network-related performance statistics at time t only if the following conditions are met at time t.

Here, δ (f _k ) and θ (f _k ) are specified in advance for the flow f _k , and IN_IP_PKTS (f _k , t, s) is a period (max (t−T, t _{enter_latest} (f _k , s)), t) is the number of input IP packets for the flow f _k scheduled for transmission by the BTS downlink scheduler. When the last bit of the IP packet is transmitted in sector s, that bit is counted in IN_IP_PKTS for the sector. The variable δ (f _k ) refers to the time after which existence in the sector is suggested. In other words, once the user is in δ seconds sector s, the process begins to evaluate resources. Once authorized, the user can exit the sector and enter the sector without requiring reauthorization.

QoS statistics and network statistics are then used to evaluate authorization criteria for each flow requesting application services. The ratio of delayed IP packets corresponding to the flow f _k in the sector s in the period (max (t−T, t _{enter_latest} (f _k , s)), t) is calculated as follows.

Here, DELAYED_IP_PKTS (f _k , t, s) corresponds to the number of IP packets delayed by over the corresponding delay limit of the flow f _{k in} the BTS for sector s by time t. Upon detection of a delay violation for an IP packet at sector s, the delay violation count for that sector is incremented. The percentage of IP packet sets having a jitter limit violation for flow f _k up to time t is calculated as follows:

Here, JTR_VIOL_PKT_PAIRS (f _k , t) corresponds to the number of IP packet sets (for continuous IP packets) that have a jitter limit violation due to slot t for flow f _k . This is counted for a sector when two consecutive IP packets for a flow are transmitted in a sector.

The rate violation of the flow f _k during the period (t _{enter_latest} (f _k , s)) is

And req_rate (f _k )> served_rate (f _k , t, s). Otherwise, if the flow f _k does not have a rate violation at time t, then the reserved_rate (f _k , t, t for the flow f _{k in} sector s during the period (t _{enter_latest} (f _k , s), t) s) is calculated.

In case of delay and jitter violations, the process applies the sample duration as the period (max (t−T, t _{enter_latest} (f _k , s)), t), whereas in the case of rate violations, the process Note that the sample duration is applied as t _{enter_latest} (f _k , s), t).

The percentage of slots used by the flow f _k during the period (max (t−T, t _{enter_latest} (f _k , s)), t) is calculated as follows:

Here, SERVED_SLOTS (f _k , t, s) is the number of slots in which the flow f _k has been _served during the period defined by (max (t−T, t _{enter_latest} (f _k , s)), t). IN_SECTOR (f _k , t, s) is the total number of slots during the period (max (t−T, t _{enter_latest} (f _k , s)), t). The percentage of slots given to flows with QoS requirements in sector s during period (t-T, t) is

As shown.

Dynamic flow classification For each flow f _k , the following four thresholds are pre-specified and used to perform per-flow QoS checks and channel state related checks.

Frac_delayed_IP_pkts_thres (f _k ),
Frac_jitter_viol_IP_pkts_thres (f _k ),
rate_viol_thres (f _k ), and Frac_slots_viol_thres (f _k )
The system adapts the ASF periodically after each period T. T is a value specified in advance. At some time t (ie t = Z * T) when the Z-th adaptation check is performed, the process has a flow with some resources reserved in sector s, ie t _reserve (f _k , s) ≦ t Consider those flows _where ≦ t _free (f _k , s). For each flow f _k from this flow set, a check is performed to evaluate the following “flow unit threshold check”.

The four checks are performed for the flow f _k when the following two conditions are satisfied.

If at least one of the conditions (32), (33) is not satisfied for a flow, but _treserve (f _k , s) ≦ t ≦ t _free (f _k , s) is true, a threshold check for this flow Is marked as NA for the flow.

The process calculates the percentage of slots used for flows with requirements during QoS, sample duration, and also calculates a threshold for this percentage value. Frac_slots_thres_quos_flows (s) is an upper threshold for the ratio of slots allocated to flows having QoS requirements in the period T of the sector s. The value of Frac_slots_thres_quos_flows (s)

Used to check if.

  The process classifies the current flow into one of the following QoS scheduling groups (QSG):

QSG I or Q_DJR: flow with delay requirement, jitter requirement, and rate requirement QSG II or Q_RavgD: flow with rate requirement and average delay requirement QSG III or Q_R: flow with rate requirement Consider a set of flows belonging to Q_DJR class Try. A given flow f _k does not qualify for the NA category,

Or

The flow is designated as having delay_or_jitter_viol (f _k , t, s) = Y. Otherwise, the process sets delay_or_jitter_viol (f _k , t, s) = N for this flow. On the other hand, if this flow has NA qualification, delay_or_jitter_viol (f _k , t, s) = NA.

  At each time t at which the adaptation check for AS (t) is performed, the process classifies the QoS flows, that is, the flows with QoS requirements as shown in Table 2. Each flow is assigned a QoS Stat Group ID (QS_GID).

QS_GID = 1: Q_DJR class flow with rate and delay (or jitter) violation QS_GID = 2: Q_DJR class flow with rate (no jitter) violation QS_GID = 3: No delay and jitter violation, Q_DJR class flow with rate violation. This case can occur for adaptive applications. In addition, flows corresponding to the Q_R class and the Q_RavDD class having a rate violation are assigned to this group.

  QS_GID = 4: flow without QoS (rate, delay, and jitter) violations. Flows within the NA category are also placed in this group as described above.

Adaptation of subscription coefficient N _k (t, s) is the number of flows corresponding to QSG k at time t, and N (t, s) is reserved for some resources in sector s at time t The total number of flows.

Let M indicate the QoS stat group id (QS_GID),

  Occurs.

The ratio of the flow corresponding to the QSG of the flow k in the QoS stat group M at time t (within the sector s), QSG k is given as follows.

The percentage of flows with delay (or jitter) and rate violation at time t is shown as follows:

The percentage of flows at time t that have a delay (or jitter) violation but no rate violation is shown as follows:

The proportion of flows with only rate violations at time t is shown as follows.

The percentage of flows with no QoS violation (or in the NA category) is shown as follows:

The adaptation of S (t) is performed periodically after a period T specified in advance. In order to adapt, the group may be considered as follows.

  The following thresholds are specified in advance and are used in the adaptation method shown below.

Frac_flows_thres_DJR: Threshold for the percentage of flows with delay (or jitter) and rate violation
Frac_flows_thres_DJ—Threshold for the percentage of flows with delay (or jitter) violations but no rate violations
Frac_flows_thres_R—Threshold for the percentage of flows with rate violations (no delay violations or jitter violations)
Frac_flows_thres_ok_qos: Threshold for percentage of flows without QoS violations The process continues in the following order at each instant when an adaptation check is performed on AS (t).

Step 1: If Frac_flows_DJR_viol (t, s) ≧ Frac_flows_thres_DJR:
AS (t ⁺ ) = f _qos * AS (t) + x _qos , so that AS (t ⁺ ) ≧ AS (t). Here, f _qos and x _qos are specified in advance. Otherwise.

Step 2: If Frac_flows_DJ_viol (t, s) ≧ Frac_flows_thres_DJ:
AS (t ⁺ ) = f _{delay_jitter} * AS (t) + x _{delay_jitter} , so that AS (t ⁺ ) ≧ AS (t). Here, f _{delay_jitter} and x _{delay_jitter} are designated in advance. Otherwise,
Step 3: When Frac_flows_R_only_viol (t, s) ≧ Frac_flows_thres_R, AS (t ⁺ ) = f _rate * AS (t) + x _rate , and as a result, AS (t ⁺ ) ≧ AS (t). Here, f _rate and x _rate are specified in advance. Otherwise,
Step 4: If Frac_flows_no_na_viol (t, s) <Frac_flows_thres_ok_qos, then AS (t ⁺ ) = f _{all_qos_flows} * AS (t) + x _{all_qos_flows} , and the result AS (t ⁺ ) ≧ AS (t). Here, f _{all_qos_flows} and x _{all_qos_flows} are specified in advance. Otherwise,
Step 5: If Frac_flows_no_na_viol (t, s) ≧ Frac_flows_thres_ok_qos, and if frac_slots_qos_flows (t, s) <Frac_thres_slots_qos_flows:
AS (t ⁺ ) = f _ok * AS (t) + x _ok , so that AS (t ⁺ ) ≧ AS (t). Here, f _ok and x _ok are designated in advance. Otherwise.

Step 6: If Frac_flows_no_na_viol (t, s) ≧ Frac_flows_thres_ok_qos, and if frac_slots_qos_flows (t, s) ≧ Frac_thres_slots_qos_flows, AS (t ⁺ ) = AS (t)
Preprocessing Method FIG. 19 depicts a preprocessing method 400 according to one embodiment. Method 400 begins by determining whether the ASF has increased at decision diamond 402. If an increase in ASF is detected, the process continues to step 404 to determine the flow with the highest number of rate violations. In other words, as the ASF increases, the pre-processing method 400 starts identifying those flows for pre-processing. In this embodiment, a flow with a rate violation is identified as the best candidate for preprocessing. In another embodiment, other flows may be prioritized and the priority scheme may be changed dynamically.

When decision diamond 406 reaches a pre-processing maximum, P _MAX (described in detail below), processing continues to step 408 to pre-process the flow with the largest number of delay violations. Otherwise, the process returns to decision diamond 402. After pre-processing the flow at step 408, processing continues at decision diamond 410 to determine whether there are multiple flows with the largest number of delay violations. For multiple flows, processing continues at step 412 to preprocess the flow using the most slots. Typically, this flow has a low data rate and therefore consumes the most slots during a period. The process then returns to decision diamond 402.

In one embodiment, the preprocessing method 400 is applied. In this method, P_max is the maximum number of flows that can be pre-processed at a certain point in time. Consider a subset of flows that satisfy the conditions of the two pre-processing groups shown in Table 3. In particular, the pre-processing group I is composed of flows belonging to QSG_R or QSG_RavgD,

as well as

  Have

Preprocessing group 2 belongs to Q_DJR QSG,

as well as

It is comprised from the flow which has.

  Step 1: If AS (t) increases at some point (as in the adaptive method for AS (t)), the process checks to see if one or more flows are eligible for preprocessing To do. Note that the flow is not preprocessed when AS (t) is not increasing.

  Step 2: Consider a subset of flows corresponding to the pre-processing group 1. From these flows, the P_max number of the flow having the highest value of rate_viol is selected. When there are a plurality of items corresponding to this, the one having a higher Frac_slots_flow value is pre-processed. When the P_max flow is preprocessed, no further flows are preprocessed for rate violations.

Step 3: Consider a subset of flows corresponding to pre-processing group 2. These flows have delay and jitter requirements _have Frac_delayed_IP_Pkts (f k, t, s )> Frac_delayed_IP_pkts_thres (fk) and _{Frac_slots_flow (f k, t, s} )> frac_thres_slots_flow a _{(f k).} Among these flows, P_max having the highest value of Frac_delayed_IP_pkts and subtracting the number of flows preprocessed in step 2 is selected. When there are a plurality of items corresponding to this, the one with a higher value of Frac_slots_flow is preprocessed.

Inter-user and intra-user QoS
A mobile phone user may have multiple flows, ie multiple applications, simultaneously. As presented here, the user may specify:

  A per-flow indication of whether it is sensitive to delay and jitter. If it is sensitive to delay and jitter, a delay limit and jitter limit must be specified.

  Aggregate target rate (ATR) for each user. This is the target rate that the downlink hierarchical scheduler will aim to give to this user.

Authorization Control At time t, R (t) users are assigned U ₁ , U ₂ ,. . . , U _{R (t)} , let num_flows (U _j , t) be the number of flows of user U _{j at} time t. Assume that the user U _j has the allowed flow (k−1) at time t, ie, num_flows (U _j , t) = k−1. To decide to allow a new flow f _{k, j} for user U _{j at} time t, the process checks the following using the observed DRC for user U _j .

While performing ASF adaptation as described above, the number of slots used by the flow and its corresponding DRC are also taken into account. The process calculates AS (t) and calculates Avail (t) as follows:

The process,

In this case, the flow f _{k, j} is permitted at time t.

If this flow is allowed, the update is as follows.

The process continues to monitor QoS statistics and network related statistics for all authorized flows and users. These are used to continue the adaptation of adaptation factors. Next, ASF and AS (t) are calculated and used.

Hierarchical scheduler per flow and per user compensation:
Each delay and jitter sensitive flow is assigned a jitter threshold. For each delay and jitter sensitive flow fx for user U _k , the process calculates a corresponding delay and jitter compensation Φ. If the flow has no packets in the queue that exceed the delay threshold,

It becomes. Otherwise,

Calculate here,

For each flow fx for user U _k ,
ndefpkts _min (n) = minimum ndefpkts (59)
It is. Considering all flows in slot n (over all users),
defpkts (fx (U _k , n)) = number of pending MAC packets of flow fx of user U _k that violated their delay threshold in slot n (60)
It is.

For rate compensation of user U _{k in} slot n, define:

here,
ASR (U _k , n _prev (n)) = total supply rate of user U _k in slot n _prev (62)
And

It is. The slot number n _prev is n or the last slot before n when the rate is monitored for the purpose of the scheduling algorithm.

The process defines aggregate delay compensation for user U _k in any slot n. Consider all of this user's flows with delay requirements and observe head of line (HOL) MAC packets for each of these delay sensitive flows. If there are no (HOL) MAC packets over the system for a period longer than that delay threshold,

Otherwise, consider a subset of flows for this user who has HOL packets in the system for a period longer than the delay threshold. For this user, the following is calculated for all flows for user U _k that have HOL MAC packets in the system over a period greater than the delay threshold of these flows.

Here, w (fx (U _k )) is an initial weight assigned to the flow fx of the user U _k .

Adaptive Weight Calculation To calculate the adaptive weight for this user, the process performs a delay threshold violation check at each slot for each user with at least one flow that is sensitive to delay. The process calculates the following for each such user U _k :

If agg_delay_comp (U _k , n)> 1, the process calculates adaptive weights for user U _k as follows:

On the other hand, if agg_delay_comp (U _k , n) = 1, the process calculates:

Where n _{prev, k} (n) is n or n when ASR (U _k , n _prev (n)) is monitored (and thus U _k , n _prev (n)) is calculated) It is the last slot before. The process continues with calculating the final adaptation weight for this user as follows:

Here, Z (U _k , n) = 1 if there is no packet in the RTx or DARQ queue for a flow that is sensitive to the delay of user U _k . Otherwise, Z (U _k , n) = C (U _k ). Here, C (U _k ) is a constant specified in advance.

User and Flow Selection Method Calculate the following metrics for each user whose process has at least one packet in its queue at slot n.

here,

Is the average service delivery rate for user U _k (ie including all corresponding flows). The process selects the user whose Y (U _k , n) is the maximum value. Once a user is selected using such a scheduler, the process selects a flow to serve the user according to the following scheme.

  Consider flows that fall into the following groups:

  Group 1: QSG_delay_jitter. VoIP flow.

  Group 2: QSG_delay_jitter. Video conference flow.

  Group 3: QSG_delay_jitter. Video streaming flow.

  Group 4: QSG_rate_avg_delay. A flow with rate and average delay requirements.

  Group 5: QSG_rate. A flow that has only rate requirements.

  The following steps may be followed in executing the scheduling algorithm described herein.

  Step 1: Consider all pending flows of the selected user in that slot.

  Step 2: Consider flows corresponding to group 1 and group 2 for the user. Select the flow for which the HOL packet violates its delay threshold and is closest to the flow's delay limit. When a flow is detected, this flow is serviced. Otherwise, go to step 3.

  Step 3: Consider the flow corresponding to group 3 where the HOL packet exceeds the delay threshold and select the flow whose HOL packet is closest to the delay limit. If a flow is detected, service this flow. Otherwise, go to the next step.

  Step 4: Consider the flow corresponding to group 4 where the HOL packet has exceeded the delay threshold, and select the flow whose HOL packet is closest to the delay limit. If a flow is detected, service this flow. Otherwise, go to the next step.

  Step 5: Pick up the pending flows to be provided from groups 1-4. Give priority to the flow of the smallest group. Once a flow is selected, service it. Otherwise, go to the next step.

  Step 6: Consider the pending flow corresponding to group 5 for that user. The one with the maximum value of required_rate / served_rate is selected. Service this flow. If nothing is selected, proceed to the next step.

  Step 7: Serve the best effort flow for the user. If there are multiple, the one with the minimum service provision rate is taken up.

  FIG. 16 depicts a two-level scheduler that performs per-flow and per-user compensation. The scheduler depicted in FIGS. 16 and 17 is a hierarchical scheduler used for compensation between and within QoS, as described herein. As depicted in FIG. 16, the first level identified as level I is comprised of a plurality of scheduling elements, namely nodes S1, S2,. . . Contains SM, where each node processes a different QSG. In this example, M is the number of QSG groups to be processed. For example, the scheduling node S1 processes a voice over IP (VoIP) type application flow. Although VoIP is shown as an example, any application flow classified as QSG1 is processed at S1. Such a flow has a delay limit and a jitter limit specified to evaluate the QoS requirements. Multiple application VoIP type flows are processed in the scheduling element S1. Similarly, each scheduling element handles the flow for a particular QSG. Note that in another embodiment, one scheduling element may be provided with application flows for multiple QSGs. Note that multiple scheduling elements may be used to process the same QSG group.

  The level I of the scheduler depicted in FIG. 16 calculates part of the per-flow compensation. Multiple application flows per user are depicted in FIG. The level II scheduling element finalizes the calculation of per-flow compensation.

FIG. 17 shows scheduling nodes S1 , S2,. . . A scheduler with Sz is depicted. In this step, z is the number of users. Note that because the number of users is dynamic, the current number of scheduling nodes can change dynamically. Each scheduling node S1 , S2,. . . Sz is adapted to receive multiple flows from a given user. Scheduling node S1 receives flow F1 through Fk for user 1 (U1). Here, k is the total number of application flows currently being processed for user 1. Using the per-flow compensation calculated for each flow by the level I and level II schedulers of FIG. 16, the level II scheduler of FIG. 17 calculates the total user compensation for each user. The level II scheduler then selects the user and services this user in the slot according to the adaptive weighted DRC / T algorithm described above for the user selection method. The level II scheduler then selects from among the weight values received from the level I scheduler. As shown, W (Uk) is the initial weight assigned to user Uk and ATR (Uk) is the total target rate for user Uk. Once a user is selected, the level I scheduler corresponding to that user selects a flow and services that user in that slot according to the flow selection method described above.

  The downlink scheduler may allow each user to specify a willing price for a flow for service at a certain DRC value in the slot. Once the price is specified, the adaptive frame structure scheduler operates to meet the QoS requirements of different types of applications. The corresponding scheduling mechanism allows service providers to find a good balance between the goal of increasing profits and the goal of meeting the application's QoS requirements. Such a scheduling mechanism also provides dynamic cost control to the end user and may be used for applications with rate requirements and / or average delay requirements, streaming applications, etc. In one embodiment, each flow is provided with a pricing option that specifies a price per slot when it is serviced. This price depends on the DRC value requested by the user for the flow in that slot. The price flow j (i.e., flow j accessed by the user) is designated as c [j, m, DRC [j, m] happily paying in slot m. Here, DRC [j, m] indicates the rate at which this user can be served in slot m. The user may statically specify a price, such as a price specified in advance for each DRC value. Alternatively, the user may specify the price dynamically, for example, to change the price while the application is active. This allows the user to have some control over the price in order to respond to changing channel conditions and achieve the desired QoS. An operator may use such a scheduler with existing schedulers for inter-user and intra-user QoS. This allows the operator to specify at least two types of price determination methods. For inter-user and intra-user QoS schedulers, the operator may specify a static pricing scheme (based on a static service content agreement) and at the same time dynamically about the scheduler based on an adaptive frame structure. Price determination method is possible. The user may choose to use different schemes for different flows.

  In one embodiment, the time is divided into multiple frames and a scheduling decision is made for each slot depending on the DRC value, QoS requirements, QoS violation statistics, and the price specified by each user. The frame structure basically determines the order in which user queues should be serviced during one lap. The network determines which flows / users to serve in a given slot for each round in each scheduling round to achieve the desired goal. The frame structure, that is, the order in which flows are serviced in each lap continues to change and is referred to as an AFS-based algorithm.

  The following definitions illustrate some notations used in the calculation process. Given N queues (and one queue per flow), assume that the QoS requirement for flow j is met if it is served at rate r [j]. An initial weight w [j] and a time scale ts [j] are also specified in advance for each flow j. The process aims to give rate guarantee to flow j. This process may be monitored every slot that is an integer multiple of the time scale (ie, every slot m * ts [j] where m is an integer).

  Let start [j] be the slot at which flow j is first considered as a service provision target in one round. By the end of slot z, the system wants to serve S [j, z] = r [j] * (z-start [j]) bits. Here, z = m * ts [j] for some integer m. Using one scheduling mechanism, the system can balance the number of (time) slots that are desired to be assigned to a flow with the number of bits that are desired to service that flow.

  In addition, other parameters used for the AFS scheduler are indicated as follows:

slots_alloc [j, n]: number of slots allocated to queue (flow) j during round n slots_served [j, n]: slot when queue (flow) j is serviced within round n Number S_r [j, n]: Number of bits to be provided to the flow f before the end of the turn n round_len [n]: Length of the number of slots in the turn n round_len_thres: The upper limit of the turn length is set by this threshold Is done.

B [n]: List of pending queues at the beginning of slot n _{Rout_round} [j, n]: Number of bits serviced for queue j in round n by the scheduler Rout [j, n, g] The number of bits served for queue j during time interval [n, g] when g ≧ n, using the explanation given above, for queue j at the beginning of lap n The lack of bits is given by:

  If there is a bit shortage, the corresponding flow is lagging in service and must be compensated. On the other hand, the excess service received by the flow is not explicitly penalized, but other flows lagging in the service will be compensated, while this flow will not be compensated, so it is indirect Will be penalized.

Further, the normalized missing bit calculation for flow j at the beginning of lap n is given as:

The shortage in the slot for queue j at the beginning of lap n is shown as follows:

The process defines the normalized missing slot for queue j at the beginning of lap n as follows:

  Let lslot [n] be the last slot in lap n, and fslot [n] be the first slot in lap n. Assume that aw [j, n] represents the (adaptive) weight assigned to flow j for lap n. This weight determines the number of slots assigned to flow j in cycle n.

A permutation is given to the DRC value requested by the user. Specifically, when DRC ₁ [B, S] is superior to DRC ₂ [B, S], (B / S) ₁ > (B / S) ₂ . Here, B is the number of bits per packet, and S is the number of slots.

  For each scheduling round of the AFS scheduler, the process calculates the state variables described above for each round, then calculates the weight of each flow at the beginning of each round, and gives this flow a fixed number of slots for this round. assign. For this purpose, the process uses an adaptive weight calculation mechanism and calculates a frame structure for each lap using a per-lap service discipline.

(Adaptive weight calculation mechanism)
Let ndef_bits_r _{thres, min} be a pre-specified threshold for ndef_bits_r. The process defines a set ndefbits_set [n] at the beginning of lap n as shown below.

Let S_I [n] be the number of flows in the set at the beginning of lap n. Similarly, ndef_slots_r _{thres, min} is a pre-specified threshold for ndef_slots_r. The process defines ndefslots_set [n] at the beginning of lap n as follows:

  Let S_II [n] be the number of flows in this set at the beginning of lap n.

For an arbitrary flow j, the corresponding slot compensation function is defined as follows at the beginning of lap n.

here,

  It is.

For each flow j,

Two thresholds, slots_comp_I _{thres, min} [j] and slots_comp_I _{thres, max} [j] are defined so that

By using these thresholds in conjunction with the adaptive weight calculation described herein, any flow is prevented from unfairly consuming a large number of slots in circulant n, while at the same time exceeding that specified limit. There will be no penalty.

For each flow j,

Two thresholds slots_comp_II _{thres, min} [j] and slots_comp_II _{thres, max} [j] are defined so that

At the beginning of each lap, the flows are divided into four groups as shown in Table 5.

Use slot_comp [j, n] = 1 for flow j belonging to either group II or group IV at the beginning of any lap n. The following applies to the flow j belonging to group I at the start of lap n.

If flow j belongs to group III at the beginning of lap n, the following applies:

Next, the process calculates the adaptive weight for flow j, where the adaptive weight for a non-empty queue of lap n is as follows:

here,

It is. For each flow j, define a threshold aw _{thres, max} [j] and use this threshold to ensure:

These adaptive weights are then used to determine the number of slots that will be assigned to each flow, and the

  Is calculated as follows.

Periodic scheduling discipline Once each flow has been assigned, some of the slots in the lap and the length of the lap have been calculated. The next step is to select a flow to serve a given slot. For any given slot m in round n, if the selected packet in one of the previous slots is still being serviced, there is no need to select a new flow that must be serviced. On the other hand, if the packet is not serviced in this slot m in circuit n, the flow to service is selected as follows. The following selection metric for slot m of round n for flow j, for each slot m where the scheduler needs to select a new flow to serve, and

as well as

For each flow j

Calculate Here, θ (j) is specified in advance for each flow j, and wait_comp is a waiting compensation given to the flow in order to improve the delay limit of the flow. Let wait [j, n, m] be the waiting time for the beginning of line packet for flow j at the beginning of slot m in cycle n.

Flow j also has at least one pending packet at the beginning of slot m in circuit n. Next, for all flows k such that kεB [n] and the number of such flows is wait_num [n, m],

Calculate For each flow j, two thresholds wait_comp _{thres, min} [j] and wait_comp _{thres, max} [j] are assigned,

  Used to ensure. The flow with the largest value of the selection metric YY is selected and serviced in any given slot by this AFS scheduler.

  An AN element according to one embodiment is depicted in FIG. The AN element 500 receives application flow data and processes this data for transmission to the user. The AN element 500 schedules multiple application flows, each having a QoS requirement. Note that the application flow may include a best effort flow as described above. The AN element 500 includes a flow classifier 502 that is adapted to identify a traffic profile and a QoS profile associated with the flow and to allocate the flow to a class, or QSG. Flow classifier 502 is coupled to scheduler 504, admission controller 510, and QoS monitor 506. The scheduler 504 may implement any of a variety of scheduling algorithms including, but not limited to, a proportional fair (PF) algorithm and an adaptive weighted PF algorithm. The admission controller 510 applies admission control mechanisms to application flows received by the AN 500. The admission controller 510 evaluates each requested new flow based on QoS statistics and network statistics to determine whether sufficient resources are available to support the new flow. The adaptive device is coupled to the admission controller, where the ASF is updated. The adaptation device 512 is adapted to perform pre-processing decisions for the currently active application flow. The preprocessing considers the performance of a given flow in terms of data rate, slots used, and other QoS and network statistics. The QoS monitor is adapted to monitor the QoS requirements of the received application flow. Note that AN element 500 typically receives multiple flows and selects among them for transmission to the user. The scheduler 504 receives information regarding whether or not a new flow is permitted from the permission control device 510. The scheduler 504 receives QoS statistics and other information from the QoS monitor 506, where the scheduler 504 uses the QoS information to select a flow for transmission.

  Presented herein are a method and apparatus for admission control, preprocessing, and scheduling of application flows in a wireless communication system. In admission control, the required data rate of the new flow is taken into account and compared to available resources. Once authorized, the flow is provided to the scheduler. The scheduler is adapted to perform per-flow and per-user analysis to select a user for transmission in each slot or specified period.

  Those skilled in the art will understand that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referred to throughout the description are voltages, currents, electromagnetic waves, magnetic fields or magnetic particles, optical fields or optical particles, or any combination thereof. Can be represented.

  Those skilled in the art will appreciate that the various exemplary logic blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or a combination of both. It will be further understood that this can be done. Various illustrative components, blocks, modules, circuits, and steps have been generally described above in terms of their functionality to clearly demonstrate hardware and software compatibility. Whether such functionality is implemented as hardware or software depends on specific applications and design constraints imposed on the overall system. Those skilled in the art may implement the functionality described in various ways for a particular application, but such implementation decisions should not be construed as causing a departure from the scope of the present invention.

  Various exemplary logic blocks, modules, and circuits described in connection with the embodiments disclosed herein include general purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), Field programmable gate array (FPGA) or other programmable logic device, discrete gate, or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein It may be realized or executed. A general purpose processor may be a microprocessor, but the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may be implemented as a combination of computing devices such as a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors used with a DSP core, or any other such configuration. May be.

  The method, algorithm steps described in the context of the embodiments disclosed herein may be implemented in hardware, in software modules executed by a processor, or in a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, removable disk, CD-ROM, or other known form of storage medium. An exemplary storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside at the user terminal. In the alternative, the processor and the storage medium may reside as discrete components in a user terminal.

  The description of the disclosed embodiments is provided to enable any person 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. Accordingly, the present invention is not intended to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims (3)

Communication that supports Internet Protocol (IP) applications and includes an access network (AN) and a plurality of access terminals (AT) each transmitting a requested data rate to the AN and supporting application flows having QoS requirements for the AT A method for allocating resources in a system, comprising:
Pre-processing a first flow having a first type of QoS violation to increase adaptive subscription;
Determining that the pre-processing maximum has been reached for the first type of QoS violation;
Pre-processing a second flow having a second type of QoS violation;
Including a method. Pre-processing the second flow
The method of claim 1, further comprising selecting the second flow based on a number of slots used for transmission of the second flow. Communication that supports Internet Protocol (IP) applications and includes an access network (AN) and a plurality of access terminals (AT) each transmitting a requested data rate to the AN and supporting application flows having QoS requirements for the AT A device for allocating resources in a system,
Means for pre-processing a first flow having a first type of QoS violation to increase adaptive subscription;
Means for determining that a pre-processing maximum has been reached for the first type of QoS violation;
Means for pre-processing a second flow having a second type of QoS violation;
An apparatus comprising:

Images