优异的OCS系统 助Starhub保持竞争优势

新加坡Starhub（星和）是新加坡第二大综合性电信类业务运营商，属于新加坡淡马锡控股的子公司，通过淡马锡控股在世界上多个国家的获得的电信业务执照，共同组成了一个庞大的电信业务联盟，在全球具有很强的辐射力和影响力。Starhub业务范围涵盖了固网、移动、宽带以及有线电视等多个方面。

    作为亚太地区人均GDP最高的国家，新加坡拥有领先和成熟的电信市场（移动渗透率高达132.6%），这也意味着Starhub从成立之初就面临移动业务市场激烈的竞争。凭借在预付费业务上的差异化竞争优势，Starhub从2004年起，跃升为新加坡第二大运营商并拥有最大的移动预付费用户群。随着其他运营商的跟进以及用户的增长，原有预付费系统遭遇性能瓶颈，过低的接通率引来了大量的投诉，并且无法满足Starhub推出新业务的需求。于是StarHub在2006年决定替换原有系统，中兴软创最终成为Starhub OCS系统的提供者。

    Starhub OCS项目横跨了在线计费、CRM、SCP/SMP、IVR、USSD、彩铃（CRBT）等多个产品。整个系统在技术框架上以OCS为核心，其他模块以接口的方式与OCS进行松散的耦合关联。

    作为发达国家的成熟市场中的高端运营商，为适应激烈竞争的市场需要，Starhub对OCS产品提出了非常苛刻的要求，中兴软创凭借过硬的产品技术实力，逐渐赢得了Starhub的信任，并以优异的系统性能最终得到Starhub的认可。

可靠性设计

    作为一个在线业务系统，保证7×24的不间断服务是运营商的基本要求。在系统框架的设计上，为保证系统的高可靠性，中兴软创第一次在核心业务中大规模使用了Unix+Linux平台，并提供了双机-双网-双系统的整体冗余和容灾设计。

操作系统平台的选择

    由于Starhub对系统的稳定性要求严格到苛刻的程度，中兴软创的设计人员在项目的最初就谨慎比较了各种操作系统平台，最终放弃了在核心业务中使用Windows，将产品全面转移到Unix+Linux平台。这虽然给开发工作带来很大的难度，但是结果证明这样做是值得的，Unix类的高稳定性、高性能、高安全性和高度的可维护性保障了OCS系统的稳定性和可靠性。

双机部署

    在部署整个系统的核心OCS后台服务器时，考虑到传统的使用Cluster的方式是Active-Standby进行主备机的切换，平常只有一台机器上的应用在运行，这样做双机切换需要消耗很长的时间启动备机上的资源和应用，我们将OCS的运行机制结合TimesTen数据库的双向复制功能，构建了Active-Active的后台服务环境，两套OCS同时运行，这样进行双机切换时仅切换服务IP所在的网络，而不需要切换相关的资源，也不需要重新启动任何进程，最终双机切换的时间被压缩到了1秒以内，极大地提高了系统故障恢复的效率。

双网配置

    系统所有的网元设备都做成冗余配置，在单个节点设备出现故障时可以自动切换到另一个节点。

    作为实时在线应用平台，ZTE OCS的系统框架非常强调系统的可靠性问题，这在Starhub项目中体现得非常明显，除了主机的双机配置，所有网络设备，包括网络交换机和防火墙等也都设置了双机冗余。

双系统容灾

    除了正常的生产环境，我们还在Starhub建设了异地容灾站点，在主生产站点遇到不可抗因素的灾难时，异地容灾站点可以继续发挥作用。

    在容灾方案的选择中，综合成本和性能等因素，我们使用了自动加手工的切换方式。对于核心的系统和应用数据采取自动镜像复制功能，通过光纤连接主站点和备用站点的磁阵，所有的客户资料、账户余额、注册信息等都在主站点和容灾站点的磁阵上同步保存。

    在需要切换的时候，主站点和容灾站点的数据是一致的，所以只要启动备用站点的应用即可，这一步工作由手工来处理，在系统启动过程中遇到各种预料之外的复杂场景时，手工处理具有比较明显的优势。

繁杂的接口

    Starhub拥有完备的IT系统，除了系统内部IVR、USSD、VC等子系统，OCS需要对接所有的这些相关子系统，而且必须沿用已有的协议和规范，接口类型基本涵盖了目前主流应用的大部分协议。典型的接口协议包括CORBA、SOCKET、SOAP、XML、数据库表接口以及不同格式的文件接口等，很多接口都是在OCS项目中第一次使用。

短信/彩信接口

    StarHub的短信和彩信中心只支持自己制定的基于CORBA的IACC接口，这是OCS在接口问题上遇到的第一个挑战。最终我们选择了VB for C++作为业务的中间件平台，并在此基础上开发了高性能的协议转换接口。经过多次功能测试、性能测试以及可靠性测试，以及上线以来长时间多次超负荷压力的洗礼，充分证明这是一个成功的接口。

数据业务接口

    Starhub没有传统的GGSN，而是在数据平台和计费系统之间搭建了一个计费网关，使用基于SOAP的OPG/CSPG协议。考虑到实时计费业务对响应时间有严格的要求，我们放弃了使用传统Webservice的方案，自行开发了符合HTTP 1.0规范的SOAP服务程序，需要特别说明的是本接口支持SSL传输。

银行充值接口

    Starhub OCS是首个大范围使用Webservice的项目，中兴软创的研发人员基于Tomcat设计开发了多种灵活的业务平台，广泛用于银行接口和号码携带（MNP）等业务。

    除了VC充值卡，Starhub还与岛内多家银行签订了ATM充值协议，所以OCS系统开发了3种银行充值接口，包括DBS银行使用的基于Webservice的固定格式的充值查询请求、SAM银行使用的Webservice+XML的接口方式以及AXS等使用的基于SOCKET+XML的接口协议。

服务开通接口

    Starhub的服务开通采用了数据库表接口，加上Java消息服务器的接口方式，在OCS和网元之间是一个第三方的JMS服务器。

单点登录接口

    Starhub对企业内部工作人员和终端用户使用了两种不同的SSO服务，一种是基于LDAP协议的Active Directory服务，用于为企业内部人员统一认证操作，OCS中所有的CRM登录都必须经过AD的认证后才能进入下一步操作。

    对于客户自服务等系统的认证，OCS提供了Right Access接口，将OCS自服务系统中所有的网页都置于Right Access的保护之下，确保用户的充值查询等操作安全无虞。

    此外，中兴软创还为Starhub提供了多种格式的其他接口，包括DWH接口、FMS系统接口、Cutie-bear充值接口、E-voucher业务接口等，这些外部接口和OCS核心系统一起为StarHub内部客户以及最终的移动业务消费者提供了完美的服务体验。

完美的施工和割接

    为保障系统的顺利调试和割接上线，我们也采取了一些有效的创新性措施。

模拟器的大规模使用

    在系统部署到现场的第一天起，各类模拟器便发挥了重要的作用，功能测试模拟器、性能测试模拟器等广泛用于语音、短信、VC充值、银行充值、IVR/USSD调试等各项业务，贯穿了软件调试、端到端对接测试、UAT功能测试、UAT性能测试等各个方面。

分步割接的支持

    支持分步割接上线是Starhub OCS实施的亮点之一，对于用户量比较大的割接任务来说有比较重要的意义。为支持大量用户的分步割接，中兴软创除了制定完善的数据核对和同步策略，还提供了新老系统并行期间的请求路由功能，在所有相关的应用上添加了消息转发功能，在CRM页面上添加了重定向等功能，从而在终端用户和系统操作人员基本没有感觉到系统变迁的情况下，实现了全部割接。

网管的精彩表现

    我们将网管作为一个重要模块来对待。网管监控对象包含了主要的硬件和网元设备、系统和应用服务以及业务相关的关键数据，在网元和服务出现异常时能及时生成告警到网管终端，并且根据告警的严重级别和紧急程度，选择发出邮件和短信通知相关人员。

    Starhub OCS中对网管的使用，主要集中以下在几个方面：

    硬件监控，网管通过代理程序或SNMP采集主机设备、存储设备以及网络设备的状态和告警信息，对于主机除了自身的告警，还采集和监控CPU、内存和文件系统空间使用状况、网络连接状态等信息。

    应用进程和服务的监控，监控系统中数据库、中间件、OCS后台应用程序、接口程序以及接口连接状态等信息，并提供告警和进程拉起功能。
关键业务数据的监控，系统对于语音、短信、充值等关键业务的CDR和Log进行监控，能够针对告警和错误的不同情况作出判断和处理。

    上线运行后，网管系统多次在重大隐患出现之前提供告警，从而避免了恶性事故的发生。

    借助OCS的不俗表现，Starhub陆续推出了Happy Topup、Use X Get Y、Upsize IDD、Redpac Topup、Tourist Card、Spin&Win、Data Pass、Mobile TV等各具特色的业务，用户量也从割接初期的不足80万上升到100万。Starhub2009年财务公报显示，使用OCS的预付费业务在所有业务线中一枝独秀，成为增长最快的部门。