NGN學習筆記6——NGN的業務提供技術

1.NGN業務的基本概念

1）定義：

下一代網絡的根本目標是提供業務，業務能夠被定義爲一種軟件應用，可以向用戶提供有用的、完善的功能。它經過分佈在網絡中的多個計算元素上的軟件組件的交互來實現。業務的用戶能夠是人，也能夠是機器實體。NGN 主要關注融合網絡環境中增值業務的提供。

2）特色：NGN業務的廣泛特徵是業務的無縫接入。

· 多媒體特性明顯：帶寬制約的消失使多媒體業務的提供成爲可能，該特性是下一代網絡業務(NGS)發展最快、最基本的特性。

· 日益完善的開放性：開放的業務開發環境便於專業服務提供商的接入，構成良性循環的NGN價值鏈

· 業務提供個性化

· 虛擬業務逐步發展 (我的身份、聯繫方式虛擬化)

· 業務智能化和融合化

3）分類：

· 根據業務的內容特徵分類

o 交互式通訊業務（實時或非實時）

o 信息或數據業務

o 內容傳送業務，如娛樂或教育

o 輔助和管理業務

· 根據業務的提供方式分類

o 全新的業務

o 用新方式實現的遺留業務

o 融合的業務

2.NGN的業務體系結構

1）傳統智能網簡述：

a）提供業務的基本原理：增長集中的業務控制點，將呼叫控制與業務控制分開

b）體系結構 ：

c）缺陷：

傳統智能網的應用環境是一個封閉的電路交換網，採用垂直業務提供方式。存在缺陷：

· 基於SCP的業務控制體系是一種集中式的控制結構，不適合將來的分佈式網絡環境

· INAP/MAP業務控制協議複雜，業務開發和部署慢

· 相關標準不適合基於IP的融合網絡業務的需求

· 控制系統基於SS7，與業務相幫定，成爲網絡瓶頸

· 業務體系結構封閉，第三方業務提供商接入困難，業務沒法移植

2）NGN業務體系結構分析：

a）整體目標：實現業務的快速有效提供

· 分佈式控制：適應IP網分佈式處理的特色，避免七號信令結構化的缺點，支持位置透明和分佈式計算

· 開放控制：網絡控制接口開放，以支持第三方提供的業務邏輯和進行業務的建立和修改

· 業務提供和網絡運營的分離：加強下一代網絡的竟爭環境，加速增值業務的提供

· 支持融合網絡的業務

· 提供加強的安全和保護機制——開放的基礎

b）業務體系結構模型：

c）一種實現方式：

d）基於軟交換的業務體系結構：

e）基於IMS的業務體系結構

f）主要採用技術概述：

· 分佈式處理技術：支持第三方業務提供商的分佈式結構，如CORBA技術、Web Service技術

· 開放接口技術：通訊網開放控制的關鍵，如Parlay/OSA和JAIN

· 業務驅動技術：驅動事件能夠來自用戶或基於優先狀態機的網絡，觸發點和觸發條件基於業務需求

· 面嚮對象的技術：任何分佈式系統須要採用的基本軟件技術，NGN採用面嚮對象的技術來構建其業務模型和技術體系結構標準

3.NGN的業務生成技術

1）定義：業務生成技術指在NGN中開發新業務（應用）所採用的技術，在應用服務器中實現主要關注如何利用底層網絡能力來開發新業務、如何擴大業務開發者的領域。

2）業務支撐環境：

關鍵：開放性、平臺無關性。

應用服務器：業務支撐環境的主體，是下一代網絡業務的執行環境

業務管理服務器：和應用服務器配合，主要負責業務的生命週期管理、業務的接入和定購、業務和用戶數據的管理，能夠與應用服務器配合存在，也能夠獨立存在。

業務生成環境：以應用服務器提供的各類開放API等爲基礎，提供友好的圖形化界面，提供完備的業務開發環境、仿真測試環境和衝突檢測環境。

3）三類主流的業務生成技術：

a)基於API的業務生成技術：

直接基於API規範開發業務的技術，包括:

· 與協議無關的標準開放的API：如Parlay/OSA API、JAIN API等，任何用標準API編寫的業務均可以在業務執行環境中運行。

· 與協議相關的API：如SIP Servlet API，能夠充分利用協議的特性開發一些新穎的業務

優勢：具備最大的靈活性，是其它業務生成技術的基礎

缺點：複雜，對開發人員要求高

b）基於框架/組件的業務生成技術：

將API封裝成具備必定功能的組件，基於組件搭建更高抽象層次的框架，業務基於框架/組件來開發。

經常使用的組件模型：Microsoft的COM、OMG的CORBA（組件對象模型）、SUN的JavaBeans

優勢：在很大程度上屏蔽了業務實現的細節，適合複雜業務的開發

缺點：框架限制了生成業務的種類和靈活性

c）基於腳本的業務生成技術：

容許開發者使用圖形界面工具生成腳本或手工 編寫腳原本進行業務的開發。已有多種基於XML的腳本開發語言，如IETF的CPL (呼叫處理語言)，JAIN的SCML (業務生成標記語言)，VoiceXML等。

優勢：抽象層次比API高，適合對業務流程較爲了解而編成能力不強的業務開發者。經過限制腳本語言的能力，能夠確保業務邏輯不出錯，提升系統的安全性

缺點：業務生成能力弱，業務種類受限

4.具體技術分析

1）Parlay/OSA API技術

      ParLay協議是ParLay工做組制定、由歐洲電信標準委員會（ETSI）發佈的開放業務接入的應用編程接口（API）標準，是NGN重要的業務接口 應用協議。該協議針對高層應用協議接口，採用面向對象的方法，使用標準建模語言（UML），分別從類（cLass）、方法（method）、參數 （parameter）和狀態模型（state modeL）等方面進行描述，用Microsoft IDL和CORBA IDL描述其全部的操做和消息。ParLay定義了一套開放的、獨立於技術的、可擴展的API，包括框架結構接口、業務接口、公共管理接口等。其中，業務 接口是ParLay接口的核心，又包括呼叫處理業務接口、通用消息業務接口、移動性業務接口、連通性管理業務接口等。
經過ParLay API完成應用服務器和軟交換間的通訊，同時應用服務器提供各類API，實現對現有通訊網絡安全和公開的訪問，爲第三方應用商提供開發和業務接入平臺。 ParLay API可適用於不一樣的通訊網絡，經過對API的不斷擴展，將解決網絡的演進、融合和擴容等方面的一系列問題。

基本思想：經過網關接口向上層應用程序提供底層網絡能力，從而達到屏蔽底層網絡細節的目的。

a）發展歷史：

· 1998年3月，Parlay工做組成立--五家公司：英國電信、Ulticom、微軟、北電、西門子，規範一組開放的、獨立於技術的應用編程接口，向企業或客戶應用提供訪問網絡信息的能力，容許企業或客戶應用在必定範圍內控制網絡能力。

· 1998年12月，Parlay API 1.0發佈

· 2001年2月，Parlay API 3.0發佈

· Parlay、3GPP、ETSI開始合做發佈統一版本：3GPP OSA Rel5 + Parlay API 3.0  ->  Parlay/OSA API，3GPP OSA (開放業務體系結構)以Parlay的早期版本爲基礎，Parlay只提供單純的API，而OSA提供API以及網絡協議與API的映射。

· Parlay與OSA的後續版本：Parlay API 4.0，基本穩定；Parlay X，基於Web Service技術

· 網絡能力在Parlay/OSA體系中體現爲SCF（業務能力特徵），經過Parlay/OSA API，網絡運營商和獨立軟件廠商可以利用現有的網絡資源來建立大量的新應用，爲固網和移動網在業務層面的融合奠基了基礎。

· Parlay/OSA Parlay/OSA融合了 IT和Telcom應用：電信界——具備豐富的網絡能力和IT界 ——具備豐富的應用和開發者

b）體系結構：

· 框架接口：Provides the surround capabilities necessary for the Service Interfaces to be open, secure, resilient and manageable

· 業務接口：Provide the mechanism by which applications can access underlying network capabilities

o 呼叫控制SCF：爲應用創建呼叫路由

o 用戶交互：被應用用來與端用戶進行交互，播放錄音通知或發送短信

o 移動：嚮應用提供用戶的位置信息

o 終端能力：被應用用來獲取終端的能力

o 數據會話控制：提供對數據會話相關事件的管理功能

o 通用消息：被應用用於發送、存儲和接收消息

o 鏈接管理：被企業經營者用於控制網絡傳輸的QoS和其它特性

o 賬戶管理：提供對賬戶信息進行訪問的能力

o 計費：被應用用於對應用的使用進行計費

o 策略管理：用於管理業務提供者提供的策略信息，並控制對策略的訪問

o 在線和可用性管理：能夠方便跨越多個通訊系統的應用和業務的開發

o 彩信多媒體：向網絡發送多媒體消息的能力

c）Parlay/OSA API的接口結構：

· 接口1：客戶應用和框架之間的接口--嚮應用提供訪問網絡能力的基本機制，包括信任和安全管理、業務發現、業務協議管理、完整性管理和通知管理。

· 接口2：客戶應用和SCF之間的接口--向第三方應用提供在該接口上運行的各項業務，如呼叫控制等。

· 接口3：框架與SCF之間的接口--向業務提供註冊和安全管理功能。包括信任和安全管理、業務工廠、業務註冊、業務發現、完整性管理和通知管理。

· 接口4：企業經營者和框架之間的接口--向企業經營者提供管理客戶應用賬戶、客戶業務合同以及業務描述的基本機制。包括信任和安全管理、業務發現和業務訂購

· 接口5：業務提供者和框架之間的接口提供多廠商機制，使得多個業務提供者能夠接入框架。包括信任和安全管理、業務發現和業務註冊

· 接口6：企業經營者和SCF之間的接口向企業經營者提供控制業務提供者網絡流量的能力，如QoS管理、虛擬指派網的鏈接管理等

d）Parlay/OSA 的商業模型

e)Parlay/OSA API的工做過程

· 在應用可以真正開始使用一項具體的業務能力以前，必須通過如下過程：

· 完成業務能力服務器、客戶應用以及企業經營者與框架之間的認證過程

· 業務能力服務器（SCS）向框架註冊業務企業經營者發現並訂購框架中註冊的業務，簽定業務合同，並受權給客戶應用

· 客戶應用發現業務，並簽定業務協議

f）Parlay/OSA網關的通常配置

g）Parlay/OSA API的實現技術及舉例

CORBA實現：

h）3GPP OSA概述

簡述：3GPP（第三代夥伴關係計劃）是一個制定第三代移動通訊系統的技術規範的組織，其目標是和互聯網、固網等多種網絡的融合3GPP將OSA引 入UMTS系統中，做爲快速部署業務的開放體系結構，應用位於OSA體系結構的上層，經過OSA接口和業務能力服務器(SCS)進行聯繫SCS完成從 OSA接口到底層網絡協議(CAP、MAP等)的映射，對應用屏蔽底層網絡的複雜性。

接口規範：

· SA1：OSA的需求，22.127

· SA2：OSA的概念和功能體系結構，23.198

· CN5：OSA的API，29.198，OSA的Web Service接口，29.199，OSA API與移動網絡協議的映射，29.998

OSA API的邏輯結構：

OSA 的物理結構：

OSA中的SCS只是邏輯實體，在規範中並無規定它是不是網絡中的獨立單元。它們能夠分佈在一個或多個物理節點上。SCS能夠做爲網絡中獨立的節 點開發，也能夠集成到核心網絡的節點。有三種結構--SCS做爲獨立節點開發（集中SCS或分佈式SCS）；SCS分佈在不一樣的網絡實體上；混合方式。

SCS 做爲獨立節點開發：

SCS分佈在網絡實體上：

混合結構：

2）JAIN API 技術

a）簡述：

一組基於Java平臺的綜合網絡API，提供了一種跨網絡環境（分組網、無線網、PSTN網等）構建和綜合業務的框架，用於開發和部署業務驅動的網 絡應用和業務。JAIN組織由SUN公司發起，其規範由許多來自JAIN Community的合做夥伴和專家共同制定。JAIN API和Parlay/OSA API設計思想相近，功能上具備互補性，內容上與Parlay相似，特色在於它徹底採用專注的Java語言實現，而且定義了比較完備的訪問各類網絡的網絡 協議API。目前Parlay/JAIN聯合工做組正在進行二者的融合工做。JAIN Community的Java API定義了Parlay API的Java版本，其目的是在Parlay API中增長Java語言的固有優點，使得Parlay API可以在業界獲得普遍的採納。第三方應用開發者能夠在遵循Java 「write once, run anywhere」理念的基礎上搭建網絡應用。JAIN Parlay API由JAIN Parlay Edit Group負責完成。JAIN API的基本思想是定義一系列標準的JavaAPI，經過這些API開發可移植的網絡應用。

b）目標和優點：

· 業務（應用）可攜性：目前業務的開發基於專有接口，不可攜，JAIN將專有接口組織成統一的Java接口，使得應用，與具體的網絡技術無關，從而實現應用的可攜性。

· 網絡融合：目前，應用的呼叫或會話只涉及單一的網絡，JAIN呼叫模型能夠基於綜合的網絡。

· 安全的網絡接入（業務的開放性）：JAIN Parlay接口使得位於網絡以外的不可信應用可以經過特定的安全措施直接訪問綜合網絡的資源。

c）體系結構：

JAIN結構模型自上而下分爲四層

· 網絡層：各種網絡實體。包括傳統電信網的SSP/交換機、移動網的MSC以及IP網的軟交換機等。業務最終由這些網元完成

· 協議層：各種網絡的控制信令。如ISUP，INAP，TCAP，MAP，SIP/H.323/H.248等

· 業務層：各種網絡的業務控制實體。如SCP，移動網的BSC/HLR/VLR/MSC組合系統，以及IP網的應用服務器等。這些實體經過相應的信令協議控制網絡層實體完成所需的業務

· 應用層：JAVA平臺上的具體應用程序。經過JAVA接口調用下面的業務層和協議層功能

d）分層結構：

業務API：業務建立和執行的管理、不可信第三方接入系統的安全性管理。包括負責業務建立的JSCE、負責業務配置和生命期管理的JSLEE和負責第三方接入的框架API

· JSLEE：JAIN Service Logic Execution Environment，業務邏輯執行環境(SLEE)業務或應用的執行環境。如，應用服務器，是一個包含軟件組件的容器。JSLEE是SLEE的 Java版本。是JAIN的核心組件，是通訊應用的邏輯執行環境。

· JSCE：JAIN Service Creation Environment 簡化業務的生成

呼叫控制API：各種基本網絡能力的實現。包括負責基本呼叫控制的JCC和負責在呼叫任意階段調用增值業務的協調和事務管理的JCAT

· JCC：JAIN Call Control API

· JCAT：JAIN Coordination and Transactions 進行進一步的呼叫處理

協議API：實現各種網絡信令協議，這是JAIN的重要特色。已經定義多種協議API，以JAIN SS7 API和JAIN IP API爲例：

SS7和IN網絡存在的問題：底層協議大多采用C等本地語言編寫，協議版本多，而業務多采用Java語言實現，利用Java的面向對象技術和平臺獨 立性，須要在Java業務與協議之間進行適配，那麼JAIN SS7 API在Java業務和C語言網絡協議之間提供了很好的適配工具使底層網絡協議的變化對應用或業務透明。

JAIN SS7 API基於JavaBeans的設計模式（Java接口）來定義其軟件組件。每一個JAIN SS7 API都定義了三種主要的Java軟件組件。

· Stack：對底層的SS7協議棧進行抽象，並提供建立和管理「Provider」的工廠

· Provider：經過專用的IPC機制與SS7協議層交換協議消息，對每個協議的具體實現是特定的，它將通用的API映射成協議的特定實現

· Listener：經過Event Object與提供者組件進行交互。Listener必須向Provider註冊。Listener對各類Provider來講是可攜的

JAIN IP API則是在IP網中能夠經過多種設備和平臺來提供多媒體業務，但經過Java語言實現的業務具備跨平臺和技術獨立的特性。JAIN IP API使Java業務實現者在使用本地協議軟件的同時，能快速提供新的Java應用，定義了多種基於Java的協議APIs：H.32三、MGCP、 SIP、Megaco、。。。

3）SIP Servlet API  技術

a）概述：基於Java的應用組件，由SIP Servlet Container管理，並能執行SIP信令，做爲SIP服務器的Java擴展API，SIP Servlet能夠擴展SIP服務器的功能，控制SIP消息的
處理，從而提供更豐富的業務。Container，又稱爲Servlet Engine，經過提供Servlet功能對SIP服務器進行擴展，提供網絡服務，經過它能夠接收或發送請求或響應Servlet容器包含並管理 Servlet，決定調用哪一個Servlet，以及按照什麼順序調用，對多個請求只需建立一個進程來處理。

b）基本模型：

SIP Servlet容器提供的SIP消息功能包括：分析接收到的SIP消息、將分析後的SIP消息轉發給相應的SIP Servlet、發送SIP Servlet產生的消息給相應的UA、自動生成SIP響應，如 "100 Trying"、自動管理SIP頭部字段。SIP Servlet 處理的SIP消息都被表示爲SipServletRequest 或SipServletResponse對象，接收到的SIP消息首先分析器分析以後，再翻譯成這些對象，而後發送給SIP Servlet 容器。

c）生命週期：

4）Web Service 技術

這裏主要說一說Parlay API與 與Web Service交互的區別：

Parlay Web Service 技術：

Parlay X Web Service業務接口，基於Parlay/OSA API，對一組通訊能力進行進一步抽象的Web業務接口。Parlay X Web業務能力主要由Parlay APIs提供的通訊能力組成，目前定義了14種Web Service業務接口：第三方呼叫、短消息業務、多媒體消息、付費、帳號管理、用戶狀態、終端位置等等。

Parlay Web服務的配置

PARLAY API與PARLAY X Web Services之間是什麼關係？

Parlay API，包含提供各類業務能力的業務能力特徵（SCF）。Parlay應用能夠經過CORBA與Parlay網關交互。應用自己能夠用各類語言（如 Java、VB、XML腳本等）實現，只要確保可以正確調用Parlay網關提供的API的各種方法並可以正確處理相應的響應。

Parlay X Web Services對Parlay API進行了更高層次抽象並對其作了簡化。在大多數狀況下，Parlay X Web Services經過調用Parlay網關資源訪問底層網絡，可是也不排除其直接與底層網絡直接進行交互。與Parlay應用相似，Parlay X應用也能夠用各類編程語言實現，只要可以進行正確的Web Service調用。

從Parlay 4.0版本開始，除了將Parlay UML標準映射到IDL（接口描述語言）外，還映射到了WSDL（Web服務描述語言）。習慣上，把映射到IDL的Parlay標準稱做Parlay API，而把映射到WSDL的Parlay標準稱做Parlay X Web Services。Parlay X Web Services是一組應用接口，可是不提供AAA（認證、受權、記賬）、SLA（服務等級協議）和其餘與環境相關的功能。這些功能應當由Web Service架構來提供。