A口用户感知系统案例汇总.doc

A口用户感知系统案例目录1应用用户感知软件解决TCH掉话问题22ZHEG97被叫无法响应案例分析43打不出去电话问题处理54通过信令分析三角切换问题65通过信令分析掉话问题76接入失败录音通知异常的问题处理97部分SIM卡不能被寻呼的问题解决118通过信令分析小区SDCCH高掉话问题131 应用用户感知软件解决TCH掉话问题2009年11月3日，用户460001453105547(IMSI号)在晚上18：00至20：00发生掉话。提取该用户感知系统A口信令，用户发生掉话信令如下：从上面信令可以看到该用户进行跨BSC切换后产生掉话，根据信令跟踪的小区号可以看到该用户从ZHEA12C（移动公司C小区）切换到了BSC13的zhea69b(河西实验中学)如下：两个小区的位置如下图：可以发现这两个小区相距2944m，跨越多个小区进行切换，再切换回移动公司微蜂窝（zhea40O）用户一次呼叫重建失败，三次呼叫拒绝，第四次才建立成功，信令如下：根据用户信令分析，移动公司微蜂窝和周围临近小区进行切换没有任何问题，因此怀疑在用户切出到较远的zhea69b后掉话，然后在移动公司微蜂窝重建及呼叫在短时间内网络进行了拒绝，应为切换产生问题。解决方案：结合MCOM地理位置，删除这两个小区的邻区关系避免这种因为过远切换失败造成掉话。2 ZHEG97被叫无法响应案例分析ZHEG97为通辽BSC9的新建站，但新建站启动后，有用户多次投诉只能打电话，却不能接电话，发生只能主叫，不能被叫的问题。首先，怀疑新建基站小区的基础数据以及参数设置有问题，但经过检查并无问题，从用户感知系统中提取了一个投诉用户的信令，发现该用户作为被叫时，只有一条下发的寻呼消息，并无寻呼响应，如下图：因此怀疑交换侧定义的小区CGI和BSC侧定义的小区CGI不符，导致寻呼不到接入到该小区的用户，但经反复核查发现交换侧定义的小区CGI和BSC侧定义的小区CGI相符，没有问题，因为该小区属于BSC9，因此查看BSC9的其他小区的T3212等会影响到寻呼的数据，发现其他小区的LAC号为18260，而新建站小区的LAC号为18266，此LAC号此前只有BSC5的小区使用，虽然这两个BSC同属于华为软交换，两个LAC号的小区用户该软交换都会进行寻呼，但在华为软交换侧会将BSC和固定的LAC号进行绑定寻呼，因此怀疑在交换侧并未将LAC号18266与BSC9进行绑定，因此不能对新建站小区的接入用户进行寻呼。解决方案：修改LAC号为18260后，经用户核实，被叫正常。3 打不出去电话问题处理7月31日下午15点，有通辽用户投诉在移动大楼发生了几次主叫失败。以往针对此类投诉，一般通过对用户描述的大致区域的小区性能进行检查，查找问题手段单一，定位问题相对困难。通过用户感知评估系统的信令追踪，可以查找对应IMSI的信令情况，帮助定位问题。如下图是当时该用户通话的信令信息，从中我们可以判断出主叫失败是因为切入目标小区失败后释放信道所致。而该目标小区是一个移动大楼里面的测试微蜂窝，一般情况下都没有开启。关闭该微蜂窝后，问题解决。TLTEST3外部小区数据定义错误4 通过信令分析三角切换问题用映在通辽市平安西区牛仔酷KTV，8月14日21：35分时拨听到另一个用户的声音，大约持续一分钟左右。 从现象上看，该用户在ZHEA01A,ZHEA45C,ZHEA37A，ZHEA19B附近区域发生频繁切换(每隔5秒左右发生一次切换，共15次)，可能是造成这种现象的原因。检查相应小区的参数设置 ，发现小区ZHEA01A与ZHEA01C, ZHEA01A与ZHEA19B的KOFFSETN=KHYST=3,这在Locating运算时很容易在某些三角区域发生旋转木马式频繁切换，对KOFFSET参数进行重新设置。 5 接入失败录音通知异常的问题处理09-7-2日上午9：209：30分左右，在通辽连续拔打同一呼市号码两次都没有接通，没有任何提示直接返回待机状态。在用户感知评估系统里通过输入用户的电话号码，在通辽全网BSC对该用户当天9:00-10:00的信令进行了追踪，主叫用户在分配完TCH信道后，一直等待被叫的ALERTING 振铃消息,但一直没有收到被叫方向发来的振铃，等待超时后，进行了拆链释放清除流程，回到了空闲。也就是主叫用户的投诉的：没有听到任何声音，直接返回到空闲状态。主叫信令流程来看，主要还是由于没有收到被叫的ALERTING 消息导致了这通话异常.l 分析定位通辽用户拨打呼市通话状态用户，和用户投诉状态一致:没有提示音而自动返回待机状态。通辽用户拨打兴安盟和海拉尔占用状态用户，提示对方正忙的录音通知正常。定位成呼和浩特侧问题。l 处理方案将用户投诉描述，分析数据以及拨打测试结果提交给呼市交换优化，交换工程师检查发现是交换侧出局路由丢失。交换工程师对此进行了路由数据调整。l 结果跟踪 现场复测，拨打呼市占线用户能听到用户忙的录音通知，正常。6 部分SIM卡不能被寻呼的问题解决目前支持手机消费的SIM卡在通辽开始试用，经常有更换该卡的用户对该卡性能进行投诉。投诉内容主要为该卡用户被叫异常。根据用户投诉现象进行细致分析,该问题可能原因有如下几点： 无线环境问题 寻呼拥塞 手机故障问题 SIM卡故障问题 交换的问题l 无线环境问题排查用户反映，用户大部分时间主被叫正常，被叫异常现象只是时有发生，排除无线环境问题。l 手机故障问题根据用户投诉反映，许多用户均有该类问题出现，并且投诉大致相同，排除手机故障问题。l 寻呼拥塞根据用户所在小区跟踪及话务统计，可以发现用户出现该类问题时所在小区并无拥塞现象，也无拥塞统计，排除寻呼拥塞问题。l SIM卡故障问题由于根据用户投诉信息及其他该类SIM卡用户咨询。得知该类SIM问题用户多为同一批SIM卡。因此不排除因SIM故障导致该问题出现。l 信令跟踪分析，定位出位置更新过程出现问题根据用户反映情况及某一用户信令跟踪，发现该SIM卡用户LAC更新失败造成用户寻呼无响应。根据通户信令跟踪情况分析，可以看出这个用户在位置区更新的时候有很大几率分配到错误的LAC号，但是一旦位置区更新失败后他会重试，多次重试后会有几率分配到成功的LAC，并位置区更新成功。所以这类用户在发生位置区更新请求后有一段时间会寻呼不到，但是在一个正常的环境里（即固定在某个区域不动）则不受影响。该用户信令如下：时间戳信令类型LACCI原因值2010-03-31 11:10:26.827位置更新请求(LOCATION UPDATING REQUEST)47647602010-03-31 11:10:27.061级别更新(Classmark update)47647602010-03-31 11:10:27.087位置更新拒绝(LOCATION UPDATING REJECT)476476Protocol error, unspecified2010-03-31 11:10:27.087清除命令(CLEAR COMMAND)476476Call control2010-03-31 11:15:07.115位置更新请求(LOCATION UPDATING REQUEST)182701114102010-03-31 11:15:07.219鉴权请求(Authentication Request)182701114102010-03-31 11:15:07.350级别更新(Classmark update)182701114102010-03-31 11:15:07.820鉴权响应(Authentication Response)182701114102010-03-31 11:15:07.858加密模式命令(Cipher Mode Command)182701114102010-03-31 11:15:08.302加密模式完成(Cipher mode Complete)182701114102010-03-31 11:15:08.338TMSI更新命令(TMSI Reallocation Command)182701114102010-03-31 11:15:08.765TMSI更新完成(TMSI Reallocation Complete)182701114102010-03-31 11:15:08.946位置更新接受(LOCATION UPDATING ACCEPT)182701114102010-03-31 11:15:08.946清除命令(CLEAR COMMAND)1827011141Call control根据信令可以看出用户在11：10的时候产生了一次位置区更新失败，主要原因是往LAC=476更新失败，根据规范，LAC不应该为476，而且根据通辽现场反应出来的信息没有LAC为476的LAC。l 分析排除工作小结通过上面的这些工作，可以定位到这个事件有两种可能性：1、SIM卡有问题。2、交换数据定义有误，及IMISDN GT（GLOBAL TITLE)指定错误。因此我们拟定对该类用户进行测试，测试步骤：1) 该手机做被叫，确认是否寻呼不到。经确认可以被寻呼到。2) 开启TLTEST9小区,用该手机座主动选网，做LAC变更。3) 该手机做被叫，确认是否寻呼不到。经确认可以被寻呼到。4) 该手机做主叫。可以进行寻呼。根据测试现象分析，该类手机做主动选网，已主动做跨LAC区做位置更新，并且成功，主叫被叫正常。说明该类型的S