IMSETSI監聽容災中幾個關鍵問題分析

黃恒基

摘要：監聽方案和容災方案往往被單獨描述和設計，而實際項目中，在監聽方案的設計和實施中要充分考慮到網絡容災方案對其的影響。文章對華為公司現有IMSETSI監聽容災方案中的幾個關鍵問題進行了分析。

關鍵詞：IMSETSI；監聽容災；容災方案

中圖分類號：TN919 文獻標識碼：A 文章編號：1009-2374（2014）09-0169-02

IMS監聽作為法定強制業務在每個商用項目中都要求部署，除東歐部分國家和國內部分運營商外，大部分國家都直接采用ETSI標準的監聽方案。同時，鑒于IMScore網絡地位的重要性，IMS容災也是大多數客戶的選擇，華為公司IMS容災方案經過IMS6.X、8.X及至最新發布的9.0，已經相當成熟。但是，根據筆者的研究理解和問題處理經驗，華為公司現有IMSETSI監聽在容災環境下存在著一些這樣那樣的限制，因此在監聽方案的設計和實施中要充分考慮到網絡容災方案對其的影響。在本文中，主要對IMSETSI監聽容災方案的幾個關鍵問題進行一些分析，以期引起讀者在項目交付和問題處理中對此給予關注和進行更深入的分析。

對單站點監聽來說，LIG面對的只有一套IMS，LIG只要和一個XPTU（XM）對接和通信即可。但在IMS容災組網下，對LIG來說不僅僅是簡單增加了一個對接對象（XPTU），因為兩套IMS不是彼此獨立，而是具有容災關系，因此必然對LIG的部署會提出新的要求，兩套IMS局的工作狀態變化也會對LIG的監聽業務帶來影響。本文從容災組網對LIG組網部署有什么要求？容災組網對XPTU上X2消息封裝會帶來什么影響？以及兩套IMS局工作狀態變化（即容災倒換）對監聽業務有什么影響？等幾個問題著手分析IMSETSI監聽容災方案的幾個關鍵技術要點。

1 容災組網對LIG部署的要求

無論采用1+1負荷分擔還是采用1+1主備容災組網，當兩套IMS局點均為正常工作狀態時，對LIG而言，可以看作兩套IMS彼此獨立在工作。

在這種組網下，當兩套IMS均正常運行時，兩套IMS獨立工作，LIG分別接收來自兩套IMS上報的監聽事件和X3通道建立請求；但兩套IMS又存在彼此容災的關系，LIG的部署需要考慮到當發生系統容災時也盡可能確保監聽業務的正常。為此，需要LIG的部署滿足至少三個要求：

一是由于LIG無法區分哪些用戶歸屬于站點A，哪些用戶歸屬于站點B，同時由于IMS容災關系，用戶的當前歸屬關系也無法確定，因此要求LIG從H1通道收到LEA下發的監聽目標操作命令后，能通過X1通道同時下發到兩個IMS站點。

二是由于兩個站點的XPTU無法進行數據同步，需要由LIG確保兩個IMS站點的監聽數據同步。因此需要LIG主動檢測兩個IMS站點的狀態，若其中一個站點故障時，則將X1命令進行本地緩存，當發現與故障IMS站點通信恢復正常后，主動重發緩存的X1消息。

三是主叫用戶注冊在站點A，被叫用戶注冊在站點B，且均為監聽目標，當A呼叫B時，A站點IMS上報用戶A的監聽（主叫），B站點上報用戶B的監聽（被叫）。

2 容災組網對XPTU上X2消息封裝的影響

我們知道，在IMS集中式監聽方案下，對基本呼叫事件（呼叫建立、應答和釋放）、用戶注冊、注銷事件，P-CSCF、S-CSCF和ATS多個網元都會上報相應監聽事件的X2消息（通過內部Y2接口），由XPTU對收到的本站點上報的相同監聽目標的同類事件進行分析和合并后只產生一條該事件的X2消息發送到LIG。當存在X3呼叫時，XPTU還要在收到CSCF和ATS上報的呼叫建立X2事件（call-establishment）后等待CCTF上報的指示X3通道建立的X2事件（x3-Channel-State），并從中提取到CIN后封裝到call-establishment中才發送到LIG。

由此可知，在集中式監聽方式下，XPTU不僅僅是個簡單的二傳手和分發單元，還是IMS監聽方案中的一個重要節點。但是XPTU在進行Y2合并和封裝時有個限制：XPTU只支持對來自與其共OMU的網元的Y2消息進行合并和處理，而無法對來自另一個站點的IMS網元的Y2消息進行合并。因此，當IMS站點發生部分網元故障的情況下，將可能導致監聽無法進行。比如，A站點的CCTF發生故障并切換到B站點后，對于A站點用戶發起的呼叫進行監聽時，A站點只能收到來自A站點的CSCF和ATS上報的呼叫建立Y2事件，而無法收到該站點CCTF上報的Y2事件，從而A站點XPTU因為無法獲取到CIN而無法完成Y2消息合并封裝為X2消息發送給LIG；另一方面，站點B收到本站點CCTF上報的Y2消息后因為無法識別而丟棄。在這種情況下，對用戶進行的呼叫監聽將因為X2消息封裝失敗而無法進行。

3 容災倒換對監聽業務的影響

上述對容災組網下X2消息封裝的描述中已經提到，部分容災場景下，由于X2消息封裝受到影響從而導致監聽業務無法進行。這里，將容災倒換的幾種典型場景對IMSETSI監聽業務的影響進行分析歸納。由于監聽方案只涉及IMS中CSCF、ATS、CCTF（含IGW）及OMU（XPTU）網元，因此下述IMS倒換或者倒回描述中僅指這幾個

網元。

3.1 集中式監聽方式下容災倒換對監聽業務的影響

（1）容災倒換過程中對監聽業務的影響。根據IMS容災原理，容災倒換（整個站點或者部分網元倒換）過程中，所有正在進行中的呼叫或者正在建立中的呼叫將全部中斷（根據具體網元情況和業務情況，立即中斷或者等待定時器超時后中斷），因此監聽業務也將隨之受到影響。

（2）容災倒換完成后對監聽業務的影響。整改IMS站點發生故障倒換后，該站點所有業務將被其容災站點接管，所有新發起的呼叫或者業務將在容災站點正在進行，監聽業務也將正常進行。如果整個CSCF發生故障切換到容災局點，SBC或者MGCF檢測到CSCF故障后將注冊和呼叫路由到容災CSCF。這種情況下和整個IMS站點發生故障倒換一樣，新發起的呼叫、業務及其監聽將在容災IMS局點上正常進行。

3.2 分布式監聽方式下容災倒換對監聽業務的影響

分布式監聽方式下，由于XPTU無需進行X2消息封裝，LIG將處理來自兩個XPTU的X2消息，并進行分析和合并。在這種情況下，只當IMS容災發生過程中，由于故障IMS站點上所有正在進行或者正在發起建立的呼叫和業務均被中斷，監聽也無法進行；除此之外，容災倒換完成后，無論是整個IMS站點發生倒換還是部分網元（XPTU本身發生故障除外，XPTU故障后該站點與LIG的X1、X2通道中斷，監聽無法進行，但原有已經建立的X3通道不受影響）發生故障倒換，在倒換后新發起的業務監聽均能正常進行。

4 結語

IMS容災組網環境下，如果采用集中式監聽，在某些容災場景下將導致監聽業務無法正常進行，但方案成熟，且對LIG要求低，同時考慮到故障容災的發生畢竟屬于小概率時間，因此網上大量應用。而采用分布式監聽可以避免集中式監聽方案的缺點，但分布式監聽可能涉及LIG的定制開發，要考慮廠家的因素。因此，在進行監聽方案設計時要根據項目情況充分考慮并權衡。endprint