PSTN與NGN互通研究
2007/11/29
摘要 隨著網(wǎng)絡(luò)技術(shù)及通信技術(shù)的快速發(fā)展，傳統(tǒng)電信網(wǎng)絡(luò)與下一代網(wǎng)絡(luò)之間的互通成為一個(gè)很熱門的話題。網(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)出來，同時(shí)由于移動(dòng)網(wǎng)絡(luò)的飛速發(fā)展，網(wǎng)絡(luò)用戶也在不斷地增加。人們希望能夠方便快捷的使用業(yè)務(wù)，并且對(duì)業(yè)務(wù)的簡(jiǎn)單化、多樣化及通用移動(dòng)性的要求越來越高，同時(shí)希望能夠達(dá)到固定移動(dòng)的無縫融合通信。
另外，傳統(tǒng)的PSTN技術(shù)已經(jīng)趨于完善，單純的話音業(yè)務(wù)一方面無法滿足用戶的需求，另一方面也不能支撐產(chǎn)業(yè)的進(jìn)一步發(fā)展。應(yīng)運(yùn)而生的下一代網(wǎng)絡(luò)，就是希望能夠在全網(wǎng)實(shí)現(xiàn)無縫通信。那么各種業(yè)務(wù)、各個(gè)用戶群之間要想達(dá)到無縫通信，在相互通信的時(shí)候就需要保持傳輸協(xié)議的一致性。
2、網(wǎng)絡(luò)互通涉及的問題
IMS是3GPP在Release 5版本標(biāo)準(zhǔn)中提出來的支持IP多媒體業(yè)務(wù)的子系統(tǒng)，能夠同時(shí)提供話音業(yè)務(wù)和各種數(shù)據(jù)業(yè)務(wù)，但是IMS畢竟是在移動(dòng)領(lǐng)域中開發(fā)出來的，多數(shù)業(yè)務(wù)也是在移動(dòng)領(lǐng)域來開發(fā)的。無論是對(duì)運(yùn)營(yíng)商還是用戶都不希望被局限在移動(dòng)網(wǎng)絡(luò)中，畢竟傳統(tǒng)的固定網(wǎng)絡(luò)用戶還是比較多的，兩種網(wǎng)絡(luò)可能會(huì)在相當(dāng)長(zhǎng)的時(shí)間里共存。既然共存，當(dāng)然要互通有無，這樣問題就出現(xiàn)了。IMS網(wǎng)絡(luò)基于SIP協(xié)議體系，而傳統(tǒng)的固定網(wǎng)絡(luò)則是基于SS7協(xié)議體系。如果存在于這兩種不同網(wǎng)絡(luò)中的用戶終端要進(jìn)行會(huì)話，就會(huì)涉及到網(wǎng)絡(luò)協(xié)議不一致的問題。
協(xié)議互通的關(guān)鍵問題在于網(wǎng)絡(luò)接口的設(shè)計(jì)。所以，要需考慮出口網(wǎng)關(guān)和入口網(wǎng)關(guān)的設(shè)計(jì)�？梢钥紤]在IMS網(wǎng)絡(luò)和PSTN網(wǎng)絡(luò)的接口處放上一個(gè)轉(zhuǎn)換設(shè)備，就像一個(gè)翻譯器一樣，將對(duì)應(yīng)的呼叫消息翻譯成適合于在各自的網(wǎng)絡(luò)上傳送的消息格式。網(wǎng)絡(luò)接口處的出口網(wǎng)關(guān)就可以完成這樣一種工作。
3、ISUP終端到SIP終端的呼叫流程
雖然呼叫雙方所在的網(wǎng)絡(luò)支撐協(xié)議可能不同，但是各種電話終端的呼叫都有一個(gè)類似的過程：首先，主叫方發(fā)出呼叫消息，若找不到被叫會(huì)收到釋放消息，若找到被叫，需看被叫是否忙，忙就回一條釋放消息，空閑則返回一條應(yīng)答消息；被叫接聽則返回接聽消息，開始通話；最后掛機(jī)方發(fā)出釋放消息。
3.1 完整呼叫應(yīng)答的建立過程
�。�1）當(dāng)一個(gè)PSTN用戶希望同一個(gè)SIP用戶建立會(huì)話時(shí)，PSTN網(wǎng)絡(luò)會(huì)產(chǎn)生一個(gè)IAM消息發(fā)送到網(wǎng)關(guān)；
�。�2）網(wǎng)關(guān)基于收到的IAM消息，產(chǎn)生一個(gè)INVITE消息，并發(fā)送到適當(dāng)?shù)腟IP節(jié)點(diǎn)；
�。�3）當(dāng)SIP節(jié)點(diǎn)判斷收到的INVITE消息能夠證明呼叫擁有充足的地址信息時(shí)，會(huì)產(chǎn)生一個(gè)180或18x臨時(shí)響應(yīng)；
（4）網(wǎng)關(guān)根據(jù)收到的18x臨時(shí)響應(yīng)，產(chǎn)生一個(gè)ACM消息。如果響應(yīng)不是180，ACM會(huì)攜帶一個(gè)沒有任何指示值的“被叫用戶狀態(tài)”消息；
（5）SIP節(jié)點(diǎn)可能會(huì)更進(jìn)一步的使用18x臨時(shí)消息來表示會(huì)話的進(jìn)行；
（6）發(fā)出ACM消息后，所有的臨時(shí)消息將被翻譯成ISUP CPG消息；
�。�7）一旦SIP節(jié)點(diǎn)回答了呼叫，就會(huì)發(fā)出一個(gè)200 OK消息；
�。�8）網(wǎng)關(guān)基于收到的200 OK消息，向ISUP節(jié)點(diǎn)發(fā)出一個(gè)ANM消息；
（9）網(wǎng)關(guān)向SIP節(jié)點(diǎn)發(fā)送一個(gè)ACK消息來確認(rèn)已經(jīng)收到了INVITE消息的最終響應(yīng)。
3.2 會(huì)話的拆除
關(guān)于會(huì)話的拆除，涉及到誰先掛機(jī)的問題。
（1）如果是SIP終端先掛機(jī)，此時(shí)SIP節(jié)點(diǎn)會(huì)發(fā)送一條BYE消息到MGC，MGC基于收到的BYE消息，會(huì)馬上向SIP節(jié)點(diǎn)返回一條200
OK響應(yīng)消息。然后MGC需要馬上釋放網(wǎng)關(guān)中占用的資源，并向ISUP節(jié)點(diǎn)發(fā)送一條REL消息，ISUP節(jié)點(diǎn)會(huì)返回一條RLC消息來證明資源已釋放。
�。�2）如果是ISUP終端先掛機(jī)，ISUP節(jié)點(diǎn)要向MGC發(fā)送一條REL消息，網(wǎng)關(guān)基于收到的REL消息，向ISUP節(jié)點(diǎn)返回一條RLC確認(rèn)消息，同時(shí)向SIP節(jié)點(diǎn)發(fā)送一條BYE消息，SIP節(jié)點(diǎn)基于此BYE消息向網(wǎng)關(guān)返回一條200
OK消息作為確認(rèn)。此期間，網(wǎng)關(guān)同時(shí)還要做資源釋放的工作。
4、消息映射
由于ISUP同SIP采用不同的消息封裝機(jī)制，ISUP采用的是二進(jìn)制編碼，而SIP采用文本編碼方式。因此，MGC收到ISUP消息后通過ISUP-MIME方式把ISUP消息內(nèi)容封裝在SIP消息體中，傳送到SIP接收端MGC再把所需內(nèi)容提取出來，從而完成對(duì)ISUP消息的透明傳送，實(shí)現(xiàn)IP網(wǎng)同PSTN網(wǎng)絡(luò)的無縫連接。具體過程見圖。
請(qǐng)求響應(yīng)流程
由于ISUP在SIP網(wǎng)絡(luò)中是透明傳送的，因此MGC就需要完成ISUP同SIP信令的轉(zhuǎn)換。呼叫信令的轉(zhuǎn)換，最直觀的方法就是翻譯。MGC根據(jù)確定的對(duì)應(yīng)關(guān)系對(duì)SIP消息和ISUP消息進(jìn)行映射，MGC收到一條ISUP消息后，需要理解ISUP消息中的關(guān)鍵信息并進(jìn)行翻譯，然后填入SIP頭部及SIP消息體中。翻譯過程一定是一一對(duì)應(yīng)的。例如，IAM翻譯成INVITE，ACM翻譯成Ringing，REL翻譯成BYE等等。也就是說逐條地取出A信令消息參數(shù)值，映射到B信令消息體中，再接著傳送。下面就對(duì)主要的信令消息的映射做一下簡(jiǎn)單的分析。
4.1 IAM消息的映射
MGC收到IAM消息后，對(duì)消息進(jìn)行分析，將其映射成INVITE請(qǐng)求消息，再將其發(fā)送出去。接下來映射的重點(diǎn)就在于如何將IAM中的關(guān)鍵參數(shù)映射到INVITE消息中。MCC收到IAM消息后會(huì)去讀取IAM消息中的被叫用戶號(hào)碼，即參數(shù)CPN。讀出來后翻譯成目的地tel
URI放入到INVITE消息的To域和Reguest-URI域。但當(dāng)FCI參數(shù)中的“號(hào)碼已轉(zhuǎn)移”位表明被叫方號(hào)碼已轉(zhuǎn)移時(shí)，就只能尋求其他參數(shù)了。在tel
URL翻譯完成后，還需要在其中附加一些ISUP字段。
�。�1）如果IAM中存在有CIP或TNS字段，則MGC應(yīng)該從所給參數(shù)中取出CIC并加以分析。在通過本地策略驗(yàn)證之后，將一個(gè)“cic=”字段附加到目的地tel
URL的后面。有一點(diǎn)需要注意的是，CIC應(yīng)該附加到國(guó)家代碼的后面。比如在中國(guó)，“5062”就應(yīng)該是“+86-5062”。
�。�2）如果FCI參數(shù)中的“號(hào)碼已轉(zhuǎn)移”位表明已經(jīng)執(zhí)行過本地號(hào)碼轉(zhuǎn)移的操作或者IAM消息的CPN中存在有本地路由號(hào)碼，則必須在URL之后附加一個(gè)“npdi=yes”字段。同時(shí)要把此路由號(hào)碼轉(zhuǎn)換成tel
URL的形式拷貝到“rn=”字段中。如果CPN中沒有路由號(hào)碼，且IAM消息中存在有通用數(shù)字參數(shù)GDP，則對(duì)此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)會(huì)自行構(gòu)造一個(gè)只包含有網(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消息，此時(shí)網(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)答消息，同時(shí)向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)消息的映射
如果是正常的會(huì)話結(jié)束，且PSTN端先掛機(jī)，PSTN端會(huì)向MGC發(fā)送一條REL消息，網(wǎng)關(guān)依據(jù)此REL消息，向SIP端點(diǎn)發(fā)送一條BYE消息來通知SIP網(wǎng)絡(luò)另一端已掛機(jī)。假如SIP端還未接通，PSTN終端就掛機(jī)了，此時(shí)網(wǎng)關(guān)依據(jù)收到的REL消息向SIP終端發(fā)送一條CANCEL消息，告訴SIP終端取消會(huì)話。
4.5 異常響應(yīng)消息的映射
前面介紹的會(huì)話建立過程，是在假設(shè)沒有任何異常發(fā)生的情況下完成的。但是實(shí)際當(dāng)中，呼叫雙方在會(huì)話建立過程中可能出現(xiàn)這樣或那樣的問題。因此還需要考慮異常響應(yīng)消息的映射問題。比如說，網(wǎng)關(guān)連接不上URI中Contact頭字段中所指的tel
URL地址，或者說沒有匹配的ENUM，這時(shí)就要用到重定向了。
3xx類響應(yīng)消息是由重定向服務(wù)器來產(chǎn)生的。當(dāng)網(wǎng)關(guān)收到來自于SIP端口的3xx響應(yīng)消息時(shí)，即與其中的Contact頭字段中所指示的用戶聯(lián)系，同時(shí)向PSTN端口發(fā)送一條事件代碼為6的CPG消息，告訴PSTN網(wǎng)絡(luò)呼叫正在被處理。
網(wǎng)關(guān)收到4xx～6xx類響應(yīng)消息時(shí)，表明網(wǎng)關(guān)之前發(fā)送到SIP端口的INVITE消息被拒絕了。多數(shù)情況下，網(wǎng)關(guān)需要釋放它所占用的資源，并發(fā)送一條帶有原因值的REL消息給PSTN網(wǎng)絡(luò)，同時(shí)還要給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ò)的特點(diǎn)是以純IP網(wǎng)絡(luò)作為承載網(wǎng)絡(luò)，以SIP（會(huì)話初始協(xié)議）作為基本的通信協(xié)議來建立會(huì)話。而傳統(tǒng)的PSTN網(wǎng)絡(luò)采用的程控交換體系，其信令系統(tǒng)采用的是7號(hào)信令系統(tǒng)。那么就涉及到會(huì)話過程中呼叫信令的轉(zhuǎn)換問題。
本文對(duì)ISUP協(xié)議與SIP協(xié)議互通進(jìn)行了簡(jiǎn)單的介紹，并對(duì)此兩種協(xié)議在互通時(shí)的映射問題做了詳細(xì)地分析。以上僅限于理論上的分析研究，在實(shí)際應(yīng)用當(dāng)中可能還會(huì)遇到很多無法預(yù)料的問題。因此還有很多有關(guān)這兩種協(xié)議的映射問題有待于進(jìn)一步的深入探討。相信在不久的將來，隨著FMC的升溫，對(duì)于ISUP與SIP互通的研究也將會(huì)不斷的成熟與完善。
參考文獻(xiàn)
[1] IETF RFC 3398 Integrated Services Digital Network（ISDN）User Part（ISUP）to
Session Initiation Protocol（SIP）Mapping
中國(guó)聯(lián)通
相關(guān)鏈接: