新媒体运营的底层逻辑精选(九篇)

前言：一篇好文章的诞生，需要你不断地搜集资料、整理思路，本站小编为你收集了丰富的新媒体运营的底层逻辑主题范文，仅供参考，欢迎阅读并收藏。

第1篇：新媒体运营的底层逻辑范文

【关键词】IMS技术；新业务；全业务运营

1 前言：

IMS（IP Multimedia Subsystem）是提升网络业务能力、应对全业务运营和互联网竞争的重要手段，是核心网演进的目标架构。它用IP从技术上粘合了移动网络和固定网络，实现了FMC（Fixed Mobile Convergence），它可以使采用不同接入手段的用户通过一张融合的核心网络来使用运营商提供的各类业务。随着国内3G牌照的发放，三大运营商均具有移动和固网牌照，这使得各运营商也加紧对基于IMS的新业务研究与试验部署。本文对IMS技术发展情况进行了探讨，阐述了基于IMS的新业务能力要求和相关架构，并对组管理、公共业务标识、呈现、PoC、综合多媒体会议等新业务进行了介绍，为IMS新业务的开展和部署提出了建议，为迎接全业务的到来做好充分准备。

2 IMS概述：

IMS（IP Multimedia Subsystem）由3GPP于2000年提出，是一个支持IP多媒体业务的子系统，其核心特点是采用了基于IP的SIP协议和实现了底层接入的无关性和融合核心网的目标。

软交换的引入第一次实现了承载和控制的分离，引入了IP，是对传统交换网络的革新，而IMS是对软交换的演进，进一步实现了业务与控制的分离。IMS对交换网络的改造程度更高，各司其职，实现了网元实体的功能细化，核心控制实体更纯净。

IMS网络分为3层：从上到下为业务层，控制层和承载层。网元实体功能细化，各司其职，网元间接口标准化。

3GPP使用分层的方法设计IMS体系结构。分层的方法是为了最小化各层之间的依赖性，以便于实现传输、控制、业务相分离，避免由于其中一层的变化而影响其他层的稳定性，这就使加入新接入网变得更加容易，从而可扩大IMS的接入范围，拓宽了新业务的应用范围。

图1描绘了一个基于IMS的全业务运营网络的分层体系结构。该体系结构共包括3层，其中，承载由底层的“接入层”提供，业务逻辑由上层的“应用层”实现，而IMS心系统是中间的“核控制层”，它为业务提供会话控制能力。

3 基于IMS的新业务能力要求：

IMS架构方便了新业务的提出和实现。组管理、呈现、PoC业务等这些在智能网时代很难实现的业务形式，将成为运营商主要的盈利内容和竞争手段。

对于IMS的新业务来说，必须能够实现业务的注册和注销、鉴权和授权、业务信令的接入、SCSF指配、用户和业务数据管理、业务触发和漫游支持、信令路由、编码和寻址、SIP压缩和会话管理等基本能力要求。

IMS终端的注册流程：

3.1 IMS用户发出注册请求消息

3.2 P-CSCF通过DNS得到用户归属网的I-CSCF

3.3 P-CSCF把注册消息转到I-CSCF

3.4 I-CSCF查询HSS，为用户选择一个S-CSCF

3.5 I-CSCF将消息转到S-CSCF

3.6 S-CSCF从HSS得到用户的认证信息

3.7 S-CSCF通知用户重新认证

3.8 用户重新发起注册（1－5步）

3.9 认证通过，S-CSCF通知HSS

3.10 S-CSCF从HSS下载用户数据和iFC

3.11 S-CSCF通知AS进行第三方注册

3.12 AS从HSS得到用户数据

3.13 P-CSC用户向S-CSCF订阅注册事件通知

3.14 用户向S-CSCF订阅注册事件通知

4 IMS的新业务应用：

多媒体彩铃、GM、IM、Presence等业务是IMS中的重要业务，是运营商未来盈利的主要内容，归纳起来，这些业务有以下特点：

以群组列表数据为中心；

业务有很强的关联性或依赖性；

数据高度共享，为用户-网络共享（如Group信息），不同业务共享（如访问列表信息）；

数据网络化，数据存贮在网络，可以供用户和网络使用；

数据可移动，数据可以根据用户的不同位置（如移动终端、Internet），从网络上进行下载，或从不同的位置进行修改；

数据管理要求很高，要求可以在不同位置修改，对不同位置进行同步等。

下面，我们以几个典型的IMS新业务形式进行重点说明。

4.1 组管理业务特征：

组列表管理是IMS群组类新业务的数据中心，是IMS的重要应用服务器AS，但又不同于普通的AS，具有很大的特殊性。它能够为不同的AS提供列表数据，并可以作为业务单独提供给用户。组管理不完全依赖于IMS的框架，具有很强的独立性。在网络和业务部署时，其位置与HSS相似，是运营商的核心网元。组管理可以促进业务融合，并影响运营模式。

组管理业务虽然可以作为单独业务提供，如提供移动电话本，但主要目的是为其他业务提供数据，因此决定其具有以下特征：移动电话本业务可以供用户通过其他方式编辑电话本，并下载到终端，具有管理方便、可移动、不易失等特点，适应更换终端设备、多终端的场合，但吸引力不大组管理业务为PoC、Presence、IM、Conference等业务提供服务，而且是上述业务开展的必要条件，因此在上述业务开展时，必须同步开展组管理业务的部署。

群组类业务是未来移动业务中的重要业务，极具发展潜力，随着群组类业务的发展和成熟，组管理业务也将迅速发展，并可能获得独立发展的机会，或派生出其他类型的新业务。

4.2 公共业务标识：

为了在IMS系统中引入标准的呈现、消息、会议、群组等业务，需要引入公共业务标识PSI（Public Service Identities）。PSI标识的是业务，由AS负责执行。另外，PSI也可用于标识群组。

IMS系统使用户能在AS的控制下创建、管理、使用PSI的能力。PSI的创建既可以是静态，也可以动态的。每个PSI由一个AS管理，该AS根据PSI执行相应的逻辑控制。

IMS能够使用PSI来为IMS消息进行寻址。又如IMS域组用户数据由一个或多个AS（通常是XDM）创建。这些组用户数据可以为不同的应用和不同的AS使用，以完成和组用户数据相关的不同业务。

由于PSI直接影响消息路由、业务触发、业务逻辑等处理，必须统一规划、明确规定，保证其唯一性和正确的语义，使网元能正确理解PSI，并正确处理。

4.3 多媒体彩铃业务：

IMS多媒体彩铃业务（MRBT: Multimedia Ring Back Tone）是一种在主、被叫用户通话前，向主叫用户播放一段用户预设的个性化多媒体回铃音取代普通回铃音的业务。他的实现原理：（1）多媒体彩铃平台跨接在主被叫终端媒体协商路径。（2）彩铃媒体由被叫彩铃平台直接提供给主叫UE。

4.4 Presense（呈现）业务：

Presence是以某种通信方式，按照一定的接入准则，实时获取Presence信息，并展现给其他用户的一种方法。Presence 是面向用户提供的IMS业务中的一个关键部件，支持增值业务：如，基于Presence的智能路由、实时状态显示、一键通业务（Push to talk）、统一通信业务（Unified Communication）等。业务提供者能根据用户目前的Presence信息，来提供最适当的业务方式。

5 结束语:

IMS业务层的标准目前来看还相对不成熟，标准定义比较完善的Presence、GM(Group Messaging)、OCS等业务和部件，而业务管理等部分还没有标准化，即时会议和MRS虽有部分标准，但还没有最终完成。设备商目前的实现是基于这些草案来做的，为实现丰富的业务功能，各自进行了少量的扩展。

要真正进行IMS业务商用部署，首先应该开始IMS新业务的演示和试验，然后进行商业规模的应用。IMS新业务只在重点城市推出试商用，可以根据发展的用户规模决定建设IMS核心网；IMS核心网及应用提供基于IMS的新的增值业务，如：对媒体彩铃、Presence、GM、企业通信助理等。现网业务由原有的业务平台提供业务，同时完成IMS与现网各设备的互通。

参考文献

[1][芬]Gonzalo CamarilloMiguel A.García-Martín 编著 张同须等译3G IP多媒体子系统IMS――融合移动网与因特网

[2]Miikka Poikselka, Aki Niemi, 编著The IMS: IP Multimedia Concepts and Services, 2nd Edition

作者简介：

第2篇：新媒体运营的底层逻辑范文

[关键字]Parlay　ParlayX　OSA　OSE　OMA

1　增值业务平台概述

移动增值业务是能够给运营商以及业务提供商、内容提供商带来高额利润的业务。近几年来，国内外运营商一直将增值业务的开展作为其业务开展的重点。而增值业务有着种类繁多、内容复杂的特点，如何进行新业务的快速开发以及如何进行有效的业务管理，成为运营商以及各标准化组织关注的热点。同时。技术和市场的发展使得移动业务的价值链分工进一步细化，运营商希望通过加强对业务平台的控制保持对价值链的主导地位。因此，移动增值业务平台的重要性日益凸显。

由于历史的原因。增值业务系统的建设原来是垂直的网络结构，运营商每提供一种增值业务就要建设一套完整的业务系统。包括业务接入、业务鉴权、业务管理、用户管理以及业务计费等功能。这样不仅造成了严重的重复投资，还使网络的维护和管理成本也越来越高，更不能简单、方便、快捷地提供各种新应用。因此。运营商迫切需要改变目前的这种状况，使移动增值业务系统由垂直架构体系向水平架构方向发展，以便于新业务的快速开发、商用，同时也使得业务系统的建设、运营、维护更加科学化。降低业务系统的复杂度。水平体系架构的业务系统正是由于其易于管理、便于迅速开发新业务等特点，正逐渐被运营商和设备厂商采用，进行业务的开发与部署。

目前在移动增值业务平台方面比较重要的标准化组织有Parlay／OSA与OMA的业务平台架构。这两种平台架构都基于水平体系架构，能方便的实现业务管理、业务开发、业务能功能。

2　OSA／Parlay、ParlayX架构

2.1 Parlay、ParlayX介绍

Parlay组织成立于1998年，最初由BT、Ulticom、Microsoft、Nortel和Siemens五家公司联合发起成立，其主要目标就是制定符合工业标准的应用编程接口规范，开放电信领域，使最大范围内的市场参与者可开发和提供电信业务。同时为特定的用户群快速定制个性化业务。Parlay组织的工作重点在于制定Parlay API规范，但不包括如何实现API，以及基于API的应用、底层网络软件、物理构件、物理接口和协议。

目前，Parlay组织的成员已经超过60家，覆盖了国际上著名的电信运营商、网络设备供应商和计算机设备供应商，随着研究的深入，Parlay组织逐渐与其他标准化组织或论坛，如ETSI、IEEE、IETF、3GPP、OMA等建立起合作关系。

在Parlay组织成立后不久，3GPP和ETSI启动了3G系统UMTS的开放式业务架构的研究，称之为OSA(Open Service Access)。OSA目标就是提供一种可扩展和可伸缩的开放式体系结构，以灵活和向后兼容的方式开发新业务能力特征，同时定义一个常规的API，以支持第三方应用接入网络的能力。两者非常类似，最初的OSA标准就是由Parlay1.2和2.1加上少量的3GPP新增功能组成的。早期两者的差别在于：Parlay是单纯的接口标准，不关心任何基础电信网络结构和技术；而OSA是一种业务结构。不但包括业务接口。还包括体系结构以及Parlay至移动网络协议，如MAP，CAP等的映射。其后，两个组织决定共同研究提供一套网络运营商之外的第三方应用安全接入和控制核心网络资源的标准方法，从Parlay3.0和OSA R5开始，共同API规范，这标志着Parlay与OSA规范区于一致，统称为Parlay／OSA。

目前OSA提供两种API，即OSA／Parlay API和Parlay X Web Service。

Parlay／OSA API源自Parlay Group的Parlay API，自3GPP R5阶段开始由3GPP、ETSI和Parlay Group联合。它得到了3GPP2，JAIN，OMA等国际技术组织的支持。目前Parlay／OSA API已经发展到了OSA v7.0.0／Parlay 6。

为了让第三方业务开发商也能够开发电信业务，3GPPR6规范中引入了Parlay X Web Service。Parlay X Web Service最初由Parlay Group定义，与Parlay／OSA API相比，Parlay X完全针对缺乏电信网络知识的业务开发者而设计，在更高的层次对网络能力进行了抽象，完全屏蔽了网络技术实现的细节，因此更加简单易用。当然，代价是ParlayX的能力远没有Parlay API强大。它只是一个应用接口，仅能够提供一些基本的网络能力，不提供AAA、服务级别的协商或其它环境相关能力，当使用到某些网络能力时，需要通过调用Parlay API来实现。目前Parlay X已发展到了OSAParlay X v7.2.0／Parlay X 3.0。

2.2 Parlay／OSA架构

如图1所示，Parlay／OSA体系结构分为应用(Application)、框架(Framework)和业务能力服务器三部分。

(1)应用(Application)：应用是指开发的具体业务，如会议电视、基于位置的应用等。业务层的业务应用程序可以是第三方SP、CP开发的业务，也可以是网络运营商自己提供的业务。这些业务可以在一个或多个应用服务器(Application Server)上实现。

(2)框架(Framework)：框架接口为网络业务接口提供必需的支撑能力以及对网络业务接口的安全管理。框架接口的存在是为了保证上层的应用业务以一种可扩展的和安全的方式使用Parlay／OSA网络业务接口。当前Parlay／OSAAPI规范的框架接口提供的功能包括：业务注册、订购和查找、认证和鉴权、完整性管理。

(3)业务能力服务器(Service Capability Server)：业务能力服务器提供的业务能力特征属于非框架业务能力特征，是网络能力的抽象与封装，应用通过这些业务接口获得网络的能力，保证应用的开发不依赖于任何的网络细节与特定的网络复杂性。这些业务能力主要包括传统电信网络能力。如：呼叫控制、用户交互、移动管理、帐户管理、计费等。OSA的业务能力特征SCF(Service Capability Feature)及框架提供的运行机制都用接13API定义。需要注意的是，在使用任何业务能力特征之前，非框架业务能力特征必须向框架注册并通知框架可 用。除此之外，业务能力服务器也支持在线监控、负荷管理、时间通知等机制以及故障恢复方法。在Parlay／OSA的网络结构中，SCS一方面为应用层提供API接口，同时完成与底层网络的适配。SCS是逻辑的概念，可以分布在不同的物理节点或同一个物理结点上。

Parlay／OSA架构提供对业务能力特征(SCF)的访问控制，从而提供了灵活的应用技术和商业模式。此外，Parlay／OSAI作方式还可以管理不同厂家提供的非标准的SCF，这些由各厂家提供的非标准的SCF往往具有各自特殊的强大功能。Parlay／OSA架构主要包括以下几个主要功能。

Parlay／OSA业务、发现、绑定过程大致描述为：

(1)业务的：业务能力服务器(SCS)启动和通过框架认证后。SCS将业务能力特征(SCF)在框架上注册。

(2)业务的发现：当应用需要使用业务能力服务器提供的SCF时。也必须首先通过框架认证，认证的应用可以获得可用的框架接口，并使用开放接口获得被授权的网络业务能力特征的业务。应用选择SCF后，在与网络业务能力特征交互之前，必须建立业务协议，应用在使用任何网络SCF前，需要签订在线的业务协议。框架请求服务生成一个服务管理器，框架将服务管理器的引用传递给应用。

(3)业务的绑定执行：应用和选中的SCF交互，在交互过程中由服务管理器在服务中负责处理与应用的所有通信，应用可以通过控制命令来使用选中的SCF，或者在SCF中注册回调接口来获得需要的事件通知。服务通过相应的回调接口返回对于控制命令的响应，或者向应用报告相关事件的发生。

2.3 Parlay X架构

Parlay API功能强大，但其对于普通开发者来说，技术难度较大，且需要开发者具备一定的电信知识。并且，在基于CORBA技术实现的Parlay API中，对于多媒体业务的控制响应速度慢、效率不高，尤其在创建跨平台应用时，可伸缩性较差。对此。Parlay组织在2002年提出了另外一种业务发现、创建方式：基于HTTP的Web Service模式。Parlay4.1规范从整体上引入了Web Service的概念，并且在原有Parlay API协议基础上，对Parlay API所描述的电信网络能力进一步的进行抽象，使用基于Web Service的WSDL(Web Service Descript Language)语言对API进行描述，从而给开发人员一个更为清晰、简洁、易于理解的电信业务开发接口。这样，IT开发人员无需掌握电信网络专业知识，即可快速理解ParlayX，利用Web Service技术开发出丰富多彩的电信增值业务。

Parlay与Parlay X在网络中的位置如图2所示。

从图2可以看出，Parlay X Web Services API位于现有网络之上，现有网络的网络单元通过Parlay X Web Services网关与应用服务器进行交互，从而提供第三方业务或综合的业务。

Parlay X Web Services网关可以直接与网元连接，也可以通过Parlay／OSA网关与网元连接。Parlay X WebServices网关与应用服务器之间的接口为Parlay X WebServices APIs，与Parlay／OSA网关之间的接口为ParlayAPIs，与现有网络的网络单元之间的协议采用各个网络的现有协议。

3　OMA OSE架构

OSE(OMA Service Environment)，是OMA的业务体系架构规范。可以简单的理解为OMA定义的移动业务应用层逻辑体系架构，或者体系架构的抽象模型。

OSE的目标就是提供一个灵活的、可扩展的结构给应用开发者、业务能力和业务提供者，在这个结构中可以生成、部署OMA业务引擎，并对其进行业务维护。OSE是OMA业务能力和相关操作者之间的一个概念环境，可以实现业务能力之间的重用，不同的业务能力可以方便地加入这个框架。OSE提供给业务开发者和SP一个完整的具有互操作性的环境，可以对OMA业务能力方便地进行集成、移植。

OSE 1.0规范已经完成，并开始实施。OSE 1.0的逻辑结构如图3所示。

(1)业务引擎实现

指业务引擎在运营商侧或者终端侧的实现。业务引擎是用于某一业务开发、部署及运营的技术，它被OMA定义为一个或一组规范，这些规范以标准包的方式。如Presence、定位业务引擎。

(2)策略执行者

提供基于策略的管理机制，通过诸如收费、用户隐私／参数设置等方式保证底层资源的安全，并对访问请求进行管理。

(3)业务绑定

指通过特定的语言、协议将业务引擎和接口进行绑定。业务绑定通常指访问某业务引擎所需要的特定的语言的语法、协议。

(4)业务执行环境

包括流程监视、软件生命周期管理、系统支撑功能(如线程管理、负载均衡和缓存)、对引擎的运行维护管理等功能。

(5)应用

执行工作时所需的相关功能的实现，通常涉及一个或多个业务，由软件和硬件元素组成。应用是开始和结束调用引擎的基本实体，它可以直接调用业务引擎实现去实现业务。应用可以放在业务环境(包括移动终端)的任何地方。

OSE的基本思想是每个业务引擎只定义与核心功能相关的功能、协议和调用方式。每个业务引擎都必须定义一个或多个标准接口提供给外部，以便其他业务引擎调用其功能。如果某个业务引擎需要依赖已定义的OMA功能，必须指明使用哪个引擎的何种接口。

为了简化业务应用层的架构模型，OMA首先对各种应用接口进行了分类。OMA在OSE中定义了四类接口：

10：内在功能接口类，由OMA进行定义。若没有Policy部分，该接口直接提供给Application和其他Enabler，便于不同Enabier之间的功能重用；

10+P：应用了Policy的IO接口，提供给Application和其他Enabler。其中，P是IO接口上的一个附加参数集，部分P参数的语法和语义在OMA中进行定义，但P也可以不含任何附加参数：

11：资源与业务执行环境之间的接口，例如软件生命周期管理。在OMA中进行规范，作为OSPE的一个部分；

12：实体调用底层资源功能的接口类，例如IMS提供给应用层的开放接口。这一类接口不在OMA中进行规范。

4　OSE与Parlay／Parlay X

Parlay/OSA与Parlay X为第三方业务开发商提供了方便调用电信网络资源的API，这些网络资源(业务能力)包括呼叫控制、消息类业务、位置类业务、Presence、计费、策略等，以及OMA定义的业务能力。3GPP和OMA的 工作范围有着大概的分工，3GPP负责定义3G网络协议、网络架构，包括无线链路、接入网及核心网的协议、架构，OMA负责与底层网络无关的业务能力的定义。而Parlay和ParlayX则是为了在业务能力之上调用业务能力、开发第三方应用。由此看来。Parlay／ParlayX与OMA的关系应该更为密切，因此，在2008年，Parlay与ParlayX的工作由3GPP转移到了OMA，3GPP原来关于Parlay／OSA与ParlayX的工作冻结。

为了更好地利用Parlay、ParlayX来访问、开发基于OMA业务能力的业务，2008年OMA的ARC组成立了一个PSA(Parlay Service Access)项目。其目的在于继续Parlay／OSA与ParlayX在3GPP冻结之后未完成的非技术性的工作。另外，为了给出Parlay与OSE的相互融合架构以及OSE如何更好地使用Parlay与PadayX提供的资源，OMA的ARC组还成立了一个PIOSE(Parlay in OSE)项目。

在PSA中，OMA给出了从OSE的角度来如何使用Parlay和ParlayX，如图5所示。

图5给出了将Parlay／ParlayX融合到OSE架构中的一个框架。从该框架可以看出，OSE的底层资源被分为两类：Parlay／ParlayX资源和非Parlay／ParlayX资源。Parlay／ParlayX API则看作是OMA的一种业务能力实现。业务能力实现可以调用Parlay／ParlayX资源和非Parlay/ParlayX资源。当SP开发应用时，通过10+P或直接通过10接口调用OMA业务能力实现。如果SP开发的业务需要调用Parlay／ParlayX资源，则通过Parlay／ParlayX API调用这些资源。

Parlay／ParlayX资源指实现Parlay／ParlayX API的物理实体，如Parlay／ParlayX网关、OSA SCS(Service CapabiIityServers,业务能力服务器)。从图6可以看出，OSE中的应用或业务能力实现可以通过10接口直接调用Parlay／ParlayX资源。

将Parlay／ParlayX与OSE结合起来的好处是：

(1)在OSE环境下，调用Parlay／ParlayX资源，从而尽可能地减少投资损失；

(2)为运营商和设备商在开发平台架构时，提供一个更为灵活的架构；

(3)给业务开发者提供更为灵活的接口。可以开发基于3GPP的业务和OMA业务能力的业务；

(4)在重用OMA业务能力和Parlay／ParlayX API时。避免因为参考不同的规范给开发者带来困惑。

第3篇：新媒体运营的底层逻辑范文

关键词：三网融合；WLAN；广电

1 三网融合下WIFI发展的背景

有线电视网作为国家的重要战略资源，不仅是党和政府的“喉舌”，担负着非常重要的宣传任务；另一方面它们又是信息传播的工具，是满足人民文化生活需要的大众媒体。其公益性、广泛接入性和宽带优势使其可以通过优质的服务和经济合理的价格同时起到为党和政府服务，以及为民众提供丰富的多媒体信息服务的双重功用。

南京有线互联网接入业务的开展有助于实现数字电视、互动电视、网络媒体等不同类型的多媒体信息服务产品。为南京200余万乃至全省1600万有线网络用户的提供多层次服务。

此外，南京有线互联网接入业务兼备网络交互传输技术，以及视频节目丰富的双重优势。在家庭电脑和电视终端拥有数较高的南京，通过业务的运营，可以在全国首先实现宽带信息网络全面接入每一个家庭，大大丰富民众对宽带接入的选择，不仅使得宽带互联网接入不再因服务和资费的高高在上而成为少数人的服务，真正贴近百姓民生。更可通过对现有各项资源的高度整合，在服务和覆盖上对有线数字互动电视形成有效补充，在满足老百姓不断增长的文化需求消费的同时，充分利用业务的优势发挥承载社会信息化的基本功能，推动南京信息化服务产业的发展，与有线数字互动电视并肩促进数字南京的推进步伐，在全国信息化和文化产业建设中起到示范和标杆作用！

无线WIFI作为互联网接入的新技术，越来越多的被政府、企业和个人用户所使用，基于WIFI接入和有线电视网络承载的新型网络就成为广电发展的必然选择；同时也可以将电视业务和视频节目更好的覆盖的千家万户。目前有线电视网络本身就在走IP化的道路，不仅仅在接入网，目前核心的数字电视前端已经IP化了，点播流的推送也实现了IP化，采用WIF接入并依托有线电视网络的安全性和权威性构建权威信息平台，发挥对舆论的正确导向，净化网络舆论环境的作用，建立政府和市民的良好沟通渠道；同时为有线电视迅速接入新媒体产业，树立新媒体权威性奠定了坚实的基础。

2 国家政策

根据工信部电管函【2012】452号文件给南京有线的批复，其中第一条“同意你公司在南京市开展基于有线电视网的互联网接入业务、互联网数据传送增值业务、国内IP电话业务。”

互联网的基础是基于TCP/IP协议，所有的用户互联网终端是以为TCP/IP协议簇为基础的网络终端。因此广电要实现基于有线电视网络的互联网业务，必须对接入网络进行改造，即要实现从有线电视网络到TCP/IP网络的转换。这种改造必须适应未来网络发展的趋势，即高带宽、移动化和广覆盖。从目前的发展趋势来看，WIFI作为一种高带宽和可集中管理的接入方式，是未来互联网接入的重要手段，也是作为家庭有线接入的重要补充， WIFI更为重要的特点是面向全终端，任何时间任何地点都可以使用。

根据国家无委会相关的法规已经批准将2.4G和5.8G用于无线业务接入，这也为互联网接入业务、互联网数据传送增值业务和国内IP电话业务提供了更多的接入选择。因此从技术和政策来说都不存在任何问题。

另一方面，根据工信息部批文目前南京有线具备从事基于有线电视网络的互联网业务资质。因此南京有线可以充分利用现有网络采用多样的接入手段将互联网用接入到有线电视网络中，通过与运营商的骨干网互联来开展国际互联。

3 技术实现

TCP/IP协议栈作为internet互联网的基础，由网络层的IP协议和传输层的TCP协议组成。TCP/IP定义了电子设备如何连入因特网，以及数据如何在它们之间传输的标准。协议采用了5层的层级结构，每一层都使用它的下一层所提供的网络来完成自己的需求。而南京广电有线电视是基于Docsis协议，因此广电要提供互联接入业务首先要做的是如何将TCP/IP协议栈和Docsis协议栈相互映射。

从下图1可以看出Docsis协议栈的网络层、传输层和应用层同TCP/IP协议栈的互联网层、传输层和应用层对应。不同的在于底层协议间的映射。TCP/IP的数据链路层协议主要有例如以太网、令牌环、HDLC、帧中继、ISDN、ATM、IEEE 802.11、FDDI、PPP；物理层协议主要有以太网、Wi-Fi等。从目前来说互联网无论是链路层协议还是物理层协议主要采用以太网和IEEE 802.11。

因此广电要提供互联网业务DOCSIS协议栈必须完成物理层和链路层到以太网和802.11的转换。Docsis和以太网的协议栈之间转换关系为下图2：

DOCSIS在网络层上完全采用了IP协议，这样可以很好地和支持IP协议的设备兼容。在数据链路层上分了三个子层，逻辑链路控制子层、逻辑链路安全子层和介质访问控制子层。逻辑链路控制子层采用了以太网的标准，DOCSIS制定了逻辑链路安全子层、介质访问控制子层（MAC）的协议。DOCSIS在物理层上定义了两个子层：下行传输汇聚子层，任务是将以太网帧封装成MPEG-2数据帧，在HFC网络上传输；物理媒体子层，定义CM和CMTS的互操作性，制定了物理层传输的TDMA和S-CDMA标准。

因此只要Cable Modem提供了CMCI以太网接口，用户可以在有线电视网络内实现国际互联网有线覆盖。从目前来看，这种方案已经非常成熟，很多大的厂家如MOTO、CISCO和华为等公司都有成熟稳定的产品。

对于无线来说802.11协议定义了物理层和MAC，LLC子层。LLC子层以上和 DOCSIS以Ethernet完全兼容，因此可以很容易的实现两种协议间的转换。

从技术角度来说有两种方案，一种是将802.11协议直接转换为Docsis协议；另一种是先将802.11转换为Ethernet协议，然后将Ethernet转换为Docsis，由于两者都有成熟的产品，因此可以很容易的实现集成。

第4篇：新媒体运营的底层逻辑范文

【关键词】软交换技术；下一代网络NGN；媒体网关；移动3G网络

一、软交换的概念

随着计算机和通信技术的不断发展，通过在一个公共的分组网络中承载话音，数据，图象已经被越来越多的运营商和设备制造商所认同。在这样的业务驱动和网络融合的趋势下，诞生了NGN下一代网络模型，实现在分组网络中，采用分布式网络结构，有效承载话音、数据和多媒体业务。作为NGN网络的核心技术，软交换主要遵循业务、控制和承载相分离的原则，为电信网提供一个不受话务传输模式限制的业务环境。

国际软交换联盟(International Softswitch Consortium)对软交换的定义是“软交换是提供呼叫控制功能的软件实体”，信息产业部电信传输研究所(现通信标准研究所)对软交换的定义是“软交换是网络演进以及下一代分组核心设备之一，它独立于传送网络，主要完成呼叫控制、资源分配、协议处理、路由、认证、计费等主要功能，同时可以向用户提供现有电路交换机所能提供的所有业务，并向第三方提供可编程能力。”目前，我国已完成并颁布了《软交换设备总体技术要求》(YDC003-2001)，明确规范了软交换在网络中的位置，功能要求、业务要求、操作维护和网管要求、协议和接口要求，计费要求和性能指标，并规定了与IP电话及智能网的互通要求等。

二、软交换的体系结构

软交换网络从功能上可以分为业务平面、控制平面、传输平面和接入平面，如图1所示。

1.软交换的网络结构介绍

接入平面：提供各种网络和设备接入到核心骨干网的方式和手段，主要包括信令网关、媒体网关、接入网关等多种接入设备。

传输平面：负责提供各种信令和媒体流传输的通道，网络的核心传输网将是IP分组网络。

控制平面：主要提供呼叫控制、连接控制、协议处理等能力，并为业务平面提供访问底层各种网络资源的开放接口。该平面的主要组成部分是软交换设备。

应用平面：利用底层的各种网络资源为用户提供丰富多样的网络业务。主要包括应用服务器（Application Server）、策略/管理服务器（Policy Server）、AAA服务器(Authority Authentication and Accounting Server)等。其中最主要的功能实体是应用服务器，它是软交换网络体系中业务的执行环境。

2.软交换的主要功能

软交换的主要设计思想是业务与呼叫控制分离、呼叫控制与承载分离，各实体之间通过标准的协议进行连接和通信。软交换的功能结构如图2所示。从图中看出，其主要功能包括媒体网关接入、呼叫控制、业务提供、互连互通、计费与网管、地址解析等功能。

图2 软交换功能结构示意图

媒体网关接入功能

媒体网关功能是接入到IP网络的一个端点、网络中继或几个端点的集合，它是分组网络和外部网络之间的接口设备，提供媒体流映射或代码转换的功能。例如，PSTN/ISDNIP中继媒体网关、ATM媒体网关、用户媒体网关和综合接入网关等，支持MGCP协议和H.1248/MEGACO协议来实现资源控制、媒体处理控制、信号与事件处理、连接管理、维护管理、传输和安全等多种复杂的功能。

呼叫控制和处理功能

呼叫控制和处理功能是软交换的重要功能之一，可以说是整个网络的灵魂。它可以为基本业务/多媒体业务呼叫的建立、保持和释放提供控制功能，包括呼叫处理、连接控制、智能呼叫触发检出和资源控制等。支持基本的双方呼叫控制功能和多方呼叫控制功能，多方呼叫控制功能包括多方呼叫的特殊逻辑关系、呼叫成员的加入/退出/隔离/旁听等。

业务提供功能

在网络从电路交换向分组交换的演进过程中，软交换必须能够实现PSTN/ISDN交换机所提供的全部业务，包括基本业务和补充业务，还应该与现有的智能网配合提供智能网业务，也可以与第三方合作，提供多种增值业务和智能业务。

互连互通功能

下一代网络并不是一个孤立的网络，尤其是在现有网络向下一代网络的发展演进中，不可避免地要实现与现有网络的协同工作、互连互通、平滑演进。例如，可以通过信令网关实现分组网与现有7号信令网的互通；可以通过信令网关与现有智能网互通，为用户提供多种智能业务；可以采用H.323协议实现与现有H.323体系的IP电话网的互通；可以采用SIP协议实现与未来SIP网络体系的互通；可以采用SIP或BICC协议与其他软交换设备互联；还可以提供IP网内H.248终端、SIP终端和MGCP终端之间的互通。

协议功能

软交换是一个开放的、多协议的实体，因此必须采用各种标准协议与各种媒体网关、应用服务器、终端和网络进行通信，最大限度地保护用户投资并充分发挥现有通信网络的作用。这些协议包括H.323、SIP、H.248、MGCP、SIGTRAN、RTP、INAP等。

软交换除了完成以上主要功能之外，还有资源管理功能、计费功能、认证与授权功能、地址解析功能、话音处理功能等。

3.软交换的主要协议

由于软交换是一个开放的、多协议的实体，必须采用标准协议与各种媒体网关、终端与网络进行通信。下一代网络中软交换设备涉及的几个主要协议有H.323、MGCP/H.248、SIP、BICC等。

H.323协议

H.323是一个伞状协议，它描述了在一个基于分组的交换网络上进行多媒体通信的系统的整体结构和操作。H.323建议对呼叫控制、多媒体管理、带宽管理以及LAN和其他网络的接口都进行了详细的规范说明。采用H.323建议，各个不同厂商的多媒体产品和应用可以进行相互操作，用户不必考虑其兼容性问题。该建议为商业、个人用户基于LAN、MAN的多媒体产品协同开发奠定了基础。它是ITU-T为了在无服务质量保证的IP网上的可视电话系统和设备进行多媒体通信所建议的协议集，包括点到点通信和多点会议。H.323包括如下几个部分的协议：H.225.0，Q.931，H.245RTP/RTCP。这套建议的主体目前已基本稳定，一些基本框架已被广泛采用，ITU-T还在不断地对协议的扩展应用进行研究。

软交换与媒体网关接口协议MGCP/H.248

MGCP协议是简单网关控制协议(SGCP)和IP设备控制(IPDC)协议合并的结果，是H.323网关分解的产物，基于主从工作模式。H.248协议使语音、传真和多媒体信号在公共电话交换网与新兴IP网络之间进行交换成为可能。与MGCP相比，H.248可以支持更多类型的接入技术并支持终端的移动性，比MGCP所允许的规模更大，并且H.248协议通过增加许多Package的定义来对协议的功能进行扩展，因而，H.248比MGCP更具灵活性，已逐渐取代MGCP发展为媒体网关控制协议的标准。

软交换间的接口协议SIP协议

SIP用于实现会话(session)的发起、建立和释放，并支持单播、组播和移动性。它以Internet协议（HTTP）为基础，遵循Internet的设计原则，所以很容易增加新业务，扩展协议，而不会引起互操作问题。SIP协议简单，是模块式，不受基础协议与结构的限制。在软交换系统中，SIP协议主要应用于软交换与SIP终端之间，软交换与软交换之间，也可用于软交换和应用服务器之间，提供基于SIP实现的增值业务。国际软交换联盟和一些组织提倡SIP，认为它虽没有H.323那样功能强大，但对运营者来说，比较容易实施，不少运营者和制造商从H.323转移到SIP。而全网采用SIP协议的大型电信网络目前尚不成熟。3GPP已经决定在SIP协议的基础上建立全IP网络，并要求未来3G终端支持SIP。

呼叫控制BICC协议

传统网络呼叫信令协议和承载的信令协议都是综合在一起，新的信令技术需要将呼叫控制和承载连接控制分开，以适应网络发展的要求和支持不断出现的新业务；另外骨干宽带传送网(ATM/IP)的出现，希望现有网络能够采用与网络基础的承载传送技术无关的呼叫控制信令协议。ITU-T提出了与承载无关的呼叫控制(BICC)，BICC支持独立于承载和信令消息的传送技术而支持窄带ISDN业务，ISUP消息同时携载呼叫控制和承载控制信息，用电路标识码(CIC)标识物理承载电路，CIC是指TDM的电路，而BICC可以与任何承载互操作，例如ATM、IP以及TDM。

三、软交换应用故障案例分析

案例：LAN Switch故障导致端局呼叫接续困难的故障处理

故障现象

深圳某软交换MSC-Server所覆盖范围内的用户出现主叫难打出难打入现象，PLLDP值仅为8%。

告警信息

MSC-Server：

*** ALARM 021 O2/APZ

SCTP NETWORK STATUS CHANGE

原因分析

1.状况描述：

深圳某MSC-Server在几乎无任何征兆的情况下，出现用户难打进打出的现象，PLLDP值仅为8%。

在检查告警及各参数状态时，未发现有A级告警。

2.故障原因分析：

拨测发现难以打通电话的两个BSC为对应同一MGW。

MSC Server上用指令EREPP查询，发现event 1025、1030频繁出现，逐定位故障原因为MSC->MGW->BSC的信令传送存在不断闪断的情况。

在Lan Switch上通过镜像端口抓取IP包的方式，发现从LanSwitch上出来的部分IP包存在异常情况。至此将故障锁定在Lan Switch上，原因为Lan Switch频繁发错误包，并在MGW积累，导致在MGW上Mc信令拥塞，尽而下挂的两个发生BSC限呼。

处理步骤

1.对BSC作LARGE RESTART，SYREI:RANK=LARGE，EXPL=OTHER，在短暂恢复15分钟后，故障重现。

2.对MGW做WARM RESTART，话务逐步恢复。

3.将故障Lan Switch的线路拔出，从而将Mc口链路进行倒换。

4.更换故障Lan Switch。

故障总结

软交换端局的故障定位较传统复杂，需要考虑MSC Server、MGW、IP承载网等设备。此次故障在定位时，我们也主要考虑到主设备方面的原因，通过逐步分析在定位在IP设备。

在本次故障定位时没有重视O2等低级别告警而走了一些歪路，下次故障定位时应该抓住各个告警，对系统的软件错误，event等要仔细分析，不遗漏任何潜在的痕迹。

四、结束语

第5篇：新媒体运营的底层逻辑范文

IPTV系统与终端互通中间件封装了特定IPTV应用的核心业务逻辑，屏蔽了系统底层软硬件资源的复杂性和差异性，并通过更高层的标准API接口支持业务领域应用程序的快速开发，同时保证IPTV系统业务能力的开放性和可扩展性。

当前，虽然IPTV可以提供直播、点播、时移等基本视频业务和一定数量的增值业务，但整个产业仍在呼唤具备很强竞争优势的差异化和杀手级业务。IPTV系统的业务能力正在深入发展中，如最新涌现的视频汇聚、视频关联业务等。此外，IPTV系统的商业模式也正在发展探索中。可以预见的是，第三方面业务提供商、业务开发商和应用软件提供商将在产业链中占有越来越重要的角色。

因此，IPTV业务能力和商务模式的不断发展，对当前机顶盒与系统的互通接口提出明确的需求，即互通接口要和IPTV开放的业务实现技术上的独立；互通接口要支持新业务的发展；互通接口也要能支持新业务的快速部署。

IPTV系统和终端的互通和标准化

目前业界在机顶盒与系统互通的讨论上主要有两种主流的方案。一种是基于信令协议的互通，另一种是基于中间件的互通。

基于信令互通模式需要事先确定好IPTV所要支持的全部业务，然后对每个业务的实现在终端和系统间约定精确到比特的信令协议来实现。如果增加任何业务或修改某个业务，系统和终端双方都需要重新定义接口协议，工作量相对繁重而冗长。这种模式对于电话这样的单一业务是非常适合的，但对于不断有新业务涌现的IPTV，则不适合新业务的引入和快速部署。对于现有的很多有生命力的互动业务，如视频关联，也很难用定义信令的模式来实现互通。此外，考虑到目前国内主要IPTV系统厂家的业务接入方式各有不同，业务方案各有差异，在机顶盒上实现业务的技术手段也各不相同的现状。即使只互通有限的业务，信令互通模式也会面临诸多实现上的困难。

从中间件的发展历程看，中间件产生的原始需求就是为了实现异构系统间的标准化和互通化。比如大家十分熟悉的分布式数据库中间件ODBC(OpenDatabaseConnectivity)，就是为了屏蔽不同数据库间的差异、屏蔽客户端的差异、并实现异构数据库系统间的标准化互通。另外，JAVA虚拟机也是为了屏蔽操作系统差异性、满足异构计算机互通标准化的需要。

考虑到本文以系统和终端互通为主题，IPTV领域的中间件可被概括为如下三类：第一类是系统中间件，位于IPTV系统侧各模块间或IPTV系统服务器与第三方服务器之间，与终端不直接发生交互。例如位于IPTV内容引入头端与第三方业务供应商服务器间的中间件，被用来支持节目和内容的标准化引入。第二类是机顶盒终端内部中间件，位于机顶盒中操作系统和应用程序之间，主要用于协调机顶盒内部模块间的交互，不涉及终端与系统的交互。例如机顶盒内部的“浏览器”和媒体播放器等。当前市场的这类中间件通常是由专门的机顶盒中间件开发商开发。第三类是IPTV系统和终端间互联互通的中间件，位于IPTV系统服务器和机顶盒终端间，主要用于实现系统与终端间业务的互通，亦可起到屏蔽机顶盒底层资源的作用，保证IPTV系统业务可在多种平台机顶盒终端上获得实现。本文主要关注和讨论的是第三类中间件，各机顶盒厂家最为关注的也是这类中间件。

IPTV系统和终端互通中间件的目的就是为了实现异构的终端和系统间的标准化和互联互通。它不仅可将应用程序与底层资源隔离，更重要的是实现系统应用与终端应用之间的交互，保障IPTV具备开放的业务能力。IPTV系统与终端间不仅可以通过该种中间件实现IPTV基本业务，当新业务被引入时，系统平台只需要下发更新后的中间件模块就可以实现业务扩展和更新，终端同样只需要通过下载更新应用程序就可以实现新的业务应用。

基于中间件的IPTV互联互通商业模式

当前中间件互通商业模式主要是由系统厂商直接提供相应的中间件给机顶盒厂商。终端厂商根据系统厂商中间件接口规范开发相应机顶盒底层接口协议，以便系统厂商中间件可被下载到第三方机顶盒平台上运行。系统集成厂商与机顶盒厂商合作，依据机顶盒关联的业务能力模块集成接口中间件，并各自获取相应的知识产权权益。

IPTV业务的更新通过中间件的更新得以实现，中间件可被方便地下载升级，这种便利开放的特性，使得中间件互通模式极具生命力。尽管某些机顶盒厂家担心中间件会被系统厂家垄断。但实际上，运营商通过制定标准的初始化下载协议，统一配置中间件调度服务器和中间件下载服务器，对新入网的机顶盒进行统一的授权管理和中间件下载。由于系统厂商间在接口中间件开发上的关系是自由竞争，与终端厂商的关系是协同合作，运营商也由于引入更多终端厂家而获得议价权，各方的利益被有机平衡，中间件被某个系统厂商垄断的局面不会发生。因此，基于中间件的互通商务模式可以动态平衡产业链各方的利益，对当前产业链的发展起到了和促进的作用。

更进一步，当IPTV发展得更为成熟后，机顶盒厂商、系统厂商还可以联合提供SDK(SoftwareDevelopmentKit)给第三方业务开发商，并各自获得相应知识产权权益。由第三中间件开发商开发专业的中间件软件，并存放在中间件管理服务器中供下载，每次下载均获得相应的知识产权权益。同时，也有专业的业务开发商在标准中间件的接口上开发新的IPTV业务，业务提供商在运营商网络中设置业务注册和管理服务器，对其提供的IPTV业务进行管理和分发，或由运营商代为分发。业务提供商因开发业务获得知识产权权益。运营商对机顶盒的业务框架和业务能力进行统一管理，并对中间件开发商和业务开发商提供的产品进行选择和管理。通过这种模式，产业链各个环节都专注于自身最擅长的业务领域，通过IPTV平台为用户提供专业化，个性化的业务。

UT斯达康奔流IPTV系统

UT斯达康奔流(RollingStream)IPTV系统是业界领先的、开放的、支持多业务、多服务终端的宽带多媒体业务平台，并得到世界范围的大规模商用。奔流是目前国内IPTV商用部署市场份额最大的方案，也是业界唯一超过百万用户商用规模的IPTV整体解决方案。奔流提供目前国内最成熟的基于中间件的互联互通模式，不仅可以集成诸如DRM系统、内容编码器等第三方系统，更可以完美地对接基于各种硬件平台的第三方机顶盒终端。

第6篇：新媒体运营的底层逻辑范文

微信这次低调而不经意地推出“微信电话本”产品再次轻而易举地博取了媒体眼球。主要是因为这一次的行动恐怕真的踩到运营商的底线了——免费电话。

一时间，行业内外的各种评论以“刷屏”态势出现在各大科技媒体头条。有的说《微信电话本来了，虎口再夺食》、有的说《微信电话本来了！颤抖吧！运营商！》、有的说《中国移动宣告短信免费，不过是OTT冲击后的自救》。

总结起来，无非是微信抢了运营商的最大一块奶酪，随时可能颠覆通信业。

在我看来，对于微信与运营商的关系，真的很有必要重新梳理一下，避免再次挑起本不存在的矛盾。

说微信推出“免费通话”是颠覆运营商的行为在我看来是站不住脚的。这种咄咄的解读一是造成对微信的“捧杀”，捧得越高摔得越惨(后文会分析原因)；二是对运营商的“诋毁”，运营商没那么脆弱说颠覆就颠覆了。

从微信诞生之日起，这款明星级的应用就被披上了“PK运营商”的战衣，无论对短彩信业务的替代，还是对话音价值造成的潜在伤害，微信似乎天生就是运营商的敌人。2013年2月底，坊间一则关于电信运营商要向微信收费的传闻引爆了两者长期积累的矛盾，引发了令人瞩目的行业震荡。

我不知道是媒体推手还是什么别的原因，运营商与腾讯之间的关系似乎突然变得紧张起来。

我却坚持认为：微信与运营商之间从来都不是“冰与火”、“水与土”样的对立关系，相反两者更多的是相互依存、合作共赢的关系，正所谓“大家好才是真的好”。而这个观点也得到不少运营商和腾讯内部工作人士的认同。

下面，我就具体谈谈微信与运营商合作的N种可能。

一、网络层面：部署PCC将为微信等产品提供差异化的QoS保障

此次微信推出电话本应用的杀手级功能是“高清免费电话”，经笔者多次实测，尽管话音质量确实非常优秀，但在通话接续等方面的使用感知并不算好，甚至有些糟糕。(这也是为什么我说媒体的捧杀会害了微信电话本的原因，用户抱着很高的期望去体验，最后发现使用感知不好，恐怕很难再次启动了)那么问题来了，如何才能保证同等条件下的微信用户使用感知呢？那就要依靠运营商的智能管道了。

作为运营商构建智能管道的主要技术，PCC可以实现网络承载与控制的有机分离，让运营商的管道能够做到“用户可识别、业务可区分、质量可控制、网络可管理。”通过网络资源与计费策略控制，为用户提供差异化的服务质量及灵活的计费策略。

比如，有些用户对移动上网提出更高质量的要求，运营商可以针对此类用户制定专门的网络服务质量方案；再比如，有些用户对微信等业务有较高的需求，运营商可以实施基于业务的优先级策略，为其量身定制适合微信的流量服务，使得他们享受到更好的业务体验。

总之，运营商可以通过部署PCC等智能管道技术为用户提供差异化的服务，改善微信等应用的用户感知。

二、资源层面：运营商的码号认证体系将为微信提供更值得信赖的用户关系体系

用过微信电话本的人肯定知道，想要拨打“免费电话”，必须要先与手机号进行绑定。而就今天的实际使用体验来说，在获得短信验证码这个步骤，笔者以及身边的不少朋友均存在“收不到验证码”、“网络不可用”、“注册超时”等提示。据腾讯内部人士解释，这是由于微信电话本的系统尚不稳定，因此在码号绑定环节出现了不少bug。

然而在我看来，这同样可能成为微信与运营商合作的契机。微信电话本之所以要与用户手机号绑定，首先是为了建立可信任的用户关系。这同样也是微信与手机绑定的初衷。作为一款移动端的即时通讯应用，微信完全可以建立自己的独立码号体系，然而在微信起步阶段，就设置了与手机或QQ号绑定的功能，我认为这为微信后期的快速发展是密不可分的。一方面可以帮助微信快速积累相当规模的初始用户，另一方面是基于电话号码的用户关系相对微博等陌生社交软件更值得用户信赖。

这也再次印证我的观点，运营商的底层码号体系由于实名制等关系，更加安全可控，完全可以成为与微信等产品的合作资源。

三、商业层面：微信与运营商合作可共同开发面向个人及政企的蓝海市场

1.个人层面，微信+运营商可推出更加灵活的资费套餐方案

不可否认的是，作为一款移动端的社交软件，微信具备了比运营商的短彩信更加出色的业务体验。这也是造成运营商短彩信收入持续下滑的主要原因。现在推出“免费电话”功能势必将对运营商视若命根的话音业务产生替代呢？是否真如一些业内人士所说的“虎口夺食”呢？我认为是不会的。根据实际测试结果显示，微信电话本通话一分钟产生的单向流量大约是0.33M，也就是说主叫+被叫共计产生流量答曰是0.66M，按照运营商平均流量单价折算，运营商并不吃亏。再加上，基于VoIP技术的“免费通话”功能受制于无线网络环境，无法满足所有场景下的客户需求，最多算是运营商话音业务的一种补充。

但是，无论是对短彩信业务的替代，还是对话音业务的补充，微信在用户通信方面已经可以形成完整的需求解决方案了。

因此，这就为不同用户群体提供了更多的选择。用户可以使用基于流量的微信服务(包含微信电话本)来实现基本的通信需求，同时可以使用更高质、更安全、更可靠的电信级话音业务(未来将是基于IMS的VoLTE业务)。

运营商完全可以为用户提供不同服务等级和容量的微信流量包和话音套餐方案。事实上，中国联通曾在这方面进行过有益的尝试。今后，随着智能管道的进一步完善以及VoLTE全面上线，运营商的业务定制化能力将持续增强。而这，也可称为微信与运营商合作的重要因素之一。

2.政企层面，微信的产品化能力+运营商的电信级服务强强联手开拓政企蓝海

诚然，微信作为一款互联网公司的产品，以其快速迭代的产品更新机制带来了良好的用户体验。不论是微信订阅号、服务号、企业号，还是对京东等商家的资本运作，互联网灵活创新的机制让微信体现出了惊人的产品化能力。

而运营商的机制体制造成了他不可能像微信一样不断去试错创新，但这也未必是坏事。偏向于“稳”的运营商尽管无法快速形成产品化能力，但却可以毫不费力地提供安全可靠的电信级服务。而这本身就是政企机构看重的能力。

那么，当微信的产品化能力遇上运营商的电信级服务，或许可以产生奇妙的化学反应，诞生出兼具创新与稳定的新型政企服务，而这将为两者拓展政企市场奠定良好的基础。

写给微信与运营商的话：莫忘初心

截至发稿时，腾讯控股有限公司公布了2014财年第三季度财报。报告显示，第三季度腾讯总营收为人民币198.08亿元，同比增长28%；净利润为人民币56.57亿元，同比增长46%。

我猜，或许明天还会有更多人继续“挑拨”微信与运营商之间的关系了。你看腾讯的财报蒸蒸日上，运营商的财报却有些“不忍直视”，这不是抢你饭碗是什么……

但我却以为，腾讯是一家互联网公司，主要领域并不是通信。微信作为一款社交软件，无论是消息还是电话服务都只是为了提高用户粘性，而在日益饱和的市场环境下，运营商也在不断强调“存量经营”，在这一点上，两家公司并无根本利益上的冲突，谈不上“抢食”，反过来讲甚至还有些相互依存的意味。过分强调微信与运营商的对立实际上是陷入了某种逻辑陷阱。

第7篇：新媒体运营的底层逻辑范文

关键词:软交换 技术 网络 电力

1 引言

由于科技的进步,企业的竞争,人们的需求促进了通信的发展,为适应各种业务发展的需求,提出了下一代网络的概念。NGN从广义上来说是指可以提供语音、数据及多媒体业务,能够实现网络终端用户之间的业务互通及共享的融合网络。从狭义来讲特指以软交换设备为控制核心,能够实现业务与控制、接入与承载彼此分离,各功能部件之间采用标准的协议互通,兼容各业务网(PSTN、IP网等)技术,提供丰富的用户接入手段,支持标准的业务开发接口,采用统一的分组网络进行传送,能够实现语音、数据和多媒体业务开放的分层体系架构。

2 软交换概念及其网络结构

软交换是提供呼叫控制功能的软件实体,也称作A2gent ,是下一代网络(NGN) 的核心技术,在NGN 分层结构中位于控制层面的位置,是多种逻辑功能实体的集合,能提供综合业务的呼叫控制、连接以及部分业务功能,实现传统程控交换机的“呼叫控制”功能。传统呼叫控制功能必须与业务结合在一起,而软交换与业务无关,因此它提供的呼叫控制功能是各种业务的基本呼叫控制,而将智能尽可能移至外部的业务层。软交换设备是下一代通信网中语音、数据、视频业务呼叫、控制、业务提供的核心设备,也是目前电路交换网向分组网演进的主要设备之一。

其核心是一个采用标准化协议和应用编程接口(API) 的开放体系结构。这就为第三方开发新应用和新业务敞开了大门。软交换体系结构的其他重要特性还包括应用分离( de coupling of applications) 、呼叫控制和承载控制。软交换系统4个功能层,各功能层完全地分离,并利用一些具有开放接口的网络部件去构造各个功能层,实现了开放的分层架构。各层次网络单元通过标准协议互通,可以各自独立演进,具有开放接口协议的网络部件的集合。如图1 所示。

图1 软交换系统结构图

这种网络拓扑结构与现有网络相比具有如下优点:可以使用基于包的承载传送,例如IP、ATM ,克服了TDM网络中容量不足的缺点;具有开放式端点的拓扑结构,既能良好的传送话音,也能支持数据业务;将网络的承载部分与控制部分相分离,允许二者分别演进,有效地打破了单块集成交换的结构;在各单元之间使用开放的接口,允许运营者为其网络的每一部分购买最理想的产品。

3 软交换的主要协议

3.1 H.323 协议

H.323协议标准是ITU T 的Study Group16 在1996 年提出的,并1998 年2 月修订第2 版。该标准是用于包交换网的多媒体通信的标准,用于不支持QOS的网络环境,这些网络构成当前企业的主要计算机环境,包括高速Ethernet、FDDI、令牌环网、ATM 上的TCP/IP和IPX。H.323 基于集中式对等结构,其优点是协议成熟,定义完全,设备的稳定性强,互通性较好,缺点是协议复杂,成本高,不能与No.7集成,不适用于组建大规模网络,且没有拥塞控制机制,服务质量不能得到保证,效率和扩展性较差。

3.2 SIP 协议

SIP(Session Initiation Protoco1) 是IETF 提出的在IP网络上进行多媒体通信的应用层控制协议,采用基于文本格式的C/S的工作方式,由客户机发起请求,服务器进行响应。SIP 独立于低层协议,采用自己的应用层可靠性机制来保证消息的可靠传送,最大的特点是仅需利用已定义的消息头字段,对其进行简单必要的扩充就能很方便地支持各项新业务和智能业务,具有很强的灵活性和扩充性。SIP 协议简单、灵活,很容易增加新业务,扩展性强,具备终端能力检测、在线检测、支持移动性、组播等能力,而且采用文本格式,开发人员容易理解,并被指定为3G的控制协议。其缺点是不够成熟,需与其他协议配合使用,单独应用的范围窄。

3.3 MGCP 协议

MGCP(Media Gateway Control Protocol) 是1998 年年底SGCP 与新的VOIP 协议IPDC 合并而成,由IETF 所提出的。MGCP 针对H.323 在VOIP 应用上的缺点进行了改良,在MGCP中扩充了原本SGCP中Call Agent的功能成为MGC(Media Gateway Cont roller)。在软交换系统中,MGCP协议主要用于软交换和媒体网关或软交换与MGCP终端之间,软交换通过此协议控制媒体网关/MGCP终端上的媒体/控制流的连接、建立和释放。MGCP 协议基于主从结构,因此其解决方案有利于网关的互连,适合构建大规模网络,且可以和No.7信令网关配合工作,能与No.7信令网良好集成,协议具有很好的扩展性。其缺点是MGCP与H.248/MEGACO存在竞争关系,而后者已于2000年年初由IETF和ITU签署认可。

3.4 H248/MEGACO 协议

在MGCP提出之后,IETF 在1999年初便以现有的MGCP为基础制定了MEGACO协议,后来被提交给ITUTSG l6并被采纳,形成了ITUT H.248协议,因而H.248和MEGACO实质上是一样的,是IETF 和ITU T 共同认可的标准协议。在软交换系统中,H.248协议主要用于软交换和媒体网关或软交换与H.248终端之间,软交换通过此协议控制媒体网关/H.248终端上的媒体/ 控制流的连接、建立和释放。

4 软交换系统的主要功能

软交换实际上是多种逻辑功能实体的集合,提供综合业务的呼叫控制、连接以及部分业务功能,是下一代电信网中语音/ 数据/ 视频业务呼叫、控制、业务提供的核心设备,也是目前电路交换网向分组网演进的主要设备之一。其主要设计思想是业务/ 控制与传送/ 接入分离,各实体之间通过标准的协议进行连接和通信。作为新、旧网络融合和关键设备,他必须具有以下功能:

4.1媒体网关接入功能

该功能可以认为是一种适配功能。他可以连接各种媒体网关,如PSTN/ISDN 的IP 中继媒体网关、ATM 媒体网关、用户媒体网关、无线媒体网关、数据媒体网关等,完成H.248协议功能。同时还可以直接与H.323 终端和SIP 客户端终端进行连接,提供相应业务。

4.2呼叫控制功能

呼叫控制功能是软交换的重要功能之一。他完成基本呼叫的建立、维持和释放,所提供的控制功能包括呼叫处理、连接控制、智能呼叫触发检出和资源控制等。

4.3 业务提供功能

由于软交换在网络从电路交换向分组交换演进的过程中起着十分重要的作用, 因此软交换应能够支持PSTN/ ISDN 交换机提供的全部业务,包括基本业务和补充业务;同时还应该可以与现有智能网配合,提供现有智能网提供的业务。

4.4 互联互通功能

目前,存在两种比较流行的IP电话体系结构,一种是ITUT制定的H.323 协议,另一种是IETF 制定的SIP协议标准,2 者是并列的、不可兼容的体系结构,均可以完成呼叫建立、释放、补充业务、能力交换等功能。软交换可以支持多种协议,当然也可以同时支持这两种协议。

5 软交换技术在电力通信系统中的应用

采用软交换技术组建电力通信网可应用纯IP的底层网络,使得底层网络建设和维护成本大大降低。但考虑到保护现有网络投资,部分话音业务仍采用现有TDM 网络承载,利用媒体网关提供的IP语音网关功能无缝连接IP电话、传统电话及话音交换机。

在供电局通信中心设置媒体网关和特征服务器(融合了媒体服务器) ,其他边缘供电所、办公大楼、营业点、变电站等电力生产场所作为远程数据采集系统(主要包括通信调度、数据流、工业监控视频采集) 和接人终端,把语音、数据和采集到的视频信号进行压缩处理后经IP网传输到媒体网关统一管理、分发和资源控制。电力系统IP 专网通过路由器/ 防火墙与Internet相连,媒体网关通过Et与PSTN和移动通信网相连,实现各种业务与公网的互联互通,从而利用公网的多种资源和提供的服务对电力通信专网进行有效的业务补充。由于软交换技术自身的功能及特点,电力系统引入软交换技术,可以解决以下几个方面的问题:

5.1在电力通信信息网中实现网络互通,并能统一不同介质的网络。

电力通信网中的电话网是一种交换网络;同时电力通信网中也存在以IP协议为基础的分组网络( 计算机网络)。软交换可以提供支持多种信令协议的接口,可以实现电话网和计算机网之间的信令互通及不同网关的互操作问题。

电力通信网有光纤、微波、载波等多种传输介质。就形成了光纤网、微波网等不同传输介质的网络形式,以前各网络间只能通过各自的复接及终端设备进行简单的模拟或数据信号转接。若引进了软交换技术,在一台交换服务器上可对多种介质的信息进行交换,各种介质的网络达到了融合互通。在不同介质的网络中传递信息时也省掉了复杂的转换环节,节约资金避免浪费,特别是提高了网络的可靠性, 而且在管理上也极易实现对整个网络的维护。

5.2极易实现新业务

软交换提供了开放式的应用程序接口(API),非常便于提供新业务。这对于满足电力发展过程中对通信网中传输的信息不断提出的新要求,避免重复投资,都大有益处。

5.3 可实现各种业务统计功能

此外,在电力通信网中引入软交换,其应用将不仅限于以上几个方面,由于软交换技术自身的功能及特点,将会产生很多方面有益的影响和作用。

6 结语

软交换技术是促进网络融合、业务整合的主要技术之一,能支持各种网络实体的互通和业务的互操作,适应各种赢利模式,代表网络技术的发展趋势。随着下一代网络的逐步实现,软交换技术将会发展得更加完善。在合适时机引入,必能提高电力行业通信信息水平,为电网提供高质量的服务。

第8篇：新媒体运营的底层逻辑范文

【关键词】NFV IMS SDN

中图分类号：TN03 文献标识码：A 文章编号：1006-1010（2014）-22-0060-05

Research on Virtualization Solution of IMS core Network Functions

PENG Li

（Guangzhou Research Institute of China Telecom Co.， Ltd.， Guangzhou 510630， China）

[Abstract] As network function virtualization （NFV） decouple the software functions and hardware functions of traditional network equipments， it decreases the investment and operating costs to enhance the deployment efficiency of new business. SDN provides a solution to NFV bearer network and ensures the implementation of NFV. In this paper， the solution to NFV of IMS core network is discussed， as well as the networking scheme of the bearer network in the environment of IMS core network visualization based on SDN framework is proposed.

[Key words]NFV IMS SDN

1 引言

网络功能虚拟化（NFV，Network Functions Virtualisation）改变了现有网络运营商构建网络的方法：不再采用专用的网络设备，而是利用IT虚拟化技术在标准的高性能服务器、交换机、存储设备上来实现各类网络节点和用户前端设备的功能。原则上，所有网络节点的功能都可以被虚拟化并在标准的服务器上运行。

软件定义网络（SDN，Software Defined Network）提出了一种新型的网络架构：将1―4层网络的控制平面与数据转发平面进行分离，并提供开放的接口和实现可编程化控制。

多媒体业务统一控制层IMS网络的虚拟化可以提高多媒体业务部署的灵活性并降低成本，但同时也对承载网带来了新的功能需求。SDN架构可以满足该需求，并进一步增强IMS虚拟化的能力。

2 NFV和SDN概述

2.1 NFV体系架构及关键技术

由全球领先的7家电信网络运营商发起成立的ETSI网络功能虚拟化行业规范工作组（ETSI NFV ISG）是目前业界一致认可的NFV相关标准体系研究的领跑者和主要推动者，现已制订和了NFV虚拟化需求、NFV用户案例、NFV体系框架等5个文档。

在NFV架构中，所有的网络功能都是以纯软件的方式运行于统一分配的计算、存储和网络等基础设施之上，软件功能不再和原有的专用硬件平台相捆绑。其体系架构如图1所示：

图1 NFV体系架构

NFV体系架构包括虚拟网络功能（VNFs，Virtualised Network Functions）、NFV基础设施（NFVI，NFV Infrastructure）、NFV管理和业务编排（NFV Management and Orchestration）3个核心工作域，具体如下：

（1）虚拟网络功能（VNFs）：运行在NFVI之上的执行指定网络功能的软件，如IMS网络中的P/I/S-CSCF、HSS。网元节点的功能和状态与它是否虚拟化无关。物理的网络功能和虚拟化的网络功能的能力以及对外的运维接口应该是相同的。一个VNF可以由多个内部组件构成。在该场景下，同一个VNF可以部署在多个虚机上，也可以运行在同一个虚机上。前者每个虚机只运行该VNF的一个组件。

（2）NFV基础设施（NFVI）：包括硬件和软件在内的提供VNFs部署、管理和执行的环境。硬件资源包括通过虚拟化层为VNFs提供处理、存储和连接能力的计算、存储和网络资源。虚拟化层对硬件资源进行了抽象，并把VNF的软件功能和底层的硬件解耦合，从而保证硬件资源与VNFs的无关性。

（3）NFV管理和业务编排：包括业务编排系统、VNF管理系统和NFVI管理系统3部分。其中，业务编排系统负责NFV基础设施、软件资源的编排和管理，并在NFV上提供网络服务;VNF管理系统负责VNF生命周期的管理（如建立、更新、扩展、终结）;NFVI管理系统为VNF提供管理和控制其所需的计算、存储及网络资源的能力。

2.2 SDN体系架构及关键技术

SDN是一种新型的网络架构，其设计理念是将网络的控制平面与数据转发平面进行分离，并实现可编程化控制。ONF、IETF等各大标准组织都根据各自的研究领域和技术观点对SDN的技术进行了研究，并制订相应的标准。虽然各大流派的具体技术方案不尽相同，但所遵循的总体框架和关键技术是基本一致的。

典型的SDN体系架构分为应用层、控制层和基础设施层3部分，具体如图2所示：

图2 SDN体系架构

（1）应用层：通过控制层提供的接口获取网络的控制权，并在其基础上开发各种业务应用，从而实现业务创新。

（2）控制层：是网络智能的集中，负责维护网络的整体状态和数据平面资源的编排，可根据用户不同的需求和全局网络拓扑，灵活动态地为每个用户分配资源。SDN控制器具有网络的全局视图，负责管理整个网络，对下通过标准的协议与基础网络进行通信，对上通过开放接口向应用层提供对网络资源的控制能力。

（3）基础设施层：是硬件设备层，专注于单纯的数据处理和转发。

3 IMS核心网虚拟化方案

IMS网络由业务层、控制层和接入层组成，不同层面之间采用开放的接口协议，在EPC和其他IP承载网上提供基于SIP协议的多媒体会话业务的控制能力及业务提供能力，包括业务层、控制层和接入层在内的IMS网络各个层面的网络设备功能都可以通过虚拟化的方式进行部署及建设。由于篇幅限制，本文将重点针对IMS核心控制层的网络功能虚拟化方案进行讨论。

IMS核心控制层主要完成SIP会话控制、资源分配、协议处理、路由、认证、计费、业务触发等功能，控制层的功能实体包括P-CSCF、I-CSCF、S-CSCF、AGCF、HSS、SLF、MGCF、MGW、BGCF、ENUM/DNS、BAC等。目前这些网络实体都是基于ATCA硬件架构实现，运营商根据预测的业务量进行网络部署。

IMS核心网网元功能虚拟化通过重新设计P/I/S-CSCF、HSS等核心网网元的系统和软件架构，使其可以独立于底层的硬件设备而运行于通用服务器平台之上。运营商在部署IMS网络时不需要购置专用的硬件平台，而是根据业务量的实际需要动态地在云平台上加载、安装、运行P/I/S-CSCF等各核心网网元软件功能模块。IMS虚拟化逻辑架构如图3所示：

图3 IMS虚拟化逻辑架构

IMS虚拟化应提供以下4个基本功能：

（1）IMS虚拟网络功能（IMS VNF）部署的一键完成：根据预定义好的业务模板和脚本，包括P/I/S-CSCF所有IMS核心网元在内的虚拟网络功能可以自动地在云平台上加载安装。

（2）IMS虚拟网络功能（IMS VNF）的自动扩展：虚拟网络功能管理系统自动监测虚拟网络功能KPI运行指标。一旦监测到虚拟网络功能的负荷已经超过了警戒值，虚拟网络功能管理系统则申请计算、存储、网络等资源，并使用预定义好的模板和脚本在新增的虚机上自动安装相关的IMS虚拟网络功能。

（3）IMS虚拟网络功能（IMS VNF）的自动回收：虚拟网络功能管理系统自动监测虚拟网络功能KPI运行指标。一旦监测到虚拟网络功能的负荷已经低于最低值，虚拟网络功能管理系统则通知虚拟网络功能准备关闭。在虚拟网络功能关闭准备工作完成后，虚拟网络功能管理系统会收回分配的资源。

（4）IMS虚拟网络功能（IMS VNF）的自动容灾保护：当运行虚拟网络功能实例的虚机发生故障时，一个新的安装有同样虚拟网络功能实例的虚机会被自动创建，以接管发生故障的虚机承担的呼叫。

4 基于SDN架构的虚拟化IMS核心网承

载网解决方案

4.1 IMS核心网虚拟化对承载网络的需求

IMS系统是基于IP承载的应用系统，因此IMS网络的核心网网元是通过IP网络进行连接的。在现有的IMS网络部署中，网络容量、网络路由组织都是在网络建设过程中根据预测的业务量和业务流量流向配置及设计的，每个网元对IP承载网带宽、端口数、IP地址的需求都是明确和固定不变的。IP承载网只需根据IMS系统提出的具体带宽、端口和路由需求提供网络连接。除非有IMS网络设备退网，否则其承载网方案都是无需变化的。

IMS网元功能虚拟化后，各个网元功能以软件的形式按用户容量变化的实际需要自动在通用硬件平台上加载或卸载。IMS核心网网元功能间的信令流程以及提供IMS业务的终端和核心网网元功能间的信令、业务流程仍保持不变。也就是说，网元功能虚拟化后各网元功能和终端仍是基于IP网络进行承载的，只是承载的需求发生了根本性的变化。IMS核心网网络功能虚拟化后对承载网络的需求如下：

（1）IMS核心网网络功能虚拟化后，各网元功能将部署于运营商的网络功能虚拟基础设施（NFVI）中以共享计算、网络和存储资源。因此，IMS虚拟化网络功能会同时部署在多个数据中心里，需实现数据中心内部和数据中心之间的网络连接。

（2）P/I/S-CSCF、MGCF等IMS网元是用SIP URI进行标识的，通过DNS查询到下一跳网元的网元标识对应的IP地址进行网元间的逐跳SIP消息路由及寻址。当一键完成IMS虚拟网络功能的自动部署时，需要给每个网元分配IP地址和SIP URI，并在IMS域内的DNS中自动生成各个网元IP地址和SIP URI的对应解析关系。

（3）当网络根据业务量的变化自动扩展IMS虚拟网络功能时，部分IMS用户会被调整接入到新的网元中，这要求除了在IMS域内的DNS中自动生成各个新生成网元的IP地址和SIP URI的对应解析关系外，还需在公网的DNS中自动加入新增用户接入网元P-CSCF或BAC的IP地址和域名对应解析关系。

（4）当网络根据业务量的变化自动回收IMS虚拟网络功能时，部分IMS用户会被调整接入到别的网元中，这要求需在IMS域内的DNS中自动删除被回收网元的IP地址和SIP URI的对应解析关系，同时在公网的DNS中自动删除被回收接入网元P-CSCF或BAC的IP地址和域名对应解析关系，并新增被调整用户的SIP URI和其接入网元的IP地址的对应关系。

（5）当IMS虚拟网络功能进行自动容灾保护时，部分IMS用户的业务会被新的网元接管，这要求在IMS域内的DNS中将发生故障网元的SIP URI对应的IP地址更新为新生成网元的IP地址。如果是接入网元发生容灾倒换，则还需在公网的DNS中将被接管用户的SIP URI对应的IP地址改为新生成网元的IP地址。

4.2 IMS核心网虚拟化承载网组网方案

IMS核心网的各个虚拟化网络功能具备自动部署、自动扩展、自动回收和容灾保护的特性，这要求虚拟化网络功能所在数据中心的承载网支持自动为IMS虚拟化网络功能建立虚拟专网、分配网络资源和IP地址、提供有QoS保证的专用网络通道，而且该虚拟专网还应能跨域跨数据中心。

目前数据中心内部和跨数据中心的组网方案都不具备上述能力，因此需要重新考虑数据中心的承载网方案。

SDN体系架构将网络的控制面和转发面相分离，实现了对网络资源的自动管理，可以很好地实现上述功能。基于SDN架构的组网方案如图4所示：

该架构把物理网络资源虚拟化，形成一个虚拟网络。虚拟网络以业务的方式开放给IMS虚拟化网络功能，负责承载业务流，从而屏蔽掉了实际的物理网络。数据中心域内SDN控制器负责管理域内的交换机、路由器等物理节点设备，并通过北向API把物理网络的相关信息传送给虚拟基础设施管理系统。虚拟基础设施管理系统再根据收集到的物理网络拓扑信息，整理出整个虚拟网络的网络拓扑和状态，对虚拟网络的网络资源进行管理，并将相关信息开放给虚拟网络功能管理系统和业务编排系统。

IMS核心网虚拟化包括自动部署、自动扩展、自动回收和容灾保护4个基本应用场景，由于篇幅有限，本文仅针对自动部署和自动回收这2种场景进行说明。自动扩展场景可参考自动部署场景，容灾保护场景则参考自动扩展和回收场景。

（1）IMS虚拟网络功能（IMS VNF）部署的一键完成：虚拟网络功能管理系统把部署IMS虚拟网络功能对计算、存储和网络等资源的需求提交给虚拟基础设施管理系统。虚拟基础设施管理系统收到网络资源需求时，根据虚拟网络的网络资源使用情况为IMS虚拟网络功能建立专用的VPN，并为相关的网络功能分配IP地址。虚拟基础设施管理系统将相关的路由策略通过SDN控制器下发给涉及到的交换机和路由器，并将资源的分配情况反馈给虚拟网络功能管理系统。虚拟网络功能管理系统根据分配到的资源生成P/S/I-CSCF等IMS虚拟网络功能，同时在DNS中添加各个网元IP地址和SIP URI的对应解析关系。

（2）IMS虚拟网络功能（IMS VNF）的自动回收：待被回收的IMS虚拟网络功能关闭后，虚拟网络功能管理系统把可回收的计算、存储和网络资源需求提交给虚拟基础设施管理系统，同时在DNS中删去回收网元IP地址和SIP URI的对应解析关系。虚拟基础设施管理系统收到回收网络资源请求时，根据虚拟专网的网络资源使用情况回收相对应的网络资源和IP地址，并将修改后的路由策略通过SDN控制器下发给交换机和路由器。

5 结束语

NFV和SDN作为解决现有网络存在的网络不能感知应用、无法实时灵活部署业务、无法共享基础设施资源、运营成本高等问题的新的体系架构，得到了业界的一致认可，是未来网络发展的方向。虽然近年来NFV和SDN技术发展十分迅速，但仍处于发展初期，ONF/IETF/ETSI/OpenSource的大部分技术方案离规模部署还需要进一步的细化和验证。

参考文献：

[1] NFV ETSI ISG. ETSI GS NFV 004 V1.1.1-2013 Network Functions Virtualisation （NFV）： Virtualisation Requirements[S]. Sophia Antipolis： ETSI， 2013.

[2] NFV ETSI ISG. ETSI GS NFV 001 V1.1.1-2013 Network Functions Virtualisation （NFV）： Use Cases[S]. Sophia Antipolis： ETSI， 2013.

[3] NFV ETSI ISG. ETSI GS NFV 002 V1.1.1-2013 Network Functions Virtualisation （NFV）： Architectural Framework[S]. Sophia Antipolis： ETSI， 2013.

第9篇：新媒体运营的底层逻辑范文

关键词：Web；协作翻译；SSH架构；vSphere

引言

随着翻译事业的蓬勃发展，翻译规模不断扩大，翻译数量和翻译类别逐渐增加，各类语言翻译的数据量和信息量成倍甚至数十倍增长，给以个人为中心的传统翻译工作带来巨大压力。机器翻译在半个世纪前就已进入人们的视线，但是机器缺乏人类所独有的处理社会知识能力，因此机器翻译所输出的译文质量远不如人译。为了适应新时代网络迅猛发展要求，推动翻译模式不断创新，开发基于Web的协作翻译系统是提高翻译工作效率、保证翻译工作规范化的必由之路，对探索协作翻译新模式具有十分重要的现实意义。

1基于Web的协作翻译模式构建

1．1协作翻译内涵协作翻译模式对提高翻译工作效率、保证翻译工作质量具有积极作用，是解决翻译工作量大、翻译周期短的重要途径［1］。许多翻译机构都非常重视协作翻译模式的应用。协作翻译模式主要用于翻译机构中的译者协作翻译，在基于Internet的跨区域翻译中没有得到很好应用，主要原因在于缺少一个适合的平台，而目前正在设计开发的协作翻译系统为译者跨区域协作翻译提供了一个新途径。1．2基于Web的协作翻译模式构建基于Web的协作翻译活动只需一网的计算机就能保证翻译工作顺利开展。协作能创造出一种比单个工作量简单累加更大的效果，实现协同效应。协作的优点是可以充分有效地利用组织资源，缩短工作时间，便于集中力量在短时间内完成个人难以完成的任务。（1）协作翻译平台构建。构建协作平台是为了充分利用组织资源实现共同目标。在团队协作翻译过程中，有创意的观点和翻译方法常会出人意料地出现。为了使协作翻译平台发挥积极作用，有效促进译者之间的协作与交流，需要构建一个便捷并具有统一规范的网络协作翻译环境。在协作翻译平台上，译者可以创建各自独立的翻译工作室，再邀请译者根据实际需求加入到各自的翻译工作室，一个译者可以隶属于多个翻译工作室。这样，译者之间共同构建了协作翻译环境，在协作翻译活动开展过程中，译者也可以参与到对方的翻译活动中，整个翻译活动是同步、动态、开放的过程。协作翻译平台成员关系如图1所示。（2）创建独立翻译工作室。为了方便译者协作翻译，需要在协作翻译平台中创建独立的翻译工作室，最恰当的方法是协作小组发起人申请创建翻译工作室，根据翻译需求邀请译者加入。组建协作翻译小组的过程类似于腾讯QQ群功能，比如：申请创建一个英汉科技类翻译协作小组，小组发起人在系统中申请建立翻译工作室，有一个唯一的标识名和该工作室的详细说明，翻译小组发起人可根据需求邀请熟悉的译者加入该协作小组。翻译小组发起人也可在平台中邀请世界各地的翻译工作者加入。（3）以任务驱动开展协作翻译。一个协作翻译小组中有多个小组负责人。开始阶段，翻译小组负责人选择翻译任务，对需要翻译的任务进行分析，决定该翻译任务适合多少人完成、翻译工作的周期有多长、协作翻译过程中的约定用语和注意事项等。然后，通过协作翻译平台邀请组内译者加入到该翻译任务中，译者可根据情况决定是否加入该翻译任务。小组负责人根据翻译小组人员水平设置翻译任务，使每个成员都能轻松完成任务。在翻译过程中，译者可随时查看小组其他成员的翻译进度和翻译内容，发现其他译者翻译错误并进行提示和标注，翻译过程如果出现异议可通过协作翻译平台相互讨论。随着翻译工作的层层深入，小组成员间的协作逐步融洽，小组负责人应适时关注翻译工作完成情况，使整个翻译工作不脱离预定轨迹。（4）成员互评引领翻译活动。翻译工作在平台上进行，每个译者的译文在网上同步，和其他成员共享，翻译组成员在自己翻译的同时可看到其他成员的译文。此时，翻译组成员对彼此之间的译文并不是简单评判，而是根据每个成员的翻译特点，针对不同译文给出建设性意见。协作翻译小组可最大化地发挥每个成员的能动性，与翻译团体共享劳动成果，使每个译者都得到关注，以此挖掘最大潜能，提高译者翻译的信心和积极性。（5）互评和验收分发校验相结合。在基于Web的协作翻译平台上，协作小组的翻译活动公开、透明。翻译内容的一致性对翻译活动来说至关重要，在协作翻译平台会将翻译过程进行统一规格描述，译者可以在翻译过程中查看其他译者译文，可以互评交流。通过浏览其他译者的译文及评价，及时回顾和总结，使互评过程在不知不觉中成为反思过程。验收环节的分发校验也是整个翻译过程必不可少的。为了保证译文的准确性和一致性，协作翻译采用分发校验方式来完成。协作小组成员提交完译文，系统会自动将译文随机分发给协作小组成员进行校验，校验完成后由小组负责人统一归档整理。翻译过程中的互评和验收分发校验相结合，使多人协作翻译在提高效率的同时保证翻译质量。

2基于Web的协作翻译系统设计

2．1系统设计原则协作翻译系统可利用校园网作为平台，将Web服务器与数据库技术相结合，把协作翻译模式中需要的信息转换成数据，由专业的管理人员对系统进行监督和管理，译者可以登录系统组建自己的翻译协作工作室进行协作翻译活动［2］。在基于Web的协作翻译系统中，协作翻译小组的建立、构成及译者之间的协作会随着需求而发生变化，在系统设计中要以协作翻译过程作为数据流程依据，以翻译人员管理权限辅助管理。2．2系统结构设计协作翻译系统采用以云操作系统VMwarevSphere为核心的云计算基础架构，支持在线翻译。大规模的在线翻译活动对服务器来说是一个很大的负担，增加了硬件设备的投入。利用vSphere虚拟化平台，可使协作翻译系统在现有设备的基础上具备快速响应能力和高稳定性。vSphere虚拟化平台通过将系统的应用与底层硬件分离，使服务器工作负载均衡［3］。协作翻译系统结构如图2所示。VMwarevSphere使用虚拟化技术汇总多个系统间的基础物理硬件资源，同时为数据中心提供大量虚拟资源。如图2所示，协作翻译系统是构建在云平台之上的，VM－warevSphere云操作系统可无缝和动态管理大型基础架构（如：CPU、存储器和网络）。用户使用Web浏览器访问协作翻译系统，系统通过vCenterServer提供的服务来管理和使用位于虚拟机群的资源，同时还管理复杂的数据中心。vSphereWebAccess用于解析虚拟机的物理位置，并将Web浏览器重定向至虚拟机。协作翻译系统需要强大的运算能力来支撑在线翻译活动。早期的单服务器模式无法满足该需求，大量的并发访问造成服务器负载及稳定性下降。以虚拟技术为基础将协作翻译系统构建在云平台上，通过云操作系统对服务器资源进行整合和统一管理，在节约计算机资源的同时还保证了系统安全稳定运行。2．3系统开发关键技术协作翻译系统采用J2EE轻量级SSH框架技术，即Struts、Hibernate和Spring的框架组合，SSH框架结构如图3所示。典型SSH框架分为表现层、业务逻辑层和持久层，三层体系将业务规则、数据访问及合法性校验等工作放在中间层处理。协作翻译系统中译者不需要直接与数据库交互，而是通过表现层与中间层建立连接，再由中间层与数据库交互。系统采用Oracle数据库。（1）表示层。表示层由Struts实现。它是三层架构的最外层，负责用户和系统的交互，系统接受用户请求并收集用户提交的信息，通过控制器把相应的请求转发到对应的Action中，并在Action中调用业务逻辑，进行业务逻辑处理，然后将相应结果返回给用户［4］。用户提交的表单数据使用ActionForm组件进行封装。协作翻译系统使用Struts2技术开发，它提供了更强大、更易用的输入检验功能，支持更多的视图技术，并整合了Ajax技术。图3SSH框架结构表示层中，通过开发的多媒体编辑器可实现汉语、英语、日语、俄语等多国语言的在线可视化输入、编辑。此外，在编辑器中集成了自主开发的翻译原文分句、分行、分段排版工具，保证译者选择适合的翻译方式。该编辑器主要应用于在线协作翻译和协作校对交互模块，对协作翻译活动提供支持。系统还开发了即时通讯工具，译者在翻译和校对过程中可以与小组成员同步交流，提高了协作翻译效果。（2）业务逻辑层。业务逻辑层由Spring实现，它是系统中间件Spring框架的核心，采取控制翻转IoC（Inver－sionofControl）依赖注入DI（DependenceInjection）机制。通过读取配置文件，IoC将业务逻辑的各个模块实现依赖注入到实际调用业务逻辑的动作模块中。DI容器在运行期间动态地将依赖关系（如构造参数、构造对象或接口）注入到组件中。Spring框架使用bean属性进行反转控制，在bean．xml文件中配置相应的属性就可以将bean放入Spring容器中，使得bean成为业务逻辑层的一个组件。比如在线协作翻译模块，只需配置bean属性，创建继承Spring提供的HibernateDao类DAO对象，然后复写其中关于CRUD方法，就可以完成业务逻辑组件的加载，使其纳入Spring容器管理。（3）持久层。持久层由Hibernate实现，作为ORM（对象／关系映射）框架，它是目前最流行的对象持久化技术。Hibernate将面向对象编程过程中的数据对象通过映射对应到数据库相关表，并将相关数据存储到数据表中。Hibernate通过对JDBC的封装，向程序员屏蔽底层的数据库操作，底层数据库的改变只需更改初始化配置文件（hibernate．cfg．xml或hibernate．properties）即可。通过配制数据库的连接属性，相关插件能自动生成Hibernate增、删、查、改等多种方法［5］。比如即时通讯模块，首先要创建持久化类，然后在进行对象关系映射后使用XML方式配置Hibernate文件。配置主要内容有数据库驱动程序、数据库语言、日志输出等，使用连接池还需要配置连接池大小、连接数等。2．4系统功能协作翻译系统主要完成译者组织管理和在线协作翻译两个主要功能。该系统通过多个功能模块把分布于世界各地的译者有机统一起来，充分发挥协作翻译模式优势，利用协作翻译系统进行在线协作翻译活动。系统功能如图4所示。（1）译者组织管理功能。协作翻译系统有协作翻译小组组织者、协作翻译小组成员和系统管理员3种角色。协作翻译小组组织者的主要任务是申请创建协作小组、成员审核、翻译活动的发起和整个翻译过程的控制管理；协作翻译小组成员在加入到协作小组后接受组织者的邀请参与翻译活动，每位译者可以从属于多个翻译小组；系统管理员负责用户管理、信息管理和系统维护工作。（2）在线协作翻译功能。在线翻译的平台贯穿协作翻译整个流程。翻译活动开始由小组负责人登录工作室上传原文、填写描述信息和翻译周期、选择该任务译者、分发任务，系统通过短信形式通知译者，译者登录系统后翻译工作正式开始。译者通过在线编辑器开始在线翻译，翻译过程中可随时查看小组成员的翻译进度和翻译内容，还可通过即时通讯功能进行讨论。翻译完成后，有两名以上成员提交完成的译文时，系统会自动将译文随机分发给其他成员校验，校验完成后系统会根据原文拆分顺序进行归档整理，小组成员都可以查看到完整的译文。

3基于Web的协作翻译系统应用

协作翻译系统要考虑实施过程中的网络支撑环境和系统应用过程中的常见问题，为跨区域的协作翻译活动提供技术支持。协作翻译系统除译者组织管理和在线协作翻译两大功能外，还包括即时短信通知、多国语言支持、译文的拆分组合管理、译文的同步共享、译者的即时通讯、共享译文的标注管理、译者翻译量统计和数据的自动备份等辅助功能［6］。（1）网络支撑环境。协作翻译系统架构在VMwarevSphere云操作系统之上。vSphere是VMware公司推出新一代数据中心虚拟化套件，提供了虚拟化基础架构的一整套解决方案。vSphere云操作系统使用ESX部署服务器集群，vCenterServer作为ESX以及在其上的虚拟机管理服务器，通过vSphereClient对ESXServer进行管理。vSphere云操作系统自动完成服务器间的辅助均衡，同时使用vLockstep容错技术对虚拟机数据进行备份，使虚拟机上的资源更加安全、有效。（2）即时短信通知。协作翻译系统支持短信通知，以保证译者没有及时查看系统消息时能第一时间收到翻译任务邀请。系统提供两种解决方案：①通过运营商提供的API接口实现即时短信通知，如联通采用的ETOT1009协议转换器，系统开发过程中直接使用ETOTAPI接口。数据传输采用MD5和DES加密，确保信息安全；②通过手机或者GSMmodem连接计算机进行即时短信通知。因第一种方式需要与运营商洽谈，并需要专线与短信网关相连，成本投入较高，所以即时短信通知模块在设计初给出了两种解决方案。（3）多国语言支持。在协作翻译平台上可以多国语言互译。协作翻译系统采用外部语言包技术，即将语言资源存储在外部语言包中，应用程序根据对应的语言标识，通过语言包中的键与值对应，动态更改翻译语言。在协作翻译系统应用过程中，可根据需要加入新的语言包，确保系统扩展性。为支持多国语言，在系统表示层下加入多语言支持层，该层负责管理多语种资源，并处理与数据层的交互。该层负责接收处理来自表示层的数据，根据需求切换语言操作。

4结语