移动分组网监控系统功能规范--中国联通.doc

i 中国联通移动分组网监控系统功能规范中国联通移动分组网监控系统功能规范 （v5.0v5.0） 2010 年 05 月 ii 目 次 一. 系统建设背景 .1 二. 文件组成 .1 三. 系统定位 .1 四. 系统应用场景 .2 五. 总体技术要求 .3 1. 总体要求3 2. 系统部署3 3. 系统功能框架4 3.1 总部系统功能框架 .4 3.2 省分系统功能框架 .4 4. 软件结构5 5. 组网结构6 6. 链路采集要求7 7. 主机系统要求7 8. 数据库系统7 9. 存储系统7 10. 广域网组织8 11. 操作系统要求8 12. 图形用户界面要求8 12.1 基本要求 8 12.2 界面锁定和激活 9 13. 接口要求9 14. 时间同步要求9 iii 15. 其他要求.10 16. 系统主要技术指标要求.10 六. 省级系统功能 11 1. 数据采集存储功能.11 1.1 协议分析要求 11 1.2 信令数据采集存储层功能 13 2. 应用层功能.13 2.1 配置管理 13 2.2 实时网络指标监视 14 2.3 实时信令跟踪 17 2.4 xdr 查询.19 2.5 协议分析 19 2.6 用户行为分析 19 2.7 业务质量分析 23 2.8 网络质量分析 25 2.9 数据关联分析 28 2.10 用户投诉处理 .29 2.11 上网日志留存 .30 2.12 网络安全检测功能 .31 3. 报表管理.31 3.1 报表模板定制功能 31 3.2 报表自定义 32 3.3 报表自动生成功能 32 3.4 报表门限管理 32 3.5 报表任务管理 33 3.6 报表呈现 33 3.7 报表发布及输出 33 3.8 报表存储 33 七. 总部系统功能 33 iv 1. 省分数据统计分析功能.33 1.1 全网网络质量统计分析 33 1.2 全网业务质量统计分析 34 1.3 全网终端使用统计分析 34 1.4 全网用户行为统计分析 34 1.5 统计信息呈现 34 1.6 采集周期 34 2. 国际业务漫游分析功能.35 2.1 信令数据分析 35 2.2 信令实时跟踪 35 2.3 业务质量监控及分析 37 2.4 网络质量监控及分析 38 2.5 失败原因分析 39 2.6 设备告警管理 40 3. 远程访问省分系统.40 4. 报表功能.40 4.1 报表模板定制功能 40 4.2 报表自定义 41 4.3 报表自动生成功能 41 4.4 报表门限管理 42 4.5 报表任务管理 42 4.6 报表呈现 42 4.7 报表发布及输出 42 八. 系统管理功能 42 1 一. 系统建设背景 随着 3g 网络的日趋完善，高速移动数据业务成为联通业务发展的新重点。现有移 动分组网维护手段单一，仅通过移动综合网管和厂家网管进行维护， 而目前的网管支撑 系统，更多的是面向网络、面向设备，关注的是网络设备的性能与告警。在网络质量监 测方面：现有的网管仅能粗线条的统计，无法按业务类型细分；在业务质量分析方面： 现有的网管只能管理网元层面，无法统计业务层信息；在故障处理方面：无法关联端到 端全过程中的所有信令消息，不能存储信令消息，无法对信令消息进行历史查询功能。 综合以上各种情况和要求，联通移动分组网信令监测分析系统的建设是必须且紧迫 的。 二. 文件组成 中国联通移动网信令监测分析系统相关规范包括： （1）中国联通移动分组网信令监测分析系统系统架构及功能需求 （2）中国联通移动分组网信令监测分析系统采集设备技术规范 （3）中国联通移动分组网信令监测分析 系统与第三方应用系统开放接口的信息 模型 本文件为中国联通移动分组网信令监测分析系统系统架构及功能需求 。 三. 系统定位 分组网信令监测系统是移动通信网运行维护的重要支撑系统之一， 系统以不影响网 络运行的高阻跨接、端口镜像、分光 等方式采集各类信令和协议数据，进行信令协议解 码，合成 xdr（包括 sdr-session detail record 和 tdr-transaction detail record），再 现业务接续全过程，进行网络和业务各类指标统计，从而帮助网络维护和分析人员掌握 分析网络与业务运行情况。 系统最基本、最核心功能是协议分析、呼叫跟踪，此外提供网络告警和预警，精细 化的网络分析、业务分析和用户分析等功能 。系统是新业务开通测试、处理用户投诉时 诊断网络故障、网络和业务运行质量精细化分析的有力工具，同时也是获得网络和业务 kpi 指标的数据源之一。 四. 系统应用场景 分组网信令监测分析系统的应用需求大致包括：辅助故障排查、网络实时 性能监 2 视、网络质量分析、业务质量分析、用户行为分析、 用户上网日志留存等方面。 在应用场景上，具体包括（但不限于）下述情况： （1）用户投诉处理、网络故障处理：通过协议分析、呼叫跟踪、 xdr 查询等功能 模块进行业务信令流程的详细分析，从而对用户网络投诉进行故障定位，对网络故障进 行诊断分析。 （2）网络实时监视：监测系统可提供实时网络质量监视 ，其网络指标实时性强、 粒度细，可提供关键网络指标的实时监视。借助监测系统，可及时掌握网络运行情况， 先于用户投诉发现、解决网络故障，从而实现预防性网络维护，有力支撑重要客户的通 信监护、重大活动的通信保障工作。 （3）网络质量分析：对 kpi 指标进行基于失败原因的精细化分析，从影响力最大 的因素入手，主动地从根源上改善网络质量。 （4）业务质量分析：通过监测系统掌握业务质量情况， 为市场部门提供支撑。 （5）用户行为分析：通过对特定客户(例如集团专用 vpdn 或 vip 用户)进行相关 分析,能定期的对该用户的使用情况（流量情况、用户数情况、业务运行情况）进行统计 分析并形成报表，为集团客户的业务营销、业务保障提供有效支撑。 （6）手机终端信息库：通过收集用户数据业务使用过程中的信令，学习不同类型 手机终端的能力信息，建立 手机终端的基本能力信息库。信息库应保存不同类型终端的 参数信息，至少包括：终端厂家、型号、 imei 前缀、是否支持 mms、是否支持 wcdma、操作系统、软件版本等，同时， 还应支持对该信息库的手动维护。 （7）网络安全检测：通过统计主要风险端口或病毒端口上面发起业务的次数、突 发流量和对防火墙 syslog 分析，监测移动分组网安全状态 。 （8）欺诈分析：通过监测系统追踪、封堵 “一号多卡”等。 （9）上网日志留存 五. 总体技术要求 1. 总体要求 移动分组网信令监测分析系统应具有分布式、分层、模块化、可组合、可伸缩的体 系架构。系统体系架构应能够保证系统稳定、可靠、高性能运行；适应被监测网络和业 务系统的变化；具备良好的可扩展性和开放性。 3 2. 系统部署 系统采用部省两级结构进行部署： 移移动动分分组组网网信信令令监监测测分分析析系系统统（总总部部） 移移动动分分组组网网信信令令监监测测分分析析系系统统（省省分分） 省级业务应用 信令采集存储层 网网元元层层 部省接口 1）省分系统采集、处理、存储、分析本省信息，跟踪处理 省内故障，提供第三方 接口，向其他系统提供所需的数据，并根据总部要求，上报相关数据 2）总部系统： -存储、统计、分析、汇总各省上报的数据 统计各省指标，横向对比省间的性能差异 能够提供给业务部门全国性数据 -采集、处理、存储、分析国际业务漫游信息，跟踪处理 国际业务漫游故障 3）部省接口现阶段采用 ftp 方式，后续可以根据需求使用 web service、socket 或 cobra+xml 等接口。 4）总部系统应能远程登录省分系统。 3. 系统功能框架 3.1 总部系统功能框架 中国联通移动分组网信令监测分析系统总部系统 的主要功能包括： （1）省份数据统计分析功能 （2）国际业务漫游分析功能 （3）报表管理功能 （4）远程登录省分系统功能 4 （5）系统管理 （6）数据采集、预处理及存储功能 移移动动分分组组网网信信令令监监测测分分析析系系统统（总总部部） 移移动动分分组组网网信信令令监监测测分分析析系系统统（省省分分） 部部省省接接口口 省省分分数数据据统统计计分分析析功功能能 全全网网 网网络络 质质量量 统统计计 分分析析 全全网网 业业务务 质质量量 统统计计 分分析析 全全网网 终终端端 使使用用 统统计计 分分析析 系系统统 管管理理 数数据据采采集集、预预处处理理及及存存储储 报报 表表 管管 理理 g gp p接接口口采采集集 国国际际业业务务漫漫游游分分析析功功能能 业业务务质质量量分分析析 网网络络质质量量分分析析 失失败败原原因因分分析析 设设备备故故障障管管理理 信信令令分分析析 信信令令跟跟踪踪 接接口口a a 远远程程 访访问问 省省分分 系系统统 全全网网 用用户户 行行为为 统统计计 分分析析 s sn nm mp p b bg g防防火火墙墙 3.2 省分系统功能框架 3.2.1 功能框架 中国联通移动分组网信令监测分析系统省分系统功能包括信令数据采集存储层、上 层应用两个部分，其中信令数据采集存储层还可以分为信令数据采集层 、信令处理层和 数据存储等，信令数据采集层强调监测系统要解析哪些接口网络协议。数据处理层 则是 对已采集到的信令消息、业务信息等数据进行解码、合并等后处理 生成 xdr 文件，为 监测系统上层应用提供符合内容、格式要求的数据支持。 信令采集存储层还包括数据存 储功能，负责存储原始信令数据和处理后生成的 xdr 数据。 信令数据采集层与上层应用之间通过接口 a 传递信息，与第三方应用之间通过接 口 b 传递信息。 5 g gr r接接口口 采采集集 g gn n接接口口 采采集集 g gi i接接口口 采采集集 i iu u- -p ps s接接 口口采采集集 g gy y接接口口 采采集集 s sg gs sn ng gg gs sn n防防火火墙墙网网元元设设备备层层 s sy ys sl lo og g 文文件件采采 集集 采采 集集 层层 处处 理理 层层 数数据据分分发发单单元元 信信令令预预处处理理单单元元信信令令分分析析处处理理单单元元数数据据 存存储储 信信 令令 采采 集集 存存 储储 层层 应应 用用 层层 系系统统管管理理 报报表表管管理理 实实时时信信令令跟跟踪踪 实实时时网网络络指指标标监监视视 x xd dr r查查询询 i ip p溯溯源源 用用户户行行为为分分析析 业业务务质质量量分分析析 网网络络质质量量分分析析 数数据据关关联联分分析析 用用户户投投诉诉处处理理 r rn nc c 第第三三方方 接接口口 第第三三方方应应用用 协协议议分分析析 配配置置管管理理 接接口口a a 接接口口b b b bg g g gp p接接口口 防防火火墙墙 b bs sc c/ /p pc cu uh hl lr r g gb b接接口口 采采集集 网网络络安安全全检检测测 g ga a接接口口 采采集集 g gp p接接口口 采采集集 注：上图中虚线框中的网元/功能只在北京和广州部署。 3.2.2 xdr 定义 xdr 是会话信令记录（ssr-session signalling record）经过处理后生成的记录文件， 包括 sdr（session detail record）和 tdr（transaction detail record）。 ssr(session signalling record)：会话信令记录，记录一次 session 过程中产生的所 有原始信令消息。 tdr(transaction detail record)：每一次 transaction 生成的记录，包括一次双向交 互的信令，如 createpdp request 和 createpdp response 对应一个 tdr。 sdr(session detail record)：一次 session 结束后生成的一条完整 session 记录信息， 即用户一次 createpdp request 到 deletepdp response 完整的交互将生成 1 个 sdr。 4. 软件结构 移动分组网信令监测分析系统从软件结构上可划分为 “采集部分”、“数据处理部 分”、“数据存储部分”、“应用部分”、“系统管理部分”、“第三方接口部分”。 系统软件结构如下图所示： 6 系 统 管 理 实时 网络 指标 监视 实 时 信 令 跟 踪 用 户 行 为 分 析 业 务 质 量 分 析 ip 溯 源 用 户 投 诉 处 理 数 据 关 联 分 析 报 表 管 理 . . 系 统 接 口 协议解 码 告警生 成 xdr 生成 数据库和 文件系统 e1接口仪表接口ip端口. . 控制 控制 控制 信令消息流 实时数据 原始消息 xdr 告警 数据库操作和文件操作 实时数据 数据库操作和文件 操作 . . 网 络 质 量 分 析 采集部分 数据处理部分 应用部分 5. 组网结构 移动网信令监测系统从组网结构上划分为 “采集设备”、“数据处理设备”、 “数据库和文件服务器”、“应用服务器”、“用户终端”、“接口服务器”、“专用 网络”几大部分。监测系统组网结构具体如下图所示。 7 6. 链路采集要求 信令监测分析系统应采取有效手段将需采集点链路接入系统， 系统应独立于通信网 络之外。监测系统应保证在任何情况下均不会干扰通信网络的正常运行。 7. 主机系统要求 （1）主机系统应运行稳定，硬件性能优良、运行可靠，平均故障时间间隔应大于 1 年，故障平均修复时间应小于 1 小时； （2）主机系统是监测系统中的关键资源，需保证 7*24 小时连续运行，因而要求具 有较高的可靠性和容错能力； （3）为适应系统容量的增加，硬件设备应具备较强的扩展能力，并应具备升级和 向后兼容的能力，包括系统处理能力的扩充、内存容量的扩容、存储容量的扩充及i/o 能力、节点数的扩充等等；并支持 cpu 的板级升级和节点级的平滑扩充； （4）监测分析系统要求采用通用的计算机系统，支持分布式系统结构； （5）服务器硬件平台应支持主流通用操作系统； （6）采集机可采用专用采集设备或通用 pc 服务器，采集机必须具备本地数据存 储能力，至少存储 8 小时原始信令数据（gp 接口采集机本地数据存储至少具备存储 24 小时原始信令数据的能力） 。 8. 数据库系统 （1）支持主流厂商硬件及主流操作系统平台； （2）数据库系统应支持市场流行的多并行处理机； （3）数据库系统应具有良好的扩展性（如从单 cpu 到多 cpu 的扩充及处理节点 的扩充，在不影响数据库正常运行的情况下更新系统，原有应用可以无损失移植）； （4）开放性方面要求应支持异种数据库的互访： （5）支持联机备份功能； （6）提供 web 服务接口模块； （7）数据库、表大小等技术参数可灵活设置，支持对大数据量处理的技术需求； （8）支持中文汉字内码，符合双字节编码； （9）监测系统的数据库表结构设计应合理优化，满足对各项操作时延的要求。 9. 存储系统 （1）存储容量要求 8 监测系统的存储系统应满足以下要求： a)原始信令消息保存 7 天； b)xdr 等记录保存 3 个月； c)门限告警记录保存 1 年； d)实时指标保存 3 个月； e)统计报表保存 3 年。 监测系统可根据需要做备份存储。 （2）存储系统的磁盘阵列设备主要用作系统数据的联机存储，需 7*24 小时连续 运行。 10. 广域网组织 广域网部分可以采用 dcn 或 ip 专网方式组网。 须采用可靠的传输网进行传送。通信网络的容量须满足联通信令网集中监测维护系 统各前端接入系统与中心站的连接传输容量。 11. 操作系统要求 （1）操作系统软件应具有开放性、 可靠性和较高容错能力，不易崩溃且具有良好 的故障恢复能力； （2）操作系统应具有较强的网络功能，应能支持通用的网络协议； （3）操作系统软件应具备升级能力，并能做到向后兼容； （4）操作系统应支持多终端、多用户操作； （5）操作系统应同时支持字符终端和图形界面 。 12. 图形用户界面要求 12.1 基本要求 图形用户界面（gui）是一种可视化的用户界面，可以为用户提供便捷的方式以满 足用户对设备进行管理的需求。 （1）界面直观，对用户透明：用户接触软件后可对界面上对应的功能一目了然， 即要求界面设计遵循界面简洁，线索清晰的原则。 （2）图形用户界面的设计应遵循一致性原则：界面和功能的一致性可使操作人员 更快使用保留字来增加系统的清晰易懂、提高系统的使用效率。操作方式的一致性可以 9 尽可能的减少误操作的产生。 （3）图形用户界面应该对操作结果提供必要的图形和声音提示：提示信息可使用 户了解目前系统所处的状态，明白命令执行的结果是否正确，以及操作的进行情况等。 举例来说，当一个操作的系统响应时间超过 7-10s 时，应该用一个带有进度条的信息框 提示当前用户的执行情况。 （4）图形用户界面应该集成在线帮助功能：图形用户界面应提供详细的在线操作 指南，对操作方式，操作步骤，输入格式等信息进行帮助提示，指导用户完成相应的操 作并提供帮助信息的导航功能。同时，对用户可能遇到的问题提供解答，用户可以打印 帮助信息。 （5）系统界面、在线帮助、报表报告应提供中文和英文两种选择，并可根据 操作 员需求设置。 （6）对于常用的表格呈现，应至少具备： a)应能够提供数据分页显示。 b)应能够提供标题行、关键列冻结显示。 c)应能够按奇偶行变换颜色显示。 （7）对于常用的图形呈现，应至少具备： a)应提供多种图形显示方式：直方图、曲线图、饼图、仪表盘等。 b)根据信息呈现的需要，应能够提供合适的图形进行切换呈现。 12.2 界面锁定和激活 为防止在用户离开时未授权人员对网管系统操作，网管系统应提供界面锁定和激活 功能。 13. 接口要求 系统应具备向第三方开放接口的能力，接口形式应包括： ftp、数据库、 webservice、socket 等接口。 系统满足工业和信息化部电信业务市场综合管理信息系统与企业网站内容拨测系 统之间的接口规范要求。 14. 时间同步要求 监测系统内时间同步方式为 ntp 同步，绝对时间同步方式为 gps 时间同步、与时 10 钟同步系统（bits）同步。 15. 其他要求 系统应在所有提供数据查询功能的地方提供数据的排序、过滤、打印、数据导出等 功能。查询过滤条件设置应支持与、或、非等逻辑运算，支持通配符，支持等于、不等 于、大于、小于、in 等关系运算。 系统应支持用户设定并保存多个监视或查询条件，当用户再次开启监视或查询应用 时，可直接使用预存的查询条件。 系统应对网络、业务、用户分析提供从大粒度数据到细粒度数据的逐层深入分析， 并提供相关 xdr 数据、呼叫流程的关联查询。 16. 系统主要技术指标要求 no分类分类指标指标参考值参考值 1系统可用性99.99% 2 总体指标 系统故障修复时间1 小时 3信令消息丢失率10-7 4xdr 合成准确性99.999% 5时钟同步精度5 毫秒 6采集时延（实时接口，从采集完成到呈现）10 秒 7 采集和处理指标 采集时延（文件接口，从采集完成到呈现）60 秒 8监测链路数（e1）2000 个 9数据处理量（gbps）20gbps 10 容量指标 系统用户数100 个 11告警时延5 秒 12并发实时跟踪用户数100 个 13实时监测操作响应时延10 秒 14普通操作响应时延5 秒 15 性能指标 复杂查询响应时延15 秒 16原始消息7 天 17xdr 数据3 月 18门限告警数据1 年 19实时指标数据3 月 20 存储指标 报表数据3 年 11 六. 省级系统功能 1. 数据采集存储功能 1.1 协议分析要求 系统应至少具备分析以下协议的能力： 1.1.1 gn 接口协议分析 （1）gtp-c 协议分析 （2）dns 协议（gsn 域名解析）分析 （3）gtp-u 协议分析 a)封装在 gtp-u 中的 ip、tcp、udp 协议 b)http 协议分析 c)ftp 协议分析 d)wap 协议分析 e)mms 协议分析 f)imap/pop3/smtp 协议分析 g)sip/sdp 协议分析 h)rtsp 协议分析 i)rtcp/rtp 协议 j)dns 协议分析 k)p2p 协议分析 1.1.2 gi 接口协议分析能力 （1）radius 协议分析 （2）l2tp 协议分析 1.1.3 gp 接口协议分析能力 （1）gtp-c 协议分析 （2）dns 协议（gsn 域名解析）分析 （3）gtp-u 协议分析 a)封装在 gtp-u 中的 ip、tcp、udp 协议 b)http 协议分析 12 c)ftp 协议分析 d)wap 协议分析 e)mms 协议分析 f)imap/pop3/smtp 协议分析 g)sip/sdp 协议分析 h)rtsp 协议分析 i)rtcp/rtp j)dns 协议分析 k)p2p 协议分析 1.1.4 gr 接口协议分析能力 （1）mtp 协议分析 （2）sccp 协议分析 （3）tcap 协议分析 （4）map 协议分析 1.1.5 iu-ps 接口协议分析能力 （1）m3ua 协议分析 （2）sctp 协议分析 （3）sccp 协议分析 （4）ranap 协议分析 1.1.6 gb 接口协议分析能力 （1）bssgp 协议分析 （2）llc 协议分析 （3）sndcp 协议分析 1.1.7 gy 接口协议分析能力 （1）diameter 协议分析 1.1.8 ga 接口协议分析能力 （1）gtp协议分析 13 1.2 信令数据采集存储层功能 信令数据采集存储层分为信令数据采集层、信令处理 层和数据存储等，其中： （1）信令数据采集层不间断地采集链路中的信令数据 ，并为原始信令消息加时间 戳，将信令消息流发送到数据处理层 ； （2）数据处理层对已采集到的信令消息、业务信息等数据进行解码、合并等后处 理生成 xdr 文件； （3）数据存储功能，负责存储原始信令数据和处理后生成的 xdr 数据； （4）信令数据采集存储层通过开放的接口，向第三方应用提供所需的数据 支持 （包括完整的原始采集数据）。 2. 应用层功能 中国联通分组网信令监测分析系统的主要应用功能包括配置管理、实时网络指标监 视、实时信令跟踪、协议分析、用户行为分析、业务质量分析、网络质量分析、数据关 联分析、上网日志留存、报表管理等。 2.1 配置管理 系统应能够从信令数据中自动 发现新增设备，并能自动将新设备添加至系统或提示 维护人员手动添加至系统；在网络中网元数据发生变化时，系统也应能及时提示维护人 员进行修改；系统能够支持批量配置的导入和导出，并能对所有配置数据提供显示、创 建、删除、修改功能。系统应支持树图、数据表格、网络拓扑图形式展示配置数据。 网元配置信息应至少包括： （1）网元名称 （2）与该网元相关的 ip 地址列表 （3）gt （4）信令点编码 （5）该网元所辖业务区列表 （6）与该网元相关的 rnc、bsc 列表（应与业务区列表关联） （7）与该网元相关的小区列表（ 应与 rnc、bsc 列表关联） （8）与该网元相关的路由区列表（应标识出 2g、3g，应与 rnc、bsc 列表关联） （9）设备厂家 14 （10）设备硬件版本 （11）设备软件版本 （12）安装地点 2.2 实时网络指标监视 2.2.1 基本功能要求 （1）系统提供网络和业务 kpi 实时监视，系统根据最小时间粒度 （至少支持 1 分 钟）自动更新实时监视数据，支持数据列表、拓扑图、折线图、柱形图、饼图等显示方 式，支持灵活的监视指标和监视范围设置。 （2）实时网络指标监控应能支持按照地市 、网元、rnc/bsc、小区、业务流向等 纬度对指定的指标进行统计、呈现。 2.2.2 门限告警管理 系统支持对网络指标、业务指标设置 多级预警门限，维护人员可以对监控的重要 kpi 指标和网络资源使用情况自定义告警类别和门限值，可自行定义网络延时门限告警 ， 当满足不同级别的预警条件时，将产生不同的预警信息。 系统可以根据网络运行情况自动生成各类指标的 历史基准线，并根据系统生成的指 标基准线，针对指标的历史基准偏离度产生告警（而不是固定阀值） ，例如，gn 网络 节点，早上 5:30-5:45 的历史基准带宽剩用率为 15%，如果当天早上 5:30-5:45 的带宽剩 用率为 30%，能够马上产生告警。 2.2.3 门限告警呈现 系统提供网络指标监视窗口，支持列表和网络拓扑图两种显示方式；支持以不同颜 色区分门限告警级别，支持用户自定义告警颜色；支持根据告警类型和告警级别设置过 滤条件。 另外，系统还应能支持声光告警方式，可通过自定义方式对预设的告警以声光的方 式呈现。 2.2.4 告警信息前转 系统可根据设置的前转规则，将重大告警信息通过短信转发至维护人员的手机，系 统提供界面供维护人员自定义告警的前转人群范围。 2.2.5 实时网络指标监视范围 网络指标监视范围应采用模块化单元管理，用户可根据侧重点不同自定义设置网络 15 指标进行监控。 实时网络指标监视范围见下表。 序 号类型指标 分析维度 1gprs 附着成功次数 2gprs 附着请求次数 3gprs 附着拒绝次数 4gprs 附着成功率 小区、rnc/pcu、路由区、sgsn、地市、 全省 5sgsn 内部路由区更新请求次数 6sgsn 内部路由区更新成功次数 7sgsn 内部路由区更新成功率 8sgsn 间路由区更新请求次数 9sgsn 间路由区更新成功次数 10sgsn 间路由区更新成功率 11sgsn 路由区更新成功率 rnc/pcu、sgsn、地市、全省 12 sgsn 内部从 2g 到 3g 切换请求的次 数 13 sgsn 内部从 2g 到 3g 切换成功的次 数 14 sgnn 内部从 3g 到 2g 切换请求的次 数 15 sgsn 内部从 3g 到 2g 切换成功的次 数 16sgsn 内系统间切换成功率 rnc/pcu、sgsn、地市、全省 17sgsn 内 srns 重定位请求次数 18sgsn 内 srns 重定位成功次数 19sgsn 之间 srns 重定位请求次数 20sgsn 之间 srns 重定位成功次数 21sgsn 内 srns 重定位成功率 22sgsn 间 srns 重定位成功率 23srns 重定位成功率 rnc/pcu、sgsn、地市、全省 24鉴权请求次数 25鉴权成功次数 26鉴权成功率 sgsn、地市、全省 27寻呼次数 28寻呼成功响应次数 29寻呼成功率 rnc/pcu、路由区、sgsn、地市、全省 30pdp 上下文激活请求次数 31pdp 上下文激活成功次数 32pdp 上下文激活拒绝次数 33pdp 上下文激活成功率 34pdp 上下文去激活请求次数 35pdp 上下文去激活成功次数 36pdp 上下文去激活成功率 37pdp 上下文修改请求次数 38pdp 上下文去修改成功次数 39pdp 上下文去修改成功率 40二次 pdp 上下文激活成功次数 41 网络质 量 二次 pdp 上下文激活请求次数 小区、rnc/pcu、sgsn、apn、地市、全 省 16 42二次 pdp 上下文激活成功率 43iu-ps 上行平均速率 44iu-ps 下行平均速率 rnc/pcu、sgsn、地市、全省 45gn/gp 接口 gtp 上行流量 46gn/gp 接口 gtp 下行流量 47gn/gp 接口上行包吞吐量 48gn/gp 接口下行包吞吐量 sgsn、apn、地市、全省 49dns 解析请求次数 50dns 解析成功次数 51dns 解析成功率 sgsn、apn、地市、全省 52gi 接口上行流量 53gi 接口下行流量 54gi 接口上行包吞吐量 55gi 接口下行包吞吐量 56gi 接口 aaa 鉴权请求次数 57gi 接口 aaa 鉴权成功次数 58gi 接口 aaa 鉴权成功率 ggsn、apn、aaa 服务器、地市、全省 59彩信业务分析 60-彩信业务 mo 次数 61-彩信业务 mo 成功次数 62-彩信业务 mo 成功率 63-彩信业务 mt 次数 64-彩信业务 mt 成功次数 65-彩信业务 mt 成功率 66http 业务分析 67-http 业务请求次数 68-http 业务成功次数 69-http 业务成功率 70wap/3g web 业务分析 71-wap/3g web 业务请求次数 72-wap/3g web 业务成功次数 73-wap/3g web 业务成功率 74email 业务分析 75-email 业务请求次数 76-email 业务成功次数 77-email 业务成功率 78sip 业务分析 79-sip 协议注册请求次数 80-sip 协议注册成功次数 81-sip 协议注册成功率 82流媒体业务分析 83-流媒体业务播放请求次数 84-流媒体业务播放成功次数 85-流媒体业务播放成功率 86定位类业务分析 87-定位业务请求次数 88-定位业务成功次数 89 业务质 量 -定位业务成功率 rnc/pcu、sgsn、ggsn、地市、全省 17 2.2.6 保存 系统支持对实时网络指标的的全部或部分进行保存，对于保存的数据可以打开查看， 系统支持将结果导出为 txt 或 excel 文件。 另外，系统还应支持实时指标监控功能生成的各类 相关图形（如偏离图、曲线图等） 文件导出。 2.3 实时信令跟踪 能够根据指定用户号码（msisdn 或 imsi）或号段（能支持至 msisdn 或 imsi 的后四位），实时关联分析各接口信令流程及用户业务使用过程，用于故障排除及其他 用途，用户号码或号段可以支持 excel、txt 文件导入。 实时信令跟踪提供对某一业务流程完整信令过程的跟踪，从而协助用户分析网络实 体之间信令配合问题或网络异常。系统应能对指定呼叫的所有相关信令流程进行关联， 包括多段（核心网部分各部分）、多协议关联。同时，系统应具备同时跟踪多个用户号 码呼叫的能力。 呼叫跟踪提供的信息包括专业域、状态、sdr id、tdr id、开始时间、结束时间、 持续时间、imsi、apn、用户终端、链路方向、物理链路（ip 地址端口号）、逻辑链 路、消息内容和帧数等。 实时呼叫跟踪的流程显示可分为一般格式、详细格式和协议层方式。时间戳的显示 分为绝对时间和相对时间两种方式 ，信令流程应能以下图方式呈现 ，在信令流程图上点 击任何一条信令消息应能查看详细的信令解码信息。 18 系统支持用户设置灵活的过滤条件，并可保存设置条件。系统支持对条件进行合理 的逻辑组合。系统支持的过滤条件如下： （1）号码 包括用户号码（imsi，msisdn、tmsi/p-tmsi）或号段 （2）区域范围 包括 cell id、opc、dpc、sgsn、ggsn、ip 地址等 （3）时间范围 （4）apn （5）业务类型 包括 wap、3g web、http、ftp、email、mms、sip、流媒体、定位等 系统可以将用户监测的条件保存为模板，便于用户后续使用过程中重复使用。 系统支持对呼叫跟踪结果的全部或部分进行保存，对于保存的数据可以打开查看。 系统支持将跟踪结果（原始消息及消息解码）导出为 cap 文件。 19 2.4 xdr 查询 系统提供各类 xdr 查询功能，支持按 xdr 各字段进行排序、过滤、统计，查询基 本条件包括时间、imsi、msisdn、ogt、dgt、opc、dpc、ip 地址等，并提供 xdr 消息完整性百分比查询。 系统能够根据指定 xdr 查询原始消息，重现呼叫过程。系统支持对指定 xdr 的多 段（接口范围应至少能涵盖本章 1.1 节中的所有接口）、多协议关联分析，关联要求同 实时信令跟踪。 系统能够将查询结果进行全部或者部分保存。 2.5 协议分析 协议分析为用户提供监测范围内链路上信令消息的 监测，支持按照协议栈层次结构 方式显示协议解码结果，支持按照呼叫流程对消息排序，并可对不识别的信令消息、离 散的信令消息进行分类统计。 系统支持用户设置灵活的过滤条件，并可保存设置条件。系统支持对条件进行合理 的逻辑组合。 2.6 用户行为分析 用户行为分析应能根据用户指定条件（如时间段、区域、用户群）， 支持按照地 市进行呈现、统计。 2.6.1 用户分布分析 可按时间、地域进行检索、统计分析并生成报表及报告。具体要求如下： 时间：可按小时、日、周、月（区别工作日与节假日）收集分类； 地域：可按用户所在的小区收集相关数据，进行分析，结合实际地理位置、号段数 据形成相关报表及报告. 能够通过信令的采集，对不同的用户行为进行不同维度的统计分析；能够通过对统 计结果的分析，了解用户访问的热点；最终显示饼形图、柱形图、折线图，并出具相关 报表及报告；能够直接输出分析报告。 （1）本地用户分布分析 通过信令数据结合用户流量细化分析本网内用户的位置分布，帮助维护人员深入掌 握网络性能，快速定位分析问题 。 （2）漫游用户分布分析 20 通过信令数据细化分析漫游到本地网的用户位置分布，帮助维护人员深入掌握网络 性能，快速定位分析问题。 （3）省内漫游用户分布分析 通过信令数据细化分析本网漫游到省内其他城市的用户进行位置分布，帮助维护人 员很直观了解到省内漫游用户分布情况。 （4）国内漫游用户分布分析 通过信令数据细化分析本网内用户漫游到各省分布情况，帮助维护 人员很直观了解 到目前分布情况。 2.6.2 用户使用行为分析 （1）用户使用业务类型分析 对其用户所使用业务种类和类型进行统计，分析用户使用业务的行为习惯。 （2）用户使用业务量分析 对其用户所使用业务种类和数量进行统计，分析用户使用业务的行为习惯。 （3）基于终端的用户统计分析 系统应提供潜在用户分析功能：即能根据一些由于终端设置或用户签约原因导致的 失败值进行统计，并结合手机能力信息库形成潜在用户报表，例如对那些终端具备3g 功能但仅使用 gprs 服务的用户，或者未开通 gprs 业务但尝试使用的用户定期形成数 据，为后续的潜在用户发掘和营销提供数据支持，同时也可以减少由于用户自身行为而 导致的使用投诉。 系统应能结合终端信息库按时间粒度、网元粒度、行政区划对不同手机终端的业务 使用情况（至少包括但不限于：设备数量、流量大小及占比、平均吞吐率、平均丢包率、 平均往返时延）进行统计分析。 2.6.3 业务倾向性分析 （1）用户业务网站访问统计 统计业务网站访问排名，同时实现针对个别网站统计访问量、访问用户（不同用户） ，访问趋势等。 通过统计用户对网站访问量的统计，细化分析本网内用户的访问倾向和习惯，帮助 市场人员深入掌握用户的喜好和消费倾向。 （2）多维度功能统计 可按时间、地域、用户、apn、业务类别、host 等条件进行检索、统计、分析并生 21 成报表及报告。 能够对数据业务进行不同维度的统计分析；能够对通话次数及流量进行不同维度的 数据统计； 对统计结果进行表格、图形的直观呈现；能够直接输出分析报告。 2.6.4 异常用户行为分析 （1）提供用户群发行为特征分析 （2）提供高失败用户失败原因分析 （3）提供用户异常流量/时长行为特征分析 2.6.5 用户错误行为分析 彩信 （1）用户 apn 设置错误 （2）mo 用户设置彩信接收方号码错误 （3）用户终端彩信中心 url 设置错误 （4）群发地址超出网络服务限制 （5）彩信大小超过 100k wap （1）用户 apn 设置错误 （2）错误 url 2.6.6 vip 客户体验分析 vip 客户体验分析侧重以 vip 用户或集团用户为出发点，从业务类型、地域、时间 等角度对用户业务使用量（ 业务流量、业务次数和时长等）、各类型业务的平均使用速 率、使用特征、业务使用的成功率及失败原因 （如附着成功率、激活成功率等） 等方面 分析，优先选择主要业务和重点发展业务，优先选择大客户和重点客户，支持多号码集 团客户的分析。 2.6.7 终端应用分析（终端类型分析、终端质量分析） （1）系统应具备手机终端信息库 ，并能通过收集用户数据业务使用过程中的信令， 学习不同类型手机终端的能力信息，信息库应保存不同类型终端的参数信息，至少应包 括：终端厂家、型号、imei 前缀、是否支持 mms、是否支持 wcdma、操作系统、软 件版本等。系统还应支持对该信息库的手动维护。 该信息库应能同基于终端的用户分析 22 进行关联。 （2）系统应能生成终端类型 top n 排名，提供给市场部门，进一步的业务宣传， 提高业务增长点 （3）系统应能根据按终端类型提取或者发送彩信次数、成功率、传输数据大小排 名，分析终端质量 （4）系统可按终端类型，软件版本以及 website 进行相关查询，并对总访问量， 业务成功率，get 成功率，post 成功率，接口的信令平均时延，最大时延以及最小时 延进行统计 （5）系统可对终端的软件版本进行统计分析 （6）系统可对各类终端业务失败原因进行统计分析（设置问题终端问题软件 问题其他） 2.6.8 “一卡多机”用户行为分析 （1）在一段时间内可根据用户终端信息（ imeisv、ip 地址）、用户位置信息、业 务使用时间等多种信息判断是否存在一卡多机的行为，提供疑似号码列表 。 （2）提供疑似用户所在的位置信息。 2.6.9 黑名单监控管理功能 （1）具备黑名单配置管理功能，系统能够针对黑名单中的用户留存上网记录 ，黑 名单列表可通过接口同步或 excel 导入和导出。 （2）上网记录留存 a)wap 上网取证 能完成对指定 msisdn、网络域名、url、ip 地址或 ip 段进行监控； 能完整记录用户浏览时的各种文件（html 文件、图像文件、文本文件等） ； 能记录用户的 msisdn 和 ip 地址，并识别出用户的归属地和漫游地； 能根据设定的过滤规则对数据进行过滤； 提供强有力的监控证据文件。 b)http 上网取证 能完成对指定 msisdn、网络域名、url、ip 地址或 ip 段进行监控； 能自动识别出非注册的网络域名，并自动启动取证记录； 能对 http 地址进行分析，追踪该域名来源国家和地区，并对访问路由进 23 行跟踪和记录。 能记录用户的 msisdn 和 ip 地址，并识别出用户的归属地和漫游地； 能根据设定的过滤规则对数据进行过滤； c)彩信上网取证 能完成对指定主叫、被叫、彩信标题、附件名称进行监控； 能完整记录同一个主叫散播的所有彩信消息及内容； 能记录用户的 msisdn 和 ip 地址，并识别出用户的归属地； d)im 上网取证 能完成对指定 msisdn、ip 地址、url 等进行监控； 能完整记录指定用户发送和接受消息及内容； （3）上网查询 可实现对用户上网日志留存记录的查询。 2.7 业务质量分析 2.7.1 业务基本应用分析 以下要求适用于 2.7 节所有部分。 （1）统计、呈现各业务的流量、流量占比、top n 排名 （2）支持基于某一种协议（标准应用协议、网络协议、自定义端口号）的应用流 量的分析，支持自定义业务组合应用（系列 ip 地址/端口号范围组合）的分析 （3）系统能够基于 web url 识别业务应用，定期发布最受欢迎的 web url topn（根据流量统计）；能够基于指定的 url 进行长期的响应时延统计。 （4）系统应能根据预设的梯度值统计各类业务质量指标，如吞吐率大于某几个阶 梯刻度值（阶梯刻度值可以按经验或后续统计的数据修正）的用户数分别占比，丢包率 大于某几个阶梯刻度值（阶梯刻度值可以按经验或后续统计的数据修正）的用户数分别 占比，时延大于某几个阶梯刻度值（阶梯刻度值可以按经验或后续统计的数据修正）的 用户数分别占比等，以此衡量网络质量和用户感受的近期变化。 （5）业务质量应能基于以下条件分析： a)地市 b)位置信息：cell id、uli、uli 组等 c)用户信息：用户号码（msisdn、imsi）或号段等 24 d)终端信息：imeisv、终端类型、操作系统、软件版本 e)网元：bts、nodeb、bsc/pcu、rnc、sgsn、ggsn f)局向 g)业务：彩信、http、wap/3g web、email、sip、流媒体、定位、p2p、im 等 h)业务提供商（sp）：判断 sp 端到端网络传输质量，提供整改依据，提供直观 的统计图表，对比分析不同 sp 的网络传输时延（网络传输时延以 tcp 连接时 长（三次握手）进行统计）与应用响应时延 i)时间粒度：周期性（5 分钟、15 分钟、30 分钟、1 小时、全天、周、月等）、 任意指定时间段 （6）信息数据钻取 系统应能根据需求将统计指标从大颗粒度的统计钻取至更小颗粒度的统计，如从整 网统计钻取至基于地市的统计、从基于地市的统计钻取至基于网元的统计、从基于网元 的统计钻取至基于局向或其他条件的统计等。 2.7.2 彩信业务分析 （1）彩信 mo 和 mt 成功率分析、失败原因分析及业务响应时延分析； a)失败原因应能区分网络侧失败原因、用户侧失败原因和业务平台侧失败原因 （2）能完成基于 sp 的业务分析； （3）能完成对指定主叫、被叫、彩信标题、附件名称进行监控； （4）能记录用户的 msisdn 和 ip 地址，并识别出用户的归属地； 2.7.3 http 业务分析 （1）能够完成 http 业务成功率分析、失败原因分析及业务时延分析； （2）能完整记录用户浏览的 url 信息； （3）能完成对指定 msisdn、网络域名、url、ip 地址或 ip 段进行分析； （4）能记录用户的 msisdn 和 ip 地址，并识别出用户的归属地和漫游地； （5）能根据设定的过滤规则对数据进行过滤； 2.7.4 wap/3g web 业务分析 （1）能够完成 wap/3g web 业务成功率分析、失败原因分析及业务时延分析； （2）能完成对基于 sp 的 wap 业务分析 25 （3）能完整记录用户浏览的 url 信息； （4）能记录用户的 msisdn 和 ip 地址，并识别出用户的归属地和漫游地； （5）能完成对指定 msisdn、网络域名、url、ip 地址或 ip 段进行分析； （6）能根据设定的过滤规则对数据进行过滤； 2.7.5 email 业务分析 （1）能够完成 email 业务成功率分析、失败原因分析及业务时延分析； （2）能完成对基于 email 业务提供商的 email 业务分析 2.7.6 sip 业务分析 （1）能够完成用户基于 sip 协议的注册成功率、失败原因分析及注册时延分析； 2.7.7 流媒体业务分析 （1）能够完成流媒体业务播放成功率分析、失败原因分析及业务时延分析 （从发 起播放请求至流媒体播放开始） ； （2）能