用於在支持多媒體服務的基於網際網路協議的移動通信系統中處理控制消息的方法和系統的製作方法

2023-12-01 13:48:26 2

專利名稱：用於在支持多媒體服務的基於網際網路協議的移動通信系統中處理控制消息的方法和系統的製作方法
技術領域：
本發明一般地涉及支持多媒體服務的基於網際網路協議(Internet Protocol, IP)的移動通信系統，並具體涉及用於處理控制消息的方法和系統。
背景技術：
給基於IP的系統配備多個伺服器，用於通過分布其服務請求集中於特定 IP位址的多個用戶來處理服務請求。
隨著訂閱的用戶(subscribed user)數量的增加，需要被同時處理的消息的 悽t量也增加了。在這種情況下，IP多媒體子系統(Multimedia Subsystem ， IMS)應該根據IP網絡系統特性增加用於映射到相關聯的服務的應用程式的 應用伺服器的呼叫處理能力，或者應該使用多個應用伺服器分布用戶。
在用於分布用戶的方法中，最直接的方法是通過安裝多個具有相同功能 的應用伺服器，並在預先定義的歸屬訂戶伺服器(home subscriber server)中劃 分和註冊多個訂戶(subscriber)信息，在任意應用伺服器上分布負載。
但是，用於根據訂戶信息靜態地預先分配應用伺服器的方法的不利之處 在於由於在可變運行環境下，訂戶信息應該定期更新，因此運行和維護成 本增加。而且，存在當分配給用戶的特定應用伺服器的運行被停止時，該用 戶永遠不能使用任何服務的問題。
用於動態地把用戶分配給應用伺服器的方法涉及配置邏輯應用伺服器， 多個應用伺服器被通過分布器(distributor)集成到所述邏輯應用伺服器中。 至少一個分布器通過從多個應用伺服器中選擇一個應用伺服器並處理和發送 從用戶接收到的請求消息來分布負載。此時，由於分布器共享應用伺服器的 用戶分配信息，所以即使用戶請求經過任何分布器，也可以始終在同一應用 伺服器中處理用戶請求。由於在動態分配方法中請求消息應該經過分布器， 所以重新傳輸可能導致延遲。當在用於負載分布的應用伺服器之間使用非標 準控制協議時，其不可以在異構應用伺服器之間應用。目前需要通過在現有IMS系統中動態分配應用伺服器來分布負載的方法。

發明內容
本發明的一個方面是至少解決上面的問題和/或缺點，並至少提供下面描 述的益處。因此，本發明的一個方面是提供一種用於在支持多媒體服務的基 於IP的移動通信系統中處理呼叫控制消息的方法和系統。
本發明的一個方面是提供一種用於在支持多媒體服務的基於網際網路的移
動通信系統中通過會話發起協議(Session Initiation Protocol, SIP )發送和接 收控制消息的方法和系統，在所述會話發起協議中處理應用層的控制消息。
本發明的一個方面是提供一種用於在支持多媒體服務的基於網際網路的移 動通信系統中通過SIP在至少一個較高層伺服器和多個較低層伺服器之間發 送和接收控制消息的方法和系統。
本發明的一個方面是提供一種用於在支持多媒體服務的基於網際網路的移 動通信系統中，如果用戶設備(User Equipment, UE)把應用層設置為用戶 代理，當該應用層處理控制消息時降低負載的方法和系統。
根據本發明的一個方面，提供了 一種用於在基於IP的移動通信系統中處 理支持多媒體服務的控制消息的方法，包括通過SIP把用於會話的請求消 息從UE發送到IMS，所述IMS是支持多媒體服務的網際網路網絡；把請求消 息從IMS的代表應用伺服器發送到從多個較低層應用伺服器中選擇的較低層 應用伺服器；以及，由被選擇的較低層應用伺服器處理請求消息，並把響應 消息發送到UE。
根據本發明的一個方面，提供了 一種用於在支持多媒體服務的基於因特 網的移動通信系統中降低處理應用層的控制消息的負載的方法，包括通過 SIP將包括呼叫標識符信息的會話請求消息從UE發送到服務伺服器；將在記 錄路由首標(record —route header)中包括服務月良務器(serving server)地址的會 話請求消息從服務伺服器發送到應用層的代表應用伺服器；由代表應用服務 器分配用於處理會話請求消息的後端應用伺服器，並將會話請求消息發送到 分配的後端應用伺服器；由後端應用伺服器處理會話請求消息，並將在記錄 路由首標中包括後端應用伺服器的路徑記錄信息的響應消息發送到UE;以 及，由UE將響應消息的記錄路由首標的路徑記錄信息設置為用於發送同一會話內的後續請求消息的路徑信息，並通過會話發起協議把包括相同呼叫標 識符信息的後續請求消息發送到分配的後端應用伺服器。
根據本發明的一個方面，提供了 一種用於在支持多媒體服務的基於因特
網的移動通信系統中降低處理應用層的控制消息的負載的方法，包括通過 SIP把包括呼叫標識符信息的會話請求消息從UE發送到服務伺服器；把在記 錄路由首標中包括服務伺服器地址的會話請求消息從服務伺服器發送到應用 層的代表應用伺服器；由代表應用伺服器分配用於處理會話請求消息的後端 應用伺服器，並把會話請求消息發送到分配的後端應用伺服器；由後端應用 伺服器處理會話請求消息，並把在記錄路由首標中包括後端應用伺服器的路 徑記錄信息的響應消息發送到l正；由用戶設備接收響應消息，並通過SIP把 包括呼叫標識符信息的後續請求消息發送到服務伺服器；以及，由服務服務 器檢查後續請求消息的記錄路由首標的路徑記錄信息，並把後續請求消息發 送到分配的後端應用伺服器。


根據下面結合附圖的詳細描述，本發明的上述和其他特徵和優點將變得 更為清晰，在附圖中
圖1示出了根據本發明的IMS的結構；
圖2A根據本發明示出了在接收到初始請求時IMS網絡實體之間的控制 消息傳輸流；
圖2B根據本發明示出了在接收到後續請求時應用伺服器(Application Server, AS )組中的控制消息傳輸流；
圖3根據本發明示出了 UE在IMS中註冊的過程。
圖4A根據本發明示出了 AS從UE接收服務請求消息的操作；
圖4B根據本發明示出了代表AS檢索後端AS的分配信息的操作；
圖5根據本發明示出了當產生註冊請求消息時UE和更高層之間的消息
流;
圖6根據本發明示出了當產生請求消息時UE和更高層之間的消息流； 圖7才艮據本發明示出了當代表AS不知道後端AS的分配狀態時，UE發 送初始請求消息和後續請求消息時的控制消息流；
圖8根據本發明示出了當後端AS作為用戶代理(User Agent, UA)運行時，UE發送請求消息時的控制消息流；
圖9根據本發明示出了代表AS的結構；和
圖IO根據本發明示出了歸屬訂戶伺服器、代表AS和後端AS間的控制 消息傳輸/接收過程。
具體實施例方式
這裡下面將參考附圖詳細描述本發明的優選實施例。描述中定義的內容， 例如詳細構造和元件，被提供用於幫助全面理解本發明的優選實施例。因此， 本領域普通技術人員將認識到，在不偏離本發明的範圍和精神的情況下，可 以對這裡所描述的實施例做出各種變化和修改。而且，為了清晰和簡潔的目 的，省略了對公知功能和構造的描述。
在本發明中，IMS系統使用SIP發送處理用戶呼叫所需的控制消息。這 裡，定義了包括代表AS和多個後端AS的應用伺服器組，並且，使用SIP定 義了處於分級結構中的AS之間的控制消息傳輸/接收。因此，提供了能夠擴 展呼叫處理能力並分布用於多媒體服務支持的負載的方案。
圖1根據本發明示出了配備分級AS的IMS的結構。
參考圖1, UE 10通過接入網101與包括AS組106的IMS域102通信。 IMS域102是支持多媒體服務的基於IP的網絡。
IMS域102至少配備了代理呼叫會話控制功能(Proxy-Call Session Control Function, P-CSCF) 103、問詢呼叫會話控制功能(Interrogating-Call Session Control Function, I-CSCF )104、服務呼叫會話控制功能(Serving- Call Session Control Function, S-CSCF ) 105、用於提供特定語音和數據服務的AS 組106,和用於存儲UE IO的訂戶信息的歸屬訂戶伺服器(Home Subscriber Server, HSS ) 109。
在本發明的優選實施例中，AS組106具有分級結構。即，AS組106配 備至少一個或者兩個作為較高層AS工作的代表AS 107和多個作為較低層 AS工作的後端AS 108。
如果需要，IMS系統還可以包括服務上下文伺服器(Service Context Server, SCS ) IIO，服務上下文伺服器110起到用於存儲在代表AS 107中可用 的後端AS 108的分配信息的專用資料庫的作用。根據網絡結構，可以在HSS 109中提供SCS 110。接著將簡要描述IMS中的控制信號(消息)流。
l正IO通過SIP發送映射到特定服務的請求消息。接入網101把接收到 的服務請求消息發送到IMS域102。P-CSCF 103是起到IMS域102中的入口 作用的伺服器，並且能夠通過根據代理伺服器的特性使用於UE 10的服務連 接的等待時間(latency)最d 、來保障服務連接。
I-CSCF 104是用於執行引導的伺服器，以使從包括UE IO的多個訂戶接 收的請求消息可以被正確地發送到相關聯的S-CSCF 105。 I-CSCF 104執行路 由操作，以正確地分布和發送請求消息。
S-CSCF 105是用於實際上處理請求消息的伺服器。S-CSCF 105從UE 10 接收請求，並把該請求發送到相關聯的AS。 S-CSCF 105起到交換機的作用， 用於處理映射到具有不同IMS域的網絡的請求消息的控制信號。從UE IO發 送的請求消息是要被從S-CSCF 105發送到AS 106的呼叫處理控制信號。
此時，關於用於接收請求消息的相關聯的AS組106的信息應該被預先 註冊在UE IO的訂戶信息中。訂戶信息是SIP統一資源指示符(SIP Uniform Resource Indicator, SIP URI)或者Tel URL訂戶信息被存儲在HSS 109中。
當從l正IO接收相關聯的服務請求時，S-CSCF 105把接收到的請求發送 到相關聯的AS組106，以根據在訂戶信息中註冊的內容處理服務。
在AS組106中，代表AS 107和多個後端AS 108是用於通過SIP協議 執行通信的節點。
具體來說，代表AS 107通過S-CSCF 105從UE 10接收請求消息，並把 接收到的請求消息發送到特定後端AS。如果存在預先分配給UE 10的後端 AS 108，則UE 10的請求消息被發送到所分配的AS 108。如果不存在分配給 UE10的AS，則代表AS 107在考慮負載分布的同時分配任意AS,並把請求 消息發送到分配的AS。此時，後端AS分配信息可以存儲在代表AS中，或 者可以在SCS 110中存儲並使用。分配或解除分配後端AS 108的時刻可以根 據服務而不同。
當請求消息與先前的SIP對話無關時，即任意UE的請求消息不需要被 連續地處理或者使用了用於存儲分配信息的SCS 110時，代表AS 107不需要 存儲分配信息。在這種情況下，優點是代表AS 107可作為無狀態(state-less) 代理伺服器運行。
在處理UE的請求消息之後，特定後端AS 108將其自身地址添加到包含SIP路徑記錄信息的記錄路由首標，以便處理相同SIP會話中的後續請求消
自
具體來說，在本發明中，代表AS 107通過記錄後端AS 108的地址作為 路徑記錄信息而不是把代表AS 107的地址添加到記錄路由首標，使得 S-CSCF 105能夠直接把後續請求發送到後端AS 108。
如上所述，使用路由首標(route header),在路徑信息中設置了從UE 10 產生的後續請求消息的傳輸，即從l正IO產生的消息應該經過的路徑。此時， 路徑信息跟在對先前請求消息的響應中所包括的記錄路由首標的路徑記錄信 息後面。
在本發明中，根據對先前請求消息的響應中所包括的記錄路由首標的路 徑信息，要從UE IO發送的後續請求消息被直接發送到後端AS 108而不經過 代表AS 107。
因此，本發明的優點在於當發送了後續請求消息，IMS網絡實體之間 的傳輸延遲時間被減小了。
圖2A根據本發明示出了當代表AS接收初始請求消息時代表AS和後端 AS之間的消息傳輸/接收。
參考圖2A，從l正202發送到S-CSCF 204的初始請求消息210被發送 到代表AS 205或者209 (如附圖標記211所指示)。此時，S-CSCF 204將其 自身地址添加到請求消息的路徑記錄信息。如果AS組203的代表AS 205和 209的數量是兩個或更多個，則S-CSCF 204根據網絡狀態從代表AS 205和 209中任意選4奪一個特定代表AS 205，並把初始請求消息210發送到選擇的 代表AS 205。當接收到請求消息時，代表AS 205確定是否存在被分配給發 送該請求消息的UE202的後端AS。如果不存在分配的後端AS,則分配適於 負載分布的後端AS。
此時，分配信息可以或者不可以存々者在已接收到請求消息的代表AS 205 中或者用於管理該分配信息的專用資料庫204中。然後，請求消息被發送到 分配的後端AS # 1 206 (如附圖標記212所指示)。
代表AS 205不把其自身地址添加到路徑記錄信息。但是，後端AS # 1 206
在將後端AS # 1 206的地址添加到被處理的請求消息213的路徑記錄信息之
後，給代表AS205提供指示請求消息已被正常地發送的響應消息。或者，對
被處理的請求消息的響應消息可以被從後端AS# 1 206直接發送到S-CSCF204而不經過代表AS 205。
圖2B根據本發明示出了當代表AS接收到後續請求消息時，代表AS和 後端AS之間的消息傳輸/接收，以及圖2A的代表AS 205或209和圖2A的 SCS 240之間的消息傳輸/接收。在圖2B中，根據代表AS 205或209的設置， 可以省略代表AS 205或209和SCS 240之間的消息傳輸"矣收。
UE 222的後續請求消息的路徑使用在處理和發送初始請求消息時收集 的路徑記錄信息。即，其中排除代表AS225的路徑記錄信息被包括在後續請 求消息的路由首標中，並被傳送。因此，UE 222的後續請求消息被直接從 S-CSCF 224發送到後端AS # 1 226。
結果，能夠分布和處理從UE 222發送的請求消息。優點在於當處理 後續請求消息時，IMS網絡實體之間的消息傳輸/接收不被延遲。
圖3根據本發明示出了一個過程，其中，UE在IMS域中註冊，並且代 表AS將後端AS分配給UE。
參考圖3,當在步驟302中UE發送註冊(REGISTER)請求消息到IMS 域時，在步驟303中，S-CSCF處理註冊請求消息。在步驟304中，S-CSCF 應用UE的初始過濾(filter)標準，並註冊用於處理請求消息的第三方。這裡， 第三方是用於接收由S-CSCF處理的註冊請求消息以用於參考的第三SIP節 點，並且在本發明的優選實施例中是AS組。在步驟305中，S-CSCF把第三 方註冊請求消息發送到代表AS。
過濾指用於檢查來自UE的請求消息的標準並把消息發送到能夠處理該 消息的特定代表AS的過程。
在步驟306中，在其中已經接收到來自S-CSCF的UE的註冊請求消息 的代表AS確定是否存在預先分配的映射到UE的訂戶信息的後端AS。如果 不存在預先分配的後端AS，則代表AS在考慮AS組中的負載狀態的同時， 分配適當的後端AS，並存儲關於所分配的後端AS的信息。在步驟307中， 代表AS把UE的註冊請求消息發送到所分配的後端AS，從而請求後端AS 註冊該UE。這個總的過程被同樣地應用於UE的重新註冊和解除註冊過程。
圖4A根據本發明示出了一個過程，其中，通過S-CSCF在代表AS和後 端AS中處理從UE發送的請求消息。
參考圖4A，在步驟402中，UE發送服務請求消息到IMS域。在步驟 403中，S-CSCF通過SIP接收UE的請求消息。在步驟404中，S-CSCF通過確定請求消息是用於產生對話的初始請求、未被包括在對話中的個別請求消 息、還是後續請求消息來檢查請求消息的類型。
如果在步驟404中，請求消息被確定是用於產生對話的初始請求消息或 者未被包括在對話中的個別請求，則過程前進到步驟405 。
在步驟405中，在根據UE的訂戶信息應用初始過濾標準之後，S-CSCF 根據過濾把請求消息發送到特定代表AS。
在步驟411中，代表AS選擇用於處理請求消息的後端AS。將參考圖4B 詳細描述代表AS選擇後端AS的方法。
在步驟406中，代表AS把請求消息發送到所分配的後端AS。當分配了 後端AS時，不在指示請求消息的路徑記錄信息的記錄路由首標中記錄代表 AS的地址。
在步驟407中，後端AS在記錄路由首標中記錄其自身的地址。 在步驟410中，S-CSCF根據在步驟407中新設置的路由信息，通過SIP
連續地發送請求消息。
在該路由信息中，用於處理隨後要在步驟410中產生的對話的實體包括
被分配的後端AS。 SIP請求消息淨皮根據路由信息發送，在所述路由信息中不
包括代表AS。
但是，如果在步驟404中，從UE發送的請求消息被確定是屬於已被配 置的對話的消息，則過程前進到步驟408,以便根據請求消息的路由信息， 直接把請求消息發送到相關聯的後端AS。
在步驟409中，後端AS處理請求消息。在步驟410中，S-CSCF通過根 據設置的路由信息發送後續接收到的SIP請求消息，連續地執行相關聯的處 理操作。
圖4B根據本發明示出了一個過程的例子，其中，代表AS獲取後端AS 的分配信息。將參考圖4B詳細地描述圖4A的步驟411。
參考圖4B，在步驟421,代表AS確定對於發送請求消息的UE，是否存 在後端AS分配信息。根據代表AS的設置，可以存儲關於被映射到訂戶信息 的已被分配的後端AS的信息。或者，可以存儲在請求先前對話或與當前請 求的服務不同的服務時使用的分配信息。
如果存在映射到UE的分配信息，則代表AS選擇被發送了該請求消息 的後端AS。如果不存在分配信息，則過程前進到步驟422。在步驟422中，代表AS確定存儲映射到多個UE的分配信息的專用SCS 是否被設置成可用。當SCS未被使用時，代表AS前進到步驟423，以在根 據應用程式實現考慮服務負載狀態的同時，分配被發送了該請求消息的任意 後端AS。
當SCS被使用時，代表AS前進到步驟424，以把後端AS分配信息請 求發送到SCS。當在步驟425中代表AS從SCS接收到映射到UE的有效的 後端AS分配信息時，根據所述有效信息選擇後端AS。當未從SCS正確地接 收到有效後端AS分配信息時，在步驟426中，代表AS在考慮服務負載的同 時分配任意的後端AS。
在步驟427中，代表AS請求SCS把用於相關聯的UE的分配信息更新 為新分配的信息。此時，在代表AS和SCS之間交換的分配信息可以包括提 供服務所需的其他信息以及後端AS分配信息。當分配信息改變時，如果需 要，則代表AS通知在第三方註冊過程中被分配/被解除分配的後端AS:現有 的被分配的後端AS已被釋放。
圖5根據本發明示出了 UE和更高層之間的控制消息流。具體來說，圖 5示出了一個過程中的控制消息流，在所述過程中，UE;故在IMS域中註冊， 並且代表AS通過第三方註冊過程分配後端AS。
參考圖5，在步驟501中，UE通過SIP把註冊請求消息發送到IMS。在 步驟502中，S-CSCF#1給UE提供200OK響應消息，指示註冊請求消息已 被正常發送。在步驟503中，S-CSCF #1使用在HSS中註冊的UE的訂戶信 息執行第三方註冊過程。在步驟504中，S-CSCF #1把UE的註冊請求消息發 送到代表AS。在步驟505中，代表AS通過發送指示註冊請求消息已被正常 發送的200 OK消息來完成響應。
在步驟506中，代表AS在多個後端AS中分配用於處理該請求消息的後 端AS弁1，並存儲關於被分配的後端AS #1的信息和被分配的訂戶信息。例 如，訂戶信息包括UE的SIPURI或者TelURI。
在步驟507中，代表AS把第三方註冊請求消息發送到分配的後端AS # 1 。 在步驟508中，代表AS接收指示後端AS #1已經正常地接收到第三方註冊 請求消息的200 OK響應消息。此時，代表AS能夠向S-CSCF #1提供200 OK 響應消息，指示後端AS弁1已經正常地接收到第三方註冊請求消息。
當使用SCS時，通過在步驟521和522中接收有效的分配信息，代表AS可以把後端AS分配信息請求發送到SCS，並分配後端AS弁1。此外，當 在代表AS和SCS之間傳送和接收更新請求和響應消息時，可以完成用於更 新後端AS分配信息的操作。儘管在圖5中未示出，但是當存儲在SCS中的 後端AS分配信息改變時，SCS向代表AS通知改變的後端AS分配信息，以 使暫時存儲在相關聯的代表AS中的分配信息與存儲在SCS中的分配信息匹 配。這個總的過程可以被同樣地應用於用於重新註冊或者解除註冊UE的過 程。
圖6根據本發明示出了當UE發送初始請求消息和後續請求消息時的控 制消息傳輸A接收過程。
具體來說，圖6示出了用於把用於產生對話的初始請求消息從UE發送 到IMS域的過程(在步驟601到614中)，以及用於發送用於後續產生的對 話的後續請求消息的過程(在步驟615到623中)。從UE發送的邀請(INVITE) 請求消息是用於產生對話的請求消息的例子。可以應用任何請求消息。
在步驟601中，對應於用於產生對話的初始請求消息的邀請請求消息被 發送到S-CSCF#1。邀請請求消息包含呼叫標識符信息(例如呼叫ID:llll )， 以便將該UE與其他UE區分開。在本發明的優選實施例中，S-CSCF弁1被利 用多個S-CSCF構建。S-CSCF #1指示作為UE的S-CSCF運行的特定實體。 注意，S-CSCF#1和S-CSCF具有彼此相同的結構。
在步驟602中，S-CSCF #1根據訂戶信息的初始過濾標準，過濾從UE 接收到的邀請請求消息。過濾指示根據來自UE的請求消息的特定標準分配 多個代表AS中特定的一個來處理該消息。
將描述本發明的優選實施例，其中，代表AS根據初始過濾標準處理消 息。在步驟603中，S-CSCF #1基於初始過濾標準設置代表AS的信息，並基 於邀請請求消息的傳輸路徑在路由首標中設置S-CSCF #1的地址。然後，邀 請請求消息糹皮發送到代表AS。
換句話說，在步驟603中，S-CSCF #1根據在路由首標中設置的傳輸路 徑，給代表AS提供對應於初始請求消息的邀請請求消息，以便把用於產生 對話的請求發送到代表AS。 S-CSCF#1在邀請請求消息的記錄路由首標中記 錄其自身的路徑記錄信息。
在步驟604中，代表AS檢索後端AS分配信息。可以從內部存儲於代表 AS中的信息或者存儲分配信息的專用資料庫SCS獲取分配信息。接著，將描述當涉及步驟604使用了 SCS時的控制消息傳輸"妄收過程。 當使用SCS時，如果需要，則在步驟631，代表AS把後端AS分配信 息請求發送到SCS。分配信息請求消息(PULL請求)包括訂戶信息和服務 類型。當在步驟632中通過分配信息響應消息(PULL響應)從SCS接收到 後端AS分配信息時，在步驟604中，代表AS使用分配信息選擇邀請請求消 息淨M送到的後端AS。
如果後端AS分配信息未被包括在步驟632中接收的分配信息響應消息 (PULL響應)中，則在步驟633和634中，代表AS在考慮負載狀態的同時， 分配多個後端AS中適當的後端AS #1,並更新存儲在SCS中的後端AS分配
4呂息。
儘管在圖6中沒有示出，但是當存儲在SCS中的後端AS分配信息改變 時，SCS向代表AS通知改變的後端AS分配信息，以使暫時存儲在相關聯的 代表AS中的分配信息與存儲在SCS中的分配信息匹配。
在步驟605中，代表AS把邀請請求消息發送到所選擇的後端AS #1。如 果需要，代表AS可以存儲關於所選擇的後端AS #1的信息。所存儲的信息 可以當以後傳送後續消息時被用作路徑信息。
當代表AS不使用SCS時，步驟631到634可以^皮跳過。在這種情況下， 消息處理操作如下。
如果代表AS知道關於預先分配給UE的後端AS的信息，則假設後端 AS #1是預先分配的後端AS。在步驟605中，代表AS立刻把邀請請求消息 發送到被分配的後端AS #1 。如果沒有將特定後端AS預先分配給UE或者分 配信息未知，則代表AS考慮服務負載狀態而分配任意後端AS。
在步驟605中，代表AS把邀請請求消息發送到被分配的後端AS #1。如 果需要，代表AS可以存儲關於被分配的後端AS #1的信息和訂戶信息。訂 戶信息包括SIPURI、 TelURI，等等。
此時，用於把邀請請求消息發送到後端AS #1的代表AS不在包含路徑 記錄信息的記錄路由首標中記錄其自身的地址。即，在步驟605中，代表AS 在指示傳輸^各徑的路由首標中記錄後端AS #1的地址和S-CSCF #1的地址， 在包含路徑記錄信息的記錄路由首標中只記錄S-CSCF # 1的地址，並把邀請 請求消息發送到#1分配的後端AS#1。
在步驟606中，後端AS #1執行映射到邀請請求消息的服務邏輯，並在步驟607中，根據路由首標把邀請請求消息發送到S-CSCF #1。此時，後端 AS #1的地址和S-CSCF #1的地址被記錄，並作為路徑記錄信息存儲在邀請 請求消息的記錄路由首標中。
在步驟608到613中執行剩餘的過程，其中，邀請請求消息被在網絡實 體之間正常地傳遞，並報告接收完成。
結果，在步驟614中，UE從S-CSCF #1接收到指示邀請請求消息已被 在網絡實體中正常處理的200 0K響應消息。此時，200 0K響應消息包含記 錄路由首標，所述記錄路由首標包含用於在排除代表AS的狀態中實現到後 端AS#1的直接通信的路徑記錄信息。因此，UE存儲記錄路由首標作為路徑 記錄信息，並在產生後續請求消息時，使用所存儲的信息作為路由首標的路 徑信息。
步驟615到623涉及當UE在使用初始邀請請求消息產生的對話內產生 後續請求消息時，發送/接收後續請求消息。邀請請求消息是後續請求消息的 例子。在同一對話中，可以應用任何後續請求消息。
在步驟615中，UE使用包含初始邀請請求消息的路徑記錄信息的記錄 路由首標，設置包含用於發送後續邀請請求消息的路徑信息的路由首標。UE 把後續邀請請求消息發送到IMS網絡。在步驟615中，後續邀請請求消息包 含用於將所述UE與其他UE區分開的呼叫標識符信息(呼叫ID:llll)，並且 在路由首標中包含P-CSCF弁1、 S-CSCF#1、後端AS #1和S-CSCF #1的路徑化息。
由於後續邀請請求消息的傳輸路徑遵循路由首標中所包含的路徑信息， 所以在步驟616中，後續邀請請求消息被從S-CSCF #1發送到後端AS #1而 不經過代表AS。
在步驟617中，後端AS #1執行映射到後續邀請請求消息的服務邏輯， 並在步驟618中，根據路由首標把後續邀請請求消息發送到S-CSCF #1。
在步驟619到623中執行剩餘的過程，其中，後續邀請請求消息被在網 絡實體之間正常地傳遞，並報告接收完成。
當後續消息被發送時，消息被發送到特定後端AS而不經過具有負載分 布功能的代表AS,使得消息傳輸延遲和由於重新傳輸所致的延遲可以被防 止，並且實體中的消息處理時間可以4皮減少。
圖7根據本發明示出了當代表AS不知道後端AS的用戶分配狀態並且不使用SCS時的控制消息傳輸/接收過程。
除了步驟704以外，從圖7的步驟701到721是和圖6相同的過程，這 裡將省略對其的描述。
具體來說，由於在步驟704中代表AS不知道後端AS的用戶分配狀態， 所以每當接收到初始請求消息時，代表AS在新分配用於UE或服務的後端 AS之後發送消息。此時，代表AS分配後端ASW作為用於UE的AS。
在步驟722中，UE把用於產生不屬於產生的現有對話的另一個對話的 初始邀請請求消息發送到IMS域。UE把包含與先前邀請請求消息的呼叫標 識符信息(呼叫ID:llll)不同的呼叫標識符信息(呼叫ID:2222)的邀請請 求消息發送到S-CSCF#1。
在步驟723中，根據初始過濾標準，用於包含呼叫標識符信息(呼叫 ID:2222 )的邀請請求消息的AS被確定是代表AS。在步驟724中，包含呼叫 標識符信息(呼叫ID:2222)的邀請請求消息被發送到代表AS。此時，邀請 請求消息被發送，在該邀請請求消息中，代表AS的地址和S-CSCF #1的地 址被存儲在路由首標中，並且只有S-CSCF #1的地址被存儲在記錄路由首標 中。
在步驟725中，代表AS新分配後端AS #2,因為代表AS不知道用於 UE的後端AS分配狀態。在步驟726中，代表AS把邀請請求消息發送到後 端AS #2，在所述邀請請求消息中，後端AS #2的地址和S-CSCF #1的地址 被設置在路由首標中，並且S-CSCF #1的地址被設置在記錄路由首標中。
在步驟727中，新分配的後端AS #2把邀請請求消息發送到S-CSCF #1 ， 在所述邀請請求消息中，後端AS #2的地址淨皮記錄在路由首標中，並且後端 AS #2的地址和S-CSCF #1的地址被記錄在記錄路由首標中。
處理邀請請求消息的步驟728到734和圖6的步驟相同，所以這裡省略 對其的描述。
在步驟734中，UE接收指示由於其他對話所致的邀請請求消息已被正 常處理的200 0K響應消息。在200OK響應消息中，記錄路由首標包含指示 消息已經被發送到新分配的後端AS #2/消息已經被通過新分配的後端AS #2 發送的路徑記錄信息。
如上所述在本發明中，IMS網絡實體把用戶(或UE)的初始請求發送 到代表AS,代表AS進而把接收到的請求發送到在註冊UE時預先分配給用戶的後端AS,或者通過#4居負載狀態分配適於服務目的的新後端AS來處理 消息。此時，代表AS使用SIP標準，利用多個後端AS處理請求消息。
因此，本發明的優點在於不同製造商的具有相同功能的AS之間的互 操作性得到保障，並且AS的呼叫處理能力被同時擴展。
圖8根據本發明示出了當後端AS作為用戶代理(User Agent, UA)運 行時的控制消息傳輸/接收過程。
在圖8中，訂閱請求消息是其中AS作為UA運行的例子。可以應用任 何請求消息。當AS作為UA運行時，UE可以通過將目標伺服器的請求URI 設置為AS地址(或公共服務身份(Public Service Identity, PSI))或者子域 PSI來發送消息。因此，UE應該在後續請求消息中明確地包括直到後端AS 的路徑信息，以便把後續請求消息直接發送到由代表AS分配的後端AS。
參考圖8，在步驟801中，UE把包含呼叫標識符信息(呼叫ID:llll) 的訂閱請求消息發送到S-CSCF#1，以使該UE能夠被與其他UE區分開。此 時，訂閱請求消息的路由首標被設置為S-CSCF#1的地址。
在步驟802中，S-CSCF #1根據初始過濾標準過濾接收到的訂閱請求消 息。此時，按初始過濾標準註冊的AS是代表AS。因此，在步驟803中，S-CSCF #1在指示訂閱請求消息的傳輸路徑的路由首標中設置其自身的地址和代表 AS的地址。此外，S-CSCF # 1在記錄路由首標中只記錄其自身的地址。
在步驟804中，代表AS使用內部存儲於代表AS中或者存儲分配信息的 SCS中的信息檢索後端AS分配信息。然後，代表AS把訂閱請求消息發送到 所選擇的後端ASW。此時，代表AS發送訂閱請求消息，在該訂閱請求消息 中，後端AS #1的地址和S-CSCF #1的地址被設置在路由首標中，並且只有 S-CSCF #1的地址#3殳置在記錄路由首標中。
在步驟806中，後端AS弁1執行映射到訂閱請求消息的服務邏輯。在步 驟807中，後端AS #1把其自身地址添加到記錄路由首標的最上端，並且在 對訂閱請求消息的響應被產生時發送該響應。即，S-CSCF #1的地址和後端 AS#1的地址被記錄在要發送到UE的響應消息的記錄路由首標中。
在步驟809中，當接收到對訂閱請求消息的響應時，UE存儲記錄^各由 首標中所包含的路徑記錄信息。在步驟810中，當發送重新訂閱請求消息時， UE使用存儲的記錄路由首標的路徑記錄信息設置新消息的路徑信息。即，在 步驟810中，UE在路由首標中設置先前訂閱請求消息的記錄路由首標的信息，以使新訂閱請求消息能夠被直接發送到後端AS #1。
因此，在步驟811中，S-CSCF #1發送新訂閱請求消息，在該訂閱_清求 消息中，後端AS#1的地址被設置在路由首標中。在步驟812和813中，UE 接收指示後端AS #1已經正常接收到訂閱請求消息的200 OK響應消息。
圖9根據本發明示出了代表AS的結構。
參考圖9,接收器901從例如UE、 S-CSCF、後端AS和SCS的IMS網 絡實體接收控制消息。
控制器903執行用於處理接收到的控制消息的總體操作，並與分配器907 及存儲器905交換所需信息。
存儲器905存儲處理控制消息所需的數據。例如，初始請求消息的傳輸 路徑信息可以淨皮存儲並用作後續請求消息的傳輸路徑信息。或者，存儲器905 可以存儲例如用於發送了先前請求消息的特定UE的後端AS分配信息。當從 該UE接收到請求消息時，控制器903可以通過從存儲器905讀取所需數據 來分配傳輸路徑或後端AS。
分配器907包括例如用於分配後端AS的算法。傳送器909把控制消息 發送到例如UE、 S-CSCF、後端AS和SCS的IMS網絡實體。
圖IO根據本發明示出了當HSS被用作SCS時在HSS、代表AS和後端 AS間的控制消息傳輸/接收過程。當HSS被用作SCS時，HSS能夠在用於存 儲用戶的逐服務(service by service)的透明數據的儲存庫(repository)數據區域 中存儲後端AS分配信息。這裡，透明數據是唯一的服務數據，並且不能在 除了 HSS和用於提供相關聯的服務的AS以外的其他地方使用。
參考圖10，代表AS通過Sh接口把Sh-Pull請求1000發送到HSS,以 便在HSS中註冊後端AS分配信息，並且使用響應1002接收存儲在HSS中 的透明數據，其中，在Sh接口上，AS和HSS相互通信。
在把後端AS分配信息添加到從HSS下載的透明數據後，代表AS把Sh 更新請求1004發送到HSS,並接收響應1006。後端AS分配信息和透明悽t據 都被存儲在HSS中。這裡，Sh被定義為標準中的AS和HSS之間的接口 ， 並且不包括任何特定含義。
此時，存儲在HSS中的透明數據包括後端AS分配信息。當後端AS把 透明數據請求發送到HSS時，可能發生錯誤操作，因為後端AS分配信息被 與透明數據一起發送。為了防止這樣的錯誤操作，後端AS通過把Sh-Pull請求1008發送到K 表AS來間接地請求透明數據。代表AS通過從自HSS接收到的透明數據中 排除後端AS分配信息，只把剩餘透明數據發送到後端AS (如附圖標記1014 所指示)。當代表AS在內部存儲透明數據時，可以跳過代表AS和HSS之間 的Sh-Pull請求1010和響應1012。
具體來說，在步驟1008到1014中，當後端AS請求透明數據時，儘管 從HSS接收到包括後端AS分配信息的透明數據，代表AS還是給後端AS 提供排除了後端AS分配信息的透明數據。因此，防止了錯誤操作。
從上面的描述很清楚，本發明至少具有下列優點。
本發明通過在IMS移動通信系統中基於SIP發送和接收呼叫連接所需的 控制消息，能夠保障互操作性，即，不同製造商的具有相同功能的AS之間 的兼容性。因此，IMS的AS的呼叫處理能力可以被擴展。
而且，本發明能夠通過在IMS的AS組的分級AS結構中經標準SIP發 送消息，分布要在AS中處理的請求消息。在更高層的概念上，由於消息處 理所致的傳輸延遲和重新傳輸延遲被防止。
換句話說，更高層伺服器中的瓶頸狀況被減少，並且能夠縮短重新請求 控制信號的路徑。
雖然已經參考本發明的某些示範性實施例示出並描述了本發明，但是本 領域普通技術人員將理解，在不偏離本發明的由所附權利要求及其等同物限 定的精神和範圍的情況下，可以對其做出形式和細節上的各種變化。
權利要求
1. 一種用於在支持多媒體服務的基於網際網路協議的移動通信系統中處理來自用戶設備的請求消息的方法，包含由代表應用伺服器在多個較低層應用伺服器中分配用於處理消息的特定較低層應用伺服器，按消息的標準選擇代表應用伺服器；和把消息發送到被分配的較低層應用伺服器而不在消息的記錄路由首標中設置所述代表應用伺服器。
2. 如權利要求1所述的方法，還包含由特定較低層應用伺服器處理所述消息，並在所述消息的記錄路由首標 中設置特定較低層應用伺服器之後把所述消息發送到交換機。
3. 如權利要求2所述的方法，還包含當從用戶設備接收到後續消息時，基於從記錄路由首標中得出的路由首 標，由交換機把後續消息直接發送到特定較低層應用伺服器。
4. 一種供在支持多媒體服務的基於網際網路協議的移動通信系統中使用 的網際網路協議網絡系統，所述系統處理來自用戶設備的請求消息，包含交換機，用於從多個代表應用伺服器中選擇用於處理映射到由用戶設備 所請求的特定服務的消息的特定代表應用伺服器，並把所述消息發送到所述特定代表應用伺服器；特定代表應用伺服器，用於在多個較低層應用伺服器中分配用於處理消 息的特定較低層應用伺服器，並旁路所述消息；和特定較低層應用伺服器，用於處理所述消息並通過在所述消息的記錄路 由首標中設置其自己的路徑信息來把所述消息發送到所述交換機。
5. 如權利要求4所述的網際網路協議網絡系統，其中，交換機是服務呼叫 會話控制功能(Serving-Call Session Control Function, S-CSCF )伺服器。
6. 如權利要求4所述的網際網路協議網絡系統，其中，當從用戶設備接收 到後續消息時，交換機根據從記錄路由首標中得到的路由首標把後續消息直 接發送到特定較低層應用伺服器。
7. —種用於在基於網際網路協議的移動通信系統中處理支持多媒體服務 的控制消息的方法，包含通過會話發起協議，把針對會話的請求消息從用戶設備發送到網際網路協議多媒體子系統(IMS), IMS是支持多媒體服務的網際網路網絡；把所述請求消息從IMS的代表應用伺服器發送到從多個較低層應用伺服器中選擇的較低層應用伺服器；和由被選擇的較低層應用伺服器處理所述請求消息，並把響應消息發送到用戶設備。
8. 如權利要求7所述的方法，其中，把所述請求消息從IMS的代表應用 伺服器發送到從多個較低層應用伺服器中選擇的較低層應用伺服器還包含把包括作為路由首標的路徑信息的被選擇的較低層應用伺服器的地址的 請求消息從代表應用伺服器發送到被選擇的較低層應用伺服器。
9. 如權利要求7所述的方法，其中，由被選擇的較低層應用伺服器處理 請求消息，並把響應消息發送到用戶設備還包含把包括作為記錄路由首標的路徑記錄信息的被選擇的較低層應用伺服器 的地址的響應消息從被選擇的較低層應用伺服器發送到用戶設備。
10. 如權利要求9所述的方法，還包含由用戶設備把響應消息的記錄路由首標的路徑記錄信息設置為下一個會 話的路徑信息，並把後續請求消息發送到被選擇的較低層應用伺服器。
11. 一種用於在支持多媒體服務的基於網際網路的移動通信系統中降低處 理應用層的控制消息的負載的方法，包含通過會話發起協議把包括呼叫標識符信息的會話請求消息從用戶設備發 送到服務伺服器；把在記錄路由首標中包括服務伺服器地址的會話請求消息從服務伺服器 發送到應用層的代表應用伺服器；由代表應用伺服器分配用於處理會話請求消息的後端應用伺服器，並把 會話請求消息發送到被分配的後端應用伺服器；由後端應用伺服器處理會話請求消息，並把在記錄路由首標中包括後端 應用伺服器的路徑記錄信息的響應消息發送到用戶設備；和由用戶設備把響應消息的記錄路由首標的路徑記錄信息設置為用於發送 下一個會話請求消息的路徑信息，並通過會話發起協議把所述下一個會話請 求消息發送到被分配的後端應用伺服器，所述下一個會話請求消息包括和所 述會話請求消息中的呼叫標識符信息相同的呼叫標識符信息。
12. 如權利要求11所述的方法，其中，代表應用伺服器分配用於處理會話請求消息的後端應用伺服器，並把所述會話請求消息發送到被分配的後端 應用伺服器，而沒有在記錄路由首標中包括對應於所述路徑記錄信息的代表 應用伺服器地址。
13. —種用於在支持多媒體服務的基於網際網路的移動通信系統中降低處理應用層的控制消息的負載的方法，包含通過會話發起協議把包括呼叫標識符信息的會話請求消息從用戶設備發 送到服務伺服器；把在記錄路由首標中包括服務伺服器地址的會話請求消息從服務伺服器 發送到應用層的代表應用伺服器；由代表應用伺服器分配用於處理所述會話請求消息的後端應用伺服器， 並把會話請求消息發送到被分配的後端應用伺服器；由後端應用伺服器處理所述會話請求消息，並把在記錄路由首標中包括 後端應用伺服器的路徑記錄信息的響應消息發送到用戶設備；由用戶設備接收所述響應消息，並通過會話發起協議把包括呼叫標識符 信息的下一個會話請求消息發送到服務伺服器；和由服務伺服器檢查下一個會話請求消息的記錄路由首標的路徑記錄信 息，並把下一個會話請求消息發送到被分配的後端應用伺服器。
14. 如權利要求13所述的方法，其中，用戶設備通過會話發起協議把用 於建立會話的邀請請求消息發送到服務伺服器。
15. —種用於在支持多媒體服務的基於網際網路協議的移動通信系統中發 送呼叫控制消息的方法，包含由較高層應用伺服器通過會話發起協議從用戶設備接收呼叫請求消息； 從存儲多個用戶設備的分配信息的資料庫伺服器檢索映射到該用戶設備 的較低層應用伺服器的分配信息；和通過會話發起協議把呼叫請求消息發送到被分配的較低層應用伺服器。
16. 如權利要求15所述的方法，還包含當從資料庫伺服器未接收到映射到該用戶設備的分配信息時，較高層服 務器在考慮負載狀態的同時，在多個較低層應用伺服器中分配特定較低層應 用伺服器，並通過會話發起協議，更新資料庫伺服器中用於該用戶設備的較 低層應用伺服器的分配信息。
17. 如權利要求16所述的方法，還包含在分配所述特定較低層應用伺服器之後，由較高層應用伺服器通過會話 發起協議把呼叫請求消息發送到被分配的較低層應用伺服器，而不在呼叫請 求消息的路徑記錄信息中記錄關於較高層應用伺服器的信息。
18. 如權利要求17所述的方法，還包含通過會話發起協議，從用戶設備接收所述呼叫請求消息之後的請求消息；和根據其中排除了所述較高層應用伺服器的路徑信息，通過會話發起協議 把後續請求消息直接發送到較低層應用伺服器。
19. 如權利要求16所述的方法，其中，較高層應用伺服器把包括特定較 低層應用伺服器的分配信息的逐個服務的透明數據存儲在歸屬訂戶伺服器 中，並通過當檢測到來自所述特定較低層應用伺服器的透明數據請求時從所 存儲的透明數據排除所述特定較低層應用伺服器的分配信息，把透明數據發 送到所述特定較低層應用伺服器。
20. —種用於在支持網際網路協議多媒體子系統的移動通信系統中的應用 伺服器組的系統，包含較高層應用伺服器，包括存儲器，用於存儲從用戶設備發送的呼叫請 求消息的傳輸路徑信息和先前呼叫請求消息的傳輸記錄信息其中的至少一 個；分配器，具有用於使用存儲在所述存儲器中的數據選擇特定較低層應用 伺服器的算法；以及控制器，用於通過所述存儲器和所述分配器從多個較低 層應用伺服器中選擇用於處理所述呼叫請求消息的特定較低層應用伺服器； 和較低層應用伺服器，用於從較高層應用伺服器接收分配信息，並通過會 話發起協議接收所述呼叫請求消息。
全文摘要
本發明公開一種用於在支持多媒體服務的基於網際網路協議的移動通信系統中處理控制消息的方法和系統。在所述系統中，應用伺服器包括代表應用伺服器和多個後端應用伺服器。提供了一種用於定義應用伺服器之間的控制消息以便使用標準網際網路協議建立會話的方法。當應用伺服器執行呼叫處理操作時，控制消息處理負載和控制消息傳輸延遲被降低。
文檔編號H04L29/06GK101449551SQ200780018734
公開日2009年6月3日 申請日期2007年3月21日 優先權日2006年3月21日
發明者宋晤碩, 廉泰善, 林嫻娜, 鄭僔 申請人:三星電子株式會社