朱 斌，符 剛，朱愛華，李延斌，吳 瓊

（中訊郵電咨詢設計院有限公司 北京 100048）

1 前言

隨著網(wǎng)絡和業(yè)務多年的發(fā)展，運營商用戶數(shù)的增長逐漸進入到一個穩(wěn)定期，運營商本身不能再簡單地依靠單純用戶數(shù)量的增長來獲取企業(yè)的發(fā)展，而需要以用戶為中心來開展業(yè)務，通過給用戶量身訂制的服務來提高用戶的滿意度和忠誠度，減少客戶流失。

隨著新技術的出現(xiàn)，用戶將可以通過不同的方式接入到運營商的網(wǎng)絡中去，而隨著網(wǎng)絡的發(fā)展建設，網(wǎng)絡也將存在電路交換（CS）、分組交換（PS）、IP 多媒體子系統(tǒng)（IMS）等多個核心域共存的情況，必然加劇目前運營商不同業(yè)務的用戶數(shù)據(jù)分散存儲在不同域中的現(xiàn)狀，伴隨著網(wǎng)絡融合的發(fā)展趨勢，用戶、運營商和業(yè)務提供商的融合業(yè)務的順利開展將面臨很大的困難，如何避免數(shù)據(jù)分散的信息孤島現(xiàn)象，有效地集中管理用戶數(shù)據(jù)，以及如何集中部署和維護用戶數(shù)據(jù)庫，成為未來網(wǎng)絡演進和企業(yè)運營的研究重點。

2 標準現(xiàn)狀

由于用戶數(shù)據(jù)融合的重要性，各大標準組織都已陸續(xù)基于各自標準化的需求開展了數(shù)據(jù)融合的研究并進行了相關的標準制定工作，標準組織如3GPP曾先后提出了GUP（generic user profile，統(tǒng)一用戶檔案）、SuM（subscription management，簽約數(shù)據(jù)管理）、CPSF（common profile storage framework，統(tǒng)一數(shù)據(jù)存儲架構）和 UDC（user date converge，用戶數(shù)據(jù)融合）等標準；OMA提出了GSSM（general service subscription management，通用業(yè)務簽約管理）和SuPM（service user profile management，業(yè)務用戶檔案管理）等標準；NGMN提出了數(shù)據(jù)融合的相關概念，但還未定義具體的模型，標準還僅限于研究報告階段，目前還不具備可實施性；ITU-T定義了數(shù)據(jù)存儲的目錄樹數(shù)據(jù)組織結構X.500的標準，定義了 LDAP（lightweight directory access protocol，輕量級目錄訪問協(xié)議）接口協(xié)議。

不同標準組織基于不同的需求開展了不同的研究工作，而目前業(yè)界比較關注的用戶數(shù)據(jù)融合的標準如下。

（1）用戶數(shù)據(jù)融合

UDC概念是3GPP在R9版本引入的，于2008年立項研究，其主要目的是為了解決跨域及跨網(wǎng)元的數(shù)據(jù)融合問題。該標準建議把用戶數(shù)據(jù)統(tǒng)一存儲在一個獨立的用戶數(shù)據(jù)庫（user data repository，UDR）中，其中用戶數(shù)據(jù)包含用戶注冊數(shù)據(jù)、內(nèi)容數(shù)據(jù)、行為數(shù)據(jù)、狀態(tài)數(shù)據(jù)，通過前端（front end，F(xiàn)E）來完成對用戶數(shù)據(jù)的訪問。

在標準進展方面，3GPP SA1工作組制定了UDC的需求，分析需要融合管理的數(shù)據(jù)類型，提供與UDC數(shù)據(jù)類型相關的需求，信息模型和數(shù)據(jù)模型，安全、冗余、擴展性的標準化。SA1的研究工作在2008年完結，后續(xù)CT4繼續(xù)研究UDC的架構及前后端的接口，SA5研究業(yè)務配置模型，目前UDC研究仍在繼續(xù)完善中。

（2）統(tǒng)一用戶檔案

GUP是3GPP定義的一種融合用戶數(shù)據(jù)訪問框架，主要是為了對運營商網(wǎng)絡數(shù)據(jù)提供一個統(tǒng)一界面，它的基本出發(fā)點是以用戶為中心，解決不同網(wǎng)絡和業(yè)務的用戶數(shù)據(jù)的統(tǒng)一訪問問題，為運營商網(wǎng)絡數(shù)據(jù)提供一個單一的接入點，為運營商網(wǎng)絡數(shù)據(jù)提供安全的接入以及提供對用戶數(shù)據(jù)使用的控制機制。GUP于2001年立項研究，3GPP在R8版本定義了GUP的第一階段的業(yè)務需求，目前已經(jīng)完成了階段1、階段2和階段3的標準工作，但是由于該標準的架構籠統(tǒng)，對相應的接口和功能節(jié)點缺少明確的定義，且缺少對運營商實際網(wǎng)絡的考慮，在實際應用起來似乎存在一定的困難，目前GUP的標準化工作處于停滯不前狀態(tài)，各運營商和廠家不是很看好該標準，多數(shù)轉向支持UDC的相關工作。

（3）業(yè)務用戶檔案管理

SuPM由OMA標準組織于2009年立項，希望解決網(wǎng)絡中用戶數(shù)據(jù)分布復雜，不利于業(yè)務的開放、用戶個性化業(yè)務的開展的問題。SuPM的用戶信息主要包括業(yè)務簽約數(shù)據(jù)、用戶的偏好、終端的位置信息、用戶的呈現(xiàn)信息、終端能力等，研究的主要目標是統(tǒng)一用戶模型、統(tǒng)一的接入點、用戶權限的統(tǒng)一管理，為用戶業(yè)務相關的數(shù)據(jù)定義一個統(tǒng)一的數(shù)據(jù)模型，并且為所有用戶業(yè)務相關的數(shù)據(jù)提供一個惟一的中央管理和訪問點，以滿足OMA業(yè)務或引擎的需要，避免不同引擎中用戶數(shù)據(jù)功能性的冗余。但是定義一個統(tǒng)一的業(yè)務數(shù)據(jù)模型比較困難，當前關于OMA SuPM的標準進展緩慢，目前依然處于數(shù)據(jù)收集階段。

從上面的介紹中可以看出，不同標準組織對數(shù)據(jù)融合的理解不同，研究的重點和角度也各異，有的偏向數(shù)據(jù)目錄結構，有的偏向網(wǎng)絡構架，還有的偏向業(yè)務數(shù)據(jù)的研究。目前對用戶數(shù)據(jù)處理的研究比較成熟的是3GPP標準組織的UDC標準，后面重點就UDC的標準化進行研究。

3 UDC關鍵技術

UDC支持分層的架構，該架構將用戶數(shù)據(jù)從應用邏輯中抽離出來，因此用戶數(shù)據(jù)存儲在一個邏輯上惟一的數(shù)據(jù)倉庫中，允許核心網(wǎng)和業(yè)務層實體訪問。訪問的實體被命名為應用前端。圖1所示即為UDC的參考架構。在該參考構架中，UDR是惟一在運營商網(wǎng)絡中的邏輯上獨立的存儲用戶數(shù)據(jù)的功能實體，F(xiàn)E是不存儲用戶數(shù)據(jù)的實體，需要訪問存儲在UDR上的用戶數(shù)據(jù)來獲得信息。

圖1 UDC系統(tǒng)架構

（4）應用前端

該功能實體可以是終端、核心網(wǎng)網(wǎng)元、業(yè)務應用服務器、OSS等。FE僅處理業(yè)務邏輯，本地不永久保存用戶數(shù)據(jù)。

（5）用戶數(shù)據(jù)倉庫

該功能實體作為一個單一的邏輯倉儲，用于存儲融合的用戶數(shù)據(jù)。當前階段UDR考慮融合HSS/HLR/AUC和AS（application server，應用服務器）的用戶數(shù)據(jù)。UDR為不同的應用前端提供了一個惟一的參考點（Ud接口）。UDR同時支持多個應用訪問，且為第三方應用和不可信任的網(wǎng)元提供了訪問控制。

（6）Ud接口

Ud接口位于UDR和應用FE之間，允許不同的FE通過統(tǒng)一的訪問接口創(chuàng)建、讀取、更改或刪除保存在UDR中的用戶數(shù)據(jù)。Ud接口需要支持訂閱通知功能，同時需要支持事務，且所有涉及的操作需要支持ACID屬性，即數(shù)據(jù)的原子性 （atomicity）、一 致性 （consistency）、隔離 性（isolation）和持久性（durability）。

4 用戶數(shù)據(jù)融合現(xiàn)狀和存在問題

傳統(tǒng)HLR面臨著容量小、數(shù)據(jù)獨立、業(yè)務引進難、網(wǎng)絡復雜等問題，從現(xiàn)狀來看，由于傳統(tǒng)HLR的容量較小，單局容量一般不超過百萬數(shù)量級，對于運營商來說，首先帶來的是網(wǎng)絡組網(wǎng)復雜的問題，此外分散的小容量HLR存儲的用戶數(shù)據(jù)相對孤立，不同的用戶數(shù)據(jù)庫之間信令交互需要占用了大量的傳輸資源，對用戶號碼管理方面也造成一定的影響。

而融合數(shù)據(jù)庫采用分離的架構，可以建立相對集中的統(tǒng)一融合用戶數(shù)據(jù)中心，支持統(tǒng)一的數(shù)據(jù)管理和分析，可以幫助運營商發(fā)掘用戶的需求和潛力，實現(xiàn)個性化的業(yè)務部署。目前雖然已經(jīng)有部分廠家擁有UDC的產(chǎn)品，但是受到用戶數(shù)據(jù)融合標準化、用戶數(shù)據(jù)模型制定等因素的制約，融合數(shù)據(jù)庫部署還存在一定的問題。

（1）用戶數(shù)據(jù)倉儲中的數(shù)據(jù)模型

用戶數(shù)據(jù)倉庫是運營商最核心的部分，從標準上來看，目前對信息模型進行了相關的標準化，信息模型分為3類：通用基線信息 模型 （common baseline information model，CBIM）、應用信息模型（application information model，AIM）、專業(yè)信息模型 （specialized information model，SpIM）。目前3GPP還在討論制定CBIM標準，最初是在CBIM模型的標準化上，重點考慮業(yè)務數(shù)據(jù)類、終端用戶類、終端設備類、標識數(shù)據(jù)類等對象類的屬性和關聯(lián)關系。而AIM和SpIM與運營商的業(yè)務更緊密，特別是SpIM是運營商特有的，因此，用戶數(shù)據(jù)模型還需要結合運營商實際的情況來考慮，只有建立了適合運營商本身發(fā)展需求的數(shù)據(jù)模型，才能發(fā)揮出集中數(shù)據(jù)存儲的優(yōu)勢，對于用戶數(shù)據(jù)倉庫中的數(shù)據(jù)結構和擴展性問題，除結合標準外，還需要依據(jù)運營商實際的用戶特點，結合用戶自身屬性進一步地研究制定。

（2）Ud接口協(xié)議的選擇

Ud接口目前存在兩種協(xié)議：LDAP和SOAP，其中數(shù)據(jù)接入的相關消息主要采用LDAP，該協(xié)議訪問數(shù)據(jù)性能較強，但擴展能力較弱；簽約和通知消息主要采用SOAP，該協(xié)議擴展能力較強，但是訪問數(shù)據(jù)性能較弱。目前來看雖然該接口已有標準定義，但是目前廠家在該接口的開放程度并不一致，在LDAP和SOAP兩種協(xié)議的選擇和使用上也存在差異，因此在部署的時候，由于Ud接口是應用前端和用戶數(shù)據(jù)倉庫之間的接口，在前端和后臺數(shù)據(jù)的選擇上需要同廠家才能實現(xiàn)。

5 發(fā)展策略與建議

從用戶的角度來看，用戶希望運營商能夠為其提供專享與定制化的服務。因此，運營商應當考慮確保服務的實時性和管理的精確性。為了更多地從用戶行為和需求中獲益，已經(jīng)有越來越多的運營商考慮通過部署用戶數(shù)據(jù)融合解決方案實現(xiàn)數(shù)據(jù)的融合。

從前面標準現(xiàn)狀來看，國際標準組織中UDC的標準研究和支持程度相對完善，廠家目前的產(chǎn)品也多以UDC的標準來構建，但目前對于AS存儲的數(shù)據(jù)并沒有考慮融合到UDC構架中，AS對于用戶數(shù)據(jù)的訪問并不像HLR/HSS那樣直接通過UDC參考架構中的Ud接口，而是通過AS與HLR/HSS間的接口以透明數(shù)據(jù)的訪問方式進行。

目前運營商的2G用戶和3G用戶的數(shù)據(jù)基本都是采用共HLR的方式，個別已經(jīng)部署IMS網(wǎng)絡的運營商有HSS和AS設備，從用戶數(shù)據(jù)融合的發(fā)展考慮，鑒于目前設備廠家在Ud接口的開放程度以及信令協(xié)議一致性上存在差異，以及現(xiàn)網(wǎng)AS、HLR/HSS存在不同廠家互通要求，因此現(xiàn)階段在網(wǎng)絡部署時，首先可以考慮在逐步采用分離架構演進現(xiàn)網(wǎng)上傳統(tǒng)的HLR，部署HSS后，構建同時支持HSS FE和HLR FE的后臺數(shù)據(jù)庫UDR，同時需要注意的是后臺數(shù)據(jù)庫體系的建設應采用靈活開放的系統(tǒng)，為網(wǎng)絡后續(xù)建設和發(fā)展的需要，為其他的應用前端的逐步引入留出余量。其次建議AS與HLR/HSS仍按兩類網(wǎng)元來分開部署，AS可以通過Sh接口訪問HLR/HSS中的透明數(shù)據(jù)，待Ud接口逐漸規(guī)范成熟后，再考慮在UDR中真正融合AS的相關用戶數(shù)據(jù)，使得AS可以通過Ud接口直接訪問UDR中數(shù)據(jù)。

具體用戶數(shù)據(jù)融合的網(wǎng)絡演進策略建議如下。

第一步：考慮對現(xiàn)網(wǎng)傳統(tǒng)的HLR進行分離架構的演進，若HSS開始部署，建議直接采用分離架構HSS來建設，該階段需要完成的工作主要有：

·考慮現(xiàn)網(wǎng)傳統(tǒng)HLR逐步過渡到分離架構；

· 若部署HSS，建議直接采用分離架構，融合HLR和HSS的數(shù)據(jù)庫，構建同時支持HSS前端和HLR前端訪問的后臺數(shù)據(jù)庫；

·若Ud接口成熟，可考慮前端和后臺數(shù)據(jù)庫采用異廠家來組網(wǎng)。

第二步：逐步將AS的業(yè)務數(shù)據(jù)統(tǒng)一到用戶融合數(shù)據(jù)庫中去，該階段需要完成工作主要有：

· 對于AS，初期可以由AS自行保存業(yè)務數(shù)據(jù)，若Sh接口已開放，可簡化AS中的數(shù)據(jù)，逐步整合到HSS/HLR的統(tǒng)一后臺數(shù)據(jù)庫中，AS可以通過Sh接口向HLR/HSS請求后臺數(shù)據(jù)庫中的透明業(yè)務數(shù)據(jù)，或將透明數(shù)據(jù)存入后臺數(shù)據(jù)庫中；

·長期發(fā)展穩(wěn)定后，可以逐步將AS作為應用前端，直接通過Ud接口與后臺統(tǒng)一的數(shù)據(jù)庫UDR連接，完成數(shù)據(jù)的訪問存儲；

·依據(jù)實際情況，可以考慮將現(xiàn)網(wǎng)中傳統(tǒng)業(yè)務平臺的數(shù)據(jù)逐步移植到統(tǒng)一數(shù)據(jù)庫中。

總的來看，融合數(shù)據(jù)庫技術統(tǒng)一存儲用戶數(shù)據(jù)，方便多種業(yè)務應用的融合，利于新業(yè)務開展和易于集中維護，節(jié)省運維成本，符合未來統(tǒng)一的融合數(shù)據(jù)庫的發(fā)展趨勢。目前各設備廠家對Ud接口的實現(xiàn)以及開放性程度并不一致，且現(xiàn)網(wǎng)的HLR、HSS、AS等網(wǎng)元相對獨立，因此現(xiàn)階段在現(xiàn)網(wǎng)中可以考慮逐步用分離架構HLR替代傳統(tǒng)集中式的HLR。今后待融合數(shù)據(jù)庫技術成熟，即數(shù)據(jù)訪問的Ud接口統(tǒng)一開放之后，可將HSS、AS等用戶數(shù)據(jù)逐步融合到后端統(tǒng)一的數(shù)據(jù)庫中，實現(xiàn)HLR、HSS、AS等業(yè)務數(shù)據(jù)的共享，降低數(shù)據(jù)冗余，提高數(shù)據(jù)訪問效率。

6 結束語

在電信用戶市場對數(shù)據(jù)業(yè)務提出更高需求的背景下，運營商對用戶數(shù)據(jù)的管理提出了更為精細化的需求，因而用戶數(shù)據(jù)融合的發(fā)展受到了越來越多的關注。作為降低運營成本和資本支出的關鍵手段之一，用戶數(shù)據(jù)融合技術可以幫助運營商改善數(shù)據(jù)孤島的現(xiàn)狀，集中用戶數(shù)據(jù)，從而高效管理用戶的數(shù)據(jù)服務。

未來所有CS/PS、LTE、IMS數(shù)據(jù)都可以融合在后臺統(tǒng)一的融合數(shù)據(jù)庫中。用戶數(shù)據(jù)融合后，可實現(xiàn)用戶及業(yè)務數(shù)據(jù)的共享，降低數(shù)據(jù)冗余，減少數(shù)據(jù)訪問信令的交互。本文主要對融合數(shù)據(jù)庫技術國內(nèi)外的標準進展情況進行研究，思考融合數(shù)據(jù)庫目前存在的問題，探討電信網(wǎng)絡融合數(shù)據(jù)庫演進發(fā)展，思考如何逐步對AS、HLR、HSS等數(shù)據(jù)庫進行統(tǒng)一管理，達到簡化現(xiàn)有網(wǎng)絡，充分挖掘用戶，為運營商網(wǎng)絡向未來網(wǎng)絡平滑演進的目的，為運營商網(wǎng)絡平滑演進提供思考和建議。

1 3GPP TS23.335.User data convergence;technical realization and information flows;stage 2,2009

2 3GPP TR 22.985.Service requirement for the userdata convergence(UDC),2008

3 3GPP TS 29.335.User data convergence (UDC);user data repository access protocol over the Ud interface;stage 3,2010

4 3GPP TS 32.181.User data convergence (UDC);framework for model handling and management,2010

5 3GPP TS 32.182.User data convergence (UDC);common baseline information model(CBIM),2010

6 劉鸝娟.統(tǒng)一用戶數(shù)據(jù)庫的分析和設計.現(xiàn)代電信科技，2009（4）

7 王明虎，段承恩，丁浩.打造融合的用戶業(yè)務數(shù)據(jù)中心.移動通信，2008（5）