專利名稱：版本不同的網(wǎng)間互聯(lián)協(xié)議網(wǎng)絡(luò)互通的方法
技術(shù)領(lǐng)域：
本發(fā)明涉及不同版本IP網(wǎng)絡(luò)的互通，特別涉及和網(wǎng)際協(xié)議多媒體核心網(wǎng)
子系統(tǒng)系統(tǒng)(IMS)有關(guān)的不同版本的IP網(wǎng)絡(luò)的互通。
背景技術(shù)：
移動通信系統(tǒng)能夠滿足人們隨時隨地進行通信的要求，從它出現(xiàn)后就得 到了迅速的發(fā)展。隨著第三代移動通信(The Third Generation, 簡稱"3G") 技術(shù)的提出和進一步發(fā)展，移動網(wǎng)絡(luò)的帶寬大大增加，移動通信將不僅僅局 限于傳統(tǒng)的語音通信，結(jié)合音頻、視頻、圖片和文本等多種媒體類型的多媒 體業(yè)務(wù)將逐漸開展起來。移動通信與呈現(xiàn)業(yè)務(wù)(presence)、短消息、網(wǎng)頁瀏 覽、定位信息、推送業(yè)務(wù)(PUSH)、文件共享等數(shù)據(jù)業(yè)務(wù)的結(jié)合，可以為 用戶提供更多的業(yè)務(wù)選擇，例如消息業(yè)務(wù)類的即時消息和聊天室、多媒體短 消息，視頻業(yè)務(wù)類的娛樂、多媒體信息、日常交流，電子商務(wù)類的產(chǎn)品目錄、 搜索引擎、購物車、訂單管理、支付，游戲類的單人游戲、群組游戲，定位 業(yè)務(wù)類的尋人、向?qū)?、報警，個人助理類的地址本、日程表、書簽管理、文 件存儲、事件提醒、電子郵件，能夠更好的滿足用戶的多種需求。
考慮到網(wǎng)間互聯(lián)協(xié)議(Internet Protocol,簡稱"IP，，)網(wǎng)絡(luò)的應(yīng)用越來 越廣泛，第三代合作伙伴項目(3rd Generation Partnership Project,簡稱 "3GPP，，)以及第三代合作伙伴項目2 ( 3rd Generation Partnership Project 2, 簡稱"3GPP2")等標準組織都制定了將移動通信網(wǎng)絡(luò)向全分組、全IP的方 向演進的標準，提出了基于IP的多媒體子系統(tǒng)架構(gòu)，目的是在移動網(wǎng)絡(luò)中使 用 一種標準化的開放的結(jié)構(gòu)來實現(xiàn)多種多樣的多媒體應(yīng)用，提供給用戶更多 的選擇和更豐富的感受。其中，3GPP在版本5 (Release 5,簡稱"R5")階段引入了 IP多媒體 子系統(tǒng)(IP Multimedia Subsystem,簡稱"IMS")域，疊加在分組域網(wǎng)絡(luò) 之上。IMS由呼叫狀態(tài)控制功能(Call Session Control Function,簡稱"CSCF")、 媒體網(wǎng)關(guān)控制功能(Media Gateway Control Function,簡稱"MGCF")、媒 體資源功能(Multimedia Resource Function,簡稱"MRF")和歸屬簽約用 戶服務(wù)器(Home Subscriber Server,簡稱"HSS")等功能實體組成。CSCF 又可以分成服務(wù)CSCF ( Serving CSCF，簡稱"S-CSCF")、代理CSCF( Proxy CSCF,簡稱"P-CSCF，，)和查詢CSCF (Interrogating CSCF,簡稱"I陽CSCF") 三個邏輯實體。其中，S-CSCF是IMS的業(yè)務(wù)交換中心，執(zhí)行會話控制，維 持會話狀態(tài)，負責(zé)管理用戶信息，產(chǎn)生計費信息等；P-CSCF是終端用戶接 入IMS的接入點，完成用戶注冊，負責(zé)QoS控制和安全管理等；I-CSCF負 責(zé)IMS域之間的互通，管理S-CSCF的分配，對外隱藏網(wǎng)絡(luò)拓樸和配置，產(chǎn) 生計費數(shù)據(jù)等。MGCF控制網(wǎng)關(guān)，實現(xiàn)IMS網(wǎng)絡(luò)和其它網(wǎng)絡(luò)的互通，MRF 提供媒體資源，如收放音，編解碼和多媒體會議橋。HSS是用戶數(shù)據(jù)庫，存 儲IMS用戶的簽約數(shù)據(jù)和配置信息等。由于IMS網(wǎng)絡(luò)的結(jié)構(gòu)做到了和底層承載網(wǎng)絡(luò)無關(guān)，因此3GPP定義的 IMS網(wǎng)絡(luò)也可以應(yīng)用在3GPP定義的分組域網(wǎng)絡(luò)之外的其他分組網(wǎng)絡(luò)上，比 如3GPP2中定義的分組網(wǎng)絡(luò)，無線局域網(wǎng)(Wireless Local Area Network,簡 稱"WLAN")，以及下一代網(wǎng)絡(luò)(Next Generation Network,簡稱"NGN")里不限制IMS只應(yīng)用在3GPP相關(guān)的網(wǎng)絡(luò)和應(yīng)用上，其他類型的接入網(wǎng)絡(luò)和 承載網(wǎng)絡(luò)的業(yè)務(wù)和應(yīng)用也可以用IMS架構(gòu)來實現(xiàn)。在IMS中，使用會話初始化協(xié)議(Session Initiation Protocol,簡稱"SIP") 作為IP多媒體會話的信令控制協(xié)議。其中，SIP協(xié)議是由互聯(lián)網(wǎng)工程任務(wù)組 (Internet Engineering Task Force,簡稱"IETF")提出的IP電話信令協(xié)議。 正如其名字所隱含的，SIP用于發(fā)起會話，它能控制多個參與者參加的多媒 體會話的建立和終結(jié)，并能動態(tài)調(diào)整和修改會話屬性，如會話帶寬要求、傳 輸?shù)拿襟w類型(語音、視頻和文本等)、媒體的編解碼格式、對組播和單播 的支持等。3GPP在制定IMS相關(guān)規(guī)范時，考慮到網(wǎng)間互聯(lián)協(xié)議第4版(Internet Protocol version 4，簡稱"IPv4")存在地址空間即將耗盡、路由表爆炸等問 題，而IMS的廣泛應(yīng)用要求大量可用的IP地址，在實現(xiàn)多種媒體類型融合 的下一代網(wǎng)絡(luò)中對網(wǎng)絡(luò)的安全、質(zhì)量和移動性都提出了更高的要求，因此， 3GPP明確規(guī)定實現(xiàn)IP多媒體業(yè)務(wù)時，用戶終端必須支持使用IPv6地址進行 通訊。對移動網(wǎng)絡(luò)功能實體而言，IMS的所有功能實體，包括用戶設(shè)備(User Equipment,簡稱"UE" ) 、 CSCF、 MGCF、 MRF和應(yīng)用月l務(wù)器(Application Server,簡稱"AS")都必須支持IPv6，通用分組無線業(yè)務(wù)網(wǎng)關(guān)支持節(jié)點(GPRS Gateway Support Node,簡稱"GGSN")與IMS有接口，也必須支持網(wǎng)間互 聯(lián)協(xié)議第6版(Internet Protocol version 6,簡稱"IPv6"),為支持動態(tài)地 址解析，GGSN還需支持IPv6的動態(tài)主機配置協(xié)議(Dynamic Host Configuration Protocol,簡稱"DHCP")。但是隨著市場的變化和技術(shù)的發(fā)展，IPv6規(guī)模商用目前沒有達到原來預(yù) 計的速度，同時缺乏所有基于IPv6產(chǎn)品的支持將使基于IPv6的IMS應(yīng)用延 遲，移動運營商為了通過給3G用戶提供更豐富的多媒體業(yè)務(wù)，促進寬帶碼 分多址(Wideband Code Division Multiple Access,簡稱"WCDMA，， ) IMS 的盡快商用，來吸引更多的用戶，促進3G網(wǎng)絡(luò)的發(fā)展，向3GPP提出建議， 考慮在IMS的實現(xiàn)中支持IPv4來滿足早期商用的需求。同時，3G另一種主 流制式碼分多址2000 ( Code Division Multiple Access 2000 , 簡稱 "CDMA2000")的標準化組織3GPP2制定的多媒體域(Multimedia Domain, 簡稱"MMD")可基于IPv4或IPv6實現(xiàn)，并且Internet上已有不少基于IPv4 的商用SIP終端，這將導(dǎo)致3GPP基于IPv6的IMS與外部基于IPv4網(wǎng)絡(luò)的 互通問題。因此，3GPP決定在初期的IMS產(chǎn)品中將增加對IPv4的支持，使 得IMS同時支持IPv6和/或IPv4，這樣3GPP就需要研究如何引入基于IPv4 的IMS，以及基于IPv4和IPv6 IMS之間的互通和漫游、IMS和IPv4 SIP應(yīng)用之間的互通等問題。3GPP技術(shù)報告(Technical Report,簡稱"TR" ) 23.981對各種可能存 在的互通問題進行了分析，包括UE支持的IP版本類型，IMS網(wǎng)絡(luò)支持的 IP版本類型，GPRS網(wǎng)絡(luò)支持的IP版本類型，考慮漫游的情況，端到端的互 通場景，涉及業(yè)務(wù)的IP版本互通等。在需要實現(xiàn)IP版本互通的地方使用網(wǎng) 絡(luò)地址轉(zhuǎn)換和協(xié)議轉(zhuǎn)換 (Network Address Translation and Protocol Translation,簡稱"NAT-PT")和應(yīng)用層網(wǎng)關(guān)(Application Layer Gateway, 簡稱"ALG")功能，其中，NAT-PT功能用于實現(xiàn)網(wǎng)絡(luò)地址變換和協(xié)議變 換，ALG功能用于實現(xiàn)應(yīng)用層相關(guān)的地址變換。因為每次使用NAT-PT和ALG功能就意味著增加會話的時延，降低了 服務(wù)質(zhì)量，這就意味著IP地址轉(zhuǎn)換的次數(shù)越少，對會話的服務(wù)質(zhì)量影響越小， 進而減輕了對實現(xiàn)NAT-PT和ALG功能的設(shè)備的壓力，減少了網(wǎng)絡(luò)瓶頸的 個數(shù)，因此在IPv4和IPv6互通時就需要考慮在什么時候引入NAT-PT和 ALG功能，可以使得實現(xiàn)端到端的互通過程中經(jīng)過的轉(zhuǎn)換次數(shù)最少?，F(xiàn)有的解決IMS中IPv4和IPv6互通的方案是由3GPP提出的。在現(xiàn)有 技術(shù)方案中，UE可以是只支持IPv4協(xié)議棧，只支持IPv6協(xié)議棧，或者同時 支持IPv4和IPv6雙棧；同樣，在會話建立中涉及到的其他功能實體，如對 端UE、 AS、 CSCF、 GGSN等都可能是只支持IPv4，只支持IPv6，或者同時 支持雙棧?？紤]到今后IMS網(wǎng)絡(luò)發(fā)展的趨勢是都試用IPv6地址，同時岡為現(xiàn)有IPv4 地址空間的緊張，很多運營商使用私網(wǎng)IP地址，導(dǎo)致和其他IP域網(wǎng)絡(luò)進行 互通的時候必須將私網(wǎng)IPv4地址轉(zhuǎn)化為公網(wǎng)IP地址，因此，現(xiàn)有4支術(shù)方案 建議盡量使用IPv6地址，這樣可以減少使用ALG/NAT-PT功能的情況，從 而提高會話的服務(wù)質(zhì)量。在涉及業(yè)務(wù)的IP版本互通中，3GPP建議的實現(xiàn)一個IPv4 UE和IPv6 UE 之間進行即時消息業(yè)務(wù)的方案如圖1所示。其中UEA支持IPv4，在傳送即時消息給UE B的時候，不涉及到々某體 成分的協(xié)商，直接使用SIP信令攜帶相關(guān)的信息，UEB支持Pv6，其歸屬網(wǎng) 絡(luò)和UEA不同。在發(fā)起方一側(cè)，UEA的歸屬S-CSCF支持雙棧，負責(zé)將使 用IPv4傳送的SIP消息直接轉(zhuǎn)化為使用IPv6傳送的SIP消息，然后繼續(xù)傳 送給接收方UEB。當(dāng)IMS網(wǎng)絡(luò)中的UE發(fā)起會話的時候，現(xiàn)有的互通方案中的處理過程如 圖2所示。其中，IMS-ALG指的是IMS網(wǎng)絡(luò)中的ALG功能實體，TrGW是IMS網(wǎng) 絡(luò)中的網(wǎng)絡(luò)地址轉(zhuǎn)換-協(xié)議轉(zhuǎn)換(Network Address Translator - Protocol Translator,簡稱"NAT-PT")功能實體。根據(jù)圖2的描述，會話發(fā)起方UE A支持IPv6,其所在的歸屬S-CSCF通過域名服務(wù)系統(tǒng)(Domain Name System, 簡稱"DNS")查詢等^L制判斷接收方無法通過IPv6進行通信，則通過和 IMS-ALG以及TrGW的交互，替換SIP消息中IPv6版本相關(guān)的信息，然后 使用IPv4和用戶側(cè)B繼續(xù)會話協(xié)商過程，建立媒體傳輸路徑?？梢钥闯?，現(xiàn)有的不同IP版本之間互通的方案先確定了通信雙方UE支 持的IP版本，即發(fā)起方使用IPv4,接收方使用IPv6,然后根據(jù)這個前提， 在最早可以使用ALG/NAT-PT功能的地方，即支持雙棧的發(fā)起方UE歸屬 S-CSCF處，執(zhí)行IP版本相關(guān)信息的映射。熟悉本領(lǐng)域的技術(shù)人員可以理解， 現(xiàn)有的技術(shù)方案優(yōu)先使用IPv6,即只要下一個功能實體能夠支持IPv6，就執(zhí) 行IPv4到IPv6的轉(zhuǎn)換。
在實際應(yīng)用中，上述方案存在以下問題現(xiàn)有的技術(shù)方案對IMS中不同 IP版本互通的情況考慮不全面，而且在不同IP版本互通時可能需要完成不 必要的版本轉(zhuǎn)換，增加了實現(xiàn)ALG/NAT-PT的設(shè)備的壓力，影響會話的服務(wù) 質(zhì)量。造成這種情況的主要原因在于，首先，現(xiàn)有的技術(shù)方案認為發(fā)起方使用 IPv4,接收方使用IPv6,而實際情況并非如此，早期商用的IMS很可能由于 業(yè)務(wù)的限制以及IPv6設(shè)備的可用性差而只支持IPv4,稍后實現(xiàn)的IMS網(wǎng)絡(luò) 則出于前向兼容和后向兼容的考慮，會同時支持雙棧，當(dāng)技術(shù)更穩(wěn)定，市場 更成熟的時候，可能只實現(xiàn)IPv6的IMS網(wǎng)絡(luò)，因此這三種類型的IMS網(wǎng)絡(luò) 在IP版本互通的時候都需要考慮，尤其是IMS網(wǎng)絡(luò)使用的初期，還需要考 慮和大量現(xiàn)有IPv4網(wǎng)絡(luò)和業(yè)務(wù)之間的互通，否則可能會存在大量的可以避免 的IP版本之間的轉(zhuǎn)換，比如當(dāng)主叫歸屬網(wǎng)絡(luò)只支持IPv4，被叫歸屬網(wǎng)絡(luò)支 持雙棧，而且主叫UE和被叫UE都是使用IPv4地址的時候，主叫歸屬網(wǎng)絡(luò) 中完全可以不執(zhí)行IPv4到IPv6的地址信息轉(zhuǎn)換。其次，實際實現(xiàn)的時候，主叫歸屬S-CSCF無法事先知道目的UE使用 的IP地址類型，只能知道目的UE歸屬網(wǎng)絡(luò)所在的IP域的地址類型，當(dāng)目 的UE漫游到了另一個網(wǎng)絡(luò)中，由漫游網(wǎng)絡(luò)分配IP地址的時候，該UE使用 的IP版本只有其歸屬S-CSCF知道，按照現(xiàn)有技術(shù)，在最早可以使用 ALG/NAT-PT的地方執(zhí)行IP版本相關(guān)信息的映射之后，很可能在到達目的 UE的歸屬網(wǎng)絡(luò)之后需要執(zhí)行新的ALG/NAT-PT變換，比如，當(dāng)主叫歸屬網(wǎng) 絡(luò)只支持IPv4，而被叫歸屬網(wǎng)絡(luò)支持雙棧，而且主叫UE和被叫UE都是使 用IPv4地址的，而實際上這些轉(zhuǎn)換完全可以不執(zhí)行，造成了不必要的IP版 本之間的轉(zhuǎn)換。 發(fā)明內(nèi)容有鑒于此，本發(fā)明的主要目的在于提供一種版本不同的網(wǎng)間互聯(lián)協(xié)議網(wǎng)絡(luò)互通的方法，使得應(yīng)用IMS時，減少了不必要轉(zhuǎn)換和ALG/NAT-PT處理， 減輕了 ALG/NAT-PT設(shè)備的壓力，使版本不同的IP網(wǎng)絡(luò)的互通效果更好。為實現(xiàn)上述目的，本發(fā)明提供了一種版本不同的網(wǎng)間互聯(lián)協(xié)議網(wǎng)絡(luò)互通 的方法，包含以下步驟C主叫用戶設(shè)備的歸屬呼叫狀態(tài)控制功能設(shè)備判斷被叫用戶設(shè)備的歸 屬網(wǎng)絡(luò)是否支持所述主叫用戶設(shè)備的網(wǎng)間互聯(lián)協(xié)議版本，如果是則將來自所 述主叫用戶設(shè)備的消息直接轉(zhuǎn)發(fā)給所述被叫用戶設(shè)備的歸屬呼叫狀態(tài)控制功 能設(shè)備，否則將該消息進行網(wǎng)間互聯(lián)協(xié)議版本轉(zhuǎn)換后轉(zhuǎn)發(fā)給所述被叫用戶設(shè) 備的歸屬呼叫狀態(tài)控制功能設(shè)備；D所述被叫用戶設(shè)備的歸屬呼叫狀態(tài)控制功能設(shè)備響應(yīng)所述消息，判斷 所述被叫用戶設(shè)備是否支持所述消息的網(wǎng)間互聯(lián)協(xié)議版本，如果是則將所述 消息直接轉(zhuǎn)發(fā)給所述被叫用戶設(shè)備，否則將所述消息進行網(wǎng)間互聯(lián)協(xié)議版本 的轉(zhuǎn)換后發(fā)送給所述被叫用戶設(shè)備。其中，所述方法在步驟C之前還包含以下步驟A所述主叫用戶設(shè)備的歸屬呼叫狀態(tài)控制功能設(shè)備判斷發(fā)起會話并發(fā) 送消息的主叫用戶設(shè)備的網(wǎng)間互聯(lián)協(xié)議地址是否是私有地址，如果是則進入 步驟B，否則進入步驟C;B判斷被叫用戶設(shè)備是否和所述主叫用戶設(shè)備處于同一歸屬網(wǎng)絡(luò)中，如 果是則直接進行通信，否則應(yīng)用網(wǎng)絡(luò)地址轉(zhuǎn)換設(shè)備將所述私有地址轉(zhuǎn)換為公 有地址后進入步驟C。所述步驟C中，所述主叫的歸屬呼叫狀態(tài)控制功能設(shè)備通過查詢本地配 置或域名服務(wù)系統(tǒng)得到所述被叫的歸屬網(wǎng)絡(luò)支持的網(wǎng)間互聯(lián)協(xié)議版本類型。
所述步驟C和D中，所述呼叫狀態(tài)控制功能設(shè)備對所述消息進行網(wǎng)間互 聯(lián)協(xié)議版本轉(zhuǎn)換的步驟還進一步包含以下子步驟所述呼叫狀態(tài)控制功能設(shè)備判斷所述會話中否有媒體描述，如果所述會 話有媒體描述，則使用應(yīng)用層網(wǎng)關(guān)設(shè)備以及網(wǎng)絡(luò)地址轉(zhuǎn)換和協(xié)議轉(zhuǎn)換設(shè)備實 現(xiàn)網(wǎng)間互聯(lián)協(xié)議版本信息的轉(zhuǎn)換，如果所述會話沒有媒體描述，則直接在所 述呼叫狀態(tài)控制功能設(shè)備中實現(xiàn)網(wǎng)間互聯(lián)協(xié)議版本信息的轉(zhuǎn)換。所述呼叫狀態(tài)控制功能設(shè)備在轉(zhuǎn)發(fā)消息給所述應(yīng)用層網(wǎng)關(guān)設(shè)備時攜帶 用于后續(xù)消息路由的下一跳地址。所述應(yīng)用層網(wǎng)關(guān)設(shè)備以及網(wǎng)絡(luò)地址轉(zhuǎn)換和協(xié)議轉(zhuǎn)換設(shè)備之間可采用擴 展的H.248消息或媒體網(wǎng)關(guān)控制協(xié)議通信。所述消息可以是會話初始化協(xié)議消息。通過比較可以發(fā)現(xiàn)，本發(fā)明的技術(shù)方案與現(xiàn)有技術(shù)的區(qū)別在于，本發(fā)明 只有在本節(jié)點和下一跳節(jié)點的IP版本不一致，若不進行IP版本轉(zhuǎn)換就無法 繼續(xù)通信的情況下，才進行轉(zhuǎn)換或使用ALG/NAT-PT功能。也就是說將 ALG/NAT-PT變換盡可能的放在被叫側(cè)完成。具體來說，先查詢下一跳節(jié)點 的IP版本和本節(jié)點是否一致，如果是則直接發(fā)送信息，否則經(jīng)過IP版本轉(zhuǎn) 換以后再發(fā)送信息?？梢愿鶕?jù)本地的配置信息或DNS來進行IP版本的一致 性查詢。這種技術(shù)方案上的區(qū)別，帶來了較為明顯的有益效果，即首先，由于本 發(fā)明方案盡量按照主叫的IP版本進行傳送，只有在不進行IP版本轉(zhuǎn)換就無 法繼續(xù)通信時才進行轉(zhuǎn)換，因此可以避免許多不必要的IP版本轉(zhuǎn)換，降低了 會話中ALG/NAT-PT的使用次數(shù)，因此能減少會話傳輸?shù)臅r延，提高了服務(wù) 質(zhì)量。第二，由于ALG/NAT-PT的使用次數(shù)可以大大減少，因此降低了系統(tǒng)中 ALG/NAT-PT設(shè)備的負擔(dān)，提高了系統(tǒng)的性能。 第三，由于本發(fā)明方案不同于現(xiàn)有技術(shù)中優(yōu)先考慮采用IPv6傳輸?shù)姆?案，對IPv4和IPv6同等對待，因此兼容性能更好，可以應(yīng)用在網(wǎng)絡(luò)商用的 各個階段，能夠最大限度的保護運營商的投資。


圖1是3GPP建議的實現(xiàn)一個IPv4 UE和IPv6 UE之間進行即時消息業(yè) 務(wù)的方案；圖2是當(dāng)IMS網(wǎng)絡(luò)中的UE發(fā)起會話的時候，現(xiàn)有的互通方案中的處理 過程；圖3是根據(jù)本發(fā)明的一個較佳實施例的帶有媒體協(xié)商的會話建立過程的 版本不同的IP網(wǎng)絡(luò)互通的流程；圖4是根據(jù)本發(fā)明的 一 個較佳實施例的端到端的帶有媒體協(xié)商的會話的 建立流程中各個功能實體之間的消息傳遞流程；圖5是根據(jù)本發(fā)明的一個H佳實施例的實現(xiàn)一個IPv4 UE和IPv6 UE之 間進行即時消息業(yè)務(wù)的方法中消息的傳遞示意圖。
具體實施方式
為使本發(fā)明的目的、技術(shù)方案和優(yōu)點更加清楚，下面將結(jié)合附圖對本發(fā) 明作進一步地詳細描述。首先說明本發(fā)明的基本原理。為了減少不必要的IP版本之間的轉(zhuǎn)換，本 發(fā)明方案將ALG/NAT-PT變換盡可能的放在被叫側(cè)完成，除非主叫側(cè)處理會 話的功能實體不進行ALG/NAT-PT變換就無法繼續(xù)后續(xù)的通信，否則就不執(zhí) 行ALG/NAT-PT變換。這樣能夠盡可能的減少不必要的ALG/NAT-PT變換， 使版本不同的IP網(wǎng)絡(luò)互通的方案更加優(yōu)化，互通的效果更好。
為了更好的說明本發(fā)明方案，下面結(jié)合附圖對本發(fā)明做詳細說明。需要先行說明的是，本發(fā)明方案從IMS網(wǎng)絡(luò)運營商運營方^f更的角度考 慮，認為位于同一個IMS網(wǎng)絡(luò)中的各個IMS功能實體，即P-CSCF、 I-CSCF 和S-CSCF所支持的IP版本是相同的，否則，IMS運營商自己還要考慮網(wǎng)內(nèi) 不同功能實體之間可能存在的多種互通場景，無端增加了網(wǎng)絡(luò)規(guī)劃的復(fù)雜度。根據(jù)本發(fā)明的 一個較佳實施例的帶有媒體協(xié)商的會話建立過程的版本 不同的IP網(wǎng)絡(luò)互通的流程如圖3所示。首先進入步驟100,主叫發(fā)起呼叫。其中，主叫可以采用SIP消息發(fā)起 呼叫。接著進入步驟110，主叫的歸屬S-CSCF判斷主叫的IP地址是否是私有 IP地址，如果是則進入步驟120，否則進入步驟140。由于IPv4地址的緊張， 現(xiàn)有的IPv4網(wǎng)絡(luò)上很多站點都采用了私網(wǎng)IPv4地址，當(dāng)需要接入公網(wǎng)時， 在私網(wǎng)和公網(wǎng)的邊緣進行私網(wǎng)地址和公網(wǎng)地址的映射。在步驟120中，主叫的歸屬S-CSCF判斷被叫的歸屬網(wǎng)絡(luò)是否和主叫的 歸屬網(wǎng)絡(luò)相同，如果是則進入步驟170，否則進入步驟130。在該步驟中，如 果被叫的歸屬網(wǎng)絡(luò)和主叫的歸屬網(wǎng)絡(luò)相同，則說明主叫和被叫同時處于一個 相同的私網(wǎng)中，IP版本也相同。在步驟130中，主叫的歸屬S-CSCF使用NAT將主叫的私有IP地址映 射到公網(wǎng)IP地址，接著進入步驟140。其中，私有IP地址到公網(wǎng)IP地址的 映射方法為本領(lǐng)域技術(shù)人員所公知，在此不詳細說明。在步驟140中，主叫的歸屬S-CSCF判斷被叫的歸屬網(wǎng)絡(luò)是否支持主叫 的IP版本，如果是則進入步驟160,否則進入步驟150。主叫的歸屬S-CSCF 可以通過查詢或者配置的方法得到被叫的歸屬網(wǎng)絡(luò)的IP版本。例如，當(dāng)主叫 的歸屬S-CSCF得到的是被叫的歸屬網(wǎng)絡(luò)域名時，可以根據(jù)當(dāng)前自己使用的 IP版本發(fā)送查詢請求給DNS,需要說明的是，這里查詢得到的僅僅是被叫 UE所在網(wǎng)絡(luò)對外接口的I-CSCF的地址，但是基于上文的考慮，認為I-CSCF 的地址類型可以代表其所在IMS網(wǎng)絡(luò)的IP地址類型。根據(jù)DNS服務(wù)器返回 的地址類型，主叫的歸屬S-CSCF可以確定是否可以不經(jīng)過ALG/NAT-PT變 換直接和對端通信。在本發(fā)明的一個較佳實施例中，主叫的歸屬S-CSCF當(dāng) 前收到IPv4消息，則主叫的歸屬S-CSCF先根據(jù)被叫的歸屬網(wǎng)絡(luò)域名查詢是 否有對應(yīng)的IPv4地址，如果DNS服務(wù)器返回了 IPv4類型的地址，說明被叫 的歸屬網(wǎng)絡(luò)支持IPv4或者支持雙棧，否則，DNS服務(wù)器會只返回對應(yīng)的IPv6 地址。熟悉本領(lǐng)域的技術(shù)人員可以理解，除了查詢DNS服務(wù)器，還可以直接 將被叫地址或者歸屬網(wǎng)絡(luò)域名和其所在歸屬網(wǎng)絡(luò)支持的IP版本類型信息配 置在S-CSCF或者I-CSCF中，也可以確定是否可以直接和被叫所在歸屬網(wǎng)絡(luò) 對外接口的I-CSCF通信。在步驟150中，主叫的歸屬S-CSCF使用ALG/NAT-PT執(zhí)行IP版本信 息的轉(zhuǎn)換后發(fā)送，接著進入步驟180。在本發(fā)明的一個較佳實施例中，主叫 的歸屬S-CSCF將SIP消息轉(zhuǎn)發(fā)到主叫歸屬網(wǎng)絡(luò)的ALG功能實體執(zhí)行應(yīng)用層 的IP地址版本信息轉(zhuǎn)換，ALG控制NAT-PT執(zhí)行用戶面IP地址版本信息轉(zhuǎn) 換。其中，ALG和NAT-PT之間可以使用H.248協(xié)議或者MECAGO協(xié)議進 行通信。需要說明的是，主叫的歸屬S-CSCF在轉(zhuǎn)發(fā)消息給ALG功能實體的 時候同時攜帶下一跳的地址，用于后續(xù)消息路由。在步驟160中，主叫的歸屬S-CSCF直接將消息發(fā)送給被叫的歸屬 S-CSCF/I-CSCF,接著進入步驟180。在該步驟中，被叫的歸屬網(wǎng)絡(luò)支持主叫 的IP版本，不需要進行IP版本的轉(zhuǎn)換也可以直接通信，因此基于將轉(zhuǎn)換盡 量放在被叫側(cè)完成的原則，主叫的歸屬S-CSCF將消息直接發(fā)送。在步驟170中，主叫的歸屬S-CSCF不進行IP版本轉(zhuǎn)換直接進行處理后 結(jié)束整個流程。在該步驟中，主叫和被叫的歸屬網(wǎng)絡(luò)相同，不需要進行IP版 本轉(zhuǎn)換即可直接通信,相關(guān)的處理方法和現(xiàn)有技術(shù)完全相同，在此不詳細說 明。在步驟180中，被叫的歸屬S-CSCF判斷被叫是否支持主叫的IP版本， 如果是則進入步驟210，否則進入步驟190。其中，被叫的IP版本保存在本 地，可以直接查詢得知。在步驟190中，被叫的歸屬S-CSCF將消息發(fā)送到ALG功能實體執(zhí)行應(yīng) 用層IP版本轉(zhuǎn)換。其中，該步驟中的ALG功能實體為被叫的歸屬網(wǎng)絡(luò)中的 ALG功能實體，被叫的歸屬S-CSCF在轉(zhuǎn)發(fā)消息給ALG功能實體的時候同 時攜帶下一跳的地址，用于后續(xù)消息路由。接著進入步驟200, ALG控制NAT-PT執(zhí)行用戶面IP版本轉(zhuǎn)換。其中， ALG和NAT-PT之間可以使用H.248協(xié)議或者MeGaCo協(xié)議進行通信。接著進入步驟210，將消息轉(zhuǎn)發(fā)給被叫對應(yīng)的P-CSCF。熟悉本領(lǐng)域的技 術(shù)人員可以理解，被叫對應(yīng)的P-CSCF的IP版本和被叫的IP版本相同。接著進入步驟220，被叫P-CSCF將消息發(fā)送給被叫。其中，該步驟中 消息的IP版本已經(jīng)可以為被叫所支持。 -至此，完成一個端到端的帶有媒體協(xié)商的會話的建立流程。本發(fā)明領(lǐng)域的4支術(shù)人員可以理解，當(dāng)步驟130中執(zhí)行私有IP地址到公有 IP地址變換的NAT設(shè)備和步驟150中執(zhí)行ALG/ANT-PT功能的設(shè)備是不同 的設(shè)備時,那么按照上述流程實現(xiàn)，否則，步驟130中執(zhí)行的私有IP地址到 公有IP地址的變換可以和步驟150中執(zhí)行ALG/NAT-PT的變換一起實現(xiàn)。根據(jù)上述流程，本發(fā)明的 一個較佳實施例的端到端的帶有媒體協(xié)商的會 話的建立流程中各個功能實體之間的消息傳遞流程如圖4所示。圖4所示的 該較佳實施例的消息傳遞流程比較清楚，本領(lǐng)域的普通技術(shù)人員參照圖3的 說明很容易理解。對于圖4的消息傳遞流程的說明如下 首先，UE1發(fā)起一個IMS會話請求給UE2，該消息是使用IPv4傳送的；接著，P-CSCF1轉(zhuǎn)發(fā)該會話請求消息給UE1的歸屬網(wǎng)絡(luò) S畫CSCF1/I-CSCF1;接著，S-CSCF1/I-CSCF1根據(jù)DNS查詢或者本地配置確定UE2所在歸 屬網(wǎng)絡(luò)可以支持當(dāng)前S-CSCF1使用的IPv4版本，因此決定繼續(xù)轉(zhuǎn)發(fā)該會話 請求消息給UE2所在歸屬網(wǎng)絡(luò)的S-CSCF2/I-CSCF2;接著，S-CSCF2/I-CSCF2根據(jù)保存的UE2的IP地址和收到的請求消息 使用的IP地址類型進行比較，發(fā)現(xiàn)不一致，必須使用ALG/NAT-PT功能進 行轉(zhuǎn)換，則將該消息轉(zhuǎn)發(fā)到ALG，同時攜帶P-CSCF2的地址；接著，ALG執(zhí)行IP地址版本相關(guān)信息從IPv4到IPv6的轉(zhuǎn)換，因為涉及 到對用戶面的修改，因此，使用擴展的H.248消息或媒體網(wǎng)關(guān)控制協(xié)議(Media Gataway Control Protocal，簡稱"MEGACO")和NAT國PT設(shè)備交互；交互結(jié)束之后，ALG將新構(gòu)造的會話請求消息發(fā)送給UE2當(dāng)前所在網(wǎng) 絡(luò)的P-CSCF2，該消息使用IPv6傳送，而且媒體描述已經(jīng)被修改；接著，P-CSCF2轉(zhuǎn)發(fā)該會話請求消息給UE2;最后，后續(xù)的信令交互將在UE1、 S-CSCF2/I-CSCF2、 ALG和UE2之間 進行，即圖4中的會話信令路徑建立；后續(xù)的媒體交互將在UE1、 NAT-PT 和UE2之間進行，即圖4中的媒體路徑建立。需要說明的是，如果一種涉及業(yè)務(wù)的IP版本互通場景，不需要媒體協(xié)商， 比如即時消息就是只有SIP信令沒有媒體協(xié)商，此時，就沒有需要ALG執(zhí)行 IP地址信息映射的IP地址等信息。這種情況下，不同IP版本互通的原理和 上述的流程的原理相同，由于消息比較短，因此不需要媒體流，只是由被叫 的歸屬S-CSCF完成一個IP版本到另一個IP版本的映射，不需要^f吏用 ALG/NAT-PT功能。在消息互通的時候，下一跳的IP版本同樣可以通過查詢 本地設(shè)置或DNS得到。根據(jù)本發(fā)明的一個較佳實施例的實現(xiàn)一個IPv4 UE和IPv6 UE之間進行 即時消息業(yè)務(wù)的方法中消息的傳遞示意圖如圖5所示。其中UE A，在傳送即時消息給UEB的時候，不涉及到媒體成分的協(xié)商， 直接使用SIP信令攜帶相關(guān)的信息，UEB的歸屬網(wǎng)絡(luò)和UE A不同。在被叫 方一側(cè)，UE B的歸屬S-CSCF支持雙棧，負責(zé)將使用IPv4傳送的SIP消息 直接轉(zhuǎn)化為使用IPv6傳送的SIP消息，然后繼續(xù)傳送給接收方UEB。熟悉本領(lǐng)域的技術(shù)人員可以看出，本發(fā)明通過在S-CSCF處對主叫和被 叫支持的IP地址類型或者歸屬網(wǎng)絡(luò)支持的IP版本進行判斷，只有在雙方版 本不一致的情況下才使用ALG/NAT-PT功能，否則就放在端到端流程的最后 一個S-CSCF,即被叫S-CSCF處使用ALG/NAT-PT或者僅僅是執(zhí)行IP版本 的映射，從而可以最大程度的降低對ALG/NAT-PT功能的使用次數(shù)；此外， 該方法對IPv4和IPv6同等對待，在IMS應(yīng)用的初期，因為使用IPv4的消息 較多，因此，根據(jù)每次查詢DNS或者配置的結(jié)果，將盡量使用IPv4傳送， 等到后期使用IPv6成為主流的時候，使用該方法將大量使用IPv6傳送消息， 因此兼容性好，可以應(yīng)用在IMS商用的各個階段。雖然通過參照本發(fā)明的某些優(yōu)選實施例，已經(jīng)對本發(fā)明進行了圖示和描 述，但本領(lǐng)域的普通技術(shù)人員應(yīng)該明白，可以在形式上和細節(jié)上對其作各種 各樣的改變，而不偏離所附權(quán)利要求書所限定的本發(fā)明的精神和范圍。
權(quán)利要求
1.一種版本不同的網(wǎng)間互聯(lián)協(xié)議網(wǎng)絡(luò)互通的方法，其特征在于，包含以下步驟C主叫用戶設(shè)備的歸屬呼叫狀態(tài)控制功能設(shè)備判斷被叫用戶設(shè)備的歸屬網(wǎng)絡(luò)是否支持所述主叫用戶設(shè)備的網(wǎng)間互聯(lián)協(xié)議版本，如果是則將來自所述主叫用戶設(shè)備的消息直接轉(zhuǎn)發(fā)給所述被叫用戶設(shè)備的歸屬呼叫狀態(tài)控制功能設(shè)備，否則將該消息進行網(wǎng)間互聯(lián)協(xié)議版本轉(zhuǎn)換后轉(zhuǎn)發(fā)給所述被叫用戶設(shè)備的歸屬呼叫狀態(tài)控制功能設(shè)備；D所述被叫用戶設(shè)備的歸屬呼叫狀態(tài)控制功能設(shè)備響應(yīng)所述消息，判斷所述被叫用戶設(shè)備是否支持所述消息的網(wǎng)間互聯(lián)協(xié)議版本，如果是則將所述消息直接轉(zhuǎn)發(fā)給所述被叫用戶設(shè)備，否則將所述消息進行網(wǎng)間互聯(lián)協(xié)議版本的轉(zhuǎn)換后發(fā)送給所述被叫用戶設(shè)備。
2. 根據(jù)權(quán)利要求1所述的版本不同的網(wǎng)間互聯(lián)協(xié)議網(wǎng)絡(luò)互通的方法， 其特征在于，所述方法在步驟C之前還包含以下步驟A所述主叫用戶設(shè)備的歸屬呼叫狀態(tài)控制功能設(shè)備判斷發(fā)起會話并發(fā) 送消息的主叫用戶設(shè)備的網(wǎng)間互聯(lián)協(xié)議地址是否是私有地址，如果是則進入 步驟B，否則進入步驟C;B判斷被叫用戶設(shè)備是否和所述主叫用戶設(shè)備處于同一歸屬網(wǎng)絡(luò)中， 如果是則直接進行通信，否則應(yīng)用網(wǎng)絡(luò)地址轉(zhuǎn)換和協(xié)議轉(zhuǎn)換設(shè)備將所述私有 地址轉(zhuǎn)換為公有地址后進入步驟C。
3. 根據(jù)權(quán)利要求1所述的版本不同的網(wǎng)間互聯(lián)協(xié)議網(wǎng)絡(luò)互通的方法， 其特征在于，所述步驟C中，所述主叫的歸屬呼叫狀態(tài)控制功能設(shè)備通過查 詢本地配置或域名服務(wù)系統(tǒng)得到所述被叫的歸屬網(wǎng)絡(luò)支持的網(wǎng)間互聯(lián)協(xié)議 版本類型。
4. 根據(jù)權(quán)利要求1所述的版本不同的網(wǎng)間互聯(lián)協(xié)議網(wǎng)絡(luò)互通的方法， 其特征在于，所述步驟C和D中，所述呼叫狀態(tài)控制功能設(shè)備對所述消息 進行網(wǎng)間互聯(lián)協(xié)議版本轉(zhuǎn)換的步驟還進一步包含以下子步驟所述呼叫狀態(tài)控制功能設(shè)備判斷所述會話中是否有媒體描述，如果所述 會話有媒體描迷，則使用應(yīng)用層網(wǎng)關(guān)設(shè)備以及網(wǎng)絡(luò)地址轉(zhuǎn)換和協(xié)議轉(zhuǎn)換設(shè)備實現(xiàn)網(wǎng)間互聯(lián)協(xié)議版本信息的轉(zhuǎn)換，如果所述會話沒有媒體描述，則直接在 所述呼叫狀態(tài)控制功能設(shè)備中實現(xiàn)網(wǎng)間互聯(lián)協(xié)議版本信息的轉(zhuǎn)換。
5. 根據(jù)權(quán)利要求4所述的版本不同的網(wǎng)間互聯(lián)協(xié)議網(wǎng)絡(luò)互通的方法， 其特征在于，所述呼叫狀態(tài)控制功能設(shè)備在轉(zhuǎn)發(fā)消息給所述應(yīng)用層網(wǎng)關(guān)設(shè)備 時攜帶用于后續(xù)消息路由的下 一跳地址。
6. 根據(jù)權(quán)利要求1所述的版本不同的網(wǎng)間互聯(lián)協(xié)議網(wǎng)絡(luò)互通的方法， 其特征在于，所迷應(yīng)用層網(wǎng)關(guān)設(shè)備以及所迷網(wǎng)絡(luò)地址轉(zhuǎn)換和協(xié)議轉(zhuǎn)換設(shè)備之 間可采用擴展的H.248消息或媒體網(wǎng)關(guān)控制協(xié)議消息通信。
7. 根據(jù)權(quán)利要求1所述的版本不同的網(wǎng)間互聯(lián)協(xié)議網(wǎng)絡(luò)互通的方法， 其特征在于，所述消息可以是會話初始化協(xié)議消息。
全文摘要
本發(fā)明涉及不同版本IP網(wǎng)絡(luò)的互通，公開了一種版本不同的網(wǎng)間互聯(lián)協(xié)議網(wǎng)絡(luò)互通的方法，使得應(yīng)用IMS時，減少了不必要轉(zhuǎn)換和ALG/NAT-PT處理，減輕了ALG/NAT-PT設(shè)備的壓力，使版本不同的IP網(wǎng)絡(luò)的互通效果更好。這種版本不同的網(wǎng)間互聯(lián)協(xié)議網(wǎng)絡(luò)互通的方法僅在本節(jié)點和下一跳節(jié)點的IP版本不一致，若不進行IP版本轉(zhuǎn)換就無法繼續(xù)通信的情況下，才進行轉(zhuǎn)換或使用ALG/NAT-PT功能。具體來說，先查詢下一跳節(jié)點的IP版本和本節(jié)點是否一致，如果是則直接發(fā)送信息，否則經(jīng)過IP版本轉(zhuǎn)換以后再發(fā)送信息?？梢愿鶕?jù)本地的配置信息或DNS來進行IP版本的一致性查詢。
文檔編號H04L29/06GK101159744SQ20071016770
公開日2008年4月9日 申請日期2004年10月5日 優(yōu)先權(quán)日2004年10月5日
發(fā)明者武亞娟 申請人:華為技術(shù)有限公司