全球专业中文经管百科,由121,994位网友共同编写而成,共计436,047个条目

分散式HLR

用手机看条目

出自 MBA智库百科(https://wiki.mbalib.com/)

目錄

什麼是分散式HLR

  分散式HLR是一種新型HLR結構,該結構將接入設備和用戶資料庫分離,具有傳統HLR所不具有的多種優勢。

分散式HLR基本組成及原理[1]

  分散式HLR採用分層設計的理念.將傳統HLR中用戶資料庫模塊和信令接人及處理模塊分離.基於IP網路互聯.採用標準的的開放性介面,與具體應用無關.實現了業務邏輯與用戶數據的分離組網架構。

  (一)分散式HLR基本組成及介面協議

  分散式HLR系統由前端(FE)設備和用戶資料庫(UDR)設備組成,其功能實體通過特定拓撲、介面構成分散式HLR網路結構。

  FE(Front End):

  前端功能實體.提供TDM、IP等對外信令介面以及應用處理功能,實現協議接入與業務處理。HLRFE(HLR前端功能實體)實現MAP協議的接人與業務處理功能.HSSFE(HSS前端)功能實體實現Diameter協議的接人與業務處理功能分散式HLR系統中的FE類型可以根據業務需求靈活擴展。

  UDR(User Data Repository):

  用戶資料庫,又稱BE.實現用戶數據的存儲、訪問、管理、接人控制、同步等功能。作為網路中統一的用戶數據中心,存儲統一用戶數據模型.即將同一用戶分佈在不同網元上的數據融合起來.設置用戶ID作為基本標識.按照統一的數據結構組織.作為所有網路的惟一用戶數據源.從而為多個網元提供用戶數據的統一管理和訪問。介面與協議:

  分散式HLR將傳統HLR中用戶資料庫模塊和信令接人及處理模塊物理分離,因此分散式除支持傳統HLR的基於MAP協議相關介面外新增加了下列介面:

  Rz:FE與UDR間介面.採用基於TC-IP的LDAP(Lightweight Directory Access Protoco1)協議,提供數據的訪問,其介面與具體數據結構無關。

  Rs:UDR與UDR間介面.用於用戶資料庫間用戶數據的同步功能,基於IP互聯.目前採用不同設備廠家採用各自的私有協議cx、Dx、sh、Dh:HSSFE與IMS系統中CSCF、AS等相關網元的介面.採用基於IP承載的Diameter協議。

  (二)分散式HLR的組網方案

  (1)分散式HLRBE內部組網方案

  為達到用戶資料庫滿足電信級可用性和可靠性要求.BE採用分散式數據存儲架構.BE具備N+K負荷分擔容災能力.BE問內部組網可按照主備或負荷分擔方式組網如一對BE之問可建立相互備份關係並通過Rs介面進行用戶數據實時更新同步.其中任意一個BE設備故障對用戶業務無影響BE間可分多物理地點設置以實現物理地理上容災。

  BE組網支持如下兩種方式:兩地設置、三地設置通常採用主備方式或負荷分擔方式與FE進行通信.當主用BE故障時.其中一個BE將變為主用,承擔業務。

  (2)分散式HLRFE與NO.7信令網組網方案。

  FE主要提供TDM、IP等對外信令介面以及應用處理功能.FE不再存儲用戶數據.因此FE可以服務於任何用戶多個FE可以組成一個“池”.“池”內FE間可以以負荷分擔或主備用N+K實時容災備份方式工作。當池內某個(或某些)FE發生故障時,“池”仍然正常工作.不影響業務。

引入分散式HLR的必要性[2]

  通信網路中,用戶是網路服務的主體,對運營商而言,用戶數據信息是至關重要的資源。目前各移動運營商的現有移動通信網路中,用戶數據均存儲在HLR中,隨著用戶規模的不斷擴大和業務的不斷發展,引入分散式HLR的已經十分必要,主要原因有以下幾個方面:

  (1)傳統HLR的容災成本高,容災效果不理想。由於用戶數據的重要性,因此HLR的安全問題十分重要。目前,現網HLR容災方式主要有以下兩種:同廠家的HLR1+1實時容災,該容災方式是將兩個相同的HLR地理位置分佈並且提供之間的數據實時同步技術,來實現系統實時容災切換。由於備用HLR在平時為閑置狀態,導致該解決方案設備利用率低,成本較高。另一種方式為異廠家的N+I非實時容災,一個HLR容災中心為多個不同廠家的主用HLR提供容災備份。由於目前沒有開放的HLR間同步數據的介面,該方案只能通過BOSS同步靜態數據,用戶位置信息等網路修改的動態數據無法實時備份,導致在主用HLR宕機,切換到容災中心時,有一定的業務損失,無法提供實時容災功能。

  分散式HLR具備靈活有效的容災機制。分散式HLR中,業務處理節點(FE)和資料庫節點(BE)均支持N+K實時備份和負荷分擔機制,而且分散式HLR的業務處理與數據存儲部分可採用不同的容災備份機制。對於重要的用戶數據的容災備份,可以採用“2N或3N”的方式進行實時備份,對於業務處理部分可以採用池組的方式進行容災,這樣即保證了用戶數據的可靠性,又能控制整個系統的成本,真正做到根據需要靈活選擇容災備份方案。

  (2)傳統HLR新業務開展困難。由於目前核心網路中用戶數據分佈在BOSS、HLR以及SCP等多個網元,各網元內部的應用和數據耦合度較大。因此在開展新業務時,需要升級多個網元的資料庫子系統和應用子系統,並且需要考慮網元間的數據一致性以及配合交互等問題,導致新業務開展成本很大。引入分散式HLR後,業務拓展能力大大增強。分散式HLR的數據存儲模塊和應用模塊松偶合,提供開放的資料庫訪問介面,便於第三方應用獲取用戶數據,極大節省業務部署成本,並降低增加新業務數據的複雜性,增強運營商提供創新業務的能力。

  (3)傳統HLR單個設備容量偏小、單用戶占用資源高。在移動網路用戶數量增加迅猛,需要提供大容量的HLR滿足移動用戶迅速增漲的需求的現實情況下,現網HLR設備存在單用戶的集成度低,空間占用大,功耗高,號碼資源,傳輸資源利用率低等缺點。

  分散式HLR採用電信級IT平臺作為硬體平臺,各廠家設備均具備千萬級以上的用戶處理能力,設備集成度提高,能夠有效降低單位用戶造價和功耗。

  (4)傳統HLR數據管理手段落後,資料庫中垃圾數據難以清理,IMSI與MSISDN對應混亂問題無法解決。HLR中放號時的數據IMSI和MSISDN對應關係原本是正確的,但當出現用戶換卡時,就可能出現IMSI和MSISDN對應關係發生混亂的情況。這一問題會引起兩個後果,一個是造成HLR用戶數據遷移困難,另外一個是進行交換機數據配置時,需要將端局和LSTP/HSTP的號段數據做成千號段,甚至更細的劃分才能保證正確的數據路由,大量的號段數據給維護帶來了很大的工作量和困難。

  目前,分散式HLR的容量一般都在千萬級甚至億級以上,多個具有相連號段的現有HLR用戶數據將彙集於一個BE。上述用戶數據的IMSI與MSIS—DN號段配對合併,重新合併成為萬號段甚至更大粒度號段,將極大減小數據路由層的路由信息量

  另外,由於分散式HLR的路由層擁有到所有用戶數據的路由信息,使得包括MSC在內的業務系統極大簡化路由表。在一個省網採用一套大容量分散式HLR的前提下,業務系統對省內所有用戶數據的路由可以通過合併省內所有號段並指向任一HLRFE實現,大大簡化網路和數據配置複雜度。

  (5)傳統HLR由於介面數量較少、數據訪問效率低下、協議(MML)處理和數據訪問功能串列緊耦合等原因造成BOSS介面能力有限,導致BOSS對用戶簽約操作的不穩定執行,進而造成BOSS和HLR中的數據不一致,產生計費、統計信息錯誤等管理問題,並造成用戶投訴

  針對這一問題,分散式HLR以負荷分擔方式處理BOSS突發性大量操作,提高用戶簽約數據的存取效率。協議處理和數據訪問功能分離且可以獨立靈活、動態擴展,實現BOSS操作任務多路徑並行分流處理,避免了BOSS操作任務流擁塞瓶頸,極大地提高了BOSS介面效率。

  綜合上述分析,分散式HLR將是今後HLR技術發展的方向,在網路中根據容量擴充和業務需求引入分散式HLR是有必要的。

分散式HLR引入策略[2]

  針對目前現網已有大量傳統HLR且分散設置的網路現狀,分散式HLR的引入可分為以下三個階段:

  (1)規模試商用階段。傳統HLR與分散式HLR獨立建設,HLR按需板卡擴容但不再新建新局點,新引入板卡必須具備軟體升級到HLRFE能力,並以設備擴容為契機,規模新建分散式HLR局點,引入HLRFE和BE。

  (2)全面擴張階段。在分散式HLR組網的可行性、實用性得到充分的現網驗證後,全面停止傳統HLR設備擴容,所有新增用戶數據採用分散式HLR解決。

  (3)全面替代階段。隨著傳統HLR的設備老化、廠商停止支持,逐漸用分散式HLR替代。對於傳統HLR,充分考慮軟體升級至分散式HLRFE以利對原有設備的投資保護。

參考文獻

  1. 陳曉偉.分散式HLR技術問題探討[J].科技致富嚮導.2014,30
  2. 2.0 2.1 王鋼,李繼.分散式HLR技術及引入策略研究[J].現代電信科技.2009,8
本條目對我有幫助1
MBA智库APP

扫一扫,下载MBA智库APP

分享到:
  如果您認為本條目還有待完善,需要補充新內容或修改錯誤內容,請編輯條目投訴舉報

本条目由以下用户参与贡献

Mis铭.

評論(共0條)

提示:評論內容為網友針對條目"分散式HLR"展開的討論,與本站觀點立場無關。

發表評論請文明上網,理性發言並遵守有關規定。

打开APP

以上内容根据网友推荐自动排序生成

官方社群
下载APP

闽公网安备 35020302032707号