宽带运营支撑系统OSS

1、宽带运营支撑系统oss引言2宽带的发展给运营商带来机遇的同时也带来新的挑战2运营支撑系统的建设目标2运营支撑系统的设计原则3系统总体设计方案4系统结构4软件体系5网络拓扑7系统功能8业务支撑系统8客户服务系统10网络管理系统10决策支持系统10接口定义11客户服务接口定义12网络管理接口12增值业务接口13系统界面及业务流程参考15业务功能15流程定义16引言宽带的发展给运营商带来机遇的同时也带来新的挑战随着信息技术的发展，人们对信息的需求已不满足于传统的电报电话业务，甚至传统的文件传输 、电子邮件等数据业务，而是追求更高品质的集视频 、图象、声音、文字、甚至动画等为一体的多媒体应用服务。由于

2、早期的internet带宽窄、路由瓶颈、接入速率低、延迟大而不确定，使得适时性强的音视频流质量不能得到保证的特点 ，限制了ip多媒体的广泛应用。尽管如此，多媒体的应用的发展并没有停止，人们还是在专网上或局域网上开发了诸如视频会议、远程教学等应用。宽带ip技术的发展和成熟，为ip多媒体的应用发展吹响了前进的号角 ，种类繁多的多媒体视频应用如决堤之水 ，为internet世界带来无限的勃勃生机和充满挑战的发展机遇，我们不得不相信，未来是宽带多媒体的信息世界。对运营商而言，确定用户类型可以推出相适应的服务。但在目前阶段，各地用户发展参差不齐，有的地区用户量非常少。而且在一定时期内，用户量的发展速度也

3、不会太快。因此，在构造运营支撑系统时，要根据各地的具体情况实施，对于用户量比较多的地区和用户量较少的地区区别对待。在用户量大的地方构造完整的运营支撑平台，用户少的地区可以组合成立一个运营支撑中心，对各地区进行综合管理。然后根据用户量的发展逐步过渡到独立的拥有自己运营支撑平台的地区实体。技术发展同时，带来网络应用服务的业务品种日趋繁多，经营方式变化多样，竞争日益激烈。在此情况下，选择先进、完善的运营支撑系统成了提高竞争力的重要一环。由于宽带网络自身的特点，产生了一种新的运营模式isp/asp分帐模式，它开辟了网络运营管理的新天地，也极大地推动了互联网的发展。运营支撑系统的建设目标根据用户类型的分

4、析，业务支撑平台需要很好向企业单位用户及小区家庭用户及流动用户提供适合的认证、计费模式，并为今后建立在业务支撑平台上的其他应用系统，如客户服务、网络管理、宽带增值业务等提供基础数据。因此对于业务支撑平台而言，它有两个明确的目标，一是建立适合当前用户的运营管理系统，吸引用户向宽带应用领域转移。二是提供良好地信息交换平台，向二次应用和上层应用提供符合要求的数据接口。运营支撑系统的设计原则运营支撑系统的设计从软件和硬件方面必须把握一定的原则，以便于实施几个阶段的工程。主要考虑的方面包括技术的先进性、实施的经济性、运行的稳定性、扩展的方便性等若干方面。明显地，上述几点在某个阶段上具有一定的矛盾性，最困

5、难地是在于如何在适当地时候选择适当的方式。技术的先进性又可以包括几个方面，如支持的接入方式、支持的增值业务方式、系统的安全性、跨平台性等。一个拥有技术先进性的系统必定能够支持多种接入方式；支持多样的增值业务及其计费方式；系统的分层隔离可以加强安全性，数据的备份和恢复机制也是保障系统数据安全的重要方式；为了保证系统能够适应多种运营平台，系统软件的跨平台特性也很重要。本方案不但提供了面向对象的组件开发技术，还提供了系统的松耦合模式，利用xml消息平台向上或向外提供开放的接口和数据。实施的经济性则包括工程的建设费用和实施费用的经济性，在本方案中，将系统实施分成两个阶段，第一阶段主要保证以较少的投资建

6、立运营平台，因此主要考虑地是基于pc服务器的运营环境；第二阶段将是保证大量用户的稳定运营的阶段，主要考虑基于小型或大型服务器。考虑到运营环境的平稳变迁，对第一阶段的硬、软件选择有一定的要求限制。运行的稳定性是要保证所有系统在运行过程中的稳定性，即设备能够抵抗一定程度的干扰和毁损。例如关键设备的双机热切换模式。扩展的方便性是指在现有的运营模式上可以容易地增加新的功能和设备，而不需要做太多的技术调整。由于本方案中提出的若干xml消息平台的特性，所以扩展功能能够非常方便利用xml消息平台构造二次应用和开发。而xml的开放性，可以方便地实现若干因特网的应用和数据共享。另外，基于现有的用户类型，运营支撑

7、平台不仅应当提供诸如基于流量、时长的计费方式，还应当就使用费用的即时控制作出规划。系统总体设计方案系统结构本方案的系统结构可以定义成区域集中、全局分布模型。所谓区域集中是指以城市为区域中心构造集中式的运营支撑平台。所谓全局分布是指以分布形式将各区域中心整合成一个统一的应用平台，向全网用户提供统一的支持和服务，而任何一个区域中心都可以构造成全网的中心节点。请看下图：上图所示，是以北京实体局作为全网中心的分布式构造方案。其中所谓的实体局是指拥有oss（业务支撑系统）的节点，可以是大区中心城市，也可以是业务量达到一定规模的城市。全国网中心的主要功能是结算、漫游、管理和决策。对于每个实体局而言，它不仅

8、负担着该实体所在城市的用户接入和服务，还具有接入其它城市和地区用户接入和服务的能力。在下图中，我们将看到实体局的系统结构图示。从中可以清楚地看到系统支持的若干接入方式。图2-2 实体局的体系结构与实体局对应，虚拟局是指没有oss的节点，各虚拟局可以就近接入到相邻地实体局，从而通过实体局完成接入服务和计费等功能。也可以连接到北京实体局，直接与全网指定的中心节点连接，由中心节点来负责对用户进行认证、授权。其中虚拟局和实体局的定义不是一尘不变的，当虚拟局所代表的区域或城市用户量达到一定规模后，应当实施虚拟局的剥离操作，即将虚拟局从实体局中剥离出去，形成独立地分布节点，成为新的实体局，拥有与前述实体局

9、相同的功能和模式。在系统实施中，将介绍如何剥离虚拟局的过程。软件体系现有应用程序中采用二层模型结构的仍然有很多，多数称为c/s（客户/服务器）结构或b/s（浏览器/服务器）结构。二层应用程序构造的实用性起了很大的作用。二层模型不是“坏事物”，而且在多数情况下更容易实现，但三层模型在有些情况下可能是更好的选择。本方案中采取三层模型。三层体系结构常被称做server-centric，因为商业应用逻辑是运行在中间层的服务器上，与用户界面和数据的访问相对独立。尽管没有要求这三部分必须运行在不同的机器上，一般情况下，表示层在客户端的应用如浏览器中运行，数据访问也在专用的数据库服务器上运行。这种分层方式带

10、来了诸多的优点： 商业应用逻辑集中放置在服务器上由所有的用户共享，使得系统的维护和更新变得简单，当事务逻辑发生变化时，只需更新服务器上相应的商业应用逻辑组件，之后所有的客户就可以使用新的事务处理逻辑。避免了客户端应用程序版本控制和更新的困难。 在商业应用逻辑层，开发人员可以利用常用的开发工具开发可重用的二进制组件，而不是编写存储过程。而且这些组件可以镜像到多台机器上同时运行，从而分担多用户的负载。 应用程序组件可以共享与数据库的连接，数据库服务器不再是为每个活动的用户保持一个连接，从而降低了数据库服务器的负担，提高了性能。 安全管理可以基于组件来授权而不是授权给用户，客户不再直接访问数据库，提

11、高了安全性。图2-6 三层体系结构在这样的三层体系结构下，软件的可靠性和可扩展性将达到很高的程度。另外这种体系结构也给将来自不同供应商的产品集成为一个能够满足特定需要的统一的整体。网络拓扑图2-4是一个简化了的网络拓扑图，它提供了一个实体局在较少的配置情况下，所建立的业务支撑平台的网络拓扑结构。其中忽略了客户接入的网络拓扑，着重于构建集中式的支撑平台实体。在这一网络拓扑中融入了基本的计费、营业、网管和客服等诸多因素，形成了一个相对全面的运营环境。不仅可以提供客户的接入服务，营业受理，还提供了对部门工作调派进行控制的模式结构。此外，对于网管的介入也作了描述。相对而言，对于客服系统的介入只是稍作意

12、会，大意是客服系统接入到业务支撑平台中，与业务支撑平台共享部分数据。需要强调的是，这一网络拓扑结构描述了基本的业务支撑平台的设备情况和网络连接示意，实际的应用中，还需要就各实体局具体的网络结构和设备情况进行相应的调整和改造。在图中，关于防火墙的设备分为二层设置，其目的是增强支撑平台网络内部的安全性和对外的隔离性。将web服务器和接入服务器置于第一层防火墙之后，而将其他的数据服务器和应用服务器置于第二层防火墙之后。第一层web服务器是面向广大用户的，其可靠性和安全性相对较低，而在第二层防火墙之后还另设有一个web服务器，专门用于内网的管理人员访问之用。换句话说，本方案建议运行商将不同的应用和管理

13、仔细斟别后分开处理，以利于提高系统的安全性。同时也说明，由于本方案中系统采用了面向对象的组件构造方式，适用于多web服务器和多应用服务器的网络结构。系统功能运营系统的系统功能可以分为四大子系统，即业务支撑系统、网络管理系统、客户服务系统和决策分析系统。为了保证运营的有效性和功能的多样性，吸引更多的客户，当然还应考虑办公自动化和增值服务。不过在本方案中，主要就前述的四大子系统进行介绍。而其中的业务支撑系统又是需要着重进行介绍，本方案将从计费和营帐两大模块对其进行介绍。业务支撑系统业务支撑系统是网络运营的支撑平台，它提供初始的客户数据和帐户数据，向客户服务系统、网络管理系统等提供最原始的配置信息，

14、并由计费子系统负责收集运营期间产生的各类数据，经加工处理后提供给营业系统和帐务系统等进行费用计算，是整个运营管理的数据源地。1 认证系统认证系统是系统对接入用户进行认证的模块，它负责对用户进行认证和授权，是运营商实现对各类接入用户进行时长、流量计费的基础。在本方案中，认证系统是一个独立的组件模块，不仅本身支持多种认证机制，还可以很方便地增加新的认证机制。现有支持的认证机制包括：l 基于nas/bras的认证，即拨号用户/pppoe认证；l 基于支持802.1x协议的设备的认证；l 基于防火墙或aaa路由器的设备的认证，该方式比较适合lan接入方式的小区用户；l 基于固定ip地址的认证，这种方式

15、适合专线用户。2 计费系统计费系统的主要工作是将用户的实时网络应用信息采集下来，并进行一定的转换处理，提供给营业系统作为费用统计之用。为了更好地满足运营商业务上的需要，本方案中实现了dbps（dynamic billing process system）动态算费。可以根据业务种类的不同，实行实时或非实时计费。3 营业系统（business running system）营业系统是用户进行业务受理的应用系统，主要功能包括业务受理、工单管理、卡管理、资费管理等。处理的对象主要有两类：客户和帐户。其中客户是帐户的拥有者，具有法律义务承担的责任人。帐户是网络使用者入网的标识，确定了使用者的入网方式、使

16、用带宽、计费方式等信息。营业系统的主要作用就是合理地管理这两类对象资源，使得帐户的拥有者在缴纳费用的前提下，使用运商向其提供的网络应用和服务。4 帐务系统（accounting system）帐务系统主要包括费用计算、对帐、帐务统计、银行结算、发票管理等模块。除了某些卡用户是采用实时算费处理外，大多数用户都是每月一结帐。因此帐务系统也是采取月费计算模式，即每个月计费一次网络通信费用和其他相关费用，生成帐单。同样的，月费的计算日期各系统都有不同，在本系统中专门有计算日的设置，用于设定计算月费、出帐的日期。有关于计算日的设置是在系统管理模块中实现的。5 系统管理（system maintenanc

17、e）系统管理主要是对系统代码维护的模块，还包括员工管理、部门管理、代理点管理等模块。此外，作为系统的特色之一，还引入流程配置管理（workflow configuration management）的概念。其定义是利用应用服务组件定义业务流程、确定用户参与方式。由于系统采用面向对象的组件，模块化很好，可以灵活增加和修正业务流程。使业务流程和服务组件独立开来，不影响业务流程的定制。另外，管理者与客户同时参与业务的监控和评估，有利于客户服务。客户服务系统客户服务系统除了提供面向用户的自服务功能，最主要是提供面对客户的人工辅助服务，其主要内容包含有投诉、故障申告，业务咨询、查询，辅助业务受理等。网络

18、管理系统网络管理系统是面向业务的网络管理，其目的是向运营系统提供更好的网络服务和客户服务。它包括拓扑管理、配置管理、故障管理和性能管理四个方面。决策支持系统狭义的决策支持系统（dss）需要建立四库系统（数据库系统、模型库系统、知识库系统和方法库系统），此外还需要有自然语言处理能力的人机界面、问题处理系统等若干要素。事实上，决策支持是一个先导的概念。所谓先导，是指这一概念的出现比实际系统的出现要早。换句话说，真正意义上的决策支持系统的出现还需要一定的时间。现有的决策支持系统更严格的说只是广义的决策支持系统，是建立在数据仓库的基础上的olap（联机事务分析）系统。本方案中将报表、查询，乃至统计、分

19、析作为决策支持系统的组成部分也是基于这样的考虑。目的是向决策人员提供界面友好，容易操作的图象、图形、数字报表和统计数据，以便用于决策。当然，在这些报表、统计中包括了一些基本的营业厅报表、工单报表、故障处理报表、帐务报表、财务报表等传统的报表外，还增加了对用户使用情况的分析报表，如用户网络应用情况分析表，用于显示和分析用户进行网络应用的时间分布情况，从而为不同时间段设置不同的使用费用并提高网络负载均衡提供理论依据。又如用户缴费分析报表可以显示不同类型的用户选择的支付方式，缴费额度等，为运行商提供针对不同用户的套餐服务提供理论依据。再如故障处理分析表不仅可以向决策人员提供主要故障类型，以便根据需要

20、改造或更换相应的网络设备，而且还可以向客户服务系统提供面向故障类型的故障处理知识库。还有，如果希望知道哪些用户对哪些增值服务感兴趣，则可以通过分析用户职业情况及用户使用增值服务的元数据获取，从而了解和掌握用户对相关增值服务的使用取向，进而制定有针对性的广告宣传策略和提供有针对性的增值服务（或称之为个性化增值服务）。所有这些决策支持内容都是广义的决策支持系统的范畴，也是在现有系统设备和配置上可以实现的。接口定义在实际集成不同供应商的产品时，必须确定相应的接口标准。其中最著名的标准是corba，因为不同的供应商执行不同的corba，它已经逐渐消蚀为一种可能的标准。由于运行商不仅可能需要将不同供应商

21、的产品集成在一起，还需要将运行和后台办公系统集成，因此需求是紧迫的。基于这样的原因，corba实施的基础动摇了。另一个标准是构建于enterprise java beans（ejb）的，但也面临许多与corba相同的挑战。企业应用程序集成（eai）有望实现互操作，比如一个应用程序可以使用corba，另一个则使用ejb，他们能够通过中间件进行沟通。在这种情况下，本方案中特别提出了松耦合的接口模式（参见图2-7），这种模式从长远看是唯一的方法，因为这是internet模式。图2-7 松耦合的接口模式从图2-7中可以看到松耦合的模式下，各子系统间通过xml消息总线连接起来，成为一个有机的整体。由于每

22、一个子系统都不与其他子系统间紧耦合，因此都可以单独编制和维护。客户服务接口定义业务支撑系统与客户服务之间的接口内容大致可以分为客服申请、业务数据准备、设备或人员方案解决反馈等若干部分，其接口示意图如下图所示：图2-9 客户服务接口定义从图2-9中可以看出，支撑平台与客户服务系统之间的数据传递大致分为两类，一类为用户身份确定数据；一类是用户请求与响应数据流。事实上，对客户身份的认证可以利用业务平台中客户数据或相关的帐户数据来完成。不过，在本方案中，这些数据只需要从xml消息平台上直接提取即可。网络管理接口网络管理接口与业务支撑平台的接口从本质上讲与客户服务系统是一样的。这里要强调的是网络管理系统

23、、客户服务系统和业务支撑平台之间三者之间的数据共享和交互性。也就是说，事实上，完全独立地考虑网络管理与业务支撑平台的接口，并不能很好地体现出系统加强网络管理以提高网络稳定性、增加网络性能的最终目的是为了向客户提供更好的服务网络接入服务。如果再考虑到增值服务的因素，还必须考虑到网络管理除了向客户提供更好的网络接入服务，还要提供更好的、更个性化的网络增值服务。图中数字表示消息传递的顺序，但实际上，由于xml消息平台的特性，消息传递并没有顺序的限制，但如果应用需要的话，可以采用xml方式定义一种对应特定业务的信息流程，并规定信息提取对象按照这一流程提取相关信息。其中数字1表示客户认证请求；数字2表示

24、客户认证及相关客户信息；数字3表示客户的故障投诉请求，注意这里的请求是被业务支撑平台接收，而非直接由网络管理系统接收，最主要的原因是向网络管理系统传递的信息中包含的客户信息应当首先通过业务支撑平台配置表转换成设备信息；数字4表示设备信息；数字5表示网络将故障设备信息或经过网络设备状态调整后返回的设备状态信息；数字6表示业务支撑平台通过将设备信息转换成与客户相应的业务信息返回给客户服务系统；数字7则表示客户将反馈信息由客户服务系统传送到xml消息平台，由于没有标识出信息的接收方，即说明7返回的信息可以由其他xml消息平台定义的系统来负责接收。增值业务接口增值业务系统与业务支撑平台的接口与前述的接

25、口会有所不同。最大的不同在于客户服务系统和网络管理系统都是专用系统，其服务对象和应用对象与业务支撑平台是相同的。而增值业务系统的服务对象既可能是业务支撑平台服务对象的子集，甚至可能是其超集（如增值服务提供商同时为若干isp提供增值服务），还可能只是两者间的服务对象有交集而已。基于这样的情况，增值业务系统可能需要进行二次认证。xml消息平台接口优势综合上述接口定义的内容，我们可以知道，xml消息平台提供了一个全新的数据交换平台，不仅可以使应用与应用之间的结合度显著降低（松耦合模式），而且还规范了应用与应用之间的接口定义，增强了应用间的无关性，从而为应用提供了最灵活的组织结构。所以，可以将本方案中所采取的软件总线机制的优势归纳如下：l 应用无需了解其它应用，只需将数据发送到网络上。l