核心网数据分析支撑需求说明.docx
《核心网数据分析支撑需求说明.docx》由会员分享,可在线阅读,更多相关《核心网数据分析支撑需求说明.docx(17页珍藏版)》请在冰豆网上搜索。
核心网数据分析支撑需求说明
核心网数据分析支撑
需求说明
1项目解决方案
1.1综述
1.1.1背景
随着市场竞争的不断加剧,网络质量成为增强竞争力的关键因素。
为了全面衡量网络质量水平,感知网络运行的变化情况,有必要完善移动网络质量管理,分析网络指标,有针对性地开展维护与优化工作,保持网络质量上的领先优势。
核心网是移动网络的重要组成部分,迫切需要一套专业的系统对核心网的本地数据进行统计分析,研究核心网节点接口容量以及性能对业务质量的影响,定位核心网瓶颈,提出优化改进建议。
1.1.2目标与范围
通过系统建设,对网元、网络性能等指标进行分析建模,从而及时发现网元或网络的异常行为,快速定位故障,保证网络质量,确保产品或服务达到顾客期望的目标。
1.1.3术语与缩写解释
术语、定义
缩略语全称
说明
1.2系统功能
1.2.1用户感知度分析
1.2.1.1客户投诉收集
本部分主要实现客服录入投诉信息的收集。
结合后台号码追踪功能,通过后台运行追踪脚本,获取用户起呼的基站、BSC、MSC等详细信息,收集记录下来,并为客服呈现相关的信息,为故障分析处理的提供更详细的原始信息。
结合电子地图,可对故障地点进行精确定位。
客服在受理投诉时,模糊输入地点信息,系统自动进行相应地理信息列表提示,方便客服选取,并可通过鼠标在地图上点击进行精确的定位,实现用户投诉地点的图形化选择与呈现。
1.2.1.1.1号码投诉实时录入
投诉号码录入主界面如下,主要面向客服人员。
通过该界面可以记录投诉信息:
投诉号码(*)、业务类型(*)、故障时间(*)、故障位置等。
录入完毕后,点击[提交]完成本次投诉信息的录入。
追踪和定位操作,请看下面的详细介绍。
1.2.1.1.2投诉号码实时追踪定位
客服在处理用户投诉时(通话中),先填写其手机号码,然后点[追踪]或按。
这时系统将会自动在后台提取手机号码的相关信息:
如品牌、所在小区、所在基站等,并将其回送到前台界面显示。
●追踪成功
如果追踪到通话手机手号所在的小区,则会同时查询在“故障时间”的一个小时内该小区所在的MSC中,出现投诉的基站,并显示投诉的次数。
如下图,右边地图的蓝色字中标识了出现投诉的基站及投诉次数。
●追踪失败
追踪成功和失败时的提示信息。
若追踪不到或1小时内所在MSC没有出现投诉,则不会在地图中显示出现投诉的基站。
1.2.1.1.3地图投诉地点定位
故障位置的填写有自动提示功能,如填写完“路”字、或“华”字,显示如下图,自动列出相应的道路等信息,方便选取。
如果列出的位置信息中只有一项时,则系统会自动选取,填入故障位置文本框中。
当选取到内容后,点[在地图显示](或按到[在地图显示],再按),这时会在右边地图中显示选中的内容,并将自动填入经纬度信息。
1.2.1.2投诉号码快速分析
目前可对号码进行多个维度的分析,分析号码集中在哪些小区、基站、SGSN、VLR、SCP、HLR、号段、品牌、业务。
得到各个维度中占有比例较高的项,生成故障排除建议报告。
再结合实时查看各项的告警和KPI等信息,进行快速故障排除。
同时还可以结合建议信息库和经验信息库进行故障排除。
1.2.1.2.1批量号码分析
号码分析主要分即时导入分析和历史号码分析。
即时导入分析实现以Excel的方式导入手机号码,并可立即对该批号码进行分析。
历史号码分析则实现对已批量导入或手工录入的号码的分析。
1.2.1.2.1.1即时导入分析
1.2.1.2.1.1.1统计分析
通过工具栏的[号码分析],调出批量号码分析界面。
导入号码后,选择本批投诉号码所集中的时段。
1.2.1.2.1.1.2告警和KPI查询
可在统计饼图上右键,查看相关告警和KPI。
目前只支持小区和SGSN饼图。
如下图列出了饼图里比例最高的几项。
1.2.1.2.1.1.3地理分布呈现
如果投诉信息中记录了经纬度或基站信息,则可以通过地图查看这次分析的地理分布。
若是投诉基站分析,还可以查看基站的相关信息:
如基站基本信息、相关KPI、告警信息等。
1.2.1.2.1.1.4分析报告查询
当分析完成后,点击工具栏上的[分析报告],可看到分析报告。
1.2.1.2.1.2历史号码分析
在号码列表视图下,可按时段或按批次对已录入系统的投诉号码进行查询,在查询的列表的基础上,点击[分析],即可实现分析。
1.2.1.2.1.3组合业务维度分析
在进行即时导入分析和历史号码分析时,可结合投诉的业务类型进一步分析。
如分析某批投诉号码中属于短信业务的集中在哪些小区。
1.2.1.3全业务拨测
1.2.1.3.1由分析报告拨测分析
通过多维度分析号码将获得投诉最高的几项如:
小区、业务类型、基站、VLR、HLR…和小区是否现在有告警等信息,根据相关分析报告可创建相对应的拨测任务进一步确定该地域的基站设备是否正常运作。
1.2.1.3.1.1分析报告
当分析完成后,点击工具栏上的[分析报告],如下图
1.2.1.3.1.2新建拨测任务
点击分析报告上的[创建任务],系统会根据报告上的业务类型、品牌、小区…等信息自动识别进行任务创建。
1.2.1.3.1.3查看拨测结果报表
拨测任务完成后,在拨测任务模块下的任务日志列表可看到刚才所创建的任务执行情况。
1.2.1.3.2直接拨测分析
工作人员可自定义已在全业务质量监测系统上定义好的各种业务的拨测任务模板来创建任务对BSC和各业务类型进行测试
1.2.1.3.2.1拨测任务列表
通过工具栏可直接进行创建拨测任务和查看拨测状态、结果。
可对任务执行状态实时监控(5秒同步一次全业务质量监测系统上的任务数据)
1.2.1.3.2.2创建任务
点击[创建拨测任务],选择BSC与测试项,附加条件(对应不同业务有不同的条件)。
1.2.1.3.2.3查看任务结果
完成的任务结果和历史记录(可过滤查询)。
单个任务的详细拨测报告,详细反映该任务的执行情况与及设备的测试数据。
1.2.1.4建议信息库及经验库
通过下图所示的工具栏按钮可进入建议信息和经验信息库。
1.2.1.4.1建议信息库
建议信息库记录了各个分析维度如,小区、SGSN、HLR等和业务的关系信息。
以便在进行号码分析时可依据这些关系产生建议信息。
如系统在分析一批号码中发生在VLR的投诉,集中在语音业务,则可以通过VLR和语音业务的关系信息中,找出类似如下的建议信息:
“建议:
检查MSC的负荷、告警、相关的SIZE占用情况、相关的交换局参数设置情况、软件补丁情况”。
1.2.1.4.2经验信息库
借助经验信息库管理,方便对每一次故障排除经验进行积累。
这对以后的故障定位、排除,以及维护人员间的技术交流起到促进作用。
1.2.2核心网性能分析
1.2.2.1指标趋势变化分析
性能指标趋势变化分析,是通过图形和表格等我多种方式呈显指标实数据据,定时刷新显示。
实时对历史数据进行监控。
1.2.2.1.1性能指标实时监控
通过定时刷新数据实现实时对性能指标当前指标值进行监控。
1.2.2.1.1.1性能指标分类呈现
实现可定制的分类指标呈现,关注网络重点指标。
1.2.2.1.1.2历史性能指标查询
打开右键菜单,点击“查看”->“历史性能指标”。
1.2.2.1.1.3明细图表呈现
双击某柱状,以明细图的形式呈现该网元的历史走向。
1.2.2.2指标瓶颈分级别预警分析
设置性能指标瓶颈阀值,当指标值处于当阀值时,产生预警,提示处理。
在性能指标实时监控中,以更变颜色或闪烁等信息显示。
界面如下图所示:
1.2.2.3网络应急指标监控
将日常应急工作中对网络重点关注的指标进行监控,将现网所有的厂家所有网元设备的性能数据统一呈现监控。
以多维图形化的方式实现对现网CP负荷、信令链路负荷、话务路由占用、交换机话务量、SCP系统性能指标、每秒呼叫次数、SCF平均响应时长、SDU平均响应时长、全网话务负荷查看以及登记用户数、开机用户数等重点指标监控。
支持按多个维度来呈现指标,多角度关注应急指标。
可以分区域监控现网的登记用户数、开机用户数情况。
1.2.2.4指标地图化呈现
1.2.2.4.1漫游指标地图化呈现
提供基于省内、全国漫游数据直观呈现,统计城市、省、国家、大洲的来访、到访漫游用户数。
左上角提供丰富的操作。
省内地图呈现,统计本地移动用户漫游省内各城市或省内各城市来访的移动用户数。
1.2.2.4.2Bts/Cell指标地图化
将基站或小区相对应的性能指标结合基站经纬度在地理化进行呈现,直观呈现全市各区域的微观性能。
实现15分钟级的小区话务量、小区掉话率、小区拥塞率和小区接通率的小区性能指标监控,同时基于基站与小区对应关系,可以统计基站和全网的话务量、掉话率、拥塞率和接通率等指标。
1.2.3网络支撑辅助应用
1.2.3.1交换机原始话单分析
实际工作中,需要通过采集话单帮助分析各种通话故障,实现快速故障定位。
由于缺乏原始话单下载的配套工具,缺乏原始话单解析工具和针对性的话单查询工具,原始话单下载、解析和查询都非常困难。
当出现客户网络故障投诉时,维护人员需要到交换机上获取原始话单文件,借助爱立信厂家的工具对采集到的话单文件转换后,然后对话单内容进行检索,从而实现客户投诉故障定位,但依赖于手工下载及查询方式效率较低,因此需要借助本系统实现话单的自动采集、解析、查询。
系统对原始的二进制话单文件进行解析转换,生成可读的文本文件;并通过灵活的查询界面提供智能查询。
交换局原始话单的解析可通过远程登陆到OSS,由OSS从指定的网元中获取话单文件。
GIMS将符合条件的话单文件从OSS下载到服务端后,根据网元类型判断是2G还是3G类型设备区分采用不同的分析方式并入库,再根据客户需求呈现话单文件。
由于交换局话单是实时生成的,每个网元每分钟都会生成一个话单文件,数据量非常庞大,所以系统在用户需要查询的时候才连接OSS系统下载话单文件,减小所获取话单的数据量,减轻系统的负荷。
网元可分为IOG协议和APG协议两种类型,所以网元话单文件的获取方式也有两种。
IOG类型的网元原始话单解析的实现过程可分为如下几个步骤:
第一步:
由用户输入投诉客户的手机号码、客户投诉的时间段、MSC等信息;
第二步:
系统根据用户输入的信息在系统数据库中查找以往话单查询的历史数据,如有结果返回则在前台呈现结果,否则通过Telnet远程连接到OSS;
第三步:
GIMS成功连接到OSS后,根据用户输入的信息,通过OSS发送指令到指定的网元,网元接收到指令后会上传符合条件的话单文件到OSS指定的FTP目录中;
第四步:
系统通过FTP连接OSS的方式,将OSS指定的FTP目录中的话单文件下载到GIMS指定的目录中;
第五步:
GIMS对获取到的话单进行过滤分析,提取整合所需信息,并将整合后的信息作为话单历史查询结果保存到GIMS数据库中;
第六步:
在客户端将结果根据用户预先定制的格式呈现。
1.2.3.2交换机日志分析
日常进行故障定位、投诉处理时,需对通过OSS连接到指定交换机上,对交换机的日志进行人工查对,由于网络上的交换机较多,且交换机日志文件是以文件方式保存,不方便进行信息查找,导致故障定位效率较低,同时对故障定位人员的技术要求较高,另外OSS系统上保存的交换机操作日志只局限于通过OSS网管系统的操作,对于维护人员在其他途径下的交换机操作是无法获取的。
系统通过实时激发的方式,采集交换机的操作日志文件,并对日志信息进行预处理和入库,并提供灵活的查询接口,查询交换机的日志操作信息,提高故障定位的速度。
1.2.3.3设备远程验收
随着移动网络不断扩展,工作人员常需要到各机房进行新建网元设备验收工作,由于移动机房地理位置分散,设备验收工作需要消耗较多的人力物力,且工作效率低下,因此集中进行设备远程验收成为迫切的需要,这也符合省公司集中化管理的指导思想。
系统对采集到的数据文件进行分析,提取有效信息保存到数据库;根据各种检验规则,对各种设备的状态进行比较和检查,实现网元设备数据的验收,分成爱立信和华为设备网元。
1.2.3.4一键式应急通信保障
对于突发情况造成通信故障,维护人员必须能在尽可能短的时间内定位故障,并处理故障以保障通信系统的正常运作。
系统结合GSM网络的维护经验,总结常见故障及其有效的处理手段,并预先固化在系统中,当出现通信故障时,用户只需点击对应的菜单或者功能键,系统自动执行预先设定的操作,提高故障处理的响应速度;同时需对执行的操作进行适当的监控或者日志登记。
由于故障类型较多,针对每种故障都有一个对应的故障处理指令集合,为方便管理提供一个管理界面,按故障类型对指令集进行划分,同时实现指令文件上传功能,用户编辑完指令后,可将指令集存储到数据库中。
1.2.3.5基站退服排查
周期性统计各地区停电、倒站的基站情况。
通过OSS系统获取包含停电、倒站的告警列表,按告警标题进行分析筛选,按地区统计基站停电数、倒站数,同时以饼状图显示分布情况。
1.2.4系统管理
1.2.4.1用户管理
用户管理模块完成系统帐号信息的管理,包括新增用户、修改用户信息、删除用户等基本维护功能。
1.2.4.2角色管理
角色管理完成系统各管理角色、使用角色的定义管理。
1.2.4.3权限管理
权限管理完成用户对系统相关模块的操作权限及相关资源数据的访问和操作权限的设置。
1.2.4.4系统日志
系统日志管理包括日志查询和日志导出等功能,完成系统日志的维护。
1.2.5系统接口模块
1.2.5.1用户同步接口
从综合应用平台同步Portal账户信息,使用户使用Portal账户及密码也可以登陆系统。
1.3系统设计
1.3.1设计理念
1.3.1.1统一系统平台
基于SOA架构和组件化设计,围绕统一的软硬件基础、统一的数据采集策略管理、统一的数据管理、统一的内外部接口和统一的界面搭建统一的系统平台。
◆统一系统平台,围绕统一的系统平台理念,将所有的业务集成起来,对终端用户可统一操作所有的系统功能;
◆统一界面,一个系统平台一个用户界面的理念,系统所有业务功能集中呈现;
◆统一操作,系统提供统一的呈现,统一的操作方式;
◆统一数据,系统通过统一的策略管理将各方面的业务数据采集起来,统一存储,集中管理,通过内外部接口提供数据;
◆统一接口,系统内外部接口都按规范化设计,统一注册,统一发布,支持高可扩展性。
1.3.1.2统一界面、统一操作
基于丰富应用的成熟的系统架构,统一系统的布局设计、UI风格和用户操作方式,以地图化、图形化方式将业务统一呈现,提供终端用户集中化的操作。
业务呈现与系统整体逻辑关系如下图所示:
1.3.1.3统一数据
搭建统一的数据中心,通过统一的采集策略、统一的采集方式,将现网各类网元性能数据和各异构系统的性能数据及现网网管系统的主次数据进行整合,集中化管理。
系统通过对纳入的资源数据进行梳理,建立一套统一的资源数据库管理规范,实现对系统资源进行统一的管理;该资源库管理规范具有简易性、维护性和扩展性。
同时,实现数据的存储格式化,访问规范化。
●数据层规范
数据字典格式规范化,统一系统各业务数据的数据字典;
数据库命名规范化,统一命名规范化;
数据访问调用标准化;
业务数据相互独立,分布存储。
●数据安全性
系统提供定时数据备份机制,周期性备份系统数据库和核心数据,当系统出现崩溃时,能够快熟恢复系统,保障系统数据恢复正常。
●数据采集控制策略规范
对系统所涉及的数据的采集周期进行全面梳理,订制执行策略,通过规范化组件设计,注册到组件管理器,并通过任务管理器进行灵活配置。
1.3.1.4统一接口
通过基于SOA的标准协议,统一规范系统的内外部接口;通过企业服务总线对所有接口统一注册、发布和管理,灵活支撑业务变化。
系统数据层接口完成数据的采集、分析及内部数据访问;系统提供对所有数据层接口进行管理,通过规范接口开发,可支持快速扩展。
系统业务层接口是面向系统业务层提供业务应用、数据调用和组件服务;系统提供对所有业务层接口进行管理,通过规范接口开发,可支持快速扩展。
应用层接口是提供系统各类应用的接口支撑。
方式
客户端
服务器
说明
一、数据层接口
FTP
所有
所有
使用FTP协议
TELNET
所有
Linux/Unix等
使用TCP协议
开放数据库接口
所有
所有
使用ODBC/JDBC协议
WebService
所有
所有
使用SOAP协议
二、业务层接口
SOAP
.NET组件
.NET组件
使用HTTP协议,接口数据为XML格式
支持WebService的平台
.NETWeb
服务
三、应用层接口
SOAP
.Net组件
.Net组件
使用HTTP协议
1.3.2总体架构
核心网本地数据分析系统采用SOA的架构和组件化设计思想,规范化整个系统架构。
同时,通过整合现网核心网各类数据,基于统一的采集策略,按定义好的数据格式,统一存储在系统的数据中心。
通过规范的各服务层接口统一提供数据。
系统与业务功能分开,构建统一的应用系统及应用规范,各业务应用功能组件之间实现“松耦合”接入;
数据处理与上层业务分开,系统数据采集处理透明化,实现可管理、可监控,与上层业务互不干扰;
系统设计组件化,实现各类接口、数据采集分析等底层模块组件化,提供统一的组件管理;
系统运行可监控化,实现对系统自身运行状况实时监控,对异常事件自动告警监控。
1.3.3框架架构
采用业界成熟的系统框架来搭建系统核心。
以ASP.NETMVC2作为前端MVC的架构;业务层采用Untiy2.0;持久化层采用DataAccessApplicationBlock,保证系统的高内聚,低耦合,使系统具备高可扩展性。
系统底层采用公司成熟的企业开发库组件。
按分布式设计思想,将系统划分成多个层次:
业务层通过Winform表现,结合GIS和图表,呈现业务模型。
业务逻辑层完成系统业务逻辑运算、分析,并结合系统各类业务数据按业务算法提供表现层呈现。
数据访问层实现了上层应用与底层数据的相互独立。
1.3.4网络拓扑图
考虑到系统的数据量相对比较大,数据交互频率比较高,而实时性要求比较高,因此在配置硬件服务器上将把数据存储中心、业务应用服务和数据采集分析分别部署在不同服务器上。
基于高带宽和用户使用考虑,系统将部署于OA网;由于需要访问OSS网,在防火墙之间需要配置互通,考虑到安全性,可配置仅数据采集分析服务器能够访问OSS网。
1.4软硬件选型
1.4.1硬件选型
根据系统的负载要求及设计思路,在满足系统高性能、高效率及低故障率的条件下,需配置三台独立的服务器来部署系统,在硬件上实现系统分布式处理。
1.4.2软件选型
本系统的软件配置以服务器硬件配置为基础,操作系统、数据库系统、开发技术、应用软件等都采用业界成熟的、紧密型的解决方案。
本系统采用Microsoft成熟的解决方案,基于一系列的软件基础,结合自身丰富的研发经验,来实现系统建设,提高系统整机运行稳定性、安全性,有效地提高系统组建的灵活性和降低成本。