隊列管理方法和裝置的制造方法
【技術領域】
[0001] 本發(fā)明涉及通信技術，尤其涉及一種隊列管理方法和裝置。
【背景技術】
[0002] 隨著移動互聯(lián)網(wǎng)的爆炸式發(fā)展，通過無線接入網(wǎng)入口的Internet服務需求龐大。 由于無線接入網(wǎng)固有的切換、高丟包率、時延抖動等特點，一般是端到端IP網(wǎng)絡性能的瓶 頸。無線和有線網(wǎng)絡共同組成的帶寬不匹配管道會增加網(wǎng)絡擁塞的發(fā)生概率，此時降低擁 塞發(fā)生概率以及從擁塞狀態(tài)快速恢復的能力和魯棒性很大程度上決定了端到端網(wǎng)絡性能。
[0003] 無線有線混合網(wǎng)絡擁塞的發(fā)生靜態(tài)上是由于有線和無線之間管道的可用帶寬 存在差異：對于下行鏈路而言，互聯(lián)網(wǎng)協(xié)議（Internet Protocol，IP)數(shù)據(jù)報從公共數(shù) 據(jù)網(wǎng)關（Public Data Network Gateway, PDN Gateway)流入無線接入網(wǎng)（Radio Access Network，RAN)的速率高于RAN通過無線接口向用戶設備（UserEquipment，UE)的發(fā)送速 率，在諸如eNodeB等RAN網(wǎng)元節(jié)點處數(shù)據(jù)緩存，當緩存數(shù)據(jù)量超過緩存內存空間（Buffer Size)時，導致緩存溢出的大量連續(xù)被動丟包。從高層協(xié)議（如傳輸控制協(xié)議Transmit Control Protocol，TCP)的角度看，就是底層網(wǎng)絡發(fā)生了嚴重擁塞。
[0004] 無線信道相對于有線信道具有窄帶寬、信道質量不穩(wěn)定、移動性等固有特征。而 TCP協(xié)議將無線信道的不穩(wěn)定性直觀理解為端到端環(huán)回時延（Round Trip Time，RTT)波動 或報文段丟失。
[0005] 當然，TCP協(xié)議本身具有一定的流量控制和擁塞恢復能力。當TCP協(xié)議"感知"到 報文段丟失后，TCP的擁塞窗口會自適應收縮，降低高層發(fā)包速率以應對底層網(wǎng)絡擁塞。但 是，TCP的擁塞恢復是典型的"端算法"，僅僅在終端設備（如UE/Server)中發(fā)揮作用。當無 線信道環(huán)境發(fā)生劇烈變化或者可用無線資源由于更多競爭者加入發(fā)生變化時，位于Server 中的TCP響應一般情況下都無法及時跟蹤這種變化，導致?lián)砣麩o法得到及時解決或者當擁 塞解除后高層傳輸速率無法及時恢復的"TCP遲滯"特性。
[0006] 主動隊列管理（Active Queue Management, AQM)是一種解決"TCP遲滯"的有效方 案，算法一般在傳輸瓶頸的網(wǎng)元節(jié)點中實現(xiàn)。優(yōu)點是簡單易行，缺點是主動丟包在一些場景 中可能導致丟包率急劇上升，降低傳輸效率。而導致性能下降的根本原因在于，TCP和AQM 這兩種擁塞算法之間無法默契配合，嚴重時出現(xiàn)互相制約。但TCP和AQM算法本身分布在 不同的網(wǎng)絡設備中，處于各自為戰(zhàn)狀態(tài)，缺乏協(xié)同能力。

【發(fā)明內容】

[0007] 本發(fā)明要解決的技術問題是提供一種隊列管理方法及裝置，以解決現(xiàn)有擁塞解決 方案不合理的問題。
[0008] 為解決上述技術問題，本發(fā)明提供了一種隊列管理方法，該方法包括：
[0009] 監(jiān)控隊列緩存狀態(tài)；
[0010] 當隊列緩存數(shù)量超過擁塞預警門限的時間超過預定時長后，開始執(zhí)行策略丟包。
[0011] 進一步地，所述隊列緩存數(shù)量超過擁塞預警門限且持續(xù)預定時長指隊列緩存數(shù)量 超過擁塞預警門限的單次持續(xù)時長或多次持續(xù)累計時長超過預定時長。
[0012] 為解決上述技術問題，本發(fā)明還提供了一種隊列管理裝置，該裝置包括：
[0013] 監(jiān)控模塊，用于監(jiān)控隊列緩存狀態(tài)；
[0014] 丟包控制模塊，用于當隊列緩存數(shù)量超過擁塞預警門限的時間超過預定時長后， 開始執(zhí)行策略丟包。
[0015] 進一步地，所述隊列緩存數(shù)量超過擁塞預警門限且持續(xù)預定時長指隊列緩存數(shù)量 超過擁塞預警門限的單次持續(xù)時長或多次持續(xù)累計時長超過預定時長。
[0016] 相較于現(xiàn)有技術，本發(fā)明隊列管理方法和裝置通過監(jiān)控隊列緩存狀態(tài)，并在隊列 緩存數(shù)量超過擁塞預警門限的時間超過預定時長后，才開始執(zhí)行策略丟包。在一定程度上 解決TCP和AQM "各自為政"的無序狀態(tài)，在不增加額外測量和協(xié)議信令的前提下，通過設 置"觀察窗"（即預定時長）對無線擁塞進行早期預測并評估TCP的擁塞恢復能力，根據(jù)評 估和預測結果協(xié)同調整隊列管理方案，降低未來發(fā)生嚴重擁塞的概率，實現(xiàn)了 TCP與AQM之 間的協(xié)同，為一種協(xié)同隊列管理（Cooperate Queue Management, CQM)的方式。
【附圖說明】
[0017] 圖1為本發(fā)明隊列管理方法實施例1的示意圖；
[0018] 圖2為本發(fā)明"運行觀察期"主動管理策略示意圖；
[0019] 圖3為本發(fā)明隊列管理方法實施例2的示意圖；
[0020] 圖4為基于實施例2的應用實例1的TK意圖；
[0021] 圖5為應用實施例2和圖4流程的動態(tài)實施效果示意圖；
[0022] 圖6為本發(fā)明隊列管理方法實施例3的示意圖；
[0023] 圖7為基于實施例3的應用實例2的不意圖；
[0024] 圖8為應用實施例2和圖7流程的動態(tài)實施效果示意圖；
[0025] 圖9為本發(fā)明隊列管理方法實施例4的示意圖；
[0026] 圖10至圖12為三種定時器自身狀態(tài)轉移的條件示意圖；
[0027] 圖13為二種定時器的動態(tài)變化TK意圖；
[0028] 圖14為基于實施例4的應用實例3的TJK意圖；
[0029] 圖15為應用實施例4和圖14流程的動態(tài)實施效果示意圖；
[0030] 圖16至圖18為本發(fā)明隊列管理裝置實施例的模塊結構示意圖。
【具體實施方式】
[0031] 實施例1
[0032] 本發(fā)明隊列管理方法實施例1，如圖1所示，該方法包括：
[0033] 步驟101 :監(jiān)控隊列緩存狀態(tài)；
[0034] 步驟102 :當隊列緩存數(shù)量超過擁塞預警門限的時間超過預定時長后，開始執(zhí)行 策略丟包。
[0035] 進一步地，所述隊列緩存數(shù)量超過擁塞預警門限且持續(xù)預定時長指隊列緩存數(shù)量 超過擁塞預警門限的單次持續(xù)時長或多次持續(xù)累計時長超過預定時長。
[0036] 當隊列緩存數(shù)量超過擁塞預警門限的時間超過預定時長（本文中也稱為"喚醒觀 察期"）表明無線網(wǎng)絡側監(jiān)測到TCP的擁塞恢復機制無法解決的擁塞問題發(fā)生，即達到了真 正的擁塞，這種情況下才開始執(zhí)行策略丟包，以解決該擁塞。
[0037] 上述實施例1在不增加額外測量和協(xié)議信令的前提下，通過設置"觀察窗"（即預 定時長）對無線擁塞進行早期預測并評估TCP的擁塞恢復能力，根據(jù)評估和預測結果協(xié)同 調整隊列管理方案，降低未來發(fā)生嚴重擁塞的概率，實現(xiàn)了 TCP與AQM之間的協(xié)同，為一種 協(xié)同隊列管理（Cooperate Queue Management, CQM)的方式。
[0038] 具體的，當CQM處于"運行觀察期"時，通過設置類似RED算法的CQM控制區(qū)（概 率丟棄區(qū)）門限來控制主動丟包，如下圖2所示：
[0039] 其中CQM控制區(qū)是緩存區(qū)域的一個連續(xù)子集，一般情況下丟包區(qū)上限為緩存容量 上限，丟包區(qū)下限由參數(shù)"CQM丟包的隊列長度下限"確定。
[0040] CQM去激活態(tài)：當緩存量低于CQM控制區(qū)下限即擁塞預警門限或緩存量超過擁塞 預警門限的時間但未超過預定時長時，為CQM去激活態(tài)，無條件接納到達的任意IP數(shù)據(jù) 報；
[0041] CQM激活態(tài)：當緩存量高于CQM控制區(qū)下限（即擁塞預警門限）且超過預定時長 后，進入CQM激活態(tài)，此時根據(jù)緩存隊列長度（例如rocp中待處理的IP數(shù)據(jù)報文量），通過 AQM丟包概率曲線進行選擇性丟棄。
[0042] 一種典型的線性RED算法丟包概率曲線為：
[0044] 其中High為CQM控制區(qū)上限（即為緩存容量上限）；Low為丟包區(qū)下限，由參數(shù) "CQM丟包隊列長度下限"控制；BO為當前緩存隊列實際長度。
[0045] 設置的擁塞預警門限一般大于丟包區(qū)下限。
[0046] 另外，可通過自適應調整"觀察窗"，提升TCP和AQM之間的互相協(xié)同能力。具體地， 從開始執(zhí)行丟包至隊列緩存數(shù)量再次超過擁塞預警門限的時長小于第一預定時間，則減少 所述喚醒定時器的時長；如從開始執(zhí)行丟包至隊列緩存數(shù)量再次超過擁塞預警門限的時長 大于第二預定時間，則增加所述喚醒定時器的時長。
[0047] 進一步地，當擁塞解決或者TCP擁塞恢復能力提升后及時退出主動丟包策略。
[0048] 為了實現(xiàn)對隊列緩存狀態(tài)的監(jiān)控，可以采用定時器方式，具體地，本發(fā)明實現(xiàn)方案 設計以下配置參數(shù)：
[0049]
[0050] 以下根據(jù)設置的定時器的，給出多個實施例：
[0051] 實施例2
[0052] 本發(fā)明隊列管理方法實施例2中僅設置喚醒定時器，如圖3所示，該方法包括：
[0053] 步驟301 :設置喚醒定時器及喚醒定時器時長；
[0054] 步驟302 :根據(jù)隊列緩存狀態(tài)調整所述喚醒定時器的狀態(tài)；
[0055] 其中，當隊列緩存數(shù)量上升至大于所述擁塞預警門限時，啟動所述喚醒定時器；所 述喚醒定時器運行期間，所述隊列緩存數(shù)量下降至小于所述擁塞預警門限時，廢棄已啟動 的喚醒定時器；
[0056] 步驟303 :監(jiān)控所述喚醒定時器的狀態(tài)；
[0057] 以上步驟301至303實現(xiàn)了對隊列緩存狀態(tài)的監(jiān)控；具體地，可周期和/或事件觸 發(fā)隊列緩存狀態(tài)尤其是隊列緩存數(shù)量的監(jiān)控操作，本文所說的所述事件包括數(shù)據(jù)包到達和 數(shù)據(jù)包發(fā)送。
[0058] 步驟304 :當所述喚醒定時器溢出后，開始執(zhí)行策略丟包。
[0059] 當所述喚醒定時器溢出時，認為隊列緩存數(shù)量超過擁塞預警門限的時間超過預定 時長。
[0060] 步驟305 :當所述隊列緩存數(shù)量下降至小于所述擁塞預警門限時，停止執(zhí)行丟包 策略。
[0061] 可選地，該實施例還包括定時器時長調整步驟，其中所述喚醒定時