專利名稱：基于ip的匯接局多業(yè)務傳輸方法
技術領域：
本發(fā)明涉及移動通信系統(tǒng)中匯接局基于IP的通信業(yè)務傳輸方法，特別涉及移動通信系統(tǒng)中匯接局基于IP的語音、傳真、數(shù)據(jù)等通信業(yè)務傳輸方法。
背景技術：
隨著通信技術的突飛猛進，人們對于個人通信的期望和要求也越來越高，因此移動運營商需要特別關注用戶界面、業(yè)務質(zhì)量等直接影響用戶使用移動業(yè)務的體驗的方面。第三代(3rd Generation，簡稱“3G”)移動通信系統(tǒng)的高帶寬、多業(yè)務、高質(zhì)量等特點極大的吸引著移動消費市場，但3G技術中尚且存在的一些問題如果沒有解決將會在一定程度上限制市場擴大，影響移動運營事務的發(fā)展。
在將來的3G網(wǎng)絡架構(gòu)中，移動網(wǎng)不再局限于電路交換的方式，逐漸向分組網(wǎng)際協(xié)議(Internet Protocol，簡稱“IP”)網(wǎng)絡演變。另外，隨著傳統(tǒng)通信網(wǎng)絡、互聯(lián)網(wǎng)以及移動通信網(wǎng)絡的發(fā)展，各個網(wǎng)絡相互融合是必然趨勢，下一代網(wǎng)絡(Next Generation Nerwork，簡稱“NGN”)就是以網(wǎng)際協(xié)議(InternetProtocol，簡稱“IP”)分組交換網(wǎng)絡為核心網(wǎng)，控制與承載分離，各種接入技術并存，融合現(xiàn)有各種網(wǎng)絡的新一代網(wǎng)絡，能夠滿足未來寬帶多媒體通信的需求。
NGN是在傳統(tǒng)的以電路交換為主的公用電話交換網(wǎng)(Public SwitchedTelephone Network，簡稱“PSTN”)中逐漸邁出了向以分組交換為主的步伐，它承載了原有PSTN網(wǎng)絡的所有業(yè)務，同時把大量的數(shù)據(jù)傳輸卸載到IP網(wǎng)絡中以減輕PSTN網(wǎng)絡的重荷，又以IP技術的新特性增加和增強了許多新老業(yè)務。NGN是基于時分復用的PSTN語音網(wǎng)絡、綜合業(yè)務數(shù)字網(wǎng)絡(IntegratedServices Digital Network，簡稱“ISDN”)、基于IP的分組網(wǎng)絡、以及移動通信網(wǎng)等多種網(wǎng)絡融合的產(chǎn)物，它使得在新一代網(wǎng)絡上語音、視頻、數(shù)據(jù)等綜合業(yè)務成為了可能。
國際電信聯(lián)盟電信標準部(International Telecommunication UnionTelecommunication Standardization Sector，簡稱“ITU-T”)所定義的NGN是一種基于分組的網(wǎng)絡，能夠提供電信業(yè)務、能夠利用多種寬帶和服務質(zhì)量(Quality of Service，簡稱“QoS”)使能的傳輸技術，其業(yè)務相關功能獨立于底層的傳輸相關技術，為用戶提供自由接入到不同的業(yè)務供應商，支持通用移動性使業(yè)務的一致性和普遍性供應給用戶成為可能。
在移動域，傳統(tǒng)的匯接移動交換中心(Transit Mobile Switching Center，簡稱“TMSC”)主要是以時分復用(Time Division Multiplex，簡稱“TDM”)承載為主，TDM固定帶寬為64Kbit/s，可以用于傳遞話音、數(shù)據(jù)及傳真業(yè)務。隨著NGN發(fā)展演變，傳統(tǒng)的TDM承載方向逐漸演進到IP承載。其中MSC也因承載與控制分離機制而被分為媒體網(wǎng)關(Media Gateway，簡稱“MGW”)和媒體網(wǎng)關控制器(Media Gateway Controller，簡稱“MGC”)。
基于IP承載的業(yè)務傳輸可以使用多種編碼方式，如ITU-T的G.729、G.711協(xié)議等。其中，G.729數(shù)據(jù)速率為8Kbit/s，可以傳送語音業(yè)務(Voiceon IP，簡稱“VoIP”)，但不能傳遞數(shù)據(jù)及傳真業(yè)務。G.711數(shù)據(jù)速率為64Kbit/s，理論上可以傳遞數(shù)據(jù)及傳真業(yè)務，但是由于IP傳輸?shù)牟豢煽啃?，如果發(fā)生丟包，則不能正常實現(xiàn)數(shù)據(jù)傳遞及傳真數(shù)據(jù)。
另外用于傳輸話音、傳真、數(shù)據(jù)業(yè)務的G.711冗余(G.711 Redundant，簡稱“G.711Red”)編解碼方案不僅在IP網(wǎng)絡適用，而且因引入了冗余機制而具有較高的可靠性。還有專門用于傳真業(yè)務的互聯(lián)網(wǎng)實時傳真協(xié)議T.38，它比G.711Red還具有更高的效率。因此，一般在傳輸傳真業(yè)務的時候，都會采用T.38編解碼。
基于IP傳輸?shù)臉I(yè)務種類越來越多，必須準確的判斷業(yè)務類型并選擇合適的編解碼方案來傳輸。如果無法準確判斷業(yè)務類型，則選擇的編解碼方案不能很好滿足業(yè)務傳輸?shù)男枨?，甚至無法正常傳輸。因此如何根據(jù)呼叫信令來判斷業(yè)務類型，并及時選擇合適編解碼方案是一個技術難題。
另外，由于匯接局MGC之間采用承載無關的呼叫控制協(xié)議(Bearerindependent call control protocol，簡稱“BICC”)進行帶外協(xié)商可選的編解碼器(Coder & Decoder，簡稱“Codec”)。而BICC信令不具備選擇IP承載的地址的功能，MGW的承載話路地址是通過基于IP的承載控制協(xié)議(IPBearer Control Protocol，簡稱“IPBCP”)進行協(xié)商的。匯接局組網(wǎng)的原理如圖1所示。在MGC和MGW之間存在Mc接口，供MGC下發(fā)命令或MGW上報事件。兩個MGW之間的數(shù)據(jù)承載面是基于IP實現(xiàn)的。在信令層MGC之間通過BICC協(xié)商，協(xié)商不涉及具體的承載地址信息等，因此在實現(xiàn)承載面時，MGW通過MGC進行IPBCP協(xié)商，確定通信的IP地址和用戶數(shù)據(jù)協(xié)議(User Data Protocol，簡稱“UDP”)端口號等信息。
因此，這就涉及到另外一個問題，在多業(yè)務傳輸時，在解決了業(yè)務編解碼方案的切換之后，如何解決基于IPBCP協(xié)商的承載面信息更新。比如在語音和傳真階段，因為無法在呼叫建立階段進行很好的區(qū)分，所以在IPBCP協(xié)商時，都使用目前的協(xié)商方式，協(xié)商出虛擬IuFP Codec或者使用實際語音使用的Codec以及UDP端口號，而實際語音編解碼是MGC通過BICC協(xié)商的G.729。在切換到傳真階段時，還使用該虛擬Codec，但是語音編解碼卻在經(jīng)過BICC協(xié)商后被MGC修改為G.711或者G.711Red，承載地址可以發(fā)生變化也可以不發(fā)生變化。
綜上所述，如何簡單高效地實現(xiàn)匯接局基于IP多業(yè)務傳輸中的編解碼方案的切換以及IP承載面信息的更新是當前急需解決的技術難題。
由于在呼叫建立階段往往無法區(qū)分語音和非語言的其他傳真或數(shù)據(jù)業(yè)務，因此一種解決方法是，在呼叫建立前就采用能夠同時支持語音、數(shù)據(jù)、傳真的承載方式或編碼。如在IP承載時使用G.711/G.711Red編碼，則能夠同時支持各種業(yè)務，保證業(yè)務的暢通。但是該方法的問題在于，若IP承載不分業(yè)務類型直接采用G.711/G.711Red編碼將嚴重浪費IP帶寬，因為TMSC的主要業(yè)務還是語音，普通的話音采用G.729編碼可以完全滿足要求。而G.711/G.711Red所需要的帶寬更大，如果一直采用該編碼方式而不顧及帶寬的浪費，顯然不能解決本質(zhì)問題。
另一種解決方法是，在呼叫建立前通過信令判斷出傳真、數(shù)據(jù)業(yè)務，然后采用G.711/G.711Red編碼傳送傳真、數(shù)據(jù)業(yè)務，實現(xiàn)各種業(yè)務的傳送。該方法的弊端在于，呼叫建立前通過信令判斷傳真、數(shù)據(jù)業(yè)務并不準確，需要特定的環(huán)境才能判斷，現(xiàn)有的網(wǎng)絡條件并不具備。如，固網(wǎng)傳真機接入時發(fā)起的呼叫在信令上與普通的公共交換電信網(wǎng)(Public SwitchTelecommunication Network，簡稱“PSTN”)的呼叫信令一樣，這樣的情況下，通過呼叫前的信令就無法檢測，因此從信令上判斷并不準確。還有種解決方法是在呼叫建立時先建立為語音通道，通過檢測傳真、調(diào)制解調(diào)器(Modulation & Demodulation，簡稱“Modem”)音修改通道為G.711透傳或者T.38來傳送傳真或調(diào)制解調(diào)數(shù)據(jù)業(yè)務。但是通過IPBCP協(xié)商的承載地址(IP地址和UDP端口號)在整個通話過程中不再需要修改。該方案中，整個過程承載地址不改變，在語音和傳真階段使用相同的IP地址和UDP端口號，如果處理不好會引起雜音以及承載處理比較麻煩，需要進行報文識別，丟棄非法報文等保護操作。因此對于通信過程中不同性質(zhì)業(yè)務的切換，最好對IP承載分配不同的端口號及地址。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明的主要目的在于提供一種基于IP的匯接局多業(yè)務傳輸方法，使得TMSC的IP承載組網(wǎng)滿足并實現(xiàn)語音、傳真、數(shù)據(jù)等多種業(yè)務的傳輸。
為實現(xiàn)上述目的，本發(fā)明提供了一種基于IP的匯接局多業(yè)務傳輸方法，包含以下步驟A在呼叫建立前，通信雙方協(xié)商并配置用于傳輸業(yè)務的編解碼方案；B在呼叫過程中，媒體網(wǎng)關檢測業(yè)務相關信號或事件并分別上報給媒體網(wǎng)關控制器；C在呼叫過程中，所述媒體網(wǎng)關控制器根據(jù)上報的所述業(yè)務相關信號或事件判斷業(yè)務類型，通知并控制切換相應的編解碼方案；D所述編解碼方案的切換觸發(fā)承載資源重協(xié)商和更新。
其中，在所述步驟C中切換所述編解碼方案時忽略承載資源相關信息；所述步驟D包含以下子步驟所述媒體網(wǎng)關控制器下發(fā)的新的編解碼方案觸發(fā)承載資源重協(xié)商；所述媒體網(wǎng)關根據(jù)配置的對應業(yè)務類型的承載資源信息向?qū)Χ税l(fā)起協(xié)商；協(xié)商成功后，雙方使用新的承載資源進行業(yè)務傳輸，并釋放原承載資源。
此外在所述方法中，所述通信雙方的媒體網(wǎng)關控制器通過承載無關呼叫控制帶外協(xié)商用于傳輸業(yè)務的編解碼方案。
此外在所述方法中，所述步驟C中所述媒體網(wǎng)關之間通過基于IP的承載控制協(xié)議協(xié)商或重協(xié)商所述承載資源。
此外在所述方法中，所述基于IP的承載控制協(xié)議協(xié)商過程中，
在呼叫建立階段，所述媒體網(wǎng)關控制器下發(fā)H.248信令支持所述基于IP的承載控制協(xié)議協(xié)商，配置承載資源和虛擬編解碼方案；在呼叫過程中，當所述編解碼方案發(fā)生切換時，所述媒體網(wǎng)關控制器下發(fā)H.248信令，忽略所述承載資源信息，并通知所切換的編解碼方案，同時觸發(fā)所述基于IP的承載控制協(xié)議重協(xié)商。
此外在所述方法中，所述承載資源是指IP地址或端口號。
此外在所述方法中，所述步驟A還包含子步驟主叫匯接局的所述媒體網(wǎng)關控制器發(fā)送初始地址消息，在其中攜帶本局支持的編解碼方案；被叫匯接局的所述媒體網(wǎng)關控制器發(fā)回應用傳送消息，在其中攜帶協(xié)商后的編解碼方案；所述被叫端發(fā)回振鈴及應答消息；主被叫匯接局的所述媒體網(wǎng)關控制器向?qū)襟w網(wǎng)關下發(fā)檢測所述業(yè)務相關信號或事件的請求。
此外在所述方法中，當所述步驟B中所述媒體網(wǎng)關檢測到所述業(yè)務相關信號或事件并上報給對應媒體網(wǎng)關控制器時，所述步驟C包含子步驟該媒體網(wǎng)關控制器下發(fā)請求指示該媒體網(wǎng)關切換到對應業(yè)務類型的編解碼方案；該媒體網(wǎng)關控制器通過所述承載無關呼叫控制指示對端媒體網(wǎng)關控制器對應業(yè)務類型的編解碼方案；對端媒體網(wǎng)關控制器下發(fā)請求指示對應媒體網(wǎng)關切換到對應業(yè)務類型的編解碼方案。
此外在所述方法中，所述業(yè)務包含語音業(yè)務、傳真業(yè)務、數(shù)據(jù)業(yè)務。
此外在所述方法中，所述編解碼方案包含G.729編解碼方案、G.711冗余編解碼方案、T.38編解碼方案。應該還有G.711透傳編解碼。
通過比較可以發(fā)現(xiàn)，本發(fā)明的技術方案與現(xiàn)有技術的主要區(qū)別在于，通過利用BICC帶外協(xié)商首先讓MGC之間協(xié)商所能切換的編解碼方案，然后MGC下發(fā)命令使得MGW開始檢測與傳真數(shù)據(jù)業(yè)務相關的信號、事件等，在呼叫通信過程中，MGW上報所檢測到的事件或信號，MGC判斷并引發(fā)對話兩側(cè)的編解碼方案的切換，比如切換到G.711或T.38，并通過IPBCP協(xié)商建立承載面，從而在MSC IP承載上實現(xiàn)傳真、數(shù)據(jù)業(yè)務，解決匯接局情況下語音傳真的切換，其中在切換時MGC忽略實際地址信息，完成編解碼方案切換后再通過MGC下發(fā)的Modify Codec的消息觸發(fā)IPBCP重協(xié)商端口號及IP地址等，然后更新IP地址和端口號信息，通過Modify消息觸發(fā)IPBCP的Modify消息進行端口號的修改，開始傳送傳真業(yè)務，并關閉原先的語音流，避免使用相同的端口號或IP地址。
這種技術方案上的區(qū)別，帶來了較為明顯的有益效果，即通過BICC帶外協(xié)商實現(xiàn)匯接局通信對端的編解碼方案的統(tǒng)一切換，通過信號或事件的檢測判斷傳真數(shù)據(jù)業(yè)務的發(fā)生，以及通過編解碼方案的切換實現(xiàn)傳真數(shù)據(jù)業(yè)務的傳送，從而在IP組網(wǎng)的TMSC承載傳真、數(shù)據(jù)業(yè)務，并且提高網(wǎng)絡帶寬的利用率，提高網(wǎng)絡靈活性，提高通信效率，同時傳真數(shù)據(jù)業(yè)務的實現(xiàn)也拓寬了移動通信及未來網(wǎng)絡的應用范圍，改善了用戶體驗，促進通信網(wǎng)絡發(fā)展；通過采用MGC和MGW間的IPBCP協(xié)商，實現(xiàn)通信對端IP地址和UDP端口號等的重協(xié)商，在語音、傳真、數(shù)據(jù)業(yè)務同時傳送的情況下，實現(xiàn)了語音和傳真的端口號不同的問題，有效防止語音流和傳真流之間在切換時的互相干擾問題；在TMSC IP承載上實現(xiàn)傳真、數(shù)據(jù)業(yè)務，解決匯接局情況下語音傳真的切換，同時減少處理的復雜度，防止語音流、傳真流互相干擾，提高業(yè)務質(zhì)量。


圖1是TMSC的IP承載組網(wǎng)結(jié)構(gòu)示意圖；圖2是根據(jù)本發(fā)明的第一實施方式的基于IP的匯接局多業(yè)務傳輸方法流程圖；圖3是根據(jù)本發(fā)明的第三實施方式的編解碼方案協(xié)商信令交互流程圖；圖4是根據(jù)本發(fā)明的第四實施方式的語音業(yè)務切換到傳真業(yè)務的信令交互流程圖。
具體實施例方式
為使本發(fā)明的目的、技術方案和優(yōu)點更加清楚，下面將結(jié)合附圖對本發(fā)明作進一步地詳細描述。
本發(fā)明提出基于IP的多業(yè)務傳輸方案，采用多種編解碼方案(G.729、G.711、G.711Red、T.38等)來傳輸語音(VoIP)、傳真(Fax)、數(shù)據(jù)(Data)、調(diào)制解調(diào)(Modem)等業(yè)務。先用語音通道建立通話之后根據(jù)帶內(nèi)呼叫信令判斷業(yè)務類型，對于傳真、數(shù)據(jù)等業(yè)務，需要切換至更大帶寬的編解碼方案；對于高速傳真業(yè)務則要采用更高效率的編解碼方案。由于對帶內(nèi)呼叫信令的檢測，能夠準確判斷業(yè)務類型。最終可以實現(xiàn)用更靈活組網(wǎng)的IP承載來高效傳輸各種業(yè)務。
在MGC之間通過BICC實現(xiàn)帶外協(xié)商編解碼方案，在MGW之間通過IPBCP實現(xiàn)承載資源如IP地址或UDP端口號等的協(xié)商分配，BICC在建立呼叫和編解碼方案切換時忽略實際承載資源信息，而在編解碼方案切換完成后，由IPBCP協(xié)商再重新配置。
在基于IP的業(yè)務傳輸中，主叫MGW和被叫MGW之間的傳輸由IP承載，業(yè)務傳輸大致分為協(xié)商、檢測、切換、更新幾個步驟，即先由主被叫雙方協(xié)商對應業(yè)務類型的備用編解碼方案，然后由MGW從帶內(nèi)信令中檢測與業(yè)務相關的特征信令，檢測結(jié)果上報給MGC，由MGC來判斷業(yè)務類型，并最終做出切換配置相應編解碼方案的控制操作，切換之后發(fā)出IPBCP重新協(xié)商承載資源，采用新資源通信的同時釋放舊資源。
本發(fā)明的第一實施方式，整個多業(yè)務傳送過程的基本步驟包括帶外協(xié)商、檢測信號、編解碼切換、承載重協(xié)商等，這個過程的流程圖如圖2所示。
在步驟201中，在呼叫建立前，通信雙方協(xié)商并配置用于傳輸業(yè)務的編解碼方案。通過BICC信令交互，發(fā)起端先發(fā)送本局所支持的所有可行的編解碼方案，這些方案包括支持各種業(yè)務的編解碼Codec，比如支持語音業(yè)務的G.729、支持語音和傳真業(yè)務的G.711/G.711Red等，對端收到協(xié)商請求后，將本局支持的編解碼方案發(fā)回，這樣雙方就協(xié)商得到共同支持的編解碼方案。
數(shù)據(jù)業(yè)務、傳真功能的提供需要MGC和MGW共同完成，由于IP承載的普通語音編碼(如G.729)不能支持傳真業(yè)務，需要在檢測到傳真事件時切換為支持傳真的編碼類型，如切換為G.711Red、T.38編碼。
在呼叫建立前進行編解碼帶外協(xié)商，呼叫應答成功后，如果協(xié)商后支持G.711Red或T.38編碼，則MGC在TDM端點向網(wǎng)關下發(fā)傳真/數(shù)據(jù)信號、傳真事件帶內(nèi)檢測請求，MGW檢測到后向MGC上報，MGC通過編解碼修改流程將IP端點的語音編碼修改為可傳遞傳真/數(shù)據(jù)的編碼(G.711Red、T.38)，從而實現(xiàn)傳真/數(shù)據(jù)功能。
在步驟202中，在呼叫過程中，媒體網(wǎng)關檢測業(yè)務相關信號或事件并分別上報給媒體網(wǎng)關控制器。在BICC帶外協(xié)商結(jié)束后，通信雙方就要下發(fā)MGW，請求其檢測相關業(yè)務的各種信號或事件，比如傳真業(yè)務的話，檢測CNG信號或CED和V21信號，MGW在呼叫過程中檢測這些信號，并上報給MGC，注意到在整個呼叫過程中都在進行檢測，而不是根據(jù)呼叫建立階段的判斷，這樣能夠精確判斷業(yè)務的切換。
在步驟203中，在呼叫過程中，媒體網(wǎng)關控制器根據(jù)上報的業(yè)務相關信號或事件判斷業(yè)務類型，通知并控制切換相應的編解碼方案。在這個步驟中，切換編解碼方案時忽略承載資源相關信息。MGC收到上報的業(yè)務相關信號和事件，就可以判斷是否啟動對應的業(yè)務，比如CNG信號的發(fā)生就指示傳真(FAX)業(yè)務的啟動，此時MGC下發(fā)請求通知MGW切換對應的Codec。本局MGC還要通過BICC信令通知對端MGC，對端MGC再下發(fā)請求通知其MGW切換對應的Codec。
在步驟204中，編解碼方案的切換觸發(fā)承載資源重協(xié)商和更新，MGC下發(fā)的新的編解碼方案觸發(fā)承載資源重協(xié)商。MGC與MGW之間的Mc接口上，MGC通過H.248信令，在Local描述符中指示引發(fā)IPBCP重協(xié)商。
在步驟205中，MGW根據(jù)配置的對應業(yè)務類型的承載資源信息向?qū)Χ税l(fā)起協(xié)商。MGW發(fā)送預先配置的承載資源信息，比如對于傳真業(yè)務，則發(fā)送預設的傳真業(yè)務專用UDP端口號，區(qū)別于之前的語音通道，可以避免混亂。對端確認該UDP端口號，協(xié)商完成，即分配成功新的承載資源。
在步驟206中，協(xié)商成功后，雙方使用新的承載資源進行業(yè)務傳輸，并釋放原承載資源。即關閉原來的UDP端口的語音通信，并采用新的端口進行傳真業(yè)務。
上面敘述中，通信雙方的信令層采用BICC，MGC通過BICC帶外協(xié)商用于傳輸業(yè)務的編解碼方案，在其他實施方式中也可以采用其他可行的信令，不限于BICC。同樣在MGW協(xié)商承載面資源分配時，可以采用但也不限于IPBCP實現(xiàn)。另外，承載資源一般是指IP地址和UDP端口號，當然在其他的基于IP的高層協(xié)議下，也是其他的端口號或其他類型的承載資源。
本發(fā)明的關鍵在于BICC及IPBCP協(xié)商的具體操作以及MGC等網(wǎng)元的處理方法。在本發(fā)明的第二實施方式中，IPBCP主要在兩個階段需要協(xié)商承載資源在呼叫建立階段，MGC下發(fā)H.248信令支持IPBCP協(xié)商，配置承載資源和虛擬編解碼方案；在呼叫過程中，當編解碼方案發(fā)生切換時，MGC下發(fā)H.248信令，忽略承載資源信息，并通知所切換的編解碼方案，同時觸發(fā)所述IPBCP重協(xié)商。
具體承載面的實現(xiàn)方法描述如下，呼叫建立階段，在MC接口上，MGC通過在H.248的Local描述符里面攜帶相應信息，來支持IPBCP的協(xié)商，IPBCP協(xié)商出本端和對端UDP端口號，以及虛擬CodecIuFP。BICC不關心實際物理承載地址，在相關命令中，使用不關注實際承載地址的方式(下文中的用“-”表示)，將后續(xù)Codec等信息在Local描述符里面下發(fā)給MGW，這樣就完成了編解碼的切換過程。
表1為支持IPBCP重協(xié)商的H.248信令，用于切換傳真業(yè)務的編解碼方案。其中關鍵部分Local描述符中“m＝image-udptl t38”表示MGC用“-”表示使用原有地址，并觸發(fā)UMG的T38傳送，即切換Codec并忽略了承載資源；“a＝T38FaxRateManagementtransferredTCF”表示采用端到端訓練；“a＝T38FaxUdpECT38UDPRedundancy”表示采用冗余包冗余；“a＝T38MaxBitRate14400”表示FAX最高速率為14400bps。
可見，MGC下發(fā)的新的編解碼觸發(fā)IPBCP的重新協(xié)商，MGW根據(jù)配置的傳真業(yè)務類型的端口號向?qū)Ψ桨l(fā)起協(xié)商。協(xié)商成功后，使用新的端口進行傳真業(yè)務流，以前的語音流關閉。
表1 支持IPBCP重協(xié)商的H.248信令

在本發(fā)明的第三實施方式中給出了BICC帶外協(xié)商的具體實現(xiàn)步驟。圖3示出了呼叫建立前的Codec協(xié)商及事件檢測請求流程，以局間為BICC信令為例首先進行編解碼(Code & Decode，簡稱“Codec”)帶外協(xié)商，MGC1向MGC2發(fā)送初始地址消息(Initial Address Message，簡稱“IAM”)，其中攜帶了主叫端即MGC1側(cè)支持的編解碼方案，如G.729、G.711Red、T.38等；MGC2收到該消息后判斷哪些Codec在本地支持，并將這些Codec發(fā)回，這樣雙方便協(xié)商確認了Codec方案，MGC2向MGC1返回應用傳輸消息(Application Transport Message，簡稱“APM”)消息，攜帶協(xié)商后確定的編解碼方案。
接著，MGC2向MGC1返回被叫振鈴消息(Address Complete Message，簡稱“ACM”)和應答消息(Answer Message，簡稱“ANM”)。
然后，主被叫MSC在TDM端點發(fā)起數(shù)據(jù)傳真信號、傳真事件檢測請求。MGC1向MGW1發(fā)送修改(Modify)消息，發(fā)起檢測業(yè)務相關信令的請求；MGW1返回Modify響應消息。另一側(cè)，MGC2向MGW2發(fā)送Modify消息，發(fā)起檢測業(yè)務相關信令的請求；MGW2返回Modify響應消息。這里檢測請求通知MGW對帶內(nèi)的業(yè)務相關信令，比如Fax業(yè)務的V21信令、CM(Fax)等，進行監(jiān)測，將檢測事件通知MGC。
在本發(fā)明的第四實施方式中，給出了業(yè)務切換過程及承載資源重協(xié)商過程的實現(xiàn)方案。當MGW檢測到業(yè)務相關信號或事件并上報給對應的MGC時，該MGC下發(fā)請求指示該MGW切換到對應業(yè)務類型的編解碼方案；該MGC通過所述BICC指示對端MGC對應業(yè)務類型的編解碼方案；對端MGC下發(fā)請求指示對應MGW切換到對應業(yè)務類型的編解碼方案。
在MGC向MGW發(fā)起帶內(nèi)檢測后，MGC根據(jù)MGW上報的信號，按上報信號不同分業(yè)務進行處理，可以支持普通FAX、高速FAX、MODEM數(shù)據(jù)業(yè)務。如圖4所示，以普通傳真業(yè)務為例，需要檢測的信號是CNG或者CED和V21，圖中假設協(xié)商結(jié)果兩端網(wǎng)關都支持G.711Red。
語音通道建立后，對普通Fax，MGW1上報CNG或者CED、V21信號，MGC1根據(jù)V21信號通知MGW切換到Fax通道(CED不能作為MGC切換的依據(jù))；MGC1下發(fā)modify，修改IP端點為Codec為G.711Red。
通過BICC攜帶G.711Red編碼到對端，要求MGC2修改Codec為G.711Red。
MGC2下發(fā)modify，修改被叫IP端點Codec為G.711Red。
完成Codec修改，之后引發(fā)的IPBCP的協(xié)商即如前所述把UDP端口號改為Fax業(yè)務專用端口號，而關閉語音業(yè)務的端口。
上述實施方式的描述中，業(yè)務類型有語音業(yè)務VoIP、傳真業(yè)務Fax、數(shù)據(jù)業(yè)務Data、調(diào)制解調(diào)器業(yè)務Modem等。而編解碼方案有G.729編解碼方案、G.711冗余編解碼方案、T.38編解碼方案等。當然以后技術發(fā)展出現(xiàn)新的業(yè)務類型及相應的編解碼方案，仍然適用于本發(fā)明中，能夠?qū)崿F(xiàn)多業(yè)務的傳輸，具有很好的兼容性。
熟悉本領域的技術人員可以理解，上述實施方式中技術細節(jié)的描述中以一些常用應用場景為例，給出具體的參數(shù)設置等，在實際應用中根據(jù)實際情況可以靈活設置，更好地實現(xiàn)發(fā)明目的，并不影響本發(fā)明的實質(zhì)和范圍。
雖然通過參照本發(fā)明的某些優(yōu)選實施方式，已經(jīng)對本發(fā)明進行了圖示和描述，但本領域的普通技術人員應該明白，可以在形式上和細節(jié)上對其作各種改變，而不偏離本發(fā)明的精神和范圍。
權(quán)利要求
1.一種基于IP的匯接局多業(yè)務傳輸方法，其特征在于，包含以下步驟A在呼叫建立前，通信雙方協(xié)商并配置用于傳輸業(yè)務的編解碼方案；B在呼叫過程中，媒體網(wǎng)關檢測業(yè)務相關信號或事件并分別上報給媒體網(wǎng)關控制器；C在呼叫過程中，所述媒體網(wǎng)關控制器根據(jù)上報的所述業(yè)務相關信號或事件判斷業(yè)務類型，通知并控制切換相應的編解碼方案；D所述編解碼方案的切換觸發(fā)承載資源重協(xié)商和更新。
2.根據(jù)權(quán)利要求1所述的基于IP的匯接局多業(yè)務傳輸方法，其特征在于，在所述步驟C中切換所述編解碼方案時忽略承載資源相關信息；所述步驟D包含以下子步驟所述媒體網(wǎng)關控制器下發(fā)的新的編解碼方案觸發(fā)承載資源重協(xié)商；所述媒體網(wǎng)關根據(jù)配置的對應業(yè)務類型的承載資源信息向?qū)Χ税l(fā)起協(xié)商；協(xié)商成功后，雙方使用新的承載資源進行業(yè)務傳輸，并釋放原承載資源。
3.根據(jù)權(quán)利要求2所述的基于IP的匯接局多業(yè)務傳輸方法，其特征在于，所述通信雙方的媒體網(wǎng)關控制器通過承載無關呼叫控制帶外協(xié)商用于傳輸業(yè)務的編解碼方案。
4.根據(jù)權(quán)利要求3所述的基于IP的匯接局多業(yè)務傳輸方法，其特征在于，所述步驟C中所述媒體網(wǎng)關之間通過基于IP的承載控制協(xié)議協(xié)商或重協(xié)商所述承載資源。
5.根據(jù)權(quán)利要求4所述的基于IP的匯接局多業(yè)務傳輸方法，其特征在于，所述基于IP的承載控制協(xié)議協(xié)商過程中，在呼叫建立階段，所述媒體網(wǎng)關控制器下發(fā)H.248信令支持所述基于IP的承載控制協(xié)議協(xié)商，配置承載資源和虛擬編解碼方案；在呼叫過程中，當所述編解碼方案發(fā)生切換時，所述媒體網(wǎng)關控制器下發(fā)H.248信令，忽略所述承載資源信息，并通知所切換的編解碼方案，同時觸發(fā)所述基于IP的承載控制協(xié)議重協(xié)商。
6.根據(jù)權(quán)利要求5所述的基于IP的匯接局多業(yè)務傳輸方法，其特征在于，所述承載資源是指IP地址或端口號。
7.根據(jù)權(quán)利要求6所述的基于IP的匯接局多業(yè)務傳輸方法，其特征在于，所述步驟A還包含子步驟主叫匯接局的所述媒體網(wǎng)關控制器發(fā)送初始地址消息，在其中攜帶本局支持的編解碼方案；被叫匯接局的所述媒體網(wǎng)關控制器發(fā)回應用傳送消息，在其中攜帶協(xié)商后的編解碼方案；所述被叫端發(fā)回振鈴及應答消息；主被叫匯接局的所述媒體網(wǎng)關控制器向?qū)襟w網(wǎng)關下發(fā)檢測所述業(yè)務相關信號或事件的請求。
8.根據(jù)權(quán)利要求7所述的基于IP的匯接局多業(yè)務傳輸方法，其特征在于，當所述步驟B中所述媒體網(wǎng)關檢測到所述業(yè)務相關信號或事件并上報給對應媒體網(wǎng)關控制器時，所述步驟C包含子步驟該媒體網(wǎng)關控制器下發(fā)請求指示該媒體網(wǎng)關切換到對應業(yè)務類型的編解碼方案；該媒體網(wǎng)關控制器通過所述承載無關呼叫控制指示對端媒體網(wǎng)關控制器對應業(yè)務類型的編解碼方案；對端媒體網(wǎng)關控制器下發(fā)請求指示對應媒體網(wǎng)關切換到對應業(yè)務類型的編解碼方案。
9.根據(jù)權(quán)利要求1-8任意一項所述的基于IP的匯接局多業(yè)務傳輸方法，其特征在于，所述業(yè)務包含語音業(yè)務、傳真業(yè)務、數(shù)據(jù)業(yè)務。
10.根據(jù)權(quán)利要求9所述的基于IP的匯接局多業(yè)務傳輸方法，其特征在于，所述編解碼方案包含G.729編解碼方案、G.711編解碼方案、G.711冗余編解碼方案、T.38編解碼方案。
全文摘要
本發(fā)明涉及移動通信系統(tǒng)中匯接局基于IP的通信業(yè)務傳輸方法，公開了一種基于IP的匯接局多業(yè)務傳輸方法，使得TMSC的IP承載組網(wǎng)滿足并實現(xiàn)語音、傳真、數(shù)據(jù)等多種業(yè)務的傳輸。本發(fā)明中，通過利用BICC帶外協(xié)商首先讓MGC之間協(xié)商所能切換的編解碼方案，然后MGC下發(fā)命令使得MGW開始檢測與傳真數(shù)據(jù)業(yè)務相關的信號、事件等，在呼叫通信過程中，MGW上報所檢測到的事件或信號，MGC判斷并引發(fā)對話兩側(cè)的編解碼方案的切換，并通過IPBCP協(xié)商建立承載面，從而在MSC IP承載上實現(xiàn)傳真、數(shù)據(jù)業(yè)務，解決匯接局情況下語音傳真的切換。
文檔編號H04Q7/22GK101031006SQ20061002434
公開日2007年9月5日 申請日期2006年3月3日 優(yōu)先權(quán)日2006年3月3日
發(fā)明者李琥 申請人:華為技術有限公司