国产精品69久久久久999小说,久久久久久久爱,日本色道久久

PSTN與NGN互通研究

2007/11/29

　　摘要　隨著網(wǎng)絡(luò)技術(shù)及通信技術(shù)的快速發(fā)展，傳統(tǒng)電信網(wǎng)絡(luò)與下一代網(wǎng)絡(luò)之間的互通成為一個很熱門的話題。網(wǎng)絡(luò)互通的主要問題之一是承載協(xié)議的相互轉(zhuǎn)換。文章介紹了ISUP網(wǎng)絡(luò)同SIP網(wǎng)絡(luò)互通的呼叫流程，詳細(xì)闡述了ISUP協(xié)議同SIP協(xié)議的相互映射問題。

1、概述

　　隨著Internet技術(shù)的飛速發(fā)展，各種各樣的數(shù)據(jù)業(yè)務(wù)、多媒體業(yè)務(wù)不斷地涌現(xiàn)出來，同時由于移動網(wǎng)絡(luò)的飛速發(fā)展，網(wǎng)絡(luò)用戶也在不斷地增加。人們希望能夠方便快捷的使用業(yè)務(wù)，并且對業(yè)務(wù)的簡單化、多樣化及通用移動性的要求越來越高，同時希望能夠達(dá)到固定移動的無縫融合通信。

　　另外，傳統(tǒng)的PSTN技術(shù)已經(jīng)趨于完善，單純的話音業(yè)務(wù)一方面無法滿足用戶的需求，另一方面也不能支撐產(chǎn)業(yè)的進(jìn)一步發(fā)展。應(yīng)運而生的下一代網(wǎng)絡(luò)，就是希望能夠在全網(wǎng)實現(xiàn)無縫通信。那么各種業(yè)務(wù)、各個用戶群之間要想達(dá)到無縫通信，在相互通信的時候就需要保持傳輸協(xié)議的一致性。

2、網(wǎng)絡(luò)互通涉及的問題

　　IMS是3GPP在Release 5版本標(biāo)準(zhǔn)中提出來的支持IP多媒體業(yè)務(wù)的子系統(tǒng)，能夠同時提供話音業(yè)務(wù)和各種數(shù)據(jù)業(yè)務(wù)，但是IMS畢竟是在移動領(lǐng)域中開發(fā)出來的，多數(shù)業(yè)務(wù)也是在移動領(lǐng)域來開發(fā)的。無論是對運營商還是用戶都不希望被局限在移動網(wǎng)絡(luò)中，畢竟傳統(tǒng)的固定網(wǎng)絡(luò)用戶還是比較多的，兩種網(wǎng)絡(luò)可能會在相當(dāng)長的時間里共存。既然共存，當(dāng)然要互通有無，這樣問題就出現(xiàn)了。IMS網(wǎng)絡(luò)基于SIP協(xié)議體系，而傳統(tǒng)的固定網(wǎng)絡(luò)則是基于SS7協(xié)議體系。如果存在于這兩種不同網(wǎng)絡(luò)中的用戶終端要進(jìn)行會話，就會涉及到網(wǎng)絡(luò)協(xié)議不一致的問題。

　　協(xié)議互通的關(guān)鍵問題在于網(wǎng)絡(luò)接口的設(shè)計。所以，要需考慮出口網(wǎng)關(guān)和入口網(wǎng)關(guān)的設(shè)計。可以考慮在IMS網(wǎng)絡(luò)和PSTN網(wǎng)絡(luò)的接口處放上一個轉(zhuǎn)換設(shè)備，就像一個翻譯器一樣，將對應(yīng)的呼叫消息翻譯成適合于在各自的網(wǎng)絡(luò)上傳送的消息格式。網(wǎng)絡(luò)接口處的出口網(wǎng)關(guān)就可以完成這樣一種工作。

3、ISUP終端到SIP終端的呼叫流程

　　雖然呼叫雙方所在的網(wǎng)絡(luò)支撐協(xié)議可能不同，但是各種電話終端的呼叫都有一個類似的過程：首先，主叫方發(fā)出呼叫消息，若找不到被叫會收到釋放消息，若找到被叫，需看被叫是否忙，忙就回一條釋放消息，空閑則返回一條應(yīng)答消息；被叫接聽則返回接聽消息，開始通話；最后掛機(jī)方發(fā)出釋放消息。

　　3.1　完整呼叫應(yīng)答的建立過程

　�。�1）當(dāng)一個PSTN用戶希望同一個SIP用戶建立會話時，PSTN網(wǎng)絡(luò)會產(chǎn)生一個IAM消息發(fā)送到網(wǎng)關(guān)；

　�。�2）網(wǎng)關(guān)基于收到的IAM消息，產(chǎn)生一個INVITE消息，并發(fā)送到適當(dāng)?shù)腟IP節(jié)點；

　�。�3）當(dāng)SIP節(jié)點判斷收到的INVITE消息能夠證明呼叫擁有充足的地址信息時，會產(chǎn)生一個180或18x臨時響應(yīng)；

　�。�4）網(wǎng)關(guān)根據(jù)收到的18x臨時響應(yīng)，產(chǎn)生一個ACM消息。如果響應(yīng)不是180，ACM會攜帶一個沒有任何指示值的“被叫用戶狀態(tài)”消息；

　�。�5）SIP節(jié)點可能會更進(jìn)一步的使用18x臨時消息來表示會話的進(jìn)行；

　�。�6）發(fā)出ACM消息后，所有的臨時消息將被翻譯成ISUP CPG消息；

　�。�7）一旦SIP節(jié)點回答了呼叫，就會發(fā)出一個200 OK消息；

　�。�8）網(wǎng)關(guān)基于收到的200 OK消息，向ISUP節(jié)點發(fā)出一個ANM消息；

　�。�9）網(wǎng)關(guān)向SIP節(jié)點發(fā)送一個ACK消息來確認(rèn)已經(jīng)收到了INVITE消息的最終響應(yīng)。

　　3.2　會話的拆除

　　關(guān)于會話的拆除，涉及到誰先掛機(jī)的問題。

　�。�1）如果是SIP終端先掛機(jī)，此時SIP節(jié)點會發(fā)送一條BYE消息到MGC，MGC基于收到的BYE消息，會馬上向SIP節(jié)點返回一條200 OK響應(yīng)消息。然后MGC需要馬上釋放網(wǎng)關(guān)中占用的資源，并向ISUP節(jié)點發(fā)送一條REL消息，ISUP節(jié)點會返回一條RLC消息來證明資源已釋放。

　�。�2）如果是ISUP終端先掛機(jī)，ISUP節(jié)點要向MGC發(fā)送一條REL消息，網(wǎng)關(guān)基于收到的REL消息，向ISUP節(jié)點返回一條RLC確認(rèn)消息，同時向SIP節(jié)點發(fā)送一條BYE消息，SIP節(jié)點基于此BYE消息向網(wǎng)關(guān)返回一條200 OK消息作為確認(rèn)。此期間，網(wǎng)關(guān)同時還要做資源釋放的工作。

4、消息映射

　　由于ISUP同SIP采用不同的消息封裝機(jī)制，ISUP采用的是二進(jìn)制編碼，而SIP采用文本編碼方式。因此，MGC收到ISUP消息后通過ISUP-MIME方式把ISUP消息內(nèi)容封裝在SIP消息體中，傳送到SIP接收端MGC再把所需內(nèi)容提取出來，從而完成對ISUP消息的透明傳送，實現(xiàn)IP網(wǎng)同PSTN網(wǎng)絡(luò)的無縫連接。具體過程見圖。

請求響應(yīng)流程

　　由于ISUP在SIP網(wǎng)絡(luò)中是透明傳送的，因此MGC就需要完成ISUP同SIP信令的轉(zhuǎn)換。呼叫信令的轉(zhuǎn)換，最直觀的方法就是翻譯。MGC根據(jù)確定的對應(yīng)關(guān)系對SIP消息和ISUP消息進(jìn)行映射，MGC收到一條ISUP消息后，需要理解ISUP消息中的關(guān)鍵信息并進(jìn)行翻譯，然后填入SIP頭部及SIP消息體中。翻譯過程一定是一一對應(yīng)的。例如，IAM翻譯成INVITE，ACM翻譯成Ringing，REL翻譯成BYE等等。也就是說逐條地取出A信令消息參數(shù)值，映射到B信令消息體中，再接著傳送。下面就對主要的信令消息的映射做一下簡單的分析。

　　4.1　IAM消息的映射

　　MGC收到IAM消息后，對消息進(jìn)行分析，將其映射成INVITE請求消息，再將其發(fā)送出去。接下來映射的重點就在于如何將IAM中的關(guān)鍵參數(shù)映射到INVITE消息中。MCC收到IAM消息后會去讀取IAM消息中的被叫用戶號碼，即參數(shù)CPN。讀出來后翻譯成目的地tel URI放入到INVITE消息的To域和Reguest-URI域。但當(dāng)FCI參數(shù)中的“號碼已轉(zhuǎn)移”位表明被叫方號碼已轉(zhuǎn)移時，就只能尋求其他參數(shù)了。在tel URL翻譯完成后，還需要在其中附加一些ISUP字段。

　�。�1）如果IAM中存在有CIP或TNS字段，則MGC應(yīng)該從所給參數(shù)中取出CIC并加以分析。在通過本地策略驗證之后，將一個“cic=”字段附加到目的地tel URL的后面。有一點需要注意的是，CIC應(yīng)該附加到國家代碼的后面。比如在中國，“5062”就應(yīng)該是“+86-5062”。

　�。�2）如果FCI參數(shù)中的“號碼已轉(zhuǎn)移”位表明已經(jīng)執(zhí)行過本地號碼轉(zhuǎn)移的操作或者IAM消息的CPN中存在有本地路由號碼，則必須在URL之后附加一個“npdi=yes”字段。同時要把此路由號碼轉(zhuǎn)換成tel URL的形式拷貝到“rn=”字段中。如果CPN中沒有路由號碼，且IAM消息中存在有通用數(shù)字參數(shù)GDP，則對此GDP參數(shù)進(jìn)行轉(zhuǎn)換并拷貝到“rn=”字段附加到tel URL之后。

　�。�3）多數(shù)情況下，To字段和Request-URI都是由目的地tel URL來提供的。但是，如果IAM中存在有OCN參數(shù)的話，To字段就應(yīng)該由OCN參數(shù)翻譯得來。

　　（4）From頭字段的構(gòu)造依賴于IAM中的CIN參數(shù)。如果CIN不存在，網(wǎng)關(guān)會自行構(gòu)造一個只包含有網(wǎng)關(guān)主機(jī)名的虛擬的From頭字段，如果CIN存在，則需要將其翻譯為tel URL來生成From頭字段。

　　4.2　1xx響應(yīng)消息的映射

　　MGC收到的響應(yīng)消息中，如果是100 trying消息則網(wǎng)關(guān)不觸發(fā)任何PSTN消息。如果是18x消息，且消息體中沒有ISUP消息，此時網(wǎng)關(guān)需要判斷在此之前是否有ACM發(fā)送出去。如果之前沒有ACM發(fā)送出去，MGC將依據(jù)表1來響應(yīng)消息。

　　表1　18x響應(yīng)消息的映射（MGC未發(fā)送ACM）

　　如果之前已發(fā)送過ACM消息，那么ISUP消息的響應(yīng)則依據(jù)表2。

　　表2　18x響應(yīng)消息的映射（MGC已發(fā)送ACM消息）

　　4.3　200響應(yīng)消息的映射

　　收到200 OK響應(yīng)消息后，網(wǎng)關(guān)需要建立一條雙向通道，向PSTN發(fā)送一條ANM應(yīng)答消息，同時向SIP網(wǎng)絡(luò)發(fā)送一條ACK確認(rèn)消息。但是，如果網(wǎng)關(guān)在發(fā)送ACM消息之前收到200 OK消息的話，MGC應(yīng)該向PSTN發(fā)送一條CON消息而非ANM消息。

　　4.4　REL響應(yīng)消息的映射

　　如果是正常的會話結(jié)束，且PSTN端先掛機(jī)，PSTN端會向MGC發(fā)送一條REL消息，網(wǎng)關(guān)依據(jù)此REL消息，向SIP端點發(fā)送一條BYE消息來通知SIP網(wǎng)絡(luò)另一端已掛機(jī)。假如SIP端還未接通，PSTN終端就掛機(jī)了，此時網(wǎng)關(guān)依據(jù)收到的REL消息向SIP終端發(fā)送一條CANCEL消息，告訴SIP終端取消會話。

　　4.5　異常響應(yīng)消息的映射

　　前面介紹的會話建立過程，是在假設(shè)沒有任何異常發(fā)生的情況下完成的。但是實際當(dāng)中，呼叫雙方在會話建立過程中可能出現(xiàn)這樣或那樣的問題。因此還需要考慮異常響應(yīng)消息的映射問題。比如說，網(wǎng)關(guān)連接不上URI中Contact頭字段中所指的tel URL地址，或者說沒有匹配的ENUM，這時就要用到重定向了。

　　3xx類響應(yīng)消息是由重定向服務(wù)器來產(chǎn)生的。當(dāng)網(wǎng)關(guān)收到來自于SIP端口的3xx響應(yīng)消息時，即與其中的Contact頭字段中所指示的用戶聯(lián)系，同時向PSTN端口發(fā)送一條事件代碼為6的CPG消息，告訴PSTN網(wǎng)絡(luò)呼叫正在被處理。

　　網(wǎng)關(guān)收到4xx～6xx類響應(yīng)消息時，表明網(wǎng)關(guān)之前發(fā)送到SIP端口的INVITE消息被拒絕了。多數(shù)情況下，網(wǎng)關(guān)需要釋放它所占用的資源，并發(fā)送一條帶有原因值的REL消息給PSTN網(wǎng)絡(luò)，同時還要給SIP網(wǎng)絡(luò)發(fā)送一條資源釋放的ACK確認(rèn)消息。PSTN端口也需要給MGC發(fā)送一條RLC確認(rèn)消息，告訴網(wǎng)關(guān)已完成資源釋放。

　　4xx～6xx異常響應(yīng)消息與REL原因代碼之間的映射關(guān)系參考文獻(xiàn)1中有詳細(xì)介紹，此處不再贅述。

5、結(jié)束語

　　IP多媒體子系統(tǒng)（IMS）是在GSM向UMTS的演進(jìn)過程中，由3GPP在Release 5版本中提出。IMS網(wǎng)絡(luò)的特點是以純IP網(wǎng)絡(luò)作為承載網(wǎng)絡(luò)，以SIP（會話初始協(xié)議）作為基本的通信協(xié)議來建立會話。而傳統(tǒng)的PSTN網(wǎng)絡(luò)采用的程控交換體系，其信令系統(tǒng)采用的是7號信令系統(tǒng)。那么就涉及到會話過程中呼叫信令的轉(zhuǎn)換問題。

　　本文對ISUP協(xié)議與SIP協(xié)議互通進(jìn)行了簡單的介紹，并對此兩種協(xié)議在互通時的映射問題做了詳細(xì)地分析。以上僅限于理論上的分析研究，在實際應(yīng)用當(dāng)中可能還會遇到很多無法預(yù)料的問題。因此還有很多有關(guān)這兩種協(xié)議的映射問題有待于進(jìn)一步的深入探討。相信在不久的將來，隨著FMC的升溫，對于ISUP與SIP互通的研究也將會不斷的成熟與完善。

　　參考文獻(xiàn)

　　[1]　IETF RFC 3398 Integrated Services Digital Network（ISDN）User Part（ISUP）to Session Initiation Protocol（SIP）Mapping

中國聯(lián)通

下一代網(wǎng)絡(luò)和業(yè)務(wù)轉(zhuǎn)型過程中資源管理系統(tǒng)的建設(shè) 2007-11-09

“2007年中國國際通信設(shè)備技術(shù)展覽會”核心網(wǎng)發(fā)展掃描 2007-10-29

向NGN演進(jìn)過渡的聯(lián)通經(jīng)驗 2007-10-25

鼎力打造全面測試解決方案助力NGN網(wǎng)絡(luò)商用 2007-10-23

分類信息: 電信_與_NGN及軟交換技術(shù) 行業(yè)_電信_文摘技術(shù)_NGN及軟交換_文摘