移动业务运营支撑系统

2024-08-18

移动业务运营支撑系统(共8篇)

1.移动业务运营支撑系统 篇一

**移动技术业务支撑中心工程支撑班主要负责**地区传输管道、线路工程,驻地网工程,无线基站工程,集团客户接入等项目建设。

高效的工程建设是优质网络的基础,工程班每一位成员充分发挥团队精神,努力开展创新工作,在本岗位上兢兢业业,孜孜以求,目标就是一张全区领先,值得信赖的无线通信网络。长期以来,该班组严格按照公司计划顺利开展本地区无线基站建设、扩容、室内分布、WLAN建设任务,为**移动的信息化业务发展做好了有力支撑。

在城市光网方面,截至2011年底,驻地网覆盖用户数达到19万,建设进度在无锡全区保持领先地位。同时,传输资源覆盖大部分城镇新建主干道路,集团客户接入工单及时率达到99%以上,为**地区全业务运营开展夯实了基础,有效扩大移动信息化业务拓展的受益面。

时值“无线城市”、“物联网”等新技术、新标准层出之时,新一轮的信息化大发展正越来越改变着我们的生活,工程班将会一如既往地开展工作,勇于突破,乐于创新,紧跟时代步伐,为满足**人民日益丰富的信息化需求而奋斗!

2.移动业务运营支撑系统 篇二

业务运营支撑系统 (B u s i n e s s&Operation Support System, 简称BOSS) , 是一个综合的业务运营和管理平台。业务运营支撑系统可以划分为业务支撑系统 (Business Support System, 简称BSS) 和运营支撑系统 (Operation Support System, 简称OSS) 两部分, 一般来说, 业务支撑系统主要包含客服、计费、结算等功能, 运营支撑系统主要包含网络管理和资源管理等功能。

业务运营支撑系统主要通过各种IT技术和IT管理办法, 来支撑运营、改善运营。从纵向上看, 它覆盖了运营商的整个业务流程, 包括业务开通、业务保障、业务计量、产品开发等。从横向上看, 它覆盖了客户管理、业务管理、资源管理、网络管理、供应商与合作伙伴管理等层次。

业务运营支撑系统是从运营管理范畴向企业管理范畴的延伸, 除了实现运营功能之外, 企业策略、产品规划、网络与资源规划、收入管理与风险管理等都是业务运营支撑系统关注的内容。

业务运营支撑系统目前在国内各大电信运营商中都有着广泛和深入的应用, 它们早在本世纪初就开始了业务运营支撑系统的建设, 期间不断地对系统进行修改和完善, 并且投资比重持续上升, 有资料表明, 目前各大电信运营商在业务运营支撑系统上的投资已经占到总设备投资的10%~15%, 这也从一个侧面表现出业务运营支撑系统对电信运营商的重大意义。

与之相对应的是, 业务运营支撑系统在各地广电运营商中的应用则刚刚起步, 并且系统的成熟度和复杂度都与电信运营商有着很大的差距。广电运营商需要充分认识到业务运营支撑系统的重要作用, 尽快加强业务运营支撑系统的建设。

2.广电运营商建设业务运营支撑系统的必要性

2.1 建设业务运营支撑系统是“三网融合”背景下的需要

近些年我国开始大力推进“三网融合”战略的实施, 这对于多年来一直在垄断领域经营的广电运营商来说, 既是机遇, 又是挑战, 可以预见, 未来广电运营商与电信运营商势必会在视频、数据、语音等各个领域展开激烈的竞争。资源的壁垒即将不复存在, 经营能力才是决定成败的关键, 而这一点恰恰是广电运营商与电信运营商之间差距最大的地方。广电运营商要想在守住原有阵地的基础上成功出击, 成为继中国移动、中国联通、中国电信之外的第四大运营商, 就必须迅速完成向全业务运营商的转变, 迅速提升业务规划、市场运营、内部管理、服务水平等各方面的能力, 这些工作的完成, 必然需要建设一个现代综合业务运营支撑系统。

2.2 广电运营商原有的用户管理系统已经无法适应新形势下的竞争

在“三网融合”的大背景下, 广电运营商原有用户管理系统的弊端也已经明显地显露出来, 主要体现在以下几个方面:

1) 多个用户管理系统同时存在, 模拟电视、数字电视、VOD、宽带等业务均有各自的用户管理系统, 各个系统之间相互独立, 很难完成信息的交互和统计, 极易形成信息孤岛;

2) 在系统核心上不存在独立的核心数据模型, 增加和改变业务规则和业务流程往往需要对系统核心进行重大修改, 无法对业务的变化进行快速响应;

3) 无法实现多业务的统一运营, 不支持跨业务的产品打包, 营销策略和营销计划也没有固化在系统之中, 很难适应未来多业务运营的需要;

4) 没有完善的客户关系管理 (CRM) 体系, 对客户资料的管理和维护缺乏严格的约束, 对客户的订购行为无法进行深入的统计、分析、预测;

5) 缺少对广电运营商未来发展所需要的计费、账务、结算等等业务过程的支持, 无法实现多业务的融合计费。

2.3 业务运营支撑系统可以极大地促进广电运营商的运营和管理

业务运营支撑系统除了能够解决原有用户管理系统的以上弊端之外, 还可以从以下几方面促进广电运营商的运营和管理:

1) 提高了生产作业的自动化水平, 将绝大多数的关键业务和关键流程纳入计算机管理的范畴, 增强了业务处理能力, 提高了生产效率;

2) 加强了运营管理的有效性, 同时也使得很多关键业务流程由计算机系统执行, 减少了人为的因素和管理的随意性;

3) 在提升管理效率的同时也提升了企业的客户服务水平, 可以使得面向客户服务的关键运营指标得到大幅度的改善;

4) 使企业的各项经营活动过程透明、可控, 并且可以量化, 使各项流程和相关管理制度落到实处, 增强整体的决策能力和管理能力;

5) 成为企业IT战略的重要组成部分, 不仅仅是业务和运营的支撑手段, 也成为企业管理手段, 关键业务流程通过业务运营支撑系统固化, 服务质量保障、关键业务指标也通过业务运营支撑系统实现评估。

3. 广电业务支撑系统的建设目标和实现功能

3.1 广电业务运营支撑系统建设目标

建设一个“以客户为中心, 以市场为导向, 以流程为驱动”, 能有效支持广电运营商向用户提供数字电视业务、数据通信业务、语音通信业务及未来新业务的综合业务运营支撑平台。将此前以系统功能实现为建设目标, 转变到以客户为中心、以市场为导向的建设思路上来, 通过对客户的接触管理和服务请求管理来驱动整个业务运营支撑的过程, 并以此来设计与部署相应的系统功能。

3.2 广电业务运营支撑系统实现功能

1) 实现统一的客户接触管理, 支持多种客户接触渠道, 包括呼叫中心、营业厅、网上营业厅、传真、短信、E-mail等。通过与呼叫中心的互联, 共同支持客户接触、服务请求、订单管理与投诉受理等功能;

2) 支持多业务融合计费与综合账务, 提供统一的计费引擎与综合账务系统以支持全业务的融合, 支持实时采集、实时计费、实时出帐、实时销账等功能, 通过提供实时的余额管理来支持预付费业务, 实现预付费和后付费的融合;

3) 加强费用流失控制手段, 实现收入保障, 在采集、计费、出帐、前端协作、数据交换、数据提供等环节均设计相应的审核检验手段, 确保处理的准确性, 最大限度地减少费用流失;

4) 能够灵活地支持各种营销策略, 能快速实施业务修改与新业务上线;

5) 实现与外部系统相关接口的集成, 包括CA系统、VOD系统、财务系统、第三方CP/SP平台、监管平台、银行系统等。

4. 结语

业务运营支撑系统对于广电运营商来说, 是发展过程中更高级的支撑平台, 也是未来经营活动中所必须依赖的管理平台。它能够有力地推动企业的经营发展, 深刻地约束经营活动的各个业务管理环节。广电运营商建设业务运营支撑系统意义重大, 势在必行。

参考文献

3.移动业务运营支撑系统 篇三

珠海广播电视台网络公司从1999年开始进行网络改造,2003年底基本完成市区骨干网双向改造,分配网相应从550MHz升级为860MHz。市区有线电视用户约为23万户,CableModem用户为25万户。系统方面,2005年7月完成了有线数字电视用户管理系统(SMS)的招标工作。

从有线电视网络的运营特征来看,其与电信/移动有许多相似之处,这些相似性在网络融合的趋势下表现的更加明显。如电信BOSS系统具有“以客户为中心,整合灵活的平台和统一的平台”等特点,从系统理念、功能模块、技术体系等各个层面来分析,应用在有线电视网络中是完全可行的。

珠海广播电视台网络公司于2007年7月重新进行了BOSS系统的招标工作,最终选定了诚毅公司的解决方案,并于2007年12月开始对珠海数字电视及宽带业务进行需求调研,目前。前期需求已基本整理完毕,预计将在2008年6月完成系统开发和数据割接工作,并开始试运行。

系统总体规划

1、建设目标

1)建立业务运营网络和分销渠道

提供营业厅等的直接接入,各种分销渠道的简单业务连接及CallCenter、网站、多媒体自助终端、银行现金代收、实时划账等多种数据交互模式,最大限度拓展业务运营支撑系统的运营渠道和运营空间;

2)建立灵活、有竟争能力的市场营铺体系

通过灵活、准确和及时的计费和账务处理系统提高计费、出账、收款的效率和准确性,提高收视费的回收率,减少坏账的产生几率;

3)充分考虑未来发展。制订增值平台的接入规范和运营规则

统一增值业务的计费规则,将增值业务纳入有序管理的环境中,以确保增值业务的健康发展;

4)建立完整的资源管理系统

加强对各种资源的集中管理,提高资源管理的效率、为各种资源的组合打包、调整服务提供支持,达到物尽其用;

5)配合数字电视发展规划

提供灵活有效的方案,确保模拟电视向数字电视的整体平移,实现业务的平稳过渡。

2、设计思想

一个好的BOSS框架,可最大限度降低系统内部的消耗,并能够将硬件系统和软件系统的性能发挥至最佳状态,从而降低整个系统的建设和运营成本。

1)面向对象

采用面向对象的设计思路,以方便业务系统构造、缩短开发周期、确保开发质量。

2)多层应用的B/S模式

采用多层B/S模式,提供一个公共的应用通信及数据接口平台,实现应用及实现的分离,以保障系统的完整性和核心数据的安全性。实现同构和异构环境下的多种数据源通信,提高系统与其他系统的互联性及扩展能力。

3)并发的程序设计思想

操作系统、数据库系统、中间件和应用系统均支持整个系统大用户量并发访问,大幅提升响应性能。

4)基于E-R关系的数据库设计

数据库表设计以实体一关系(E-R关系模型)为基础,数据结构的紧密关联,保障了数据一致性、完整性,提升了系统的可靠性及完整型。

5)模块化独立设计

将应用程序分为多个既能独立运行又可灵活组合的程序包,以提高系统的灵活性、扩充性和可维护性。

3、系统管理层次划分

在系统的管理上,将整个系统划分为决策支持层、管理层和业务运行层三个层次。

★决策支持层

为决策人员提供生产业务和管理控制的各种信息,为有线电视网络的战略决策提供决策手段。

★管理层

为管理人员提供各种管理功能,便于管理者方便获取统计分析数据,详细了解业务的运行情况和发展趋势,实现信息管理的自动化和科学化。

★业务运行层

主要实现面向用户的各种业务需求,并对系统的运行提供保障和支持。

4、技术层次划分

★系统体系架构

在技术实现上,BOSS系统须能够充分应对有线业务快速发展的需求,因此其逻辑结构应当具备良好的层次,同时不同的层次结构间的耦合关系应尽可能小。

珠海BOSS系统采用J2EE架构,分为客户接入层、界面表现层、业务逻辑层和核心数据资源层,界面实现了Web化。这样的结构不但避免了客户端臃肿、版本发布与升级的工作量大、客户端界面与其他系统的界面整合比较困难、业务逻辑和展现逻辑没有完全分离等问题,提升了维护和版本升级的效率,同时也为与其他系统的界面整合和系统自身的扩展提供了更多的空间。

★表现层

主要功能为实现用户交互和数据显示,为以后的处理收集数据,向第二层业务逻辑请求调用核心服务处理,并显示处理结果。这一层功能的实现主要有两种方式:①GUI,即图形用户界面,采用VB、PowerBuilder、Delphi等进行开发;②Browser,即浏览器,用HTML结合Servlet进行开发(珠海的前端采用B/S结构,因此采用第二种方式)。

★逻辑层

该层为本系统的核心层。物理分布的多台设备通过事务管理器构成虚拟主机,虚拟主机上分布着多个服务器,每个服务器可支撑多种服务。服务是业务逻辑的具体体现。也是接受客户服务请求的基本单元。业务逻辑层通过XA协议与数据层的数据库连接,与表示层则是通过ATMIAPI进行交互。

★资源层

该层可以是多个关系型数据库,也可以是异构数据库。

九大功能及实现

1、业务受理

客户可通过多种服务渠道享受珠海有线提供的各种服务,包括业务受理、用户缴费、产品订购等。业务受理功能可显示客户的全面信息,如基本资料、业务变更、账务登记、客服资料、售后服务资料等,方便全面了解客户情况,加强对市场营销的支持。

为实现面向客户销售自动化的目标,BOSS系统必须对销售过程的各类行为及活动进行流程化管理。即通过流程管理机制,实现对各项营销活动的自动跟踪、记录、调度和监控。业务受理能支持多种接入方式,包括面对面、语音、Internet、移动终端及其他方式。

BOSS业务受理功能包括:开户、增装、过户、迁移、更改账户信息、资料更改、停机、开机、销户、修改密码、修改服务方式、产品订购、退订业务、更换设备、营业收费、营销方案办理、用户资料查询、业务异动查询、用户业务类型查询、用户产品查询、待处理资料查询等。

2、账务处理

帐务管理主要完成根据计费的清单结果进行出账以及固定费用的计算等功能,出账处理、调账处理、账务托收和销售处理等。可将所有账单文件按用户编号、业务类型进行合

并或分离。

3、资源管理

本模块主要完成各类业务所需资源的集中管理,涉及到的进销存流程。

流程描述:订购相关业务资源——各营业厅、分公司根据业务需要从总库领取业务资源——营业厅、分公司之间可以进行资源的调配或调拨,通过客户业务办理完成资源的销售——系统可为因各种原因产生的客户设备更换提供支持,有问题的设备可经营业厅、分公司退回公司总库,再由公司总库统一处理(譬如退回供货商)——总公司仓库或分公司、营业厅仓库定期进行盘点。

根据以上流程,本模块主要包括:配置管理、入库、退货、盘点、出库,退库、调拨,及地址资料清理、资源告警、状态修改、资源查询、认证资源管理等功能。

4、产品管理

产品管理模块的主要功能为,对产品的相应属性进行设置、主要包括产品基本信息、CA产品、费用、停用期间产品费用、包容互斥关系、促销方案等的设置。最后还需通过相应部门的审核才能最终发布。促销方案优惠的内容主要包括对资费、产品、设备、账户、客户群、时段、跨业务类型的优惠等。

5、终端销售管理

终端销售模块负责管理公司的各种有编号设备(包括机顶盒、有线电视卡、Ic卡、各种充值卡等)以及其他无编号设备(包括网线、双叉线、遥控器等)的批发、零售业务,对各终端销售商的设备订购、代销、付款进行统一管理,并跟踪设备的流向。

6、客服管理

客服管理功能包括:投诉、咨询、维修、建议、客服业务受理、复核派单、维修派工、工单处理、客服工单查询、客服日志查询、客户建议处理对、重大故障、刷新授权、客服知识库维护、发送短信息、工单分步时限、节目预订、满意度调查、客户信息管理、客服统计分析等。

7、接口管理

珠海BOSS管理系统外围接口平台管理主要包括:

★CA接口

实时将OSS系统送来的相关客户数据翻译成CA的系统指令,送入CA的相应系统中执行;对CA的执行结果或返回的有关信息做出相应处理,能同时支持爱迪德、永新同方等不同的CA系统。

★监管平台接口

支持广电总局监管平台需要的信息查询接口。

★现金代缴接口

客户通过银行缴纳客户的服务使用费,由银行方向我方发起缴费请求,银行对我方账户进行销账处理。

★电子报盘接口

电子报盘是我方委托银行方收取客户服务使用费,将客户所付费用从其银行账户转到我方账户的处理过程。

★短信接口

与其他运营商合作,通过短信平台提高客户服务水平,同时还可开展付费节目的营销工作。

★宽带认证接口

通过宽带接入服务器完成对上网用户的认证和数据采集,将用户上网的主要信息传递给BOSS系统,从而完成对上网用户的控制。

★其他系统接口

与其它相关系统进行通讯的接口。预留如与珠海GIS(地理信息系统)系统、OA系统、仓库管理系统等的接口。

8、数据分析与统计处理

可提供业务处理、市场分析和财务结算所需的各种业务、账务和资源分析报表,为相关部门和管理人员提供准确、实时的统计数据,方便进行业务管理,减少人员的手工操作,提高工作效率。

报表处理功能包括:业务报表、状态统计报表、业务发展报表、账务报表、业务资源报表等。

9、系统管理

4.移动业务运营支撑系统 篇四

光缆网现状

移动运营商在长期发展过程中,已经从上至下建设起一个适应移动通信的光缆网。从覆盖范围上可将光缆网分为省际长途干线、省内长途干线和本地传送网三个级别。本地传送网按网络规模大小又分为核心层、汇聚层、接入层三个网络层次。本文将重点介绍全业务影响最大的本地光缆网。

核心(骨干)层光缆网是连接本地核心机房之间的光缆网。移动网络在核心层高度集中,核心机房数量少,一般在2~4个,少数发达地市在4个以上,机房多集中在市区,相互间距离短。核心机房内安装的设备是整个网络的大脑和心脏,机房间传输数据量大,业务密集。核心节点间传输的顺畅与否直接关系到整个网络的安全,一旦发生意外必定是重大事故。因此,核心层传送网的特点是容量大、冗余备份多、安全性极高。核心层光缆结构多为多环叠加的方式,核心节点4个以上的地区,逐步实现光缆网格化,核心光缆芯数一般在48~144芯之间,全程采用管道方式敷设。

汇聚层光缆是连接汇聚节点之间以及汇聚节点与核心节点的光缆,是介于移动基站与核心节点之间的光缆网络,用于将底层传送需求集中,提高网络传送效率,降低CAPEX和OPEX。由于汇聚节点数量多,分布广,环行结构是首选。在业务量大的地区,已建成独立的汇聚层光缆。在业务量较小的地区,汇聚层光缆与接入层光缆混合使用。汇聚层光缆的市区芯数在36芯以上,郊县、农村地区则在24~48芯之间。城区光缆敷设以管道方式为主,郊县和农村以杆路质量较好的接入层杆路或专用汇聚层杆路为主。

接入层光缆是连接移动基站之间或基站与汇聚节点的光缆,同时兼顾少量营业厅和集团客户。光缆网结构以环行为主,辅以少量的星型、树型。光缆芯数一般在24芯以下,敷设方式无特殊要求,各地根据实际情况决定采用管道、架空或直埋等多种方式。

移动运营商光缆网结构现状如图1所示。

图1 移动运营商光缆网分成结构示意图

全业务背景下业务和技术对光缆网的影响

全业务在国外又称为“多业务”或“综合业务”。全业务运营可以分为狭义和广义,狭义的全业务运营是基于政策管制角度进行定义,即移动业务、固话业务、宽带业务,还包括基于以上三种基本业务延伸和拓展的各类增值和信息化业务(VOD、视频监控等)。广义定义是基于多业务领域与通信的结合,即综合信息服务、通信+多媒体信息服务+综合信息解决方案。本文主要指狭义的全业务,它所对应的网络包括移动网络、固定网络及互联网络。

从整体来看,移动运营商向全业务转型的重点在于在现有以移动业务为主的网络中引入固定和宽带数据业务。业务网的融合转型催生了大量新技术,新技术的出现又反过来改变了网络架构模式,推动业务层面向全业务融合。网络架构模式的变化和新技术的发展,又对底层光缆网的建设产生较大影响,下面将分析全业务网络的主要变化特征对光缆网的影响。

1.3G

3G网络核心层设备集中设置在少数核心机房,大量数据通过大容量的局间中继传送系统疏导,对核心层光缆网影响不大。在接入层,3G移动基站对光缆网的需求与2G基本相同,应重点保障基站接入光缆的安全性和稳定性。在网络建设初期,大部分3G基站将与2G基站共址,但3G基站需要支持高速率的数据业务,在基站空口能力提升的同时,覆盖半径在逐渐变小,后期3G基站密度将较2G网络有所加大,光缆网密度在接入层也需要随之适当加大(即FTTM),网络结构仍然以环行为主。3G基站数据电路需求量大,类型复杂,可在传输系统层面通过更加智能高效的MSTP/PTN传送技术解决。

2.固定语音、互联网

固定语音和互联网接入服务是移动运营商网络中资源比较匮乏的部分。随着网络技术的发展,移动运营商建设传统固话网络的可能性很小,更可行的方式是利用软交换技术和IP技术的结合,在数据城域网平台上承载固网软交换业务,通过综合接入终端(PON+LAN+I)为用户同时提供固定语音和互联网服务。为能提供互联网业务,运营商需在核心汇聚层建设数据城域网,在接入层建设FTTx为主的数据接入网。在核心层,由于核心网元高度集中,对光缆需求不大;在汇聚层,应充分利用现有汇聚层光缆资源,数据城域汇聚点布局时应尽量与传输汇聚节点重合。但数据城域网汇聚设备与BRAS之间连接为双归星型,与汇聚层光缆环行结构存在一定差异,直接用现有的汇聚光缆网承载,不但会造成大量纤芯资源的浪费,而且中间跳纤点过多,还会增加网络故障点。因此要求光缆网需逐步由环行向网格型演进,需增建城域数据汇聚节点与数据核心节点之间的直达光缆路由,或在汇聚光缆网之上增加汇聚调度光缆,重新配置汇聚纤芯资源。在接入层,全面建设面向用户的FTTx光缆网,满足海量用户的接入需求是主要任务。

3.网络扁平化

网络扁平化是业务网转型的必然结果。网络扁平化后,核心层网络膨胀,核心节点之间连接更加紧密,跨片区、跨地市甚至是跨省的光缆路由需求增多。接入层由于可以方便地接入到核心网络,单个接入光缆网的覆盖范围缩小,整体网络规模加大,光缆网更加靠近用户,光缆网的接入能力和接入便利性得到提高。

4.网络IP化

对移动运营商而言,网络IP化最大的变化在于移动基站的IP化。但无论是2G还是3G,无论其电路形式是TDM还是IP化的,均要求承载层能够提供电信级保护,因此传送网的网络结构不会产生大的变化,在汇聚层和接入层,光缆网仍将以高效安全的环行结构为主,通过传输设备升级提供IP接口,应对网络IP化初期电路传送需求。

5.网络宽带化

随着IP业务的发展,普通移动个人用户和互联网用户对带宽的需求也越来越高。在接入层,无线接入的宽带化,使得移动基站IP化之前的电路需求由1~3个E1扩大到5个以上,IP化后电路接口将以10Mbit/s甚至100Mbit/s为主。随着高清IPTV等业务的普及,普通互联网用户带宽需求也将达到10~30Mbit/s。在汇聚层,上联带宽已经达到1GE,正全面向10GE升级。若仍采用传输系统解决如此大容量的传输电路需求,将会占用大量汇聚层和核心层带宽,系统复杂度和建设维护成本也随之升高,裸纤直连的优越性逐渐凸显,这就需要增大汇聚层光缆密度。

6.传送网技术发展

在核心汇聚层,传送能力强大的WDN/OTN技术大大降低了业务对光纤需求的压力,光缆容量无需大规模扩容。但技术的发展无法弥补光缆路由不足的缺陷,相反需要光缆网的网格化来支撑传送网系统向MESH升级。光纤路由的不丰富,将制约设备性能发挥。接入层MSTP/PTN技术与核心层相类似,利用设备的处理能力缓解了接入点电路需求增加造成的压力,网络结构也无需作大规模调整。

归纳以上分析,全业务技术环境下除数据城域网和用户接入网分别对光缆核心、汇聚层和接入层产生很大影响外,其他变化因素都可在现有光缆网基础上灵活应对。

全业务光缆目标网架构

综合未来网络发展需要,移动运营商全业务光缆网应分为核心、汇聚、接入三层。其中核心层、汇聚层为多业务共享的物理平台,接入层可再细分为主干(馈线)光缆、配线光缆和末端引入光缆。主干光缆可考虑多业务共享,而配线和末端引入由于基站接入和用户接入需求差异较大,建议独立建设。核心节点三个以上的大型本地网,核心光缆网结构以网格状为主,非数据核心节点之间与数据核心节点之间光缆芯数应适当加大,以满足数据城域网连接需要。汇聚层光缆仍然以环行为主,并逐步在汇聚层之上以数据汇聚节点为中心叠加汇聚调度层,增加数据汇聚节点与核心节点之间的直达光缆,推动汇聚层光缆网向网格化、扁平化演进。接入层解决2G、3G移动基站接入的光缆网应以环行为主,用户接入光缆网应以星型、树形为主,辅以少量环行光缆网,为重要客户提供更高质量的保证。光缆网的整体架构如图2所示。

图2 光缆网整体架构示意图

用户接入光缆网(FTTx)架构中,FTTx光缆网又分为主干、配线和末端接入三层。为提高接入效率,降低建设成本,降低线路衰耗,主干、配线光缆采用星型和树型结构,利用基站和光交递减配纤或非递减配纤。同时,FTTx网络应能支持为少数重要客户提供路由保护和后期扩容,因此,需保留部分公共光纤。FTTx主干、配纤光缆结构建议如图3所示。FTTx主干、配纤光缆结构示意图

光缆网发展策略

1.光缆网建设应统一规划,分区分步实施。光缆网是底层物理层,多业务共享,要综合考虑各种影响因素和所有业务需求,需要统一规划,避免重复建设和资源浪费。由于用户接入光缆网的特殊性,其分布面广,接入数量庞大,光缆若要一次到位投入巨大,投资效益比很低。因此,需要根据市场拓展情况逐步实施,先覆盖用户密集、业务发展好的地区,后逐步向周边渗透;先解决资源问题,后提高容量。

2.充分利用现有资源。移动运营商已经建成的大量汇聚光缆、汇聚节点和基站,是其光缆网向客户推进的基础,应以这些点为基点,向下敷设主干、配线光缆,覆盖周边用户。向上利用汇聚核心光缆,完成业务汇聚。

3.核心汇聚层扁平化,接入层纵深化。受业务网和传送网技术发展的影响,核心汇聚层光缆将逐步扁平化。随着汇聚层与核心层的连接光缆越来越多,层次间的界限也逐步模糊。而在接入层,为维持基站接入光缆网的稳定,应独立发展面向基站接入的光缆网和面向用户的光缆网。用户接入光缆数量庞大,若直接接入汇聚层,将会给汇聚节点周边管线和进出局管道造成巨大的压力,因此需要通过移动基站、光缆交接箱、接头盒等设施逐级汇聚,通过分光器汇聚节约主干光缆线芯资源,尽量避免末端接入光缆直接进入汇聚节点。

4.网络建设差异化。在光缆网建设过程中,也应对光缆接入对象进行等级划分,为不同的用户提供安全级别不同的接入服务,以有效控制网络建设成本,体现差异化服务(SLA)的服务特色。对于移动基站、集团大客户等,应使用安全级别高的环形光网络,普通用户使用成本低、效率高的星型和树型光网络。

5.积极采用新技术,推动FTTx光缆网建设。移动运营商作为固定接入和互联网接入的后进入者,基础资源相对匮乏。但同时又必须打造优于先进入者的光缆网,来吸引用户。要想达到目的,就必须利用新型光纤光缆和新的施工工艺,如微管微缆、浅槽光缆等,快速建设更加贴近客户的光缆网。

6.多运营商网络资源共享。在核心汇聚层,需要保障光缆网的绝对安全和稳定,以及在故障时的快速响应,因此,建议尽量确保使用自有管线资源。在接入层,情况复杂,管线需求数量庞大,应加大资源共享力度,节约投资。

光缆建设技术选型

1.光纤类型选择

目前最常使用的光纤类型主要有G.652和G.655光纤。对于通路非常密集的WDM系统,G.652光纤能有效抑制影响系统的主要因素——FWM效应,在技术上有更多的优势。高密度、大容量的WDM/OTN系统是未来干线和核心汇聚层光传送系统中的主流技术。因此,笔者建议干线、核心层、汇聚层选用G.652D光纤。在接入层,速率相对较低的传送系统对纤芯各项指标的要求除衰耗外,其他并不严格,仍然可以采用G.652B型光纤。

FTTx网络进入用户建筑物内后,因为特殊的施工条件,需要使用G.657低弯曲损耗敏感单模光纤。考虑到与本地光缆网G.652光纤的兼容性,应优先考虑使用G.657A型。G.657光纤在国内尚未得到大范围使用,价格仍然偏高,应尽量减少G.657光缆的使用量。

2.光缆结构选择

光缆结构设计已经非常成熟,并且经过了长期商用的考验。骨干、汇聚层大芯数光缆优先选择骨架式、层绞式光缆,接入层选用层绞式、中心束管式,末端引入层则可采用敷设简单、室内外通用的8字型和气吹架空型等各种新型干式、半干式光缆。

5.移动业务运营支撑系统 篇五

国内电信业的竞争正从“资源竞争”转移到“业务竞争。”在这个转移过程中,各大运营商纷纷重新规划建设适应新电信环境的运营支撑系统。一时间,关于BOSS的讨论、研究以及相关的建设案例被炒得热闹非凡。可就在这热闹繁华的泡沫底下,往往会看到运营商的业务发展被不完善的支撑系统所拖累,投入了大量资金,却远远没有达到预想的效果,而软件集成商在获取大量订单的情况下,却一个一个陷入到BOSS系统的建设项目当中,消耗了大量人力、财力。

我们必须让自己冷静下来,思考问题究竟出在哪里?

总结国内的BOSS系统建设情况,有以下五大硬伤,严重影响着运营支撑系统的正常发展。

一、赢单不赢利

对于国内做电信运营支撑系统的软件集成商来说,目前最头痛的问题就是赢单不赢利。在BOSS系统的招标过程中,有的竞争厂商为了拿到订单,大打价格战;也有新进入的厂商处于所谓的战略考虑,直接出地板价拿下;还有的运营商预算低,让厂商没有任何回旋余地。这样一来,软件集成商处于一种尴尬的境地:“拿不着单是等死,拿下单是找死。”

对于这种情况,运营商往往并不在意,甚至是一定程度地纵容。殊不知,软件厂商在出现利润长期得不到保证的情况下,要么是给多少钱,出多少力,集成商投入少,导致提供给运营商的软件质量和服务得不到保障;要么是由软件集成商亏本投入,最后支撑不下去而放弃。这种例子,在国内BOSS系统建设中比比皆是。

当然,出现这种情况,国内的软件集成商自身也有很大问题。由于它们的产品设计不到位,质量不过硬,基本上是项目型的公司,且项目管理差强人意,系统实施的周期过长,从而导致项目成本居高不下。使得本来就少的利润被进一步侵蚀。

因此要扭转这种“赢单不赢利”的局面,只能从两方面着手:一方面,运营商应该认识到,一味降价并不是好事,一个报价过低的系统,不是软件本身有问题,就是后续的服务跟不上,因此需要预留一定程度的利润给软件集成商,以充分保证软件质量的可靠和持续的服务;另一方面,软件集成商要狠抓内部管理、合理控制成本、严格管理软件开发过程、优化产品质量,改纯项目型公司运作为项目、产品迭代运作方式,通过项目完善自身的产品,通过产品化来减少项目实施周期,稳定产品质量。

二、过分乐观的工期

尽管大家都知道BOSS系统是一项非常艰巨、周期相当长的系统工程,但在实际系统建设过程中,却经常将其忘之脑后。其理由为,一是软件集成商的销售人员为了拿单,在应标时投运营商所好,宣称在较短的时间内能够将系统实施完成;二是运营商由于各种因素,包括一些企业内部的“政治”因素,将工程预期压缩得很短。

因此一个完整的BOSS系统,在各方因素的推动下,被要求在3个月、甚至是1个月之内实施上线。如果是拿现成的产品实施倒也罢了,但运营商还有非常多的个性化需求和自有的业务处理流程,软件集成商提供的产品又没有足够的灵活性去适应运营商个性化的需求。更严重的是,运营商和软件集成商缺乏全面把握业务的人才,无法细致地在前期定义功能需求。

有了这么多的限制条件,系统还要在非常紧的工期下实施上线,于是在资源、质量、进度均衡的项目管理平衡圈上,便只有牺牲系统的质量了。过粗的需求分析、草草的设计、未经严格测试的系统,匆匆忙忙赶在期限内上线,结果当然可想而知,更谈不上对系统扩展性的远期规划。系统漏洞百出,然后又在本来就不牢固的基础上现场打补丁,越改越乱的情况经常出现。好一点的勉强应付,差一点的被推到重来。几番折腾,到系统能够稳定运行时,已经离当初的预期过去很远了。如此匆忙应急救火的行为,可谓是“能让项目尽早地开始,却不能让项目尽早地结束。”

既然知道带着光环的工期不切现实,运营商和系统集成商不如静下心来,做好系统的项目规划。即使是业务紧,迫切需要新系统的支持,也可以根据系统的轻重缓急,规划好建设的分期分批实施,不要想着一步登天。这方面,可以充分借鉴OMM(运营成熟度模型)。BOSS系统的建设,最重要的是要打好基础,构架好扩展性、伸缩性良好的数据模型和技术体系。一两次应急系统的建设可能还说得过去,要是长此以往,运营商和系统集成商总是在忙于类似的系统应急和救火,问题就大了。

三、变化的需求和难变的系统

如果任意问一个BOSS系统的项目经理,关于BOSS项目最头痛的5个问题,估计80%的人的回答是“客户的需求变化太快。”

需求变化快,系统还没上线,原来的业务流程就变了,需要支持的业务又增多了,数据格式和以前又不同了。国内现有的BOSS系统,对于这些种种的变化,又缺乏足够的适应能力。尽管各个厂家都会宣称自己的系统灵活性怎么强,可遇到实际情况的变化,又都是一顿手忙脚乱地修改。最痛苦的是,需要将以前的模块推倒重来才能适应新的要求。

“多变的需求”经常是运营商和系统集成商产生纠纷的最主要原因。

从系统集成商的角度看,合同签订时,不覆盖这些变化的需求,能不做就不做,能少做就少做;而对于运营商来讲,投资了这么大一个系统,可一些关键业务还支持不了,更是想不通,于是便压着集成商反复修改,反正“顾客就是上帝,钱在谁手里谁是大爷。”

变化的需求固然需要控制,但是我们应更多地站在运营商的角度考虑。首先,运营商要发展,业务必然会根据竞争情况发生变化;其次,构建的BOSS系统绝对不是一个静态的系统,必须“与时俱进”。

“如何支持从几十种业务到几百种业务的扩充”、“如何支持从几十万用户到几百万用户规模的增长”、“如何支持运营商各种个性化服务”等问题,都必须是在构建BOSS系统时重点考虑的问题。

再回到项目与产品的关系上面来,对于BOSS系统的建设,应遵循以下理念:

统不需修改就能适应电信行业业务管理70%左右的共性化功能;

过系统数据定制的方式,适应运营商25%左右的个性化的功能;

不推翻原有架构、不重做原有模块,利用面向对象的继承和重用,以增加业务插件的方式,满足剩余5%的功能。

四、铁打的营盘流水的兵

BOSS系统的建设讲究长期规划、分布实施和持续建设。对于系统建设是这样,对于参与建设的人来说,也同样如此。但对于国内的软件集成商来说,能做到这一点的,可谓少之又少。

由于大多数公司都是项目型的公司,有了项目,就把开发人员、实施人员长期置于外面出差。有很多不适应这种状况的人员,在公司无望解决这种局面的时候,选择了退出。还有的就是公司之间挖墙角。有的甚至是整个项目团队被连锅端掉。挖墙角时,有冲人去的,将骨干人员挖过来,补充自己的设计开发力量;也有冲公司去的,如两个公司同时在竞一个标,其中一个公司将其主要人员挖过去,使得另外一个公司力量被极大削弱,而被迫退出。

更多的是,软件集成商内部根本就没有长久的规划,跟着运营商的指挥棒走。今年大力建设“九七系统”时,全力投入做“九七”;明年本地网计费系统热起来了,又把力量转向本地网计费系统;过一阵大家一炒CRM,人员又去改做CRM系统。而一旦没拿到单,相关人员裁的裁,转的转。等拿到单时,又临时去拼凑人员,重砌炉灶来建设系统。

很多厂家就是这样,一轮一轮地进行着低水平的重复,没有积累或很少积累,公司总觉得上不了规模。总觉得没单的时候人太多,把人闲死;有单的时候人又太少,把人忙死。

注重持续发展的公司,一定要有自己的产品线规划。要静得下心、沉得住气,保留和稳定一批队伍,注重产品开发。走项目与产品迭代发展的路线,产品出来后,拿到实际项目中检验完善,然后再整理提高,以此不断地循环反复,产品的水平自然而然地就上去了。

公司运作的目的是什么,谈得很多的是四个“价值最大化”:股东价值最大化、客户价值最大化、员工价值最大化和社会价值最大化。这四个方面中,“员工价值最大化”是一个基础。没有员工长期的、富有创造力的奉献,根本谈不上其他三个方面。

对于员工来说,有三点非常重要:成就感、利益和自身能力的不断提高;而对于公司来说,怎样将公司的成就、利润和发展与员工的以上方面有效地结合在一起,形成一个良性循环,这点尤显重要。只看事物的任何一方面,都会走向极端。

五、“城头变幻大王旗”

在任何领域,追求的都是长期友好的合作。但对于国内BOSS系统的建设,经常看到的却是“城头变幻大王旗”。可换来换去还是那么几家集成商,换来换去的系统,本质上并没有多

大改变。

软件集成商的愿望都是美好的,都希望做好项目。可遇到种种实际情况时,美好的愿望就打了折扣。比如软件厂商拿到的订单一多,人手忙不过来;或签下的订单利润不高,不愿意过多地投入;或自身软件能力存在问题;或项目管理失控;或人员频繁变动;或厂商和运营商产生冲突。有了这些主观和客观的因素,反映到最后提交的系统就是一个差强人意的系统。

运营商有时也提出一些理想但不切实际的要求,让软件集成商勉为其难,或者是眼里容不得一点沙子,一些小问题故意扩大化。

而在软件集成商内部,却经常不大理会运营商的一些问题,认为运营商提出的问题幼稚,在技术上一点也不懂;而运营商则认为号称高科技的公司,却做出这么一个漏洞百出的系统,运营商内部的一些人员甚至经常恶意责骂集成商开发人员的能力。宁愿冒着自己建设的系统上不去、出大问题的风险,也要去看软件集成商的笑话。

这样一来,本来就存在不少问题的系统,再加上运营商和软件集成商之间的不协调,互相看不起,将问题都推到对方身上。结果就经常出现“签单前是朋友,实施后成怨敌”的情况。当运营商进行下一期BOSS系统建设时,更换厂家就是自然而然的事情了。

可是更换的成本和代价是相当大的,劳民又伤财。并且,在没有解决本质问题的时候,每一次更换,又是新一轮争吵的开始。

要解决这个问题,双方都需要从完善自身着手,但运营商可以发挥更多的主导作用。在招标时,不要轻易相信软件厂商许下的空头支票,一定要眼见为实,同时细致地、多角度地考察兄弟运营商的建设情况,以及软件集成商的历史表现,初期就剔除不合格的厂家;建设时,既要严格规范,又要从实际出发。不把自己当作出钱的甲方,颐指气使。心态上更应该将软件集成商当作是一个壕沟的战友,和软件集成商一起共同面对问题、解决问题。

6.移动业务运营支撑系统 篇六

如何随时把握外勤人员每日的行程?如何对外勤人员进行科学、体系的调度组织?如何完成进步出售成绩和操控差旅、燃油本钱?如何包管依照决策者的目的,不折不扣的履行到位?

企业信息化管理中,针对外勤人员的考核管理是非常重要的一个部分。尤其是外勤销售人员,因为缺少有力的进程监督、监控手法,外勤人员任务难以进行实时办理,招致消极怠工、虚伪报销、敷衍塞责、任务不敷勤勉等履行力缺乏的状况时有发生,并且,呈现了问题往往过后好久才会被发现。

对准外出人员,让办理者随时查看外出人员在外出走访客户的详细方位,上下班移动考勤管理,员工可主动上报位置。节省公司与员工的工夫本钱,节省费用,使任务通明,使职工出勤100%,成绩晋升。

杰信通—外勤管理定位系统成功的完成企业科学信息化管理,成功打扫企业关于外勤人员管理的盲点死角,真实完成企业外出人员的移动任务、科学考勤管理。杰信通—外勤管理定位系统是专为企业客户供给实时双向数据通信和定位考勤管理的新式管理方式,真正的解决企业针对外勤业务员管理难的问题。

杰信通业务员外勤管理定位系统,是一个相互调配的管理系统,管理者可以主动对外出业务员进行位置查询,外出业务员也可以将自己的位置汇报到,杰信通—外勤管理系统会统计两者的数据,形成统一格式的考勤报表,正真满足管理者的需求。

7.移动业务运营支撑系统 篇七

随着电信业竞争的日趋白热化, 客户选择电信业务及电信企业的余地越来越大, 电信企业之间对客户的争夺也越来越激烈。不断的价格战, 导致电信市场出现了严重的“增量不增收”现象, 大量低忠诚度的客户转网或变更业务。电信企业虽纷纷开展具有一定优惠期限的活动以降低客户的流失率, 但优惠期结束后, 很多客户仍然纷纷离网或弃卡重新入网以换得新的优惠, 也造成了企业收入的下滑和客户发展的低效率、高成本。另一方面, 电信客户近年来高速增长, 形成了需求差异很大的客户群;适用于不同客户群的各种新业务不断推出, 电信企业需要通过细分市场、细分客户群, 将最合适的业务推销给最需要的客户, 以实现业务和客户的最佳匹配。

在这种局面下, 如何运用科学的经营分析方法, 实现精细化管理和营销, 以高质量的服务吸引、留住客户, 扩大市场占有率, 就成为当前电信企业亟待解决的问题。淄博联通积极采取各项措施, 利用规模发展和重点突破, 实现了移动业务的快速发展。但随着市场精细化营销水平和深度运营能力的不断提升, 各种经营分析和营销活动对后台支撑系统提出了越来越高的要求, 原先的系统已经不能适应经营分析和营销工作的需要。鉴于此, 为向市场一线提供可靠、精准、灵活、高效的支撑系统服务, 淄博联通信息化支撑中心今年5月份开发建设了移动业务综合支撑系统, 8月正式上线, 并收到了初步成效。

2 移动业务综合支撑系统的建设目标

移动业务综合支撑系统的建设目标, 是建立面向企业运营的统一数据信息平台, 为移动业务的客户服务、市场营销、经营决策、业务实施、渠道管理等工作提供有效的支撑, 同时进一步支持市公司对所属分公司、电话局、营销中心、营销经理等经营活动的管理和指导, 为企业的精细化运营提供系统数据基础支撑。

3 移动业务综合支撑系统的功能

3.1 经营分析

系统基于OLAP的多维分析技术, 按照轴、面、群的分析方法, 对移动业务指标从品牌、客户变化、ARPU值、时间、地区、用户特性等维度进行层层分解, 并对分解出的群中所包含的内容进行综合分析, 分析内容包括客户数、收入、发展量、增值业务等。分析粒度覆盖分公司、营销中心、电话局、渠道经理、代理商、营销经理各个层面, 提供日报、月报、自定义时间段的相关统计数据, 对各级营销部门都提供全面的支撑。系统还重点对各类营销活动进行质量和收益分析, 为各项经营决策提供辅助分析工具, 有效避免“增量不增收”情况的发生。

3.2 客户消费分析

系统提供未出账用户分析、优惠到期预警、客户消费层次分析、消费异动预警、客户流失分析、客户增值业务分析等功能, 与前台营销、维系等市场经营活动充分结合, 为前台的营销和维系活动提供目标客户清单, 使相关工作有的放矢, 大大提高工作的质量和效率。

3.3 渠道管理

系统为渠道管理人员提供对渠道业务发展情况的分析、考评与监控的工具, 保证渠道管理的高效有序。具体功能包括:渠道信息管理、渠道业务统计分析、渠道绩效考核、渠道星级管理、渠道经理走访管理、渠道信息短信收发平台、佣金稽核等。

通过绩效考核与星级评定, 对渠道的市场拓展、业务宣传、客户服务、新业务营销等方面予以考核奖励, 提升社会渠道的积极性和忠诚度。

通过渠道预警功能, 对渠道监控开卡量、发展量等情况到达预警阀值时自动生成预警短信, 依据预警级别自动发送给渠道经理直至相应管理人员, 以提升社会渠道的控制力和发展效能。

通过短信平台, 实现佣金短信通知, 做到及时发放, 奖罚透明;另外, 系统通过短信向代理商实时发送各类通知信息和实时指标进度, 实现基层渠道服务的信息直达, 简化中间传递环节, 缩短信息传递时间。系统还面向代理商建立短信建议平台, 并可跟踪、监控建议处理结果, 加强双向沟通, 促进渠道管理的不断完善, 提升社会渠道的满意度。

通过物料管理功能, 实现宣传物料发放和库存管理。通过定制机管理, 实现对定制机使用的全面自动稽核管理。

3.4 营销绩效考核

通过系统, 还可为各级营销部门和人员制定计划任务, 并提取各部门和人员各项考核指标的完成情况, 对员工绩效实现全面量化考核, 为公司推出的各项营销劳动竞赛提供全面支撑。

3.5 客户维系管理

系统将所有在网客户分解到电话局和营销经理, 营销经理对各自名单上的客户进行维系。营销人员可以通过系统查看自己负责客户的收入、欠费、流失、消费异常等情况, 有针对性地进行欠费催缴、客户挽留等工作, 有效避免客户流失。

3.6 动态报表与动态考核

系统设计充分考虑了各项功能的动态管理和可扩展性, 通过动态报表功能, 技术人员可以自定义实现新增报表的开发, 及时有效地支撑前台的统计需求变化。动态绩效考核功能不仅实现了对考核对象的动态设置, 对于考核指标还可实现动态配置, 其中新增自动指标还可由技术人员配置后台自动生成算法, 最大程度地适应考核管理不断变化的需要。

4 移动业务综合支撑系统的应用效果

系统上线后, 有效弥补了Info系统对区县以下统计支撑的不足, 全市156个各级营销部门和1100多名营销经理可以方便地提取各自的收入、发展、欠费等情况, 并对各项营销活动做全面的质量分析;同时还可提取各类营销维系工作所需的目标数据, 有效指导了日常的经营分析和营销工作。通过对各类竞赛活动、绩效考核的支撑, 对部门和员工绩效实现了全面量化考核。在渠道管理方面, 为渠道经理和代理商提供了管理和服务平台, 提高了社会渠道的掌控能力, 实现了对全网渠道的有效监控和管理, 为渠道管理和建设提供了有力支撑。

5 结束语

8.电信运营支撑系统的标准及其进展 篇八

文章对电信运营支撑系统标准的现状进行了介绍,对电信运营支撑系统标准中的关键内容进行了阐述,并对电信运营支撑系统标准中尚存在的问题及下一步研究方向进行了探讨。

关键词:

新一代运营与支撑系统;增强电信运营图;标准

Abstract:

The present developments of OSS standards are introduced, and key issues of the OSS standards are analyzed. Further discussion on problems existed in these standards is presented and future research directions are also suggested.

Key words:

NGOSS; eTOM; Standard

1、 引言

全球电信市场逐步走向开放化,电信用户的数量迅速增加,用户需求不断变化,新业务、新技术也不断推陈出新,这使得电信运营商面临日益激烈和复杂的竞争环境。在新的环境下,电信运营商要努力提高自身竞争力,不断提高网络运营、业务供应、服务质量、企业管理和经营决策的水平。电信运营商的经营模式将从传统的“面向网络”的经营模式逐步转变到“面向客户”的经营管理模式,不断向信息化、市场化和个性化的方向迈进。这种经营管理模式的转变使得对电信运营管理水平的高要求被提到了重要日程上来。

国际电信联盟(ITU)提出的电信管理网(TMN)框架,长久以来一直指导着电信领域的网络管理建设。TMN在其信息体系结构模型中从逻辑分层、功能分布的角度出发定义了一个分层管理结构,这个分层管理结构的4个各有侧重而又互相关联的层次由底至上依次是:网元管理层、网络管理层、业务管理层和商务管理层。TMN模型通过分层实施的管理功能和由下至上的信息综合来实现对电信网的管理。

在新的电信经营管理模式下,按照“面向客户”的经营原则,各层管理功能的规划都应贯彻以客户为中心的主线,把客户化需求、市场化需求切实反映到各个层次的管理功能的实施中去,而这个过程则恰恰是一个基于商务视点的自顶向下的规划设计过程。不同于从技术/实现视点出发的自下而上构建的TMN分层结构,运营支撑系统(OSS)是在新的电信运营环境下提出的一种以TMN的分层结构为指导,结合自顶向下的商务设计原则,融合客户管理、业务运作和网络管理为一体的电信企业运营管理解决方案。

近些年来,国际民间组织电信管理论坛(TMF)一直致力于运营支撑系统(OSS)的相关研究。发展到现阶段,OSS已被在其基础上发展而来的新一代运营支撑系统(NGOSS)所代替。TMF的成员由电信运营商、系统集成商、软件供应商和设备供应商组成,这些不同类型的成员分布在NGOSS供应链的不同位置。

2、 电信管理论坛的运营支撑系统标准

2.1 标准文档形式和发布程序

TMF的技术研究和标准制订工作以工作组为单位来进行开展,例如与NGOSS研究相关的工作组目前有4个:基于增强电信运营图(eTOM)的商务处理框架研究工作组、共享信息数据建模研究工作组、与技术无关的NGOSS体系构架研究工作组、NGOSS产品的一致性测试研究工作组。工作组的研究成果将以文档形式体现,以便TMF成员共享最新成果。TMF所认可的文档形式包括:

指南:定义框架和策略方向的指导性文档。

商务协定:描述具体商务需求的文档。

信息协定:定义特定信息模型的文档。

规范:描述需要遵照执行的要求的文件。

接口实现规范:结合TMF中的一些合作实施项目输出的关于产品或接口实现方面的文档。

技术报告:对一些公共关注问题的阐述、评估、分析或建议性质的文档。

在TMF的工作流程中,以上任何一类文档的批准和释放均需经历以下过程:

工作组草案:工作组内产生的文档草案。

成员草案:在工作组草案稳定一段时间后,由工作组提交可供TMF所有成员访问的成员草案。

成员评议版:在提交成员草案的3~6个月内,工作组提交可供TMF策略管理组审议批准的成员评议版文档。

TMF批准版:获电信管理论坛批准的文档。

成员公开版:未获TMF批准、但可向TMF所有成员公开的文档。

完全公开版:未获TMF批准但可公开的文档。

2.2 运营支撑系统标准概览

TMF提出了对NGOSS体系进行描述的4个视点,而这4个视点又恰恰与实现运营支撑系统的各个阶段相对应。(1)商务视点:对应分解商务流程、定义需求模型的阶段。(2)系统视点:对应设计逻辑系统构架、定义合约接口、建立数据模型阶段。(3)实现视点:对应基于特定技术的实现、验证过程。(4)运行视点:对应系统运行过程。

TMF与NGOSS相关的工作主要集中在以下几方面:

定义商务处理框架和处理流程模型。

在已定义的商务处理框架的基础上定义系统框架。

通过一系列的合作项目开展多供应商环境下系统解决方案的实现和展示。

向TMF成员提供NGOSS的研究成果和资源共享,如文档、模型、程序源码等。

表1是TMF现阶段公开的NGOSS相关标准一览表(已被新标准所替代的文档不再列出,如GB910电信运营图已被GB921增强电信运营图所替代)。表中各标准介绍如下:

(1)GB909

GB909描述技术集成图(TIM),从系统视点对OSS逻辑系统构建的原则、合约定义原则和可采用的技术方向进行阐述。其第1部分描述了基于构件的分布式逻辑系统构架,构件间通过已注册的合约进行交互。构件的设计采用面向对象概念,将实现细节隐藏在内部,只有合约是对外可见的。其第2部分阐述了TMN体系结构的借鉴意义,强调运营支撑系统着重于提供端到端运营流程自动化的解决方案,对在系统实现时可能采用的技术(如Web/JAVA、CORBA、CMIP/SNMP)及其应用场合进行了说明。TIM的研究成果已以适当的形式被NGOSS体系采纳,如基于构件的分布式结构。

(2)GB914

GB914描述系统集成图(SIM),从系统视点给出了基于逻辑商务组件(LBC)的组件信息结构。SIM按功能划分定义了若干个管理域,而每个管理域由若干个逻辑商务组件组成。LBC通过相关的合约与其他组件进行交互,通过LBC的适当组合为运营商提供针对特定商务流程的方案设计。SIM可看作是细化NGOSS组件的一个参考视图。

(3)GB920

GB920给出了NGOSS体系框架的概览。NGOSS提供的是一套面向组件的、基于即插即用方式进行松耦合集成的分布式体系结构。NGOSS体系应定义具备标准合约接口的分布式组件、基于公共合约的组件特性、共享数据信息服务以及与技术无关的通用意义上的基础框架。

(4)GB921

GB921中的增强电信运营图从商务视点描述了支持端到端运营流程自动化的商务处理框架。eTOM从电信运营图(TOM)发展而来,GB921对商务流程进行了分解和细化,并给出了eTOM的分层视图以及相关的流程描述。

(5)GB922

GB922及相关附件定义共享信息/数据(SID)模型。针对SIM中定义的管理域,采用UML类图对各管理域所用到的共享信息进行数据建模,定义了相关的数据对象、对象的属性及属性值类型。

(6)TMF051

TMF051针对NGOSS可能给NGOSS供应链的各方(服务提供商、系统集成商、独立软件供应商、设备供应商)带来的利益、成本和风险进行了分析,并提出了各方投入NGOSS建设应达到的目标以及决策模型。

(7)TMF052

TMF052提出了对NGOSS框架的需求,如互操作性、可扩展性、可移植性、后向兼容性、可靠性、灵活性、数据可达、易管理、易测试等需求,并从服务提供商、系统集成商、独立软件供应商、设备供应商4个主体的不同视角对需求进行了详述。关于对NGOSS功能组件的需求,TMF052建议参考SIM(GB914)中的描述。

(8)TMF053

TMF053描述了基于组件的分布式体系的构建原则,给出了与技术无关的NGOSS体系结构,并对NGOSS体系结构的关键要素(如合约、组件、分布透明性、流程控制、共享信息数据管理)作了细化阐述。其附件B“合约规范”利用UML类图和XML Schema对合约的内容和格式作了形式化的要求。

(9)TMF050

TMF050定义了NGOSS一致性测试的测试内容和测试原则。测试内容涉及对公共通信平台、合约接口和流程控制的要求以及对SIM中定义的管理域的功能覆盖情况,测试范围涵盖TMF052、TMF053及GB914中的相关要求。

(10)TMF055和057

TMF055和057分别对CORBA技术和XML技术以及它们的相关研究与应用现状进行了简单介绍,并对它们在NGOSS体系中的可能应用进行了简要分析。

3、 运营支撑系统标准研究现状

3.1 体系构架

新一代运营支撑系统结合了组件技术和分布式技术,提供基于分布式组件的松耦合体系构架。NGOSS体系构架应满足如下主要特征:

(1)商务处理流程的抽象

商务处理流程的抽象与组件相分离,可达到单个组件与商务处理流程逻辑的无关性,使得组件的集成更灵活,也大大提高了组件的可用性和重用性。

(2)NGOSS组件

NGOSS组件表示一个可配置的软件实体,NGOSS组件可分为两大类:应用组件和系统服务组件。组件间利用定义好的合约接口进行交互。商务处理流程通过顺序调用一系列的应用组件的合约接口来实现,应用组件可通过调用系统服务组件来完成自身的部分功能。

(3)共享信息服务

共享信息服务向各独立的组件提供共享信息,并通过提供统一的标准合约接口供各组件来访问。共享信息服务的接口不仅提供数据读、写、增、删等操作,还提供数据排序、访问控制等服务。

(4)合约发现

合约用于描述组件的调用接口,合约的内容包括接口的语法和语义规定。商务处理流程通过调用组件的合约接口得到实现。所有组件都要通过合约注册服务对与其相关的合约进行注册,以便于其他组件的访问。合约交易服务则支持系统在运行时动态发现组件合约,以支持组件的即插即用。

(5)公共通信平台

NGOSS体系采用分布式通信软总线作为公共通信平台。

基于NGOSS体系构架以上的特征,TMF053给出了与技术无关的体系结构,该结构划分为基础框架服务、策略框架服务和商务服务三大组件域。商务服务通过合约规范提供可分解的商务功能单元以供商务处理流程调用,而框架服务提供商务应用组件间的交互能力,包括商务流程管理、共享数据管理、安全及支持分布透明性的命名服务、注册服务、目录服务、交易服务、调用服务等。

3.2 增强电信运营图

在多变的竞争环境下,能够迅速实现业务配置、客户入网及解决业务质量问题对运营商来说尤为重要。eTOM的提出旨在帮助业务/网络运营商将信息管理、业务管理、网络管理等方面较好地集成在一起,以实现低成本的端到端运营流程自动化,并支持运营商之间的互联互通。eTOM从电信运营图(TOM)发展而来,但它作为一个更宽泛意义上的通用商务处理框架比TOM复杂得多。在eTOM中,运营商需要和一些外部实体及内部实体进行交互,这些实体在eTOM中被分为五大类:客户(运营商的销售对象)、供应商或合作方(运营商的购买或合作对象)、运营商的股东、运营商内部职员、其他相关方(包括政府、媒体、竞争者等)。

eTOM给出了一个水平分层、垂直分块的商务处理框架视图。总体上eTOM包括三大处理域:策略、基础设施与产品域,运营域,企业管理域。运营域是eTOM的核心;策略、基础设施与产品域侧重于策略及生命周期的管理,为运营域提供功能性支持;企业管理域属于通用性交叉领域,不是eTOM的重点。

运营域以及策略、基础设施与产品域可水平划分为4个管理层:市场、产品及客户管理层,业务管理层,资源管理层,供应商/合作方管理层。与TOM相比,eTOM融合了电子商务的概念,提出了与其他供应商/合作方的关系管理以及供应链的发展和管理(供应商/合作方管理层)。

eTOM的运营域被垂直分割为4类端到端的处理流程服务。其中FAB(业务指配、业务保障和计费)3类服务是从TOM继承而来的,而运营支持准备(OSR)服务包括为支持FAB实时实现的系列准备活动。

eTOM新提出的策略、基础设施与产品域被垂直分割为3类端到端的处理流程服务,分别是:策略与调配、基础设施生命周期管理、产品生命周期管理。基于eTOM的商务处理流程框架是独立于被管网络、被管业务和企业组织结构的,GB921中还给出了更低层次的流程分解与分析,运营商可根据自身特定需求套用这个框架来进行自身NGOSS系统的商务处理流程映射。

3.3 合约定义

NGOSS中的合约提供组件间进行交互的规范接口,是实现商务处理流程自动化的基础。NGOSS体系中所使用的合约均应有标准定义,以实现即插即用的分布式组件集成。目前TMF并没有定义具体合约的相关规范,但TMF053B中对合约的内容和格式作了如下要求:

合约应具有名称和版本号以被识别。

合约可被继承和扩展。

合约可包括一个或多个操作。

合约应具备文本的行为描述。

合约可包括一系列参数,每个参数应有名字、类型和用法说明(如输入参数、输出参数、返回参数等)。

合约可规定一系列前置条件、后置条件以及适当条件下的异常。

4、 结束语

TMF现有的规范在NGOSS体系结构、商务处理流程框架、高层需求及共享数据模型方面都给出了较详细的描述和定义,为电信运营商构建新一代运营支撑系统提供了宝贵的方向性指导,具有可贵的借鉴意义。但TMF现有的NGOSS规范间相互关系较为零散,不同规范对某些相同概念或相似概念所采用的术语描述也不一致,还不足以形成一套自成体系的规范来保证NGOSS系统的设计与实现。因此,为保证NGOSS规范的实用性,相关的研究需进一步开展。

NGOSS旨在提供端到端的运营流程自动化支持,GB921对商务处理流程需求进行了细化,GB920中规定了商务处理流程通过顺序调用一系列应用组件的合约接口来实现的规则,这就需要对应用组件进行细化,对应用组件的合约接口进行定义,对特定商务处理流程与相关合约接口的顺序调用关系进行映射。目前TMF仅在GB914中提出了对逻辑商务组件(LBC)的简单功能性描述,而在应用组件的合约接口定义以及商务处理流程的控制和映射方面还 强瞻住A硗猓琓MF053提出了与技术无关的通用意义上的NGOSS体系结构,但还需定义和实现相关的基于特定技术的体系构架。□

基金项目:国家杰出青年科学基金项目(60025104);国家自然科学基金面上项(60202003);国家自然科学基金重大研究计划项目(90204002)

参考文献:

[1] TMF GB909, Technology Integration Map (Part 1):Generic Requirements for Telecommunications Management Building Blocks [S].

[2] TMF GB909, Technology Integration Map (Part 2):Smart TMN & Technology Direction Statement [S].

[3] TMF GB910 Version 2.1, Telecom Operations Map [S].

[4] TMF GB914 Version 1.3, System Integration Map [S].

[5] TMF GB920 Version 1.5, New Generation Operational Support Systems (NGOSS), Architecture Overview [S].

[6] TMF GB921 Version 3.0, The en?鄄

hanced Telecom Operation Map (eTOM) Business Process Framework [S].

[7] TMF GB922, Shared Information/Data (SID) Model [S].

[8] TMF050, NGOSS Compliance Testing Strategy Technical Specification [S].

[9] TMF 051 Version 1.1, New Generation Operations Systems & Software (NGOSS) Technical Specification Business Case [S].

[10]TMF052, NGOSS Requirements

Technical Specification [S].

[11] TMF053, NGOSS Architecture Technology Neutral Specification [S].

[12] TMF055 Version 1.5, NGOSS Phase 1 Technology Application Note — CORBA [S].

[13] TMF057, NGOSS Phase 1 Technology Application Note — XML [S].

收稿日期:2003-03-25

作者简介:

上一篇:初中夏季运动会加油稿下一篇:监事会个人岗位职责经典