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