專利名稱：減少通信服務(wù)器之間需要的存儲器使用的系統(tǒng)和方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信系統(tǒng)。更具體而言，并且不是通過限制的方式，本 發(fā)明針對減少在通信網(wǎng)絡(luò)的服務(wù)器之間進(jìn)行通信的兩端上的存儲器使 用的系統(tǒng)和方法。
背景技術(shù)：
在諸如IP多媒體子系統(tǒng)(IP Multimedia Subsystem, IMS )網(wǎng)絡(luò)之類 的使用會話發(fā)起協(xié)議(Session Initiation Protocol, SIP )的通信網(wǎng)絡(luò)中， 使用SIP SUBSCRIBE消息來預(yù)訂屬于IMS網(wǎng)絡(luò)中的用戶的狀態(tài)的改變。 當(dāng)用戶狀態(tài)(User state)改變時，從通知服務(wù)器發(fā)送SIP NOTIFY消息 到預(yù)訂用戶。在IMS網(wǎng)絡(luò)中，由于縮放的原因，存在多個SIP應(yīng)用服務(wù) 器(AS),每個服務(wù)器服務(wù)域中的多個用戶。用戶到AS的某示例的分 配由IMS網(wǎng)絡(luò)來處理，且預(yù)訂AS ( Subscribing AS )不知道哪個通知 AS (Notifying AS )包含用戶狀態(tài)。為了找到正確的通知AS，預(yù)訂AS 發(fā)送SUBSCRIBE消息到IMS核心網(wǎng)，該核心網(wǎng)又將該消息路由到正確 的通知AS。
根據(jù)RFC3265，有可能使用事件標(biāo)頭(Event-header)的現(xiàn)有"id" 參數(shù)，以便在一次對話中具有多個預(yù)訂。但是，仍然需要大容量的存儲 器來存儲SIP對話。 一個原因是使用"id"參數(shù)意味著相同的對話中的 預(yù)訂必須共享相同的觀察者和目標(biāo)，原因在于除使用到和來自對話的標(biāo) 頭之外沒有辦法標(biāo)識它們。因此，這使得對于不同的觀察者和目標(biāo)的預(yù) 訂而言，不可能使用相同的對話。因此，必須在預(yù)訂AS與通知AS之 間建立多個SIP對話。在預(yù)訂的有效期期間，這些對話;故保持。對話可
6以在延長的時間段內(nèi)存在，即使在預(yù)訂的有效期期間，發(fā)送的NOTIFY 消息的數(shù)目可能相當(dāng)?shù)男?，。還常常存在對實(shí)時發(fā)送NOTIFY消息的需 要。因此，不優(yōu)選基于拉(pull-based)的解決方案。
以這種方式來處理的狀態(tài)的示例是如IETF、 3GPP和OMA標(biāo)準(zhǔn)所 限定的Presence和XCAP文檔《奮改。
現(xiàn)有的解決方案強(qiáng)制預(yù)訂和通知AS為每用戶和AS的預(yù)訂對話保 持一個狀態(tài)。每個對話需要一些存儲器使用。例如，假設(shè)在IMS域中有 一百萬個用戶且每AS分配100000個用戶，這意味著存在十個預(yù)訂AS 和十個通知AS。如果每個用戶預(yù)訂另一個用戶，則將存在一百萬個SIP 對話。舉例來說，如果每個對話需要每AS2K字節(jié)的基本存儲器，則對 于這些對話，將需要總共2G字節(jié)的存儲器。如果假設(shè)每個用戶預(yù)訂十 個其它用戶，如資源列表服務(wù)器(Resource List Server, RLS )與存在服 務(wù)器(Presence Server, PS )之間可能的情況一樣，則將需要20G字節(jié)的 存儲器，如此類推。
因此，能夠看出在RLS與存在服務(wù)器以及RLS/PS與不同XML文 檔管理服務(wù)器(XDMS)之間建立的會話數(shù)目可能非常高，并且使用的 聯(lián)系人(contact)越多，需要的會話就越多。在這種情況下，存儲器使 用是比每秒交易數(shù)目更大的問題，因?yàn)榧僭O(shè)NOTIFY消息的頻率將相當(dāng) 低。
在本領(lǐng)域中需要的是用于減少存儲S IP對話所需的存儲器量的系統(tǒng) 和方法。本發(fā)明提供了這樣的系統(tǒng)和方法。

發(fā)明內(nèi)容
在一個實(shí)施例中，本發(fā)明提供了一種方法，通過該方法，將針對某 事件包的單個SIP隧道用于資源列表服務(wù)器(RLS)的一個實(shí)例與諸如 像存在服務(wù)器之類的應(yīng)用服務(wù)器的 一個實(shí)例之間的多個預(yù)訂。于是使用 SIP隧道在這兩個實(shí)體之間發(fā)送所有的SIP NOTIFY消息以通過去除由 SIP產(chǎn)生的開銷來減少這兩端處的存儲器使用。
本發(fā)明減少所述系統(tǒng)中支持諸如RLS之類的SIP SUBSCRIBE探險 者(exploder)的功能所需的SIP對話數(shù)目。由于每個SIP對話需要分配 相當(dāng)大數(shù)量的諸如存儲器和磁盤空間之類的資源，本發(fā)明顯著減少了所 需硬件的量。本發(fā)明在大量聯(lián)系人列表的情況下特別有價值，其中當(dāng)使用標(biāo)準(zhǔn)化SIP信令時建立的會話的數(shù)目量非常大。本發(fā)明比現(xiàn)有的解決 方案好得多地縮放，聯(lián)系人列表的大小并不以與現(xiàn)有技術(shù)解決方案相同 的方式顯著地影響系統(tǒng)的尺寸確定。
一方面，本發(fā)明針對 一 種減少在通信網(wǎng)絡(luò)中進(jìn)行通信的第 一 和第二 服務(wù)器中的存儲器使用的方法。該方法包括在第 一和第二服務(wù)器的實(shí)例
之間建立對話；以及使用所建立的對話在第一和第二服務(wù)器的實(shí)例之間 隧穿(tunnel)所有Notify消息。通過這種方式，減少了第一和第二服 務(wù)器之間的對話數(shù)目以及相關(guān)聯(lián)的存儲器使用。
另 一方面，本發(fā)明針對一種向多個應(yīng)用服務(wù)器提供多個預(yù)訂的請求 服務(wù)器。該請求服務(wù)器包括從用戶接收用于請求預(yù)訂聯(lián)系人列表中的多 個資源的預(yù)訂請求的裝置；用于為聯(lián)系人列表中的每個資源標(biāo)識應(yīng)用服 務(wù)器的裝置；用于發(fā)送預(yù)訂請求到所標(biāo)識的應(yīng)用服務(wù)器的裝置，該預(yù)訂 請求包括請求服務(wù)器支持隧穿的指示；以及用于從所標(biāo)識的應(yīng)用服務(wù)器 之一接收指示所標(biāo)識的應(yīng)用服務(wù)器也支持隧穿的響應(yīng)的裝置。所述請求 服務(wù)器還包括用于確定所標(biāo)識的應(yīng)用服務(wù)器是否已具有與第一應(yīng)用服 務(wù)器的現(xiàn)有隧道的裝置；以及用于確定響應(yīng)消息是否指示建立的隧道已 存在于請求服務(wù)器與所標(biāo)識的應(yīng)用服務(wù)器之間的邏輯。如果建立的隧道 尚未存在于請求服務(wù)器與所標(biāo)識的應(yīng)用服務(wù)器之間，則請求服務(wù)器建立 新的隧道。如果建立的對話已經(jīng)存在，則請求服務(wù)器使用現(xiàn)有已建立隧 道來支持所請求的預(yù)訂。
另 一 方面，本發(fā)明針對 一 種在通信網(wǎng)絡(luò)中通過預(yù)訂來提供資源給請 求服務(wù)器的應(yīng)用服務(wù)器。該應(yīng)用服務(wù)器包括用于從請求服務(wù)器接收預(yù)訂 請求的裝置，該預(yù)訂請求包括該請求服務(wù)器支持隧穿的指示；以及用于 確定應(yīng)用服務(wù)器是否支持隧穿且如果支持，則確定隧道是否已存在于應(yīng) 用服務(wù)器與請求服務(wù)器之間的裝置。該應(yīng)用服務(wù)器還包括用于如果應(yīng)用 服務(wù)器不支持隧穿則發(fā)送第一類型的響應(yīng)到請求服務(wù)器的裝置；用于如 果應(yīng)用服務(wù)器支持隧穿且在應(yīng)用服務(wù)器和請求服務(wù)器之間已經(jīng)存在隧 道則發(fā)送第二類型的響應(yīng)到請求服務(wù)器的裝置；以及用于如果應(yīng)用服務(wù) 器支持隧穿但是在應(yīng)用服務(wù)器和請求服務(wù)器之間尚未存在隧道則發(fā)送 第三類型的響應(yīng)到請求服務(wù)器的裝置。


在下文中，將參考附圖、通過示出優(yōu)選實(shí)施例來詳細(xì)地描述本發(fā)明
的基本特征，在附圖中
圖1是圖示本發(fā)明的方法的第一示例性實(shí)施例的步驟的流程圖； 圖2是圖示本發(fā)明的方法的第二示例性實(shí)施例的步驟的流程圖，在
該實(shí)施例中使用新的事件包來建立SIP隧道；
圖3是圖示本發(fā)明的方法的第三示例性實(shí)施例的步驟的流程圖；以
及
圖4是本發(fā)明的系統(tǒng)的示例性實(shí)施例的簡化框圖。
具體實(shí)施例方式
圖l是示出了本發(fā)明的笫一示例性實(shí)施例的步驟的流程圖。在步驟 11,在資源列表服務(wù)器(RLS)的一個實(shí)例與諸如像存在服務(wù)器之類的 應(yīng)用服務(wù)器的一個實(shí)例之間為某事件包(event package )建立單個SIP SUBSCRIBE對話。在步驟12,然后4吏用此對話來隧穿此單個對話內(nèi)部 的這兩個實(shí)體之間的所有SIP NOTIFY消息以通過消除SIP所產(chǎn)生的開 銷來減少在這兩端的存儲器使用。本發(fā)明對于任何類型的SUBSCRIBE 探險者和相應(yīng)的NOTIFY服務(wù)器、或任何類型的具有面向另一應(yīng)用服務(wù) 器的多個預(yù)訂的應(yīng)用服務(wù)器是通用的。本實(shí)施例利用具有某些擴(kuò)展的現(xiàn) 有SIP協(xié)議，這種擴(kuò)展引起一種解決方案與現(xiàn)有"非隧道"服務(wù)器的 向后兼容。
本發(fā)明減少在IMS網(wǎng)絡(luò)中使用的存儲器的量。每對預(yù)訂AS和通知 AS使用一個對話。單個對話被用來隧穿所有的NOTIFY消息。在其中 IMS域中存在一百萬個用戶且每個用戶預(yù)訂另一個用戶的上述實(shí)例中， 當(dāng)使用現(xiàn)有過程時，存在一百萬個對話，這些對話將需要2G字節(jié)的存 儲器。本發(fā)明將對話的數(shù)量減少至僅100個對話，每個對話使用2K字 節(jié)的基本數(shù)據(jù)。因此，總共僅需要200K字節(jié)的存儲器。對于每個用戶 對話，需要額外的0.1K字節(jié)。因此作為如現(xiàn)有技術(shù)中每新預(yù)訂增加2K 字節(jié)的替代，本發(fā)明對于每個新的預(yù)訂僅增加0.2K字節(jié)。
此外，本發(fā)明使用現(xiàn)有的IMS/SIP路由過程來找到通知AS。如果 在這兩個實(shí)例之間已經(jīng)存在對話，則本發(fā)明通知預(yù)訂AS:對于此特定 預(yù)定，將在現(xiàn)有的"公共"對話中而不是在單獨(dú)的對話中發(fā)送NOTIFY 消息。本發(fā)明還可以減少由于刷新過程而引起的SIP SUBSCRIBE消息的 數(shù)目，原因在于在某些情況下，只有一個對話需要被刷新。因此，也節(jié) 約了處理器資源。
圖2是圖示本發(fā)明方法的第二示例性實(shí)施例的步驟的流程圖，其中， 使用新的事件包來建立SIP隧道。在步驟21,用戶設(shè)備(UE)發(fā)送SIP SUBSCRIBE請求到RLS實(shí)例以請求創(chuàng)建預(yù)訂。在步驟22, RLS找到預(yù) 訂的目標(biāo)，且在步驟23, RLS和該目標(biāo)協(xié)商對SIP隧穿的支持。在步驟 24,在用戶代理客戶端(User Agent Client, UAC )與用戶代理服務(wù)器(User Agent Server, UAS )實(shí)例之間創(chuàng)建SIP隧道。在步驟25，使用SIP隧道 來發(fā)送與不同的預(yù)訂有關(guān)的消息。
圖3是圖示本發(fā)明方法的笫三示例性實(shí)施例的步驟的流程圖。舉例 來說，把該應(yīng)用服務(wù)器作為存在服務(wù)器，不過其它類型的應(yīng)用服務(wù)器也 同樣可適用。在步驟31, UE發(fā)送SIP SUBSCRIBE請求到RLS實(shí)例以 通過使用指向聯(lián)系人列表的具體URI來請求創(chuàng)建到多個資源的預(yù)訂。 IMS核心網(wǎng)將該請求路由到RLS實(shí)例，在該RLS實(shí)例處將處理所述聯(lián) 系人列表。在步驟32, RLS解析所請求的聯(lián)系人列表。在步驟33, RLS 實(shí)例為聯(lián)系人列表中的資源而發(fā)送SIP SUBSCRIBE請求到每個存在服 務(wù)器(PS)以請求為該聯(lián)系人列表中的每個資源創(chuàng)建一個后端預(yù)訂。RLS 將有關(guān)其支持SIP隧穿的能力的信息包括在請求中，并標(biāo)識該請求RLS 實(shí)例。此信息例如可以是諸如"x-sip-tunneling"的新標(biāo)頭。實(shí)際存在后 端預(yù)訂的協(xié)商也可以被包括在所述請求中，在這種情況下，還包括希望 的預(yù)訂屆滿時間和后端預(yù)訂的唯一 ID。
在步驟34, IMS核心網(wǎng)基于請求URI中的信息照常將每個SIP SUBSCRIBE請求路由到正確的PS實(shí)例。在步驟35, PS接收SIP SUBSCRIBE請求并通過檢查"x-sip-tunneling"標(biāo)頭來檢測RLS支持SIP 隧穿的能力。在步驟36;確定PS是否也支持SIP隧穿。如果PS不支持 SIP隧穿，則所述方法移到步驟37,在該步驟37PS發(fā)送指示PS不支持 SIP隧穿的響應(yīng)到RLS。例如，PS可以發(fā)送不包括"x-sip-tunneling"標(biāo) 頭的響應(yīng)。在步驟38, RLS照常繼續(xù)并建立后端預(yù)訂而不進(jìn)行隧穿。應(yīng) 該注意到不支持SIP隧穿的外部PS將不識別SIP SUBSCRIBE請求中的 "x畫sip-tunneling，，標(biāo)頭，所以在其響應(yīng)中將不返回x-sip-tunneling標(biāo)頭。 因此，RLS將建立正常的后端預(yù)訂。如果在步驟36確定PS支持SIP隧穿，則所述方法轉(zhuǎn)到步驟39，在 該步驟39PS確定它是否已具有與請求RLS的現(xiàn)有已建立隧道。這可以 例如通過檢查SIP SUBSCRIBE請求中的"聯(lián)系人"標(biāo)頭值和針對客戶 端的現(xiàn)有隧道比較該聯(lián)系人標(biāo)頭值與該客戶端的地址來完成。如果PS 有與該RLS的現(xiàn)有已建立隧道，則所述方法轉(zhuǎn)到步驟41,在該步驟41 PS 創(chuàng)建并存儲一皮請求的預(yù)訂和面向RLS的現(xiàn)有已建立隧道之間的關(guān)系。在 步驟42, PS發(fā)送響應(yīng)到RLS并包括在RLS和PS之間已經(jīng)存在有效預(yù) 訂的指示。然后RLS等待初始通知到達(dá)。在步驟43,使用現(xiàn)有的SIP 隧道來在RLS和PS之間隧穿所有SIP NOTIFY消息。
在可替換實(shí)施例中，如果PS具有與此RLS的現(xiàn)有已建立隧道，則 所述方法轉(zhuǎn)到步驟44，在該步驟44 PS用新創(chuàng)建的隧道來取代現(xiàn)有的隧 道。如果能夠成功地創(chuàng)建新的隧道，則PS還基于所包括的參數(shù)來創(chuàng)建 存在預(yù)訂并將該預(yù)定捆綁到所迷隧道。PS返回200 OK到RLS以指示隧 道已經(jīng)被創(chuàng)建。優(yōu)選地，在預(yù)訂專用標(biāo)頭中發(fā)送與預(yù)訂相聯(lián)系的任何錯 誤以避免使不知道SIP隧穿的代理混淆。
如果在步驟39確定PS不具有與該RLS的現(xiàn)有已建立隧道，則如下 所述PS不創(chuàng)建預(yù)訂，原因在于RLS將創(chuàng)建新的SIP隧道并將預(yù)訂捆綁 到該隧道。該預(yù)訂是臨時的，并且僅僅被用于隧道協(xié)商和找到PS的實(shí) 例。所述方法轉(zhuǎn)到步驟45，在該步驟45 PS向RLS返回指示PS支持SIP 隧穿的響應(yīng)。在一個實(shí)施例中，PS例如把"301永久性移動(301 Moved Permanently)"消息返回到RLS,該消息包括支持sip-tunneling的信息。 例如，PS可以將標(biāo)頭"x-sip-tu皿eling" 包括在到RLS的301響應(yīng)消息 中。PS任選地可以包括隧道當(dāng)前不存在的指示。
在步驟46, RLS接收響應(yīng)并識別到PS支持SIP隧穿。RLS可以利 用被PS放置在301響應(yīng)消息的聯(lián)系人標(biāo)頭中的可選信息來確定隧道是 否已經(jīng)存在?？商鎿Q地，該響應(yīng)可以不包括關(guān)于隧道存在的信息。作為 替代，RLS可以針對RLS的現(xiàn)有隧道來檢查聯(lián)系人標(biāo)頭。如果隧道尚未 存在，則所述方法轉(zhuǎn)到步驟47,在該步驟47RLS創(chuàng)建隧道且只要任何 RLS預(yù)訂存在就保持該隧道，這需要面向該P(yáng)S實(shí)例的后端預(yù)訂(或直 到系統(tǒng)被重新啟動)。此SUBSCRIBE請求是例如使用被稱為
"presence.sip-tunneling"的新事件包來創(chuàng)建存在隧道的請求。此初始請 求創(chuàng)建隧道并且還可以在具體標(biāo)頭中包括創(chuàng)建存在預(yù)訂以避免額外信令的信息。"屆滿"標(biāo)頭包括所配置的"SIP隧道屆滿值"。
在這點(diǎn)上，RLS和PS這二者具有RLS實(shí)例與PS實(shí)例之間的預(yù)訂 對話關(guān)系。在該特定RLS/PS實(shí)例對之間創(chuàng)建的任何新預(yù)訂將使用相同 的建立的對話和相應(yīng)的隧道。每當(dāng)發(fā)送與預(yù)訂相關(guān)的請求時，它都使用 相應(yīng)的隧道。在這種情況下標(biāo)準(zhǔn)SIP標(biāo)頭被用于與該隧道有關(guān)的信息， 且具體標(biāo)頭和主體信息被用于與該預(yù)訂相關(guān)的信息。
如果RLS接收到來自客戶端的預(yù)訂刷新請求，則RLS照常繼續(xù)并 刷新面向PS的預(yù)訂。應(yīng)該注意到如果現(xiàn)有對話的剩余時間短于接收到 的預(yù)訂的屆滿時間，則RLS僅刷新面向PS的SIP隧道預(yù)訂。RLS可以 以不同的方式來處理隧道的刷新，諸如
1. 自動刷新SIP隧道-在這種解決方案中，只要在RLS和PS之間 存在任何預(yù)訂，則RLS/PS通過使用可配置的屆滿時間(在RLS和PS 這二者中是相同的)但不發(fā)送刷新消息來刷新SIP隧道。
2. 當(dāng)預(yù)訂被刷新/創(chuàng)建時刷新SIP隧道-在這種情況下，當(dāng)使用可 配置的屆滿時間來創(chuàng)建/刷新后端預(yù)訂時刷新SIP隧道。
3. 明確地刷新SIP隧道-只要任何后端預(yù)訂存在，則在RLS中使 用單獨(dú)的線程來刷新SIP隧道。當(dāng)RLS希望刷新SIP隧道時，RLS不在 刷新消息中包括"x-sub-data"標(biāo)頭。然而，當(dāng)在后端預(yù)訂中發(fā)生任何改 變時，包括該x-sub-data標(biāo)頭。
RLS刷新后端預(yù)訂并包括具體的后端預(yù)訂的ID。如果只有SIP隧道 要被刷新，則RLS不包括具體的后端預(yù)訂的ID。
當(dāng)XCAP的預(yù)訂改變時，例如特別是如果XDMS和AS未被協(xié)同定 位時，SIP隧穿功能也是非常有用的。還可以避免特定預(yù)訂上的定時器 的使用，僅僅在SIP隧道上使用定時器。
對于每個存在預(yù)訂，具有單獨(dú)的定時器是必要的，原因在于需要向 客戶端發(fā)送最終通知以指示預(yù)訂已被終止。另外，存儲器節(jié)省量將會大 得多并會降低定時器復(fù)雜性。在一個實(shí)施例中，在PS中不使用定時器， 原因在于當(dāng)預(yù)訂到時時，RLS終止所有后端預(yù)訂。這種方法的缺陷在于 在PS可能存在"懸掛"預(yù)訂。然而，可以執(zhí)行具體的清理(clean-up) 線程來去除經(jīng)過了屆滿時間的所有預(yù)訂。
本發(fā)明達(dá)到的存儲器節(jié)省量取決于聯(lián)系人(即存在體(presentities)) 在不同的地址(處理器)上的分布。例如，從RLS的角度來看，如果所有聯(lián)系人定位在相同的處理器上，則就達(dá)到了最大的存儲器節(jié)約量。隨 著越來越多的聯(lián)系人位于不同的處理器上，節(jié)省量越來越少。
以下部分提供了示例模式。在請求模式中，解決方案的基礎(chǔ)是使用 現(xiàn)有的SIP協(xié)議來找到具有少量擴(kuò)展的存在服務(wù)器的正確實(shí)例，這些擴(kuò) 展產(chǎn)生了與現(xiàn)有的"非隧道"服務(wù)器的向后兼容的解決方案。使用被稱
為"x-sip-tunneling"的新標(biāo)頭來協(xié)商對SIP隧穿的支持。應(yīng)該注意到如 果它不是RFC的一部分，則不允許將所支持的標(biāo)頭用于專有的擴(kuò)展。然 而，如果將來需要，這能夠作為擴(kuò)展而被提出。有關(guān)發(fā)送請求的RLS實(shí) 例(IP地址/端口)的信息照常被包括在預(yù)訂請求的聯(lián)系人標(biāo)頭中。
當(dāng)找到存在服務(wù)器的實(shí)例時，RLS建立面向PS實(shí)例的隧道以使用 RLS和PS服務(wù)器地址作為To/From (向/從)信息來創(chuàng)建SIP對話。由 于這些消息中的信息不同于標(biāo)準(zhǔn)的存在事件包，所以優(yōu)選使用例如被稱 為 "presence.sip-tunneling"的新事件包。規(guī)定所述應(yīng)用的原因在于它 可以被用于若干應(yīng)用(諸如從AS到XDMS的預(yù)訂)并因此指出正確的 應(yīng)用是必要的。
有關(guān)具體預(yù)訂的信息被包括在SIP SUBSCRIBE/SIP NOTIFY請求的 具體標(biāo)頭中以及對這些請求的響應(yīng)中。這意。木著SIP請求包括與SIP隧 道有關(guān)的信息以及與個別預(yù)訂有關(guān)的信息。這樣，可以在不影響任何代 理的情況下，在端點(diǎn)應(yīng)用(例如RLS與PS)之間交換信息。應(yīng)該注意 到代理必須能夠基于請求中的IP地址/端口來處理標(biāo)準(zhǔn)路由。代理還必 須能夠處理新的事件包。還應(yīng)該注意到請求/響應(yīng)總是包括標(biāo)識該具體預(yù) 定的具體的"x-sub-data'，。
SIP隧道預(yù)訂請求。與使用隧道的預(yù)訂有關(guān)的預(yù)訂請求可以是刷新 或終止請求，原因在于初始預(yù)訂使用標(biāo)準(zhǔn)的存在預(yù)訂。對于預(yù)訂請求， RLS使用Request-URI和To標(biāo)頭中的接收到的聯(lián)系人地址。RLS還在 P國Asserted-Identity以及From標(biāo)頭中包括RLS實(shí)例(TP )的聯(lián)系人地址。 可替換地，在To、 From、和P-Asserted-Identity中可以使用其它信息， 然后通常僅在Request-URI和聯(lián)系人(Contact)中使用聯(lián)系人信息。預(yù) 訂請求還包括"presence.sip-tunneling"事件包，并優(yōu)選使用具體的標(biāo)頭 "x-sub-data"來傳達(dá)有關(guān)預(yù)訂的所有信息。例如，x-sub-data標(biāo)頭可以 采取"x-sub-data: To = a, From = b, Expires = x, sub-id = y，， 的形式。 這比對于每個參數(shù)使用一個標(biāo)頭提供了更加緊湊的格式。然而，作為替
13(1) 具體的"x"標(biāo)頭，指示實(shí)際預(yù)訂的To和From信息，即包括 在第一存在預(yù)訂中以把該請求路由到正確PS實(shí)例的信息。此信息例如 對于故障查找是重要的。
(2) 指示預(yù)訂的希望屆滿值的"x-sub-expires"(如果預(yù)訂被終止， 則該值為"0")。
(3) 指示該具體預(yù)訂的"x畫sub-id"。
SIP隧道預(yù)訂響應(yīng)。除標(biāo)準(zhǔn)信息之外，SIP預(yù)訂響應(yīng)包括預(yù)訂的具體 信息。優(yōu)選地，使用具體的標(biāo)頭"x-sub-data"來傳達(dá)關(guān)于預(yù)訂的所有信 息、。會寸長口， x國sub國data才示頭可以采取"x-sub國data: To = a, From = b, Expires =x, Response-code = xxx sub-id = y"的形式?？商鎿Q地，針對每個參數(shù) 所述響應(yīng)可以包括一個標(biāo)頭，諸如指示相關(guān)預(yù)訂的"x-sub-id"、指示為 預(yù)訂所確定的時間的"x-sub-expires"、以及指示特定預(yù)訂的響應(yīng)代碼 的 "x-sub-response，，。
SIP隧道通知請求。與使用隧道的預(yù)訂有關(guān)的Notify請求必須包括 預(yù)訂的具體標(biāo)頭以使得把該隧道保持為"不知道(unaware)"所述預(yù) 訂。Notify請求優(yōu)選包括具體的標(biāo)頭"x-sub-data",其中包括關(guān)于預(yù)訂 的所有信息。例如，x-sub-daa標(biāo)頭可以采取"x-sub-data: To = a， From =b, Sub-state = xxx sub-id = y"的形式?？商?灸》也，所述響應(yīng)可以劉-于每個參數(shù)包括一個標(biāo)頭，諸如指示該響應(yīng)是與預(yù)訂還是與隧道有關(guān)的
"x-sub-id"、以及指示存在預(yù)訂的狀態(tài)的"x-sub-state"(等效于 Subscription-State)。例如，如果x-sub-state聲稱"被終止，，，則它向 RLS指示存在服務(wù)器已經(jīng)終止所述預(yù)訂。
RLS和PS還必須存儲為每個特定預(yù)訂所獨(dú)有的信息，該預(yù)訂并不 直接與SIP隧道(SIP對話)有關(guān)。根據(jù)多少數(shù)據(jù)與所述預(yù)訂有關(guān)，所 使用的存儲器的量將會不同，但是與SIP隧道有關(guān)的存儲器節(jié)省量仍是 相同的。
圖4是本發(fā)明的系統(tǒng)的示例性實(shí)施例的筒化框圖。用戶設(shè)備(UE) 51經(jīng)由IMS核心網(wǎng)53發(fā)送SIP SUBSCRIBE請求消息52到RLS實(shí)例 54以請求通過使用指向聯(lián)系人列表的具體的URI來創(chuàng)建對多個資源的 預(yù)訂。RLS中的聯(lián)系人列表解析器55解析所請求的列表。RLS中的SIP SUBSCRIBE生成器56經(jīng)由IMS核心網(wǎng)把每個聯(lián)系人的SIPSUBSCRIBE請求57發(fā)送到應(yīng)用服務(wù)器。舉例來說，這里圖示了存在服 務(wù)器(PS) 58。 SUBSCRIBE消息請求為聯(lián)系人列表中的每個資源創(chuàng)建 一個后端預(yù)訂。RLS在請求中包括有關(guān)其支持SIP隧穿的能力的信息， 并標(biāo)識該請求RLS實(shí)例。此信息例如可以是諸如在"支持的"標(biāo)頭中的 "sip-tunneling"之類的新值。
PS 58接收SIP SUBSCRIBE請求57并通過檢查"支持的"的標(biāo)頭 來檢測RLS 34支持SIP隧穿的能力。PS中的現(xiàn)有隧道確定單元59通過 比較"聯(lián)系人"標(biāo)頭值與存儲在PS中的關(guān)于正在進(jìn)行的預(yù)訂的信息來 確定它是否已具有與該請求RLS的現(xiàn)有已建立隧道。此信息可以存儲在 預(yù)訂隧道關(guān)系數(shù)據(jù)庫61中。如果PS不具有與此RLS的現(xiàn)有已建立隧道， 則PS中的預(yù)訂創(chuàng)建器62創(chuàng)建新的預(yù)訂。關(guān)于該新預(yù)訂的信息存儲在預(yù) 訂-隧道數(shù)據(jù)庫中。PS可以使用SIP SUBSCRIBE請求57中的"聯(lián)系人" 標(biāo)頭值來標(biāo)識RLS實(shí)例，并存儲將具體的預(yù)訂捆綁到具體的RLS實(shí)例 的信息。
PS 58經(jīng)由IMS核心網(wǎng)向RLS 54返回具有標(biāo)識新的或現(xiàn)有的預(yù)訂的 ID的響應(yīng)。如果PS不具有與RLS 54的現(xiàn)有已建立隧道，則可以由SIP 200 OK消息生成器64來生成200 OK響應(yīng)63。如果PS具有與RLS的 現(xiàn)有已建立隧道，則可以由SIP 301響應(yīng)生成器66來生成301響應(yīng)65。
RLS 54接收所述響應(yīng)，且RLS中的現(xiàn)有的PS預(yù)訂確定單元67通 過檢查所接收的響應(yīng)來確定對此PS實(shí)例的預(yù)訂是否已經(jīng)存在。如果接 收到了 200 OK響應(yīng)63，則RLS知道沒有預(yù)訂存在。如果接收到了 "301" 響應(yīng)65,則RLS知道預(yù)訂已經(jīng)存在。如果預(yù)訂不存在，則RLS中的預(yù) 訂-隧道關(guān)系創(chuàng)建器68使用200 OK響應(yīng)消息的聯(lián)系人標(biāo)頭中的信息來 創(chuàng)建面向PS 58的特定實(shí)例的新的預(yù)訂-隧道關(guān)系。RLS將該預(yù)訂-對話 關(guān)系本地存儲在預(yù)訂-隧道關(guān)系數(shù)據(jù)庫69中，只要RLS預(yù)定存在的話。 如果對該P(yáng)S的此實(shí)例的預(yù)訂已經(jīng)存在，則RLS使用301響應(yīng)消息的聯(lián) 系人標(biāo)頭中的信息來創(chuàng)建入局RLS預(yù)訂與面向PS的已存在對話之間的 預(yù)訂-對話關(guān)系。RLS將該預(yù)訂-對話關(guān)系本地存儲在預(yù)訂-隧道數(shù)據(jù)庫69 中，只要RLS預(yù)定存在的話。
RLS還返回指出此特定預(yù)訂的具體預(yù)訂-隧道關(guān)系的唯一 ID。此信 息可以被包括在額外路由標(biāo)頭中或在內(nèi)部被包括在RLS所使用的附加 標(biāo)頭中。之后，在該特定RLS/PS實(shí)例對之間創(chuàng)建的任何新預(yù)訂將使用相同 的已建立的對話。
雖然已經(jīng)在附圖中圖示并在前述詳細(xì)說明中描述了本發(fā)明的優(yōu)選 實(shí)施例，但是應(yīng)該明白本發(fā)明并不局限于所公開的實(shí)施例，而是在不背 離本發(fā)明范圍的情況下能夠進(jìn)行眾多重新布置、修改和替換。本說明書 意圖包括落入由隨附權(quán)利要求書所限定的本發(fā)明范圍內(nèi)的任何所有修 改。
權(quán)利要求
1. 一種減少在通信網(wǎng)絡(luò)中進(jìn)行通信的第一和第二服務(wù)器中的存儲器使用的方法，所述方法包括在所述第一和第二服務(wù)器的實(shí)例之間建立(11)對話以支持預(yù)訂；以及使用所建立的對話在所述第一和第二服務(wù)器的實(shí)例之間隧穿(12)所述預(yù)訂內(nèi)的所有請求。
2. 根據(jù)權(quán)利要求1所述的方法，其中，所述服務(wù)器使用會話發(fā)起協(xié)議(SIP)通信。
3. 根據(jù)權(quán)利要求2所述的方法，其中，建立對話的步驟包括從所述第一服務(wù)器發(fā)送(33)請求建立預(yù)訂的SIP預(yù)訂請求到所述第二服務(wù)器，所述SIP預(yù)訂請求包括所述第 一服務(wù)器支持SIP隧穿的指示；如果所述第二服務(wù)器也支持SIP隧穿，則所述第二服務(wù)器確定(39)所述第二服務(wù)器是否已經(jīng)具有與所述第一服務(wù)器的現(xiàn)有隧道；如果所述第二服務(wù)器已經(jīng)具有與所述第一服務(wù)器的現(xiàn)有隧道，則創(chuàng)建(41)所請求的預(yù)訂和所述現(xiàn)有隧道之間的關(guān)系，并把標(biāo)識所述關(guān)系的響應(yīng)從所述第二服務(wù)器發(fā)送(42)到所述第一服務(wù)器；以及如果所述第二服務(wù)器不具有與所述第一服務(wù)器的現(xiàn)有隧道，則從所述第二服務(wù)器把指示所述第二服務(wù)器支持隧穿的響應(yīng)發(fā)送(45)到所述第 一服務(wù)器，其中，在響應(yīng)中，所述第 一服務(wù)器為所請求的預(yù)訂創(chuàng)建(47 )與所述笫二服務(wù)器的隧道。
4. 根據(jù)權(quán)利要求2所述的方法，其中，建立對話的步驟包括從所述第一服務(wù)器發(fā)送(33)請求建立預(yù)訂的SIP預(yù)訂請求到所述第二服務(wù)器，所述SIP預(yù)訂請求包括所述第一服務(wù)器支持SIP隧穿的指示；如果所述第二服務(wù)器也支持SIP隧穿，則所述第二服務(wù)器確定(39 )所述第二服務(wù)器是否已經(jīng)具有與所述第一服務(wù)器的現(xiàn)有隧道；如果所述第二服務(wù)器已經(jīng)具有與所述第一服務(wù)器的現(xiàn)有隧道，則所述第二服務(wù)器用新隧道來代替所述現(xiàn)有隧道，所述第二服務(wù)器創(chuàng)建預(yù)訂，創(chuàng)建所請求的預(yù)訂與所述新隧道之間的關(guān)系，并從所述第二服務(wù)器發(fā)送標(biāo)識所述關(guān)系的響應(yīng)到所述第一服務(wù)器；以及如果所述第二服務(wù)器不具有與所述第一服務(wù)器的現(xiàn)有隧道，則從所述第二服務(wù)器發(fā)送(45)指示所述第二服務(wù)器支持隧穿的響應(yīng)到所述第 一服務(wù)器，其中，在響應(yīng)中，所述第一服務(wù)器為所請求的預(yù)訂創(chuàng)建(47) 與所述第二服務(wù)器的隧道。
5. —種用于向多個應(yīng)用服務(wù)器提供多個預(yù)訂的請求服務(wù)器(54), 包括用于從用戶接收請求預(yù)訂聯(lián)系人列表中的多個資源的預(yù)訂請求 (52)的裝置(55);用于為所述聯(lián)系人列表中的每個資源標(biāo)識應(yīng)用服務(wù)器(58)的裝置 (55);用于把預(yù)訂請求(57)發(fā)送到所標(biāo)識的應(yīng)用服務(wù)器的裝置(56), 所述預(yù)訂請求(57)包括(57) ( 57)所述請求服務(wù)器支持隧穿的指示；用于從所標(biāo)識的應(yīng)用服務(wù)器之一接收指示所標(biāo)識的應(yīng)用服務(wù)器也 支持隧穿的響應(yīng)(65)的裝置(67);用于確定所標(biāo)識的應(yīng)用服務(wù)器是否已經(jīng)具有與所述第 一應(yīng)用服務(wù) 器的現(xiàn)有隧道的裝置(67);用于確定響應(yīng)消息是否指示建立的隧道已存在于所述請求服務(wù)器 與所標(biāo)識的應(yīng)用服務(wù)器之間的邏輯(67);用于響應(yīng)于所述響應(yīng)消息指示建立的隧道尚未存在于所述請求服 務(wù)器與所標(biāo)識的應(yīng)用服務(wù)器之間的確定而建立新的隧道的裝置(68);以及用于響應(yīng)于所述響應(yīng)消息指示建立的對話已存在于所述請求服務(wù) 器與所標(biāo)識的應(yīng)用服務(wù)器之間的確定而使用現(xiàn)有已建立隧道來支持所 請求的預(yù)訂的裝置。
6. 根據(jù)權(quán)利要求5所述的請求服務(wù)器，其中，用于確定響應(yīng)消息 是否指示建立的隧道已經(jīng)存在的邏輯包括如果從所標(biāo)識的應(yīng)用服務(wù)器 接收到第 一 類型的響應(yīng)消息則推斷建立的隧道尚未存在、且如果接收到 了第二類型的響應(yīng)消息則推斷建立的隧道已經(jīng)存在的邏輯。
7. 根據(jù)權(quán)利要求5所述的請求服務(wù)器，其中，所述服務(wù)器在IP多 媒體子系統(tǒng)(IMS)網(wǎng)絡(luò)上使用會話發(fā)起協(xié)議(SIP)進(jìn)行通信，其中所述應(yīng)用服務(wù)器是存在服務(wù)器； 所述請求服務(wù)器是資源列表服務(wù)器；所述預(yù)訂請求消息是SIP SUBSCRIBE消息；所述笫 一類型的響應(yīng)消息是SIP 200 OK消息；以及所述笫二類型的響應(yīng)消息是SIP返回代碼。
8. 根據(jù)權(quán)利要求5所述的請求服務(wù)器，其中，所述服務(wù)器在IP多媒體子系統(tǒng)(IMS)網(wǎng)絡(luò)上使用會話發(fā)起協(xié)議(SIP)進(jìn)行通信，其中所述應(yīng)用服務(wù)器是任何IMS服務(wù)器；所述請求服務(wù)器是任何IMS服務(wù)器；所述預(yù)訂請求消息是SIP SUBSCRIBE消息；所述第 一類型的響應(yīng)消息是SIP 200 OK消息；以及所述第二類型的響應(yīng)消息是SIP返回代碼。
9. 根據(jù)權(quán)利要求5所述的請求服務(wù)器，還包括存儲裝置，所述存儲裝置用于存儲將所請求的預(yù)訂和所述應(yīng)用服務(wù)器與所述現(xiàn)有已建立隧道相關(guān)聯(lián)的預(yù)訂-隧道關(guān)系。
10. —種在通信網(wǎng)絡(luò)中用來通過預(yù)訂向請求服務(wù)器(54)提供資源的應(yīng)用服務(wù)器(58),所述應(yīng)用服務(wù)器包括用于從所述請求服務(wù)器接收預(yù)訂請求的裝置(59)，所述預(yù)訂請求包括所述請求服務(wù)器支持隧穿的指示；用于確定所述應(yīng)用服務(wù)器是否支持隧穿且如果支持、則確定在所述應(yīng)用服務(wù)器和所述請求服務(wù)器之間是否已經(jīng)存在隧道的裝置(59);用于如果所述應(yīng)用服務(wù)器不支持隧穿則發(fā)送第一類型的響應(yīng)到所述請求服務(wù)器的裝置(64);用于如果所述應(yīng)用服務(wù)器支持隧穿且在所述應(yīng)用服務(wù)器和所述請求服務(wù)器之間已經(jīng)存在隧道則發(fā)送第二類型的響應(yīng)到所述請求服務(wù)器的裝置(66);以及用于如果所述應(yīng)用服務(wù)器支持隧穿但是在所述應(yīng)用服務(wù)器和所述請求服務(wù)器之間尚未存在隧道則發(fā)送第三類型的響應(yīng)到所述請求服務(wù)器的裝置(64)。
11. 根據(jù)權(quán)利要求IO所述的應(yīng)用服務(wù)器，其中，用于發(fā)送第一類型響應(yīng)的所述裝置通知所述請求服務(wù)器所述應(yīng)用服務(wù)器不支持隧穿，由此通知所述請求服務(wù)器建立預(yù)訂而不進(jìn)行隧穿。
12. 根據(jù)權(quán)利要求IO所述的應(yīng)用服務(wù)器，其中，用于發(fā)送第二類型響應(yīng)的所述裝置通知所述請求服務(wù)器所請求的預(yù)訂與所述現(xiàn)有隧道之間的關(guān)系，由此致使所述現(xiàn)有隧道要被用來在所述請求服務(wù)器和所述 應(yīng)用服務(wù)器之間發(fā)送所有的后續(xù)請求。
13. 根據(jù)權(quán)利要求IO所述的應(yīng)用服務(wù)器，其中用于發(fā)送第三類型 響應(yīng)的所述裝置通知所述請求服務(wù)器所述應(yīng)用服務(wù)器支持隧穿但是隧 道尚未存在，由此致使所述請求服務(wù)器創(chuàng)建隧道并使用所述隧道在所述 請求服務(wù)器和所述應(yīng)用服務(wù)器之間發(fā)送所有的后續(xù)請求。
14. 根據(jù)權(quán)利要求IO所述的應(yīng)用服務(wù)器，其中，所述通信網(wǎng)絡(luò)是 IP多媒體子系統(tǒng)(IMS)網(wǎng)絡(luò)且所述服務(wù)器使用會話發(fā)起協(xié)議(SIP)進(jìn) 4亍通信，其中所述應(yīng)用服務(wù)器是存在服務(wù)器； 所述請求服務(wù)器是資源列表服務(wù)器； 所述預(yù)訂請求消息是SIP SUBSCRIBE消息； 所述第 一類型的響應(yīng)消息是SIP 200 OK消息；和 所述第二類型的響應(yīng)消息是SIP返回代碼。
15. 根據(jù)權(quán)利要求IO所述的請求服務(wù)器，其中，所述服務(wù)器在IP 多媒體子系統(tǒng)(IMS )網(wǎng)絡(luò)上使用會話發(fā)起協(xié)議(SIP )進(jìn)行通信，其中所述應(yīng)用服務(wù)器是任何IMS服務(wù)器； 所述請求服務(wù)器是任何IMS服務(wù)器； 所述預(yù)訂請求消息是SIP SUBSCRIBE消息； 所述第一類型的響應(yīng)消息是SIP 200 OK消息；和 所述第二類型的響應(yīng)消息是SIP返回代碼。
16. 根據(jù)權(quán)利要求IO所述的應(yīng)用服務(wù)器，還包括存儲裝置(61)，用于存儲將所請求的預(yù)訂和所述請求服務(wù)器與所 述現(xiàn)有已建立隧道相關(guān)聯(lián)的預(yù)訂-隧道關(guān)系；其中，用于確定在所述應(yīng)用服務(wù)器和所述請求服務(wù)器之間是否已經(jīng) 存在隧道的所述裝置(59)響應(yīng)于接收附加的預(yù)訂請求而訪問所述存儲 裝置。
全文摘要
一種通過控制SIP-隧道的建立來減少用于通信網(wǎng)絡(luò)中使用會話發(fā)起協(xié)議SIP的服務(wù)器之間通信的存儲器使用的布置和方法。將某事件包的單個SIP-隧道用于諸如資源列表服務(wù)器RLS(54)的請求服務(wù)器的一個實(shí)例與諸如像存在服務(wù)器(58)的應(yīng)用服務(wù)器的一個實(shí)例之間的多個預(yù)訂。然后使用(12)SIP-隧道在這兩個實(shí)體之間發(fā)送所有的SIPNOTIFY消息以通過去除SIP所產(chǎn)生的開銷來減少這兩端的存儲器使用。
文檔編號H04L12/46GK101485155SQ200780025436
公開日2009年7月15日 申請日期2007年4月27日 優(yōu)先權(quán)日2006年7月6日
發(fā)明者A·林德格倫, C·博伯格, S·索霍爾姆 申請人:艾利森電話股份有限公司