南京MSC Pool内被叫LAU过程与寻呼流程冲突导致未接通.doc

名称：南京MSC Pool内被叫LAU过程与寻呼流程冲突导致未接通*问题描述9月14号早忙时网格3测试，主叫占用大行宫会所-1小区起呼，PCCPCH RSCP=70dBm，PCCPCH C/I=18，在10：25：11主叫发CALL PROCEEDING，这时被叫在做位置区更新。在10：25：19被叫收到寻呼消息，并发起RRC连接，响应寻呼，进行鉴权、加密和TMSI重分配，被叫完成TMSI重分配后，核心网没有进行RAB指配，而是释放了连接，专用资源没有建立，导致未接通。主叫信令截图被叫信令截图问题分析分析后台trace跟踪，被叫终端在TMSI重分配后，MSC直接释放IU RELEASE COMMAND，cause是：normal release，如下图所示：通过以上分析，需要核心网协助分析定位。核心网经过核查确定个别MSC调整后恢复为默认值：IMSI寻呼，导致出现核心网异常拆链造成未接通问题，核心网已完成核查并修改为TMSI寻呼，详细原因和案例如下。问题原因一、问题发现POOL入网后全网位置更新原因引起的未接通有明显改善，但在最近测试中发现在POOL交换机内依然存在被叫做位置更新时导致的未接通现象。测试环境：华夏银行1（BSC20-1，GS19）吉兆花园2（BSC19-2,GS49/GS48）。在12月11日晚上的测试看，87次人工测试中出现了3次，几次这种状况表现出来信令一致。从交换软件看到的A口部分流程是：被叫在位置更新时收到paging消息，在2次或3次paging后（每次paging5秒钟间隔），收到了手机上发的paging response消息。然后有正常呼叫的鉴权、身份请求、重分配等流程，但在tmsi重分配后立即下发clear command（call control）消息，CAUSE为：Call Control。空口测试的及详细的交换机信令（包括E口等）如下： 12月13日：使用华为HLR归属的SIM卡，做的测试结果和以往一致；12月14日，使用华为HLR归属的SIM卡，且HLR侧已经跟踪到对应信令，从A口上测试结果和以往一致。二、问题现象描述通过网优测试人员在MSC POOL覆盖区内的NJBSC19_2下进行反复测试发现，当被叫用户在进行局内位置更新的同时做被叫时，如果第一次寻呼无响应，而第二次寻呼响应后可能会出现位置更新完成后被叫无法接通的问题，该问题在相邻覆盖区的BSC下未曾发生。三、问题分析以其中一例失败呼叫作为样例进行分析，被叫用户登记在MSC POOL内的交换机NJGS47上，信令跟踪消息显示，被叫用户的局内位置更新流程与被叫流程发生了碰撞，前期针对寻呼与被叫冲突进行了优化，即交换机打开寻呼优化软参（软参P1100BIT1），优化流程为“先完成位置更新，后进行被叫寻呼”，从而可提升寻呼成功率。12日网优测试发现存在交换机在用户完成位置更新与寻呼过程中存在无法接通问题，现象为在被叫流程与寻呼冲突的情况下（被叫在该寻呼前正在进行位置更新见附件中位置更新接受后20：27：50sTMSI重分配完成后下寻呼），交换机向被叫发起了第一次寻呼，但此次寻呼被叫未响应，按照寻呼策略，五秒后，交换机第二次下发了寻呼消息。但就在交换机下发第二次寻呼后的两秒，即20:27:57秒，NJGS47收到了被叫HLR发来的CANCEL LOCATION消息， 清除用户数据，但未收到寻呼响应消息。此时NJGS85的信令跟踪消息中，NJGS85于20:27:55秒收到了NJGS47对该用户下发寻呼的寻呼响应消息，而NJGS85的VLR中并无该用户的数据，因此NJGS85向被叫HLR发起了被叫数据恢复（即隐式位置更新），于20:27:57完成了位置更新。NJGS85位置更新过程，HLR向NJGS47发送CANCEL LOCATION消息，此时拆除本次的寻呼冲突呼叫。经过深入分析发现，NJBSC19_2以双接入NJGM20/NJGM21这两个MGW,被叫的寻呼响应消息会负荷分担送至两个MGW。MGW此时处理的流程如下：1、BSC单接入或双接入MGW针对TMSI寻呼流程相同。如果寻呼以TMSI下发寻呼，寻呼响应消息送到MGW，MGW根据TMSI消息解析TMSI内部的NRI值，从而将该寻呼响应消息送到下发寻呼消息的MSS处理。2、 BSC单接入MGW时，当MSS以IMSI寻呼被叫时，MGW将临时存储IMSI与发寻呼的MSS的对应关系，当被寻呼的MS以IMSI寻呼响应网络时，MGW根据临时存储的IMSI与MSS的对应关系，将寻呼响应被发送回发寻呼的MSS，保证呼叫成功；3、 BSC双接入MGW时，当MSS通过其中一个MGW以IMSI寻呼被叫时，该MGW将临时存储IMSI与发寻呼的MSS的对应关系，同时MSS将通过广播消息将IMSI与发寻呼的MSS的对应关系告知另一个MGW,因此当被寻呼的MS以IMSI寻呼响应网络时，BSC将寻呼响应消息发送给双接的MGW中的任一个，MGW均可以根据临时存储的IMSI与MSS的对应关系，将寻呼响应被发送回发寻呼的MSS，保证呼叫成功。从上述两局的信令跟踪消息看出，NJGS47在向被叫用户发送了第二次寻呼消息后，BSC的发送的被叫的寻呼响应消息负荷分担送入到MGW，按照正常流程，MGW会根据MSS广播的信息将寻呼响应消息送至NJGS47处理，而此时却送至NJGS85进行处理，NJGS85没有改用户数据，重新向HLR发起位置更新，HLR同时向NJGS47发送CANCEL LOCANTION消息，从而拆除本次被叫。为何被叫用户的寻呼响应消息送到MGW将该消息地发送到NJGS85？经过和厂家研发的共同定位，问题结论如下：NJBSC19_2以双接方式同时和NJGM20/NJGM21这两个MGW相连，NJGS47的寻呼策略为第一次寻呼使用TMSI，第二/三次寻呼使用IMSI，对被叫用户的寻呼消息通过NJGM20下发给被叫归属的BSC，由于第一次寻呼下发后，被叫用户未响应，交换机下发了第二次寻呼（以IMSI进行寻呼），被叫用户以IMSI进行了寻呼响应，该响应被BSC发送至NJGM21进行处理。由于此时启动了寻呼冲突优化同能，位置更新完成后，悬置的寻呼消息经过NJGM20下发，该MGW记录IMSI与MSS的关系，而MSS此时不再向NJGM21下发IMSI与MSS关联的广播消息，NJGM21会选择POOL内任意SERVER，导致本次寻呼场景下的寻呼冲突优化功能失效。结论：在寻呼冲突的优化功能打开后，在以IMSI寻呼冲突场景下，寻呼优化功能失效，即不能对该寻呼场景的寻呼冲突进行优化，从而拆除被叫流程。计划2011年华为公司针对该寻呼冲突场景下发布优化补丁完善以IMSI寻呼冲突优化功能。当同时满足以下场景条件时，以IMSI寻呼冲突功能失效：1. BSC通过双接方式连接POOL内的媒体网关2. 被叫用户的位置更新流程与被叫流程发生碰撞，即寻呼冲突3. 启动寻呼冲突优化功能：呼叫碰撞优化软参P1100的Bit1被设置为0（即启用碰撞发生时先完成位置更新后向被叫用户下寻呼的功能）4. 交换机向被叫用户下寻呼消息时，使用IMSI进行寻呼本次寻呼冲突功能失效完全符合上述触发条件。 四、问题规避措施该问题可通过如下两种方法进行规避：1.关闭呼叫碰撞优化软参，将P1100 bit1设置为1，会造成呼叫碰撞引起的被叫未接通（即被叫位置更新时做被叫，交换机将直接回复失败消息，在一定程度上影响接通率）。2.修改POOL内所有MSC的寻呼策略，将其调整为三次寻呼全部使用TMSI进行寻呼，此种方法可直接规避用IMSI进行寻呼的场景。 五、方案验证效果经过与省网优沟通，推荐采用建议二。12月13日20：00修改POOL内MSS寻呼策略由原来的第一次TMSI寻呼、第二次IMSI寻呼、第三次IMSI寻呼修改为第一/二/三次寻呼全部使用TMSI进行寻呼以规避IMSI寻呼冲突优化失效问题的发生。省网优路测人员