專利名稱：業(yè)務網(wǎng)絡內(nèi)提供端到端服務質(zhì)量保證的裝置和方法
技術領域：
本發(fā)明涉及網(wǎng)絡通訊領域，尤其涉及一種業(yè)務網(wǎng)絡內(nèi)提供端到端服務質(zhì)量保證的裝置和方法。
背景技術：
隨著電信網(wǎng)絡技術和用戶需求的不斷發(fā)展，各種單一的網(wǎng)絡運營商正在向綜合信息提供商轉(zhuǎn)變，向用戶提供的業(yè)務由傳統(tǒng)的語言業(yè)務為主向豐富多彩的多媒體業(yè)務和數(shù)據(jù)業(yè)務發(fā)展，比如，向用戶提供MMS(multi-mediamessage service，多媒體信息業(yè)務)、新聞、視頻電話、互動消息、游戲、音樂、娛樂和位置服務等。這些多媒體業(yè)務和數(shù)據(jù)業(yè)務吸引了更多的用戶，給運營商帶來了更多的網(wǎng)絡業(yè)務流量和營業(yè)收入，同時這些豐富多彩的多媒體業(yè)務和數(shù)據(jù)業(yè)務構(gòu)成了一個新的疊加網(wǎng)絡-業(yè)務網(wǎng)絡。
隨著各種豐富多彩的業(yè)務的不斷涌現(xiàn)及用戶各種需求的不斷增加，未來的電信網(wǎng)絡將是以用戶為中心的，滿足用戶對業(yè)務的性能要求是至關重要的，直接關系到用戶對網(wǎng)絡運營商的滿意度和忠誠度。
相對傳統(tǒng)的語言業(yè)務等電信業(yè)務，上述多媒體業(yè)務和數(shù)據(jù)業(yè)務的種類和復雜度也在不但增大，具有更復雜的業(yè)務邏輯，一個用戶業(yè)務可能需要業(yè)務網(wǎng)內(nèi)多個業(yè)務服務器的共同協(xié)調(diào)才能完成，如現(xiàn)在熱門的組合業(yè)務、業(yè)務鏈等都需要業(yè)務網(wǎng)內(nèi)多個應用服務器的協(xié)作才能滿足用戶需求。
因而，如何在上述情況下保證用戶仍然能夠獲得良好的業(yè)務體驗已經(jīng)成為網(wǎng)絡運營商一個亟待解決的問題。
現(xiàn)有技術中一種在業(yè)務網(wǎng)絡內(nèi)對用戶業(yè)務提供QoS(服務質(zhì)量)保證的方法為采用網(wǎng)絡準入系統(tǒng)的解決方案。該方案的架構(gòu)如圖1所示，該方案在網(wǎng)絡的邊緣節(jié)點上部署一個或多個NAC(Network admission control，網(wǎng)絡準入控制設備)，在核心網(wǎng)絡上部署一個或多個NCS(Network controlserver，網(wǎng)絡控制服務器)，根據(jù)當前網(wǎng)絡的資源使用情況、負載率及請求的數(shù)據(jù)流所需要的QoS保證決定是否允許該數(shù)據(jù)流通過本網(wǎng)絡，該技術主要用于避免出現(xiàn)資源瓶頸，保證具有QoS要求的數(shù)據(jù)傳輸。
上述現(xiàn)有技術的方法的缺點為1、該方法是針對單一類型的應用服務器，監(jiān)控的資源均為統(tǒng)一的同質(zhì)的資源。而各個異構(gòu)型應用服務器所包含的資源各不相同，該方法不能同時為各種不同的異構(gòu)型應用服務器提供資源監(jiān)控和準入控制。因此，該方法不具備可擴展性，不適用于整個業(yè)務網(wǎng)絡。
2.該方法無法根據(jù)請求的數(shù)據(jù)流的特點動態(tài)選擇、檢測所需的應用服務器。
發(fā)明內(nèi)容
本發(fā)明的目的是提供一種業(yè)務網(wǎng)絡內(nèi)提供端到端服務質(zhì)量保證的裝置和方法，從而可以保證業(yè)務網(wǎng)絡內(nèi)端到端的業(yè)務QoS，提高業(yè)務網(wǎng)絡內(nèi)應用服務器的使用效率。
本發(fā)明的目的是通過以下技術方案實現(xiàn)的一種業(yè)務網(wǎng)絡內(nèi)提供端到端服務質(zhì)量保證的裝置，該裝置通過資源監(jiān)控管理器SRM來實現(xiàn)，所述SRM包括業(yè)務處理單元、資源管理單元和業(yè)務接口單元，其中，業(yè)務接口單元為用戶業(yè)務提供接口，通過所述接口接收應用服務器傳遞過來的服務請求，將接收到的服務請求傳遞給業(yè)務處理單元；通過所述接口將業(yè)務處理單元針對所述用戶業(yè)務產(chǎn)生的處理計劃傳遞給請求的應用服務器；資源管理單元監(jiān)控和管理業(yè)務網(wǎng)絡內(nèi)應用服務器的資源使用情況；根據(jù)業(yè)務處理單元發(fā)送過來的查詢請求，向業(yè)務處理單元返回相應的應用服務器的資源使用情況信息；業(yè)務處理單元根據(jù)業(yè)務接口單元傳遞過來的服務請求中攜帶的用戶業(yè)務所要求的服務質(zhì)量QoS要求信息，向資源管理單元發(fā)送查詢請求，接收資源管理單元返回的相應的應用服務器的資源使用情況信息，針對所述用戶業(yè)務產(chǎn)生處理計劃，將該具體處理計劃傳遞給業(yè)務接口單元。
還包括策略管理單元針對用戶業(yè)務提供具體的控制策略，將該控制策略傳遞給業(yè)務處理單元；業(yè)務處理單元利用該控制策略產(chǎn)生針對所述用戶業(yè)務的處理計劃。
所述的資源管理單元具體包括資源監(jiān)控單元用于通過主動查詢或者應用服務器主動上報的方式監(jiān)控所管轄的應用服務器的資源使用情況；并根據(jù)業(yè)務處理單元產(chǎn)生的針對所述用戶業(yè)務的處理計劃修改相關應用服務器的可用資源參數(shù)；資源交互單元提供SRM之間的交互接口，通過該交互接口SRM向其他SRM發(fā)送查詢請求，查詢其他SRM所管轄的應用服務器資源使用情況；接收其他SRM發(fā)送過來的查詢請求，將本SRM所管轄的應用服務器資源使用情況返回給所述請求的其他SRM。
所述的SRM采用分布式的方式或者集中式的方式或者混合式的方式部署在業(yè)務網(wǎng)絡中。
一種業(yè)務網(wǎng)絡內(nèi)提供端到端服務質(zhì)量保證的方法，包括步驟
SRM接收到用戶業(yè)務的服務請求，所述SRM根據(jù)所監(jiān)控到的應用服務器的資源使用情況和所述用戶業(yè)務的QoS要求對所述用戶業(yè)務進行處理，將處理結(jié)果返回給所述服務請求的發(fā)送方。
具體包括A1、應用服務器向SRM發(fā)送服務請求，該服務請求中攜帶用戶業(yè)務所要求的QoS參數(shù)信息和應用服務器類型信息；A2、SRM根據(jù)所述用戶業(yè)務所要求的應用服務器類型信息，在其所監(jiān)控到的應用服務器的資源使用情況中進行查詢；和/或，與其它SRM進行交互，獲得相應的應用服務器的地址和當前資源使用情況信息；A3、SRM根據(jù)所述用戶業(yè)務所要求的QoS參數(shù)信息、獲取的相應的應用服務器的地址和當前資源使用情況信息以及設定的控制策略信息，產(chǎn)生針對所述用戶業(yè)務的處理計劃，將該處理計劃傳遞給所述請求的應用服務器。
所述的處理計劃包括拒絕所述用戶業(yè)務的服務請求；或者，給所述用戶業(yè)務提供服務的應用服務器列表和地址信息。
所述的控制策略包括在滿足用戶業(yè)務的QoS要求下選擇當前響應時間最小的應用服務器；和/或，在滿足用戶業(yè)務的QoS要求下選取當前負載率最低的應用服務器；和/或，在滿足用戶業(yè)務的QoS要求下隨機選取應用服務器；和/或，在滿足用戶業(yè)務的QoS要求下選取參數(shù)值與用戶業(yè)務要求的QoS參數(shù)值之間差值最小的應用服務器。
所述的服務請求的發(fā)送方為應用服務器或用戶。
還包括
在業(yè)務網(wǎng)絡內(nèi)設置SRM，使用所述SRM監(jiān)控業(yè)務網(wǎng)絡內(nèi)應用服務器的資源使用情況。
所述的應用服務器的資源使用情況包括應用服務器的QoS參數(shù)信息，該QoS參數(shù)信息包括應用服務器的負載率、響應時間、帶寬、碼率和/或顯示分辨率信息。
還包括在SRM中維護一個資源狀態(tài)列表，該資源狀態(tài)列表中包括應用服務器的標識、應用服務器的地址和該應用服務器的QoS參數(shù)信息。
所述的資源狀態(tài)列表在SRM中采用可擴展標記語言XML格式存儲。
由上述本發(fā)明提供的技術方案可以看出，本發(fā)明通過在業(yè)務網(wǎng)絡中設置SRM(Service resource monitor/management，資源監(jiān)控管理器)，SRM動態(tài)監(jiān)控業(yè)務網(wǎng)絡內(nèi)應用服務器的資源使用情況，并動態(tài)作出具體的業(yè)務處理計劃。從而可以保證業(yè)務網(wǎng)絡內(nèi)端到端的業(yè)務QoS，提高業(yè)務網(wǎng)絡內(nèi)應用服務器的使用效率，可以最大限定的保障用戶的業(yè)務使用及體驗，優(yōu)化整個業(yè)務網(wǎng)路內(nèi)的資源使用率。解決現(xiàn)有技術無法針對業(yè)務的特點進行異構(gòu)性的QoS保障及無法動態(tài)選擇、檢測所需的應用服務器的缺點。
圖1為現(xiàn)有技術中采用網(wǎng)絡準入系統(tǒng)的解決方案的架構(gòu)示意圖；圖2為SRM采用分布式的方式部署時的網(wǎng)絡的體系架構(gòu)示意圖；圖3為本方法所述SRM的功能架構(gòu)示意圖。
具體實施例方式
本發(fā)明提供了一種業(yè)務網(wǎng)絡內(nèi)提供端到端服務質(zhì)量保證的裝置和方法，本發(fā)明的核心為在業(yè)務網(wǎng)絡中設置SRM，SRM動態(tài)監(jiān)控業(yè)務網(wǎng)絡內(nèi)應用服務器的資源使用情況，并根據(jù)獲得的資源使用情況、控制策略以及用戶業(yè)務的QoS要求動態(tài)作出具體的業(yè)務處理計劃。
下面先結(jié)合附圖來詳細描述本發(fā)明所述裝置，本方法所述裝置通過SRM來實現(xiàn)。
SRM作為一個資源管理裝置動態(tài)監(jiān)控和管理業(yè)務網(wǎng)絡內(nèi)應用服務器的資源使用情況，該資源使用情況包括應用服務器的QoS參數(shù)信息、應用服務器之間的傳輸延遲，應用服務器提供的媒體資源等，該QoS參數(shù)信息包括應用服務器的負載率、響應時間、帶寬信息、碼率和顯示分辨率信息等。每種應用服務器對應的QoS參數(shù)是不一樣的，有的可能是負載率、帶寬，有的可能是碼率、顯示分辨率，有的可能是帶寬、顯示負載率。
SRM根據(jù)所述用戶業(yè)務所要求的QoS參數(shù)信息、獲取的應用服務器的資源使用情況以及控制策略信息，產(chǎn)生針對所述用戶業(yè)務的處理計劃，將該處理計劃傳遞給所述請求的應用服務器。
SRM可以采用集中式的方式或者采用分部式的方式或者是采用混合的方式部署在業(yè)務網(wǎng)絡中。在采用集中式的方式部署時，一個SRM需要監(jiān)控整個業(yè)務網(wǎng)絡內(nèi)部所有的應用服務器的資源使用情況。采用分部或混合的方式部署時，可能需要多個SRM來監(jiān)控業(yè)務網(wǎng)絡內(nèi)部的資源使用情況，其中每個SRM可能監(jiān)控一個或多個應用服務器的資源使用，SRM與SRM之間存在通訊接口。SRM采用分布式的方式部署時，網(wǎng)絡的體系架構(gòu)如圖2所示，AS為應用服務器。
如圖2所示，最下層為基本的網(wǎng)絡層，用于保證應用服務器與應用服務器、應用服務器與SRM、SRM與SRM之間的通訊，可能包含多個路由器和物理鏈路，用于處理具體的用戶業(yè)務，給用戶業(yè)務提供應用服務?；镜木W(wǎng)絡層的上面為業(yè)務網(wǎng)絡，在業(yè)務網(wǎng)絡中，需要多個應用服務器協(xié)同工作才能處理一個用戶業(yè)務的服務請求。
SRM與應用服務器之間可以是一對一，也可以是一對多的關系，SRM與SRM之間需要相互進行通訊從而在整個業(yè)務網(wǎng)絡內(nèi)提供端到端的QoS保證。
上述SRM的功能架構(gòu)圖如圖3所示，包括業(yè)務接口單元、資源監(jiān)控單元、資源交互單元、業(yè)務處理單元和策略管理單元等模塊。
上述SRM的中的各個模塊的功能描述如下業(yè)務接口單元為用戶業(yè)務提供查詢和響應接口，通過所述查詢接口接收從應用服務器傳來的服務請求，將接收到的服務請求傳遞給業(yè)務處理單元。該服務請求包括用戶業(yè)務所要求的QoS參數(shù)值、QoS參數(shù)名及相關要求、需要的應用服務器的標識符及數(shù)目等信息。其中QoS參數(shù)要求包括但不限于整個業(yè)務的響應時間、所需要的帶寬等。業(yè)務接口單元還通過所述響應接口將業(yè)務處理單元針對所述用戶業(yè)務產(chǎn)生的具體處理計劃下發(fā)到所述發(fā)送服務請求的應用服務器，該具體處理計劃中包含給用戶業(yè)務提供服務的應用服務器列表和地址信息，或者，拒絕所述用戶業(yè)務的服務請求信息。
資源監(jiān)控單元用于監(jiān)控和管理所管轄的應用服務器的資源使用情況，資源監(jiān)控單元主動查詢相關應用服務器的資源使用情況(也可以是各應用服務器主動向資源監(jiān)控單元上報當前的資源使用情況)，將獲取的應用服務器的資源使用情況進行保存，并傳遞給業(yè)務處理單元。在資源監(jiān)控單元中應維護一張資源狀態(tài)列表，該資源狀態(tài)列表中包括應用服務器ID、應用服務器的地址及該應用服務器所提供的各種QoS參數(shù)，這些QoS參數(shù)包含但不限于應用服務器的當前響應時間、當前負載率和當前可用帶寬等信息。由于各種應用服務器所涉及的QoS參數(shù)各不相同，很難用數(shù)據(jù)庫進行統(tǒng)一的建模，因此，上述資源狀態(tài)列表在資源監(jiān)控單元中采用XML(可擴展標記語言)格式存儲。并根據(jù)業(yè)務處理單元模塊傳遞過來的策略決定修改相關應用服務器的可用資源參數(shù)。
描述上述資源狀態(tài)列表的XML文件的格式可以如下所示<服務列表>
<服務標識＝“服務1”地址＝“地址1”>
<資源標識＝“資源1”>當前值1</資源>
<資源標識＝“資源2”>當前值2</資源>
</服務>
<服務標識＝“服務2”地址＝“地址2”>
<資源標識＝“資源2”>當前值3</資源>
<資源標識＝“資源3”>當前值4</資源>
</服務>
</服務列表>
該XML文件對應的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之間的交互接口，通過該交互接口SRM可以向其他SRM發(fā)送資源查詢請求，查詢其他SRM所管轄的應用服務器資源使用情況。所述對其他SRM發(fā)出的資源查詢請求包括應用服務器類型及用戶業(yè)務要求的QoS參數(shù)。
通過該交互接口SRM也可以接收其他SRM發(fā)送過來的資源查詢請求，并返回響應信息。在響應其它SRM的查詢請求時，需要與資源監(jiān)控單元進行交互取得相關應用服務器的資源使用狀態(tài)。所述返回的響應信息包括應用服務器的標識、地址及當前資源的使用情況(如當前響應時間等)。
需要說明的是一個用戶業(yè)務所要求的應用服務器可能并不在本SRM所管理的范圍內(nèi)，而在其他SRM所管轄的范圍內(nèi)，所以需要各個SRM之間進行通訊交互從而達到端到端的QoS保證。
業(yè)務處理單元是SRM的主控模塊，進行具體的用戶業(yè)務處理。它根據(jù)業(yè)務接口單元發(fā)送過來的服務請求中攜帶的用戶業(yè)務所要求的應用服務器類型及當前SRM所監(jiān)控的應用服務器種類分別向資源交互單元和/或資源監(jiān)控單元進行相關查詢。
根據(jù)策略管理單元傳遞過來的當前策略、從資源交互單元和/或資源監(jiān)控單元返回的當前各應用服務器的資源可用情況及所述用戶業(yè)務所要求的QoS參數(shù)信息作出具體的業(yè)務處理計劃，然后將制定出的處理計劃通過業(yè)務接口單元傳遞給所述發(fā)送服務請求的應用服務器。其中，具體的業(yè)務處理計劃可能是拒絕所述服務請求，也可能是滿足所述服務請求所要求的具體的應用服務器列表和地址信息。
策略管理單元對用戶業(yè)務提供具體的控制策略及對應算法，將該控制策略及對應算法傳遞給業(yè)務處理單元。具體的控制策略包括但不限于1、在滿足用戶業(yè)務QoS要求下選擇當前響應時間最小的應用服務器。
2、在滿足用戶業(yè)務QoS要求下選取當前負載率最低的應用服務器。
3、在滿足用戶業(yè)務QoS條件下隨機選取適當?shù)膽梅掌鳌?br>
4、在滿足用戶業(yè)務QoS要求下選取參數(shù)值最相近于用戶業(yè)務的QoS參數(shù)值的應用服務器等。
基于上述裝置，本發(fā)明所述方法的實施例的處理流程包括如下步驟步驟1應用服務器通過業(yè)務接口單元向該應用服務器所屬的SRM發(fā)送服務請求，該服務請求中攜帶用戶業(yè)務所要求的應用服務器類型和QoS參數(shù)信息。
步驟2所述SRM中的業(yè)務處理單元獲取接收到的所述服務請求中攜帶的用戶業(yè)務所要求的應用服務器類型和QoS參數(shù)信息。
當所述用戶業(yè)務所要求的應用服務器類型均在所述SRM中的資源監(jiān)控單元中保存時，則所述SRM中的業(yè)務處理單元向該SRM中的資源監(jiān)控單元發(fā)送查詢請求，查詢相應的應用服務器的資源使用情況信息。資源監(jiān)控單元根據(jù)發(fā)送過來的查詢請求獲取用戶業(yè)務所要求的應用服務器地址及當前資源使用情況(如當前響應時間)信息，并將所獲取的應用服務器地址及當前資源使用情況信息返回給業(yè)務處理單元。
當所述用戶業(yè)務所要求的應用服務器類型均在其他SRM管轄的范圍內(nèi)時，則所述SRM中的業(yè)務處理單元向資源交互單元發(fā)送上述查詢請求，資源交互單元與所述其他SRM進行交互，將接收到的上述查詢請求轉(zhuǎn)交給所述其他SRM，并且接收所述其它SRM返回的用戶業(yè)務所要求的應用服務器地址及當前資源使用情況信息，將接收到的應用服務器地址及當前資源使用情況信息返回給業(yè)務處理單元。
當所述用戶業(yè)務所要求的應用服務器類型同時在所述SRM的資源監(jiān)控單元和其他SRM管轄的范圍內(nèi)時，則業(yè)務處理單元同時向資源交互單元和資源監(jiān)控單元發(fā)送上述查詢請求，接收資源交互單元和資源監(jiān)控單元返回的用戶業(yè)務所要求的應用服務器地址及當前資源使用情況信息。
步驟3、業(yè)務處理單元根據(jù)所述資源交互單元和/或資源監(jiān)控單元返回的用戶業(yè)務所要求的應用服務器地址及當前資源使用情況信息，以及策略管理單元傳遞過來的當前控制策略和該用戶業(yè)務所要求的QoS參數(shù)信息作出具體的業(yè)務處理計劃，然后將制定出的處理計劃通過業(yè)務接口單元傳遞給上述發(fā)送服務請求的應用服務器。其中，如果不能滿足用戶業(yè)務的QoS要求，則具體的業(yè)務處理計劃是拒絕該用戶業(yè)務的服務請求；否則，具體的業(yè)務處理計劃中包括給所述用戶業(yè)務提供服務的應用服務器列表和地址信息。
所述SRM的資源監(jiān)控單元根據(jù)上述獲得的應用服務器地址及當前資源信息對相關應用服務器的相關資源參數(shù)進行修改。
上述本發(fā)明所述方法的一個應用場景如下用戶通過發(fā)送一個短信選擇所要看的電影，在這個應用場景中，短信服務器處理用戶發(fā)送的短信，然后將相關信息轉(zhuǎn)發(fā)給電影服務器，電影服務器根據(jù)收到的信息播放相關電影給用戶。
當前分別有短信服務器1、短信服務器2和短信服務器3，上述三個短信服務器由SRM1進行管理，各個短信服務器當前的資源使用情況分別為服務器1延遲＝0.5ms，負載率＝50％；服務器2延遲＝1ms，負載率＝30％；服務器3延遲＝2ms，負載率＝70％。
當前分別有電影服務器1、電影服務器2，上述兩個電影服務器由SRM2進行管理，各個電影服務器當前的資源使用情況分別為電影服務器1延遲＝3ms，負載率＝50％，帶寬＝20K，電影服務器2延遲＝4ms，負載率＝40％，帶寬＝40K。當前控制策略為在滿足業(yè)務QoS要求下選擇當前響應時間最小的應用服務器。
SRM1收到服務請求，該服務請求中攜帶用戶業(yè)務對短信服務器和電影服務器的需求及用戶業(yè)務的服務質(zhì)量要求信息，具體為總的延遲＜5.5ms，電影服務器的帶寬＞30K。SRM1根據(jù)上述用戶業(yè)務的服務質(zhì)量要求，查詢資源監(jiān)控單元，資源監(jiān)控單元返回短信服務器1、短信服務器2的當前資源使用情況信息。SRM1還向SRM2發(fā)送攜帶上述用戶業(yè)務的服務質(zhì)量要求信息的查詢請求，SRM2向SRM1返回符合上述用戶業(yè)務的服務質(zhì)量要求(帶寬＞30K)的電影服務器2的當前資源使用情況信息。
SRM1根據(jù)上述短信服務器1、短信服務器2和SRM2返回的信息，確定當前滿足上述用戶業(yè)務的服務質(zhì)量要求的短信服務器、電影服務器組合為短信服務器1，電影服務器2短信服務器2，電影服務器2SRM1又根據(jù)上述當前控制策略，即選擇當前響應時間最小的應用服務器，選取短信服務器1和電影服務器2為該用戶業(yè)務服務，并將短信服務器1和電影服務器2的相關信息返回給該請求者。
以上所述，僅為本發(fā)明較佳的具體實施方式
，但本發(fā)明的保護范圍并不局限于此，任何熟悉本技術領域的技術人員在本發(fā)明揭露的技術范圍內(nèi)，可輕易想到的變化或替換，都應涵蓋在本發(fā)明的保護范圍之內(nèi)。因此，本發(fā)明的保護范圍應該以權(quán)利要求的保護范圍為準。
權(quán)利要求
1.一種業(yè)務網(wǎng)絡內(nèi)提供端到端服務質(zhì)量保證的裝置，其特征在于，該裝置通過資源監(jiān)控管理器SRM來實現(xiàn)，所述SRM包括業(yè)務處理單元、資源管理單元和業(yè)務接口單元，其中，業(yè)務接口單元為用戶業(yè)務提供接口，通過所述接口接收應用服務器傳遞過來的服務請求，將接收到的服務請求傳遞給業(yè)務處理單元；通過所述接口將業(yè)務處理單元針對所述用戶業(yè)務產(chǎn)生的處理計劃傳遞給請求的應用服務器；資源管理單元監(jiān)控和管理業(yè)務網(wǎng)絡內(nèi)應用服務器的資源使用情況；根據(jù)業(yè)務處理單元發(fā)送過來的查詢請求，向業(yè)務處理單元返回相應的應用服務器的資源使用情況信息；業(yè)務處理單元根據(jù)業(yè)務接口單元傳遞過來的服務請求中攜帶的用戶業(yè)務所要求的服務質(zhì)量QoS要求信息，向資源管理單元發(fā)送查詢請求，接收資源管理單元返回的相應的應用服務器的資源使用情況信息，針對所述用戶業(yè)務產(chǎn)生處理計劃，將該具體處理計劃傳遞給業(yè)務接口單元。
2.根據(jù)權(quán)利要求1所述的裝置，其特征在于，還包括策略管理單元針對用戶業(yè)務提供具體的控制策略，將該控制策略傳遞給業(yè)務處理單元；業(yè)務處理單元利用該控制策略產(chǎn)生針對所述用戶業(yè)務的處理計劃。
3.根據(jù)權(quán)利要求1或2所述的裝置，其特征在于，所述的資源管理單元具體包括資源監(jiān)控單元用于通過主動查詢或者應用服務器主動上報的方式監(jiān)控所管轄的應用服務器的資源使用情況；并根據(jù)業(yè)務處理單元產(chǎn)生的針對所述用戶業(yè)務的處理計劃修改相關應用服務器的可用資源參數(shù)；資源交互單元提供SRM之間的交互接口，通過該交互接口SRM向其他SRM發(fā)送查詢請求，查詢其他SRM所管轄的應用服務器資源使用情況；接收其他SRM發(fā)送過來的查詢請求，將本SRM所管轄的應用服務器資源使用情況返回給所述請求的其他SRM。
4.根據(jù)權(quán)利要求1所述的裝置，其特征在于，所述的SRM采用分布式的方式或者集中式的方式或者混合式的方式部署在業(yè)務網(wǎng)絡中。
5.一種業(yè)務網(wǎng)絡內(nèi)提供端到端服務質(zhì)量保證的方法，其特征在于，包括步驟SRM接收到用戶業(yè)務的服務請求，所述SRM根據(jù)所監(jiān)控到的應用服務器的資源使用情況和所述用戶業(yè)務的QoS要求對所述用戶業(yè)務進行處理，將處理結(jié)果返回給所述服務請求的發(fā)送方。
6.根據(jù)權(quán)利要求5所述的方法，其特征在于，具體包括A1、應用服務器向SRM發(fā)送服務請求，該服務請求中攜帶用戶業(yè)務所要求的QoS參數(shù)信息和應用服務器類型信息；A2、SRM根據(jù)所述用戶業(yè)務所要求的應用服務器類型信息，在其所監(jiān)控到的應用服務器的資源使用情況中進行查詢；和/或，與其它SRM進行交互，獲得相應的應用服務器的地址和當前資源使用情況信息；A3、SRM根據(jù)所述用戶業(yè)務所要求的QoS參數(shù)信息、獲取的相應的應用服務器的地址和當前資源使用情況信息以及設定的控制策略信息，產(chǎn)生針對所述用戶業(yè)務的處理計劃，將該處理計劃傳遞給所述請求的應用服務器。
7.根據(jù)權(quán)利要求6所述的方法，其特征在于，所述的處理計劃包括拒絕所述用戶業(yè)務的服務請求；或者，給所述用戶業(yè)務提供服務的應用服務器列表和地址信息。
8.根據(jù)權(quán)利要求6所述的方法，其特征在于，所述的控制策略包括在滿足用戶業(yè)務的QoS要求下選擇當前響應時間最小的應用服務器；和/或，在滿足用戶業(yè)務的QoS要求下選取當前負載率最低的應用服務器；和/或，在滿足用戶業(yè)務的QoS要求下隨機選取應用服務器；和/或，在滿足用戶業(yè)務的QoS要求下選取參數(shù)值與用戶業(yè)務要求的QoS參數(shù)值之間差值最小的應用服務器。
9.如權(quán)利要求5所述的的方法，其特征在于，所述的服務請求的發(fā)送方為應用服務器或用戶。
10.根據(jù)權(quán)利要求5所述的方法，其特征在于，還包括在業(yè)務網(wǎng)絡內(nèi)設置SRM，使用所述SRM監(jiān)控業(yè)務網(wǎng)絡內(nèi)應用服務器的資源使用情況。
11.根據(jù)權(quán)利要求5、6或9所述的方法，其特征在于，所述的應用服務器的資源使用情況包括應用服務器的QoS參數(shù)信息，該QoS參數(shù)信息包括應用服務器的負載率、響應時間、帶寬、碼率和/或顯示分辨率信息。
12.根據(jù)權(quán)利要求11所述的方法，其特征在于，還包括在SRM中維護一個資源狀態(tài)列表，該資源狀態(tài)列表中包括應用服務器的標識、應用服務器的地址和該應用服務器的QoS參數(shù)信息。
13.根據(jù)權(quán)利要求12所述的方法，其特征在于，所述的資源狀態(tài)列表在SRM中采用可擴展標記語言XML格式存儲。
全文摘要
本發(fā)明提供了一種業(yè)務網(wǎng)絡內(nèi)提供端到端服務質(zhì)量保證的裝置和方法，該裝置通過SRM(資源監(jiān)控管理器)來實現(xiàn)，主要包括業(yè)務處理單元、資源管理單元和業(yè)務接口單元。該方法主要包括SRM接收到用戶業(yè)務的服務請求，所述SRM根據(jù)所監(jiān)控到的應用服務器的資源使用情況和所述用戶業(yè)務的QoS要求對所述用戶業(yè)務進行處理，將處理結(jié)果返回給所述服務請求的發(fā)送方。利用本發(fā)明所述裝置和方法，保證業(yè)務網(wǎng)絡內(nèi)端到端的業(yè)務QoS(服務質(zhì)量)，提高業(yè)務網(wǎng)絡內(nèi)應用服務器的使用效率。
文檔編號H04L12/54GK101083517SQ200610083218
公開日2007年12月5日 申請日期2006年5月30日 優(yōu)先權(quán)日2006年5月30日
發(fā)明者鄒現(xiàn)軍, 李彥, 石曉旻 申請人:華為技術有限公司