省级话务网网管系统三期技术方案-可选功能需求V1.0.0.doc

中国移动话务网网管系统三期总体技术方案（v0.1.0）中国移动技术规范 文档编号：中国移动话务网网管系统三期可选功能需求文档版本：version 1.0.0版权声明：版权归中国移动通信集团公司所有，未经中国移动通信集团公司书面许可，任何单位或个人不得以任何形式全部或部分使用和传播本技术规范。发布日期：2003年11月发布单位：中国移动通信集团公司第 2 页 共1 页中国移动省级话务网网管三期系列规范可选功能需求 文档说明：本技术规范为中国移动话务网网管三期规范中的可选功能部分。本规范为三期规范中的可选功能部分仅用于指导中国移动网管系统建设，中国移动通信集团公司保留对本方案的解释权和修改权。以下同志参加了本规范初稿的编写工作，表示感谢魏丽红、熊宙实、王烨、张雷、李长城、刘可、蔡军、于涛、娄云、高江晖、赵纲、李明晖、管光明、罗东、吴登中、革诗新、李鹏、jeremy 、杨保宁等编号说明：（本文档编号依照以下原则进行：x.y.z x: 大版本更新，文档结构变化 y: 具体方案的更改，部分内容的修正 z: 文字修改，奇数为包含对上一版修改记录的稿子偶数为对上修改稿的定稿 ）增强集中操作维护子系统文档修改历史版本更新日期修改核定更新说明文档状态v0.1.02003-4吴荣宇、李永春、索那等张潮初稿v0.1.02003-9-29赵纲、卢海杨、艾建平、楼云、赵万红等王烨、张雷征求意见稿发布v1.0.02003-11-25张潮等王烨发布稿发布客户服务支持子系统文档修改历史版本更新日期修改核定更新说明文档状态v0.1.02003-4-26杜笃、曹玮、肖强、柴谊林等张潮初稿v0.1.02003-9-29徐谨、李长城、曹玮等王烨、张雷征求意见稿发布v1.0.02003-11-25张潮等王烨发布稿发布网优综合分析文档修改历史版本更新日期修改核定更新说明文档状态v0.1.02003-9-29许莲、管光明、李明辉等王烨、张雷征求意见稿发布v1.0.02003-11-25张潮等王烨发布稿发布目 录综述1增强集中操作维护子系统2客户服务支持子系统2网络优化支持子系统3第1章 增强集中操作维护子系统61.1.概述61.1.1. 话务网集中操作维护发展建设思路61.1.2. 本期建设的定位61.2.局数据管理61.2.1. 适用性和适用范围61.2.2. 完善局数据核查的功能61.2.3. 管理范围和内容：81.2.4. 完善局数据制作141.3.智能巡检151.3.1. 概念解释161.3.2. 功能要求181.3.3. 元任务相关的的标准接口功能241.4.用户信息查询251.4.1. 查询条件251.4.2. 查询内容251.4.3. 查询结果显示271.4.4. 安全保障机制271.4.5. 用户位置更新27第2章 客户服务支持子系统292.1.客户服务支持系统功能架构292.2.客户服务支撑功能312.2.1. 应答知识查询功能322.2.2. 投诉信息定位功能322.2.3. 网络信息发布322.2.4. 终端功能332.3.客服规则库功能需求342.3.1. 客服规则库的基本结构342.3.2. 客服规则库基础数据需求342.3.3. 客服规则库系统功能352.3.4. 客服规则库性能需求352.4.客服分析功能352.4.1. 投诉关联分析352.4.2. 大客户综合分析382.5.用户相关数据核查功能39第3章 网优综合分析403.1.dt 、cqt 数据管理功能403.1.1. dt数据导入403.1.2. cqt统计数据导入403.1.3. dt/cqt统计数据管理413.2.性能管理功能413.2.1. 性能数据采集413.2.2. 性能数据呈现423.2.3. 历史分析和趋势预测423.2.4. 性能告警功能433.2.5. 性能数据与dt/cqt、投诉数据之间的关联433.2.6. 性能数据呈现增强功能433.3.gis功能443.3.1. 邻区同/邻频查询453.3.2. 性能、配置数据与dt数据的结合453.3.3. cqt数据的地理展现463.3.4. 投诉数据的查询展现463.3.5. 小区覆盖数据的展现473.3.6. 话务的分布473.3.7. gprs pcu数据流量的分布473.3.8. 自定义范围内话务量分析473.3.9. gis上的dt后处理483.4.优化参数管理功能483.4.1. 优化参数采集483.4.2. 优化参数导入483.4.3. 优化参数管理493.4.4. 优化档案管理493.5.网络评估功能493.5.1. omc性能数据量化评估493.5.2. dt数据量化评估493.5.3. cqt数据量化评估493.5.4. 投诉数据量化评估503.5.5. 整体网络性能评估503.5.6. 优化过程重现503.5.7. 优化效果评估51 综述根据中国移动网管系统三期建设目标和建设原则，在省级网管系统三期中，应从网管体系结构方面，对现有系统的框架进行完善，逐步建立网管基础服务平台，并从故障管理、配置管理、性能管理、作业管理等角度建立相对独立的资源管理子系统、综合性能分析子系统、综合告警管理子系统、增强集中操作维护子系统、网络优化支持子系统和客户服务支持子系统。其中“相对独立”是为了防止省级网管系统庞大的各个功能模块群体因个别模块的故障，从而导致其它功能模块的不正常使用；相对独立也不是绝对独立，几个子系统可以共用主机、磁盘、网络和数据库等资源，以减少设备投资。各个模块之间的关系如下图所示：各个可选子系统的简要功能描述如下：增强集中操作维护子系统继承话务网管系统的基础，补充相关实用功能，帮助维护人员有效、快速的完成各种操作维护工作。达到与话务网管其他模块相互结合，能够快速反映网元及网络的各种异常变化情况，同时提供维护人员可以相对快速的解决各种管理和维护操作的手段。1. 局数据功能 完善据局数据核查功能 完善局数据制作2. 智能巡检 元任务管理功能 任务管理功能 方案管理功能 方案实例管理功能 调度功能 巡检结果察看功能 调度日志察看功能3. 用户信息查询 条件查询功能 安全保障功能 用户位置更新客户服务支持子系统客户服务支持子系统为客户受理业务代表坐席提供即时的、准确的、简单易懂的网络运行的各种信息，方便客户投诉受理人员在较短时间里给客户一个比较满意的答复，提高客户受理的时效性，提高客户的满意度，从而提高客户的忠诚度.同时，通过网络客户服务系统对客户投诉的各种信息进行汇总、归纳、通过知识经验库生成关联规则，帮助维护部门更好的作好网络维护和作好网络优化。 主要功能包括:1. 客户服务支持功能：包括投诉空间位置定位，网络信息发布以及应答知识查询等。2. 知识库功能需求：知识库是保存客户投诉分析专家的分析经验或客服数据分析系统产生的关联规则等知识，以便为客服中心操作人员在解决客户投诉或客户服务系统在处理投诉时提供必要的经验或知识支持的专家规则系统。通过对知识库的维护和管理，可以动态的添加、修改、删除投诉分析的经验或处理规则。3. 客服分析功能：包括通过对dt、cqt、cdr、网管性能数据等各类数据的收集完成对用户（特别是大客户）投诉的分析，完成对用户（特别是大客户）活动热点区域的保障，对用户投诉进行综合分析，对网络隐性故障的判断，为网络优化提供参考信息。4. 用户相关数据核查功能：实时对单个用户进行hlr数据核查。定期对hlr中用户自定义数据进行主动性的清查，通过各种方式对存在的问题进行解决。网络优化支持子系统网优支撑系统，意在将无线网络数据、路测、定点测试数据与数字化地图相结合，直观反映全网的无线网络运行状况。对无线网络的运行状况、覆盖分布、信号质量、话务分布、用户投诉等情况进行集中监控，建立起网络优化和建设规划的基础数据。逐步建立网络优化方案集中制作、优化效果集中评估、无线资源统一调度、分区测试的优化模式。网优支撑系统的目标：l 成为网络优化方案制定的数据平台l 成为网络优化效果评估的平台l 网络优化工作流程实现电子化网优支撑系统的主要功能应用如下：1. dt 、cqt 数据管理功能l dt/cqt数据的导入l dt/cqt数据的管理2. 无线性能管理功能l 历史分析和趋势预测l 性能告警l 性能数据与dt/cqt、投诉数据之间的关联l 性能数据呈现部分的功能加强3. gis功能l 相邻小区切换关系图示查询l 邻区同/邻频查询l 性能数据、配置数据与dt综合展现l cqt数据的地理展现l 投诉数据的查询展现l 小区覆盖数据的展现l gprs pcu数据流量的分布展现l 自定义范围内话务量分析l gis上的dt后处理4. 无线参数和配置管理l 无线参数的采集、导入l 无线参数管理l 优化档案管理5. 网络评估功能l omc性能数据量化评估l dt/cqt数据量化评估l 投诉数据量化评估l 整体网络性能评估l 优化过程重现l 优化效果评估l 分析结果处理第 53 页 共 52 页第1章 增强集中操作维护子系统1.1. 概述1.1.1. 话务网集中操作维护发展建设思路以“三集中”为发展建设的基本思路。由面向管理发展为管理与维护并重。实用化和贴近维护流程，为流程中的不同岗位提供不同的信息和操作能力。1.1.2. 本期建设的定位使用对象：管理人员、网络操作维护人员、监控人员。建设方式：继承话务网管系统的基础，补充相关实用功能，帮助维护人员有效、快速的完成各种操作维护工作。建设目标：达到与话务网管其他模块相互结合，能够快速反映网元及网络的各种异常变化情况，同时提供维护人员可以快速的解决各种管理和维护操作的手段。1.2. 局数据管理1.2.1. 适用性和适用范围2003年初，集团公司下发了hstp、lstp、tmsc1、tmsc2、msc、hlr、gmsc等七类网元的局数据规范（第一版）及数据设置原则。随着各类网元局数据的逐步规范，为实现局数据的集中核查和制作软件的开发提供了保证。本章节是在各省开发的局数据管理软件的基础上，明确了局数据管理（包括局数据核查及统一制作）的范围和深度以及软件的必备功能，以实现集团公司对于局数据集中核查制作的要求。使用对象:主要是网络维护人。1.2.2. 完善局数据核查的功能要求提供两种核查手段：联机核查和脱机核查。其中脱机核查为针对各类网元的数据所必须具备的核查手段；联机核查是在满足客观条件（如接口方案已解决）的前提下的可选手段。联机核查适用于有针对性的局部数据的核查；脱机核查适用于定期的、以网元或数据类型为单位的核查。1.2.2.1. 标准数据的导入应当同时具备人工选择文件导入和自动导入两种功能。人工选择文件导入指由操作员手动选择需要导入的标准数据文件，其中包括覆盖式导入和增量式导入。覆盖式导入指系统通过由用户指定导入文件，将集团公司下发的局数据、省内所有设备信息的相关局数据导入到系统数据库当中，作为局数据核查的标准数据。增量式导入指对于每次下发的局数据文件采用递增的模式插入到数据库中，作为局数据核查、制作的依据。自动导入是指软件应能自动将集团公司局数据管理系统中的标准数据定期自动（或由人工触发）导入到数据库中，并提示用户本次导入的数据与库中原有数据间的差异，供维护人员参考。这种导入方式只能用于覆盖式导入，并且实现的前提是集团公司局数据管理系统能够提供开发式接口。对于标准局数据的导入，应当能够自动判断标准局数据文件中的错误，对于无法正确导入的数据应当准确地反馈给用户，以方便用户修正这些错误之后再次导入。1.2.2.2. 交换机现网数据的采集对于实际局数据的采集要求系统提供比较方便的采集接收方式，允许用户通过人工直接从交换机提取数据，系统自动从交换机提取数据两种方式。对系统自动提取要求能够提供用户设定诸如采集的网元、采集的数据内容、采集的时间、采集周期等相关条件，并且支持多网元并发采集。数据自动采集必须保证系统的安全性。1.2.2.3. 现网数据的导入应能提供现网数据的导入渠道，以便软件分析比较现网数据与标准数据的区别。要求支持多网元数据的并发导入。1.2.2.4. 现网数据的核查应能实现对各具体项目的核查，正确指出现网数据的错误，并提出修改建议。要求支持多网元数据的并发核查。作为可选内容，建议同时具备将核查结果转化为交换机指令文件的功能。1.2.2.5. 局数据备份应能实现局数据制作前对现网数据进行采集并保存的功能，并能实现将现网数据的输出文件正确转化为交换机指令文件的功能。要求局数据制作过程中的操作记录、交换机反馈信息能够妥善保存。1.2.2.6. 软件数据库的人工维护功能应能提供对部分信息简便的手动维护渠道，如软件登录口令的变更、个别数据信息的变更等。1.2.3. 管理范围和内容：要求局数据核查和制作模块可以对hstp、tmsc1、lstp、tmsc2、hlr、msc、gmsc、scp、smsc和sgsn进行核查。1.2.3.1. hstp1. gt-msc id（m号）的核查。要求核查多做、漏做和做错。2. 应能正确核查msc id的gt分析数据及其指向。要求核查多做、漏做和做错。3. gt-smc（短信中心号码）的核查。要求核查多做、漏做和做错。4. 应能正确核查smc号码的gt分析数据及其指向。要求核查多做、漏做和做错。5. gt-msisdn（h号）的核查。要求核查多做、漏做和做错。6. hstp中的用户号段数据一定要将所有的标准msisdn号码段做全，即完全匹配。要求核查多做、漏做和做错。7. 应能正确核查全网h号的e.164号码段gt分析数据及其指向。要求核查多做、漏做和做错。8. gt-e214的核查。要求核查多做、漏做和做错。9. hstp中的用户号段数据一定要将所有的标准e214号码段做全（对于省内热计费号段，只做本省数据），且完全匹配。要求核查多做、漏做和做错。10. 应能正确核查全网h号的e.214号码段gt分析数据及其指向。要求核查多做、漏做和做错。11. 国际号码的核查。要求核查多做、漏做和做错。12. 应能正确核查国际设备号的e.164号码段和用户号的e.214号码段gt分析数据及其指向。要求核查多做、漏做和做错。1.2.3.2. tmsc11. cpt-msc id（m号）的核查应能正确核查msc id的被叫号码分析数据及其指向。要求能够核查多做、漏做和做错。2. 语音信箱号码应能正确核查语音信箱的被叫号码分析数据及其指向。要求能够核查多做、漏做和做错。3. 长途区号的核查应能正确核查全网长途区号的被叫号码分析数据及其指向。要求能够核查多做、漏做和做错。4. 国际号码的核查应能正确核查国际被叫号码的分析数据及其指向。要求能够核查漏做和做错。5. 联通号段的核查应能正确核查联通网被叫号码分析数据及其指向。要求能够核查多做、漏做和做错。 1.2.3.3. lstp1. gt-msc id（m号）的核查应能正确核查msc id的gt分析数据及其指向。对于端局将外省msc id数据直接指向hstp的省份，由于lstp只进行mtp转接，故不对外省msc id数据进行核查。要求核查漏做和做错。2. gt-smc（短信中心号码）的核查应能正确核查smc的gt分析数据及其指向。对于端局将外省smc数据直接指向hstp的省份，由于lstp只进行mtp转接，故不对外省smc数据进行核查。要求核查漏做和做错。3. gt-msisdn（h号）的核查应能正确核查h号的e.164号码段gt分析数据及其指向。对于端局将外省h号数据直接指向hstp的省份，由于lstp只进行mtp转接，故不对外省h号数据进行核查。要求核查漏做和做错。4. gt-e214的核查应能正确核查h号的e.214号码段gt分析数据及其指向。对于端局将外省e.214数据直接指向hstp的省份，由于lstp只进行mtp转接，故不对外省e.214数据进行核查。要求核查漏做和做错。1.2.3.4. msc1. msc id（m号）的核查l 信令：应能正确核查msc id的gt分析数据及其指向。核查范围包括与本局有切换关系的msc id，考虑到部分smsc与msc有归属关系，对于这类msc id，也应进行核查。 l 话路：应能正确核查msc id的被叫号码分析数据及其指向。要求核查漏做和做错。1. gt-smc（短信中心号码）的核查应能正确核查smc号码的gt分析数据及其指向。要求核查漏做和做错。2. gt-msisdn（h号）的核查msc中的用户号段数据一定要将所有的标准库中的msisdn号码段做全，即完全覆盖标准库。应能正确核查全网h号的e.164号码段gt分析数据及其指向。要求核查漏做和做错。3. gt-e214的核查msc中的用户号段数据一定要将所有的标准e214号码段做全（对于省内热计费号段，只做本省数据），且完全匹配。应能正确核查全网h号的e.214号码段gt分析数据及其指向。要求核查漏做和做错。4. 漫游局数据核查主要是翻译数据核查，对国内及国际的imsi应能正确翻译，且要求对翻译替换的位数也能核查准确。要求核查多做、漏做和做错。5. 联通号段的核查应能正确核查联通网被叫号码分析数据及其指向。 要求核查漏做和做错。1.2.3.5. hlr1. gt-msc id（m号）的核查应能正确核查msc id的gt分析数据及其指向。hlr的各项数据要求核查漏做和做错。2. gt-smc（短信中心号码）的核查应能正确核查smc号码的gt分析数据及其指向。（北电hlr需要对短信中心进行唯一性定义，标准数据中将明确具体的短信中心号码）。要求核查漏做和做错。1.2.3.6. tmsc21. cpt-msc id（m号）的核查应能正确核查msc id的被叫号码分析数据及其指向。2. 语音信箱号码应能正确核查语音信箱的被叫号码分析数据及其指向。3. 省内长途区号的核查应能正确核查省内长途区号的被叫号码分析数据及其指向。4. 联通号码的核查应能正确核查联通网被叫号码分析数据及其指向。tmsc2的各项数据要求核查漏做和做错。1.2.3.7. gmsc1. msc id（m号）的核查应能正确核查m号的被叫号码分析数据及其指向。要求核查漏做和做错。2. gt-msisdn（h号）的核查gmsc中的用户号段数据一定要将所有的标准库中的msisdn号码段做全，即完全覆盖标准库。要求核查漏做和做错。应能正确核查h号的e.164分析数据及其指向。要求核查漏做和做错。3. 联通号段的核查应能正确核查联通网被叫号码分析数据及其指向。要求核查漏做和做错。1.2.3.8. scp1. gt-msisdn（h号）的核查scp中的用户号段数据一定要将所有的标准库中的msisdn号码段做全，即完全覆盖标准库。应能正确核查h号的gt分析数据及其指向。要求核查漏做和做错。2. mscid所属区号的核查应能正确核查mscid与区号的对应关系。要求核查多做、漏做和做错。3. msisdn所属区号的核查应能正确核查msisdn与区号的对应关系。要求核查多做、漏做和做错。4. 智能号段所属scp是否作全。应能正确核查智能号段与所属scp对应关系。要求核查多做、漏做和做错。5. 智能vc/ip设备数据核查。应能正确核查vc/ip对应关系。要求核查多做、漏做和做错。1.2.3.9. smsc1. 核查用户号段应能正确核查全网用户号段、联通号段。要求核查多做、漏做和做错。2. gt-msc id（m号）的核查应能正确核查m号的gt分析数据及其指向。要求核查漏做和做错。3. gt-msisdn（h号）的核查用户号段数据一定要将所有的标准库中的msisdn号码段做全，即完全覆盖标准库。应能正确核查h号的gt分析数据及其指向。要求核查漏做和做错。4. icp数据的核查应能正确核查全网类icp数据。要求核查多做、漏做和做错。1.2.3.10. sgsn1. gt-msisdn（h号）的核查用户号段数据一定要将所有的标准库中的msisdn号码段做全，即完全覆盖标准库。应能正确核查h号的e.164 gt分析数据及其指向。要求核查漏做和做错。2. gt-e214的核查用户号段数据一定要将所有的标准库中的e214号码段做全，即完全覆盖标准库。应能正确核查h号的e.214 gt分析数据及其指向。要求核查漏做和做错。3. imsi分析数据的核查sgsn应当制作与中国移动签订漫游协议国际的gprs运行商的e.212到e.214的号码翻译。应能正确核查国际的imsi翻译结果，且要求对翻译替换的位数也能核查准确。要求核查多做、漏做和做错。1.2.3.11. 软件版本要求核查软件增加各类网元的软件版本的核查功能。1.2.4. 完善局数据制作1.2.4.1. 实现方式：目前有两种实现方式，即通过仿真终端（在二期规范中已实现）逐条命令交互实现和通过批处理命令方式实现。生成批处理命令的方式有两种，一种是人工编辑方式，一种是软件分析自动产生。要求生成的批命令能够保存。作为可选项，在确保安全性和可靠性的前提下，应当提供批命令的自动（要求提供人工触发机制）执行功能。但在自动执行批命令文件前，必须提供操作员的审核功能。1.2.4.2. 局数据制作内容及范围：原则上，各类节点的局数据制作范围等同于核查范围，对于未向第三方开放接口的设备类型暂不要求。1.2.4.3. 信令中继局数据管理模块（可选）1.2.4.3.1. 概念解释信令中继局数据管理模块：该模块完成对交换机信令链路、语音中继、路由数据创建、修改等的局数据自动制作。1.2.4.3.2. 功能描述采集交换机中的信令链路、路由、中继及其相关的资源数据， 并将这些数据分析入库，作为局数据命令生成的基础数据。根据已采集的基础数据和定义好的数据制作流程，自动产生局数据制作命令：用户选择要进行数据制作的网元，并输入相关的参数，程序根据输入的参数去查询数据库中已有的实际数据，按照已定义的数据制作流程一步一步生成命令，一些空闲资源信息由程序到数据库中查找并提示用户选择，需要用户输入的参数自动弹出对话框由用户输入。最后自动产生局数据制作的批命令文件。经维护人员确认后将已产生的命令文件发送到相应交换机中。对每条命令的返回结果进行分析，如果某条命令发送失败，立即停止命令的发送并提示用户。命令发送过程有详细的日志记录。1.3. 智能巡检随着中国移动网络规模不断扩大，设备情况越来越复杂，要求操作维护面向集中处理，维护人员的工作压力越来越大，有必要在网管建设中引入智能巡检。所谓智能巡检指通过命令脚本的方式，完成日常的维护和检测任务，提高维护工作效率和质量。常用的巡检功能包括：专业网管系统检查、网元各单元/模块状态检查、中继/信令状态检查、计费信息自动备份、网元属性参数检查、告警级别定义核查、性能数据保障监控。各省公司可以根据各自情况予以删减或增加。主要使用对象为网络监控维护人员，可以分为两种级别：l 高级维护人员：总结运维经验，把其中有价值的并且能够用智能巡检功能实现的部分归纳整理出来，编写、测试巡检任务脚本，通过任务管理系统添加到网管系统中，使之成为一个正式运行的智能巡检任务。l 初级维护人员：使用高级维护人员或开发商开发的巡检任务，进行日常的维护工作，检查每个运行周期生成的巡检报告，发现网元问题。1.3.1. 概念解释1.3.1.1. 元任务元任务是指利用网管系统提供的接口，依据接收的参数，按照一定的逻辑，独立完成某个网元某个状态的检查，并可以根据检查结果进一步触发一条或多条告警，或直接将检查结果反馈出来的程序模块。1.3.1.2. 任务任务是一个元任务和某一执行周期的结合。1.3.1.3. 方案方案是若干任务的组合。1.3.1.4. 方案实例和元任务实例方案加载到网元上称为方案实例。方案实例又可以依据该方案是由哪些任务组成的，划分为元任务实例。1.3.1.5. 元任务实例结果状态和方案实例结果状态元任务实例结果状态指一个元任务实例对于巡检对象进行检查后，对于巡检对象状态是否正常所做出的分析结果。元任务实例结果状态有正常，异常和未知三种情况。如果最新检查的结果表明，所检查的网元当前处于正常运行的状态，则该网元实例结果状态为正常。如果最新检查的结果表明，所检查的网元当前处于异常的状态，则该网元实例结果状态为异常。如果因为某种原因，当前网元的状态无法获得，则该网元实例结果状态为未知。方案实例结果状态是对一个方案实例中各个元任务实例结果状态的整体描述。方案实例结果状态有正常和异常两种情况。当一个方案实例中包含的各个元任务实例结果状态全部为正常，则该方案实例结果状态为正常。如果方案实例中包含的任何一个元任务实例结果状态为未知或异常则方案实例结果状态为异常。1.3.1.6. 智能巡检功能的典型用例下面描述智能巡检功能的一个典型用例：用例名称：高级维护人员添加并设置运行一个智能巡检任务1. 编辑任务：使用任何一种文本编辑器编写巡检任务脚本，即元任务脚本。2. 注册任务：登记元任务脚本到任务管理系统，同时指定任务名称、任务类型等属性信息。3. 设置任务关联的网元：指定任务运行的网元类型、厂家、网元范围等信息。4. 建立任务方案：建立一个任务方案包含此元任务（任务方案可能包括多个元任务），设置任务运行时间类型、周期或者立即执行。5. 任务执行：在约定时间或者立即执行触发下，任务执行；在任务运行监视界面，可以看到任务运行状态信息。6. 查看任务运行报告：在任务运行完毕后，可以通过任务结果报告查看器查看运行结果。智能巡检任务将产生报表形式的结果报告。1.3.2. 功能要求1.3.2.1. 元任务管理功能1.3.2.1.1. 元任务的注册对于一个尚没有纳入巡检模块管理的元任务，可以利用元任务注册功能将该元任务纳入巡检模块的管理。注册功能需要传递的信息包括：l 元任务名称（指一个便于用户识别记忆的标识）l 调用方法（文件路径和文件名）l 元任务的注释信息1.3.2.1.2. 元任务的浏览按照一定的顺序，列出当前已经注册的所有元任务的名称，调用方法以及相关的调度信息。1.3.2.1.3. 元任务的注销对于当前处于非执行状态，且处于非关联状态（即此元任务未被定义成任何任务）的任务，可以予以删除。删除后其注册信息将被清除掉。1.3.2.2. 任务管理功能1.3.2.2.1. 增加任务用户可以通过该功能模块定义新的任务。一个任务包含下列信息：l 任务名称l 引用的元任务名称l 任务执行周期l 任务的注释信息1.3.2.2.2. 任务浏览用户能够以列表的方式浏览已经定义好的任务。在列表中可以显示下列信息：l 任务名称l 引用的元任务名称l 任务执行周期l 任务的注释信息。1.3.2.2.3. 修改任务对处于非执行状态且处于非关联状态的任务，用户可以修改下列信息：l 任务名称l 任务执行周期l 引用的元任务l 任务的注释信息1.3.2.2.4. 删除任务对处于非执行状态且处于非关联状态的任务, 用户可以进行删除操作。1.3.2.3. 方案管理功能1.3.2.3.1. 增加方案用户可以通过该功能模块定义新的方案。一个方案包含下列信息：l 方案名称l 方案所包含的各任务的名称l 方案的注释信息1.3.2.3.2. 方案浏览用户能够以列表的方式浏览已经定义好的方案。在列表中可以显示下列信息：l 方案名称l 方案中所包含的各个任务的名称l 方案的注释信息。1.3.2.3.3. 修改方案对处于非执行状态且处于非关联状态的方案，用户可以对下列信息进行修改：l 方案名称l 方案中所包含的任务l 方案的注释信息1.3.2.3.4. 删除方案对处于非执行状态且处于非关联状态的任务，用户可以进行删除操作。1.3.2.4. 方案实例管理功能可以灵活配置巡检任务脚本；可以方便的增加、修改、删除巡检任务脚本。1.3.2.4.1. 创建方案实例用户可以通过该功能模块定义方案实例。一个新的方案实例应包含下列信息：l 方案实例的名称l 需要实施该方案的一个或一组网元l 方案实例的注释信息一个新的方案实例在创建后，处于非激活状态。处于非激活状态的方案实例将不会被调度执行。1.3.2.4.2. 方案实例的浏览用户可以通过该功能模块浏览已经定义好的方案实例。一个新的方案实例应包含下列信息：l 方案实例的名称l 需要实施该方案的网元的范围l 方案实例的注释信息l 方案实例的状态（激活状态，非激活状态）1.3.2.4.3. 修改方案实例对处于非执行状态的方案实例，用户可以修改下列信息：l 方案实例的名称l 需要实施该方案的网元的范围l 方案实例的注释信息1.3.2.4.4. 删除方案实例对处于非执行状态的方案实例，用户可以进行删除操作。1.3.2.4.5. 激活方案实例的执行对于原先处于非激活状态的方案实例，用户可以通过激活操作，将方案实例变为激活的状态。处于激活状态的方案实例，将被巡检模块调度执行。1.3.2.4.6. 停止方案实例的执行对于原先处于激活状态的方案实例，用户可以通过停止的操作，将其改变为非激活的状态。处于非激活状态的方案实例将不会被调度执行。1.3.2.5. 调度功能巡检模块可以依据不同用户指定的巡检方案实例，对元任务实例进行调度，即按照各个方案内的时间表，在所设定的时间到达后，巡检功能模块可以将网元的标识、该网元上当前网管用户关联的用户名、口令以及用于记录与网元巡检过程中交互内容的日志文件的路径传送给相应的元任务模块，执行该模块，并接收该模块返回的结果（是否执行成功，巡检结果是否正常等信息）。巡检模块可以支持对不同元任务实例的并发调度。当同一个元任务实例在执行时间上发生冲突时，调度功能应能够自动调整，避免冲突。1.3.2.6. 巡检结果察看功能智能巡检模块应可以存储所有元任务实例结果状态和最新的元任务实例执行过程中所有的网元交互详细信息。1.3.2.6.1. 方案实例结果状态察看功能依据用户选择的一个或多个方案实例，将这些方案实例结果状态显示出来。1.3.2.6.2. 元任务实例结果状态察看功能根据用户指定的方案实例，将该方案实例包含的所有元任务实例结果状态呈现出来。1.3.2.6.3. 元任务实例详细结果察看功能根据用户指定的元任务实例，显示系统存储的该元任务实例的网元交互信息详细记录。1.3.2.7. 调度日志察看功能巡检模块能够存储其对各元任务实例的调度日志，能够记录元任务实例每次被调度时的执行情况和返回结果。巡检模块可以根据用户指定的时间范围和指定的方案实例，显示每一个元任务实例上一次执行的开始时间，结束时间，执行是否成功，以及下一次执行的开始时间（如果当前正在执行，则下一次执行时间显示为“运行中”）。1.3.3. 元任务相关的的标准接口功能1.3.3.1. 元任务调度接口接口类型：北向接口；输入参数：网元的标识，用户名，口令，记录网元交互结果文件的路径和文件名输出参数：元任务执行过程是否成功，元任务对于网元检查的结果。如果元任务实例执行时间超时认为元任务实例执行失败；1.3.3.2. 网元操作接口1.3.3.2.1. 打开接口接口类型：南向接口；输入参数：网元的标识，用户名，口令；输出参数：执行是否成功，一个网元会话的句柄；1.3.3.2.2. 发送和接收指令接口类型：南向接口；输入参数：网元会话的句柄，需要发送的指令文本；输出参数：执行是否成功，会话返回的结果；1.3.3.2.3. 关闭接口接口类型：南向接口；输入参数：网元会话的句柄；输出参数：执行是否成功；1.3.3.3. 告警采集层告警插入功能接口类型：南向接口；输入参数：告警内容；输出参数：告警插入是否成功；1.3.3.4. 网管数据库访问接口接口类型：南向接口；输入参数：查询条件输出参数：返回结果；1.4. 用户信息查询本功能主要面向用户投诉处理人员、网络监控维护人员，使其可以及时查询用户信息，以便向客服提供一定的技术支持。提供gsm用户信息查询功能：需要屏蔽归属号段与hlr的对应关系和不同厂家查询指令的差异性；根据本省号段与hlr的对应表对gsm用户所属hlr自动定位、根据gsm用户登记信息对msc/scp自动定位，根据运行维护人员定义的查询条件进行单个或者批量gsm用户信息的查询；将查询结果以界面形式显示出来；向交换机或数据库提供一定的安全保障机制；根据gsm用户信息的查询结果进行用户位置更新。1.4.1. 查询条件1. 用户的msisdn2. 用户的imsi系统能够对用户输入的不合理查询条件（查询的用户号码非本地用户、查询的用户号码位长不够）进行准确的提醒。1.4.2. 查询内容1. 用户的基本信息l 用户的漫游范围、级别l 用户登记的交换机和上次登记的交换机（可根据用户要求将msc_id翻译为相应的网元名称）l imsi状态（是否激活）l 用户的闭锁信息 是否闭塞incoming call 是否闭塞outgoing call 是否双向闭塞2. 用户的基本业务信息l 电话业务l 短信业务（mo、mt、短信中心号码）l 数据业务3. 用户的补充业务信息l 用户是否有主叫隐藏l 用户是否有被叫显示l 用户是否有呼叫等待l 用户是否有呼叫保持l 用户的多种呼转业务l 国际漫游呼入呼出l 用户是否有多方会议4. 用户的csi信息l 用户是vpn或pps用户l 用户的dp码l 用户归属的scp5. gprs业务l 用户登记的sgsnl apnl qosl vpaa6. 智能用户的状态。l 是否欠费l 是否在有效期各个省公司可根据自身需要对查询内容字段进行增加。1.4.3. 查询结果显示1. 查询结果可直接输出或进行保存便于用户查看；2. 将查询结果转换为需要的规范格式并按照维护人员选择的字段进行显示。显示的形式如下所示：1.4.4. 安全保障机制考虑到运行维护人员需要频繁的连接hlr或msc、scp等重要的设备进行用户信息查询，这样可能会带来如端口吊死、占有过多scp数据库资源等安全隐患，应该采用一些机制防止上述问题产生，保障设备安全。1.4.5. 用户位置更新l 功能主要用途用户信息查询系统可向维护人员提供用户详细的业务和位置信息，用户位置更新功能可通过对hlr、vlr发送指令对用户的位置进行更新，解决日常一些用户漫游登记失败等必须进行强制性位置更新的故障投诉。l 使用对象:适用于用户投诉处理人员。对使用对象，需要提供特定的权限。l 功能描述:通过输入用户msisdn或imsi号码，完成hlr、vlr的用户信息查询，再根据此查询结果，向本省的hlr、vlr发位置更新指令。第2章 客户服务支持子系统客户服务支持系统的用户主要为网络维护管理人员、网络性能分析人员、网络投诉处理人员、支撑网管系统维护管理人员、客户服务前台业务受理人员、客户服务专家人员等。客户服务支持系统为客户受理业务代表坐席提供及时的、准确的、简单易懂的网络运行相关的各种信息，更好的保证客户投诉受理人员在较短时间里给客户一个比较满意的答复，提高客户受理的时效性，提高客户的满意度，从而提高客户的忠诚度；同时，通过对客户投诉的各种信息进行汇总、归纳、和知识经验库生成的关联规则，客户服务子系统可以帮助维护部门更好的完成网络维护和网络优化。2.1. 客户服务支持系统功能架构网络客户服务子系统包括以下几个功能模块：1. 系统接口:客服系统与网管系统接口、boss与网管系统接口、e-oms与网管系统接口。2. 客户服务支撑功能：投诉空间位置定位，网络信息发布以及应答知识查询等。3. 客服规则库功能：客服规则库保存客户投诉分析专家的分析经验或客服数据分析系统产生的关联规则等知识，为客服中心操作人员在解决客户投诉或客户服务系统在处理投诉时提供必要的经验或知识支持。对客服经验库的维护和管理包括：动态的添加、修改、删除投诉分析的经验或处理规则。4. 客服分析功能：收集dt、cqt、cdr、网管性能数据等各类数据；分析用户（特别是大客户）投诉从而实现对用户（特别是大客户）活动热点区域的保障；通过对用户投诉的综合分析，和网络隐性故障的判断，为网络优化提供参考信息。5. 用户相关数据核查功能：对单个用户或批量用户的hlr数据进行实时核查；定期对hlr中用户自定义数据进行主动清查；通过各种方式对存在的问题进行解决。2.2. 客户服务支撑功能网络客户服务支撑子系统把各种网络信息（如断站，hlr退服，msc退服，高拥塞，高掉话，网元割接等），以在线方式直接提供给客服系统，以便客服中心的客户服务人员快速有效的解决客户投诉，提高客户满意度，为更好地开展市场服务提供有力支撑。2.2.1. 应答知识查询功能系统收到用户投诉以后，根据投诉的类别和现象的关键字，到知识库中提取规则，并对相关数据进行分析，然后根据分析结果，得出可能的原因及处理建议。2.2.2. 投诉信息定位功能通过用户提供的地理位置信息，按一定的范围（可自定义）进行定位搜索（直接定位，或位置匹配），确定出比较准确的投诉位置区域，通过gis或文本的方式呈现给操作人员。2.2.2.1. gis功能客户服务支持系统是基于地图发布技术、空间数据管理与分析技术，在企业internet/intranet上，采用三层体系结构的地理信息系统。它以b/s方式在终端上直观地反映全网的网络运行状况，可以方便地调用、查询网络的各种信息。2.2.2.2. 用户地理位置定位和相关网元定位固定电话投诉或非现场投诉，根据用户提供的故障发生位置的确切街道名称或者周围标志性建筑物名称，比较准确的确定出投诉位置区域和相关网元，以gis或文本数据的方式呈现。2.2.2.3. 根据用户号码确定该用户的归属hlr/地区根据用户号码确定该用户的hlr。对于本地用户，提供归属hlr查询功能，对于漫游用户给出提示。2.2.2.4. 根据用户号码确定所在小区位置及其他信息对于用户用手机在投诉现场投诉，如果是本地用户，则根据用户的号码进行用户数据查询，定位用户所在lac，ci及其它相关信息（如sgsn号码根据厂家机型是否支持提供）。2.2.3. 网络信息发布及时发布网络重大信息，使客服人员能及时掌握网络运行状况。网络信息指网络告警信息、网络性能告警信息、网络调整信息等，发布的方式可采用人工录入的方式或系统自动生成的方式。2.2.3.1. 实时查询网络信息 用户只需在电子地图上点击相应的网元，系统即可自动查询出该网元的状态（基站是否断站等）及各种用户数据（如gprs,短信开通，长权，漫游限制数据等）。2.2.3.2. 网络告警导致服务受影响的信息发布及时把对网络服务产生影响的各种告警发布到客户服务系统。从综合告警分析子系统中提取分析结果，以gis或文本等方式呈现给客服人员。2.2.3.3. 网络性能导致的服务受影响的信息发布及时把对网络服务产生影响的网络性能信息发布到客户服务系统。从综合性能分析子系统中提取分析结果，以gis方式或文本等方式呈现给客服人员。2.2.3.4. 网络调整信息发布系统把各种重要的网络调整信息（如割接，版本升级等调整信息），和该网络调整可能影响到的区域、时间、号段等信息进行预计，并以gis或文本等方式显示，在明显的位置发布。以便客服人员及时向用户作出满意的答复。2.2.3.5. 网络信息翻译呈现给客服人员的故障，应按投诉类型进行数据翻译，将告警数据、性能数据、优化信息转换成客服人员能理解的信息，如断电、基站故障、信号弱等。2.2.4. 终端功能本系统需要在客户服务中心配置终端，供客服专家使用。2.2.4.1. 功能需求l 以gis或文本等方式呈现网络信息和客户分析子系统提供的数据。l 显示网络调整信息。l 查询与投诉处理相关的数据（如用户定位），并进行用户数据核查等处理。2.2.4.2. 性能需求为了保证终端座席能及时准确的为客户提供服务，要求系