软交换IP信令分析(二)-现网异常信令分析.ppt
Company Logo,研究数据基础,一,整体失败原因值分布,二,疑难CAUSE定位交流,三,呼叫失败案例应用分析,四,一、项目概况,Company Logo,通过采集软交换网元MC口以及SEVER至LSTP的MAP信令数据进行数据分析的数据基础。,相对于挂表采集信令的方式具有以下特点和优势：原始数据采集，不会丢失属于部分网络异常的不完整事件多接口同时采集，可进行会话关联性分析，实现对部分一直疑而未决的CAUSE进行了原因定位海量数据多时段分析，定位更准确更深入,二、整体失败原因值分布,整体失败原因值CAUSE的分布根据用户成功登记至网络，发起呼叫到振铃，接续成功后到挂机完整呼叫流程的三大部分中产生的失败原因进行分布分析研究。,Company Logo,www.themegallerycom,2.1位置更新失败原因值统计(BSSMAP),Company Logo,上表是位置更新失败原因以BSSMAP协议为基础进行统计，从上表可见在A口上失败的位置更新的主要原因是PLMN not allowed、IMSI unknown in HLR、NetWork failure等三种，这三种原因总数量占了98%以上。,Company Logo,2.1位置更新失败原因值统计(MAP),表是位置更新失败原因以MAP协议为基础进行统计，从上表可见，在MAP上位置更新失败主要都是errcode=8（Roaming not allowed）占的比重最大，达到99%以上。,2.2 MO SERVICE REQUEST-ALERTING失败原因值统计(bssmap),Company Logo,Company Logo,2.2 MO SERVICE REQUEST-ALERTING失败原因值统计(map),2.3 CONNECT-DISCONNECT失败原因值统计,Company Logo,3.2 MO SERVICE REQUEST-ALERTING（1）,下行DISCONNECT带CAUSE 41（主叫ASSIGNMENT REQUEST 后收到DISCONNECT，T8超时）CAUSE解释：Temporary failure,主叫SEVER发送IAM消息后，收到APM消息，发起ASSIGNMENT REQUEST。主叫BSC TCH分配未完成，使得主叫SEVER没能发送导通消息COT，导致被叫局T8超时。该CAUSE是由于主叫侧BSC TCH分配未完成导致的，从场景分析来看，部分事件流程中SEVER下发DISC后BSC还上行了CLEAR REQ请求释放呼叫。怀疑无线环境质差导致。用户表现为呼叫失败，无通知音。,BSC_O,SEVER_O,HLR,SEVER_T,CM SERVICE REQUEST,SETUP,CALL PROCEEDING,SRI,PRN,PRN_ack,SRI_ack,IAM,PAGING_REQ,APM,APM,ASSIGNMENT REQUEST,.省略,BSC_T,APM,PAGING_RESPONSE,SETUP,CALL CONFIRMED,REL CAUSE 41,DISCONNECT CAUSE=41,DISCONNECT CAUSE=41,CLEAR REQUEST CAUSE=0,CLEAR COMMAND,该IAM消息带有“期望COT”，启动T8计时器,15s,3.2 MO SERVICE REQUEST-ALERTING（2）,下行DISCONNECT带CAUSE 41（主叫ASSIGNMENT REQUEST 后收到DISCONNECT，T8超时）CAUSE解释：Temporary failure,BSC_O,SEVER_O,HLR,SEVER_T,CM SERVICE REQUEST,SETUP,CALL PROCEEDING,SRI,PRN,PRN_ack,SRI_ack,IAM,PAGING_REQ,APM,APM,ASSIGNMENT REQUEST,.省略,BSC_T,APM,PAGING_RESPONSE,SETUP,CALL CONFIRMED,DISCONNECT CAUSE=41,CLEAR REQUEST CAUSE=0,CLEAR COMMAND,主叫发送IAM后，在T7时间内没有收到ACM消息，故向被叫SEVER发送REL消息，并向主叫BSC下发DISCONNECT消息，携带CAUSE41。同时向被叫局发送REL带CAUSE 31指示对端释放呼叫。该CAUSE是由于被叫侧无线环境质差，引起主叫呼叫失败。用户侧表现为呼叫失败。,ASSIGNMENT complete,COT,REL CAUSE 31,DISCONNECT CAUSE=31,ASSIGNMENT。,15s,3.2 MO SERVICE REQUEST-ALERTING（3）,Company Logo,下行DISCONNECT带CAUSE 41（CALL PROCEEDING 后收到DISCONNECT，T8超时）CAUSE解释：Temporary failure,被叫局收到IAM后，在T8时间内没有收到COT消息，导致T8超时，向主叫局发送REL带CAUSE41。该场景产生的CAUSE原因是用户拨打了“3”开头的7位数电话号码，移动关口局（GZDS05、GZDS06）没有将此号码送出局导致的，属于核心网的问题。用户侧表现为拨打了“3”开头的7位数电话号码，等待一小段时间后，手机显示“网络繁忙”。,BSC_O,SEVER_O,SEVER_T,HLR,CM SERVICE REQUEST,SETUP,CALL PROCEEDING,SRI,PRN,PRN_ack,SRI_ack,IAM,REL CAUSE41,.省略,15s,DISCONNECTCAUSE41,该IAM消息带有“期望COT”，启动T8计时器,3.2 MO SERVICE REQUEST-ALERTING（4）,下行DISCONNECT带CAUSE 41（主CALL PROCEEDING 后收到DISCONNECT，SRI失败）CAUSE解释：Temporary failure,BSC_O,SEVER_O,HLR_T,CM SERVICE REQUEST,SETUP,CALL PROCEEDING,SRI,.省略,DISCONNECTCAUSE41,LSTP,.,在SRI过程中，收到L局原包转发回来的SRI带有SCCP ERROR CODE 1（No Translation for this specific address）产生该CAUSE的原因是LSTP缺少对被叫号码进行号码分析的局数据，属于核心网局数据设置问题。用户侧表现为呼叫失败，无通知音。,SRISCCP ERROR CODE 1,3.2 MO SERVICE REQUEST-ALERTING（5）,Company Logo,下行DISCONNECT带CAUSE 41（CALL PROCEEDING 后收到DISCONNECT，SRI失败）CAUSE解释：Temporary failure,BSC_O,SEVER_O,HLR,SEVER_T,CM SERVICE REQUEST,SETUP,CALL PROCEEDING,SRI,SRI_ACK ERROR CODE 34,.省略,DISCONNECT CAUSE41,PRN,CANCLE LU_ACK,PRN_ACK ERROR CODE 39,HLR收到PRN_ACK 带有ERROR CODE 39（No roaming nr available）接着HLR再向主叫MSC回复SRI_ACK带有ERROR CODE 34（System failure）主叫MSC收到SRI_ACK后，向BSC下发DISCONNECT带CAUSE41（Temporary failure）在PRN前有一条CANCEL LU消息，在出POOL至新SERVER的LU尚未完成，HLR中VLR 地址仍指向老的SERVER时，收到一个PRN消息，此时老的SERVER已经不存在该用户数据，导致回PRN_ACK，cause=39 No roaming number available,3.2 MO SERVICE REQUEST-ALERTING（6）,Company Logo,CM SERVICE REJECT带CAUSE 101CAUSE解释：Message not Compatible with the protocol state,MSC下发PAGNIG消息尚未收到响应寻呼请求前发起CM SERVICE REQUEST，或者MSC下发CP-DATA后，BSC尚未回复CP-DATA_ACK，此时用户发起CM SERVICE REQUEST，系统拒绝该MO请求,BSC_O,MSC-S_O,CM SERVICE REQUEST,CC,PAGING/CP DATA,CM SERVICE REJECTCAUSE=101,3.2 MO SERVICE REQUEST-ALERTING（6）,Company Logo,CM SERVICE REJECT带CAUSE 98CAUSE解释：Message type not compatible with the protocol state,PAGING及PAGING响应后、LU及响应后、HO及HO响应后但都未完成之前用户侧又发起了MO呼叫请求,BSC_O,MSC-S_O,CM SERVICE REQUEST,CC,PAGING/CP DATA,CM SERVICE REJECTCAUSE=101,3.2 MO SERVICE REQUEST-ALERTING（3）,Company Logo,CM SERVICE REJECT带CAUSE 17CAUSE解释：NetWork failure,该失败模型均为AUTHENTICATION REQUEST后，12秒即T3260超时后收到CM SERVICE REJECT消息释放呼叫。该CAUSE由BSC及BSC以下侧原因导致，表现为用户侧呼叫失败，无通知音直接返回待机画面。,CM SERVICE REQUEST,AUTHENTICATION REQUEST,CM SERVICE REJECTCAUSE=17,12S,BSC_O,SEVER_O,Company Logo,3.2 MO SERVICE REQUEST-ALERTING（8）,SRI带ERRCODE 1CAUSE解释：nknown subscriber该ERRCODE 1的失败原因是在HLR没有该被叫用户信息导致，该被叫用户号码为没有使用号码。属用户行为原因。,SRI带ERRCODE 11CAUSE解释：Teleservice not provisioned该ERRCODE 11的失败原因是由于被叫用户不支持话音呼叫功能而产生。该问题属用户行为。,SRI带ERRCODE 13CAUSE解释：call barred 这种ERRCODE=13是被叫用户某种服务受限，如号码暂停使用，欠费等导致的正常情况。属用户行为原因。,Company Logo,3.2 MO SERVICE REQUEST-ALERTING（9）,SRI带ERRCODE 14CAUSE解释：Forwarding violation产生该ERRCODE 11的原因是由于用户设置了二次呼转，而在现网中并不允许进行二次呼转。该问题与用户行为相关。,SRI带ERRCODE 34CAUSE解释：SYSTEM FAILURE这种ERRCODE=34的失败原因之一为该被叫用户在做位置更新到另外一个LAC,且HLR向PVLR进行“取消位置”操作时，同时收到HLR发的PRN导致。与用户行为相关。,SRI带ERRCODE 39CAUSE解释：o roaming nr available该ERRCODE=39的失败原因为该用户在做位置更新到另外一个LAC时,且HLR向PVLR进行“取消位置”操作时，同时收到PRN_REQ导致。与用户行为相关。,3.3 CONNECTDISCONNECT(1),Company Logo,Clear Request消息带cause=0CAUSE解释：Radio interface message failureClear Request是一条单向的上行消息，在呼叫过程的任何时刻，均可由BSC上发，请求SERVER释放呼叫，其带有的cause均是反映了BSC及以下侧端口的问题,Clear Request消息带cause=32CAUSE解释：Equipment failureClear Request是一条单向的上行消息，在呼叫过程的任何时刻，均可由BSC上发，请求SERVER释放呼叫，其带有的cause均是反映了BSC及以下侧端口的问题,Company Logo,下行Disconnect消息带cause=21CAUSE解释：Call rejected在用户通话正常通话过程中，其中一方用户出现资费不足，SCP指示SERVER释放呼叫。属于用户行为，为不可控原因，在用户侧表现为呼叫掉话。,3.3 CONNECTDISCONNECT(9),下行Disconnect消息带cause=27CAUSE解释：Destination out of order在通话过程中，手机自然断电后，server（华为）通过BICC端口，向对端server发送REL消息释放呼叫，其原因值是27。同类情况，爱立信释放CAUSE为31。,Company Logo,HANDOVER FAILURE带CAUSE=8CAUSE解释：Response to MSC invocationCAUSE 8的切换失败原因是在切换未完成前用户先挂机而导致的切换失败，该问题属于用户行为。,3.3 CONNECTDISCONNECT(10),下行Disconnect消息带cause=96CAUSE解释：Invalid mandatory information具有呼叫等待功能的用户，在释放原呼叫的时候，刚好有新的呼叫准备接入。SERVER在未完成释放原呼叫的时候，下行setup消息，接入新的呼叫，但是由于BSC侧已经释放了原来的呼叫，因此，BSC上行的CALL CONFIRMED消息中未带有下行setup消息所期望的Cause参数，故server认为信令缺少了必要字段，因此释放呼叫。,四、呼叫失败案例应用分析,Company Logo,无通知音，未接通直接返回待机画面会话类型为MO呼叫会话中不包含“alerting“及”CONNECT“信令消息会话中不包含“CM SERVICE ABORT“用户侧中断会话中不包含”DISCONNECT”带CAUSE 16/31（用户侧释放、正常释放）会话中不包含“CLEAR COMMAND”带CAUSE 11(切换成功)会话中不包含“PROGRESS”带IN BANK INFORMATION(语音播放标识),信令过滤原则,首次拨打未接通，再次拨打接通会话类型为MO呼叫首次MO没有”ALERTING”或者“CONNECT”信令就释放了，且非用户侧上行的DISCONNET正常挂机释放。在5分钟内有再次发起MO且MO会话包含有”ALERTING”信令当首次MO信令流程中能获取到CALLINGNUM和CALLEDNUM的，二次MO根据主被叫号码匹配当首次MO信令流程中只能获取到CALLINGNUM但未能获取到CALLEDNUM的，二次呼叫根据主叫号码匹配,四、呼叫失败案例应用分析,数据分析基础：通过信令搭接采集所得的信令数据数据分析节点：GZS01(归属POOL3，覆盖天河)GZS15(归属POOL1,覆盖海心沙)GZS16（归属POOL5，覆盖亚运村）数据分析时间段：,原因属性描述：根据各信令场景的原因定位进行原因属性划分对于已定位原因可划分为：“BSC以下侧原因”、“BSC以上侧原因”、“对端节点及MS原因”、“用户行为相关”对于一些偶发性事件或者需要根据实际分析才能定位的事件，归类到“综合原因”,分析数据基础,四、呼叫失败案例应用分析,无通知音，直接返回待机画面,首次呼叫失败，再次拨打接通,用户行为相关的原因部分占比明显下降，下降原因主要为:CM Service Reject_101，用户正在被寻呼、位置更新、收短信等操作中而又还没有回应时，用户发起呼叫。,“BSC及BSC以下级”及需要根据实际定位的“综合原因”有一定的上升，上升原因主要分别为Assignment Failure_33，无可用无线资源，Disconnect_34，无电路或信道可用。,整体原因属性分布,四、呼叫失败案例应用分析,无通知音，直接返回待机画面,首次呼叫失败，再次拨打接通,用户行为相关的原因部分占比明显下降，下降原因主要为:Release Complte_57，用户请求的功能与网络功能不匹配。如被叫用户不支持语音业务时会呼叫失败。,“BSC及BSC以下级”及需要根据实际定位的“综合原因”有一定的上升，上升原因主要分别为Assignment Failure_33，无可用无线资源，Disconnect_34，无电路或信道可用。,整体原因属性分布,四、呼叫失败案例应用分析,无通知音，直接返回待机画面,首次呼叫失败，再次拨打接通,“BSC及BSC以下级”的原因部分数量明显下降，下降原因主要为:Assignment Failure_33，没有可用的无线资源,“用户行为相关”及需要根据实际定位的“综合原因”有一定的上升，上升原因主要分别为CM Service Reject_101，用户正在被寻呼、位置更新、收短信等操作中而又还没有回应时，用户发起呼叫；Release Complte_50，用户调用的功能在现行网络中不被允许。Disconnect_41，网路临时故障。,整体原因属性分布,三、呼叫失败投诉案例定位,无通知音，直接返回待机画面,首次呼叫失败，再次拨打接通,TOP 10原因占比,三、呼叫失败投诉案例定位,已定位导致两投诉案例的“BSC以上侧原因”包括：,Disconnect带CAUSE 42 交换设备拥塞,Assignment Failure带CAUSE 80 陆路电路已经分配,Disconnect带CUASE 41 网路临时错误，STP未正确指向导致SRI查询失败部分,从上表统计数据可以看出，能明确为BSC以上级的原因均为一些临时性的资源拥塞或者偶发事件。,三、呼叫失败投诉案例定位,投诉案例影响度分析,无通知音，直接返回待机画面,首次呼叫失败，再次拨打接通,三、呼叫失败投诉案例定位,小结：整体原因属性分布中，较早前数据与近期数据对比GZS01、GZS15由于用户行为相关的部分有明显下降，但与无线环境及无线资源相关的部分事件数有上升。GZS16无线环境及无线资源相关的事件有所减少，但Disconnect_41，网路临时故障有所增加。TOP10原因中占整体原因85%以上。除用户行为相关及对端原因外，其余部分几乎均与无线资源及无线环境相关。根据信令评估，每一千个拨打电话的用户中就会有十几个用户会出现”无通知音，拨打电话后直接弹回待机画面的未接通现象”，24个用户会出现“首次拨打未接通，再次拨打接通”。重点原因包括网络接续与用户行为之间的冲突、BSC及BSC以下侧的原因占了80%以上。能明确为BSC以上级的原因均为一些临时性的拥塞或者偶发事件，优化具有一定难度。从BSC以及BSC以下侧优化的空间相对较大。,主叫接入呼叫时延细化分析,四、时延信令应用分析,被叫业务信道分配和响铃的时间,包括了被叫寻呼鉴权的时间,鉴权时延,业务信道分配,被叫接入呼叫时延细化分析,四、时延信令应用分析,信道分配时延,鉴权时延,寻呼响应时延,包含了主叫侧的信道分配时延,2G及3G位置更新时延分析,四、时延信令应用分析,从上表可以看出，2G的位置更新时间消耗均值相对比较稳定，3G的位置更新时间消耗波动性较大，特别是NOR_LU的时间消耗。经信令回溯分析发现发送请求IMEI信息后，12S内没有收到MS返回IMEI信息，不进行IMEI CHECK直接位置更新成功。建议减少T3270（IDENTIFY RESPONSE计时器）的值，优化位置更新的时延。,Thank You!,
