基于NGOSS的移动通信网络投诉支撑平台研究*

2010-06-11郭建华

电信科学 2010年9期

郭建华，向华

（1.广东技术师范学院计算机科学学院广州510665；2.亿阳信通股份有限公司北京100093）

1 引言

为了增强核心竞争力，建设“以客户为中心”的运维支撑系统成为电信运营商的重要目标[1，2]。网络相关的投诉在移动通信客户投诉中占很大比例，网络投诉的应答和处理需要结合相关的网络运维信息和专业知识进行分析，客服人员接到网络投诉后，一般只能简单记录后转发给网维部门处理。这种传统的网络投诉处理方式，对于客户而言因为得不到及时有效的应答，感知较差；对于网维部门而言，面对数量巨大、信息记录不规范的投诉工单，难以进行有效的分析和归并处理。在运维支撑系统上建设“以客户为中心”的网络投诉支撑平台，帮助客服人员规范记录网络投诉，并自动分析投诉原因，直接有效地应答客户，是解决上述问题的有效途径。

支持跨部门的业务协作和信息共享，并且适应未来的业务变化，是网络投诉支撑平台需要考虑的核心问题。电信管理论坛（TMF）提出的下一代运营软件系统（next generation operations systems and software，NGOSS）体系[3]是下一代运维支撑系统的参照规范，为解决上述核心问题提供了清晰的指导思想。NGOSS体系包括增强的电信运维流程框架（enhanced telecom operations map,eTOM）、共享信息和数据模型（shared information/data,SID）以及技术中立的软件体系结构（technology neutral architecture,TNA），其基本思想可以概括为：以业务运营流程为业务需求驱动，以共享信息数据模型为信息交换基础，应用基于组件的软件体系结构实现分布异构环境中的应用集成系统，以期实现业务运营流程的自动化[4，5]。本文参照NGOSS的思想来研究移动通信网络投诉支撑平台，以提高网络投诉的客户感知和处理效率为目标，在客服部门和网维部门之间建立端到端的网络投诉处理流程和共享信息数据模型，进而设计适应业务变化的，基于组件的软件体系结构。

2 端到端的网络投诉处理流程

eTOM流程框架是电信运营流程向导的蓝图，采用多级视图和矩阵结构对电信企业运营流程进行了规范描述。eTOM通过三级视图对电信运营流程元素提供了详尽的列表，并且提供了端到端业务流程的部分流程样例[6]。因为各个运营商的管理流程差异很大，eTOM的主要价值并非其流程样例，而在于指导电信企业利用流程元素构建具体的端到端业务流程。

网络投诉处理流程服务的对象是客户，在eTOM 1级视图中属于运营（Operation）区域，在2级视图中属于保障（Assurance）垂直流程组，3级视图中为该流程组定义了一系列流程元素。为了简化流程，提高处理效率，我国电信运营商网络投诉处理的重点在于问题处理，因此客户QoS/SLA管理、客户保持与忠诚度等流程元素可以暂时忽略，简化的网络投诉处理流程如图1所示。

端到端的网络投诉处理流程跨越3个水平流程组：市场、产品和客户，服务，资源，流程步骤描述如下：

（1）客户感知网络服务问题并报告给客服人员；

（2）客服人员通过“问题处理”流程发送投诉描述给“服务问题管理”流程；

（3）“服务问题管理”流程通过“资源故障管理”进行资源层问题分析；

（4）“资源故障管理”定位投诉原因后，逐级返回投诉解释；

（5）客服人员根据返回的投诉解释回复客户投诉，网络投诉处理终结。

网络投诉处理流程虽然比较简单，却反映了实现流程自动化时横向层面的系统融合，引导出了网络投诉支撑平台的系统需求，网络投诉支撑平台着重实现网络运维信息和专业知识的共享，以支撑网络投诉的规范描述和自动分析。客服人员利用网络投诉支撑平台，能够快速定位投诉原因，提高投诉一次完成率，提升客户感知；同时对投诉进行规范描述和初步归并，提高网维部门的投诉处理效率。

3 网络投诉支撑平台的共享信息/数据模型

3.1 网络投诉支撑的可聚合商业实体

SID是NGOSS的共享信息模型框架，其目标是建立企业级的全局数据管理中心，为电信运营商的信息集成平台提供统一和标准的信息服务。与eTOM的水平流程组相对应，SID框架首先从商业视角划分为市场/销售、产品和客户，服务，资源，供应商/合作伙伴等4个水平层次的信息管理域，然后针对每个域定义可聚合商业实体（aggregate business entity,ABE）和商业实体（business entity,BE），一个BE代表了一个与运营相关的物理或逻辑上的事物，如客户、客户订单、客户账户等，一个ABE则是在一组高内聚、低耦合的BE上定义的信息和操作[7]。

网络投诉处理流程主要涉及客户域和资源域的信息共享。移动通信环境下，引发网络投诉的资源层问题主要是网络故障和网络覆盖缺陷。基站断站是引发投诉的主要网络故障，基站断站会引发局部区域突然信号变弱或中断，MSC和BSC的故障也会引发更大区域的接通或信号问题，网络故障原因可进一步追溯到设备故障和工程割接。网络覆盖缺陷包括信号盲区和弱信号区，需要通过网络优化和规划建站来解决，有的网络覆盖缺陷属于物业难点，短期内不能解决。网络故障和网络覆盖缺陷引发的是一定区域的服务质量下降或服务中断，而客户的网络投诉在地理上也分布在上述区域，因此，地理信息是网络投诉分析的纽带信息。本文以地理信息为纽带按照如下步骤进行网络投诉分析：（1）确定投诉客户的地理位置；（2）关联查找投诉客户周边区域的网络信息，包括其他同类投诉、故障基站、信号盲区、弱信号区等；（3）通过网络信息分析投诉原因，给出解释口径。

与此相对应，定义如下ABE：投诉定位（ComplaintLocation）ABE、网络信息查询（NetInfoQuery）ABE、投诉原因分析（ComplaintAnalysis）ABE。

投诉定位ABE：属于客户域，根据用户的投诉描述模糊查找相关地物（包括建筑物、街道、企业、学校等），确定投诉用户的地理位置（地理位置统一用经度和纬度描述，下同）。

网络信息查询ABE：属于资源域，根据某一地理位置，查询周边区域（一般以基站覆盖半径范围为基准）的相关网络信息。

投诉原因分析ABE：属于资源域，根据投诉周边区域的网络信息进行分析，找出可能的投诉原因。

图6所示胶粘修复结构示意图，金属裂纹母板两端施加100MPa均匀的拉伸载荷；表1所示为上述材料的材料力学性能列表。

3.2 网络投诉支撑的商业实体UML模型

从投诉定位ABE抽象出客户（Customer）、客户投诉（NetComplaint）、投诉类型（ComplaintType）、基础地物（Feature）等BE，从网络信息查询ABE抽象出信号盲区（BliandArea）、弱信号区（WeakArea）、物业难点（PropertyDifficulty）、网元（NetElement）、网元告警（NeAlarm）、工程割接（Changeover）等BE，从投诉原因分析ABE抽象出投诉解释器（ComplaintExplainer）BE，参考 SID的设计模式，建立的BE UML模型如图2所示。

模型中，带有地理位置的网络实体，包括网络投诉、网元、信号盲区等，抽象为网络对象（NetObject），而网络对象的地理位置及其在地图上的展现（figure）则通过聚合地理对象（GeoObject）来实现，从地理对象派生出点（point）、线（line）、多边形（polygon）等形状对象。网络对象与地理对象之间不是派生关系，而是聚合关系，其优点在于两者之间的耦合很松散，网元在SID框架中已纳入资源模型的范畴，与地理对象建立聚合关系不会破坏原有的资源模型，另外，一个网络对象可以同时使用一个或多个地理对象灵活表示。同理，基础地物与地理对象也是聚合关系。

网络信息查询 ABE 中，基站（BTS）、MSC、BSC 等从网元派生，规划站（PlanedBTS）作为一种特殊的基站从 BTS中派生，网元与网元告警之间是聚合关系（NeHasAlarm），一个网元告警关联一个网元类型（AlarmType）。在地理上，网元可以根据其所处的地理位置和网络覆盖区域，同时使用多个地理对象描述，基站的覆盖区域用其覆盖半径粗略描述，也可用测绘所得的覆盖区域精确描述，而BSC和MSC的覆盖区域通过其管理或关联的基站覆盖区域描述。

投诉定位ABE中，客户报告（Report）客户投诉，两者之间是聚合关系，一个客户投诉关联一个投诉类型（ComplaintType），基础地物在投诉定位时起辅助作用，客户投诉与基础地物之间没有直接关联。

投诉原因分析ABE中，在地理上直接呈现的网络对象作为分析的起点，但是更深层的原因需要逐步追溯，如从网元追溯到网元告警，再追溯到工程割接。在资源模型中，网元并不需要具备解释投诉的能力，为了不破坏原有的资源模型，抽象出投诉解释器（ComplaintExplainer）BE，将网络对象、网元告警、告警类型、工程割接的BE与投诉解释器聚合，使其具备投诉解释能力。投诉解释器BE以两种方式解释投诉，一是面向网维人员的技术解释（TechExplain），使用技术语言解释投诉原因；另一是面向客户的客户解释（CustExplain），使用客户服务语言解释投诉原因。一个投诉解释器解释（CanExplain）一类或多类投诉类型，两者之间存在关联关系。

3.3 网络投诉原因分析模型

对于投诉原因的追溯，采用职责链（chain of responsibility）设计模式[8]实现，投诉解释器具有与自身关联的一个后继者（successor），后继者是隐式的解释者，沿着后继者传递建立一条解释链，当投诉解释器接收到解释请求后，首先检查自身是否有后继者，有则将解释请求转给后继者解释，否则利用自身的接口解释，沿着解释连越往后传递，解释的原因越具体。

4条解释链按照优先级排序，其业务含义是：新的网络投诉产生时，首先查询其周边是否有同类投诉，如果有，则沿用原投诉的解释，统一客户解释口径，并作投诉归并，否则，查询其发生的地理位置是否在信号盲区、弱覆盖区、故障网元覆盖区，如果处在某一问题覆盖区，则按照解释链追溯解释原因，如NetElement—NeAlarm—AlarmType—Changeover链，最后可能由工程割接聚合的投诉解释器作出解释。如果网络投诉发生位置同时处在多个问题区域中，则同时沿着多条解释链进行追溯，追溯出的解释按照优先级排序后由客服人员选择客户解释。如果追溯失败，则交给网维人员人工分析。

4 基于组件的网络投诉支撑平台体系结构

NGOSS在技术上采用基于组件的面向对象分布式系统结构，在eTOM的功能定义的指导下将功能分解为对象和对象接口，通过接口交互实现灵活的应用集成，接口交互可以是面向操作的远程过程调用和面向数据流的异步消息机制。

根据网络投诉处理流程，在功能上分解出基础地物查询、网络投诉定位、网络信息查询、网络投诉分析等面向对象的功能组件。在网络投诉支撑平台的实现上，因为相关功能主要是由人工驱动而非数据流驱动的，采用面向操作的远程过程调用的方式提供接口交互。网络投诉支撑平台的体系结构如图4所示。

网络投诉支撑平台首先基于企业服务总线，利用客户服务服务器、网络管理服务器、地理数据服务器等各专业服务器提供的数据服务，构建共享信息/数据服务器，按照网络投诉支撑BE UML模型的规范对外提供数据服务。在此基础上，建立包含各组件的组件服务器，各组件统一发布到企业服务总线上，供其他系统集成应用。

5 网络投诉支撑平台的实现和应用

参考广东某移动运营商的网络管理系统和客服服务系统环境，对上述网络投诉支撑平台进行了构建。采用Oracle数据库构建了共享信息/数据服务器，实现时对各商业实体的属性进行了细化。采用JBOSS服务器构建了组件服务器，并在JavaEE平台上完成各功能组件的开发。各功能组件提供了WebService和Serverlet两种不同的集成接口，分别用于数据集成和门户集成，在呈现上则采用地理信息系统对投诉位置和网络信息进行直观展现。客服服务系统通过集成网络投诉平台的各个组件实现了网络投诉分析功能，以下以基站割接导致的客户投诉为例来说明网络投诉分析的应用。网维部门计划于某日对“白马花园”基站进行割接，并提前1天在网管系统中填写了基站割接计划。基站割接时导致该基站覆盖的白马花园小区部分区域无信号，某客户事后进行投诉，客服人员接到该投诉后，根据投诉描述地点利用基础地物查询功能在电子地图上找到了投诉位置，并利用网络投诉定位功能规范记录了投诉经纬度位置。接着启动网络投诉分析功能，分析结果显示，投诉描述的时间范围内，“白马花园”基站因工程割接产生了断站告警，“白马花园”基站在地图上以警告色高亮显示，并附注了投诉的解释口径。分析结果界面如图5所示。客服人员根据解释口径及时回复客户，实现一次截单。

6 结束语

本文参考NGOSS的电信运维支撑系统建设思想，以提高移动通信中的网络投诉客户感知和投诉处理效率为目标，建设网络投诉支撑平台，利用eTOM流程元素构建网络投诉处理流程，根据流程需求抽象出ABE和BE，并建立了共享信息/数据的UML模型和投诉解释链模型，设计出了技术中立的基于组件的平台软件体系结构。最后在某电信运营商的网络管理系统和客服服务系统环境构建了网络投诉支撑平台，并在客户服务系统中进行集成应用，实现了网络投诉的自动分析和一次截单。本文为落实“以客户为中心”的运维支撑系统建设目标提供了一个最佳的切入点，并为NGOSS思想的实施提供了一个实践案例。