融合网络需要开放式解决方案保证_融合通信_电信

融合网络需要开放式解决方案保证

Mark Sylor 2010/09/14

　　语音、视频、数据和无线服务的融合已经开始，并且正在不断发展。通过在单个网络上提供这些基于 IP 的下一代服务，而不是通过分开的专用网络提供，改进了整个世界的通信、互动、业务联系与娱乐方式。对于服务提供商而言，共享/融合网络比传统的专用解决方案更为高效。但其劣势在于，为每项服务的每位客户都确保同样高的体验质量 (QoE) 更为复杂，并且需要更多的关注和专业知识。在服务提供商的整个运营支持系统/业务支持系统 (OSS/BSS) 中，融合网络的每个位置都需要一致的端到端服务质量 (QoS)；而通过服务保证系统便可满足这一需求。

　　此外，服务保证系统还能测量用户感受到的 QoE 和网络提供的 QoE。它可将对整个网络的测量结果进行整合，并关联到系统维护的数据库中。另外，还能对原始测量结果进行分析，得出贵机构从操作员到管理人员再到客户等所有人员需要的有用信息。此外，它还能直观展示数据，以便用户轻易理解信息并对其进行处理。服务保证所提供的价值在于它为决策者所提供的信息。

开放式解决方案为何如此重要

　　服务提供商会出于多种考虑采用 IP 多媒体子系统 (IMS) 等 NGN 架构。一般而言，相比于传统的封闭式专用系统，开放式 NGN 组件的购买和运行相关费用更为低廉，因此能够节省成本。开放式 NGN 将众多服务整合到一个灵活的融合网络基础架构上，使该网络的使用更加高效和便捷。而最重要的是，一旦开放式 NGN 部署就位，新型服务就能以更快的速度开发并从相同或不同来源提供给客户。借助开放式 NGN，服务提供商就无需在每次需要销售新型服务时都构建新的网络或提供新的线路。这些新型服务为服务提供商实现全新收入流带来了契机。这些优势来源于 Internet 标准所固有的开放式传统，而这些技术正是基于该传统开发出来的。尽管如此，只有在支持这些网络和服务的 OSS/BSS 的开放程度相等时，才能实现开放式 NGN 的优势。

　　与需要为每项服务都提供单独网络的传统系统相比，基于 IP 的开放式 NGN 在购买、构建和运营上都更高效。利用开放式标准和接口设计网络组件可提高组件使用率，避免自定义产品的开支，从而大幅降低成本。由于开放式系统得到了普遍采用，所以有更多的人员知道如何管理开放式系统，从而扩展了提供商可以吸纳的人才库。这一概念将面向孤立服务构建的孤立网络转化为融合网络，并将其作为共享服务和内容交付平台。

　　图1所示的第三代合作伙伴计划 (3GPP) 架构就是服务提供商正在构建的基于 IP 的开放式 NGN 服务的示例。这些网络正在将多种服务和应用融合到一个开放式 NGN，包括固定和移动语音、电子邮件、实时通讯、Web 以及视频。

3GPP/IMS 基础架构

图1. 3GPP/IMS 基础架构
　　当服务提供商将网络服务整合到开放式 NGN 时，就突破了内部组织的障碍。传统网络包括多个专用系统：OSS 调配、故障和性能管理系统，以及测试和测量系统。这些专用系统通常都会导致专用的支持组织（孤井）。

　　开放式 NGN 突破了这些孤井的界限，使 OSS 能够用于多种用途，继而支持多个组织。通过单个集成系统就能支持从网络操作员到管理人员和客户等多种类型的用户。通过针对客户购买的所有服务都提供统一接口的统一客户支持、计费和调配系统，提供商将为客户带来更为一致的体验。而在提供商的内部，由于组织之间的矛盾减少了，问题也能够更容易地得到解决。

　　与传统网络相比，开放式 NGN 包含更多来自不同网络设备制造商的设备。因此，要对这一环境中的性能和故障进行测试和测量，就需要多台设备（通常由不同厂商供应）之间的协作和协调。为此，针对运行测试、报告测量结果以及发出故障通知的标准就显得至关重要。为了进行测量，服务保证系统就必须与网络中已经部署的设备进行互操作，如图 2 所示。此外，还必须考虑到传统的测试和测量系统可能仍在使用；它们提供的数据对于为 NGN 服务提供商提供所需信息将非常必要。没有一家厂商能够监控所有这一切。

面向基于IP的NGN的服务保证

图2. 面向基于IP的NGN的服务保证
　　开放式 NGN 的关键优势在于，能够基于该平台提供的服务数量和种类十分灵活。借助该平台，新型服务能够更快地开发、部署和交付。再也不必为每款服务都开发全新的网络。现有的设备、OSS/BSS 以及现有的政策和流程都可以进行调整以供再次使用，从而缩短了新型服务的上市时间。YouTube.com 网站就是一个很好的例子，这项新型服务在没有创建全新系统的情况下，利用现有 Internet 基础架构成功推出。

　　为了实现开放式 NGN 的优势，支持这些网络的 OSS/BSS 必须与其支持的网络具有同等程度的开放性和灵活性，并且价格更低、经过整合。一家厂商无法提供一整套 NGN OSS/BSS，但一家厂商却可以提供 NGN 的全部组件。要装配一套完整的 NGN OSS/BSS，服务提供商必须从一个一个的组件开始构建。连接器可以传输数据，并通过 OSS 提供的开放 API 采取相应行动，从而将这些组件系统集成为一项解决方案。这些 API 的形式多种多样；可以是 XML 之类数据交换格式的编程 API，可以是 RTCP-XR 之类的网络协议，也可以是命令行调用的数据导入/提取实用程序。API 的格式并不重要，重要的是它的存在。

　　集成需要时间。如果构建一项新型应用（如在线音乐和机顶盒视频）的时间、成本和工作量过高，那么 OSS 集成问题便会阻碍服务提供商实现开放式 NGN 的优势。通过开放式 API 和标准将多个 OSS/BSS 相连，以实施服务提供商的整体程序和流程必定非常简单。毕竟，这些流程可将客户满意度较高的 tier-1 服务与客户投诉严重的提供商区分开来。服务提供商需要的是灵活便捷；它可以通过易于集成的开放接口实现。

　　服务提供商所实施的流程最长的服务，往往都是能够确保服务正常运行并且 QoS 体验能够接受的服务。这一流程从服务首次售出一直运行到服务终止使用为止。如果该服务成功，那么与设计、规划和实施新型服务相比，它能够运行更长的时间并且消耗的资源更少。

　　利用 NGN 解决方案，组织内部的管理人员、技术人员以及客户的高级管理人员便能提供服务等级协议 (SLA) 报告。这些业务报告用于展示服务质量会如何影响性能和用户 QoE。该信息会直接影响客户的满意度或投诉率。

对服务保证系统开放接口

　　要实现开放式服务保证的优势，系统必须提供一系列 API 与系统处理的信息进行交互。API 的用途各不相同。传统上，我们主要将接口分为四类：北向、南向、东向和西向。北向 API 用于访问信息。南向 API 可使系统从多个来源获取数据。东向和西向配置负责导出和导入 API，并用于与 OSS/BSS 调配系统集成。系统的每个阶段都需要北向和南向 API（如图 3 所示）。然后，API 会用于一个软件组件，即将 OSS/BSS 连接在一起的连接器。其中的箭头表示可使用 API 开发的多种连接器。

连接 Brix 系统的北向、南向、东向和西向接口

图3. 连接 Brix 系统的北向、南向、东向和西向接口

北向 API 和连接器

　　北向 API 和连接器主要用于提取开放式服务保证系统处理的信息。

　　1. 直观展示

　　现代 OSS 通过 Web 界面向用户提供信息。在开放式服务保证系统中，每个显示画面、屏幕、门户页面、报告和管理界面都以 Web 页面的形式展现内容，而 Web 页面可以基于 URL 从其他任何 Web 门户或应用程序启动。这样，就可以对来自不同 OSS/BSS 的信息进行简单但功能强大的 Web 集成或结合。这项技术的主要用途就是显示由服务保证系统从故障管理系统（如 Micromuse Netcool）生成的详细故障诊断信息。

　　可以使用标准 Web 门户（信息接入点）来创建门户页面，并且针对管理层人员、事务管理人员和客户定制其内容。该门户内置的报告和仪表板可显示为 portlet，并且可以根据需要进行混合和匹配。所有这些 portlet 都可通过符合远程门户 (WSRP) 标准的 Web 服务进行访问，并可导入到来自 BEA 和 IBM 等厂商的公司 Web 门户中进行显示。
　　2. 分析

　　服务保证系统可对收集的数据进行分析，以生成用户所需信息。它可将服务质量的测量结果转换为用户能够理解的关键性能指标 (KPI) 和关键质量指标 (KQI)。它利用强大的商业智能特性来整合和总结数据，从而以用户能够理解的方式进行组织、过滤和呈现。此外，还能以业务环境的角度组织信息，而不是单纯从技术角度。分析过的数据可通过 API 进行提供。该接口的一般用途便是将融合的 SLA 数据馈送到客户支持门户。

　　系统会对收集的数据进行分析，查找预示着潜在 SLA 违例的条件。如果检测到潜在的 SLA 违例，系统便会通过信令网络管理协议 (SNMP) 或者能够转发到 OSS 的故障和问题管理系统的电子邮件来发送 SLA 告警。EMC Smarts、Remedy 的 AR 故障标签系统和 Tivoli Enterprise Console 都是故障和问题管理系统的示例，它们可与本系统的 SLA 告警相集成。

　　3. 整合

　　服务保证系统可将从网络多个位置和设备获得的测量结果整合到系统维护的数据库中。此外，它还可将在不同位置获得的测量结果关联为单个视图，对进行质量测量的测试、呼叫、视频流或服务请求进行集中显示。与传统测试和测量装置采用的本地视图不同，此类系统可显示相互关联的端到端服务质量测量结果。这些相互关联的整合测量结果可导出到 CA 的 eHealth、InfoVista 和 Telcordia 的 Service Director 等性能管理系统。

　　4. 测量

　　服务保证系统利用整个网络上的软硬件进行服务质量测量。可以通过整合数据库查看这些测量结果。此外，测量层还会生成阈交告警，这些告警可以通过标准 SNMP 通知协议发送。这些通知可用作对潜在问题的快速早期警告；测量层生成的 SNMP 自陷已与众多故障管理系统相集成，包括 Micromuse NetCool 和 HP OpenView。

南向 API

　　与开放式服务保证系统连接的南向接口通过系统内置的专业知识和智能，获取来自网络设备、测试和测量系统以及其他 OSS 的测量结果和数据进行处理。API 可在每个级别获取数据，如图 3 所示。

　　1. 测量

　　很多测量都是通过网络中的设备并使用相关标准进行的。其中一些标准包括：

　　(1) 实时控制协议 (RTCP XR)，端点可利用该协议报告语音质量
　　(2) 双向主动测量协议 (TWAMP)，可提供一项标准技术测量同一网络上两台设备之间的 IP 层网络性能
　　(3) 会话发起协议 (SIP) 和网络呼叫信令 (NCS) 媒体环回，可以使 Brix 系统将非插入式测试呼叫置于客户驻地网设备、终端适配器、住宅网关以及 IP 电话
　　(4) IEEE 802.1ag 和 ITU Y.1731，可用于测试和测量基于提供商的以太网接入网络的性能

　　2. 整合

　　网络中的设备、测试和测量系统，或者其他 OSS 性能系统得出的测量结果，可整合到开放式服务保证系统及其测量结果数据库。Cisco 的 IP SLA 就是一个例子，通过这项功能，已部署在网络中的路由器便可以运行测试并测量网络性能。借助开放式服务保证系统，所有这些统计数据都可存储在中央数据库中，以便与从其他来源收集到的监控数据一同进行分析、关联和报告。

　　3. 分析

　　对于任何服务保证系统而言，使数据与业务用户相关联都是一项挑战。面向业务用户的高效分析可构建于服务保证系统的商业智能 (BI) 引擎上。一个简单的例子就是，获取与某位客户有关的全部服务质量测量结果，并将其整合到 KQI 的整体视图中。这样，服务客户经理即可利用该信息回答诸如“哪些客户在这段时期遭遇了较差的服务？”之类简单但却至关重要的问题。获得这样的信息后，客户经理就能前瞻性地采取行动，从而在问题变得严重之前安抚受影响的客户，以次减少客户投诉。

　　当与其他 OSS/BSS 数据库中存储的其他业务数据结合使用时，服务质量 BI 分析将发挥出更大作用。例如，通过将每位客户的收入与客户的服务质量信息相结合，服务提供商就能够开发出更精巧的收入模型。而开放式服务保证系统可从外部数据库获取数据，并将其纳入自己的分析。

　　4. 直观展示

　　通过在开放式服务保证系统中添加 Web 门户，服务提供商便可将来自任何 Web 应用程序的信息与服务质量信息一同展示在单个门户页面中。例如，通过单个页面便可呈现站点的可用性，以及连接到该站点的调配系统的 Web 接口。门户可以包括采用 WSRP 标准开发的 portlet，或者可以包括 Web 页面或 Web 页面片断，所有这些都可通过 RUL 进行访问。

东向和西向 API

　　东向和西向 API 用于将开放式服务保证系统的配置集成到服务提供商的调配系统中；是处理插件、迁移和变更的地方。通过 Brix 系统，可提供两种主要的 API：调配导入 API 和配置导出 API。

　　1. 调配导入

　　调配导入 API 用于控制服务保证系统。例如，添加新客户时，调配 API 可用于创建从已部署 Brix 检测器运行的新测试，以测量该客户的网络接入链接，并为该用户添加用户帐户，供其查看月度报告和安排运行这些报告的日程。

　　2. 配置导出

　　与调配导入相反，配置导出 API 用于确定当前的服务保证系统配置。它可用于推动对业务流程的支持，如在将新检测器添加到网络时为其自动分配地址并设置防火墙。

结论

　　借助开放 API 以及 OSS/BSS 之间的连接器，服务提供商可以开发出灵活的系统，以适应不断变化的各种下一代 IP 融合网络。随着该网络上构建的服务数量变得越来越巨大，并且越来越复杂，确保用户获得同样高的体验质量的重要性也随之增加。能够确保用户获得比竞争对手更好的服务质量，是使顶级服务提供商脱颖而出的关键所在。服务保证流程必须全天候对服务质量进行测量、整合、关联、分析和直观展示。要取得成功，服务保证系统就必须与所管理的 IP 网络具有相同程度的开放性。

共 2 页：1 2

通讯世界(www.tele.com.cn)