宽带运营支撑系统OSS.docx

宽带运营支撑系统OSS.docx

《宽带运营支撑系统OSS.docx》由会员分享，可在线阅读，更多相关《宽带运营支撑系统OSS.docx（15页珍藏版）》请在冰豆网上搜索。

宽带运营支撑系统OSS

宽带运营支撑系统OSS

引言

宽带的发展给运营商带来机遇的同时也带来新的挑战

随着信息技术的发展，人们对信息的需求已不满足于传统的电报电话业务，甚至传统的文件传输、电子邮件等数据业务，而是追求更高品质的集视频、图象、声音、文字、甚至动画等为一体的多媒体应用服务。

由于早期的INTERNET带宽窄、路由瓶颈、接入速率低、延迟大而不确定，使得适时性强的音视频流质量不能得到保证的特点，限制了IP多媒体的广泛应用。

尽管如此，多媒体的应用的发展并没有停止，人们还是在专网上或局域网上开发了诸如视频会议、远程教学等应用。

宽带IP技术的发展和成熟，为IP多媒体的应用发展吹响了前进的号角，种类繁多的多媒体视频应用如决堤之水，为INTERNET世界带来无限的勃勃生机和充满挑战的发展机遇，我们不得不相信，未来是宽带多媒体的信息世界。

对运营商而言，确定用户类型可以推出相适应的服务。

但在目前阶段，各地用户发展参差不齐，有的地区用户量非常少。

而且在一定时期内，用户量的发展速度也不会太快。

因此，在构造运营支撑系统时，要根据各地的具体情况实施，对于用户量比较多的地区和用户量较少的地区区别对待。

在用户量大的地方构造完整的运营支撑平台，用户少的地区可以组合成立一个运营支撑中心，对各地区进行综合管理。

然后根据用户量的发展逐步过渡到独立的拥有自己运营支撑平台的地区实体。

技术发展同时，带来网络应用服务的业务品种日趋繁多，经营方式变化多样，竞争日益激烈。

在此情况下，选择先进、完善的运营支撑系统成了提高竞争力的重要一环。

由于宽带网络自身的特点，产生了一种新的运营模式—ISP/ASP分帐模式，它开辟了网络运营管理的新天地，也极大地推动了互联网的发展。

运营支撑系统的建设目标

根据用户类型的分析，业务支撑平台需要很好向企业单位用户及小区家庭用户及流动用户提供适合的认证、计费模式，并为今后建立在业务支撑平台上的其他应用系统，如客户服务、网络管理、宽带增值业务等提供基础数据。

因此对于业务支撑平台而言，它有两个明确的目标，一是建立适合当前用户的运营管理系统，吸引用户向宽带应用领域转移。

二是提供良好地信息交换平台，向二次应用和上层应用提供符合要求的数据接口。

运营支撑系统的设计原则

运营支撑系统的设计从软件和硬件方面必须把握一定的原则，以便于实施几个阶段的工程。

主要考虑的方面包括技术的先进性、实施的经济性、运行的稳定性、扩展的方便性等若干方面。

明显地，上述几点在某个阶段上具有一定的矛盾性，最困难地是在于如何在适当地时候选择适当的方式。

技术的先进性又可以包括几个方面，如支持的接入方式、支持的增值业务方式、系统的安全性、跨平台性等。

一个拥有技术先进性的系统必定能够支持多种接入方式；支持多样的增值业务及其计费方式；系统的分层隔离可以加强安全性，数据的备份和恢复机制也是保障系统数据安全的重要方式；为了保证系统能够适应多种运营平台，系统软件的跨平台特性也很重要。

本方案不但提供了面向对象的组件开发技术，还提供了系统的松耦合模式，利用XML消息平台向上或向外提供开放的接口和数据。

实施的经济性则包括工程的建设费用和实施费用的经济性，在本方案中，将系统实施分成两个阶段，第一阶段主要保证以较少的投资建立运营平台，因此主要考虑地是基于PC服务器的运营环境；第二阶段将是保证大量用户的稳定运营的阶段，主要考虑基于小型或大型服务器。

考虑到运营环境的平稳变迁，对第一阶段的硬、软件选择有一定的要求限制。

运行的稳定性是要保证所有系统在运行过程中的稳定性，即设备能够抵抗一定程度的干扰和毁损。

例如关键设备的双机热切换模式。

扩展的方便性是指在现有的运营模式上可以容易地增加新的功能和设备，而不需要做太多的技术调整。

由于本方案中提出的若干XML消息平台的特性，所以扩展功能能够非常方便利用XML消息平台构造二次应用和开发。

而XML的开放性，可以方便地实现若干因特网的应用和数据共享。

另外，基于现有的用户类型，运营支撑平台不仅应当提供诸如基于流量、时长的计费方式，还应当就使用费用的即时控制作出规划。

系统总体设计方案

系统结构

本方案的系统结构可以定义成区域集中、全局分布模型。

所谓区域集中是指以城市为区域中心构造集中式的运营支撑平台。

所谓全局分布是指以分布形式将各区域中心整合成一个统一的应用平台，向全网用户提供统一的支持和服务，而任何一个区域中心都可以构造成全网的中心节点。

请看下图：

上图所示，是以北京实体局作为全网中心的分布式构造方案。

其中所谓的实体局是指拥有OSS（业务支撑系统）的节点，可以是大区中心城市，也可以是业务量达到一定规模的城市。

全国网中心的主要功能是结算、漫游、管理和决策。

对于每个实体局而言，它不仅负担着该实体所在城市的用户接入和服务，还具有接入其它城市和地区用户接入和服务的能力。

在下图中，我们将看到实体局的系统结构图示。

从中可以清楚地看到系统支持的若干接入方式。

图2-2实体局的体系结构

与实体局对应，虚拟局是指没有OSS的节点，各虚拟局可以就近接入到相邻地实体局，从而通过实体局完成接入服务和计费等功能。

也可以连接到北京实体局，直接与全网指定的中心节点连接，由中心节点来负责对用户进行认证、授权。

其中虚拟局和实体局的定义不是一尘不变的，当虚拟局所代表的区域或城市用户量达到一定规模后，应当实施虚拟局的剥离操作，即将虚拟局从实体局中剥离出去，形成独立地分布节点，成为新的实体局，拥有与前述实体局相同的功能和模式。

在系统实施中，将介绍如何剥离虚拟局的过程。

软件体系

现有应用程序中采用二层模型结构的仍然有很多，多数称为C/S（客户/服务器）结构或B/S（浏览器/服务器）结构。

二层应用程序构造的实用性起了很大的作用。

二层模型不是“坏事物”，而且在多数情况下更容易实现，但三层模型在有些情况下可能是更好的选择。

本方案中采取三层模型。

三层体系结构常被称做Server-Centric，因为商业应用逻辑是运行在中间层的服务器上，与用户界面和数据的访问相对独立。

尽管没有要求这三部分必须运行在不同的机器上，一般情况下，表示层在客户端的应用如浏览器中运行，数据访问也在专用的数据库服务器上运行。

这种分层方式带来了诸多的优点：

1商业应用逻辑集中放置在服务器上由所有的用户共享，使得系统的维护和更新变得简单，当事务逻辑发生变化时，只需更新服务器上相应的商业应用逻辑组件，之后所有的客户就可以使用新的事务处理逻辑。

避免了客户端应用程序版本控制和更新的困难。

2在商业应用逻辑层，开发人员可以利用常用的开发工具开发可重用的二进制组件，而不是编写存储过程。

而且这些组件可以镜像到多台机器上同时运行，从而分担多用户的负载。

3应用程序组件可以共享与数据库的连接，数据库服务器不再是为每个活动的用户保持一个连接，从而降低了数据库服务器的负担，提高了性能。

4安全管理可以基于组件来授权而不是授权给用户，客户不再直接访问数据库，提高了安全性。

图2-6三层体系结构

在这样的三层体系结构下，软件的可靠性和可扩展性将达到很高的程度。

另外这种体系结构也给将来自不同供应商的产品集成为一个能够满足特定需要的统一的整体。

网络拓扑

图2-4是一个简化了的网络拓扑图，它提供了一个实体局在较少的配置情况下，所建立的业务支撑平台的网络拓扑结构。

其中忽略了客户接入的网络拓扑，着重于构建集中式的支撑平台实体。

在这一网络拓扑中融入了基本的计费、营业、网管和客服等诸多因素，形成了一个相对全面的运营环境。

不仅可以提供客户的接入服务，营业受理，还提供了对部门工作调派进行控制的模式结构。

此外，对于网管的介入也作了描述。

相对而言，对于客服系统的介入只是稍作意会，大意是客服系统接入到业务支撑平台中，与业务支撑平台共享部分数据。

需要强调的是，这一网络拓扑结构描述了基本的业务支撑平台的设备情况和网络连接示意，实际的应用中，还需要就各实体局具体的网络结构和设备情况进行相应的调整和改造。

在图中，关于防火墙的设备分为二层设置，其目的是增强支撑平台网络内部的安全性和对外的隔离性。

将WEB服务器和接入服务器置于第一层防火墙之后，而将其他的数据服务器和应用服务器置于第二层防火墙之后。

第一层WEB服务器是面向广大用户的，其可靠性和安全性相对较低，而在第二层防火墙之后还另设有一个WEB服务器，专门用于内网的管理人员访问之用。

换句话说，本方案建议运行商将不同的应用和管理仔细斟别后分开处理，以利于提高系统的安全性。

同时也说明，由于本方案中系统采用了面向对象的组件构造方式，适用于多WEB服务器和多应用服务器的网络结构。

系统功能

运营系统的系统功能可以分为四大子系统，即业务支撑系统、网络管理系统、客户服务系统和决策分析系统。

为了保证运营的有效性和功能的多样性，吸引更多的客户，当然还应考虑办公自动化和增值服务。

不过在本方案中，主要就前述的四大子系统进行介绍。

而其中的业务支撑系统又是需要着重进行介绍，本方案将从计费和营帐两大模块对其进行介绍。

业务支撑系统

业务支撑系统是网络运营的支撑平台，它提供初始的客户数据和帐户数据，向客户服务系统、网络管理系统等提供最原始的配置信息，并由计费子系统负责收集运营期间产生的各类数据，经加工处理后提供给营业系统和帐务系统等进行费用计算，是整个运营管理的数据源地。

1．认证系统

认证系统是系统对接入用户进行认证的模块，它负责对用户进行认证和授权，是运营商实现对各类接入用户进行时长、流量计费的基础。

在本方案中，认证系统是一个独立的组件模块，不仅本身支持多种认证机制，还可以很方便地增加新的认证机制。

现有支持的认证机制包括：

●基于NAS/BRAS的认证，即拨号用户/PPPOE认证；

●基于支持802.1x协议的设备的认证；

●基于防火墙或AAA路由器的设备的认证，该方式比较适合LAN接入方式的小区用户；

●基于固定IP地址的认证，这种方式适合专线用户。

2．计费系统

计费系统的主要工作是将用户的实时网络应用信息采集下来，并进行一定的转换处理，提供给营业系统作为费用统计之用。

为了更好地满足运营商业务上的需要，本方案中实现了DBPS（DynamicBillingProcessSystem）动态算费。

可以根据业务种类的不同，实行实时或非实时计费。

3．营业系统（BusinessRunningSystem）

营业系统是用户进行业务受理的应用系统，主要功能包括业务受理、工单管理、卡管理、资费管理等。

处理的对象主要有两类：

客户和帐户。

其中客户是帐户的拥有者，具有法律义务承担的责任人。

帐户是网络使用者入网的标识，确定了使用者的入网方式、使用带宽、计费方式等信息。

营业系统的主要作用就是合理地管理这两类对象资源，使得帐户的拥有者在缴纳费用的前提下，使用运商向其提供的网络应用和服务。

4．帐务系统（AccountingSystem）

帐务系统主要包括费用计算、对帐、帐务统计、银行结算、发票管理等模块。

除了某些卡用户是采用实时算费处理外，大多数用户都是每月一结帐。

因此帐务系统也是采取月费计算模式，即每个月计费一次网络通信费用和其他相关费用，生成帐单。

同样的，月费的计算日期各系统都有不同，在本系统中专门有计算日的设置，用于设定计算月费、出帐的日期。

有关于计算日的设置是在系统管理模块中实现的。

5．系统管理（SystemMaintenance）

系统管理主要是对系统代码维护的模块，还包括员工管理、部门管理、代理点管理等模块。

此外，作为系统的特色之一，还引入流程配置管理（WorkflowConfigurationManagement）的概念。

其定义是利用应用服务组件定义业务流程、确定用户参与方式。

由于系统采用面向对象的组件，模块化很好，可以灵活增加和修正业务流程。

使业务流程和服务组件独立开来，不影响业务流程的定制。

另外，管理者与客户同时参与业务的监控和评估，有利于客户服务。

客户