由於，許多演算法並沒有將有限的佇列長度加入網路系統設計的考 量，甚至假設無上限的佇列長度。因此，本文所提出之排程器演算法在 分配資源時參考該連線的佇列狀態，將網路頻寬優先分配予佇列使用程 度較滿之連線，以避免佇列滿溢（overflow）而造成封包丟棄之結果。
本文提出了一個以估算佇列長度為基礎的BS端下行鏈結排程方法。
此法參考原有 Random Early Detection（RED）[14]方法，以估算佇列長度 來進行排程，稱之為 Queue-Length based Scheduling（QLS）。原始的 RED 是針對路由器的壅塞控制問題而進行所謂的佇列管理機制。讓不同網路 應用，如：Telnet、FTP、P2P、VoIP 及其他多媒體應用在封包遺失率、
生產效能等之表現都有所改善提升。
在 QLS 機制裡，如圖 3-1 封包佇列有固定的最低（Minimum Threshold，
Tmin）與最高門檻值（Maximum Threshold， Tmax）。並且依照最長至最短 短之佇列長度順序進行頻寬分配。在每一次頻寬分配回合開始時，QLS 利用公式（1）找出使用程度最高即最長的佇列，為該回合欲服務的佇列。
（1）
QLi為第 i 個佇列之佇列長度，並且 QLi≧0；n 為所有 QL≧0 的佇列 個數。
State 1 State 2 State 3
Tmin Tmax
Qtmi
QLS scheduler
n i*
圖 3-1 QLS 演算法正常情況示意圖
State 1（佇列使用程度過低）：當 QLi值小於等於 Tmin時。
State 2（佇列使用程度正常）：當 QLi值大於 Tmin但小於 Tmax時。
State 3（佇列使用程度過大）： QLi大於等於 Tmax。
在 QLS 排程器根據公式（1）選出目前最長之佇列後，首先判斷其 是否小於等於最低門檻值。假使是的話，即表示現存所有佇列皆為 State 1 之佇列，如圖 3-2。在這樣的情況下，我們將先以最公平的方式分配頻寬 資源，如公式（2）所示。
（ ） （2）
其中 W 為連線可供分配的所有頻寬（link capacity），n 為所有 QL≧0 的佇列個數。
i*
Tmin Tmax
QLS scheduler Qtmi
n
圖 3-2 QLS 演算法特殊情況示意圖
接著，將那些上一個步驟利用公式（2）分配而 QLi仍然大於 0 的佇 列，再次藉由公式（1）選出最長的佇列，將剩餘的 W 以 1 個封包單位的 配額循環逐次增加 Qtmi*值，直到所有佇列皆被清空或是頻寬分配完畢為 止。
然而，假使所選出佇列 i*之長度大於 Tmax時，則以估算佇列長度之 動態分配頻寬的方式來進行資源配置，如公式（3）所示。
（ ）
（ ） （3）
Qtmi*為佇列 i*所分配的頻寬資源配額（Quantum），其單位為封包個 數；假設 QLi*為佇列 i*之佇列長度（Queue Length），單位為封包個數；C 為固定分配的頻寬資源常數值（Constant）；Tmin為最低門檻值；Tmax為最 高門檻值；而 W 則為該連線可供分配的所有頻寬（link capacity）。
如上公式（2）分為兩種情境：當 QLi*值大於 Tmin但小於 Tmax時。即 佇列狀態為 State 2，QLS 排程器將取固定配額 C 與剩餘頻寬 W，兩者中 較小值為該佇列 Qtm 值，足以應付其佇列需求，而不至於過度飢餓
（starvation）；QLi*大於等於 Tmax。這時 QLS 排程器不僅配予此佇列 C 值 的固定配額，並且將取 QLi*與 Tmax之差額加 1 與剩餘頻寬 W 中較小值為 該佇列 Qtmi*值，配予比之 State 2 更多的配額，並盡可能讓佇列之使用程 度恢復成正常（State 2）而不會有佇列滿溢之結果。當然，每次計算出來 Qtmi*值後，會將可供分配頻寬 W 減掉該 Qtmi*值，以供下次欲服務的佇 列參考。直到所有佇列皆被清空或是頻寬分配完畢為止。
如上述，本研究不僅僅以佇列使用程度進行動態的分配網路頻寬資 源，更考慮了特殊情況並依照其特性採用了權重的概念為每個網路用戶 端提供更有效率的頻寬分配同時更確保了頻寬資源分享的公平性。圖 3-3 為本研究所提出之 QLS 演算法流程圖。其中 為所有 QLi
≧0 的佇列集合，而 。
Start
find i* based on formula (1)
Tmin
if i*
Yes No
assign Qtmi*
based on formula (3)
QLi* = QLi* - Qtmi* based on formula (1)
Qtmi* = Qtmi* + 1