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

（中訊郵電咨詢設(shè)計(jì)院有限公司 北京 100048）

1 前言

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

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

2 標(biāo)準(zhǔn)現(xiàn)狀

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

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

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

UDC概念是3GPP在R9版本引入的，于2008年立項(xiàng)研究，其主要目的是為了解決跨域及跨網(wǎng)元的數(shù)據(jù)融合問題。該標(biāo)準(zhǔn)建議把用戶數(shù)據(jù)統(tǒng)一存儲在一個(gè)獨(dú)立的用戶數(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ù)的訪問。

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

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

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

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

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

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

3 UDC關(guān)鍵技術(shù)

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

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

（4）應(yīng)用前端

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

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

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

（6）Ud接口

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

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

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

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

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

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

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

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

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

從用戶的角度來看，用戶希望運(yùn)營商能夠?yàn)槠涮峁Ｏ砼c定制化的服務(wù)。因此，運(yùn)營商應(yīng)當(dāng)考慮確保服務(wù)的實(shí)時(shí)性和管理的精確性。為了更多地從用戶行為和需求中獲益，已經(jīng)有越來越多的運(yùn)營商考慮通過部署用戶數(shù)據(jù)融合解決方案實(shí)現(xiàn)數(shù)據(jù)的融合。

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

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

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

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

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

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

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

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

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

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

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

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

6 結(jié)束語

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

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

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ù)庫的分析和設(shè)計(jì).現(xiàn)代電信科技，2009（4）

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