專利名稱：版本不同的網(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)能夠滿足人們隨時隨地進(jìn)行通信的要求，從它出現(xiàn)后就得到了迅速的發(fā)展。隨著第三代移動通信(The Third Generation，簡稱“3G”)技術(shù)的提出和進(jìn)一步發(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”)等標(biāo)準(zhǔn)組織都制定了將移動通信網(wǎng)絡(luò)向全分組、全I(xiàn)P的方向演進(jìn)的標(biāo)準(zhǔn)，提出了基于IP的多媒體子系統(tǒng)架構(gòu)，目的是在移動網(wǎng)絡(luò)中使用一種標(biāo)準(zhǔn)化的開放的結(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(ProxyCSCF，簡稱“P-CSCF”)和查詢CSCF(Interrogating CSCF，簡稱“I-CSCF”)三個邏輯實體。其中，S-CSCF是IMS的業(yè)務(wù)交換中心，執(zhí)行會話控制，維持會話狀態(tài)，負(fù)責(zé)管理用戶信息，產(chǎn)生計費信息等；P-CSCF是終端用戶接入IMS的接入點，完成用戶注冊，負(fù)責(zé)QoS控制和安全管理等；I-CSCF負(fù)責(zé)IMS域之間的互通，管理S-CSCF的分配，對外隱藏網(wǎng)絡(luò)拓?fù)浜团渲?，產(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”)等，實現(xiàn)了和用戶使用終端類型的無關(guān)性以及和接入網(wǎng)絡(luò)類型的無關(guān)性。這里不限制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版(InternetProtocol version 4，簡稱“IPv4”)存在地址空間即將耗盡、路由表爆炸等問題，而IMS的廣泛應(yīng)用要求大量可用的IP地址，在實現(xiàn)多種媒體類型融合的下一代網(wǎng)絡(luò)中對網(wǎng)絡(luò)的安全、質(zhì)量和移動性都提出了更高的要求，因此，3GPP明確規(guī)定實現(xiàn)IP多媒體業(yè)務(wù)時，用戶終端必須支持使用IPv6地址進(jìn)行通訊。對移動網(wǎng)絡(luò)功能實體而言，IMS的所有功能實體，包括用戶設(shè)備(UserEquipment，簡稱“UE”)、CSCF、MGCF、MRF和應(yīng)用服務(wù)器(ApplicationServer，簡稱“AS”)都必須支持IPv6，通用分組無線業(yè)務(wù)網(wǎng)關(guān)支持節(jié)點(GPRSGateway Support Node，簡稱“GGSN”)與IMS有接口，也必須支持網(wǎng)間互聯(lián)協(xié)議第6版(Internet Protocol version 6，簡稱“IPv6”)，為支持動態(tài)地址解析，GGSN還需支持IPv6的動態(tài)主機(jī)配置協(xié)議(Dynamic HostConfiguration Protocol，簡稱“DHCP”)。
但是隨著市場的變化和技術(shù)的發(fā)展，IPv6規(guī)模商用目前沒有達(dá)到原來預(yù)計的速度，同時缺乏所有基于IPv6產(chǎn)品的支持將使基于IPv6的IMS應(yīng)用延遲，移動運營商為了通過給3G用戶提供更豐富的多媒體業(yè)務(wù)，促進(jìn)寬帶碼分多址(Wideband Code Division Multiple Access，簡稱“WCDMA”)IMS的盡快商用，來吸引更多的用戶，促進(jìn)3G網(wǎng)絡(luò)的發(fā)展，向3GPP提出建議，考慮在IMS的實現(xiàn)中支持IPv4來滿足早期商用的需求。同時，3G另一種主流制式碼分多址2000(Code Division Multiple Access 2000，簡稱“CDMA2000”)的標(biāo)準(zhǔn)化組織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對各種可能存在的互通問題進(jìn)行了分析，包括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 ProtocolTranslation，簡稱“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ì)量影響越小，進(jìn)而減輕了對實現(xiàn)NAT-PT和ALG功能的設(shè)備的壓力，減少了網(wǎng)絡(luò)瓶頸的個數(shù)，因此在IPv4和IPv6互通時就需要考慮在什么時候引入NAT-PT和ALG功能，可以使得實現(xiàn)端到端的互通過程中經(jīng)過的轉(zhuǎn)換次數(shù)最少。
現(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ò)進(jìn)行互通的時候必須將私網(wǎng)IPv4地址轉(zhuǎn)化為公網(wǎng)IP地址，因此，現(xiàn)有技術(shù)方案建議盡量使用IPv6地址，這樣可以減少使用ALG/NAT-PT功能的情況，從而提高會話的服務(wù)質(zhì)量。
在涉及業(yè)務(wù)的IP版本互通中，3GPP建議的實現(xiàn)一個IPv4UE和IPv6 UE之間進(jìn)行即時消息業(yè)務(wù)的方案如圖1所示。
其中UE A支持IPv4，在傳送即時消息給UE B的時候，不涉及到媒體成分的協(xié)商，直接使用SIP信令攜帶相關(guān)的信息，UE B支持Pv6，其歸屬網(wǎng)絡(luò)和UE A不同。在發(fā)起方一側(cè)，UE A的歸屬S-CSCF支持雙棧，負(fù)責(zé)將使用IPv4傳送的SIP消息直接轉(zhuǎn)化為使用IPv6傳送的SIP消息，然后繼續(xù)傳送給接收方UE B。
當(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-ProtocolTranslator，簡稱“NAT-PT”)功能實體。根據(jù)圖2的描述，會話發(fā)起方UEA支持IPv6，其所在的歸屬S-CSCF通過域名服務(wù)系統(tǒng)(Domain Name Svstem，簡稱“DNS”)查詢等機(jī)制判斷接收方無法通過IPv6進(jìn)行通信，則通過和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ù)方案認(rèn)為發(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)信息的映射之后，很可能在到達(dá)目的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è)備，否則將該消息進(jìn)行網(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è)備，否則將所述消息進(jìn)行網(wǎng)間互聯(lián)協(xié)議版本的轉(zhuǎn)換后發(fā)送給所述被叫用戶設(shè)備。
其中，所述方法在步驟C之前還包含以下步驟A所述主叫用戶設(shè)備的歸屬呼叫狀態(tài)控制功能設(shè)備判斷發(fā)起會話并發(fā)送消息的主叫用戶設(shè)備的網(wǎng)間互聯(lián)協(xié)議地址是否是私有地址，如果是則進(jìn)入步驟B，否則進(jìn)入步驟C；B判斷被叫用戶設(shè)備是否和所述主叫用戶設(shè)備處于同一歸屬網(wǎng)絡(luò)中，如果是則直接進(jìn)行通信，否則應(yīng)用網(wǎng)絡(luò)地址轉(zhuǎn)換設(shè)備將所述私有地址轉(zhuǎn)換為公有地址后進(jìn)入步驟C。
所述步驟C中，所述主叫的歸屬呼叫狀態(tài)控制功能設(shè)備通過查詢本地配置或域名服務(wù)系統(tǒng)得到所述被叫的歸屬網(wǎng)絡(luò)支持的網(wǎng)間互聯(lián)協(xié)議版本類型。
所述步驟C和D中，所述呼叫狀態(tài)控制功能設(shè)備對所述消息進(jìn)行網(wǎng)間互聯(lián)協(xié)議版本轉(zhuǎn)換的步驟還進(jì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è)備之間可采用擴(kuò)展的H.248消息或媒體網(wǎng)關(guān)控制協(xié)議通信。
所述消息可以是會話初始化協(xié)議消息。
通過比較可以發(fā)現(xiàn)，本發(fā)明的技術(shù)方案與現(xiàn)有技術(shù)的區(qū)別在于，本發(fā)明只有在本節(jié)點和下一跳節(jié)點的IP版本不一致，若不進(jìn)行IP版本轉(zhuǎn)換就無法繼續(xù)通信的情況下，才進(jìn)行轉(zhuǎn)換或使用ALG/NAT-PT功能。也就是說將ALG/NAT-PT變換盡可能的放在被叫側(cè)完成。具體來說，先查詢下一跳節(jié)點的IP版本和本節(jié)點是否一致，如果是則直接發(fā)送信息，否則經(jīng)過IP版本轉(zhuǎn)換以后再發(fā)送信息?？梢愿鶕?jù)本地的配置信息或DNS來進(jìn)行IP版本的一致性查詢。
這種技術(shù)方案上的區(qū)別，帶來了較為明顯的有益效果，即首先，由于本發(fā)明方案盡量按照主叫的IP版本進(jìn)行傳送，只有在不進(jìn)行IP版本轉(zhuǎn)換就無法繼續(xù)通信時才進(jìn)行轉(zhuǎn)換，因此可以避免許多不必要的IP版本轉(zhuǎn)換，降低了會話中ALG/NAT-PT的使用次數(shù)，因此能減少會話傳輸?shù)臅r延，提高了服務(wù)質(zhì)量。
第二，由于ALG/NAT-PT的使用次數(shù)可以大大減少，因此降低了系統(tǒng)中ALG/NAT-PT設(shè)備的負(fù)擔(dān)，提高了系統(tǒng)的性能。
第三，由于本發(fā)明方案不同于現(xiàn)有技術(shù)中優(yōu)先考慮采用IPv6傳輸?shù)姆桨?，對IPv4和IPv6同等對待，因此兼容性能更好，可以應(yīng)用在網(wǎng)絡(luò)商用的各個階段，能夠最大限度的保護(hù)運營商的投資。


圖1是3GPP建議的實現(xiàn)一個IPv4 UE和IPv6 UE之間進(jìn)行即時消息業(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ā)明的一個較佳實施例的實現(xiàn)一個IPv4 UE和IPv6 UE之間進(jìn)行即時消息業(yè)務(wù)的方法中消息的傳遞示意圖。
具體實施例方式
為使本發(fā)明的目的、技術(shù)方案和優(yōu)點更加清楚，下面將結(jié)合附圖對本發(fā)明作進(jìn)一步地詳細(xì)描述。
首先說明本發(fā)明的基本原理。為了減少不必要的IP版本之間的轉(zhuǎn)換，本發(fā)明方案將ALG/NAT-PT變換盡可能的放在被叫側(cè)完成，除非主叫側(cè)處理會話的功能實體不進(jìn)行ALG/NAT-PT變換就無法繼續(xù)后續(xù)的通信，否則就不執(zhí)行ALG/NAT-PT變換。這樣能夠盡可能的減少不必要的ALG/NAT-PT變換，使版本不同的IP網(wǎng)絡(luò)互通的方案更加優(yōu)化，互通的效果更好。
為了更好的說明本發(fā)明方案，下面結(jié)合附圖對本發(fā)明做詳細(xì)說明。
需要先行說明的是，本發(fā)明方案從IMS網(wǎng)絡(luò)運營商運營方便的角度考慮，認(rèn)為位于同一個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所示。
首先進(jìn)入步驟100，主叫發(fā)起呼叫。其中，主叫可以采用SIP消息發(fā)起呼叫。
接著進(jìn)入步驟110，主叫的歸屬S-CSCF判斷主叫的IP地址是否是私有IP地址，如果是則進(jìn)入步驟120，否則進(jìn)入步驟140。由于IPv4地址的緊張，現(xiàn)有的IPv4網(wǎng)絡(luò)上很多站點都采用了私網(wǎng)IPv4地址，當(dāng)需要接入公網(wǎng)時，在私網(wǎng)和公網(wǎng)的邊緣進(jìn)行私網(wǎng)地址和公網(wǎng)地址的映射。
在步驟120中，主叫的歸屬S-CSCF判斷被叫的歸屬網(wǎng)絡(luò)是否和主叫的歸屬網(wǎng)絡(luò)相同，如果是則進(jìn)入步驟170，否則進(jìn)入步驟130。在該步驟中，如果被叫的歸屬網(wǎng)絡(luò)和主叫的歸屬網(wǎng)絡(luò)相同，則說明主叫和被叫同時處于一個相同的私網(wǎng)中，IP版本也相同。
在步驟130中，主叫的歸屬S-CSCF使用NAT將主叫的私有IP地址映射到公網(wǎng)IP地址，接著進(jìn)入步驟140。其中，私有IP地址到公網(wǎng)IP地址的映射方法為本領(lǐng)域技術(shù)人員所公知，在此不詳細(xì)說明。
在步驟140中，主叫的歸屬S-CSCF判斷被叫的歸屬網(wǎng)絡(luò)是否支持主叫的IP版本，如果是則進(jìn)入步驟160，否則進(jìn)入步驟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的地址，但是基于上文的考慮，認(rèn)為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ā)送，接著進(jìn)入步驟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é)議或者M(jìn)ECAGO協(xié)議進(jìn)行通信。需要說明的是，主叫的歸屬S-CSCF在轉(zhuǎn)發(fā)消息給ALG功能實體的時候同時攜帶下一跳的地址，用于后續(xù)消息路由。
在步驟160中，主叫的歸屬S-CSCF直接將消息發(fā)送給被叫的歸屬S-CSCF/I-CSCF，接著進(jìn)入步驟180。在該步驟中，被叫的歸屬網(wǎng)絡(luò)支持主叫的IP版本，不需要進(jìn)行IP版本的轉(zhuǎn)換也可以直接通信，因此基于將轉(zhuǎn)換盡量放在被叫側(cè)完成的原則，主叫的歸屬S-CSCF將消息直接發(fā)送。
在步驟170中，主叫的歸屬S-CSCF不進(jìn)行IP版本轉(zhuǎn)換直接進(jìn)行處理后結(jié)束整個流程。在該步驟中，主叫和被叫的歸屬網(wǎng)絡(luò)相同，不需要進(jìn)行IP版本轉(zhuǎn)換即可直接通信，相關(guān)的處理方法和現(xiàn)有技術(shù)完全相同，在此不詳細(xì)說明。
在步驟180中，被叫的歸屬S-CSCF判斷被叫是否支持主叫的IP版本，如果是則進(jìn)入步驟210，否則進(jìn)入步驟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ù)消息路由。
接著進(jìn)入步驟200，ALG控制NAT-PT執(zhí)行用戶面IP版本轉(zhuǎn)換。其中，ALG和NAT-PT之間可以使用H.248協(xié)議或者M(jìn)eGaCo協(xié)議進(jìn)行通信。
接著進(jìn)入步驟210，將消息轉(zhuǎn)發(fā)給被叫對應(yīng)的P-CSCF。熟悉本領(lǐng)域的技術(shù)人員可以理解，被叫對應(yīng)的P-CSCF的IP版本和被叫的IP版本相同。
接著進(jìn)入步驟220，被叫P-CSCF將消息發(fā)送給被叫。其中，該步驟中消息的IP版本已經(jīng)可以為被叫所支持。
至此，完成一個端到端的帶有媒體協(xié)商的會話的建立流程。
本發(fā)明領(lǐng)域的技術(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地址類型進(jìn)行比較，發(fā)現(xiàn)不一致，必須使用ALG/NAT-PT功能進(jìn)行轉(zhuǎn)換，則將該消息轉(zhuǎn)發(fā)到ALG，同時攜帶P-CSCF2的地址；接著，ALG執(zhí)行IP地址版本相關(guān)信息從IPv4到IPv6的轉(zhuǎn)換，因為涉及到對用戶面的修改，因此，使用擴(kuò)展的H.248消息或媒體網(wǎng)關(guān)控制協(xié)議(MediaGataway 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之間進(jìn)行，即圖4中的會話信令路徑建立；后續(xù)的媒體交互將在UE1、NAT-PT和UE2之間進(jìn)行，即圖4中的媒體路徑建立。
需要說明的是，如果一種涉及業(yè)務(wù)的IP版本互通場景，不需要媒體協(xié)商，比如即時消息就是只有SIP信令沒有媒體協(xié)商，此時，就沒有需要ALG執(zhí)行IP地址信息映射的IP地址等信息。這種情況下，不同IP版本互通的原理和上述的流程的原理相同，由于消息比較短，因此不需要媒體流，只是由被叫的歸屬S-CSCF完成一個IP版本到另一個IP版本的映射，不需要使用ALG/NAT-PT功能。在消息互通的時候，下一跳的IP版本同樣可以通過查詢本地設(shè)置或DNS得到。
根據(jù)本發(fā)明的一個較佳實施例的實現(xiàn)一個IPv4 UE和IPv6 UE之間進(jìn)行即時消息業(yè)務(wù)的方法中消息的傳遞示意圖如圖5所示。
其中UE A，在傳送即時消息給UE B的時候，不涉及到媒體成分的協(xié)商，直接使用SIP信令攜帶相關(guān)的信息，UE B的歸屬網(wǎng)絡(luò)和UE A不同。在被叫方一側(cè)，UE B的歸屬S-CSCF支持雙棧，負(fù)責(zé)將使用IPv4傳送的SIP消息直接轉(zhuǎn)化為使用IPv6傳送的SIP消息，然后繼續(xù)傳送給接收方UE B。
熟悉本領(lǐng)域的技術(shù)人員可以看出，本發(fā)明通過在S-CSCF處對主叫和被叫支持的IP地址類型或者歸屬網(wǎng)絡(luò)支持的IP版本進(jìn)行判斷，只有在雙方版本不一致的情況下才使用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ā)明進(jìn)行了圖示和描述，但本領(lǐng)域的普通技術(shù)人員應(yīng)該明白，可以在形式上和細(xì)節(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è)備，否則將該消息進(jìn)行網(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è)備，否則將所述消息進(jìn)行網(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é)議地址是否是私有地址，如果是則進(jìn)入步驟B，否則進(jìn)入步驟C；B判斷被叫用戶設(shè)備是否和所述主叫用戶設(shè)備處于同一歸屬網(wǎng)絡(luò)中，如果是則直接進(jìn)行通信，否則應(yīng)用網(wǎng)絡(luò)地址轉(zhuǎn)換和協(xié)議轉(zhuǎn)換設(shè)備將所述私有地址轉(zhuǎn)換為公有地址后進(jì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è)備對所述消息進(jìn)行網(wǎng)間互聯(lián)協(xié)議版本轉(zhuǎn)換的步驟還進(jì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è)備之間可采用擴(kuò)展的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版本不一致，若不進(jìn)行IP版本轉(zhuǎn)換就無法繼續(xù)通信的情況下，才進(jìn)行轉(zhuǎn)換或使用ALG/NAT－PT功能。具體來說，先查詢下一跳節(jié)點的IP版本和本節(jié)點是否一致，如果是則直接發(fā)送信息，否則經(jīng)過IP版本轉(zhuǎn)換以后再發(fā)送信息?？梢愿鶕?jù)本地的配置信息或DNS來進(jìn)行IP版本的一致性查詢。
文檔編號H04L12/66GK1758649SQ20041007932
公開日2006年4月12日 申請日期2004年10月5日 優(yōu)先權(quán)日2004年10月5日
發(fā)明者李輝, 武亞娟 申請人:華為技術(shù)有限公司