前言：一篇好文章的誕生，需要你不斷地搜集資料、整理思路，本站小編為你收集了豐富的新媒體運營的底層邏輯主題范文，僅供參考，歡迎閱讀并收藏。

第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、企業通信助理等?，F網業務由原有的業務平臺提供業務，同時完成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電話業務?！?/p>

互聯網的基礎是基于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系統的商業模式也正在發展探索中?？梢灶A見的是，第三方面業務提供商、業務開發商和應用軟件提供商將在產業鏈中占有越來越重要的角色。

因此，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.個人層面，微信+運營商可推出更加靈活的資費套餐方案

不可否認的是，作為一款移動端的社交軟件，微信具備了比運營商的短彩信更加出色的業務體驗。這也是造成運營商短彩信收入持續下滑的主要原因?，F在推出“免費電話”功能勢必將對運營商視若命根的話音業務產生替代呢？是否真如一些業內人士所說的“虎口奪食”呢？我認為是不會的。根據實際測試結果顯示，微信電話本通話一分鐘產生的單向流量大約是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體系架構將網絡的控制面和轉發面相分離，實現了對網絡資源的自動管理，可以很好地實現上述功能?；赟DN架構的組網方案如圖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結語