專利名稱：基于分組的網(wǎng)絡(luò)中的服務(wù)質(zhì)量監(jiān)控的制作方法
技術(shù)領(lǐng)域：
本發(fā)明總體上涉及網(wǎng)絡(luò)，更具體的，涉及監(jiān)控基于分組的網(wǎng)絡(luò)中的服務(wù)質(zhì)量(QoS)。
背景技術(shù)：
預(yù)期在下一十年中信息互聯(lián)網(wǎng)舞臺中的競爭會很激烈。隨著競爭的增加，使公司將其自身置于適當?shù)乩闷浜诵母偁幜Σ⑶裔槍Τ霈F(xiàn)的電信技術(shù)做好準備的位置是至關(guān)重要的。在此競爭環(huán)境下，市場中的合并、聯(lián)盟以及新進入者使得服務(wù)提供商不得不探求用于保持并吸引訂戶的革新方式。當今的服務(wù)提供商通過探求對于其客戶群捆綁銷售新服務(wù)的方案，來努力在此競爭不斷擴大的領(lǐng)域內(nèi)使自己標新立異。從而，許多服務(wù)提供商將下一代網(wǎng)絡(luò)(NGN)看作吸引新客戶的方式。
NGN是用于指代正在到來的基于IP技術(shù)的電信網(wǎng)絡(luò)，其傳送整合的語音和數(shù)據(jù)服務(wù)。NGN可以被視為基于分組的網(wǎng)絡(luò)，其中分組交換和傳輸元件，諸如路由器、交換機和網(wǎng)關(guān)，在邏輯上和物理上獨立于服務(wù)/呼叫控制機構(gòu)(intelligence)。該控制機構(gòu)用于支持所有類型的基于分組的傳輸網(wǎng)絡(luò)的服務(wù)，包括從基本語音電話服務(wù)到數(shù)據(jù)、視頻、多媒體和高級寬帶的每一個服務(wù)。
QoS是確保NGN的魯棒發(fā)展的重要要素，可以包括監(jiān)控以下中的一個或更多個服務(wù)可用性，如用戶到因特網(wǎng)服務(wù)的連接的可靠性。
延遲(也稱為等待時間)，如發(fā)送和接收分組之間的時間間隔。
延遲變化或抖動，其是指采用同一路由的流中的所有分組之間在持續(xù)時間方面的變化。
吞吐量，其是發(fā)送分組的平均速率或峰值速率。
由于擁塞導(dǎo)致的丟包率，其是在經(jīng)由網(wǎng)絡(luò)進行傳輸期間可能丟棄分組的最大速率。
為了更具有競爭力，公司將不得不確保網(wǎng)絡(luò)保持適當?shù)腝oS級別和/或SLA(服務(wù)級別協(xié)議)標準，以使移動用戶體驗到豐富的多媒體服務(wù)。對于網(wǎng)絡(luò)元件加強QoS的技術(shù)的示例包括整合的服務(wù)和區(qū)分服務(wù)。整合服務(wù)(也稱為Int-Serv)使用資源預(yù)留協(xié)議(RSVP)，并且在企業(yè)網(wǎng)絡(luò)的邊緣實現(xiàn)，其中，可以在桌面用戶級別管理用戶流。該協(xié)議假設(shè)使用端到端信號傳輸，來對于在接收機和發(fā)射機之間的路徑中的每一個路由器中心處的每一個要求QoS的流預(yù)留資源，并且必須在網(wǎng)絡(luò)中的每一個路由器處保持逐流的軟狀態(tài)。區(qū)分服務(wù)(也稱為Diff-Serv)使信號傳輸最小化，并且集中于聚集的流以及應(yīng)用于針對整個網(wǎng)絡(luò)的業(yè)務(wù)量類的集的逐中心行為(per-hub behavior PHB)。區(qū)分服務(wù)確保下游節(jié)點接收到對到達各輸入端口的分組進行處理并將這些分組適當?shù)剞D(zhuǎn)發(fā)到下一路由器所需的信息。
測量QoS是NGN中的另一重要問題。某些提出的解決方案包括侵害性(invasive)和非侵害性技術(shù)。
侵害性技術(shù)使用業(yè)務(wù)量生成器來注入人工業(yè)務(wù)量，該業(yè)務(wù)量生成器使網(wǎng)絡(luò)負荷以驗證往返延遲、分組速率和連接性。不幸的是，這些侵害性技術(shù)在網(wǎng)絡(luò)上注入了不期望的業(yè)務(wù)量。此外，這些技術(shù)沒有提供準時的逐會話QoS測量，因為該業(yè)務(wù)量注入與實際業(yè)務(wù)量不同步。最后，QoS測量是針對所注入的業(yè)務(wù)量，而不是實際業(yè)務(wù)量，這進一步弱化了測量的價值。
還提出了非侵害性測量。例如，可以通過使用用于測量業(yè)務(wù)量流的QoS參數(shù)的探測器來實現(xiàn)QoS監(jiān)控。此技術(shù)允許對會話和參與者進行標識，還允許測量錯誤率、丟包率、抖動以及對話的每個流的延遲。不幸的是，使用探測器具有有限的可伸縮性，因為探測器的安裝和維護是昂貴的。
圖1示出了在Anwar Siddiqui，Dan Romascanu和EugeneGolovinsky的提為“Real-Time Application Quality of ServiceMonitoring(RAQMON)Framework”的IETF論文中描述的非侵害性方法的另一示例。第一IP設(shè)備12，如蜂窩電話，包括運行應(yīng)用13所需的內(nèi)部硬件。第一設(shè)備12使用諸如SIP(會話初始化協(xié)議)的設(shè)置(set-up)協(xié)議與第二IP設(shè)備14通信，該第二IP設(shè)備14也包含應(yīng)用16。在設(shè)置之后，這兩個IP設(shè)備通過RTP(實時傳輸協(xié)議)進行通信，RTP是用于傳輸包括音頻和視頻的實時數(shù)據(jù)的因特網(wǎng)標準協(xié)議，并且其可以用于請求式媒體和交互式服務(wù)，如因特網(wǎng)電話。為了監(jiān)控QoS，將RAQMON數(shù)據(jù)源18嵌入IP設(shè)備14中。該RAQMON數(shù)據(jù)源(RDS)在多媒體會話期間獲取應(yīng)用16產(chǎn)生的QoS信息。然后經(jīng)由22處指示的RTCP(實時控制協(xié)議)應(yīng)用或SNMP(簡單網(wǎng)絡(luò)管理協(xié)議)所承載的RAQMON協(xié)議數(shù)據(jù)單元(PDU)，將QoS信息發(fā)送到RAQMON報告收集器20(1-N)。報告收集器20用作存儲QoS信息、保持歷史數(shù)據(jù)，并將該數(shù)據(jù)報告給網(wǎng)絡(luò)管理應(yīng)用26以進行分析的數(shù)據(jù)庫。
圖1的QoS解決方案有幾個問題。首先，IP終端設(shè)備14中的RDS 18必須存儲相當量的歷史數(shù)據(jù)，這將占用大量存儲容量并且昂貴。另外，IP終端設(shè)備14必須能夠處理3種協(xié)議，包括用于呼叫設(shè)置的信號傳輸協(xié)議(如，SIP)；發(fā)送PDU的協(xié)議(如，SNMP)；以及RTP。每個協(xié)議都需要支持該協(xié)議所需的多個獨立的軟件應(yīng)用和多個獨立的存儲區(qū)域。此外，RRC 20必須是稍微復(fù)雜的機器，其由于成本而危及了大型網(wǎng)絡(luò)中的可伸縮性。
圖2示出了Mueller等人的美國申請2003/0120773號中描述的另一解決方案。終端30經(jīng)由路由器32和網(wǎng)守34進行通信。第二終端36也經(jīng)由路由器38和網(wǎng)守40進行通信。中央的處理后設(shè)備42(CPP)和性能監(jiān)控單元44(PMON)被指定以與網(wǎng)守34、40進行通信來接收QoS信息。網(wǎng)守34、40必須進行收集、處理、存儲和將經(jīng)處理的數(shù)據(jù)傳送到監(jiān)控應(yīng)用42、44的功能。不僅網(wǎng)守是相當昂貴的部件，而且因網(wǎng)守僅能處理有限數(shù)量的終端使得該解決方案的可伸縮性嚴重受到阻礙。
因此，所需要的是在不降低通信效率以及增加成本和復(fù)雜性的情況下，監(jiān)控包括多個移動設(shè)備的網(wǎng)絡(luò)中的QoS的方法和系統(tǒng)。

發(fā)明內(nèi)容
因此本發(fā)明提供了一種監(jiān)控基于分組的網(wǎng)絡(luò)(如因特網(wǎng))中的服務(wù)質(zhì)量的方法和系統(tǒng)，該方法和系統(tǒng)克服了現(xiàn)有技術(shù)的缺陷。
申請人發(fā)現(xiàn)，通過使用三層架構(gòu)，可以進行非常靈活和低成本的QoS監(jiān)控，并且可以實現(xiàn)網(wǎng)絡(luò)的高可伸縮性，在該三層架構(gòu)中，一個或更多個應(yīng)用(下文中稱為“訂戶”或“監(jiān)視者”)可以使用預(yù)訂請求來從質(zhì)量服務(wù)器請求定制的QoS報告，并且其中，響應(yīng)于此，質(zhì)量服務(wù)器基于在它們的通信期間從用戶終端接收的QoS消息來準備這些報告并將這些報告以所請求的形式發(fā)送到訂戶。
本發(fā)明的三層架構(gòu)由于調(diào)解元件的存在而提供了更良好的可伸縮性，而利用二層架構(gòu)，消息直接由應(yīng)用和終端來交換。由于要求質(zhì)量服務(wù)器存儲很少量的歷史數(shù)據(jù)(直到該報告被發(fā)送到訂戶)，所以進一步提高了可伸縮性。
此外，預(yù)訂功能允許選擇性，該選擇性在于不同訂戶可以通過簡單的預(yù)訂消息來預(yù)訂不同服務(wù)或者相同服務(wù)(可能具有不同參數(shù))。具體的，訂戶可以從質(zhì)量服務(wù)器請求特定報告格式以及發(fā)送報告的觸發(fā)點。
另外，使用用于設(shè)置用戶通信的相同協(xié)議，在基于分組的網(wǎng)絡(luò)上從用戶終端向質(zhì)量服務(wù)器(或“事件”服務(wù)器)發(fā)送QoS信息，這使得能夠以高可伸縮性進行有效和低成本的QoS監(jiān)控解決方案。
由此，根據(jù)本發(fā)明第一方面，本發(fā)明涉及一種監(jiān)控基于分組的網(wǎng)絡(luò)中的服務(wù)質(zhì)量的方法，所述網(wǎng)絡(luò)適于在用戶終端之間建立通信，所述方法包括以下步驟請求對于至少所述用戶終端中的兩個之間的通信的服務(wù)質(zhì)量報告，其中所述請求包括提供與服務(wù)質(zhì)量報告的定制相關(guān)的信息；從所述兩個用戶終端接收與所述通信相關(guān)的服務(wù)質(zhì)量信息；以及基于所述服務(wù)質(zhì)量信息和所述定制信息提供所述報告。
有利的，請求所定制的報告包括指示要包括在QoS報告中的信息的類型。
優(yōu)選的，所述方法進一步包括提供多個通知服務(wù)，所述多個通知服務(wù)中的每一個包括提供至少各個服務(wù)質(zhì)量報告。
優(yōu)選的，請求服務(wù)質(zhì)量報告包括預(yù)訂所述多個通知服務(wù)之一。
優(yōu)選的，服務(wù)質(zhì)量信息是使用第一協(xié)議接收的，并且所述通信是使用與所述第一協(xié)議不同的第二協(xié)議建立的。
優(yōu)選的，在建立所述通信之前，使用所述第一協(xié)議設(shè)置所述通信。
定制信息可以包括指定與所述通信相關(guān)的一個或更多個觸發(fā)事件，并且所述報告可以是響應(yīng)于觸發(fā)事件提供的。
定制信息還可以包括指定期望的報告格式，并且所述報告可以所指定的報告格式提供。
涉及報告的這些信息可以是在預(yù)訂通知服務(wù)時指定的。具體的，預(yù)訂通知服務(wù)可以包括指定期望的報告格式以及用于提供報告的一個或更多個觸發(fā)事件。
有利的，基于分組的網(wǎng)絡(luò)是基于因特網(wǎng)的網(wǎng)絡(luò)。此外，第一協(xié)議可以是會話初始化協(xié)議(SIP)，第二協(xié)議可以是因特網(wǎng)實時協(xié)議(RTP)。
設(shè)置通信優(yōu)選的包括從第一用戶終端接收對于與第二用戶終端進行通信的邀請；搜索第二用戶終端的因特網(wǎng)協(xié)議地址；向第二用戶終端的因特網(wǎng)協(xié)議地址發(fā)送通信邀請；從第二用戶終端接收對于該通信邀請的接受；以及將該接受發(fā)送到第一用戶終端。
優(yōu)選的，用戶終端之間的所述通信是經(jīng)由包括語音和數(shù)據(jù)的多媒體信道建立的。
該報告可以包括呼叫詳情記錄數(shù)據(jù)。
在這種情況下，提供所述報告包括基于呼叫標識符，將所述呼叫詳情記錄數(shù)據(jù)與所述服務(wù)質(zhì)量信息匹配。
所述觸發(fā)事件可以包括與所述通信相關(guān)的參數(shù)超過預(yù)定界限。
另選的或者另外的，所述觸發(fā)事件可以包括通信的終止。
服務(wù)質(zhì)量信息優(yōu)選的是在通信過程中接收的。
所述方法可以進一步包括響應(yīng)于報告的提供，在所述基于分組的網(wǎng)絡(luò)中采取適當動作。
在本發(fā)明的第二方面，本發(fā)明涉及一種監(jiān)控基于分組的網(wǎng)絡(luò)中的服務(wù)質(zhì)量的系統(tǒng)，所述網(wǎng)絡(luò)被配置為在用戶終端之間建立通信，所述用戶終端被配置為提供與所述通信相關(guān)的服務(wù)質(zhì)量信息；所述系統(tǒng)包括訂戶，被配置為發(fā)送對于至少所述用戶終端中的兩個之間的通信的服務(wù)質(zhì)量報告的請求，所述請求包括與服務(wù)質(zhì)量報告的定制相關(guān)的信息；以及質(zhì)量服務(wù)器，被配置為從所述兩個用戶終端接收與所述通信相關(guān)的服務(wù)質(zhì)量信息，以及基于所述服務(wù)質(zhì)量信息和所述定制信息提供所述服務(wù)質(zhì)量報告。
優(yōu)選的，用戶終端適于使用第一協(xié)議提供所述服務(wù)質(zhì)量信息，并且適于使用與所述第一協(xié)議不同的第二協(xié)議建立所述通信。
第一協(xié)議可以是會話初始化協(xié)議(SIP)。
此外，優(yōu)選的，用戶終端適于使用所述第一協(xié)議設(shè)置所述通信。
優(yōu)選的，基于分組的網(wǎng)絡(luò)是基于因特網(wǎng)的網(wǎng)絡(luò)。
有利的，該報告包括從用戶終端接收的服務(wù)質(zhì)量信息。
此外，定制信息可以包括一個或更多個觸發(fā)事件。另外的或者另選的，定制信息可以包括期望的報告格式。
優(yōu)選的，質(zhì)量服務(wù)器包括報告生成器和預(yù)訂登記器，所述預(yù)訂登記器適于登記所述觸發(fā)事件和所述報告格式。
優(yōu)選的，質(zhì)量服務(wù)器適于在所述用戶終端相互通信的同時接收所述服務(wù)質(zhì)量信息。
優(yōu)選的，通信包括語音和數(shù)據(jù)。
有利的，所述用戶終端、所述質(zhì)量服務(wù)器和所述至少訂戶實現(xiàn)了三層架構(gòu)。
在本發(fā)明的另一方面，本發(fā)明涉及能夠?qū)崿F(xiàn)先前描述的方法的軟件程序。


為了更好地理解本發(fā)明，將參照附圖描述只作為示例而非應(yīng)被理解為限制的優(yōu)選實施例，其中圖1是用于監(jiān)控QoS的現(xiàn)有技術(shù)系統(tǒng)的框圖。
圖2是示出根據(jù)美國專利申請2003/0120773號的現(xiàn)有技術(shù)系統(tǒng)的圖。
圖3是示出根據(jù)本發(fā)明的監(jiān)控QoS的系統(tǒng)的框圖。
圖4示出了使用SIP網(wǎng)絡(luò)的圖3的系統(tǒng)的示例實現(xiàn)。
圖5是使用圖3的系統(tǒng)來監(jiān)控QoS的方法的流程圖。
圖6示出了質(zhì)量服務(wù)器的框圖。
具體實施例方式
參照圖3，示出了系統(tǒng)50具有兩個用戶終端52、54，這兩個用戶終端通過收集并發(fā)布QoS信息還用作發(fā)布者。用戶終端可以是任何類型的通信設(shè)備，諸如IP電話、尋呼機、即時消息傳送客戶機、移動電話、手持計算設(shè)備等。用戶終端在任何期望的基于分組的網(wǎng)絡(luò)(總體示為59)上使用任何期望的協(xié)議(如，SIP、H.323、JMS等)，以發(fā)布消息57的形式將QoS信息發(fā)送到質(zhì)量服務(wù)器56(也稱為“事件服務(wù)器”)。如下進一步所述，質(zhì)量服務(wù)器56被配置為從用戶終端接收QoS信息并且據(jù)此生成質(zhì)量報告。質(zhì)量服務(wù)器56還經(jīng)由網(wǎng)絡(luò)耦合到訂戶58，訂戶58適于從質(zhì)量服務(wù)器56請求要通過質(zhì)量報告通知的特定QoS服務(wù)。具體的，訂戶58適于向質(zhì)量服務(wù)器發(fā)送包括與質(zhì)量報告的定制相關(guān)的信息在內(nèi)的預(yù)定請求60。該定制可能包括與用于接收QoS報告的格式類型有關(guān)的信息以及/或者指示要在何時發(fā)送報告的觸發(fā)事件。此外，定制可以通過從一組預(yù)定可能事物中選擇一個來完成，或者定制可以獨立地從頭開始生成。預(yù)訂請求60可以采用取決于應(yīng)用的多種形式，并且可以與單個呼叫、單個用戶、域(來自/到達一域的所有呼叫)等相關(guān)。下面將參照兩個示例性服務(wù)稱為“劣化的QoS通知”的第一服務(wù)，當每次用戶之間的通信質(zhì)量低于期望級別時觸發(fā)；稱為“CDR(呼叫詳情記錄)生成”的第二服務(wù)，其中在一通信的終端處提供包括QoS數(shù)據(jù)在內(nèi)的增強的CDR(一般用于記帳目的)。本領(lǐng)域技術(shù)人員將容易意識到，可以采用許多其它與系統(tǒng)提供服務(wù)的質(zhì)量相關(guān)的信息服務(wù)。
在檢測到觸發(fā)事件時，質(zhì)量服務(wù)器56以62處所示的通知消息，將包括QoS信息并且按照在預(yù)訂請求60中標識的格式類型的報告發(fā)送到訂戶58。在發(fā)布消息57被傳送到質(zhì)量服務(wù)器56的同時，用戶終端52、54使用任何期望的協(xié)議(如RTP)經(jīng)由通信網(wǎng)絡(luò)64進行點到點通信。
該解決方案使用三層層1包括用戶終端52、54；層2包括質(zhì)量服務(wù)器56；層3包括訂戶58。總體而言，這些層之間的通信是使用基于因特網(wǎng)的網(wǎng)絡(luò)完成的，但是也可以使用其它類型的通信技術(shù)。顯然，該三層使得該解決方案可伸縮，從而可以添加附加的質(zhì)量服務(wù)器。質(zhì)量服務(wù)器56通常同時支持許多用戶終端和訂戶，但是為了便于例示，只示出了兩個用戶終端52、54以及單個訂戶58。因為在將報告發(fā)送到訂戶之前質(zhì)量服務(wù)器56只需要存儲歷史數(shù)據(jù)，其中該報告一般是在用戶終端52、54之間的通信終止以后的很短時間內(nèi)進行的，所以進一步實現(xiàn)了可伸縮性。其它優(yōu)點包括不同訂戶可以通過使用簡單的預(yù)定消息60來請求不同的服務(wù)，并且用戶終端可以發(fā)送頻繁的發(fā)布消息，而不是存儲很多歷史數(shù)據(jù)。質(zhì)量服務(wù)器56通過從訂戶58去除(decouple)所發(fā)布的消息57并且通過對訂戶提供其所請求的消息，而用作過濾器。該解決方案的另一優(yōu)點在于可以使用同一協(xié)議進行設(shè)置和消息發(fā)布，如下面所述的。
圖4示出了更具體的示例，其中將基于分組的網(wǎng)絡(luò)78(如，SIP網(wǎng)絡(luò))用作用于用戶終端52、54之間的通信設(shè)置以及用于與質(zhì)量服務(wù)器56的通信的基礎(chǔ)。SIP網(wǎng)絡(luò)包括SIP代理服務(wù)器80以及域登記器和位置服務(wù)82。所示的編號1到11表示事件的正常順序，但是事件可以以不同順序發(fā)生。如通信1處所指示的，訂戶58經(jīng)由代理服務(wù)器80將預(yù)訂消息發(fā)送到質(zhì)量服務(wù)器56。該預(yù)訂消息包括定制信息，如對于所請求服務(wù)的指示、要監(jiān)控的通信(與一個或更多個域、用戶或呼叫關(guān)聯(lián))、觸發(fā)事件和/或期望的報告格式。
假設(shè)對于用戶A與B之間的通信，請求“劣化的QoS通知“和“CDR生成”服務(wù)。還假設(shè)用戶A具有SIP電話，用戶B具有運行軟客戶機的PC，該軟客戶機可以支持語音和視頻。在給電時，用戶52、54都利用ISP的網(wǎng)絡(luò)中的SIP代理服務(wù)器80登記它們的可用性和它們的IP地址。箭頭2到7示出了使用第一協(xié)議設(shè)置通信，總體上示為84。用戶A通過告知SIP代理服務(wù)器80其想要聯(lián)系用戶B，來發(fā)起呼叫(參見箭頭2)。隨后，SIP代理服務(wù)器從域登記器服務(wù)器82請求用戶B的IP地址(參見箭頭3)。域登記器服務(wù)器82利用用戶B的IP地址進行回復(fù)(參見箭頭4)。然后，SIP代理服務(wù)器80中繼用戶A的與用戶B通信的請求(參見箭頭5)，該請求包括用戶A 52想要使用的媒體(此通信可以通過使用會話描述協(xié)議(SDP)來完成)。然后，用戶B 54告知SIP代理服務(wù)器80接受了用戶A的邀請，并且用戶B準備好接收消息(參見箭頭6)。SIP代理服務(wù)器告知用戶A 52該請求被接受(參見箭頭7)，由此建立了SIP會話。然后，用戶52、54建立了使它們能夠交互的點到點實時協(xié)議(RTP)連接(參見箭頭8)。使用第二協(xié)議建立通信信道總體上在86處示出。在通信過程中的任何時間點，用戶A和B使用與用于設(shè)置通信84的協(xié)議相同的協(xié)議來將異步QoS消息(參見箭頭9)發(fā)布到SIP代理服務(wù)器80。SIP代理服務(wù)器將這些消息轉(zhuǎn)發(fā)到質(zhì)量服務(wù)器56。雖然未示出，但是SIP代理服務(wù)器可能還需要從域登記器82請求質(zhì)量服務(wù)器56的IP地址。質(zhì)量服務(wù)器56使用QoS信息來建立報告，并且監(jiān)控QoS數(shù)據(jù)以發(fā)現(xiàn)預(yù)定觸發(fā)事件。示例觸發(fā)事件有用戶之間的通信質(zhì)量是否降至低于期望級別。在這種情況下，質(zhì)量服務(wù)器56將異步消息(參見箭頭11)發(fā)送到訂戶58，以警告訂戶通信故障(“劣化的QoS通知”)。此外，可以采取適當行動作為反饋，諸如加強連接或者限制該同一鏈路上的進一步通信的準入。當用戶52、54之間的通信終止時，將指示通信終止的異步消息(箭頭9)發(fā)送到SIP代理服務(wù)器80。該消息被轉(zhuǎn)發(fā)到質(zhì)量服務(wù)器56(參見箭頭10)，質(zhì)量服務(wù)器56作為響應(yīng)以所請求的格式(“CDR生成”)建立QoS報告。該報告優(yōu)選的包含QoS數(shù)據(jù)和CDR數(shù)據(jù)，通過使用與該通信關(guān)聯(lián)的呼叫id來使這兩個數(shù)據(jù)匹配。然后經(jīng)由代理服務(wù)器80將該報告轉(zhuǎn)發(fā)到訂戶(參見箭頭11)。本領(lǐng)域技術(shù)人員將容易意識到，圖4的系統(tǒng)不必基于SIP代理服務(wù)器。例如，可以使用任何信號傳輸協(xié)議來建立用戶A與B之間的通信。此外，可以將任何異步協(xié)議用于用戶52、54與質(zhì)量服務(wù)器56之間的通信。此外，可以將任何異步協(xié)議用于質(zhì)量服務(wù)器56與訂戶58之間的通信。最后，可以將任何分組媒體傳輸協(xié)議用于用戶A與B之間的通信。雖然圖4總體上示出了單個域，但是該系統(tǒng)可以容易地擴展到多域環(huán)境，如通過在域之間使用重定向服務(wù)器。
圖5示出了用于實現(xiàn)質(zhì)量服務(wù)器56的方法的流程圖。在處理塊90中，方法開始。在處理塊92中，質(zhì)量服務(wù)器56監(jiān)控來自訂戶58的預(yù)定消息。該預(yù)定消息可以定義觸發(fā)事件以及從質(zhì)量服務(wù)器發(fā)送到訂戶的報告格式。質(zhì)量服務(wù)器與訂戶之間的通信一般是異步通信，并且可以采取任何期望格式，但是XML格式的示例預(yù)訂消息可以如下(考慮稱為“topolinia”和“paperopoli”的兩個域)< xml version="1.0"encoding="UTF-8" >
<SUBSCRIBExmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:noNamespaceSchemaLocation="C:\Documents andSettings\00917438\Desktop\ro8\qos throughsip\susbscribe2.xsd>
<Generation_CDR>
<Dominio>topolinia.wd<\Dominio>
<Dominio>paperopoli.wd<\Dominio>
</Generation_CDR>
</SUBSCRIBE>
預(yù)訂消息可以請求呼叫詳情記錄(CDR)，該呼叫詳情記錄通常包括開始時間、結(jié)束時間和用于記帳目的的其它信息。預(yù)訂消息還可以請求關(guān)于用戶之間的通信的任何劣化的立即通知，以使得訂戶可以采取適當?shù)膭幼?。在處理塊94中，質(zhì)量服務(wù)器56監(jiān)控發(fā)布消息。在用戶相互之間進行點到點通信的同時，用戶發(fā)送發(fā)布消息。雖然用戶可以對于發(fā)布消息使用其它協(xié)議，但是可能期望使用與用于通信設(shè)置的協(xié)議相同的協(xié)議，因為用戶將不需要使用對于支持不同協(xié)議所需的外部程序和?？臻g。例如，SIP是可以用于發(fā)布消息和呼叫設(shè)置的協(xié)議。優(yōu)選的，發(fā)布消息是利用可配置參數(shù)發(fā)送的異步消息，并且沒有對網(wǎng)絡(luò)添加相當多業(yè)務(wù)量。包含RTCP信息的XML格式的發(fā)布消息的簡單示例如下< xml version="1.0" encoding="UTF-8" ><notify-publishxmins:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:noNamespaceSSchemaLocation="C:\notify_publish_5.xsd">
<call_id>kj1238921u219</call_id>
<date>2001-10-15T09:41:33</date>
<call_closed>true</call_closed>
<packet_RTCP>
<header>
<IP_address_A>163.162.76.1</IP_address_A>
<IP_address_B>163.162.24.1</IP_address_B>
<PT>200</PT>
</header>
<reportblock>
<cumulative_num_of_pckt_lost>1234</cumulative_num of_pckt_lost>
<interarrival_jitter>45</interarrival_jitter>
</reportblock>
</packet_RTCP><notify-publish>
如果沒有接收到發(fā)布消息，則如95處所示重復(fù)處理。然而，如果接收到發(fā)布消息，則在判決塊96中，質(zhì)量服務(wù)器56對發(fā)布消息進行分析以查看是否存在需要立即通知訂戶58的時間。例如，如果用戶之間通信過程中的服務(wù)質(zhì)量降到低于可接受的級別(例如，由于超過閾值的抖動或者過多數(shù)量的丟失包)，則質(zhì)量服務(wù)器將異步通知消息發(fā)送到訂戶，如處理塊98中所示。該異步通知消息可以是預(yù)訂消息中所請求的報告格式。否則，在處理塊100中，質(zhì)量服務(wù)器分析所發(fā)布的消息，以確定是否終止A與B之間的通信。如果不終止，則處理再次在處理塊92處開始。如果通信已終止，則在處理塊102中，質(zhì)量服務(wù)器按照預(yù)訂消息中所請求的，建立報告。在處理塊104中，報告被異步地發(fā)送到訂戶，并且處理在處理塊106處結(jié)束。雖然未示出，但是該處理再次在監(jiān)控消息的處理塊90處開始。
發(fā)送到訂戶的示例報告可以如下< xml version="1.0"encoding="UTF-8" ><notify-publishxmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:noNamespaceSchemaLocation="C:\notify_publish_5.xsd">
<Service_name>generation CDR<Service_name><call_id>kj1238921u219<call_id><date>2001-10-15T09:41:33</date><call_closed>false</call_closed><packet_RTCP>
<header>
<IP_address_A>163.162.76.16</IP_address_A>
<IP_address_B>163.162.24.145</IP_address_B>
<PT>200</PT>
</header>
<reportblock>
<cumulative_num_of_pckt_lost>524</cumulative_num_of_pckt_lost>
<interarrival_jitter>21</interarrival_jitter>
</reportblock></packet_RTCP></notify-publish>
圖6更具體地示出了質(zhì)量服務(wù)器56。質(zhì)量服務(wù)器通常包括兩個部分報告生成器120和預(yù)訂登記器122。預(yù)訂登記器122存儲與一個和更多個訂戶相關(guān)的預(yù)訂列表124。每個預(yù)訂包括諸如報告格式126和觸發(fā)事件128的預(yù)訂信息。報告生成器120分析來自用戶終端的到來的發(fā)布消息，并且使用發(fā)布消息來生成按照預(yù)訂登記器的報告。該報告發(fā)生器還監(jiān)控發(fā)布消息以發(fā)現(xiàn)觸發(fā)事件。為了完成報告，報告發(fā)生器將用戶與列表124中的預(yù)訂之一關(guān)聯(lián)。然后，報告發(fā)生器使用來自預(yù)訂登記器的預(yù)訂信息來以訂戶期望的格式生成報告。該報告通常在用戶之間的通信終止時發(fā)送。然而，訂戶可以通過在預(yù)訂登記器中設(shè)置觸發(fā)事件來控制何時發(fā)送報告。
術(shù)語“設(shè)置”通信通常用于指呼叫設(shè)置或資源預(yù)留。
很清楚，可以對于本發(fā)明進行各種修改和變型，所有這些都落在所附權(quán)利要求所限定的本發(fā)明的范圍之內(nèi)。
具體的，雖然具體參考SIP事件結(jié)構(gòu)描述了本發(fā)明，但是本領(lǐng)域技術(shù)人員將意識到，可以使用任何其它有效軟件技術(shù)以允許以有效并可執(zhí)行的方式實現(xiàn)三層事件結(jié)構(gòu)，該三層事件結(jié)構(gòu)能夠從網(wǎng)絡(luò)終端向中間元件(諸如質(zhì)量服務(wù)器)發(fā)布QoS數(shù)據(jù)；預(yù)訂駐留在中間元件中的服務(wù)。該預(yù)訂可以是從QoS應(yīng)用(訂戶)向中間元件進行的，并且涉及中間元件所實現(xiàn)的一個或更多個特定服務(wù)。
被通知由中間元件中的特定邏輯生成的取決于特定服務(wù)的事件?？梢赃x擇性方式從中間元件向預(yù)訂該服務(wù)的QoS應(yīng)用進行所述通知。
這些軟件技術(shù)的示例有JMS(使用Java API)和Web服務(wù)(使用XML)。
權(quán)利要求
1.一種監(jiān)控基于分組的網(wǎng)絡(luò)中的服務(wù)質(zhì)量的方法，所述網(wǎng)絡(luò)適于在用戶終端之間建立通信，所述方法包括以下步驟的組合請求對于至少所述用戶終端中的兩個之間的通信的服務(wù)質(zhì)量報告，其中所述請求包括提供與服務(wù)質(zhì)量報告的定制相關(guān)的信息；從所述兩個用戶終端接收與所述通信相關(guān)的服務(wù)質(zhì)量信息；以及基于所述服務(wù)質(zhì)量信息和所述定制信息提供所述報告。
2.根據(jù)權(quán)利要求1所述的方法，進一步包括提供多個通知服務(wù)，所述多個通知服務(wù)中的每一個包括提供至少各個服務(wù)質(zhì)量報告。
3.根據(jù)權(quán)利要求2所述的方法，其中請求服務(wù)質(zhì)量報告包括預(yù)訂所述多個通知服務(wù)中的一個。
4.根據(jù)權(quán)利要求1所述的方法，其中服務(wù)質(zhì)量信息是使用第一協(xié)議接收的，并且所述通信是使用與所述第一協(xié)議不同的第二協(xié)議建立的。
5.根據(jù)權(quán)利要求4所述的方法，進一步包括，在建立所述通信之前，使用所述第一協(xié)議設(shè)置所述通信。
6.根據(jù)權(quán)利要求1所述的方法，其中定制信息包括指定與所述通信相關(guān)的一個或更多個觸發(fā)事件，并且其中所述報告是響應(yīng)于觸發(fā)事件而提供的。
7.根據(jù)權(quán)利要求1所述的方法，其中定制信息包括指定期望的報告格式，并且其中所述報告是以所述報告格式提供的。
8.根據(jù)權(quán)利要求3所述的方法，其中預(yù)訂通知服務(wù)包括指定期望的報告格式以及用于提供所述報告的一個或更多個觸發(fā)事件。
9.根據(jù)權(quán)利要求1所述的方法，其中基于分組的網(wǎng)絡(luò)是基于因特網(wǎng)的網(wǎng)絡(luò)。
10.根據(jù)權(quán)利要求4所述的方法，其中第一協(xié)議是會話初始化協(xié)議(SIP)。
11.根據(jù)權(quán)利要求4所述的方法，其中第二協(xié)議是因特網(wǎng)實時協(xié)議(RTP)。
12.根據(jù)權(quán)利要求5所述的方法，其中設(shè)置所述通信包括從第一用戶終端接收對于與第二用戶終端進行通信的邀請；搜索第二用戶終端的因特網(wǎng)協(xié)議地址；向第二用戶終端的因特網(wǎng)協(xié)議地址發(fā)送通信邀請；從第二用戶終端接收對于該通信邀請的接受；以及將該接受發(fā)送到第一用戶終端。
13.根據(jù)權(quán)利要求1所述的方法，其中所述通信是經(jīng)由包括語音和數(shù)據(jù)的多媒體信道建立的。
14.根據(jù)權(quán)利要求1所述的方法，其中所述報告包括呼叫詳情記錄數(shù)據(jù)。
15.根據(jù)權(quán)利要求14所述的方法，其中提供所述報告包括基于呼叫標識符，將所述呼叫詳情記錄數(shù)據(jù)與所述服務(wù)質(zhì)量信息匹配。
16.根據(jù)權(quán)利要求6所述的方法，其中所述觸發(fā)事件包括與所述通信相關(guān)的參數(shù)超過預(yù)定界限。
17.根據(jù)權(quán)利要求6所述的方法，其中所述觸發(fā)事件包括通信的終止。
18.根據(jù)權(quán)利要求1所述的方法，其中所述服務(wù)質(zhì)量信息是在所述通信過程中接收的。
19.根據(jù)權(quán)利要求1所述的方法，進一步包括響應(yīng)于報告的提供，在所述基于分組的網(wǎng)絡(luò)中采取適當動作。
20.一種監(jiān)控基于分組的網(wǎng)絡(luò)(59，78)中的服務(wù)質(zhì)量的系統(tǒng)，所述網(wǎng)絡(luò)被配置為在用戶終端(52，54)之間建立通信，所述用戶終端被配置為提供與所述通信相關(guān)的服務(wù)質(zhì)量信息；所述系統(tǒng)包括訂戶(58)，被配置為發(fā)送對于至少所述用戶終端中的兩個之間的通信的服務(wù)質(zhì)量報告的請求，所述請求包括與服務(wù)質(zhì)量報告的定制相關(guān)的信息；以及質(zhì)量服務(wù)器(56)，被配置為從所述兩個用戶終端接收與所述通信相關(guān)的服務(wù)質(zhì)量信息，以及基于所述服務(wù)質(zhì)量信息和所述定制信息提供所述服務(wù)質(zhì)量報告。
21.根據(jù)權(quán)利要求20所述的系統(tǒng)，其中用戶終端適于使用第一協(xié)議提供所述服務(wù)質(zhì)量信息，并且適于使用與所述第一協(xié)議不同的第二協(xié)議建立所述通信。
22.根據(jù)權(quán)利要求21所述的系統(tǒng)，其中所述用戶終端(52，54)適于使用所述第一協(xié)議設(shè)置所述通信。
23.根據(jù)權(quán)利要求20到22中任何一個所述的系統(tǒng)，其中基于分組的網(wǎng)絡(luò)(59，78)是基于因特網(wǎng)的網(wǎng)絡(luò)。
24.根據(jù)權(quán)利要求20到23中任何一個所述的系統(tǒng)，其中所述報告包括從用戶終端接收的服務(wù)質(zhì)量信息。
25.根據(jù)權(quán)利要求20到24中任何一個所述的系統(tǒng)，其中定制信息包括一個或更多個觸發(fā)事件。
26.根據(jù)權(quán)利要求25所述的系統(tǒng)，其中定制信息包括期望的報告格式。
27.根據(jù)權(quán)利要求26所述的系統(tǒng)，其中質(zhì)量服務(wù)器(56)包括報告生成器(120)和預(yù)訂登記器(122)，所述預(yù)訂登記器適于登記所述觸發(fā)事件和所述報告格式。
28.根據(jù)權(quán)利要求21所述的系統(tǒng)，其中第一協(xié)議是會話初始化協(xié)議(SIP)。
29.根據(jù)權(quán)利要求20到28中任何一個所述的系統(tǒng)，其中質(zhì)量服務(wù)器(56)適于在所述用戶終端相互通信的同時接收所述服務(wù)質(zhì)量信息。
30.根據(jù)權(quán)利要求20到29中任何一個所述的系統(tǒng)，其中所述通信包括語音和數(shù)據(jù)。
31.根據(jù)權(quán)利要求20到30中任何一個所述的系統(tǒng)，其中所述用戶終端(52，54)、所述質(zhì)量服務(wù)器(56)和所述至少訂戶(58)實現(xiàn)了三層架構(gòu)。
32.一種能夠?qū)崿F(xiàn)根據(jù)權(quán)利1到19中任何一個所述的方法的軟件程序。
全文摘要
公開了一種監(jiān)控基于分組的網(wǎng)絡(luò)(59，78)中的服務(wù)質(zhì)量的方法和系統(tǒng)，該方法和系統(tǒng)包括三層架構(gòu)，其中一個或更多個應(yīng)用可以從質(zhì)量服務(wù)器請求定制的QoS報告。所定制的報告可以包括例如期望的報告格式或者觸發(fā)事件，其指示所述一個或更多個應(yīng)用應(yīng)當何時接收報告。質(zhì)量服務(wù)器基于從用戶終端接收的QoS消息準備這些報告，并根據(jù)請求發(fā)送報告。
文檔編號H04L12/14GK101053204SQ200480044146
公開日2007年10月10日 申請日期2004年8月20日 優(yōu)先權(quán)日2004年8月20日
發(fā)明者朱塞佩·德諾亞, 安托尼奧·福斯庫, 安德瑞·羅斯奧 申請人:意大利電信股份公司