随着大量新的移动数据增值业务的涌现和2.5g\3g移动网中分组交换代替传统的电路交换，目前以网络为中心的电信维护模式无法对单独的业务在网络中是如何运行的提供有效监控途径。而客户最关心的是其付费购买的电信业务，如何保证客户业务的服务品质是运营商面临的首要问题。虽然理想的情况下，网络是业务的载体，网络管理如果能够保证网络零缺陷运行，则监控和管理单独的业务是不必要的。但实际情况是：网络缺陷是不可避免的。因此，在这种情况下，就必须要监控识别其对各个业务的影响，并知道什么样的网络问题对客户业务影响最大。
同时，由于网络技术的日益复杂，网元的故障对业务很可能并不造成任何影响（如在ip网的多种路由路径存在的情况下）。而从某种业务来看，网络未发生任何故障，业务可能已经出现了问题（如客户认证拥塞）。
以上情况表明，需要面向客户提供一种有效的业务监控手段，实现有效的服务保障。
服务保障在移动网络维护中的地位和作用
根据tmf的定义，服务保障系统是运营支撑业务层的应用系统，其通过对网管、故障管理、性能管理、计费系统、crm系统、网元日志等多种数据源的监控，以客户为中心、从客户/业务角度提供网络缺陷的监控和管理功能，同时实现客户业务的sla管理。
服务保障系统功能的提供，对于迅速发展的移动网络来说，显得更为迫切。表现如下：
* 对于电信固定网来说，客户业务均具有一个固定的业务接入点，因此，客户业务可以固定地和一些网元发生关系。如对于固网语音电话业务来说，通过对网元客户接入端口的监控及资源管理系统的关联查询，可以比较容易地确定故障对客户的影响。虽然随着ip网络在固网的应用，以上关系的确定也越来越困难。但对于移动网来说，其基本的移动特性决定了其业务接入点是随时变化的。同时对于新的移动增值业务，存在多个业务访问点。如对于gprs网络，不同的业务能力可以通过多个ggsn (gateway gprs support nodes)接入，而客户终端可以通过任意sgsn (serving gprs support node)访问业务。因此，通过监控网络告警而保证客户服务质量明显是不充分的。
* 固定网络中，数据业务的传输带宽基本是固定的。而移动网络的数据传输带宽随着不同的接入地点、基站负荷、接入时间而变化。甚至在单独用户一个业务的使用过程中，随着其基站接入用户数量的变化，以及这些用户正在使用的不同业务应用的变化，带宽也是不稳定的。同时，移动电话在不同基站之间的漫游也造成带宽的波动变化。从用户角度出发，其在使用业务的过程中足够和稳定的带宽是其服务质量保证的重要内容，因此以客户为中心，对其在一个业务使用过程中所获得的实际带宽进行监视是十分必要的。
* 对于移动网络来说，不同的网元可能造成不同的延时，如gprs网络中的sgsn、ggsn、hlr及mmsc等业务能力网元，这些延时的监视对于特定业务的服务质量至关重要，如实时性强的互动游戏及流媒体应用等，而某个网元设备网管提供的延时数据对整个业务提供过程的影响是难以判断的。因此，也需要以客户业务为中心，对整个端到端业务过程各环节的延时进行集中监视及管理。
* 如前所述，试验证明原始话单cdr的数据对于衡量客户业务的使用情况是非常有价值的。而原始话单cdr在目前运营支撑系统中通过计费采集系统（mediation）进行采集并提供计费系统（billing）进行批价及帐务处理，而移动网管系统并不对以上信息进行监视。
因此，移动服务保障系统通过多种影响业务服务质量的数据的汇集，实现以客户为中心的端到端服务质量监视。在此基础上，识别对服务品质降低起关键作用的业务元素，从而帮助运营商采取纠正措施，提供客户满意度及业务使用率，提高业务收入。
通过移动服务保障系统的应用，提供了以客户为中心的端到端业务监控和管理平台，可以显著降低对服务品质下降从探测、分析、定位到恢复的时间，从而将移动网络的运维提高到一个新的水平。
服务保障的实现探讨
对于运营商来说，针对一个新的业务实现服务保障，必须根据业务建立起服务保障的分析模型，首先必须完成以下几个步骤：
* 根据这个业务的具体特性，定义需要监视的业务资源参数；
* 定义对这些影响业务参数的监视方法及多种因素的分析模型；
* 定义以上业务参数的数据采集的途径和方法；
* 定义服务质量的显示表现方法，如不同业务的显示界面、告警及报告。
在此基础上，实际搭建服务保障系统，实现以上内容。由于不同的移动数据增值业务的不同特性，以上四个步骤应根据不同业务分析定义，并产生不同的分析内容。因此，要求服务保障系统设计必须具有强大的灵活性，针对不同的业务，通过灵活的配置就可以快速实现系统功能，而不需要重新编码开发。
因此，对服务保障系统设计中必须考虑具有如下的灵活管理和扩展能力：
* 业务服务模型自定义，包括定义不同业务的关键质量指标kqi，定义kqi涉及的网络资源数据，算法；
* 灵活地定义和扩展系统接口适配功能，从相关系统采集数据；
* 灵活地根据采集的数据和kqi算法进行计算，产生实际的关键质量指标数据；
* 自动产生管理和监视业务服务质量的输出、告警和报告。
* 通过以上过程，同时实现客户业务sla的功能。
同时，通过新的业务服务保障功能的灵活搭建，可以快速的搭建模拟环境并进行系统测试，测试验证对于业务的服务保障分析结果，如验证定义的kqi是否能够真正代表业务的特性，kqi定义及计算参数、算法的调整等。在此基础上，实现高效运行的服务保障功能。
整个系统可以分为三个管理层面：
* 适配层，通过与其它数据源系统的适配接口，抽取、转换、过滤数据，输出服务保障所需要的资源数据；其中公共的功能通过接口适配平台实现，同时根据数据源系统的情况灵活地配置适配接口。
* 业务层，接收适配层产生的资源数据，通过数据的关联算法，以客户、业务为中心，进行数据的关联分析，实现服务品质降低的根本原因分析；通过配置的算法进行计算，产生kqi数据；同时根据预设的sla阈值，产生sla告警，产生sla报告。
* 用户层，利用业务层产生的kqi数据，根据各业务的特性，采用数据表格、图形、告警、报告等方式提供服务保障的数据输出，并提供给其它系统使用。根据不同业务，提供按客户、按业务、按sla的不同检索查询途径。其它系统输出包括：向故障单管理系统输出服务告警，触发相应的服务品质保证处理过程；向计费系统输出sla报告，提供计费过程中sla资费策略计算所需的数据等。
Java Asp PHP .Net XML C/C++ CGI VB Jsp J2ee J2se J2me EJB Servlet Tomcat Resin Struts Weblogic Eclipse ANT GUI JMS Web servise IDEA Webphere Hibernate Spring Jboss Applet Swing Socket Javamail Perl Ajax P2P 安全 模式 框架 测试 开源 游戏
Windows XP Windows 2000 Windows 2003 Windows Me Windows 9.x Linux UNIX 注册表 操作系统 服务器 应用服务器
