业务部署

业务部署（精选8篇）

业务部署 篇1

通过梳理各行业中的关键业务应用, 我们不难看到一些新的特征, 例如在电信行业、银行领域中, 企业业务复杂, IT依赖程度高, 软件系统数量繁多, 同时具备复杂性的多系统多产品线也在不断涌现;另一方面, 运营效率的提升需求又在挤压软件的总投资。来自不同方面的压力使得企业的CIO们必须思考一个本质的问题—如何在有限的软件投资范围内, 通过有效的方法支撑繁杂的关键业务体系, 实现多系统间的规模化定制。

“软件平台”普及关键行业

对此, 普元提出了“软件平台”的概念, 即借鉴平台化理念, 将软件实现与运行的共性技术抽取集成封包成为“技术平台”, 用来构建与支撑应用软件的独立软件及系统。

这样做的好处是, 企业通过引入软件平台, 可以快速实现高质量、低成本、灵活、低维护的软件产品, 即以规模化定制的方式, 实现在合理成本的约束下提供可定制、个性化、多样性的软件系统。

普元软件高级副总裁刘尔洪告诉记者:软件平台趋势将是软件业发展最重要的趋势之一。

刘尔洪解释说, 金融行业、电信行业等领域的大型企业都有共性业务和个性化业务, 共性业务需要全网部署, 个性化业务应由各地方自由开发营销而不受总部约束。面向业务的软件平台将大量成熟而实用的应用组件和模块进行高度封装, 并内置功能强大的工作流管理系统、电子表单管理系统、信息门户系统、统一用户管理系统、消息管理系统、知识管理系统等各种成熟的应用系统和开发工具。

开发人员在进行软件开发过程中, 绝大多数开发与应用无需特殊的代码编写, 只需按照项目需求选择相应的组件或模块进行“拖拽式”配置, 而捏合过程由系统自动完成。

“共性+个性”加速应用效率

正如统一规格、统一标准的机器零部件, 只需按要求简单的拼装即能成为完整的机械设备一样。“软件平台”大大提高了软件开发的效率, 降低了软件开发与应用的难度, 并且应用可立即部署, 大大缩短了应用开发的调试期。

这些功能浓缩后就是普元为软件平台化提出的“四个现代化”:层次化、组件化、产品化、简约化。比如从财务角度, 软件平台化表现为多项目软件管理的ROI;从业务角度, 软件平台可为业务部门提供支撑;从管理角度, 软件平台更多意义在于对精细化管理的支持。

事实上, 软件平台化趋势已成共识, 软件平台化也将是“十二五”期间软件技术和产业的趋势之一。在平台化趋势下, 软件的竞争从单一产品的竞争发展为平台间的竞争, 未来软件产业将围绕主流软件平台构造产业链。

业务部署 篇2

兼顾，保质保量完成各项经 营指标任务，在剩余几天时间内，全员行动起来，奋力赶超完成任务。针对全县信用社的存款、不良、客户完成情况，联社副主任李素 伟按增减幅度、定期活期分类通报了相关情况，要求各社进一步提高 服务水平，以“强服务、促转型、谋跨越”为主题，“三个转变”为 指引，转变工作作风，改善服务态度，提高思想认识，努力保持存款 的稳定性，连续性和前进性。清收不良过程中，不要仅限于现金清收，还要通过转化、活化等方式处置，要勤下乡，多催收，努力清收不良 贷款。要统一思想，认清形势，针对优质客户，各社、各网点不得出 现推诿扯皮现象，有困难要及时向联社反映，共同研讨解决，发放贷 款时要合规、合法、手续齐全，做好服务和解释工作。针对全县的财务检查情况及利收完成情况，联社副主任郭志通报 了检查情况并做出了详细安排，要求对账岗和记账岗必须分离，月对 账率必须达到 95%以上，数额在 100 万元以上的账户必须对账达到 1 00%。开户手续要规范、齐全，并且在有效期内。他指出，截至 3 月

17 日，全县完成利息收入 321 万元，占到任务的 14.1%，其中只有杨 芳、分社占到 50%以上。利息收入是信用社经营的关键指标，各社一 定要重视起来，努力完成一季度计划指标任务。针对国家公职人员逾期拖欠贷款的清收情况及信贷达标情况，联 社副主任刘培荣做出了详细安排与通报，要求在今后的工作当中，信 贷资料、流程要严格按照规定执行，调查、审查、检查要遵照规章制 度执行，发放贷款前要认真审核，信贷会计要做到“六不入账”，按 月进行贷后风险分类，及时预警，科学管理，签订贷款合同时间与电 脑流程时间必须一致，提高档案的管理标准，明确信贷责任，信贷人 员要树立信贷风险观念，各项贷款严格按照联社发文的文件执行。会议进入第六项议程，联社党委书记、理事长郭俊裕做业务促进 会、贷款专项检查讲话，郭理事长鼓励全社员工坚定信心、转变观念、创新举措、抓好落实，进一步寻找差距和不足，下定决心、排除万难，确保一季度各项任务圆满完成。在业务经营方面，理事长郭俊裕指出，组织资金、不良贷款清收、利息收入等几项主要经营指标不容乐观，在全市排名倒数第一，就这 样的经营成绩，要实现转型跨越发展，提高员工收入，无疑是纸上谈 兵。全县信合人，尤其是网点负责人一定要做到以社为家，具有高度 的责任感和使命感，一定要为信用社的发展做贡献，为广大职工谋利 益，要当好家，不要无所事事、得过且过，一季

季度下达的各项指标任 务必须不折不扣完成。

关于贷款专项检查，全县信合员工一定要站在事关农村信用社生 存和发展的高度，深刻领会这次贷款专项检查的重要性和紧迫性，统 一思想，提高认识，端正态度，积极参与，对自己的行为、对自己所 发放的贷款、所承担的责任进行一次全面的、细致的自查自纠工作。关于贷款发放工作，郭俊裕理事长告诫大家坚持“十个严禁”和 “六不入账”，即：严禁发放超权限贷款;严禁发放多头贷款;严禁发 放手续不完善贷款;严禁发放借冒名贷款;严禁发放假担保和关联人 相互保证及自然人大额信用贷款;严禁继续对不具备贷款主体资格的 部门发放贷款;严禁发放不符合国家产业政策的贷款;严禁对有不良 贷款和欠息的企业、自然人发放贷款;严禁违规倒约换据;严禁一个家 庭内多人承贷。今后检查中如发现以上违规行为，县联社将追究有关 人员的责任。信贷会计在坚持真实性、执行性上严格把关，做到“六 不入账”：非本人办理不入账、超过贷款权限不入账、借据要素不全 不入账、抵押和担保手续不全不入账、不符合换据条件不入账，在我 县其他营业机构有不良贷款不入账。针对我县信用社的工作作风问题，郭俊裕提出以下几点：

一、求 真务实，彻底扭转作风不实的现象。

二、爱岗敬业，彻底扭转精神不 振的现象。

三、遵规守纪，彻底扭转纪律松散的现象。

电信级业务平台云化研究和部署 篇3

为贯彻落实中国电信“新三者”定位 (智能管道的主导者, 综合平台的提供者, 内容应用的参与者) , 打造聚合、高效、开放的综合业务平台, 中国电信业务平台应朝着加强管理集中、统一开放、资源共享方面演进。主要包括管理集中、整合减少 (含同质整合及关停下线) 、平台云化三方面。

1.1 管理集中思路

新建业务平台原则上应全部纳入ISMP、UDB集中管理, 并纳入业务平台集中监控;已有平台根据规划安排分批纳入管理, 扩容改造项目立项前进行是否需纳入横向管理的评估, 未纳入集中管理的平台优先安排改造或在项目中考虑纳入。

1.2 整合减少思路

对业务平台从产品生命周期、产品收入、运营成本等多方面进行评估, 对无效益平台进行退网, 对同质平台进行整合。并且形成长效机制, 避免功能相同或相近的平台重复建设, 及时发现新的无效益平台并补充到整合任务中。

1.3 平台云化思路

统筹考虑资源在省内的集约共享, 同时兼顾集团对于云计算资源和服务统一管理的要求, 建设统一的云计算资源池。将云计算Iaa S技术作为业务平台整合的一种重要手段, 实现硬件资源集约共享, 提高业务平台资源利用率。

2. 电信级业务平台演进方案

2.1 树立“9+1”整合目标

9代表到2015年末, 我省不纳入云资源池的业务平台数不超过9个, 1代表云资源池, 即大部分业务平台需迁移到云资源池上。

对全省业务平台进行梳理, 从平台分类、业务重要程度、业务量、专属设备情况、机房分布、割接难度、网络条件、技术条件等多方面进行综合评估, 考虑暂不纳入云计算资源池的9个平台为IPTV平台、全球眼平台、高清视频会议系统、智能网平台、彩铃、短信、号百三统一、电子广告平台、统一支付平台。这9个平台从评估情况看, 都属于有较多非通用设备 (专属设备) 、数据库IO非常频繁、与交换呼叫业务相关、实时性要求高、割接难度比较大或者技术条件有困难的平台, 可考虑实施平台内部云化改造或者部分入云资源池, 待条件成熟后, 再统一纳入云计算资源池。

2.2 管理集中方案

重点实现移动互联网应用、行业应用全面纳入横向架构管理, 有效支撑产品的集约运营与快速部署。

将ISMP-M升级为ISMP-M/W, 并将互联星空浏览类业务、彩铃、ITV增值业务等纳入ISMP-M/W管理。2011年, 集团考虑在省公司开展ISMP-M和ISMP-W融合试点, 由ISMP负责宽带及视讯类业务的统一发布、统一管理、统一鉴权计费。福建省响应集团要求成为五大试点省份之一, 并成功完成试点工作。通过试验对IPTV、VNET等宽带及视讯类业务的融合管理, 推进ISMP体系跨网络多种类业务的管理, 为中国电信全业务运营提供坚实基础:构建统一的增值业务产品视图、增加业务开展的灵活性、满足客户个性化订购的需求、加快3G、ITV及宽带市场的开展及占有, 从而为电信带来可观的经济效益和社会效益。

ISMP-B重点关注支撑行业应用快速上线。所有新接入政企信息化和行业应用原则上应纳入ISMP-B进行管理, 并逐步纳入已有的政企信息化和行业应用。

UDB重点完善业务域、IT域双向互通, 试点业务域、接入域互通, 积极探索认证能力+客户信息+支付能力的综合信息对外开放。所有新建平台具备认证功能的均应纳入UDB平台进行统一认证管理, 已有认证模块的平台也应逐步纳入。

2.3 整合减少 (含同质整合及关停下线) 方案

以效益为导向, 从产品生命周期、产品收入、运营成本等多维度, 梳理、分析、论证产品清退、整合的原则, 并在此基础上, 全面梳理平台退网、整合的标准, 对无效益平台进行退网, 对同质平台进行整合。

针对每一个要退网或整合的平台, 制定了详细周全的方案, 以保障平台整合工作的顺利进行。主要整合方案有:地市平台整合到省级平台, 承载固网、PHS用户的业务平台逐步退网, 窄带平台业务逐步迁移到宽带业务平台。

2.4 业务平台云化方案

以Iaa S技术为基础构建了云计算资源池, 加强了计算、存储、网络等资源的集约共享, 实现了项目与资源分离及资源的按需分配与动态管理。提高了业务部署效率, 可以满足各种自营应用及合作类应用的快速部署需求。

3. 业务网云计算资源池现状

(1) 马尾云资源池节点

资源池由23台PC服务器, 8台交换机, 2台防火墙, 2台存储 (132.6T裸容量) 组成, 采用VMware虚拟化软件。

(2) 仓科云资源池节点

资源池由18台PC服务器, 8台交换机, 2台防火墙, 1台存储 (48T裸容量) , 其它安全设备5台组成, 采用VMware虚拟化软件。2014年扩容, 新增48台PC服务器、两台光纤交换机, 扩容93.6TB裸容量。

4. 业务平台云化部署方案

目前业务系统多采用三层架构 (接入层-应用层-数据库层) 。在实施云化部署时, 各层分别需要若干台虚机来承载, 虚机的配置和数量依赖于各层应用的特性。通过对系统的特性分析, 给业务平台云化提供了资源分配思路, 既可指导原有系统的云化迁移, 也可作为新建系统的资源分配参考。每一层的特性分析及虚机分配思路如下:

4.1 接入层

(1) 基于密集连接型接入层

如云密保等系统, 这类应用的特点是不断有大量的访问请求从终端向主机发出, 单一请求的计算量很小, 各请求互不关联, 而请求并发量很大。这种情况下, 需要接入层有足够数量的线程响应请求, 而单个线程计算量不大, 因而对单个CPU处理性能要求不高, 而可以通过提供足够CPU数量或接入服务器数量来满足需求。因而, 该种应用需求的虚拟化技术支撑关键点是数量较多的小配置的虚机作为前端接入层服务器。

(2) 基于稀疏连接型接入层

这类应用用户基数较小, 通常属于非大众性业务, 如报表类、网上审批系统等, 每个用户登录时间较长, 多是进行流程性操作, 此类应用接入层压力较小, 在虚机的配置上考虑到满足所需的并发连接及可靠性即可, 可配置若干台小配置的虚机作为前端接入层服务器, 也可根据应用层的部署情况, 与应用层虚机整合部署。

4.2 应用层

(1) 基于大运算量的应用

如客户关系系统、地理信息系统、车翼行等复杂信息处理系统, 这类应用的特点是每一连接的逻辑计算量较大、运算复杂、内存需求大, 应用逻辑对服务器计算性能要求高。因而, 该种应用需求的虚拟化技术支撑点是配置较高性能的应用层虚拟机。

(2) 基于简单业务逻辑的应用

此类业务的应用层通常对数据做简单的逻辑组合, 不涉及海量数量计算及浮点运算, 每事务所消耗的CPU时间片较小, 对于此类应用, 仅需配置若干台小配置的虚机作为应用服务器, 也可根据接入层的部署情况, 与接入层虚机整合部署。

4.3 数据库层

(1) 基于海量数据的数据库应用

如计费系统等, 信息量巨大, 对于数据库层的压力较大, 需要配置强大的数据库层服务器, 提供足够的CPU及I/O性能来处理大量的数据。在许多情况下, 需配置独立的数据库服务器来满足需求。

(2) 一般类型的数据库应用系统

此类应用数据量不大, 数据表之间的关联运算较少, 以企业网站为代表。对于此类应用, 考虑到数据库应用自身将消耗一定的CPU、共享内存及I/O资源, 可提供1-2台高配置的虚机作为数据库服务器。

目前, 在业务网云计算资源池已部署了公共信息化平台、天翼景象、翼商云、翼起购、SIP IPC、通信报社、电信俱乐部、二维码系统、光网城市、晋江磁灶闽运兴、晋江中小企业创业团队、零门槛接入、绿盟备份、能力开放管理门户、宁德电大、人力资源开发中心、升腾云桌面演示环境、省电子研究所、厦门金龙、库易云呼叫中心、翼云桌面、云密宝、中兴呼叫中心、助老网平台、IEN智慧节能、数字城管系统、保险E通、省经贸委肉品追溯系统、食品安全公共查询平台、销售管家平台等30个业务。

5. 业务平台云化实施效果

截至2014年10月底, 我省整合减少 (含同质整合及关停下线) 的平台数量为58个, 纳入云计算资源池的平台数量为30个, 纳入ISMP-M/W统一管理的平台数量为7个, 纳入ISMP-B统一管理的应用数量为76个, 纳入UDB统一认证的平台数量为27个, 36个平台以平台级方式纳入集中监控平台, 10个平台以业务级方式纳入集中监控平台。我省的业务平台整合云化成果位居中国电信集团前列。

参考文献

[1]刘鹏.云计算 (第二版) [M].北京:电子工业出版社, 2011.

业务部署 篇4

层出不穷的3G增值业务为电信运营商创造了广阔发展空间，随之产生了对移动带宽需求的迅速增长，移动业务的宽带化发展不可避免地带来了移动业务IP化承载趋势。传统MSTP网络主要承载移动2G/2.5G业务，语音是其主要业务，因此带宽需求不高，网络相对稳定可靠;而到了3G时代，MSTP就逐渐无法满足移动业务发展的需求了。

(1) MSTP的刚性管道，没有统计复用能力，无法满足移动带宽增长和IP化需求。在3G时代，数据业务占整个移动业务带宽的70%以上，且具有很高的突发特性，而MSTP会导致巨大的带宽浪费和投资浪费;

(2)带宽增长，大量的E1接口带来整个MSTP网络调配的复杂性，基站接口以太化后，又面临MSTP对FE到GE的汇聚比太低的不适配性;

(3) MSTP缺少智能化的网络承载能力，很难满足LTE阶段基站之间的业务互通、基站的多归属关系等需求;

(4) MSTP无法提供网络时间同步功能，因此无法替代GPS。

随着3G业务的迅猛发展，基站数据流量激增，企业面临继续规模扩容现有MSTP网络还是引进基站承载新技术的抉择。本文通过对下一代传送技术网IP RAN与PTN的对比，结合某电信运营商工程实例，提出了IP RAN综合业务组网方案。

2 部署方案

随着智能终端的普及，移动互联网流量快速增加，竞争对手的策略可能会加速LTE的部署进程，因此需要承载网络以较低的成本来承接流量的膨胀。某电信运营商政企专线接入CN2业务在本地延伸能力、同城互联业务能力等方面存在不足，软交换、C网、政企专线等多个独立接入承载专网众多，网络建设及维护成本居高不下。而城域网目前尚不具备基础数据网业务迁移承接能力。

为抓住全业务发展和网络技术演进的时间窗口，必须按照统一、融合的网络架构，系统地实施综合承载网的发展演进。

2.1 方案选择

后3G时代和LTE阶段，PTN和IP RAN将成为下一代传输网的主流技术。

(1）业务能力

IP RAN可综合承载2G/3G/LTE基站、NGN、专线、IPTV、HSI等业务，支持多点;PTN可承载2G/3G基站承载和二层专线，仅能在业务流向相对固定、接入点和业务点数量较小时用点到点技术满足多点需求。

(2）网络扩展性

IP RAN二、三层技术兼容动静配置，设备启动协议掌握全网拓扑，指导业务转发，配置工作量小，调整简单;PTN仅支持二层静态技术，所有业务的转发路径和备份路径人为指定，在业务路径经常变换时工作量较大。

(3）互通性

IP RAN可以实现不同厂家设备的互通;PTN端到端必须使用同一厂家设备，导致网络扩容、优化受限。

(4）投资保护

IP RAN可利旧部分IP城域网资源;PTN需端到端新建，投资较高。

(5）技术成熟度

IP RAN标准统一，成熟可靠;PTN标准化进程缓慢 (MPLS-TP) ，产业链尚不成熟。

综合上述因素，某电信运营商选用IP RAN方案。

2.2 IP RAN建设方案选择

IP RAN的建设可以采用两种方案：

(1)利旧城域网资源：利旧IP城域网SR、CR、CE设备及其电路并进行扩容，以满足业务需求;

(2)新建IP承载网：新建本地IP承载网，实现对高价值业务的承载;原IP城域网中SR分离到本地IP承载网，城域网中只保留宽带上网业务。

考虑建设成本及现有网络资源，某电信运营商决定采用第一种方案。

3 业务承载方式

对于基站FE业务，接入环接入路由器A到汇聚路由器B之间建立PW，再通过B启用L3VPN连接到BSC/SGW侧的RAN-CE。对于基站E1业务，通过分段PW实现，并在B实现PW的粘贴。汇接路由器设备上联IP城域网SR设备，通过SR至CR原有电路上联CR，本期新增CE及CE至CR设备电路，通过CE连接至BSC设备。

汇聚节点B成对配置，形成双归属方式接入不同的接入环(图1)。

4 网络拓扑

按照建设方案，需新建一对RAN-CE设备，各通过1条10GE电路与两台CR设备对接，2条GE电路与BSC1对接;汇聚层在6个汇聚机房新建汇聚路由器，汇聚路由器通过GE电路双上联至SR设备，接入层双挂在汇聚路由器下面以保证网络的安全性。网络结构如图2所示。

5 结束语

业务部署 篇5

一、IDC网络安全需求探讨

面对无序的网络环境, IDC用户存在着多种安全需求。首先是防治病毒需求。当IDC用户浏览到一些恶意邮件和病毒、或无意中运行一些恶意代码程序时, 都很可能导致病毒侵蚀, 进而造成系统崩溃等危害。其次是安全访问需求。由于用户托管系统与互联网处于连接状态, 所以很可能存在一些不法分子通过互联网对用户托管系统进行非法访问, 进而影响系统安全性。然后是防治异常流量需求。IDC用户对各种信息数据的需求量较大, 对数据实时性及准确性的要求较高, 如果互联网被各类异常流量侵袭, 将会导致服务器瘫痪, 难以较好满足用户需求。最后是安全监控需求。IDC用户对相应信息的获取要求较高, 所以其需要实时了解自身托管主机以及互联网中的安全情况, 并采取有效措施进行应对, 这样才能降低用户损失。

二、IDC网络安全增值业务的实现与部署探讨

2.1清洗流量业务实现与部署

如图1, 显示的是清洗流量业务系统结构图。在实现方面, 清洗流量业务系统中包含多个模块, 主要包括异常流量监测、流量牵引、流量过滤、网路流量模型学习等模块。当流量监测模块检测到因DDOS侵袭产生的异常流量时, 就会将相关信息传递给流量过滤模块。之后再由流量过滤模块以BGP协议为基础将策略路由发送至IDC汇聚层路由器, 对相应流量进行牵引, 再由相应的清洗模块对DDOS攻击流量进行清洗, 最后将正常流量输入网络。在部署方面, IDC运营者须购买合适的流量清洗系统, 在汇接层对相应的流量清洗过滤设备进行设置, 在接入层对流量监控设备进行设置, 并采用SPAN方式对流量进行监控。当异常流量被清洗后, 正常流量依旧可以到达被攻击目标。IDC运营者还需对安全报表系统进行开发, 为用户提供各种安全日志、安全报表查询功能, 从而让用户能够更好了解业务相关情况。

2.2安全特区业务实现与部署

如图2, 显示的是安全特区业务系统结构图。在实现方面, IDC运营者可对系统进行划分, 分为一个外网区以及多个用户服务区, 在用户服务器之间设置一定的VLAN隔离, 在服务器和外网之间设置一定的安全通行策略。在网管系统和用户托管系统中建立相应的业务管理系统, 让用户自行管理。在安全网关的用户管理系统中建立相应的报表系统, 为用户实时提供各种报表查询及安全查询功能。在部署方面, 采用负载均衡备份方式对安全网关进行设置。在IDC汇接层对业务节点进行部署, 将用户托管主机转移至专门的空间进行放置, 并开发用户自管理业务管理支持系统以及用户报表系统。

2.3安全评估业务实现与部署

在实现方面, 安全评估业务系统主要对各种远程漏洞进行扫描, 并加以审核。由于漏洞扫描软件可能会出一些漏报和错报问题, 所以技术人员需加强维护, 根据主机相应情况采取一定的安全加固措施。在部署方面, IDC运营者须购买适宜的远程漏洞扫描软件, 确保其能够较好适应IDC网络系统环境, 能实时更新漏洞数据, 并形成相应报告。

结束语:互联网虽然有着较多优势, 存在着多种数据交流平台, 但是基于其自身的无序性, 很多风险隐患都侵蚀进互联网的方方面面, 而IDC用户与互联网之间存在着紧密联系, 致使IDC用户面临着较多的安全风险。因此, 面对各种风险因素, IDC运营者必须准确分析网络环境, 设置多种安全增值业务, 并进行合理部署, 满足IDC用户的安全需求, 从而更好促进IDC的发展。

参考文献

[1]许莎佳.IDC网络安全的构建[J].中国电子商务, 2013, (17) :55.

业务部署 篇6

随着移动互联网应用的日益丰富, 特别是微信等OTT业务的飞速发展, 电信运营商的短信、彩信等业务正在受到冲击, 统计数据显示[1], 2014年1-6月, 全国移动短信业务量仅有3789亿条, 同比下降18%;彩信业务量仅有316亿条, 同比下降30.3%。移动短信业务收入持续下滑, 1-6月, 收入规模同比减少37.3亿, 除了1月份春节刺激增长以外, 连续23个月出现负增长。

在此背景下, 短信、彩信等的原有业务模型已与用户使用习惯产生偏差, 如按原有业务模型对平台进行规划和建设, 既与实际需求不匹配, 不适应业务发展, 同时也造成投资的浪费, 本文将以短信平台为例, 对业务模型的优化调整进行研究, 同时, 对短信平台云化部署进行探讨。

二、短信业务模型优化

结合对某电信运营商省级公司短信中心的现网日常、节假日的数据监测与分析, 短信中心业务总量、点对点业务量、月平均每用户点对点短信数量自2013年起呈明显下降趋势。

2.1原有业务模型

某电信运营商省级公司短信中心原业务模型如下:

短信中心处理能力=总用户数× (平均每天发送短消息条数+平均每天接收短消息条数) ×忙时集中比系数/3600×节假日放大系数。

2.2调整后业务模型及效果

由上文分析可以看出:

由于受到互联网OTT消息类业务的冲击, 短信业务量处于下滑的趋势, 并且这一趋势会逐渐加剧;

平均每天发送短消息条数、平均每天接收短消息条数因用户短信量减少, 应根据实际情况做调整;

短信平常日期业务量处于下降趋势, 仅受节假日影响点对点短信量会发生剧增, 但考虑到在节假日时将会关闭SP群发短信通道, 故平时忙时业务量和节假日忙时业务量相差不大, 需对节假日放大系数进行调整。

根据业务量实际情况进行分析, 短信中心业务模型主要调整参数为:

节假日放大系数:原取值为3, 调整后为1.1;

平均每用户每天发送短消息条数:原取值为6.7, 调整后为1.23;

平均每用户每天接收短消息条数:原取值为9.03, 调整后为3.42。

业务模型优化前后对比如下:

现有能力:6000条/秒;

原有扩容方式 (达到值) :11000条/秒;

优化扩容方法 (达到值) :6442条/秒;

实际扩容 (增量) :442条/秒。

可以看出:模型优化后, 短信中心能力仅需扩容442条/秒 (满足峰值) , 减少扩容4558条, 可节省投资约200万元。

2.3业务模型优化后续建议

1) 基于长期历史数据分析得到的业务模型会更加贴近实际, 符合长期业务发展趋势, 故短信中心应对尽可能长时间的历史数据进行保存 (建议至少一年) ;同时, 对日常及节假日峰值数据进行存档, 可便于验证优化后模型是否满足峰值需求。

2) 短信业务随着移动互联网的发展也在不断变化, 短信业务模型也建议进行周期性修正, 以适应业务的迅速变化。

三、短信平台云化方案

随着移动互联网进入高速发展期, 电信运营商面临被“管道化”, 需加快网络转型。而运营商业务平台与移动互联网平台最为相似, 因此业务平台就成为运营商向移动互联网化转型的排头兵。通过对“BAT”三大公司企业战略的分析, 不难看出云平台是共同的基础, 云平台符合移动互联网时代的特征, 用户体验优、开放、低成本、可运营、业务提供快速。因此, 打造业务平台云, 实现业务创新, 成为电信运营商转型的关键。

短信业务具有节假日等高峰期突发性明显的特征, 若处理能力不足, 容易造成时延, 大大降低用户感知, 造成用户流失。随着用户数的增多, 电信运营商一般对短信平台相关硬件进行逐年扩容, 采用传统方式 (非云计算) , 存在部署时间长、非高峰期资源利用率低、投资较高等缺点, 且不符合技术发展趋势, 故可对短信平台进行云化部署。

3.1主要模块云化评估

1) 信令前置机:信令专用设备, 暂不能云化;

2) 业务处理机、SMPP Server、接口机:硬件基于X86, 操作系统基于Linux, 可优先考虑云化;

3) QAS/CDR/DB Server:承载有关系型数据库, 建议在引入分布式数据库后, 实施云化迁移。

由以上分析可知, 除信令专用设备外, 短信中心业务分析、接口、SMPP等全部业务均可移植在虚拟机环境运行。

3.2云化步骤及方案

对于短信平台云化, 总体方案可分三个阶段进行实施:

第一阶段:云化平台搭建, 主要建设内容包括资源申请、环境搭建、软件部署、软件功能与压力测试等。该阶段续完成短信平台业务处理机、接口服务器等模块的虚拟化部署;

第二阶段:云节点与现网节点双节点试运行, 主要建设内容包括云化平台的对外接口配置、功能配置修改、DNS分流配置、周边网元配置与对接实测等;

第三阶段:整体迁移云化, 主要建设内容包括数据库迁移、应用程序配置、DNS指向与网络配置调整等, 由云化平台承接业务, 因平台地址涉及众多SP, 联调量大, 建议尽量采用原地址, 如云资源池建设情况无法满足源地址携带的话, 可选择更改为新地址, 建议更改平台访问方式为域名方式。

四、短信业务发展思路探讨

相比微信等OTT信息服务, 短信虽费用略高, 但发布正式、到达较为快捷、来源可靠, 使其成为多数用户正式沟通或者获取商家信息的首选。在具体应用中, 例如支付宝的验证码服务, 依靠短信为用户提供实时的安全金融服务。

从某电信运营商省级公司短信中心提取数据来看, 虽然点对点短信业务量呈加速下滑趋势, 但行业短信得以蓬勃发展, 以2014年6月为例, 用户接受点对点短信为6404万条, 接受群发短信为3.51亿条, 绝大部分业务为行业短信。

针对点对点短信业务呈现疲软, 行业短信拉动发展的现状, 可以预见以后短信中心的峰值就在平时, 而不会出现在节假日的所谓高峰。而业务的定位也应该着眼于群发和行业短信:

群发短信方面, 可针对节假日, 推出相应的短信促销和套餐优惠, 针对商户发布群发短信的优惠套餐。

行业短信方面, 在银行、交通等行业应用中, 短信起到了关键性的作用。对行业客户而言, 短信意味着电信运营商的一套高效安全的运营体系, 包括了整个质量管理体系和安全保障体系。事实上, OTT平台出现不仅影响了消费级市场, 而且对行业应用也有一定的影响, 但因为行业用户有一定的使用门槛, 使得冲击变得缓慢。因此电信运营商应更多地与行业用户和企业用户进行协作, 为企业内部治理和行业应用提供支持, 特别是在交通、银行、教育、天气等政府部门和大型企事业单位, 这些部门对信息发布的权威性和可达性要求较高, 应着力为其提供支撑服务。

参考文献

业务部署 篇7

从2009年开始, 中国电信已在广东等6省13个本地网进行IP RAN试点, 目前已进入大规模商用阶段。IP RAN综合业务接入网, 以满足IP化基站业务、政企客户专线业务以及未来LTE业务的承接需求为目的, 提升接入网络的扩展性和综合承载能力。网络组织结构、业务承载方式、保护机制的部署等成为网络建设至关重要的因素。本文对IP RAN网络建设的关键因素IP RAN网络规划要点进行阐述, 并对业务承载方案及保护机制部署进行分析。

2 移动承载需求

(1) 基站回传等自营业务承载需求

(1) 随着移动数据业务的规模发展, 基站IP化已经成为必然趋势。基站的接口也将从原有的大量E1+少量FE发展为GE/FE等以太接口为主。

(2) 随着LTE阶段的到来, 满足基站灵活互联、基站多归属及组播等需求, 为客户提供更为丰富的应用, 综合接入网需具备高度的扩展性和业务实现能力。

(2) 政企专线业务需求

随着视频会议、数据共享等应用的增多, 大客户接入带宽粒度由传统的E1向FE、GE、10GE变化;大客户业务规模发展后, 特别是L3VPN的需求大量涌现, 则需要延伸3层到边缘, 满足政企客户日益显著的点到多点、多点到多点组网需求。

(3) MSTP无法满足高速发展的移动业务需求

传统MSTP网络对于移动2G/2.5G网络的业务承载, 语音是其主要业务, 带宽需求不高, 网络稳定可靠, MSTP具备天然的优势和很高的适配性。而3G以及后3G时代和LTE阶段, MSTP逐渐无法满足移动业务发展的需求, 主要体现在:

(1) MSTP的刚性管道, 无统计复用能力。在3G时代, 数据业务占整个移动业务带宽的70%以上, 数据业务具有很高的突发特性, MSTP会带来巨大的带宽浪费和投资浪费;

(2) 带宽增长, 大量的E1接口带来整个MSTP网络调配的复杂性, 基站接口以太化后, 又面临MSTP对于FE到GE的汇聚比太低的不适配性;

(3) LTE阶段, 基站之间的业务互通, 基站的多归属关系, MSTP实现困难, 缺少智能化的网络承载能力;

3 网络规划与设计

3.1 建网原则

综合业务接入网定位于城域内基站回传等自营业务及政企客户业务的高质量接入和承载。建网模式包括一下两类:

(1) 利旧现有IP城域网资源作综合承载:以IP城域网为基础进行综合承载, 利旧IP城域网SR、CR设备及其电路, 新建综合接入网, 无线、专线、NGN、IPTV等业务实现就近综合接入。

(2) 新建精品IP承载网:新建本地IP承载网, 实现对高价值业务的承载;原IP城域网中SR分离到本地IP承载网, 城域网中只保留宽带上网业务。新建综合接入网, 实现无线、专线、NGN、IPTV等自营业务的接入。

3.2 拓扑结构

3.2.1 分层结构

IP RAN网络的建设按照接入层、汇聚层和核心层来规划, 支持灵活丰富的拓扑结构, 可根据本地实际和光缆情况进行选择:

(1) 接入层:可采用环型、链型、双上行等任何组网方式, 建网时重点考虑已有光纤资源;从节约光纤成本等综合考虑, 接入层推荐环型组网;

(2) 汇聚层:可采用环型、口字型组网, 规划时需结合考虑光纤资源情况和带宽需求;考虑到承载效率, 推荐口字型组网;

(3) 核心层:沿用城域网架构, 汇聚层路由器通过SR接入城域网。

典型网络拓扑图如图1所示:

3.3 IP RAN业务承载方案

I P R A N采用I P/M P L S标准, 增加同步、保护、OAM、网管等功能, 简化路由转发等指标, 目前中国电信IP RAN试点主流的业务承载方案为PW+L3VPN方式, 即基站单播业务在IP RAN综合业务接入网的接入层采用PW承载, 在汇聚层和核心层采用L3VPN方式进行承载。

4 IP RAN网络保护机制部署

4.1 IP RAN保护机制分类

IP RAN综合业务接入网网络组织中, 从隧道、业务及网络层面都进行了保护策略的部署, 不管接入层、汇聚层和核心层的节点或者链路出现故障, 网络都能快速检测并通过迂回路径及时解决问题。

(1) 隧道保护:LSP1:1保护是IP RAN网络中基本的保护方式, 在建立LSP主隧道的同时建立LSP备份隧道;当主用链路出现故障时, 通过备份链路能够实现数据的传送。

(2) 业务保护:IP RAN网络采用PW+L3VPN方式进行业务承载, 接入层采用PW冗余, 在接入层业务节点间将建立主用PW、备用PW和迂回PW隧道。在汇聚层和核心层采用的VPN FRR的保护方式;

(3) 网络保护:BSC双归到IP RAN网络, 两台RAN-CE之间采用的VRRP以及心跳报文的传送方式。

另外, 在IP RAN网络中, 不管是隧道层面、业务层面和网络层面, 均可采用BFD进行快速的故障检测。

4.2 关键技术介绍

4.2.1 BFD快速侦测

网络设备要求对相邻系统之间通信故障进行快速检测, 这样在出现故障时可以更快地建立起替代通道或倒换到其他链路。当数据速率到吉比特时, 故障感应时间长代表着大量数据的丢失。

BFD (双向转发检测) 是一套用来实现快速检测的国际标准协议, 提供轻负荷、持续时间短的检测。BFD能够在系统之间的任何类型通道上进行故障检测, 这些通道包括直接的物理链路、虚电路、隧道、MPLS LSP、多跳路由通道, 以及非直接的通道。

BFD是一个简单的“Hello”协议, 工作原理如下:

(1) 自身没有邻居发现机制, 靠被服务的上层应用通知其邻居信息建立会话;

(2) 会话建立后, 周期性地快速发送检测报文;

(3) 一段时间内未收到检测报文即认为发生了故障, 通知被服务的上层应用进行相应的处理。

4.2.2 LSP 1:1隧道保护技术

LSP1:1是在IP RAN网络中最基本的保护形式, 应用于源宿节点不变的场景, 用于保护外层标签。在建立LSP主隧道的同时, 建立LSP备份隧道, 同时下发到转发平面, 当主隧道出现故障时, 业务快速切换到备份隧道承载。可采用MPLS OAM或者BFD实现快速故障检测。

优点:LSP1:1机制成熟稳定、易于实现、倒换性能好, 维护机制类似于SDH的线性保护, 扩容简单。

缺点:抗单点故障, 大批量时维护较复杂。

IP RAN组网中, LSP1:1保护常与业务保护同时部署。

4.2.3 PW冗余

PW冗余属于业务保护手段, 是在建立主用PW的同时, 建立备份PW和Bypass PW, 当主PW出现故障时, 业务切换到备份PW, 之后从Bypass PW迂回到原PE设备。可采用BFD for PW实现快速故障检测。

4.2.4 VPN FRR

FRR快速重路由技术能够实现对局部的链路或者节点进行保护。FRR通告预先建立备份路径的方式进行保护。当检测到主用路径中断后, 可以将流量快速切换到备份路径上, 保证业务不中断。

VPN FRR利用基于VPN的私网路由快速切换技术, 通过预先在远端PE中设置指向主用PE和备用PE的主备用转发项, 并结合PE故障快速探测, 旨在解决CE双归PE的MPLS VPN网络中, PE节点故障导致的端到端业务收敛时间长 (大于1s) 的问题, 同时解决PE节点故障恢复时间与其承载的私网路由的数量相关的问题, 在PE节点故障情况下, 端到端业务收敛时间小于1s。

以L3VPN典型组网为例:

假设CE-B访问CE-A的路径为:

CE-B——PE-E——P-C——PE-A——CE-A, 当PE-A节点故障之后, CE-B访问CE-A的路径收敛为:CE-B——PE-E——P-D——PE-B——CE-A。

VPN FRR技术立足于CE双归属的网络模型, 是面向内层标签的快速倒换技术。

4.2.5 VRRP虚拟路由器冗余协议

VRRP虚拟路由器冗余协议作为网关保护技术, 是为解决如下问题而产生的:

网络上的主机设置了一条缺省路由, 该路由的下一跳指向主机所在网段内的一个路由器R1, 由R1将报文转发出去。这样, 主机发出的目的地址不在本网段的报文将被通过缺省路由发往R1, 从而实现主机与外部网络的通信。然而, 当R1出现故障, 主机将与外界失去联系, 陷入孤立的境地。

VRRP作为容错协议, 能够在保证当主机下一跳路由器坏掉时, 可以及时地由另一台路由器代替, 从来保持通讯的连续性和可靠性。具体解决方法如下:

(1) 将多个路由器运行VRRP协议, 并组成一个虚拟路由器。虚拟路由器拥有一个虚拟IP地址和MAC地址。

(2) LAN上的终端主机利用虚拟路由器作为其缺省路由器。

(3) 根据优先级的大小和主IP地址挑选主路由器Master, 由它提供实际的路由服务;

(4) 其他路由器作为备份路由器, 随时监测主路由器的状态。当主路由器正常工作时, 它会每隔一段时间发送一个VRRP多播报文, 以通知组内的备份路由器, 主路由器处于正常工作状态。

(3) 当组内备份路由器长时间没有接受到来自主路由器的报文, 则自己状态转为Master。这时每个主路由器会比较VRRP报文中的优先级和自己本地的优先级, 如果本地的优先级小于VRRP中的优先级, 则将自己的状态转为Backup, 否则保持自己的状态不变。通过这种过程, 能够选出优先级最大的路由器作为新的主路由器, 完成VRRP的备份。

4.3 IP RAN网络保护机制部署

中国电信IP RAN网络业务承载方式采用分段承载, 因此保护技术和检测技术也根据网络层次灵活部署, 具体如图7所示:

在IP RAN网络部署中, 主要检测内容包括:

(1) BFD for LSP

(2) BFD for PW

(3) BFD for VRRP

(4) BFD for FRR

当IP RAN网络中节点或链路出现故障, 网络能够自动实现故障检测, 并通过迂回电路, 实现数据传递的快速恢复。主要实现方式概况为:

(1) LSP1:1

在网络各段建立主用链路和备用链路, 当主用链路在a处出现故障, 数据传递的迂回路径将改为:

(2) PW冗余

针对接入层PW承载方式, 当主用PW在b处出现故障, 数据传递的迂回路径将改为:

(3) VPN FRR

通过部署主备PE, 实现业务上冗余备份。当d处出现故障, 数据传递的迂回路径将改为:

(4) VRRP

用于保护RAN CE及RAN CE与BSC之间的链路故障, 当e处出现故障, 数据传递的迂回路径将改为:

5 总结

本文从中国电信IP RAN网络实施场景入手, 展示了典型的网络组织规划, 并对网络组织中主流的保护策略进行深入研究。综合分析, IP RAN综合业务接入网能够面向未来, 采用分层的网络结构、灵活的业务承载方式以及全面、稳定、成熟的保护机制, 为IP RAN大规模商用提供了基础保障。

参考文献

[1]龚倩, 徐荣, 李允博等.分组传送网.北京:人民邮电出版社, 2009.

[2]中国区IP RAN组网实践培训 (华为) .华为中国区方案部.

业务部署 篇8

近年来, OTT业务对全球范围内的电信运营商的传统业务冲击日益增大。刚刚过去的2014年, 被业界普遍认为是Vo LTE大发展元年, Vo LTE的发展进入快车道, 借助于Vo LTE以及RCS, 运营商可将与OTT服务提供商的竞争引向一个新的阶段。

2 LTE语音解决方案及Vo LTE商用进展

LTE已经成为主流的新一代宽带无线移动通信技术, 采用统一分组域网络架构, 不再像传统的2G/3G网络那样提供电路域业务, 因此如何在LTE网络提供语音业务成为业界关注的一个问题。现阶段, LTE语音解决方案包括CSFB、SVLTE、Vo LTE三种。

CSFB (Circuit Switched Fallback) :LTE只提供数据业务, 当用户发起或者接受语音呼叫时, 从LTE网络回落到2G/3G的电路域重新接入, 并按照电路域的业务流程发起或接听语音业务。

SVLTE (Simultaneous Voice and LTE) :双待机终端同时工作在LTE网络和2G/3G网络里, 可以同时从LTE和2G/3G网络接收和发送信号。双待机终端在拨打电话时, 可以自动选择从2G/3G模式下进行语音通信。

Vo LTE (Voice over LTE) :基于IMS的语音业务。当LTE网络达到全覆盖时, Vo LTE语音方案将成为运营商的终极解决方案。Vo LTE的核心业务控制网络是IMS网络, 通过IMS系统的控制, Vo LTE可以提供传统电路域的语音业务及其补充业务。

相对于CSFB和SVLTE, Vo LTE基于LTE网络提供语音业务, 并支持与2G/3G互通, 成为LTE网络的终极语音解决方案, 世界主流的运营商、设备制造商、终端芯片厂商都将Vo LTE纳入了其发展规划。例如中国移动TD-LTE语音解决方案就是以Vo LTE为主, 同时兼顾CSFB, SVLTE作为一种终端形态长期存在。

从全球Vo LTE的全球应用来看, 海外的应用步伐相对较快。包括Verizon、AT&T、韩国的SK电讯和LG Uplus等海外运营商较早开启了LTE网络的部署, 并提前试水Vo LTE业务。2014年第一季度, 在全球商用Vo LTE的运营商名单里还只有韩国的KT、SK Telecom、LG U+, 德国O2等6家 (数据来源GSA统计报告) 。进入第二季度, 美国移动运营商TMO抢在竞争对手AT&T前一天在5月2 2日正式发布了Vo LTE商用业务。6月份, 日本运营商NTT Do Co Mo和KDDI也相继推出了Vo LTE商用服务。此外, 还有多个T 1运营商宣布了2014年商用Vo LTE的计划, 这其中包括了美国Verizon和中国移动等运营商。

在国内, 中国移动正在积极推进Vo LTE商用服务。但整体来看, 国内三家基础电信运营商对于Vo LTE语音策略各异。中国移动因TD-SCDMA网络性能和市场发展均不占优势, 对于Vo LTE态度最为积极而明确;中国电信面临CSFB标准与CDMA网络兼容性和互操作等问题, 对于Vo LTE的态度也较为积极。中联通对于Vo LTE需求不如移动和电信迫切, 态度并不积极, 可能在将来很长一段时间都会以CSFB作为主要的LTE话音方案, 以相对较小的网络满足用户高质量语音业务的需求。

3 Vo LTE商用阶段运营商“管道化”更加严重

随着互联网技术的高速发展, 人们的生活不断地被新的技术重塑。Skype、Facetime、微信等OTT业务开始拓展到语音、消息和视频, 这运营商的三大传统业务市场, 逐渐侵蚀电信运营商的核心盈利点。运营商的“管道化”危机日益严重, 迫切需要新型的业务来抢占用户, 增加收入, 应对来自OTT业务的冲击。

在LTE时代, 随着Vo LTE的商用, 运营商“管道化”的趋势不仅没有改善, 反而日趋严重。究其原因, 一方面LTE运营商利用LTE每比特成本降低, 推出更优惠的数据套餐, 反过来推动了OTT业务的爆炸性发展;另一方面, LTE加剧了数据业务竞争, 运营商纷纷推出“管道化”套餐。

3G时代由于每比特成本较高, 运营商一致抵制被“管道化”, 一定程度上延缓了“管道化”进程。但LTE的出现以及Vo LTE的商用, 打破了原有的“市场平衡”, 使部分“成本控制”较好的运营商率先接受了“管道化”定位, 其他不愿被“管道化”的运营商也不得不跟随, 形成“雪崩效应”, 促使整个移动运营业向“管道化”加速蜕化。

4 运营商应对策略及RCS介绍

4.1 运营商应对策略

“管道化”危机, 部分原因是由于运营商传统的通信模式更关注功能的实现, 忽略了用户通信体验的优化, 简而言之:通信体验十多年停滞不前, 无法满足用户不断增长的通信需求。运营商传统的通信模式如表1所示。

OTT业务正在蚕食运营商的固有领域, 运营商也可以实现OTT业务最常见的功能, 以迈出竞争的第一步。但在与OTT的竞争中, 若采用OTT的方式应对则难以成功, 这相当于抛开运营商的所有优势, 以短比长, APP方式的类RCS业务均难以成功。面对该困境, 在GSMA推动下, 定位为4G时代的基础通信服务的RCS, 正在逐渐被全球运营商认可和接受。

4.2 RCS简介

RCS (Rich Communication Suite) 业务是由GSMA (全球移动通信联盟) 负责规划的, 构建在IMS网络之上, 具有统一业务集定义的技术标准, 是基于手机电话号码簿实现语音、消息、状态呈现等多媒体业务的总称。

目前互联网上各种OTT应用软件由不同服务商提供和开发, 用户使用时需要分别注册, 因此, 不同应用软件之间很难实现互联互通。RCS直接基于手机通信录, 在此基础上扩展语音、视频、即时消息、文件传送等通信服务, 并以全球50多亿移动用户为基础, 基于全球互联性和互操作性构建一个庞大的“社交网络”, 增强用户粘性, 应对微信等互联网即时通信平台业务、社交网络等的竞争。RCS对运营商的价值可以从几方面进行分析:

(1) 丰富运营商的业务种类。目前, 运营商内置在手机地址簿中、可以提供给用户的功能只有语音和短信, RCS可以让运营商向用户提供即时消息等IP多媒体功能;

(2) 充分利用互联互通的优势。运营商相对于互联网企业, 最大的优势就是互联互通。Whats APP、LINE、i Message等应用在当前难以互通, 并且互通问题的解决, 不仅涉及到技术层面, 还涉及到政策层面, 在短期内难以实现, 而运营商则可利用RCS的互联互通优势获得用户的青睐;

(3) 统一品牌, 无需推广。RCS是运营商的基础电信业务, 类似于短信, 它内置在手机中, 不需要做推广, 用户打开地址簿即可使用;

(4) 可让运营商开放更多的业务能力。RCS扩展了运营商的基础电信业务, 新增聊天、在线状态、文件传输、地理位置等功能, 这些功能都可以作为业务能力对第三方开放, 从而进一步丰富业务种类, 并从中获得一定收益;

(5) 可以促进流量的增长。从目前的商用情况看, 运营商不对RCS的功能进行单独计费, 一般是对流量进行收费。RCS的普及, 将有助于促进用户使用更多流量, 从而使运营商在流量上获得收益。

4.3 RCS能给电信运营商带来什么

RCS的商业价值包括三方面。第一, RCS可以增加运营商的业务吸引力, 提供集成呈现能力的新业务;第二, RCS的消息业务基于电话号码, 通过手机通信录, 易于使用, 可以与Skype等用户互通;第三, RCS可以增强运营商对客户个性化业务需求的响应, 基于同样的价格提供更好的服务, 保持ARPU值和用户的忠诚度等。

RCS业务除了是运营商提供的一项业务, 还将推动运营商整个网络的发展。RCS业务将极大地促进电信运营商基于IMS的多媒体业务能力部署, 促进通信与互联网络的融合、集成, 提升电信运营商网络融合通信及整合互联网社交服务的能力。在LTE阶段全IP网络化趋势下, RCS将成为电信运营商提供IP多媒体业务应用的突破点, 逐渐推动国内电信运营商网络的语音业务及语音网络向分组网络的迁移。

5 Vo LTE商用阶段的RCS业务部署

LTE系统有两种制式:FDD-LTE和TDD-LTE, 但无论是LTE FDD还是TD-LTE, Vo LTE的核心网络都是IMS网络。RCS技术同样基于IMS网络, 两者可以实现无缝集成, 可以说Vo LTE的发展离不开RCS, 运营商在实现和部署Vo LTE的同时就需要考虑与RCS的集成。针对运营商的这一需求, 各大设备厂商纷纷推出自己的RCS端到端业务部署方案, 下面简要介绍RCS业务部署方案。

RCS业务部署方案如图1所示。该解决方案为完整的端到端解决方案, 支持GSMA RCSe1.2&RCS5.1标准, 提供IMS core, RCS AS, RCS O&M系统及RCS软、硬终端提供, 在支持RCS的基础上, 同时提供Vo LTE和Vo Wifi业务。

6 RCS运营模式

运营商推出一项新的业务, 通常需要经历技术和设备选型、网络改造和建设、终端定制、业务设计及营销推广五大环节。但RCS业务显然有其特殊性, RCS并非一项简单的移动互联网业务, 而是彻底颠覆电信运营商既有运营模式的一个技术标准。三大运营商中, 中国移动对RCS业务推广是最积极的, 但是从中国移动发布的《下一代融合通信白皮书》内容来看, 直到目前为止, 中国移动在RCS方面的部署仅限于技术路径和技术规范, 而并未到后续的商务和运营战略。总结影响RCS业务推广的问题如下:

一是收费问题。如果RCS业务收费, 即使其基于智能手机原生系统, 也不会有太大竞争力;如果免费, 那运营商是否能够承受RCS流失的通话、短信收入?

二是定价问题。RCS是一个颠覆性业务, 需要将原有的定价模型全部推翻重来。并且什么业务该收费, 什么业务该免费, 使用RCS业务和不使用RCS业务用户之间的互通如何收费, 不仅不同的运营商之间有不同的态度, 即便是一个运营商之间, 亦有对立意见。

三是既有电信规则的打破。若中国三大运营商实现RCS互通, 意味着既有电信规则的打破。例如, 一位中国电信用户打电话给一位中国移动用户, 按照现有规则, 双方之间的通话需要收取一定的费用, 若实现RCS互通, 这两位不同运营商的用户不仅有可能通话免费, 更可在通话的同时发起图片、视频等多媒体内容分享, 或可轻松加进另一位用户进行多方通话。

RCS业务的推出, 肯定会对运营商现有业务造成冲击, 运营商应该在通过推出RCS业务黏住用户的基础上, 通过RCS业务平台的开放, 开放通信能力, 吸引合作伙伴, 将通信扩展到运营商不擅长的领域实现合作共赢。能力开放方式如下所述:

向上能力开放:提供基于融合通信平台API, SP/SI合作方组合封装为不同的业务, 利用自有渠道, 快速占有细分领域市场;

向下能力开放:提供统一的业务平台入口, 终端厂家, 快速推出多媒体通信产品。

基于RCS能力开放业务平台的视频监控方案如图2所示。

7 结束语

Vo LTE商用阶段, 运营商“管道化”危机更加严重, RCS将是电信运营商对抗OTT冲击的重要砝码, Vo LTE与RCS的无缝融合, 为客户提供全新的通信体验, 将成为运营商对抗OTT业务的新手段。在Vo LTE商用阶RCS段, 如何去“管道化”, 如何尽快推动产业化, 如何在新的形势下成功转型, 将是一个需要持续研究、不断实践的问题。

参考文献

[1]黄倩.GSMA RCS标准化进展研究.通信技术与标准, 2011 (8) .

[2]Vo LTE技术白皮书.中国移动, 2013 (6) .