專利名稱：業(yè)務(wù)網(wǎng)絡(luò)內(nèi)提供端到端服務(wù)質(zhì)量保證的裝置和方法
技術(shù)領(lǐng)域：
本發(fā)明涉及網(wǎng)絡(luò)通訊領(lǐng)域，尤其涉及一種業(yè)務(wù)網(wǎng)絡(luò)內(nèi)提供端到端服務(wù)質(zhì)量保證的裝置和方法。
背景技術(shù)：
隨著電信網(wǎng)絡(luò)技術(shù)和用戶需求的不斷發(fā)展，各種單一的網(wǎng)絡(luò)運(yùn)營(yíng)商正在向綜合信息提供商轉(zhuǎn)變，向用戶提供的業(yè)務(wù)由傳統(tǒng)的語(yǔ)言業(yè)務(wù)為主向豐富多彩的多媒體業(yè)務(wù)和數(shù)據(jù)業(yè)務(wù)發(fā)展，比如，向用戶提供MMS(multi-mediamessage service，多媒體信息業(yè)務(wù))、新聞、視頻電話、互動(dòng)消息、游戲、音樂、娛樂和位置服務(wù)等。這些多媒體業(yè)務(wù)和數(shù)據(jù)業(yè)務(wù)吸引了更多的用戶，給運(yùn)營(yíng)商帶來(lái)了更多的網(wǎng)絡(luò)業(yè)務(wù)流量和營(yíng)業(yè)收入，同時(shí)這些豐富多彩的多媒體業(yè)務(wù)和數(shù)據(jù)業(yè)務(wù)構(gòu)成了一個(gè)新的疊加網(wǎng)絡(luò)-業(yè)務(wù)網(wǎng)絡(luò)。
隨著各種豐富多彩的業(yè)務(wù)的不斷涌現(xiàn)及用戶各種需求的不斷增加，未來(lái)的電信網(wǎng)絡(luò)將是以用戶為中心的，滿足用戶對(duì)業(yè)務(wù)的性能要求是至關(guān)重要的，直接關(guān)系到用戶對(duì)網(wǎng)絡(luò)運(yùn)營(yíng)商的滿意度和忠誠(chéng)度。
相對(duì)傳統(tǒng)的語(yǔ)言業(yè)務(wù)等電信業(yè)務(wù)，上述多媒體業(yè)務(wù)和數(shù)據(jù)業(yè)務(wù)的種類和復(fù)雜度也在不但增大，具有更復(fù)雜的業(yè)務(wù)邏輯，一個(gè)用戶業(yè)務(wù)可能需要業(yè)務(wù)網(wǎng)內(nèi)多個(gè)業(yè)務(wù)服務(wù)器的共同協(xié)調(diào)才能完成，如現(xiàn)在熱門的組合業(yè)務(wù)、業(yè)務(wù)鏈等都需要業(yè)務(wù)網(wǎng)內(nèi)多個(gè)應(yīng)用服務(wù)器的協(xié)作才能滿足用戶需求。
因而，如何在上述情況下保證用戶仍然能夠獲得良好的業(yè)務(wù)體驗(yàn)已經(jīng)成為網(wǎng)絡(luò)運(yùn)營(yíng)商一個(gè)亟待解決的問題。
現(xiàn)有技術(shù)中一種在業(yè)務(wù)網(wǎng)絡(luò)內(nèi)對(duì)用戶業(yè)務(wù)提供QoS(服務(wù)質(zhì)量)保證的方法為采用網(wǎng)絡(luò)準(zhǔn)入系統(tǒng)的解決方案。該方案的架構(gòu)如圖1所示，該方案在網(wǎng)絡(luò)的邊緣節(jié)點(diǎn)上部署一個(gè)或多個(gè)NAC(Network admission control，網(wǎng)絡(luò)準(zhǔn)入控制設(shè)備)，在核心網(wǎng)絡(luò)上部署一個(gè)或多個(gè)NCS(Network controlserver，網(wǎng)絡(luò)控制服務(wù)器)，根據(jù)當(dāng)前網(wǎng)絡(luò)的資源使用情況、負(fù)載率及請(qǐng)求的數(shù)據(jù)流所需要的QoS保證決定是否允許該數(shù)據(jù)流通過(guò)本網(wǎng)絡(luò)，該技術(shù)主要用于避免出現(xiàn)資源瓶頸，保證具有QoS要求的數(shù)據(jù)傳輸。
上述現(xiàn)有技術(shù)的方法的缺點(diǎn)為1、該方法是針對(duì)單一類型的應(yīng)用服務(wù)器，監(jiān)控的資源均為統(tǒng)一的同質(zhì)的資源。而各個(gè)異構(gòu)型應(yīng)用服務(wù)器所包含的資源各不相同，該方法不能同時(shí)為各種不同的異構(gòu)型應(yīng)用服務(wù)器提供資源監(jiān)控和準(zhǔn)入控制。因此，該方法不具備可擴(kuò)展性，不適用于整個(gè)業(yè)務(wù)網(wǎng)絡(luò)。
2.該方法無(wú)法根據(jù)請(qǐng)求的數(shù)據(jù)流的特點(diǎn)動(dòng)態(tài)選擇、檢測(cè)所需的應(yīng)用服務(wù)器。

發(fā)明內(nèi)容
本發(fā)明的目的是提供一種業(yè)務(wù)網(wǎng)絡(luò)內(nèi)提供端到端服務(wù)質(zhì)量保證的裝置和方法，從而可以保證業(yè)務(wù)網(wǎng)絡(luò)內(nèi)端到端的業(yè)務(wù)QoS，提高業(yè)務(wù)網(wǎng)絡(luò)內(nèi)應(yīng)用服務(wù)器的使用效率。
本發(fā)明的目的是通過(guò)以下技術(shù)方案實(shí)現(xiàn)的一種業(yè)務(wù)網(wǎng)絡(luò)內(nèi)提供端到端服務(wù)質(zhì)量保證的裝置，該裝置通過(guò)資源監(jiān)控管理器SRM來(lái)實(shí)現(xiàn)，所述SRM包括業(yè)務(wù)處理單元、資源管理單元和業(yè)務(wù)接口單元，其中，業(yè)務(wù)接口單元為用戶業(yè)務(wù)提供接口，通過(guò)所述接口接收應(yīng)用服務(wù)器傳遞過(guò)來(lái)的服務(wù)請(qǐng)求，將接收到的服務(wù)請(qǐng)求傳遞給業(yè)務(wù)處理單元；通過(guò)所述接口將業(yè)務(wù)處理單元針對(duì)所述用戶業(yè)務(wù)產(chǎn)生的處理計(jì)劃傳遞給請(qǐng)求的應(yīng)用服務(wù)器；資源管理單元監(jiān)控和管理業(yè)務(wù)網(wǎng)絡(luò)內(nèi)應(yīng)用服務(wù)器的資源使用情況；根據(jù)業(yè)務(wù)處理單元發(fā)送過(guò)來(lái)的查詢請(qǐng)求，向業(yè)務(wù)處理單元返回相應(yīng)的應(yīng)用服務(wù)器的資源使用情況信息；業(yè)務(wù)處理單元根據(jù)業(yè)務(wù)接口單元傳遞過(guò)來(lái)的服務(wù)請(qǐng)求中攜帶的用戶業(yè)務(wù)所要求的服務(wù)質(zhì)量QoS要求信息，向資源管理單元發(fā)送查詢請(qǐng)求，接收資源管理單元返回的相應(yīng)的應(yīng)用服務(wù)器的資源使用情況信息，針對(duì)所述用戶業(yè)務(wù)產(chǎn)生處理計(jì)劃，將該具體處理計(jì)劃傳遞給業(yè)務(wù)接口單元。
還包括策略管理單元針對(duì)用戶業(yè)務(wù)提供具體的控制策略，將該控制策略傳遞給業(yè)務(wù)處理單元；業(yè)務(wù)處理單元利用該控制策略產(chǎn)生針對(duì)所述用戶業(yè)務(wù)的處理計(jì)劃。
所述的資源管理單元具體包括資源監(jiān)控單元用于通過(guò)主動(dòng)查詢或者應(yīng)用服務(wù)器主動(dòng)上報(bào)的方式監(jiān)控所管轄的應(yīng)用服務(wù)器的資源使用情況；并根據(jù)業(yè)務(wù)處理單元產(chǎn)生的針對(duì)所述用戶業(yè)務(wù)的處理計(jì)劃修改相關(guān)應(yīng)用服務(wù)器的可用資源參數(shù)；資源交互單元提供SRM之間的交互接口，通過(guò)該交互接口SRM向其他SRM發(fā)送查詢請(qǐng)求，查詢其他SRM所管轄的應(yīng)用服務(wù)器資源使用情況；接收其他SRM發(fā)送過(guò)來(lái)的查詢請(qǐng)求，將本SRM所管轄的應(yīng)用服務(wù)器資源使用情況返回給所述請(qǐng)求的其他SRM。
所述的SRM采用分布式的方式或者集中式的方式或者混合式的方式部署在業(yè)務(wù)網(wǎng)絡(luò)中。
一種業(yè)務(wù)網(wǎng)絡(luò)內(nèi)提供端到端服務(wù)質(zhì)量保證的方法，包括步驟
SRM接收到用戶業(yè)務(wù)的服務(wù)請(qǐng)求，所述SRM根據(jù)所監(jiān)控到的應(yīng)用服務(wù)器的資源使用情況和所述用戶業(yè)務(wù)的QoS要求對(duì)所述用戶業(yè)務(wù)進(jìn)行處理，將處理結(jié)果返回給所述服務(wù)請(qǐng)求的發(fā)送方。
具體包括A1、應(yīng)用服務(wù)器向SRM發(fā)送服務(wù)請(qǐng)求，該服務(wù)請(qǐng)求中攜帶用戶業(yè)務(wù)所要求的QoS參數(shù)信息和應(yīng)用服務(wù)器類型信息；A2、SRM根據(jù)所述用戶業(yè)務(wù)所要求的應(yīng)用服務(wù)器類型信息，在其所監(jiān)控到的應(yīng)用服務(wù)器的資源使用情況中進(jìn)行查詢；和/或，與其它SRM進(jìn)行交互，獲得相應(yīng)的應(yīng)用服務(wù)器的地址和當(dāng)前資源使用情況信息；A3、SRM根據(jù)所述用戶業(yè)務(wù)所要求的QoS參數(shù)信息、獲取的相應(yīng)的應(yīng)用服務(wù)器的地址和當(dāng)前資源使用情況信息以及設(shè)定的控制策略信息，產(chǎn)生針對(duì)所述用戶業(yè)務(wù)的處理計(jì)劃，將該處理計(jì)劃傳遞給所述請(qǐng)求的應(yīng)用服務(wù)器。
所述的處理計(jì)劃包括拒絕所述用戶業(yè)務(wù)的服務(wù)請(qǐng)求；或者，給所述用戶業(yè)務(wù)提供服務(wù)的應(yīng)用服務(wù)器列表和地址信息。
所述的控制策略包括在滿足用戶業(yè)務(wù)的QoS要求下選擇當(dāng)前響應(yīng)時(shí)間最小的應(yīng)用服務(wù)器；和/或，在滿足用戶業(yè)務(wù)的QoS要求下選取當(dāng)前負(fù)載率最低的應(yīng)用服務(wù)器；和/或，在滿足用戶業(yè)務(wù)的QoS要求下隨機(jī)選取應(yīng)用服務(wù)器；和/或，在滿足用戶業(yè)務(wù)的QoS要求下選取參數(shù)值與用戶業(yè)務(wù)要求的QoS參數(shù)值之間差值最小的應(yīng)用服務(wù)器。
所述的服務(wù)請(qǐng)求的發(fā)送方為應(yīng)用服務(wù)器或用戶。
還包括
在業(yè)務(wù)網(wǎng)絡(luò)內(nèi)設(shè)置SRM，使用所述SRM監(jiān)控業(yè)務(wù)網(wǎng)絡(luò)內(nèi)應(yīng)用服務(wù)器的資源使用情況。
所述的應(yīng)用服務(wù)器的資源使用情況包括應(yīng)用服務(wù)器的QoS參數(shù)信息，該QoS參數(shù)信息包括應(yīng)用服務(wù)器的負(fù)載率、響應(yīng)時(shí)間、帶寬、碼率和/或顯示分辨率信息。
還包括在SRM中維護(hù)一個(gè)資源狀態(tài)列表，該資源狀態(tài)列表中包括應(yīng)用服務(wù)器的標(biāo)識(shí)、應(yīng)用服務(wù)器的地址和該應(yīng)用服務(wù)器的QoS參數(shù)信息。
所述的資源狀態(tài)列表在SRM中采用可擴(kuò)展標(biāo)記語(yǔ)言XML格式存儲(chǔ)。
由上述本發(fā)明提供的技術(shù)方案可以看出，本發(fā)明通過(guò)在業(yè)務(wù)網(wǎng)絡(luò)中設(shè)置SRM(Service resource monitor/management，資源監(jiān)控管理器)，SRM動(dòng)態(tài)監(jiān)控業(yè)務(wù)網(wǎng)絡(luò)內(nèi)應(yīng)用服務(wù)器的資源使用情況，并動(dòng)態(tài)作出具體的業(yè)務(wù)處理計(jì)劃。從而可以保證業(yè)務(wù)網(wǎng)絡(luò)內(nèi)端到端的業(yè)務(wù)QoS，提高業(yè)務(wù)網(wǎng)絡(luò)內(nèi)應(yīng)用服務(wù)器的使用效率，可以最大限定的保障用戶的業(yè)務(wù)使用及體驗(yàn)，優(yōu)化整個(gè)業(yè)務(wù)網(wǎng)路內(nèi)的資源使用率。解決現(xiàn)有技術(shù)無(wú)法針對(duì)業(yè)務(wù)的特點(diǎn)進(jìn)行異構(gòu)性的QoS保障及無(wú)法動(dòng)態(tài)選擇、檢測(cè)所需的應(yīng)用服務(wù)器的缺點(diǎn)。


圖1為現(xiàn)有技術(shù)中采用網(wǎng)絡(luò)準(zhǔn)入系統(tǒng)的解決方案的架構(gòu)示意圖；圖2為SRM采用分布式的方式部署時(shí)的網(wǎng)絡(luò)的體系架構(gòu)示意圖；圖3為本方法所述SRM的功能架構(gòu)示意圖。
具體實(shí)施例方式
本發(fā)明提供了一種業(yè)務(wù)網(wǎng)絡(luò)內(nèi)提供端到端服務(wù)質(zhì)量保證的裝置和方法，本發(fā)明的核心為在業(yè)務(wù)網(wǎng)絡(luò)中設(shè)置SRM，SRM動(dòng)態(tài)監(jiān)控業(yè)務(wù)網(wǎng)絡(luò)內(nèi)應(yīng)用服務(wù)器的資源使用情況，并根據(jù)獲得的資源使用情況、控制策略以及用戶業(yè)務(wù)的QoS要求動(dòng)態(tài)作出具體的業(yè)務(wù)處理計(jì)劃。
下面先結(jié)合附圖來(lái)詳細(xì)描述本發(fā)明所述裝置，本方法所述裝置通過(guò)SRM來(lái)實(shí)現(xiàn)。
SRM作為一個(gè)資源管理裝置動(dòng)態(tài)監(jiān)控和管理業(yè)務(wù)網(wǎng)絡(luò)內(nèi)應(yīng)用服務(wù)器的資源使用情況，該資源使用情況包括應(yīng)用服務(wù)器的QoS參數(shù)信息、應(yīng)用服務(wù)器之間的傳輸延遲，應(yīng)用服務(wù)器提供的媒體資源等，該QoS參數(shù)信息包括應(yīng)用服務(wù)器的負(fù)載率、響應(yīng)時(shí)間、帶寬信息、碼率和顯示分辨率信息等。每種應(yīng)用服務(wù)器對(duì)應(yīng)的QoS參數(shù)是不一樣的，有的可能是負(fù)載率、帶寬，有的可能是碼率、顯示分辨率，有的可能是帶寬、顯示負(fù)載率。
SRM根據(jù)所述用戶業(yè)務(wù)所要求的QoS參數(shù)信息、獲取的應(yīng)用服務(wù)器的資源使用情況以及控制策略信息，產(chǎn)生針對(duì)所述用戶業(yè)務(wù)的處理計(jì)劃，將該處理計(jì)劃傳遞給所述請(qǐng)求的應(yīng)用服務(wù)器。
SRM可以采用集中式的方式或者采用分部式的方式或者是采用混合的方式部署在業(yè)務(wù)網(wǎng)絡(luò)中。在采用集中式的方式部署時(shí)，一個(gè)SRM需要監(jiān)控整個(gè)業(yè)務(wù)網(wǎng)絡(luò)內(nèi)部所有的應(yīng)用服務(wù)器的資源使用情況。采用分部或混合的方式部署時(shí)，可能需要多個(gè)SRM來(lái)監(jiān)控業(yè)務(wù)網(wǎng)絡(luò)內(nèi)部的資源使用情況，其中每個(gè)SRM可能監(jiān)控一個(gè)或多個(gè)應(yīng)用服務(wù)器的資源使用，SRM與SRM之間存在通訊接口。SRM采用分布式的方式部署時(shí)，網(wǎng)絡(luò)的體系架構(gòu)如圖2所示，AS為應(yīng)用服務(wù)器。
如圖2所示，最下層為基本的網(wǎng)絡(luò)層，用于保證應(yīng)用服務(wù)器與應(yīng)用服務(wù)器、應(yīng)用服務(wù)器與SRM、SRM與SRM之間的通訊，可能包含多個(gè)路由器和物理鏈路，用于處理具體的用戶業(yè)務(wù)，給用戶業(yè)務(wù)提供應(yīng)用服務(wù)。基本的網(wǎng)絡(luò)層的上面為業(yè)務(wù)網(wǎng)絡(luò)，在業(yè)務(wù)網(wǎng)絡(luò)中，需要多個(gè)應(yīng)用服務(wù)器協(xié)同工作才能處理一個(gè)用戶業(yè)務(wù)的服務(wù)請(qǐng)求。
SRM與應(yīng)用服務(wù)器之間可以是一對(duì)一，也可以是一對(duì)多的關(guān)系，SRM與SRM之間需要相互進(jìn)行通訊從而在整個(gè)業(yè)務(wù)網(wǎng)絡(luò)內(nèi)提供端到端的QoS保證。
上述SRM的功能架構(gòu)圖如圖3所示，包括業(yè)務(wù)接口單元、資源監(jiān)控單元、資源交互單元、業(yè)務(wù)處理單元和策略管理單元等模塊。
上述SRM的中的各個(gè)模塊的功能描述如下業(yè)務(wù)接口單元為用戶業(yè)務(wù)提供查詢和響應(yīng)接口，通過(guò)所述查詢接口接收從應(yīng)用服務(wù)器傳來(lái)的服務(wù)請(qǐng)求，將接收到的服務(wù)請(qǐng)求傳遞給業(yè)務(wù)處理單元。該服務(wù)請(qǐng)求包括用戶業(yè)務(wù)所要求的QoS參數(shù)值、QoS參數(shù)名及相關(guān)要求、需要的應(yīng)用服務(wù)器的標(biāo)識(shí)符及數(shù)目等信息。其中QoS參數(shù)要求包括但不限于整個(gè)業(yè)務(wù)的響應(yīng)時(shí)間、所需要的帶寬等。業(yè)務(wù)接口單元還通過(guò)所述響應(yīng)接口將業(yè)務(wù)處理單元針對(duì)所述用戶業(yè)務(wù)產(chǎn)生的具體處理計(jì)劃下發(fā)到所述發(fā)送服務(wù)請(qǐng)求的應(yīng)用服務(wù)器，該具體處理計(jì)劃中包含給用戶業(yè)務(wù)提供服務(wù)的應(yīng)用服務(wù)器列表和地址信息，或者，拒絕所述用戶業(yè)務(wù)的服務(wù)請(qǐng)求信息。
資源監(jiān)控單元用于監(jiān)控和管理所管轄的應(yīng)用服務(wù)器的資源使用情況，資源監(jiān)控單元主動(dòng)查詢相關(guān)應(yīng)用服務(wù)器的資源使用情況(也可以是各應(yīng)用服務(wù)器主動(dòng)向資源監(jiān)控單元上報(bào)當(dāng)前的資源使用情況)，將獲取的應(yīng)用服務(wù)器的資源使用情況進(jìn)行保存，并傳遞給業(yè)務(wù)處理單元。在資源監(jiān)控單元中應(yīng)維護(hù)一張資源狀態(tài)列表，該資源狀態(tài)列表中包括應(yīng)用服務(wù)器ID、應(yīng)用服務(wù)器的地址及該應(yīng)用服務(wù)器所提供的各種QoS參數(shù)，這些QoS參數(shù)包含但不限于應(yīng)用服務(wù)器的當(dāng)前響應(yīng)時(shí)間、當(dāng)前負(fù)載率和當(dāng)前可用帶寬等信息。由于各種應(yīng)用服務(wù)器所涉及的QoS參數(shù)各不相同，很難用數(shù)據(jù)庫(kù)進(jìn)行統(tǒng)一的建模，因此，上述資源狀態(tài)列表在資源監(jiān)控單元中采用XML(可擴(kuò)展標(biāo)記語(yǔ)言)格式存儲(chǔ)。并根據(jù)業(yè)務(wù)處理單元模塊傳遞過(guò)來(lái)的策略決定修改相關(guān)應(yīng)用服務(wù)器的可用資源參數(shù)。
描述上述資源狀態(tài)列表的XML文件的格式可以如下所示<服務(wù)列表>
<服務(wù)標(biāo)識(shí)＝“服務(wù)1”地址＝“地址1”>
<資源標(biāo)識(shí)＝“資源1”>當(dāng)前值1</資源>
<資源標(biāo)識(shí)＝“資源2”>當(dāng)前值2</資源>
</服務(wù)>
<服務(wù)標(biāo)識(shí)＝“服務(wù)2”地址＝“地址2”>
<資源標(biāo)識(shí)＝“資源2”>當(dāng)前值3</資源>
<資源標(biāo)識(shí)＝“資源3”>當(dāng)前值4</資源>
</服務(wù)>
</服務(wù)列表>
該XML文件對(duì)應(yīng)的Schema為<？XML version＝”1.0”？>
<Schema name＝”Resource monitor”xmlns＝”http://www.w3.org/2001/XMLSchema”>
<element name＝”resourceList”>
<complexType>
<element name＝”service”maxOccurs＝”unbounded”>
<complexType>
<element name＝”resource”type＝”string”maxOccurs＝”unbounded”>
<attribute name＝″id″type＝″string″>
</element>
</complexType>
</element>
</complexType>
</element>
</Schema>
資源交互單元用于提供SRM之間的交互接口，通過(guò)該交互接口SRM可以向其他SRM發(fā)送資源查詢請(qǐng)求，查詢其他SRM所管轄的應(yīng)用服務(wù)器資源使用情況。所述對(duì)其他SRM發(fā)出的資源查詢請(qǐng)求包括應(yīng)用服務(wù)器類型及用戶業(yè)務(wù)要求的QoS參數(shù)。
通過(guò)該交互接口SRM也可以接收其他SRM發(fā)送過(guò)來(lái)的資源查詢請(qǐng)求，并返回響應(yīng)信息。在響應(yīng)其它SRM的查詢請(qǐng)求時(shí)，需要與資源監(jiān)控單元進(jìn)行交互取得相關(guān)應(yīng)用服務(wù)器的資源使用狀態(tài)。所述返回的響應(yīng)信息包括應(yīng)用服務(wù)器的標(biāo)識(shí)、地址及當(dāng)前資源的使用情況(如當(dāng)前響應(yīng)時(shí)間等)。
需要說(shuō)明的是一個(gè)用戶業(yè)務(wù)所要求的應(yīng)用服務(wù)器可能并不在本SRM所管理的范圍內(nèi)，而在其他SRM所管轄的范圍內(nèi)，所以需要各個(gè)SRM之間進(jìn)行通訊交互從而達(dá)到端到端的QoS保證。
業(yè)務(wù)處理單元是SRM的主控模塊，進(jìn)行具體的用戶業(yè)務(wù)處理。它根據(jù)業(yè)務(wù)接口單元發(fā)送過(guò)來(lái)的服務(wù)請(qǐng)求中攜帶的用戶業(yè)務(wù)所要求的應(yīng)用服務(wù)器類型及當(dāng)前SRM所監(jiān)控的應(yīng)用服務(wù)器種類分別向資源交互單元和/或資源監(jiān)控單元進(jìn)行相關(guān)查詢。
根據(jù)策略管理單元傳遞過(guò)來(lái)的當(dāng)前策略、從資源交互單元和/或資源監(jiān)控單元返回的當(dāng)前各應(yīng)用服務(wù)器的資源可用情況及所述用戶業(yè)務(wù)所要求的QoS參數(shù)信息作出具體的業(yè)務(wù)處理計(jì)劃，然后將制定出的處理計(jì)劃通過(guò)業(yè)務(wù)接口單元傳遞給所述發(fā)送服務(wù)請(qǐng)求的應(yīng)用服務(wù)器。其中，具體的業(yè)務(wù)處理計(jì)劃可能是拒絕所述服務(wù)請(qǐng)求，也可能是滿足所述服務(wù)請(qǐng)求所要求的具體的應(yīng)用服務(wù)器列表和地址信息。
策略管理單元對(duì)用戶業(yè)務(wù)提供具體的控制策略及對(duì)應(yīng)算法，將該控制策略及對(duì)應(yīng)算法傳遞給業(yè)務(wù)處理單元。具體的控制策略包括但不限于1、在滿足用戶業(yè)務(wù)QoS要求下選擇當(dāng)前響應(yīng)時(shí)間最小的應(yīng)用服務(wù)器。
2、在滿足用戶業(yè)務(wù)QoS要求下選取當(dāng)前負(fù)載率最低的應(yīng)用服務(wù)器。
3、在滿足用戶業(yè)務(wù)QoS條件下隨機(jī)選取適當(dāng)?shù)膽?yīng)用服務(wù)器。
4、在滿足用戶業(yè)務(wù)QoS要求下選取參數(shù)值最相近于用戶業(yè)務(wù)的QoS參數(shù)值的應(yīng)用服務(wù)器等。
基于上述裝置，本發(fā)明所述方法的實(shí)施例的處理流程包括如下步驟步驟1應(yīng)用服務(wù)器通過(guò)業(yè)務(wù)接口單元向該應(yīng)用服務(wù)器所屬的SRM發(fā)送服務(wù)請(qǐng)求，該服務(wù)請(qǐng)求中攜帶用戶業(yè)務(wù)所要求的應(yīng)用服務(wù)器類型和QoS參數(shù)信息。
步驟2所述SRM中的業(yè)務(wù)處理單元獲取接收到的所述服務(wù)請(qǐng)求中攜帶的用戶業(yè)務(wù)所要求的應(yīng)用服務(wù)器類型和QoS參數(shù)信息。
當(dāng)所述用戶業(yè)務(wù)所要求的應(yīng)用服務(wù)器類型均在所述SRM中的資源監(jiān)控單元中保存時(shí)，則所述SRM中的業(yè)務(wù)處理單元向該SRM中的資源監(jiān)控單元發(fā)送查詢請(qǐng)求，查詢相應(yīng)的應(yīng)用服務(wù)器的資源使用情況信息。資源監(jiān)控單元根據(jù)發(fā)送過(guò)來(lái)的查詢請(qǐng)求獲取用戶業(yè)務(wù)所要求的應(yīng)用服務(wù)器地址及當(dāng)前資源使用情況(如當(dāng)前響應(yīng)時(shí)間)信息，并將所獲取的應(yīng)用服務(wù)器地址及當(dāng)前資源使用情況信息返回給業(yè)務(wù)處理單元。
當(dāng)所述用戶業(yè)務(wù)所要求的應(yīng)用服務(wù)器類型均在其他SRM管轄的范圍內(nèi)時(shí)，則所述SRM中的業(yè)務(wù)處理單元向資源交互單元發(fā)送上述查詢請(qǐng)求，資源交互單元與所述其他SRM進(jìn)行交互，將接收到的上述查詢請(qǐng)求轉(zhuǎn)交給所述其他SRM，并且接收所述其它SRM返回的用戶業(yè)務(wù)所要求的應(yīng)用服務(wù)器地址及當(dāng)前資源使用情況信息，將接收到的應(yīng)用服務(wù)器地址及當(dāng)前資源使用情況信息返回給業(yè)務(wù)處理單元。
當(dāng)所述用戶業(yè)務(wù)所要求的應(yīng)用服務(wù)器類型同時(shí)在所述SRM的資源監(jiān)控單元和其他SRM管轄的范圍內(nèi)時(shí)，則業(yè)務(wù)處理單元同時(shí)向資源交互單元和資源監(jiān)控單元發(fā)送上述查詢請(qǐng)求，接收資源交互單元和資源監(jiān)控單元返回的用戶業(yè)務(wù)所要求的應(yīng)用服務(wù)器地址及當(dāng)前資源使用情況信息。
步驟3、業(yè)務(wù)處理單元根據(jù)所述資源交互單元和/或資源監(jiān)控單元返回的用戶業(yè)務(wù)所要求的應(yīng)用服務(wù)器地址及當(dāng)前資源使用情況信息，以及策略管理單元傳遞過(guò)來(lái)的當(dāng)前控制策略和該用戶業(yè)務(wù)所要求的QoS參數(shù)信息作出具體的業(yè)務(wù)處理計(jì)劃，然后將制定出的處理計(jì)劃通過(guò)業(yè)務(wù)接口單元傳遞給上述發(fā)送服務(wù)請(qǐng)求的應(yīng)用服務(wù)器。其中，如果不能滿足用戶業(yè)務(wù)的QoS要求，則具體的業(yè)務(wù)處理計(jì)劃是拒絕該用戶業(yè)務(wù)的服務(wù)請(qǐng)求；否則，具體的業(yè)務(wù)處理計(jì)劃中包括給所述用戶業(yè)務(wù)提供服務(wù)的應(yīng)用服務(wù)器列表和地址信息。
所述SRM的資源監(jiān)控單元根據(jù)上述獲得的應(yīng)用服務(wù)器地址及當(dāng)前資源信息對(duì)相關(guān)應(yīng)用服務(wù)器的相關(guān)資源參數(shù)進(jìn)行修改。
上述本發(fā)明所述方法的一個(gè)應(yīng)用場(chǎng)景如下用戶通過(guò)發(fā)送一個(gè)短信選擇所要看的電影，在這個(gè)應(yīng)用場(chǎng)景中，短信服務(wù)器處理用戶發(fā)送的短信，然后將相關(guān)信息轉(zhuǎn)發(fā)給電影服務(wù)器，電影服務(wù)器根據(jù)收到的信息播放相關(guān)電影給用戶。
當(dāng)前分別有短信服務(wù)器1、短信服務(wù)器2和短信服務(wù)器3，上述三個(gè)短信服務(wù)器由SRM1進(jìn)行管理，各個(gè)短信服務(wù)器當(dāng)前的資源使用情況分別為服務(wù)器1延遲＝0.5ms，負(fù)載率＝50％；服務(wù)器2延遲＝1ms，負(fù)載率＝30％；服務(wù)器3延遲＝2ms，負(fù)載率＝70％。
當(dāng)前分別有電影服務(wù)器1、電影服務(wù)器2，上述兩個(gè)電影服務(wù)器由SRM2進(jìn)行管理，各個(gè)電影服務(wù)器當(dāng)前的資源使用情況分別為電影服務(wù)器1延遲＝3ms，負(fù)載率＝50％，帶寬＝20K，電影服務(wù)器2延遲＝4ms，負(fù)載率＝40％，帶寬＝40K。當(dāng)前控制策略為在滿足業(yè)務(wù)QoS要求下選擇當(dāng)前響應(yīng)時(shí)間最小的應(yīng)用服務(wù)器。
SRM1收到服務(wù)請(qǐng)求，該服務(wù)請(qǐng)求中攜帶用戶業(yè)務(wù)對(duì)短信服務(wù)器和電影服務(wù)器的需求及用戶業(yè)務(wù)的服務(wù)質(zhì)量要求信息，具體為總的延遲＜5.5ms，電影服務(wù)器的帶寬＞30K。SRM1根據(jù)上述用戶業(yè)務(wù)的服務(wù)質(zhì)量要求，查詢資源監(jiān)控單元，資源監(jiān)控單元返回短信服務(wù)器1、短信服務(wù)器2的當(dāng)前資源使用情況信息。SRM1還向SRM2發(fā)送攜帶上述用戶業(yè)務(wù)的服務(wù)質(zhì)量要求信息的查詢請(qǐng)求，SRM2向SRM1返回符合上述用戶業(yè)務(wù)的服務(wù)質(zhì)量要求(帶寬＞30K)的電影服務(wù)器2的當(dāng)前資源使用情況信息。
SRM1根據(jù)上述短信服務(wù)器1、短信服務(wù)器2和SRM2返回的信息，確定當(dāng)前滿足上述用戶業(yè)務(wù)的服務(wù)質(zhì)量要求的短信服務(wù)器、電影服務(wù)器組合為短信服務(wù)器1，電影服務(wù)器2短信服務(wù)器2，電影服務(wù)器2SRM1又根據(jù)上述當(dāng)前控制策略，即選擇當(dāng)前響應(yīng)時(shí)間最小的應(yīng)用服務(wù)器，選取短信服務(wù)器1和電影服務(wù)器2為該用戶業(yè)務(wù)服務(wù)，并將短信服務(wù)器1和電影服務(wù)器2的相關(guān)信息返回給該請(qǐng)求者。
以上所述，僅為本發(fā)明較佳的具體實(shí)施方式
，但本發(fā)明的保護(hù)范圍并不局限于此，任何熟悉本技術(shù)領(lǐng)域的技術(shù)人員在本發(fā)明揭露的技術(shù)范圍內(nèi)，可輕易想到的變化或替換，都應(yīng)涵蓋在本發(fā)明的保護(hù)范圍之內(nèi)。因此，本發(fā)明的保護(hù)范圍應(yīng)該以權(quán)利要求的保護(hù)范圍為準(zhǔn)。
權(quán)利要求
1.一種業(yè)務(wù)網(wǎng)絡(luò)內(nèi)提供端到端服務(wù)質(zhì)量保證的裝置，其特征在于，該裝置通過(guò)資源監(jiān)控管理器SRM來(lái)實(shí)現(xiàn)，所述SRM包括業(yè)務(wù)處理單元、資源管理單元和業(yè)務(wù)接口單元，其中，業(yè)務(wù)接口單元為用戶業(yè)務(wù)提供接口，通過(guò)所述接口接收應(yīng)用服務(wù)器傳遞過(guò)來(lái)的服務(wù)請(qǐng)求，將接收到的服務(wù)請(qǐng)求傳遞給業(yè)務(wù)處理單元；通過(guò)所述接口將業(yè)務(wù)處理單元針對(duì)所述用戶業(yè)務(wù)產(chǎn)生的處理計(jì)劃傳遞給請(qǐng)求的應(yīng)用服務(wù)器；資源管理單元監(jiān)控和管理業(yè)務(wù)網(wǎng)絡(luò)內(nèi)應(yīng)用服務(wù)器的資源使用情況；根據(jù)業(yè)務(wù)處理單元發(fā)送過(guò)來(lái)的查詢請(qǐng)求，向業(yè)務(wù)處理單元返回相應(yīng)的應(yīng)用服務(wù)器的資源使用情況信息；業(yè)務(wù)處理單元根據(jù)業(yè)務(wù)接口單元傳遞過(guò)來(lái)的服務(wù)請(qǐng)求中攜帶的用戶業(yè)務(wù)所要求的服務(wù)質(zhì)量QoS要求信息，向資源管理單元發(fā)送查詢請(qǐng)求，接收資源管理單元返回的相應(yīng)的應(yīng)用服務(wù)器的資源使用情況信息，針對(duì)所述用戶業(yè)務(wù)產(chǎn)生處理計(jì)劃，將該具體處理計(jì)劃傳遞給業(yè)務(wù)接口單元。
2.根據(jù)權(quán)利要求1所述的裝置，其特征在于，還包括策略管理單元針對(duì)用戶業(yè)務(wù)提供具體的控制策略，將該控制策略傳遞給業(yè)務(wù)處理單元；業(yè)務(wù)處理單元利用該控制策略產(chǎn)生針對(duì)所述用戶業(yè)務(wù)的處理計(jì)劃。
3.根據(jù)權(quán)利要求1或2所述的裝置，其特征在于，所述的資源管理單元具體包括資源監(jiān)控單元用于通過(guò)主動(dòng)查詢或者應(yīng)用服務(wù)器主動(dòng)上報(bào)的方式監(jiān)控所管轄的應(yīng)用服務(wù)器的資源使用情況；并根據(jù)業(yè)務(wù)處理單元產(chǎn)生的針對(duì)所述用戶業(yè)務(wù)的處理計(jì)劃修改相關(guān)應(yīng)用服務(wù)器的可用資源參數(shù)；資源交互單元提供SRM之間的交互接口，通過(guò)該交互接口SRM向其他SRM發(fā)送查詢請(qǐng)求，查詢其他SRM所管轄的應(yīng)用服務(wù)器資源使用情況；接收其他SRM發(fā)送過(guò)來(lái)的查詢請(qǐng)求，將本SRM所管轄的應(yīng)用服務(wù)器資源使用情況返回給所述請(qǐng)求的其他SRM。
4.根據(jù)權(quán)利要求1所述的裝置，其特征在于，所述的SRM采用分布式的方式或者集中式的方式或者混合式的方式部署在業(yè)務(wù)網(wǎng)絡(luò)中。
5.一種業(yè)務(wù)網(wǎng)絡(luò)內(nèi)提供端到端服務(wù)質(zhì)量保證的方法，其特征在于，包括步驟SRM接收到用戶業(yè)務(wù)的服務(wù)請(qǐng)求，所述SRM根據(jù)所監(jiān)控到的應(yīng)用服務(wù)器的資源使用情況和所述用戶業(yè)務(wù)的QoS要求對(duì)所述用戶業(yè)務(wù)進(jìn)行處理，將處理結(jié)果返回給所述服務(wù)請(qǐng)求的發(fā)送方。
6.根據(jù)權(quán)利要求5所述的方法，其特征在于，具體包括A1、應(yīng)用服務(wù)器向SRM發(fā)送服務(wù)請(qǐng)求，該服務(wù)請(qǐng)求中攜帶用戶業(yè)務(wù)所要求的QoS參數(shù)信息和應(yīng)用服務(wù)器類型信息；A2、SRM根據(jù)所述用戶業(yè)務(wù)所要求的應(yīng)用服務(wù)器類型信息，在其所監(jiān)控到的應(yīng)用服務(wù)器的資源使用情況中進(jìn)行查詢；和/或，與其它SRM進(jìn)行交互，獲得相應(yīng)的應(yīng)用服務(wù)器的地址和當(dāng)前資源使用情況信息；A3、SRM根據(jù)所述用戶業(yè)務(wù)所要求的QoS參數(shù)信息、獲取的相應(yīng)的應(yīng)用服務(wù)器的地址和當(dāng)前資源使用情況信息以及設(shè)定的控制策略信息，產(chǎn)生針對(duì)所述用戶業(yè)務(wù)的處理計(jì)劃，將該處理計(jì)劃傳遞給所述請(qǐng)求的應(yīng)用服務(wù)器。
7.根據(jù)權(quán)利要求6所述的方法，其特征在于，所述的處理計(jì)劃包括拒絕所述用戶業(yè)務(wù)的服務(wù)請(qǐng)求；或者，給所述用戶業(yè)務(wù)提供服務(wù)的應(yīng)用服務(wù)器列表和地址信息。
8.根據(jù)權(quán)利要求6所述的方法，其特征在于，所述的控制策略包括在滿足用戶業(yè)務(wù)的QoS要求下選擇當(dāng)前響應(yīng)時(shí)間最小的應(yīng)用服務(wù)器；和/或，在滿足用戶業(yè)務(wù)的QoS要求下選取當(dāng)前負(fù)載率最低的應(yīng)用服務(wù)器；和/或，在滿足用戶業(yè)務(wù)的QoS要求下隨機(jī)選取應(yīng)用服務(wù)器；和/或，在滿足用戶業(yè)務(wù)的QoS要求下選取參數(shù)值與用戶業(yè)務(wù)要求的QoS參數(shù)值之間差值最小的應(yīng)用服務(wù)器。
9.如權(quán)利要求5所述的的方法，其特征在于，所述的服務(wù)請(qǐng)求的發(fā)送方為應(yīng)用服務(wù)器或用戶。
10.根據(jù)權(quán)利要求5所述的方法，其特征在于，還包括在業(yè)務(wù)網(wǎng)絡(luò)內(nèi)設(shè)置SRM，使用所述SRM監(jiān)控業(yè)務(wù)網(wǎng)絡(luò)內(nèi)應(yīng)用服務(wù)器的資源使用情況。
11.根據(jù)權(quán)利要求5、6或9所述的方法，其特征在于，所述的應(yīng)用服務(wù)器的資源使用情況包括應(yīng)用服務(wù)器的QoS參數(shù)信息，該QoS參數(shù)信息包括應(yīng)用服務(wù)器的負(fù)載率、響應(yīng)時(shí)間、帶寬、碼率和/或顯示分辨率信息。
12.根據(jù)權(quán)利要求11所述的方法，其特征在于，還包括在SRM中維護(hù)一個(gè)資源狀態(tài)列表，該資源狀態(tài)列表中包括應(yīng)用服務(wù)器的標(biāo)識(shí)、應(yīng)用服務(wù)器的地址和該應(yīng)用服務(wù)器的QoS參數(shù)信息。
13.根據(jù)權(quán)利要求12所述的方法，其特征在于，所述的資源狀態(tài)列表在SRM中采用可擴(kuò)展標(biāo)記語(yǔ)言XML格式存儲(chǔ)。
全文摘要
本發(fā)明提供了一種業(yè)務(wù)網(wǎng)絡(luò)內(nèi)提供端到端服務(wù)質(zhì)量保證的裝置和方法，該裝置通過(guò)SRM(資源監(jiān)控管理器)來(lái)實(shí)現(xiàn)，主要包括業(yè)務(wù)處理單元、資源管理單元和業(yè)務(wù)接口單元。該方法主要包括SRM接收到用戶業(yè)務(wù)的服務(wù)請(qǐng)求，所述SRM根據(jù)所監(jiān)控到的應(yīng)用服務(wù)器的資源使用情況和所述用戶業(yè)務(wù)的QoS要求對(duì)所述用戶業(yè)務(wù)進(jìn)行處理，將處理結(jié)果返回給所述服務(wù)請(qǐng)求的發(fā)送方。利用本發(fā)明所述裝置和方法，保證業(yè)務(wù)網(wǎng)絡(luò)內(nèi)端到端的業(yè)務(wù)QoS(服務(wù)質(zhì)量)，提高業(yè)務(wù)網(wǎng)絡(luò)內(nèi)應(yīng)用服務(wù)器的使用效率。
文檔編號(hào)H04L12/54GK101083517SQ200610083218
公開日2007年12月5日 申請(qǐng)日期2006年5月30日 優(yōu)先權(quán)日2006年5月30日
發(fā)明者鄒現(xiàn)軍, 李彥, 石曉旻 申請(qǐng)人:華為技術(shù)有限公司