WRNC系統(tǒng)中單用戶跟蹤的設計
加入技術交流群
本文引入一定的機制，使無線網(wǎng)絡控制器RNC（Radio Network Control）內(nèi)部能夠方便、準確地收集到單用戶數(shù)據(jù)處理中各個環(huán)節(jié)的統(tǒng)計信息，便于快速地對單用戶信息進行統(tǒng)計與核對，提高問題分析的效率。
1 速率問題的產(chǎn)生及現(xiàn)象
RNC內(nèi)部速率問題的產(chǎn)生主要有3個原因：(1)用戶面處理數(shù)據(jù)包不當，異常丟包；(2)控制面?zhèn)鬟f給用戶面的接續(xù)參數(shù)有誤，用戶面與承載無法銜接；(3)用戶面自身在處理各種接續(xù)關系時處理不當。
在實際應用中幾種不同情況的速率現(xiàn)象分別為：(1)HSDPA/HSUPA業(yè)務進行時上下行速率不穩(wěn)定；(2)HSDPA/HSUPA業(yè)務進行過程中出現(xiàn)速率掉鉤；(3)HSDPA/HSUPA PS業(yè)務無法達到簽約的預期速率；（4） 速 率正常。
2 傳統(tǒng)的定位方法及缺陷
目前，傳統(tǒng)的速率定位方法分為3種：SHELL命令定位、DSP打印定位和信令跟蹤定位。
但是對于外場定位來說，這些傳統(tǒng)的定位手段卻很難實現(xiàn)。首先，SHELL命令定位，外場接口板數(shù)量多，承載著不同的業(yè)務，需要在接口板之間輪流輸入SHELL命令，顯得極其麻煩，同時SHELL命令只能跟蹤所有的業(yè)務流量信息，無法針對特定用戶，缺少針對性。其次，外場對于打印有嚴格的要求，一般不允許開啟內(nèi)部打印，正式的商用局資源本來就比較少，開啟內(nèi)部繁多的打印，會影響整個系統(tǒng)的運行。最后，信令跟蹤只是記錄控制面的基本信息，對于用戶面的檢查無法起到真正的幫助作用。
因此對于此類問題，需要有一個良好的定位方法將問題鎖定在具體的接口或者FP層面上。單用戶跟蹤正是針對這個缺陷設計的，其優(yōu)點是：(1)數(shù)據(jù)的上報通過后臺信令跟蹤來記載，利于觀測；(2)數(shù)據(jù)跟蹤以FP為單位，直接定位到業(yè)務通道，定位準確；(3)對正常的設備運行不會增加額外的開銷，且不需要進行多余的手工操作，使用方便。
3 單用戶跟蹤的設計及實現(xiàn)
3.1 WCDMA系統(tǒng)的整體概述
WCDMA系統(tǒng)主要由三大核心部分組成，分為核心網(wǎng)(CN)、無線網(wǎng)絡控制器(RNC)和基站(NodeB)。RNC連接著CN和NodeB，在整個WCDMA中起著舉足輕重的作用。RNC和RNC之間用IUR口連接。RNC分為CRNC(控制RNC)、SRNC(服務RNC)和DRNC(漂移RNC)三部分[5]。
3.2 單用戶跟蹤的數(shù)據(jù)流
RNC內(nèi)數(shù)據(jù)流的路徑分為兩條，一條是通過IUB口直接進入SRNC，途經(jīng)IU口到達CN；另一條是通過IUB口先到達DRNC，再由DRNC經(jīng)IUR口到SRNC，最后到達CN[6]。如果能在每個結點處對各個FP的數(shù)據(jù)包進行統(tǒng)計，對比各個結點數(shù)據(jù)的流量，就能迅速定位出數(shù)據(jù)丟失的接口和FP。
3.3 單用戶跟蹤的整體設計
UTRAN各個接口的協(xié)議架構是按照一個通用的協(xié)議模型設計的，如圖1所示。設計的原則是層間和平面間在邏輯上相互獨立。從水平層面來看，協(xié)議結構主要包括兩層：無線網(wǎng)絡層和傳輸網(wǎng)絡層。所有UTRAN相關問題只與無線網(wǎng)絡層有關，傳輸網(wǎng)絡層只是UTRAN采用的標準化的傳輸技術，與UTRAN的特定功能無關。從垂直平面來看，協(xié)議結構包括控制平面、用戶平面、傳輸網(wǎng)絡控制平面和傳輸網(wǎng)絡用戶平面[1]。
本設計根據(jù)UTRAN的協(xié)議架構，分為以下幾個模塊：消息處理模塊、控制面、用戶面、承載管理模塊和信令跟蹤模塊。
整個單用戶跟蹤設計思路如圖2所示，其中實線代表控制流，虛線代表數(shù)據(jù)流。
對于控制信息來說，后臺將媒體面跟蹤的任務分配到消息處理模塊（Daemon），Daemon通知控制面CP(Control Plane)和用戶面UP（User Plane）?？刂泼嬖诔休d鏈路建立和刪除時通知承載管理模塊BM（Bear Management,BM）建立和刪除相關的承載跟蹤。從消息中提取相關信息，并發(fā)送消息通知接口板，接口板收到消息后，設置好過濾條件，對處理的報文進行過濾統(tǒng)計。
對于數(shù)據(jù)業(yè)務流來說，收集跟蹤信息后，接口板和用戶面直接將跟蹤信息上報到Daemon。Daemon將消息的內(nèi)容進行核對后上報給后臺。
3.4 單用戶跟蹤的實現(xiàn)流程
為了在現(xiàn)有體系的框架下順利實現(xiàn)各個接口FP的流量上報，設計如下2個流程：任務的啟動和數(shù)據(jù)的上報及核對。
評論