OSA體系

在了解OSA體系之前，我們必須要知道的幾個詞：

API：Application Program Interface，是一種開放、標準、統一的套用編程接口。它不依賴於業務提供方的解決方法，不依賴於業務的程式語言，不依賴於業務運行的作業系統，也不依賴於業務實現的位置。
SCF：Service Capability Features，業務能力特徵。是一組承載網路的業務能力的抽象化表達。
SCS：Service Capability Servers，業務能力伺服器。用於實現和支持SCF。

下面，我們來看OSA的三層體系架構：

業務層（Application）：主要提供具體套用，其業務套用可以是運營商自己的，也可以是第三方開發的。
框架部分（Framework）：為業務層提供基本運作機制，使業務套用可以利用承載網路的業務能力。框架部分典型的運作機制是以下兩種：
鑒權機制：業務套用使用下層承載網路前，必須與框架部分進行鑒權。
發現機制：鑒權成功後，通過發現機制幫助業務套用找到適合SCS中SCF的業務伺服器。
業務能力伺服器SCS：向業務套用提供SCF。SCS是邏輯的概念，可以分布在不同的物理節點上，如用戶定位SCF、呼叫控制SCF可以在一個物理節點實現，也可以分布在不同的物理節點實現。SCS是網路實體及上層業務之間的橋樑。

工作機制

在體系架構之外，OSA還需要具備一些基本的工作機制，以保障用戶可以正常調用OSA的業務套用及網路運營的安全性。

l 鑒權機制：在業務部署時，業務套用和框架必須相互鑒權。OSA的鑒權模式是端到端的，只有在鑒權後業務套用才能使用SCF。

l 授權機制：用於確定鑒權後的業務套用具有哪些許可權。業務套用在鑒權後就可以被授權，有權力使用某些下層承載網路能力。

l 發現機制：在鑒權後業務套用可以隨時訪問框架的發現機制接口，獲取關於各SCS的信息。

l 制定服務規約：在業務套用和SCS互動前，需要線上制定一些它們之間的服務規約。

l 安全機制：框架需要提供接入控制功能，對調用OSA API的業務套用的數據做接入檢查。

如上所述，OSA充分實現了承載與控制分離、控制與業務分離，為行動網路與固定網路、網際網路的融合提供了極大地便利。