用戶的服務實體之間的靈活用戶分布的製作方法
2023-10-22 03:54:47 4
專利名稱：用戶的服務實體之間的靈活用戶分布的製作方法
技術領域：
在此所公開和要求保護的發明一般地涉及使用多個伺服器向它們的用戶或訂戶提供業務的大型通信網絡，通過多個不同的用戶標識符來識別或接入所述用戶或訂戶。更具體地說，本發明涉及用於上述類型的網絡的裝置、系統和方法，所述網絡在不限制用戶和提供業務的伺服器所使用的標識符類型的情況下，能夠找到合適的伺服器為一個特定用戶提供一個特定的伺服器。
現在，大型電信系統趨向於擴展並跨越多個運營商網絡，其中各個網絡都提供許多種不同的業務，並且通常以不同和獨立的技術為基礎。這種發展的一個重要的例子是在一個固定或者移動環境中新出現的基於網際網路的網絡與傳統的有線和無線電話系統的互連。具有不同特性並且向網絡用戶提供不同種類業務的不同運營商網絡的合併通常需要在一個電信網絡內有多個不同的伺服器，以便保存預約和向它們的用戶提供業務。
另一方面，使用現有的網絡資源經過適當的修改之後實現和支持新興業務可能成為以及時的方式和在不丟失現有網絡資源中的性能或其它特徵的情況下有效地將這些新業務推向市場的主要障礙。曾經普遍使用的一種方法是引入新的專用伺服器，用於引入僅在某種技術條件下可用或打算使用的業務。因此，引入多個業務專用伺服器以及多個預約專用伺服器所面對的一個基本的問題是在不對用戶和提供業務的伺服器的標識進行任何限制的情況下如何找到合適的服務特定用戶的伺服器。這個問題的解決方法必須能夠適應當前不可用或者不知道的用戶和伺服器標識符。
一般而言，現在在一個大型通信網絡中一般使用特定的用戶標識符來識別一個用戶或訂戶，所述特定用戶標識符通常根據具體的系統技術是不同的。在一些情況下，由於不同的原因，一個具體的網絡為同一個用戶支持或者使用多個標識符。有許多網絡使用不同的用戶標識符，例如在許多方面在概念上類似的GSM和ANSI-41。
例如，為了內部識別的目的，GSM網絡具有特定的用戶標識符，例如IMSI，而為了外部識別的目的，GSM和PSTN網絡都具有E.164標識符。而且，E.164標識符可以與用戶或者網絡節點相關，並可以用於尋址目的。在UMTS網絡內，以與GSM網絡類似的方式，數字方案與非數字方案並存。舉另外一個例子，網際協議(IP)多媒體系統使用通常基於非數字方案的不同標識符，例如SIP url、電子郵件名稱或者其它別名。這些標識符用於在一個具體的業務環境下識別用戶，即，配置用戶接收一個具體的業務或者一組業務。這些標識符還用於識別一個具體業務的伺服器。另一方面，這些IP多媒體系統還使用E.164標識符與PSTN網絡互連，而將典型的IP機制用於尋址目的。
在一個大型電信網絡內不斷地為每個用戶使用不同的標識符以及與不同業務或者業務環境相關的多個伺服器的出現需要一種改進的機制，用於找到為特定用戶提供服務的適當的伺服器。這種改進的機制必須非常靈活，也就是說，它必須如上所述不能限制為用戶或者提供業務的伺服器使用多個標識符。這種機制還必須考慮在確定哪一個伺服器是為一個終端用戶提供服務的實際或正確的伺服器的處理中嚴格的實時限制。而且，所提供的解決方法必須最小化實施和配置的複雜性，並限制運營成本，儘管存在大量用戶，每個用戶都具有多個用戶標識符，每個標識符可以與一個通信網絡相關。
在標準化論壇「第三代合作項目」(在下文中稱作3GPP)中在IP多媒體子系統的開發過程中將著重研究上述更有效地分布用戶標識符的需要。具體而言，如在附件F(信息資料)技術規範(TS)23.228中「到HSS解析的用戶標識(User Identity to HSS resolution)」所描述的，一個感興趣的用戶被編址成預約位置功能的輸出。在此，認識到在登記和會話建立過程中，因為在具體運營商的網絡通常存在多個HSS，所以需要確定當前保存用戶特定數據的實際原籍用戶伺服器(HSS)的位置，所述用戶具體數據例如是位置或鑑權參數。
因而，本發明的第一個目的是提供允許在多個不同和專用的預約和業務伺服器之間靈活地分布用戶的裝置和方法。所述靈活地分布是希望獨立於用戶標識符的方案、結構和可用的業務。
本發明的另一個目的是提供一種解決方案，它在儘可能地與現有的傳統電信系統兼容的情況下，使對第三代電信系統當前推薦的結構影響最小。
本發明的又一個目的是提供在不明顯增加所需要的操作和維護(OM)工作和相關成本的情況下允許上述用戶的靈活分布的方法和裝置。在這一方面，在資料庫之間交換所需要數據的自動程序是本發明所尋求的一個重要特徵。
背景技術：
在諸如GSM和ANSI-41網絡等典型的第二代無線系統中找到了感興趣的起始點。隨著所述無線系統擁有越來越多的用戶，運營商需要諸如原籍位置寄存器(HLR)等大型用戶資料庫以保存大量的預約信息，所述預約信息最小化操作和維護工作，並優化七號信令系統(SS7)網絡內的路由表。隨後，運營商開始通過拆分現有的HLR來引入冗餘HLR，以使每個HLR包括自己的用戶組和冗餘HLR擁有的用戶組。伴隨著這種支持冗餘的用戶初始化分布的是在SS7網絡內引入越來越複雜的路由表。因為將整個用戶組從一個HLR移動到另一個HLR，所以並不一定需要一個資料庫分布器為某個用戶找到保存其預約的正確的HLR，這種分布可以通過在SS7網絡內添加更多的路由表來解決。最近出現的號碼可移植性的要求使對資料庫分布器的需要成為必然，所述號碼可移植性的要求在一些情況下是通過法律規定的，其中各個用戶從屬於一個運營商的HLR移動到屬於另一個運營商的另一個HLR。
這樣一個資料庫分布器的示例性描述可以在國際申請WO 99/23838中找到，其中所述的在某個網絡內的資料庫分布器被稱作靈活號碼寄存器(FNR)。這個FNR是在第二代無線網絡內與其用戶號碼組屬於所述網絡的那些用戶有關的查詢的自然入口，而與當前哪個網絡保存有用戶預約無關。也就是說，所述FNR包括尋址這一網絡的所有用戶號碼組以及用於用戶從另一個網絡進入該網絡的個人用戶號碼。另外，已經進入另一個網絡的原籍用戶的個人用戶號碼被特別地標記，並且具有一個特定網絡標識符以抵達網絡內用戶當前保存他或她的預約的一個入口節點。
以諸如IMSI或E.164格式等用戶號碼為基礎的與用戶有關的查詢被發送給由所述IMSI或E.164格式尋址的一個網絡內的FNR。然後，FNR決定是否應因為用戶從未進入其它網絡或者從其它網絡進入而將該查詢簡單地轉發給其自己網絡內的適當的HLR，或者應當將該查詢改發到正確的用戶已經進入的網絡。在較低的信令層上執行所有的所需要的路由選擇和尋址過程，例如在SS7中在信令連接控制部分(SCCP)上。
儘管將這種方案視為最接近的現有技術，但是對於直接應用於在大型電信網絡內互連傳統的固定和無線電話網絡與網際網路和多媒體業務網絡的最新情況來說，它依然存在嚴重的局限性。例如，這種FNR的現有技術根據用戶或訂戶的標識符僅僅基於結構化編碼的SS7的原理而僅僅考慮信令、路由選擇和尋址。而且，必須以這種方式來結構化編碼與一個用戶有關的至少一個標識符以通過分析這個號碼就能夠明確地識別出正確的HLR。這種現有方案的另一個局限性在於在這些第二代無線網絡的發展過程中並未考慮其它最新的標識符方法，也未考慮除了SS7相關較高層之外的協議支持。這種方案所隱含的另一個缺點也是本發明所要解決的問題是這些資料庫結構的高成本的操作和維護，其中運營商必須人工地介入所有這些資料庫以確保一致的數據相互關係。另外，在這種現有技術中也沒有預見到業務專用伺服器，例如支持多媒體相關業務的業務專用伺服器，這些業務是可以通過響應以相應用戶標識符為基礎的查詢來實現的。
美國專利申請公開文獻2001/0049676(Kepler等人)描述了使用由主資料庫和輔助資料庫構成的資料庫體系來搜索內容的方法和系統，所述主資料庫包含具體數據，所述輔助資料庫包含這些數據的子集以及一個表示包含這些數據的主資料庫的欄位。該申請需要一個前端路由資料庫，它包含分布在若干後端資料庫之中的大量數據，不便於順序地查詢，更不可能得知所有這些後端資料庫或者其中包含的數據類型。除此之外，如本領域的任意一位技術人員可以理解的，在前端資料庫中接收查詢方面可能存在一些其它優點，所述查詢例如查詢搜索排除欄位的驗證，並在將所述查詢轉發給有關後端資料庫時進一步檢驗。當在前端資料庫上接收到一個資料庫搜索時，根據該搜索請求中所包含信息的類型和在前端資料庫的數據欄位內所包含信息的類型之間的重疊生成一個修改後的搜索。這個修改後的搜索請求用於提取一個可能生成原搜索請求結果的候選資料庫的列表。然後將原搜索請求提交給這些候選資料庫，並將結果返送給用戶。
如本領域的任意一位技術人員可以理解的，上述申請中的教導具體針對執行特殊內容的搜索，其中將一個候選結果列表提供給用戶，以便根據原始搜索的目標來選擇一個最有吸引力的結果。具體而言，該申請看起來在描述由搜索裝置執行的工作任務的種類。然而，在3G無線網絡的用戶試圖調用一個具體業務的情況下應用這種方法是不方便的，所述具體業務例如是啟動一個視頻會議。主叫用戶執行一個呼叫或者調用一個業務，並且希望網絡透明地工作，以便用戶不必採取與選擇最合適的伺服器有關的任何動作，另一方面，在一般情況下用戶絕對不知道最合適的伺服器。從這一方面來說，該申請中的搜索或者路由選擇方法都不能用於在電信系統內的多個不同伺服器中實現用戶的靈活分布。
因此，看起來通過上述申請的教導不能實現或者預測到本發明的上述目的。從這一方面來說，本發明的目的是提供在與用戶標識符方案、結構和可應用的業務無關的情況下允許在多個伺服器之間用戶的靈活分布的裝置和方法。本發明的目的還在於最小化對最新的和傳統的電信系統互連的影響以及最小化操作與維護OM工作任務及成本的所述裝置和方法。
發明內容
為了實現這些目的，本發明將一個用戶標識符分布器放置在一個網絡的解析域(resolution domain)內，並且可以訪問一個設置用於請求用戶信息的實體。該分布器或者用戶分布伺服器(UDS)包括用於在不同業務環境下識別一個用戶的每個用戶的多個用戶標識符。
這個UDS使用從主資料庫獲得的用戶和伺服器標識符實現一個輔助資料庫，安排用於在一個具體業務環境下確定負責一個給定用戶的一個特定網絡伺服器。這些特定網絡伺服器是指其中分布有在具體業務環境下的用戶或者更具體地說用戶數據的主資料庫。
因此，該UDS用作一個輔助資料庫，包括用於從所述用作主資料庫的特定網絡伺服器以及從網絡解析域內的其它UDS重新獲得用戶標識符和必要的業務數據的裝置。這個UDS還包括存儲器，用於每個特定網絡伺服器的用戶標識符和必要的業務數據，如果有的話。
能夠在具體業務環境下確定負責通過某個用戶標識符標識的給定用戶的特定網絡伺服器的所述UDS還包括用於從業務請求器節點或者從解析域內的另一個UDS接收和處理業務請求的裝置。而且，所述UDS還包括用於向所述業務請求器節點或者另一個UDS應答先前請求的裝置。具體而言，該應答可以包括在具體業務環境下負責所述用戶的特定網絡伺服器，或者如果存在冗餘配置的話一個可能的網絡伺服器的列表，或者一個新的用戶標識符和需要在另一個伺服器內再次查詢給定新標識符和可選地說明原因的指示。
該UDS適合於與使用相同或者不同協議的主資料庫、其它外部資料庫和業務請求器節點進行通信。因此，UDS還包括多個協議處理器模塊中的至少一個和在某些情況下的一個協議鑑別器模塊。
因此，本發明提供一個包括至少一個上述UDS的系統，儘管也可以包括多個。例如，如果考慮與現有業務請求器節點的位置有關的近似標準，不同的UDS可以負責不同的網絡域段。在這個系統中，多個主伺服器可以使用不同內容或者為了冗餘目的使用相同的內容更新不同的UDS。
在一個實施例中，UDS可以用作一個預約定位器功能。在這個實施例中的UDS能夠確定負責給定用戶的原籍預約伺服器(HSS)。這些HSS用作UDS的主資料庫。在這個系統內的業務請求器節點例如用作一個查詢或者一個服務呼叫狀態控制功能。
本發明的另一個實施例涉及電信系統，其中為了更新可以將多個主資料庫中的至少一個主資料庫內的相關用戶標識符提交給在至少一個主資料庫上所知的一個特定UDS、一組UDS或者所有UDS。而且，多個主資料庫中的至少一個主資料庫被安排用於從在至少一個主資料庫上所知的一個特定UDS，一組UDS或者所有的UDS接收UDS恢復優選選擇。該系統還安排用於根據每個恢復優先選擇來更新每個UDS。
本發明還提供一種在每個用戶使用多個用戶標識符的一個網絡解析域內在不同的業務環境下識別一個用戶的方法。該方法包括在用戶分布伺服器(UDS)內在一個具體業務環境下確定負責每個用戶的特定網絡伺服器的步驟。該方法還包括在UDS上從用作主資料庫的特定網絡伺服器以及從該網絡解析域內的其它UDS恢復用戶標識符和必要的業務數據的步驟；和在UDS上存儲每個特定網絡伺服器的每個用戶所述用戶標識符和必要的業務數據(如果有的話)的步驟。該方法還包括接收並處理來自業務請求器節點或者來自解析域內另一個UDS的業務請求的步驟；和向業務請求器節點或者向另一個UDS應答一個預期響應的步驟。所述預期響應可以是在一個具體業務環境下負責所述用戶的特定網絡伺服器，或者在存在冗餘配置時一個可能的網絡伺服器的列表，或者一個新的用戶標識符，具有在另一個伺服器內再次查詢所述新標識符是必需的的指示和可選地說明背後原因。
由於根據本發明由UDS提供的特殊靈活性，業務請求器節點可以是一個移動交換中心、一個信令網關、一個GPRS支持節點或者一個用於多媒體用途的應用伺服器。該列表是以非限制性的方式示範性地列舉的，決不打算限制本發明的範圍。
通過結合附圖閱讀說明書，本發明的特徵、目的和優點將變得顯而易見，在附圖中圖1圖示一個普通的網絡結構，說明用於本發明一個實施例的主和輔助資料庫的結構。
圖2基本地圖示用於本發明至少一個實施例的在輔助資料庫內每個用戶的個人記錄的內容。
圖3a示意性地描述根據本發明的用戶分布伺服器內部結構的一個實施例。
圖3b示意性地描述一個用戶分布伺服器內部結構的另一個實施例，其中在一個外部協議適應實體內處理多種協議。
圖4基本地圖示為了使用在圖1的實施例中來自主資料庫的內容更新輔助資料庫而執行的一個示範性流程。
具體實施例方式
下面描述在與用戶標識符方案、結構和可應用業務無關的情況下允許在多個伺服器之間靈活分布用戶的裝置、方法和系統的當前優選根據本發明的一個方面，在一個網路解析域內提供一個用戶分布伺服器(在下文中稱作UDS)，用於在具體業務環境下接收對特定用戶的業務請求有關的查詢。該UDS被安排用作一個輔助資料庫，它包括以每個用戶為基礎的多個用戶標識符，每個用戶標識符可以應用於一個具體的業務環境，並與尋址當前負責相應用戶數據的特定伺服器的一個伺服器標識符相關。這些特定伺服器被安排用作主伺服器，從其將用戶標識符和必要的業務數據下載到用作輔助資料庫的UDS中。該UDS通過提供伺服器標識符以進一步訪問當前在可應用的業務環境下服務該用戶的特定伺服器，向任意一個業務請求器節點應答與查詢一個特定用戶有關的業務請求。
在圖1中允許用戶靈活分布的示範性結構圖示了專用用戶分布伺服器可以如何負責某個網絡域內的特定地理位置。例如，UDS-1和UDS-2可以分別負責網絡域-2內的地理區域1和地理區域2。用戶標識符可以根據不同的標準分布在這個網絡域-2內的多個伺服器中，其中為了清楚僅圖示了伺服器-1、伺服器-2、伺服器-3和伺服器-n。這些伺服器分別標註為14-20。所述伺服器-1、伺服器-2、伺服器-3和伺服器-n用作主資料庫，從此主資料庫中通過所述伺服器-1的相應接口(P-11，P-12)、所述伺服器-2的相應接口(P-21，P22)、所述伺服器-3的相應接口(P-31，P-32)和所述伺服器-n的相應接口(P-n1，P-n2)將用戶數據下載到UDS-1和有可能下載到UDS-2。
主資料庫和輔助資料庫之間的分類簡化了數據處理，允許在主資料庫內容易地管理變化，並將在輔助資料庫內進一步更新這些變化。在圖4中圖示了一個如何執行此更新的示範性實施例，其中初始假定為UDS-1已經存在網絡內，操作和維護系統(22)已經啟動一個新伺服器(伺服器-1)。在此假定下，伺服器-1通過一個包括其自己的伺服器-1標識符的諸如REGISTER(登記)的可應用協議操作將它的出現指示給UDS-1。UDS-1使用該伺服器指示在一個諸如UPDATE_Req(更新請求)的可應用協議操作中請求更新所有的相關用戶。一旦在伺服器-1上接收到該請求，使用圖4所示的可應用協議方法通過一個操作UPDATE_Ind(更新指示)提交合適的用戶數據。此操作實際上可以代表某個信令流以提交伺服器-1內的所有用戶的用戶數據。在更新UDS-1之後，在諸如伺服器-1、新用戶的主資料庫內由操作和維護QM系統(22)執行的任意一個新的更新產生一個從伺服器-1到UDS-1的自動更新。都包括新用戶的標識符的用於a--用戶的類似協議方法等更具體地可以使用例如所述操作UPDATE-Ind。
圖4還圖示了在假定上述情況已經出現的情況下如何在網絡內引入另一個UDS(UDS-2)。UDS-2開始於操作和維護系統(24)，或者是其它的典型裝置，並且已經或者最近被配置以獲知它應當處理的目前存在的伺服器。在上述假定的情況下，所述UDS-2請求使用上述在圖4中用操作UPDATE_Req表示的類似指示和協議操作請求來更新所有相關用戶。一旦在伺服器-1上接收到請求，就使用必要的更新指示(UPDATE_Ind)執行一個類似於更新UDS-1的處理，直到下載了所有用戶的標識符。假設通過伺服器-1內的操作和維護系統(22)執行任意一個新的更新，例如一個新用戶，啟動一個從所述伺服器-1到UDS-1和UDS-2的自動更新。
在圖4中的另一個示範性的步驟考慮在上述情況下引入另一個伺服器(伺服器-2)。伺服器-2開始於操作和維護系統(24)，或者通過其它的典型裝置，並且已經或者最近被配置以獲得必須更新的當前存在的UDS。然後，伺服器-2通過廣播可應用的協議操作，例如上述REGISTER操作，其中包括它自己的伺服器-2標識符，將它的存在指示給UDS-1和UDS-2。然後，一旦從每個UDS接收到更新所有用戶相關信息的相應請求，伺服器-2啟動相應的請求UDS的指示(UPDATE_Ind)。
作為上述更新程序的結果，一個UDS包括與在網絡內或者在其控制下的網絡區域內提供特定業務的所有伺服器有關的信息，包括以每個用戶為基礎的相關被服務用戶的標識符。因此，主資料庫更新相關用戶數據變化的UDS。而且，在存在多個UDS的解析域內，每個UDS可以維護根據某個標準直接從主資料庫或者從另一個UDS或者從兩者更新的冗餘信息。例如，如圖1所示，服務不同地理區域的用戶分布伺服器可以通過鏈路(P-00)相互提供所請求的信息。優選地，UDS可以自己聯繫一些特定伺服器以在需要時提供與服務實體有關的更動態的信息。
為此，網絡域內的伺服器(伺服器-1、伺服器-2、伺服器-3、伺服器-n)從其自身預約(P-11、P-21、P-31、P-n1)網絡域-2內的多個UDS中的至少之一(UDS-1)。此外，在存在另一個UDS(UDS-2)的情況下，兩個UDS可以相互通信(P-00)以相互檢驗數據，或者為了可靠性的原因，或者僅僅因為它們負責不同的地理區域。
如圖1所示，出現一個典型的流程，其中網絡解析域例如網絡域-1內的一個外部客戶(26)向通常在另一個網絡解析域例如網絡域-2內的一個業務請求器節點發送一個消息(S-10)。所述消息例如可以是一個呼叫的一部分或者一個登記流程的一部分，一旦接收到，該業務請求器節點向一個特定UDS(UDS-1)發起一個查詢(S-20)。可以通過諸如在發現階段、在啟動階段或者通過配置執行的給定方法在業務請求器節點上指定所述UDS，用於處理與業務請求有關的查詢。
接收到查詢的UDS(UDS-1)通過檢查其資料庫記錄來檢查接收到的參數，即，用戶和/或業務相關數據，UDS-1與在可應用的業務環境下負責特定用戶的正確伺服器交互。在這一方面上，圖2圖示根據本發明的一個方面一個UDS中內部資料庫內容的一個解釋性和非限制性的例子。圖2圖示一個特定用戶可以具有不同的標識符。
一個UDS由請求與一個特定伺服器的連接的實體來查詢，所述特定伺服器向特定用戶提供業務。因此，該請求實體指示用戶標識符和可選的其它數據，例如所請求業務的指示。一般來說，UDS資料庫的行為可以通過定製行為來優化，例如，接受查詢而不明確指示所涉及業務的事實，在這種情況下返回所有被存儲的用戶數據以便另一個節點解釋這個結果。假設這個用戶和業務相關信息可能非常快地改變，指示表示其有效性的參數，例如使用期限值(在下文中稱作TTL)。而且，在多個伺服器可以向一個特定用戶提供業務的情況下，例如在冗餘配置的情況下，可以指示可能的伺服器列表。另外，在構建用戶標識符以便在某個結構層次中包括的所有用戶由一個特定伺服器服務的情況下，查詢的應答可以指示所述結構的層次。
然而，如果所指示的用戶或者業務在該網絡解析域內不存在，則UDS發送適當的錯誤。在此一個非常重要的方面是UDS查詢如圖1所示的外部資料庫(S-25)以請求與諸如號碼可移植性解析的某些入口有關的進一步信息的能力。這個外部資料庫(在下文中簡稱為Ex-Db)可以具有與根據本發明一個方面的UDS類似的結構和類似的內容，或者可以具有其它的結構或內容。查詢這個外部資料庫的接口可以是在主資料庫和輔助資料庫之間使用的接口之一，也可以是一個與之不同的接口。
一旦該查詢已經被內部或者外部地解決，UDS-1向業務請求器節點返回(S-30)一個相應的響應，其中包括合適的伺服器標識符以進一步訪問該合適的伺服器。假設這些應答由業務請求器節點緩存，在應答內提供一個有效時間(即，上述TTL值)以優化該緩存。
而且，以不同的呼叫為基礎，業務請求器節點可以訪問(S-40)該合適的伺服器，或者相應地發送(S-45)期望的響應給外部客戶機以便該客戶訪問(S-50)該合適的伺服器。
圖1還圖示安裝有分別用於接收一個查詢(S-20)和提供一個響應或應答(S-30)的第一裝置(40)和第二裝置(42)的UDS-1。UDS-1還安裝有第三裝置(44)，用於從伺服器主資料庫傳送或恢復用戶標識符和業務數據。
如上所述，UDS安排用於處理不同的協議，這些協議用於與用作主資料庫的不同的特定伺服器通信，用於與最終的外部資料庫通信，和用於與多個業務請求器節點中的至少之一通信。因此，UDS安裝有至少一個協議處理器模塊(在下文中稱作PHM)，這些模塊能夠處理這些不同通信協議中的至少一個協議。假設存在多個PHM，則需要一種協議鑑別功能以根據特定的協議基礎來確定哪一特定PHM應當處理一個接收到的查詢、應答或者其它消息。所述協議鑑別功能由如圖3a和圖3b所示的一個附加協議鑑別器模塊(在下文中稱作PDM)來執行，僅在存在多個PHM的情況下需要所述附加協議鑑別器模塊。例如，在支持最好根據「域名伺服器(DNS)」協議、「輕量級目錄訪問協議」(LDAP)、半徑協議或者直徑協議中的至少之一操作的電信協議的情況下，UDS(例如UDS-1或UDS-2)能夠解釋查詢和提交響應。以非限制性的方式提及這些協議，僅僅是為了闡述包含一個用於支持若干協議的UDS的明顯優點，這可以通過替換或者添加專用協議處理器模塊並僅在協議鑑別器模塊內進行修改來改變。
圖3a圖示包括幾個PHM(29)(也稱作1-3，m)和唯一一個PDM(30)的UDS(10)的優選實施例。本領域的技術人員將理解通過劃分在一個所謂的協議自適應實體(32)(在下文中稱作PAE)中集成的多個PHM(29)和PDM(30)可以實現類似的實施例。如圖3b所示，可以在PAE上保存一個專用PHM，用於與UDS(10)的內部通信，其中還存在唯一一個專用PHM(34)。圖3b還圖示包含一個內部資料庫(36)的UDS。
如果輔助資料庫(即，UDS)在地理上更靠近信息的請求器(即，所謂的業務請求器節點(28))以加速解析處理，則可以獲得其它的優點，儘管所述優點不是一個基本的特徵。
不考慮地理位置，從諸如UDS的輔助資料庫請求第一查詢，而主伺服器僅在成功應答第一查詢的情況下進行進一步的查詢。這一程序可以有效地避免由於查詢不存在的用戶通常稱作「業務拒絕」(DOS)攻擊所導致的主資料庫過載。具有在網絡運營商內部的部署或者在一個信任環境下，例如在不同國家運營共用某個基礎設備的合作夥伴，這種解決方案不需要與運營商網絡內任何其它標準節點不同的特殊安全保護。
圖1所示的結構以及UDS的上述基本特徵和優點適合於在根據第三代合作項目(3GPP)操作的電信系統內使用。更具體地說，該UDS可以如在附錄F的所述3GPP的技術規範(TS)23.228中所述操作為業務定位器功能(SLF)。
如在所述TS中描述的，因為在運營商的網絡內通常存在多個HSS，所以在登記和會話或呼叫建立過程中必須識別出原籍用戶伺服器(HSS)，所述原籍用戶伺服器當前保存有用戶特定數據，例如用戶位置或鑑權參數。一個查詢呼叫狀態控制功能(I-CSCF)節點和服務呼叫狀態控制功能(S-CSCF)節點需要識別一個特定的HSS，從而獲得負責一個給定用戶的HSS的實際名稱和/或地址。更具體地說，I-CSCF節點在登記和會話或呼叫建立過程中需要HSS識別，而S-CSCF節點僅在登記過程中需要這樣的HSS識別。為了簡化，本說明書僅涉及一個呼叫狀態控制功能(CSCF)節點，所述解釋同樣可以應用於查詢或者服務CSCF。
在這種情況下，分布有用戶的不同HSS被安排用作主資料庫，與先前在圖1中所示的主資料庫相同，在本說明書中稱作伺服器-i(i從1到n)，而CSCF節點被安排用作上述服務請求器節點(28)。根據本發明，上述UDS(10)然後可操作為用作一個輔助資料庫的所述業務定位器功能(SLF)，用於從CSCF接收查詢，與負責一個給定用戶的HSS交互，並將結果應答給所述CSCF。
因此，安排用作SLF的UDS包括至少一個協議處理器模塊，用於處理從CSCF節點接收到的查詢，並向該CSCF節點應答該查詢。而且，假設適合於SLF和HSS之間通信的協議不同於SLF和CSCF之間的通信協議，則安排用作SLF的UDS包括另一個協議處理器模塊(PHM)，用於處理更新或者與HSS的下載。如已經描述的，在使用多個PHM的UDS中包括一個協議鑑別器模塊(PHM)。
例如，CSCF和UDS之間的接口包括一個用於從CSCF查詢預約定位器的操作和一個用於將HSS地址提供給CSCF的響應，所述UDS安排用作一個SLF。具體地說，通過發送一個諸如SLF_QUERY的操作，CSCF指示HSS尋找的用戶標識(在登記或者會話或呼叫建立過程中接收到的)。然後，通過返回操作SLF_RESP，用作SLF的UDS用HSS名稱和/或地址進行響應以便CSCF繼續查詢給定的HSS。可選擇地，操作SLF_RESP可以指示一個新的用戶標識符和必須進行另一次查詢的指示。這個指示可以包括新查詢的地址和原因的說明，或者可以僅是新查詢的原因。前面的指示類型例如用於號碼可移植性，而後者暗示必須通過查詢實體來發現新伺服器的地址。假設CSCF和SLF之間的上述示範性DNS協議也使用在SLF和HSS之間，則操作SLF_UPDATE_REQUEST可以用於從每個特定HSS請求用戶數據。然後，操作SLF_UPDATE用於在這個HSS中出現變化時隨時從該HSS更新用作SLF的UDS。
在登記流程期間，可選擇地，查詢CSCF(I-CSCF)可以將HSS地址轉發給一個服務CSCF(S-CSCF)以簡化S-CSCF尋找HSS的行為。在所接收的用戶標識符並不對應於任意一個已知用戶時，返回對應的錯誤。
在示範性地使用DNS協議的情況下，儘管也可以使用其它的協議，例如直徑或者半徑協議，諸如用作SLF的UDS的輔助資料庫從諸如HSS的主資料庫的更新包括圖4所示的專用方法。
圖4中的SLF_UPDATE_REQUEST操作(即，UPDATE_Req)提供為查詢實體指示在所有或者一組標識符空間上請求特定操作的方法。所述操作包括用於為一個或一組用戶請求「所有用戶數據」或「特定用戶數據」的方法。例如，僅電路交換(在下文中稱作CS)接入相關數據，或者僅分組交換(在下文中稱作PS)接入相關數據，或者僅網際網路協議多媒體(在下文中稱作IM)相關數據。所述操作還包括用於為一個或一組用戶請求與業務網絡相關的「一組特定數據」的方法，所述業務網絡實際上可能包括一組業務。而且，所述操作還包括用於請求一種特定類型的標識符的方法，例如和以非限制性的方式，E.164號碼或SIP_url。另外，所述操作還包括用於僅請求屬於一個特定標識空間的標識符的方法，例如僅僅到acme.land.land域的標識符。
相應地，SLF_UPDATE響應操作(即，圖4中的UPDATE_Ind)提供用於向查詢實體指示為一個特定用戶或者為一組用戶更新「所有用戶數據」或者僅「特定用戶數據」的方法。
另一方面，如上面參考圖4所描述的，就用於一個、一組或者所有用戶的唯一業務、一組業務或者所有業務來說，將要請求更新的實體範圍以及被有效更新的實體範圍在這種情況下也具有可應用性。
總的來說，SLF_UPDATE_REQUEST操作(即，圖4中的UPDATE_Req)提供方法以指示-用戶範圍，可以是一個用戶、在某種分組條件下的一組用戶或者所有用戶。
-業務範圍，可以是一個特定業務、一組業務或者所有業務。
-將要查詢的實體範圍，可以是一個實體，在某種條件下的一組實體，即組播，或者所有實體，即廣播。
相應地，SLF_UPDATE響應操作(即，圖4中的UPDATE_Ind)提供方法以指示-用戶範圍，可以是一個用戶、在某種分組條件下的一組用戶或者所有用戶。
-業務範圍，可以是一個特定業務、一組業務或者所有業務。
-將要更新的實體範圍，可以是一個實體，在某種條件下的一組實體，即組播，或者所有實體，即廣播。
如上面參考圖4所預期的，當在網絡內引入一個用作SLF的新UDS時，向提供業務的所有節點，也就是說向所有的主資料庫發起一個查詢，即，向諸如HSS的主資料庫廣播。另一方面，從網絡中移除一個諸如UDS的查詢實體可以繼之以一個向所有協同操作的主資料庫的告警消息OUT_OF_SERVICE_like，或者，可選擇地，在主資料庫上提供附加的與存在有關的機制ACTIVITY_TEST_like以被定期地調用。根據本發明在從網絡中移除諸如HSS的任意一個主資料庫的情況下使用一個與上述機制OUT_OF_SERVICE_like或者相應的ACTIVITY_TEST_like的相關機制類似的方法。與用戶數據的引入、移除或者修改有關，上述UPDATE_Ind包括與明確地注釋更新類型有關的合適的指示符數值。
即使在主資料庫和輔助資料庫上有意地和優選地執行更新請求以及更新本身，也可能出現輔助資料庫UDS並不知道最新請求的某些特定用戶數據的情況。在這種情況下，由於UDS知道保存該數據的另一個主資料庫或輔助資料庫，從接收機UDS向另一個UDS或者向另一個外部資料庫發出一個新的查詢。這對於號碼可移植性的支持特別有用，將在本說明書中進一步為此提供一個附加的說明性的使用情況。
一個特別感興趣的方面是根據本發明用作一個SLF和因而在登記階段與CSCF交互工作的UDS的最佳行為。參考圖1中的接口和實體進行下述解釋。首先，CSCF(業務請求器節點)接收一個登記請求(S-10)，並必須啟動一個用戶數據位置的查詢。然後，CSCF向SLF(UDS-1)發送一個操作SLF_QUERY_like(S-20)，並包括在登記請求中所述的用戶標識。此時所使用的協議並不重要，因為根據本發明的UDS可以以如圖3a所示的方式安裝有多個協議處理器模塊(PHM)，例如適合於與DNS、半徑、直徑或者任何其它適當的協議通信。而且，為此可以將圖3b中的上述協議適配實體(32)插入在CSCF和UDS之間。第三，依然參考圖1，SLF(UDS-1)查看如圖2所示的它自己的資料庫內容，例如所查詢的用戶標識。第四，再次參考圖1，SLF(UDS-1)用可以發現用戶數據的HSS名稱應答(S-30)。第五，CSCF優選地直接向HSS(伺服器-3)發起一個查詢(S-40)。作為上述第五步驟的替代步驟和以某種呼叫為基礎，CSCF(業務請求器節點)(28)可以繼之以將查詢結果(S-45)返送給發出登記請求的外部客戶(26)，用於所述外部客戶查詢(S-50)合適的HSS(伺服器-3)。
除了針對在一個CSCF實體上接收一個登記請求的情況已經描述的之外，從根據本發明的一個UDS預見到一個類似的方法和行為，用於一個參與會話或呼叫建立的I-CSCF節點的情況。
根據本發明將一個UDS用作一個SLF的另一個優點是如何輕易地執行向外部資料庫(38)的特定查詢，並因而在下述兩種情況下支持號碼可移植性查詢在一個供方(donor)網絡上，和在一個始發網絡上。
在一個供方網絡上，UDS概念可以用於在一些情況下處理號碼和名稱可移植性。如當前在一些情況下規定的，可能會發生一些流程進入當前並未保存用戶預約的網絡的I-CSCF。當這樣一個I-CSCF查詢SLF時，必須在這個步驟中應用一個鑑別以避免這些來自一個進入用戶的查詢可以進入這個網絡的HSS。參見圖1，I-CSCF(業務請求器節點)接收一個INVITE請求(S-10)，並必須查詢用戶數據的位置。I-CSCF向SLF(UDS-1)發送一個SLF_QUERY(S-20)，作為參數包括先前在INVITE請求中接收到的用戶標識。SLF(UDS-1)在它自己的本地資料庫內查找所查詢的用戶標識。一個圖2中的標識符「2.2.3.4.9.e164.arpa」的示範性入口說明這個用戶使用一個作為伺服器標識符的「Forward_query_to_Ex_Db」型的指示進入。然後，SLF(UDS_1)通過接口S-25查詢如圖1所示的可移植性資料庫(外部資料庫)(38)，並從所述可移植性資料庫獲得將用於聯繫該用戶的標識符。隨後，SLF(UDS_1)使用一個地址或者一個用於抵達所述用戶的URL應答(S-30)I-CSCF(業務請求器節點)。I-CSCF現在可以命令將該INVITE消息改發到用戶已經進入的網絡。
另一方面，UDS還可以有利地用於解決在始發網絡內的號碼可移植性，其中實際上從一個服務呼叫狀態控制功能(S-CSCF)實體執行查詢。在這一方面上，相同的原理應用於從一個S-CSCF到一個用作SLF的UDS的查詢以及從上面指出的I-CSCF的查詢。
許多其它情況可以有利地使用根據本發明的UDS。例如，所述UDS可以為一個包含其自己的HSS的虛擬網絡運營商提供實質支持，在作為一個相應的網絡解析域尋址的一個非虛擬網絡內通過用作SLF的UDS來識別所述自己的HSS。
根據本發明，一個UDS可應用性的另一個例子是在外部網際網路協議多媒體業務提供器(在下文中稱作IMSP)內用戶的登記。可以遵循與上述相同的原理使用UDS概念，但是在這種情況下，用戶指示的聯繫名稱可以用於識別IMSP提供業務的領域。換句話說，原籍運營商用作一種代理，即，根據這個用戶的任意優先選擇提供用戶的聯繫地址，或者在號碼或者名稱可移植性的情況下提供改發業務的業務提供器。
當考慮在一個IP移動性管理(IPMM)結構中通過HSS和應用伺服器(在下文中稱作AS)之間的所謂Sh接口的查詢和響應時，發現另一種有利的使用情況。所述應用伺服器必須訪問在HSS內存儲的用戶數據，但是如同I-CSCF或者S-CSCF的情況，讓它們知道所有用戶的所有HSS的地址是不現實的。因此，根據本發明的相同UDS看起來也可以應用於這種情況，其中為了根據每個用戶和/或業務的請求將查詢從AS改發到正確HSS的目的，可以將一個諸如所述UDS的實體放置在HSS和AS之間。
上面已經確定了使用的優點和不同的情況，它們中的大多數涉及最新一代的無線系統，尤其考慮它們與最新的多媒體和網際網路相關業務的連通性。然而，還存在另一種UDS在典型的GSM或UMTS標識符上的有利應用。可以利用相同的原理使用該UDS的概念，但是在這種情況下，用戶指示的聯繫名稱根據特定的消息流可以是IMSI或者MSISDN。這可以以將這些號碼映射成可路由的名稱為基礎來進行，如已經在ENUM協議中推薦的，它將E.164號碼映射到可路由的名稱。在這種特定情況下，參考圖1，業務請求器節點所表示的查詢實體是移動交換中心伺服器(MSC)、網關MSC伺服器(GMSC)、服務GSM伺服器節點(SGSN)、或者網關GSM伺服器節點(GGSN)。以舉例而非限制性的方式列舉這些實體。而且，在這種典型的GSM或UMTS環境下，HLR和HSS是用伺服器-1至伺服器-n表示的主資料庫。這些業務請求器節點也可以是一個信令網關、一個GPRS支持節點、一個開放業務結構業務性能伺服器、一個多媒體消息伺服器或者一個CAMEL網關伺服器。
儘管已經在附圖中圖示和在上述優選實施例的詳細描述中描述了本發明的優選實施例，將理解本發明並不限制於所公開的實施例，在不脫離由權利要求書闡述和定義的本發明範圍的情況下，能夠進行多種重新配置、修改和置換。
權利要求
1.一種在一個網絡解析域內的用戶分布伺服器(UDS)，包括用於在不同業務環境下識別用戶的以每個用戶為基礎的多個用戶標識符，所述UDS被安排用於確定在一個具體業務環境下負責所述用戶的一個特定網絡伺服器，其特徵在於，所述UDS用作一個輔助資料庫，包括(a)裝置，用於從用作主資料庫的特定網絡伺服器中以及從網絡解析域內的其它UDS中恢復用戶標識符和必要的業務數據；(b)存儲器，用於每個特定網絡伺服器的用戶標識符和必要的業務數據，如果有的話；(c)裝置，用於接收和處理來自一個業務請求器節點或者來自該解析域內另一個UDS的業務請求；和(d)裝置，用於應答所述業務請求器節點或者另一個UDS(d1)在一個具體業務環境下負責所述用戶的特定網絡伺服器；或(d2)如果存在冗餘配置，一個可能的網絡伺服器的列表；或(d3)一個新的用戶標識符，具有在另一個伺服器內對所述新標識符的另一次查詢是必需的指示和可選地指示背後原因。
2.權利要求1的用戶分布伺服器(UDS)，其中裝置a)包括裝置，用於在指示上和從主資料庫或另一個UDS中將有關更新用戶標識符和/或必要的業務數據的需要通知所述UDS。
3.權利要求2的用戶分布伺服器(UDS)，其中裝置a)包括裝置，用於在打算用作主資料庫的所有網絡伺服器中登記所述UDS和從這些所有網絡伺服器中撤銷登記。
4.權利要求3的用戶分布伺服器(UDS)，其中裝置a)包括裝置，用於指示為所有被服務的用戶、為一個特定組的用戶或者僅為一個特定用戶恢復用戶標識符和/或必要的業務數據所用的恢復優先選擇。
5.權利要求4的用戶分布伺服器(UDS)，其中裝置a)還包括裝置，用於為下列組之中的至少一個組恢復用戶標識符和/或必要的業務數據(a)多個有效標識符類型之中的一種特定類型的標識符；(b)在特定域內使用的標識符；和(c)屬於一個域內特定標識空間的標識符。
6.權利要求5的用戶分布伺服器(UDS)，其中每個特定網絡業務的對臨時有效性敏感的數據包括一個「使用期限」(TTL)參數，用於確定從主資料庫恢復數據的需要。
7.權利要求5的用戶分布伺服器(UDS)，還包括至少一個協議處理器模塊，並且在存在一個以上的協議處理器模塊的情況下還包括一個協議鑑別器模塊，每個協議處理器模塊負責一個特定的電信協議。
8.權利要求7的用戶分布伺服器(UDS)，其中包括至少一個「域名伺服器(DNS)」相關的協議處理器模塊。
9.權利要求7的用戶分布伺服器(UDS)，其中包括至少一個「直徑」相關的協議處理器模塊。
10.權利要求7的用戶分布伺服器(UDS)，其中包括至少一個「輕量級目錄訪問協議(LDAP)」相關的協議處理器模塊。
11.權利要求7的用戶分布伺服器(UDS)，其中包括至少一個「半徑」相關的協議處理器模塊。
12.權利要求7的用戶分布伺服器(UDS)，還包括協議和處理裝置，用於使用不打算用作主資料庫或者用作另一個UDS的一個外部資料庫來解決業務請求。
13.權利要求12的用戶分布伺服器(UDS)，其中所述外部資料庫是一個號碼可移植性資料庫。
14.一種電信系統，包括權利要求1的用戶分布伺服器(UDS)，其特徵在於，可以為了更新將多個主資料庫之中的至少一個主資料庫內的相關用戶標識符提交給在所述至少一個主資料庫上所知道的一個特定UDS、一組UDS或者所有的UDS。
15.權利要求14的電信系統，其中多個主資料庫之中的至少一個主資料庫被安排用於從在所述至少一個主資料庫上所知道的一個特定UDS、一組UDS或者所有的UDS中接收UDS恢復優先選擇，並且被安排用於根據每個恢復優先選擇來相應地更新每個UDS。
16.權利要求15的電信系統，其中UDS起著預約定位器功能(SLF)。
17.權利要求15的電信系統，其中用作主資料庫的多個特定伺服器之中的至少一個特定伺服器是一個原籍預約伺服器(HSS)。
18.權利要求15的電信系統，其中用作主資料庫的多個特定伺服器之中的至少一個特定伺服器是一個存在伺服器。
19.權利要求15的電信系統，其中多個業務請求器節點之中的至少一個業務請求器節點是一個詢問呼叫狀態控制功能(I-CSCF)。
20.權利要求15的電信系統，其中多個業務請求器節點之中的至少一個業務請求器節點是一個服務呼叫狀態控制功能(S-CSCF)。
21.權利要求15的電信系統，其中多個業務請求器節點之中的至少一個業務請求器節點是一個移動交換中心(MSC)。
22.權利要求15的電信系統，其中多個業務請求器節點之中的至少一個業務請求器節點是一個信令網關。
23.權利要求15的電信系統，其中多個業務請求器節點之中的至少一個業務請求器節點是一個GPRS支持節點。
24.權利要求15的電信系統，其中多個業務請求器節點之中的至少一個業務請求器節點是一個打算用於多媒體相關用途的應用伺服器(AS)。
25.權利要求15的電信系統，其中多個業務請求器節點之中的至少一個業務請求器節點是一個開放業務結構業務性能伺服器。
26.權利要求15的電信系統，其中多個業務請求器節點之中的至少一個業務請求器節點是一個多媒體通信伺服器。
27.權利要求15的電信系統，其中多個業務請求器節點之中的至少一個業務請求器節點是一個CAMEL網關伺服器。
28.權利要求15的電信系統，其中多個用於解析的外部資料庫之中的至少一個外部資料庫是一個域名伺服器。
29.權利要求15的電信系統，其中多個用於解析的外部資料庫之中的至少一個外部資料庫是一個以輕量級目錄訪問協議(LDAP)為基礎的資料庫系統。
30.權利要求15的電信系統，其中多個用於解析的外部資料庫之中的至少一個外部資料庫是一個號碼可移植性資料庫。
31.一種網絡解析域內的方法，其中使用以每個用戶為基礎的多個用戶標識符來在不同業務環境下識別用戶，並且其中權利要求1中的用戶分布伺服器(UDS)被配置用於確定在一個具體業務環境下負責每個用戶的一個特定網絡伺服器，該方法的特徵在於，所述方法包括步驟(a)在UDS上從用作主資料庫的特定網絡伺服器和從網絡解析域內的其它UDS中恢復用戶標識符和必要的業務數據；(b)在UDS上存儲每個特定網絡伺服器的以每個用戶為基礎的用戶標識符和必要的業務數據，如果有的話；(c)接收和處理來自業務請求器節點或者來自該解析域內另一個UDS的業務請求；和(d)應答業務請求器節點或者應答另一個UDS(d1)在具體業務環境下負責所述用戶的特定網絡伺服器；(d2)如果存在冗餘配置，一個可能的網絡伺服器的列表；或(d3)一個新的用戶標識符，具有在另一個伺服器內對所述新標識符進行另一次查詢是必需的指示和可選地指示背後原因。
32.權利要求31的方法，還包括步驟在指示上和從主資料庫或另一個UDS中將有關更新用戶標識符和/或必要的業務數據的需要通知至少一個UDS。
33.權利要求32的方法，還包括步驟在打算用作主資料庫的所有網絡伺服器中登記一個UDS和從這些所有網絡伺服器中撤銷一個UDS的登記。
34.權利要求33的方法，還包括步驟向至少一個主資料庫指示為所有被服務的用戶、為一組特定用戶或者僅為一個特定用戶恢復用戶標識符和/或必要的業務數據所用的UDS恢復優先選擇。
35.權利要求34的方法，還包括步驟從在至少一個主資料庫上所知道的一個特定UDS、一組UDS或者所有的UDS中接收UDS恢復優先選擇，並根據每個恢復優先選擇從所述至少一個主資料庫中相應地更新每個UDS。
全文摘要
在一個網絡內提供一個用戶分布伺服器(UDS)，所述網絡具有均利用多個不同的使用標識符識別的多個伺服器和用戶。該UDS位於可以訪問一個被配置用於請求用戶信息的實體的位置上，該UDS通過將查詢改發到合適的伺服器或服務實體來響應一個與特定用戶有關的查詢。UDS使用從與伺服器有關或者從這些伺服器中推導出的主用戶資料庫獲得的用戶與伺服器標識符來實現一個輔助資料庫。因為可以在主資料庫內很容易地管理數據變化和更新，並且然後將這些數據變化和更新傳送給輔助資料庫或者在輔助資料庫中實現，所以不同的主資料庫和輔助資料庫的使用簡化了數據處理。
文檔編號H04Q7/24GK1633795SQ02806042
公開日2005年6月29日 申請日期2002年3月6日 優先權日2001年3月6日
發明者J·A·桑切斯埃雷羅, I·P·安德烈斯 申請人:艾利森電話股份有限公司