本發(fā)明涉及無線通信領域，特別是涉及一種控制面資源調度方法和裝置。

背景技術：

隨著移動互聯(lián)應用的發(fā)展，移動實時通訊等OTT應用廣泛普及，由于移動實時通訊軟件表現(xiàn)出數(shù)據(jù)傳輸非連續(xù)但又存在頻繁發(fā)送數(shù)據(jù)的需求，為了降低頻繁發(fā)送導致初始接入壓力過大等問題，現(xiàn)時移動通信網(wǎng)絡中采用拉長終端失同步判定時長來克服該問題，即使得終端在完成數(shù)據(jù)傳輸后，下次數(shù)據(jù)傳輸假如在失同步時長范圍內，則終端可以直接發(fā)送數(shù)據(jù)，無需重新執(zhí)行接入過程，有效克服大量終端頻繁接入導致空口側及核心側壓力過大的問題。

然而，在拉長終端的失同步時長后，待調度的用戶存在一個特征，那就是實際有調度需求的用戶數(shù)不變，但數(shù)據(jù)調度完畢而失同步時長還沒到的用戶，依然在待調度用戶隊列中，導致調度過程需要檢測的待調度用戶數(shù)成倍激增。調度過程需檢測在失同步時長內的所有接入用戶，進而造成控制面(媒體接入控制層控制面)調度壓力大。

技術實現(xiàn)要素：

基于此，有必要針對降低調度壓力的控制面資源調度方法的裝置。

一種控制面資源調度方法，包括：

獲取調度請求；

將所述調度請求對應的用戶放入業(yè)務隊列中；

在對應的調度時刻，采用預設的調度算法，根據(jù)所述業(yè)務隊列中的用戶進行資源調度；

根據(jù)調度結果，將調度完成的用戶從所述業(yè)務隊列中刪除，并放入空閑隊列中。

在其中一個實施例中，還包括：

對所述空閑隊列中的用戶進行失同步判定；

若所述空閑隊列中的用戶在預設時長內未發(fā)送調度請求，則將所述用戶從所述空閑隊列中刪除。

在其中一個實施例中，所述將所述調度請求對應的用戶放入業(yè)務隊列中的步驟為：

當獲取到的調度請求為新用戶的調度請求時，將對應的用戶添加到業(yè)務隊列；或

當獲取到的調度請求為空閑隊列中的用戶的調度請求時，將對應的用戶添加到業(yè)務隊列。

在其中一個實施例中，在所述獲取調度請求的步驟之前，還包括：

建立業(yè)務隊列和空閑隊列。

在其中一個實施例中，所述預設的調度算法包括比例平均調度算法、QoS調度算法、最大載干比算法和輪詢調度算法中的任意一種。

一種控制面資源調度裝置，包括：

獲取模塊，用于獲取調度請求；

隊列管理模塊，用于將所述調度請求對應的用戶放入業(yè)務隊列中；

調度模塊，用于在對應的調度時刻，采用預設的調度算法，根據(jù)所述業(yè)務隊列中的用戶進行資源調度；

所述隊列管理模塊，還用于根據(jù)調度結果，將調度完成的用戶從所述業(yè)務隊列中刪除，并放入空閑隊列中。

在其中一個實施例中，還包括：

失同步判定模塊，用于對所述空閑隊列中的用戶進行失同步判定；

所述隊列管理模塊用于在所述失同步判定模塊判定所述空閑隊列中的用戶在預設時長內未發(fā)送調度請求時，將所述用戶從所述空閑隊列中刪除。

在其中一個實施例中，所述隊列管理模塊，用于當獲取到的調度請求為新用戶的調度請求時，將對應的用戶添加到業(yè)務隊列；或當獲取到的調度請求為空閑隊列中的用戶的調度請求時，將對應的用戶添加到業(yè)務隊列。

在其中一個實施例中，所述隊列管理模塊，還用于在所述獲取模塊獲取調度請求之前，建立業(yè)務隊列和空閑隊列。

在其中一個實施例中，所述預設的調度算法包括比例平均調度算法、QoS調度算法、最大載干比算法和輪詢調度算法中的任意一種。

上述的控制面資源調度方法，將有調度需求的用戶放入業(yè)務隊列中，并對業(yè)務隊列中的用戶采用預設的調度算法進行資源調度，調度需求完成的用戶放入空閑隊列中。通過采用業(yè)務隊列與空閑隊列分離管理的機制，將有調度需求的用戶和調度需求完成的用戶分離管理，在調度過程中僅需要對業(yè)務隊列中用戶進行檢測，避免檢測在線而又調度完畢的用戶的開銷，大大提升了控制面調度能力。

附圖說明

圖1為一個實施例的控制面資源調度方法的流程圖；

圖2為一個實施例的控制面調度過程示意圖；

圖3為一個實施例的控制面資源調度裝置的結構示意圖；

圖4為另一個實施例的控制面資源調度裝置的結構示意圖。

具體實施方式

在一個實施例中，提供一種控制面資源調度方法，該方法由基站執(zhí)行，如圖1所示，具體包括以下步驟：

S102：獲取調度請求。

本實施例中的調度請求包括已接入的用戶在其失同步時長內發(fā)送的調度請求和新用戶在接入過程中產(chǎn)生的調度請求。調度請求分為上行調度請求和下行調度請求。

S104：將調度請求對應的用戶放入業(yè)務隊列中。

S106：在對應的調度時刻，采用預設的調度算法，根據(jù)業(yè)務隊列中的用戶進行資源調度。

本實施例中，預設的調度算法包括比例平均調度算法、QoS調度算法、最大載干比算法和輪詢調度算法中的任意一種。

其中，輪詢調度算法的基本思想就是認為小區(qū)內所有用戶的調度優(yōu)先級都是相等的，所有用戶周期性地被調度，保證每個用戶被調整概率相同。例如小區(qū)中有3個用戶，采用輪詢算法的調度器不會考慮每個用戶所處的位置以及之前被調度的情況，只是簡單地按照某個固定的調度順序，如用戶1、用戶2、用戶3、用戶1、用戶2、用戶3……周期性地調度每個用戶。因此輪詢算法是一種典型的追求公開最大化的調度算法，實現(xiàn)起來比較簡單。

最大載干比算法的基本思想是在每一個調度時刻，調度器會對所有待調度用戶進行載干比的排序，然后調度器會選擇信道質量最好的用戶進行調度，這樣保證系統(tǒng)總是能夠調度到最好的用戶，保證系統(tǒng)性能的最大化，資源利用率最高?？梢?，最大載干比算法是一種追求系統(tǒng)性能最大化的調度算法，在調度周期內把所有資源仙女湖給信號質量最好的終端，保證系統(tǒng)吞吐量可以達到最大值。

比例公平調度算法在盡量滿足信道質量較好的終端的高速數(shù)據(jù)業(yè)務需求的同時，也兼顧信道質量狀況不好的終端的使用體驗，該算法的基本思想是選擇用戶時考慮瞬時速率和長期平均速率的比值，同時利用權重值對不同用戶進行調整，達到同時兼顧系統(tǒng)性能和用戶體驗的目的。

QoS(Quality of Service，服務質量)調度算法通過控制不同類型的分組對鏈路帶寬的使用，使不同的數(shù)據(jù)流得到不同等級的服務，包括先進先出隊列、嚴格優(yōu)先級調度算法、通用處理器共享算法和加權公平隊列算法等。

預算的調度算法為以上中的任意一個。

S108：根據(jù)調度結果，將調度完成的用戶從業(yè)務隊列中刪除，并放入空閑隊列中。

本實施例中，有調度需求的用戶放入業(yè)務隊列中，并對業(yè)務隊列中的用戶采用預設的調度算法進行資源調度，調度需求完成的用戶放入空閑隊列中。通過采用業(yè)務隊列與空閑隊列分離管理的機制，將有調度需求的用戶和調度需求完成的用戶分離管理，在調度過程中僅需要對業(yè)務隊列中用戶進行檢測，避免檢測在線而又調度完畢的用戶的開銷，大大提升了控制面調度能力。

在另一個實施例中，還包括以下步驟：

步驟1：對空閑隊列中的用戶進行失同步判定。

步驟2：若空閑隊列中的用戶在預設時長內未發(fā)送調度請求，則將用戶從空閑隊列中刪除。

由于業(yè)務隊列中的用戶在完成調度需求后，會從業(yè)務隊列中被刪除，被放入空閑隊列中，因而本實施例的失同步判定只針對空閑隊列的用戶進行。若空間隊列中的用戶在預設時長內未發(fā)送調度請求，則將用戶從空閑隊列中刪除。從而完成失同步判定。并且，由于失同步判定只針對空閑隊列中的用戶，無需對接入的全部用戶進行失同步判定，從而提高了判定效率。

在另一個實施例，步驟S104包括：

當獲取到的調度請求為新用戶的調度請求時，將對應的用戶添加到業(yè)務隊列；或

當獲取到的調度請求為空閑隊列中的用戶的調度請求時，將對應的用戶添加到業(yè)務隊列。

即，調度請求包括新用戶在接入過程中產(chǎn)生的調度請求和已接入的位于空閑隊列中用戶產(chǎn)生的調度請求。

在另一個實施例中，在步驟S102之前，還包括步驟：建立業(yè)務隊列和空閑隊列。

建立的業(yè)務隊列用于放入有調度需求的用戶，空閑隊列用于放入調度需求完成的用戶。

在另一個實施例中，該步驟還可以為：建立上行業(yè)務隊列、上行空閑隊列、下行業(yè)務隊列和下行業(yè)務隊列。

在該實施方式中，上行業(yè)務隊列用于放入上行調度過程中有調度需求的用戶，上行空閑隊列用于放入上行調度過程中調度需求完成的用戶，下行業(yè)務隊列用于放入下行調度過程中有調度需求的用戶，下行空閑隊列用于放入下行調度過程中調度需求完成的用戶。

可以理解的是，在該實施方式中，后續(xù)的調度請求的處理，應當根據(jù)調度請求的類型，例如，是屬于上行調度過程還是下行調度過程的需求，放入對應的隊列中。例如，步驟S104為：根據(jù)調度請求確定調度請求的類型，并將調度請求對應的用戶放入對應的上行業(yè)務隊列或下行業(yè)務隊列中。又例如，步驟S108為：根據(jù)調度結果，將調度完成的用戶從對應的上行業(yè)務隊列或下行業(yè)務隊列中刪除，并放入對應的上行空閑隊列或下行空閑隊列中。又例如，對上行空閑隊列和下行空閑對列中的用戶進行失同步判定，其它的隊列處理類似，在此不再贅述。

本實施通過對上下行調度分別建立空閑隊列和業(yè)務隊列，上行的空閑隊列和上行的業(yè)務隊列管理上行調度過程中的調度請求的用戶，下行的空閑隊列和下行的業(yè)務隊列管理下行調度過程中的調度請求的用戶，從而能夠避免上下行數(shù)據(jù)的相互干擾，并且，上下行調度數(shù)據(jù)分開進行管理，便于對上下行數(shù)據(jù)根據(jù)實際情況進行需要調整，適應性好。

下面，結合具體的實施方式對本發(fā)明的控制面資源調度方法進行詳細說明。

在本實施例中包括三個用戶，依次為用戶0、用戶1、用戶2，用戶失同步時長為(T3-T0)，從圖2中可以看到，假如按照現(xiàn)有技術方案，用戶完成調度之后，就把用戶釋放，則圖2中從T0時刻到T3時刻這段時間，會由于三個用戶反復釋放而后又有調度需求而發(fā)起隨機接入，而導致T0至T3這段時間總共發(fā)生了12次初始接入處理，因此，為了降低隨機接入頻度，降低用戶有頻繁發(fā)送需求導致初始接入壓力過大等問題，現(xiàn)時移動通信網(wǎng)絡中把失同步時間設置為(T3-T0)，此時可以看出，用戶0在T0時刻做初始接入后，在T3時刻之前的另外3次調度請求，則無需做初始接入就能得到調度，有效降低系統(tǒng)初始接入壓力，同樣的，用戶1在T1時刻完成初始接入后，后續(xù)三次調度請求無需做初始接入，用戶2也是后續(xù)在T2時刻完成初始接入后，后續(xù)三次調度請求無需做初始接入，因此，采用拉長用戶的失同步時長判定門限后，圖2中初始接入次數(shù)由原來的12次降低到3次，有效降低用戶有頻繁發(fā)送需求導致初始接入壓力過大等問題。

相應的，由于把用戶的失同步時間判定門限拉長，因此，在T0到T3這段時間，三個用戶都處于同步狀態(tài)，也就是說，每個調度時刻，按照現(xiàn)有技術做法，得檢測3個用戶的調度請求，而后才能確定調度結果，這樣勢必由于沒有實際調度需求而又處于同步狀態(tài)的用戶給調度過程造成檢測的開銷，進而導致調度效率下降，在密集的覆蓋區(qū)域，由于人數(shù)較多，這種影響是難以承受的。

為了解決該問題，本發(fā)明創(chuàng)新性提出了隊列分管方案，即先創(chuàng)建兩個隊列，一個為業(yè)務隊列(對應還沒調度完畢的用戶)，一個為空閑隊列(對應當前已調度完畢的用戶)，T0時刻，用戶0初始接入后，添加到業(yè)務隊列，并完成調度，而后把用戶0移到空閑隊列。T1時刻，用戶1完成初始接入后，添加到業(yè)務隊列，此時雖然用戶0處于同步狀態(tài)，但是由于T0時刻已經(jīng)確定其當前調度需求已調度完畢并移到空閑隊列，因此T1時刻無需去檢測用戶0是否有調度需求，T1時刻只需檢測業(yè)務隊列中僅有的用戶1，就可以實現(xiàn)調度，有效降低無謂的檢測開銷。同樣的，T1時刻完成用戶1的調度需求調度完畢后，調度模塊把用戶1從業(yè)務隊列移到空閑隊列；T2時刻，用戶2完成初始接入后，添加到業(yè)務隊列，此時雖然用戶0、用戶1處于同步狀態(tài)，但是由于用戶0、用戶1當前調度請求已調度完畢而被移到空閑隊列，因此，T2時刻只需檢測業(yè)務隊列中僅有的用戶2，就可以實現(xiàn)調度，有效降低無謂的檢測開銷。依次類推，從而完成后續(xù)各個時刻的調度，當某用戶在空閑隊列中停留的時間大于失同步時長，則直接刪除該用戶。

因此，在拉長用戶失同步時長降低初始接入壓力的應用模式下，采用本發(fā)明的方法，通過引進業(yè)務隊列與空閑隊列分離管理的機制，避免了檢測在線而又調度完畢之用戶狀態(tài)的開銷，大大提升了控制面調度能力，有效適應拉長用戶失同步時長的應用需求。

在一個實施例中，提供一種控制面資源調度裝置，如圖3所示，包括：

獲取模塊302，用于獲取調度請求。

本實施例中的調度請求包括已接入的用戶在其失同步時長內發(fā)送的調度請求和新用戶在接入過程中產(chǎn)生的調度請求。調度請求分為上行調度請求和下行調度請求。

隊列管理模塊304，用于將調度請求對應的用戶放入業(yè)務隊列中。

調度模塊306，用于在對應的調度時刻，采用預設的調度算法，根據(jù)業(yè)務隊列中的用戶進行資源調度。

本實施例中，預設的調度算法包括比例平均調度算法、QoS調度算法、最大載干比算法和輪詢調度算法中的任意一種。

隊列管理模塊，還用于根據(jù)調度結果，將調度完成的用戶從業(yè)務隊列中刪除，并放入空閑隊列中。

本實施例中，有調度需求的用戶放入業(yè)務隊列中，并對業(yè)務隊列中的用戶采用預設的調度算法進行資源調度，調度需求完成的用戶放入空閑隊列中。通過采用業(yè)務隊列與空閑隊列分離管理的機制，將有調度需求的用戶和調度需求完成的用戶分離管理，在調度過程中僅需要對業(yè)務隊列中用戶進行檢測，避免檢測在線而又調度完畢的用戶的開銷，大大提升了控制面調度能力。

在另一個實施例中，如圖4所示，控制面資源調度裝置還包括失同步判定模塊308。

失同步判定模塊308，用于對空閑隊列中的用戶進行失同步判定。

隊列管理模塊304用于在失同步判定模塊判定空閑隊列中的用戶在預設時長內未發(fā)送調度請求時，將用戶從空閑隊列中刪除。

由于業(yè)務隊列中的用戶在完成調度需求后，會從業(yè)務隊列中被刪除，被放入空閑隊列中，因而本實施例的失同步判定只針對空閑隊列的用戶進行。若空間隊列中的用戶在預設時長內未發(fā)送調度請求，則將用戶從空閑隊列中刪除。從而完成失同步判定。并且，由于失同步判定只針對空閑隊列中的用戶，無需對接入的全部用戶進行失同步判定，從而提高了判定效率。

在另一個實施例中，隊列管理模塊304，用于當獲取到的調度請求為新用戶的調度請求時，將對應的用戶添加到業(yè)務隊列；或當獲取到的調度請求為空閑隊列中的用戶的調度請求時，將對應的用戶添加到業(yè)務隊列。

在另一個實施例中，隊列管理模塊304，還用于在獲取模塊獲取調度請求之前，建立業(yè)務隊列和空閑隊列。

建立的業(yè)務隊列用于放入有調度需求的用戶，空閑隊列用于放入調度需求完成的用戶。

在另一個實施例中，隊列管理模塊304，用于建立上行業(yè)務隊列、上行空閑隊列、下行業(yè)務隊列和下行業(yè)務隊列。

在該實施方式中，上行業(yè)務隊列用于放入上行調度過程中有調度需求的用戶，上行空閑隊列用于放入上行調度過程中調度需求完成的用戶，下行業(yè)務隊列用于放入下行調度過程中有調度需求的用戶，下行空閑隊列用于放入下行調度過程中調度需求完成的用戶。

可以理解的是，在該實施方式中，后續(xù)的調度請求的處理，應當根據(jù)調度請求的類型，例如，是屬于上行調度過程還是下行調度過程的需求，放入對應的隊列中。例如，隊列管理模塊304用于根據(jù)調度請求確定調度請求的類型，并將調度請求對應的用戶放入對應的上行業(yè)務隊列或下行業(yè)務隊列中。又例如，隊列管理模塊304根據(jù)調度結果，將調度完成的用戶從對應的上行業(yè)務隊列或下行業(yè)務隊列中刪除，并放入對應的上行空閑隊列或下行空閑隊列中。又例如，對上行空閑隊列和下行空閑對列中的用戶進行失同步判定，其它的隊列處理類似，在此不再贅述。

本實施通過對上下行調度分別建立空閑隊列和業(yè)務隊列，上行的空閑隊列和上行的業(yè)務隊列管理上行調度過程中的調度請求的用戶，下行的空閑隊列和下行的業(yè)務隊列管理下行調度過程中的調度請求的用戶，從而能夠避免上下行數(shù)據(jù)的相互干擾，并且，上下行調度數(shù)據(jù)分開進行管理，便于對上下行數(shù)據(jù)根據(jù)實際情況進行需要調整，適應性好。

以上所述實施例的各技術特征可以進行任意的組合，為使描述簡潔，未對上述實施例中的各個技術特征所有可能的組合都進行描述，然而，只要這些技術特征的組合不存在矛盾，都應當認為是本說明書記載的范圍。

以上所述實施例僅表達了本發(fā)明的幾種實施方式，其描述較為具體和詳細，但并不能因此而理解為對發(fā)明專利范圍的限制。應當指出的是，對于本領域的普通技術人員來說，在不脫離本發(fā)明構思的前提下，還可以做出若干變形和改進，這些都屬于本發(fā)明的保護范圍。因此，本發(fā)明專利的保護范圍應以所附權利要求為準。