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