（计算机应用技术专业论文）电信统一故障处理系统的设计与实现.pdf

电信统一故障处理系统的设计与实现中文摘要 摘要 上海电信于1 9 9 7 年起，先后在市区和各个郊区建成各自独立的11 2 系统。 2 0 0 1 年上海电信首先在上海市区实现了1 1 2 系统的互联，即能对市区所有用户 线路进行自动测试和障碍报修。但市区1 1 2 系统与郊区1 1 2 系统之间至今仍未 能实现整合。在新业务不断出现、企业信息系统数据量激增、数据共享要求越来 越高的背景下，11 2 市郊合并逐步提上了日程。 本文以上海电信市郊1 1 2 系统整合项目为背景，研究在市郊1 1 2 系统的合并 的几种可能采用的整合方案，并针对选定的整合模式，制定技术解决方案。 本文的贡献如下： 1 对实现数据共享的方式进行了研究，提出以集中与分布结合方案实现 市郊1 1 2 系统的数据共享。该方式符合现有系统的架构，改动较小。 在系统的可用性、访问的局部性等方面具有优势。避免了采用分布式 数据库带来的系统大规模改动，以及采用集中式数据库带来的访问局 部性和系统安全性较差的问题。 2 提出网关测试的方案，实现集中测试。网关测试模式与直接测试模式的 最大区别在于保留了郊区1 1 2 测试系统。测试请求由测试协议网关转发 给相应郊区测试系统执行。在该模式下，市区受理员或自动语音流程受 理了郊县电话的申告后，可对郊区电话进行测试，获得测试结果。解决 了直接测试中存在的对市区系统资源消耗大、需建立大量链路等问题。 3 设计了一套符合行业标准的露关测试协议。市郊系统只需按照协议进行 开发，即可实现网关测试。该协议采用t c p ( t r a n s m i s s i o nc o n t r o lp r o t o c 0 1 传输控制协议) 连接，确保可靠性。为保证应用层对消息的可靠收发， 测试协议应在消息格式中添加额外的保障。 4 对现有的9 7 接口提出了整合的想法。采用9 7 接口机方式和通用格 式文本方式，解决了9 7 存在多个1 1 2 接口格式文件的问题。 5 提出了t m s ( 特服汇接局) 转接方式实现1 1 2 与1 0 0 0 0 号的接口， 为实现上海电信1 0 0 0 0 号与1 1 2 话务转接傲准备。 6 依托奉贤11 2 试点项目，对上述方案进行了实际的测试和验证工作； 关键词： 电信故障受理与测试系统，分布式数据库，集中式数据库，网关私i 试，测试 协议，i t i l ( i ti n f r a s t r u c t u r el i b r a r y ，信息技术基础设施库) 电信统一故障处理系统的设计与实现 英文摘要 a b s t r a c t s i n c e1 9 9 7 ，t e l e e o mc o m p l a i n tp r o c e s s i n gs y s t e m ，w e l l - k n o w nn a m e d11 2 s y s t e m s ，h a v eb e e ne s t a b l i s h e dr e s p e c t i v e l ys t e pb ys t e pb ys h a n g h a it e l e c o mi nt h e c i t ya n ds u b u r b s a n di n2 0 0 1 ，s h a n g h a it e l e c o ma c c o m p l i s h e di n n e r - c o n n e c to f t h r e e11 2s y s t e m si nt h ec i t y f r o mt h a tt i m eo n ，a l ls u b s c r i b e rl i n e sc o u l db et e s t e d a u t o m a t i c a l l ya n db ea s s i g n e dt ob er e p a i r e da u t o m a t i c a l l y b u tu pt ot h ep r e s e n t ，11 2 s y s t e m si nt h ec i t ya n d11 2s y s t e m si nt h es u b u r b sr e m a i ns e p a r a t e i nt h i sa r t i c l e ，w ew i l ls t u d ys e v e r a lp o s s i b l ei n t e g r a t i o ns o l u t i o no f11 2s y s t e m s i nt h ec i t ya n ds u b u r b sf o rt h ei n t e g r a t i o no fc i t ya n ds u b u r b11 2s y s t e m so f s h a n g h a it e l e c o m ，a n dw o r ko u tt h et e c h n o l o g ys o l u t i o n t h i sa r t i c l ec o n t r i b u t e st o ： 1 w ep r o p o s eas o l u t i o nt h a tu n i t et h ec e n t r a l i z a t i o na n dd i s t r i b u t i o n s ，a n d f u l f i l ld a t as h a r i n go f1 1 2s y s t e m ，w h i c hs u i t sf o rt h ea r c h i t e c t u r eo f t h e1 1 2 s y s t e m ，a n dr e q u i r e sl e s sa l t e r a t i o n 2 w ep r o p o s eas o l u t i o no f t e s t i n gb yg a t e w a y , t os a t i s f yt h er e q u i r e m e n t so f d i s t r i b u t et e s t i ng a t e w a yt e s t i n g ，r e q u e s t so fl i n et e s t i n gc a nb et r a n s f e r r e d b yt e s t i n gg a t e w a yt ot h ec o r r e s p o n d i n gt e s t i n gs y s t e mi ns u b u r b 3 w ed e s i g nas e to fp r o t o c o lc o n s i s t e n tw i t i lb u s i n e s ss t a n d a r df o rt e s t i n gb y g a t e w a y w ea d o p tt h et c p ( t r a n s m i s s i o nc o n t r o lp r o t o c 0 1 ) c o n n e c t i o nt o e n s u r et h er e l i a b i l i t y i no r d e rt oi n s u r et h er e l i a b l em e s s a g et r a n s m i s s i o n ， a d d i t i o n a lp r o t e c t i o ns h o u l db ea d d e dt ot h et e s t i n gp r o t o c o li na p p l i c a t i o n l a y e r 4 w et a b l eap r o p o s a lo fi n t e r f a c eb e t w e e nt h e1 1 2 s y s t e ma n do t h e r i n t e r r e l a t e ds y s t e m s f o ra l le x a m p l e ，w es u g g e s tt h a tt e x tf i l e si ng e n e r a l f o r m a tb eu s e dt os o l v et h ep r o b l e mo f m u l t i p l ef o r m a t so f i n t e r f a c eb e t w e e n 9 7s y s t e ma n do t h e rs y s t e m s 5 w ea p p l ya n dv a l i d a t et h es o l u t i o n t of e n g x i a n1 1 2e x p e r i m e n t a lp r o j e c t k e y w o r d s ： t e l e c o m c o m p l a i n tp r o c e s s i n ga n dt e s t i n gs y s t e m ，d i s t r i b u t e dd a t a b a s e ， c e n t r a l i z e dd a t a b a s e ，t e s t i n gb yg a t e w a y , p r o t o c o l ，i t i l ( i ti n f r a s t r u c t u r el i b r a r y ) 2 电信统一故障处理系统的设计与实现 第一章概述 本章主要阐述了本文的研究背景，介绍了上海电信1 1 2 系统的概况，引出了 本文的研究目的、内容和技术难点。本章最后给出了本文的组织结构。 1 1 项目背景简介 电信故障处理系统，俗称1 1 2 系统，是随着我国电信业的发展，主要是程控 交换机的大规模发展而兴起的。其发展经历了分散受理一手工仪表测试、分散受 理一测试头测试和集中受理自动测试这三个阶段。 程控交换机在我国发展的初期( 2 0 世纪8 0 年代末到9 0 年代初) ，用户数 量较少，但已经有用户报修电话故障的情况发生。在这个阶段，运营商设立了 11 2 报修电话，并在每个分局的测量室安排专职的线务人员接听用户的报修电 话，并就近在m d f ( m a i nd i s t r i b u t i o nf r a m e ，主配线架) 上对用户报修的线路 进行手工测试。因为缺乏专业的测试设备，线务员只能利用一些常见的仪表测试 线路的基本情况。测试准确度完全依赖于线务员的专业素质。 1 9 9 0 - 1 9 9 6 年间，随着程控电话的逐渐普及，障碍数量也随之上升。这个阶 段，陆续出现了一些专业的线路测试设备。这些设备的投入使用，提升了障碍测 试准确率。但由于障碍申告数量的上升，线务人员的工作量明显加重。特别是一 些跨局的电话报修，线务人员需要联络相应分局的线务人员协同处理，工作量成 倍上升，障碍处理的效率低下。电信运营商为保证服务质量，不得不在分散在各 个分局的测量室中投入更多的线务人员，但仍无法有效地提升服务质量。 随着程控交换机电话用户规模的日益膨胀，上述维护模式己无法适应新的要 求。1 9 9 7 年前后，邮电部发文要求各省电信运营商按照集中受理、集中测试、 集中派修和集中管理这四个集中的模式，建设各自的1 1 2 故障集中处理系统。 上海电信于1 9 9 7 年起，先后在市区和各个郊区建成各自独立的11 2 系统。 2 0 0 1 年上海电信首先在上海市区实现了1 1 2 系统的互联。至此，上海市区电信 用户拨打1 1 2 申告电话，进入1 1 2 系统平台，即能对市区所有用户线路进行自 动测试和障碍报修。但市区11 2 系统与郊区11 2 系统之间至今仍未能实现整合。 近年来，随着市场竞争的日益加剧，市场对电信运营企业的服务内容、服务 模式、服务质量、服务意识以及经营管理等，均提出了严峻的挑战。为了适应环 电信统一故障处理系统的设计与实现 概述 境的变化，根据自身的业务特点及战略目标，中国电信相继启动了新一代运营支 撑系统的研究论证和建设工作。新一代运营支撑系统的建设，打破了传统系统间 的信息孤岛，实现了企业信息的充分共享，改善了服务水平和服务质量，加快了 对市场的响应速度，推动了新业务的开展，提高了企业对运营的控制能力，为企 业信息化建设奠定了基础。 上海电信11 2 系统作为上海电信m b o s s ( 由b u s i n e s ss u p p o r ts y s t e m ， m s s 管理支撑系统、b u s i n e s ss u p p o r ts y s t e m ，b s s 业务支撑系统和o p e r a t i o n s u p p o r ts y s t e m ，o s s 运营支撑系统三部分组成，简称m b o s s ) 系统的一个 组成部分，对上海电信业务的开展起着非常重要的支撑作用，与其他信息系统的 信息共享的情况将日益增多，例如11 2 系统从9 7 数据库获取用户基本信息，而 ”2 系统的数据可以为c r m ( c u s t o m e rr e l a t i o n s h i pm a n a g e m e n t ，客户关系 管理) 系统以及公司的其他运营、决策支持系统提供用户使用业务的一手资料。 上海电信的9 7 系统目前已经完成了小龙并大龙的工程，而由于几个1 1 2 系统相 互独立，9 7 系统在为1 1 2 系统提供用户基本信息时需要有不同的接口，造成网 络结构与数据流向的复杂化，今后在与其他系统进行数据共享方面可能也会存在 类似的问题。而且这种多接口的现象也给新业务的开展设置了内部的障碍，在新 业务不断出现、企业信息系统数据量激增、数据共享要求越来越高的背景下，目 前市郊系统分散的状况显然不利于上海电信企业核心竞争力的打造，在这样的背 景下1 1 2 市郊合并逐步提上了日程。 上海电信市郊11 2 系统整合后，将形成一个本地网统一11 2 系统。具体目标 如下： 1 实现本地网11 2 申告的集中受理，统一受理流程； 2 实现市区受理中心对全市( 包括市区和郊区) 所有普通电话用户线路的 测试功能； 3 实现全市范围内障碍单的自动派修； 4 统一1 1 2 系统与其他系统的接口。其中包括1 1 2 与9 7 、1 1 2 与o d s ( o p e r a t i o n a ld a t as t o r e ，操作型数据存储) 等系统的接i z l ： 5 改善现有系统的性能，使其能满足新业务不断发展的需求； 1 2 本文的贡献 上海电信11 2 由市区一个系统和郊区七个系统组成，情况较为复杂。 电信统一故障处理系统的设计与实现 这八个1 1 2 系统分别拥有独立的1 1 2 数据库。其中，市区1 1 2 系统数据库 中存放的数据量较大，包括了市区8 0 0 万用户及其线路信息、局方设备数据以 及在申告受理中产生的障碍数据。对于历史障碍数据，系统将容纳两年的数据量。 超出两年的历史障碍数据，系统将备份之后自动予以清除。郊区七个1 1 2 系统 的数据库的数据量相对较小，其存储的用户及其线路信息大致在3 0 到4 0 万之 间。上海11 2 系统现有8 个数据库系统，分别采用了s o l a r i s + s y b a s e 、w i n d o w s 2 0 0 0 + s y b a s e 、w i n d o w s2 0 0 0 + s q ls e r v e r 共三种不同的组合方式。要整合11 2 系统，首先需要实现数据的整合。 市郊11 2 系统整合后，市区11 2 系统应能对上海电信本地网内所有普通电话 用户进行自动测试，以及在全市范围内进行障碍单自动派修，为实现这些功能， 需跨越不同的应用系统，打破系统与系统之间的壁垒。 上海电信1 1 2 系统整合后，本地网统一的1 1 2 系统与上海电信0 s s ( o p e r a t i o ns u p p o r ts y s t e m 运营支撑系统) 架构内其他系统存在各种接口。应 对这些接口进行优化，以使这些接口具备高度的可管理性和可扩充性。 本文的主要工作是：以上海电信市郊1 1 2 系统整合项目为背景，基于用户的 实际业务需求、对系统整体未来业务的发展趋势以及各个系统的协调发展进行调 研，研究在市郊1 1 2 系统的合并的几种可能采用的整合方案。从现有管理要求、 业务发展、以及相关技术角度出发，对不同的方案进行分析，并针对选定的整合 模式，制定技术解决方案。 本文对实现整合过程中主要的技术难点，如：数据整合的问题、跨系统测试 问题、派修信息互连、集中管理及与其他系统接口等问题进行了深入的研究并给 出了解决方案。 1 3 本文的组织结构 本文一共分为七章。第一章介绍了本文的研究背景；第二章总体介绍了上海 电信市郊1 1 2 系统的发展状况和软硬件架构；第三章分析比较了分布式数据库、 联邦式数据库和集中式数据库实现数据整合的方案，提出了以集中式数据库方案 实现用户信息及障碍申告数据的整合：第四章分析了几种实现跨系统测试功能的 方案，提出了采用网关测试方式实现测试互连的方案；第五章提出了整合各种不 同对外接口的方案；第六章介绍了对市郊1 1 2 系统整合的试点应用案例；第七章 对上海电信本地网统一1 1 2 系统今后的进一步发展进行了展望。 4 电信统一故障处理系统的设计与实现1 1 2 系统架构 第二章1 12 系统架构 本章主要介绍了上海1 1 2 系统的组成以及市区1 1 2 系统的主要软硬件架构。 本章的组织如下：第一节简要介绍了上海11 2 系统的现状，说明了建立本地 网统一11 2 系统的必要性；第二节介绍了1 1 2 系统架构，为讨论具体的整合方 案打下基础：第三节分析了上海电信市郊11 2 系统整合的要求；本章最后进行 了小结。 2 1 上海1 1 2 系统的现状 上海电信现有八个1 1 2 系统，分别部署在市区以及嘉定、青浦、松江、奉贤、 南汇、金山和崇明等郊区。其中市区11 2 系统分别在浦东、新华和逸仙建有三 个1 1 2 受理中心。每个1 1 2 系统都具备独立的申告电话受理、自动测试、自动 派修和集中管理的功能。 2 1 1 市区1 1 2 系统现状 2 1 1 1 系统组成 市区的1 2 系统包括以下几个主要节点： 1 三个1 1 2 受理中心 三个互联的中心，实现集中受理用户申告。 2 一个用户申告及线路信息数据库 即l | n a ( l i n ei n f o r m a t i o na d m i n i s t r a t i o n ，线路信息管理) 数据库，集 中存放用户信息、线路信息和申告信息。 3 八个派修中心 负责市区八个地面局的故障指派和管理。 2 1 1 2 受理方面 目前市区1 1 2 的受理分布在三个受理中心( 新华、浦东、逸仙) ，用户的呼 入按照地域接入相应的受理中心。在两个受理中心之间，通过d t - a v r ( d i g i t a l 电信统一故障处理系统的设计与实现1 1 2 系统架构 t r u n k - a u t o m a t e dv o i c er e s p o n s e ，数字中继一自动语音应答器) 之间的2 m 连 线实现无缝的话务转接。当用户申告跨区的电话时，受理方的a v r ( a u t o m a t e d v o i c er e s p o n s e ，自动语音应答器) 通过查询数据库，若发现该申告属于其他 两个中心所管辖的范围，即在跨区的e 1 中继中选择一路进行话务转接。如下图 所示： 2 1 1 3 测试方面 图1 市区1 1 2 系统跨区转接示意 在市区的测试模块中，测试系统通过通信服务器向测试设备发送测试命令。 测试设备在接受到测试命令后，通知交换机接取用户线至该测试设备，然后进行 各项测试，并将测试结果返还给发动测试方。 市区1 1 2 系统已经具备连网测试功能。市区三个1 1 2 中心都可以对市区所有 普通电话用户发动测试。当被测电话属于其他中心所管辖的范围，系统自动通过 系统之间的连接将测试请求转发给对应中心。 6 电信统一故障处理系统的设计与实现1 1 2 系统架构 2 1 1 4 派修方面 图2 派修示意图 ”2 受理中心将障碍的测试和1 2 9 完工信息传送给1 1 2 受理中心数据接口。 接口将数据作预处理后交给派修逻辑管理系统进行处理。派修逻辑管理系统负责 整个派修过程的管理和控制。派修通知系统通过各种通信手段将障碍派修单信息 通知修理人员。同时派修通知系统也可把派修中的反馈信息通过11 2 受理中心 数据接口反馈给11 2 受理中心。 其中： 1 1 1 2 受理中心数据接口 负责与11 2 受理中心交换动态和静态数据 2 自动派修逻辑 负责自动指派障碍到修理人员，自动派修遇到不能够处理的障碍则移交 人工派修逻辑处理 3 人工派修逻辑 提供了人工处理自动派修中无法处理的障碍 4 派修通知系统 包括自动发拷机，自动发传真和语音信箱。 市区11 2 系统根据测试结果输出派修单，按机线或内、外线不同故障类型分 别通过传输介质发送至各相关维修中心。系统具有故障转派功能。以区局为单位 成立八个派修中心，从受理中心自动采集派修信息，通过发送信息到b p ( b e e p p a g e r ) 机、语音信箱、传真等方式，进行自动或人工派修。 障碍修复后，线务员通过“1 2 9 ”系统自动进行障碍修复证实功能，并能将修复 障碍情况自动记录。 电信统一故障处理系统的设计与实现 1 1 2 系统架构 2 1 。2 郊区1 1 2 系统现状 2 1 2 1 系统组成 郊区局11 2 系统相互独立，只负责本局范围内的用户故障受理，各系统之间 不能做到跨区受理、测试等。 2 1 2 2 受理方面 郊县用户拨打1 1 2 申告后，进入本局1 1 2 系统的自动语音系统。系统可发起 对线路的自动测试。用户也可转人工坐席受理。一般每个郊县只设立两个人工席。 郊县1 1 2 只负责受理本局范围内用户申告。用户如果在市区申告郊县电话故 障，则由市区受理中心受理后，人工转到郊县1 1 2 。此外，随着1 0 0 0 0 电信综 合服务热线的宣传深入，不少用户拨打1 0 0 0 0 号进行申告。此部分申告也是人 工转入各郊县的11 2 。 2 1 2 3 测试方面 在郊县的1 1 2 系统中，测试控制器联接业务处理子系统，负责测试并返还测 试报告。各郊县”2 只负责本局范围内电话的测试，无跨区测试功能。 2 1 2 4 派修方面 郊县11 2 的派修功能较为简便，不设立专门的派修中心。受理测试系统根据 测试结果输出派修单后，一般直接发送到所属区局的测量室，再由人工制定修理 人员。障碍修复后，线务员通过拨打“11 2 ”，进行复测和销障。 2 1 3 市郊1 1 2 系统对比 2 1 3 1 配置方面 由于系统有不同的厂商提供，目前市郊1 1 2 系统在一些基本的网络配置、硬 件设备以及软件版本上均有较大的不同，见下表： 电信统一故障处理系统的设计与实现1 1 2 系统架构 1 1 2 版本数据库版本安全机制 市区 a l l a 3 2 cs y b a s e l1 9 2双机c l u s t e r 金山 i m s 1 1 2s q l 2 0 0 0 青浦 松江 嘉定数据库备份 j t l 0 5 s y b a s e l1 9 2 崇明 奉贤 南汇 表格1 市郊1 1 2 系统配置对比表 从上表可以看出，市郊在系统配置方面具有较大的区别。但郊县虽然是7 个 1 1 2 系统，但其中六个均由理想公司提供，系统版本、数据库版本、安全机制都 比较统一。这种情况下，在做市郊系统合并工作中，这几个郊县的情况基本一致， 可以当作一个系统考虑，再推而广之，大大减少了合并工作的复杂度。 2 1 3 2 业务流程方面 市区和郊县的11 2 业务流程基本一致，如下图所示： 1 1 2 申告 受理铡试派修销障 图3 1 1 2 受理流程示意图 用户拨打1 1 2 ，进入自动语音系统。自动语音系统根据用户输入的故障设备 号码，从数据库中获取用户信息。按照流程定义，若需要进行障碍测试时，则进 入测试步骤。系统能自动对故障号码进行多项测试。对于模拟用户线，可以进行 外线测试、内向测试。若测试结果正常，则通告用户。用户可选择人工台继续处 理。若发现故障，则通告用户申告已经受理，转入派修流程。市区还有申告复测 环节，自动测试有故障的，先由人工方式复测后进入派修流程。 9 电信统一故障处理系统的设计与实现1 1 2 系统架构 派修方面，市区根据预定的派修原则，指定修理人员，下达工单。一般使用 寻呼机直接发送。郊县一般使用纸质工单方式，下达到测量室。修理人员在修理 完毕后，拨打1 2 9 销障电话，由系统对此故障进行测试，确认是否已经修复。 具体来说，目前市区1 1 2 业务由于申告量大，跨区申告现象多，从整个的业 务流程来说分工细致、考核明确，而郊县一般结合了地方特色，由于他们地域广 阔，用户密度低，一般采取分局负责制的方法，根据我们对各区县的调研情况， 总结了如下的业务流程比较表： 受理测试派修销障 市区 实现了2 4 小自动测试或确定有故障后修理人员打 时受理。用户人工测试后进行派修，指定1 2 9 销障，系 的呼入( 市区再转入申告到修理人员，下统进行自动测 内) 接入相应复测达工单，一般使试或人工测 的受理中心，用寻呼机直接试，若无问题 可以话务转发送。则结案 接。 郊区 只受理本局自动测试有一般使用纸质修理人员打 的故障。夜间故障或无法工单方式，下达1 1 2 进行销障， 一般转入语测试达到三到测量室。系统进行测试 音信箱。次后转到下确认没有问题 一流程后销障 表格2 市郊业务流程比较表 上表对市郊的业务流程的每个环节进行了详细的比较。 目前市郊系统业务流程均能基本满足对现有用户规模下的业务开展支撑。但 是，随着市场竞争激烈程度不断加剧，上海电信向公众客户所提供的服务均在向 标准化、规范化以及管理简单化方向发展。就这一点来说，市区相对郊区具有一 定的优势。比如：市区系统流程在面对用户的这一环节能够提供7 + 2 4 小时无差 别的受理服务，而郊县受理服务一般有时间段的差异。另外，市区具有申告复测 功能，对障碍的认定较郊区严格，这样能够减少后面流程的无效劳动，使整个流 程运转高效化。虽然郊区现有系统也能够支撑其当地业务的开展，并具有相应的 管理灵活性，但是随着用户规模的扩大，灵活性的代价就是管理复杂度增加。所 以在实施市郊11 2 整合时，考虑采用市区1 1 2 业务流程为基础的统一流程模式 是必然的。 2 1 4 建立本地网统一1 1 2 系统的必要性 上海地区拥有一个大的本地网，1 1 2 作为一个服务品牌已经深入人心。对用 电信统一故障处理系统的设计与实现1 1 2 系统架构 户来说，在市郊虽然都是使用一个相同的号码实现该业务，但是由于分属不同的 独立系统，市郊在对该业务的管理以及提供的服务并不完全相同。 总体来说，整合市郊1 1 2 系统，建立上海电信本地网统一11 2 系统符合信息 系统整合、共享的趋势，可以从以下几个方面体现其必要性： 1 1 1 2 业务管理的需求 目前市郊在业务流程、管理模式上存在区别，他们对业务指标的统计口 径可能存在着差异，这给公司相关部门在利用这些指标进行分析、考核 时带来一定的困难，也可能给决策层在制定相关决策时提供了不确切的 信息。因此有必要将各区局管理上的特殊性融合到统一的规范当中，这 样管理需求有一个统一的系统、统一的业务流程作支撑。 2 数据共享的需求 随着电信业务模式不断修正完善，各相关部门对障碍数据的共享要求也 日益增多，11 2 系统正成为一个为多部门人员提供信息的后台数据中心。 如果能将1 1 2 进行归并，将可以统一窗口服务，减少接口的反复，统一 数据结构，有利于数据的共享，从而能提高11 2 的服务水平。 3 提升服务的需要 11 2 是一个面向最广大的电信用户的售后服务品牌，对用户来说1 1 2 系 统服务水平最直接的感受体现在受理这一环节，这也是市郊目前在服务 水平存在差异较大的地方。市郊统一后可以实现集中受理、跨区测试， 管理部门可以制定一个统一的服务标准，届时无论用户处在何处，将享 受的是统一的、规范化与人性化的电信服务。 2 2 市区1 1 2 系统架构 市区11 2 系统主要由受理子系统、测试子系统、数据库子系统和派修子系统 这四个部分组成。 电信统一故障处理系统的设计与实现1 1 2 系统架构 竺塑事：dt-ivr国ms-ivr 舍 且 v 数据库于系统 8 憋 图4 1 1 2 系统组成 以上子系统的数量配备是灵活的。由于采用了模块化的结构设计，客户可根 据自身的实际情况选取需要的子系统。例如，在有的实际应用中，共配备了三个 受理子系统、三个测试子系统、八个派修子系统以及一个数据库子系统来实现对 大型交换本地网的11 2 集中受理、集中测试、集中派修和集中管理。 四个子系统之间配合工作的情况如下： 1 市话用户拨打的“1 1 2 ”障碍申告电话首先由受理子系统中的d t i v r 受 理，依据用户提供的障碍电话号码，通过数据库子系统提供的查询界面， 查询数据库以获得该用户信息，并根据用户信息对此申告作相应的处理， 这些处理包括通过测试子系统发动测试、告知用户目前障碍已在处理中、 直接转入人工坐席台处理等。 2 需要人工服务的申告( 这类申告可由局方定义) ，将转入受理子系统的 排队队列，并最终由人工坐席来受理。人工坐席可通过测试子系统对用 户线路进行测试。必要时，人工坐席也可通过测试子系统对用户线路进 行监听。 3 。人工坐席也可通过l a n ( l o c a la r e an e t w o r k s 局域网) 或者v 悛n ( 网 w i d ea r e an e t w o r k s ) 操纵数据库子系统中的各项数据。这些数据包括 用户数据、线路数据、障碍数据等。数据库子系统负责提供操纵这些数 电信统一故障处理系统的设计与实现1 1 2 系统架构 据的界面并妥善的管理这些数据。 4 测试子系统负责连接测试设备和管理测试请求。 5 在测试结果有障碍的情况下，该笔障碍单将根据一定的派修逻辑( 可按 照局方的要求定义) ，被发送到终端( p c 或传真) 。维修人员可通过 派修终端查看到最新的派修单，并进行相应的处理。 2 3 需求初步分析 上海电信本地网统一11 2 系统建成后将以现有市区11 2 系统为主，集中受理 上海地区所有电信用户的故障申告。整个业务流程也将以市区现有流程为基础。 因此，以市区现有1 1 2 系统的软硬件架构为基础实现市郊1 1 2 系统的整合是较 为切实可行的解决方案。 根据上海电信的要求，市郊1 1 2 系统整合后，将形成一个本地网统一11 2 系统。具体目标如下： 1 实现本地网1 1 2 申告的集中受理，统一受理流程； 2 实现市区受理中心对全市c e , 括市区和郊区) 所有普通电话用户线路的 测试功能； 3 实现全市范围内障碍单的自动派修： 4 统一1 1 2 系统与其他系统的接口。其中包括1 1 2 与9 7 、1 1 2 与o d s 等 系统的接口； 5 改善现有系统的性能，使其能满足新业务不断发展的需求； 按照原邮电部对于11 2 系统的要求，11 2 系统必须实现“集中受理”、“集中测 试”、“集中派修”和“集中管理” y d 9 7 ，s t 9 7 。下面将根据这四点来分析上海电信 对市郊1 1 2 整合的要求。 2 3 1 集中受理 11 2 集中受理有两层含义： 1 交换系统层面的集中受理： 2 1 1 2 业务的集中受理； 交换系统层面的集中受理是指上海地区所有电信用户的障碍申告电话，即用 电信统一故障处理系统的设计与实现1 1 2 系统架构 户拨打112 后，通过p s t n ( p u b l i cs w i t c h e dt e l e p h o n en e t w o r k ，公共交换电 话网络，简称固定网) 交换机网络转到市区1 1 2 受理系统。 新华1 1 2 中心迫t = 1 1 1 1 2 中心 浦东1 1 2 中心 图5 ”2 集中受理话务分配示意圈 如上图所示，上海现有特服中继系统有t m s l 4 。其中，浦东11 2 中心接受 来自于t m s 3 、4 的1 1 2 呼叫；新华和逸仙两中心接受来自t m s l 、2 的1 1 2 呼 叫。用户拨打1 1 2 申告电话时，本地交换机会分析被叫号码，然后根据预先的 设置数据，将此话务占用对应的到1 1 2 中心的中继路由。特别的，t m s 3 、4 为 区别两个1 1 2 中心，在本地交换机中对逸仙1 1 2 中心所辖地区的数据进行了设 置，即当用户拨打11 2 时，加上字母d ，以示区别。 采用此架构，只需对上海各郊区的本地电话交换机的数据进行更新，即可实 现”2 申告话务在交换系统意义上的集中受理。交换系统对1 1 2 呼叫的集中。 将所有1 1 2 申告集中到市区三个11 2 中心受理，为实现11 2 业务的集中创造了 条件。业务的根本是数据。11 2 业务的集中需建立在11 2 数据共享的基础之上。 上海电信11 2 系统的数据类型如下表中所示 数据类型说明 固定电话、宽带、a d s l ( a s y m m e t r i cd i g i t a l s u b s c r i b e rl i n e ，不对称数字用户线) 、i s d n 用户基本数据 ( i n t e g r a t e ds e r v i c ed i g i t a ln e t w o r k ，综合业务数 字网，俗称“一线通”) 、专线等电信用户的用户 名称，装机时间，地址，特服等基本信息 线路数据用户电话所经过的线路数据 1 4 电信统一故障处理系统的设计与实现1 1 2 系统架构 设备数据电缆、分线箱等设备数据 处理中的申告记录申告时间，申告现象，测试结果等 历史申告记录已经结案的障碍数据，历史数据在系统中保留两年 统计数据各类统计数据 其他局方数据，局因数据，操作员数据等 表格31 1 2 数据种类 z 0 4 以上数据中，用户基本数据、线路数据、设备数据等均来源于上海电信9 7 数据库；处理中的申告记录、历史申告记录和其他数据是1 1 2 系统运行过程中 的o l t p ( o n l i n et r a n s a c t i o np r o c e s s i n g ，联机事务处理) 过程产生的数据； 而统计数据则为o l a p ( o n l i n ea n a l y t i cp r o c e s s i n g ，联机分析处理) 【h k 0 1 ， w 9 8 应用所产生的数据。 以上数据分布在上海电信各个11 2 系统的数据库中，每个数据库存储本系统 管辖范围内的数据。数据共享即指对于集中受理后的市区11 2 中心的应用程序， 所有市郊11 2 系统的数据应是可访问的。 缺少不同的数据会导致以下不同的问题： 1 缺少用户基本数据 系统会将不存在的用户当作空号处理。针对该号码的申告一律无法得到 系统处理。 2 缺少线路、设备数据 系统会受理该申告。但对于维修人员来说，无法了解该用户的线路和设 备信息，意味着无法找到用户号码对应的设备位置，无法进行维修。 3 缺少申告记录和历史记录 会导致系统无法按照预先定义的业务流程对申告进行处理。 本文第三章将对如何实现市郊112 数据共享进行详细的讨论。 2 3 2 集中测试 “集中澳i 试”是指在1 1 2 受理中心，可实现对所辖区域电话用户的自动测 试。通过测试，可判断用户申告的电话号码是否有障碍。测试结论为有障碍的电 话号码，可直接进入下一步派修流程。测试结果正常的，则可告知用户。目前 1 1 2 系统普遍只能对窄带( p s t n ) 用户线路进行自动测试，对a d s l 等宽带的 测试尚待建设 c 0 5 1 。 上海电信市郊11 2 系统整合后，按照“集中受理”的方式，所有申告将被集 电信统一故障处理系统的设计与实现1 1 2 系统架构 中到市区三个”2 受理中心。在此基础上，需进一步实现“集中测试”。即市 区1 1 2 受理中心应能对郊区p s t n 用户线路进行自动测试。 本文第四章将对如何实现市郊11 2 跨系统测试进行详细讨论。 2 3 3 集中派修 “集中派修”是指在1 1 2 受理中心对已受理并经测试证实有障碍的故障电话 号码进行派单处理。经系统派单后，障碍单将按定义的流程被派往指定的维修人 员，从而启动障碍修理工作。障碍修理完成后，维修人员通过拨打“1 2 9 ”特服 号码，进行完工消障，结束整个障碍处理流程。 上海电信市郊11 2 系统整合后，“集中派修”的实现方案将取决于“集中受 理”中数据共享的实现方案。其最大的差异在于派修系统与数据库系统之间的接 口。 本文第三章将对实现市郊11 2 集中派修进行讨论。 2 3 4 集中管理 “集中管理”是指在实现了11 2 申告处理工作的“集中受理”、“集中测试” 和“集中派修”的基础上，对整个11 2 工作流程可以实现实时的监督。通过对 系统历史数据的采集和分析，可全面掌握11 2 处理工作的各个细节指标，以便 更有效地实施管理和改进。 上海电信1 1 2 系统在整合之前，管理工作分散在市区和各个郊区电信局。虽 然市公司主管部门对11 2 处理工作有一系列的标准和考核要求，但由于系统存 在不同差异，导致统计口径在不同程度上存在不一致。市郊11 2 系统整合后， 将消除不同系统在技术上的差异，实现“集中管理”。 本文第三章将叙述数据共享的实现，数据共享是实现集中管理的基础。本文 第五章将叙述11 2 系统与其他系统接口的实现。这两部分构成了集中管理的主 要概念。 2 4 小结 本章主要介绍了上海1 1 2 系统的现状，对市区和郊区1 1 2 系统进行了介绍和 比较。进而对上海电信市郊11 2 系统整合的需求进行了初步的分析。 电信统一故障处理系统的设计与实现 1 1 2 系统架构 下一章中，将着重介绍市郊11 2 数据共享的实现方案。 电信统一故障处理系统的设计与实现数据共享 第三章数据共享 本章主要介绍了上海电信市郊1 1 2 系统实现1 1 2 数据共享的技术方案。市郊 11 2 系统的数据共享，是实现集中受理、集中派修和集中管理的技术基础。 本章的组织如下：第一节简要介绍了1 1 2 数据库系统的软件架构；第二节介 绍了几种实现市郊1 1 2 系统数据共享的方案。包括分布式数据库、联邦式数据库 和集中式数据库方案：第三节基于前面几节的论述，选择了较为适合的数据共享 方式，并进行了深入的讨论；本章最后进行了小结。 3 11 1 2 数据库系统软件架构 数据库子系统主要由数据库管理系统和应用软件组成。其中，数据库管理系 统软件一般采用较为成熟的商用软件系统。在数据库管理系统软件之上，可采用 各种技术开发应用软件来满足业务的要求。 3 1 1 数据库管理系统 上海电信市郊11 2 系统共有8 个数据库。软件配置情况如下表所示： d b m s操作系统 市区 s y b a s e a s e1 1 9 2 s o l a r i s2 6 金山m ss q ls e r v e r2 0 0 0w i n d o w s2 0 0 0 其余郊区 s y b a s e a s e1 1 9 2 w i n d o w s2 0 0 0 表格4 数据库软件目a 置表 当前常见的数据库管理系统软件主要有：o r a c l e 、d b 2 、s y b a s ea s e 、m s s q ls e r v e r 等几种。从上表中可以看到，市郊”2 系统主要采用了s y b a s e a s e u r l a 。 s y b a s ea s e 具有以下特点： 1