《A接口信令过程深度挖掘分析软件》由会员分享，可在线阅读，更多相关《A接口信令过程深度挖掘分析软件（8页珍藏版）》请在金锄头文库上搜索。
1、1成果上报申请书成果名称 A 接口海量信令过程深度挖掘分析软件成果申报单位 北京移动成果承担部门/分公司北京移动网络运行支撑中心项目负责人姓名 项目负责人联系电话和 Email成果专业类别* 核心网成果研究类别* 相关网络解决方案省内评审结果*关键词索引（35 个） 信令分析、A 接口信令应用投资 0 万元（指别的省引入应用大致需要的投资金额）产品版权归属单位 中国移动北京公司对企业现有标准规范的符合度： （按填写说明 4）目前没有相关软件产品，属自主开发的信令数据分析工具软件。成果简介：简要描述成果目的和意义，解决的问题，取得的社会和经济效益。A 接口含有丰富的信令消息，优化人员通过深入分析
2、 A 接口的海量信令流程可以对网络做出客观的评价。 得出如下统计样本数据：时延分析：位置更新时延、切换时延、短信时延，TCH 指派时延、呼叫端到端接续时延、寻呼时延等。呼损分析：呼损原因值分布、呼损与小区的关系、掉话事件与短信下发事件之间的关系。业务量统计：位置更新事件、短信事件、呼叫事件，寻呼事件、切换事件等等。异常事件分析：定时器超时事件分析，如 T305,T308 定时器超时事件排查；信道清除过程异常（如 MSC下发 CLEAR COMMAND 消息后，BSC 没有响应，MSC 再次下发 CLEAR COMMAND 清除资源） ；A 接口电路二次指派事件分析（MSC 第一次下发 ASSI
3、GNMENT REQUEST,BSC 回 ASSIGNMENT FAILURE , 然后 MSC 再次下发 ASSIGNMENT REQUEST 请求重新分配信道。 ） 、TCH 指派失败事件分析（MSC 下发 ASSIGNMENT REQUEST,BSC 回 ASSIGNMENT FAILURE） 、掉话消息出现点分析，如 CLEAR REQUEST 消息在 DISCONNECT 之后出现的次数统计等等。现有的大多数信令分析仪表主要功能在消息解码方面功能强大，但对于海量信令消息的消息过程分析及特定消息序列查询功能支持程度较弱。例如，查询 CLEAR REQUEST 消息出现在 DISCONN
4、ECT 消息之后的事件过程，查询 RELEASE 重发过程，查询消息流程中出3现 2 次 CLEAR COMMAND 消息过程，查询 ASSIGNMENT 消息到 ASSIGNMENT COMPLETE 消息时延大于 500 毫秒的消息过程等等一些特定消息过程的查询功能，信令仪表基本无法满足优化人员的分析需求。另外，针对现网信令监测系统提供的一些统计数值，如短信量统计、寻呼量统计，切换统计，由于没有有效验证手段难以验证其准确性。针对上述问题，我们独立开发了一套海量信令过程分析软件，本软件的功能是用户通过信令仪表采集数据，或是通过信令监测系统采集数据，然后将原始信令消息按指定的消息字段导出为纯文
5、本文件，消息的关联不再由信仪表处理，而是通过本软件将海量的原始消息关键字段写入到数据库，并进行消息关联处理，最终在数据库中生成海量的信令事件过程。由于信令数据库是开放的，而且主要的信令消息字段已经存储在数据库中，如 Cause value, 消息名称、主、被叫号码等等，所以优化人员可以通过数据库方式进行灵活的查询和统计分析，常规的信令仪表由于其后台的信令数据存储格式和处理算法对我们普通用户不开放，所以我们很多的查询和统计功能需求信令仪表无法满足！现在我们通过本软件已经将信令许多关键字段存储到了数据库中，这为我们很多的特定查询分析需求提供了可能性。因此本软件的最大优点在于它给用户提供了一个开放信
6、令数据平台信令消息数据库，在它的基础上网络优化人员还可以根据自己的实际分析需求设计不同的 SQL 查询，最终完成个性化的分析目标。目前，已经实现的查询功能如下：时延分析：TCH 指派时延分析；呼叫时延分析；位置更新时延分析；呼损分析：原因值分布呈现：clear request 消息 cause value 分布,disconnect 消息 cause value 分布, release 消息 cause value 分布，LU reject 消息 cause value 分布, handover failure 消息 cause value 分布等等，所有有失败原因值消息的原因值分布。掉话事件
7、场景分析：呈现与 CLEAR REQUEST 掉话消息相关的信息：如 CLEAR REQUEST 消息之前的消息是什么？CLEAR REQUEST 消息之前用户是否挂机，此掉话事件是否有短信业务伴随，此掉话消息与前一条相邻消息之间的时间间隔是多少，掉话的小区信息，掉话的事件类型（LU，VOICE,SMS） ，掉话是否有切换操作存在等。异常流程查询功能：信令流程中 RELEASE，CLEAR COMMAND 重发的过程查询。TCH 指派时延大于 N 毫秒过程查询.位置更新过程大于 N 毫米过程查询。4实际应用效果：本软件在 2010 年 7 月集团公司在北京开展的“网络质量竞赛试点项目”中得到了
8、实际应用。通过本软件分析完成了对中创信令监测系统的数据完整性验证工作，发现中创系统对于位置更新过程中的短信事件是无法统计的，中创公司对此问题已经确认存在，并反馈下一版本可以解决此问题。另外，应用本软件对部分 BSC 的 A 接口信令进行了深入分析。相关指标有时延分析、呼损分析、异常流程分析。其间定位了一些异常问题：A.NOKIA MSC 给 MOTOROLA BSC 发消息，MOTOROLA BSC 没有响应引发 MSC 侧定时器超时现象出现 1653 号告警 THE A-INTERFACE BSSMAP-LEVEL TIMER EXPIRY。B.部分小区的被叫接续时延较长,最终定位无线接口存
9、在问题。C.个别小区存在 TCH 指派排队现象严重。D.部分小区掉话率较高。E.核心网异常下发 DISCONNECT 消息。省内试运行效果：描述成果引入后在本省试运行方案、取得的效果、推广价值和建议等。本软件在集团公司开展的“网络质量竞赛试点项目”中得到了实际应用。通过本软件分析完成了对中创信令监测系统的数据完整性验证工作，发现中创系统对于位置更新过程中的短信事件是无法统计的，中创公司对此问题确认，并反馈下一版本可以解决此问题。另外，应用本软件对部分 BSC 的 A 接口信令进行了深入分析。相关指标有时延分析、呼损分析、异常流程分析。其间定位了一些异常问题：A.NOKIA MSC 给 MOTO
10、ROLA BSC 发消息，MOTOROLA BSC 没有响应引发 MSC 侧定时器超时现象出现 1653 号告警 THE A-INTERFACE BSSMAP-LEVEL TIMER EXPIRY。B.部分小区的被叫接续时延较长,最终定位无线接口存在问题。C.个别小区存在 TCH 指派排队现象严重。D.部分小区掉话率较高。E.核心网异常下发 DISCONNECT 消息。本软件的优势在于它可以辅助优化人员进行海量 A 接口信令过程分析，从信令层面客观深入的挖掘网络中存在的问题，开放的信令消息数据库为我们多维度地分析信令数据提供了有力的手段，优化人员可以在此基础上进行二次开发。海量信令过程分析对于
11、网络优化，故障处理应用方面较为实用，且目前的许多信令分析仪表不具备海量信令过程分析功能，本软件由北京移动员工独立开发，没有软件费用，且软件在普通配置的 PC 上即可运行，不需要另购硬件设备，因此对于引入省分的成本为零，建议引入。7文章主体（3000 字以上，可附在表格后）：根据成果研究类别，主体内容的要求有差异，具体要求见表格后的“填写说明 5”。 背景情况参见 “成果简介”部分内容。 技术方案：概述、网络解决方案（如果涉及到网络方面的改造，信令改造，路由改造等，应有详细的描述） 、设备及系统改造/建设要求、码号资源需求用仪表采集信令，将原始消息以文本文件格式导出，提取部分关键字段，需要导出的
12、字段信息如下：时间 19:32:22,272,511OPC 3F2hDPC 3F8hFrom 2-BSSMAP-AMSG ID AUTREQDLR 5801413SLR -1LAC CI IMSI TMSI IMEI Calling_number Called_number Cause Len 37SERVICE_TYPE 其中：DLR(Destination Local Reference)和 SLR(Source Local Reference) 是 SCCP 层连接号，用于实现消息之间的关联。MSG ID：最高层消息名称，如 LU Request, CP-DATA, SETUP.等等。F
13、rom: 表示消息来自哪个链路。Len: 表示消息长度。SERVICE_TYPE:表示 CM service request 业务请求类型，如位置更新、短信、语音呼叫。导出的消息样本示例如下：Long Time;OPC;DPC;From;Last MSG;DLR;SLR;LAC;CI;IMSI;TMSI;Identity digits;Calling party number;Called Party;Cause Value;Len;CM Service type;19:32:21,503,906;3F2h;3F8h;2-BSSMAP-A;AUTREQ;5702277; 37;19:32:21
14、,506,390;3F8h;3F2h;0-BSSMAP-A;Alert;5046301; 18;19:32:21,506,752;3F8h;3F2h;0-BSSMAP-A;LU Request;5064910; 28;819:32:21,507,051;3F2h;3F8h;2-BSSMAP-A;PAGIN;460023102134385; 40;19:32:21,507,888;3F2h;3F8h;2-BSSMAP-A;CP-ACK;5718540; 20;19:32:21,513,768;3F2h;3F8h;2-BSSMAP-A;CP-DATA;5718226; 23;19:32:21,51
15、6,047;3F8h;3F2h;0-BSSMAP-A;SETUP;5112571; 20;19:32:21,519,148;3F2h;3F8h;2-BSSMAP-A;CLASSMARK UPDATE;5734950; 37;19:32:21,519,766;3F8h;3F2h;0-BSSMAP-A;Handover command;4998226; 20;19:32:21,523,749;3F2h;3F8h;2-BSSMAP-A;Paging;5752960; 25;19:32:21,525,922;3F8h;3F2h;0-BSSMAP-A;PRES;5800967;4239;21243;46
16、0021284219017; 57;创建后台存储信令的数据库：为了实现消息之间的关联，在信令数据库中增加一些辅助字段：time_id 70342272511msg_num 411session_id 25RLC 0DETACH 0Time_id 用于存储消息的时间戳信息，精确到 10 万分之 1 毫秒。Msg_num：用于存储消息序号Session_id:用于存储信令事件号，同一信令事件过程中的所有消息的 session_id 号码相同。RLC:表示当前消息是不是 “RLC”消息。DETACH: 表示当前消息是不是 “DETACH”消息。将信令记录导入到后台数据库，应用程序算法处理消息将海量消
